In a new thread to avoid getting too OT on Greg's thread... On Wed, Apr 8, 2015 at 10:17 AM, Greg Keogh <[email protected]> wrote:
> The code and scripts that make the demo work are obtuse, cryptic, verbose > and fragile, and you'd have to take a bit of time to study how it works and > get a comfortable feel for it. This confirms my distaste for writing > anything with JavaScript involved ... it's the joke of the century. Once > day when I'm an old head-in-a-jar and someone has finally made the web > function properly, we'll look back and laugh and say "I can't believe we > made that junk work!". On 8 April 2015 at 12:28, Stephen Price <[email protected]> wrote: > That's the beauty of it all. The power of Javascript is that you *can* > hack it together. Does it mean you should? We'll leave that discussion for > another lunch time. On 8 April 2015 at 13:13, Tom Rutter <[email protected]> wrote: > Don't even get me started on javascript. I feel just as dirty using > javascript as I did with silverlight version 1. God save us Yes, JavaScript is an awful programming language with an appalling "standard library" ("you call that a standard library?!"). And everybody knows it too. The introduction of many new "compiles to JavaScript" languages (e.g. CoffeeScript[1], Dart[2], Elm[3], Flow[4], TypeScript[5]), as well as the re-purposing of several general purpose programming languages with a JavaScript compiler back end (e.g. C++/Emscripten[6], Haskell/GHCJS[7], Java/GWT[8], Ruby/Opal[9], Python/Pyjamas[10]), shows that language designers do recognize how impractical JavaScript is and are starting to treat JavaScript more like an in-browser assembly language. Given the absence of any credible solution to "the JavaScript problem" in the last few decades, I tentatively agree that this is the right direction for JavaScript. If it has to stay, treating JavaScript with the same caution as an assembly language seems to be a sensible attitude. Like true assembly languages, when you make a type error in JavaScript (in the type-theoretic sense), your process usually (1) dies (if you're lucky), (2) exposes a deadly security vulnerability, and/or (3) enters the Twilight Zone. Often you get a combination of (2) and (3) until finally (1). These new languages and especially these new compiler back ends for existing languages look like they are a step in the right direction. Unfortunately, there are still far too many implementations to choose from, as usual. A final, lighthearted comment that probably should be saved for Friday relief: Note that some of these language newcomers originated at commercial software superpowers like Apple, Microsoft, Google and Facebook, fully consistent with their aims of world domination. In blatant Orwellian style, they seek to influence thought by controlling the language of thought - our programming languages in this case. "Don't you see that the whole aim of [your favourite programming language] is to narrow the range of thought? In the end we shall make thoughtcrime literally impossible, because there will be no words in which to express it." The antidote is, accordingly, to know your history and investigate as many programming languages as you can. [1] http://coffeescript.org [2] http://www.dartlang.org [3] http://elm-lang.org [4] http://flowtype.org [5] http://www.typescriptlang.org [6] https://kripken.github.io/emscripten-site [7] https://github.com/ghcjs/ghcjs [8] http://www.gwtproject.org [9] http://opalrb.org [10] http://pyjs.org -- Thomas Koster
