Hacker News Reader

I've never been a huge fan of lispy syntax, but I've never been a big hater, either. Personally, I find the square brackets and curly braces to be just enough additional texture to make the code plenty readable, as long as you're using a good autoformatter. (Letting people make their own decisions about code formatting in any lisp seems to be a very quick route to a very bad time.) What I find, though, which makes me sad, is that many people knee-jerk reject any non-ALGOL syntax (Lisp, but also Smalltalk, ML, Prolog, whatever). To the point that I fear that not being able to understand the syntax becomes a point of pride. It reminds me a bit of the sort of asymmetrical intelligibility of Metropolitan French and any of the Canadian dialects, a situation where I also get the impression that the difficulty in understanding is more than a little bit deliberate.

So there's that. But I also do find that Clojurists have not been immune to some of the snootiness that seems to infect most functional language communities. And I wonder if some of the reaction comes from that, combined with Clojure maybe bumping into the rest of the world more often due to its identity as a JVM language.

Yeah I do see this attitude and it’s sad, I guess it’s hard to create a new language on an existing runtime and not try to market it (and convince yourself) that it’s better than the alternatives, but no doubt it goes further than that. Which is a shame because again, I think Clojure is good because it’s fairly pragmatic. It feels to me much more a product of software engineering knowledge than computer science knowledge (despite fancy and useful theoretical stuff like transducers, which of course exist in many places now).

I'm inclined to agree. For me, Clojure feels like the one alternative JVM language that really offers a more-than-merely-incremental productivity boost over Java for a lot of everyday problems. (Scala also has its strong spots, but I find them to be fewer and further between.) And also, conveniently, it lets you really easily switch to Java for the bits that Java does better.

It's maybe the quintessential Cassandra language, though. As a dynamic functional language, Clojure is a great complement to Java. And, while I've also never really been comfortable with macro programming, compared to Java's accumulated decades' worth of XML and code generation and bytecode munging and and dependency graphs that have been sent through a wood chipper by annotations, s-expressions and macros strike me as a delightfully clean and maintanable-looking breath of fresh air. But all that stuff also makes it a bit of a tough sell among the kinds of folks who haven't long since abandoned Java for a language like Ruby or Python. A bit like trying to sell tie-dyed shirts out of a VW bus at a Barbara Streisand concert.

Could you elaborate on what “ A bit like trying to sell tie-dyed shirts out of a VW bus at a Barbara Streisand concert.” means here? I’m not sure what the colloquial terms actually mean :) is it that Streisand concerts were fashionable and tie dyes weren’t?

Tie-dye T-shirts and VW buses are associated with the hippie subculture in the US. A group of people much more likely to listen to Bob Dylan or Creedence Clearwater Revival than to Streisand.

Likewise, the sort of people associated with Streisand concerts -- mainly well-to-do, cosmopolitan, white (especially, but not exclusively, Jewish) women -- would not trust a shaggy man with a rusting VW bus with their money, let alone be interested in his handmade wares when there are perfectly good boutiques on Fifth Avenue (or Rodeo Drive) to patronize if they are in need of clothing.

OP was trying to imply that the people who still use Java have fundamentally different tastes than dynamic-language programmers, and so evangelizing Clojure to them would be a fundamental mismatch in tastes, like a hippie trying to sell to upscale white women.

Just for clarity, I was only going for the "fundamentally different tastes" angle, and not trying to draw any political analogies.

Your last point is very well put. Clojure's selling point to an extent was "look, a Lisp they might actually let you put in production!" compared to Ruby's, which certainly in the early 2000s was "rip off your suit and join a startup".

> At the same time Clojure people do have a tendency to paper over the cracks quite a lot, at least some of which must be cognitive dissonance.

An executive I previously worked with commented one day "Every small language's following is a little bit cult-y. Clojure's is more so than most."

Personally, I think the technology itself is fine. The ecosystem, from my exposure to it, has a few warts. It's somewhat small, which I expect of what is still a niche language. The killer issue for me was the memes that slowed and discouraged the development of useful frameworks in favor of gluing together ad-hoc sets of libraries.

Of course, it may have just been that I was working with a batch of Clojure devs who were in those jobs because they were sold on the glories of functional programming purity. Hard to say. They were better than the Haskell shop I worked in, but not as much so as I would have liked.

