Question: what would a LISP dialect with static typing look like? EDIT: Found an answer: http://stackoverflow.com/questions/3323549/is-a-statically-t...
The Idea of Lisp
181–190 of 348 posts
Re: The Idea of Lisp
#182It'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…
Specially since Lisp was once upon a time, also a systems programming language.
Re: The Idea of Lisp
#183When I was a kid they made us learn C and Lisp as part of Cognitive Science degree. I don't really use either language, unless you count C++. But I do feel that between those two languages you can understand two ideals really well. One is the idea of a clean symbolic expression, the other is the idea of a portable language that lets you get to the core of what the machine is really doing. Both are useful ways to thin…
Some years ago, Paul Graham wrote about there being too conceptually clean approaches to programming Languages, C and Lisp. The C family is far more popular, but the trend is to take C as your starting point, and add Lisp features to it. Gosling said that Java drug the C++ crowd halfway to Lisp.
And many of us don't really want to go back. :)
Re: The Idea of Lisp
#184This 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…
> Implementing Lisp properly in machine code is not easy; you have to write a garbage collector.
That's not actually true: you could, instead, just fill up memory and crash when you're out. It's not ideal, but it does work.
Re: The Idea of Lisp
#185This 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…
There's a lot here, but this one jumped out at me: > You can indent a Lisp program in any way but the language doesn't require any at all. Off the top of my head, isn't this true of basically all languages? Except one, and it got a lot of criticism for it (Python).
After I wrote that statement I started thinking that C programs can be formatted so that they don't read very well also. In C, an 'if' is always an 'if' (unless you use the pre-processor to screw it up) but in Lisp an 'if' could be anything. I do like the idea of Lisp macros where you can run a Lisp program at compile time to generate the code that is then compiled inline.
What I should have said was that Lisp has no commands or structure that can't be changed. Some might argue that this is it's strength but I have seen hundreds of samples of Lisp and it looks very confusing. I don't normally program in C# or Java or many other languages but I can normally understand their code. (Lisp and functional languages are the most opaque to me)
My language uses a byte code interpreter and that byte code is in polish prefix notation just like Lisp. I wouldn't want to code in my byte code either (even if the byte codes were replaced with keywords instead of the binary code). Polish prefix notation is great for the compiler but not very good for people.
Re: The Idea of Lisp
#186Earlier 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.
There was no "AI winter"; that's a myth. Well, or least a big exaggeration when used to explain why certain things are the way they are. The main force which explains everything is the procession whereby mainframes were replaced by minis, were replaced by workstations, were replaced by microcomputers. At each stage, the new wave of hardware started small, bringing in its own approaches, tools and languages. As each w…
Imagine an alternative universe where AT&T was allowed to sell UNIX and charged the same price as other mainframe OSes, instead of a symbolic license price for universities.
I have a feeling that would have turned out quite different.
Re: The Idea of Lisp
#187Earlier quoted context omitted.
void in C can't be created, used, or passed around - () can.
But void pointers can, and are often used.
So in Rust, the equivalent of void* with references instead looks like:
enum Void{}
fn foo(v: &Void){ ... }
let bar : Void;
fn abc() -> &Void{ ...}
fn xyz() -> Void{ ... }
On the other hand, you can do all of these just fine:
fn foo(v: ()){ ... }
fn bar(v: &()){ ... }
...
let v = ();
bar(&v);
foo(v);
(All statements here are made within the safe subset of the language - unsafe allows access to intrinsics that would allow a Void to be made, and a reference to Void.)
Re: The Idea of Lisp
#188Earlier quoted context omitted.
They do if always matched 1:1, it doesn't usually happen, specially in big codebases, thus leading to CVEs.
They surely do not. Malloc is specified in such a way such that the request for memory can fail (which leads to returning NULL).
The specification allows for this, yes. However, on some platforms (including linux glibc by default, I believe), malloc() never fails, but allocates virtual memory optimistically; the first you hear of an out of memory condition is when the system slows down due to paging, and the next thing you notice is when the OOM killer nixes a process.
Of course, other platforms, especially embedded ones, behave differently.
Re: The Idea of Lisp
#189It'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…
That's good perspective. My lens on it has mostly been stuff like SICP, Paul Graham's old essays, periodic Lisp HN posts etc. Good to hear there's a community out there that's fine with the messy practical stuff.
Re: The Idea of Lisp
#190Earlier quoted context omitted.
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.
In practice, many programs ignore the fact that malloc can return NULL. As do some OSes and their implementations of malloc, if they support/enable/require overcommit. These are perhaps operating under "the illusion of infinite memory" (in the GC sense): free, in this context, is simply a way of marking data as invalid and no longer to be referenced - a method of poisoning data for debug purposes.
But of course, I've had malloc return NULL - very finite.