HN Explorer

315 comments

[ 2.9 ms ] story [ 80.1 ms ] thread
lukeholder
Can I write my TypeScript in coffeescript?
gfosco
One can never be too careful, apparently.
streptomycin
This seems similar to the type checking and optimization done by Google Closure Compiler?
polarix
The main difference is that the Closure compiler compiles JS->JS, keeping all the type info in jsdoc comments. Typescript makes the typing a first class language entity, which reduces code portability (and toolchain flexibility) in favor of (I assume) readability and maintainabilty.

Another huge advantage is that the typescript parser & compiler is written in Javascript. Closure's jscomp is Java, which decreases backend portability somewhat.

[deleted]
(comment deleted)
cek
Say what you want about whether this is a good idea or not, it is clear at least part of MS is really serious about open source.

* TypeScript is under the Apache 2.0 license [1]

* Source is available via git on Codeplex [2]

* Installation is as easy as npm install -g typescript [3]

Extra bonus coolness: They've provided an online playground like jsfiddle! [4].

[1]http://typescript.codeplex.com/license

[2]http://typescript.codeplex.com/SourceControl/changeset/view/...

[3]http://www.typescriptlang.org/#Download

[4]http://www.typescriptlang.org/Playground/

kibwen
Also cool: in addition to the expected Visual Studio support, they've also provided support for Sublime Text, Emacs, and Vim.

http://blogs.msdn.com/b/interoperability/archive/2012/10/01/...

nigma
The online playground can do live syntax and type checking as well as provide function call hints. That's pretty cool.
PabloOsinaga
and you can also see in realtime the typescript -> javascript compilation as you type your typescript code. pretty cool.
DougWebb
I started doing C# development last year, coming from mostly a Unix/Perl platform, and I'm really glad about the timing because that's when Microsoft got serious about open development. I started doing web apps using ASP.NET MVC3, and this year MVC4 was released as an open-source project[1]. It seems that a bunch of 'young turks' have reached higher management positions in most of the key software development products within Microsoft and they're all pushing for this kind of open source approach.

[1] http://aspnet.codeplex.com/

skrebbel
Roughly the same story here. At the risk of sounding like a fanboy, I feel that while most tech BigCos (e.g. Google, Apple) have become more evil over time, MS has actually become less evil, to the point that using their tech (and some major tech at that) is relatively free of any lock-in risk.

TypeScript seems very much in line with this trend, and I love it. This is exactly what I wanted - JavaScript but with decent safety and IDE support. And no more than that. I really hope that non-MS-geeks will embrace it and that Eclipse plugins and JetBrains tools and the likes will follow.

That said, ASP.NET MVC is a misguided and overrated Rails ripoff, IMHO. Where's all that great refactoring support if everything is made `dynamic` and stringly typed? What's up with matching parameters to method argument names? (I mean, change an argument name and your code breaks? wtf?) Since when does Microsoft tech favour magic over clarity?

euroclydon
How would you otherwise map GET and POST parameters to method parameters? Have you heard fo model binders? With them you can accept a class as a parameter.
meanguy
Um, you know how Rails binds, right?

Also: MVC2 runs under NET 3.5 which doesn't even have the dynamic keyword. (I don't use dynamic in MVC3 or MVC4 either...)

The "stringly typed" (magic string) stuff was always avoidable. Regardless, see the [CallerMemberName] annotation and others which solves it back to INotifyPropertyChanged.

Now that the backlog of Microsoft tools have shipped, the scaffolding makes a bit more sense. The MVC team released multiple versions (open sourced!) instead of waiting for VS11. Which actually lines up with your core argument.

Mpdreamz
Magic strings can be avoided by always using a viewmodel ,using the lamda overloads on HtmlHelper (@Html.*) also T4MVC is a godsend strongly typing routes, url lookups, viewnames, filenames.

Most of these have been around since MVC 1.0.

Hope these pointers will keep you magic string free :)

highace
Adding T4MVC is the first thing I do on a new project. It makes pretty much all the magic strings disappear.
btilly
Given where MS started, "less evil" is damning with faint praise. The people in charge include people who were part of everything that was wrong with the company all along. As long as I have a reasonable alternative, I will never choose to trust Microsoft.

Then again I'm biased. Their desire to sell insecure software to the US government when that was against the law lead them to deliberately destroy the life of a friend of mine who they were afraid was going to turn whistleblower to such an extent that he died and left behind a widow and small kids. (Example incident. At one point he got hired at another company, and his manager to be received a call from Microsoft whose whole point was, "How much do we have to pay you to fire him before he starts?" Microsoft knew how to be evil.) I'm not forgetting Ed Curry. Nor do I have any desire to forgive Microsoft.

As long as people associated with the worst of their excesses remain involved and in control - people like Bill Gates and Steve Ballmer - I will always make the non-Microsoft choice.

meanguy
I hadn't heard this story before, but time isn't kind to this particular conspiracy. The moment of clarity: Mr. Curry wanted to sue Microsoft but "couldn't find a lawyer willing to take on the case" -- in 1998. EVERYBODY was suing Microsoft in 1998, including multiple governments. If you couldn't find someone to sue them that year, I'm afraid you don't have much credibility.

And this made my head hurt:

"All computer security systems begin with the Intel processor itself," Curry said. "I helped Intel develop their processor, so I know how they work and how vulnerable they can be if left exposed." ... "In fact," he added, "Microsoft NT 4.0 is the least secure of all the NT versions... Processors on Windows NT Version 4.0 are insecure because they have been designed to automatically open the processor up to accept commands on start-up."

btilly
I love how everyone is an instant expert on the Internet, even if they have only heard of the issue minutes before. I'm not a random internet conspiracist. I'm an established member of this community reporting what happened to someone that I considered a friend at the time that it happened.

Here is the story as I remember it.

The private lawsuit that Ed Curry had standing to bring was a complex contract violation between himself and Microsoft. The fact that Microsoft was not carrying through with their obligations left Ed Curry with very poor personal finances. Therefore any lawyer who took the case on would be doing so on contingency. No matter how many other lawsuits may have been filed, it is not a particularly easy matter to find a lawyer who is willing to spend years in a private lawsuit against pockets as deep as Microsoft's in the hope that someday, maybe, you'll get a big enough settlement to justify it.

So what were Ed Curry's other options?

Well he was aware that Microsoft was breaking the law in a rather egregious way. Windows NT 3.5.0 service pack 3 had a C2 certification. Ed knew this, he is the person who had done that security evaluation. (Which he did on the very contract that Microsoft was breaking the terms on.)

However Microsoft was advertising that Windows NT 4.0 had a C2 clearance. And was selling that into government departments whose regulations required that clearance. Ed Curry was aware of the false advertising, and the lack of clearance, and was furthermore aware that major design decisions, such as putting third party graphics drivers into ring 0, made the attack surface against Windows NT 4.0 sufficiently large that it could not qualify for C2 certification. (Historical note, Windows NT 4.0 never got that certification. But many years later, on service pack 6, they got a British certification that they claimed was equivalent.)

But what could he do about that? Microsoft was clearly breaking the law. But as a private individual, Ed did not have standing to sue Microsoft for the false advertising. He's not the wronged party, you need someone like the attorney general to sue. But Microsoft was politically connected, and getting those people interested is difficult.