Can’t argue with this, I find it immensely frustrating. I’m on my fifth or sixth library for interacting with a database, my third component library, fourth or fifth config library, and the data science story especially has always been terrible because of the aversion to frameworks. This isn’t necessarily a great hardship, and for the most part old code just works, but so many libraries fall by the wayside or just never reach their potential cos they were the singular vision of one smart person, while all the other smart people were off working on other stuff.

It became a major headache for me when I saw multiple teams of developers trip over the same blind spots. Gluing together libraries works best when you're enough of a domain expert to understand every aspect.

When you're writing public-facing web services and forget about security while pulling together your stack, this ignorance can become very dangerous!

The problem with lisp is that most programmers find the syntax extremely off putting. I've been watching this debate go around and around in circles for 20 years now and nothing has changed. And as much as I appreciate the power of macros I feel like the features of other modern languages cover a lot of the same ground so the benefits of such a controversial syntax are diminished.

Lisp is a fascinating and very elegant language and every developer can learn something from it but I gave up waiting for the lisp revolution a while ago.

The other problem with Lisp is that it attracts a fanatical element that rejects any criticsm of the language. Every language has its zealots but Lisp takes it a step further.

Google Erik Naggum for an extreme example of this syndrome.

Yeah I just think when a language never has to go back and invent new syntax and junk to keep up, it’s probably doing something right.

Lisp got a lot of things right and modern languages have borrowed a lot of ideas that were pioneered in various Lisps. But nobody has borrowed s-expression syntax and I don't think that's an accident.

I don't think that's true -- we're discussing a language that was invented relatively recently and has sexpressions. It's just that if a language has lots of parentheses, it gets classified as a lisp.

As soon as a language borrows s-expressions, it's a Lisp. This makes it impossible in practice for a non-Lisp to just "borrow" s-expressions. Definitely not an accident.

On the other hand, you do have languages like XML which is basically a much more cumbersome syntax for s-expressions.

>>The problem with lisp is that most programmers find the syntax extremely off putting.

For all practical purposes Lisp doesn't even have a syntax.

The real issue is with programmers who are at beginner and advanced beginner levels all life.

This problem existed with Perl too. Agreed that a lot of text manipulation tasks that existed before the data exchange standards like JSON and XML came around don't exist anymore. The use cases for Perl have reduced. But the overall point stands of course. People are willing to write 100 classes to extract a string from data, than learn to write 10 lines of regex code.

If the only thing you are willing to learn and use is a for loop, if statement and function/class syntax. Anything will look off putting.

Just see how many programmers struggle with concepts like concurrency, pointers, recursion etc. It's just that these people struggle to hold non-trivial concepts in mind.

There's an elitism inherent in this take that I think is misplaced. A lot of programmers are perfectly capable of weighing the pros and cons of s-expression syntax and deciding it's not for them. Too many Lisp programmers believe that Lisp way is the right way and not just a set of tradeoffs like every other language design.

Only a relatively few amount of programmers have programmed in non-Algol syntax in-anger, rather than the reverse.

How can you weigh up the pro or con of a syntax when you haven't used it much? I couldn't tell you whether APL syntax was any good.

I know quite a few really brilliant programmers that were exposed to scheme or lisp in school but prefer other languages for various reasons in their professional work.

Does programming in-school really count as programming in anger? I did a module on C++ at university but I'm not equipped to evaluate it.

No offence but it sounds as if you are invoking a “True Scotsman” argument here? Also (using your argument) how do you know LISP is better than C++ when you haven’t programmed C++ “in anger”?

"[N]ot equipped to evaluate [C++]" clearly means that yw3410 doesn't know whether Lisp is better or worse than C++.

I have tried really hard to fall in love with LISP style languages. This includes implementing my own LISP interpreters/compilers just for fun. I also know enough Haskell (and Idris) to compare LISP style languages with the “opposite” end of the functional language spectrum. And I an the maintainer of a high performance functional programming language at work. In the end I still end up never reaching for LISP or Clojure when solving real world programming challenges. The key reason is that I am more productive with strong types. The same reason why I initially loved Ruby and then stopped using it the moment I tried to build anything bigger with it. I realise that not having types makes some people happy. That’s great. It just doesn’t make me happy.

