Optional Strong Typing
I haven't personally used it, but you may find that TypeScript provides what you're looking for: www.typescriptlang.org
I'm aware of TypeScript, as well as all of these: jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
But those languages appear to have been created precisely because ECMAScript lacks features like typing. How many of those languages offer strong typing? I count quite a few... Doesn't that say something?
So the defacto response for large scale JS development will always be: Use X?
In general ECMAScript lacks lots of features. You may well ask why it doesn't have any other pet feature, and you can often point to compile-to-JS languages that add those. This doesn't imply that the feature should be added to the language.
Here, let me try:
I'm aware of LispyScript, as well as all of these: jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS.
But those languages appear to have been created precisely because ECMAScript lacks features like lots of parentheses or macros. How many of those languages offer lots of parentheses? I count quite a few... Doesn't that say something?
The existence of a feature in other languages does not imply it should be added to ECMAScript. You'll have to justify better than that why you think strong typing would be valuable to a language that has historically rejected it. (I'll wait for one of the old timers to chime in about the ES4 days here.)
For one, I wouldn't describe strong typing as a "pet feature". Two, no, as far as I know, most of those languages in that list don't offer macros or lots of parentheses; and, if they did, then, yeah, maybe it does say something.
And just to be clear, I'm not asking for run-time type checking or coercion; I'm simply asking that the interpreter not to thrown an error when it encounters something like this: var foo:String;
var foo:String;
That's already a compile-time error (as opposed to runtime.... not sure if that's what you meant by the interpreter throwing an error).
Are you referring to browsers like Chrome that compile the JS first? Then, yeah, I mean it shouldn't throw an error at compile time.
Evolving a language standard used as broadly as ECMAScript takes time. You can see TypeScript as exploring future options for ECMAScript.
Guards [1] may still be added to ECMAScript, I don’t know what the current TC39 opinion is on them.
Lastly, TypeScript tracks JavaScript very closely, I would not consider it a different language.
[1] strawman:guards
I mean it's a parse error that will throw prior to attempting to execute it. For example, consider:
(function() { var foo:String; })
This will throw an error, despite the fact that the function hasn't been invoked. I replied in haste, though... your point is obviously valid for other scenarios. Nonetheless, as a non-authoritative response, you're going to need an argument far more compelling than I can think of to see static typing seriously considered.
@Jeremy: I mean the parser will strip all of the typing info out before it's compiled/interpreted.
@Axel: "Evolving a language standard used as broadly as ECMAScript takes time" -- I agree. "You can see TypeScript as exploring future options for ECMAScript." -- Wasn't AS3 already doing this? "Guards" -- Looks good... "TypeScript tracks JavaScript very closely, I would not consider it a different language." It's compiled, and it's one of many options available, which presents a problem in that if one code base is written in TypeScript, and another in JavaScript++ will they be compatible? Even if the resulting JS is, devs will be required to learn several variants of JS. It's not that this isn't happening elsewhere (libraries written in Java vs C#), but it's been made worse by ECMAScript's lack of key features, which has caused a good many of these languages to appear, and to be used. My point is, if JS was a little more large scale development friendly (like TypeScript), devs could just use plain ol' JS! Sure, some would still use language extensions like TypeScript, but at least it wouldn't be the defacto standard because of core inadequacies in base language.
Has everyone forgotten ES4? Blasts from the past:
brendaneich.com/2007/11/my-media-ajax-keynote
and then
ES4 failed in part because of AS3 namespaces (from original JS2/ES4 namespaces in 1999, also in JScript.NET in 2000, IIRC; inspired by Common Lisp symbol packages), but also because on the Web it's very hard to know when to typecheck. Code loads all the time. Judgments may be invalidated down the road. The "any" type requires runtime checking.
So "strong typing" if it means "what AS3 does" bounced, hard.
The best we have in its place are the compile-to-JS langauges with optional and unsound type If you want warnings, use WarnScript (er, TypeScript or Dart or ...).
If you want standardized warnings, we need lots more developer experience from TypeScript and other languages to get anywhere near a standard. ES8 at the earliest, given our move toward more rapid releases.
If you want a static type system -- which means soundness -- then there are big open research problems to solve.
I mean the parser will strip all of the typing info out before it's
compiled/interpreted.
The implication being that implementors start shipping static compilers where this parsing/stripping takes place (i.e., as a precursory step to being interpreted)?
but it's been made worse by ECMAScript's lack of key features
The problem with this statement is that "key features" is open for interpretation.
if JS was a little more large scale development friendly (like
TypeScript), devs could just use plain ol' JS
The fact is that devs already are building "large scale" projects using plain ol' JS (I myself have worked on JS projects with 100k+ loc without feeling the need for static typing). The same goes for Python, PHP, Ruby, etc. - this isn't an attack against static typing, but it's hardly necessary for a language to be "friendly" for "large scale development".
Sure, some would still use language extensions like TypeScript, but at
least it wouldn't be the defacto standard because of core inadequacies in base language.
I'd be interested in seeing data that the de facto standard is to use compile-to-JavaScript languages. My own experience has been quite the opposite.
Also, unlike other language features, static typing has it's own section in that list; and they're not all in that section: "Some of the ones listed below are also statically typed, such as mobl, GWT, JSIL, NS Basic, and Haxe."
So, yeah, I don't think it qualifies as a "pet feature".
None of this was a problem when plugins were the norm, but now that they appear to be going away, more and more devs have been transitioning over to JS for serious development (games, frameworks, engines..), but JS wasn't ready for this, so all of these other JavaScript like languages crept in to fill the gaps... That's good, but shouldn't that be a short term solution? Also, maybe this was part of the reason why ES4 got a little carried away, but come on, that doesn't mean ECMAScript shouldn't be extended so that it can also support larger scale development.
@Brendan - The typing wouldn't be used at all during run-time. So, unlike AS3, it wouldn't check if types were valid, and it wouldn't try an kind of implicit coercion.
@Jeremy - "The implication being that implementors start shipping static compilers where this parsing/stripping takes place (i.e., as a precursory step to being interpreted)?" --You would probably know better than me. I'm not too sure how the various implementations work, but the idea is to simply ignore all the special typing code.
"The problem with this statement is that "key features" is open for interpretation." --You're right in that it's open for interpretation, but I think we can both agree that there are things that most devs would agree are key features, and most would not, and there are some where it would be a coin flip; but, as there is a JS extension called "TypeScript" (the key feature is in the very name), and there is a section in that list I linked to dedicated to this key feature, I think it's a bit more important than... generics... for instance.
"The fact is that devs already are building "large scale" projects using plain ol' JS" --I prefer to have the option of static typing, because there are definite benefits that are hard to ignore, especially when it's code refactoring time. I'm not saying building large scale projects with untyped code can't be done, or even that loose typing is a bad thing (it's not), but static typing can often make things a whole hell of a lot easier for larger projects with large amounts of developers.
"I'd be interested in seeing data that the de facto standard is to use compile-to-JavaScript languages. My own experience has been quite the opposite." --For large scale/professional development? I think it's the very reason why TypeScript exists, and why Visual Studio supports it. Also, a description given for TypeScript is [1]: "TypeScript is a language for application-scale JavaScript development."
J B wrote:
@Brendan - The typing wouldn't be used at all during run-time. So, unlike AS3, it wouldn't check if types were valid, and it wouldn't try an kind of implicit coercion.
Ok, that's not "typing" (I mean not a type system).
"Those are warnings, but WarnScript was a bad name" - me at JSConf.au last November.
The unsoundness means you have something that needs strong tool support, not just an error or JS console in which to spew. TypeScript got this right.
This again puts unsound warning "types" outside of the standards track for a while. But carry on with TypeScript etc. -- TC39 is tracking.
@Brendan "Those are warnings, but WarnScript was a bad name" --you mean the tools (IDEs, closure compiler, etc) throw warnings, but not the Chrome debugger, for instance, right?
brendaneich.com/2007/11/my-media-ajax-keynote I liked reading this...
esdiscuss/2008-August/006837 This is depressing.
On Fri, Aug 23, 2013 at 1:20 PM, J B <port25 at gmail.com> wrote:
esdiscuss/2008-August/006837 This is depressing.
J B,
You’re entitled to a dissenting opinion. However, this archives one of the best moments for the evolution of the language. It was a commitment to focus on deliberate, consistent, incremental change. We are realizing the rewards for the Harmony agenda today with property descriptors (which formalized and exposed an existing concept), new collections, and Proxies. The cesura on namespaces have provided an opportunity for much much more deliberately designed modules. Innovation has returned and the pace is good, neither hasty nor stagnant.
That said, note that your sentiment has been graciously heard. What you are asking for is well-represented by rigorous research going into TypeScript, which is very closely aligned with work and proposals that came out of these discussions. I believe it is fair to interpret Brendan’s last sentiment, “This again puts unsound warning "types" outside of the standards track for a while. But carry on with TypeScript etc. — TC39 is tracking”, not as “no”, but as “not yet”.
Kris Kowal
TypeScript are a move from Microsoft to become JavaScript more friendly to VisualStudio developers. And to try typed scenarios.
I'm a VisualStudio-developer, and for years, I didn't need typed JavaScript (as I didn't need type Python or Ruby). I feel that is the case with many developers.
I guess the point is:
- Some developers prefer or feel more comfortable with typed system
But the point:
- Typed language allows large systems or something alike
is more debatable. I don't think so, and tons of JavaScript, Ruby, Python programs, libraries, and complete system go against that point.
Having no typing, sometimes is easy to implement some features. In my experience, I had more work and time in writing the same system in typed language than in not-typed ones. And code complexity and refactor, can be managed without pain.
I'm apologize bad English, but I hope I wrote an "clear" argument
Angel "Java" Lopez @ajlopez
"That said, note that your sentiment has been graciously heard. What you are asking for is well-represented by rigorous research going into TypeScript, which is very closely aligned with work and proposals that came out of these discussions. I believe it is fair to interpret Brendan’s last sentiment, “This again puts unsound warning "types" outside of the standards track for a while. But carry on with TypeScript etc. — TC39 is tracking”, not as “no”, but as “not yet”."
Thanks Kris, That's all I wanted to know; I don't have anything remaining to say on the subject.
Thank you.
On Aug 23, 2013, at 1:20 PM, J B <port25 at gmail.com> wrote:
On Fri, Aug 23, 2013 at 2:50 PM, J B <port25 at gmail.com> wrote:
@Brendan "Those are warnings, but WarnScript was a bad name" --you mean the tools (IDEs, closure compiler, etc) throw warnings, but not the Chrome debugger, for instance, right?
The Chrome dev tools (Firefox devtools, etc.) can cope -- but the burning is: will we have more type confusion bugs or fewer if we standardize warning annotations.
Here it pays to recall the benefit of soundness. A type system (sound by definition) will stop code cold, at compile time. Anything like what you propose will possibly let bugs out into the wild.
Whether more or same/fewer that without, I do not know. But I suspect "more", because programmers will have a false sense of security from the "strong typing".
Brendan Eich wrote:
The Chrome dev tools (Firefox devtools, etc.) can cope -- but the burning
question
Le 23/08/2013 19:38, J B a écrit :
So the defacto response for large scale JS development will always be: Use X?
Even if so, why would it be a big deal?
Just to clarify a point, I read interesting definitions of what "weak", "strong", "static" and "dynamic" typing means [1]. Not sure how they are grounded with more formal definitions. Anyway, according to this definition, JavaScript is dynamically strongly typed.
I imagine your question is then "why can't we have optional static typing in JS?". And I'm not entirely sure what the benefits would be for the entire language. Static typing has huge benefits at development time (early errors, errors more meaningful than "undefined is not a function"! Had a 5 week experience with TypeScript on a real-life project that'll ship soon. That made a difference). The downside of JS types is that JS engines will have to verify them and that adds to total runtime cost, especially load time, which we don't need to be slower than it is now (something about a 1000ms time to glass barrier [2]). Just to be clear, the main problem isn't JS engines ability to compile JS with optional static type, but more our practice to load too much code (that will have to be verified before running). Hopefully that trend will change, but the web isn't ready to add another static verification step I believe.
If the JS engine had knowledge of static types, maybe they could go faster (after the slower load time). But how much faster? Current JS engines go really fast after doing type inference when the code is type stable. The interesting part is that the instrumentation/JIT-compilation costs only for long-running code (and not all the code we've loaded! especially not the unused paths!!), but practice shows that the cost is very small compared to the gains it provides.
On a related note, I've recently been asked whether TypeScript compiled more efficient JS (cc'ing Luke Hoban to be sure I'm not spreading misinformation). My answer was that no, it doesn't by itself. TypeScript is very respectful of the input JS (and that's a feature!). However, the JS subset the TypeScript compiler encourages to write to has stable types and has a very strong chance to run faster in current engines.
An interesting approach to static typing is asm.js. The interesting part is that the statically compiled part is very localized (and not whole-language-scoped), so its cost is localized. Brendan suggests [3] that ahead of time compilation can only provide better performance. I wonder what's the cost of the static verification is and how much it hurts load time. I'm especially wondering whether this cost will not hurt performance too much when people will load lots of unnecessary asm.js code (cc'ing Dave Herman in case he has answers on that topic), which is obviously not measured by current benchmarks.
Anyway, whole-language static typing sounds like a bad idea and "use X" seems to be to good way forward. The compile-to-JS battle has just started. Let's be patient.
David
[1] coding.smashingmagazine.com/2013/04/18/introduction-to-programming-type-systems [2] www.youtube.com/watch?v=Il4swGfTOSM [3] www.youtube.com/watch?feature=player_detailpage&v=O83-d0t0Ldw#t=797
Ressurrecting this thread whoo :)
I don't feel static typing making its way to JavaScript. It just wouldn't fit. The core libraries haven't been designed for it, and the community libraries haven't been designated for it. I'd say static typing in JS is a lost cause now. Designing a language for type guarantees takes a far different route than designing a overtly dynamic language — there are plenty of operations in JS whose types that are not even predictable, which often causes JITs to drop optimisations defined for one function or another.
However, guards and contracts are cool. They're run-time type checking, and they'll just work with what we have right now. You won't get a Haskell type system, but you'll get confidence about the inputs where it matters.
That said, you can still try to shoehorn types in JS by way of an external tool or compile-to-JS language. TypeScript takes this route (Dart too, to a point, but it's a watered-down-Strongtalk-for-teh-web, really). You still won't have Haskell's type system, but you'll have a nice design and documentation tool if you design your type system right. You can't achieve much more than this if you're targeting JS, we can't change the language to being Haskell, or ML, or Scala, since we can't break existing code.
To say that types are strictly necessary for "large scale applications," is a bit odd, though, and according to some research about effectiveness of type systems, perhaps also incorrect — but I don't remember the name of the papers, and I'm usually skeptical of such papers on CS.
Eric Meijer I think says it very well in this very interesting paper that I recommend all read here.
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.69.5966&rep=rep1&type=pdf
“In the mother of all papers on scripting [16], John Ousterhout argues that statically typed systems programming languages make code less reusable, more verbose, not more safe, and less expressive than dynamically typed scripting languages. This argument is parroted literally by many proponents of dynamically typed scripting languages. We argue that this is a fallacy and falls into the same category as arguing that the essence of declarative programming is eliminating assignment. Or as John Hughes says [8], it is a logical impossibility to make a language more powerful by omitting features. Defending the fact that delaying all type-checking to runtime is a good thing, is playing ostrich tactics with the fact that errors should be caught as early in the development process as possible”
Sent from Windows Mail
Is there any particular reason my JS doesn't support (optional) AS3 style strong typing? All the typing info would be ignored at run-time, but it would be helpful for compile-time checking, code hinting, and general readability of code. Tools like the closure compiler could even strip out all the typing info, and it wouldn't make any difference at run-time. I'm probably beating a dead horse here, but why?