What Ed decided to do - in retrospect it was clearly a mistake - was to go public with Microsoft's lawbreaking in the hope that he could get the attention of someone sufficiently highly placed to force Microsoft to follow the law. That's when Microsoft went nuclear. They paid every one of his clients to go elsewhere. After his company went bankrupt, when he got a job they paid that company to preemptively fire him. After several months of this, he died of a heart attack.

Incidentally you may wonder why Microsoft broke their contract with him in the first place. The reason was simple. They came to him with NT 4.0, and said that they wanted C2 clearance. He came back and said that it would never pass, and explained why. They told him to lie so that they could get the certification. When he refused to lie, they decided that they would punish him for failing to cooperate, and decided to not live up to their side of the agreement, safe in the knowledge that he was not going to have a reasonable chance of successfully suing them for it.

That's what happened, and I don't much care whether you happen to believe it. I was there, you weren't, and people who are active on HN will make up their own minds about me.

meanguy
And here's where I flash pocket aces: I sat in a room with no windows and no computers, across from men with strong chins and short haircuts, reviewing Windows NT source code line by line. On friggin' paper.

Never heard of this guy. Never heard this story. It makes no sense, and I cannot even imagine what "automatically open the processor up to accept commands on start-up" means.

Mr. Curry eventually met with senior NSA/DoD officials, aired what he had -- while a major government lawsuit against Microsoft played out -- and nothing.

Also, Windows NT 4.0 very much did get C2 certification and had E3 (equivalent but not transferable) at the time. Which again doesn't help the story in hindsight.

I mean, seriously... read this nonsense (gcn.com). This stuff doesn't even qualify him for a Wikipedia entry. It's just the story of someone who cracked under the pressure of releasing a version of NT every year for four years straight. He certainly wasn't the only one.

-----

Curry also gave Schaeffer an updated document pulled from Microsoft’s Web site. Under a section of frequently asked questions on security, the site answered the question: “Is Windows NT a secure enough platform for enterprise applications?” by stating that the company recently enhanced the security of NT Server 4.0 through a service pack.

“Windows NT Server was designed from the ground up with a sound, integrated and extensible security model,” the Microsoft Web site said as late as last week. “It has been certified at the C2 level by the U.S. government and the E3 level by the U.K. government.”

Hodson said the passage claiming C2 certification cited by Curry refers to NT 3.5 with Service Pack 3, which is the only version of NT to meet the NSA’s C2 level requirements to date. But because the passage earlier mentions NT 4.0, Hodson said, the meaning could be misconstrued.

btilly
Interesting. On Microsoft's own site they have http://support.microsoft.com/kb/93362 which does not list 4.0. But I found several references claiming that they did achieve C2 certification with service pack 6 in early 2000. My memory had that as a British certification that they claimed was equivalent, but Google is not turning up anything that supports my memory.

However that said, by the time they got that many service packs out, it was clearly no longer the same operating system that they were pushing in 1995. There will never be proof either way, but my belief is that the reason that it took 6 service packs before that certification happened is that there were real security flaws in early NT 4.0.

As articles like http://www.wired.com/science/discoveries/news/1998/05/12121 make clear, Ed Curry's claims were serious enough to be reported in the press at the time. And governments are large and diverse enough that there is no reason to believe that the opinions of people pursuing an anti-trust case about browsers would have much impact on people. This qualifies as a lot more than "nonsense".

As for your "pocket aces", I have absolutely zero clue who you are or whether you're telling the truth. I have no reason to doubt that people who would have been reviewing that code would find themselves on Hacker News. Obviously if you were working for the NSA, you wouldn't be likely to be inclined to leave a traceable trail all over the internet demonstrating that fact. However you wouldn't necessarily know everyone else involved. Nor after 17+ years can any of us claim perfect memory of everyone we might have worked with.

But I did know Ed somewhat. My impression of Ed, and the impression of many others we both interacted with, is that he was a credible witness. I never encountered any evidence that indicates that he was lying.

kenjackson
Interesting. On Microsoft's own site they have http://support.microsoft.com/kb/93362 which does not list 4.0.

I see 4.0 listed on the page. It's right at the bottom -- twice.

btilly
Yes, they list the advice in the article as applying to NT 4.0. And the advice on access controls does apply there.

But the only sentences stating that specific versions have actually received C2 type certifications are in the summary. And the statement there is that 3.5 was certified as of 1995 in the USA, and 3.5.1 was given a E3/F-C2 rating in the UK. Nowhere in that article does it say that any version of 4.0 ever received C2 certification.

If you think I'm missing something, please quote directly from the relevant section of the article.

lusr
There's no need to guess about any of this:

"SAIC's Center for Information Security Technology, an authorized TTAP Evaluation Facility, has performed the evaluation of Microsoft's claim that the security features and assurances provided by Windows NT 4.0 with Service Pack 6a and the C2 Update with networking meet the C2 requirements of the Department of Defense Trusted Computer System Evaluation Criteria (TCSEC) dated December 1985." [1]

Anyway isn't all of this missing the point that the TCSEC C* requirements didn't really amount to much anyway? It's a pity no general purpose operating systems were ever evaluated to A1 criteria, and that that the Common Criteria haven't lead to systems like EROS/Coyotos/Capros receiving more development attention.

[1] http://web.archive.org/web/20060503192159/http://www.radium....

dmethvin
I knew Ed Curry and worked with him at his home north of Austin for some reporting I did regarding bugs in the Cyrix CPUs. He was a friendly and kind-hearted person, was deeply devoted to both his religion and family. With respect, however, he did not have the best of business judgement. I spoke with him during the time he was setting up his NT certification business. I do not recall all the details, but even today I remember feeling uneasy that he was investing so heavily in creating a business for C2 certification before demand had proven itself. The alarms were going off in my head. I really think that Ed read a lot more into the relationship than he had a right to do.
btilly
I would not disagree with your evaluation.

It does not excuse Microsoft's behavior.

ajuc
Corporate ethic law:

How evil a company is is directly proportional to the percentage of marketshare it has.

nkohari
Trust me when I say that if you use .NET, you're always going to be stuck with Microsoft. Mono, the only other somewhat viable implementation of the CLR, just doesn't really cut it in practice -- at least for ASP.NET.
skrebbel
hmm, mind sharing why? My limited Mono experience was that getting a simple ASP.NET application running on a Linux VPS was, without prior Mono experience, one hours' work. I was pretty impressed by this.
meanguy
After losing the support of Novell they refocused (see xamarin.com). They really did an amazing job with what they had, though.

That said, Mono benchmarked about 4x slower on my web apps.

For me, better to use two Windows instances rather than deal with the ongoing Mono compatibility drama across 8 Linux machines.

nkohari
As meanguy pointed out, the Mono team lost Novell's backing -- arguably, they never had it in the first place. Xamarin is now focused entirely on mobile, to the detriment of the core CLR implementation and web.

Not that I blame them in the least. I've been a huge fan of Miguel for years, and they're doing great things in the mobile space. I just can't in good conscience invest heavily in Mono knowing that it's essentially at a dead end -- particularly when other much more attractive web technologies have been released since .NET's inception.

The reality is that Microsoft never really wanted to build a cross-platform CLR. They wanted a great Java-like runtime that only works on Windows. If that matches up with your goals, then by all means use .NET, but be prepared for a tough slog later on if you want to escape Windows.

cek
Mono is now backed by Xamarin. They got something like 12M in VC funding this summer and appear to be on fire. From what I've seen, the future of cross platform .NET looks great.
meanguy
Click the Xamarin Dev Center link. You'll see Android and iOS but no Linux. They're focusing on mobile client tools.

