The reason I’m using Python right now, despite wanting Lisp’s advantages, is Python’s ecosystem. The ecosystem gives me these benefits:
Tons of educational resources for every part of the spectrum.
My questions were usually already answered online on StackOverflow, blogs, or web sites built with HTML 4. (Yeah, Python is that old.)
There’s tons of knowledgeable people if the first two don’t help. If I have to hire them, they’ll probably cost less due to their abundance and geographical spread.
Code is available for about every kind of area. There’s battle-tested code for specific needs I have.
Good tooling. Especially, the free IDE’s that catch my mistakes. There’s also tools to make the code go faster.
The subset I use should be easy to port later, maybe automatically. The py2nim project(s) prove that out given what they already did is way harder than what I had in mind.
So, these are the reasons I delayed Racket or CL to start writing Python. Although it has gotchas, the language, educational resources, tooling, and subsetting let me start cranking out working code before I even understood the language or its libraries. Flask even let me crank out two, web apps without knowing anything about that. I’ll quickly add that I’m also grateful to everyone that contributed to all of that. Their generosity helped me quickly avoid personal headaches and help other people out, too.
I’m definitely learning Python for real as I go along. The IDE mostly complains about typos and refactoring errors. It’s just that Python reminds me of QBASIC and VB6 in how I can just get straight to productivity with minimal effort invested. Then, get more productive as I invest more effort. And when it doesn’t cut it, switch to a rea… uh, a language with better control of resources and/or high-level expression of my ideas. While I get comfortable in that language, it wouldn’t surprise me if I still prototyped, analyzed, and tested code in Python before porting it to that language. Can’t let those hard-earned skills go to waste. ;)
So, these are the reasons I delayed Racket or CL to start writing Python
So you’ve never actually learned a Lisp? The reason Lisps are useful to learn is that they give you good habits that you can start incorporating into your Python code. This is widely known and it’s the reason behind scheme.
So you’ve looked at Lisp, recognized its qualities, but you’ve never actually learned one, even though its biggest advantages come from what it teaches you?
I lost my memory to a brain injury a long time ago. What you see here are how I can work with combinations of fragments of what I had, things I pick up, etc. It’s much harder for me to learn, focus, and code now.
At present, I work 8-13hr shifts with high-priority projects to code that are easier to do in an established language. So, I focus on that, family, or resting. Many off days I have zero energy. I plan to do HtDP when I get free time away from higher-priority projects. Then, probably CL for its ecosystem advantages over Racket. Especially tooling.
I’m very sorry, I didn’t know about your brain injury. The core principles of Lisp can be learned from scheme, which is a simpler language. It’s very easy to learn through The Little Schemer.
It’s a short book that teaches it with some form of immersion technique, but it might require varying amounts of concentration depending on how well you adapt to the syntax. Once you’re familiar with the syntax, scheme is very easy to work with, as it’s overall only a very small set of very well chosen rules. I think reading this book, and then trying to write some simple programs in scheme once in a while, could help you find a side of programming that could make Python easier to work with for you (or anyone who doesn’t know a Lisp), and it would take less than a day of work.
Basically Lisp is like stretching. It’s hard but you have to do it because it makes everything easier.
A lot of the pro-lisp answers are because “people are biased against lisp”. I think this is unlikely. My realistic answer is that “Lisp is not actually that much better” or “language choice is a proxy for some other confounding factor like programming experience”. My crazypants answer is that powerful languages are actually bad for collaboration.
Having worked with Java for around a decade and then Clojure after, I can definitely say that Lisp is indeed much better in a wide range of scenarios. For example, here’s a presentation on the application my team develops, and the benefits we saw from using Clojure. I simply can’t imagine developing something like that with a small team using a language like Python.
Clojure community is also a clear counterexample to the idea that Lisps are bad for collaboration. My personal experience is that I never contributed to a single Java project during my time with it. Since I moved to Clojure I’ve contributed to lots of libraries I use, and people often contribute to the ones I maintain. There’s a vibrant community around the language with lots of collaboration happening all the time. There are also lots of companies using Clojure commercially, and some have grown to have teams with dozens and even hundreds of developers. Here’s a talk from one company that grew to large scale using Clojure.
Do you believe there are meaningful improvements you can make to lisps, or the lisp communities, that would make it more popular, or do you believe the issue is entirely with non-lisp users?
I ask this because this seems similar to a common problem in formal methods communities: the assumption that it’s other people’s fault for not using FM, as opposed to a meaningful issue with the tool or community that drives people away. Often insiders have a very different view of the issues that the outsiders they want to reach do.
I see Clojure as one such improvement. I find that the additional syntax it introduces with data structure literals results in significantly improved readability. I also think that since Clojure was aimed at production use from the start that helped shaped the tooling around it. Clojure has had a great story for managing libraries out of the gate because it piggy backs on the Java repository ecosystem. This facilitated collaboration and library use from the early days.
Clojure also manages to side step the niche ecosystem problem by embracing being a hosted language. This gives it access to existing ecosystems around .NET, JVM, Python and Js. So, you don’t have to worry about finding mature drivers for databases, crypto libraries, and so on.
I think that the growth of commercial Clojure use over the years speaks for itself. Nowadays, it’s used in many different domains by companies big and small, including Apple, Atlassian, Boeing, Walmart. In case of Walmart, tech isn’t even their primary business. If there was no practical advantage to using the language then we simply wouldn’t see this happening.
And yet it’s still not nowhere near as popular as languages like Go, Kotlin, Rust, and Swift, languages that came out after Clojure. Go and Rust didn’t even have existing ecosystems! So why is Clojure not mainstream? What’s holding it back?
I propose that you, as @yogthos, are not the right person to answer this question. That’s because you’re an expert in Clojure, and the price of expertise is expert blindness. Once you master something it is incredibly hard to understand what it’s like to not know it inside and out. You’ve rejected most of the problems people have provided in this thread because they are not problems once you’re an expert. But they’re still what people perceive about the language, and often they’re what people initially experience with the language.
This has been on my mind a lot because I’m doing similar work for formal methods, interviewing people and researching what’s holding it back. The problem is that almost everybody in FM is already a master, so their efforts have for years been shaped by what masters think outsiders need, not what outsiders actually needed. This is f.ex why people have been putting a huge amount of time into switching Alloy analysis from SAT to SMT but nobody’s bothered to add a CLI yet.
And yet it’s still not nowhere near as popular as languages like Go, Kotlin, Rust, and Swift, languages that came out after Clojure.
We might need to differentiate in these discussions between languages that are popular for whatever set of reasons and languages that got popular because highly-influential companies pushed them. That’s 4 out of 4 on your list. Add .NET and Java to that. I mean, a company as rich as Apple announcing their next, big language was a systems Lisp instead of Swift probably would’ve led a Lisp to having massive uptake and investment overnight. Also hints at how to get a language to succeed against all odds: get a FAANG or whatever to make it a major language in their ecosystem, esp with money or users tied to it.
Those not backed by highly-influential companies seem to be successful or not for other reasons. These Lisps would be judged by the other reasons. Looks like a lot of reasons versus the one, major driver for people adopting each of the above languages.
There are counter points, however. Dart, Reason and Flow don’t seem to have nearly the buzz online that you see from Go/Rust/Kotlin/Swift, and those all had pushes from the same large companies.
I’m not saying that a push from a big company isn’t a strong advantage, just that it’s not sufficient to drive adoption of a language. If it was, we’d all be writing VBScript in our web browsers, rather than JavaScript.
There are some situations, like Apple + ObjC and Swift, where a company has the ability to drive adoption of a language pretty heavily.
It’s not just another good point. You just made me remember that I did write VBScript at one point. Had to keep reusing my BASIC skills. That’s one I won’t be relearning, though.
I’m not sure why you find the fact that languages from the same popular family would be be more popular surprising. It’s much easier for somebody to go from one mainstream language to another because a lot of the concepts and patterns transfer directly. Learning a language from a different family takes a lot more up front effort. This is precisely why it’s so notable that Clojure is being used in the industry right now, and it’s adoption is growing.
While I’m an expert at Clojure, I also have extensive experience teaching Clojure to beginners. My team has been using Clojure for around a decade now, and we regularly hire coop students who have little programing experience, and haven’t even heard of FP or Lisps. I think that gives me a pretty good basis to say that learning Clojure is not inherently more challenging than any mainstream language. I’ve rejected most of the problems people provided because I’ve worked with a lots of beginners who were able to overcome these problems easily. If a second year computer science student with little programming experience is able to pick up Clojure within a couple of weeks and write useful code, it seems silly to argue that the language is somehow inherently challenging. In fact, I can get somebody with no programming experience productive with Clojure much easier than I could with a language like Java because there are less concepts involved.
and we regularly hire coop students who have little programing experience
I’m kind of curious about your hiring process with that claim. Do you hire really smart people inclined to pick up any tech or average people willing to put in effort who learn because it’s truly easy? Have you accounted for that in assessing how easy it was to train them?
I like testing tech usability on folks that are less technically-inclined or at least challenged when moving to new things. The easier it is on them, the easier it might be in general.
Our experience is that it’s actually much easier to hire for Clojure than it was for Java just because it acts as a filter. We used to get hundreds of applications for a Java position, and we found that resumes were only loosely correlated to the actual skill of the candidate. With Clojure, we might get a dozen applicants, but they tend to be much better quality overall. People who apply for Clojure jobs tend to be open to learning and trying new things. We only hired one dev who had prior experience with Clojure, but the rest applied because they were interested in trying something different.
During the interview we tend to focus on CS basics to see whether the candidate understands the use of data structures and algorithmic complexity. We don’t ask any puzzles in our interviews, and mostly treat it as a pair programming session. The goal is to see that the candidate has a solid understanding of the core programming principles, and that we can communicate easily.
My experience teaching is that people can pick up Clojure very quickly with a bit of mentoring. We start by giving the hires a bit of an overview, get them to read through some online resources, and play with it in the REPL on their own. Then we pair up a bit to see if they’re on the right track. Next, we start giving them some small tasks to do, like simple JIRA tickets, we then do code reviews together to show them how to accomplish things in a more idiomatic way, and it goes from there.
My crazypants answer is that powerful languages are actually bad for collaboration.
There is a presumption here that collaboration is to be optimized for. Obviously, collaboration is a desirable quality in a language. But I’m not sold that we must sacrifice metaprogramming on the altar of collaboration. (I realize you’re not saying this.)
I’m biased here; I’ve sunk a lot of time into malleable grammars, so there’s bound to be some sunk cost fallacy at work in me. But I worry that tech culture (whatever that is) seems to subconsciously adopt more corporate views of programming as time goes on, and this is another one. Namely, that programming is so error-prone and tricky, we must put as many guard rails in our tools as possible.
Thus you get things like Elm mandating a certain architecture, Rails requiring files to be named a certain way, and avoidance of macros because “readability,” despite things like JSX doing exactly that. In short, we seem to be okay trusting that $MEGACORP engineers should wield maximum computational power when making these tools, but we never trust regular developers with that power.
That seems a little too authoritarian for my taste.
It makes sense to me that collaboration and metaprogramming are in opposition. In order for two people to collaborate, they need to communicate, which means they need a shared vocabulary. Meanwhile, metaprogramming is all about giving individuals the power to customise their vocabulary, but “unique, personal vocabulary” is the opposite of “shared vocabulary”.
That’s not to say you must choose one or the other, since people can always learn the new vocabulary, and then they can collaborate. But that’s not a solution so much as another impractical extreme: you can avoid collaboration, you can avoid metaprogramming, you can do both and accept that you’ll spend a lot of time on education, or you can pick some point between all three with a little bit of collaboration, a little bit of metaprogramming, and a little bit of education to cover the difference. But whatever you choose, you can’t crank up both collaboration and metaprogramming at zero cost.
As for authoritarianism in tech, as megacorps employ a huge number of technical people, and since they often talk about the problems they face and their impressively-engineered solutions, it’s only natural that “tech culture” reflects those ideas. To try to fight against those trends directly would be fighting against human nature, and that’s not a fight you can win.
Instead, make cool stuff and talk about it. Build something neat with metaprogramming cranked up to the max, and show people what the benefits are. Talk about projects you’ve worked on that emphasised configurability and what the experience was like. Help broaden people’s horizons, and trust that they can figure out their own comfort zone among the alternatives they’ve seen.
I wax poetic about AHK and love fringetech, you don’t need to convince me about the importance of expressiveness ;) I just think that this is a possible explanation for why the languages don’t become mainstream.
But I’m not sold that we must sacrifice metaprogramming on the altar of collaboration.
You said it buddy. I’m missing it so much with Python that I ended up dabbling with Hy Language. The trick that experienced Lispers told me was that you can stay within the regular language in a maintainable style as much as possible. Then, use macros where they solve more problems than they create.
I don’t think this correct, mainly because people who have tried both, seem to prefer clojure to python (maybe selection bias). I think the answer is somewhere between people use what they tried first, and people have pretty closed minds, its better but not THAAAT much better when you are an average programmer.
Python is popular because it looks like pseudo-code. Pseudo-code is called so because it looks like most common languages. Lisp is not a common language because it was not a common language. If Lisp had become as influential as ALGOL, the question would not refer to Lisp at all, but to RacketScript or ClojureScript or some other modern refinement thereof which anyone with previous programming experience could quickly pick up because it looked much like any other parenthesis-heavy language, which would be most languages out there.
The fact that Algol based syntax is popular because it’s already widely used is basically the thesis of the article. I think an interesting point to consider is the reason Algol became more popular than Lisp.
A common view is that it’s more natural in some way, and I don’t actually think there’s any evidence to support that notion. My team works with Clojure, and we regularly train coop students on it. What we see is that students from earlier years who have less programming experience consistently pick it up much easier than those who have more experience. We also noticed the same pattern for experienced developers as well. For example, somebody with a strong background in Java will often find switching their mindset to Clojure more difficult than somebody with little to no experience.
I think the actual reasons are largely historical in nature. General computing started becoming accessible back in late 70s and early 80s. Back then the hardware was very limited. All you had to work with was a single core CPU coupled with a tiny amount of memory. You didn’t have to worry about things like parallelism, concurrency, or networking. The goal was to squeeze as much performance out of the hardware as possible. So, something like C was a natural choice back then because it was effectively portable assembly that could be compiled against different architectures.
Meanwhile, Lisps were largely used on supercomputers and only a tiny percentage of developers got exposure to these languages because using a VM was just not practical on consumer grade hardware. Even back in the 90s and early 2000s GC was considered controversial in terms of performance. When Java came out a lot of people claimed that it was a non started because of that.
So, a whole generation of programmers were trained on C style languages, and this cemented C style syntax because that’s what vast majority of people had exposure to.
A common view is that it’s more natural in some way, and I don’t actually think there’s any evidence to support that notion.
There is evidence to support that familiarity improves learning and uptake. The pseudo-code languages are closer to the English that people in my area use to describe solutions to their problems. The Lisp’s look alien in comparison. I’d definitely like to see studies done on how much it really matters for people of various backgrounds. I’m also for skinnable syntaxes where you can pick the one you like that all get turned into same, underlying semantics.
Familiarity can also hurt uptake if you falsely believe that something new is similar to a thing you already know, when they’re not actually similar. Although Python looks somewhat like English, it’s categorically different. An English-like syntax can fool beginners into thinking that the computer can “kind of understand English” (or something similar, if not exactly that - e.g. a computer knows what “this” means) when that couldn’t be further (farther?) from the truth.
Here’s a concrete example: Verilog is a Hardware Description Language. You describe how the hardware should look, and then a “compiler” translates that declarative description into hardware (or software for the purposes of simulation, but that software is pretending to be hardware). However, the Verilog syntax (and some of the semantics) look almost exactly like that of a normal programming language. As a result, I and many other hardware engineers started working with Verilog using the mental model of a normal programming language that was “executed”, ran into many mental blocks when that model broke down, and ended up had to very painfully re-learn the language as a declarative hardware description language.
I disagree that any programming languages have any meaningful similarity to natural languages like English. I’d like to see some studies as well, but my personal experience is that Clojure is very easy to teach to somebody without any preconceptions regarding how programming should be done. On average, the students my team hires get productive to the point where they’re able to write useful code in about a week of working with it.
And of course, Lisps are one of the best tools when it comes to having skinnable syntaxes thanks to their powerful macro systems. In fact, I’d argue this is the key reason why Clojure core language managed to stay a small and focused in over a decade of use now. I wrote about that in more detail here if you’re interested.
Lisp is one of those things that I want to like, but every time I think I’ve found a way to actually like it and use it something stops me. Racket is the closest I’ve ever come to using a Lisp-y language for non-trivial code. I really enjoy the community, there are a ton of libraries available, and there’s even Typed Racket! But then I remember that someone else is going to have to read / modify / run my code and they’re likely to be annoyed that I used something relatively obscure, and I back off. So my theory is that Lisp is less popular than many people think it ought to be at time t simply because it was less popular than many people thought it ought to be at time t-1.
I made the case at Racket Con a few years ago that the way to get adoption is to introduce it in tools that aren’t critical to production, which shows people the power, but allows them to slowly learn what makes it tick. I tried to introduce scribble for my team’s internal documentation afterwards, and failed because $X decided godoc was better. As the codebase is go, it was hard to argue against, even though most of the documentation is not a good fit for godoc.
That’s a great idea, even if it didn’t work in that particular case. Now that I’m thinking about it, I could probably find a way to introduce scribble into my work, thanks!
Python ended up on my radar for two reasons. First: I didn’t have a license to matlab anymore and the internet told me that Python+numpy could be a partial replacement. Second: When I needed to rapidly prototype a website I could use Rails or Django, and for me Django was a better fit philosophically. The batteries included stdlib was a big help.
In my experience the problem with lisp is a fragmented community because there are so many flavors of lisp.
Clojure was only 2 years post 1.0 when this was written, and though it’s a counterexample to be sure, it’s only one in the long history of lisps in the past half dozen decades.
Yet it seems to be the first lisp written with the expectation that you wouldn’t spend your time manipulating lists to get things done, but rather spend your time getting things done by manipulating lists. Just the perception of this novice.
Frustrated that the top quora answer is from somebody who hates lisp.
My take:
Lisp had some popularity that died a hard death, killing adoption for roughly a generation
Python has had a unified ecosystem from the getgo. Lisp had ecosystem fragmentation early on, with several major implementations costing $$$. ASDF-install didn’t show up til 2003ish, took years to get widespread adoption, never worked on Windows, and is no longer in use (replaced by Quicklisp). PyPI showed up around the same time, and is still the primary package repository
Python has had a robust standard library from the getgo
Python’s standard library had web-relevant libraries very early on
Python has a syntax, and that syntax grows. In particular, Python has a pattern of seeing useful concepts in other programming languages (including Lisp), and incorporating them after refining the syntax to the most common use cases
My suspicion is that you haven’t spent enough time with it.
Over the years I’ve used languages with wildly different syntax (Lisp, Haskell, Ada, Python, Erlang) , and after a few months with any of them, my eyes and brain filter out the syntax and all I really think about is the semantic structure and what the code’s doing.
I think it’s part of the reason people are so persnickety about code formatting - consistent formatting makes common idioms and syntax elements easier to read at a glance.
I actually agree that it looks better, but I think that’s besides the point. For me the benefits of the S-expression syntax outweigh what I feel a is minor cost in aesthetics. Those benefits include: simplicity through uniformity, no ambiguity, and interchangeability of code and data (meta-programming).
This is a matter of subjectivity for anyone who’s experienced with programming. For instance, I find the Lisp version much more beautiful. The indentation “flows” in a way that is much more curvy and less blocky than the majority of other languages - less so in the example that you gave, but in the general case.
Why do I think that it’s more beautiful? Because, even though I wrote Python and C for 4 years, I discovered and wrote Common Lisp for 5 years after that, and my tastes have changed. I think that it’s more interesting to ask beginners which syntax they prefer.
(not relevant to my point, but you might be interested to know that after you’ve written Lisp for a few months, the parentheses fade from your perceptual awareness. Lisp programmers read code mostly using indentation - we don’t count parentheses)
Oh? Lisp: 29 tokens, Python: 24 tokens. If I count python indentation as a token, then python goes up to 28 or 30 tokens (more if 2 indentations on a row equals 2 tokens), which seems like a off-by-one error rather than clear win for either :)
I don’t think that calling Lisp parens “tokens” is very accurate, because (1) they’re pervasive (more so than newlines by far) which leads to (2) tooling+experience causes them to perceptually vanish.
In other languages, you notice every parenthesis. In Lisp, you notice few (but you do notice some). I perceive that code fragment as:
defun factorial (n)
if (= n 0) 1
* n (factorial (- n 1
I agree that there is no clear winner, though, even if you fix the Lisp formatting:
defun factorial (n)
if = n 0
1
* n (factorial (- n 1
(note the unmatched open parens) I think that much more interesting examples involve larger and more complex code, which allows you to (reasonably) compare Lisp macros against the abstraction features of other languages.
Given the answer to every vague software question is “it depends”, you can’t just talk about “Lisp”.
I can’t install “Lisp”, I can install Clojure or Racket or SBCL; each has its own different tradeoffs, libraries, and communities. So the question isn’t useful from the get go, because software in the real world is about specific situations and resulting tradeoffs and engineering decisions.
I wouldn’t write the flight search engine that powers Google Flights in Python; having worked with the people who wrote it, Common Lisp actually seemed like a good choice. But I wouldn’t use Common Lisp for 99% of the software I’ve written over the past few years. I don’t want to write every tiny utility I might need from scratch because there’s no libraries. And the language itself wouldn’t have added much.
And while Clojure definitely and probably Racket are much better ecosystems than CL they still wouldn’t help me much with the job that did scientific computing—I guess Clojure + ImageJ would have worked just fine, but Clojure wouldn’t have added anything, and the organization was already using Python.
I find it telling that almost every comment that points out a missing part in the Lisp metaverse is given a retort of “But Clojure…”
Clojure is not Lisp. It’s an implementation of it. That’s the problem - there’s not a reference implementation that can be pointed to as the “reference” to follow. Because of that, excessive fragmentation is a guarantee. There are so many of them out there, each with large enough standard library differences to make it difficult for a fair fraction of developers to think twice. All of the Python interpreters out there that I know of provide a fairly consistent standard library such that it’s not surprising. They pretty much behave the same way with the same semantics and grammar. C and C++ have large hidebound standardization committees and a large audience to demand a lot of primitives and behaviors are present in most general situations.
The fragmented nature of the Lisp family means that it’s clojure vs racket vs scheme… A whole bunch of versus and infighting about what really is the definitive Lisp. And because of that, each one fights on its own, succeeding on its own, et al. An advocate for Clojure is less of a lisp advocate and more of the Clojure advocate. A Python advocate doesn’t have that burden, so their advocacy suffers less from message incoherence.
As a side note, yes, Python 2/3 is a perfect example of a reference splitting the ecosystem and there’s been much effort into choosing one over the other to resolve that split.
I don’t really follow your argument here. Lisp is a family of languages, and it’s exactly the same situation with Algol style languages. You have C, C++, Ruby, Python, Go Java, Rust, etc. Python is just one language in a huge family that’s bigger and less consistent than Lisps. Fragmented nature of Algol family means that it’s Ruby vs Python vs Go. A Python advocate is certainly not a Ruby advocate any more than Clojure advocate being a CL advocate.
The question asks why Lisp (language) is not as popular as Python (language). Aside from a few pedants, most people don’t compare or even talk about Algol vs Lisp. They talk about Lisp (usually picking their favorite implementation as the language) vs another language.
You can’t have it both ways Y. The discussion is around “why isn’t {{language}} popular”. Not “why isn’t {{language family}}popular?”
No one seriously would conflate C and Python despite being under the same nebulous Algol umbrella. Languages are the tools that are used. Language families are multiple sections of the tool store.
The write up is clearly talking about Lisp family of languages as it uses examples from different Lisps. It seems to me that you’re the one trying to have it both ways here by lumping all Lisps together and comparing them to Python as if similar languages like Ruby and Go don’t exist.
I’m simply pointing out that your argument regarding fragmentation doesn’t really make sense because the exact same argument holds for languages like Ruby, Python, and Go.
Actually I’m pointing out the fundamental comparison is flawed. For example, you don’t compare “Declarative languages” to C - you compare C to a declarative language or set of them.
Also, you’re flat out wrong. There’s multiple write ups of different opinions, many of them anti-lisp in general. To say the writeup covers the family is disingenuous.
Personally Python’s massive standard library makes it more popular for random projects for me. I might delete this code tomorrow, so I might as well try to get something hacked together as fast as possible.
That’s one place where Clojure really shines, I get access to all of the JVM, Js ecosystem, and now Python. I can use the same language with the same tooling and get all the benefits of these ecosystems.
In my opinion, Python is so popular because its semantics are basically C with GNU extensions, operator overloading, memory safety and a decent garbage collector.
Anyone who have ever programmed in an imperative language will be able to get up to speed very quickly. The only two complicated concepts to learn with Python are the difference between scalars and composite types (especially with respect to references / copying) and closures (with at least basic, intuitive understanding of lexical scoping).
Also, a lot of people coming from more unwieldy languages such as PHP, JS of old or C will probably enjoy the Python experience a lot. Others might feel a little bit constrained, but higher order functions along with dynamic typing will actually allow them to encode more complicated constructions in a less safe, but nevertheless a working way. Decorators, operator overloading and keyword arguments can be used to create some rudimentary DSLs as well.
Of course, when you compare all that with - for example - much more sensible semantics of Racket, where DSLs can be made really first-class, it makes zero sense to stick around Python long-term. And that’s where the libraries will get you. It’s more work to re-implement them so you shoehorn your DSL into limited Python syntax, tack on some type annotations if you feel adventurous and give up. And since a lot of people are only now crawling from the PHP space or coming into IT anew, Python is getting the mind share required to grow the libraries a little bit more.
I have no idea what comes next syntactically, but I am enjoying the tug-of-war between single and multiple dispatch and I am still holding my breath for the great constant-propagation-like ahead-of-time contract validation comeback some dynamic language developer will pull off to prove that you don’t really have to use Haskell to get the same safety guarantees. :-)
As person who only learned to program and work with computers about 4 years ago, I would say that looking back the syntax really doesn’t mater. Someone who doesn’t know programming or computers will find all code confusing and ugly. This might be biased because I’ve recently become interested in Lisp, but I think the amount of material saying Python was easy to learn and the idea that I could get a job in it was the reason I learned it first. If it had been a Lisp language I would have banged my head against the wall until I learned it too.
The top answer claims that Lisp has a much steeper learning curve than Python, but gives no evidence, and on paper, his argument is false.
Python’s semantics are very similar to Scheme and CL (the latter are simpler, even), and while the syntax is completely different, Lisp syntax is significantly more regular: open parenthesis, name of operator, arguments separated by spaces, close parenthesis.
Compare that to, uh, the Python BNF grammar - or just look at some Python syntax. You write return without parens, function calls with parens, and print sometimes has parens and sometimes not depending on whether you’re using Python 2 or Python 3. Strings can be made with either single or double quotes - but you need to triple-quote strings when they span multiple lines, even when there’s no meaning for a single/double quote with its complement on another line! Arrays are made using brackets, dictionaries using curly braces (and don’t forget that you have to separate keys from their values using a colon, and key/value pairs using commas), and tuples using parenthesis. Spaces are optional in so many places, but conventions vary - write foo = 10 when assigning a variable but foo=10 when passing in a keyword argument - oh, and don’t forget about *args and **kwargs!
All of this is trivial for any experienced programmer, but much more difficult for a beginner to remember.
The top answer suggests that writing “hello world!” is more difficult in Lisp than Python. How is (print "hello world!) harder than print("hello world")?
“accessible, powerful, and free” - implying that Lisp is not accessible, powerful, or free (the latter of which are objectively false and the former of which is contentious and unproven by the author). “Lisp dates from an era when real computers (by which I mean computers running some flavor of Unix) were not in the hands of individuals outside of academia, government, big business, and the military.” - more fluff without any actual argument being made.
Programming has a huge learning curve, and if anything, Python adds more on to it than Lisp does. Scoping rules are more complex and difficult to remember, there’s this arbitrary distinction between statements and expressions, and another (less arbitrary) distinction between “operators” and “functions” that results in the former being infix and the latter being postfix, in addition to the former not being proper functions that can be passed to other functions (e.g. you can’t just pass the lesser-than function to a sorting routine).
My comment was about “hello world!”, because that was the one mentioned in the answer, so I don’t quite see how your example is related to the part of my comment that you quoted…
More generally, that entire comment was about the suitability of Lisps for beginners. No beginner is ever going to need to write code that looks like that, because…
…that kind of code is very rare. That particular fragment doesn’t do anything, and more generally, you rarely, if ever, see numerical code that looks like that. The vast majority of beginner code is control flow, with a small amount of numerical code sprinkled in - for which Lisp code becomes much closer to the equivalent in other languages.
Also, this is a pathological example - not only because the Python code is indented while the Lisp code is not, but also because it is unrealistically heavy on numerical code, which is the only thing for which the Lisp syntax could undisputedly be claimed to be “less natural”. Finally, I’ve never actually seen the kind of code in this example “in the wild” in any code before, much less in anything that a beginner would write.
Edit: typo.
Edit2: less aggressive tone.
Edit3: hopefully even less confrontational.
First off all, my point was specifically about “hello world!”, because that was the one mentioned in the answer. I don’t quite see how your example is related to the part of my comment that you quoted…
Yeah, I realize I’m a bit off base. I think I’m venting a little bit of frustration from seeing the claim that “Lisp syntax isn’t any harder, it’s (f x) instead of f(x)”, which is ignoring that things get way hairier when you deal with more complex logic. But you’re right, that’s not exactly what you were claiming, so I apologize.
Edit2: less aggressive tone.
If I’m being honest, it’s still pretty aggressive.
things get way hairier when you deal with more complex logic
I don’t unconditionally accept this premise. I write nontrivial logic in Common Lisp all the time. When I don’t make heavy use of macros, it’s a little bit easier than using Python. When I use lots of macros, it’s significantly easier and more readable than the Python equivalent. Now, I’ve been writing Common Lisp for fun for several years, and I’m more than a little bit emotionally invested in it, but that doesn’t change the fact that my experience allows me to easily write complex logic in it. If you can show me evidence that I’m an outlier and that most people, given the same amount of experience with both languages and a task that is more representative of normal code, are much more easily able to read and write the Python version, then I’ll happily change my worldview. However, I’ve never actually seen any evidence for that claim (which I’ve heard many times before), nor even somebody who has written Lisp for several years agree with it.
If I’m being honest, it’s still pretty aggressive.
Now it’s my turn to apologize. I rewrote my post from attacking you to attacking that example, but you’re right, I was still being overly confrontational. Please be patient with me while I try to figure out how to better convey tone through text. Let me try again…
However, I’ve never actually seen any evidence for that claim (which I’ve heard many times before), nor even somebody who has written Lisp for several years agree with it.
Yeah, I agree, it’s mostly opinions. I’m not familiar if there’s been any serious studies on the understandability of sexprs, but I can dig around and see if anything comes up.
Please be patient with me while I try to figure out how to better convey tone through text. Let me try again…
No worries, I don’t think it’s necessary; we’ve both admitted we got a little heated. S’all good :)
I’m not arguing that you cannot write bad or unreadable Lisp code - that would be absurd. I’m arguing that well-written Lisp code is just as readable, if not more, than well-written code in other languages (particularly Python), and that Lisp doesn’t make it harder to write readable code than most other languages.
The reason I’m using Python right now, despite wanting Lisp’s advantages, is Python’s ecosystem. The ecosystem gives me these benefits:
Tons of educational resources for every part of the spectrum.
My questions were usually already answered online on StackOverflow, blogs, or web sites built with HTML 4. (Yeah, Python is that old.)
There’s tons of knowledgeable people if the first two don’t help. If I have to hire them, they’ll probably cost less due to their abundance and geographical spread.
Code is available for about every kind of area. There’s battle-tested code for specific needs I have.
Good tooling. Especially, the free IDE’s that catch my mistakes. There’s also tools to make the code go faster.
The subset I use should be easy to port later, maybe automatically. The py2nim project(s) prove that out given what they already did is way harder than what I had in mind.
So, these are the reasons I delayed Racket or CL to start writing Python. Although it has gotchas, the language, educational resources, tooling, and subsetting let me start cranking out working code before I even understood the language or its libraries. Flask even let me crank out two, web apps without knowing anything about that. I’ll quickly add that I’m also grateful to everyone that contributed to all of that. Their generosity helped me quickly avoid personal headaches and help other people out, too.
I’m definitely learning Python for real as I go along. The IDE mostly complains about typos and refactoring errors. It’s just that Python reminds me of QBASIC and VB6 in how I can just get straight to productivity with minimal effort invested. Then, get more productive as I invest more effort. And when it doesn’t cut it, switch to a rea… uh, a language with better control of resources and/or high-level expression of my ideas. While I get comfortable in that language, it wouldn’t surprise me if I still prototyped, analyzed, and tested code in Python before porting it to that language. Can’t let those hard-earned skills go to waste. ;)
So you’ve never actually learned a Lisp? The reason Lisps are useful to learn is that they give you good habits that you can start incorporating into your Python code. This is widely known and it’s the reason behind scheme.
So you’ve looked at Lisp, recognized its qualities, but you’ve never actually learned one, even though its biggest advantages come from what it teaches you?
I lost my memory to a brain injury a long time ago. What you see here are how I can work with combinations of fragments of what I had, things I pick up, etc. It’s much harder for me to learn, focus, and code now.
At present, I work 8-13hr shifts with high-priority projects to code that are easier to do in an established language. So, I focus on that, family, or resting. Many off days I have zero energy. I plan to do HtDP when I get free time away from higher-priority projects. Then, probably CL for its ecosystem advantages over Racket. Especially tooling.
I’m very sorry, I didn’t know about your brain injury. The core principles of Lisp can be learned from scheme, which is a simpler language. It’s very easy to learn through The Little Schemer.
It’s a short book that teaches it with some form of immersion technique, but it might require varying amounts of concentration depending on how well you adapt to the syntax. Once you’re familiar with the syntax, scheme is very easy to work with, as it’s overall only a very small set of very well chosen rules. I think reading this book, and then trying to write some simple programs in scheme once in a while, could help you find a side of programming that could make Python easier to work with for you (or anyone who doesn’t know a Lisp), and it would take less than a day of work.
Basically Lisp is like stretching. It’s hard but you have to do it because it makes everything easier.
A lot of the pro-lisp answers are because “people are biased against lisp”. I think this is unlikely. My realistic answer is that “Lisp is not actually that much better” or “language choice is a proxy for some other confounding factor like programming experience”. My crazypants answer is that powerful languages are actually bad for collaboration.
Having worked with Java for around a decade and then Clojure after, I can definitely say that Lisp is indeed much better in a wide range of scenarios. For example, here’s a presentation on the application my team develops, and the benefits we saw from using Clojure. I simply can’t imagine developing something like that with a small team using a language like Python.
Clojure community is also a clear counterexample to the idea that Lisps are bad for collaboration. My personal experience is that I never contributed to a single Java project during my time with it. Since I moved to Clojure I’ve contributed to lots of libraries I use, and people often contribute to the ones I maintain. There’s a vibrant community around the language with lots of collaboration happening all the time. There are also lots of companies using Clojure commercially, and some have grown to have teams with dozens and even hundreds of developers. Here’s a talk from one company that grew to large scale using Clojure.
Do you believe there are meaningful improvements you can make to lisps, or the lisp communities, that would make it more popular, or do you believe the issue is entirely with non-lisp users?
I ask this because this seems similar to a common problem in formal methods communities: the assumption that it’s other people’s fault for not using FM, as opposed to a meaningful issue with the tool or community that drives people away. Often insiders have a very different view of the issues that the outsiders they want to reach do.
I see Clojure as one such improvement. I find that the additional syntax it introduces with data structure literals results in significantly improved readability. I also think that since Clojure was aimed at production use from the start that helped shaped the tooling around it. Clojure has had a great story for managing libraries out of the gate because it piggy backs on the Java repository ecosystem. This facilitated collaboration and library use from the early days.
Clojure also manages to side step the niche ecosystem problem by embracing being a hosted language. This gives it access to existing ecosystems around .NET, JVM, Python and Js. So, you don’t have to worry about finding mature drivers for databases, crypto libraries, and so on.
I think that the growth of commercial Clojure use over the years speaks for itself. Nowadays, it’s used in many different domains by companies big and small, including Apple, Atlassian, Boeing, Walmart. In case of Walmart, tech isn’t even their primary business. If there was no practical advantage to using the language then we simply wouldn’t see this happening.
And yet it’s still not nowhere near as popular as languages like Go, Kotlin, Rust, and Swift, languages that came out after Clojure. Go and Rust didn’t even have existing ecosystems! So why is Clojure not mainstream? What’s holding it back?
I propose that you, as @yogthos, are not the right person to answer this question. That’s because you’re an expert in Clojure, and the price of expertise is expert blindness. Once you master something it is incredibly hard to understand what it’s like to not know it inside and out. You’ve rejected most of the problems people have provided in this thread because they are not problems once you’re an expert. But they’re still what people perceive about the language, and often they’re what people initially experience with the language.
This has been on my mind a lot because I’m doing similar work for formal methods, interviewing people and researching what’s holding it back. The problem is that almost everybody in FM is already a master, so their efforts have for years been shaped by what masters think outsiders need, not what outsiders actually needed. This is f.ex why people have been putting a huge amount of time into switching Alloy analysis from SAT to SMT but nobody’s bothered to add a CLI yet.
We might need to differentiate in these discussions between languages that are popular for whatever set of reasons and languages that got popular because highly-influential companies pushed them. That’s 4 out of 4 on your list. Add .NET and Java to that. I mean, a company as rich as Apple announcing their next, big language was a systems Lisp instead of Swift probably would’ve led a Lisp to having massive uptake and investment overnight. Also hints at how to get a language to succeed against all odds: get a FAANG or whatever to make it a major language in their ecosystem, esp with money or users tied to it.
Those not backed by highly-influential companies seem to be successful or not for other reasons. These Lisps would be judged by the other reasons. Looks like a lot of reasons versus the one, major driver for people adopting each of the above languages.
There are counter points, however. Dart, Reason and Flow don’t seem to have nearly the buzz online that you see from Go/Rust/Kotlin/Swift, and those all had pushes from the same large companies.
Those are good counterpoints. I’ll modify my claim to say I guess big company was primary advantage on top of other influences I’m less sure about.
I’m not saying that a push from a big company isn’t a strong advantage, just that it’s not sufficient to drive adoption of a language. If it was, we’d all be writing VBScript in our web browsers, rather than JavaScript.
There are some situations, like Apple + ObjC and Swift, where a company has the ability to drive adoption of a language pretty heavily.
It’s not just another good point. You just made me remember that I did write VBScript at one point. Had to keep reusing my BASIC skills. That’s one I won’t be relearning, though.
I’m not sure why you find the fact that languages from the same popular family would be be more popular surprising. It’s much easier for somebody to go from one mainstream language to another because a lot of the concepts and patterns transfer directly. Learning a language from a different family takes a lot more up front effort. This is precisely why it’s so notable that Clojure is being used in the industry right now, and it’s adoption is growing.
While I’m an expert at Clojure, I also have extensive experience teaching Clojure to beginners. My team has been using Clojure for around a decade now, and we regularly hire coop students who have little programing experience, and haven’t even heard of FP or Lisps. I think that gives me a pretty good basis to say that learning Clojure is not inherently more challenging than any mainstream language. I’ve rejected most of the problems people provided because I’ve worked with a lots of beginners who were able to overcome these problems easily. If a second year computer science student with little programming experience is able to pick up Clojure within a couple of weeks and write useful code, it seems silly to argue that the language is somehow inherently challenging. In fact, I can get somebody with no programming experience productive with Clojure much easier than I could with a language like Java because there are less concepts involved.
I’m kind of curious about your hiring process with that claim. Do you hire really smart people inclined to pick up any tech or average people willing to put in effort who learn because it’s truly easy? Have you accounted for that in assessing how easy it was to train them?
I like testing tech usability on folks that are less technically-inclined or at least challenged when moving to new things. The easier it is on them, the easier it might be in general.
Our experience is that it’s actually much easier to hire for Clojure than it was for Java just because it acts as a filter. We used to get hundreds of applications for a Java position, and we found that resumes were only loosely correlated to the actual skill of the candidate. With Clojure, we might get a dozen applicants, but they tend to be much better quality overall. People who apply for Clojure jobs tend to be open to learning and trying new things. We only hired one dev who had prior experience with Clojure, but the rest applied because they were interested in trying something different.
During the interview we tend to focus on CS basics to see whether the candidate understands the use of data structures and algorithmic complexity. We don’t ask any puzzles in our interviews, and mostly treat it as a pair programming session. The goal is to see that the candidate has a solid understanding of the core programming principles, and that we can communicate easily.
My experience teaching is that people can pick up Clojure very quickly with a bit of mentoring. We start by giving the hires a bit of an overview, get them to read through some online resources, and play with it in the REPL on their own. Then we pair up a bit to see if they’re on the right track. Next, we start giving them some small tasks to do, like simple JIRA tickets, we then do code reviews together to show them how to accomplish things in a more idiomatic way, and it goes from there.
There is a presumption here that collaboration is to be optimized for. Obviously, collaboration is a desirable quality in a language. But I’m not sold that we must sacrifice metaprogramming on the altar of collaboration. (I realize you’re not saying this.)
I’m biased here; I’ve sunk a lot of time into malleable grammars, so there’s bound to be some sunk cost fallacy at work in me. But I worry that tech culture (whatever that is) seems to subconsciously adopt more corporate views of programming as time goes on, and this is another one. Namely, that programming is so error-prone and tricky, we must put as many guard rails in our tools as possible.
Thus you get things like Elm mandating a certain architecture, Rails requiring files to be named a certain way, and avoidance of macros because “readability,” despite things like JSX doing exactly that. In short, we seem to be okay trusting that $MEGACORP engineers should wield maximum computational power when making these tools, but we never trust regular developers with that power.
That seems a little too authoritarian for my taste.
It makes sense to me that collaboration and metaprogramming are in opposition. In order for two people to collaborate, they need to communicate, which means they need a shared vocabulary. Meanwhile, metaprogramming is all about giving individuals the power to customise their vocabulary, but “unique, personal vocabulary” is the opposite of “shared vocabulary”.
That’s not to say you must choose one or the other, since people can always learn the new vocabulary, and then they can collaborate. But that’s not a solution so much as another impractical extreme: you can avoid collaboration, you can avoid metaprogramming, you can do both and accept that you’ll spend a lot of time on education, or you can pick some point between all three with a little bit of collaboration, a little bit of metaprogramming, and a little bit of education to cover the difference. But whatever you choose, you can’t crank up both collaboration and metaprogramming at zero cost.
As for authoritarianism in tech, as megacorps employ a huge number of technical people, and since they often talk about the problems they face and their impressively-engineered solutions, it’s only natural that “tech culture” reflects those ideas. To try to fight against those trends directly would be fighting against human nature, and that’s not a fight you can win.
Instead, make cool stuff and talk about it. Build something neat with metaprogramming cranked up to the max, and show people what the benefits are. Talk about projects you’ve worked on that emphasised configurability and what the experience was like. Help broaden people’s horizons, and trust that they can figure out their own comfort zone among the alternatives they’ve seen.
I wax poetic about AHK and love fringetech, you don’t need to convince me about the importance of expressiveness ;) I just think that this is a possible explanation for why the languages don’t become mainstream.
(I wrote a followup defending this here.)
You said it buddy. I’m missing it so much with Python that I ended up dabbling with Hy Language. The trick that experienced Lispers told me was that you can stay within the regular language in a maintainable style as much as possible. Then, use macros where they solve more problems than they create.
I don’t think this correct, mainly because people who have tried both, seem to prefer clojure to python (maybe selection bias). I think the answer is somewhere between people use what they tried first, and people have pretty closed minds, its better but not THAAAT much better when you are an average programmer.
Python is popular because it looks like pseudo-code. Pseudo-code is called so because it looks like most common languages. Lisp is not a common language because it was not a common language. If Lisp had become as influential as ALGOL, the question would not refer to Lisp at all, but to RacketScript or ClojureScript or some other modern refinement thereof which anyone with previous programming experience could quickly pick up because it looked much like any other parenthesis-heavy language, which would be most languages out there.
The fact that Algol based syntax is popular because it’s already widely used is basically the thesis of the article. I think an interesting point to consider is the reason Algol became more popular than Lisp.
A common view is that it’s more natural in some way, and I don’t actually think there’s any evidence to support that notion. My team works with Clojure, and we regularly train coop students on it. What we see is that students from earlier years who have less programming experience consistently pick it up much easier than those who have more experience. We also noticed the same pattern for experienced developers as well. For example, somebody with a strong background in Java will often find switching their mindset to Clojure more difficult than somebody with little to no experience.
I think the actual reasons are largely historical in nature. General computing started becoming accessible back in late 70s and early 80s. Back then the hardware was very limited. All you had to work with was a single core CPU coupled with a tiny amount of memory. You didn’t have to worry about things like parallelism, concurrency, or networking. The goal was to squeeze as much performance out of the hardware as possible. So, something like C was a natural choice back then because it was effectively portable assembly that could be compiled against different architectures.
Meanwhile, Lisps were largely used on supercomputers and only a tiny percentage of developers got exposure to these languages because using a VM was just not practical on consumer grade hardware. Even back in the 90s and early 2000s GC was considered controversial in terms of performance. When Java came out a lot of people claimed that it was a non started because of that.
So, a whole generation of programmers were trained on C style languages, and this cemented C style syntax because that’s what vast majority of people had exposure to.
There is evidence to support that familiarity improves learning and uptake. The pseudo-code languages are closer to the English that people in my area use to describe solutions to their problems. The Lisp’s look alien in comparison. I’d definitely like to see studies done on how much it really matters for people of various backgrounds. I’m also for skinnable syntaxes where you can pick the one you like that all get turned into same, underlying semantics.
Familiarity can also hurt uptake if you falsely believe that something new is similar to a thing you already know, when they’re not actually similar. Although Python looks somewhat like English, it’s categorically different. An English-like syntax can fool beginners into thinking that the computer can “kind of understand English” (or something similar, if not exactly that - e.g. a computer knows what “this” means) when that couldn’t be further (farther?) from the truth.
Here’s a concrete example: Verilog is a Hardware Description Language. You describe how the hardware should look, and then a “compiler” translates that declarative description into hardware (or software for the purposes of simulation, but that software is pretending to be hardware). However, the Verilog syntax (and some of the semantics) look almost exactly like that of a normal programming language. As a result, I and many other hardware engineers started working with Verilog using the mental model of a normal programming language that was “executed”, ran into many mental blocks when that model broke down, and ended up had to very painfully re-learn the language as a declarative hardware description language.
I disagree that any programming languages have any meaningful similarity to natural languages like English. I’d like to see some studies as well, but my personal experience is that Clojure is very easy to teach to somebody without any preconceptions regarding how programming should be done. On average, the students my team hires get productive to the point where they’re able to write useful code in about a week of working with it.
And of course, Lisps are one of the best tools when it comes to having skinnable syntaxes thanks to their powerful macro systems. In fact, I’d argue this is the key reason why Clojure core language managed to stay a small and focused in over a decade of use now. I wrote about that in more detail here if you’re interested.
Lisp is one of those things that I want to like, but every time I think I’ve found a way to actually like it and use it something stops me. Racket is the closest I’ve ever come to using a Lisp-y language for non-trivial code. I really enjoy the community, there are a ton of libraries available, and there’s even Typed Racket! But then I remember that someone else is going to have to read / modify / run my code and they’re likely to be annoyed that I used something relatively obscure, and I back off. So my theory is that Lisp is less popular than many people think it ought to be at time
tsimply because it was less popular than many people thought it ought to be at timet-1.Yeah, this is my reasoning for not using Lisp/Clojure at work. I would feel bad for forcing it on someone that has no interest in learning it.
I made the case at Racket Con a few years ago that the way to get adoption is to introduce it in tools that aren’t critical to production, which shows people the power, but allows them to slowly learn what makes it tick. I tried to introduce scribble for my team’s internal documentation afterwards, and failed because $X decided godoc was better. As the codebase is go, it was hard to argue against, even though most of the documentation is not a good fit for godoc.
That’s a great idea, even if it didn’t work in that particular case. Now that I’m thinking about it, I could probably find a way to introduce scribble into my work, thanks!
Python ended up on my radar for two reasons. First: I didn’t have a license to matlab anymore and the internet told me that Python+numpy could be a partial replacement. Second: When I needed to rapidly prototype a website I could use Rails or Django, and for me Django was a better fit philosophically. The batteries included stdlib was a big help.
In my experience the problem with lisp is a fragmented community because there are so many flavors of lisp.
This link might be old hat, but for those who haven’t seen it, I found its argument on this topic to be pretty compelling:
http://winestockwebdesign.com/Essays/Lisp_Curse.html
Clojure is a clear counterexample to this argument.
…And it would be very interesting to study more about Clojure’s community and tech ecosystem to try to come up with an argument as to why.
Clojure was only 2 years post 1.0 when this was written, and though it’s a counterexample to be sure, it’s only one in the long history of lisps in the past half dozen decades.
Yet it seems to be the first lisp written with the expectation that you wouldn’t spend your time manipulating lists to get things done, but rather spend your time getting things done by manipulating lists. Just the perception of this novice.
Frustrated that the top quora answer is from somebody who hates lisp.
My take:
Because of the brackets? I never quite understood how this can be found aesthetic or intuitive to be honest:
Python is not my favorite language either, but this looks just so much better:
My suspicion is that you haven’t spent enough time with it.
Over the years I’ve used languages with wildly different syntax (Lisp, Haskell, Ada, Python, Erlang) , and after a few months with any of them, my eyes and brain filter out the syntax and all I really think about is the semantic structure and what the code’s doing.
I think it’s part of the reason people are so persnickety about code formatting - consistent formatting makes common idioms and syntax elements easier to read at a glance.
I actually agree that it looks better, but I think that’s besides the point. For me the benefits of the S-expression syntax outweigh what I feel a is minor cost in aesthetics. Those benefits include: simplicity through uniformity, no ambiguity, and interchangeability of code and data (meta-programming).
This is a matter of subjectivity for anyone who’s experienced with programming. For instance, I find the Lisp version much more beautiful. The indentation “flows” in a way that is much more curvy and less blocky than the majority of other languages - less so in the example that you gave, but in the general case.
Why do I think that it’s more beautiful? Because, even though I wrote Python and C for 4 years, I discovered and wrote Common Lisp for 5 years after that, and my tastes have changed. I think that it’s more interesting to ask beginners which syntax they prefer.
(not relevant to my point, but you might be interested to know that after you’ve written Lisp for a few months, the parentheses fade from your perceptual awareness. Lisp programmers read code mostly using indentation - we don’t count parentheses)
Your Python snippet is longer than Lisp one while not conveying extra complexity. Another way to say, less elegant.
Oh? Lisp: 29 tokens, Python: 24 tokens. If I count python indentation as a token, then python goes up to 28 or 30 tokens (more if 2 indentations on a row equals 2 tokens), which seems like a off-by-one error rather than clear win for either :)
I don’t think that calling Lisp parens “tokens” is very accurate, because (1) they’re pervasive (more so than newlines by far) which leads to (2) tooling+experience causes them to perceptually vanish.
In other languages, you notice every parenthesis. In Lisp, you notice few (but you do notice some). I perceive that code fragment as:
I agree that there is no clear winner, though, even if you fix the Lisp formatting:
(note the unmatched open parens) I think that much more interesting examples involve larger and more complex code, which allows you to (reasonably) compare Lisp macros against the abstraction features of other languages.
Clojure:
Tbh, when you use it enough all you see is this anyway:
Which amounts to about the same as python.
Given the answer to every vague software question is “it depends”, you can’t just talk about “Lisp”.
I can’t install “Lisp”, I can install Clojure or Racket or SBCL; each has its own different tradeoffs, libraries, and communities. So the question isn’t useful from the get go, because software in the real world is about specific situations and resulting tradeoffs and engineering decisions.
I wouldn’t write the flight search engine that powers Google Flights in Python; having worked with the people who wrote it, Common Lisp actually seemed like a good choice. But I wouldn’t use Common Lisp for 99% of the software I’ve written over the past few years. I don’t want to write every tiny utility I might need from scratch because there’s no libraries. And the language itself wouldn’t have added much.
And while Clojure definitely and probably Racket are much better ecosystems than CL they still wouldn’t help me much with the job that did scientific computing—I guess Clojure + ImageJ would have worked just fine, but Clojure wouldn’t have added anything, and the organization was already using Python.
I find it telling that almost every comment that points out a missing part in the Lisp metaverse is given a retort of “But Clojure…”
Clojure is not Lisp. It’s an implementation of it. That’s the problem - there’s not a reference implementation that can be pointed to as the “reference” to follow. Because of that, excessive fragmentation is a guarantee. There are so many of them out there, each with large enough standard library differences to make it difficult for a fair fraction of developers to think twice. All of the Python interpreters out there that I know of provide a fairly consistent standard library such that it’s not surprising. They pretty much behave the same way with the same semantics and grammar. C and C++ have large hidebound standardization committees and a large audience to demand a lot of primitives and behaviors are present in most general situations.
The fragmented nature of the Lisp family means that it’s clojure vs racket vs scheme… A whole bunch of versus and infighting about what really is the definitive Lisp. And because of that, each one fights on its own, succeeding on its own, et al. An advocate for Clojure is less of a lisp advocate and more of the Clojure advocate. A Python advocate doesn’t have that burden, so their advocacy suffers less from message incoherence.
As a side note, yes, Python 2/3 is a perfect example of a reference splitting the ecosystem and there’s been much effort into choosing one over the other to resolve that split.
I don’t really follow your argument here. Lisp is a family of languages, and it’s exactly the same situation with Algol style languages. You have C, C++, Ruby, Python, Go Java, Rust, etc. Python is just one language in a huge family that’s bigger and less consistent than Lisps. Fragmented nature of Algol family means that it’s Ruby vs Python vs Go. A Python advocate is certainly not a Ruby advocate any more than Clojure advocate being a CL advocate.
The question asks why Lisp (language) is not as popular as Python (language). Aside from a few pedants, most people don’t compare or even talk about Algol vs Lisp. They talk about Lisp (usually picking their favorite implementation as the language) vs another language.
You can’t have it both ways Y. The discussion is around “why isn’t {{language}} popular”. Not “why isn’t {{language family}}popular?”
No one seriously would conflate C and Python despite being under the same nebulous Algol umbrella. Languages are the tools that are used. Language families are multiple sections of the tool store.
The write up is clearly talking about Lisp family of languages as it uses examples from different Lisps. It seems to me that you’re the one trying to have it both ways here by lumping all Lisps together and comparing them to Python as if similar languages like Ruby and Go don’t exist.
I’m simply pointing out that your argument regarding fragmentation doesn’t really make sense because the exact same argument holds for languages like Ruby, Python, and Go.
Actually I’m pointing out the fundamental comparison is flawed. For example, you don’t compare “Declarative languages” to C - you compare C to a declarative language or set of them.
Also, you’re flat out wrong. There’s multiple write ups of different opinions, many of them anti-lisp in general. To say the writeup covers the family is disingenuous.
When you phrase it that way, I completely agree. It would be much better to pick a concrete Lisp like CL or Clojure and compare it against Python.
Personally Python’s massive standard library makes it more popular for random projects for me. I might delete this code tomorrow, so I might as well try to get something hacked together as fast as possible.
That’s one place where Clojure really shines, I get access to all of the JVM, Js ecosystem, and now Python. I can use the same language with the same tooling and get all the benefits of these ecosystems.
Python’s coherence in documentation, and huge standard library set within that documentation, helps enormously, I believe.
In my opinion, Python is so popular because its semantics are basically C with GNU extensions, operator overloading, memory safety and a decent garbage collector.
Anyone who have ever programmed in an imperative language will be able to get up to speed very quickly. The only two complicated concepts to learn with Python are the difference between scalars and composite types (especially with respect to references / copying) and closures (with at least basic, intuitive understanding of lexical scoping).
Also, a lot of people coming from more unwieldy languages such as PHP, JS of old or C will probably enjoy the Python experience a lot. Others might feel a little bit constrained, but higher order functions along with dynamic typing will actually allow them to encode more complicated constructions in a less safe, but nevertheless a working way. Decorators, operator overloading and keyword arguments can be used to create some rudimentary DSLs as well.
Of course, when you compare all that with - for example - much more sensible semantics of Racket, where DSLs can be made really first-class, it makes zero sense to stick around Python long-term. And that’s where the libraries will get you. It’s more work to re-implement them so you shoehorn your DSL into limited Python syntax, tack on some type annotations if you feel adventurous and give up. And since a lot of people are only now crawling from the PHP space or coming into IT anew, Python is getting the mind share required to grow the libraries a little bit more.
I have no idea what comes next syntactically, but I am enjoying the tug-of-war between single and multiple dispatch and I am still holding my breath for the great constant-propagation-like ahead-of-time contract validation comeback some dynamic language developer will pull off to prove that you don’t really have to use Haskell to get the same safety guarantees. :-)
As person who only learned to program and work with computers about 4 years ago, I would say that looking back the syntax really doesn’t mater. Someone who doesn’t know programming or computers will find all code confusing and ugly. This might be biased because I’ve recently become interested in Lisp, but I think the amount of material saying Python was easy to learn and the idea that I could get a job in it was the reason I learned it first. If it had been a Lisp language I would have banged my head against the wall until I learned it too.
The top answer claims that Lisp has a much steeper learning curve than Python, but gives no evidence, and on paper, his argument is false.
Python’s semantics are very similar to Scheme and CL (the latter are simpler, even), and while the syntax is completely different, Lisp syntax is significantly more regular: open parenthesis, name of operator, arguments separated by spaces, close parenthesis.
Compare that to, uh, the Python BNF grammar - or just look at some Python syntax. You write
returnwithout parens, function calls with parens, andprintsometimes has parens and sometimes not depending on whether you’re using Python 2 or Python 3. Strings can be made with either single or double quotes - but you need to triple-quote strings when they span multiple lines, even when there’s no meaning for a single/double quote with its complement on another line! Arrays are made using brackets, dictionaries using curly braces (and don’t forget that you have to separate keys from their values using a colon, and key/value pairs using commas), and tuples using parenthesis. Spaces are optional in so many places, but conventions vary - writefoo = 10when assigning a variable butfoo=10when passing in a keyword argument - oh, and don’t forget about *args and **kwargs!All of this is trivial for any experienced programmer, but much more difficult for a beginner to remember.
The top answer suggests that writing “hello world!” is more difficult in Lisp than Python. How is
(print "hello world!)harder thanprint("hello world")?“accessible, powerful, and free” - implying that Lisp is not accessible, powerful, or free (the latter of which are objectively false and the former of which is contentious and unproven by the author). “Lisp dates from an era when real computers (by which I mean computers running some flavor of Unix) were not in the hands of individuals outside of academia, government, big business, and the military.” - more fluff without any actual argument being made.
Programming has a huge learning curve, and if anything, Python adds more on to it than Lisp does. Scoping rules are more complex and difficult to remember, there’s this arbitrary distinction between statements and expressions, and another (less arbitrary) distinction between “operators” and “functions” that results in the former being infix and the latter being postfix, in addition to the former not being proper functions that can be passed to other functions (e.g. you can’t just pass the lesser-than function to a sorting routine).
If I may propose a more pathological example:
My comment was about “hello world!”, because that was the one mentioned in the answer, so I don’t quite see how your example is related to the part of my comment that you quoted…
More generally, that entire comment was about the suitability of Lisps for beginners. No beginner is ever going to need to write code that looks like that, because…
…that kind of code is very rare. That particular fragment doesn’t do anything, and more generally, you rarely, if ever, see numerical code that looks like that. The vast majority of beginner code is control flow, with a small amount of numerical code sprinkled in - for which Lisp code becomes much closer to the equivalent in other languages.
Also, this is a pathological example - not only because the Python code is indented while the Lisp code is not, but also because it is unrealistically heavy on numerical code, which is the only thing for which the Lisp syntax could undisputedly be claimed to be “less natural”. Finally, I’ve never actually seen the kind of code in this example “in the wild” in any code before, much less in anything that a beginner would write.
Edit: typo. Edit2: less aggressive tone. Edit3: hopefully even less confrontational.
Yeah, I realize I’m a bit off base. I think I’m venting a little bit of frustration from seeing the claim that “Lisp syntax isn’t any harder, it’s
(f x)instead off(x)”, which is ignoring that things get way hairier when you deal with more complex logic. But you’re right, that’s not exactly what you were claiming, so I apologize.If I’m being honest, it’s still pretty aggressive.
I don’t unconditionally accept this premise. I write nontrivial logic in Common Lisp all the time. When I don’t make heavy use of macros, it’s a little bit easier than using Python. When I use lots of macros, it’s significantly easier and more readable than the Python equivalent. Now, I’ve been writing Common Lisp for fun for several years, and I’m more than a little bit emotionally invested in it, but that doesn’t change the fact that my experience allows me to easily write complex logic in it. If you can show me evidence that I’m an outlier and that most people, given the same amount of experience with both languages and a task that is more representative of normal code, are much more easily able to read and write the Python version, then I’ll happily change my worldview. However, I’ve never actually seen any evidence for that claim (which I’ve heard many times before), nor even somebody who has written Lisp for several years agree with it.
Now it’s my turn to apologize. I rewrote my post from attacking you to attacking that example, but you’re right, I was still being overly confrontational. Please be patient with me while I try to figure out how to better convey tone through text. Let me try again…
Yeah, I agree, it’s mostly opinions. I’m not familiar if there’s been any serious studies on the understandability of sexprs, but I can dig around and see if anything comes up.
No worries, I don’t think it’s necessary; we’ve both admitted we got a little heated. S’all good :)
So what do you make of this code?
Well, what do you think of this code?
In all seriousness, you can write bad and/or unreadable code in any language. Even this code, however, looks a bit better when you actually put it in an editor. I’ve read code by this guy before and I don’t like it that much - it’s hard to read. Much better code includes part of Shirakumo’s Wavefront loader and cl-ppcre in general.
I’m not arguing that you cannot write bad or unreadable Lisp code - that would be absurd. I’m arguing that well-written Lisp code is just as readable, if not more, than well-written code in other languages (particularly Python), and that Lisp doesn’t make it harder to write readable code than most other languages.
(It’s (the (par (en (the (se (s, (sil (l y))))))))!)