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

141–150 of 348 posts

Re: The Idea of Lisp

#141

Post by goatlover »

mroll wrote: post #31
qwertyuiop924 wrote: post #26

Earlier quoted context omitted.

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.

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…

I believe IO lets you do the same. Everything is a prototype with slots, communicating via messages.

I guess Self was the same way. Self & Smalltalk also give you access to the entire runtime.

Re: The Idea of Lisp

#142

Post by theseoafs »

crististm wrote: post #129
rntz wrote: post #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 bril…

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.

Re: The Idea of Lisp

#143

Post by junke »

stormbrew wrote: post #115
dopamean wrote: post #80

Earlier quoted context omitted.

Correct me if I'm wrong but doesn't Ruby have everything (maybe just most?) things be an expression. I always liked x = if condition something else something_else end

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.

Re: The Idea of Lisp

#144

Post by pg314 »

crististm wrote: post #129
rntz wrote: post #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 bril…

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

And the implementation of garbage collection was, on at least two occasions, postponed. Once in the first implementation [1] and a second time in the early MIT Lisp Machines [2] (you just ran the machine until you ran out of memory which could take days or weeks, after which you saved the world to disk and rebooted).

[1] http://www-formal.stanford.edu/jmc/history/lisp/node3.html

[2] https://www.csee.umbc.edu/courses/331/resources/papers/Evolu...

Re: The Idea of Lisp

#145

Post by kazinator »

vertex-four wrote: post #73
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();

The difference is that C/Java/Algol have different syntaxes for things-as-expressions and things-as-statements, and you can't put blocks in the things-as-expressions. In Rust, blocks are also expressions and so have a result (the result of the last expression in the block), so your expressions inside the if can be as complex as you like. Since functions also have a block, and the return value of the function is the r…

In GNU C, you can use a brace-enclosed statement block as an expression.

Funny story; years before I became a C programmer, and at a time when I didn't yet study ISO C properly, I discovered and used this extension naturally.

I wanted to evaluate some statements where only an expression could be used so I thought, gee, come on, can't you just put parens around it to turn it into an expression and get the value of the last expression as a return value? I tried that and it worked. And of course, if it works it's good (standards? what are those?)

Then I tried using the code with a different C compiler; oops!

Anyway, this GNU C feature doesn't have as much of an impact as you might think.

Re: The Idea of Lisp

#146

Post by goatlover »

jhbadger wrote: post #63
qwertyuiop924 wrote: post #26

Earlier quoted context omitted.

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.

Should have been made available on the web by some browser vendor in the 90s. Netscape invented a language, Sun wanted to embed Java, but went with the applet approach in lieu of Netscape, Microsoft put vbscript in IE.

Re: The Idea of Lisp

#147

Post by theseoafs »

jimktrains2 wrote: post #76
virtualwhys wrote: post #68

Earlier quoted context omitted.

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

It's the same thing. It's a type with only a single value.

`void` in C does not have a value. You can't make a variable and put a void in it because there is no such object as "void".

Re: The Idea of Lisp

#148

Post by shakna »

amelius wrote: post #54

Question: what would a LISP dialect with static typing look like? EDIT: Found an answer: http://stackoverflow.com/questions/3323549/is-a-statically-t...

I designed and built a statically-typed F-Expr LISP for my thesis, using some partial AST evaluation to trace and ensure every value had at least an initial value, and from that, type inference.

So it looked like:

    (define fib
      (lambda (n)
        (let loop ((a 0) (b 1) (n n))
          (if (= n 0) a
          (loop b (+ a b) (- n 1)))))
Which would do nothing by itself, and be eliminated as dead code unless called.

If we called it with:

    (fib 10)
It would expand, after the macro stage, to:

    (define fib
      ((Type/Number lambda) ((Type/Number n))
        (let loop (((Type/Number a) 0) ((Type/Number b) 1) (n n))
          (if (= n 0) a
          (loop b (+ a b) (- n 1)))))
If a value couldn't be inferred after ensuring the validity of the AST, it was supposed to error out with some helpful messages, but tracing the entire AST forward and back repeatedly always managed to type every value that was at least initialised, and if not, eliminate it as dead code.

Tradeoffs:

Compiling can be very lengthy, and it would be theoretically possible to write a program that would take ridiculous times to compile.

Once compiled, we can ensure type safety, and in the underlying implementation, JIT everything for a decent amount of speed.

Edit: Forgot to add lambda return type. Then added it in the wrong place.

Re: The Idea of Lisp

#149

Post by AnimalMuppet »

pjmlp wrote: post #37
mtrimpe wrote: post #22

Earlier quoted context omitted.

Because Common Lisp was the language for AI before the big AI-winter hit and it's now associated with approaches to AI that don't actually work. Also a lot of the latest AI is hyper optimized data crunching on GPUs which isn't necessarily one of lisp's strengths.

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

Re: The Idea of Lisp

#150

Post by goatlover »

mbrock wrote: post #128
QuadrupleA wrote: post #119

It's interesting, I'm reading Black Swan at the moment by Nassim Taleb, and one of his big rants is about how we get blinded by idealized, platonic forms and ideas when the real world is messy and inherently unpredictable. E.g. trying to explain the forms of nature with platonic archetypal shapes like circles, rectangles and triangles. Lisp and the community around it kinda has that flavor - getting lost in a world o…

I don't think actual Lisp programmers share this obsession with purity and ideal forms. It's more something that shows up in blog posts about Lisp by people who probably don't actually use it. The title of this one is telling: it's about "the idea of Lisp." On the other hand, if you look at, say, ANSI Common Lisp, it's not at all some kind of perfectionistic attempt at divine elegance. It's a pragmatic compromise res…

But then again, there's Scheme ...
Post reply on HN