
Experimental New Directions for Javascript - jashkenas
https://drive.google.com/file/d/0B2p58mpwToefRzlGMzRxTnhNb00/view?usp=sharing
======
breckinloggins
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/](http://www.kythe.io/docs/schema/)

~~~
sanderjd
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
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.

~~~
sanderjd
You misunderstood me. People who use editors that don't have IntelliSense are
the ones accused of living in the past by my parent comment. I think liking
and wanting IntelliSense is incredibly reasonable, but I think that the
perspective that it is _indispensable_ and that people who don't use it are
products of the 80s (or the 60s!) is ridiculous.

~~~
seanmcdirmid
People still drive around without live GPS, many find it distracting and
prefer old fashioned maps or to remember all their routes in their heads.

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.

------
jashkenas

        * 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](https://www.youtube.com/watch?v=pmRAiUPdRjk)

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

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

------
tieTYT
> [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
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.

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

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

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

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

~~~
bcheung
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.

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

~~~
olavk
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.

------
olavk
Mascara Compiler
([http://www.mascaraengine.com/](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

------
pothibo
Love the SaneScript idea, that could be very big.

------
bcheung
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
What if the typing was optional?

~~~
bcheung
I'm down for that.

~~~
seasoup
I'm still not, it's adding complexity in exchange for performance. I prefer
ease of use of the language over performance, JavaScript is fast enough for
most things and is still getting faster without adding complexity for
programmers.

------
jsmadthrow
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?

~~~
jack9
> 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.

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

