jakub_h

Wouldn't SSDs - and even better system-bus-connected storage contraptions - also drive the use of different algorithms? I can see how merely cutting the disk latencies by two (or more) orders of magnitude leaves you starved for computational resources, but you don't have to do many things at that point. Data packing is different (could be even CPU matched now?), access patterns can be more random, etc.

> When clouds roll in, people are not OK with their TVs turning off. So you'd always need the traditional grid in place, even if it's for a few days a year.

Sounds like a great argument for municipal generation and storage. If nothing else, it's both cheaper than "everyone on his own" and could lesser the strain for long-distance infrastructure (which could still be nice for geographic smoothing).

> So, yes, a huge amount of solar can figuratively blow up the electrical grid.

Demand-controlled EVs could take a lot of the load. In fact, it's probably one of the sanest applications of massive solar installations (beyond the potential of future power-to-gas tech).

> Clinton should at a minimum be banned from handling classified information in the future.

That sounds like a good idea for many more politicians of this world.

Seriously? That sounds like the perfect job for Common Lisp (which appears more or less set in stone in 2016, albeit without the usual concomitant stagnation, given its malleability).

Plus, in fact, I get the distinct impression that your second sentence describes what COBOL actually did for companies decades ago, so the first one makes it sound like a contradiction.

Well, Romans, from what I can tell, had better multiculturalism than Ottomans centuries later. They did not split the society into religion-based classes. So "the West" was quite a bit more progressive centuries earlier in some ways.

> Because cuda matrix multiplication is so optimized that no one with a bit of sense would roll out his own

Really? What if you have, for example, special matrices, not general ones? What's going to be faster, generating a matrix and then running the fastest general matrix multiplication code money can buy on it, or, even a somewhat slower code, but one that can instead use some extra invariants?

> Addidionally, the main issue in gpu kernels is not the ugliness of c itself, but the need to optimize algorithms to the hardware of the gpu, thus making the code much more verbose and ugly than the naive c code.

But that sounds like a compiler issue to be solved. And then you don't have to do it by hand, you let the machine find it out. (And I can't help but think that C is terrible for array based programming anyway. Granted, pure Lua might not be great either for the same reasons.)

With enough libraries, everything fits into a few lines. How big is Parsec itself?

In the same place where there's a horse in a seahorse.

> "descends from a multicultural, religiously tolerant empire (Ottoman)"

Where the terms "multicultural" and "religiously tolerant" apparently mean something quite a bit different from today (just like Athenian democracy from ours, for example).

> 88642ba Fix all the conflicts

> fbd2658 Conflict all the fixes

Sounds like some amount of made-up work!

Well at least the biggest thing they can break now is the gym equipment.

That sounds a little bit harsh (even if I ignore the claims of unsuitability of Go for that purpose). What if I want to write, for example, a Go port of DataDraw? Perhaps with profiling-based memory layout optimization thrown in? And maybe even caching/lazy/caching+lazy collections/maps. If I were obeying your recommendations verbatim, I'd probably still be using mainframe libraries.

One of the points of Go seems to have been the idea of making a Go process a lot like a mini-Unix, with many small programs plumbed together and communicating through pipes, only strong-typed ones (and often by passing ownership of data using pointers, so that you don't have to actually copy stuff). Which uses zero HTTP and JSON traffic, which is faster than even the fastest HTTP and JSON library could ever be.

The reason why Go doesn't (currently?) have a super-performant HTTP server and a super-performant JSON library is that the designers probably didn't envision someone using the language like this.

True, one of the prime considerations for Go's design was that despite having pointers, structs could be embedded as values into other structs. That's the reason it doesn't look half like Java.

Correction: they thought they had to. I suspect that an in-process solution would avoid the HTTP and JSON issues, and better implementation of the store itself would avoid GC issues.

Now that I think about these issues, I'm wondering now how performant AllegroCache is.

> 'He' is sometimes used in this fashion, but it is an uncommon use

Says someone unfamiliar with Indo-European languages in general?

Likewise, the square-cube law could mean that the smaller versions are necessarily less impressive with repect to what you can squeeze into the uninflated volume of the module.

I suspect that https://play.google.com/store/apps/details?id=com.gnuroot.de... is the newer version?

Well, I'm happy with running the basic stuff using GNURoot. (I have no intention of running more complicate GUI apps anyway, even though that should be possible as well.)

It's probably more useful to be able to run Lisp, R, Octave etc. in a device like this.

> Yes, this is why photographers who avoid postprocessing because they're "purists" who like "unenhanced, natural images" sometimes deliver unnaturally bland images. The visual system phenomena at play are high dynamic range, simultaneous contrast, chromatic adaptation, and perceptual uniformity.

I know next to nothing about photo processing but I would assume that because watching a photo print in a random environment is not the same thing as being immersed by the scenery and lighting in the photo, the perception is influenced by that very fact and reproducing photographer's own impression of the scene purely by means of physically correct measurements and their reproduction in form of a picture is impossible; ergo, alterations are necessary.

True. But when it comes to learning the basics of programming, you can always pick better languages. There doesn't appear to a shortage of pedagogically useful ones.

I could take that text more seriously if it at least discussed the limitations of the most powerful embodiments of OOP that we have today and not the accidental limitations of languages that for one reason or the other ended up not as good as they could have and force you to jump through hoops, as evidenced by the very mentions of classes, constructors, private methods etc., none of which are fundamental to OOP but all of which were made fundamental to certain languages.

For a number of reasons, I'm not particularly fond of this specific implementation but I'm seriously considering porting its principles into something else (where they might work even better).

Setting aside the cringe I experience whenever supposed principles of "OOP" are mentioned by the author, that page painfully reminds me of the that old joke about bolting four extra legs onto a dog... Furthermore, both a broader comparison (for more complex data and processing) and the technique I mentioned seems to be absent. However, I suppose it shows how to reclaim at least some benefits of better data arrangement even if the language isn't a good fit.

> "Most stop signs just mean slow down."

Which must be why "stop means STOP!!!" was repeated very forcefully by the driving instructor and the friendly police officer multiple times during my driving course.

Unless you use a DataDraw-like approach, I presume. I can't see templates doing similar amounts of data rearrangements.

> That's a pretty good argument against democracy.

If you pardon a certain amount of sarcasm, it may seem like one to uneducated people.

But I don't think democracy should be equated to dictatorship of optimality. Likewise, personal freedoms are also not about only being allowed to do those things that have the best outcomes.

> They were printed on a long paper then folded onto itself which creates the pages and then stitched in the middle, the folds are then are cut on the sides to free the pages.

Ah, the memories... I recall some of the vintage math textbooks from my high school's library (one of the older teachers had died and willed his personal library to the school, about 12k books). I must have been the first one to actually read some algebra texts because about half of their pages was improperly separated.