Lots of them. A few hundreds, I think. Viability may depend on site. But if there's space nearby for a reasonable array, there doesn't seem to be any reason not to use it no matter how small it gets (any size will result in savings), unless your electricity is dirt-cheap, or the place is so infrequently used that for a significant portion of the time, nobody is charging (which would waste a portion of the local generation and worsen the ROI).
But Java conceptually has a lot of drawbacks that require the JVM to have screaming performance to compensate for. Almost everything being a "headered" object being probably the worst offender. Even a slightly worse Go compiler is probably well compensated-for by denser data structure layout in the operating memory.
The problem is that software works the same every time, hardware doesn't have to (for example, if there was some kind of wear in the umbilical, for example).
> "Do you guys mean template/rule/pattern based when you write AI-powered? Once in a while someone posts something AI-powered and I will immediately check is there any breakthrough in this field, after testing product will get disappointed. ... And all of them should be in automated/intelligent way, not ..."
In my home, a single Powerwall battery could cover 90+ percent (or perhaps 95+ percent?) of nights even in an off-grid arrangement. Covering the rare extremes with a $150 generator would be more cost-efficient than using a larger battery, and likewise, covering the usual case with a battery would be more cost-efficient than running all nights inefficiently using our $5/USgal gasoline.
I'm wondering if torrents as such are actually useful for this. I'd figure some kind of virtual file system (perhaps based on BitTorrent) would be very useful. You'd simply pass a file path to an open() routine in your scientific code and data would get opened transparently. You currently have this with URLs and HTTP but there's no useful caching or data distribution.
I never understood Excel or any other spreadsheet's database features (as in "why such a convoluted thing?") but we did have set theory in high school. There must be better environments for such data processing tasks. If there isn't, one ought to be devised. (There used to be DabbleDB for some time, but that's gone now.)
I suspect that Oberon wants you to roll out your own text library. It's actually how C probably wants you to roll out your own string library, too, because "C strings" are no better than Oberon's text facilities. The problem is that nobody knows how you want to work with your strings. There doesn't seem to be "the one correct way" to work with texts. Gauche Scheme, for example, has an interesting take on strings (http://practical-scheme.net/docs/ILC2003.html): backing arrays are shared and substrings are O(1), semantics for Scheme strings is observed - mutability is still possible but expensive, thus also gently discouraging the programmer from using it.
Just compare the price of a solar panel with the price of coal you'd have to pay for in China. That's the uppermost possible limit of what you could expect for CO₂ emissions if you didn't have to pay for anything else. Just conveniently assume all your workers and other raw materials are free. ;) You can probably buy two tonnes of coal in China for the price of a ~250W solar panel. That gives you about 4000 kWh of electricity. At a 15% capacity factor in China, the same panel can generate at least 6500 kWh in 25 years, even including quite substantial degradation. So if used to offset electricity generation within China, it's neutral after 15 years.
In reality, it's most likely much sooner because you don't need 4000 kWh of coal electricity to manufacture a 250W panel; you have to pay your workers and raw material suppliers instead.
Even in a 100%-coal grid, I don't think it's likely that >1000 kg CO₂/kWp is necessary. German manufacturers can achieve 400 kg CO₂/kWp in the still-rather-mediocre German grid.
In the US, I'd image tariffs on panels having a much lower influence then elsewhere in the world. Even if panels were completely free in the US, a US-based residential solar system is going to be more expensive to install than even European ones (including European panel costs).
Yes, but it was defined after actual assembly/low level languages like BLISS. So it was defined as a way of doing something "assembly-like" (or BLISS-like, or BCPL-like) in an environment that didn't allow for such code.
The guy who was looking half a year for a bug in his code and then half a year for a bug in GCC (or something like that) only to find out that it was a bug in an AMD CPU.
One could make a number of arguments about at least half of these. Racket/PLT has been free for a long time but ten years ago, a friend of mine simply left it for Common Lisp for the sole reason of speed. Gambit is great - I'd say almost as good as Chez - but there's no proper modules or native multi-threading. The Scheme->C model is also cumbersome; reintroduction of a native compiler was promised but if I'm not mistaken, still hasn't happened (although some other interesting things did - the recent mobile code support is very interesting!). T was a research vehicle but apparently the closest thing to an accessible environment for it was A/UX on Mac. Say what you want about IBM PCs but they won.
Earlier accessibility of a top Scheme implementation could have helped make it more popular earlier. Just like with Smalltalk and Common Lisp before which also got into trouble because of good implementations being out of reach of most people.