Live data from Hacker News

The Idea of Lisp

dev.to

61–70 of 348 posts

Re: The Idea of Lisp

#61
post #31

Earlier quoted context omitted.

Yeah the level of dynamicness (dynamism?) you can get in tcl is unparalleled as far as I can see. Having no types or syntax and access to the entire runtime at any point in the program opens up all kinds of crazy doors. But you're right, that slows it down. But you might be interested to know there is currently an effort to get Tcl to compile to native/near-native code. Here is a paper on the new techniques being dev…

Picolisp can match it in dynamism. Seriously, Picolisp is absolutely insane.

I just read a bit of documentation from the Picolisp page. It looks really cool, but can it reach arbitrarily far up the call stack? That's the quality of tcl that I don't see other places. The capabilities of 'upvar' and 'uplevel'.

[Edit] I should say "one of the qualities." The other important one is that Tcl has no types. Even all the lisps I know have types.

Re: The Idea of Lisp

#62

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…

[deleted]

Re: The Idea of Lisp

#63
post #25

Earlier quoted context omitted.

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, while it has its warts, is a really cool language. I mean, it even basically has fexprs, something most Lisps put by the wayside years ago. When you don't actually care about speed, you can do some pretty cool stuff.

Pity that it became so associated with the Tk GUI toolkit -- half the Linux GUI apps in the 1990s were in Tcl/Tk, and when Tk fell out of favor so did Tcl.

Re: The Idea of Lisp

#64

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…

Agreed about linked lists; that virtually all functional languages make them the default/literal data structure is IMO a poor practical design choice (no matter how theoretically elegant) and is the primary culprit for their reputation for slowness.

And the tendency for functional compile-to-JS langs to emulate linked lists in Javascript and keep them the default data structure is downright laughable.

Re: The Idea of Lisp

#65
post #43

I'm working on a Lisp-based introductory programming book: https://github.com/rongarret/BWFP Still very much a work in progress. Feedback appreciated.

You may be interested in checking this out for inspiration: http://www.ccs.neu.edu/home/matthias/HtDP2e/

(It's the Intro to CS book used at my alma mater, teaching programming in Racket)

Re: The Idea of Lisp

#66
post #24

Earlier quoted context omitted.

While ML was the meta language for a theorem prover. Funny how these were side effects.

And ML was originally written in Lisp. https://github.com/theoremprover-museum/LCF77/tree/master/sr... https://github.com/theoremprover-museum/HOL88/tree/master/sr...

ps: I didn't bother to check those repos. Very nice to see old lisp code. It's very very clean. I often fear messy lisp 1.5 style but that's quite pretty.

Re: The Idea of Lisp

#67

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…

You make some specific claims here that sound a little odd to this LISP and assembly language hacker.

Assembly language doesn't provide any datatypes. LISP does. Assembly language doesn't provide any type checking. LISP does. Assembly language doesn't provide automatic storage reclamation. LISP does. Assembly language doesn't provide naming. LISP does.

You also make a claim about L1 caches and locality of reference. Every LISP compiler writer, and every LISP garbage collector writer, knows about CDR-coding. We also know about how Cheney copying garbage collectors and their descendants like the Baker incremental collector compact data, precisely for locality of reference. The compiler writer of course is thinking about cache performance and how lines are mapped in particular target architectures.

You should probably educate yourself a little more about LISP if you are so interested in it as to make statements in a public forum.

Re: The Idea of Lisp

#68
post #25

Earlier quoted context omitted.

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.

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*).

Re: The Idea of Lisp

#69
post #4
post #3

Lisp was developed because McCarthy needed a tool for experimenting with AI. Found a video of McCarthy talking about AI: https://www.youtube.com/watch?v=Ozipf13jRr4 And if anyone cares, here is nice Shirt with McCarthy on it ;) https://www.teepublic.com/t-shirt/666689-john-mccarthy-lisp-... I think it should be mandatory for CS students to implement their own little Lisp using the building blocks McCarthy described!…

Is there a kind of walkthrough/tutorial about how to develop a little Lisp interpreter? That sounds like a fun experiment. PS: Sorry, I am a Java OO developper. But I like to learn :)

I've made a Lisp that compiles to Ramda.js, the source code is simple, http://github.com/yosbelms/ramdascript

Re: The Idea of Lisp

#70
This article has many misstatements in its first half.

> John McCarthy wrote 6 easy things in machine code, then combined them to make a programming language.

John McCarthy didn't implement Lisp in machine code. Steve Russell did. Implementing Lisp properly in machine code is not easy; you have to write a garbage collector. To do that in the early 60s, you had to first invent garbage collection. Lisp was and is brilliant, but not as easily bootstrappable as this makes it out to be.

> It's not obvious that these six things are computationally complete (AKA Turing Complete).

`lambda` and function application alone are Turing-complete, as McCarthy would have known. The credit here belongs with Turing and Church, not McCarthy. `atom`, `cons`, `car` and all the rest are just icing on the cake of the lambda calculus when it comes to computability.

> All other meaning can be defined in terms of them.

Yes, and you can build everything on top of the SK combinator calculus if you like, but that doesn't make it a good idea. Lisp is surprisingly practical given how few core constructs it has, but real Lisp implementations have always added more primitives (eg. numbers and addition) for reasons of practicality.

> The language was defined in terms of itself as an interpreter. This is a proof by construction that the language is computationally complete.

No, it isn't. To prove Turing-completeness you need to show that you are as powerful as Turing machines. To do this it suffices to show that you can interpret a language already known to be Turing-complete. Showing you can interpret yourself does not suffice. It's easy to define a language which can do nothing useful except interpret itself, for example. (See also wyager's comment.)

> Well, Lisp is defined as an interpreter in terms of itself from the get-go, just like a Universal Turing Machine.

No. Defining a language only in itself is nonsense, for exactly the reason given above: it means nothing yet! It's like writing in a dictionary:

   qyzzyghlm, v. intr. To qyzzyghlm.
It explains nothing unless you already understand it!

> Lisp is a universal language because it can interpret its own code. While you can certainly write a JavaScript interpreter in JavaScript, none of the work is done for you.

Almost none of the work is done for you in Lisp either. The core of Lisp is just a relatively easy language to implement, while Javascript is a difficult one. Lisp is easy to implement because it has simple syntax (s-expressions) and few core constructs. The only thing that is special about implementing Lisp in Lisp is that Lisp uses s-expressions as its core data structure, so you don't have to invent an AST representation. The article, to its credit, explores this idea later.

Post reply on HN