Experimental New Directions for Javascript
drive.google.com
drive.google.com
That Microsoft environments are STILL 15 years ahead of the Unix / web world on this (and modulo F# type providers, themselves 15 years behind Genera and SmallTalk) will be recorded in history as one of the tragic ironies of this age.
Give up assuming that all programming must be done on a teletype from the 60's. It's time to move on to at LEAST the Lisp Machines of the 80's. Please??
By the way, for those who didn't understand what Kythe[1] was all about: THIS is what it's all about. It's possible without types, but it's MUCH better with them.
See also https://srclib.org/, a library with similar goals to Kythe supporting a different set of initial languages (including JavaScript, Python, Ruby, Java, Haskell, and Go) with editor plugin support for Emacs, Sublime, and Atom. (Disclaimer: I'm one of the authors.) The dynamic languages, and JavaScript in particular, are hard to support well. Libraries like tern.js make it doable, but life would be much easier with stronger static guarantees from the language itself. For now, it's a very hard problem, but there is so much to gain from Intellisense-level tooling around JS.
What I'm hoping for is a "decoupling layer" that allows every text editor, IDE, and other code tool on the planet to hook into one end, and every language, compiler, interpreter, etc. to hook into the other. If I'm writing a new language (which, of course, I am) I know how important tooling is. But I don't use vim or Emacs so I personally don't care about vim or Emacs. Sublime Text maybe. It would be nice if I could upload a thing somewhere for my language and suddenly GitHub gets syntax highlighting for it and every editor and IDE in the world suddenly supports all the IntelliSense-like things for it. But we don't do it that way. Each of us has to re-invent 18 wheels.
Needless to say, I hope approaches like yours and Kythe succeed. Then we can focus on the obvious utility of adding more metadata to our programs.
PyCharm even does a great job for dynamically typed Python, relying on type annotations, run time logs, etc.
IntelliSense isn't even close to the coolest thing about good type systems. What's cool about them is catching dumb errors and contract violations statically and reducing the number of unit tests that it takes to feel confident in a piece of software.
Kythe is a really great project, though.
I don't see how wanting it is "living in the past" - because we certainly don't have it - not on Linux - in the present.
Having code completion allows you to work with bigger APIs in an ad hoc manner (discover Inge as you go). You don't need that, but it is nice. There are other factors that can improve the experience, which you have to look at holistically.
* SoundScript (Google)
* SaneScript (Google)
* TypeScript (Microsoft)
* ECMAScript 4 (Dead)
* AtScript (Google)
* Flow (Facebook)
* Closure Compiler Strict Mode (Google)
* Asm.js (Mozilla)
* Dart (Google)
* PureScript (OSS)
* Dependent JavaScript (Mozilla + Microsoft)
Ah, I would love this. I have a small, thoroughly tested JS app (15k+ lines of code) but the biggest pain in the butt to debug is, "how did this 'undefined' get here?" I wish there was a way to fail early without putting tons of guard clauses everywhere.
"Fail early" (and loudly!) ought to be design goals for all programming languages IMO.
I think TypeScript et al provide the needed type safety (until ES6 is fully supported) I'm just not sure we need a new "the good parts only" language. Didn't Google already try to do that with Dart?, I think Dart is great, but it still long way to go.
There a tons of bad things you can do with any language, Java, Scala, Ruby, Python that people don't do anymore and any automated style check / lint will fail. You don't go and remove parts from the language, you just have a good style check / lint plugin. I mean, you can use "go to" in the form of break to label in Java, but I don't see anyone using it much. This is very interesting, but I'm not sure it will get a lot of traction (mostly due to the need to rewrite huge parts of your code as they won't compile, vs gradually fixing your code using lint warnings). Am I missing something?
p.s. took me a minute to realize who is the OP (Jeremy Ashkenas of Backbone and CoffeeScript fame), I would love to hear your opinion on this, I highly respect it!
No doubt this is an evolution of Google Closure, which you might call a "very smart" linter. As the author of the O'Reilly book put it, If JSLint will hurt your feelings, Closure will put you into therapy.
1. JS has various annoying parts, like how comparisons work, or that x.y returns undefined if y isn't a property, etc.
2. JS is sometimes hard to optimize to Java-like speed.
I think (1) is already well underway to being solved, through compiling to JS. Things like TypeScript, CoffeeScript, ClojureScript, Elm, Scala.js, GWT, JSIL, Emscripten, etc. Those let you compile whatever language you want, without all the JS oddities. You can use anything from a familiar language like Java or C# or C++ or Scala, to an almost-JS language like TypeScript. People aren't really limited by JavaScript's oddities anymore.
It's true these languages sometimes have downsides when compiled, e.g. due to limitations on debugging. But progress is being made there and things are pretty good already.
(2) is indeed something also worth solving. But I'm not sure the solution is the same solution, so trying to fix both at once sounds far, far riskier. For example, a lower-risk way to help with the perf issues might be work piece by piece, perhaps starting by proposing a hole-less array type for JavaScript, to avoid the sparse array problem.
- non-nullable types
- proper scoping (no use before declare, block scope)
- optional and rest arguments
- calling with too few arguments is flagged by compiler
- "this:" parameter
- Function types are contravariant
- classes, interfacesParsing JSON to a hash is especially problematic in typed languages. Often they force you to create a class that maps from the JSON to a class. This is extremely tedious and wastes time. Also, if the JSON can change dynamically then you are screwed as it can't be mapped to a class anymore.
If you want type safety there are plenty of means to do this in a language that compiles to Javascript or some kind of linting step.
Please don't turn Javascript into Java.
1: http://en.wikipedia.org/wiki/ActionScript#ActionScript_3.0
I'm not the best programmer out-there but when I started learning Python this blog-post had a pretty big effect on me: "Python Is Not Java" (http://dirtsimple.org/2004/12/python-is-not-java.html) , I remember referencing it in one of my first job interviews and actually getting hired.
It may sound crazy to a lot of people in here from this day and age when types are all the rage, but there was a time not that long ago when dynamic languages came as a huge (I mean huge) breath of fresh air. Without languages like PHP, Ruby, Python and JavaScript we wouldn't probably have this conversation in here, but on an ASP- or Struts-based forum thingie that would cost money to join and would be filled with horrendous ads (think ExpertsExchange or whatever the name of that website was).
But today the breath of fresh air is powerful type systems and type inference which provides the benefit of typing without the syntactic overhead.
Even if you don't add any type annotations yourself, you'll still benefit from the annotated libraries and from type inference.
To get almost all of the tooling benefits, you only have to annotate arguments and the return value. That's it. Inside your functions you generally can omit them because there are enough types floating around. Literals have a type and if you call an annotated function, you also know what type you get back.
E.g. this function is fully typed (none of the variables is purple):
Do you even get javascript? And the beauty and ease of coding in it?
JS is amazing because of two things:
1. VAR - yes var. it's 2015 and yet you want me to waste my time typing in useless int, float, char. Really? But wait! now that you have wasted hours adding useless types to your code, you can benefit from our IDE that will tell you where you missed one! So you see, we actually saved your ass!
2. JSON, and everything is an object. Instead of creating 20 functions, a single function(x) can handle multiple cases with flow enhancement.
x is an array. x[0] is a number, x[1] is an optional object, x[2] is a freaking function. all dynamically changeable.
f([1]), f([2, {}]), f([3, {}, callback]). you want to add another flow? no problem, extend your array or just set a property on the object, js serves you, you are the master.
--
instead what we get? 'too few arguments throws'; typeof D < {new(x:T):D, s(x:T):U, ...C’s...}. WTF is that? Does that look like sound coherent code to you?
• `var` is replaced by `let`, but it works mostly the same in sane situations. It's merely a bugfix for warts in `var`. It has nothing to do with static type declarations.
• Types are optional. JSON is still allowed. For a bag of properties `Map` is suggested, since it doesn't have some of the quirks of using `Object` as a map.
And the WTF is not a suggested syntax but an explanation of the type system in a more formal notation.
Most programmers disagree. Get over the fact that you are in the minority and JS has succeeded DESPITE the massive barrier to entry (beyond the simplest of tasks) and the monumentally messy spaghetti code that javascript (as a prototypical language) inevitably becomes, in larger projects.
The ideas in the article are terrible. It does not look remotely interesting. I read these slides and think, this is someone that doesn't like JavaScript and is trying to make it more like languages they enjoy, like Java. Trying to eek out every performance improvement possible by removing developer friendly features is not a good idea.
"let" scoping is a terrible idea, it is not at all sane. Functional scoping is clean and simple, there is only one thing that scopes variables, functions. Thats it. Easy. Block level scoping will introduce coding nightmares trying to figure out what scope your variable is in. I can just imagine the nightmare code people are going to write interspersed with both var and let, and having to figure out how the variable was declared to know its scoping rules. GAH. Not having to tell the compiler what kind of variable you are trying to use makes coding so much simpler. Not having to cast variables manually is a godsend. And this is considered a good thing to take away?
Reading further into this presentation, it's clear that the developer wants JavaScript to be Java. any<T>...? No no no no no no no.
Keep classes away from JS, unneeded complexity. Classes are inherently complex compared to the simplicity of prototypes. Classes sound like such a good idea, until you are knee deep in the inheritance chain trying to figure out where some method or attribute is defined and/or overwritten. They are one of the biggest reasons people need to use an IDE to write code.
Just learn JavaScript, guys. It'a a really simple language, just not like the ones you learned in university.
I almost suspect you are trolling here. The variable is in scope inside the block in which it is declared. What could be simpler? With JavaScripts function-scoping, you can declare a variable inside a nested block, but it is still in scope outside and even before it is declared! And if you forget the "var" it is suddenly a global variable.
But adding a block level variable declaration just adds to the complexity of the language and doesn't add any real additional capabilities. It adds some nice fluff around loops and asynch operations, but that is all easily done using current scoping rules once you understand closures.
var is still going to be around, but now we've added let. you might like let's scoping rules better then var's scoping rules, but now we'll have both. the interaction between the two is going to have some amazingly confusing and complex edge cases. If you think that hoisting and closures are confusing now, just wait until let is thrown into the mix as well. Even if let is simpler, var isn't going away. So we're just adding complexity to the system.
var foo = "abc";
function do ( foo ) { foo = "def"; console.log( foo );
let foo = "bar";
console.log( foo );
var foo = "baz";
console.log( foo );And of course var has to be around for backwards compatibility, but if the addition of let is being made to make variable declaration more intuitive or simpler then it is failing because var must be included. You cannot consider let in isolation and when considered in combination with var, it makes things more complicated.
I guess you are right that the language is getting more complex because you are introducing a new way of declaring variables. However the added complexity in the language means you can write code which is less complex and error prone (if you consistently use 'let' instead of 'var'), and I think this is a fair trade-off given that backwards compatibility must be preserved.
Types are optional and they can be also inferred.