They never got the full stack running on the server and they punted most of the Windows-specific client stuff from the start.

They landed on a super smart subset and seem to be kicking ass with it. A C# compiler with some odd omissions and cool enhancements + native bindings to iOS and Android equals a damn useful tool. If you're building .NET or even Java backends it's certainly a very sane way to hook into them from Android phones and tablets in the enterprise.

But it's not a cross-platform .NET environment by any stretch and certainly isn't on the path to becoming one.

nkohari
Xamarin is awesome, and what they're doing seems great. They've just entirely shifted their focus to mobile, which makes a lot of sense for them, but doesn't bode well for core Mono and their port of ASP.NET.
[deleted]
(comment deleted)
DougWebb
I'm hardly a fanboy, I'm just lucky that MS' web stack became usable at the time I changed to a job where I needed to start using it. I don't think I could have transitioned from where I was to ASP.NET or the older stacks. I actually miss Apache/mod_perl which I found much simpler and more powerful, and I regret that I didn't get the chance to use Mojolicious professionally. But MVC3/4 haven't been so bad. I like the naming-convention-based approach because Rails and other frameworks use it, and I like having the ability to override it as-needed with attributes or route definitions. I like the dynamic type, given that I'm a die-hard Perl programmer, but I honestly haven't needed to use it in MVC so I'm not sure what you're referring too... maybe just the ViewBag object? I always used typed models for my views, and when I pass info through ViewBag I pull typed objects out of it at the top of my view so I have strongly typed variables in the rest of the view.

I don't think Microsoft tech has ever favored clarity...it's usually too java-esqe ivory-tower architeched enterprisey for my tastes. MVC is like that too, but the worst bits seem to be the ones inherited from ASP.NET. The new stuff is somewhat better, and you can now at least go look at the code to figure out how it works.

SideburnsOfDoom
> That said, ASP.NET MVC is a misguided and overrated Rails ripoff, IMHO.

I completely disagree. ASP MVC may be inspired by rails, and C# inspired by java, and MS may be loathe to admit ether of those sources of inspiration.

however, ASP MVC on C# is great. Maybe because MS stole from the best.

IMHO.

[deleted]
(comment deleted)
shawnb576
Interesting.

Worth noting that the Azure SDK [1] was released on GitHub over a year ago with the same attributes. The move to Codeplex is concerning.

[1] https://github.com/WindowsAzure/azure-sdk-for-node

jules
Using their own platform instead of a commercial competitor that is also closed source is concerning?! Would it also be concerning if github hosted their open source projects on github instead of on codeplex?
chollida1
> The move to Codeplex is concerning.

What's concerning about moving the location where Microsoft hosts their code?

polarix
Well, for one, their git integration is just bad. Looks like it only supports https password auth. Also I would really miss markdown integration after a while.
eranation
Microsoft is doing a lot of community trust building steps that I wish Oracle / Sun were doing, I wonder if people take it seriously and if Microsoft will be ever "Cool" again in the startup / hacker community, or is taken as PR attempts? I personally like it.
OriginalSyn
I don't know when it happened but CodePlex got a makeover as well, it looks good.
JimmaDaRustla
Microsoft also has Github a account/accounts - I thought they were going use it for all their open-source projects, but they seem undecided now.
nigelsampson
I believe a lot of the teams were jumping on Git for source control before Codeplex had Git support. A little awkward in that stuff is split, but still awesome to seem more stuff like this.
[dead] Rhino55
This is an absurd and outrageous statement. Akin to the full pay glossy ads for oil companies in Vanity Fair with messages like "We care about people and nature".

M$ is serious about embrace, extend, extinguish. M$ is not serious about supporting the computing community, is not serious about creating powerful platforms, and has gone out of its way to serious damage the knowledge economy.

Microsoft will destroy this technology just like it destroys everything it touches. Microsoft is the Chuck Bass of computing. If you get that reference, you are probably looking at someone else's computer right now.

The thing you see in front of you is, perhaps 10% Microsoft and 90% the work of a small number of dedicated individuals. Microsoft has shown a track record of destroying good technology and ignoring the community standards process.

I sincerely hope that someone rips this idea off and liberates it from Microsoft. Typed JavaScript is not patentable or copyright-able, and Google beat the daylights out of Oracle over Java, so I think this is fair game.

tl;dr I give this project 18 months before the M$ business machine starts using TypeScript as a weapon.

colin_jack
I have to admit I'm impressed with MS here.

Contrast Dart and TS. Dart announced a year ago and they're only now dealing the JS interop issue, so to most people its still only really interesting as a play thing. TS announced and from the looks of if we choose to we can immediately start using it.

I know Dart is more ambitious and maybe long term their focus on issues other than interop will be proved to be correct, but I doubt it.

discreteevent
Google deliberately opened up dart development early. I thing that was a good thing. They could have kept it closed and released it today, it's roughly as mature as type script seems to be. Would you have been happier with that?
maratd
> Would you have been happier with that?

Yes. Google (and others) need to stop releasing half-baked products.

You release something half-baked, even if it gets up to speed down the road, people will still have perceptions of it being half-baked. The above exchange is typical.

Evbn
Imagine if Linus Torvalds shared your point of view.
dmorgan
We'd have a rocking *BSD community now, with all that Linux mindshare going there. Nice.
Ygg2
Nah, we'd have another POSIX OS, only worse than Linux (probably). Plus they attract different kinds of mindshare.
fusiongyro
I heard a kid complaining about Java being slow yesterday. People remember their first experiences for a long, long time after they stop being true.
TazeTSchnitzel
Well, Java is slow. The JVM startup times are what people notice.
fusiongyro
You're assuming he was making a nuanced argument and not just flashing gang signs.
marshray
This kid had a slow experience with Java a long, long time ago?
fusiongyro
He's 19 and been programming for one year.
colin_jack
Opening it early was maybe fine, opening it early with no coherent interop strategy and then taking a year to put one together seems like it could have been a mistake.
munificent
Comparing JS interop in Dart and TypeScript is apples and oranges. Dart has a native virtual machine with its own garbage collector and object representation. The language itself has an entirely different object model and set of collection types. For better or worse, even Dart's number types are different from JS. Doing JS interop in Dart is like trying to do interop between the JVM and CLR.

TypeScript doesn't have JS interop: it is JavaScript. TypeScript is basically JS linter with a type annotation syntax. (And a few additional local features like arrow functions and class syntax.)

That being said, we know on the Dart team that JS interop is hugely important. It's just much harder for us to do. We've just announced a big step in the right direction: http://www.dartlang.org/articles/js-dart-interop/

colin_jack
Apples and oranges are both fruits though, so when I am thinking about how to get my five a day I think its reasonable to compare them.

I do understand what you are saying, had read similiar on Dart forum in past. Just to be dear I am not in any way saying I think the interop would have been easy, I do think without it Dart was a dead end for most people. It will be interesting to see how things proceed, whether the interop story that is now available lets Dart finally take off a bit in terms of usage and mindshare.

mtgx
Only when it suits them. When it doesn't, they go after the companies using it with the threat of lawsuits.
hermanhermitage
This looks excellent a nice restrained effort. Hasn't fallen into the trap that ActionScript3 did with too much ceremony, and its nice to see a syntactic super-setting approach rather than Dart's.

