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

131–140 of 143 posts

Re: Lisp at the Frontier of Computation [video]

#131

Post by sedachv »

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?)

> What are other use cases of first-class identifiers, other than making some function arguments or macros look prettier?

You are completely missing the point. Not having identifiers be first-class objects with unique identity is how Python ended up being unable to reload code properly.

Re: Lisp at the Frontier of Computation [video]

#132

Post by cicero »

kbp wrote: post #94
gregman1 wrote: post #81

Earlier quoted context omitted.

They have still one thing in common - that are not oop!

Most Lisps have object systems; Common Lisp was the first ANSI-standardised language with one.

In most Lisps, objects are an option, as opposed to languages like Java.

Re: Lisp at the Frontier of Computation [video]

#133

Post by _xhok »

sillysaurus3 wrote: post #96
rcarmo wrote: post #93

Earlier quoted context omitted.

Lumen seems interesting, but at a quick glance the GitHub repo has zero information as to how to install it and getting it to run. Is it an npm package/lua rock as well? (edit: it's all in the repo.) Follow-up: I don't see much in the way of interop documentation... Pointers?

The cool thing is, there's no interop. It's literally JS or Lua. Think of it like CoffeeScript -- there's no "interop" between CoffeeScript and JS. It's just JS. You can see what each expression compiles to by passing it through (print (compile (expand ...))) For example: > ((require 'leftpad) "foo" 5) "00foo" > (print (compile (expand '((require 'leftpad) "foo" 5)))) require("leftpad")("foo", 5) And of course, you c…

Also, you can compile a Lumen file to JS/Lua by running `lumen -c file.l -o file.js`. More info at `lumen --help`.

Re: Lisp at the Frontier of Computation [video]

#134

Post by pjmlp »

taeric wrote: post #125
pjmlp wrote: post #116

Earlier quoted context omitted.

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.

What are you saying "not really" to? I wasn't claiming that lisp didn't allow you to use hardware. Rather, I was claiming that most of the hallmarks of functional code in today's programs wasn't possible in older hardware. Specifically, many of the "functional data structures" that people are growing to love nowadays were decidedly not possible on so little memory.

To which I gave the example of 80's Thinking Machines as "older hardware".

I could also given Symbolics as example.

As 40 year old examples, in 20 years the use of Lisp improved a lot since the early IBM mainframes.

Re: Lisp at the Frontier of Computation [video]

#135

Post by taeric »

pjmlp wrote: post #134
taeric wrote: post #125

Earlier quoted context omitted.

What are you saying "not really" to? I wasn't claiming that lisp didn't allow you to use hardware. Rather, I was claiming that most of the hallmarks of functional code in today's programs wasn't possible in older hardware. Specifically, many of the "functional data structures" that people are growing to love nowadays were decidedly not possible on so little memory.

To which I gave the example of 80's Thinking Machines as "older hardware". I could also given Symbolics as example. As 40 year old examples, in 20 years the use of Lisp improved a lot since the early IBM mainframes.

But what is that contradicting? Lisp certainly ran on older hardware.

My assertion is that "functional" is not the defining feature of lisp. My evidence is much of modern functional programming was not done for a large part of it's history. My claim is further that many modern idioms couldn't be done on older hardware. Not that lisp couldn't run there, but that modern practices couldn't. Regardless of language.

Functional is certainly a feature. Even a prominent one. Just not a defining one.

Re: Lisp at the Frontier of Computation [video]

#136

Post by qohen »

flavio81 wrote: post #44
tunesmith wrote: post #29

Earlier quoted context omitted.

The problem for me is that I've learned to avoid macros in other languages. It seems to me that when you've got a fairly complex program, you need a fairly complex mental model of what the program "is" to understand it. But if you introduce macros, or code writing code, then you have a much more complex mental model since now even what the code "is" can change. What is it about lisp that makes this an easier sell?

> The problem for me is that I've learned to avoid macros in other languages. Macros in other languages are significntly unlike Lisp macros. You should take a look at the Practical Common Lisp book (available for free online) to have an idea on how you can easily leverage Lisp macros for more readable, succint, easy to understand code. > But if you introduce macros, or code writing code, then you have a much more com…

Another free Lisp book, one that focuses on macros -- and is quite readable -- is YC-founder Paul Graham's "On Lisp". There's a download page [0] (for the book and code) at paulgraham.com as well as the following on a description page [1]:

On Lisp is a comprehensive study of advanced Lisp techniques, with bottom-up programming as the unifying theme. It gives the first complete description of macros and macro applications. The book also covers important subjects related to bottom-up programming, including functional programming, rapid prototyping, interactive development, and embedded languages. The final chapter takes a deeper look at object-oriented programming than previous Lisp books, showing the step-by-step construction of a working model of the Common Lisp Object System (CLOS).

As well as an indispensable reference, On Lisp is a source of software. Its examples form a library of functions and macros that readers will be able to use in their own Lisp programs.

[0] http://www.paulgraham.com/onlisptext.html

[1] http://www.paulgraham.com/onlisp.html

Re: Lisp at the Frontier of Computation [video]

#137

Post by pjmlp »

taeric wrote: post #135
pjmlp wrote: post #134

Earlier quoted context omitted.

To which I gave the example of 80's Thinking Machines as "older hardware". I could also given Symbolics as example. As 40 year old examples, in 20 years the use of Lisp improved a lot since the early IBM mainframes.

But what is that contradicting? Lisp certainly ran on older hardware. My assertion is that "functional" is not the defining feature of lisp. My evidence is much of modern functional programming was not done for a large part of it's history. My claim is further that many modern idioms couldn't be done on older hardware. Not that lisp couldn't run there, but that modern practices couldn't. Regardless of language. Funct…

One of the ideas behind Thinking Machines with StarLisp was functional programming.

Re: Lisp at the Frontier of Computation [video]

#138

Post by pjmlp »

kgwgk wrote: post #123
pjmlp wrote: post #89

Earlier quoted context omitted.

The sad part is that Ruby and Python could have taken some lessons from Lisp, how to have a dynamic language that has a good toolchain to generate native code. Thankfully we have now Julia, as yet another Algol-Lisp attempt.

The “lispy” aspect of Julia is somewhat disappointing, macros do not fit naturally with the non-lisp syntax of the language.

Agreed, but I can still imagine it being improved.

Re: Lisp at the Frontier of Computation [video]

#139

Post by kbp »

agumonkey wrote: post #126
kbp wrote: post #111

Earlier quoted context omitted.

> 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. Support…

I'm not criticizing lisp at all here. And Java had lists but no functional API on top of it. Processing ArrayLists is extremely different from (mapcar #'f '(....)), in idiom, paradigm. You can, but you'll have to do anonymous inner classes gymnastics and you'll end up writing loops before you know it. And my point is: it sucks.

> Java had lists but no functional API on top of it. Processing ArrayLists is extremely different from (mapcar #'f '(....))

My point was that the functional API is the key difference, not arrays vs lists. Java in 2000 had lists and no functional API, whereas Lisp in 1970 had mutable arrays with a functional API available for use on them. Mapping over a list in Lisp looks like `(map 'list #'f '(...))` (The first argument is the return type; MAPCAR is just a list-specific version of MAP), mapping over a Java-style array looks like `(map 'list #'f #(...))`. Lists vs arrays makes no real difference (if they were in variables instead of literals, you couldn't even tell if it were an array or a list by looking at that call). Java in 2017 similarly has a functional API that can be used on lists or (much more commonly) on mutable arrays.

Re: Lisp at the Frontier of Computation [video]

#140

Post by taeric »

pjmlp wrote: post #137
taeric wrote: post #135

Earlier quoted context omitted.

But what is that contradicting? Lisp certainly ran on older hardware. My assertion is that "functional" is not the defining feature of lisp. My evidence is much of modern functional programming was not done for a large part of it's history. My claim is further that many modern idioms couldn't be done on older hardware. Not that lisp couldn't run there, but that modern practices couldn't. Regardless of language. Funct…

One of the ideas behind Thinking Machines with StarLisp was functional programming.

Doesn't that still support what I'm saying? Specifically, was it a defining idea, or the defining idea?

I've never claimed that functional was not a facet of lisp. Just that it is not the facet.

Now, the claim I'm making that requires the most evidence is that many of the common functional datastructures people learn of today would not have been feasible on older hardware. I will not claim that they are too slow. I will claim that they are a bit too memory intensive for older hardware.

So, immutable lists are not equal to cons lists. Since most implementations allow direct modifications of cons lists. (Scheme bucked this trend, and people laud it for that. But it was certainly not the norm early on.)

Similarly, the highly branched vectors and other datastructures popular in clojure and friends are just too unfriendly to hardware. Could they have been done? Possibly, but the mutable structures had massive advantages on the hardware of the time. (Arguably, they still have advantages, just nowadays we get to make more tradeoffs between bleeding performance and maintenance.)

I'm definitely open to the idea what I'm saying is flat out wrong. I doubt I've reached my quota on stupid claims for my lifetime. And if my reading of your post was as off as one of the siblings where you weren't trying to contradict my claim, but strengthen it, my apologies. :) And my thanks for sticking with the thread.

Post reply on HN