pl patterns: Blub by Convention (In Defense of Arc)
Jeff
· 1 month ago
Checkout Clojure. In many ways I think it's done a better job of creating a next-gen Lisp than Arc has, and with the entire world of Java libraries at your disposal you get the best of both worlds.
Michał Kwiatkowski
· 1 month ago
I think putting all non-Arc Lisps into a single bag is oversimplification. That also includes Schemes, which may differ significantly. One prominent example is PLT, which allows you to use different language for each module you write. For example, you may have one module written in Typed Scheme and another in R5RS and both will be able to cooperate in a single application. Now that's the freedom in the usage of languages, don't you think?
From your previous posts I know that you're familiar with Clojure. Its naming conventions are pretty decent and the consistent use of sequences actually make a difference. Not to mention its concurrency story or Java integration. Do you really want to put this brilliant language "below" Arc?
The bottom line is that there's so much more to a programming language than its syntax. Arc, being a bunch of macros, is not a good (not event a decent) environment for building your applications in.
BTW, I wonder what happened to your post "What I Would Do Differently from Arc", which landed in my RSS reader, but is nowhere to be found on your blog. You wrote there one thing, which I believe is relevant in the context of today's post. You said that because Arc doesn't have an object system, programmers will be forced to reinvent something like CLOS. By the lack of object system Arc sets no convention, which gives more than enough possibility for implementations to diverge. Now suddenly you're back to square one, with such a basic issue like an object system.
The real issue here is that there is no One True Way(tm). Any convention, formal or not, will be OK for one person/team and not for another. It's just a fact of life, different people do things in different ways. We have a vast spectrum of languages and programming techniques to choose from and still, within each community, there is still much diversity. Look at Python with its "only one obvious way" philosophy - features are constantly added to the language, and lots of them overlapping, to support different ways people use the language.
I think diversity is a really good thing and putting languages on a linear "scale of power" is IMHO a bunch of crap.
Jonathan Tran
· 1 month ago
Thanks for the thoughts. All the comments for this have shown me that what I meant to say wasn't communicated very well. (The post you are referring to, I had written months ago, decided to post it, and then unposted it b/c I thought it was unworthy. Guess it already spread through the tubes, though.)
If I could redo this post, I would try to make it clear that what I meant was: (1) Many languages could be better than they are if they used different conventions; (2) it's damn-near impossible to go against the conventions; (3) conventions are difficult to change, more of a way of thinking of the community; (4) it's worthwhile to push good conventions into the core language/libraries, and if you do that, you're essentially making something new.
This really has little to do with Arc. Silly me for associating Arc with language design.
Michał Kwiatkowski
· 1 month ago
Now I understand your point better, although still I can't fully agree. ;-)
Your first point ("Many languages could be better than they are if they used different conventions") sounds sensible, but I think a broader context is needed. Let's get back to Common Lisp, since you mentioned it. There is a good reason why names like mapcar or lambda are the part of Common Lisp. When the standard was emerging those were the names that were most sensible and known to Lisp programmers. Goal of Common Lisp was to set a common standard for different variants of Lisp implementations that were in use at that time. It succeeded, and its use of already established names was a part of that success.
Of course good 20 years ago may not be good today. I think this applies to Common Lisp, at least in some regards, although after reading "Practical Common Lisp" I would still argue Common Lisp is a great language and even after those years still beats more popular languages in some areas. Generic functions are great, Clojure leads the way with multimethods, while Java/Python/Ruby are all only single-dispatch. Conditions and restarts are still quite unique to Common Lisp, while the best other languages can do is to unwind the stack and die.
Regarding your second point ("it's damn-near impossible to go against the conventions") I'd say it is an exaggeration. A team of people, especially one enough forward-thinking to use a Lisp, can agree on any sensible convention and it doesn't necessarily have to be a convention shared by the given language community. Don't look at Python with its PEP8 and other coding style documents. Look at an even older language, like C. Is there a single convention for writing C? I guess not. GNU devs have their own way, Linux devs have another and other teams (especially those working on closed source apps) even more different. Each one of those conventions work for the people that use them and one isn't particularly "better" than the other.
Regarding points 3 and 4 I generally agree, but you don't have to go upstream to make something new. Sometimes a team-level (or organization-level) improvement will be more than enough and actually doable. All Lisps share this unique property that they can be customized - the language itself can be build bottom-up to support a better description of a problem you're trying to solve. There are many problems to be solved and thus the need for different languages and conventions. Getting back to your second point, I believe Lisps are especially well suited to going against the conventions. Syntactic abstractions allow you to do anything with the language and bend it to your needs. The magic here is that Lisps allow you to make your inventions look exactly the same as tools built into the language, so the barrier to entry is really low.
Anyway, thanks for the thought-provoking post! :-)
Jonathan Tran
· 1 month ago
My pleasure! If it was thought-provoking, then I have succeeded.
All Comments
From your previous posts I know that you're familiar with Clojure. Its naming conventions are pretty decent and the consistent use of sequences actually make a difference. Not to mention its concurrency story or Java integration. Do you really want to put this brilliant language "below" Arc?
The bottom line is that there's so much more to a programming language than its syntax. Arc, being a bunch of macros, is not a good (not event a decent) environment for building your applications in.
BTW, I wonder what happened to your post "What I Would Do Differently from Arc", which landed in my RSS reader, but is nowhere to be found on your blog. You wrote there one thing, which I believe is relevant in the context of today's post. You said that because Arc doesn't have an object system, programmers will be forced to reinvent something like CLOS. By the lack of object system Arc sets no convention, which gives more than enough possibility for implementations to diverge. Now suddenly you're back to square one, with such a basic issue like an object system.
The real issue here is that there is no One True Way(tm). Any convention, formal or not, will be OK for one person/team and not for another. It's just a fact of life, different people do things in different ways. We have a vast spectrum of languages and programming techniques to choose from and still, within each community, there is still much diversity. Look at Python with its "only one obvious way" philosophy - features are constantly added to the language, and lots of them overlapping, to support different ways people use the language.
I think diversity is a really good thing and putting languages on a linear "scale of power" is IMHO a bunch of crap.
If I could redo this post, I would try to make it clear that what I meant was: (1) Many languages could be better than they are if they used different conventions; (2) it's damn-near impossible to go against the conventions; (3) conventions are difficult to change, more of a way of thinking of the community; (4) it's worthwhile to push good conventions into the core language/libraries, and if you do that, you're essentially making something new.
This really has little to do with Arc. Silly me for associating Arc with language design.
Your first point ("Many languages could be better than they are if they used different conventions") sounds sensible, but I think a broader context is needed. Let's get back to Common Lisp, since you mentioned it. There is a good reason why names like mapcar or lambda are the part of Common Lisp. When the standard was emerging those were the names that were most sensible and known to Lisp programmers. Goal of Common Lisp was to set a common standard for different variants of Lisp implementations that were in use at that time. It succeeded, and its use of already established names was a part of that success.
Of course good 20 years ago may not be good today. I think this applies to Common Lisp, at least in some regards, although after reading "Practical Common Lisp" I would still argue Common Lisp is a great language and even after those years still beats more popular languages in some areas. Generic functions are great, Clojure leads the way with multimethods, while Java/Python/Ruby are all only single-dispatch. Conditions and restarts are still quite unique to Common Lisp, while the best other languages can do is to unwind the stack and die.
Regarding your second point ("it's damn-near impossible to go against the conventions") I'd say it is an exaggeration. A team of people, especially one enough forward-thinking to use a Lisp, can agree on any sensible convention and it doesn't necessarily have to be a convention shared by the given language community. Don't look at Python with its PEP8 and other coding style documents. Look at an even older language, like C. Is there a single convention for writing C? I guess not. GNU devs have their own way, Linux devs have another and other teams (especially those working on closed source apps) even more different. Each one of those conventions work for the people that use them and one isn't particularly "better" than the other.
Regarding points 3 and 4 I generally agree, but you don't have to go upstream to make something new. Sometimes a team-level (or organization-level) improvement will be more than enough and actually doable. All Lisps share this unique property that they can be customized - the language itself can be build bottom-up to support a better description of a problem you're trying to solve. There are many problems to be solved and thus the need for different languages and conventions. Getting back to your second point, I believe Lisps are especially well suited to going against the conventions. Syntactic abstractions allow you to do anything with the language and bend it to your needs. The magic here is that Lisps allow you to make your inventions look exactly the same as tools built into the language, so the barrier to entry is really low.
Anyway, thanks for the thought-provoking post! :-)