jwz finally learns some JS and picks at an old scab that had almost healed. I reply in various comments. I include some little-known, kind-of-funny (not always ha-ha funny) history along the way to set several records straight.
The issue before us now is whether to add value types to JS, perhaps by extending proxies, so you can implement non-reference-semantics objects with operators (because without operators, what’s the point?); or just add bignums; or do nothing.
Comments welcome (to keep up with Akismet-gaming spammers — anyone have a better WP plugin to stop comment spam?).
/be
To improve comments (and spam): https://wordpress.org/extend/plugins/disqus-comment-system/
Huh, to improve Brendan’s comments he should rely on a third party’s centralised system for storing them? Impressive thinking.
Yes to value types, yes to removing what people see as bugs in the implementation.
If javascript gained an optional static type system like proposed for javascript 2 over 10 years ago, I wonder if that would let us fix the problem ourselves – such as the jsdocs / closure compiler one: https://docs.google.com/document/edit?id=1L6g92j9Z-w3uvDP0H-0whb2fOcwnjiXRY8pbG9LkOvQ&hl=en#
Doug: we tried for years, in two sustained efforts, to get JS2 through the committee, and really, to get it completed so it was self-consistent and usable. We (Waldemar Horwat, the Macromedia guys, some top Opera language guys, and very smart Mozillans I dragged along) failed.
There were many reasons why we failed, but politics was not really the main one in my opinion.
If we get optional *non-static* types, I’ll be surprised. Static on the web? No way — when do you run the type-checker? How do you interface untyped and typed code efficiently? These are hard “gradual typing” problems in the research world.
Anyway, purely dynamic value types with operators are relatively easy to do (double-dispatch, some rules for hashing and identity), so this is the likeliest outcome for an extensible system. But bignums could be hardcoded even more quickly.
/be
Who needs bignums in a world where integers overfloat into ℝ…? 😉
Doug: Brendan’s right on static types. I’m more sanguine about gradual typing, but that’s not an out on this either since that alone doesn’t address a lot of the usability issues that add complexity: operator overloading, precision decisions on casting, and performance. It’s little use having bignums if you can’t use them ’cause they’re too slow. Same for fixed storage classes for other numeric-ish types that need to be passed to hardware (GPU operations come to mind). Most of this stuff should be made to work in the standard library ASAP so that when good type descriptions come along, they can just be re-interpreted in terms of them.
Bonzo: IEEE double is not R!
Alex: so value types, then? Cuz without operators and literals there is no usability, and bignum libraries see use only when there’s a hard need (for GWT, Skulpt, and other languages hosted on JS; or perhaps for serious CryptoHeads).
/be
Alex: gradual typing is static typing, it just allows you to leave parts of the program untyped. What did you mean by gradual typing?
Anyone: Static types are hard to fit into the web, as Brendan says, both because any kind of non-trivial validation process hurts performance and because it’s not clear that significant up-front validation helps the user in any meaningful way (it’s already deployed, after all). Here’s my question: is there room for an explicit type system that could both a) be ignored at runtime, with the same dynamic behavior of existing JS, and b) statically checked in a development environment (say, an IDE, or even better, a browser in “development mode” with a useful developer’s console), with meaningful guarantees?
I ask this not because I have a concrete solution in my back pocket, but because there are languages that provide this kind of feature (see e.g.: https://docs.racket-lang.org/ts-guide/) to good effect, and I believe we need better web development tools integrated into our browsers.
Dave
@bga_ is doing pretty impressive tests and benchmarks with recently introduced typed Arrays ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html ) and I have already said this is in my opinion the way to go. Number in JS are “too much magic” and following typed array approach I wonder what could go wrong if JS introduces the same concept without the “Array” suffix: Int8, Uint8, Int16, Uint16, Int32, Uint32, Float32, Float64
All these constructors may be downgraded for backward compatibility via constructors able to cast manually on creation time ( without ensuring anything after, but that would be eventually just our fault ) and engines can easily represent these types adding “setter” scope/property logic rather than just index as is right now for TypedArray.
Delirium, nonsense, WTFs? Well, this is just an idea, I am already happy with repeated TypedArray index access to perform typed numbers operations when WebGL is in the house 😀
Regards,
WebReflection
Id like the current JS number to stay as it is. I think for the most part more types of numbers will just add complexity. Double may have its quirks but the current system has advantages in its simplicity.
You don’t have to cast all the time ( this is a breath of fresh air coming from the horribly verbose c# and as3 which is apparently an improvement over JS ).
Thinking about different types of numbers takes you away from the problem domain. Although from a technical point of view having more types of numbers to choose from puts more tools in your tool box to help you solve the problem, In practice It gives you a lot more decisions to worry about. You have to make an extra decision every time you create a number and every time you convert between one type of number to another as well as learning and thinking about the technical nuances in both the language specification itself and different browser implementations. This is time where you have to shift your focus away from the actual problem you are tying to solve to think about more complex language features.
For me having just one number is simple and powerful.
Abe, I was proposing the same, leave Number as is, eventually add other type of Numbers. We are not all idiots in JS world, somebody “may be able to use an Int32” when meant … and I prefer more power and control, rather than more slower magic behind the scene. If we have choice, as it is already with typed Arrays that are available right now, we can decide how to make things faster.
Regards
@Andrea: Except your code is not you — you may have intentions, but your code does not. This has always been the problem with code written for performance: it depends on a slew of subtle interpretations and hacky restrictions about what will run fast on today’s machines. But tomorrow’s machines may run things faster and perhaps very differently. Did you mean “integer” when you typed Int32? Or would the set of reals be OK, were it not for performance. If your code better reflects *your intentions* (in this case, Number, not Int32) then your code can function in many more contexts — many that not even you can imagine. And other people who have to read your code can spend less time wondering whether, by Int32, you meant something magical, or you just meant ‘number’.
I’d rather people get into the habit of writing correct, general code that lasts long into the future as opposed to cute code that’s fast but has limited reusability and that fossilizes the Javascript engine because it *absolutely has* to be backwards compatible with it. Of course, in some cases (i.e. WebGL and critical high performance cases) you haven’t got a choice. But those cases are set well apart from Javascript proper and shrink as each year passes. (And if I start seeing TypedArrays show up in code that just adds a couple of numbers together a handful of times, I’m going to get very grumpy!)
I would hope that first a captcha would be used. For those that don’t want to deal with a captcha, a log-in system into brendaneich.com could be provided. I think the Disqus approach is a little excessive and cumbersome to use (textbox expansion being one). I would rather IntenseDebate as I don’t think it provides analytics but regardless a centralized comment system of the web I believe would limit who could comment on your blog since people are protective of their privacy. With connections between comments being made by commercial interests some may choose to use an anonymous alias but still contribute to a discussion, possibly solving problems that otherwise wouldn’t be solved.
I stumbled on this, it’s a plug-in/extension for Thunderbird (seems client-side). This isn’t for blog posts but you might be able to use this for the Thunderbird accounts thing you guys are working on, maybe bundling it with TB if the user is using a TB account. Goodluck. 🙂
https://spambayes.sourceforge.net/
Hi Brendan,
In a previous post you mentioned the “concurrency vs. code simplicity trade-off is in general a false dilemma”. Do you mind talking more about that? Or pointing me towards where the discussion is happening?
Cheers.
Ted: callbacks in a single-threaded program mean manual continuation passing style, which JS wins at by its closures: you can carry along state in the callback’s environment.
It’s possible to entrain a lot of memory this way of course. Worse, it still adds overhead to your code and thought processes, compared to writing shared-nothing threaded code. But shared-nothing has other costs, as do OS threads.
The lighter-weight green threads, aka fibers, called “tasks” in Rust, are a “third way” between callbacks and full threads. The Asana guys blogged about this recently:
https://asana.com/blog/?p=49
/be
Off Topic: Maybe Mozilla might want to look at Coverity or others for Static Analysis. Not sure if it fits the bill but I wouldn’t know if you’ve heard of it before. I hope it helps.
https://gsoc-wiki.osuosl.org/index.php/Static_Code_Analysis
Andreas Schiffler was at GSOC for SDL and wrote the sdl-gfx library. The session was about using the different tools for static code anaysis such as Coverity and others.
Also are you guys going to change how when you install another version of Firefox “over the top” but without deleting the other one it still points the default profile? I’ve seen bloggers not realize this and it affected the beta and they were surprised something was conflicting. If Mozilla could solve this problem before version 4 hits I’m sure everthing will go smoothly in the transition.
Anonymous, have you read these posts?
https://brendaneich.com/2005/01/assertions-should-be-fatal/
https://brendaneich.com/2006/10/mozilla-2/
https://brendaneich.com/2006/11/oink-based-patch-generation/
We have been investing profitably in static analysis for almost six years. See also the coverity keyword in bugzilla: https://bit.ly/9VcvUX
On the profile thing, bsmedberg says works as designed. If you see a bug, please file it.
/be