Goodbye CoffeeScript, Hello TypeScript(blog.heapanalytics.com) |
Goodbye CoffeeScript, Hello TypeScript(blog.heapanalytics.com) |
Flow is not really fundamentally different from Typescript. The syntax is almost the exact same.
I tried them out side-by-side for the same project a few months ago. The main difference was that Typescript was installable through npm and simply read and wrote files to the directory, whereas Flow required an OCaml binary and ran a client-server setup that required some fiddling to get working.
Flow is designed to work better with React, so it has that going for it, but if you're not using React, Typescript is almost exactly the same.
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.
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.
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.
* 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.
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.
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.
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.
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.
> 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...
How does Typescript compare with Dart? Is Javascript the place to start?
We have to wait for the previous generation to retire or die before we can get critical mass on the next idea. - Douglas Crockford
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!
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 ;)
I guess your milage may vary though depending on what you're doing etc.
The only reason why this is becoming more of a "thing" nowadays, at least on blogs and in the media, is because the idea of creating a web application that actually does stuff entirely with JavaScript is a relatively new idea, at least in practice on a grand scale. As a job, many web developers (myself included) use JavaScript only when absolutely necessary, and it's really just to make things "look nice". At work, JavaScript is not the thing that drives our entire application (in fact we have more than a few tests that ensure our apps' critical functions work even when JavaScript is disabled in the browser). But I've been experimenting with Ember, Electron, et. al., and it's pretty cool what you can do nowadays with JS alone. These new toolchains have brought and will continue to allow entirely new genres of web applications to be developed with ease, meaning my job gets a little more interesting. We'll probably always have/need CRUD apps, but as a web developer, your fate is no longer sealed in writing CRUD apps for the rest of your life. That's pretty neat!
No it isn't. This was written nearly 15 years ago: https://bitbucket.org/BerislavLopac/waexplorer
Some applications necessitate more sophisticated user interactions.
And you are claim that your way is simpler? To me all the thing that you rant about are just different. If things with the web rendering would started with the front-end instead the back-end, then you would be ranting the same stuff on the opposite side and you would be saying that SPA are simpler.
* 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.
Not really. While your points are all true, the two biggest factors that you can't really escape are 1) your SPA is still a 1 MB download 2) eval'ing 1 MB of JS before rendering is still slower than serving HTML.
SPAs are a better experience, but they're still slower than conventional pages, and I wouldn't recommend their use on high traffic areas of your site, like the landing page.
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.
Same case with blog posts. Sites like HN would not even exist if everyone published all their posts in SPAs.
I figured out I could built simple CRUDS in minutes (literally) using scaffolding, and may a couple hours of editing for special cases.
But I got bored, and went to look for what I could do differently. How to make it "smoother". I'm sure scaffolding and quickly generating CRUD with SPA's will happen soon enough and we will move on to something like "pure browser functions" using links and changing pages statefully.
> It’s reasonable to assume "foo bar and hello world" will compile to either:
> foo(bar) && hello(world)
> foo(bar && hello(world))
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.
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
[2]https://github.com/jashkenas/coffee-script/commit/7f1088054c...
note I'm being deliberately provocative with the above statement to promote discussion, not argument. :-)
* 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 :-)
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.
Coming from many years of python development, coffeescript is a natural fit...
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.
You can benefit immoderately from compiling your existing codebase in TS; you'll probably discover some bugs, even before adding any annotations.
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.
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!
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.
Unlike C++ templates, generics in TypeScript are really simple - I'd estimate it would only take a week to get used to them.
If you just want to write a site while using a bunch of libraries, it might be useful to use VSCode, which provides autocomplete for normal JS code, as long as at least parts of the code have typescript bindings.
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
));
});
});
});
}
}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.
));
}); // I
}); // love
}); // TypeScript
}
}
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'
This makes huge difference when you write async code and no amount of TypeScript can really help it.
let some_func = callback => callback(new Error('boom'));
let some_func = err => console.log(err || 'everything is fine'); let some_func = (callback) => callback(new Error('boom'))
let some_other_func = (err) => console.log(err || 'everything is fine')
let some_func = co(function*() {
try {
const someData = yield asyncRequest(some_url);
console.log('asyncRequest resolved with %j', someData)
}
catch(e) {
console.log('asyncRequest rejected with %j', e);
}
});[0]: http://flowtype.org/
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...
* 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 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.
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.
But except that, typescript has some catch up to do in terms of typesystem with Flow.
You can use TypeScript with --target es6 and then use babel as a secondary transpiler.
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.
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.
http://www.typescriptlang.org/Handbook#writing-dts-files
Will your third-party-lib that doesn't use Typescript keep a dts file? Who knows...
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.
For me this was one of the greatest lessons of Clean Code by Bob Martin, in my opinion a wonderful book which completely changed and dramatically improved the way I write code. By improvement I mean simply the ease with which I can understand and modify my own code months after writing it/ seeing it last.
There's a slight contradiction here with another great lesson of that book though which is short code (by lines) > longer code simply because it's easier to consume in a single glance. There's certainly a delicate balance at play here.
It's a great thing to break down a complex process into steps, naming those steps as you go, and storing things in variables achieves that. However sometimes a better tool, and again another frequent suggestion in Clean Code (really, all credit to Bob Martin for all these ideas) is to instead break the steps into clearly-named functions, if this is possible. Chaining or nesting a series of function calls, depending on the language, can be more readable still than the variables approach and at the same time more concise.
Another great tool for the belt and one of the reasons I have come to always prefer programming in a functional style vs a more stateful, OO style, where I can (even within pretty OO languages such as Java - though the lambdas in 8 have greatly improved the ease with which this can be done).
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.
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;
}> Although Coffeescript is worse than most, any language will allow you to write expressions that are hard for humans to parse
But regardless of the truthiness of this statement, it has no value. It's like saying that no matter what you eat, in large quantities it can cause humans harm. And yet there's a clear distinction between ingesting mercury or lettuce.
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 .The problem isn't "hard to parse", but rather "easy to parse --- in two or more ways".
an example that is clear and consistent, albeit contrived, would be to wrap arguments when there are more than one:
foo bar
foo (bin, bar)
or if that's too "iffy" for you, you just always wrap with parens!
E.g. (foo bar) and (hello world)
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.
You can do 20 layers of callbacks in Haskell without any problem. That's how Haskell does imperative blocks of code (ie monads).
1. most of the analytics/event-stream processing will be done on the backend anyway
2. If you are picky enough you can do functional programming in js. Reative.js is decent library for processing streams of events.
What screams to use something more haskell-like, is their example of 'Trys', i.e:
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
));
});
});
});
}
}
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 : 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));
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].
> 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!
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.
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.
As opposed to what? In what ways do you not consider Javascript to a be a functional language?
* 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.
var a = 1;
a = 2;
window.someGlobal = 'foo';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.
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.
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?
minus a couple of bugs which should be fixed by now.
I was to build the startup front-end with typescript, but then there were too many libraries needing manual wrapping and I didn't want to experiment too much.
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 may have seen this, but if not: http://standardjs.com/
I understand why people might prefer the whitespace but to me the ambiguity and extra technical debt isn't worth the payoff in readability.
I also like semicolons. Especially in javascript.
TypeScript and related make a lot of sense for very large projects/teams because static type checking can be VERY useful, and the lack of a statically typed language choice for in-browser programming is a large weakness of the web ecosystem. So TypeScript is a tremendous advantage to have in the toolkit, and a much saner approach than older heavy-weight options like GWT.
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.
(Also I don't think optional static typing has gotten off the ground in Python land, or adopted in production at Dropbox?)
I used to use Coffee Script, which I still like, but ES6 clearly made Coffee Script less relevant. Typescript value is clearly in the type annotations and the support for ES6 ...
Another problem with Coffee Script is the fact that it evolves way to slowly and it is unlikely to support most of ES6 features because its core maintainers are clearly not interested in adding significant features. In fact that the main issue for me. Both Backbone and Underscore suffer from the same issues.
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.
Better - it removes that ability for deliberate bad behavior by devs.
That said - I prefer JavaScript + Flow as thats a much more native solution which means you don't need to learn a pseudo language first.
- 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.
- Your designers need to change the markup of the invalid form alerts, and you have to point them to a string building function in your JS rather than an HTML template.
- Once they change the string builder, you need to run your unit tests to make sure it still works. If you don't have any way to do dependency injection, writing unit tests of client side code will be difficult.
- Now your presentation logic is split between front and back end. This makes engineering tasks like assessing test coverage and refactoring more difficult.
For some use cases AJAX only may work. When I'm doing a side project that involves a lot of visual stuff and little state management, I'll ditch the MVC framework and task runner and work with just jQuery or D3. But if I'm working on a large project where many other people are contributing, I want a framework that helps me write testable code and provides structure to help keep my concerns separated.
As for the 1MB download, angular is about 100KB minified (most of the space in angular is comments, which contain ALL of its documentation). Angular is also used in so many places that if you pull it from a CDN your users should never have to download it. In my experience, my SPAs themselves rarely outweigh 10-20KB. Worst case: I have to download 120KB of JavaScript and parse it. Still though, I find that AJAX requests to slow backends still take up most of the load time -- meaning that if my app was a conventional one, the page would take a while to appear at all, then load instantly. Of course, with Angular 2, I've heard server-side rendering comes into the picture, making the whole "where should I render my templates" discussion moot.
Sure there's a lot of back and forth and a lot of complexity. But in my experience, many clients and businesses want the kinds of modern touches that only a SPA can give them, and the tooling we have around our code exists to make the task easier, even if it may seem complex at first.
I love PureScript (and Haskell, FWIW), but it's a huge paradigm shift from CS, TS, or JS.
[1]: https://github.com/JuliaLang/julia/commit/28e7bd4536d06a9e13...
class GraphQuery extends Query {
static parse(object: any): Try<GraphQuery> {
return TimeRange.parse(object.over)
.combinedWith(() => Filter.parse(object.where) )
.combinedWith(() => GroupBy.parse(object.by) )
.withCombinedValues((timeRange, filter, groupBy) => {
return new Success(new GraphQuery(filter, groupBy, timeRange));
});
}
}
If the type system requires it for some reason, you could add a `.startCombining()` call at the end of the first line within the method, so that `combinedWith` is sure to be possible.
Only because you know it better...
> - I like the line number in the JS I'm debugging to equal the line in my source code
Source maps.
> - There's less magic to understand & deal with
https://medium.com/@c2c/nodejs-a-quick-optimization-advice-7...
> - CoffeeScript automatically returns the last line of a function, and I don't always like that
Use explicit return then.
I am, of course, the arbiter of what I permit my browser, running on my computer and accessing my data, to do.
How to middle click with an apple mighty mouse with no middle click? Press and hold cmd whilst clicking left click.
Middle click doesn't work and it if you are about to submit a comment on a thread how do you middle click to load the same page at the same scroll position?
You can avoid excessive nesting/flatmapping with some syntax sugar, but it needs to be sufficiently different from normal declarative code.
If you properly define the functions (`c`, `f`, `g`, `t`), you can get the semantics of halted computation on failure. That is essentially what Haskell's `do` notation does.
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.
* pure functions - all you said is equally true for Scheme
* immutability - set-cdr! and many SRFIs: vectors, boxes, records...
* curried by default - nope, not in Scheme either
I mean, it seems pretty useless to define "functional programming language" in a way that includes both C and OCaml just because you can pass functions around in both of them.
It looks close to that, yes. However Flow can be also implemented via comments to native JS so... TS can't do that.
In which case...
> it's just as "native" as JavaScript + Flow annotations
is wrong. TypeScript requires a transpilation step. Flow doesn't. It can do, but it's not required.
I may have been a little harsh with the "pseudo-language" but I'm not sure what else to call something that is designed to be transpiled into the right language. It's not higher-level, it's sort of... a companion language I guess.
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.
Its impossible to have any sort of typed functional programming without generics. Even the most basic of functions, map, has a type:
declare function map<T,U>(a:Array<T>, f: (T) => U):Array<U>
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.
function sum(array) {
return array.reduce((a, b) => a + b);
}
function sum(array) {
let acc = 0;
for(let val of array) {
acc += val;
}
return acc;
} sum = (values) ->
values.reduce (result, x) -> result + x > 3 == "3"
true
> 3 * "3"
9=== does no type coercion. You can also coerce types manually. JS is not statically typed, but it is typed.
> A language is typed if the specification of _every_ operation defines types of data to which the operation is applicable, with the implication that it is not applicable to other types.
For a language to be typed, both the data must have a type and the operations must have a type specification.
> "a" * "b"
NaN
> true / false
Infinity
> setInterval(function(){ console.log("hi") }, "later")
> hi
> hi
> hi
> hi
...
Javascript's type coercion leads to some wacky things like
> [] == []
> false
But it's actually all perfectly consistent once you understand what the compiler is doing with type (and JavaScript is compiled, not interpreted). == is an operator that will always try to coerce its operands to numbers, but the way it gets there can be circuitous.
You can specify type in JavaScript and avoid implicit coercion, you can use type constructors (generally worse) or certain unary operators. Ex:
> var foo = "12"
> var bar = +foo - 5; //+ explicitly converts foo to a number
Javascript is typed, it just makes a lot of crazy decisions about what operations an operator does.
const a = {b: "foo"};
a.b = "bar"; const a = icepick.freeze({b: "foo"});
All a functional language really needs is first class functions. JS has had that since the very beginning.
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.
So its not just naming keys in a structure, those had a very low level meaning related the the implementation of the CONS cell structure in hardware.
[1]: http://www.paulgraham.com/avg.html [2]: http://www.paulgraham.com/pypar.html
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.
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.
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.
I've been on both sides of Haskell hiring. There's more people who want nice Haskell jobs than Haskell jobs advertised these days.
https://mail.haskell.org/mailman/listinfo/haskell-cafe
http://www.haskellers.com/jobs
http://careers.stackoverflow.com/jobs (more general, but I see Haskell jobs here and look for them here)
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.
> 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.
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))
)
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.
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).
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
>&.@:/"1\&&[:
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.