Seriously, this is a great point. One of the big problems with a small community of programmers who all think of themselves as elite, is that tasks like documentation and tutorial writing go by the wayside. This comment should be a wake-up call to any smart and far-sighted individuals who want to promote a language.
Yep. They have time to draw elaborate cartoons, but not elaborate documentation! Funny how that works.
The author (Conrad Barski) wrote a book: Land of Lisp ...
Seriously, this is a great point. One of the big problems with a small community of programmers who all think of themselves as elite, is that tasks like documentation and tutorial writing go by the wayside. This comment should be a wake-up call to any smart and far-sighted individuals who want to promote a language.
Is there a open source Common Lisp library that you'd like to see better documented? Also, if you're (or anyone else is) interested in working on a Common Lisp environment tutorial, shoot me an email. I've been working on one but haven't launched it yet.
I would love to see cffi, opengl and one of the gtk binding libs have better documentation.
How is it that referential transparency (the ability to swap a reference with it's value: no hidden inputs) and homoiconicity (both the source and the resulting syntax tree sharing the same structure) are mutually exclusive? What homoiconicity offers is the macro system, the ability to operate on the syntax tree as a regular language data structure. The difference is a language like Haskell enforces referential trans…
"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:
Seriously, this is a great point. One of the big problems with a small community of programmers who all think of themselves as elite, is that tasks like documentation and tutorial writing go by the wayside. This comment should be a wake-up call to any smart and far-sighted individuals who want to promote a language.
Yep. They have time to draw elaborate cartoons, but not elaborate documentation! Funny how that works.
Is there a open source Common Lisp library that you'd like to see better documented? Also, if you're (or anyone else is) interested in working on a Common Lisp environment tutorial, shoot me an email. I've been working on one but haven't launched it yet.
I would love to see cffi, opengl and one of the gtk binding libs have better documentation.
The opengl bindings don't really need documentation, as they're automatically generated to mirror the C API. Really, if you want to know how to use `cl-opengl`, you memorize a simple naming convention and the rest is a matter of "how do I use OpenGL," not "how do I use cl-opengl?"
I'm missing something; how does LISP enable bug-free programs?
Did you click on any of the blue links in the comic? They contain articles on language features with sections: 'Synopsis', 'How it kills bugs', 'Explanation' and 'Weakness'.
Whoa, hopefully I'm not the only one who missed that. I thought it was just animated text, not a link.
Neither - I cannot measure how many times it gets clicked, since it's not my website, and I didn't really mean it in the satirical sense. I guess I just wanted to see how many points it collects. So far it has exceeded my wildest expectations, although that is mainly due to the content, not the title.
In the Explanation on Brevity Guild Micro Fighter, you use "i" as the variable, but the code snippet uses "n". I only found this because I was having fun following along! :)
> * No free implementations existed during a key period (80s, 90s) so no initial traction, no useful libraries and killer apps which would pull the whole ecosystem. Implementations didnt even exist for commodity hardware. Emacs LISP (OK, a limited dialect) was available and so was CMUCL (full implementation), which I believe was used for teaching in 1992 when I first got in contact with LISP at our uni ... Also, back…
> 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" if it's only half as fast as C.