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

The Idea of Lisp

dev.to

Post reply on HN
Print view View original

151–160 of 348 posts

Re: The Idea of Lisp

#151

Post by pg314 »

mroll wrote: post #25
agentgt wrote: 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.

Tcl does have a lispy feel to it, but s-expressions in Lisp are much more elegant than strings in Tcl, imho. Greenspun called Tcl the Lisp without a brain[1], which can be taken both as a compliment or an insult.

[1] http://philip.greenspun.com/tcl/introduction.adp

Re: The Idea of Lisp

#152

Post by kazinator »

coderzach wrote: post #49
qznc wrote: 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); }

It should work in GNU C:

  x = (something) ? ({ a = foo(); baz(a) }) : ({ b = bar(); baz(b); });
However, since all your forms are actually expression statements, we can happily just use the ISO C comma operator:

  x = (something) ? (a = foo(), baz(a)) : (b = bar(); baz(b));
If C provided operators for iteration, selection and for binding some variables over a scope (that scope consisting of an expression), everything would be cool. E.g. fantasy while loop:

  x = (
Variable binding:

  x = let (int x = 3, double y = 3.0) : (x++, x*y);
The problem is that some things can only be done with statements.

The ternary operator is not actually lacking anything; with the comma operator, multiple expressions can be evaluated. What's lacking is the vocabulary of what those expressions can do.

Re: The Idea of Lisp

#153

Post by goatlover »

coliveira wrote: post #28
erik14th wrote: post #18

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.

Most algorithms currently labeled machine learning are different in nature from original AI algorithms. Nowadays there is big emphasis in numerical algorithms, while in the past AI was about symbolic computation -- which is the biggest strength of Lisp. If you only use numerical algorithms, you can use Python or even FORTRAN.

But what makes Python any better at numerical algorithms than Common Lisp? It's not like CL is lacking in numeric support. It probably has superior numeric support than Python, actually.

Re: The Idea of Lisp

#154

Post by sbov »

clarkd99 wrote: post #55

This great idea of Lisp (the simple syntax of function calls in round brackets) isn't much different than a good macro assembler even back in the 1960's. The only major difference was that more than 1 function could be defined in 1 source code line. (I think that machine code is nothing but a sequence of function calls where the function is the logic encoded in the CPU itself for each opcode.) Is it fair to compare t…

There's a lot here, but this one jumped out at me:

> You can indent a Lisp program in any way but the language doesn't require any at all.

Off the top of my head, isn't this true of basically all languages? Except one, and it got a lot of criticism for it (Python).

Re: The Idea of Lisp

#155

Post by pg314 »

kbp wrote: post #50
Blackthorn wrote: post #36

Earlier quoted context omitted.

Well, it was. Specifically, Common Lisp was. But that language's standard was etched in stone in 1994 whereas languages like Python (where most deep learning user-facing code is done) continue to evolve. I think Python really took off for that because it already had quality and widely-used libraries for writing the code in Python and doing the work in a more efficient place (numpy, scipy). Clojure has one of those fo…

> Well, it was. Specifically, Common Lisp was. But that language's standard was etched in stone in 1994 whereas languages like Python (where most deep learning user-facing code is done) continue to evolve. This is an apples to oranges comparison. The Common Lisp standard hasn't been updated since 1994. The Python standard has not been written at all yet. Lisp and Python implementations both continue to evolve and be…

To add to that, the transition from Python 2 to Python 3 is also an example of how not to evolve a language.

Re: The Idea of Lisp

#156

Post by stcredzero »

theseoafs wrote: post #142
crististm wrote: post #129

Earlier quoted context omitted.

Garbage collection is not necessary for lisp. Garbage collection only provides the illusion of infinite memory. Just like malloc/free.

I assure you that "malloc" and "free" don't "provide the illusion of infinite memory". Quite the opposite, in fact.

Challenge: Write a Turing complete machine using a finite number of registers and a state machine. One or all of the registers can contain a rational number of unlimited precision. (This has already been done, so if you are aware of the existing machines, you have to create a new one.)

Re: The Idea of Lisp

#157

Post by goatlover »

georgeecollins wrote: post #130

When I was a kid they made us learn C and Lisp as part of Cognitive Science degree. I don't really use either language, unless you count C++. But I do feel that between those two languages you can understand two ideals really well. One is the idea of a clean symbolic expression, the other is the idea of a portable language that lets you get to the core of what the machine is really doing. Both are useful ways to thin…

Some years ago, Paul Graham wrote about there being too conceptually clean approaches to programming Languages, C and Lisp. The C family is far more popular, but the trend is to take C as your starting point, and add Lisp features to it.

Gosling said that Java drug the C++ crowd halfway to Lisp.

Re: The Idea of Lisp

#158

Post by pg314 »

goatlover wrote: post #153
coliveira wrote: post #28

Earlier quoted context omitted.

Most algorithms currently labeled machine learning are different in nature from original AI algorithms. Nowadays there is big emphasis in numerical algorithms, while in the past AI was about symbolic computation -- which is the biggest strength of Lisp. If you only use numerical algorithms, you can use Python or even FORTRAN.

But what makes Python any better at numerical algorithms than Common Lisp? It's not like CL is lacking in numeric support. It probably has superior numeric support than Python, actually.

Some/most Common Lisp implementation have better native support for numeric types than Python, but Python has a wealth of libraries like numpy that bind to optimised C/Fortran/assembly.

Re: The Idea of Lisp

#159

Post by kazinator »

junke wrote: post #143
stormbrew wrote: post #115

Earlier quoted context omitted.

Everything is an expression in Ruby, yes. Even `class` and `def` and `module`, for example. Though class, as a specific example, returns nil, so it's not terribly useful that it is one.

In Lisp, "def..." macros, like defclass, defun, etc. return the symbol to which is bound the definition. Not essential, but useful at times. I tend to find Lisp is full of details like this.

Well, Common Lisp!

In the Scheme language, many imperative forms have an unspecified result. For instance, see R7RS 4.1.6: "the result of the set! expression is unspecified".

Also, a related misfeature is that function arguments can be evaluated in any order.

Re: The Idea of Lisp

#160

Post by pjmlp »

AnimalMuppet wrote: post #149
pjmlp wrote: post #37

Earlier quoted context omitted.

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.

Wouldn't it be harder to get Lisp to run in a GPU, though? Or perhaps my point is, wouldn't it be harder to get old-style (symbolic) AI to run in a GPU than ML-style AI? (If I understand correctly, the old style is a lot of walking data structures, and the new style is largely matrix operations. The latter seems like a much better fit for a GPU than the former.)

Well, the Connection Machine was highly parallel.

Also the declarative way of programming in languages like Lisp, and also the macros, would surely allow for nice expressive DSLs.

So far I am only aware of companies exploring Haskell and F# support for GPUs, but I guess it is usually a matter of someone trying it out.

After all, there is FPGA tooling generation support for Clojure already,e.g. Piplin.

Post reply on HN