Clearly, they would know that a Cretan is just a Minoan a large pool.

Seconded.

Mojolicious is an excellent back-end or middle layer (depending on your data needs), mostly because it removes the need for many of Perl's more infamous convolutions and contortions. With a bit of Bootstrap and/or AngularJS on the front end, you can get a useable online service put together in a very limited amount of time.

Well, to be fair, climatologists have always been a little dubious about Swedish farmers, too....

As a pilot once sagely put it: Take-off is optional. Landing is compulsory.

Sit down, my child. This may take a while....

I started writing web apps in 1994. Using CGI.pm in Perl was pretty much state of the art - and the art wasn't very pretty. ColdFusion appeared shortly thereafter, but only supported basic control structures - no functions or even subroutines at the start. Then came ASP and a disastrous mishmash of security holes, ActiveX objects being called from the only thing worse than PHP for tag soup with spaghetti code for filler. PHP, for our sins, went from being a 'hey, kids, look - I made a web page!' app to an actual application platform.

.. and the list goes on.

I've lived through the browser standards wars, I've seen such sins committed in the name of the Web that I would wake up screaming, 'Why, Tim Berners Lee?!? WHY???!!' I've lived through <BLINK>, Flash, animated GIFs, <MARQUEE>... and other monstrosities whose names Shall Not Be Spoken.

I've used JavaScript since it was a toy.

But this, my child, is the key: It's not a toy any more. Finally, after two decades of stumbling around blindly, wreaking more chaos and mayhem than a shirtless, drunken Australian on a JetStar weekend in Bali, web development has finally matured. A bit. It's learned that being cool doesn't earn you nearly as many friends as being useful. It's learned that a guy's gotta eat, fer Chrissakes, and sleep from time to time. It's learned that popsicle-stick bridges may be neat, but won't carry the load that a boring old concrete one will.

But, as the scripture says, 'then I put away my childish things.' Oh, it's true that just because we've grown up doesn't mean we've learned every lesson ever. It's true that we Web Developers still get seduced by Teh Shiney. But all in all, we've grown; we've lost our innocence and our hair. But we sleep at night. And we parallelise. And we scale. We're grown-ups now. With grown-up tools.

So put down your PHP child. It's really just Poorly Hung Perl. Accept that JavaScript is a language. REST in your Bower and accept that some change is for the better.

I couldn't agree more about Slashdot curmudgeonery, but the real problem is when that quote comes from the mouths of teachers. Which it all too often does.

Based on my experience (10+ years) working in ICT in a developing country, I think that this plan is:

1) Very audacious; and
2) Very likely to fail. These things work well in micro scale (because of committed individuals), but are very hard to systematise, because of 'I'm old and I don't like this.'

I was thinking more about tweaking the summary to read:

"Researchers recruited 27 men and women to spend several nights in a sleep lab, located on Elm Street. Each night, the surviving volunteers were plunged into REM sleep..."

As a 50-year-old, I'm inclined to agree with the statement that there is such a thing as too many tools, but not for the same reason. Expertise and experience are important, no question about that. But both are often easily transferred from one language or framework to the next. For my part, I'm quite enjoying working with NodeJS, Angular, NoSQL and a bunch of things that take significantly different approaches to problems I've been solving my entire career.

But a problem I face quite often these days is trying to apply the toolkit approach with newer software. On any decent POSIX-supporting platform, you can generally leverage libraries and modules for just about anything and still expect at least a modicum of consistency. Each tool has its own quirks and foibles and strengths, all of which need to be understood, but with a bit of time and perseverance, these can be coped with.

But the application I'm working on right now requires the integration of an Angular framework with UI elements derived from JQuery, D3 and Bootstrap as well as one or two products of the inspiration of some young developers who are clever but sadly too confident in their own abilities. Trying to reconcile them all has resulted in a LOT of time spent pondering, refactoring and coping with bugs that inevitably result from using the tool in a way that wasn't foreseen by enthusiastic but inexperienced developers.

So far, the benefits have outweighed the costs, but there's a fine line between saving time by appropriating others' tools and wasting time shaving a very big, hairy yak.

I like many of the new technologies I'm using, and I love learning new tricks, notwithstanding the few grey hairs remaining on my shining dome. But yes, there is such a thing as too many tools. And many young developers these days are going to have to learn that the hard way.

Not to take away from your argument, but that statement is incorrect. The very first copyright law was "An Act for preventing the frequent Abuses in printing seditious treasonable and unlicensed Bookes and Pamphlets and for regulating of Printing and Printing Presses."

In other words, its original motivation was to limit the ability of people to print whatever they liked - in other words, an engine of censorship.

The US Constitution framed the rationale for copyright differently, as did French copyright law, which introduced the concept of 'droits d'auteur', or authors' rights.

Don't worry, they're going to name the executable 'System Idle Process'. :-)

Because for the majority of the world's population, there simply is no legal way to obtain this stuff. I live in a country where the majority of the population cannot get a credit card, and for whom internet is a luxury beyond the means of most. But even for people like me who have full-time access, the prospect of actually paying for things is a daunting one. Many companies simply won't accept my credit card; virtually none of them ship to my country, and a number of software makers (I'm looking at you, Apple & Adobe) don't even admit that my country exists.

Someone who goes to the lengths required to maintain a VPN presence and a subscription should be welcomed by the industry, not cast out. But instead they drive us back to our shonky screeners purchased for a buck at the local Chinese store.

I'm not really taking issue with your conclusion, but a decent quality 50mm lens (widely known as a portrait lens because of its shallow depth of field) can be got new for about $200. And I got a beautiful 1984-vintage 105mm prime lens for $250 a few years back. It's an exception to the rule, yes, but sometimes the glass is less expensive than the camera body. That said, if you've got good lenses, they can make up for a lot of shortcomings in the camera body.

My own feeling about algorithms such as this is that they'd be better off chasing the ideal of perfect focus for everything - or better yet, for pseudo-3D renderings - those would be more desirable goals, IMO. I suppose it's possible to get the same effect as really good glass, but something tells me the laws of physics (well, optics) will always win over computed logic.

In C, a Hungarian string manufacturer. :-)

Those are good reasons, and it's also true that CouchDB will use a lot less resource overhead than a full-bore RDBMS under load. Depending on the use case, it might also prove decidedly easier to scale.

But the place where NoSQL really shines is storing amorphous or heterogeneous data. Because you have no constraints about what goes into a given record, you can record more or less name/value pairs at your whim. As with Perl, though, freedom comes at the cost of potential disorder.

But honestly, with the tiny amount of detail provided, it seems like it's really six of one and half a dozen of the other. If it's just call data being recorded, and the same call data every time, it won't make a huge difference if you use a full-blown RDBMS or a NoSQL database. Either one has its costs (individual PUTs and POSTs in CouchDB for example, can be expensive, whereas queuing and write contention might cause headaches at extreme scales in PostGres or Oracle).

Both an RDBMS and a NoSQL database will deal with replication fairly well, though my personal inclination is to prefer the simplicity of replication in CouchDB right up until the noise level gets out of hand.