The State of JavaScript - Brendan Eich • Hacker News Board

Re: The State of JavaScript - Brendan Eich

#221

Post by cmccabe » Wed, Oct 10, 2012, 6:50 AM UTC

bzbarsky wrote: post #210

cmccabe wrote: post #203

Earlier quoted context omitted.

Sigh. Not all open source projects are community projects. That doesn't make them proprietary. I'm disappointed to see this kind of confusion on HN. Rust doesn't have much of a community around it, besides Mozilla. Does that make it "proprietary"? Nope. We all know NaCl is not going to be adopted-- not because it's not good enough, but because it's too good, and would threaten the native app ecosystems of Apple and M…

I think you missed my point. Say you have an open-source project with a single owner, who makes all the decisions about it, and is willing to totally change it around to suit his needs. Would you stake your business on use of that open-source project? Only to the extent that you're sure your needs align with the project owner's. Unless, of course, you're planning to fork anyway. That's where NaCl is at the moment. It…

Let's check wikipedia.

"Proprietary software or closed source software is computer software licensed under exclusive legal right of the copyright holder.[1] The licensee is given the right to use the software under certain conditions, while restricted from other uses, such as modification, further distribution, or reverse engineering"

Muddying the waters by referring to open source software as proprietary software does not help. And I am sure the folks at Mozilla, being open source advocates themselves, would tell you the same thing.

Reminds me of an ex-boss (from a long time ago) who referred to all open source software as "freeware." Hey guys, the 1990s called, they want their bad hacker movies and confusion about the software business back.

Re: The State of JavaScript - Brendan Eich

#222

Post by cmccabe » Wed, Oct 10, 2012, 7:10 AM UTC

BrendanEich wrote: post #208

cmccabe wrote: post #203

Earlier quoted context omitted.

Sigh. Not all open source projects are community projects. That doesn't make them proprietary. I'm disappointed to see this kind of confusion on HN. Rust doesn't have much of a community around it, besides Mozilla. Does that make it "proprietary"? Nope. We all know NaCl is not going to be adopted-- not because it's not good enough, but because it's too good, and would threaten the native app ecosystems of Apple and M…

Rust has a healthy number of committers who are not employed by Mozilla. I will let pcwalton fill in details if necessary. "Proprietary" as in "sole proprietor" is appropriate for a project with zero governance, launched by Google after some incubation closed-source, dominated by Googlers. NaCl is not adopted because it's machine-dependent! PNaCl is not ready . Show me Chrome Web Store games compiled with it and not…

According to the Apache project, a project is "considered to have a diverse community when it is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)." Rust might meet that standard in the future, but it is not there yet.

With regard to JavaScript versus NaCl / PNaCl / etc-- I've heard all the debates before, and they are kind of tedious. ECMAScript is a good language for some things, but making it the only option is goofy. I think Mozilla is shooting itself in the foot by not supporting PNaCl, which is the one thing that could potentially save their "boot to Gecko" initiative from disaster. I guess the Adobe Flash and ActiveX experience left emotional scars that haven't healed yet. Oh well. Their loss, Apple/Google/Other app stores' profit.

Re: The State of JavaScript - Brendan Eich

#223

Post by cmccabe » Wed, Oct 10, 2012, 7:12 AM UTC

BrendanEich wrote: post #215

cmccabe wrote: post #203

Earlier quoted context omitted.

Sigh. Not all open source projects are community projects. That doesn't make them proprietary. I'm disappointed to see this kind of confusion on HN. Rust doesn't have much of a community around it, besides Mozilla. Does that make it "proprietary"? Nope. We all know NaCl is not going to be adopted-- not because it's not good enough, but because it's too good, and would threaten the native app ecosystems of Apple and M…

On TypeScript, are you seriously asking for warning-annotations? The class syntax is in for ES6, not original to TS. Or do you mean 'interface' as structural type (record width subtyping relation) declaration form?

I like the structural subtyping. This is a feature I also like in Go.

Re: The State of JavaScript - Brendan Eich

#224

Post by saebekassebil » Wed, Oct 10, 2012, 7:19 AM UTC

disnet wrote: post #177

saebekassebil wrote: post #153

Earlier quoted context omitted.

Of course, as in every aspect of understanding, here for source code, it is important first to learn the context, here the macro definitions. My concern is that this will impose more than just a paradigm - it will impose new syntax which could effectively completely ruin the readability of JavaScript source. The macro syntax is definitely not simple, and it could possibly get really complex for more elaborate syntact…

> The macro syntax is definitely not simple, and it could possibly get really complex for more elaborate syntactic definitions, thus rendering the source much less readable. True, but the same can be said of any API. Reading the definitions can help but for both complex macros and complex APIs built today out of just functions and objects you need to document your abstractions. Macros don't change this, they just giv…

I meant compile time of course, thank you for your clarifications. I'm eager to see how this turn out.

Re: The State of JavaScript - Brendan Eich

#225

Post by saebekassebil » Wed, Oct 10, 2012, 7:27 AM UTC

dherman wrote: post #196

saebekassebil wrote: post #139

Earlier quoted context omitted.

May be off-topic but: Is it just me, or are macros just a new way to get confused while reading JavaScript? Introducing language-foreign syntactic constructs seems to me superfluous and confusing - This is the job of transcompiling languages like CoffeeScript.

All abstractions can make your code unreadable; the key, as always, is to create good abstractions and document them clearly. Macros are syntactic abstractions. It's just as important to document them as it is for functions or objects. Of course, if you just have a little local macro that you're using for convenience, looking at the implementation may be sufficient. But when you write a macro that you want to share f…

