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

Lisp at the Frontier of Computation [video]

youtube.com

Post reply on HN
Print view View original

101–110 of 143 posts

Re: Lisp at the Frontier of Computation [video]

#101

Post by progman »

dreamcompiler wrote: post #34
nafizh wrote: post #7

Every time, I see one of these links or videos, I feel the urge to learn Lisp. But after some time, I lose the motivation. I think that is because I don't know what benefit learning lisp will provide me concretely. Anyone has any suggestion?

Do you like Python? Python is basically simplified Lisp. Common Lisp is Python plus first-class lexical closures (rather than second-class) plus true multithreading plus a real compiler so it runs much faster. Plus parentheses rather than indentation to delimit expressions; parentheses are much more versatile once you get used to them.

The only foreign languages which come close to Lisp with a Python like syntax are Stanza [1] and Nim [2].

Stanza feels like a Lisp with infix syntax. The closeness to Lisp explains why Stanza makes a semantic difference between "f(x)" (which is a function application) and "f (x)" which is a sequence of two elements (f and x). Unlike Nim which is strongly typed, Stanza allows to mix typed and untyped data freely.

[1] lbstanza.org

[2] nim-lang.org

Re: Lisp at the Frontier of Computation [video]

#102

Post by agumonkey »

kbp wrote: post #97
agumonkey wrote: post #15

Earlier quoted context omitted.

Don't force it. It will come at the right time. Enjoy your spot on the programming map, it's no use to learn Foo if it means you'll suffer your day job or can't get enough value out of it. That said, lisp is a goldmine / rabbithole crossover. As other said: - opens for a hackable tool mindset, use lisp on lisp to make it do what you need [1] - as said in this talk, if you want a dsl, you don't need a parser. Only lat…

> it's often highly interactive, and value oriented. You get to "touch" the data a bit like material. Nowadays repl's are common, so it doesn't seem special but it was so for 30years. REPL's are common, but they're rarely as useful in other languages. Even relatively basic (to Lisp programmers) things are almost universally missing, for example: [1]> (defun f (x) (1+ (g x))) F [2]> (f 4) *** - EVAL: undefined functio…

map / filter over list is different from arrays. Even in the 2000s we had to hand write Java Iterators and fear mutation while iterating .. that sort of things.

Re: Lisp at the Frontier of Computation [video]

#103

Post by kbp »

agumonkey wrote: post #102
kbp wrote: post #97

Earlier quoted context omitted.

> it's often highly interactive, and value oriented. You get to "touch" the data a bit like material. Nowadays repl's are common, so it doesn't seem special but it was so for 30years. REPL's are common, but they're rarely as useful in other languages. Even relatively basic (to Lisp programmers) things are almost universally missing, for example: [1]> (defun f (x) (1+ (g x))) F [2]> (f 4) *** - EVAL: undefined functio…

map / filter over list is different from arrays. Even in the 2000s we had to hand write Java Iterators and fear mutation while iterating .. that sort of things.

> map / filter over list is different from arrays.

