9 ms·

I think Lisp is going to live forever as a niche tool for people who "get" it. I use Clojure on a daily basis. Not necessarily because it is best Lisp, but rat

I think Lisp is going to live forever as a niche tool for people who "get" it. I use Clojure on a daily basis. Not necessarily because it is best Lisp, but rather because I am working with Java applications and being able to reuse the same Java code I have already developed is a huge boon to me. If I was able to choose, I would be using Common Lisp. The way I use it is to quickly develop adhoc tools and PoCs and more rarely small UIs in re-frame. Working with Lisp is a joy for me and I always get this feeling of frustration when I have to go back to Java, especially if I have to translate to Java what I just prototyped in Clojure. Unfortunately, where I work (financial systems for financial institutions), I have trouble finding enough people, mature enough to be able to even propose working projects in Clojure. Close in my org structure there is a set of Clojure projects where the company got badly burnt. The code is a mess and a huge headache for management. The guys who wrote it were either promoted (claiming outstanding work on the project but not wanting to maintain it) or left. Now new developers are barely able to change anything without blowing it up. This underlines the fact that Lisp projects can very easily end in spectacular disasters. You have to be really incompetent to write a typical Java service in a way where it is no longer possible to develop it at all, but in Clojure it is just enough to get couple of people that are intelligent enough to write macros but not experienced enough to understand the dangers of lack framework forcing the structure of your application.

vslira 6y ago
Have you looked at Nubank? Largest neobank in the world by users and valuation, it's a clojure shop to such an extent they literally bought Cognitect No affiliation, just a satisfied customer
- mbrodersen 6y ago
  There are examples of successful companies using any programming language. It doesn’t prove anything about the quality of the language. The world still succcesfully runs on COBOL. That is not a good enough reason to pick COBOL for your next project.
  - sidebits 6y ago
    The difference here is that Nubank attributes part of their success to the use of Clojure.
nojito 6y ago
> I have trouble finding enough people, mature enough to be able to even propose working projects in Clojure. It has nothing to do with maturity and very thing to do with maintenance time and maintenance costs of using languages that do not have a robust pipeline of talent. Using languages like closure do give you a great amount of job security if you manage to sneak it in though.
- lmilcin 6y ago
  > Using languages like closure do give you a great amount of job security if you manage to sneak it in though. I am not after job security. In fact, I treat "I am not after job security" as one of the important points when presenting to potential employers. I try to do good job and think for the outcomes for the employer first. I value trust and I try to make it clear to my boss that they can trust me to always work with best interest for the project and company. For example, I always make it clear when I make mistakes and then we try to figure out how to solve them. I think, overall, this brings much better job security than trying to sneak technology to create a project that only I would be able to maintain.
jimmyvalmer 6y ago
> You have to be really incompetent to write a typical Java service in a way where it is no longer possible to develop it at all, Disagree. Anything can be made write-only. > but in Clojure it is just enough to get couple of people that are intelligent enough to write macros but not experienced enough to understand the dangers of lack framework forcing the structure of your application. Sentence doesn't parse on multiple levels.
- base698 6y ago
  Agree with him. Coming from an OO background I always cringed at the 15,000 line classes with 2000 line methods. Side effects everywhere. In my naivety I thought functional programs with their emphasis on lack of side effects could help. I then encountered a project that was totally functional but written entirely by people with no functional experience. The entire application was unmaintainable even in the most basic parts. > Doesn't parse > Macros Macros modify code structure at runtime so obviously that is fraught with danger. > Framework forcing structure Lisp languages in general have a do it yourself attitude not found in others. While there are frameworks it's common to find projects that have invented from the ground up entire web frameworks, db access and orm. Imagine if every project you encountered in Java reinvented Rx Java, Hibernate, and Spring.
  - rpdillon 6y ago
    I'm a big fan of Racket, and while I don't write very many macros, my understanding is that in both Common Lisp and Racket, macros are essentially a compiler pass, with no modification at runtime. https://docs.racket-lang.org/guide/macros.html https://docs.racket-lang.org/guide/macros.html
  - SomeHacker44 6y ago
    > Macros modify code structure at runtime so obviously that is fraught with danger. You may have inadvertently misspoke, but macros operate at compile time, at least in the Lisps I have used.
    - 6y ago
