31–40 of 63 posts
If iOS had required Lisp instead of Objective-C, then Lisp would have been popular right now. Ruby really needed Rails to get people to try it. I think the killer use problem is more an explanation then anything else. Java also showed a good marketing, well funded campaign does wonders.
Probably. I wonder if we wouldn't have ended up with more Xamarins instead.
It's kind of interesting in the 2001 essay that invented blub it was suggested as a hypothesis as to >And if Lisp is so great, why doesn't everyone use it? Suggesting programmers in a blub language don't realise it's power. I get the impression in the 18 or so years subsequently that the main reason for the low uptake of Lisp is it's power enables people to write clever code that other programmers have quite a job to…
Golang was designed around the philosophy of blub.
It's kind of interesting in the 2001 essay that invented blub it was suggested as a hypothesis as to >And if Lisp is so great, why doesn't everyone use it? Suggesting programmers in a blub language don't realise it's power. I get the impression in the 18 or so years subsequently that the main reason for the low uptake of Lisp is it's power enables people to write clever code that other programmers have quite a job to…
I'd love to know Lisp, just like I'd love to know Python. I have no experience in either (I come mostly from Java, javascript with some Ruby and some ancient C/C++ experience). When I look at Python code, I understand what it does. I don't think I've ever written any Python, but I think I could sit down and be productive within a day. Lisp looks like complete gobbledygook to me. I'd love to be able to understand it a…
PG: - It is more efficient to write software in Lisp. Others: - Nah, it doesn't matter.
But no empirical evidence has ever been presented...
This one sentence to me is an indication that the author has completely missed the point. Templates and macros do the "same thing" only in the sense that all languages do the "same thing" at some level of abstraction, that is, model Turing machines. What matters is not what languages "do" when they are compiled, but in how they bridge the "impedance mismatch" between TM's and human brains. And in that regard, templates and macros are about as different as two language constructs can possibly be.
Earlier quoted context omitted.
> Lisp looks like complete gobbledygook to me. Might that be Clojure, rather than Lisp, that you're looking at, without an extensive functional programming background? Some classic Lisp code, too, will look like gobbledygook if you've never had a tutorial, due to unfamiliar symbols. If you don't know what is a "cons cell" or the functions car and cdr , for instance. Surely, you can guess what this is doing: (let ((x…
> unfamiliar symbols. If you don't know what is a "cons cell" or the functions car and cdr, for instance. Those short, cryptic names are definitely part of it. It's unfamiliar syntax, and overdose of brackets for added confusion, and in the middle of it all, words that mean nothing to me. Stuff like cout, puts or the printf syntax also take some getting used to if they're new to you, but you get more context with the…
The good news is that parentheses disambiguate everything; if we remove some of them, we have to introduce hidden rules that determine what is a child or sibling of what.
let can have fewer parentheses, and some dialects (like Arc, in which HN is written) have tried that:
(let (x 1 y 2) ...)
(let1 x 1 ...)
Parentheses are needed around the variables so that they form a single argument position in the let syntax. Without that, we don't know where the body of the let begins. So that is to say, if we make it (let (x 1) (y 2) (print x)), how do we know (y 2) isn't supposed to be an invocation of function y on argument 2 rather than another variable binding.
The parentheses are great for code layout; there are formatting rules to make all complex expressions look consistently good. The parentheses also facilitate good editor support.
Earlier quoted context omitted.
But that's because all the languages you know are basically dialects of each other because they all descend from ALGOL, not because they are inherently easier to understand. Similarly, someone trained in Lisp would find things like Scheme and Clojure easier to understand than something like Python because those likewise are dialects of Lisp. I'd strongly recommend studying languages different from ones you know -- th…
> not because they are inherently easier to understand I'm honestly not sure that that's true. I would bet money that someone who primarily works in Lisp would still have an easier time sitting down and reading Python code than someone who works in Python sitting down and reading Lisp, because I think it might truly be inherently easier to understand. There is intrinsic meaning in: x = 5 let x = 5 etc., insofar as th…
No, there isn't. That just happens to be closer to the notation you were taught in elementary school, so you're more familiar with it. If you were taught s-expressions in elementary school (and this would actually be a really good idea) you would say the exact opposite. In fact, once you understand s-expressions, all other notations seem awkward and arbitrary. That's actually the reason that Lisp persists, because it's a kind of natural "local maximum" in notational idea space. It just happens to be one that very few people ever reach because of the damage done to them in their primary school education.
Isn't anyone but me annoyed by the lack of scientific rigor in arguments like these? PG: - It is more efficient to write software in Lisp. Others: - Nah, it doesn't matter. But no empirical evidence has ever been presented...
It's kind of interesting in the 2001 essay that invented blub it was suggested as a hypothesis as to >And if Lisp is so great, why doesn't everyone use it? Suggesting programmers in a blub language don't realise it's power. I get the impression in the 18 or so years subsequently that the main reason for the low uptake of Lisp is it's power enables people to write clever code that other programmers have quite a job to…
Lisp isn't really a language so much as a language construction toolkit, because macros are like language features (e.g. any macro you're using needs dedicated support from any tools that you want to use on your codebase). Effective lisp organizations will generally use a small handful of general-purpose macros throughout their codebases - but at that point you might as well standardise that handful of macros as a la…