181–190 of 239 posts
Earlier quoted context omitted.
Just a curiosity -- why do you call Clojure a "half-Lisp?"
Not me, but I would guess it's because, while both Common Lisp (ie. SBCL) and Clojure are both Lisp-like languages per se, Clojure departs further from "pure" Lisp than Common Lisp, in that it replaces lists with things such as vectors in a lot of places (see defn syntax).
Earlier quoted context omitted.
"How is it that referential transparency..." That was incorrect, I meant: "the kinds of metaprogramming associated with homoiconicity are mutually exclusive with referential transparency". A macro could not, for instance, take a variable name as an argument and return a result that's based on the value of that variable and maintain referential transparency. So that would be a pretty weak macro system. I suppose there…
Maybe I don't understand referential transparency, but why not? `or` is a macro in Clojure: (def a 10) (def b 20) (or a b) => 20 Is `or` not referentially transparent?
My clojure interpreter gives "10" not "20".
The function "or" is referentially transparent, because if you call it with the same argument values you are going to get the same result every time. (or 10 20) is the same as 10.
However, the following function is not referentially transparent:
(defn incx [] (do (def x (+ x 1)) x))
(def x 2)
(incx)
(incx)
Earlier quoted context omitted.
the first Gulf War in Iraq was won because a Lisp application took care that US soldiers had everything from toilet paper, ammunition to gasoline The word because means that if there was no Lisp application the war would not have been won. This is almost certainly false, even if the Lisp application did make things easier.
without that application, nobody would have been there.
Am I the only one having a hard time reading lisp? Non-functional programs read like plain English. Particularly Python but I just can't get my head around the functional ones.
Earlier quoted context omitted.
Maybe I don't understand referential transparency, but why not? `or` is a macro in Clojure: (def a 10) (def b 20) (or a b) => 20 Is `or` not referentially transparent?
(please excuse my poor knowledge of lisp... check out the wikipedia page if my explanation falls apart: http://en.wikipedia.org/wiki/Referential_transparency_%28com... ) My clojure interpreter gives "10" not "20". The function "or" is referentially transparent, because if you call it with the same argument values you are going to get the same result every time. (or 10 20) is the same as 10. However, the following fun…
That said, if any admission of mutability is sufficient to disqualify a language from claiming to encourage or support referential transparency, then Haskell fails the test, too. unsafePerformIO is a trivial example. I'm sure if you were determined to introduce nondeterminism, you could find a lot more. But that's not the point, is it?
Maybe there's a way to demonstrate your point, but what you've shown here doesn't involve homoiconicity or macros at all.
Great story. Unfortunately, the API documentation and tutorial writing guilds went extinct decades ago and has never been able to return to Lispland. :)
I'd ask you to mention a lisp library which you use but find under-documented (as another reply already has), but I don't think anyone with actual first-hand knowledge of the CL ecosystem would make this comment (even though I'm sure it recieved many enthusiastic if uninformed upvotes).
Lets look at some popular libraries with documentation. - Alexandria http://common-lisp.net/project/alexandria/draft/alexandria.h... - CL-PPCRE http://weitz.de/cl-ppcre/ - metabang-bind http://common-lisp.net/project/metabang-bind/ - not to mention the standard by which all other language documentation should be judged, the CL hyperspec http://www.lispworks.com/documentation/HyperSpec/Front/
And with sites like http://www.cliki.net/, http://common-lisp.net/ and http://www.gigamonkeys.com/book/ and many other full length books, if you can't find lisp documentation you're not looking very hard.
Earlier quoted context omitted.
the first Gulf War in Iraq was won because a Lisp application took care that US soldiers had everything from toilet paper, ammunition to gasoline The word because means that if there was no Lisp application the war would not have been won. This is almost certainly false, even if the Lisp application did make things easier.
without that application, nobody would have been there.
Great story. Unfortunately, the API documentation and tutorial writing guilds went extinct decades ago and has never been able to return to Lispland. :)
This is how false misperceptions are spread. I'd ask you to mention a lisp library which you use but find under-documented (as another reply already has), but I don't think anyone with actual first-hand knowledge of the CL ecosystem would make this comment (even though I'm sure it recieved many enthusiastic if uninformed upvotes). Lets look at some popular libraries with documentation. - Alexandria http://common-lisp…
I'll make that statement, but only in a somewhat pedantic sense about the language standard itself. Yes, I know CLTL2 is over a thousand pages long, but the one thing about programming languages that always bothers me is undefined behavior. Sadly, even Common Lisp has undefined behavior; Paul Graham's book On Lisp actually relies on undefined behavior being implemented in a particular way e.g. using setq on an unbound variable.
Good documentation should not leave anything undefined; good documentation should leave no questions about the semantics of a system/API/language. Given source code and documentation, it should be possible (perhaps difficult, but possible) for a person to figure out what will happen if the program is run.
Great story. Unfortunately, the API documentation and tutorial writing guilds went extinct decades ago and has never been able to return to Lispland. :)
Here's a racket guide, which provides detailed documentation for every facet of the language: http://docs.racket-lang.org/
Earlier quoted context omitted.
> faster compiled languages Lisp is a compiled language. For that matter, it's a damn fast one, too. The Lisp implementation of PCREs are actually faster than Perl's, by some benchmarks. I don't want to start a tangent about benchmarks and their relevance, but it's clear that Lisp performance isn't a limiting factor.
C is still faster at common tasks and back then, code from readily available C and Pascal compilers was much faster than CMUCL or ELISP (both had a bytecode interpreter only AFAIR). My point is that in the 80s and 90s, computers were much slower and a factor of 2 was a big deal then, especially for professional developers who had to write well-performing applications, though nowdays a good language is "fast enough" i…