> I'm just glad New Zealand finally found an industry more lucrative than sheep herding.
It's called beef. There are still plenty of sheep about but the numbers have gone down as more cows have been raised - since milk solids and beef are worth more than lamb and mutton at the moment. Yes, I'm from New Zealand so we do hear about these things.
Part of New Zealand's supposed "struggling" economy is the fact that our public debt (eg that of the government and people) is relatively low as a proportion of GDP compared to say, England, Greece etc. The economic growth rate is around 1% and poised to slow to about half that, but at least it is still growing. As a result the New Zealand dollar has been getting stronger vs the greenback etc. This helps importers but hurts exporters as NZ goods become more expensive overseas. Naturally every country would like to optimize exports vs imports, so it is a balancing act between making our goods competitively priced and easier to sell and our imports cheaper.
One observer from the UK once noted that in the UK the public would have a large segment of national news devoted to football in New Zealand he found it was devoted to economic news instead. For a little flea like us, we notice whether the dog or the tail is wagging:)
ps. I liked your joke. I just took the opportunity to bring up some tidbits you'd never hear otherwise - not that anyone is particularly interested, but the New Zealand economy is not often its own slashdot topic. Incidentally, New Zealand has some pretty hi-tech and innovative outfits, kinda like Israel (similar population) does (although New Zealand has a vastly larger land mass than Israel; about 77% of Germany in size).
Great comment. Some folks on these forums seem to love re-inventing the *same* problems with different tools. They learn development languages and compare them, citing the well-worn "If all you have is a hammer...".
For me, I prefer to choose one very general purpose and performant language every half-decade or so. At the moment I'm still getting great mileage out of Java. While I take peeks at other languages for me Java is still fast enough, general purpose enough, comprehensive enough and evolving enough to get stuff done in almost any application domain (I like GWT/vaadin for the Web, JoGL for 3D stuff, and modern Swing for the UI). Now, because I have stabilized on that toolset (which is also cross-platform) that means I then free my mind to work on the important stuff, the application domain.
While there are plenty of jobs that are just shuffling fields between database, memory and screen I'm fortunately enough to get some hard problems too - device control, scientific problems etc. Now rather than try and learn the language-du-jour I've been learning how to solve hard problems (re-using the ever-broadening Java knowledge and toolset I've built up over time). I understand how many hate Java, or consider other languages better for specific purposes, but for me Java is good enough and the benefit of having my mind free to work on hard problems (optimising and implementing linear algebra, calculus, and GLSL shader problems, for example) is worth not following some of these new, short-lived, narrow-utility languages.
So, in this regard. My experience leads me to agree with your statements 100%. In my case, I do have a strongly preferred technology, but that is just because re-using complicated modules I've developed saves me time. I find it is simply not possible to solve hard problems from scratch each time you have a new hard project - that's why I try and stick with a cross-platform, efficient, general purpose technology (even if I'm tempted by niceties in other languages from time to time - but it turns out they are not worth the loss of code reuse, IMHO).
> You are really funny. Why would async/await be handy to bang out smaller stuff quickly? Async/await isn't really relevant for anything but large multi threaded applications that need to scale.
Another fail. The design intend was not for large multi-threading problems (easily covered by existing constructs) but for handling UI events without affecting the responsiveness of the software - or so say the C# designers. Surely you read their intent?
Oh, here's another fail. I say: Is it true or not that TypeScript adds (removable) annotations to Javascript, and hence can be considered a variant of Javascript? true or false?
You say: False. The TypeScript website says (in 30 point font, at the top, on every page): TypeScript is a language for application-scale JavaScript development.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Superset, get it yet? even the authors consider TypeScript a dialect of JavaScript (dialects do not necessarily have to be fully mutually intelligible, they just have to share a common base).
Oh, and in your paragraph stating, "And you are still spouting nonsense out of your ignorant ass. Really. Check it out. They are not working on JScript at all, they are working on JavaScript, and the annotations they are adding are not single vendor. If you had not been so fucking retarded that you had to go an spout all kinds of nonsense about a technology you have not bothered (I am assuming it must be due to the lack of ability) to read a damned thing about. Hint: The annotations are in line with ECMA future. Check it out and stop being such a fucking idiot."
Not only were you wrong, but you were so badly wrong you added "ignorant ass", "so fucking retarded", "spout all kinds of nonsense about a technology you have not bothered (I am assuming it must be due to the lack of ability) to read a damned thing about.", "fucking idiot" about something I was right about and you were being totally idiotic about. Somehow you thought that liberally lacing with insults would make your ignorant statement true, through sheer force of willpower perhaps? Somehow you thought that this was the only mistake you made. Somehow you thought you didn't mix in ad-hominems as well (hint: it is not a boolean function as you stated but instead a spectrum, ad-hominems can still be present even when other valid points are made in a debate), but you most surely did. Even. When. You. Were. Wrong.
Fare well. No more feeding trollish behaviour for me. Plus, I've learned everything I need to from and about you. Unfortunately, I don't think you'll learn to temper your anger and arrogance with this debate. That's a real shame, it will ruin your life in the long term. Pax.
> Also, my error rate in C# is lower than in Java because I have to write quite a lot less code in C# compared to Java.
Most of the extra boilerplate code in Java should be generated. There are a few savings in C# compared to Java on smaller projects, but on big projects the time and effort is in complex logic, not boilerplate. LINQ is great. For you this is obviously sufficient. For me, cross-platform is vastly more important and the advantage of LINQ over JPA2 is not enough (don't worry, I understand that this is not your view, I'm just presenting mine). With regard to error rate, well I never care what the initial rate is - only the rate once you have finish unit, integration and system testing (which should make both languages the same given the same functionality).
> With the new.NET 4.5 and things like async/await, writing scalable server applications is going to be even easier, probably increasing the 20% to some 30-40% given the number of problems found in async programming which is now a breeze in C# and.NET.
Handy, but the amount of lines you save over a Java Runnable in a quarter million line program is completely negligible in my personal experience. The effort is expended elsewhere. However, async/await may just be handy to bang smaller stuff out quickly.
> You can't do autoboxing in the compiler it has to be in the VM.
Yeah, the obsession with maintaining backward compatibility at the bytecode level is indeed a bitch. I do like how old stuff and libraries still work though. Fair enough if you hate the cruft.
> My bad on JScript, I was unaware of this. You have caught my in my first error - the name of a product.
Bro, this is a fundamental fail. At least you can admit you were wrong. Here, I'll do the same. I txted my bro and and he is a bit fuzzy (20 years ago) but thinks it was kernel 0.12. We're both old timers, so your initial statement of be being in "diapers" ("nappies" they are called in my part of the world) was your attempt to circumvent debate but was incorrect. Incidentally, your "Yes, you are a dumb little liar, are you not?" statement is another fail. Completely unnecessary and uncivilized. It is ok for people to be wrong (as you point out), your behaviour is not ok on a public forum no matter how wrong you think I might be. In this case, you learned something about your bread and butter trade. In contrast, I knew you were wrong about JScript yet did I pillory you for it? No, I tried to be patient and get citations for you and convince you through reason rather than insults.
With regard to TypeScript, I have been to http://www.typescriptlang.org/ and http://typescript.codeplex.com/ and noticed out of the 37k page views and 14k+ visitors there have been 236 downloads. Looks like they're on to a winner there.I better bet my business on it quick.. With regard to your crew (oh, I hope you treat them well), yes learning ECMA script 6 is worthwhile. Although as Henry Ford famously said, "If I had asked people what they wanted, they would have said faster horses.". IMHO (and it is my opinion), you'd be better off training them to use GWT or vaadin or Script# or something like that. As is often said on the interweb, developing in JavaScript (and TypeScript) is analogous to developing in assembler. Yes you can do cool things, but by focussing on that you are missing out on the important big picture.
By all means, bet your business on TypeScript. Hopefully you will be a success (and all that TypeScript is still useable, if only the JavaScript is usable then why bother with the TypeScript extensions at all? why not just stick with your JS?). Meanwhile I'll still be recommending GWT and vaadin for higher productivity and great interactivity and a big ecosystem.
As explained by JavaScript guru Douglas Crockford in his talk entitled The JavaScript Programming Language on YUI Theater,
[Microsoft] did not want to deal with Sun about the trademark issue, and so they called their implementation JScript. A lot of people think that JScript and JavaScript are different but similar languages. That's not the case. They are just different names for the same language, and the reason the names are different was to get around trademark issues.[5]
JScript supports conditional compilation, which allows a programmer to selectively execute code within block comments. This is an extension to the ECMAScript standard that is not supported in other JavaScript implementations.
> "They are not working on JScript at all, they are working on JavaScript"
Lol, fail. "JScript" is Microsoft's trade name for their JavaScript implementation (at ECMAScript 3 level). There is no difference. Microsoft do as I did, use the term to denote that their Javascript variant (I did it to distinguish variants, they do it for trademark reasons). Now in IE 10 the tradename "JScript" may or may not be used officially - but it doesn't change anything for the purposes of our discussion. Your point was wrong... and your apoplexy was again for wrong reasons.
> Nobody does that. The patch is called IE9 and IE10.
I have given a link to IE9's significant compatibility flaws. It needs to be patched. So should IE 8. Yes, vendors do patch older versions of their products - this is industry wide. For developers it is called "working on multiple branches", and I have to do this all the time. I'm sure an experienced fellow like you has come across this, and is aware that is it critical to maintain older stuff in the enterprise space. Suggesting you fix things by just replacing the old with the new (eg. as small outfits can) is not realistic. In fact, back-ports and patching is something Microsoft is exceptionally good at in general - supporting and patching older stuff - just not with their browser. Hence, I see it as a possibility that *if* they focused they could fix their deployed browser base in the near future [without going to an entirely untested version, or resorting to JavaScript extensions]. This was the point I was trying to make.
> IE 10 is up there with Chrome, and on JavaScript, it is better than Chrome.
Great. Shame it is not yet released to the non-MSDN public. Shame it is not in the enterprise and won't be for some time. IE 10 is still not relevant to this discussion *at this point in time*. When it does I'll re-evaluate the compliance. Meanwhile, the only things that matter are the compliance of the deployed IE base and whether or not they get useful patches in the near term. No patches forthcoming means IE will still be despised - this is how my clients perceive IE.
> False. TypeScript includes removable annotations, but the annotations are not carried over to the compiled JavaScript.
TypeScript *is* a dialect of Javascript. Just because you convert it to Javascript means nothing (just as the Javascript being converted to machine instructions in the browser means nothing in the context of our discussion). By working in TypeScript you are still working in a single-vendor dialect of Javascript (eg. JScript). Now from your posts you seem to be a bit of an absolutist. Just because the compiler has been placed under the Apache license you believe you are not subject to lock-in. This is an absolutist and technologist point of view. To those less absolutist, say a businessman/CTO/consultant, then the lock-in is still there. Once you have a large code base written in TypeScript it is a pain to convert back to pure Javascript should you want to - yes the tool is provided, but this still takes time and effort (as in, money). This is still single-vendor lock in, just not as constrictive as it has been in the past. Don't think this is so? Well, you could always write C++ with various compiler-specific (eg. GNU) macros. Yes, you can strip these out and even have a functional program, but the effort to do so on a large code base is prohibitive - not because of technological reasons but because of practical business reasons. I will sound the same caution for those considering solutions that use custom GNU macros in their C++ as I am to those that think it is better to choose TypeScript rather than cross-browser JavaScript. The TypeScript project currently provides an out and is not too intrusive, but looking at history there is little guarantee this won't change (and less guaranteed that the whole technology won't bomb, as many Microsoft efforts have in the past). Hence, I urge caution of those considering adopting it as a direct implementation language (better to let their tools use it under the hood).
Now if you really want to improve the web experience why do a half-assed solution like TypeScript? If you are going to use a JavaScript-esque language then why not just bite the bullet and use something else (like Google's two languages, that have been around for longer and are reasonably well proven).
> You know nothing about me
This was in response to your post about me being in "diapers" while you were futzing around with Sun gear. Incidentally, both my brother and I were amazed when the Linux kernel we'd been using for a while reached 0.20 (not a typo). So (bad joke alert) you are still a short timer in my book. Off topic, I'm also curious why you hate Solaris. I always found it incredibly stable, and CDE was pretty good for the time (although it is incredibly dated now). Now it turns out you know nothing about me (eg. the PhD in Astrophysics, doing high-throughput image processing etc), but you still assume that I know nothing, despite you being incensed at me doing the same to you (sorry, it was teasing, I hope you can see your statements make assumptions about me, to which I responded in a way that made assumptions about you).
> It doesn't mean that I can't realize that Windows 8 server is probably the very best commodity operating systems for servers on the market today by a very decent margin
You are thinking like a technologist here and not a businessman. Windows server is decent (fortunately debacles like "Windows for Warships" are in the past). However, it cannot compete on *price* with Linux servers: both in terms of licensing cost, in terms of hardware required (headless for high-performance instances that aren't virtualized), and cheaper in terms of human labour per compute unit to maintain. When your go large you don't go Windows (as Google and the supercomputer clusters attest to). So Windows 8 is indeed excellent, but at least qualify your statement to say, "for SMEs" (Small-to-Medium Enterprises) as belies your experience. Windows 8 is not the absolute best commodity OS for all purposes, k?
I sent you the CSS3 compatibility link didn't I? Maybe not. Here is a handy comparison between browsers: http://www.findmebyip.com/litmus/
Note: IE9 is supposed to be CSS3 compliant (as stated by Slashdot user "shutdown -p now", who is a nice Microsoftie, although not on the browser team).
Perhaps you've been lucky enough not to be screwed up by all those read crosses, hence IE 9 is still golden for you. It just doesn't happen to be that way for some of us. You may still think I am an idiot, but I my experience is backed by a large number of fellow developers (as shown by that site, ).
It is my wish that Microsoft patch their older browsers for better compliance. Now IE 10 may be great, but the reality is we won't see in large enterprises for a few years. The pain developers feel is *now*. Hence my point, don't frig around adding single-vendor annotations to JScript, spend every ounce of effort fixing the dogs you already have running out on the real world - throw in every talented hand you have (why? because the current effort falls short). Yes, this is hyperbole, but it is meant to indicate that effort is being wasted creating new balkanizing technologies rather than fixing what is already in use.
Well, of course you have it easy if you don't even have to make it work on IE6 *as well as everything else*. Duh!
You accuse me of being ignorant yet you don't even have to solve the problems I was talking about. Unbelievable! You probably assume that no one else has to deal with the messes of IE 6 and XP as well as the latest and greatest stuff (I don't get to choose what my corporate clients run, they are far too big to dictate to).
I can't believe you have been such an venomous asshat yet you don't even have to solve the same range of problems that other web devs are cursed with - yet somehow you arrogantly assume you know it all and everyone else knows dick. I suppose I should "never attribute to malice what can be attributed to incompetence". Here's a pro tip, if someone is reluctant to use a brand spanking new tech it might even be because they have been bitten by tech (especially Microsoft tech) over the last two decades, and realise that the brochures don't cover all the hooks and pitfalls that can get you into trouble down the road. The reluctance is caution borne from hard-won experience, not some dogmatic crusade against a significant tech player (although it can sometimes seem that way, but admission that Microsoft does things right from time to time is a clue; I praise them for their license in this case).
> Wow, you still haven't read about TypeScript. You still base your comments solely on dogma and ignorance. Ass was an understatement.
Is it true or not that TypeScript adds (removable) annotations to Javascript, and hence can be considered a variant of Javascript? true or false?
> You'd know if you'd tried to use and deploy it.
Actually, I know an use GWT daily as well as vaadin. Here's a nice thing, I can use one tech no matter whether I'm on Linux or Windows or Mac. GWTs uptake at Google is irrelevant, because they are solving different problems than the average application developer (eg. how many enterprise apps need MapReduce? how many need to be coded down to the last javascript instruction because of millions of simultaneous users). So your assumption about me is false, and your statement about Google is not thought out. Who is the ass?
> No, I have not claimed that you should drool over TypeScript,
You defended TypeScript and then proceeded to make arguments that I have subsequently addressed. It still remains, Microsoft could have chosen to use Javascript with metadata defined in another file but instead they still want to alter the Javascript you produce (albiet in a way their tool can reverse). Is this incorrect? Without using their tool would the Javascript run without modification in another Javascript engine?
> Does it appear to you that I am a fan of IE10 and that I want people to go back to IE10 from Chrome? Have you found a single statement of mine that implies that?
Hmmm, let me see, "but for work I have to work with IE as well, and IE9 and 10 are really good browsers in their own right. Arguing that MS should drop TypeScript and work on IE instead is like saying Ford should stop making blue cars and work on better engines instead."
Well, I said IE sucks and Microsoft should work on those. In yous statement you say that IE 9 and 10 are "really good browser" (which the bulk of the web development community would disagree with, for IE 9 at least and IE 10 is not yet *publicly* released), and that the IE 10 preview in MSDN is basically gonna kick ass. I can only go on the statements you write, I'm afraid. Hence, any neutral reader would deduce you are a proponent of IE based on your statements - where you meant that you don't feel that my statements about IE brokenness were correct. Now you are backing away from this. This may not have been what you meant, but it is what you said. Therefore, your statements indicate you think IE is "great" and that there is little point in getting Javascript experts involved in fixing Javascript support in IE.
> You think that I, since I have said that Microsoft has done a good job with IE9 and now IE10, I am a fan of said browsers and that I am dying to use them.
I can only go on what *you said*. If you believe IE need work (eg. compared to Chrome) then why be contrary and say they are great? If you don't think that IE has more faults than its current competitors then why attack my statements where I suggest this is a more significant problem than enhancing Javascript with their own set of annotations? Why? Why indulge in your continued ad-hominems ("hallucination medications", "voices in your head are not real" etc) rather than just say, "well I think doing more for Javascript development is good, and maybe IE 9 could use some work for better CSS3 compliance and definitely work on speed-ups in hotspots". Instead, you chose to be obnoxious and spray around insults, then reverting some the stronger positions made in your earlier posts. I would ask why but it is clear, you have a bit of a temper issue and it is you who is dogmatic about defending indefensible positions - is this not true?
> Oh, and BTW, IE10 is released to MSDN subscribers now (has been for a while) and will be released to the rest of the world in about three weeks.
That is good news that IE 10 is improving. In a couple of years it will make it to the corporate desktop. Hopefully the goalposts won't have moved too far by then. Meanwhile, Microsoft will fiddle around creating *yet another* Javascript variant while other companies are progressively eating their lunch. Perhaps you think it is a non-issue but while Microsoft have slipped to #3 tech company by market cap. They can and should do better, but fidgetting with Javascript is not going to help them. Typescript may give an certifiable MSDN type like yourself a woody but to the rest of us hard working devs it is merely putting lipstick on the pig that is Javascript. Personally, I'd much rather Microsoft had competed with GWT through its Project Volta but instead they abandoned it - which is something they may well do with TypeScript (and with other useful but orphaned technologies of theirs). If you don't think TypeScript could be abandoned in the same way then you need to "get some time up" - Apache license or not, it'll always be MS' baby.
Unfortunately what doesn't seem evident to you is that the majority of users just happen to share the same point of view that I do, the current versions of IE are crap and as a result a substantial fraction of people are only IE because their work mandates it (this includes you, according to your post). Defending IE9 makes no sense to this substantial fraction, accept it has a lot more flaws than its competitors and move on.
Now we've been promised "newer, betterer, shinyer" before from IE. If IE 10 indeed nails it then Microsoft have a chance digging themselves out of the "potential well" they are currently in, Hey, I actually have an open mind that IE 10 could actually be great - but have been disappointed so many times before by them I now start very skeptical.
> Obviously Microsoft is working very hard to become compliant. What exactly is it that you are complaining about?
Do, or do not, there is no try. The Microsoft browser currently *publicly* available (that is, pay no money) have poor compliance. The Microsoft browsers currently deployed in enterprise (that is, older versions) have poor compliance. Yet a fanboi like yourself expects us to drool uncritically whenever Microsoft release an extended dialect of Javascript? Now it is excellent Microsoft have woken up - as they do when they are getting their asses handed to them in a particular market. It is excellent that Microsofties like "shutdown -p now" patiently explain their understanding of how TypeScript might be good. However, it is yet to be seen whether IE 10 is a "miracle save" when it is used by the non-MSDN masses that visit all manner of websites and webapps - and whether IE 10 is actually compelling enough for people to leave Chrome and Firefox to flock back to IE 10.
Care to make a wager about voluntary IE 10 adoption?
> I use Chrome my self, but for work I have to work with IE as well, and IE9 and 10 are really good browsers in their own right.
By "use" do you mean "use the browser as a result user", or do you mean "develop web applications for"? If the former then I understand your position, someone else has done all the hard work to patch over IE brokenness for you. In that case you are lucky (if somewhat ignorant of the actual issues).
If the latter, and you create cross-browser solutions, then I'd be very interested to know what toolkit you are using - IE 9 and earlier are a PITA!
> I was not, I was just pointing out the obvious. People who comment on things based solely on ignorance and bigotry are asses, no matter how you look at it.
Huh? you were indeed insulting unnecessarily. Please stop being an obnoxious wanker and then turning around and denying it. I welcome you debating my points, but it stops at you being a jerk. Get a grip on your attitude, please!
That information is interesting. It sounds as if IE is moving in the right direction. Once corporates adopt it (some time away, I'd imagine) it'll make a big difference for us in the trenches with better compliance.
Oops, I forgot to attach the nice reference, here it is: http://www.findmebyip.com/litmus/
So, for me, Microsoft spending effort on TypeScript is less useful than spending effort on getting IE working right for modern web development. Microsoft does have limited resources, spreading them shot-gun style is interesting for their employees but doesn't fix their fundamental issue, IE sucks and its release cycle so slow that it is always behind its competitors (who are relatively on-par feature-wise).
Then you are back to crap old Javascript:(
Optional type checking is a good thing. Backwards compatibility is a good thing. However, personally I think TypeScript is just-another-Javascript (of which we have shitloads of variants already), and too low level to make much of a useful impact. Far better to bite the bullet, and use a high-level abstraction, say Dart, or GWT, or Coffescript etc. Yes, when choosing these you really are committing to a technology - but the point is productivity and the end result. Is adding TypeScript annotations really worth the effort? perhaps for you but certainly not for me. TypeScript is intended to help produce large JavaScript applications but I think there are far better solutions out there for that. Hence, I argue that Microsoft are wasting their time with TypeScript and should have spent effort making IE better. Here's a quick n easy reference for the features peoples are trying to use in modern development, and browser support for them: . Note also these are functional aspects, the terrible performance of IE in certain operations is not addressed on that page.
Incidentally, I noticed you were severely enraged and resorted to calling me an ass. Personally I don't care, but you ought to consider that such fury is bad for your heart and long term health. People making statements on the Internet are probably not worth you getting so mad about - certainly not half a dozen posts to vent your spleen. Pax.
Oh, while I remember, this may be of interest to you. It is a colorful way of comparing modern feature compliance on browsers (and yes, I know that IE is designed for CSS 2.1, but everyone else has moved on to CSS 3 and that is what developers expect to use): http://www.findmebyip.com/litmus/
Please don't take this as a 'dig' at you or your employer. It's just an FYI from the other side of the fence.
> Admittedly I don't know much about the current flock of issues with IE - not being a web developer - but from what I've heard, IE9 was a massive improvement on IE8, and I've heard good things about IE10 as well - I wonder if your "100x slower than competitors" still applies there?
IE is improving, but it is still the bane of web developers. We had horrific performance issues when rendering map layers in IE9. With another client we have tooltips that don't work correctly on IE9 (but do on other browsers). It is true that all browsers have quirks, but IE just happens to have a lot more, and the ones it does have are unfortunately quite noticeable. Hence, a casual Google (or Bing) web search will reveal a lot of poor user experiences with IE9, and tribulations for web developers (feel blessed you don't have to deal with it:) with lots of stuff moving to the web lots of devs can't avoid it).
Exactly. To remove the code you still have a reliance on tools and vendors that you might prefer not to. Even if everything is open (as it is in this case, thank goodness), you still have to spend the effort running this 'preprocessor' to remove unwanted constructs. Probably the code that is remaining will lack something that the annotations gave (tying it together), which will require work to adjust the Javascript to work. This is speculation on my part (since I've not used Typescript, and it doesn't solve any particular problem for me, so I won't be using it in the near term), but I would be very surprised if something was not lost when annotations were removed (otherwise, what is the point of even having them?).
Java doesn't have yield as a keyword. That is not its philosophy to add lots of keywords (like C++), but instead to be like C and add such functionality to libraries (standard libraries in Java's case). Java has had Thread.yield since its release in the mid 90s. Even Java borrowed this concept from elsewhere (eg. pthread).
C# will continue, as I stated. It just won't be the focus of attention for Microsoft that it once was. This follows a historical pattern. I have experienced this with many Microsoft technologies I've used since the early days. Hence, this is a heads-up for anyone currently using it - you will be able to get things done, but don't expect to get the same level of love as you used to (unlike some languages and technologies).
You miss the point, I think. When you remove the TypeScript annotations what makes you think the remaining JavaScript will be useful. Usually the annotations are a core part of the implementation that ties disparate parts together. Without them you simply don't get the same application in the remaining code. Hence, it is an issue. Once you start using such things going back is not simple (it also takes time and effort/money to *remove* source components and ensure the remaining code actually works).
> Most of it is actually bog standard ES6 (for example, classes). The only proprietary bit here are type annotations. Which you can ignore altogether if you want, and then you just get a free, open-source implementation of a convenient subset of ES6 that spits out ES5.
You cannot ignore the annotations if the majority of libraries you are attempting to use are 'tainted' with them. This is the problem with injecting proprietary technology (behaviour not specific to Microsoft) into existing and widely used technologies (not only development languages). Historical example: the mutation of Kerberos for Windows, etc etc.
Now, if Microsoft were actually going to do something to improve the Javascript experience they would spend effort into make Internet Explorer work like the other browsers (which, despite pitiful resources, manage to be roughly similar in behaviour) and make it run fast (there are some Javascript operations in IE that are 100x slower than its competitors). I'm suggesting a 'profile guided optimization' here; leave Javascript/Ecmascript alone for now and fix the real point of pain of Microsoft tech on the web/mobile; the Abomination that causes Desolation, and premature aging of web devs (otherwise known as Internet Explorer).
> Anyway, this is open source (Apache license), and the implementation is itself written in TS, and runs on Node.js. In other words, it is in no way locked into any existing Microsoft technologies, completely self-sufficient, and you can fork and mod it to your heart's content, on any platform. There is no way to "extinguish" it for Microsoft from this point on, nor control you should you choose to use it, now or in the future.
Now *that* kind of behaviour is good, and I applaud Microsoft for choosing to do that. I'm sure it was techies like yourself that fought the good fight and sold your management that this was a Good Thing. Well done.
The probem isn't so much with C# the language/toolset. The problem is that in order for Microsoft to sell you new tools and tech it has to periodically change them just enough so you feel enough pain to shell out for new stuff. The other problem is that while C# is good for development it is clear that it is no longer an object of adoration in Microsoft's strategy. C# will always be around but it won't get the resources that the 'new hotness' team gets (eg. TypeScript). Meanwhile, those that use other tools (standard C++, Java etc) will keep plodding along, continuously evolving.
If you know Aesop's Tortoise versus the Hare fable then this is what is happening now. Those who always watch the speed of the hare miss the fact that a new hare is entered into the race every few years. Meanwhile, those not distracted by the hare are watching the tortoise and see how it is less flashy but progresses continuously. If you built your tech on the tortoise you still have good solutions. If you build your tech with the hare then every few years you either have to rebuild your tech for the new hare (expensive! this is what CTOs worry about and code-monkeys don't), drop your existing investment and start building again for the new hare (expensive and wasteful), or stay with old tech (painful, and now surpassed by the tortoise).
Slashdot Mirror
Dunno about the coins but the 'paper' (plastic) notes get printed in Singapore, although may have moved to Hong Kong now.
> I'm just glad New Zealand finally found an industry more lucrative than sheep herding.
It's called beef. There are still plenty of sheep about but the numbers have gone down as more cows have been raised - since milk solids and beef are worth more than lamb and mutton at the moment. Yes, I'm from New Zealand so we do hear about these things.
Part of New Zealand's supposed "struggling" economy is the fact that our public debt (eg that of the government and people) is relatively low as a proportion of GDP compared to say, England, Greece etc. The economic growth rate is around 1% and poised to slow to about half that, but at least it is still growing. As a result the New Zealand dollar has been getting stronger vs the greenback etc. This helps importers but hurts exporters as NZ goods become more expensive overseas. Naturally every country would like to optimize exports vs imports, so it is a balancing act between making our goods competitively priced and easier to sell and our imports cheaper.
One observer from the UK once noted that in the UK the public would have a large segment of national news devoted to football in New Zealand he found it was devoted to economic news instead. For a little flea like us, we notice whether the dog or the tail is wagging :)
ps. I liked your joke. I just took the opportunity to bring up some tidbits you'd never hear otherwise - not that anyone is particularly interested, but the New Zealand economy is not often its own slashdot topic. Incidentally, New Zealand has some pretty hi-tech and innovative outfits, kinda like Israel (similar population) does (although New Zealand has a vastly larger land mass than Israel; about 77% of Germany in size).
Great comment. Some folks on these forums seem to love re-inventing the *same* problems with different tools. They learn development languages and compare them, citing the well-worn "If all you have is a hammer ...".
For me, I prefer to choose one very general purpose and performant language every half-decade or so. At the moment I'm still getting great mileage out of Java. While I take peeks at other languages for me Java is still fast enough, general purpose enough, comprehensive enough and evolving enough to get stuff done in almost any application domain (I like GWT/vaadin for the Web, JoGL for 3D stuff, and modern Swing for the UI). Now, because I have stabilized on that toolset (which is also cross-platform) that means I then free my mind to work on the important stuff, the application domain.
While there are plenty of jobs that are just shuffling fields between database, memory and screen I'm fortunately enough to get some hard problems too - device control, scientific problems etc. Now rather than try and learn the language-du-jour I've been learning how to solve hard problems (re-using the ever-broadening Java knowledge and toolset I've built up over time). I understand how many hate Java, or consider other languages better for specific purposes, but for me Java is good enough and the benefit of having my mind free to work on hard problems (optimising and implementing linear algebra, calculus, and GLSL shader problems, for example) is worth not following some of these new, short-lived, narrow-utility languages.
So, in this regard. My experience leads me to agree with your statements 100%. In my case, I do have a strongly preferred technology, but that is just because re-using complicated modules I've developed saves me time. I find it is simply not possible to solve hard problems from scratch each time you have a new hard project - that's why I try and stick with a cross-platform, efficient, general purpose technology (even if I'm tempted by niceties in other languages from time to time - but it turns out they are not worth the loss of code reuse, IMHO).
> You are really funny. Why would async/await be handy to bang out smaller stuff quickly? Async/await isn't really relevant for anything but large multi threaded applications that need to scale.
Another fail. The design intend was not for large multi-threading problems (easily covered by existing constructs) but for handling UI events without affecting the responsiveness of the software - or so say the C# designers. Surely you read their intent?
Oh, here's another fail.
I say: Is it true or not that TypeScript adds (removable) annotations to Javascript, and hence can be considered a variant of Javascript? true or false? You say: False.
The TypeScript website says (in 30 point font, at the top, on every page): TypeScript is a language for application-scale JavaScript development. TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Superset, get it yet? even the authors consider TypeScript a dialect of JavaScript (dialects do not necessarily have to be fully mutually intelligible, they just have to share a common base).
Oh, and in your paragraph stating, "And you are still spouting nonsense out of your ignorant ass. Really. Check it out. They are not working on JScript at all, they are working on JavaScript, and the annotations they are adding are not single vendor. If you had not been so fucking retarded that you had to go an spout all kinds of nonsense about a technology you have not bothered (I am assuming it must be due to the lack of ability) to read a damned thing about. Hint: The annotations are in line with ECMA future. Check it out and stop being such a fucking idiot."
Not only were you wrong, but you were so badly wrong you added "ignorant ass", "so fucking retarded", "spout all kinds of nonsense about a technology you have not bothered (I am assuming it must be due to the lack of ability) to read a damned thing about.", "fucking idiot" about something I was right about and you were being totally idiotic about. Somehow you thought that liberally lacing with insults would make your ignorant statement true, through sheer force of willpower perhaps? Somehow you thought that this was the only mistake you made. Somehow you thought you didn't mix in ad-hominems as well (hint: it is not a boolean function as you stated but instead a spectrum, ad-hominems can still be present even when other valid points are made in a debate), but you most surely did. Even. When. You. Were. Wrong.
Fare well. No more feeding trollish behaviour for me. Plus, I've learned everything I need to from and about you. Unfortunately, I don't think you'll learn to temper your anger and arrogance with this debate. That's a real shame, it will ruin your life in the long term. Pax.
> Also, my error rate in C# is lower than in Java because I have to write quite a lot less code in C# compared to Java.
Most of the extra boilerplate code in Java should be generated. There are a few savings in C# compared to Java on smaller projects, but on big projects the time and effort is in complex logic, not boilerplate. LINQ is great. For you this is obviously sufficient. For me, cross-platform is vastly more important and the advantage of LINQ over JPA2 is not enough (don't worry, I understand that this is not your view, I'm just presenting mine). With regard to error rate, well I never care what the initial rate is - only the rate once you have finish unit, integration and system testing (which should make both languages the same given the same functionality).
> With the new .NET 4.5 and things like async/await, writing scalable server applications is going to be even easier, probably increasing the 20% to some 30-40% given the number of problems found in async programming which is now a breeze in C# and .NET.
Handy, but the amount of lines you save over a Java Runnable in a quarter million line program is completely negligible in my personal experience. The effort is expended elsewhere. However, async/await may just be handy to bang smaller stuff out quickly.
> You can't do autoboxing in the compiler it has to be in the VM.
Yeah, the obsession with maintaining backward compatibility at the bytecode level is indeed a bitch. I do like how old stuff and libraries still work though. Fair enough if you hate the cruft.
> My bad on JScript, I was unaware of this. You have caught my in my first error - the name of a product.
Bro, this is a fundamental fail. At least you can admit you were wrong. Here, I'll do the same. I txted my bro and and he is a bit fuzzy (20 years ago) but thinks it was kernel 0.12. We're both old timers, so your initial statement of be being in "diapers" ("nappies" they are called in my part of the world) was your attempt to circumvent debate but was incorrect. Incidentally, your "Yes, you are a dumb little liar, are you not?" statement is another fail. Completely unnecessary and uncivilized. It is ok for people to be wrong (as you point out), your behaviour is not ok on a public forum no matter how wrong you think I might be. In this case, you learned something about your bread and butter trade. In contrast, I knew you were wrong about JScript yet did I pillory you for it? No, I tried to be patient and get citations for you and convince you through reason rather than insults.
With regard to TypeScript, I have been to http://www.typescriptlang.org/ and http://typescript.codeplex.com/ and noticed out of the 37k page views and 14k+ visitors there have been 236 downloads. Looks like they're on to a winner there.I better bet my business on it quick.. With regard to your crew (oh, I hope you treat them well), yes learning ECMA script 6 is worthwhile. Although as Henry Ford famously said, "If I had asked people what they wanted, they would have said faster horses.". IMHO (and it is my opinion), you'd be better off training them to use GWT or vaadin or Script# or something like that. As is often said on the interweb, developing in JavaScript (and TypeScript) is analogous to developing in assembler. Yes you can do cool things, but by focussing on that you are missing out on the important big picture.
By all means, bet your business on TypeScript. Hopefully you will be a success (and all that TypeScript is still useable, if only the JavaScript is usable then why bother with the TypeScript extensions at all? why not just stick with your JS?). Meanwhile I'll still be recommending GWT and vaadin for higher productivity and great interactivity and a big ecosystem.
Let's see, some basic citations for you:
From: http://en.wikipedia.org/wiki/JScript
"JScript was first supported in the Internet Explorer 3.0 browser released in August 1996. Its most recent version is JScript 9.0, included in Internet Explorer 9."
and
http://en.wikipedia.org/wiki/Chakra_(JScript_engine)
http://msdn.microsoft.com/en-us/library/hbxc2t98(VS.85).aspx
As explained by JavaScript guru Douglas Crockford in his talk entitled The JavaScript Programming Language on YUI Theater,
[Microsoft] did not want to deal with Sun about the trademark issue, and so they called their implementation JScript. A lot of people think that JScript and JavaScript are different but similar languages. That's not the case. They are just different names for the same language, and the reason the names are different was to get around trademark issues.[5]
JScript supports conditional compilation, which allows a programmer to selectively execute code within block comments. This is an extension to the ECMAScript standard that is not supported in other JavaScript implementations.
> "They are not working on JScript at all, they are working on JavaScript" ... and your apoplexy was again for wrong reasons.
Lol, fail. "JScript" is Microsoft's trade name for their JavaScript implementation (at ECMAScript 3 level). There is no difference. Microsoft do as I did, use the term to denote that their Javascript variant (I did it to distinguish variants, they do it for trademark reasons). Now in IE 10 the tradename "JScript" may or may not be used officially - but it doesn't change anything for the purposes of our discussion. Your point was wrong
> Nobody does that. The patch is called IE9 and IE10.
I have given a link to IE9's significant compatibility flaws. It needs to be patched. So should IE 8. Yes, vendors do patch older versions of their products - this is industry wide. For developers it is called "working on multiple branches", and I have to do this all the time. I'm sure an experienced fellow like you has come across this, and is aware that is it critical to maintain older stuff in the enterprise space. Suggesting you fix things by just replacing the old with the new (eg. as small outfits can) is not realistic. In fact, back-ports and patching is something Microsoft is exceptionally good at in general - supporting and patching older stuff - just not with their browser. Hence, I see it as a possibility that *if* they focused they could fix their deployed browser base in the near future [without going to an entirely untested version, or resorting to JavaScript extensions]. This was the point I was trying to make.
> IE 10 is up there with Chrome, and on JavaScript, it is better than Chrome.
Great. Shame it is not yet released to the non-MSDN public. Shame it is not in the enterprise and won't be for some time. IE 10 is still not relevant to this discussion *at this point in time*. When it does I'll re-evaluate the compliance. Meanwhile, the only things that matter are the compliance of the deployed IE base and whether or not they get useful patches in the near term. No patches forthcoming means IE will still be despised - this is how my clients perceive IE.
> False. TypeScript includes removable annotations, but the annotations are not carried over to the compiled JavaScript.
TypeScript *is* a dialect of Javascript. Just because you convert it to Javascript means nothing (just as the Javascript being converted to machine instructions in the browser means nothing in the context of our discussion). By working in TypeScript you are still working in a single-vendor dialect of Javascript (eg. JScript). Now from your posts you seem to be a bit of an absolutist. Just because the compiler has been placed under the Apache license you believe you are not subject to lock-in. This is an absolutist and technologist point of view. To those less absolutist, say a businessman/CTO/consultant, then the lock-in is still there. Once you have a large code base written in TypeScript it is a pain to convert back to pure Javascript should you want to - yes the tool is provided, but this still takes time and effort (as in, money). This is still single-vendor lock in, just not as constrictive as it has been in the past. Don't think this is so? Well, you could always write C++ with various compiler-specific (eg. GNU) macros. Yes, you can strip these out and even have a functional program, but the effort to do so on a large code base is prohibitive - not because of technological reasons but because of practical business reasons. I will sound the same caution for those considering solutions that use custom GNU macros in their C++ as I am to those that think it is better to choose TypeScript rather than cross-browser JavaScript. The TypeScript project currently provides an out and is not too intrusive, but looking at history there is little guarantee this won't change (and less guaranteed that the whole technology won't bomb, as many Microsoft efforts have in the past). Hence, I urge caution of those considering adopting it as a direct implementation language (better to let their tools use it under the hood).
Now if you really want to improve the web experience why do a half-assed solution like TypeScript? If you are going to use a JavaScript-esque language then why not just bite the bullet and use something else (like Google's two languages, that have been around for longer and are reasonably well proven).
> You know nothing about me
This was in response to your post about me being in "diapers" while you were futzing around with Sun gear. Incidentally, both my brother and I were amazed when the Linux kernel we'd been using for a while reached 0.20 (not a typo). So (bad joke alert) you are still a short timer in my book. Off topic, I'm also curious why you hate Solaris. I always found it incredibly stable, and CDE was pretty good for the time (although it is incredibly dated now). Now it turns out you know nothing about me (eg. the PhD in Astrophysics, doing high-throughput image processing etc), but you still assume that I know nothing, despite you being incensed at me doing the same to you (sorry, it was teasing, I hope you can see your statements make assumptions about me, to which I responded in a way that made assumptions about you).
> It doesn't mean that I can't realize that Windows 8 server is probably the very best commodity operating systems for servers on the market today by a very decent margin
You are thinking like a technologist here and not a businessman. Windows server is decent (fortunately debacles like "Windows for Warships" are in the past). However, it cannot compete on *price* with Linux servers: both in terms of licensing cost, in terms of hardware required (headless for high-performance instances that aren't virtualized), and cheaper in terms of human labour per compute unit to maintain. When your go large you don't go Windows (as Google and the supercomputer clusters attest to). So Windows 8 is indeed excellent, but at least qualify your statement to say, "for SMEs" (Small-to-Medium Enterprises) as belies your experience. Windows 8 is not the absolute best commodity OS for all purposes, k?
> Java is stuck in committee
I sent you the CSS3 compatibility link didn't I? Maybe not. Here is a handy comparison between browsers:
http://www.findmebyip.com/litmus/
Note: IE9 is supposed to be CSS3 compliant (as stated by Slashdot user "shutdown -p now", who is a nice Microsoftie, although not on the browser team).
Perhaps you've been lucky enough not to be screwed up by all those read crosses, hence IE 9 is still golden for you. It just doesn't happen to be that way for some of us. You may still think I am an idiot, but I my experience is backed by a large number of fellow developers (as shown by that site, ).
It is my wish that Microsoft patch their older browsers for better compliance. Now IE 10 may be great, but the reality is we won't see in large enterprises for a few years. The pain developers feel is *now*. Hence my point, don't frig around adding single-vendor annotations to JScript, spend every ounce of effort fixing the dogs you already have running out on the real world - throw in every talented hand you have (why? because the current effort falls short). Yes, this is hyperbole, but it is meant to indicate that effort is being wasted creating new balkanizing technologies rather than fixing what is already in use.
Well, of course you have it easy if you don't even have to make it work on IE6 *as well as everything else*. Duh!
You accuse me of being ignorant yet you don't even have to solve the problems I was talking about. Unbelievable! You probably assume that no one else has to deal with the messes of IE 6 and XP as well as the latest and greatest stuff (I don't get to choose what my corporate clients run, they are far too big to dictate to).
I can't believe you have been such an venomous asshat yet you don't even have to solve the same range of problems that other web devs are cursed with - yet somehow you arrogantly assume you know it all and everyone else knows dick. I suppose I should "never attribute to malice what can be attributed to incompetence". Here's a pro tip, if someone is reluctant to use a brand spanking new tech it might even be because they have been bitten by tech (especially Microsoft tech) over the last two decades, and realise that the brochures don't cover all the hooks and pitfalls that can get you into trouble down the road. The reluctance is caution borne from hard-won experience, not some dogmatic crusade against a significant tech player (although it can sometimes seem that way, but admission that Microsoft does things right from time to time is a clue; I praise them for their license in this case).
> Wow, you still haven't read about TypeScript. You still base your comments solely on dogma and ignorance. Ass was an understatement.
Is it true or not that TypeScript adds (removable) annotations to Javascript, and hence can be considered a variant of Javascript? true or false?
> You'd know if you'd tried to use and deploy it.
Actually, I know an use GWT daily as well as vaadin. Here's a nice thing, I can use one tech no matter whether I'm on Linux or Windows or Mac. GWTs uptake at Google is irrelevant, because they are solving different problems than the average application developer (eg. how many enterprise apps need MapReduce? how many need to be coded down to the last javascript instruction because of millions of simultaneous users). So your assumption about me is false, and your statement about Google is not thought out. Who is the ass?
> No, I have not claimed that you should drool over TypeScript,
You defended TypeScript and then proceeded to make arguments that I have subsequently addressed. It still remains, Microsoft could have chosen to use Javascript with metadata defined in another file but instead they still want to alter the Javascript you produce (albiet in a way their tool can reverse). Is this incorrect? Without using their tool would the Javascript run without modification in another Javascript engine?
> Does it appear to you that I am a fan of IE10 and that I want people to go back to IE10 from Chrome? Have you found a single statement of mine that implies that?
Hmmm, let me see, "but for work I have to work with IE as well, and IE9 and 10 are really good browsers in their own right. Arguing that MS should drop TypeScript and work on IE instead is like saying Ford should stop making blue cars and work on better engines instead."
Well, I said IE sucks and Microsoft should work on those. In yous statement you say that IE 9 and 10 are "really good browser" (which the bulk of the web development community would disagree with, for IE 9 at least and IE 10 is not yet *publicly* released), and that the IE 10 preview in MSDN is basically gonna kick ass. I can only go on the statements you write, I'm afraid. Hence, any neutral reader would deduce you are a proponent of IE based on your statements - where you meant that you don't feel that my statements about IE brokenness were correct. Now you are backing away from this. This may not have been what you meant, but it is what you said. Therefore, your statements indicate you think IE is "great" and that there is little point in getting Javascript experts involved in fixing Javascript support in IE.
> You think that I, since I have said that Microsoft has done a good job with IE9 and now IE10, I am a fan of said browsers and that I am dying to use them.
I can only go on what *you said*. If you believe IE need work (eg. compared to Chrome) then why be contrary and say they are great? If you don't think that IE has more faults than its current competitors then why attack my statements where I suggest this is a more significant problem than enhancing Javascript with their own set of annotations? Why? Why indulge in your continued ad-hominems ("hallucination medications", "voices in your head are not real" etc) rather than just say, "well I think doing more for Javascript development is good, and maybe IE 9 could use some work for better CSS3 compliance and definitely work on speed-ups in hotspots". Instead, you chose to be obnoxious and spray around insults, then reverting some the stronger positions made in your earlier posts. I would ask why but it is clear, you have a bit of a temper issue and it is you who is dogmatic about defending indefensible positions - is this not true?
> Oh, and BTW, IE10 is released to MSDN subscribers now (has been for a while) and will be released to the rest of the world in about three weeks.
That is good news that IE 10 is improving. In a couple of years it will make it to the corporate desktop. Hopefully the goalposts won't have moved too far by then. Meanwhile, Microsoft will fiddle around creating *yet another* Javascript variant while other companies are progressively eating their lunch. Perhaps you think it is a non-issue but while Microsoft have slipped to #3 tech company by market cap. They can and should do better, but fidgetting with Javascript is not going to help them. Typescript may give an certifiable MSDN type like yourself a woody but to the rest of us hard working devs it is merely putting lipstick on the pig that is Javascript. Personally, I'd much rather Microsoft had competed with GWT through its Project Volta but instead they abandoned it - which is something they may well do with TypeScript (and with other useful but orphaned technologies of theirs). If you don't think TypeScript could be abandoned in the same way then you need to "get some time up" - Apache license or not, it'll always be MS' baby.
Unfortunately what doesn't seem evident to you is that the majority of users just happen to share the same point of view that I do, the current versions of IE are crap and as a result a substantial fraction of people are only IE because their work mandates it (this includes you, according to your post). Defending IE9 makes no sense to this substantial fraction, accept it has a lot more flaws than its competitors and move on.
Now we've been promised "newer, betterer, shinyer" before from IE. If IE 10 indeed nails it then Microsoft have a chance digging themselves out of the "potential well" they are currently in, Hey, I actually have an open mind that IE 10 could actually be great - but have been disappointed so many times before by them I now start very skeptical.
> Obviously Microsoft is working very hard to become compliant. What exactly is it that you are complaining about?
Do, or do not, there is no try. The Microsoft browser currently *publicly* available (that is, pay no money) have poor compliance. The Microsoft browsers currently deployed in enterprise (that is, older versions) have poor compliance. Yet a fanboi like yourself expects us to drool uncritically whenever Microsoft release an extended dialect of Javascript? Now it is excellent Microsoft have woken up - as they do when they are getting their asses handed to them in a particular market. It is excellent that Microsofties like "shutdown -p now" patiently explain their understanding of how TypeScript might be good. However, it is yet to be seen whether IE 10 is a "miracle save" when it is used by the non-MSDN masses that visit all manner of websites and webapps - and whether IE 10 is actually compelling enough for people to leave Chrome and Firefox to flock back to IE 10.
Care to make a wager about voluntary IE 10 adoption?
> I use Chrome my self, but for work I have to work with IE as well, and IE9 and 10 are really good browsers in their own right.
By "use" do you mean "use the browser as a result user", or do you mean "develop web applications for"? If the former then I understand your position, someone else has done all the hard work to patch over IE brokenness for you. In that case you are lucky (if somewhat ignorant of the actual issues).
If the latter, and you create cross-browser solutions, then I'd be very interested to know what toolkit you are using - IE 9 and earlier are a PITA!
> I was not, I was just pointing out the obvious. People who comment on things based solely on ignorance and bigotry are asses, no matter how you look at it.
Huh? you were indeed insulting unnecessarily. Please stop being an obnoxious wanker and then turning around and denying it. I welcome you debating my points, but it stops at you being a jerk. Get a grip on your attitude, please!
That information is interesting. It sounds as if IE is moving in the right direction. Once corporates adopt it (some time away, I'd imagine) it'll make a big difference for us in the trenches with better compliance.
Oops, I forgot to attach the nice reference, here it is:
http://www.findmebyip.com/litmus/
So, for me, Microsoft spending effort on TypeScript is less useful than spending effort on getting IE working right for modern web development. Microsoft does have limited resources, spreading them shot-gun style is interesting for their employees but doesn't fix their fundamental issue, IE sucks and its release cycle so slow that it is always behind its competitors (who are relatively on-par feature-wise).
Then you are back to crap old Javascript :(
Optional type checking is a good thing. Backwards compatibility is a good thing. However, personally I think TypeScript is just-another-Javascript (of which we have shitloads of variants already), and too low level to make much of a useful impact. Far better to bite the bullet, and use a high-level abstraction, say Dart, or GWT, or Coffescript etc. Yes, when choosing these you really are committing to a technology - but the point is productivity and the end result. Is adding TypeScript annotations really worth the effort? perhaps for you but certainly not for me. TypeScript is intended to help produce large JavaScript applications but I think there are far better solutions out there for that. Hence, I argue that Microsoft are wasting their time with TypeScript and should have spent effort making IE better. Here's a quick n easy reference for the features peoples are trying to use in modern development, and browser support for them: . Note also these are functional aspects, the terrible performance of IE in certain operations is not addressed on that page.
Incidentally, I noticed you were severely enraged and resorted to calling me an ass. Personally I don't care, but you ought to consider that such fury is bad for your heart and long term health. People making statements on the Internet are probably not worth you getting so mad about - certainly not half a dozen posts to vent your spleen. Pax.
Oh, while I remember, this may be of interest to you. It is a colorful way of comparing modern feature compliance on browsers (and yes, I know that IE is designed for CSS 2.1, but everyone else has moved on to CSS 3 and that is what developers expect to use):
http://www.findmebyip.com/litmus/
Please don't take this as a 'dig' at you or your employer. It's just an FYI from the other side of the fence.
> Admittedly I don't know much about the current flock of issues with IE - not being a web developer - but from what I've heard, IE9 was a massive improvement on IE8, and I've heard good things about IE10 as well - I wonder if your "100x slower than competitors" still applies there?
IE is improving, but it is still the bane of web developers. We had horrific performance issues when rendering map layers in IE9. With another client we have tooltips that don't work correctly on IE9 (but do on other browsers). It is true that all browsers have quirks, but IE just happens to have a lot more, and the ones it does have are unfortunately quite noticeable. Hence, a casual Google (or Bing) web search will reveal a lot of poor user experiences with IE9, and tribulations for web developers (feel blessed you don't have to deal with it :) with lots of stuff moving to the web lots of devs can't avoid it).
Exactly. To remove the code you still have a reliance on tools and vendors that you might prefer not to. Even if everything is open (as it is in this case, thank goodness), you still have to spend the effort running this 'preprocessor' to remove unwanted constructs. Probably the code that is remaining will lack something that the annotations gave (tying it together), which will require work to adjust the Javascript to work. This is speculation on my part (since I've not used Typescript, and it doesn't solve any particular problem for me, so I won't be using it in the near term), but I would be very surprised if something was not lost when annotations were removed (otherwise, what is the point of even having them?).
Please elaborate. Why did the committee reject the annotations?
Java doesn't have yield as a keyword. That is not its philosophy to add lots of keywords (like C++), but instead to be like C and add such functionality to libraries (standard libraries in Java's case). Java has had Thread.yield since its release in the mid 90s. Even Java borrowed this concept from elsewhere (eg. pthread).
C# will continue, as I stated. It just won't be the focus of attention for Microsoft that it once was. This follows a historical pattern. I have experienced this with many Microsoft technologies I've used since the early days. Hence, this is a heads-up for anyone currently using it - you will be able to get things done, but don't expect to get the same level of love as you used to (unlike some languages and technologies).
You miss the point, I think. When you remove the TypeScript annotations what makes you think the remaining JavaScript will be useful. Usually the annotations are a core part of the implementation that ties disparate parts together. Without them you simply don't get the same application in the remaining code. Hence, it is an issue. Once you start using such things going back is not simple (it also takes time and effort/money to *remove* source components and ensure the remaining code actually works).
> Most of it is actually bog standard ES6 (for example, classes). The only proprietary bit here are type annotations. Which you can ignore altogether if you want, and then you just get a free, open-source implementation of a convenient subset of ES6 that spits out ES5.
You cannot ignore the annotations if the majority of libraries you are attempting to use are 'tainted' with them. This is the problem with injecting proprietary technology (behaviour not specific to Microsoft) into existing and widely used technologies (not only development languages). Historical example: the mutation of Kerberos for Windows, etc etc.
Now, if Microsoft were actually going to do something to improve the Javascript experience they would spend effort into make Internet Explorer work like the other browsers (which, despite pitiful resources, manage to be roughly similar in behaviour) and make it run fast (there are some Javascript operations in IE that are 100x slower than its competitors). I'm suggesting a 'profile guided optimization' here; leave Javascript/Ecmascript alone for now and fix the real point of pain of Microsoft tech on the web/mobile; the Abomination that causes Desolation, and premature aging of web devs (otherwise known as Internet Explorer).
> Anyway, this is open source (Apache license), and the implementation is itself written in TS, and runs on Node.js. In other words, it is in no way locked into any existing Microsoft technologies, completely self-sufficient, and you can fork and mod it to your heart's content, on any platform. There is no way to "extinguish" it for Microsoft from this point on, nor control you should you choose to use it, now or in the future.
Now *that* kind of behaviour is good, and I applaud Microsoft for choosing to do that. I'm sure it was techies like yourself that fought the good fight and sold your management that this was a Good Thing. Well done.
The significance of those languages is not the same as mainstream Javascript (meaning, one already has huge adoption and the others, not so much).
The probem isn't so much with C# the language/toolset. The problem is that in order for Microsoft to sell you new tools and tech it has to periodically change them just enough so you feel enough pain to shell out for new stuff. The other problem is that while C# is good for development it is clear that it is no longer an object of adoration in Microsoft's strategy. C# will always be around but it won't get the resources that the 'new hotness' team gets (eg. TypeScript). Meanwhile, those that use other tools (standard C++, Java etc) will keep plodding along, continuously evolving.
If you know Aesop's Tortoise versus the Hare fable then this is what is happening now. Those who always watch the speed of the hare miss the fact that a new hare is entered into the race every few years. Meanwhile, those not distracted by the hare are watching the tortoise and see how it is less flashy but progresses continuously. If you built your tech on the tortoise you still have good solutions. If you build your tech with the hare then every few years you either have to rebuild your tech for the new hare (expensive! this is what CTOs worry about and code-monkeys don't), drop your existing investment and start building again for the new hare (expensive and wasteful), or stay with old tech (painful, and now surpassed by the tortoise).