Microsoft: TypeScript isn't a JavaScript killer Microsoft may have a poor track record for web standards compliance, but if the capacity crowd at Microsoft Technical Fellow Anders Hejlsberg's Build conference session on TypeScript was any indication, Redmond's JavaScript alternative has struck a nerve with coders who have grown frustrated with the web's de facto applications …
When you check the TypeScript download page you'll notice that you can get it installed as a 'node.js' package, an extension for editors such as Emacs and Vim as well as a Visual Studio 2012 plugin.
But what about the people still using Visual Studio 2010? Or what about the hobby developers using the Express version(s) of Visual Studio, whether its 2010 or 2012?
The reason I mention VS 2010 Express is because this platform is still relevant; otherwise I doubt Microsoft would keep the option to download VS 2010 Express online.
It strikes me as odd that they only target well known open source editors and VS 2012 while leaving out all their other environments.
"What about the many developers that don't user windows at all, or not use a windows IDE?"
The very post you are replying to says that MS have provided it for vi and emacs. And it's an open standard. There's nothing to stop anyone on any platform coming along and adding it to their IDE.
NOOOOOOOOOOOOOOOOOOOOOOOOO........................................!
There MUST be subtraction of features or we'll end up with a bigger language inheriting all the 'fun' features of the original. We don't need that.
Aw poo. C++ all over again.
And without sufficient constraints it can't be compiled easily if at all to efficient object code. JS is not a good target language.
I think you are right about "fun" features, but you've failed to follow the logic through.
I can't think of any case where a descendant language has successfully subtracted features from its parent. There are certainly languages with "deprecated" features, but it takes decades for those to finally be removed. You have to look at truly ancient languages like Fortran and C to find examples. Backwards compatibility appears to be an essential property that any child must have, or else it will be still born.
It follows that any "fun" features that are present in a parent language essentially doom that language and all its descendants. You may *think* you have given yourself a clean slate with a new language, but you haven't. You *would* be better off spending the same effort on improving the original language.
Wannabee language designers out there, take note. There are *very* few languages with no such features and certainly none with a sizeable userbase or collection of handy libraries. Most modern programming is done using languages that are clearly band-aids around the original Lisp, Cobol, Fortran, Pascal, Basic and C. In most cases, they haven't even got around to changing the name yet. (I could probably be persuaded to add JavaScript to that list. It is a little young but, then again, so is its target platform.)
Obviously there are a *few* exceptions but there have been thousands of attempts and you can do the maths yourself. Statistically, it is almost inevitable that your language will fail. Stop it.
I use JavaScript every single day in my job, and something about trying to shoehorn the language into a 'proper' application development language just strikes me as wrong.
Whilst I find it a very capable tool, it's purpose is, and has always been, to create small blocks of code that perform a single, simple function - not to develop a huge, full-on application consisting of thousands of lines of code. Surely we have much better languages already to achieve this, and as BlueGreen stated above, all this will do is further bloat the language and lead to more abuse of what it's original intended use.
Javascript definitely belongs to the keep it simple, small is beautiful, toss the code over the shoulder style which is what I learned back when Unix was born. Unfortunately, code and libraries, even chains of libraries, are being created and used to create large, multifaceted applications which was not the original intent. So things get extremely messy, which is what happens when the wrong collection of tools is used to get the job done. And it even works, for a while. What I see Anders doing is just what he has done all along, coming over and sorting through that toolbox to come up with a set of duller/safer tools that not too many people can hurt themselves or others with. He's rather good at that, even if I'm not exactly a fan of the product that results.
Short of scrapping the entire paradigm blessed in the form of HTML5+CSS3+Javascript(whatever), what can we do? Ever since I started with punch cards, the systems advance, achieve a towering level of complexity which few can deal with, and a new paradigm is advanced. Soap, lather, rinse, repeat. It'll probably happen even faster in this cycle than anyone can imagine.
So, kicking back with a half-ton of popcorn. This train wreck should be monumental.
The problem with every highlevel language is that you can't know what happens inside the blackboxes you use to build the lego system application. The bigger the blackboxes the bigger the changes of unexpected interaction, stands to reason. There is just a limit to what you can do with it. That limit begins to be breached by now.
Try and build an OS with it.
Standard C++ is as high as you can go and still have enough insight into what happens.
"The problem with every highlevel language is that you can't know what happens inside the blackboxes you use to build the lego system application"
The output of TypeScript "compilation" is JavaScript. It's not so much a blackbox as a clear box that you can take the lid off and re-arrange stuff in.
I respect AH enormously - clearly one of the geniuses of our profession. And I love C#. But I'm not even going to waste my time looking at this, because I just don't trust Microsoft to follow-through any more - they've cried wolf too many times over the past few years.
Atlas... Silverlight... WPF... Metro... TypeScript.
It's like a bad case of framework ADHD.
Haha!!! Best comment I've seen in a long ass time!
Seriously, I was reading comments just to find the moron who would bash the technology because of lame assed anti-Microsoft sentiment.
Personally, I've been looking for something like typescript for ages, so I'm happy to see it come. It would be fantastic to have a real programming language in the browser. I was just so pleased to see your response to this guy :)
I kind of fail to see why this is a problem. Will we use it in the browser? Yes, if the typing is an annotation or is stripped upon "compile" (and typekit won't compile, since javascript doesn't get compiled) for deployment. Is it like [insert failed MS technology here]? If you think so, you might consider that you don't realise how silly that sounds.
They started with JavaScript, and then added some features that you really, as a dev, want while developing your code.
You don't want them in the final code, and you don't NEED them in the final code. Things like typing, visibility, etc. are merely code promises. You can enforce them even in the final compiled version, like Java does, but that's missing the point: If your code passes your tests with those promises enforced during development, then those same tests will pass with those promises removed). So for a JavaScript program, as long as your development environment at least supports them while you're working on the code, stripping those promises for deployment is a no-brainer. Of course you're going to. And lo, a JavaScript program be here.
Seriously, do nay-sayers on this one even use JavaScript? O_o
Static typing is an ugly remnant of the days when computers weren't smart enough to figure out what a variable was.
All that is required is for language designers to realise that adding numbers and concatenating strings are two distinct operations (even although they both take two scalars and return a scalar), and to give them two distinct operators.
You have no idea what you are talking about. Typed and untyped languages serve different purposes. If you need speed, you use a typed language. If you don't care about speed, just need something quickly up and running, you use untyped.
http://shootout.alioth.debian.org/u32/which-programs-are-fastest.php
For a decent programmer, neither typed or untyped languages are an issue.
The performance argument is invalid because the compiled javascript is still run as untyped or dynamically typed code.
The type checking is only done on compile time. And I must agree that this is something from a past era. Have more fun writing functional code and forget about boilerplate code. Use coffeescript.
Untyped languages are not as fast as typed languages. Typing allows the compiler to optimize the generated binary. Read the dragon book.
Boilerplate code? you mean all the checks you have to write in untyped languages to make sure that you received the right type of data? Or you don't do that because it's not "fun"?
As I said above, both typed and untyped languages have their place. But to say that typed languages are just something from the past, is just plain silly.
I practically memorized the dragon book an the LCC book and some other good ones. I also developed a browser for a living for 5 years. So please don't simply discount me for chiming in.
Your point is valid. But that said, code from TypeScript is interpreted to JavaScript. Even in optimal scenarios, the bottleneck in JavaScript is the cost of the "thunk" into the browser. Also the JavaScript code generated is untyped.
People like me LOVE the idea of having a typed front end to JavaScript. I can now develop solid code in the browser. But it is a mistake to assume we'll gain the benefits of a typed language in the execution environment. Strangely enough, I have already written a lex implementation for TypeScript. This is something that would be borderline impossible without a typed language. I'm doing this as a OpenCL JavaScript optimizer. It will allow JavaScript to be interpreted on the fly to OpenCL. I'm doing this so I can finish coding my H.265 decoder for the web. I'll probably convert the entire decoder to TypeScript and OpenCL in the future.
Now all we really need is tight integration between TypeScript and OpenCL. That would be amazing?
"I have already written a lex implementation for TypeScript. This is something that would be borderline impossible without a typed language. I'm doing this as a OpenCL JavaScript optimizer. It will allow JavaScript to be interpreted on the fly to OpenCL"
I just want to say that this is awesome and exactly the sort of thing that the world should contain.
Static typing is an ugly remnant of the days when computers weren't smart enough to figure out what a variable was.
Type inference and dynamic typing are two entirely separate issues, and conflation them like that shows complete ignorance of both of them. Consider a language such as SML - there is a very strong type inference mechanism that is powerful enough that the need to manually specify a variable or parameter type is very much the exception rather than the rule. However is is also very strongly typed and completely statically typed.
When these two separate concepts are reseparated it isn't clear what you actual point is.
"These extended Javascripts are not going to fly until they offer debugger support in their languages and on most major browsers. The mental overhead of writing in one language and debugging in another is too high."
This exists for Chrome. I'm presuming for Firefox also. It uses a technique called "Source Mapping" which comes from Mozilla (which is why I presume it exists for Mozilla also). Here is the implementation for Chome:
It's very clever and it lets you debug the TypeScript source code from the running Javacsript. It's one of those things that makes me smile just to see such an elegant solution. The designers of TypeScript built the mapping into it for just this purpose, though as far as I'm aware, only Chrome and Firefox have it implemented so far. (Which should also help drive home to some of the more zealous anti-MS posters here that TypeScript is actually an open standard despite their paranoia).
Unusually, the moronic drivel passing as comments and interspersed with occasional bits of lucidity has helped me to considerTypeScript. As an old fogey who routinely dismisses MS's latest effort on the basis of it being MS, it's nice to see a set of cogent arguments pointing out why I should bother to take a look. For those who say it's MS-only, typing the precise command sequence given on the TypeScript home page ("npm install typescript ... tsc helloworld.ts") worked perfectly on my Arch box with the exception of me not having written helloworld.ts; I think I can probably forgive them that
I'd welcome a rational comparison of TypeScript vs CoffeeScript vs JavaScript; personally, I do write multi-thousand line programs in JavaScript and actually think it's a very elegant language when used properly (my first language was Z80 assembler, btw, with C then C++ being the natural successors - so I am quite familiar with typed languages!) though very easy to make mistakes with. Modules / closures / 1st-class functions are all just ways of segmenting memory as we've done since the beginning in various ways. I still remember my introduction to C++ and being horrified to discover that I couldn't just malloc() a block of memory and do whatever I wanted with it - at that point in time, keeping track of memory blocks and what was in them was 2nd nature so handing control over to the computer felt very un-natural. Even after grudgingly accepting this, I spent a significant period of time writing (myPointer*)(void*)someRandomThing* and waving two fingers at the casting system because "I knew better". I didn't. The point of this rant is that actually C++ automated details for me and allowed me to concentrate on the functionality, which is what we're paid for.
If TypeScript is (1) truly mutliplatform [*cough* Silverlight] which it does in fact seem to be based upon a 30 second investigation after 5 pints of beer, and (2) not tied with you-are-pwned legalese as *all* the big companies seem to do, then it seems well worth investigation. For me, the name of the company that primarily sponsors a project is immaterial; it is a combination of the legal encumbrance and the technical merit that is important.
Beer, because I'm working on a death-march project atm and have had far too much tonight (both the project and the beer).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
