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

Why Lisp?

nyxt.atlas.engineer

Post reply on HN
Print view View original

331–339 of 339 posts

Re: Why Lisp?

#331

Post by foldr »

medo-bear wrote: post #329
foldr wrote: post #313

Earlier quoted context omitted.

That's all pie in the sky isn't it? I was talking about CL. The only practical suggestion I can take from this is that one could drop down to inline assembly in some CL implementations. It's unclear to me how that would help with the problem of defining unboxed arrays of structs.

I am not sure what you mean. If I want to use unboxed array of structs I can easily do so via FFI and create some sort of DSL for working with them. If this sounds like too much work for you, then yes we are at an impase. I think CL is great in this way in that writing FFIs is pretty natural. Also if you need performance code, why would you be worried too much about portability accross implementations. Maybe I am mis…

>If this sounds like too much work for you, then yes we are at an impase

It's not necessarily too much work (that depends on the context), but it is more work.

I am not sure why there is so much reluctance to acknowledge this one particular disadvantage of Common Lisp as compared to e.g. C++, Rust, etc. Common Lisp is not a perfect programming language. It does not need to be reflexively defended against all potential criticisms.

Please note that none of my posts says "Common Lisp sucks", or "you should use Language X instead of Common Lisp", or "the lack of proper support for unboxed arrays outweighs all the potential advantages of Common Lisp in all circumstances".

Not sure why you bring up Haskell, but yes, the same criticism applies to Haskell as well. The difference is really just a cultural one: even the most fanatical Haskell advocates would probably acknowledge that it's not a great language to use if you need fine control over memory layout.

Re: Why Lisp?

#332

Post by ducktective »

foldr wrote: post #331
medo-bear wrote: post #329

Earlier quoted context omitted.

I am not sure what you mean. If I want to use unboxed array of structs I can easily do so via FFI and create some sort of DSL for working with them. If this sounds like too much work for you, then yes we are at an impase. I think CL is great in this way in that writing FFIs is pretty natural. Also if you need performance code, why would you be worried too much about portability accross implementations. Maybe I am mis…

>If this sounds like too much work for you, then yes we are at an impase It's not necessarily too much work (that depends on the context), but it is more work. I am not sure why there is so much reluctance to acknowledge this one particular disadvantage of Common Lisp as compared to e.g. C++, Rust, etc. Common Lisp is not a perfect programming language. It does not need to be reflexively defended against all potentia…

So, basically, does this rule out Common Lisp for performance critical applications like numerical computation and ML?

Re: Why Lisp?

#333

Post by foldr »

ducktective wrote: post #332
foldr wrote: post #331

Earlier quoted context omitted.

>If this sounds like too much work for you, then yes we are at an impase It's not necessarily too much work (that depends on the context), but it is more work. I am not sure why there is so much reluctance to acknowledge this one particular disadvantage of Common Lisp as compared to e.g. C++, Rust, etc. Common Lisp is not a perfect programming language. It does not need to be reflexively defended against all potentia…

So, basically, does this rule out Common Lisp for performance critical applications like numerical computation and ML?

I wouldn't go that far, personally. It's convenient to be able to have unboxed arrays of arbitrary non-primitive datatypes, but you can work around it.

Re: Why Lisp?

#334

Post by jhgb »

foldr wrote: post #220
pjmlp wrote: post #209

Earlier quoted context omitted.

That isn't what Bjarne means by zero cost abstractions. It means the abstractions produce the same code as having written the same manually without the abstraction, e.g. having a class with virtual methods versus having a struct with function pointers as fields.

I interpret the term compostitonally. But CL doesn’t have zero cost abstractions in that sense either. Take the example I mentioned. Say that you’re looping through an array of pairs of 2D vectors and calculating the dot product of each pair. In C++ you can use your 2D vector class without any additional cost. In CL you either need to remove that abstraction (and deal with flat arrays of scalars) or incur the cost of…

> Say that you’re looping through an array of pairs of 2D vectors and calculating the dot product of each pair. In C++ you can use your 2D vector class without any additional cost. In CL you either need to remove that abstraction (and deal with flat arrays of scalars) or incur the cost of boxing.

Or maybe use compiler macros to remove the abstraction without the cost of boxing?

Re: Why Lisp?

#335

Post by medo-bear »

foldr wrote: post #331
medo-bear wrote: post #329

Earlier quoted context omitted.

