Hacker News Reader

Comment by dimatura | Hacker News Reader

I absolutely love lisp. It's crazy how it's one of the oldest language around, yet it still has more features than many other newer mainstream languages.

At the same time, one of the reasons I don't like it too much for daily work, is how it encourages cleverness. This sounds silly, I know. But sometimes when there's opportunities for cleverness -- such as with C++ (meta) template programming -- I become too tempted to make my own code more clever instead of, you know, making it do whatever it's supposed to do. That makes me appreciate the relative dumbness of say, Go and Python (not that you can't be clever with Python, but it's not encouraged).

View on HN

> ... one of the reasons I don't like [LISP] too much for daily work, is how it encourages cleverness

I fully agree: nothing is as dumb as being too smart.

From a linguistic PoV LISP stole my heart as a lad and never really let go... I think it's much more consistent and reasoned than most programming languages, and it's wildly powerful. I can only imagine what 5+ years hacking a domain on a proper LISP machine would bring...

That said, I can't bring myself to use it in Enterprise projects because of the 'LISP curse'. While LISP got computing right, I think the type systems of the ML languages got industry right. They strike a nice balance between linguistic power, wild cleverness, and a brutal mandatory type system that means I rarely have to understand cleverness. As long as a function signature says it turns a 'Foo' into a 'Bar', I've got what I need.

My biggest issue as well. People seem to be drawn to creating a DSL for their problem set, and then programming in that. I've thought of Go as the Anti Lisp, in that there will be NONE OF THOSE SHENANIGANS LIKE THAT HERE. I think that's why Go draws so much vehemence. It's the "No fun allowed" of computer languages.

I recently had to use Go for the first time at work, while generally Common Lisp is my go-to language.

I kinda liked it for a systems language. It has conveniences trickled down from higher level languages[1] that are missing from C & C++ and which make them such a chore to use

[1] for example: garbage collection and being able to print an object without have to import vast libraries

These are things that Lisp programmers take for granted, but it's difficult to convince most C/C++ programmers of the advantages of garbage collection, as if they wanted it they wouldn't be using C/C++.

>advantages of garbage collection, as if they wanted it they wouldn't be using C/C++.

There are garbage collection libs for C++ and they are used by C++ programmers whenever necessary.

>>People seem to be drawn to creating a DSL for their problem set, and then programming in that.

You have to create a DSL for your problem, no matter what programming language you code in. Its just that most people never program in anything beyond their area of exposure, and their DSL which they creates just appears very normal to them. But not to others.

> People seem to be drawn to creating a DSL for their problem set, and then programming in that.

ML languages strike a pretty nice balance here, IMO. Your DSL tend to be normal code with a funny operator or two, structured into happy little lists.

I think your version of "fun" is my version of "proper abstraction and factoring".

This is maybe a problem for small open source software projects, but not at organizations where code is vetted with constant review.

I claim a lot of problems like this are solved perfectly well by team-agreed policy. For the same reason you don’t see people writing C functions taking void* everywhere for every problem, you don’t see professional Lisp codebase chock-full of terrible, homegrown DSLs.

You will see bad code in Lisp, C, Go, Java, whatever if it goes without review or peer agreement. With that said, since coding in Go is a bit more menial, there’s less policy to make around it.

You can write good code in Lisp, but isn't it wiser to choose a language/technology that drains less organizational resources for herding cats?

Peer review is always going to use resources. Policing style doesn't take much effort, in my experience.

I've seen excessively clever Java. Instead of code which did what was wanted using POJOs, it acted as an interpreter with most of the business logic in configuration files, which eventually numbered hundreds and had to be generated by shell scripts.

I avoid cleverness, including when writing Lisp. I rarely use macros, for example. Even if no one else reads my code, I'll still have to understand how it works in future.

One of the problems of the Lisp approach with extreme flexibility: it's amplifying the programmer. One can write extremely dumb code in Lisp - in many dimensions. Well trained/educated programmers can use it to their advantage, but the opposite is creating easily unmaintainable software.

But in enterprise OO software (-> Java) you can get similar effects once there are enough layers of factories, special purpose DSLs, greenspunning, etc.

>>But in enterprise OO software (-> Java) you can get similar effects

'can' is the wrong word there. You 'always' get an effect worse than lisp.

It once took me hours and severals hundreds of classes to sift through a massive java code base to understand that all the programmer wanted to do was post a XML to a endpoint.

This is more of a software engineering problem and not a lisp problem.

It's been called the "Lisp Curse", but I don't think it's unique to Lisp. Any highly expressive and productive language is vulnerable to such social problems.

The Lisp curse is described here: http://winestockwebdesign.com/Essays/Lisp_Curse.html

Every so often, someone writes an essay explaining why, if Lisp is so good, it isn't used much. There are at least three others.

Reply on news.ycombinator.com