cle 6y ago
Honestly I’ve seen just as many disastrous codebases written in highly structured, statically typed languages. Any language with intrinsically interesting features tends to attract inexperienced (or just bad) developers who don’t appreciate the tradeoffs of their tools and design decisions, and think the tool is a panacea. This leads to disastrous codebases, and is not at all limited to lisps or dynamically typed languages. I can point just as many disasters written in statically typed languages, and they tend to be the “interesting” ones with fancy type systems in the ML family like Scala, Haskell, and Rust. (I am a huge fan of both Lisps and ML-family languages.) I think the important point is to be very aware of this risk and consider it when making technical decisions. Sometimes the tradeoffs are worth it to use a powerful tool, depending on the team and the product, and sometimes you’re better off using boring tools that won’t distract smart engineers.
- mumblemumble 6y ago
  I 100% agree that disastrous codebases are every bit as likely in other languages. But it somehow hurts more in a lisp. I think that the syntax really is the culprit. In a language like Java, the Byzantine syntax and semantics enforce some minimum level of structure on the code. It's not much, but it's something, just enough to give an experienced programmer a few extra heuristics they can use to make sense of what they're seeing. Even some things that normally drive me nuts about Java, like the way that there's no standard way to call an anonymous function (because the invocation is done through a method whose name is allowed to vary) end up being useful bread crumbs when I'm reading somebody else's code. In a Lisp, though, everything looks more-or-less homogeneous. You can memorize the names of special forms, but, beyond that, you can't quickly tell whether some thing you're looking at is data, a function, or a macro, or what. It all blends together into a disorienting fog. You need to go trace its provenance to see how some new value is defined or constructed before you can even tell what kind of thing it is. (This, tangentially, might be a great argument in favor of lisp-2, though I haven't spent enough time in a lisp-2 to have an opinion that's worth beans.) It may, in the grand scheme of things, be only a small reduction in what you can assume without careful study. But, in an unfamiliar codebase where you don't know much to begin with, every little scrap of knowledge counts. It all points to an insight I should have had 20 years ago when I was working in Perl: Features that make a programming language pleasant to write tend to make it unpleasant to read, and vice versa.
VLM 6y ago
An excellent analogy would be the metric system vs imperial measurement system, at least in the USA. A productive and profitable country of feet and pounds and inches, but significant progress is usually made in labs full of meters and liters. One could say the constant translation problems between the systems are something like an intelligence filter which provides its own rewards when not actively translating.
agumonkey 6y ago
I've read a few times that Java and enterprise languages are so horribly tedious for the purpose of slowing down armies of monkeys to avoid catastrophic design. ps: what kind of clojure projects do you have in mind ?
- thu2111 6y ago
  That's a common meme but there's not much evidence for it. Java has the syntax it does because it's based on C++. It is verbose because (a) C++ is verbose and (b) it insists on everything being inside a class. The latter is a reasonable choice given that the underlying VM needs some unit of linkage and scope ... sort of like criticising C and C++ for requiring that everything be inside a function, but there are reasons for doing it that way. It's true that Java's designers are very conservative, and this is partly because there are many users who appreciate that their skills don't get obsoleted all that fast (a lot of whom are in enterprise roles). But that's more of an accident of a commitment to backwards compatibility and historically long release cycles. It's not like they set out to make an 'enterprise language', they didn't. It was originally meant for the embedded TV set top box world.
  - agumonkey 6y ago
    I really read that big companies, for logistics reasons, prefer verbose, boilerplate-full languages because it slows down mistakes. Not only because the pace of evolution in the language is better for long term careers.
    - thu2111 6y ago
      I don't think that's really true. I think it's more the case that the sort of languages that have the features large teams need have tended historically to be verbose, and some people conflated the two together. For instance lambdas made Java less verbose and there was no pushback from enterprises, which you'd have expected if they actually loved verbosity. Kotlin is also doing great in big companies and conciseness is one of its selling points.
piercebot 6y ago
How do you find REPL integration in Common Lisp compares with Clojure? I find myself blissfully productive in Clojure, and I wonder if it's the same for all Lisps
- pjmlp 6y ago
  Common Lisp invented the REPL, Clojure only provides a subset of it. Have a look at, "The Interlisp Programming Environment", https://www.computer.org/csdl/magazine/co/1981/04/01667317/13rRUyv53Ic https://www.computer.org/csdl/magazine/co/1981/04/01667317/1... Or online demos like https://youtu.be/OBfB2MJw3qg https://youtu.be/OBfB2MJw3qg for Symbolics. Ultimately you can try the community versions of Allegro and LispWorks. https://franz.com/enterprise_development_tools.lhtml https://franz.com/enterprise_development_tools.lhtml http://www.lispworks.com/ http://www.lispworks.com/
