3 ms·

Dart and NaCL design are not happening behind closed doors, period. NaCL was first published as a research paper. All development since it was published has hap

Dart and NaCL design are not happening behind closed doors, period. NaCL was first published as a research paper. All development since it was published has happened in the open. None of the popular languages today have been the designed the way you suggest. K&R designed C behind closed doors, ANSI C came later. Python, Ruby, Perl, JavaScript, the list goes on and on, all designed and prototyped first prior to any kind of standardization. Committee driven languages like C++ have shown to bloated monstrosities in terms of complexity. Creating a focus group and committee to design a language is the surest way to lead to failure or to compete with Duke Nukem Forever for delayed completion. I have a nagging suspicion that many of these arguments are based around aesthetics and language chauvinism. The people who are super critical of Dart or NaCL are also the people who intersect with people with absolutely love Javascript, and dislike class-based OO and other paradigms. There is no such thing as a unified web community. Everyone has difference preferences and opinions on the way to write web apps. The forest through the trees is that consumers and developers today increasingly don't care and are seeking out native, battery efficient, mobile applications. It's an incredible threat to the Web, and all of this bickering over people's attempts to find more performant ways of shipping apps within the Web model, but not use JS are IMHO, missing the point. While Mozilla and others think the fight is against Dart and NaCL, Android Java and Objective-C are crushing on mobile. I have grave doubts that FirefoxOS + asm.js can rectify any of the core issues. The desktop is going bye bye. Anyway, Dart was announced in 2011. It still isn't finished and it has been changed radically since then based on community feedback from the needs of developers. Everyone ships binary blobs to the Web today. Gmail is a binary blob. It's a red herring. I love the Web with all my heart. I don't think JS is the Web. The Web is HTTP. It is URL. It is transparent content. RESTy semantics. It is indexable, federatable. You can ship JS based apps that I don't think quality as very Webby. My big fear is, 5-10 years from now, everyone is publishing "sites" that are app store distributed, and all information is siloed behind private repositories. Is asm.js going to stop that? Is it going to make mobile web apps as battery efficient, memory efficient, or performance efficient, with less jank, than iOS? I don't think Dart will either, but we need to figure out a solution.

kevingadd 13y ago
I don't know why you're fixated on things like asm.js and C++ here when I didn't bring either of them up. Here's the deal: Yes, C++ is a monster. Yes, asm.js might be doomed. I don't really care, because I don't like C++ and I don't have any intent to use asm.js. Given that, however: C++ may be a monster but it's the monster that won. Worse is better, or whatever: C and C++ are tremendously prevalent languages and nothing anyone has done has managed to displace them even one bit. We've got new languages like Java and JavaScript that have managed to carve out footholds, but it's still a fact that when you grab a modern piece of software, it's almost always written in C, C++, or a weird C derivative (like Objective-C). Note also that I've never argued here that the design behind closed doors is the problem, merely that it is a root of the problem. The design behind closed doors leads to poor/misguided design decisions being baked into a project and then cemented by years of engineering and derived decisions. You can certainly undo all that bad decisionmaking after you put your project out in the open, but it's not free, and it comes at the cost of severe resistance because people aren't excited by the idea of throwing out all the work they did. You can see this by looking at the mailing list for the W3C Audio group right now and observing just how hard it is for them to specify the Audio API that Google designed behind closed doors. An equally troubled API could have been designed in the open, but being designed behind closed doors is why it ended up with a narrow design that wasn't informed enough by a wider set of use cases and customers. It's incredibly easy for software engineers to convince themselves that they are expert enough to make all the right design decisions and lock them in. We've seen it again and again. That is why it is important to work in the open and that is why Google's reluctance to do so early on causes lots of friction for (technologically stellar) projects like Dart and NaCL. Were Dart already an established language player like C or even Java, these complaints wouldn't really matter, because at that point a language is a thriving, living thing that can evolve as time passes to become a better language and overcome its own faults. The problem here is that Dart is not there, it's not anywhere close to there, and it's not clearly on anything resembling a trajectory to there. If the software engineering community as a whole - not just people at Google - don't start learning from these mistakes we're just going to keep adding to a long, dire list of failed languages, libraries, and platforms. Asking people to adopt a new language you designed for your needs, learn a bunch of new libraries, and rewrite all your code in order to run it in a small subset of available runtimes is simply not a winning play. As a developer I have literally dozens of great languages to pick from to write my applications in - Haskell, Scala, C#, Python, etc. Why would I pick Dart if the toolchain isn't there, the runtime isn't there, the libraries aren't there, and Google might abandon it in 5 years when it doesn't catch on? And now you know why I'm writing a transpiler for an existing language that outputs JS, instead of hacking on something like Dart: Because I don't want to waste my time.

kevingadd 13y ago

I don't know why you're fixated on things like asm.js and C++ here when I didn't bring either of them up. Here's the deal: Yes, C++ is a monster. Yes, asm.js might be doomed. I don't really care, because I don't like C++ and I don't have any intent to use asm.js. Given that, however: C++ may be a monster but it's the monster that won. Worse is better, or whatever: C and C++ are tremendously prevalent languages and nothing anyone has done has managed to displace them even one bit. We've got new languages like Java and JavaScript that have managed to carve out footholds, but it's still a fact that when you grab a modern piece of software, it's almost always written in C, C++, or a weird C derivative (like Objective-C). Note also that I've never argued here that the design behind closed doors is the problem, merely that it is a root of the problem. The design behind closed doors leads to poor/misguided design decisions being baked into a project and then cemented by years of engineering and derived decisions. You can certainly undo all that bad decisionmaking after you put your project out in the open, but it's not free, and it comes at the cost of severe resistance because people aren't excited by the idea of throwing out all the work they did. You can see this by looking at the mailing list for the W3C Audio group right now and observing just how hard it is for them to specify the Audio API that Google designed behind closed doors. An equally troubled API could have been designed in the open, but being designed behind closed doors is why it ended up with a narrow design that wasn't informed enough by a wider set of use cases and customers. It's incredibly easy for software engineers to convince themselves that they are expert enough to make all the right design decisions and lock them in. We've seen it again and again. That is why it is important to work in the open and that is why Google's reluctance to do so early on causes lots of friction for (technologically stellar) projects like Dart and NaCL. Were Dart already an established language player like C or even Java, these complaints wouldn't really matter, because at that point a language is a thriving, living thing that can evolve as time passes to become a better language and overcome its own faults. The problem here is that Dart is not there, it's not anywhere close to there, and it's not clearly on anything resembling a trajectory to there. If the software engineering community as a whole - not just people at Google - don't start learning from these mistakes we're just going to keep adding to a long, dire list of failed languages, libraries, and platforms. Asking people to adopt a new language you designed for your needs, learn a bunch of new libraries, and rewrite all your code in order to run it in a small subset of available runtimes is simply not a winning play. As a developer I have literally dozens of great languages to pick from to write my applications in - Haskell, Scala, C#, Python, etc. Why would I pick Dart if the toolchain isn't there, the runtime isn't there, the libraries aren't there, and Google might abandon it in 5 years when it doesn't catch on? And now you know why I'm writing a transpiler for an existing language that outputs JS, instead of hacking on something like Dart: Because I don't want to waste my time.