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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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):
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.
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?
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.
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.
> 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.
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.
> 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.
Sure, forgetting the var causing a global variable is a problem, and I'd have no problem with removing variable hoisting and requiring all vars to be declared at the top of the function, it's what I do anyway.
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.
I don't really see any edge cases in the interaction between let and var, can you provide an example? But yeah, using both var and let in the same function would be ugly. Probably you would want to stick with let in new code since there is no benefit to var over let. But obviously var has to remain in the language for backwards compatibility.
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 would assume you get a compile-time error because you are declaring 'foo' twice.
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.
- 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
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.
> [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.
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.
53 comments
[ 2.7 ms ] story [ 115 ms ] threadI 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.
https://www.youtube.com/watch?v=pmRAiUPdRjk
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/
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.
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.
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):
http://i.imgur.com/xHWlJVn.png
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 );
} console.log( foo ); do( foo ); 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.
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.
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.