3 ms·

So, great, this is the mainstream view. It won. We got Pascal, that philosophy mutated into Java and here we are. It takes lots of code to do stuff, and that's

So, great, this is the mainstream view. It won. We got Pascal, that philosophy mutated into Java and here we are. It takes lots of code to do stuff, and that's universally scored as a maintainability win. All right. Who disagrees? Little pockets of Lisp hackers up in the hills? 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.)

alricb 11y ago
One example would be a language to deal with TLV data, like ASN.1 DER (e.g. TLS certificates). Currently most TLS libraries use C, which is insane, but in principle, you don't even need recursion to parse DER data; so even vanilla Haskell is overpowered for the purpose.
- mcnamaratw 11y ago
  Yeah, for sure, in a lot of applications you really don't want people chanting "code is data, data is code" and building impossible shit that nobody can figure out. 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.
- nullc 11y ago
  Fun fact; what these things implement is more general than DER; a sub/superset of BER. 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! :) )
pnathan 11y ago
As a lisp hacker in the foothills of WA, I think that the OP's article is fairly stupid. I'm over here on the extreme; I wish that my types had more power, that I could do more things with my Lisp macros to more deeply affect live functions. The thing I'm always looking for is how to say more with less, with more expressivity, with more power, and more clarity, but with less code, less complexity. oh well. I'll just have to write some Lisp tonight. :-)
- mcnamaratw 11y ago
  I feel like it's horses for courses. Of course there needs to be a mark-up language that's not higher math. Of course that doesn't mean we should all program in Pascal. 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.
nickpsecurity 11y ago
The number of people moving away from Java due to it's difficulties in coding, performance, and maintenance contradicts your claim a bit. You might have done better with something in between Java and Pascal like Modula-3 which was still understandable across the board. 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
- mcnamaratw 11y ago
  1! People moving away from Java is interesting, and we may see a surprise coming up. But do I really have to go and look at the charts with teh Popularity Bubbles to find out whether Java is still a bigger part of the landscape than Modula 3? 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.
  - nickpsecurity 11y ago
    "But do I really have to go and look at the charts with teh Popularity Bubbles to find out whether Java is still a bigger part of the landscape than Modula 3?" 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-turing-complete/ 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 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.

alricb 11y ago

One example would be a language to deal with TLV data, like ASN.1 DER (e.g. TLS certificates). Currently most TLS libraries use C, which is insane, but in principle, you don't even need recursion to parse DER data; so even vanilla Haskell is overpowered for the purpose.

mcnamaratw 11y ago
Yeah, for sure, in a lot of applications you really don't want people chanting "code is data, data is code" and building impossible shit that nobody can figure out. 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.
nullc 11y ago
Fun fact; what these things implement is more general than DER; a sub/superset of BER. 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! :) )

pnathan 11y ago

As a lisp hacker in the foothills of WA, I think that the OP's article is fairly stupid. I'm over here on the extreme; I wish that my types had more power, that I could do more things with my Lisp macros to more deeply affect live functions. The thing I'm always looking for is how to say more with less, with more expressivity, with more power, and more clarity, but with less code, less complexity. oh well. I'll just have to write some Lisp tonight. :-)

mcnamaratw 11y ago
I feel like it's horses for courses. Of course there needs to be a mark-up language that's not higher math. Of course that doesn't mean we should all program in Pascal. 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.

nickpsecurity 11y ago

The number of people moving away from Java due to it's difficulties in coding, performance, and maintenance contradicts your claim a bit. You might have done better with something in between Java and Pascal like Modula-3 which was still understandable across the board. 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

mcnamaratw 11y ago
1! People moving away from Java is interesting, and we may see a surprise coming up. But do I really have to go and look at the charts with teh Popularity Bubbles to find out whether Java is still a bigger part of the landscape than Modula 3? 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.
- nickpsecurity 11y ago
  "But do I really have to go and look at the charts with teh Popularity Bubbles to find out whether Java is still a bigger part of the landscape than Modula 3?" 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-turing-complete/ 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 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.