Now what I'd like to see in Javascripts evolution (non backwards compatible):

    * Subract: Removing parts of the language - let crockford free to rip out the bad parts.
    * Enhance: Bring in some more taste of Scheme.
    * Replace: New scoping for var etc, without introducing new keywords.
jasondenizac
new scoping for `var`? Like the block-scoped `let`?
hermanhermitage
Yes.

I'd prefer to change the semantics than introduce new keywords. Of course there are two schools of thought - I favour a small language over backwards compatibility. (And interim tools for migration).

Where I do favour extensions is for expressiveness or performance reasons.

gcr
What would more "taste of scheme" mean? Do you mean like lexically-shaped macros?
kombine
Now I want to take an advantage of strict typing at runtime, which is obviously not possible, because instead of standardizing a VM all vendors are doing stupid things like this.
cek
I'm willing to bet MS has built runtime type support into the Chakra VM.

The question is whether they will do it in a propitiatory way or push it as an extension of ECMAScript and try to get other VMs to implement it.

kombine
The worst thing is that they already have the runtime that is language-agnostic, performant, has a great standard library and so on. When they tried making it available on the Web, the so-called "open stadards" won. Which are in fact a bag of shit.
freehunter
On the Techcrunch article also posted to HN recently, the designer said they would not be baking TypeScript into Chakra, but rather letting it compile to JS and running it the same way everywhere.
iambot
I worked on a joke/conversion project a little while ago that achieves the same ends without having to compile to JavaScript.

The only reason I wrote it was to prove to a co-worker who was "hating" on JavaScript that it IS possible to have a type system in JavaScript - if that's what you want. Its not the same end result but similar enough to warrant a mention.

Here's the repo: https://github.com/christopherdebeer/TypedFunc

tlack
Weird that I didn't spot a friendly list of features.. seems to have some cool ones, like a shortened function expression (from the doc PDF):

    (x) => { return Math.sin(x); }
and modules, which are implemented using the immediately invoked function expression pattern:

    module M {
      var s = "hello";
      export function f() {
        return s;
      }
    }
Syntax seems more clear than CoffeeScript and tool chain will probably shape up better. Looking forward to seeing this get some traction.
untog
I like the shortened function form. I played around with CS for a while before going back to JS, but I do miss being able to do something like:

    var names = people.map((p) -> return p.name);
(or something along those lines). Funnily enough, it reminds me of C#'s LINQ:

    var names = people.Select(p => p.name);
wingspan
I've written a LINQ style library for TypeScript that allows you to write something like this:

  from([1,2,3]).select(n => n * n).where(n >=2).toArray()
which outputs

  [4, 9]
Hoping to open source it soon.

Edit: typo, n * 2 should have been n * n, sorry for the confusion

Kafka
Could you please explain why it would output that?
wingspan
Typo, updated. Should have been n * n
spicyj
Have you used the popular library Underscore.js http://underscorejs.org/? The equivalent to your code in Underscore would be:

    _.chain([1,2,3]).map(n => n * n).filter(n => n >= 2).value()
