Live data from Hacker News

The Idea of Lisp

dev.to

71–80 of 348 posts

Re: The Idea of Lisp

#71

I wonder why lisp isn't as popular as say python for AI, ML, and stuff. I see these fields as having a strong academic tone, and it feels like racket or clojure could be bigger when it comes to that.

One factor is that you can't just go to "$language.org" and download the canonical version of the language. There are many different and somewhat incompatible versions of the language for various platforms and multiple decades of books written for the various stages of the evolution of each competing implementation.

Lisp is incredibly malleable and this may have hurt it over the years.

Re: The Idea of Lisp

#72
post #37
post #22

Earlier quoted context omitted.

Because Common Lisp was the language for AI before the big AI-winter hit and it's now associated with approaches to AI that don't actually work. Also a lot of the latest AI is hyper optimized data crunching on GPUs which isn't necessarily one of lisp's strengths.

Well, actually *Lisp was a thing. I think it is also a matter of culture, probably if the likes of AMD and NVidia cared, they could invest some money into making such languages run properly on GPGPUs, instead of leaving it to researchers alone how to target PTX and ROCm. On the other hand something like C++17 would already offer many of the Lisp benefits, even if a bit uglier.

> even if a bit uglier

That was very kind.

Re: The Idea of Lisp

#73
post #48

Earlier quoted context omitted.

Rust also has (almost) everything being an expression - things like this aren't uncommon: let x = if something { foo() } else { bar() } Things which don't have a logical value evaluate to `()` (the empty tuple), I believe.

The if expression is not a persuasive example. C/Java/Algol/etc all have it as well. x = something ? foo() : bar();

The difference is that C/Java/Algol have different syntaxes for things-as-expressions and things-as-statements, and you can't put blocks in the things-as-expressions. In Rust, blocks are also expressions and so have a result (the result of the last expression in the block), so your expressions inside the if can be as complex as you like.

Since functions also have a block, and the return value of the function is the result of the block, this is much more consistent.

Re: The Idea of Lisp

#75
post #48

Earlier quoted context omitted.

The if expression is not a persuasive example. C/Java/Algol/etc all have it as well. x = something ? foo() : bar();

I see two issues with the ternary operator. One, the syntax is much less readable, and two, the consequent and alternate are both single expressions, so you can't do something like: x = if(something) { a = foo(); baz(a); } else { b = bar(); baz(b); }

I've always read ternary statements to myself as a question.

  some_condition ? this : that
some_condition? then this, otherwise that

Typing this, I realize how hard it is to explain without speaking it :)

Re: The Idea of Lisp

#76

Earlier quoted context omitted.

Rust also has (almost) everything being an expression - things like this aren't uncommon: let x = if something { foo() } else { bar() } Things which don't have a logical value evaluate to `()` (the empty tuple), I believe.

> Things which don't have a logical value evaluate to `()` (the empty tuple), I believe. If Rust follows Scala then `()` is not the empty tuple, but rather Unit (void in C*).

It's the same thing. It's a type with only a single value.

Re: The Idea of Lisp

#77
post #16

> This is a proof by construction that the language is computationally complete. The definition of Turing completeness in the article is not correct. A language being able to execute programs written in itself is not a sufficient condition of Turing completenes. Trivial example: define a language with one pre-defined term, x, which is a routine that takes as input a string, checks if it's "x", and executes it if it i…

[deleted]

Re: The Idea of Lisp

#78

Earlier quoted context omitted.

Rust also has (almost) everything being an expression - things like this aren't uncommon: let x = if something { foo() } else { bar() } Things which don't have a logical value evaluate to `()` (the empty tuple), I believe.

> Things which don't have a logical value evaluate to `()` (the empty tuple), I believe. If Rust follows Scala then `()` is not the empty tuple, but rather Unit (void in C*).

void in C can't be created, used, or passed around - () can.

Re: The Idea of Lisp

#79
post #13

Nice article. Check out Paul graham's The Roots of Lisp for a similar exploration in which he shows how to build the metacircular interpreter. > John McCarthy wrote 6 easy things in machine code It was actually Steve Russel, McCarthy's grad student, who had the idea of writing McCarthy's eval function in machine code.

> It was actually Steve Russel

I seem to recall reading that McCarthy was actually surprised to discover that Lisp _could_ be run by a real computer; he intended it to be a completely theoretical tool.

Re: The Idea of Lisp

#80
post #25
post #2

The conditional expression or more specifically everything being an expression is my favorite thing about Lisp. I did not know that McCarthy pushed to add it to Algol which apparently today is the ternary operator for most languages. It is annoying that so many languages (C, Java, C#, etc) have both a conditional statement (if-else) and conditional expression (ternary ?:). Really the if-else should be an expression (…

If you like everything being an expression, check out tcl. A lot of ideas from lisp show up in tcl, especially the idea of everything as an expression. Tcl embodies this idea while also having the look of an algol-like language. Funny it can pull this off while having basically no syntax.

Correct me if I'm wrong but doesn't Ruby have everything (maybe just most?) things be an expression. I always liked

    x = if condition
          something
        else
          something_else
        end
Post reply on HN