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

111–120 of 143 posts

Re: Lisp at the Frontier of Computation [video]

#111

Post by kbp »

agumonkey wrote: post #109
kbp wrote: post #103

Earlier quoted context omitted.

> 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

> In non lisp languages, the mutable array often came without map / filter

What languages do you know that have map and filter for lists, but not for arrays? Lisp has them for both, C++ has them for both, Java has them for both; Java didn't used to have lambdas or map, but it had standard lists long before it got either of them. Several decades before Java existed, Lisp had mutable arrays with map and filter. Supporting higher order functions has nothing at all to do with arrays vs lists.

> didn't have lambdas so you end up writing imperative loops

Lisp does have lambdas and imperative loops are still extremely common in Lisp code.

Re: Lisp at the Frontier of Computation [video]

#112

Post by taeric »

kbp wrote: post #107
taeric wrote: post #106

Earlier quoted context omitted.

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 p…

My reading comprehension on first waking up was terrible. I thought we were disagreeing, but I can see you were clearly adding to my statement, not contradicting it. :)

Love that quote from McCarthy, btw. I have not seen that before. Is there more in the context of where that came from?

Re: Lisp at the Frontier of Computation [video]

#113

Post by kbp »

taeric wrote: post #112
kbp wrote: post #107

Earlier quoted context omitted.

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 p…

My reading comprehension on first waking up was terrible. I thought we were disagreeing, but I can see you were clearly adding to my statement, not contradicting it. :) Love that quote from McCarthy, btw. I have not seen that before. Is there more in the context of where that came from?

It's from this: http://www-formal.stanford.edu/jmc/history/lisp/lisp.html

Re: Lisp at the Frontier of Computation [video]

#114

Post by PuercoPop »

rhaps0dy wrote: post #90
sedachv wrote: post #72

Earlier quoted context omitted.

Python is in no way a Lisp. Python is not homoiconic, does not have first-class identifiers (symbols), and does not have full support for dynamically loading code ( https://news.ycombinator.com/item?id=14666300 ). All that makes Python much closer to BASIC than to other dynamic programming languages. I think of Python as a BASIC with an object system and a couple of incorrectly borrowed ideas from Scheme (lexical sco…

Well, the comparison by Peter Norvig makes Python and Lisp look pretty similar ( https://norvig.com/python-lisp.html , also linked below in this thread). In some cases, you can get around no-first-class-identifiers in Python by using strings and getattr(object, symbol) or locals()[symbol]. (What are other use cases of first-class identifiers, other than making some function arguments or macros look prettier?)

And when Norvig made that claim in from of McCarthy, McCarthy disagreed.

> Peter bravely repeated his claim that Python is a Lisp.

> Yes, John?" Peter said.

> I won't pretend to remember Lisp inventor John McCarthy's exact words which is odd because there were only about ten but he simply asked if Python could gracefully manipulate Python code as data.

> "No, John, it can't," said Peter and nothing more, graciously assenting to the professor's critique, and McCarthy said no more though Peter waited a moment to see if he would and in the silence a thousand words were said.

http://smuglispweeny.blogspot.pe/2008/02/ooh-ooh-my-turn-why...

Re: Lisp at the Frontier of Computation [video]

#115

Post by _xhok »

sillysaurus3 wrote: post #41
xstartup wrote: post #30

Earlier quoted context omitted.

What's the most popular Lisp in use today? Does it come with a static compile type checking?

Rather than most popular, I propose using the most useful. That'd be Lumen. http://github.com/sctb/lumen It's the only lisp that can interface seamlessly with any JS library you want. Just `npm i leftpad && LUMEN_HOST=node lumen` and type `(require 'leftpad)`. $ npm i leftpad $ LUMEN_HOST=node lumen > (require 'leftpad) function > ((require 'leftpad) "foo" 5) "00foo" Other lisps are nice, but they all try to build th…

This is wonderful. Thank you for sharing! I've been putting off a JS coding project for some interview, which I now think I'll write in Lumen. Another pleasant surprise: it was written by the HN moderators.

Have you used this in any substantial projects?

Re: Lisp at the Frontier of Computation [video]

#116

Post by pjmlp »

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…

Not really, the way Lisp abstracts the hardware is what made projects like Thinking Machines in 1985, with StarLisp possible.

So it might not be 60 years ago, but 40 is already quite some years.

Re: Lisp at the Frontier of Computation [video]

#117

Post by mark_l_watson »

pjmlp wrote: post #116
taeric wrote: post #106

Earlier quoted context omitted.

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…

Not really, the way Lisp abstracts the hardware is what made projects like Thinking Machines in 1985, with StarLisp possible. So it might not be 60 years ago, but 40 is already quite some years.

I used StarLisp on the Connection Machine 1, and it was such a good fit for using the hardware. I didn't get too much time on that project, but StarLisp let me work offline on code before getting access to the hardware.

Re: Lisp at the Frontier of Computation [video]

#118

Post by open_bear »

michaelsbradley wrote: post #69
flavio81 wrote: post #56

This is a really good video. Here is a simple timeline of what it is all about, so people can jump to what they would find interesting: 23:43 "It really is incredible that we can go close to one order of magnitude" (to C) 26:00 Lisp code is faster than optimized C (quantum) programs when running on the QVM. For non trivial benchmarks (...) {Lisp faster} on an average of 40% percent. 30:00 quick explanation of quantum…

I guess ParEdit has staying power, but isn't Smartparens[+] the way to go these days? https://github.com/Fuco1/smartparens

Parinfer is another good attempt at making editing Lisp code easier: https://github.com/shaunlebron/parinfer

Re: Lisp at the Frontier of Computation [video]

#120

Post by dreamcompiler »

PuercoPop wrote: post #114
rhaps0dy wrote: post #90

Earlier quoted context omitted.

Well, the comparison by Peter Norvig makes Python and Lisp look pretty similar ( https://norvig.com/python-lisp.html , also linked below in this thread). In some cases, you can get around no-first-class-identifiers in Python by using strings and getattr(object, symbol) or locals()[symbol]. (What are other use cases of first-class identifiers, other than making some function arguments or macros look prettier?)

And when Norvig made that claim in from of McCarthy, McCarthy disagreed. > Peter bravely repeated his claim that Python is a Lisp. > Yes, John?" Peter said. > I won't pretend to remember Lisp inventor John McCarthy's exact words which is odd because there were only about ten but he simply asked if Python could gracefully manipulate Python code as data. > "No, John, it can't," said Peter and nothing more, graciously a…

I was at that meeting. The mood in the room toward Norvig was "Who are you and what have you done with Peter Norvig?"
Post reply on HN