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

171–180 of 339 posts

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

#171

Post by HexDecOctBin »

brlewis wrote: post #125
IshKebab wrote: post #21

Earlier quoted context omitted.

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?

> 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 }.

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

#172

Post by dreamcompiler »

kazinator wrote: post #130

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…

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

This times 100. There are only a few places where the ANSI standard got it very wrong, but this is one of them. Logical pathnames were intended to abstract away different file naming conventions but what they actually did was cast in stone some anachronisms that are incompatible with modern Unix file naming (e.g. case-sensitive path names. Whoops! Can't handle that.)

The good news is that you can just ignore logical pathnames and use normal native pathnames, or use the illogical-pathnames package which largely fixes the problem.

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

#173

Post by yazzku »

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)

In Haskell:

let xs = [x*x | x You can decide later how many you actually want.

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

#174

Post by dreamcompiler »

lcall wrote: post #37

Somebody famous said something like "Lisp makes hard things easy, and easy things hard", which finally, after all these years, clarified it for me. (It was quoted on HN in a previous discussion, and I was impressed with the credentials of the person quoted, but I don't have the reference handy.)

I've written a great deal of Common Lisp and the only "easy things hard" I've encountered are fast matrix multiplications -- because there are many ways to do this and they each have different tradeoffs, and implementing symmetric crypto algorithms that assume 32-bit word sizes. Because Lisp integers automatically grow when necessary, forcing arithmetic to stay within a 32-but limit is hard do do in pure Common Lisp efficiently. The solution is to write bottleneck routines in assembly, which the Lisp compiler I use (CCL) facilitates.

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

#175

Post by dreamcompiler »

booleandilemma wrote: post #45

For me it's the parentheses. I'm sorry, I know it sounds childish, but it's true. Just look at this picture: https://www.semanticscholar.org/paper/The-programming-langua... We call that "line noise".

That's code from 1966. It resembles modern Common Lisp the same way "Beowulf" resembles "The Three-Body Problem."

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

#176

Post by quantified »

agumonkey wrote: post #18
thot_experiment wrote: post #14

Because most programming is done by people trying to do a job and it requires broad tooling support and familiarity, LISP is a language that has neither. LISP, (similarly to Haskell) requires you to bend your mind and pay an upfront mental cost in order to access it's benefits, which are that everything is equally easy to describe. No construct in LISP feels like it requires you to bend the language in an awful way b…

the upfront mental cost debate is still going, a few people tried teachings lisps as first languages and people didn't struggle i personally cried a few tears when learning java, whereas the weird drscheme class made me all calm and happy programming also blends a few layers into one, and some people are operating at one (line by line modification of data), some want generic infinite freedom[0], you can rapidly see w…

Logo was a great teaching language. If you're not already patterned into C-style programming, it is a great experience.

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

#177

Post by esafak »

pierrebai wrote: post #69
LeoPanthera wrote: post #53

Earlier quoted context omitted.

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)

Of course, Python would have been way more awesome if they did not reject the much more reader-friendly and idiomatic: squared_div_by_3 = [ for i in range(10): if i % 3 == 0: i**2 ] That is, just transforming the normal for loop and if into a list comprehension by surrounding it with brackets. It would even preserve the friendly forced blocking and indentation. Can you imagine?

It's inspired by set-builder notation: https://en.wikipedia.org/wiki/Set-builder_notation

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

#178

Post by gumby »

svachalek wrote: post #85
gumby wrote: post #75

Earlier quoted context omitted.

It's exactly how you would do the calculation if you ran it by hand, unlike the regular algebraic notation. I am flabbergasted that anyone uses the latter, especially as for most of the history of mathematics calculation was done by hand!

I don't "run" x 2 ^ by hand and I don't think anyone does. Some people find different notations more intuitive and that's fine but whether it's prefix postfix or infix, it's still an abstraction.

> I don't "run" x 2 ^ by hand and I don't think anyone does

Of course everyone evaluates expressions symbolically: in code review, when debugging, even when looking over an expression just after typing it to make sure it’s right.

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

#179

Post by thaumasiotes »

tonyarkles wrote: post #108
jjav wrote: 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.…

I went through EE using an HP 49G+ and continue to this day using RPN in Emacs calc-mode. >> I find it nearly impossible to parse this without actually maintaining the stack in my mind. > You compute the problem going from smaller units to larger units getting intermediate results as you go and combining them That's totally it. I've tried doing infix/standard algebraic notation on a calculator and unless the screen i…

> Ohhh... that's Forth. And you don't need brackets at all...

You still need them if you want variadic functions. Symmetrically, you don't need parentheses in lisp if you don't want variadic functions, as long as you're willing to draw an explicit distinction between calling a function and referring to it.

You might as well just make that distinction by using the parentheses, though.

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

#180

Post by breather »

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'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 files.
Post reply on HN