Worth noting this was written up a year ago and there hasn't been a whole lot of progress since. Would love to see this idea progressed further, this seems really neat.
My problem is that all of my ideas are too big. It seems that every new idea I think of -- well, if I kept going with it and finished it to the extent that it matches my idea, it would take a year or two. I don't have two years to waste on an idea that may or may not help me. Maybe that's sad but it's real life™.
The real mess is how in ES6 they (the ES6 WG I mean) are furthering the illusion that JS supports classical OO, which is completely crazy. They should be going the other direction (and I think /be wanted to) but they steered away from that and seem to think that mixing syntaxes and thus concepts is the right move. I would imagine this article series will talk that eventually, though, kind of hard not to.
I think BE is a fan of the max-min class proposal... At any rate, naming aside, ES6 classes are simple syntactic sugar for a very common pattern in JS development today. It makes sense to provide a syntactic sugar in this case that makes developer intention clear and reduces boilerplate.
TypeScript has (I believe) a mostly compatible implementation of these classes if you want to try them out in today's runtimes.
JavaScript was a pseudo-classical language from the beginning. JS constructors were and still are the core language feature that clearly tries to mimic classes from Java. I agree that's it's awful, but it can't be depracated or removed from the language because there is so much code relying on it.
Evolving JS into language with minimal dynamic classes such as Python or Ruby should be easy as all interfaces are already "classical", you just need to add some syntactic sugar. This approach was already proved to work by CoffeeScript and TypeScript. I can't imagine how JS could be evolved into clean prototypal language such Io without breaking backwards compatibility.
There is no hope for JavaScript to become elegant prototypal language because of the design mistakes that were done in the past. All that TC39 / ECMAScript.next committee can do is put even more lipstick on a pig.
Actually, the evolution of the language has been adding "class-like" features over time. It was most definitely not designed originally to mimic classes. That's been the demand of all the classicists coming to the language. There are those of us who wish for the language to not have all those things.
In parts 2 and 3, I'll make the case for why I think all those things don't belong in JS and should be removed or avoided.
There was really little evolution of the language since 1995. It was initially launched as a "perfect complement to Java" [1] and until recently its development was stalled.
Constructors and "new" were there from the beginning. Nobody have even noticed the prototypal nature of JS until people like Crockford started evangelising it 10 years later, which in turn resulted in the addition of Object.create() in ES5.
I'm not sure the actual history bears out your assertion that 1995 was the fix-point date for all/most of these concepts.
AIUI, functions were not originally first-class citizens. My understanding is (and I may very well be incorrect), in these very early days, functions not being objects precluded an awful lot of what we currently "know" to be true about how JS emulates "classes" with function.prototype. I tried to find good citations for this fact, but I'm having trouble finding good "early JavaScript" history.
I do know that at least as early as ES1, in mid-1997, we had constructors with prototypes and "new". [1]
In any case, besides `Object.create()` which you've noted, here are some other milestones in the evolution of "OO in JS" I could find:
`instanceof` was added in JavaScript 1.4 [2], which was sometime after Oct 1998 [3], probably officially in ES3.
`Object#isPrototypeOf()` was added in ES3 [4], which was around late 1999.
`Object.getPrototypeOf()` was added in ES5 [5], which was around 2009.
Why? If the people want a language changed, most abuse the current prototype system to be more classic class like (including top notch programmers), and there is a demand for it, why not add a proper class syntax, even as a sugar for the common workaround?
It's like saying people must adapt to the idiomatic ways of a language without offering any proof that those are better (and no, random qualities like "more flexible" is not necessarily better in actual use).
I don't think we should worship "idiomatic" ways of each language. For example, tons of Beans, XML, and boilerplate was the idiomatic Java way, but then projects came along and showed it could be done better (e.g Play). Using every feature under the sun and abusing templates is kind of an idiomatic C++ way, but people are arguing successfully for merely using C++ only as a C with classes and some minimal features.
In part 2, which should be published today, I'll be addressing "class { }" and why I think it doesn't belong in JS. I think it's just more "distraction" that moves us away from a better clearer understanding of how [[Prototype]] behavior delegation works.
That is way too much information for me personally (I am distracted enough as it is, and I believe real-time data like battery level belongs in your menu bar, not the terminal) but I can see how it would be useful to some.
That's amusing, because I've started liquidprompt for this very specific reason: I was constantly missing the battery notification icon. Time seems to have trained my brain not to look at this screen area. Fortunately, with liquidprompt alerts are spoting just where I look at, and only when necessary.
Yeah, Conky or similar status bar window manager widget is better for me for the real-time data (battery, cpu temp, date/time, etc.); too much to visually parse otherwise.
Definitely some nice features in here at first glance (colored directory perms and colored root vs. normal user are real nice-to-haves for example).
If you look under features configuration there's options for turning a lot of it off. I agree that the majority probably isn't useful unless you're running without a window manager for some reason, but even just the VCS info is pretty neat.
Window manager doesn't necessarily imply menubar. For example, with xmonad, you don't have a menubar unless you install xmobar. This could be an alternative to that, though admittedly that's a really obscure use case.
For me, most of this I don't want, and some I already have (git repo stuff), but some is new and potentially really convenient, especially the stuff for number of sleeping/background jobs.
I've never understood these sorts of statements. You can write spaghetti code in a functional language too. Instead of objects floating around, you have functions. Instead of objects interacting with each other in various ways, you have functions interacting with each other in various ways. You can "build programs by accretion" in any language. Ultimately it all comes down to complexity. Simple code is simple, complex code is complex. You're not going to magically get around this by switching to a functional language. Right?
Well, if you're really programming in a function way, then you're not using side effects (or at least, the side effects are constrained). That means things are local, and you can safely compose functions without causing the behavior of other parts of the program to change.
Or, you know, a software engineer. Good software engineers, after all, value things like low coupling; composability is like a stronger version of low coupling. (That is, composable things are not tightly coupled but decoupled things are not necessarily composable.)
Good software engineers certainly value low couplings. Unless it is a coupling with some code written in an obscure language with extreme (and masochistic) approach and with no common sense.
I'm not at all sure what your point is. There's nothing controversial about the benefits of referential transparency and immutable state, for modularity, composition and simplicity. What is obscure to you? It won't be to everyone.
The biggest thing in this regard a language like Haskell has going for it is purity, and therefore the concept of "no global state" taken to an extreme. Add to that referential transparency (which is a highly related concept anyway) and you get pretty strong "equational reasoning" where it is quite easy to trace, accurately, what's happening in a chain of calls - it's all transformation of data structures passing through.
If by "functional language" you mean JavaScript, then that's a completely different matter... :-)
Whatever you do, don't let some baby with a hammer to take some abstract and high concepts to the extreme, ruin your project and learn from it. Not in your project.
In the production code, stay with the mainstream. And limit your extreme approaches to research grade code, with limited lifetime.
We use Haskell in mission critical production code at my company and we are very happy with it. So do many banks in their pricing models and many other areas of application.
This may mean that we can't just go hire your average programmer, but we have also had a bizarrely low rate of bugs in production despite a high level of inherent complexity in what we do.
Based on what I've seen, codebases, that use non-mainstream languages and technologies have a tendency to fracture into parts written in a mix of languages and disappear in the rubble.
So let's wait a few years, and see, shall we?
(It's not that I don't like, or don't use shiny 'new' toys. It's just that in the long run it really really helps to use these toys only in the 'research grade' code. Depending on anything even a tiny bit out of industry mainstream in your key production code is a huge liability few years down the line.)
That looks really nice. A lot of WebGL demos these days don't really show the full extend of what WebGL can do, so to my eyes it's basically equivalent to something like VRML (anyone remember that?). Of course WebGL/OpenGL and VRML are totally different but you get the idea. Yeah I know there's stuff like Quake in WebGL but it's not really the same thing, because Quake was designed for lesser powered machines.
I'm still waiting for someone to make a fully fledged game in WebGL because I can totally see it happening.
