> Step 1. Pick a language.

Since the focus seems to be on web backends (given the section following this one), I'd imagine that trying to use C or C++ for such a thing would not be one of the obvious choices.

Also, you've listed Scala twice, I'm pretty sure Xhp and Hack count under PHP, and God help you if you opt to use ColdFusion or ASP.NET (or PHP, for that matter) in anything new.

> Step 2. Pick a framework for the selected language:

Once you've picked a language, you can usually narrow down the selection quite a bit. For some languages it's a bit harder, but for most, the choices are manageable.

C/C++ -> Raphters, CppCMS, WSO2, Wt, ffead-cpp

Go -> Revel, Martini, Gorilla

Java -> Spring, JSF, Struts, GWT, Play, Grails (if we count Groovy as Java), maybe some others that I haven't heard of yet

Ruby -> Rails, Sinatra, Padrino (which is basically Sinatra plus some helpers for databases and views), camping (if anyone actually uses camping in production, please let me know)

Python -> Django, maybe some others (but Django's the only one I hear about regularly)

Dart -> does anyone even use Dart? I'm pretty sure even Google has moved on to Go for backend stuff, and the plan to integrate Dart with Chrome was apparently cancelled.

PHP -> Laravel... I can't think of any others that I've actually seen used. Pretty much every PHP app I've encountered was CGI-based.

Erlang -> YAWS or ChicagoBoss. If you're counting Elixir with Erlang (we might as well), then we can throw in Phoenix and Sugar.

D -> vibe.d is the only one I know of

Javascript -> Node.js, probably.

Perl -> Catalyst, Mojolicious. Or just use (Fast)CGI.

Scala -> Play, Scalatra, Lift, Sweet, Slinky

Clojure -> Compojure, Webjure, Conjure, Moustache

Lisp -> (Common -> Weblocks, possibly Hunchentoot), (Scheme -> SISCWeb (via J2EE)), Racket

ColdFusion -> ColdFusion. I don't know if ColdFusion doesn't instead count under the Java category, though.

ASP.NET -> I dunno, ASP.NET?

Basically, once you have a language picked (based probably on which one looks the best to you), it's pretty straightforward to search the web for "$LANG web frameworks" and find some sort of comparison between them.

> Step 3. Pick a database:

If you're not picking PostgreSQL, then you're wrong, end of story. Maybe CouchDB or Mnesia if you know for sure that you need their replication features and are aware of the tradeoffs of using a non-relational database.

SQLite deserves special mention, because while it's absolutely wonderful for end-user applications, it's not at all ideal for server software except for specific use cases (like using it as an offline data storage format, e.g. for backups or data imports/exports).

MongoDB, Oracle, MS SQL Server, and MySQL also deserve special mention because, if you're using them willingly in a new application (other than to interface with a legacy system that did involve such a regrettable choice), you're probably not right in the head. In particular, there's pretty much zero reason to use MySQL instead of MariaDB (which is also arguably marginal due to its MySQL heritage, but at least it's slightly better), using a commercial database like MSSQL or Oracle is basically begging for vendor-lock-in-related problems, and MongoDB... Jesus fuck-me-in-the-ass-with-a-pogo-stick Christ. Might as well just pipe your data to /dev/null while ranting about how it's "web scale" while we both transform into 3D-animated bipedal animals and I resign from my job as programmer/sysadmin and go shovel pig shit for a living.

> Step 4. Pick a hosting provider: Classic or Cloud and pick from just several hundred providers with different APIs and architectures.

If you're smart, you'd go with Cloud Foundry, since a large number of PaaS vendors support it, so you can pretty much just pick whichever one has the best bang for the buck (might I suggest IBM Bluemix?) and use the `cf` tool to deploy to it.

Additionally, if you're using containers of the Docker variety, the vast majority of PaaS and hosting companies nowadays support them with little to no modifications, so - again - the choice matters very little beyond one's priorities regarding performance, location, and cost.

> Step 5. You're all set! Enjoy your backend. Now it's time to pick a front-end !

Now that is a massive can of worms. So many frontend frameworks. So little time. And pretty much all of them constrained to the quirks and pains of Javascript.

Of course, you could just go with straight HTML and CSS (plus a smattering of JS using JQuery or Mootools), which is what I generally prefer to do in most cases.

Nice write-up. I hope you do understand that the original message was a sarcastic joke.

The point was - there's just so many technologies to consider and it's been just 15 years.

When I got my first PC, my choice was: MS-DOS 3.3. QuickBasic, Pascal, C or Assembler for writing programs.

There might have been other stuff, but I had no access to it. Ditto for documentation, tutorials or books.

Things have definetely evolved and if the rate continues, we'll have thousands of languages/frameworks in the next decade, unless something absolutely mind blowing comes up and replaces everything forever.

> I hope you do understand that the original message was a sarcastic joke.

I'm aware. I just like taking things needlessly seriously. It's a hobby of mine :)

> When I got my first PC, my choice was: MS-DOS 3.3. QuickBasic, Pascal, C or Assembler for writing programs.

Indeed, though those weren't the only choices even back then. Lots of different microcomputers, all with their unique dialects of BASIC, up until the late 80's and early 90's, when the diversity died off and IBM-compatibles became the norm.

Really, the current evolution in software is more just a resurrection of the diversity once strong in the realm of computers. Back then, one would actually have to make conscious choices about CPU architecture of all things; nowadays (for better or worse), we seem to be resigned to the idea of big machines being x86(-64) and little machines being ARM or maybe MIPS.

Not to say that languages weren't diverse back then, either. You still had Lisp and FORTRAN and COBOL and Forth and C and assembly and PL/I and ALGOL and Pascal and Logo (turtle power!). A little later there was C++ and Perl and Tcl to join them as some others faded out.

Basically, the evolution now is less about the quantity of platforms to develop for and more about the accessibility of those platforms. Pretty much all the good ones are open-source, available on the internet, and have plenty of online documentation. The free software and open source movements have been a boon to those seeking to get their foot in the door.

> unless something absolutely mind blowing comes up and replaces everything forever.

I suspect that "something" will either be artificially intelligent or pretty damn close to it. Development time and effort will decrease substantially if a programmer can just tell his artificially-intelligent software maker what the program needs to do - in a natural language - and the software-maker goes and makes a program. I suspect there will be a couple of stepping stones before that, including some existing stepping stones that we've already walked on. One of them is LLVM, providing a common core that any language can use with relatively-few obstacles. Another is the concept of programs that create other programs; languages like Ruby, Tcl, and Lisp facilitate this quite well, and it's probably a matter of time before those and similar languages are used to do things like automatically generate HTML/CSS/JS for web apps (as one example of potential usefulness in the short term). Natural language parsing by artificial electrical systems is getting better and better, too.