gngeal

But I'm a Luddite, though; I like self-hosting native compilers and I'm not terribly fond of the idea of having to pack a 20MB blob of C++ code with my code either. (There's a lot of apps that could profit from dynamic translation at run-time, but using LLVM for that feels unnecessarily heavyweight. I wish the algorithms and passes from LLVM were available in form of some high-level DSL that you'd be able to translate into whatever language you use and automatically adapt to whatever data structures you use in your code. It doesn't sound exactly impossible.)

I'd have thought that deterministic builds are really simple unless your toolkit ecosystem is FUBAR. After all, a compiler is a simple function from input to output (unless the FUBAR ecosystem syndrome arises, as I said).

"Reduce inventions to practice?" First, I don't think that my country has any such legalese in our patent law. Second, what does that make NVIDIA? Or ATI? They don't make their own chips either. Third, I believe that what is protected by most of these patents are neither HDL files nor the chips but rather specific implementation techniques for parts of the HDL implementation of the ISA. If the chips were patented, it would be worthless because you could do an independent design.

SSH is great at least in the sense that it's configuration-format-agnostic, mostly-OS-agnostic, client-side-automation-agnostic, and many other things like that.

Oops. I meant "seen technically", not "seen socially".

I think it's more likely that in 10 years, Go will be the new Java.

I'd rather think of Go as the new C. :-)

Also, as far the "do more with less" and "no nonsense" stuff is concerned - have you seen the spec of Java on one side, and the specs for Go and Oberon on the other? There's quite some difference.

In ten years, Go will be seen as what Oberon is seen as today: essentially all the things you mention, plus the fact that there will be a dedicated community of people who like the no-nonsense "do more with less" approach that is peculiar to this family of languages and don't want to live without it. Plus, Go will most likely have some evolutionary continuation anyway.

Except that you do. You've just said it yourself! What the for command does in Python is essentially running two communicating coroutines, passing control between them. Yield-using generators actually make it very explicit, by creating special resumable stack frames. The only difference is that in Go, you're not limited to a single stack frame in the producer, nor do you have to use a loop or the new PEP-380 "yield from" syntax (for example, if you're iterating over a tree). The blocking channel takes care of the execution sequencing. (Also, in Go, the channel makes it possible for the consumer to use multiple stack frames, if you're re-building another data structure instead with the data you receive from the producer, but that seems to be a rarer case. It's a nice symmetry, though.)

Why don't they vet the results instead of vetting the people? Isn't that what matters? Not even the Soviets believed that the grain imports from the US were poisoned in order to kill them.

Any reason why doing this with channels and goroutines doesn't fulfill your requirements?

Both sides will simply send an adequate amount of people into disintegration booths. No blood necessary.

My once-inflamed pancreas says otherwise. :-) I guess there's no one-size-fits-all solution to that.

I think it's not as much a matter of making an FPGA that would be easier to program as it is a matter of coming up with an order-of-magnitude of improvement in programming techniques. What you're demanding is not far removed from saying that better programming models require improved transistors.

If there's a simple window, you can kill everyone along the wall by a simple application of a high-precision-timed grenade. "Explode 50 cm behind the window" is simple to achieve these days: http://en.wikipedia.org/wiki/XM25_CDTE , http://www.youtube.com/watch?v=Fgh4uy5A-lI

The idea of one robot having one (potentially flawed) operator seems exceedingly dated to me. In conjunction with AI and dynamically created battlefield models, we could relegate the human brain into making those decisions that human brain is good at ("that's a terrorist, and that guy is a civilian") and let machines do their job at what they excel at ("let's use drone 17, it has its barrel only 7 degrees away from the target, already moving in the right direction, and can hit it within the next 700 milliseconds").

Lavabit was the middleman in the communication, not the end; or was it?