Live data from Hacker News

Why is Common Lisp not the most popular programming language?

daninus14.github.io

321–330 of 339 posts

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

#321
post #105

Earlier quoted context omitted.

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…

I don’t think you know Common Lisp very well, or are talking about some super limited Lisp dialect I’ve never heard of.

99% emacs lisp

hmm... maybe I need to look at the packages that use common lisp.

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

#322

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?

Many companies are risk-averse and prefer predictability to performance. They therefore often choose slow and outdated software products instead of newer, more efficient ones and they prefer using tools that require large amounts of developers, but in a predictable fashion. Using a tool that allows a very small team to perform the job of 10x as many is risky because the bus factor becomes that much higher, as well as the difficulty in finding and training replacements.

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

#323
post #116

Earlier quoted context omitted.

Agreed. And why I love Ruby and hate Python. But yes.

Ruby is "perl-esque" in syntax, and of course TIMTOWTDI is opposite to the 13th item of the Zen of Python, so it's understandable some dislike to an express design decision. But hate ? Really?

> But hate? Really?

Coding with Python makes me feel like I'm hand-washing dishes that have been dirtied and left in the sink for several days.

I know that many like Python, and I'm not arguing against that in any way. Whatever floats your boat, mang.

However, trying to tell me why I "ought to like" Python is like telling me why I "ought to like" cilantro. I know you think it's delicious. To me it smells like squashed bugs, and tastes like dish soap.

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

#324
post #286

Earlier quoted context omitted.

;; clojure (defn sum-and-square [a b] (let [sum (+ a b)] (* sum sum))) Honestly, I'm not sure what you're trying to show.