How?

    CL-USER> (remove-if-not #'evenp '(1 2 3 4 5))
    (2 4)
    CL-USER> (remove-if-not #'evenp #(1 2 3 4 5))
    #(2 4)
    CL-USER> (loop for x in '(1 2 3 4 5) when (evenp x) do (format t "~&~a~%" x))
    2
    4
    NIL
    CL-USER> (loop for x across #(1 2 3 4 5) when (evenp x) do (format t "~&~a~%" x))
    2
    4
    NIL
Even a function like:

    (defun print-evens (sequence)
      (loop for i below (length sequence)
            for x = (elt sequence i)
            when (evenp x)
              do (format t "~&~a~%" x)))
Works for both, although it's considerably more efficient for arrays.

> Even in the 2000s we had to hand write Java Iterators and fear mutation while iterating .. that sort of things.

And even in Lisp, the standard specifies "The consequences are undefined when code executed during an object-traversing operation destructively modifies the object in a way that might affect the ongoing traversal operation."

Re: Lisp at the Frontier of Computation [video]

#104

Post by progman »

astrange wrote: post #73
gnufx wrote: post #40

Earlier quoted context omitted.

An old epi²gram: There should be only one way to do it. — Python There's more than one way to do it. — Perl Do the right thing. — Lisp

"Do the right thing" is a brave statement for a language with no typechecking!

Emacs, one of the most reliable software ever was written in a language with no typechecking -- in Lisp! Emacs never crashes although it is configurable by the user in almost any way -- also in Lisp.

Re: Lisp at the Frontier of Computation [video]

#106

Post by taeric »

kbp wrote: post #100
taeric wrote: post #33

Earlier quoted context omitted.

That is far from the defining trait of lisp. Probably brought about because it was easy to pass around functions in lisp. However, i find lisp is at its most powerful when you understand some of the imperative abstractions that are available to you.

Around 60 years ago, Lisp pioneered functional programming and was the only thing that supported it at all. Up until the mid-90s or so it was still far and away the most popular language that had meaningful support for closures and higher order functions. That hasn't been true anymore for about 20 years, but for a long time anyone interested in using that stuff probably learnt it from Lisp, and Lisp was probably thei…

60 or so years ago, many of the main tricks of functional programming today were far too expensive in terms of memory to actually be used. So, I find this claim somewhat hard to take at face value.

More, early lisps were far more up front about their imperative abstractions. Something that we try our damnedest to hide from folks nowadays. In ways that are actually hard to fully explain. Used to, you were given an array of functions not just as a programmer, but as a user of the machine. The "side effects" of the functions were the point of them. They literally made the machine do something.

So, yes, functional has always been a defining element of lisp. I can fully support that statement. The defining element, though? I have a hard time supporting that one.

Re: Lisp at the Frontier of Computation [video]

#107

Post by kbp »

taeric wrote: post #106
kbp wrote: post #100

Earlier quoted context omitted.

Around 60 years ago, Lisp pioneered functional programming and was the only thing that supported it at all. Up until the mid-90s or so it was still far and away the most popular language that had meaningful support for closures and higher order functions. That hasn't been true anymore for about 20 years, but for a long time anyone interested in using that stuff probably learnt it from Lisp, and Lisp was probably thei…

60 or so years ago, many of the main tricks of functional programming today were far too expensive in terms of memory to actually be used. So, I find this claim somewhat hard to take at face value. More, early lisps were far more up front about their imperative abstractions. Something that we try our damnedest to hide from folks nowadays. In ways that are actually hard to fully explain. Used to, you were given an arr…

Yes, I agree. If you've ever read old Lisp code it's full of PROG and assigning variables and jumping around with gotos, McCarthy even said: "LISP also allows sequential programs written with assignment statements and go tos. Compared to the mathematically elegant recursive function definition features, the ``program feature'' looks like a hasty afterthought. This is not quite correct; the idea of having sequential programs in LISP antedates that of having recursive function definition." Mind, if you've ever read modern Lisp code, it's full of LOOP and ITER. Lisp has always been largely imperative.

As for what makes Lisp "different," I think it was true in about 1960 that it was mostly the functional support. It hasn't been for a long time, but I just think that people who don't know Lisp assuming that it is isn't completely unfounded.

> More, early lisps were far more up front about their imperative abstractions.

I will say that I have no idea how someone could look at Common Lisp and not realise it was largely an imperative language unless they had some major preconceptions going in.

Re: Lisp at the Frontier of Computation [video]

#108

Post by flavio81 »

cube2222 wrote: post #92
flavio81 wrote: post #52

Earlier quoted context omitted.

> What's the most popular Lisp in use today? At least if based in 2016 GitHub popularity: http://sogrady-media.redmonk.com/sogrady/files/2016/07/lang.... #1 Emacs Lisp #2 Common Lisp #3 Scheme #4 Racket Unless you consider Clojure a Lisp (yes it is, and no, it isn't...), in which case #1 would be Clojure, and then the others listed above.

Why would clojure not be considered a lisp? (I'm curious)

See this subthread and answers by LispM:

https://news.ycombinator.com/item?id=10207616

Re: Lisp at the Frontier of Computation [video]

#109

Post by agumonkey »

kbp wrote: post #103
agumonkey wrote: post #102

Earlier quoted context omitted.

map / filter over list is different from arrays. Even in the 2000s we had to hand write Java Iterators and fear mutation while iterating .. that sort of things.

> map / filter over list is different from arrays. How? CL-USER> (remove-if-not #'evenp '(1 2 3 4 5)) (2 4) CL-USER> (remove-if-not #'evenp #(1 2 3 4 5)) #(2 4) CL-USER> (loop for x in '(1 2 3 4 5) when (evenp x) do (format t "~&~a~%" x)) 2 4 NIL CL-USER> (loop for x across #(1 2 3 4 5) when (evenp x) do (format t "~&~a~%" x)) 2 4 NIL Even a function like: (defun print-evens (sequence) (loop for i below (length seque…

In non lisp languages, the mutable array often came without map / filter, weren't generic, didn't have lambdas so you end up writing imperative loops and potentially mutating elements in place because it's tempting; changing the paradigm right away

Re: Lisp at the Frontier of Computation [video]

#110

Post by taeric »

agumonkey wrote: post #102
kbp wrote: post #97

Earlier quoted context omitted.

> it's often highly interactive, and value oriented. You get to "touch" the data a bit like material. Nowadays repl's are common, so it doesn't seem special but it was so for 30years. REPL's are common, but they're rarely as useful in other languages. Even relatively basic (to Lisp programmers) things are almost universally missing, for example: [1]> (defun f (x) (1+ (g x))) F [2]> (f 4) *** - EVAL: undefined functio…

map / filter over list is different from arrays. Even in the 2000s we had to hand write Java Iterators and fear mutation while iterating .. that sort of things.

As the sibling post illustrates, it really isn't. And this is by far one of the biggest strengths of lisps that many languages are finally getting. The structure of your program often doesn't have to change just because you modified the underlying representation of some data.

Now, also pointed out by the sibling post, modifying the underlying driver of your logic is a bad idea. Just like having a printer print on its own circuitry would be a bad idea.

Post reply on HN