Every few days there is a post on my Google stream that says “best programming languages for 2019”…“worst…”, “top 10”… and so on. WHAT A COLOSSAL MESS!I’ve been a programmer for over 35 years and so I’ve seen the birth and death of many languages, operating systems, system designs, and system principles. Just for some scope I have implemented commercial level hardware, firmware, operating systems, UI, scripting, databases, network security, about 30 different languages including internals and so much more. I’ve seen the birth and death of smalltalk and macro assembler and the COBOLinazation of Java. Maybe I know a thing or two.A few years ago I started work for a client that wanted report after report after report. None of the languages available have any sort of framework or even best practices that could be used to pull data from a database, analyse it, and then export it to any sort of file. Then there are other needs like scheduling, scaling, monitoring and so on.At the same time we were looking for some flow based programming based on what we saw with NOFLO and the related projects. Javascript was not the answer because it was still single threaded and given the amount of DB round trips it was not practical to work that problem.While years earlier I worked for an employer that was heavy into DSLs they got it wrong. They were trying to work inside the likes of Java and C# with all that heavy lifting to create languages that might do all that Touring magic, however, 99 times out of 100 most of the work comes down to simple scripting.Lastly I carry two bookmarks. The first is tcl. First of all SQLite’s testing framework is implemented in a variation of tcl. WHY? Well because the SQLite author was also the tcl author. Second because the tcl interpreter is simple, small, lightweight. While modern tcl is powerful and has plenty of APIs the API syntax can be implemented in about 500 lines of C or Golang code. It’s also extensible. And in the case of Golang it’s really easy to layer even more 3rd party APIs.The second bookmark dates back prior to PCI and in the early days of Java when I realized that even though the jar file contained the language bytecode I could also store the source code. And in this way if I received a bug report I know exactly what the state of the source was. I could implement an air gaped patch and preserve the chain of evidence.I’m not sure why programmers get all wrapped up in ideas like generics. My favorite argument is Object Oriented. For example inheritance is cornerstone themes in OO. The problem is as soon as things they complicated everything starts to fork. For example in the reporting system I designed there is a common set of about 700 SQL queries. For the most part they are thematic…. several based on orders, customer, payments, and so on. The DSL is also divided up by function like “find the first order” and “print orders”; separating work from I/O.Every once in a while someone will say, I need “customer language” on the customer report. Step [1] is check the work and make sure that the language data is being retrieved and if not add it and check the query performance. This change will now be inherited by all the reports when they are regenerated. Step [2] add the language to the output function. If that’s a common function then when the other reports are regenerated they will inherit that change. So now we need to know the impact and whether that’s important. So sometimes the output function will be versioned. Sometimes the function is parameter-ized.And there is a secret 3rd bookmark. Ruby. The syntax is fine but the ability to do modify code at runtime especially inherited code make it impossible to debug. Sure the elite programmers avoid the big mistakes but the crazy Ivans just make a mess.In conclusion we only need simple syntax like tcl, LUA, even BASIC, COBOL or Fortran; to get the work done. We can add syntax and API for things like databases, user interfaces. One thing for sure is we go not need a complete new syntax to add ideas. For example we did not need to add tabs to perl in order to get python. Instead of forking the perl community to a python they should have made a simple perl that expressed those ideas.And if you made it this far then there is a fourth bookmark. “readable code” It’s an idea put out by Knuth. So my idea is that markdown should be the document container for the next language framework. Markdown is readable in both source and rendered form. While there is something called the python notebook and the R notebook these are almost what I’m referring to. I have not gotten there yet. I’m also not interested in python or R syntax at this point. I also have over 1700 reports that would have to be migrated and that in itself needs some management.