I read that back in 2007, and I was surprised at the time, but he was right.
—Dave On Dec 9, 2013, at 9:19 AM, Mike Moore <[email protected]> wrote: > Anyone remember this? > > http://steve-yegge.blogspot.com/2007/02/next-big-language.html > > > On Sun, Dec 8, 2013 at 9:06 PM, Dave Smith <[email protected]> wrote: > >> Yes indeed. The evolution of JavaScript from red-headed stepchild to its >> present state has been a surprising journey. >> >> I predict a day in the not-too-distant future where JavaScript will become >> the assembly language (or byte code) of the web, both client side and >> server side. We’re already seeing languages that compile to JavaScript, >> like CoffeeScript and TypeScript. Browsers have some really impressive >> interpreters and JITs. I predict that developers of the future will say, >> “You actually *wrote* JavaScript? You’re hard core”. >> >> —Dave >> >> On Dec 7, 2013, at 5:37 PM, S. Dale Morrey <[email protected]> wrote: >> >>> I've been working on a sparetime project for a few weeks and had >> something >>> mostly coded up in Java, then realized that perhaps I was trying to >>> re-invent the wheel so I googled for a library to do the heavy lifting >> for >>> me. >>> >>> Imagine my surprise when many of my queries for xyz java library started >>> returning xyz javascript library. >>> >>> Just for fun I decided to look at the effort involved in remaking my >>> prototype in Javascript using node.js and some helper libraries. >>> >>> When I found that 90+ % of my prototype was available as library >> functions >>> and it was more or less a matter of gluing them together. I decided to >> go >>> ahead and just give it a try in js. >>> >>> Now don't get me wrong. I'm hardly a javascript noob. I was writing >>> Ajax-like website helpers scripts before we ever coined the terms Comet >> or >>> Ajax. Nevertheless I've always viewed it as a tool for making shiny bits >>> and/or using it as a scripting language for controlling other programs. >> In >>> other words I've always seen it as being firmly as part of the view >>> component. I never really viewed it as something for serious >> computational >>> workloads. Until now. >>> >>> I finished both prototypes to the same level. With my curiosity piqued I >>> decided to let them both rip on separate instances in the same AWS >>> availability zone, same EC2 machine types (t1.micro). >>> >>> The job is just to hash words from a dictionary list (I'm making a >> personal >>> rainbow table) using a few different hashing algorithms after which I >> will >>> be doing an analysis with map reduce but neither the the map reduce nor >>> analysis steps are included in this part. This is just a feed generation >>> step. >>> >>> I just wanted to test raw hashing power in this case. >>> I added a loop counter to the main loop and put in stopwatch function to >>> ensure identical runtimes. >>> >>> Here are my results after 2 minutes of runtime... >>> Java 7 J2SE : 1,000,079 >>> Node.js Javascript : 1,548,103 >>> >>> The numbers represent how many times it made it through the final loop >>> where it would normally have written out a csv. Thus there were several >>> steps. Read a fixed list, them run SHA256, Scrypt and Ripe-MD160 on each >>> unit. There was no output step so as to rule out filesystem access times. >>> >>> This isn't meant to be a head to head comparison. >>> >>> The Node.js version is (to the best of my knowledge) single threaded and >>> the Java version is running on a thread per core model (even though the >>> test box is 1.5 cores). Looking back, going with thread per core may >> have >>> gimped the Java version because of list contention, and/or context >>> switching penalties so I do doubt the numbers here are anything >> resembling >>> final. In fact I ran it for 5 - 10 - 15 and 30 mins as well and once JIT >>> kicked in and moved some stuff to metal, Java slightly matched (at 15 >> mins) >>> and slightly exceeded (at 30 mins) Javascript. >>> >>> Javascript just trucked along at the same rate during similar intervals. >>> >>> The point is, When the heck did Javascript become suitable for something >>> that's so computationally heavy? A 50% performance improvement over Java >>> in a short interval, especially when I have not done anything to >>> intentionally gimp the Java version, tells me this is not the Javascript >> I >>> used to know. >>> >>> It also showed me something about my own internal biases. >>> I find it odd how my thinking has evolved over time. >>> >>> I used to be a computer programmer who had a good/decent familiarity >> with a >>> broad range of languages and I would always try to select the best tool >> for >>> the job taking into account the cost of developer time vs cpu time. >>> >>> Over the past 4 or 5 years I've been so heavy into Java (because that's >>> what employers want), that I think I may have evolved into a Java >>> programmer. >>> >>> This experience has shown me that it might be time to broaden my horizons >>> and again embrace the "right tool for the right job" approach I used to >>> have, rather than the Swiss Army Chainsaw habits I've picked up from >>> programming in Java. >>> >>> So what do you think? Have you looked at any languages for purposes you >>> had previously disregarded? What were your thoughts? >>> >>> /* >>> PLUG: http://plug.org, #utah on irc.freenode.net >>> Unsubscribe: http://plug.org/mailman/options/plug >>> Don't fear the penguin. >>> */ >>> >> >> >> /* >> PLUG: http://plug.org, #utah on irc.freenode.net >> Unsubscribe: http://plug.org/mailman/options/plug >> Don't fear the penguin. >> */ >> > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