wingspan
I did look at underscore when figuring out how to design the library, along with many JS LINQ variants (http://ianobermiller.com/blog/2012/09/19/linq-for-javascript...).

It should be pretty straightforward to provide Underscore bindings for TypeScript.

One big difference in the library I was working on is that it is lazy, and modeled after .NETs IEnumerable. Whether this is a good thing or not, I'm not yet sure.

sciolistse
I've made a lazy linq-like library for javascript in the past..

The problem i had was that the native array methods are rather fast while function calls (for moveNext) are quite slow, so i couldn't get a whole lot of speed out of it.

Newer javascript engines might be sufficient to offset that though.

wingspan
I tried to get around this by creating overloads of almost all methods when you are operating on an array. `each` for instance, has a standard implementation using moveNext, and then an array implementation using a fast for loop. In some cases you could even drop down to native function calls.
sciolistse
Sounds reasonable. Could be better timing now as well, what with server-side javascript having become popular. Good luck with the library!
colin_jack
As a .NET and JS developer underscore is definitely the secret sauce that means I don't miss linq at all. Lovely lovely little library.
murki
Wouldn't it output [4, 6]?
baltcode
It's actually even shorter:

      names = people.map((p) -> p.name)
tlack
I wish Typescript would add "implied return of last statement" to the short function syntax! I love that feature in Erlang.
zem
that's the feature i'm most surprised they didn't add. coffeescript already does it, for instance.
ConstantineXVI
I'm getting the impression that TS is avoiding making too many dramatic changes to JS. Functions that return undefined in vanilla JS would suddenly return whatever happened to be the last statement; likely leading to unexpected behavior.
zem
i wonder how hard it would be for their compiler to catch the opposite case, then - a program using the return value of a function without a return statement. i think that was my most common bug when i was doing javascript programming, because all the other languages i was using at the time had implicit returns.
wingspan
Here are some off the top of my head:

1. Lambdas (as you mentioned) are not only shortened syntax, but also capture the `this` variable automatically for you. Try typing in the following at the playground in the body of the `greet` method to see what I mean (http://typescriptlang.org/playground):

  var x = a => this.greet();
2. Classes with inheritance are a big one, implemented using the IIFE pattern as well, with support for static and class members.

3. Interfaces with duck typing are very lightweight and easy to use:

  interface IGreeter { greet(); }
  class Greeter /* implements IGreeter */ {
      greet() { ... };
  }
4. Extensive type inference. In the following example, the function greet will be typed () => string:

  class Greet {
    greet(x: number) {
        var s = ' greetings';
        return x + s;
    }
  }
Static and member vars, return types, local variables, all are type inferred.

5. Javascript is TypeScript, just without typing, so converting your codebase is instance, and then you can begin adding type annotations to get more robust checking

koops
I've written a lot of JavaScript, including large-scale projects, and never once have thought, "Gee, I wish I had type checking."

Haven't we come to a consensus that types are more trouble than they're worth? They hurt clarity and catch few bugs.

masklinn
> Haven't we come to a consensus that types are more trouble than they're worth?

Pretty sure we haven't. That shitty languages with shitty type systems are mor trouble than they're worth yes, but types?

ovidiu
No, we have not. Read John Carmack's posts on static code analysis to understand why.
erichocean
I've been writing large-scale JS applications with SproutCore since 2007, and not once have I been bitten by a bug that would have been caught by static typing.

Same with Objective-C and my iOS and Cocoa development (since the OpenStep days).

I do use Scala on the server side though, and it helps there. But application development is, IMO, hindered by static typing. It's a lot more work to set up, and provides essentially zero benefit.

And I love static type analysis (I use it with C stuff all the time). +1

samspot
I noticed you mentioned scala on the server side. Does your comment about static typing being a hindrance apply to scala?

I would also argue that static typing provides a self-documenting benefit that is easy to forget, making it easier for someone unfamiliar with the codebase to understand what is going on. When I'm doing maintenance work I often start at the point of failure and work backwards, and it is very helpful when I can immediately identify what a variable is supposed to be representing.

colin_jack
"I would also argue that static typing provides a self-documenting benefit that is easy to forget"

Ditto. For me that's by some way the biggest advantage of typing, with refactoring/navigation being the next biggest.

I do wonder if some of these newer languages are going to make the self-documenting aspect even stronger though. I'm speaking here of optional typing and/or implicit implementation (Greeter implements IGreeter if it has the correct methods). For me this will let me put type information and abstractions (interfaces etc) only where they make sense.

Compare that with what you get in current static languages, where projects I've worked on that also use IoC have so many interface-implementation pairs that it becomes difficult to spot the important abstractions.

Interesting times ahead I think.

erichocean
I haven't used Scala for application development (I'm talking about apps with a UI here). I really like it on the server -- easy to refactor, self documenting, great implicit typing so it feels like a "safer, faster" ruby or python.

I'm just really happy with Scala. Highly recommended, and the Akka library (Erlang for Scala, essentially) is fantastic.

ufo
> I've been writing large-scale JS applications with SproutCore since 2007, and not once have I been bitten by a bug that would have been caught by static typing.

Common things such as access an undefined variable or property or trying to call a method of a null object would be detected by most static type checking algorithms.

masklinn
> Common things such as access an undefined variable

That does not require static typing, unless you're developing in elisp maybe.

> trying to call a method of a null object

Unless there's support from the type system, that one only works on very short code spans within the same scope, which is the least useful it can be (as opposed to type inference which is most useful locally).

bruceboughton
Like spaces vs. tabs, braces vs significant whitespace, there is, and never will be, no such consensus.
jakejake
I have a theory about this - how you feel about static typing is related to whether you see the compiler as your friend or as your enemy.

If you see the compiler as your friend then you tend to like type checking because it blocks certain bugs and typos. It won't let you run your code until they're fixed. If you see the compiler as your enemy, as a barricade that you need to get past, then you tend to not like static types. The compiler prevents you from seeing your code running immediately.

Obviously there's other benefits to each system but I feel like this is the more "gut reaction."

airfoil
Ha! I think you may be on to something. I've always had a "fear of rejection" with the compiler and I tend to get more enjoyment when coding in Python, Lisp, etc..
masklinn
> I have a theory about this - how you feel about static typing is related to whether you see the compiler as your friend or as your enemy.

An alternative explanation is a dislike of overly verbose languages with terrible type systems (the poster child for this category being Java), and as a result of low exposure to better statically typed languages painting all of the category with a Java brush.

jakejake
probably true if people equate static typing to Java then they assume it adds a lot of overhead.
[dead] jakejake
probably true if people equate static typing to Java then they assume it adds a lot of overhead.
[deleted]
(comment deleted)
[deleted]
(comment deleted)
colin_jack
Not really, i love JavaScript but do think types have their place in documenting the code and in supporting tooling (e.g. Refactoring).
drcode
Back in the day, Microsoft would use a strategy called "embrace, extend, extinguish." http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

Recently, Microsoft has been pushing Javascript very hard (embrace) and now it looks like they've started the "extend" phase.

Luckily, no one really worries about them being able to pull off the "extinguish" part anymore... they just don't have enough market power these days.

EDIT: Yes, I conceede the fact that TypeScript is OS probably addresses most of these objections.

zokier
TypeScript is as likely to extinguish JS as ASP is to extinguish HTML.
MatthewPhillips
You're wrong "extend" is when you add features to a standard that are not part of the standard. Since this only compiles to JavaScript and isn't being built into IE, it doesn't qualify. Dart does, though.
untog
Except that this is fully open source, which makes it a little difficult for MS to retain control over it, no?

Re-reading late 90s M$ memes gets old after a time.

dj2stein9
Microsoft was so ruthless, and dominating in the 1990's that it will be incredibly difficult to convince any developer that was streamrolled by this company to give them a second chance.
jakejake
This would still be the "embrase" phase. Extending is when they add a new feature that doesn't exist and isn't supported by the competitors. As soon as you see it compile to a flavor of JavaScript that only IE understands - then will the "extend" phase have begun.
wingspan
Awesome, great to see this finally released. I'm a dev in FUSE Labs (http://fuse.microsoft.com) and we've been dogfooding TypeScript for a while now. I'd be happy to answer any questions about using TypeScript vs vanilla JS, converting a large codebase, etc.
ovidiu
I'm wondering how to make use of an existing object system. We already have a JS framework that simulates classes and inheritance in the Java-style OOP.
wingspan
If you have a small sample, you could try it out in the playground (http://www.typescriptlang.org/Playground/) and see what TypeScript can recognize. Generally, I've seen TypeScript plays well with other OO forms and gives you intellisense on quite a lot.
platonichvn
This is great to hear. I have only just started reading up on TypeScript. But I would love to know if there will be support for a decimal type. I have been following Google's work on Dart and it doesn't look like they will be implementing it last I checked. Such a feature would be a great differentiator.
wingspan
A team member could comment better than I, but unless TypeScript adds some kind of operator overloading, supporting a new type would be difficult since it compiles to normal JavaScript. Even then, creating a performance decimal type without native code support might be difficult.
platonichvn
Yeah performance is another issue. But providing a type that compiles to a defined type that implements decimal representation would be very useful. GWT pulls off something similar by compiling the Java BigDecimal to a JavaScript equivalent.
[deleted]
(comment deleted)
lstroud
How does it compare to Dart & Harmony (even coffeescript)?

I know that is a long answer, but I'd love a bullet point list of how if compares to the other javascript++ languages that have been coming out over the last couple of years.

wingspan
I'd have to defer this one to the language designers, I'm sure they've done such a comparison.

Per the spec [1]:

  TypeScript syntax includes several proposed features of Ecmascript 6 (ES6), including classes and modules.
[1] http://go.microsoft.com/fwlink/?LinkId=267121
zachrose
Would it not be just as reasonable to put type information in JSDoc, and build a preprocessor that does the complaining?
ericcholis
Favorite part about this, I didn't know it was Microsoft until I scrolled down!
lowboy
I had suspicions from their choice of styling and typeface.
init0
http://i.imgur.com/XB3ib.png Oh M$ Oh...
untog
You lost me at "M$". I'd like to think that HN's level of discussion is above that.
cbaleanu
Nonetheless, interesting disclaimer text spotted there. Raises a good question... would that text be there because somebody in the industry analyzes your code?
lazugod
Are we reading the same thing? Code is not sent to Microsoft.
cbaleanu
Exactly. But if one clearly states that, perhaps there are others in the industry that do the oposite, iaw analyzing / scraping / calling home some code.

Having that disclaimer makes them safe in case someone might notice that insert IDE / online editor here does that and rings the bell.

untog
I think it just means that Microsoft has overzealous lawyers.
spicyj
This looks nice. I love the fact that there's no runtime that needs to be included or any overhead when the compiled JS runs.

It'd be 100% more useful if it was more aware of nullable types -- as it is, it appears that

    null * 7
compiles without any error messages. If they add a "nullable number" type distinct from "number", I'll be a lot more likely to use it.

It also appears that some other things compile that perhaps shouldn't, such as

    7[2]
and

    7["a"]
even though (7).a is equivalent and (correctly) fails to compile.
wingspan
`7[2]` is valid Javascript, so it is also valid TypeScript (fetching the '2' member of the `7` object).

Detecting null expressions at compile time might help. There are "nullable" types, but afaik only in signatures:

  foo(x?) {
      alert(x);
  }
If `x` is not passed in, it will be `undefined`.
spicyj
"wingspan" * 7 is also gramatically correct JavaScript, but evaluates to NaN and almost certainly isn't what you want in your JS program, which is why TypeScript prints a type error (well, warning) if you try to compile it.

Having optional variables is similar, but not the same as nullable types, especially when the compiler can't enforce non-nullable-ness. All JS devs are familiar with the annoying error "'null' is not an object" (and anyone who's programmed in a language like Haskell, OCaml, or F# knows the value of sophisticated compile-type type checking).

wingspan
Yes I see what you mean, it'd be interesting to see what the exact rules around type checking are; especially when dealing with []. The string type for example, always give you a string when indexed, even when incorrect:

  var s = 'foo';
  var l = s['length'];
  // type of l is `string`
I also agree about non-nullable types, and I've found even with TypeScript, having to make sure your vars are defined and not-null is still a pain.
masklinn
> var s = 'foo';

> var l = s['length'];

> // type of l is `string`

beg pardon?

    $ js
    js> var s = 'foo';
    js> s['length'];
    3
    js> typeof s['length'];
    number

    $ node
    > var s = 'foo';
    undefined
    > s['length'];
    3
    > typeof s['length'];
    'number'
wingspan
Please read the whole post for context. I am talking about the type system in TypeScript thinking that `l` is a string (which you can find out, for instance, by hovering over the `var` keyword in Visual Studio), when in fact, as you pointed out, it is a number. I assume this is because TypeScript caters to the most common case of indexing a string to obtain a single character (another string, basically).
[deleted]
(comment deleted)
wicknicks
Looks really good. The IDE support looks like a big bonus. Wish this had been released on a Friday -- have to wait a bit before I can dig deeper!
tlrobinson
This looks great, but the IDE seems to be one of the key features, so we're going to need something other than Visual Studio.

EDIT: they've got syntax highlighting for some other editors, but full completion and error reporting is still needed http://blogs.msdn.com/b/interoperability/archive/2012/10/01/...

jopamer
Our language service APIs are all open source, so feel free to hack together support for your favorite IDE and let us know! (Check out the code under src\services, and let us know if you have questions.)
Permit
I can't imagine it'll be too tough for other IDEs to support.

There's a pretty impressive demo here: http://www.typescriptlang.org/Playground/

It even has auto-complete if you press "Ctr-Space" while typing a word. Considering the source for all this stuff is freely available, I don't think it'll be too long before other IDEs support it.

wingspan
The language support in VS is really great, and getting better with each release. Go to definition, code outlining, folding, type information on hover, intellisense; all these make writing code much less easier and error prone, especially if you are used to writing in a language like C# or Java in a good IDE.
tlrobinson
But does VS run on Mac OS X or Linux? Didn't think so.
wingspan
Ah right, misread your post. I was just commenting in general on the VS support, you are right that it would not be as nice on other platforms.
wensheng
No list comprehension? No, Thanks.
wingspan
Would be a good thing to suggest to the team, it is the first release of the language, after all.

In the interim, a simple library like underscore is quite succinct:

  _.map([1,2,3], n => n * n)
With more library support you could even do infinite lists with something like this:

  _.generate(index => 1.0 / index);
jonny_eh
I was reading the synopsis on the page then it faded out and replaced it with sample code. Geez, let me read and then scroll down. WTF is with the carousel non-sense?
scanr
Very interesting. The Apache 2.0 Licence is comforting, makes it worth having a look. The docs are here for anyone interested in the spec:

http://typescript.codeplex.com/documentation

I like what they've done. Nothing too revolutionary, mostly adding static typing to Javascript without straying to far from the existing (or future) language or increasing the noise significantly.

Here's some highlights:

* Type inference

    function f() {
        return "Hello World!";
    }
Will do the right thing

* Explicit Typing

    function f(s: string) {
        return s;
    }
* 'Ambient Types'

To facilitate integration into existing JS libraries or the DOM, TypeScript lets you specify 'placeholders' for variables / classes that the runtime would expect to see e.g.

    declare var document;
Almost a kind of dependency injection but also a neat way to manage talking to existing code.

* Structural Typing

* Classes and Interfaces

    interface BankAccount {
        balance: number;
        deposit(credit: number): number;
    }
    
    class CheckingAccount extends BankAccount {
        constructor(balance: number) {
            super(balance);
        }
        writeCheck(debit: number) {
            this.balance -= debit;
        }
    }
* Modules

    module M {
        var s = "hello";
        export function f() {
            return s;
        }
    }
* Arrow function expressions

    (x) => { return Math.sin(x); }
euroclydon
Are you actually implying with the above example code that you can call a undefined "super" constructor on an interface and pass it the "balance" variable, which the interface's non-existent constructor would presumably match by name?
scanr
Nope. I probably should have used a different example for the interface. The examples are from the full spec where they progress a little more gradually from a BankAccount interface to a BankAccount class to a CheckingAccount subclass.
zokier
I haven't read the docs so I may be completely off. But that "super" syntax could be similar to "brace initialization" in C.
bmuon
I don't think `super` can be invoked as a function yet. I think it's only a reference to the superclass' prototype.
camus
Funny how Microsoft refused ES4 because it came from Macromedia/Adobe ,yet now it pushes a language that looks like its own JScript/AS3
arturadib
All of these compile-to-JS efforts are great, and as much as I love things like CoffeeScript I have to say I definitely worry about language fragmentation.

JavaScript is full of flaws, but its monopoly in the browser space has brought about one intriguing and welcome side-effect: a VERY efficient market for both employers and employees.

It's easy to overlook how important this common denominator has been for everyone involved. Employees have a tremendous amount of mobility within the industry: don't like your current JavaScript job? No problem - just about every dot-com needs a JavaScripter. Similarly, companies can today tap into a tremendous pool of JavaScript developers.

In today's fast-paced development environment, the ability to hit the ground running is key, and I worry that fragmentation will introduce unnecessary friction in the industry.

latchkey
This same fear of fragmentation is what kept Java from progressing for so many years and look what happened there. Things 'fragmented' by people just switching to other languages. I say roll the dice and see what happens.
camus
Javascript is dreadfull , and its flaws are counter productive and intolerable. It has good things like closures and first class functions , and that's it. Most of js developpers hate javascript , but are forced to work with it. So they dont care what they use as client language provided it gets the job done. few people cares about Javascript. most of the devs hate it. But the browser as dev plateform is a fact.
thedufer
That is a sweeping condemnation of JavaScript that I've honestly never heard support for. JavaScript has quirks that people don't like, but it can be rather enjoyable to work with.
SoftwareMaven
It sounds like a condemnation coming from 1998, when doing anything in the browser was painful and that was the only place JavaScript existed. I hated JavaScript in those days, too, but today is a very different world.
niggler
I've only started playing with it recently, but I've been doing some heavy stuff and wonder whether the criticism stems from deficiencies in the language (for which there are workarounds within the language) or a fundamental lack of understanding of the javascript model.
jonknee
> Most of js developpers hate javascript

I don't know of any JS developers that hate JS. I know a lot that hate some browser implementations of JS though.

georgemcbay
I've done quite a lot of JavaScript development, enough that I guess I'm a "JavaScript developer" (though thankfully that isn't my current day to day job) and I hate it. So now you know of at least one.

I agree with everything camus said. Yes JavaScript has some cool stuff in it, but taken as a whole it is a pretty shitty language. This has less to do with the creation of JavaScript than it does the practical reality that JavaScript cannot really be changed in fundamental ways without immense amounts of politics. Pretty much the entire time JavaScript has existed it was due to be fixed in a couple of years, but then political fiasco after political fiasco (eg. EcmaScript 4) delays this.

JavaScript as you can use it today sucks pretty much as much as it always has, and is only tolerable now because there are some good libraries that hide the shittiness of the language from you. Wouldn't it be better to have a web language without such a shitty core, that didn't require 100k libraries to hide you from the terrible bits?

jonknee
What are the problems with Javascript you speak of? The libraries hiding you from terrible bits, at least the ones I use, have to do with the DOM and not with Javascript.
georgemcbay
Variable scoping, unavoidable global namespace pollution, === vs == insanity, etc.
shawndellysse
But how do libraries help you from that?
georgemcbay
Kitchen sink libraries like jquery + jquery ui save you from having to write much JavaScript at all beyond basic glue code. The less JavaScript I write, the happier I am. This is in stark contrast to other languages I work in where I actually like to roll my own frameworks.
PommeDeTerre
The problems should be blatantly obvious to developers who have used languages other than JavaScript and PHP (which both have many of the same flaws).

Once you've studied and used languages like C, C++, Python, Java, C#, Haskell, Scheme, Erlang and Standard ML, you'll see what we mean when we say that JavaScript is a very flawed language. Pick any of its features, and compare that feature to the equivalent feature in the other languages. JavaScript's approach will generally be the worst of all of them.

wwweston
> good libraries that hide the shittiness of the language from you.

Ah, the "only the libraries make the language tolerable" argument.

My experience has pretty much been that most of the devs who thinks the libraries are hiding problems with the language are confused on one or both of the following points:

1) the distinction between the DOM and JavaScript (for those who don't know: jQuery and the like address problems with the former)

2) the idea that a language is terrible if it doesn't have a specific class-based OO model

Hard to say in your case, though, given that you didn't mention any specific problems or solutions presented by specific libraries.

d2vid
I end up using underscore.js in every project I work on because JS doesn't have good functional programming built in, at least not that you can count on in all implementations.

I use date.js or moment.js whenever I have to deal with times/dates in JS because the built in date support is pretty bad.

That being said, I think libraries like this take Javascript from being "tolerable" to "lovable"

snortblt
I'll second that. I use it yet avoid it when possible. It's downright clunky compared to many scripting languages. Not completely broken, but broken enough.
lowboy
Please don't speak for javascript developers without some substantiation of your opinions.
pacomerh
Nah, you're generalizing. I know many JS developers and they all love Javascript in one way or another.
snortblt
Is that not generalizing as well? I'm one that doesn't. But then, you probably don't know me.
lowboy
Critical difference is that pacomerh is speaking about the JS developers s/he knows while Camus had no such qualification.
pacomerh
Yeah, "I know many" refers to a group of people I know, so I'm not generalizing. It's like that silly quote from the Anchorman '60 percent of the time, it works every time'.
PommeDeTerre
Of these developers, how many of them have any real experience with languages like C++, Java, C#, Scheme, Haskell and Erlang?

It's easy to find JavaScript developers who love JavaScript solely because it's the only language they know. But once you start dealing with JavaScript developers who have a wider understanding of what various programming languages offer, the problems with JavaScript become much more obvious, and the hatred for JavaScript becomes immense.

marshray
I think Anders Hejlsberg knows a few other languages.
PommeDeTerre
Yes, indeed. That's why we're finally seeing some sensibility being brought to JavaScript. He's bringing in basic features and functionality that should have been included 17 years ago, back when JavaScript was first developed.
jfoutz
With a name like Camus, how can you not be a fan of javascript?
kofman
Agreed, it's a terrible language. Among other things, it makes it way too easy to write code which many people will read as being correct, but will actually be subtly incorrect.

A few of the weakest parts:

- for (var x in y) when used for array iteration or even dict iteration; hasOwnProperty? Really?

- x[obj] = y; seriously, did i really want '[Object object]' as my key?

- the choice of function level scope over block level scope

Xcelerate
I'm not sure function level scope over block level is a bad thing. It makes it more Lisp-y. And if you want block level scope, it's about as easy as (in CoffeeScript):

    do ->
        ... local variables right here ...
munificent
> I'm not sure function level scope over block level is a bad thing. It makes it more Lisp-y.

Lisp has block scope.

Xcelerate
Well, it can have both...
Evbn
Example?

Can you write Lisp like this?

Function for(){ f(x); var x = 2; }

Compiles and runs with f(undefined)

msteigerwalt
From my experience, "most" of those JavaScript developers who "hate JavaScript" are in fact front-end developers who hate writing JavaScript for websites, since they struggle daily with issues such as cross-browser compatibility and inconsistent DOM implementations, which have nothing to do with JavaScript at all, and can't be fixed by a different syntax.

It's also compounded because the majority of front-end developers write their code procedurally for each application component, which creates a terrible nest of repetitive and error-prone code.

They feel the pain, don't know how to solve it, so switch to a different syntax, blaming that as the root cause of the problem.

But feeling enough pain to viscerally HATE a language, as many front-end developers do, is not something that can simply come from the syntax of the language and the fact that the equality operator does type conversion and whatever small list of gripes users have. Most other languages (including CoffeeScript!) have a similarly-sized set of flaws and aren't nearly as derided.

Me1000
Correlation not causation.

As someone who has built large scale JavaScript applications, and has a lot of experience in other languages I really don't like JavaScript. My experience is that a lot of people know JavaScript, but very few people actually like it... Those people generally make writing JavaScript their day job.

Overall, cross browser js isn't really that difficult anymore and I rarely see people complaining about that. Of course, I've been part of the AltJS community for a while, and the people I follow closely are not front end developers.

medikoo
JavaScript is my main language since about 5 years, and I love it. I know a lot JavaScript developers and honestly I don't know any that "hate" the language, about 80% are very passionate about it, for rest is just tool to achieve the goals.

JavaScript has minor flaws but in general when understood it's outstanding. However it's not the style that you've been taught in school (OOP) and that's the problem for many newcomers.

It looks that you're just frustrated with something and want whole world to be as well, it won't work. Try CoffeeScript, it's much more approachable when coming from OOP world, then when you get how JavaScript works and understand it makes sense, you'll be ready to program in it directly.

georgemcbay
JavaScript is forever stuck in design-by-committee hell, which dooms it long-term. Developers who do nothing but pure JavaScript and don't at least play around with the other options (Dart, TypeScript, Haxe, CoffeeScript, et al) are just going to be hurting themselves long-term.

It is always a bad idea to tie yourself too strongly to any single language.

zachrose
I don't know, ECMAScript 6 looks a lot like Coffeescript, and ECMAScript 6 modules look a lot like Node modules.
georgemcbay
ECMAScript 4 looked a lot like ActionScript 3 up until the whole thing was suddenly killed. I don't care too much what a language is supposed to look like years from now if everything goes right. This goes double for languages with a tortured history of failure when it comes to big changes.
dmorgan
>I don't know, ECMAScript 6 looks a lot like Coffeescript, and ECMAScript 6 modules look a lot like Node modules.

The fact that after all this time and efforts, ES6 won't be released for another year plus, speaks volumes about the "design by committee" thing.

BrendanEich
Nope, spec finalization follows shipping.

First, Firefox and Chrome (under a flag, to be removed) already ship great pieces of ES6. JSC (Safari) and IE prototypes coming too. This is necessary to test interop and design soundness.

Second, we don't do "Design by Committee", we use the "Champions" model where 1 or 2 people design a proposal and a larger number beat it into consensus shape without "redesign".

Nothing's perfect, least of all with multi-browser standards, but if you have an alternative for evolving the actual JS language implemented by browsers, lay it on us.

Compilers on top are great, and many. Good to see MS do one that tries to build on ES6.

dmorgan
Wow. Didn't expect a reply from "THE Eich" itself. Honoured.

>Nope, spec finalization follows shipping.

Still, shipping ES6 is also scaled back at this time, and it requires special flags and hoops to be enabled.

This means actual mainstream use (the way we know use HTML5, IE7 be damned) will be possible 2-3 years in the future at the minimum, which would be like 6-7 years from the beginning of the whole process.

This is W3C-level waiting times, especially considering that ES now is essentially the same it was in 1999, with minimal changes to the language or the standard libs.

>Nothing's perfect, least of all with multi-browser standards, but if you have an alternative for evolving the actual JS language implemented by browsers, lay it on us.

I would wish for a "one guy sets them all straight, it's his way or the highway" benevolent dictator model, but I understand that while it works for Ruby or Scala or whatever, it doesn't work in JS case where you _have_ to have 4 different implementation by 4 browser vendors to have it adopted.

I think what those vendors need is something to force their hand, but don't know what that could be.

gsnedders
90% marketshare was effective for IE6 forcing other vendors' hands. Not that that's a good model to go back to. :)
BrendanEich
Device turnover on mobile is 2-3 years. Things are picking up with more balanced competition and the rise of mobile to dwarf desktop.

You can't get an interoperable spec of a new edition of a language the size of JS in less than three years, for any such language. Not for Dart (which is still changing and by Google's own plans nowhere near ready to standardize) or TypeScript (also new, and tracking ES6). Java, C#, Python, Ruby, etc. were built to today's state over years or decades.