Whoa, this was a point about syntax (non-Algol vs. Algol) being overstated. Haskell and Idris absolutely fall in non-Algol languages that make people do a double-take.

For the record I like lots of languages - dependent types are awesome. I find that the language I reach for will mostly be a function of the problem space.

Just an FYI, certain Lisps have static typing as well.

>>A lot of programmers are perfectly capable of weighing the pros and cons of s-expression syntax and deciding it's not for them.

Most of the programmers today have negligible experience with Lisp.

It's also not really elitism. I'm not saying people are stupid. But people take great pain in avoiding reading documentation and understanding anything in general. Which is why I gave the Perl example.

Reading documentation for 30 mins could help you understand the issues and help you fix them at root, instead of hours of Googling. For some reason people do the latter, not the former.

I actually think your Perl and specifically regex example where spot on, in my career I have only worked with probably 4 programmers who really understood and could think in regex, which gave them the tools to solve extremely complicated parsing problems rather simply. The rest of the teams just relied on those people to do their regex thinking for them. The sad part, it regex it rather simple to learn and just takes a little effort but people treat it like it is black magic.

A lot of regex-based solutions are not robust against bad input.

Bad input doesn't always mean that the regexes don't match!

Regexes have a very happy home inside lexical analyzers for tokenizing languages. Lexers define what is correct input and match every case with some regex pattern. If there is no match, then the input doesn't contain a valid token: the lexer can loudly complain (logging an error that can be treated as fatal by the overall compile job), drop an input character and try matching again.

The typical regex solutions in Perl (Awk, ...) scripts go like this: "look for this flimsy, minimal regex somewhere in the stream and assume it's the right thing, then match this other regex in the same line and---woo hoo!--that's our item. Oh, false positives, schmozitives."

Basically, if we were to pin it down to a single difference in principles is that using regexes for searching for something small in something large is different from matching an entire input in its totality (and then getting at the desired parts).

Searching is the quick and dirty thing that's easy to reach for.

This clearly isn't true, though. Lisps do have a lot of syntax. In the Clojure samples in this blog post alone we have:

• Parens

• Curly braces

• Square brackets (why are they here, if Lisp is just s-exprs?)

• Colon-prefixed symbols

• Quote-prefixed lists

• Functions with names like >!! and ->>

That's pretty obviously syntax. You could argue it doesn't have keywords in the way C-type languages do, but magical functions that are defined as part of the language and should never be changed for all intents and purposes might as well be syntax too. So in the end the difference is kind of academic.

So if its not an issue in C languages, how come this is an issue in Clojure?

The argument here is lisp has a simple rule. The first element of a list says that what is to be done, the remaining are its inputs. That's really all there is to it(mostly). Using () for everything was really a kind of overloading, which is why I guess they used different opening and closing characters for different contexts.

> • Functions with names like >!! and ->>

To be precise, those are just function names, not syntax. But even Clojure having a more complicated syntax than Common Lisp or Scheme is much simpler than Java, for example. Instead of f(x, y) it's (f x y), essentially.

I'm not saying it doesn't have any symbols, and yes Clojure makes a pragmatic choice to include more primitives than just lists, I think people are pretty happy with that. But everything you mention was present in the very first release of Clojure (function names are just function names). The changes since then have been tiny (some reader stuff which you could easily ignore). My point is once you know how to read and navigate Clojure code you're never going to have to worry about new primitive stuff being added, because the syntax is enough for life. I like that, and dislike languages like C# where every release and every new language feature introduces new keywords. That's an entirely personal thing, I'm not saying it's better, but I do think it's to Clojure's credit that it doesn't have to add new syntax to get new things done.

When I mentally diff Clojure against other JVM-based Lisps -- mainly thinking of Kawa and ABCL here, which are dialects of long-established Lisps -- Clojure comes up different enough to be weird, but not sufficiently better than the alternatives for me to put up with the weirdness and choose it over them.

