5 ms·

Glad to see this old horse is still being pulled out and beaten every now and then. I think this is the worst part of learning to program in CL: the self-flage

Glad to see this old horse is still being pulled out and beaten every now and then. I think this is the worst part of learning to program in CL: the self-flagellating, cynical CL users and the haters that parrot this old, barnacle-ridden trope: it's too powerful! Macros! Nobody can understand it but gods and strange people on the Internet! You will have to listen to these people constantly invade every forum, discussion group, and chat room on the Internet to tell you how you shouldn't be learning CL. I like powerful languages. They have neat ideas. If they help you get more done in less time with less code, great. Not every software project needs to be a tedious, boring slog that takes 30 developers 8 months to do what you can with CL in a week. Keep learning CL if that floats your boat. I had a blast learning it and it's a great tool to have and a constant source of inspiration for ideas.

watmough 5y ago
Yes, it's great to experience the 10x or 100x developer syndrome sometimes. Using Clojure changed my life somewhat, as at some point I rewrote 2000 lines of C++ (to handle splitting and coalescing NAESB cycle pipeline nominations) in about 27 lines of pattern-matching Clojure, and just no one, no one would take it seriously. A usable UI in Swing to manage it wasn't much more, and was cross-platform. Not a fun experience overall, I ended up quitting that company, doing iPhone dev for a bit, then moved back into G&G. Other than that rewrite experience, I just used Clojure like I used to use Perl. Easy to bang something out in, and performant native Java libraries for things you might not expect, like low-level SQL Server (2005 at the time!) and Oracle (8 at the time) drivers. I'm back mainly as a C++ developer now in visualization and HPC.
- outworlder 5y ago
  That's also the problem with Lisp (and other powerful languages). They are far too malleable. They can be changed into unrecognizable blobs by people with lots of intelligence but low wisdom (I include myself in that group). They don't _have_ to. They can lead (and often do) to clean implementations. But we tend to like 'cleverness'. The larger the team, the more detrimental the effect. That's why we ended up with Java. And more recently, golang. As much as I like Go on its niche, it's a straightjacket. I'd often think to myself "this whole file I've been working for a week on would be 5 lines of scheme or lisp". But then if I get run over by a bus the company could theoretically replace me the next day (they couldn't because there's far more knowledge required than coding, but they think they could).
  - agentultra 5y ago
    Ah yes, the "we should be able to hire anyone off the street and replace you instantly," fallacy. I've never in all my career ever been asked to walk out into the street and grab a random stranger and pull them into our office to fix this code now because Jerry just got hit by a bus and won't be making it into the office ever again. We can barely hire other programmers.
    - watmough 5y ago
      Great point! Maybe not so much of a fallacy when you look at how developer management currently works in most mainstream companies. It really does seem more geared to going slowly, and making each tiny step be recorded in some system.
  - jimbokun 5y ago
    Mediocre programmers will write unrecognizable blobs in any language, and good Lisp programmers can use macros and other advanced tools to make their code even more clear and understandable.
  - wtetzner 5y ago
    > That's why we ended up with Java. To be fair, I've seen much bigger unrecognizable blobs in Java than I have in any Lisp. A language that's too rigid just makes people reach for other workarounds, e.g. craziness in the build system, using lots of reflection, configuring things with XML, etc. It doesn't make it any easier for someone to come into a project and understand what's going on. At least with Common Lisp you can just expand the macros to see what's going on.
gjvc 5y ago
Amen.
leprechaun1066 5y ago
> the haters that parrot this old, barnacle-ridden trope: it's too powerful! Macros! Nobody can understand it but gods and strange people on the Internet! You will have to listen to these people constantly invade every forum, discussion group, and chat room on the Internet to tell you how you shouldn't be learning CL. These people are actually the reason I went and learned CL. I couldn't understand why some programmers would hate a programming language so much. Now it's one of my favourite languages.
mbrodersen 5y ago
If you want to learn a truly powerful language then learn Assembler programming ;)
- remexre 5y ago
  Once you want some macros for "obvious abstractions," use a macro assembler; then once you want a more consistent macro language reinvent Forth on your macro assembler; then once you want a complete stdlib reinvent Lisp on Forth
  - mbrodersen 5y ago
    Yep which is why we have less powerful but more productive programming languages today. And we created it all from Assembler.

