Live data from Hacker News

TypeScript: a language for application-scale JavaScript development

typescriptlang.org

191–200 of 316 posts

Re: TypeScript: a language for application-scale JavaScript development

#191
post #187

Earlier quoted context omitted.

In this case, I must infer that the culture of documentation is not the same at Microsoft as it is at Google. Further, how can you have a tool like this and nothing for generating type-aware documentation from your source code? Google uses jsdoc-toolkit, so this is a moot point for them. Either you guys are using this in an informal fashion, or documentation isn't that important at Microsoft, or you just haven't rele…

The Language Specification looks pretty extensive[1]. And TypeScript is just the language, so there's no API to document besides what your browser exposes in JS. [1] http://www.typescriptlang.org/Content/TypeScript%20Language%...

Of course there is no API to document, and I noted the spec PDF in my top comment. Where is the manual, or something like one? At Microsoft, do they just tell a developer new to TypeScript to read the spec? Highly unlikely. MSDN is full of good documentation, and it's very weird that there's nothing of the sort for this project. I'd think that's an awful lot more important than Vim integration and such.

Even CoffeeScript had a manual very early on, and so did Dart.

I'm not saying "bad on Microsoft for releasing this!"; it's good they're starting to sort of figure out how open source works. Rather, like I said,

I think you'd be a damned fool to invest in this technology for any serious project.

Right now this is a toy.

Re: TypeScript: a language for application-scale JavaScript development

#192

Earlier quoted context omitted.

I don't know when it happened but CodePlex got a makeover as well, it looks good.

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.

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.

Re: TypeScript: a language for application-scale JavaScript development

#193

Earlier quoted context omitted.

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 product…

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 decen…

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 :)

Re: TypeScript: a language for application-scale JavaScript development

#194

Earlier quoted context omitted.

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…

> 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 problem…

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"

Re: TypeScript: a language for application-scale JavaScript development

#198

Earlier quoted context omitted.

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 product…

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 decen…

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.

Re: TypeScript: a language for application-scale JavaScript development

#199
post #186
post #79

Earlier quoted context omitted.

I wish Typescript would add "implied return of last statement" to the short function syntax! I love that feature in Erlang.

that's the feature i'm most surprised they didn't add. coffeescript already does it, for instance.

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.

Re: TypeScript: a language for application-scale JavaScript development

#200
post #109

Earlier quoted context omitted.

>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.

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 g…

> 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/

Post reply on HN