Experimental New Directions for Javascript

https://drive.google.com/file/d/0B2p58mpwToefRzlGMzRxTnhNb00/view?usp=sharing

by jashkenas • 11 years ago

54 53 11 years ago

drive.google.com

pothibo• 11 years ago

Love the SaneScript idea, that could be very big.

eranation• 11 years ago

I am all for recreating JavaScript the way it should have been, but aren't the problems this tries to solve solvable with a good linter? (perhaps a very smart one, on the verge of a compiler, but still a linter)

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!

gavinpc• 11 years ago

a good linter

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.

jashkenas• 11 years ago

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

Welcome to the Typed JavaScript Thunderdome! Ten contenders enter, one JS leaves!

https://www.youtube.com/watch?v=pmRAiUPdRjk

pests• 11 years ago

Asm.js is just standard JS that happens to conform to Mozilla's performance guarantees.

TazeTSchnitzel• 11 years ago

Indeed, and it benefits from ES6 stuff which was added for asm.js's sake.

adamvalve• 11 years ago

http://xkcd.com/927/

_random_2• 11 years ago

Google consists of openly competing departments as far as I understand? Java vs Go vs Dart vs Python vs AtScript vs Sane/Sound/Script. They are either non-general-purpose (DSL) or competing.

mappu• 11 years ago

You forgot

    * Dependent JavaScript (Mozilla + Microsoft)

http://cseweb.ucsd.edu/~rchugh/research/nested/djs.pdf https://github.com/ravichugh/djs

breckinloggins2• 11 years ago

Programming language researchers always seem to miss the biggest selling point of manifest and (partly-)nominal typing. It's the thing that happens after a C# programmer types a "." in Visual Studio. Want someone to use a single language and voluntarily turn the play-doh of a prototype into a sound concrete foundation via gradual typing? Tell them they will get full IntelliSense.

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.

[1] http://www.kythe.io/docs/schema/

beliu• 11 years ago

This is a great point. The quality of the tooling around a given language/ecosystem has a huge impact on the productivity of people working in that ecosystem.

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.

breckinloggins2• 11 years ago

That's awesome!

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.

murbard2• 11 years ago

I agree with you on the sentiment, but note that Jetbrains products run great on Linux and do a lot more magic than IntelliSense.

PyCharm even does a great job for dynamically typed Python, relying on type annotations, run time logs, etc.

sanderjd3• 11 years ago

I like IntelliSense and its just-as-good brethren mostly in Java-focused IDEs, but my perspective is that it's a valuable but small bonus, rather than anything like a 15-year leap of progress. It's nice, but it just isn't that important, and it's very annoying when people act like if you don't see it as some sort of Best. Feature. Ever. you're living in the past.

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.

XorNot• 11 years ago

Intellisense is an amazing friction reducer for good APIs though. Having something pop up, give you the exact spelling, what's available, and the parameter names, massively reduces the learning curve.

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.

ep103• 11 years ago

I'm so tired of these "Why can't JavaScript be just like my favorite static-ly typed language" conversations. Leave my javascript alone please.

Zikes• 11 years ago

I think the issue is that it's literally the only option for web development. If there were a common bytecode that multiple languages could compile to so that everyone could use whatever language they preferred, that would be ideal.

bcheung4• 11 years ago

You can always create your own language that compiles to Javascript. There are multiple examples of this with languages that have type safety. With the Mozilla Parser API this becomes really easy.

sanderjd3• 11 years ago

This is all purely opt-in and compatible with "your javascript".

transfire• 11 years ago

Seems that Javascript was named appropriately after all. With a few more iterations it will be Java.

bobajeff• 11 years ago

If I understand this correctly SaneScript is like asm.js in that it's a subset of JavaScript but rather being intended for compilers it's intended for humans so that JS engines can start to remove the insane parts of the language and transition it be SoundScript which is not to be compatible with JavaScript.

olavk8• 11 years ago

