Live data from Hacker News

Why is Common Lisp not the most popular programming language?

daninus14.github.io

241–250 of 339 posts

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

#241

Earlier quoted context omitted.

> With Rust do you close all your } manually? You don't have to, because you don't end up with }}}}}}}}} in Rust, because statements end with ; and not }.

I didn't end up with ))))))))) in Scheme because it was easy to create smaller functions. I do see rust ending with } } } In TypeScript I'll often find myself ending blocks of code with }); } }); } I'm having fun with TS, but I do miss the parentheses. They were simpler.

1. Lots of small functions lead to code in which bugs often hide in plain sight, see this old memo by John Carmack: http://number-none.com/blow/john_carmack_on_inlined_code.htm...

2. Scheme is better than Common Lisp when it comes to Lots of Irritating Superfluous Parenthesis, since declaring a variable in Scheme (using 'define') doesn't create a new nesting like it does in Common Lisp (using 'let').

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

#242

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…

> 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 comes to software, companies favor the ability to monitor and control the development process from above over speed. Agile only gets uptake among large orgs inasmuch as Agile consultants promise them this.

3) There is, decades after The Mythical Man-Month, a sense that you can get a good programmer's worth of output -- without a good programmer's worth of risk -- out of several, much more fungible, mid programmers.

4) Egos on the line. Tom Smykowski from Office Space is real. Need proof? Propose something sensible like having engineers talk to, or shadow, customers so they can see what the pain points are in their work and which pieces of the software need attention... and see who bristles.

No conspiracy is needed. Companies can remain stubbornly dysfunctional, and will bizarrely spend more to protect that dysfunction, for decades, than to try something better. My father proposed more resilient ways of running an assembly line in the 1960s, upper management laughed. In the 1980s what he proposed was one of the tenets of the "Toyota Way", but it took until the 90s/2000s for American managers to start listening.

This goes double when you realize that software is off most companies' critical path, and addressing performance issues among software teams is way less important than addressing performance issues among, say, sales and marketing teams.

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

#243
post #88

Earlier quoted context omitted.

> I don't see why I should have to do the tedious work of figuring out all the parentheses manually. I think most people who write a lot of Lisp don't do that. I use Paredit mode in Emacs, which doesn't allow the parens to become mismatched and has operations like "move the last token out of this expression" and "jump to the next expression" so it actually feels like you're editing a tree rather than a chunk of text.…

> operations like "move the last token out of this expression" and "jump to the next expression" And that is the problem. When I am writing code, last thing I want to do is to think about tree manipulation and the numerous commands to do similar-but-not-the-same operations. This is the same reason I don't like Vim, it's hard enough to keep the problem domain in mind, there's no mental space to also remember the ed-st…

After the learning period it becomes muscle memory and you don't have to think about it. If you're not willing to put in even the small amount of effort to build up new muscle memory, I don't know what to say other than don't be so defeatist.

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

#244
A good deal of my work involves moving data in and out of databases. For the three Ps--Perl, PHP, Python--it is trivial to set up the libraries for the commonly used databases, after one can move on to work. Is that the case for Common Lisp?

Another part of my work involves the web. There I can use mod_perl, mod_php, and mod_wsgi. What about Lisp?

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

#246
post #74

You want to learn programming. Lets get started - how long does that take to bang out 10 exercises? Order the estimated results from quickest to slowest. Here's my estimates (don't like them, show yours! It'll be interesting): - Scratch - python/perl/ruby/javascript - C/Java - Swift/Rust - Anything else running on the jvm - - a whole lot of daylight - - common lisp. And many if not most will fail to get to the first…

Interestingly, Scratch is based on Logo, which is based on Lisp, although that Lisp is older than Common Lisp, so that means a Lisp is at the top of your list.

If you want a really nice language derived from Lisp, try REBOL or Red (derived from REBOL).

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

#247
post #186

Earlier quoted context omitted.

Half of the phones in the US run BSD. Good luck getting SBCL on it though.

