Unless the argument is that we need another big wave of even weaker tools, it feels unnecessary to give this sermon in 2015.
(I invite people who disagree to express something concrete in reply.)
A finite state machine can easily be made basically un-debuggable by human beings.
It's just ... maybe it's the crowd I hang out with, but I feel like these ideas have already totally won.
BER does have "constructed values" which are most 'obviously' parsed recursively. OpenSSL handles this via C macros that unroll the parsing 7 levels deep, but no more.
(What does it do when given nested constructed values? Well-- when its expecting an integer it goes and traverses into the constructed values in a particular order, pulls out the primitive types at the bottom, concatenates their bytes, and treats the result as an unsigned integer. ... Why? Because this is precisely the kind of madness that happens when you deploy a 'too powerful' language! :) )
Nonetheless, one doesn't have to be a LISP weenie to see how messed up things are. LISP, REBOL/Red, the 4GL's on top of BASIC, etc... these all showed that a simple core language could be combined with macro-like features to keep expression clear, performance high, integration problems low, and boiler-plate low to non-existent. The opposite of the Java ecosystem.
A maintainability win is concise code that gets the job done and fast. Mainstream languages aren't it. They just want too many features to do too many things. Go is the exception is it follows the Oberon tradition. It's too simple imho. Julia is the most interesting language of recent times in balancing productivity, performance, macro's, safety, legacy compatibility, and maintenance. And, of course, it's Lisp underneath. :P
2. Do we really wish HTML were Turing complete? LaTex gotta be Turing complete? The author isn't really saying everything has to be underpowered and take 2000 lines to do what 100 lines of Python can do.
3. "Right tool for the job" is the slogan that could defuse about 90% of the language wars. Instead of saying "HTML is better than Lisp" and trying to start a flame war, I could notice that sometimes I just want to mark some stuff up. I don't always want to debug my text.
Irrelevant to the claim I made. You pointed out Java as a straight win for both variant of Pascal philosophy and maintainability. I countered that this wasn't true given Java was inefficient for over a decade, very hard to port, bloated, hard to understand, and anything but easy to maintain. I gave counter-example of Modula line, esp Modula-3, that was easy to totally understand, consistent, fast to compile, easy to port, cpu/space efficient, and supported most features industry needed for programming in the large. Java got popular due to social and political reasons on top of massive financial push by Sun. It's technically crap. Latest Modula-like language is Go and most Java programmers experimenting with it write like it's a breath of fresh air. That's due to Java problems more than Go strengths but Go embodying Pascal line's good traits helps.
Although, there's irony in you citing Java while critiquing LISP: Java co-author, Guy Steele, said one of Java's successes was dragging some C++ developers half-way to the capabilities of LISP. Implies he knew both technically inferior to LISP even when designing Java to replace C++. ;)
"Do we really wish HTML were Turing complete? LaTex gotta be Turing complete? The author isn't really saying everything has to be underpowered and take 2000 lines to do what 100 lines of Python can do."
I'm sorry to deliver the news but the fools did it anyway:
http://lemire.me/blog/2011/03/08/breaking-news-htmlcss-is-tu...
Also, representing HTML actually takes less in Scheme due to HTML's complexity and redundancy. Same for XML. See here:
https://en.wikipedia.org/wiki/SXML
That's not your point, though, so I'll focus on it. We have two major approaches we take here: a limited language like HTML that's not Turing complete and which we extend all around with Turing complete languages; a Turing complete language with a subset, even equivalent to HTML, that's not Turing complete but lets you have a great, highly-integrated & client/server-consistent language when you need that. Simplest version of the 2nd category is one of the Scheme web application systems that leverage a form of HTML with ability to transform and present it only limited by Scheme's power. Use simple version if you can then use Scheme otherwise. Can do something similar with function calls in other languages that correspond to HTML, building up an AST to output static or dynamic content.
""Right tool for the job" is the slogan that could defuse about 90% of the language wars. Instead of saying "HTML is better than Lisp" and trying to start a flame war, I could notice that sometimes I just want to mark some stuff up. I don't always want to debug my text."
I try to avoid them and convey information instead. My point the whole Turing complete vs incomplete is kind of a false dichotomy where we can't have both. HTML can be a DSL and is in many real works. LISP isn't required there although macros & easy parsing are a great aid in any language for DSL's. Rebol, Forth, and Julia can do it that I'm aware of. That almost nobody uses pure HTML w/ no server-side anymore shows it wasn't adequate. Led to proliferation of worst stack of Turing complete crap I've ever seen with a few exceptions sprinkled in.
So, what to learn from the mess and how to do it better next time? A powerful client- and server-side language with easy syntax + HTML DSL seems like it would've been the best option. Was done by certain groups in fact while delivering on its goals. Let's one default on safe & simple while incrementally adding on with consistency, performance, and power [where necessary]. Or an integration of a bunch of Turing incomplete DSL's for the crowd that loves those.
oh well. I'll just have to write some Lisp tonight. :-)
Things were saner in 1990. Arguments about whether C was "better" or "worse" than Lisp, without giving any application space, tended to fall on bored ears.