Goodbye CoffeeScript, Hello TypeScript (blog.heapanalytics.com)

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.

     foo () (irb) :2: warning: don't put space before argument parentheses .

Couldnt agree more, variables are just clutter you have to keep mental track of, and working with series of transformations is much easier (for me at least) to process. I would be interested to know if its like this for all developers, perhaps not, since I know some that are also opposed to recursion.

but for me this:

    sum([]) = 0.
    sum([H|T]) = H + sum(T).

    function sum(ary) {
      var i = ary.length,
       res;
      while(--i) {
        res += ary[i];
      }
      return res;
    }

I hate this lesson. And it's not because short code is a bad thing...when you find code that's well structured and broken down such that no method/function needs to be long, it's a joy to read. The problem comes when people learn the rule without learning the why behind it. And that leads to one logical function/method that's huge and has now been broken down into many nested methods/functions simply to satisfy the "none are long" requirement. Now, as a reader, I've still got to keep the entire context of the method/function in my head, but I now have to jump all over the code to find out what the single, large method actually does. I'd rather have a single, 200-line code block to look at than this sort of jumble.

What developers need to learn is that short methods/functions are a consequence of good techniques, not a technique in and of themselves and that long methods/functions are not bad in and of themselves, but they indicate that it's very likely that the developer hasn't put the proper thought into separating concerns and ensuring that each unit of his/her code has a single responsibility.

Sorry to get on my soapbox, but I've seen this "lesson" make ugly code even uglier when programmers don't understand the why behind the lesson.

E.g. (foo bar) and (hello world)

The problem core of the problem is that many of the definitions they host are contributed as one-offs by developers who create them as needed, and often there is no one responsible for making sure they get updated in lock step with the library itself.

The only way I can think to solve this is to have a contributor to the library itself be responsible for maintaining its type definition, so that keeping it up to date becomes part of the release process. Of course, really everyone should just switch development to typescript so that the defs get generated automatically ;)

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.

It has seemed pretty easy to add types for the parts of the library I need, rather than the entire library. Is there anything in particular that makes partially typing server-side libraries difficult?

If a definition doesn't match the version of library you're using, changing the definition or adding to it omly takes a few minutes.

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

- Writing JS gives me a better feel for how the language actually works

- I like the line number in the JS I'm debugging to equal the line in my source code

- There's less magic to understand & deal with

- CoffeeScript automatically returns the last line of a function, and I don't always like that

Fortunately, most everyone else seems to understand what Coffeescript is, and thus they were able to grok my meaning.

I see that a lot and find it highly subjective. I don't find es6 useful at all and will stick with coffeescript for the foreseeable future but that also has to do with my reasons for using it.

You may have seen this, but if not: http://standardjs.com/

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.

There is only a single instance I think of that is of legitimate concern - which is #4 listed on this blog [0]. The rest, to me, seem like arbitrarily shitty formatting or scenarios that never arise in an attempt to show why semicolons are needed.

  i
  ++
  j

That being said - "remove all semicolons except the times you need semicolons" is silly. I also personally dislike the look of prefixed semicolons, so I'll continue to add semicolons. But I disagree the "nasty issues" are a legitimate concern anymore than "adding semicolons where they don't belong" is a legitimate concern. Both can bite you in the ass and both require a small understanding of where semicolons are needed and how Javascript gets parsed.

Ultimately I think having semicolons will increase the amount of people who contribute - as people will be more comfortable with that style - but I think to have or to not have semicolons is a stylistic choice in the end.

[0] http://blog.izs.me/post/2353458699/an-open-letter-to-javascr...

You can do 20 layers of callbacks in Haskell without any problem. That's how Haskell does imperative blocks of code (ie monads).

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.

> 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

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!

There are plenty of developers, especially here on HN, who would absolutely love to work with Clojure/ClojureScript full-time.

1) you'll need less people (better more reusable code) 2) the best people will speak you out.

This was very much my experience when I put a Haskell team together, and everyone I've spoken to who has done the same has said the same.

It's an opportunity for a young company, not a problem.

On the one hand there's a smaller pool of people, on the other hand a primary issue in hiring is sifting people who can do the job from a random draw[0], in which case interest and/or knowledge of Elm or Purescript is a huge prefilter, and can draw/poach people who wouldn't otherwise be interested (pg's "the python paradox"[1] talks about that)

[0] or worse, you don't get a random section of developers, you get a section of developers currently looking for a job, so the average competence of your draft is below average.

[1] http://www.paulgraham.com/pypar.html

   var a = 1;
   a = 2;

   window.someGlobal = 'foo';

* Pure functions - JS functions are essentially subroutines. They might return a useful value or they might mutate a bunch of stuff and interact with the outside world. Who knows? JS functions aren't guarunteed to return the same value, or any value at all.

* Immutability - Anything and everything can be mutated in JS, including the contents of objects that are defined using the new ES6 `const` keyword

* Curried functions by default - Although it's possible to compose or partially apply JS functions, it's not nearly as nice as Haskell or Elm.

For the purposes of this article, we tried to avoid too much syntax sugar to make it more accessible. That aside, I'd love to add something like this to monapt![1].

[1] https://github.com/jiaweihli/monapt

    >   parse : Any -> Try GraphQuery
    >   parse object = do 
    >     timeRange <- TimeRange.parse object.over
    >     filter    <- Filter.parse object.where
    >     groupBy   <- GroupBy.parse object.by
    >     return (createGraphQuery filter groupBy timeRange)

    parse = ({by, over, where}) => {
      timeRange = TimeRange.parse(over)
      filter    = Filter.parse(where)
      groupBy   = GroupBy.parse(by)
      return createGraphQuery(filter, groupBy, timeRange)
    }

    parse = ({by, over, where}) => 
      createGraphQuery(
        Filter.parse(where),
        GroupBy.parse(by),
        TimeRange.parse(over));

    parse = ({by, over, where}) => 
      createGraphQuery(
        Filter(where),
        GroupBy(by),
        TimeRange(over));

    parse = ({by, over, where}) => createGraphQuery( Filter(where), GroupBy(by), TimeRange(over) );

    parse = ({by, over, where}) => c(f(where), g(by), t(over));

    parse = ({b, o, w}) => c(f(w), g(b), t(o));

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

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

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

We also have an established toolchain with gulp and browserify and babel, and again, at the time TS didn't play as nicely (vs Flow which just worked). Things are definitely improving in the TS world, and I keep tabs on it. The fortunate thing is that both Flow and TS' annotations are compatible, so it should be relatively easy to switch from one to another.

Whichever one you go with doesn't actually matter though. As long as you go with one of them you'll see a massive increase in productivity vs vanilla JS.

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

For something that follows the semantics of JS and produces very readable code (a la TypeScript), PureScript is really nice.

It seems from the article like the reason why the dismissed it was that it interoperated poorly with existing vanilla JavaScript libraries.

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.

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