Don't worry, no fisking (bottom-citing instead :-P). This topic of "let's switch to bytecode" or "let's abstract a VM" has come up before:
http://apps.ycombinator.com/item?id=1893686 IMHO Java's bytecode did not help, it hurt. It hurt Java's evolution, in big ways -- often just by keeping compatibility when breaking compatibility was required (and compatibility was broken later anyway). It hurt VM implementation and optimization.It hurt users who had to compile and package all the time -- during development in particular (yes, people minify JS when deploying, but that's not the javac/jar pain point). I think bytecode helped kill Java on the client. In similar big ways, and others that I won't rehash (see http://brendaneich.com/2007/03/the-open-web-and-its-adversaries/), the opacity (at least until recently) and even *multi-generation VM* bytecode sub-formats of SWF has hurt Flash. Some think Native Client will save us. I read http://cananian.livejournal.com/63325.html and see great research, but nothing any browser save Chrome might ship, let alone standardize. DLL hell, libc version hell, svn branch feature-conflict hell, ARM vs. x86 etc. hell (PNACL has not saved us; LLVM bitcode is not always arch-independent), and on and on. This stuff is 10x to 100x more complex than JS to specify in a standard and implement interoperably. And that's the main argument for JS over bytecode, beyond the distortions of lowering to bytecode, freezing the bytecode, trying to evolve languages and VMs thereafter: that JS is strictly much simpler, orders of magnitude simpler, than a language VM. Especially a language-"neutral" VM. (ECMA-334 and -335? Don't even try those on me.) /be On May 12, 2011, at 3:09 PM, David Foley wrote: > You know what? As a pragmatic programmer, one who tries their best to > translate problem domains into normative business logic in a language with a > sufficient level of expressiveness to accommodate manageable adaption to > moving goals, the language should not be the problem domain. > > As far as I have so far understood it, this list is about the evolution of > JavaScript. (Personally I prefer it's original designation as LiveScript, and > the affordances it allowed to move from scratch code to mature application > delivery). > > I am most likely going to regret saying this, but I would feel (yes, actual > emotion') like a coward if I didn't make this point. > > There appears to me, to be too much focus on the interpretation of the > language, and the technical challenges therein, rather than than the business > hours affordances of the language to deliverables and developer experience of > the language. > > However, what if, rather than trying to consolidate legacy with emerging > (naive or otherwise) expectations of the languages evolution, that focus is > put instead upon a polysemetic interpreter, a common VM, which language > authors can utilise to their own ends (within constraints), whereby the > principles of JavaScript dynamism define it's operational boundaries. > > In essence, what I'm proposing, is rather than JavaScript being the sole glue > of the web, that instead focus is put upon a programmable standardised vm > design, which can accommodate JavaScripts evolution. > > That way we can focus on interpreter specifics, and language design, without > the politics. > > As I said, I know I will probably regret this, and Brendan, I know I wouldn't > survive a point by point break down (really, this is a high level > philosophical proposal, not a technical one), but at least this path could > (potentially) be a sound vehicle to distinguish the natural evolution of this > particular language, from the needs of developer teams producing > sophisticated highly interactive client side web applications (JavaScript > could be the Rosetta stone). > > I am genuine trying to be constructive here, for better or worse, and I know > that casual subjective opinions are not necessarily welcomed here, but that's > my tuppence all the same. > > If this mentality is anathema to the group, and if anyone is open to discuss > this strategy lest we pollute this list, feel free to get in touch > > Best > > Dave > > David Foley | Senior Software Architect > > +353 87 667 4504 > Skype: david.d.foley > > On 12 May 2011, at 22:51, "Dmitry A. Soshnikov" <[email protected]> > wrote: > >> On 13.05.2011 1:25, Brendan Eich wrote: >>> >>> On May 12, 2011, at 1:06 PM, Brendan Eich wrote: >>> >>>> On May 12, 2011, at 10:55 AM, Brendan Eich wrote: >>>> >>>>> Ruby is far from simple, btw. Check out >>>>> >>>>> http://samdanielson.com/2007/3/19/proc-new-vs-lambda-in-ruby >>>>> >>>>> and the wikipedia page it references. >>>>> >>>>> Looks like Proc.new but not lambda can return from its caller. >>>> >>>> From http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Method_Calls it >>>> should be clear I was missing the "block" target. Blocks are syntactically >>>> restricted to being downward funargs. Only if reified as Procs do they >>>> potentially escape to be called later when their lexical parent method >>>> could have already returned. >>>> >>>> IOW, blocks are restricted to being downward-funargs by syntax at their >>>> expression site, and by default in the callee (without the & before the >>>> corresponding formal parameter). >>> >>> To say a bit more about this, here's a demo of the downward-only-funarg >>> nature of blocks passed as extra trailing arguments, with no matching >>> ¶meters: >>> >>> def say >>> puts yield "world" >>> end >>> >>> def say_hello >>> say {|x| "hello #{x}" } >>> end >>> >>> say_hello >>> >>> The output is "hello world" of course, but Ruby's yield calls the block >>> without it escaping as a reified Proc that could be invoked later, after >>> the downward flow. Neat! >>> >>> (Rubyists, please correct anything wrong here.) >>> >> >> If the block is described explicitly in the method definition (that is, the >> last parameter with &) then it can be returned back as a result: >> >> def foo &block >> >> if block_given? >> >> yield 10 # call the block implicitly >> >> block.call 20 # the same, but explicitly >> >> block # return the block back >> >> end >> >> end >> >> # pass the block downwards, >> # and get it back (upwards) as a result >> >> returned_block = foo { |i| print i } >> >> # and call it again >> returned_block.call 30 >> >> Though, there's no much practical sense in this, since the block lexically >> is created in the global context of (in this case particular case) and >> captures its bindings, it, obviously isn't related with bindings of callee. >> >> Brendan, take a look at this detailed source-article explanation of closures >> in Ruby http://innig.net/software/ruby/closures-in-ruby.rb (it's executable >> file, so a good tutorial). There all this stuff with blocks, etc is >> explained well. >> >> P.S.: damn, it's so sorry that I haven't much time now to be involved deeply >> into the recent discussions of shorter function syntax. I hope I'll read >> carefully those threads later. A one thing I'd like to mention, we should >> not afraid of changes even if they syntactically aren't so familiar and >> habitual as were in Java. >> >> P.S.[2]: >> >> -> syntax is / was long time before CoffeeScript. It's just a standard math >> definition of a function, it's used as a type of a "function" -- lambda >> abstraction -- in the lambda calculus, that is the "arrow type". It's used >> in many other langs, e.g. Erlang (which I use in my current job), Haskell, >> other. So, don't afraid it. Though, the issues with hand-written LL parsers >> should be also considered. >> >> Dmitry. >> >>> I'm not suggesting we copy any of this, just passing along my Ruby-n00b >>> knowledge. >>> >>> >>>> When we considered lambdas (the "Allen's lambda syntax proposal" thread >>>> from late 2008 to early 2009), we did not try to confine them >>>> syntactically to actual parameter lists. Did we miss a key restriction or >>>> feature of Ruby? I'm not sure, I'm too much a Ruby n00b. >>> >>> If blocks could not escape to be called after their enclosing function had >>> returned, then we would overcome the objection raised last time, >>> articulated best by Maciej: >>> >>> https://mail.mozilla.org/pipermail/es-discuss/2008-December/008390.html >>> >>> But Ruby went all the way, allowing a block to grow into a Proc and outlive >>> the method in which the block was expressed. I expect similar "ecological >>> pressures" to apply if we added blocks only as downward-funargs. >>> >>> Plus, we'd still want shorter function syntax, not just blocks as >>> downward-only funargs (however nice for map, forEach, etc.). >>> >>> I will write up a block strawman, to give it a fair shake along side >>> http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax. >>> >>> /be >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
