Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is Common Lisp not the most popular programming language?

daninus14.github.io

Post reply on HN
Print view View original

121–130 of 339 posts

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

#121

Post by brlewis »

jjav wrote: post #107
samatman wrote: 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 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…

In companies, most languages have some kind of system to enforce style guidelines and restrict which dependencies can be used. Companies already restrict the flexibility of the languages they are already using. So flexibility is not the reason Lisp is unpopular among companies.

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

#122

Post by thaumasiotes »

LeoPanthera wrote: post #53
Karellen wrote: post #42

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 love Python's list comprehensions. When I first discovered them I had a kind of "mind blown" moment. They look like this, for anyone who doesn't know: squared_div_by_3 = [i**2 for i in range(10) if i % 3 == 0] Without using a list comprehension, this is equivalent to: squared_div_by_3 = [] for i in range(10): if i % 3 == 0: squared_div_by_3.append(i**2)

There seems to have been a design emphasis in C# on providing something similar under the name LINQ. It would look like this:

    var squared_div_by_3 = from i in Enumerable.Range(0,10) where i % 3 == 0 select i*i;
or alternatively:

    var squared_div_by_3 = Enumerable.Range(0,10).Where(i => i % 3 == 0).Select(i => i*i);
In that second syntax, `Where` is exactly equivalent to Python's `filter` (or lisp's `remove-if-not`) and `Select` is of course equivalent to `map`; I assume the odd choice of names for C# is meant to appear similar to SQL.

They're introducing Range objects with syntactic sugar so you can say `0..10` instead of `Enumerable.Range(0,10)`, and you'd think there would be LINQ implementations for those objects, but there aren't.

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

#123

Post by samatman »

m463 wrote: post #105
Karellen wrote: post #42

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…

> is there a lisp dialect that makes common data structures available in a multitude of ways?

Clojure. The language is built around immutable data structures with the expected interface for maps and vectors, and the idiomatic list-churning we're both referring to is unified through the sequence abstraction. So switching from a vector to a map can often be as simple as switching constructors. Because they're immutable, every operation makes a "copy" but does so efficiently.

I don't have a lot of use for Clojure these days but I enjoyed working with it. Rich Hickey is a smart fella.

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

#124

Post by richie_adler »

jjav wrote: post #116
shrimp_emoji wrote: post #113

Earlier quoted context omitted.

> Simple, not very flexible, everyone does it the same way mostly, you can plug & play developers like scrum demands we do. I think that's why Python beat Ruby. :p

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?

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

#125

Post by brlewis »

IshKebab wrote: post #21
samatman wrote: 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 disagree. I have no problem with lists obsession in other languages like OCaml. The parentheses are just too much. I get how elegant and unambiguous they are for computers but I am not a computer. It's like RPN. It's elegant and easy for code to parse and unambiguous and all these nice things.... except it isn't easy for me to parse. Compilers are perfectly capable of compiling readable code like Rust so I don't se…

With Rust do you close all your } manually? Do you have an example of Rust code where the equivalent Lisp code would be harder to parse, assuming equal familiarity with both languages?

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

#127

Post by munchler »

erik_seaberg wrote: post #118
munchler wrote: post #94

Earlier quoted context omitted.

I'm not saying Python is always crappy. It's just easier to create crappy code in Python, due to dynamic typing, rampant side effects, null values, OO madness, etc. If your team has the discipline not to do that, great.

> dynamic typing, rampant side effects, null values I’m afraid these are also problems in Common Lisp.

Yeah, I’m not a Lisp fan myself. I was comparing Python to functional languages, like Haskell or F#.

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

#128

Post by skybrian »

valty wrote: post #91
samatman wrote: 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 ),…

It's funny that behind the scenes in all languages, everything is lists (in the AST). It's strange that we tend to initially code in easily readable built-in control structures (if, switch, for, while), but then there always comes a point when you need to refactor...and convert them into lists of data structures and process those. For example, if you are matching routes in a web server, you can write a bunch of if-st…

It's not true that everything is a list in most languages. Typically an AST is built with both lists and structs. Special forms are always going to exist and the code needs to deal with them, so this isn't a loss; it's being more explicit. Well-named fields are better documentation and faster than accessing the nth item than a linked list. (You can emulate named fields using just lists, but it's just a convention.)

Also, in most languages, the lists aren't linked lists. They're typically array-backed.

JSON has both lists and objects (which serve as structs) and it's quite popular and usable for representing AST's.

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

#129

Post by richie_adler »

Karellen wrote: post #42
samatman wrote: 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 ),…

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

> And strings are lists

Eh, not really. Lists are mutable, strings are not.

Strings are iterable and sliceable, which makes them usable in many similar ways to lists, but they're not lists.

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

#130

Post by kazinator »

Popularity is a matter of luck. But suppose that the forces that drive luck somehow aligned themselves with promoting Lisp. There are ways Lisp would sabotage the luck being radiated upon it.

Programmers who get into CL will hit various silly obstacles:

- No standard way to express special characters in string literals.

- No standard Unicode support; no \u1234 notation in the standard. I/O with character encodings is implementation-specific.

- Weird pathname handling that is simultaneously too abstract, and too nonportable, which is oxymoronic. The pathname abstraction caters to features of operating systems that basically no longer exist. Yet at the same time, two CL implementations on the same modern OS (POSIX or Windows) cannot agree on all the details regarding how a pathname string (the real artifact seen by the OS) parses to a pathname object!

- The experience of just firing up a free CL implementation (no Emacs) out of the box and experimenting in its REPL is poor. CLISP has built in history recall and editing; I would recommend that.

- Ironically poor REPL experience in the free implementations, given that Lisp gave us that word. Only CLISP has built in editing and history recall out of the box. Telling newbies they have to learn a specific editor and its Lisp integration is poor and adds to the activation energy.

- Working with objects can be verbose with syntax like (slot-value point 'x) which is just point.x in many other languages. This can be shortened by defining accessors, but accessors abstract a lot. Given (x point) you no longer know that it's just a simple slot. It's a function call, which could be anything. Another thing is, would you give an accessor a one letter name like x, even if it's in a package?

- Newcomers to Lisp do have to learn the list processing. People coming from languages in which lists are collection bags get confused why their list x is not changing after (append x '(1 2)). If you don't use the loop macro and want to collect items into a list, you have to learn the ritual of push-ing items into a stack, and then using nreverse at the end. Guy Steele described a nice procedural list construction API in Common Lisp, The Language, second edition, but it's not in the standard.

- Working with multiple values is verbose, with forms like (multiple-value-bind (quotient reminder) (truncate 1 2) ...), and multiple-value-setq, and whatnot. Some pattern matching or binding libraries help with that.

Post reply on HN