SBCL is a Common Lisp implementation with: * a runtime in-memory native code compiler (-> COMPILE) * a file native code compiler (-> COMPILE-FILE) * and a runtime native code loader (-> LOAD) Apple forbids providing compiled languages on (I'm talking about "ON THE DEVICE") iOS. Good luck getting those onto iOS. Their own Javascript runtime JIT is allowed, others are not. Common Lisp runtime native compilers are not.…

> Good luck getting those onto iOS.

That's what I said, yes.

Although as long as you're not distributing the code these restrictions don't apply. Depending on what you're doing that's either a technicality or that's how you intend to proceed, there's a reasonable amount of iOS code out there which pays no attention to Apple's rules whatsoever, and which you can't download binaries from the App Store of.

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

#248
post #205

Earlier quoted context omitted.

I remember Erik Naggum. He was always worth reading, but yeah—incredibly abrasive.

He was so often frustratingly right, too.

I particularly remember an extended rant that Lisp == Common Lisp, and Scheme is not Common Lisp, and therefore Scheme is not Lisp. I’m oversimplifying—Erik gave specific reasons—but that’s what it amounted to. Derailed an entire conversation, IIRC.

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

#249
post #198

Earlier quoted context omitted.

> Lifetimes on the other hand seem unnecessary in 99% cases where compiler forces you to use them - why can't it just assume that all the required parts have the 'a and complain if something violates that? Rust does that, this is lifetime elision. If the compiler complains about missing lifetime annotations, that means it can't infer the lifetime. Granted that it not-infrequently feels like it should be able to, and…

To the contrary I ran into cases pretty quickly that rust just wasn't useful for in my opinion. One of my use cases was something like a mutable borrow of an struct in a struct in a single threaded code path wasn't allowed because the entire struct was mutably borrowed or some nonsense. I believe the "idiomatic" way was to create some weird abstraction to appease the borrow checker that the thing being borrowed once…

From what I have observed, most advanced Rust authors don't bother with lifetimes at all. Every pointer becomes an integer index into some slice and they mostly skip the lifetime/borrow checking. Lifetime are only kept on the few, easy-to-reason about cases. Kind of funny actually.

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

#250

Earlier quoted context omitted.

On the strength of your first four paragraphs, I have to plug Julia. It doesn't have the benefit you point to in your fifth paragraph, of having a decades-old standard; stability of the core language is good so long as you aren't comparing it with C or CL. But it has a full-fledged macro system, the kind where you can write an anaphoric if. It doesn't have the Zen of macros in a Lisp, but it has the power, and that's…

These points scare me: https://gist.github.com/vindarel/15f4021baad4d22d334cb5ce2be... I doubt Julia gives as many image-based tools for the REPL (no conditions and restarts?), no single-file binary? I guess Julia's ecosystem is less rich than CL's outside of science.

It's a young language still. Pre-compilation has brought "time to first plot" down considerably, and ameliorated many (but not all) of the specific complaints in that gist. One stands out, which is "lack of pattern matching", Julia is a language like CL where a language feature can be a library. MLStyle is arguably the best but there are a few[0].

Similarly, there's a start (heh) on a condition and restart system[1]. Julia macros are actually full-strength and that makes up for a lot. I would say that "less mature" is a fair comparison with CL but "less rich" is more of a judgement call. When people are in a mood to be critical of Common Lisp, the richness of the package/system ecosystem is a frequent target of that critique.

Binaries which aren't enormous is a main focus of development now, as I understand the timeline 1.11 will bring modest improvements (in the next few months) and 1.12 will be relentlessly focused on achieving this, it's a recognized problem.

I find Julia completely suitable for general-purpose programming, right now. Moreover I see it on the right trajectory. My hope is that when the trigger is pulled on 2.0, this will include a standardization process, resulting in an actually-stable language by about 2030. Note that Julia is closer to Rust-stable than Python-stable already, post-1.0 code which runs on the latest version (1.10) is more common than not, but I do think compatibility needs to be broken, once, eventually, to fix some bad decisions. It shouldn't have to happen twice.

[0]: https://juliahub.com/ui/Search?q=pattern+matching&type=packa...

[1]: https://news.ycombinator.com/item?id=39377229

Post reply on HN