Live data from Hacker News

Why is Common Lisp not the most popular programming language?

daninus14.github.io

291–300 of 339 posts

Re: Why is Common Lisp not the most popular programming language?

#291

Earlier quoted context omitted.

> But idiomatic Lisp code really does use linked lists extensively, Idiomatic python code uses lists extensively. In my (somewhat limited) experience, they're the default data structure to use for a lot of algorithms. Slightly more accurately, a lot of stuff in python uses sequences extensively, which are implemented by a number of types - but the default sequence is a list. And strings are lists. Yeah, if a list doe…

A Python list is an ArrayList/vector, not a linked list. CL lists are linked lists of cons cells.

Does the CL spec require the implementation to use linked lists or merely to behave as if it were a linked list? I believe it is the latter and that makes a world of difference when it comes to optimization.

A great mainstream example of this are JavaScript Arrays. They are defined to behave as hashtables. They inherit from Object. Their "indices" are actually strings instead of numbers (all object keys are strings and numbers get converted to strings before the lookup happens).

Despite that spec model, JS arrays have used a very different representation in practice for decades. Even in the dark ages, arrays were implemented as linked lists. Today, they might be hashtables, linked lists, boxed objects, or even unboxed primitives all while still pretending to be hashtables.

Cons doesn't have to return a linked list element.

Re: Why is Common Lisp not the most popular programming language?

#292

Earlier quoted context omitted.

People confuse code at the exploratory phase with final production code. Linked lists are a massively flexible data structure which can be great when you are still feeling your way around a problem domain. Once you have a good sense for the shape of your data it is relatively trivial to go back and update the codebase with performance optimized structures.

That may or may not be the case (that they're great for exploratory code, I have actually mixed feelings about that), but it in fact points directly at the problem I was referring to: using Common Lisp in the idiomatic and expected way involves reading and writing a whole bunch of list processing code. It's not so much that it's a foreign language in the syntactic sense (although it is) but the idiomatic semantics ar…

How is the idiom of linked lists foreign to modern devs?

You create a list of items. You can add/remove elements to the start, end, and even the middle and even indexing is just as easy with the `nth` function.

From a programmer perspective linked lists are universally better. That is to say that if a computer could perform operations on a linked list as quickly and with as little memory as it could for an array, nobody would ever choose to use arrays. We only use arrays because the computer forces us to.

Re: Why is Common Lisp not the most popular programming language?

#293

Earlier quoted context omitted.

I suppose, if you are happy with the state of things and the size of the current userbase.

I can’t imagine a single feature that would be worth a change, and I have plenty of complaints about the library. I also can’t see how that would make it more popular.

I'll never understand why a language needs to constantly evolve to be popular. There's nothing fun about having to keep up with changes, and continuous development just screams to me that a project has not yet matured. When something is stable enough to just keep working for 10 years without an update, that's not a bad thing. When did that become the mindset?

Re: Why is Common Lisp not the most popular programming language?

#294
post #105

Earlier quoted context omitted.

> But idiomatic Lisp code really does use linked lists extensively, Idiomatic python code uses lists extensively. In my (somewhat limited) experience, they're the default data structure to use for a lot of algorithms. Slightly more accurately, a lot of stuff in python uses sequences extensively, which are implemented by a number of types - but the default sequence is a list. And strings are lists. Yeah, if a list doe…

I like python significantly more than lisp. There are so many ways to express yourself in python that are troublesome in lisp. I actually think list manipulation is easier in python than lisp. I don't know, is there a lisp dialect that makes common data structures available in a multitude of ways? I seem to be able to manipulate lists quite easily in python, and switch back and forth to sets or hashes. but in lisp yo…

This is all "I don't know the language" type stuff.

If you don't know Python, slicing syntax is also strange.

Common Lisp was VERY forward-thinking and has all kinds of these features that only became mainstream decades later.

Re: Why is Common Lisp not the most popular programming language?

#295
post #34

Common Lisp once had plenty of backing from major companies like Symbolics, Xerox, and Texas Instruments, as well as smaller companies such as Harlequin. Even Apple owned Macintosh Common Lisp at one point, and SK8 (which could be considered a follow-up to HyperCard) was implemented in it. Had Apple not had its problems in the 1990s, one potential alternate version of Apple I could imagine would be some sort of Lisp…

The saddest thing to me is that Brendan Eich didn't do a scheme like he intended.

If that had happened, the web would have been fast 15 years earlier. Things like Flash wouldn't have ever happened. ES2015 would have never been necessary. HTML would have gone away. CSS would have never existed. Declarative web frameworks would have become a reality decades ago. WASM wouldn't have happened. Even stuff like the App Store likely wouldn't have happened because Scheme would have been fast enough that Jobs would have stuck with his initial web app idea.

Re: Why is Common Lisp not the most popular programming language?

#296

Earlier quoted context omitted.

> What world are you living in that corporations actively want their employees to work slowly or to have too many employees? Who does that benefit? 1) In the corporate world, a larger headcount under you means you get more funding for your initiatives. If you get things done with a team of five, that signals to upper management that that's all you need and your budget will be adjusted down accordingly. 2) When it com…