Bite-sized specs are much better. Small libraries on github and universal edge-caching, even better. Could we have bite-sized specs for JS?

As I speculated at Strange Loop last week, with a few final gaps in the language filled (Object.observe, slated for ES7, weak refs and event loops, and definitely macros! see http://sweetjs.org/) by a future JS standard, we will be "all but done".

Working away at this goal,

BrendanEich
(Was that a "Lensman" ref in your first line? ;-)
edwinnathaniel
Conversely it's a bad idea to spread yourself thin in multiple languages but master of none.

Having said that, I'm pretty much tied to Java since 2000 and haven't seen anything wrong... yet. In fact, I'm determined to get better in Java everyday (memory model, JVM, concurrency, better design, etc).

Side note: I'm also learning pure "modern" JS just because there's no choice on the client-side.

jasondenizac
Actually, it's quite easy to write for the client in most languages targetting javascript. Certainly it's the case for CoffeeScript, and TypeScript looks even better in that regard since it's a strict superset.
mcosta
> Side note: I'm also learning pure "modern" JS just because there's no choice on the client-side.

Knowing Javascript, GWT is a win.

edwinnathaniel
I've done GWT for about 2.5 years from version 1.x to 2.x. I'm not sure I prefer one or the other.

GWT development is a bit painful to setup and to work day-to-day.

It's nice to have the similar Java structure and to be able to write unit-tests to test the app via MVP patterns but I'm still not sure it's a big win for me going forward. Especially when the founding members have left the team.

eddieplan9
I think you were referring to the JavaScript syntax when you said JavaScript is full of flaws, because IMHO the language itself - except the syntax component - is actually very good. Someone on Quora said[1] it very well:

JavaScript is a wonderful language, deep down: It's Lisp-y, yet imperative. Its lack of support for threads has turned out to be a strength on the server side. And recent implementations have made it very fast.

People favoring node.js and compile-to-JS languages like Iced CoffeeScript to other server-side languages supports the fact that JavaScript itself is actually quite decent. At the end of the day, a language too broken could not easily be fixed with any thin compile-to-* effort, and most of the compile-to-JS efforts (with the notable exception of emscripten, whose goal is not to fix JavaScript) are quite quite thin.

[1] http://www.quora.com/CoffeeScript/What-are-disadvantages-of-...

stdbrouw
The intrinsic beauty of JavaScript doesn't matter in this context. Either you use JavaScript or you use something else, and if you use something else then that'll lead to language fragmentation, which is arturadib's concern.
norswap
The good parts are good. The bad parts are pretty horrible.
zemo
>Its lack of support for threads has turned out to be a strength on the server side.

ummmm, can someone elaborate? I don't understand that statement.

eddieplan9
I think it means the language forces designs and eventually an ecosystem that's optimized around having cooperative multitasking as the only option. That makes dealing with concurrency an easier task since every library you depend on also takes concurrency seriously. And since cooperative multitasking is much much more efficient than preemptive alternatives, you end up with applications with great efficient concurrency support by default.
webjprgm
E.g. node.js + socket.io. The event-driven concurrency model makes it easier to write servers without worrying about race conditions and thread locks while also having less overhead from a heavy thread implementation. For some applications this has been quite good. The downside is that it can be a bit tricky to scale node.js larger but it's not too hard to run multiple processes or do other load balancing. It's not good for all applications, but very good for some.
wickedchicken
> The event-driven concurrency model makes it easier to write servers without worrying about race conditions and thread locks

Well, no, you're just writing the locks yourself in an ad-hoc way. Every time you have a callback calling another callback, you have a lock and all the race condition/deadlock issues associated with that. Of course, writing an application that doesn't have complicated synchronization requirements (streaming fileserver) can often require less boilerplate in an evented system. However, you run into a catch-22 here: by definition it's an application with fewer synchronization requirements, so you'd have to use fewer complicated locks in a 'heavy thread' implementation as well :).

