I began writing software in the early 1980's in BASIC, Assembly, RPG II, eventually C, Bash, Perl, C++, and PHP along with SQL and more so now JavaScript/Node.j

I began writing software in the early 1980's in BASIC, Assembly, RPG II, eventually C, Bash, Perl, C++, and PHP along with SQL and more so now JavaScript/Node.js, C#, and Python. The truth is, these languages have continually become more complex, more memory bloated, slower, harder to learn, and less efficient to code in. Frameworks have enabled people who cannot write softare from scratch to write applications, too, but very restricted and poor performing. COBOL is still easy to argue as the best overall language for business data processing -- easy to learn, easy to read/debug, and very fast executing. Next up might be Python, except Python is very slow and, although it has nice data structures, it's restricted and clumsy with its data structures. For example, you are kept from manipulating a list while looping through it and are often forced to add excess logic to deal with None Types and such. It's also super annoying to have to type myvar['subvar']['subsubvar'], etc. Third up I would say is Node.js. Performance and object/data structure flexibility is very good. The only problem--and it is a major problem--is that asychrony is forced upon you even while working with SQL databases. This very much complicates data processing to the point of not being practical at all for any kind of fluid business processes (where you have to read and make changes on a regular basis). I have also spent a few years writing in Microsoft JScript.Net. While almost nobody else uses this language, I found it to be far superior to C#, Java, or really any other language for business data processing except for performance. It performs as well as C# or Java and is far more readable and efficiently writable but the Microsoft dotnet CLR (Common Language Runtime) that underlays all dotnot languages has no real support for variant data types. Instead it instantiates a generic object for each which is very expensive on memory and performance. This experience is what got my originally interested in Google's V8 JavaScript JIT-compiler and eventually its derivative, Node.js. However--and even though I use Node.js heavily, this also leaves me with a rather large feeling of tragedy that Node.js maintainers are so dead set against sychronous access to SQL databases... It is a huge loss.