Pretty neat. Mirah is to Java as CoffeeScript is to JavaScript?
Looks very similar to ActionScript 2, with shades of Scala. Really neat looking language.
Anyone know where the `param: Type` (i.e., parameter name colon type) convention came from? I've seen it more frequently lately, and I wonder if it's easier to parse than Java's `Type param` (or my favorite: `param Type`)?
I actually officially asked Jeremy Askenas if I can use the phrase "Mirah is the Coffeescript of Java". He gave me his blessing.
The param:type notation I largely just stole from Scala, but it seems (in my novice opinion) easier to parse as well. It also fits better with optional type declarations, which we have in the case of interface impl or class extension (easier to omit syntax on the RHS than on the LHS for a typical parser).
I'm not sure if it's where the 'param: Type' idiom is where it came from originally, but its use in Mirah almost certainly descended from its use in Haskell and ML. Scala also uses it, and its use there is definitely ML/Haskell-inspired. (Haskell technically is 'param :: Type', since ':' is the cons operator, but it's basically the same thing.)
Since languages like Haskell and ML (and Scala, to a lesser extent) do type inference, type annotations are often unnecessary, and so having the type listed after the name probably makes more sense in that context: what's important is the name, and variable-specific type hints are usually there for the compiler, not the human reader. The exception is functions, which very often get type definitions just because it's very helpful to have that information as a human. Since ML/Haskell-like languages have multiple function definitions and rely on pattern matching, the postfix type notation fits in very well:
Pascal uses the "param : type" syntax, although I'm not sure it's the first language to do so. I believe it's older than ML. It's funny to "see this more frequently lately" as it's a really old convention. What's old is new again, I guess...
ML type annotations use that syntax, so it's probably the grandaddy of them all.
It's easier to parse if your type syntax uses juxtaposition. "Some int" is a valid type, so it would make "<type> <var>" harder to parse. It's hard to tell when the type ends and the variable name starts without backtracking.
It's common in statically typed functional languages and an old notation. I believe a key motivation is the analogy between a Set and a Type. Then saying x : Int is like similar to saying x ∈ Z, x is an element of the integers.
That would be my bet, especially since Java, especially since 1.1, reminded me so much of [Turbo] Pascal in C++ clothing, so it only seems natural to borrow another Pascal-ism.
But Pascal stole from Algol. Nothing new under the sun...
I think you approached this article with a different set of expectations than I had. It felt like a personal essay early on for me. I don't think it's meant to be an empirical distillation of the ways in which a few cultures are different from one another. I found it to be elucidating in the way that a standup comic might be (I recognize the pattern, but never thought of it concretely; e.g., 'Guys always leave the seat up.') Maybe you have a more broad exposure to different cultures than I have.
A wiki on cultural differences is a really good idea, though.
I expect to burn some karma for this, but there's another extant pocket of optimization driven development: banner ads. If there is such a thing as a "good" banner ad, I'm referring to those (unobtrusive, non-autoexpanding, subtle animations resulting from interaction [no seizure-inducing manic blinking]). Good banner ads use almost no bandwidth (15k-40k) and go easy on the user's processor. They are built for big companies who care about their reputation and trafficked by platforms that respect the user.
I don't get to build as many of them as I once did, but they're incredibly fun little puzzles to solve. Cramming largish photographs, animation, copy (including fonts, which usually result in the bulk of filesize), and animation into such a tiny package is no small feat, and requires a lot of time (the productivity tradeoff Jacques referred to) and tons of little optimization tricks you need to spend a few years collecting and perfecting, like:
* becoming a vector artist. Sometimes its necessary to have a partially transparent image, which means 32 bit PNGs, which are super expensive. Flash allows you to create vector masks (vector illustrations are incredibly size efficient), which means you can use a PNG-8 or JPG and mask out the areas that need to be transparent. Which means getting really good, and fast, at tracing outlines. The next level being
* learning how to do photo-realistic illustrations. In the old days of 12k for a banner, I did a lot of car banners, which meant a lot of car illustrations that needed to look exactly like the photos. Even then, you'd have to reuse your assets a lot, in creative ways, in order to make the filesize. (Like using a tire illustration for the windshield [by scaling and masking]).
* writing really tight code. In the early days, our basic animation engines were a few KB, but you could rewrite your own using only the chunks of code you needed, and save a few K. My newest library is about 800 bytes and is powerful enough to use on most of my banners.
* learning that people really aren't as detail oriented as you might think, and blurs, rotations, tints, and speed are usually all the tools you need to make a convincing animation
Is your only basis for feeling that people that like CoffeeScript don't "get" JavaScript the `class` syntax? If that's the case, it's a minor feature of CoffeeScript. I'd say the rest of the features it offers fall on the dynamic/functional side of things more than the strong+static typed/classical OOP side ( list comprehensions, splats, treating everything as an exression, etc.).
> It doesn't but JavaScript and Skilled js devs can!
You might be overestimating the differences between Flash and JS here -- especially when you add HTML5 into the mix. What's to stop a skilled JS dev from playing <audio> when the user hits a page, burning processors with a few autoplaying <videos>, after forcing the user to sit through an interminable, animated <js/css3/svg> 'loading' screen? At that point, it's up to our own good tastes to decide how to wield that kind of power.
I'm saying kind of the opposite -- JS/HTML/CSS and Flash are now more similar than they are different. It's not the platform that's the problem. It's what you can do with (and how you can abuse) the platform.
If you're running Flash content on a page, Flash is going to be running an event loop at the SWFs frame rate, even if it's not actually doing anything. JS, on the other hand, can be totally idle when it's not running any code.
Most JS use is sparing and lightweight and more about interaction than action/animation. Most Flash use is heavy-handed, ham-fisted, and overbearing, done more for cosmetic effect than additional function. Is this a part of the technology? No, but it certainly is nurtured by the differences between the development environments — Flash is still sold as an animation studio! What's more, JS gets to manipulate the DOM directly, giving it a much nicer relationship with the typical web experience than Flash, which is effectively a replacement for the DOM.
Have you used Twitter or Facebook on resource constrained machines? Even on latest nightly builds of Chromium it's painful on my Dell Mini netbook.
The point is that you can use Javascript do just about everything you can do in Flash. And Adobe CS6 will almost certainly contain some tools to help you use your existing Flash assets in a pure JS+HTML+CSS environment. So the animation studio for Javascript doesn't exist yet, but we're talking about the near future where it will and it will be just as obnoxious as Flash (but much harder to block from consuming CPU.)
The new Twitter really is the worst, and it's not just the Javascript. They've got that hovering topbar with an RGBA shadow and gradient background, which I've personally verified as being a source of much of the slowness on browsers that support these things. You can test it for yourself in any Webkit browser or FireBug — just disable those two CSS properties, and new Twitter feels immediately snappier.
Imagine what Gmail would be like if they went overboard with CSS.
In case anyone's scared away by the format, it's an accessible, three-page, quick read. And it's really interesting. The author's approach of blending language survey with language construction is a strategy I've recently employed, and I've grown more as a programmer, more rapidly, because of it.
You might be very comfortable sharing the story about the situation, but I hope you can appreciate that not everyone else would be.