(λove (print (eval (read))))
readevalprintlove.fogus.me
readevalprintlove.fogus.me
I like writing about Lisp[1], and have been so far as to write blog posts ranging from why parentheses are a good thing to what kinds of data types Common Lisp has. I think there is still a place for writing about Lisp, but I don't think this e-zine accomplished the task to make it interesting.
Lisp unfortunately attracts a lot of fluff writing. Writing about how wonderful, deep, rich, or sophisticated it is. Writing about how it completely blows one's mind and takes you to this baroque, fluid land of programming literacy. I must admit that I've even been sucked into the vortex at a point in my Lisp career.
Then there are particular topics that get rehashed over and over again: what makes a Lisp? which is the best Lisp? which is the most practical? lisp-1 vs. lisp-2? was r6rs a failure? why are macros so great? why does Lisp subsume every programming language ever?
I found in this e-zine—whose title I can't repeat without bloating the paragraphs I write—that I didn't really gain anything after reading it all. What did I learn about T? I just learned that it was some language with interesting concepts, backed up with a paltry offering of examples. What did I learn about Apple? To me, it seemed like an opinion: Since Apple isn't doing wacky Lisp things, it no longer is catering to those with ideas. (This is something I disagree with.)
Regarding topics, I also found this e-zine to be somewhat haphazard in its arrangement. Maybe it's just the visual layout, but the topics didn't really flow, and it read more like a long blog post with randomly selected topics interjected with philosophical ideas about categorization.
I have a hard time really seeing, after reading, who this e-zine is for. It doesn't seem like it'd interest the general programming enthusiast, because it's just about a class of languages that few people actually use. It constantly shows code and uses jargon that the general programmer probably isn't accustomed with. It barely seems to appeal to veteran Lisp programmers because there's little depth and lots of the aforementioned fluff. The only group I can think it appeals to are people who have casually brushed next to Lisp at a previous time and wish to be re-injected with a shot of apparent beauty and mysticism they once saw, but never had time time or patience to fully reach.
My suggestion for future articles: Instead of trying to talk about all Lisps all the time, and talk about beaten-to-death topics that pop up on Usenet everyday, talk about something more technical and be comprehensive. What is something really interesting about Common Lisp? Though not exactly in the format I'd have for a magazine article, I wrote about "linear random access sequences" in Lisp here:
http://symbo1ics.com/blog/?p=1845
What about an overview of how the object system in T works? How about examples of how Lisp has solved problems in the industry that people don't know about (i.e., people know about ITA, the space probe, Jak & Dexter game, etc. because they're the examples that continue to propagate)?
How about where Lisp falls short? Lisp is a language that was ahead of its time, but there are language features now that seem beyond Lisp's grasp. Where has it failed?
All in all, I was somewhat disappointed, especially given the well qualified and articulate author. I think there's potential, but I don't think Read-Eval-Print-Love has successfully converged to what it should or could be.
I do wish Code Quarterly[2] was successful. Fogus even seemed to contribute to it with an interview with Rich Hickey. But, as outlined here[3], there wasn't enough motivation from the writers to make it successful.
[1] http://symbo1ics.com/blog/?cat=10
[2] http://www.codequarterly.com/
[3] http://gigamonkeys.wordpress.com/2011/10/17/end-of-the-line-...
The interesting thing about putting things out into the world is that people feel compelled to have an opinion. The fact of the matter is that this only exists because it's something that I feel motivated to write about. I am under no contractual obligation to produce anything, so that it exists at all is the result of a labor of love. You're probably right that there is nothing ground-breaking here and that the same information is available elsewhere, but where? Two dozen blog posts here, a few dozen Usenet posts there, a few books over here and a few papers over there. The value that I'm attempting to bring is through curation -- value to myself and as a side-effect others. The information is free foremost and is created on my free time.
As an author I have very little control over my readers' expectations or desires. The topics that you list are definitely interesting, so I hope to see you one day write about them on your blog (which I like BTW). I think that if this newsletter does not meet your expectations then maybe you will not like future installments. I appreciate your constructive criticism, but if I am to write a newsletter then I should stand true to the topics and styles that I would like to read and hope there are others who feel the same.
Thanks for reading.
In the end, any piece may be dead to a reader, but writing without passion will almost certainly be stillborn.
A firearm that shoots books? Or did you by chance mean "canon"?
http://dictionary.reference.com/browse/canon : "the body of rules, principles, or standards accepted as axiomatic and universally binding in a field of study or art"
http://dictionary.reference.com/browse/cannon : "a mounted gun for firing heavy projectiles; a gun, howitzer, or mortar"
Did you mean pedants by chance?
http://dictionary.reference.com/browse/pedant : "a person who makes an excessive or inappropriate display of learning."
http://dictionary.reference.com/browse/pendant?s=t : "a hanging ornament, as an earring or the main piece suspended from a necklace."
Interested to hear your views, can you provide some examples?
Polymorphism: In Common Lisp, I can't really make efficient, generic data structures. In Haskell, I can, by making the data structure polymorphic. Haskell will know the types at compile time and can optimize accordingly. In CL, I must do ugly things like provide equality predicates to functions, as opposed to having them associated to the data structure itself. François René Rideau has been trying to patch this up by something called the "Lisp Interface Library".
Functional optimizations: In any Lisp, you typically need a special library for doing optimization of functional code. Deforestation and so on can only be done with special packages like reducers in Clojure or SERIES in Common Lisp. Again, they aren't broad enough to cover the language as a whole.
Immutable/persistent data structures: Clojure has this pretty covered. It is possible to implement these data structures in other Lisps, like Common Lisp, but they're not bound to be very efficient.
OS integration: Not much of a comment. For Common Lisp at least, the language was designed without POSIX or Windows in mind. So it has really weird pathname conventions, poor ways of targeting the user environment, a weird idea about files, etc.
Code organization and packaging at the language level: This is an issue with CL and Scheme. Lisp doesn't really have the concept of an explicit API, or modules of code. There's no concept of a compiled shared library. Code is almost always distributed and integrated by source.
...
The list goes on. You can implement lazy data structures in Lisp, but it's hard to really integrate them in the language. Lazy data structures provide tons of benefits, especially by moving the boundaries for abstraction, but there seems little hope to make this a part of Lisp.
A big problem is that even if some of the above concepts are implemented in various languages (and as I stated, some of them have), they're usually implemented as a part of a toy language (even if it's not intended to be a toy), and are never really integrated well with what exists. Because of this, I don't think it's fair to say Lisp has all of these features, even if there exists dialects of Lisp that implement some of them.
> Immutable/persistent data structures: Clojure has this pretty covered. It is possible to implement these data structures in other Lisps, like Common Lisp, but they're not bound to be very efficient.
You really should take a look at FSet[0]. Not only does it provide fairly efficient persistent implementations of functional datatypes -- not as fast as Clojure's, perhaps, but not bad -- but it allows you to associate your equality predicates with your datatypes rather than passing them to every operation explicitly. (In fact, FSet currently provides no way to pass the predicate explicitly. Some people, including Faré, think this is an unfortunate omission, but I've never needed to do that.)
FSet's solution to the equality "issue" is by having a generic function COMPARE which will return :LESS, :GREATER, and whatnot.
FSet goes to length describing the issues embedding immutable data structures in an inherently mutable language. Things like RENAME-PACKAGE screw up invariants that FSet expects.
Lastly, FSet admits that it isn't exactly performant, it's just good enough, which was the point I was trying to make.
Aside from a few gripes I have, it's a good library to use, especially in multithreaded environments where you don't want to deal with locking and whatnot.
I protest, though, that there's nothing about Common Lisp that makes FSet slower than Clojure. Rich Hickey used a very clever data structure called a Hash Array-Mapped Trie to implement Clojure sets and maps, and (I think) an Okasaki-style sequence implementation. FSet, in contrast, uses balanced binary trees for all these types. That's the source of the performance difference, not anything about CL.
What are your gripes about FSet?
`(defmethod insert ((heap heap)) ... )` is distinctly slower than `(defun insert-heap (heap) ... )` (even after as much tuning of SBCL as I could).
While I share your belief in the importance of type systems, I don't understand this remark.
I haven't used Shen (or Qi), but it's at the top of my list of interesting languages to try. As I understand, the optional type system is a core Shen feature. The syntax may be unlike other programming languages, but is taken directly from type theory. Can you go into more detail, perhaps contrasting with Haskell?
http://www.shenlanguage.org/learn-shen/types/types_sequent_c...
Let's say we see:
int add_two(int a, int b)
ensure_conforms_to(int) add_two(ensure_conforms_to(int, a), ensure_conforms_to(int, b))
And there is no reason that your editors, documentation browsers, code completion engines, syntax highlighters, debuggers, and every other part of your environment can't use it!
Shen seems to get that.
Why int? What about adding floats? complex numbers? rationals? quaternions? matrices? dimensional quantities? etc. etc. etc.
The larger point is that baked-in type system see the word "int" as a type, but what that's hiding is the higher abstraction: that what we're really doing is specifying a function which should be run when determining the validity of the program.
What exactly is the point of a type system? I think there are really two big ones: program verification and metadata tagging. To simplify, the former is why Haskellers love types, and the latter seems to be the main reason that F#'s type providers exist (and why C# programmers love creating lots of little types rather than using typeless object literals a la Ruby).
Intellisense is an incredibly seductive thing, and many programmers in the enterprise world would argue that any language that can't show you that little "box" after you press Ctrl+Space is dead on arrival.
But both of those things are a subset of the things you COULD do if the phases of compilation were in your control. Maybe you want a function that says "throw an error at compile time if someone uses this deprecated parameter on this API call", or maybe you'd like to have a function where if you call it with a hard-coded URL, the program fails at compile time if the URL can't be reached.
These are obviously a bit silly, but the point is that, to many of us, WHENEVER a compiler is doing something with our AST, that should be fully exposed and not a black box. Another example: why is Idris[1] its own language? Why isn't it just a Haskell library? Granted that also gets into programmable syntax and editor support thereof, but that's part of my larger point as well.
Sometimes you get type erasure, but for really interesting programs to arise (the kind that I'm sure Idris is aiming at, though I don't know for certain) you really want to operate in that blurry divide.
Enjoy.
(foo a b c) and it isn't quoted, we know that foo will be resolved and evaluated, so will a, b, and c, and then the objects to which a, b, and c resolved will be applied to the object to which foo was resolved.
So, if I then type (a foo b c), we get the same behavior with different object resolutions.
And that should work everywhere, all the time.
http://www.nhplace.com/kent/Papers/Technical-Issues.html
What I took away from it was that macros get more tricky to write when you have possible variable capture for functions, which we humans seem to be a little more blind to than for values.
Item 18 contains the compatibility concerns for existing code, which the guys writing the standard seemed to think critical to keep the various vendors on board.
I don't buy it, but I can understand the reasoning.
The execute bit comparison is especially specious. If I try to execute a non-executable file, it fails. It doesn't go look for an executable file with the same name. Same as if I try to invoke 0 in Clojure. e.g. (0)
He's right that the symbol resolution of the first entry has different rules but ignores the fact that the shell isn't very good at higher order commands. Which is probably okay for a shell but not much use for a modern programming language.
Finally, he's right that multiple namespaces are a good idea, but that's Accepted Truth these days. It's just that we think namespacing should be under the control of the dev, not dependent on the type of the variable.
Uh, no you cant:
$ ls ls
ls: cannot access ls: No such file or directory
$ cat cat
cat: cat: No such file or directory $ ls $(which ls)
$ cat $(which cat) ls /bin/ls
From the Lisp 1.5 manual (1962):
"In actual practice, LABEL is seldom used. It is usually more convenient to attach the name to the definition in a uniform manner... The fact that most functions are constants defined by the programmer, and not variables that are modified by the program, is not due to any weakness of the system. On the contrary, it indicates a richness of the system which we do not know how to exploit very well."
What I personally like is that you always know what are you referring to in a higher-order function call: a variable name or a function name. So it just removes the need for some additional intellectual effort of remembering this (i.e. #' is a nice annotation)
Truly, this is a Lisp article.
Also, what exactly do you mean by "homoiconic"? People love this word because it sounds fancy and marks them as someone who geeks out on programming, but the fact is that this word is, if not ambiguous, at least prone to abuse. Let me give a specific example.
The new language Julia has a macro system and Julia's designers claim that the language is homoiconic. Is it? It has a way to quote expressions such that
a + b
:(a + b)
head: call
args:
[0] symbol(:+)
[1] symbol(:a)
[2] symbol(:b)
type: any
{:call, {:+, :a, :b}, Any}
In any event, while you CAN write a Julia program using the literal syntax for the data structures that represent Julia programs, people usually don't do that.
So what does homoiconic mean? Does it mean that you can get to the data structure representing your code and then manipulate it at will? Or does it mean that PLUS the fact that programs in your language always take exactly the form of the data structure that represents that code?
If the former, then a lot of languages (including C# with its expression trees) can claim to be partially or fully homoiconic. If the latter, then the list is much smaller.
So would a homoiconic Haskell be a lisp? I think what you'd end up with after taking things far enough wouldn't be Haskell at all. It'd be a lisp with a REALLY good type system.
After all, things like monads and morphisms and applicative functors aren't Haskell, they're mathematics.
Yeah, the word is admittedly a bit problematic. If one wanted to be overly pedantic, any language with strings might be called homoiconic. The better answer is to ask how commonly-used are the data structures for storing the expressions. What makes Lisp so powerful is that these data structures are lists and lists are used all the time; this enables a large amount of code sharing between macros and regular functions.
Now this makes it very straightforward to evaluate the usefulness of Julia's claim of homoiconicity: how often would you expect to use the data structures Julia uses to represent its expression trees? If the answer is not very often, then the language suffers for it because you're going to have to write special-purpose code for macros instead of reusing the libraries you'd use anyway.
... But instead I think I'm more likely to take a look at that T manual.
Common Lisp is a little less straight-forward and a little more complex, so Racket is awesome for learning the patterns you'll use to program with.
I'm starting to move into Common Lisp now, because it has more useful tools and libraries available for making 'proper' programming easier.
"It might help to start off with some text"
HN comment text fades to gray
Flower abides
HN should always be a place where we can give feedback on web design.