- fmakunbound 6y ago
  Yeah the REPL in your typical Common Lisp is much more integrated than nrepl/cider in Clojure. Things like restarts and the debugger are built with the REPL in mind.
didibus 6y ago
> You have to be really incompetent to write a typical Java service in a way where it is no longer possible to develop it at all I've seen multiple Java services reach this state and require complete rewrite as the only path forward. I think you've just had one kind of experience and are making conclusions out of it, but in your case, I don't think the programming language is a factor. You just happened to see some failed Clojure projects, as I happen to have seen failed Java projects.
- lostcolony 6y ago
  Yeah...or where it's possible to develop, but a feature that -should- be all of a week, is a multi-month effort. In fact that seems like the norm for any Java project that has been ongoing more than a year.
deleted 6y ago
[deleted]
hota_mazi 6y ago
> This underlines the fact that Lisp projects can very easily end in spectacular disasters. This is not specific to Lisp, it happens to all dynamically typed languages. And this is why "holding invariants in my head" doesn't scale. Your objects have a type. Why not put it in the code and ask the compiler to verify it, so that future developers on that code (including yourself) will have an easier time reading it and evolving it?
- lispm 6y ago
  Common Lisp allows to annotate code with type information, which can be checked at runtime. Also it's object system works on classes and thus generic function have arguments for those classes. Something like Common Lisp is a dynamically typed language, but where implementations can use knowledge about types, either at runtime or even sometimes at compile time. SBCL * (defvar *foo*) ; a global variable *FOO* *FOO* We tell SBCL that the type of the variable is an integer between 0 and 10. * (declaim (type (integer 0 10) *foo*)) (*FOO*) Now we try to set it to 30: * (setf *foo* 30) SBCL detects the problem: ; in: SETF FOO ; (SETF FOO 30) ; --> SETQ ; ==> ; (THE (MOD 11) 30) ; ; caught WARNING: ; Constant 30 conflicts with its asserted type (MOD 11). ; See also: ; The SBCL Manual, Node "Handling of Types"
  - sevensor 6y ago
    That's amazing. I want that. I like how clear it is about what it's for, which is the sort of thing one does all the time in other languages that lack a vocabulary for it. I'm going to assume you could put any predicate you wanted in there?
kazinator 6y ago
> This underlines the fact that Lisp projects can very easily end in spectacular disasters. I've been following HN since 2014 and haven't seen any submission about such a thing. The closest was some article or comment from someone who worked at Cycorp, about some horrors of the legacy code base. Here it is: https://news.ycombinator.com/item?id=21783828 https://news.ycombinator.com/item?id=21783828 "... the biggest mess I have ever seen by an order of magnitude" :)
- mbrodersen 6y ago
  Not surprising since LISP isn’t used much.
  - vindarel 6y ago
    Still, for some example companies: https://github.com/azzamsa/awesome-lisp-companies https://github.com/azzamsa/awesome-lisp-companies

vslira 6y ago

Have you looked at Nubank? Largest neobank in the world by users and valuation, it's a clojure shop to such an extent they literally bought Cognitect No affiliation, just a satisfied customer

mbrodersen 6y ago
There are examples of successful companies using any programming language. It doesn’t prove anything about the quality of the language. The world still succcesfully runs on COBOL. That is not a good enough reason to pick COBOL for your next project.
- sidebits 6y ago
  The difference here is that Nubank attributes part of their success to the use of Clojure.

nojito 6y ago

> I have trouble finding enough people, mature enough to be able to even propose working projects in Clojure. It has nothing to do with maturity and very thing to do with maintenance time and maintenance costs of using languages that do not have a robust pipeline of talent. Using languages like closure do give you a great amount of job security if you manage to sneak it in though.

lmilcin 6y ago
> Using languages like closure do give you a great amount of job security if you manage to sneak it in though. I am not after job security. In fact, I treat "I am not after job security" as one of the important points when presenting to potential employers. I try to do good job and think for the outcomes for the employer first. I value trust and I try to make it clear to my boss that they can trust me to always work with best interest for the project and company. For example, I always make it clear when I make mistakes and then we try to figure out how to solve them. I think, overall, this brings much better job security than trying to sneak technology to create a project that only I would be able to maintain.

jimmyvalmer 6y ago

> You have to be really incompetent to write a typical Java service in a way where it is no longer possible to develop it at all, Disagree. Anything can be made write-only. > but in Clojure it is just enough to get couple of people that are intelligent enough to write macros but not experienced enough to understand the dangers of lack framework forcing the structure of your application. Sentence doesn't parse on multiple levels.