I'm not sure what you are trying to show? Code can be in one line? Okaaaaay... I was trying to show that one can define local variables without adding another list level via let. Like if one would/could write in Clojure: (defn sum-and-square [a b &blah sum (+ a b)] (* sum sum)) Another Common Lisp example, we'll stick to your one liner format, using infix syntax via a reader macro: (defun sum-and-square (a b) #I(sum=…

Reader macros are global and stateful, this is one of the worst things about Common Lisp. Excellent feature, pity we're forever burdened with the implementation.

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

#325
post #276

Earlier quoted context omitted.

> 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…

Lisp's primordial sin is the fact that it is FP. US cooperations never supported FP (see Microsoft and F#). FP is largely a European phenomenon.

Lisp is non-opinionated and supports FP, OOP, AOP, in whatever mix you want.

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

#326
post #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 Stor…

I don't agree with this counterfactual, much as I love Scheme among languages I've barely used in my career.

Chez Scheme was fast but would not fit in the browser especially on Windows 3.1, which still had the largest share when I started JS in 1995, if memory serves -- it was certainly important to Netscape because Microsoft started bundling IE into later Windows versions, as default browser in Windows 98. Petit Chez Scheme was not fast, and I'm not sure I would have had time to use it in those ten days (I never looked at the code).

Guile was out because of the GPL, not my choice (same as with Make It Look Like Java order) and probably no time to embed, or just no way with 64K segments.

If you know of another fast-in-1995 Scheme that might have fit, links welcome.

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

#327
post #320
post #107

Earlier quoted context omitted.

I didn't see mentioned in the thread (maybe missed it) the #1 reason, IMO, that Lisp can't be popular in companies. Everyone should take the time to learn Lisp and do a handful of personal projects with it. It'll help your growth as a software engineer. Just do it! But that doesn't make it a great corporate language. Lips is infinitely flexible, you can mutate it to be what you want. That's cool and feels awesome. Al…

> The anti-Lisp is something like Go. Simple, not very flexible, everyone does it the same way mostly, you can plug & play developers like scrum demands we do. This has not been my experience with Go. The only areas where Go actually enforces consistency is that gofmt has no configuration surface, and Go Modules conclusively won the dependency management war. Other than that, it's still a lawless wasteland. Foreword:…

> Go gets far more credit here than it deserves.

When I said it is kind of the anti-Lisp, I wasn't thinking of it as credit...

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

#328
post #295

Earlier quoted context omitted.

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 Stor…

I don't agree with this counterfactual, much as I love Scheme among languages I've barely used in my career. Chez Scheme was fast but would not fit in the browser especially on Windows 3.1, which still had the largest share when I started JS in 1995, if memory serves -- it was certainly important to Netscape because Microsoft started bundling IE into later Windows versions, as default browser in Windows 98. Petit Che…

I guess I'll start by saying that JS is my absolute favorite among all the top languages out there (StandardML, Rust, Scheme, and CL probably being the others in my top 5). Thanks for making it!

Of course, everything said is hypothetical as we can't actually wind back the clock.

You could have rolled your own Scheme instead of adopting a then-fast implementation. The Scheme would certainly have been faster from the very start if for no other reasons than integers are faster than floats and real arrays are faster than hashtables.

Scheme would likely have been a bit faster from the start, but the real question would be the trajectory from there. JS needs inline caches and hidden classes to be fast. I don't see how all that could have possibly run on typical systems of the 90s. In contrast, there's a lot of Scheme optimizations that would work perfectly well on those machines before resorting to the really heavyweight stuff.

Considering that JS with many millions in investment is generally slower in typical code than something like Gambit or Chez (both of which have very little financial backing) leaves me assuming that the Scheme trajectory would always be better.

This just leaves the hypotheticals of Scheme's other effects.

Anyone who's used basically any lisp for web work would understand why HTML would become effectively subsumed. S-expressions make dynamic manipulation of the raw trees very easy as that's what a lisp is designed to do. React revolutionized frontend development in 2013, but a huge part of what people like most about it would have been obvious to web developers years earlier.

XML may well have never happened either. While JSON was apparently only obvious in hindsight, the idea of sending S-exp over the wire then parsing out the data is very in-your-face with lisps.

CSS is a much more simple matter. One of the major syntax proposals used S-expressions and their easy integration into Scheme would have all but guaranteed their adoption.

WASM likely wouldn't be needed because as has been shown with Common Lisp, you can already get very low level with just lisp (and even lower if you allow stuff to optionally handle its own memory). Asm.js got really complicated to the point that WASM made more sense, but with performance already being very good, it becomes a lot less necessary (even without those lower-level changes).

Flash was a bit hyperbolic. It would probably still have existed for a variety of reasons, but probably wouldn't have become a separate language and ironically would probably still exist today as a development layer over the browser's features.

Steve Jobs was very open that he didn't want an app store, but instead wanted web applications. There was an issue with the browser's capabilities, but the biggest issue was that JS engines were still just too slow in the late 2000s (part of what killed off the very amazing webOS). Scheme would likely have been quite fast by that point making the web app argument much more appealing and possibly saving the world from fractured ecosystems.

Of course, there's the counter-argument that the world would never accept a scheme and it would have either been replaced or moved everyone into the nightmare of Java applets. There are certainly a lot of alternative universes where the world would be far worse if we'd wound up with Scheme rather than Javascript.

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

#329
post #302

Earlier quoted context omitted.

Try it. Point someone at trying to learn programming at sbcl. What percentage do you think have any clue what you just wrote let alone run a debian based distro or even know what that is? Compare that experience to choosing python. Forget the actual language just all the overhead. It's not a close run thing no matter how angry common lispers get about it. This is my exact experience of common lisp. People aggressivel…

I don't understand, is installing and running python easier than running an install command?

Oh come on. You mean installing with apt on debian based linux? Ok so compared to not having to do that. Both easy once you're proficient at debian, one easier.

Now do mac.

Now do windows.

Installation is only step /one/ in smashing out your first ten exercises.

Pretending something is easy because you want it to be does not make it so for others.

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

#330
post #7

It's the lists. No, not the prefix notation, parenthesis, what have you, although that doesn't help. The lists themselves. In Lisp, code is data, and data is lists. Yes, of course, there are hashmaps, arrays, strings. But idiomatic Lisp code really does use linked lists extensively, it's an entire style of programming. Even if you'd prefer to use different data structures (and again, Common Lisp does support this ),…

I'm tackling a significant lisp project right now, and the thing that holds me up right now is that the code is difficult to organize. Python, java, rust, go etc have well-defined patterns to figure out where code lives and where you might expect certain behaviors to occur. With lisp you can really shoot yourself in the foot very easily by using abstractions that are difficult to follow and are spread out across many…

Lately, I've been creating protocols that are meant to be the interface for some kind of entity, such as "user", "utility", "configuration", "auth", and so on. The logistics of that are to use defgeneric for the protocol interface, defmethod in the same package, but can be over-ridden with a more specific defmethod in another package if necessary. I still export regular functions too, but I look to the defgenerics as the main entry points for a particular package. To (sort of) enforce some separation, I try to keep these packages self-contained in their own system (defsystem).

I mean, it's one approach, but my advice would be to take some time to come up with what would work for your appication and CL is flexible enough it can probably support it.

Post reply on HN