Live data from Hacker News

The Idea of Lisp

dev.to

101–110 of 348 posts

Re: The Idea of Lisp

#101
post #89
post #61

Earlier quoted context omitted.

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.

>The other important one is that Tcl has no types. Is it that it has no types or that everything is a string? asking, not stating.

Yes, everything is a string. But you can pass data around anywhere you like without worrying about coercing. A command will receive its data in string representation and treat it however it likes. So when you go to do math with the 'expr' command, 'expr' will treat its arguments as numbers.

    set x 5
    expr { $x + 3 }
'expr' receives x as the string 5 but knows to treat it as an int.

I'm not sure that's a great explanation. Maybe a decent summary of the concept of 'no types' is "the language does not presume to tell you how you can or cannot use your data."

Re: The Idea of Lisp

#102
post #27
post #2

The conditional expression or more specifically everything being an expression is my favorite thing about Lisp. I did not know that McCarthy pushed to add it to Algol which apparently today is the ternary operator for most languages. It is annoying that so many languages (C, Java, C#, etc) have both a conditional statement (if-else) and conditional expression (ternary ?:). Really the if-else should be an expression (…

Is there any literature on how to translate languages where everything is an expression to ones where it isn't, for example when compiling/transpiling to java? If/then can be translated to the ternary operator, but terms like try/catch are trickier.

An easy to follow example is Coffeescript (where everything is an expression), which transpiles in javascript (where not everything is).

Re: The Idea of Lisp

#103
I can't comment too much on this article, as I have a very, very limited view on LISP - basically just a couple of minor tutorials and one of the open-source interpreters. For me, it's always been one of those "I need to learn this" kind of languages, but I've never had a use case for it, and so it remains a curiosity to me more than anything.

I do know, though, that LISP allows the creation (or at least I have heard) for DSLs - so I am curious what people here think about this.

I'm also curious if anyone has an opinion on JetBrains MSL:

https://www.jetbrains.com/mps/

...and whether that would be a better thing to learn before or after learning LISP, as well as how it compares to LISP?

It's yet another "thing" that has caught my eye over the years, but again - no use case, and so it remains on the back burner for now...

Re: The Idea of Lisp

#104
post #2

The conditional expression or more specifically everything being an expression is my favorite thing about Lisp. I did not know that McCarthy pushed to add it to Algol which apparently today is the ternary operator for most languages. It is annoying that so many languages (C, Java, C#, etc) have both a conditional statement (if-else) and conditional expression (ternary ?:). Really the if-else should be an expression (…

It's been a while since I used Common Lisp but isn't it recommended to use "if" for conditional expressions and "when"/"unless" for conditional statements?

The choice exists only if you have a single form to evaluate subject to the condition. If there are two or more, of course this is imperative programming and (when condition form1 form2 ...) recommends itself over (if condition (progn form1 form2 ...)). If there is only form1, either one will do, so then it's down to a decision based on whether form1 returns a useful value and/or performs a side effect.

Re: The Idea of Lisp

#105
post #103

I can't comment too much on this article, as I have a very, very limited view on LISP - basically just a couple of minor tutorials and one of the open-source interpreters. For me, it's always been one of those "I need to learn this" kind of languages, but I've never had a use case for it, and so it remains a curiosity to me more than anything. I do know, though, that LISP allows the creation (or at least I have heard…

Lisp is an interesting thing because once you learn it, you start seeing use cases for the ideas you've picked up during the process all over the place.

Re: The Idea of Lisp

#106
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…

The story as I have heard it before is that John McCarthy wrote a Lisp interpreter in Lisp and Steve Russell translated it directly into machine code to get a working interpreter. Wikipedia indicates that Steve Russell implemented Lisp in machine code twice but gives no details.

Do you have a source giving additional details of what happened?

Re: The Idea of Lisp

#107
post #20

I wonder why lisp isn't as popular as say python for AI, ML, and stuff. I see these fields as having a strong academic tone, and it feels like racket or clojure could be bigger when it comes to that.

The "base rate" popularity of Python is much higher than all those others. This leads (via many mechanisms) to Python being more popular than these others. (The reason it's Python and not another popular language is another matter - I think for various reasons Python was a more popular language for scientific computing).

Could you explain what you mean by the "base rate" popularity?

Re: The Idea of Lisp

#108
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…

«`lambda` and function application alone are Turing-complete, as McCarthy would have known. The credit here belongs with Turing and Church, not McCarthy»

I have sometimes pedantically quibbled with people that it is properly named the Church-Turing Theorem (of Computation) and that that distinction of including both esteemed mathematicians helps to push people towards the realization of how groundbreaking that effort was (two mathematicians separated by an ocean and using vastly different approaches to the mathematics of computation realizing how intricately linked they were), and also how the Lambda Calculus truly was integral in the definition of "Turing-complete".

Without Church's work on the Lambda calculus and without the Lambda calculus being so very different from the Turing "imperative" model of machine, we'd probably have a much narrower view of what "Turing-complete" even means, if we even had the concept at all.

Re: The Idea of Lisp

#109
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();

I see two issues with the ternary operator. One, the syntax is much less readable, and two, the consequent and alternate are both single expressions, so you can't do something like: x = if(something) { a = foo(); baz(a); } else { b = bar(); baz(b); }

If you insist on the assignments:

x = something ? ((a=foo()), baz(a)) : ((b = bar()), baz(b));

Otherwise:

x = something ? baz(foo()) : baz(bar());

Re: The Idea of Lisp

#110

Earlier quoted context omitted.

(Singly linked) lists are a functional data structure. You can manipulate them efficiently without modifying the lists you started with. You can't do that easily with arrays. So if you base your language around arrays, you're better off making it imperative. Lisp predated level 1 caches. I think it's better to design hardware around the software that runs on it (the Burroughs mainframe/Lisp machine approach), than de…

I can 'efficiently modify the lists you started with' with a dynamic multi-type array and I have cache locality and random access. I have a single data structure with an 8 byte overhead, 2 byte overhead per node that can be used as a tuple array with direct lookup, a single linked list, double linked list, a queue, a stack, and a balanced binary search tree. This whole structure is allocated in a single contiguous me…

I'd be interested to learn more about your language. Is there a web page about it, or a paper? Are you the D Clark who's at UCL?

The way things are now can be changed.

For most applications users care more about response times than CPU clock rates. Hardware has speeded up by several powers of ten (Moore's law) but software has at the same time slowed down (Wirth's law), resulting in little if any net gain, and that has nothing to do with the use of lists: most applications don't use them.

Post reply on HN