``...software engineer in the 1980s, writing hundreds of thousands of lines of ALGOL, FORTRAN, COBOL, and Pascal programs, as well as working in 370 and 8080 assembly language & pre-relational DBMS systems.... I wouldn't know where to start learning C++, PHP, Java, HTML5, or PERL, much less how to choose one over the other for a particular application....''
--------
Random rift from an old luddie follows...
This is hilarious. Poor bastard. I actually got about half way through a two part series in the first list above back in 1981-2 going to nightschool. I confess a certain nostalgia for the simple process and direct application link to accounting, payroll, and inventory, the actual infrastructure of corporations and governments. The user interfaces were a card reader, or a TTY, or a terminal running on a modem with phone cups... I started in Fortran VI because UCB had a CDC 6600 in the basement of Evans. (Just checking...) Fortan is still in use in giant number crunching applications like weather, astronomy, climate modelling, and probably the vast NSA spy telcom system etc. Reading through the wiki, I see the Fortran develop tried to follow each era's dominant paragdim...
To answer this guy's question, get a box running Winsuck and a unix like OS that should include PHP, PERL and the C,C++ compilers. Java is now under GNU, but I bet you still have spend hours figuring out which parts to download from the amazingly bullshit Sun-Oracle web... and assemble your own development environment. Use a combination of Wiki, W3C, and W3Schools for tutorials and documentation. Put your sample projects up on a web page and use that as your resume with links in an email. (This will do no good, since the first question will be, yes but do you know the XP or OSX or some other commercial production environment...fuck you.)
About six years ago I actually got java (jdk, jvm, etc) to work on a freebsd box and then hand wrote little html wraps to do stupid baby things. (java-html is pure evil, scripts for nested relational objects embedded in a gui...unintelligible gibberish.)
It's like jumping in a fast moving river and very similar to learning the latest web tools for graphic design. In fact they are the same since one is the technical infrastructure to support the other, where the ultimate product is a jerk-off pop-up animation or video ad gizmos (or virus) you get when you try to actually read something on a web page.
My hypothesis is that Google is the current emperor of evil---stole the crown from M$uck. Their sort engines perform on the basis of how much crap is embedded on the site...the more crap, the greater likelihood it will be near the top, i.e. delivering content. Here is a nice note on HTML5:
``The Web Hypertext Application Technology Working Group (WHATWG) started work on the specification in June 2004... the specification is in the Draft Standard state at the WHATWG, and in Working Draft state at the W3C. Ian Hickson of Google, Inc. is the editor of HTML5.[2]''
http://en.wikipedia.org/wiki/HTML5
The beauty of the ugliness of it all is to realize you can creat an almost infinite number of objects and objects within objects, little wind-up tinker toys, with almost no limit to inheritance (graphs) and nesting (of objects)
(Something about html tags, tag soup, and code bloat machines went here, but I deleted it...)
So in a minor way, I've tried to follow the conceptual jumps from top-down (proceedural), to structured (modules), to relational (objects). You can conceptually follow this by imagining the early flow chart with loops (FORTRAN), then modular trees (C, C++), then graphs for relational objects(Java)...
I imagine a tribe in Java Island paradise where everybody fucks everybody else with no incest taboo, and the offspring start fucking as soon and as often as possible with as many as possible. Now given a few generations, some concerned group of young Christians decide to figure out the kinship relations for everybody on the island. They give up and hire the Chinese Postman...
Practically every asshole software corporation uses its own jargon which makes communication, maintenance, and documentation amazingly difficult. The documentation becomes its own concurrent application...And the great communication competition (of perception) is whose jargon will win...
Other issues...the inter-relationship between servers, OSs applications, interfaces, and implimenting systems has become so complex, you need yet another software `suite' devoted to just figuring it out.
Stop Chuck, stop. Step away from the keyboard...
CG