So this is all in the holy name of making JavaScript the assembly language of the web? Making it possible for every JavaScripter to write "his own" JavaScript syntax definitions meaning that I'll (as a contributor or just casual watcher) would have to read his whole collection of macros before I could begin to understand the code?

I don't think this can be compared to API's as they still follow the regular syntactic definitions - This will be like reading a completely new language every time I read a different repository. (Of course this is a worst-case scenario as I imagine that many macros will be used across several projects, but still.)

Is all hope gone for writing vanilla JS gone? And isn't macros kinda going in the opposite direction than the ES specs? There's no use for many of the ES6/7 features as they could just be mocked up in macros.

Re: The State of JavaScript - Brendan Eich

#226

Post by BrendanEich » Wed, Oct 10, 2012, 7:56 AM UTC

haberman wrote: post #217

BrendanEich wrote: post #205

Earlier quoted context omitted.

You wrote, very first comment at top: "To dis NaCl on this basis and not even mention PNaCl is dishonest." That was in response to my slides. You were calling me dishonest. Come on yourself! You then went on about "propaganda" and scary salt crystals. Something is off right there. Mozilla doesn't make propaganda and we have a tiny fraction of Google's budget (which I can assure you has been deployed commercially to p…

You seem a lot more interested in getting me to take back things than you are in taking back your misleading slide. Substitute whatever adjectives you want if the ones I used offend you, but the point still remains that the most vocal criticism of (P)NaCl comes from Mozilla and it is anything but "balanced." I would feel more inclined to issue an actual retraction if there was any indication that I was mistaken about…

The slide I showed is not misleading. NaCl is not portable, PNaCl is still not ready for prime time based on Google's own actions, and you protest too much and do not practice what you preach.

"Mozilla" meaning me, bzbarsky, blizzard (previously), roc on the plugin-futures list, others have been forthright compared to the mostly-silent other browser vendors, who haven't even spoken via corporate or individual channels on this non-issue apart from my pal Maciej at Apple coining "Active G" to refer to Pepper.

If this circumstance makes you shoot us, the messengers, you need to read more Greek tragedy!

We're telling you why NaCl/Pepper are a no-sale among all the non-chromium browsers. You don't like the reasons we give, but that's no justification for your ascribing to us bad motives or a dishonest agenda or techniques ("propaganda"). We have been perfectly clear about the unacceptably high cost of Pepper, and the single-company control problem of all of NaCl/PNaCl/Pepper.

Your own misstatements are yours, and you should retract or not based on their righteous or wrongful nature, not on what anyone else does. That you excuse your conduct based on your grievance with us is thoroughly broken, as a piece of moral reasoning.

At this point you are perfectly clear: you want a free lunch (from all browsers, but especially from Firefox), we won't give it to you, so you call us names and imply that we act out of bad motives. That makes you persona non grata in my book. Good luck!

Re: The State of JavaScript - Brendan Eich

#227

Post by BrendanEich » Wed, Oct 10, 2012, 8:01 AM UTC

qwinter wrote: post #216

BrendanEich wrote: post #205

Earlier quoted context omitted.

You wrote, very first comment at top: "To dis NaCl on this basis and not even mention PNaCl is dishonest." That was in response to my slides. You were calling me dishonest. Come on yourself! You then went on about "propaganda" and scary salt crystals. Something is off right there. Mozilla doesn't make propaganda and we have a tiny fraction of Google's budget (which I can assure you has been deployed commercially to p…

Please stop signing your posts.

Why?

Re: The State of JavaScript - Brendan Eich

#228

Post by robin_reala » Wed, Oct 10, 2012, 8:03 AM UTC

BrendanEich wrote: post #227

qwinter wrote: post #216

Earlier quoted context omitted.

Please stop signing your posts.

Why?

House style: http://ycombinator.com/newsguidelines.html

Please don't sign comments, especially with your url. They're already signed with your username. If other users want to learn more about you, they can click on it to see your profile.

Re: The State of JavaScript - Brendan Eich

#229

Post by mercurial » Wed, Oct 10, 2012, 8:17 AM UTC

pcwalton wrote: post #95

MatthewPhillips wrote: post #93

Earlier quoted context omitted.

People who want bytecode has nothing to do with bytecode being better; they want bytecode because they want their language of choice to be a first class citizen and JavaScript-as-assembly means their language will always be second class.

I've never seen a bytecode that wasn't just a straightforward source-to-source translation of some language. JVM bytecode is pretty much just another way to encode Java (invokedynamic notwithstanding). .NET bytecode is pretty much just another way to write C#. Bytecode really is nothing more than just a compressed source encoding of some language. It doesn't magically result in a VM that can efficiently encode all se…

What about LLVM? It seems able to deal with a fairly large number of languages with fairly different paradigms (including Rust :) )

Re: The State of JavaScript - Brendan Eich

#230

Post by cygx » Wed, Oct 10, 2012, 9:13 AM UTC

mercurial wrote: post #229

pcwalton wrote: post #95

Earlier quoted context omitted.

I've never seen a bytecode that wasn't just a straightforward source-to-source translation of some language. JVM bytecode is pretty much just another way to encode Java (invokedynamic notwithstanding). .NET bytecode is pretty much just another way to write C#. Bytecode really is nothing more than just a compressed source encoding of some language. It doesn't magically result in a VM that can efficiently encode all se…

What about LLVM? It seems able to deal with a fairly large number of languages with fairly different paradigms (including Rust :) )

That's similar to saying that x86 asm is able to deal with a large number of paradigms. LLVM IR might be a a viable target to avoid writing your own native code generators, but that does not a universal bytecode VM for dynamic languages make.

It sure would have been nice if Parrot had succeeded there...