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

The Lisp Curse (2017)

winestockwebdesign.com

Post reply on HN
Print view View original

81–90 of 93 posts

Re: The Lisp Curse (2017)

#81

Post by lisper »

gnulinux wrote: post #79
lisper wrote: post #62

Earlier quoted context omitted.

Turing completeness may be a flaw, but it is nearly impossible to avoid.

Not true at all. It is hard, but not impossible. Technologically it's very challenging because we don't have non-TC programming languages that are able to keep up with modern ones. But, for example, we have (safe) Agda which is not TC (all programs marked --safe should prove to halt) and you can write useful programs. Here, "useful" is a subjective qualifier, but I personally implemented many parsers in Agda (includi…

I didn't say it was impossible. I said it was nearly impossible, which is a synonym for "hard" for some value of hard.

Case in point: I looked into Agda and ended up in a deep rabbit hole that involved something I had never heard of called "Walther recursion." Whether this qualifies as "nearly impossible" or merely "hard" is quibbling over terminology, not substance.

Re: The Lisp Curse (2017)

#82

Post by lisper »

xscott wrote: post #78
lisper wrote: post #76

Earlier quoted context omitted.

I was responding to this: > If you're willing to use a garbage collection library [0], you can even have a pleasant syntax for ObjectiveC style OOP in C: That sounded to me as if you were claiming that GC is a pre-requisite for having a particular syntax . But I gather that's not what you meant. I'm still a little unclear about what you actually meant. You can have memory leaks like the one in your example above in v…

Yeah, I got your point. I don't think we're in disagreement about anything, and I probably shouldn't have conflated multiple topics. It's not really _syntax_, but this would be uglier to me: var temp = alloc("Circle radius: %d color: %u", r, 0xFF0000); var ignored = call(window, "draw: %d %d %p", x, y, temp); drop(ignored); drop(temp); What's a good word for the overall/high level result being less attractive while t…

I don't know of a word for it. It's just a fact: GC simplifies code because it liberates the programmer from having to figure out when memory can be safely reused and transfers that responsibility to the runtime. It has next to nothing to do with any other aspect of language design, except insofar as if you have GC then your language can get by without any mechanism to allow the programmer to free allocated memory. This observation has some pretty significant practical impact, but you can't say much more about it than that.

Re: The Lisp Curse (2017)

#83

Post by zelphirkalt »

hajile wrote: post #18
_hcuq wrote: post #7

If Lisp is do efficient for development, why are there essentially no commercial products that use it?

StandardML vs go is a great illustration. StandardML is just as fast, is more simple to learn with more simple syntax and basically zero gotchas, has more powerful syntax, has an actually sound type system (which has better generics than the ones proposed in go), does a better job at defining public functionality (via modules), has a better CST model, and many other great features. The only area where it loses is sta…

I am learning SML currently (with the book "Elements of ML Programming" by Jeffrey D. Ullman) and I have to say it is quite elegant. I like the pattern matching for functions. Often it is surprising how much shorter functions become, when you pattern match in the signature of the function. Makes me think, that maybe I should think about using pattern matching more in Scheme as well. And that I don't want to miss it in any new language I learn. Of course also the type safety is great. I could imagine writing critical parts of a system using SML.

Re: The Lisp Curse (2017)

#84

Post by davidgrenier »

tharne wrote: post #14
davidgrenier wrote: post #10

I just wish more people understood that something being Turing Complete isn't a feature, it's a flaw.

How so?

Also, Turing Completeness is almost always accidental while non-TC is obtained by design. Hence, just about anything has Turing Completness which doesn't make it a feature.

Now if you want to gain the ability to make serious proofs about your programs, one can make the argument you need non-TC.

Re: The Lisp Curse (2017)

#85

Post by JonChesterfield »

lisper wrote: post #81
gnulinux wrote: post #79

Earlier quoted context omitted.

Not true at all. It is hard, but not impossible. Technologically it's very challenging because we don't have non-TC programming languages that are able to keep up with modern ones. But, for example, we have (safe) Agda which is not TC (all programs marked --safe should prove to halt) and you can write useful programs. Here, "useful" is a subjective qualifier, but I personally implemented many parsers in Agda (includi…

I didn't say it was impossible. I said it was nearly impossible, which is a synonym for "hard" for some value of hard. Case in point: I looked into Agda and ended up in a deep rabbit hole that involved something I had never heard of called "Walther recursion." Whether this qualifies as "nearly impossible" or merely "hard" is quibbling over terminology, not substance.

Corresponding paper is probably http://people.csail.mit.edu/kostas/papers/CADE1996.pdf. Thanks for the name drop, looks great

Re: The Lisp Curse (2017)

#86

Post by paperclipp »

eimrine wrote: post #44
tharne wrote: post #13

Earlier quoted context omitted.

> The answer is always that popularity doesn't correlate with merit. Exactly. If we used popularity and usage rates as the measure of merit, we'd have to conclude that the highest quality restaurant in the world is MacDonald's.

> the highest quality restaurant in the world is MacDonald's. Isn't it so? The meal is enough healthy (for hard-workers only, not for calories-gathers), calorage as I have mentioned is excellent, waiting is minimum, non-meal payings (keeping the restaurant attractive) are the lowest possible, the most important thing is that in poor countries (my is in the bottom of bigmac index) the prices are lower than anything el…

>The meal is enough healthy Have you been sleeping under a rock for the last 20 years ? McDo food has never been healthy. The nutrient content is poor, potatoes are cultivated with nasty insecticides, shit in the meat, etc, etc

Re: The Lisp Curse (2017)

#87

Post by paperclipp »

lispm wrote: post #63
a4isms wrote: post #39

Earlier quoted context omitted.

> If Lisp is [so] efficient for development, why are there essentially no commercial products that use it? I’m sorry you’ve been downvoted for asking this question, even if it was a rhetorical question. It’s easily the most important question to ask in the professional programming area, and it’s worth the effort to truly grok the answers rather than look up what everyone seems to say and then repeat it as gospel. It…

Lisp was the main language of Symbolic AI. That market largely crashed in the 80s/90s. Planners&scheduling in the military&logistics (airlines, airports, train operators, satellites, ...), expert systems for maintenance, computational engineering systems (for example for airplanes from Airbus and Boeing), theorem provers (used in chip design), symbolic mathematics, natural language systems (text translation for the E…

I always associated all the use cases with Prolog ...

Re: The Lisp Curse (2017)

#88

Post by speed_spread »

jhgb wrote: post #70
speed_spread wrote: post #35

Earlier quoted context omitted.

Let's see: - Insists on every expression being (wrapped (in parenthesis)) - Uses polish prefix notation - Profound belief that recursion is more intuitive than loops - Macros everywhere, because code is data, so why not? - Whole language built from a very small set of axioms - REPL-based workflow QED Clojure is _a_ Lisp. (FWIW I'm learning Racket right now)

Lisp: "List processing". Clojure doesn't even have cons cells... A Lisp without cons cells is like a C derivative without pointers...is it really C at that point? I'd also question the "profound belief that recursion is more intuitive than loops" since Lisp supports loops extremely well -- better than most languages, since you can build up your own iterative constructs using tagbody. And Clojure doesn't even have pro…

Clojure doesn't have tail calls because they should be implemented at the JVM level to be effective, a feature which has been on the back burner for ever because no other languages would use them.

Re: The Lisp Curse (2017)

#89

Post by gnulinux »

lisper wrote: post #81
gnulinux wrote: post #79

Earlier quoted context omitted.

Not true at all. It is hard, but not impossible. Technologically it's very challenging because we don't have non-TC programming languages that are able to keep up with modern ones. But, for example, we have (safe) Agda which is not TC (all programs marked --safe should prove to halt) and you can write useful programs. Here, "useful" is a subjective qualifier, but I personally implemented many parsers in Agda (includi…

I didn't say it was impossible. I said it was nearly impossible, which is a synonym for "hard" for some value of hard. Case in point: I looked into Agda and ended up in a deep rabbit hole that involved something I had never heard of called "Walther recursion." Whether this qualifies as "nearly impossible" or merely "hard" is quibbling over terminology, not substance.

I've been writing programs in Agda for years (since when they didn't have sized types or cubical theory) but I never heard "Walther recursion" before. If this is your day 0 I doubt you need to know about it to understand the language.

Re: The Lisp Curse (2017)

#90

Post by lispm »

nerdponx wrote: post #25
throwaway599281 wrote: post #23

Earlier quoted context omitted.

>Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. [0] Neither the Clojure page, nor its users seem to agree with you. [0] https://clojure.org/

It's not Lisp-as-in-Common-Lisp. It's closer to Scheme than to CL. But it's "a Lisp" in the colloquial sense that it uses s-expression syntax and has macros.

Not s-expressions in the traditional Lisp definition of singly linked lists. In Lisp (a . b) is a cons cell with two symbols a and b. In Clojure it is some complex data structure with three elements a, ., and b.
Post reply on HN