Goodbye CoffeeScript, Hello TypeScript - <AUTHOR> http://blog.heapanalytics.com/goodbye-coffeescript-hello-typescript/ <comment><USER3> Is it really that important nowadays to build webapps in pure js or abstractions of it? We read articles about how many smartphones get superslow when executing loads of JS code, how broken the development process is and how framework x tries to solve that broken flow. We make use of super heavy and complicated toolchains that are outdated half a year from now. I often hear and read things like: "You still use bower instead of npm?", "You still use coffee script?! Go with TypeScript.", "BackboneJS? Why not go with Angular?". Some requirements make it mandatory to do lots of stuff in the frontend. For example: SoundCloud is supposed to continue playing songs when users navigate around. Okay they need a pure JS page refresh experience. But the standard CRUD admin panel you write 90% of the time? There it's not wrong if a browser does what it is supposed to do. Load a page when a user clicks on a link. Is this such a bad thing to keep things simple?

<comment><USER4> Single Page Applications can enhance the user experience in many ways, even with more "boring" apps:

* Forums/Comment Threads - If I want to reply to a comment in a thread (like I'm doing right now) I don't want the page to refresh after I submit, causing me to lose my scroll position. Even worse is when discussion sites ( _cough_ HN) whisk you away to a whole 'nother page to submit your comment, then dump you back to the thread afterward.

* Documentation - Let's say you have a long list of topics in a sidebar on the left. If I find a bunch of topics that I want to read and they're in the middle of the scroll, I'll be annoyed if the whole page refreshes when I click on one.

* Forms - If I'm filling out a long form (like enrolling in school or applying for a job) and I enter something wrong, I want to know immediately. I don't want to hit submit, land back on the same page, then find where the error is. Even when sites do this well (by saving the whole state of the form and clearly indicating where the bad field is) it's still annoying. Client-side validation also saves server resources (even though you need to do server-side validation too): every time the client catches a validation error, that's one less postback the server needs to process.

Following the emerging set of best practices (use a CDN, bundle/minify your code with a tool like browserify/webpack, don't block the critical render path) is enough to get your code to a point where it should run totally fine on mobile. The horrible state of mobile web performance more often results from:

* Fonts - for some reason these seem to take a longer time to load than other assets (or maybe their absence is just more noticable). Using a tool like TypeKit can help to get around issues like "Flash Of Invisible Text".

* Images - People not properly compressing images, using too many images, using PNG where SVG could possibly work are all contributing to slow page loads. Images are usually the largest things on the page (sometimes by an order of magnitude). They are also often demanded by "the business" in the same way that carousels are usually a result of a business compromise and not a deliberate design decision. Tools like grunticon and other gulp/grunt tasks can help mitigate these issues by ensuring that huge hi-res images have a compressed version and don't get sent to phones with tiny screens.

* Ads - Many ad networks either don't run a tight ship or don't police the companies who they allow to run code on their client's sites. The further someone is from actually owning the page where the code runs, the less they often feel compelled to make good optimization decisions.

My point is that a lot of this new-fangled front-end tooling (browserify/webpack, TypeKit, SVG, grunt/gulp, the <picture> element, etc.) are geared towards producing a better experience for the user. Many of them either emerged to deal with mobile web issues or found new importance in light of the problems developers (and businesses) face on the mobile web.

<comment><USER5> > If I want to reply to a comment in a thread (like I'm doing right now) I > don't want the page to refresh after I submit, causing me to lose my scroll > position.

That's what middle-click to create a new tab is for.

> Even worse is when discussion sites (cough HN) whisk you away to a whole > 'nother page to submit your comment, then dump you back to the thread > afterward.

If HN were a single-page app, I wouldn't use HN. Period.

> Let's say you have a long list of topics in a sidebar on the left. If I find > a bunch of topics that I want to read and they're in the middle of the > scroll, I'll be annoyed if the whole page refreshes when I click on one.

Again, that's what middle-click is for.

> If I'm filling out a long form (like enrolling in school or applying for a > job) and I enter something wrong, I want to know immediately.

Sure, that's a nice use for JavaScript. I just don't want to have to expose my entire system, and all my data, and every system I can connect to, to malware in return.

<comment><USER6> I have to admit, I'm not really interested in your restrictions on what people are allowed to use in browsers. You are definitely not the arbiter of the one true way, no matter how right you feel about your opinions.

<comment><USER5> Are you interested in security and privacy? Are you interested in functionality?

I am, of course, the arbiter of what I permit my browser, running on my computer and accessing my data, to do.

</comment></comment></comment></comment></comment><comment><USER7>
      > It's reasonable to assume "foo bar and hello world" will compile to either:
      > foo(bar) && hello(world)
      > foo(bar && hello(world))

Feel free to sprinkle in additional operators to increase the clarity and readability of your code. Coffeescript is extreme in what it allows. But even C code can be made more clear by using more operators than the compiler actually demands.

I'm not really trying to come to the defense of Coffeescript here, but I think it's worth noting that adding more operators for clarity is a good thing. I even go as far as adding additional variables for clarity, because the names can show what you're thinking as you do the computations involved in a complex expression.

Although Coffeescript is worse than most, any language will allow you to write expressions that are hard for humans to parse.

<comment><USER8> agreed, add a good linter and problem solved. Ruby has been this flexible since its inception and you don't see people complaining about ambiguity because they learn how the language works. When there's ambiguity, be explicit.

<comment><USER9> _When there 's ambiguity, be explicit._

Many (too many) programers seem to take a viewpoint of "only type the minimum numbers of characters necessary to get something to work." Then they make their programming goal to be the least characters possible as long as the compiler accepts their input.

 _complaining about ambiguity because they learn how the language works._

Some programmers also enjoy learning all the ambiguous edge cases then making sure their code fits them exactly in the way they intend, but not necessarily the way others will read the code.

That's why we end up with awful things like "if (abc) def; else hij;" or worse "if (abc) { def; } else hij;", etc. Plus, if your language isn't line- sensitive, using weak syntax but pretty alignment is just a recipe for future failures a few steps removed from when you originally introduced the future inconsistencies.

<comment><USER10> Ugh, I used to write coffeescript and I was that way for a while. I left off parens, brackets, commas, etc. wherever possible. I thought it was great at the time, but when I came back to the code after writing in other languages it looked awful, and I wasn't always sure how to read it. Being a little more verbose will save you a lot of time in the future.

</comment></comment></comment></comment><comment><USER11> _> Variable initialization and reassignment are the same It's easy to accidentally overwrite a variable from a higher scope as a codebase increases in depth. _

Yep. There was a previous July 2013 article and related reddit thread about it.[1] The CoffeeScript compiler devs themselves were bitten by their own strange scoping rules!

As to the other question about why people don't just write raw Javascript, Eric Lippert explained why plain Javascript is inadequate if you want to do more than just "make the monkey dance"[3] -- a.k.a. "large complex apps".

[1][https://www.reddit.com/comments/1j1cw7](https://www.reddit.com/comments/1j1cw7)

[2][https://github.com/jashkenas/coffee- script/commit/7f1088054c...](https://github.com/jashkenas/coffee- script/commit/7f1088054c91f5ab3bf1ea1098b6ebffaa29a5a9)

[3][http://programmers.stackexchange.com/a/221658](http://programmers.stackexchange.com/a/221658)

</comment><comment><USER12> The advantages of CoffeeScript that TypeScript is lacking aren't mentioned. I wouldn't casually give up lightweight indentation-based syntax and optional parentheses, despite the confusion both can cause. CoffeeScript makes it easy to create small DSLs that are fairly readable. Implicit hashes make for easy keyword-based arguments, only requiring '->' to make a value lazy is a bit better than () =>, and in particular not needing to end a big block of mixed code and data in a random mix of ")}]});" is a surprisingly big win, aesthetically.

<comment><USER13> I have written a full production application in CS before switching to JS and then eventually migrated to TS.

I was one of the "you save characters, you gain readability" proponents as well (I love Python too).

However, it is a terribly flawed argument. Typing characters is incredibly cheap.

Debugging and refactoring in a dynamic language. However, is very time- consuming. You might be a tad slower writing Typescript (with autocompletion and typechecking, I doubt it though). But over the whole lifecycle of a codebase, Typescript is a lot faster for everything but very small projects.

I have done refactors in Typescript in hours that would have taken me days in CS... multiple times.

Additionally the human brain can adjust to predictable noise very well (brackets). After a training period, I find Javascript and Typescript almost as readable as MY Coffeescript.

However, even when developing 8 hours for multiple months in Coffeescript, I always had a hard time to grok other people's Coffeescript. There is just too much freedom.

This does not happen that easy with Javascript/Typescript.

Generally, static typing in a complex user interface is a huge huge win productivity wise. While you type more characters, you are still faster over the lifecycle of a project. Hitting keys on your keyboard is literally the least time-consuming part of programming.

<comment><USER14> Static typing doesn't have to require typing substantially more characters though (ML-family languages are good example, other examples I can think of is Nim), the syntax choice is quite orthogonal to this but it seems like C-syntax appears in new languages mostly due to its familiarity.

</comment></comment></comment><comment><USER15> If you're an analytics shop (presumably) working with streams of events, I'm going to go out on a limb and say that not picking a functional language (purescript or elm) is a mistake. It's fits the domain so well, take a look at the mileage that slamdata are getting out of purescript for example.

 _note_ I'm being deliberately provocative with the above statement to promote discussion, not argument. :-)

<comment><USER16> I know zero developers who know purescript or elm. That is a hiring problem, especially for young companies.

<comment><USER17> I know a few Elm developers. Using a less mainstream language can actually be a boon to hiring. (Isn't there a classic PG essay on how ViaWeb benefitted enormously from using a Lisp when no competitors did?)

> _Had our first hire start today who applied because we use @elmlang in > production. He rocked it!_

> _PS: still hiring :)_

[https://twitter.com/rtfeldman/status/656238188961226752](https://twitter.com/rtfeldman/status/656238188961226752)

Furthermore, I've learned _so many_ languages on the job in my career that I am unsympathetic to companies who refuse to believe that people who have learned programming can continue to learn programming!

<comment><USER18> PG isn't God, and he related a single anecdote. I won't believe that argument unless I see current data that's language-specific.

For example, I could imagine easily being able to hire devs to work on Go, but it'd probably be really hard to get them to work on Haskell.

<comment><USER17> > PG isn't God

Can you prove that? Absence of evidence isn't evidence of absence, after all. You're being a bit militant in your pg-atheism.

Okay, in all seriousness, you are correct. Ability to hire coders to work in a particular language is a legitimate concern to have. Still, it's sad to see lack of usage drive, well, lack of usage – sometimes it looks to me like an unexamined assumption, or a self-fulfilling prophecy. To take it back to the land of religious arguments: it's a bit cargo-culty.

<comment><USER18> I agree with what you're saying, but "low popularity" is just one mark on one side of the pros/cons list.

New languages can outweigh low popularity with lots of other important qualities: syntax, tooling, appropriateness for a certain purpose, abundance of libraries, etc. If the new language is easy to learn, that pretty much defeats the issue of low popularity all together!

Unfortunately, a lot of new/amazing languages with great tooling are somewhat hard to learn. Again, Haskell might be a great language, but it's daunting to people who only have experience with C-like languages.

Go is one of the exceptions, and I think it did that intentionally. Instead of having complex syntax, it just has lots of boilerplate. It's easier to read and easier to learn at the expense of being harder to write and harder to modify.

<comment><USER19> > _New languages_ can outweigh low popularity with lots of other important > qualities [...] _abundance of libraries_ , etc.

How?

> If the new language is easy to learn, that pretty much defeats the issue of > low popularity all together!

If the language is easy to learn it's probably not worth learning. "Easy to learn" in most contexts and for most people means "similar" or "familiar".

Of course, there are languages truly easy to learn thanks to their small surface and internal consistency (like Erlang, PicoLisp, Forth...) but they are very rarely regarded as such.

> Again, Haskell might be a great language, but it's daunting to people who > only have experience with C-like languages.

My opinion is that it's their problem, not Haskell's. Instead of "being daunted" they should go polyglot already and stop whining.

<comment><USER18> > > _New languages can outweigh low popularity with lots of other important > qualities [...] abundance of libraries, etc._

> _How?_

By "new" I didn't necessarily brand new. I meant something like Rust, Go, or Julia. They're more than 3 years old and relatively fully-baked, but they're much younger than the mainstream languages.

I don't know much about Julia, but in the Rust and Go communities, the early adopters are producing libraries for the not-so-early adopters. A good question would be, "Why?" I think the answers are: 1) fun, 2) because they want to get others to use the language, and 3) because their company has adopted the language in production.

So it does (and has to) happen. In this whole thread, I'm not talking about the decision-making process of an early adopter. I'm talking more about someone replacing a mainstream language in a production or business environment.

> _" Easy to learn" in most contexts and for most people means "similar" or > "familiar"._

I meant "easy to learn" however you want to define that. Similar/familiar is fine, as it's definitely contributing to the popularity of Rust and Go. It really does hurt some excellent languages (e.g. OCaml) that they look so alien to mainstream, working programmers.

> _My opinion is that it 's their problem, not Haskell's_

That's true. A language should have whatever syntax is most effective and not make the same mistakes that past languages made.

However, that's not the same thing as readability. A language can be totally different from C-family languages and still be readable. To mention OCaml again, I find it ridiculously hard to read because there are tiny, similar- looking characters that are significant all over the place. To my eye, significant dots and tildes are very hard to pick out when I'm scanning down a page.

So assuming Haskell is readable to a complete newbie, it isn't Haskell's problem that the syntax is new. But it _is_ Haskell's problem if it can't overcome the catch-22 that people don't use a language if other people don't use it.

I'm glad we're talking about Haskell, because that community is very enthusiastic and has made some incredible, accessible Haskell resources to solve this problem. It may not be their problem, but they're still attacking it, as every language has to. It seems to me that the Rust community knows this and is going in the same direction with highly-accessible tutorials.

As for Go, the language is so small that it's "easy to learn" in terms of syntax, but the patterns and paradigms you use in Go might take longer as a result.

<comment><USER19> > It really does hurt some excellent languages (e.g. OCaml) that they look so > alien to mainstream, working programmers.

How will you explain a relative success of F#, then?

In my opinion "looking alien" is not important at all. To the mainstream real qualities are much less important than marketing; that's true in many areas and mainstream programming is not an exception. Given enough marketing, you can turn "alien syntax" into a perceived advantage relatively easily.

> To mention OCaml again, I find it ridiculously hard to read because there > are tiny, similar-looking characters that are significant all over the > place.

Have you seen J? I'll just paste a bit of code in it:

       join =: 1 : 0
        ((([:{.[:>{.),:[:([:<(>"0))"1[:{:[:1 2 0&|:[:>([:,u"0)#]) (pr y))
       )

Is it readable? I'm told that yes, it is. There are people who can read this mess just fine, no problems at all.

Readability is an artifact of familiarity and, in some cases, tooling. You can get used to reading (and writing) even the most "unreadable" of syntaxes. Ask a PERL programmer if she finds her language readable. Will she say "no"?

My point is: until readability is formally defined and we're able to measure it objectively it's utterly useless to talk about it.

> But it is Haskell's problem if it can't overcome the catch-22 that people > don't use a language if other people don't use it.

Yes, but this problem _cannot_ be solved with technical qualities alone. Was it possible we wouldn't use C, Java or JavaScript at all.

It's marketing and "killer use-cases" that matter. You want to use the same language your OS is written in, for example. Was Windows written in OCaml you'd use OCaml to write Windows programs. If there's a program you really like, which is scriptable in Lua, you will use Lua.

<comment><USER18> > _My point is: until readability is formally defined and we 're able to > measure it objectively it's utterly useless to talk about it._

It's more defined than we, as programmers, pretend it is. There's research in cognitive psychology, linguistics, and lexicology that tells us that some things are easier for human brains to process than others.

For example, if you skim through a block of code, it's easier to pick out "&&" than it is to pick out "and". There are lots of rules like this.

This is partially because of the way humans read words. If yuo spel a bunhc of words wrng in a sentence in minor ways that don't alter the shapes too much, it's still very readable.

That's why your example of J is very hard to read (objectively, not relatively). If someone removed or altered a few of those symbols, no one would notice upon skimming it. It's ludicrous to argue that it's readable just because some people say it is (and I think they're just bragging to begin with).

<comment><USER19> > There's research in cognitive psychology, linguistics, and lexicology that > tells us that some things are easier for human brains to process than > others.

I'm not convinced that such research controls for familiarity effects. Not to mention, programming languages have much richer syntaxes than natural languages. I think (suspect), in regard to PLs, what you're talking about (you mention "skimming" later) is actually legibility - ease of recognizing letters and words. Not readability, that is ease of understanding the meaning of what's written.

> For example, if you skim through a block of code, it's easier to pick out > "&&" than it is to pick out "and".

Why? What if the rest of the line is similarly composed of punctuation? Are you sure in a line looking like this:

       >&.@:/"1\and[:    NB. some nonsensical J phrase

you'd have an easier time spotting the "and" were it written as "&&":

       >&.@:/"1\&&[:

> If someone removed or altered a few of those symbols, no one would notice > upon skimming it.

Possibly, but we're not talking about "skimmability", but readability. Removing or altering a few characters in that line would result in an incorrect, nonsensical sentence and you'd notice it right away.

"Right away" is subjective, of course. I spent nearly an hour trying to read this damned thing when I attempted it for the first time. Every J phrase was a challenge then. It's still hard, but it got _much_ easier with practice. The trick here is exactly the same as in your example:

> yuo spel a bunhc of words wrng

that is, once you learn how the words look like you can recognize them easily, even if they are a bit mangled.

> (and I think they're just bragging to begin with)

Yeah, I get the same feeling sometimes ;-)

But a human brain is great at pattern recognition. It has to be trained, and it's possible that some shapes are harder to learn to recognize than others, but once you learned them... is there really a difference?

Learning different PLs is my hobby, I've looked at ~80 languages to date and learned quite a chunk of them. Every single time I noticed this effect: once you internalize shapes of common phrases, you stop having trouble reading the code. It's much, much harder in some case (J is an abomination here - I'm trying to really learn it for the second year now and... it's not going that well) and easier in others (Smalltalk, Lisp, Forth, ...). But I strongly suspect every language, if studied and used enough, becomes readable.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Not trying to sell CoffeeScript here but most reasons of the author for dropping it looks more like a fault of the developer instead of the tool.

* Ambiguous syntax? Just add a few parenthesis.

* You don't like the existencial operator? Learn some JS, being able to easily differentiate between a truthy value and the existence of a variable with a single character is as sweet as it can get.

* Comparing a language to Babel? Doesn't make sense. Babel translate ES6/2015 to ES5 for compatibility. Comparing ES6/2015 to CoffeeScript makes sense.

* CoffeeScript is the reason you couldn't scale/solve data syncing or redrawable views? JS/CS/TypeScript/etc have nothing to do with that! Maybe he was thinking about Backbone?

Seems like the guy is confusing tools and languages... and making (bad) decisions because of that.

Personally I'm not going back to writing { }, return and ;'s :-)

<comment><USER21> Language should be natural enough for the person to use and good enough to apply for the problem at hand. We don't yet know how to have consistently good solutions for these requirements.

For me, {} are better than spaces - perhaps because of habits, but what will I get in - non-effortless - changing my habit in this place? "Add a few parenthesis" advice seems the opposite - don't we want not to have to use artifacts for clarification, but have simple and natural defaults working? Etc.

<comment><USER22> It's not a choice of this versus that. In CoffeeScript you don't write spaces instead {} - you write neither. You express this with indentation anyway so why the extra boilerplate? CoffeeScript removes a lot of the excess work while TypeScript actually does the opposite.

</comment></comment></comment><comment><USER23> Once you go typed JS you don't go back.

We had a large existing pure JS codebase, so Facebook's Flow was a better fit for us. We still have some portions of our code that don't have type annotations, and invariably that's where the majority of new bugs are introduced. Now we have a policy of making sure all the files we touch are typed, and adding types to a file if it doesn't already have it.

Types + React is a whole new ballgame when it comes to front end dev.

<comment><USER24> Every JS code is a valid TS, since TS is a superset of JS.

You can benefit immoderately from compiling your existing codebase in TS; you'll probably discover some bugs, even before adding any annotations.

<comment><USER25> > _Every JS code is a valid TS, since TS is a superset of JS._

There are still cases where you'll need to sprinkle <any>. For example:

        var state = { foo: 1 };
        if(something) {
          state.bar = 2;
        }

is valid JS, but the TS compiler will complain that `state` does not have a member named `bar`.

<comment><USER26> The TS compiler will complain but still generate working JS code, so you don't lose anything.

<comment><USER25> But the compiler's output will be polluted with these false positives, making it harder to see actual errors. (Also, there's a compiler flag to prevent codegen on error, which comes in handy sometimes.)

</comment></comment></comment></comment></comment><comment><USER27> I've been playing around with typescript and together with IntelliJ it's just great... Fast transpiling, easy to config, easy to debug, typed, the list goes on...

The only thing that toke me a while to understand at the start was the whole "Definetly Typed" repo, why and how to use it. It is a bit strange to have to add types as you develop but you can live with it after it sits in.

There is also Angular 2 which mergers very well with it, friendly advice, try it!

<comment><USER28> My experience with Typescript is that I have spent the majority of what I would call 'wasted' time either messing with type definitions, or fumbling with getting modules to play nicely with code that needs to be used in the browser and in Node. My impression of the language is fairly positive, however I'm not currently using it for backend development because the burden of the type definition files is too great. Having to write a type definition file yourself for a library where none exists has been fairly painful in my experience.

<comment><USER29> If you don't have time to write a type definition file, there's always the fallback to any type. (I tend to start with any-typed things, see any as a TODO marker, and then fill in definitions as I have time, interest, or need.)

declare var SomeGlobal: any

declare module 'some-node-module' { declare var m: any; export = m }

Also, hopefully more npm package maintainers will start to add typings directly now that TypeScript searches node_modules.

</comment></comment></comment><comment><USER30> I've been looking into TypeScript recently, but after having clicked on this article, I'm thinking that I'll stick with ES6.

Being able to have code completion in javascript is nice, but it's also something that you can work around by developing a good work regiment using browser-based debugging tools. The benefit of typescript is substantial, but circumventable. The drawback, one that I haven't seen anyone mention yet, is now having to deal with generics inside javascript. Trying to reason about this code and spending most of my cognitive focus on how the author is dealing with generics adds an entirely different complexity to reading and understanding javascript.

On one hand, it's helpful to have types. On the other, adding a very Microsofty overhead to programming using meta-data on your data and generics inside javascript makes me want to pass on this.

<comment><USER18> Reasoning about generics in TypeScript isn't bad. I'm not totally sure what you meant by that. I just rewrote an API in TypeScript for Node, and I didn't spend most of my time reasoning about meta-anything. TypeScript mostly added amazing, insightful static analysis, and when I ran my code, it almost always worked perfectly at runtime. The debugger in VSCode is great, too!

<comment><USER31> I think its a common meme that started because of the complexity of C++ templates and continues to be perpetuated by the creators (and moreso, users) of Go as an excuse to not implement generics.

Unlike C++ templates, generics in TypeScript are really simple - I'd estimate it would only take a week to get used to them.

<comment><USER30> I have some experience with C++'s templates, but I'm more comfortable with Generics in C# which I believe are done correctly. I view the code I saw as closer to C#'s approach to generics so I'm not sure your assumption is correct in my case.

I just don't want the extra mental overhead of writing and reading generic parameters whereas I never had to do that with javascript. I really enjoyed the concept of having types for my javascript objects, but am getting frightened at the concept of decreased readability due to generics.

<comment><USER32> C# generics are not the same creature as C++ templates. It isn't a matter of done correctly or incorrectly, it's apples and oranges.

<comment><USER30> Yes I know. I've done both. Typescript's syntax appears more like C#'s generics.

My issue is that I would like types for when I get data from the server, but I don't really want to deal with casting window to "any".

I personally went through the pains of learning javascript and have come out on the other side comfortable with its dynamic types. I really like the idea of compile time error checking, but I'm not sure I would stand for adding the complexity of generics.

The change in my workflow is not very difficult. For example, when I'm using plain old javascript, I use documentation to find out how to use third party libraries and DOM manipulations. Though it works out for all of my needs, I wouldn't mind adding types. Adding types on top of that would reduce casting and spelling mistakes, but it's not like I can't open up the browser and test my code with a step through debugger. I would personally prefer opening the browser and maintaining readability in my code versus having type safety in my code and giving up readability.

<comment><USER31> I almost forgot: generic type variables are used very little outside of generic libraries. We have a 20KLOC codebase which doesn't use type variables at all and has only a single in-house written dependency [1] that declares functions with type variables.

note: This is about declaring generics, not using them. You'll still have to write Array<string> and Promise<MyType>, thats true. But its hardly any different from ArrayOfString or PromiseOfMyType in terms of readability.

If I may be so bold, I'd really encourage you to give it a spin. You just might find that your fears about readability are exaggerated.

[1]: [https://github.com/doxout/promise- observer](https://github.com/doxout/promise-observer)

<comment><USER30> I didn't catch this at the time, but I will take a look. Thanks.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> After Coffeescript, it's really hard to go back to excess brackets everywhere. I really wish there was a Coffeetypescript.

<comment><USER34> I used to feel the same way, but now I greatly prefer languages with brackets. Refactoring and auto-formatting in indentation-sensitive languages can be a real pain. Semicolons, though, I have no use for. Pity that omitting them in JS potentially leaves you open to some nasty issues.

<comment><USER29> I've been using semicolon-free Typescript a lot lately (and really liking it that way) and its transpiler is ASI (automatic semicolon insertion) aware so it ends up adding the semicolons back into its JS output, which you can use as a safety net if you are worried that you don't quite have a handle on ASI.

That said, JS ASI is not much different than Python/Coffeescript newline rules and if you are comfortable programming semicolon free in those languages there shouldn't be a reason that you should feel uncomfortable going semicolon free in Typescript and/or JS. The nasty issues are in fact mostly the same as Python/Coffescript.

</comment></comment></comment><comment><USER35> This is being portrayed as clear code / a helpful pattern??

      class GraphQuery extends Query {
        static parse(object: any): Try<GraphQuery> {
          return TimeRange.parse(object.over).flatMap((timeRange: TimeRange) => {
            return Filter.parse(object.where).flatMap((filter: Option<Filter>) => {
              return GroupBy.parse(object.by).flatMap((groupBy: Option<GroupBy>) => {
                return new Success(new GraphQuery(
                  filter,
                  groupBy,
                  timeRange
                ));
              });
            });
          });
        }
      }

</comment><comment><USER36> The biggest advantage of TypeScript is that the output is unminified Javascript that closely resembles the input. In fact, you could show someone the output and convince them that you wrote the Javascript manually (rather than generating it from the TypeScript).

This makes it really easy to interop with existing Javascript code, but it also makes it really easy for non-Typescript developers to pick up.

For me, learning Typescript was pretty quick, because valid Javascript is already valid Typescript. All I had to do was remember the syntax for (optional) type annotations.

Learning ES6 was actually the bigger hurdle, not Typescript.

</comment><comment><USER37>
    			  ));
    			}); // I
    		  }); // love
    		}); // TypeScript
    	  }
    	}

Actual code from the article above. Just added comments.

<comment><USER38> Trailing parents/braces seems like a bad reason to dislike a language. Ever heard of Lisp? :)

<comment><USER39> Presumably that's why some people dislike Lisp too.

<comment><USER40> Is that a valid reason? I know that personal taste plays a strong and important role but typescript is really cool.

<comment><USER41> I didn't like Lisp for a long time because of it, I've since given up and tried Lisp. My friends don't care for Lisp probably because of that as well.

<comment><USER42> I could get over the parentheses but CAR and CDR instead of HEAD / TAIL or FIRST / REST annoy the crap out of me.

<comment><USER43> I have no idea about the veracity of the claim but this page[0] contends that Lisp has had first/rest since 1959.

[0] [https://en.wikipedia.org/wiki/CAR_and_CDR](https://en.wikipedia.org/wiki/CAR_and_CDR)

<comment><USER44> It cited the claim with a source, so presumably you could check the veracity that way.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> I'll never understand why people don't just use javascript.

<comment><AUTHOR> Because it's really hard to build, test and maintain a non-trivial application in a dynamically-typed language like JavaScript.

I think it's telling that a lot of companies with the most mature products (Facebook, Dropbox, Asana) eventually resort to optional static typing in their products, whether that means extending their runtimes (e.g. Hack) or using a transpiler like TypeScript.

<comment><USER45> The implicit conversions and "we'll just randomly give you undefined to propagate ondwards" stuff is a much bigger source of bugs in JS than dynamic typing. Picky dynamically typed languages like Erlang or Python will pretty reliably produce an error/exception at the scene of the crime. (More so than C/C++!)

(Also I don't think optional static typing has gotten off the ground in Python land, or adopted in production at Dropbox?)

<comment><USER46> Dropbox Paper is written almost entirely in TypeScript.

</comment></comment></comment></comment><comment><USER47> I typically don't get into these types of conversations but here we go. CoffeeScript is a lovely language by all means and at my company we use it extensively because it reduces the amount of boiler plate code by a factor of 10 maybe even 20.

Here is a simple example:

      some_func = (callback) -> callback new Error 'boom'

      some_func (err) ->
        return console.log err if err
        console.log 'everything is fine'

The alternative JavaScript version is just too much to read.

This makes huge difference when you write async code and no amount of TypeScript can really help it.

<comment><USER48> Have you tried diving into ES6 yet? It's much more terse now that they stole the good bits from coffeescript...

        let some_func = callback => callback(new Error('boom'));

        let some_func = err => console.log(err || 'everything is fine');

<comment><USER49> I promise I started writing my comment before I saw yours ;)

</comment></comment></comment><comment><USER50> Did you also consider Flow[0] as an alternative? I'm now using ES6 with Babel to build some small side-projects and it has been a great experience. But as the codebase grows, I'd appreciate to add some Flow type annotations. Typescript looks great but it's still not JS. I wonder what will happen to all those compile-to-JS languages once ES6 becomes supported everywhere.

[0]: [http://flowtype.org/](http://flowtype.org/)

<comment><USER36> > I'd appreciate to add some Flow type annotations. Typescript looks great but > it's still not JS.

The Flow type annotations are almost identical to Typescript. There's one edge case around one of them requiring a space before/after the colon and the other not, but I can't remember what it is. I just tried running one of the Flow examples through the Typescript playground and it worked fine[0].

The biggest differences between Flow and Typescript are how you run the build system (`tsc` versus the Flow server) and the file extension you put on the file.

[0] [http://www.typescriptlang.org/Playground#src=%0A%2F%2F%20htt...](http://www.typescriptlang.org/Playground#src=%0A%2F%2F%20https%3A%2F%2Fsmellegantcode.wordpress.com%2F2015%2F04%2F02%2Ftypescript-1-5-get- the-decorators- in%2F%0Afunction%20foo\(x%3A%20string%2C%20y%3A%20number\)%3A%20string%20%7B%0A%20%20return%20x.length%20*%20y%3B%0A%7D%0Afoo\('Hello'%2C%2042\)%3B)

<comment><USER51> While the type annotation syntax between Flow and Typescript are mostly identical (this is intentional), there are a bunch of differences between them:

* TypeScript allows unsound casting, Flow doesn't. These casts are very practical, as you might know more than the analyzer. Flow takes a stricter position here, which is a theme.

* Function are bivariant w.r.t. their parameters (which is unsound) in TypeScript, but contravariant in Flow. Again, this is an intentional, practical choice, but Flow emphasizes soundness.

* TypeScript asks users to add annotations in scenarios where Flow will infer types. TypeScript will infer any (there is a "no implicit any" option).

* Classes in Flow are nominal (interfaces are structural). Classes are structural in TypeScript.

* Flow adds no additional runtime syntax to JavaScript; TypeScript does (enums, for example). Flow does support some ES2016 features (async/await, object spread), but generally holds off on experimental features (stage < 2).

* Flow has a couple interesting features absent in TypeScript, like disjoint unions. I suspect/hope both systems will converge on useful features like this.

* TypeScript treats null as a bottom type, but Flow uses explicit "maybe types."

<comment><USER52> TypeScript supports disjoint unions: [http://blogs.msdn.com/b/typescript/archive/2015/09/16/announ...](http://blogs.msdn.com/b/typescript/archive/2015/09/16/announcing- typescript-1-6.aspx)

The two real pain points (among those you mentioned) of TypeScript are bivariant function parameters and structural classes, since they lead to potentially unsound code that compiles.

<comment><USER51> The link you provided doesn't seem to show disjoint union support. I'm talking about this: [http://flowtype.org/blog/2015/07/03/Disjoint- Unions.html](http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html)

</comment></comment></comment></comment></comment><comment><USER53> I _do_ wish CoffeeScript had stronger type support, however, I don't want to give up indentation, optional object brackets, optional function parens and easy loops.

There are a ton of other CoffeeScript features I love like the string interpolation syntax, comprehensions, implicit return, @ for this, improved switch syntax, ranges and a ton of other stuff, but I'm going to hang on to those first four for as long as its practical to do so.

</comment><comment><USER54> From the cons the author listed for typescript, this article is way too generous with this language. Like CoffeeScript it is just an intermediate solution to the problems JS has. We are still far away from inventing a good language for UI logic development. IMO Elm is pointing in the right direction, Scala.JS is getting some interesting traction and momentum.

<comment><USER52> Personally I'm not a huge fan of mixing language with UI architecture - <USER2> seems like it would slow down development on both fronts. Replacement costs are also much higher.

That aside, we'll talk about how we built our architecture in our next blog post! I promise you that I thoroughly pored over the Elm architecture tutorial[1] before designing any building blocks.

[1] [https://github.com/evancz/elm-architecture- tutorial/](https://github.com/evancz/elm-architecture-tutorial/)

</comment></comment><comment><USER55> Kind of feels like they're trying to jump from one popular thing to the next. The JavaScript world is exhausting.

</comment><comment><USER56> You can have my CoffeeScript when you pry it from my cold, dead hands.

</comment><comment><USER57> I wonder by Babel was ruled out, in conjunction with Flow. DefinatelyTyped was a game changer for us, as it already has a large repository for popular libraries.

But except that, typescript has some catch up to do in terms of typesystem with Flow.

</comment><comment><USER58> There's no need to choose between TypeScript or Babel!

You can use TypeScript with --target es6 and then use babel as a secondary transpiler.

<comment><USER59> Isn't the problem that the TypeScript compiler doesn't support all of the ES6 features that Babel does?

</comment></comment><comment><USER60> Migrating away from CoffeeScript too. I'll be happy to have the ternary operator back. The existential operator was handy but became a source of land mines as the project grew. Will miss list comprehensions though.

<comment><USER61> Seriously? 'You' ? 'like' : 'this'; if 'better' then 'than' else 'this?'

<comment><USER60> Ternary operator is more compact and consistent with many other programming languages.

The bigger issue was the bugs the existential operator led to. Not worth it when checking for existence wasn't a problem in javascript anyways.

<comment><USER61> What sort of issues were you having with the existential operator? I've honestly never had a problem with that, and I often wish I had it in other programming languages.

</comment></comment></comment></comment><comment><USER62> Why not Haskell? If you're going to be transpiling to JS might as well get all the power of purity and robust typing.

<comment><USER63> Which haskell to js project do you recommend? The wiki lists a number of them, but it's to tell which is the best choice.

<comment><USER62> GHCJS. That said, there's not necessarily a best choice because it depends on what type of application you're transpiling.

There's an Om-like UI project with bindings to virtual-dom [https://github.com/boothead/oHm](https://github.com/boothead/oHm) as well as various react bindings such as [https://github.com/joelburget/react- haskell](https://github.com/joelburget/react-haskell)

</comment></comment></comment><comment><USER64> Typescript looks great until you realize you need special files that match types in third-part libraries:

[http://www.typescriptlang.org/Handbook#writing-dts- files](http://www.typescriptlang.org/Handbook#writing-dts-files)

Will your third-party-lib that doesn't use Typescript keep a dts file? Who knows...

<comment><USER65> ..and for that work, you get a whole class of errors removed from your code..

Luckily most of the big libraries are covered; it's mainly smaller stuff - think random jQuery plugins - that aren't covered.

These are libraries which are often hacked together, lack tests, clear documentation and anything approaching support. So things that you shouldn't really rely on.

</comment></comment><comment><USER66> How about using JavaScript with flow?

<comment><USER52> We considered Flow initially as well - but aside from its built-in maybe types (we use Monapt for this!), it's a subset of TypeScript feature-wise that doesn't iterate as quickly.

<comment><USER29> Side question: when evaluating/updating Monapt did you take a look at any of the "Fantasy Land" compliant implementations? ([https://github.com/fantasyland/fantasy- land](https://github.com/fantasyland/fantasy-land))

<comment><USER52> Ah! I think I saw this awhile back. I didn't refer to it too much when working on Monapt since it seems to serve a more abstract purpose, and since Monapt's original purpose was to emulate Scala syntax.

</comment></comment></comment></comment><comment><USER67> Have they fixed the issue where it was really hard to work with third party libraries unless they have type definitions?

One problem I saw that it was heard to try out release candidates for React when they were lacking type definitions.

Apart from that I really like TypeScript.

<comment><USER68> Not that I can tell, and it is the one thing keeping me from embracing TypeScript.

To get the full benefit from TS you really need to have type definitions for all 3rd-party libraries you use. Libs that aren't written in TS generally don't provide them, and many of the community definitions maintained by DefinitelyTyped are badly out of date or incomplete, which in my mind is worse than having no definition at all.

Without defs you can get the compiler to stop complaining by turning off implicit any errors and creating definitions for just a few things like node's require and exports, but this felt like too much of a hack for me to really feel good about it.

If anyone has found solid solution to this problem please let me know. I love TypeScript but don't want to spend too much time futzing with definitions.

</comment></comment><comment><USER69> After using ES2015 patterns for a while now CoffeeScript looks utterly barbaric in comparison. That said it's really for Ruby programmers (or those who know/want to know Ruby) who write JavaScript so I guess it will continue to fill that void.

It adds no utility outside of that niche anymore however.

TypeScript is great but I honestly prefer ES2015/ES6 + Flow comments. It means I write native JavaScript (ok, for now a transpile step, but _that will go away in time_ and I'll still have valid JS code) but get all the benefits of typing like in TypeScript.

However TypeScript is still pretty awesome, though I find the syntax rather verbose.

<comment><USER70> You have an interesting opinion. Coffeescript has, for several years now, encompassed nearly the entire API surface of ES2015.

      * Comprehensions (more flexible with Coffeescript).  Wait, that's ES7 now.
      * Template strings
      * For .. Of loops
      * Destructing
      * Classes. ES2015 has an awful implementation of this, without allowing an syntax for binding methods.  Also enforces the somewhat arbitrary requirement of function properties only, as opposed to any type I choose.  Don't forget, mixins with Coffeescript classes is a breeze, but no support with ES2015.
      * Arrow functions.  Unnecessary syntax with ES2015 (the parens even without arguments), not to mention confusing implicit return.
      * Generators with ES2105.  If you find a use for these in front end web dev I'll buy you a beer.

ES2015 does succeed in introducing an entire set of confusing ideas: we rolled for years with var's, but now I get my hand held with const and let, because figuring out how var works (or just relying on Coffeescript to handle it for you) is too challenging.

The point here is that it is frustrating to see people jump on the ES2015 bandwagon when Coffeescript has had the same feature set for years. It suffered adoption because of developers who didn't want to learn `another` language. I have met a tremendous quantity of developers - myself included - who initially rebelled against the use of Coffeescript, only to eventually fall in love with it.

<comment><USER69> > Coffeescript has, for several years now, encompassed nearly the entire API > surface of ES2015.

Agreed. I didn't say features; I said _looked_. It looks horrible in comparison.

ES6/7 code is much cleaner, clearer, and more idiomatic, than CoffeeScript. (in my experience, and I've used/debugged/worked with a LOT of both)

Not going to crap all over the _features_ of CoffeeScript, those were good (though they produced pretty awful looking JS code as a result). I would say however it wasn't worth the trade off in debugging pain.

<comment><USER71> > ES6/7 code is much cleaner, clearer, and more idiomatic

I'm assuming you're talking about the compiled javascript from coffeescript and not coffeescript itself? I find coffeescript code much, much nicer to read, write, and deciper.. but that's just me!

<comment><USER69> Well I could refer to both, but no I wasn't specifically (though it does apply).

I'm curious: were you a Ruby dev before using CoffeeScript, or at least had a reasonable amount of experience with it?

That said I find Ruby to be dense and annoying to read sometimes (due to its sometimes Perl Golf obsession with brevity in language constructs), so it could be just Ruby idioms annoy me ;)

<comment><USER71> I haven't used ruby but ive been writing python for many years and so the indentation-based syntax definitely something I enjoy. But that said I didn't even use coffeescript until I was forced to while working at a huge media company where the big project I worked on had the large client written in coffeescript... once I got used to working with it I think I enjoyed the clean code and productivity gains..

I guess your milage may vary though depending on what you're doing etc.

</comment></comment></comment></comment></comment></comment><comment><USER72> interesting. we use coffeescript at nootrobox.com, but as you noted, it doesn't have a lot of hand rails. many a time, i've run javascript through a js2coffee translator to verify. will look into typescript.

</comment><comment><USER73> Embrace, extend, extinguish. TypeScript doesn't implement ES6 fully.

</comment><comment><USER74> [http://www.walkercoderanger.com/blog/2014/02/typescript- isnt...](http://www.walkercoderanger.com/blog/2014/02/typescript-isnt-the- answer/) so this blog is arguing typescript is not that good either.

Can we have a typescript-alike tool that integrates the "best parts of javascript" and defaults to 'use strict'? if there is one I'm in.

<comment><USER75> Babel + Flow?

</comment></comment><comment><USER76> > Existential operator accessor (?.) is a leaky abstraction for null

I found this out the hard way when using it in groovy a while back. The Options abstraction you describe is better, or the one in Java 8, which Groovy _still_ hasn't brought into its syntax. Groovy's creator James Strachan talked a lot about how he designed Groovy to avoid the "leaky abstractions" in Java.

<comment><USER52> There is also this gem of a quote by him[1]:

> I can honestly say if someone had shown me the Programming in Scala book by > by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have > never created Groovy.

[1] [http://macstrac.blogspot.com/2009/04/scala-as-long-term- repl...](http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement- for.html)

</comment></comment><comment><USER77> Is Typescript a good language for someone that has done very little in Javascript? Are resources available for newbies? I've programmed in dozens of languages over the last 30 years, so I'm not a beginning programmer, but have simply never messed with Javascript.

How does Typescript compare with Dart? Is Javascript the place to start?

<comment><USER78> I don't think you can expect to use typescript without really understanding javascript. Not to say you shouldn't learn typescript first. But by the time you're fluent in typescript, you basically know javascript also.

</comment></comment><comment><USER79> If you want to migrate a coffeescript codebase to typescript, try out [https://github.com/palantir/coffeescript-to- typescript](https://github.com/palantir/coffeescript-to-typescript) which should do it for you automatically

</comment><comment><USER80> I am trying desperately to understand why TS. How does lumping in the baggage of Java/C# onto a functional language like JS make it better?

 _We have to wait for the previous generation to retire or die before we can get critical mass on the next idea._ \- Douglas Crockford

</comment><comment><USER81> I heard Wikia gave up on TS - wondering why people are leaving TS ? Too much friction ?

</comment><comment><USER82> Where is the developer community going 2 years from now? I think we can derive some sort of Moore's law for new languages/frameworks for JS/Web/Mobile. Objective C and now Swift. Coffee script and now Type script. JS frameworks and more frameworks. What can be the tighter bound Moore's law alternative for new frameworks and languages for Web / Mobile/ IOT. It almost always doubles every two years for sure.

</comment><comment><USER83> Anyone know if TypeScript will ever be included in ECMAScript standard? If it is I will love Microsoft forever.

<comment><USER84> It's not _that_ far off of ActionScript3, or ES4's proposals for strong typing... I think things are probably headed that way, I would love for the AS guys to integrate as a Babel plugin for typing (similar to flow), so that it's just one tool to rule them all... FB already deferred to Babel for JSX processing.

</comment></comment><comment> nv-vn >Non-mainstream syntax seems like this author already knew what they were looking for from the beginning.</comment>


Ask HN: Main reason that year of the Linux desktop hasn't happened (yet)? - <AUTHOR> <comment><USER2> I installed Debian (supposedly a distribution that is stability-oriented) just today. After initial restart, it greeted me with... a blinking cursor (not even a prompt) in the upper-right corner of the screen. Knowing Linux, I knew that I need to Alt+F1 into a terminal, log in and then troubleshoot what went wrong. Turns out you need to manually download and install some ATI firmware or the X won't work. I wasn't informed of that anywhere in the installation process. As long as shit like that is commonplace, Linux adoption will be limited to fans and IT specialists.

BTW once I fixed that, it turns out that Xorg, even with the recommended drivers, is just too crappy to maintain Vsync and everything (even just moving of a window on the desktop) is slightly, but noticeably tearing. As a remedy, I switched to Wayland, which is designed to not have this issue, and everything is butter-smooth. Why is Debian shipping with an option to install the crappy, tearing windowing system in 2020? Many users will, not knowing about the Wayland fix, want to go back to Windows after just couple hours of use.

<comment><USER3> Debian is stability oriented not user oriented. Ubuntu and Fedora have better defaults and work well.

</comment></comment><comment><USER4> This question presumes that "the linux desktop hasn't happened". Something that is very much a definition issue.

* What is "happened"? Millions of people use Linux on their desktop. Probably more people (absolute numbers) use Linux today, than windows3.11 back then. Does that mean windows3.11 never "happened"?

* What is "Linux desktop"? Is chromebook a Linux desktop? A raspberry-pie? A laptop? The terminal on the counter of some large bank or PoS in a large shop?

What also strikes me in this, is that it used to be "the year of linux", until Linux emerged in every niche as clear "winner" (firmware, mobile, terminals, servers, supercomputers), at which moment the meme pivoted from "year of Linux" into "year of the Linux Desktop".

I'm not saying OP is doing this, but I have a strong feeling the phrase "year of Linux _on the desktop_ " is mostly used by people who want to show that Linux is failing.

Edit: which it clearly is not: Linux is Open Source. Open Source has "won" the very moment one person is using it successfully. The fact that I'm typing this on my Linux machine means that Linux "won"; don't forget that Open Source software has no- or at least a very different business model than most closed- source software: success is not (nessecarily) defined by "market share".

</comment><comment><USER5> There are too many Linux distributions and too many desktop environments. There is no coherent message as to what software to use. It is difficult to develop a critical mass of users that uses the Linux desktop.

Lenovo announced recently that they will support Ubuntu in their range of P-series laptops because they are interested in the near 3% total Linux global desktop users.

</comment><comment><USER6> Linux desktop is simply unreliable. I know this might not be what the community would like to see in the comments, but in my experience, the linux desktop has a long way to go in terms of reliability.

For example, an ubuntu update, literally crashed my system and i managed to recover my machine from collapse. I am a techie, so i managed to do this, how many normal people can do this ? Would they know where to look for the issue ?

Also, the desktop freezing, and constant popups asking to submit reports for some internal issues is quite an annoyance.

Having said these, using only cli linux is the best and no OS comes closer to the versatility of linux. But as a desktop, i feel its has not made it. Reliability is a core feature.

</comment><comment><USER7> Main reason is the lack of a holistic approach. Every Linux desktop is a loose collection of separate programs that don't really play together in harmony. There are no Product Managers behind the distros, it would seem, or if there are, they haven't been very effective. KDE, GNOME, Cinnamon, all of them scream, "we haven't done user studies."

I suspect this is a function of the distributed ownership. No one is able to manage the full stack because the complexity of doing that would be a full time job and take a team working for months to get it ready.

<comment><USER8> Another way to look at it: what makes Apple successful is at odds with how the components of the Linux desktop come together/are built.

In order to provide for a consistent, interoperable experience across the stack, you need control of its components. Apple's vertical integration (now making chips!) gives it the ability to make changes in order to provide the 'best' experience (best as in, profit; taking into account consumers express their opinion with their $).

The Linux desktop optimizes for freedom: you can choose what parts you want. That's not conducive to a consistent experience.

One could argue that's not the point. If you want 'the desktop' just buy a Mac. If you want 'the Linux desktop', it's been there for a while now, just go ahead and glue together the parts - that's the point!

<comment><USER7> The freedom of choice for individual components is certainly a benefit of the platform, but I would argue that it also doesn't preclude having a default preset of components that form a cohesive vertical experience. In other words, the defaults should work. That most likely means forking select components, which is what Mint did with Cinnamon, to create a micro-ecosystem that is internally consistent, but they just haven't gone far enough yet.

</comment></comment></comment><comment><USER9> It's not good enough for most users.

<comment><USER10> This has been my (unfortunate) experience trying to help some friends and family over to various distros over the years. Linux is in the odd cycle of assuming users are comfortable using the command line to do things which inevitably leads to users who aren't comfortable not using Linux, forming a self-re-enforcing cycle. The entire Unix design philosophy of small tools that are chained together that (most) know and love only really makes sense under a cli first approach because we don't really have a semantic to pipe and redirect output in a graphical environment.

</comment></comment><comment> open-source-ux You can't design a desktop GUI by committee. But when it comes to Linux everyone wants a say. The model for open source code contributions just doesn't work for visual and interaction design. (Or if it does, I've yet to see a successful example that wasn't an exception rather than the rule).

When there are too many participants in the visual and interaction design of a program or OS, you end up with a project pulled in every direction and pleasing to no-one. But if you go the opposite route and limit design decisions to a dedicated UX team (like Canonical did for Ubuntu), you end up generating resentment from contributors or users who feel their input is being ignored.

One of the best Linux desktop GUIs was Corel Linux which was released in 1999(!). Corel understood that a consistent look-and-feel and ease-of-use were essential to attract new users. But even back then they faced criticism from Linux developers over various design decisions. Rinse and repeat this scenario for every attempt to create a consistent, cohesive Linux desktop over the years.

</comment><comment><USER11> Perhaps too much choice. The lack of a single dominant leader in the desktop Linux distribution space makes standardization a challenge. Thus every Linux desktop is a little different.

Personally I find PopOS to be the perfect blend of what I want in a desktop Linux system, but because desktop Linux isn't popular enough it still lacks support from major software producers such as Adobe.

</comment><comment><USER12> IMHO, it is because desktop development is:

1\. Fragmented. There are probably an adequate number of developers working on the Linux desktop, but they're working on different desktop environments.

This isn't necessarily a bad thing, because nearly everyone can find something that suits their tastes.

2\. Not funded. There is not enough financial incentive to get something that can truly, truly compete with the likes of macOS and Windows. The closest, I guess, would be ChromeOS, but AFAIK the needed desktop components aren't open sourced in a usable manner.

Note: I primarily run either Ubuntu GNOME, XFCE, or Manjaro as the primary OS on my home PC -- depending on my mood of the week.

</comment><comment><USER13> Macs come preinstalled with MacOS, anything else comes preinstalled with Windows. Very few people will even consider their OS as something they can choose, many have no idea what Linux is and the percentage of people who will take the time and effort to switch to Linux is even smaller. So the Linux desktop will remain a thing mostly for people who work in software.

</comment><comment><USER14> It already happened for me, I've been using it with all my computers since 2000.

</comment><comment><USER15> I'm curious what would have to happen for you to consider "the year of the linux desktop" to have happened? I'd say it arguably already has happened.

<comment><USER16> I'm curious why say that it has already happened? Linux is generally reported to only have 1-2% market share for personal computers.</comment></comment>


Ask HN: What is the eng headcount of global Google and FB offices? - <AUTHOR> This is one part of the puzzle of evaluating global alternatives to SF (and the US in general).
They both list a number of locations: https://www.facebook.com/careers/locations/ https://www.google.com/about/careers/locations/
but it's unclear where the bulk of non-American engineering occurs. Does anyone know? <comment><AUTHOR> To answer my own question, after having combed through the above careers pages:

Facebook:

\- Canada: Nothing.

\- Europe: London only.

\- South America: Nothing.

\- APAC: Nothing listed, though I'm pretty sure they have an engineering office in Hyderabad.

Google:

\- North America: Waterloo only ("More than 350 engineers expected").

\- Europe: London (biggest), Zurich, Warsaw.

\- South America: Nothing.

\- APAC: Hyderabad, Sydney, Tokyo.

</comment><comment><USER2> Zurich is a big non-American engineering office, there is some in Dublin, and London.</comment>


What's Hiding in Demand Media's Finances? - <AUTHOR> http://www.wired.com/epicenter/2010/09/whats-hiding-in-demand-medias-finances/all/1 <comment><USER2> I spent a few months of full time work investigating the viability of an eHow like site - trying to measure likely profit margins. I put the effort in because of this Demand Media article in wired: <http://www.wired.com/magazine/2009/10/ff_demandmedia/> and because it was the opinion of some people whose opinion I value highly that such a site would be profitable. The idea actually went against my own gut feel because I was wary of all the SEO that goes on. Although typically localized in topic, I thought in aggregate the global phrase space would be pretty densely covered by now.

Anyway...

I optimized on both the demand side (data from keyword search tool) and supply side (number of results returned from searches, number of exact term matches, and page rank of each site in the top ten). I did this for about 200k phrases (yes, it was difficult to get the supply side data). I set up 3 separate test sites to test the most promising search phrases.

I couldn't make the numbers work. I was actually nearly an order of magnitude off being somewhere reasonable and even allowing for benefits of scale (which are admittedly hard to quantify) I still couldn't rationalize that it would be a good business.

So i'm quite happy to see this article in that it some what validates my own findings. I for one will not be taking part in the IPO!

<comment><USER3> I briefly tried this too, data mining thousands of high-paying keywords and looking for available exact match domains, so I didn't even have to worry about SEO to get to #1.

I still couldn't make this profitable, even to cover domain/hosting costs, much less my own time put into the project.

But you or I are not Demand Media, and that's why we're not making the big bucks. The fact remains that they are INCREDIBLY good at acquiring and monetizing low-quality traffic.

This has less to do with their SEO skills and more with the fact that, for example, they can produce content that will hit the Digg front page 80% of the time.

<comment><USER4> gaming the Digg FP for traffic ala Cracked.com is now (for better or worse) basically over, I'm sure Cracked is seeing a massive loss of traffic.

</comment></comment></comment><comment><USER5> You have to ask yourself, what would Warren Buffet do? If you look at Demand Media not as an IPO to speculate on, but as something to own because you understand how they profit and you believe in what they do, then all I see is a big red stop sign.

</comment><comment><USER6> Queue patio11.

I remember Patrick commenting on this issue a few months back. His comment was insightful and, from what I remember, he concluded that Demand Media was indeed profitable.

His SEO knowledge lends his conclusion credibility.

<comment><USER7> "His SEO knowledge lends his conclusion credibility."

No. What lends a conclusion of profitablity credibility is numbers that make sense and not much else.

<comment><USER8> That's definitely true. The grandparent poster was referring to Patrick's top- ranked comment on <http://news.ycombinator.com/item?id=1599181> , which dealt mainly with how amortization of Demand Media's acquisitions requires them to amortize each acquisition's costs as a quarterly charge over the next ten years. A similar point is made by John Batelle in the Wired article, and is another reason why non-GAAP measures like EBITDA that exclude amortization are widely used.

This doesn't say very much about whether Demand Media is profitable once you exclude amortization, but it is an important thing to consider.</comment></comment></comment>


The unlikely origins of the word 'thug' - <AUTHOR> http://www.bbc.com/news/world-us-canada-32538487

<comment><USER2> Okay thug is exclusively reserved for Indian people. It's our word, stop using it :p

I've never heard it in a racial manner either. The play of words is silly, it just shifts the attention from the real issues at hand i.e. excessive police brutality and civic unrest.

</comment><comment><USER3> There was just a piece on NPR claiming thug now means ni__er, at least when white people say it. I'm white and always thought it mean something more along the lines of soccer hooligan or bully. Am I that out of touch?

<comment><USER4> Terms like "thug" "lynch" etc have always felt weird to me when people insist that they are racialized, but in the media the last several years I've heard it in higher correlation to a black purported criminal than a white one. But when I was a kid, I grew up in a town where there was a single black family. "lynch" was something that happened to cattle rustlers, and "thug" meant an italian gangster.</comment></comment>


BareMetal OS: A 64-bit Operating System in only 16KiB - <AUTHOR> http://blog.returninfinity.com/2010/09/baremetal-os-v049-and-baremetal-node.html <comment><USER2> Wow, from the queue presentation this OS looks even less usable than DOS (MS aka Q). Why would the CLI terminate when it runs a programme? How do you run more than one programme at once? If each core polls the run queue does that mean that it busy cycles when there is no more work to do? Won't this waste energy? (A sin in the HPC world). Does it do the same for IO? IO request completion on a slow and/or busy disk could take as long as 50ms, for a 2.5GHz CPU for example this is 125 million clock cycles. Will the CPU busy cycle this as well?

If you want a simple OS that fits a lot into a small space, why not get a copy of the Lions' Commentary and translate the edition 6 kernel into asm. If you wanted to go gung ho you could add a simple BKL, demand paging and a network stack to complete the job. You could probably do all the above and keep it somewhere close to 20,000 lines of assembly (excluding drivers).

If you are looking for an education doing the above will probably do you just as good a job as trying from scratch.

Lions' Commentary on UNIX 6th Edition, with Source Code [http://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th...](http://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th_Edition,_with_Source_Code)

The Art of Computer Programming <http://en.wikipedia.org/wiki/The_Art_of_Computer_Programming>

<comment><USER3> TAOCP and the Lion's commentary? Edition 6 kernel into asm? Why?

You're working hard to sound old-school, but these are just random allusions. TAOCP is not especially relevant to OS programming, and translating _all_ of an OS into asm to make it "fit a lot into a small space" is just... plain... stupid...

You will make the code smaller (as compared to gcc -Os) in a few places; you will likely give yourself a hernia maintaining it, and you are likely to get considerably worse performance than a decent compiler will.

<comment><USER4> To expand on that: it's fun to take a look at the assembly code "gcc -O3" produces. It's absolutely wild: even after staring at it for a while, I often have no idea what clever tricks gcc used to turn the C code into that assembly code. It does a better job of making fast, compact code than I suspect I ever could.

There was a time when C compilers generated crappy assembly code, because that was easy for the compiler writers. That time is long past, with exceptions for a very few situations where the compiler misses a trick that a human can do.

<comment><USER3> Well, sometimes it's fun. Other times it's utterly horrible. gcc doesn't always do a wonderful job and the maintainers sometimes just don't seem to care - induction variable optimizations and gcse were broken in 4.2 and 4.3 and the issue was left unfixed, with clear examples of obvious FAIL on simple and performance-critical inner loops.

However, this doesn't apply so much to OS code, which doesn't have nearly as much opportunity for micro-architectural shenanigans either way. Typically something like -Os does a good job of handling operating system style code.

Hand-coding OS asm remains a fine example of pointless tedium for the most part. There are clear places where you absolutely need asm, of course, but writing stuff in asm that can be perfectly well done in C is like cleaning out the barracks room bathroom with a toothbrush.

This was one of the early innovations of UNIX (high level language use), so there's something wildly anachronistic about this guy's suggestion. It's like suggesting that you rebuild grandpa's Studebaker so that it can be drawn by a team of horses.

</comment></comment></comment></comment><comment><USER5> Keep it up, I love new OSes.

My dream is to write a cloud programming language that compiles high level code to a low-level kernel and deploys. I abhor waste, so efforts like this are a great start. I look forward to more!

<comment><USER6> > My dream is to write a cloud programming language that compiles high level > code to a low-level kernel and deploys.

I'm curious as to what you want to gain from that compared to running a custom compiled Linux kernel with your program as init or as the only running process.

<comment><USER5> Nothing from an engineering standpoint.

<http://en.wikipedia.org/wiki/Art_for_art%27s_sake>

</comment></comment></comment><comment><USER7> The spin-off Pure64 looks very interesting. It looks like they have factored out the code for getting up and running with your own project:

"The loader gets the computer into a full 64-bit state with no legacy compatibility layers and also enables all available CPU Cores in the computer."

"Two very simple kernels are included to get you started with your new 64-bit OS (One written in Assembly, the other in C)."

<comment><USER8> There seems to be some "64-bit" buzzwordism going on here. There's nothing special about 64-bit; it's just a different processor mode. Writing 64-bit code is no different than 32-bit.

<comment><USER9> AMD64 also included a lot more registers, and has some extensions to the instruction set. It also makes a baseline for other features like SSE, as all CPU:s supporting AMD64 are relatively modern. Also having larger address space to work with may affect some design decisions.

So while you can write 64-bit code just like 32-bit code, it's bit like saying that writing c++ is no different than writing c.

</comment></comment></comment><comment><USER10> <http://www.returninfinity.com/baremetal.html>

</comment><comment><USER11> This reminds me of MenuetOS (<http://www.menuetos.net>), although a bit larger BareMetal OS, still manages to cram in a unholy amount of functionality in to a couple of megs.

<comment><USER12> FWIW, I found a local privilege escalation vulnerability (arguably just a bug allowing apps to trash the kernel, since it's single-user anyway) in Menuet32, and I'm not optimistic about the network stack. I would have expected ping of death to work, but it doesn't even seem to support IP packet fragmentation.

These throwback OSes are cute, but there would be hell to pay if they ever took off.

</comment></comment><comment><USER13> Other than the academic nerdiness of minimal OSs, what is this good for?

Do modern OSs cause too much overhead for certain operations?

<comment><USER14> They cause too much overhead for teaching. A minimal OS is a great way to show how one works, what the essentials are, and even what weaknesses it has.

<comment><USER4> It's amazing, when you look at a simple operating system like TinyOS, just how simple some of the things are. (Once you start actually hacking on the OS code, you realize that they're also very finnicky and easy to mess up if you don't know what you're doing. And hard to debug.)

</comment></comment></comment><comment><USER15> Could be useful if it did something new - support virtual apps, manage restartable/persistent state processes, something. Just another thread/memory/interrupt kernel? Why?

<comment><USER9> I think the point here is being minimalism, and being a starting point to build on those features you mention.

</comment></comment><comment><USER16> So is this like the demoscene stuff or is there a practical use for it?

<comment><USER17> I read the link in the article, so I'll just paste what it says:

* High Performance Computing - Act as the base OS for a HPC cluster node. Running advanced computation workloads is ideal for a mono-tasking Operating System.

* Embedded Applications - Provide a platform for embedded applications running on commodity x86-64 hardware.

* Education - Provide an environment for learning and experimenting with programming in x86-64 Assembly as well as Operating System fundamentals.

<comment><USER18> For the first use, it seems like it'd be nice if there were some way it could reuse existing hardware-compatibility work done on projects like the Linux kernel or the BSD kernels. Even if you want a single-tasking system with little in the way of OS services, you still usually don't want to be debugging the quirks of every hardware device, or writing your own driver every time you get a machine with a new SATA controller or NIC.

</comment></comment></comment><comment><USER19> Can you play Doom on it?</comment>


Why do we eat meat? - <AUTHOR> https://en.wikipedia.org/wiki/Ethics_of_eating_meat <comment><USER2> The so-called 'ethics' of vegetarianism just don't hold up. Its hard to see it as anything but cherry-picking which creatures are important, based mostly on how cute and fuzzy. Never mind the billions of low-level organisms we digest and kill no matter what we eat. Gardening and farming vegetables kills thousands of vermin per acre - mice, snakes, bees. These are not morally important. But grazers and cute fuzzy sheep _are_ morally important. I can't buy into that logic.

Folks can argue, intelligent creatures! But its not clear how that makes a difference. And it sounds like an argument made up after the fact - "How are we going to criticize eating pigs?"

How 'intelligent' is a hive of bees? How 'smart' is a creature in its own environment? No, its only human-like intelligence that matters. Again, what's emotionally cute and fuzzy.</comment>


C# Closures Explained - <AUTHOR> http://www.codethinked.com/post/2010/06/22/C-Closures-Explained.aspx <comment><USER2> Javascript (with Prototype and later jQuery) taught me how to do functional programming. Or at least made me love it. I actually began to prefer programming JavaScript for the power/freedom. Glad to see I can do about the same thing now in C# with the var keyword and closures, first class functions, etc.

<comment><USER3> Python did the same for me. Closures was not a new feature as of C# 3.0. It is a part of C# 2.0. The problem is that the syntax is so verbose and horrible in 2.0 that the readability of the code can be quite messy and almost not worth the effort.

C# 3.0 greatly simplified things with the introduction of the lambda function syntax hence why a lot more people have suddenly "discovered" closures in .NET.

When first learning C# 2.0 I had a lot of difficulty understanding how to use delegates with closures mainly because I couldn't get past the syntax. Learning and using Python shortly after helped me tremendously in understanding how closures worked and when to use them because (not surprisingly) the Python syntax is so much cleaner and intuitive. I was able to then transfer and apply this knowledge to C# by cutting through the noise and using closures effortlessly (as needed). When lambdas arrived in 3.0, it was a no brainer.

This experience showed me how being exposed to and learning other programming languages that follow different paradigms can have a positive impact on how you write code in your primary language.

</comment></comment><comment><USER4> Something I sorely missed when I still worked for the man.

Anyhow, in Lisp, visually, a LET with it's enclosing parens makes it much faster to see the closed-over variables.

<comment><USER5> Don't you mean 'lambda'?

<comment><USER4> I think I meant what I said :-), which is that closing over a lexical variable in Lisp, using LET, more _clearly_ , to my eyes at least, show which variables are hidden/closed over.

For example, in CL, this guy's example would take the general form:

(let ((counter 0))

       (defun tally ()

          (incf counter)))

So, in this form, I _know_ that TALLY hides/closes over COUNTER, without needing to inspect the function body (either before, or within a λ that might be returned from within the function body).

</comment></comment></comment><comment><USER6> Useful. I'd heard the term closure bandied around, but never bothered to learn what it was. Cheers.</comment>


1Password iOS 8 App Extension - <AUTHOR> https://github.com/AgileBits/onepassword-app-extension

<comment><USER2> This is exactly why I'm so excited for iOS 8. I never liked the apps living in their own walled garden and am excited to see those walls start to break.</comment>