base698 6y ago
Agree with him. Coming from an OO background I always cringed at the 15,000 line classes with 2000 line methods. Side effects everywhere. In my naivety I thought functional programs with their emphasis on lack of side effects could help. I then encountered a project that was totally functional but written entirely by people with no functional experience. The entire application was unmaintainable even in the most basic parts. > Doesn't parse > Macros Macros modify code structure at runtime so obviously that is fraught with danger. > Framework forcing structure Lisp languages in general have a do it yourself attitude not found in others. While there are frameworks it's common to find projects that have invented from the ground up entire web frameworks, db access and orm. Imagine if every project you encountered in Java reinvented Rx Java, Hibernate, and Spring.
- rpdillon 6y ago
  I'm a big fan of Racket, and while I don't write very many macros, my understanding is that in both Common Lisp and Racket, macros are essentially a compiler pass, with no modification at runtime. https://docs.racket-lang.org/guide/macros.html https://docs.racket-lang.org/guide/macros.html
- SomeHacker44 6y ago
  > Macros modify code structure at runtime so obviously that is fraught with danger. You may have inadvertently misspoke, but macros operate at compile time, at least in the Lisps I have used.
  - 6y ago

cle 6y ago

Honestly I’ve seen just as many disastrous codebases written in highly structured, statically typed languages. Any language with intrinsically interesting features tends to attract inexperienced (or just bad) developers who don’t appreciate the tradeoffs of their tools and design decisions, and think the tool is a panacea. This leads to disastrous codebases, and is not at all limited to lisps or dynamically typed languages. I can point just as many disasters written in statically typed languages, and they tend to be the “interesting” ones with fancy type systems in the ML family like Scala, Haskell, and Rust. (I am a huge fan of both Lisps and ML-family languages.) I think the important point is to be very aware of this risk and consider it when making technical decisions. Sometimes the tradeoffs are worth it to use a powerful tool, depending on the team and the product, and sometimes you’re better off using boring tools that won’t distract smart engineers.

mumblemumble 6y ago
I 100% agree that disastrous codebases are every bit as likely in other languages. But it somehow hurts more in a lisp. I think that the syntax really is the culprit. In a language like Java, the Byzantine syntax and semantics enforce some minimum level of structure on the code. It's not much, but it's something, just enough to give an experienced programmer a few extra heuristics they can use to make sense of what they're seeing. Even some things that normally drive me nuts about Java, like the way that there's no standard way to call an anonymous function (because the invocation is done through a method whose name is allowed to vary) end up being useful bread crumbs when I'm reading somebody else's code. In a Lisp, though, everything looks more-or-less homogeneous. You can memorize the names of special forms, but, beyond that, you can't quickly tell whether some thing you're looking at is data, a function, or a macro, or what. It all blends together into a disorienting fog. You need to go trace its provenance to see how some new value is defined or constructed before you can even tell what kind of thing it is. (This, tangentially, might be a great argument in favor of lisp-2, though I haven't spent enough time in a lisp-2 to have an opinion that's worth beans.) It may, in the grand scheme of things, be only a small reduction in what you can assume without careful study. But, in an unfamiliar codebase where you don't know much to begin with, every little scrap of knowledge counts. It all points to an insight I should have had 20 years ago when I was working in Perl: Features that make a programming language pleasant to write tend to make it unpleasant to read, and vice versa.

VLM 6y ago

An excellent analogy would be the metric system vs imperial measurement system, at least in the USA. A productive and profitable country of feet and pounds and inches, but significant progress is usually made in labs full of meters and liters. One could say the constant translation problems between the systems are something like an intelligence filter which provides its own rewards when not actively translating.

agumonkey 6y ago

I've read a few times that Java and enterprise languages are so horribly tedious for the purpose of slowing down armies of monkeys to avoid catastrophic design. ps: what kind of clojure projects do you have in mind ?