SaneScript is AFAICT like the "use strict" directive in ES5 which defines a restricted subset of the language. Compilers might also take advantage of this by performing certain optimizations. SoundScript extends this restricted subset. It is incompatible with previous versions of JavaScript only in the same sense that ES5 is incompatible with ES3: It introduces new features not supported by older engines.

bcheung4• 11 years ago

If I wanted a typed language I would use Java. Dynamic languages allow me to get the job done faster. It is extremely rare that I run into any issues regarding type. Every typed / object oriented language I have used so far forces me to jump through hoops to get at my data and I find myself needing to create way too many objects. I want to work with data, not objects, not types.

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

Bahamut• 11 years ago

What if the typing was optional?

bcheung4• 11 years ago

I'm down for that.

enobrev• 11 years ago

That's what I loved about the [basically] now-deceased Actionscript 3 [1]. It was an optionally typed Javascript with compile-time and runtime checking, packages, and namespaces. It was an absolute pleasure to code with. I would generally start my prototypes untyped to get something running quickly as a throwaway, and then rewrite strictly typed as I better understood the problem. I was very happy to ditch Flash years ago, but I would have loved to have AS3 replace Javascript.

1: http://en.wikipedia.org/wiki/ActionScript#ActionScript_3.0

detaro• 11 years ago

Have you ever tried OCaml?

olavk8• 11 years ago

They are suggesting adding optional explicit typing to JavaScript. This will not impede your ability to use untyped dynamic JSON. But it allows you to take advantage of explicit typing where it adds value.

paganel• 11 years ago

Please don't turn Javascript into Java.

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

olavk8• 11 years ago

Dynamic languages was a breath of fresh air compared to the clunky explicit typing of Java. The first versions of Java didn't even have generic, so just using collections required lots of explicit casting to make the compiler happy for little benefit.

But today the breath of fresh air is powerful type systems and type inference which provides the benefit of typing without the syntactic overhead.

ahoge2• 11 years ago

Please don't dismiss optional typing without trying it first.

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

http://i.imgur.com/xHWlJVn.png

bcheung4• 11 years ago

I'm not dismissing optional typing at all. I'm completely for that. I have used it in JS when performance is needed when dealing with large data sets. It's forced static typing that I am against.

jsmadthrow• 11 years ago

Why do people keep on trying to fuck up Javascript? I don't want your shit OOP and classes, take them back.

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?

pornel• 11 years ago

It looks like you didn't fully understand what the presentation is about.

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

tacos• 11 years ago

Not even C++ requires you to type a "useless float or char" ahead of a variable any more. But declaring something before using it offers a number of benefits with a JIT compiler in a VM. If you choose to use it, it's available. In this case, you can have it both ways.

_random_2• 11 years ago

How can you f..k up something that is screwed up from the start? Oh, the beauty: http://wtfjs.com

jack9• 11 years ago

I don't want your shit OOP and classes, take them back.

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.

seanmcdirmid2• 11 years ago

Prototypes are also OOP by the 1988 Treaty of Orlando, so we are just arguing about one kind of OOP vs. another.

seasoup4• 11 years ago

Yes. This.

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.

olavk8• 11 years ago

Block level scoping will introduce coding nightmares trying to figure out what scope your variable is in.

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.

ahoge2• 11 years ago

This function is fully typed: http://i.imgur.com/xHWlJVn.png

Types are optional and they can be also inferred.

olavk8• 11 years ago

Mascara Compiler (http://www.mascaraengine.com/) supports many of these features already:

  - 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, interfaces

azakai• 11 years ago

I think the motivations here are noble, but what troubles me is that this is trying to fix two problems with one big risky hammer. The problems are

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.

tieTYT• 11 years ago

[SaneScript] Accessing missing properties throws (on both reads & writes)

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.

peterashford• 11 years ago

I hear ya. One of my greatest frustrations with reading "Javascript: the good parts" is where Crockford dismisses the legions of faults with Javascript as 'things that never happen to him anyway". Well in my bloody world, these JS faults go undetected in production code, causes days lost to debugging, cause customer complaints etc...

"Fail early" (and loudly!) ought to be design goals for all programming languages IMO.

Experimental New Directions for Javascript

Related Stories