4 ms·

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 th

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).

zabuni 9y ago
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.
- aerique 9y ago
  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
  - DonaldFisk 9y ago
    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++.
    - flavio81 9y ago
      >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.
- kamaal 9y ago
  >>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.
- bonesss 9y ago
  > 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.
- kbp 9y ago
  I think your version of "fun" is my version of "proper abstraction and factoring".
reikonomusha 9y ago
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.
- dmytrish 9y ago
  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?
  - reikonomusha 9y ago
    Peer review is always going to use resources. Policing style doesn't take much effort, in my experience.
willtim 9y ago
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.
- DonaldFisk 9y ago
  The Lisp curse is described here: http://winestockwebdesign.com/Essays/Lisp_Curse.html 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.
lispm 9y ago
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.
- kamaal 9y ago
  >>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.
bonesss 9y ago
> ... 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.
DonaldFisk 9y ago
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.

zabuni 9y ago

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.

aerique 9y ago
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
- DonaldFisk 9y ago
  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++.
  - flavio81 9y ago
    >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.
kamaal 9y ago
>>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.
bonesss 9y ago
> 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.
kbp 9y ago
I think your version of "fun" is my version of "proper abstraction and factoring".

reikonomusha 9y ago

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.

dmytrish 9y ago
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?
- reikonomusha 9y ago
  Peer review is always going to use resources. Policing style doesn't take much effort, in my experience.

willtim 9y ago

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.

DonaldFisk 9y ago
The Lisp curse is described here: http://winestockwebdesign.com/Essays/Lisp_Curse.html 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.

lispm 9y ago

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.

kamaal 9y ago
>>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.

bonesss 9y ago

> ... 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.

DonaldFisk 9y ago

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.