Ultimately it's an engineering tradeoff problem, and you have to weigh lightweight node-style cooperative multitasking with the ability of a traditional thread system to better handle highly complicated scenarios.

Or you can be Russ Cox and argue that this is a false dichotomy[1] and that we should all be using CSP. I'm in that camp.

Andrew Birrell: threads.

John Ousterhout: events.

John DeTreville: no.

Rob Pike: yes.

[1] http://swtch.com/~rsc/talks/threads07/

rdtsc
> makes it easier to write servers without worrying about race conditions

So how do you handle concurrency without race conditions without using isolated processes or pure message passing? Ok so you don't have thread locks, big deal, but you still have shared data structured that could be updated in a non-deterministic order depending on which file descriptor gets fired first by epoll (or whatever select thingy is being used lately).

aaronblohowiak
The language itself is broken, especially when it comes to equality, type coercion, `arguments`, and Date processing.
nahname
I think you mean, when only looking at those things. Outside of hoisting, you just listed all of the issues. Even hoisting is only an issue when you start polluting the global namespace.
repsilat
Depending on who you are you can also complain about scoping rules, the object model, semicolon insertion and more general syntactic complaints, speed, access to native APIs and so on. One language is never going to be all things to all people.
esrauch
Equality (and that portion of type coercion) is pretty much solved by using === and the rest of type coercion is solved by only using + when both sides are numbers or strings. I don't see how that gets as much ire as it does
marknutter
> I don't see how that gets as much ire as it does

Because it's the straw-man.

[deleted]
(comment deleted)
[deleted]
(comment deleted)
zem
> In today's fast-paced development environment, the ability to hit the ground running is key

actually, i think one of the major flaws in the current programming job market is overrating the ability to hit the ground running. that leads to a dangerous level of short-term optimisation, where, say, you'd choose an employee who has experience with your current stack over someone with a better track record but requiring a month or so to learn their way around the specific languages and ecosystems involved.