watmough 5y ago

Yes, it's great to experience the 10x or 100x developer syndrome sometimes. Using Clojure changed my life somewhat, as at some point I rewrote 2000 lines of C++ (to handle splitting and coalescing NAESB cycle pipeline nominations) in about 27 lines of pattern-matching Clojure, and just no one, no one would take it seriously. A usable UI in Swing to manage it wasn't much more, and was cross-platform. Not a fun experience overall, I ended up quitting that company, doing iPhone dev for a bit, then moved back into G&G. Other than that rewrite experience, I just used Clojure like I used to use Perl. Easy to bang something out in, and performant native Java libraries for things you might not expect, like low-level SQL Server (2005 at the time!) and Oracle (8 at the time) drivers. I'm back mainly as a C++ developer now in visualization and HPC.

outworlder 5y ago
That's also the problem with Lisp (and other powerful languages). They are far too malleable. They can be changed into unrecognizable blobs by people with lots of intelligence but low wisdom (I include myself in that group). They don't _have_ to. They can lead (and often do) to clean implementations. But we tend to like 'cleverness'. The larger the team, the more detrimental the effect. That's why we ended up with Java. And more recently, golang. As much as I like Go on its niche, it's a straightjacket. I'd often think to myself "this whole file I've been working for a week on would be 5 lines of scheme or lisp". But then if I get run over by a bus the company could theoretically replace me the next day (they couldn't because there's far more knowledge required than coding, but they think they could).
- agentultra 5y ago
  Ah yes, the "we should be able to hire anyone off the street and replace you instantly," fallacy. I've never in all my career ever been asked to walk out into the street and grab a random stranger and pull them into our office to fix this code now because Jerry just got hit by a bus and won't be making it into the office ever again. We can barely hire other programmers.
  - watmough 5y ago
    Great point! Maybe not so much of a fallacy when you look at how developer management currently works in most mainstream companies. It really does seem more geared to going slowly, and making each tiny step be recorded in some system.
- jimbokun 5y ago
  Mediocre programmers will write unrecognizable blobs in any language, and good Lisp programmers can use macros and other advanced tools to make their code even more clear and understandable.
- wtetzner 5y ago
  > That's why we ended up with Java. To be fair, I've seen much bigger unrecognizable blobs in Java than I have in any Lisp. A language that's too rigid just makes people reach for other workarounds, e.g. craziness in the build system, using lots of reflection, configuring things with XML, etc. It doesn't make it any easier for someone to come into a project and understand what's going on. At least with Common Lisp you can just expand the macros to see what's going on.

gjvc 5y ago

Amen.

leprechaun1066 5y ago

> the haters that parrot this old, barnacle-ridden trope: it's too powerful! Macros! Nobody can understand it but gods and strange people on the Internet! You will have to listen to these people constantly invade every forum, discussion group, and chat room on the Internet to tell you how you shouldn't be learning CL. These people are actually the reason I went and learned CL. I couldn't understand why some programmers would hate a programming language so much. Now it's one of my favourite languages.

mbrodersen 5y ago

If you want to learn a truly powerful language then learn Assembler programming ;)

remexre 5y ago
Once you want some macros for "obvious abstractions," use a macro assembler; then once you want a more consistent macro language reinvent Forth on your macro assembler; then once you want a complete stdlib reinvent Lisp on Forth
- mbrodersen 5y ago
  Yep which is why we have less powerful but more productive programming languages today. And we created it all from Assembler.