I am not sure what you mean. If I want to use unboxed array of structs I can easily do so via FFI and create some sort of DSL for working with them. If this sounds like too much work for you, then yes we are at an impase. I think CL is great in this way in that writing FFIs is pretty natural. Also if you need performance code, why would you be worried too much about portability accross implementations. Maybe I am mis…

>If this sounds like too much work for you, then yes we are at an impase It's not necessarily too much work (that depends on the context), but it is more work. I am not sure why there is so much reluctance to acknowledge this one particular disadvantage of Common Lisp as compared to e.g. C++, Rust, etc. Common Lisp is not a perfect programming language. It does not need to be reflexively defended against all potentia…

i was more confused about the point you are making. more as an educational piece for myself in the sense maybe there is something im missing in my knowledge. you seem to know what you are talking about. that said, as far as i am concerned, you made your point clear in this reply. common lisp is primarily a high level language, albeit one with really good low level capabilities. however for tasks that require fine grained stack memory control, or even abstractions over that, it would be hard to see how it could compete with c family. i think this is perfectly fine

i brought up haskell as an example of a high level language that does unboxing of arrays, but also because your handle[0] suggested to me that you know quite a bit about haskell and will be able to inform me accordingly :)

for what its worth i personally think that it is a very good thing for a programmer to have thorough knowledge of both high and low level languages, and a great thing if they are able to combine it. for me lisp fits the latter porpose, but thats not important for everyone, and people are definitely free to dislike lisp

thanks for your reply

[0] https://zvon.org/other/haskell/Outputprelude/foldr_f.html

Re: Why Lisp?

#336

Post by medo-bear »

ducktective wrote: post #332
foldr wrote: post #331

Earlier quoted context omitted.

>If this sounds like too much work for you, then yes we are at an impase It's not necessarily too much work (that depends on the context), but it is more work. I am not sure why there is so much reluctance to acknowledge this one particular disadvantage of Common Lisp as compared to e.g. C++, Rust, etc. Common Lisp is not a perfect programming language. It does not need to be reflexively defended against all potentia…

So, basically, does this rule out Common Lisp for performance critical applications like numerical computation and ML?

given that i use common lisp for numerical computations including ml, i hope not :) given just that python reigns supreme in this field, clear answer is no. however it is worth keeping in mimd that common lisp is a high level language with very good low level features. you can for example use c data structures seamlessly if you need fine grained memory control you, or write inline assembly

Re: Why Lisp?

#337

Post by erichocean »

fulafel wrote: post #323
ravi-delia wrote: post #322

Earlier quoted context omitted.

I mean depending on what you mean by "have", yes? But also that's been true since the 90s. Out of the box, less so. Clojure has destructuring assignment, but no matching. A lot of little lisps downstream of Clojure (Janet, Fennel I think) do have matching, though not for function calls. I think that destructuring is most of the value add of pattern matching for me- that's not to say matching isn't great, just that de…

I think Clojure has benefited from matching being kept out of the built-in stdlib. https://github.com/clojure/core.match is a plug-in and as a result we've had lots of cool data traversal/matching DSLs come around and evolved user communities with time such as Meander and Datascript not to mention the parsing applications of the schema systems (spec & malli).

Meander and Specter make Clojure a lot nicer to use day-to-day.

Re: Why Lisp?

#338

Post by rgherdt »

eviks wrote: post #235

> The Lisp designers do not assume what syntax, features or functions will be necessary in the future. The developers of Lisp give you the full powers that they had to develop the language. Isn't that ~ abdicating responsibility for language design?

May I quote the first sentences from Scheme's R7RS standard that relates to this topic:

"Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. Scheme demonstrates that a very small number of rules for forming expressions, with no restrictions on how they are composed, suffice to form a practical and efficient programming language that is flexible enough to support most of the major programming paradigms in use today."

Re: Why Lisp?

#339

Post by jhgb »

xmcqdpt2 wrote: post #158
Paul-Craft wrote: post #154

Here's a question the article doesn't answer: why Common Lisp? I.e. why not Scheme? Scheme is a plenty powerful language these days with all the libraries it has available. Granted, it doesn't have history going back to the 1950s, but it does date back to the 1970s. There are also multiple implementations, each with its own set of strengths. And there are some solid standards written for the language that have good i…

I recently decided to try a scheme and did not find any that had supported Windows as a first class platform, so that's one limitation. By comparison SBCL just runs on Windows without any difficulties.

I believe that Chez should support Windows very well, even to the extent of supporting COM calls.
Post reply on HN