Your comments are describing two different things. - Technical leaders choosing a language that's easy for developers to Grok to make them more fungible, and make onboarding easier. - Corporate managers purposefully choosing a language as a "Response" to Common Lisp, as you said, to tank the performance of a company for more funding. One is actually happening, the other requires me to believe corporations even know w…

You're missing the point.

It's not really a response to Lisp as such, it's a response to anything which makes developers more productive. Developments from the Lisp world have had trickle-down effects that make other languages and IDEs more powerful: garbage collection, hot-reloading, etc. The productivity gains realized by these developments, however, have been more than neutralized by a concomitant increase in corporate BS. So it's not really a conspiracy of orgs out to get Lisp but it does make Lisp a bad fit for organizations which rely on inertia, ego, and fungible worker-units, which is most of them.

Re: Why is Common Lisp not the most popular programming language?

#297

Earlier quoted context omitted.

I'm not sure if Rust is a good comparison though. Rust is a lot closer to C, it is a language influenced by C, and current popular programming languages tend to also be influenced by C. So while there is a lot different with Rust, a lot of knowledge from, lets say, a C developer can carry over. Say your a C developer, or C++ developer and I am a Rust developer trying to sell you on Rust. You have to learn a new langu…

I'd argue Lisps are worse today. They encourage a thing that's generally discouraged in C: macro programming and typedefs. You're coding in Lisp, but you're actually coding in your own dialect of Lisp, eventually, with lots of idiosyncratic code that's difficult to reason about. That doesn't scale well in collaborative environments, where many people are touching a vast codebase (which I don't think was really a thin…

You can code your own dialect of ANYTHING. OOP does this all the time (anyone for Enterprise Fizzbuzz).

C considers macros as bad because they are dangerous and have all kinds of weird side effects that break things. If they had all the capabilities of lisp macros, you wouldn't be hearing all the complaints.

Re: Why is Common Lisp not the most popular programming language?

#298

It's the learnability of the language. Remember BASIC? You could show someone a FOR ... NEXT loop and they would completely understand. After a couple more 10 line programs and you can safely hand over the keyboard and handle the "how do I?" questions You had to show very little before they understood. Now try Lisp ... M: This is a list S: What can I do with it? M: By itself nothing but trust me it is important. This…

    (set x (list 1 2 3 4 5))
    (for item in x 
      (do stuff to item))
Now try to explain BASIC, but do it by first explaining how to create and manipulate a block of memory.

You are conflating language differences with the real argument which is the decades-old debate about whether introductory courses should be practical or rigorous.

Re: Why is Common Lisp not the most popular programming language?

#299

Earlier quoted context omitted.

> Also: a maintenance nightmare as soon as you have more than ~1 person working on the codebase! Lisp isn't any harder to maintain than any other language. The Lisp codebases I've worked on, even professionally, were originally written by talented, experienced engineers and were in fact wonderful to maintain. > Now imagine something like Lisp where every developer & team morphs it in a different way and you have a pr…

> I think you might be on to something. Symbolics was very much in danger of making large software projects possible by one person or a small team of people. It seems as if the corporate world has responded to the proliferation of more powerful software development tools -- not only in Lisp, but certainly Lisp and Smalltalk had an outsized influence -- by lowering the skill ceiling to make devs more fungible, and cre…

> This is a ridiculous LISP conspiracy theory that really needs to die.

Not really. Lisp can be a power amplifier if you can keep it under control. But, as I've argued above, that limits you to a small stable team.

If I could start a new company with a few solid Lisp buddies and I knew that's going to be the core team for the next decade, I think I'd use Lisp and it would be a significant productivity gain.

But but but.. those are some unrealistic constraints. If I'm starting a company presumably I want the company to keep growing as much as possible, not stay with a few core people for years. So no, I wouldn't use Lisp.

> to have too many employees

All of them, the goal of both startups and public companies is to continuously grow. As soon as growth stops that is seen as a problem and the decline begins. The only exception is privately held companies who don't run on VC money and don't have any intention to become public. Those might be the best candidates for Lisp.

> to work slowly

No company specifically wants that, but they vastly prioritize being able to hire 10,000 scrum interchangeable cogs to do development and that's not the environment where Lisp works well.

Re: Why is Common Lisp not the most popular programming language?

#300
post #200
post #102

Earlier quoted context omitted.

> I find it nearly impossible to parse this without actually maintaining the stack in my mind. You don't write out RPN in a long sequence like that. I'm a devoted RPN advocate and seeing "x y + 2 ^ = x 2 ^ 2 x y * * y 2 ^ + +" is indeed difficult to parse. But that's not at all how you use RPN. You compute the problem going from smaller units to larger units getting intermediate results as you go and combining them.…

How would you write this algebraic identity?

You write equations in the usual algebraic form. You don't write RPN on paper (or screen), that's not a thing.

When you're going to compute a value on the calculator, that's where you use RPN starting from the innermost computations working outwards, because you have a stack to keep all the intermediate results handy.

Again for like 2+2 it doesn't make any difference, but if you have a long formula with lots of values and different operations, it is much easier to do correctly and fast with RPN.

Post reply on HN