4 ms·

NaCl and Dart were not created in the open. Both were secret projects within Google before their alpha versions were released; Dart was in development for at le

NaCl and Dart were not created in the open. Both were secret projects within Google before their alpha versions were released; Dart was in development for at least 2 years before it was announced to the world. By that time there was no way a third party could have an affect on any of the fundamentals. Also, for the record, PNaCl doesn't have a spec. It only has a reference implementation.

derefr 14y ago
> By that time there was no way a third party could have an affect on any of the fundamentals. It's not like NaCl is a market-dominating monopoly format like MS Word .doc now or anything. Going by usage, it's basically still a prototype. Anyone (e.g. Mozilla) who disagrees with the fundamentals of the design so thoroughly that they don't want to work with what Google came up with, could create a competitor to NaCl using the same basic idea (native-speed code execution using a pre-checked subset of machine instructions), and their version would have roughly 99% as good a chance of becoming dominant as if NaCl hadn't yet existed. There are two alternatives when coming up with a standard: drag people through a committee forever to pin down every little feature--or just have one of the concerned parties throw together a working implementation that everyone else can then point at and say "well, this part is good, but that part is crap, I think I'll make a version of my own without that part", and shake thoroughly until a stable ecosystem settles out of it. --- As an aside--it seems like most of the good things in technology (e.g. HTML) come out of the latter process, and yet everyone somehow sees the former as fundamentally "fairer" or something. What's so wrong with making a bunch of incompatible forks, and then competing to merge all the best features of one-another so that your thing will be the "most compatible", and therefore see the greatest adoption? :)
- MatthewPhillips 14y ago
  > There are two alternatives when coming up with a standard: drag people through a committee forever to pin down every little feature--or just have one of the concerned parties throw together a working implementation You can do #2 in the open. This is what Mozilla is doing with it's Web APIs. Doing it in the open hasn't slowed them down at all.
- pcwalton 14y ago
  > Anyone (e.g. Mozilla) who disagrees with the fundamentals of the design so thoroughly that they don't want to work with what Google came up with, could create a competitor to NaCl using the same basic idea (native-speed code execution using a pre-checked subset of machine instructions), and their version would have roughly 99% as good a chance of becoming dominant as if NaCl hadn't yet existed. That's exactly what Mozilla is doing: asm.js.
- mccr8 14y ago
  > could create a competitor to NaCl using the same basic idea (native-speed code execution using a pre-checked subset of machine instructions) That's pretty much exactly what asm.js is. It is currently slower, but it is also a younger project. They both even use LLVM as part of their standard toolchain.

derefr 14y ago

> By that time there was no way a third party could have an affect on any of the fundamentals. It's not like NaCl is a market-dominating monopoly format like MS Word .doc now or anything. Going by usage, it's basically still a prototype. Anyone (e.g. Mozilla) who disagrees with the fundamentals of the design so thoroughly that they don't want to work with what Google came up with, could create a competitor to NaCl using the same basic idea (native-speed code execution using a pre-checked subset of machine instructions), and their version would have roughly 99% as good a chance of becoming dominant as if NaCl hadn't yet existed. There are two alternatives when coming up with a standard: drag people through a committee forever to pin down every little feature--or just have one of the concerned parties throw together a working implementation that everyone else can then point at and say "well, this part is good, but that part is crap, I think I'll make a version of my own without that part", and shake thoroughly until a stable ecosystem settles out of it. --- As an aside--it seems like most of the good things in technology (e.g. HTML) come out of the latter process, and yet everyone somehow sees the former as fundamentally "fairer" or something. What's so wrong with making a bunch of incompatible forks, and then competing to merge all the best features of one-another so that your thing will be the "most compatible", and therefore see the greatest adoption? :)

MatthewPhillips 14y ago
> There are two alternatives when coming up with a standard: drag people through a committee forever to pin down every little feature--or just have one of the concerned parties throw together a working implementation You can do #2 in the open. This is what Mozilla is doing with it's Web APIs. Doing it in the open hasn't slowed them down at all.
pcwalton 14y ago
> Anyone (e.g. Mozilla) who disagrees with the fundamentals of the design so thoroughly that they don't want to work with what Google came up with, could create a competitor to NaCl using the same basic idea (native-speed code execution using a pre-checked subset of machine instructions), and their version would have roughly 99% as good a chance of becoming dominant as if NaCl hadn't yet existed. That's exactly what Mozilla is doing: asm.js.
mccr8 14y ago
> could create a competitor to NaCl using the same basic idea (native-speed code execution using a pre-checked subset of machine instructions) That's pretty much exactly what asm.js is. It is currently slower, but it is also a younger project. They both even use LLVM as part of their standard toolchain.