thu2111 6y ago
That's a common meme but there's not much evidence for it. Java has the syntax it does because it's based on C++. It is verbose because (a) C++ is verbose and (b) it insists on everything being inside a class. The latter is a reasonable choice given that the underlying VM needs some unit of linkage and scope ... sort of like criticising C and C++ for requiring that everything be inside a function, but there are reasons for doing it that way. It's true that Java's designers are very conservative, and this is partly because there are many users who appreciate that their skills don't get obsoleted all that fast (a lot of whom are in enterprise roles). But that's more of an accident of a commitment to backwards compatibility and historically long release cycles. It's not like they set out to make an 'enterprise language', they didn't. It was originally meant for the embedded TV set top box world.
- agumonkey 6y ago
  I really read that big companies, for logistics reasons, prefer verbose, boilerplate-full languages because it slows down mistakes. Not only because the pace of evolution in the language is better for long term careers.
  - thu2111 6y ago
    I don't think that's really true. I think it's more the case that the sort of languages that have the features large teams need have tended historically to be verbose, and some people conflated the two together. For instance lambdas made Java less verbose and there was no pushback from enterprises, which you'd have expected if they actually loved verbosity. Kotlin is also doing great in big companies and conciseness is one of its selling points.

piercebot 6y ago

How do you find REPL integration in Common Lisp compares with Clojure? I find myself blissfully productive in Clojure, and I wonder if it's the same for all Lisps

pjmlp 6y ago
Common Lisp invented the REPL, Clojure only provides a subset of it. Have a look at, "The Interlisp Programming Environment", https://www.computer.org/csdl/magazine/co/1981/04/01667317/13rRUyv53Ic https://www.computer.org/csdl/magazine/co/1981/04/01667317/1... Or online demos like https://youtu.be/OBfB2MJw3qg https://youtu.be/OBfB2MJw3qg for Symbolics. Ultimately you can try the community versions of Allegro and LispWorks. https://franz.com/enterprise_development_tools.lhtml https://franz.com/enterprise_development_tools.lhtml http://www.lispworks.com/ http://www.lispworks.com/
fmakunbound 6y ago
Yeah the REPL in your typical Common Lisp is much more integrated than nrepl/cider in Clojure. Things like restarts and the debugger are built with the REPL in mind.

didibus 6y ago

> You have to be really incompetent to write a typical Java service in a way where it is no longer possible to develop it at all I've seen multiple Java services reach this state and require complete rewrite as the only path forward. I think you've just had one kind of experience and are making conclusions out of it, but in your case, I don't think the programming language is a factor. You just happened to see some failed Clojure projects, as I happen to have seen failed Java projects.

lostcolony 6y ago
Yeah...or where it's possible to develop, but a feature that -should- be all of a week, is a multi-month effort. In fact that seems like the norm for any Java project that has been ongoing more than a year.

deleted 6y ago

[deleted]

hota_mazi 6y ago

> This underlines the fact that Lisp projects can very easily end in spectacular disasters. This is not specific to Lisp, it happens to all dynamically typed languages. And this is why "holding invariants in my head" doesn't scale. Your objects have a type. Why not put it in the code and ask the compiler to verify it, so that future developers on that code (including yourself) will have an easier time reading it and evolving it?

lispm 6y ago
Common Lisp allows to annotate code with type information, which can be checked at runtime. Also it's object system works on classes and thus generic function have arguments for those classes. Something like Common Lisp is a dynamically typed language, but where implementations can use knowledge about types, either at runtime or even sometimes at compile time. SBCL * (defvar *foo*) ; a global variable *FOO* *FOO* We tell SBCL that the type of the variable is an integer between 0 and 10. * (declaim (type (integer 0 10) *foo*)) (*FOO*) Now we try to set it to 30: * (setf *foo* 30) SBCL detects the problem: ; in: SETF FOO ; (SETF FOO 30) ; --> SETQ ; ==> ; (THE (MOD 11) 30) ; ; caught WARNING: ; Constant 30 conflicts with its asserted type (MOD 11). ; See also: ; The SBCL Manual, Node "Handling of Types"
- sevensor 6y ago
  That's amazing. I want that. I like how clear it is about what it's for, which is the sort of thing one does all the time in other languages that lack a vocabulary for it. I'm going to assume you could put any predicate you wanted in there?

kazinator 6y ago

> This underlines the fact that Lisp projects can very easily end in spectacular disasters. I've been following HN since 2014 and haven't seen any submission about such a thing. The closest was some article or comment from someone who worked at Cycorp, about some horrors of the legacy code base. Here it is: https://news.ycombinator.com/item?id=21783828 https://news.ycombinator.com/item?id=21783828 "... the biggest mess I have ever seen by an order of magnitude" :)

mbrodersen 6y ago
Not surprising since LISP isn’t used much.
- vindarel 6y ago
  Still, for some example companies: https://github.com/azzamsa/awesome-lisp-companies https://github.com/azzamsa/awesome-lisp-companies