It's kind of like when I recently evaluated Visual Studio Code (for the (1+ n)th time) to use as my default editor. Everybody I know at work uses it, and for a couple years there Hackernews made a collective O-face every time a new version dropped from Microsoft. So it must be good, right? Well, it was different enough from Emacs to force me to get used to an entirely different workflow, but not enough better than Emacs (really, for my purposes, not better at all) to justify making that enormous transition. So back to Emacs I trudge. A reasonable person may make the same call about transitioning from Visual Studio Code to Emacs when they hear advocacy from Emacs users like me.

That's where Clojure is for me -- in this limbo of it sounds good but it's not really worth it for me, personally, to switch. Plus its community has a strong contingent of douchey advocates -- not quite at the level of say, Rust or Newlisp but getting up there -- who act like Rich Hickey was God's gift to programming and make me think "So that's what Smug Lisp Weenies sound like to the rest of the world." And that further cements me in the realm of "hard pass" w.r.t. Clojure. Call it an irrational, emotion-based response.

To be honest I don’t really believe any programming language is that big of a boost in the real world, outside of certain hard requirements for correctness or performance. Ironically if I were to want to make another 10-20 year bet on a language it would be Rust so perhaps I’m drawn to douchebaggery, but I’m sorry that’s your experience of Clojure.

>>not enough better than Emacs (really, for my purposes, not better at all) to justify making that enormous transition.

So tell us what your workflow is, so that everyone can benefit from it.

It doesn't do much good in just saying Its magic, trust me and then leave it there.

Emacs is slightly painful to use on Windows just because I don't want to have WSL2 just for an agreeable set of Unix tools, so I have tried to fall in love with VSCode for the times I find myself there and not in Linux. It is good, and will probably and deservedly dominate developer mindshare for a generation.

That said, there are a lot of fundamental differences that might be painful for someone transitioning from Emacs. First obviously is just keybindings, there are great packages to handle most of the basics but like with any new editor it's a faff to get everything right over time.

Second is that is has lots of special cases of windows, which are hard to manage. In Emacs everything is the same, just a buffer. Your shell, your database client, your code, all buffers. You decide how all this is laid out and have absolute control. The same navigation, manipulation and search functionality exists everywhere. When you get an autocompletion of some text, it works the same everywhere, and the same navigation and search functions work in those menus. In VSCode, you have some text editor windows, but also tab groups which behave subtly differently, and then the panel and sidebar which are both different. I don't know how to 100% stop these things popping up, and the terminal seems like the only one available, so they're a regular annoyance to someone who is used to owning every character of screen real estate. Extension developers don't create extensions from the point of view that users want to consume textual information like everything else. It's not bad or wrong, it's just that Emacs works at a lower level of abstraction. It would be entirely valid to point out that VSCode's level of abstraction enables a more vibrant extension ecosystem.

Third is that there are modes in Emacs that are much more mature than VSCode. Calva for Clojure REPLs is pretty weak compared to CIDER in Emacs. All the git modes are inferior to Magit, even the direct clones of Magit (which are good and tastefully done). All of these are very actively developed and will get better, they're just not there yet.

Overall Emacs has fewer primitives, but they apply everywhere to everything, and I find that a much more humane environment for the kind of work I do (it's why it's a nice environment for a Lisp, which has the same philosophy to code).

> who act like Rich Hickey was God's gift to programming

This is a typical cult pattern: the “esteemed leader” who is godlike perfect and can do no wrong. Having said that, in all fairness, Rich Hickey is a great presenter and I learned a lot about functional programming from watching his talks. I completely disagree with him on types but still learned a lot.

Every time Clojure comes up on HN there always seems to be a lot of negativity.

Frankly I'm just sick of hearing "Why you should use Clojure" over and over again. Posts about other languages center on some problem that language solved for them, or some problem they have with it. Clojure posts are always cold-call cheerleading about how good it is in a general sense. Tell me something cool you did with it. Tell me how it saved you a mind-blowing amount of work. I'm not interested in hearing for the Nth time how someone think it's an overall excellent choice.

At my previous job, I implemented a stream processing solution in Clojure, which superseded a Java one which never had quite worked (it was a pretty bad codebase, in fairness), added more complex functionality, and allowed me to drop 1/3rd of the code in that module (from 18KSLOC to 6KSLOC). More importantly, it worked as intended, and only a couple of negligible bugs made it to production, which for the complexity of the system, and the scarcity of QA we had, was surprisingly good, tbh.