Comments for Three of Coins http://www.3ofcoins.net Just another WordPress weblog Tue, 08 Nov 2011 22:21:22 +0000 hourly 1 http://wordpress.org/?v=3.3 Comment on Common Lisp, Clojure, and seriousness. by Dude http://www.3ofcoins.net/2009/01/30/common-lisp-clojure-and-seriousness/comment-page-1/#comment-45634 Dude Tue, 08 Nov 2011 22:21:22 +0000 http://www.3ofcoins.net/?p=78#comment-45634 Clojure is optimized for the slick one-page example. The basic idea is "Let's create a Lisp-like language, but one which is a champion in programming language duels where the contest revolves around solving trivial tasks in half a page of code. A key requirement is beat functional languages using identical approaches." Clojure is good for Lisp because most Blub programmers and their managers only understand programming language contests based on solving a task in a page of code. Go Clojure! Clojure is optimized for the slick one-page example. The basic idea is “Let’s create a Lisp-like language, but one which is a champion in programming language duels where the contest revolves around solving trivial tasks in half a page of code. A key requirement is beat functional languages using identical approaches.”

Clojure is good for Lisp because most Blub programmers and their managers only understand programming language contests based on solving a task in a page of code.

Go Clojure!

]]> Comment on Yaclml in pictures, part II: Templating by Anton Vodonsov http://www.3ofcoins.net/2010/01/21/yaclml-in-pictures-part-ii-templating/comment-page-1/#comment-36110 Anton Vodonsov Sat, 13 Aug 2011 02:47:24 +0000 http://www.3ofcoins.net/?p=94#comment-36110 Hello Maciej. Have you ever used google closure-templates (or it's lisp implementation, cl-closure-templates)? Can you say, is closure-templates templating solution better or not that TAL? Best regards, - Anton Hello Maciej.

Have you ever used google closure-templates (or it’s lisp implementation, cl-closure-templates)? Can you say, is closure-templates templating solution better or not that TAL?

Best regards,
- Anton

]]> Comment on Common Lisp, Clojure, and seriousness. by Michael http://www.3ofcoins.net/2009/01/30/common-lisp-clojure-and-seriousness/comment-page-1/#comment-28371 Michael Thu, 14 Apr 2011 00:42:26 +0000 http://www.3ofcoins.net/?p=78#comment-28371 I'm aware the article is two years old. But it probably gets a lot of hits still. if you search "clojure vs. common lisp" on Google, it usually comes up in the top 5 or 6 results, so I imagine it will continue to be read frequently. I think characterizing Clojure as "sugar coating" over Java is really not accurate. Most of Clojure is written in Clojure, including its data structures such as hash maps, vectors, and lists. These are not Java's hash maps, vectors, or lists. They are new ones that were written in Clojure. Also keep in mind that Clojure supports first class functions and software transactional memory--both things that you really can't do in Java code without resorting to really deep black magic with the reflection and introspection APIs. As far as elegance, I think that is debatable as well. Clojure is somewhat more "functionally pure" than CL. And being a lisp-1, I think it's possible to write more elegant code in clojure since you don't have to use (funcall). Clojure's support for STM also makes it possible to write some very elegant code. Of course, elegance is largely a matter of personal taste. And we aren't likely to shed any new light on the lisp-1 vs. lisp-2 debate. But really, I think it's unfair to call Clojure syntactic sugar for Java, given that Clojure can do a lot of things that most mere mortals wouldn't even attempt to do in Java. I’m aware the article is two years old. But it probably gets a lot of hits still. if you search “clojure vs. common lisp” on Google, it usually comes up in the top 5 or 6 results, so I imagine it will continue to be read frequently.

I think characterizing Clojure as “sugar coating” over Java is really not accurate. Most of Clojure is written in Clojure, including its data structures such as hash maps, vectors, and lists. These are not Java’s hash maps, vectors, or lists. They are new ones that were written in Clojure. Also keep in mind that Clojure supports first class functions and software transactional memory–both things that you really can’t do in Java code without resorting to really deep black magic with the reflection and introspection APIs.

As far as elegance, I think that is debatable as well. Clojure is somewhat more “functionally pure” than CL. And being a lisp-1, I think it’s possible to write more elegant code in clojure since you don’t have to use (funcall). Clojure’s support for STM also makes it possible to write some very elegant code.

Of course, elegance is largely a matter of personal taste. And we aren’t likely to shed any new light on the lisp-1 vs. lisp-2 debate.

But really, I think it’s unfair to call Clojure syntactic sugar for Java, given that Clojure can do a lot of things that most mere mortals wouldn’t even attempt to do in Java.

]]> Comment on Common Lisp, Clojure, and seriousness. by Maciej http://www.3ofcoins.net/2009/01/30/common-lisp-clojure-and-seriousness/comment-page-1/#comment-28361 Maciej Wed, 13 Apr 2011 19:02:52 +0000 http://www.3ofcoins.net/?p=78#comment-28361 This article is over two years old, and while I still hold some points expressed here (having a standard is good; being implementation defined is bad and risky; piggybacking on somebody else's standard and claiming to be a separate tool doesn't seem right; etc), I admit I've overtrolled here a bit. Also, Clojure has matured a lot over these two years: it is (at least partially, I'm not sure) self-hosted and seems not to be as implementation-defined as it used to be. Michael: your points are completely valid. Clojure is a good, useful and every month more mature tool. Large part of its usefulness comes from it being defined in terms of a different tool; this is why I consider it a "toy language" (it's an unfortunate name, but let's stick with it): it does not define its own space, but it is merely a sugar coating over JVM the VM, Java's runtime libraries and APIs. JVM as a platform is fine; dependence on Java's runtime libraries, while it boosts immediate usefulness, seems to make Clojure just a nice frontend. I don't argue whether it's good or bad: at this moment, in terms of real-world productivity, Clojure is probably way more useful than CL. I was concerned about theoretical stuff like elegance, self-containedness, self-sustainability, etc. I was writing not from engineer's point of view, but from computer science student's point of view. From engineers point of view (especially now, two years ahead), Clojure seems a better tool to use in most cases; to a CS student, it seemed underspecified, not really defined, piggybacking on other tools and pulling its usefulness from their popularity. Immediately useful - maybe, but not nearly as elegant, independent and complete as CL. Engineer's toy. Now - two years later and no longer a student for most of that time - I admit that my point of view had its flaws, and on top of that I have chosen quite inflammable and unfortunate wording. In real life and real work - right, Clojure is more useful, even if it's not as beautiful and independent as CL. This article is over two years old, and while I still hold some points expressed here (having a standard is good; being implementation defined is bad and risky; piggybacking on somebody else’s standard and claiming to be a separate tool doesn’t seem right; etc), I admit I’ve overtrolled here a bit. Also, Clojure has matured a lot over these two years: it is (at least partially, I’m not sure) self-hosted and seems not to be as implementation-defined as it used to be.
Michael: your points are completely valid. Clojure is a good, useful and every month more mature tool. Large part of its usefulness comes from it being defined in terms of a different tool; this is why I consider it a “toy language” (it’s an unfortunate name, but let’s stick with it): it does not define its own space, but it is merely a sugar coating over JVM the VM, Java’s runtime libraries and APIs. JVM as a platform is fine; dependence on Java’s runtime libraries, while it boosts immediate usefulness, seems to make Clojure just a nice frontend. I don’t argue whether it’s good or bad: at this moment, in terms of real-world productivity, Clojure is probably way more useful than CL. I was concerned about theoretical stuff like elegance, self-containedness, self-sustainability, etc.
I was writing not from engineer’s point of view, but from computer science student’s point of view. From engineers point of view (especially now, two years ahead), Clojure seems a better tool to use in most cases; to a CS student, it seemed underspecified, not really defined, piggybacking on other tools and pulling its usefulness from their popularity. Immediately useful – maybe, but not nearly as elegant, independent and complete as CL. Engineer’s toy.
Now – two years later and no longer a student for most of that time – I admit that my point of view had its flaws, and on top of that I have chosen quite inflammable and unfortunate wording. In real life and real work – right, Clojure is more useful, even if it’s not as beautiful and independent as CL.

]]> Comment on Common Lisp, Clojure, and seriousness. by Michael http://www.3ofcoins.net/2009/01/30/common-lisp-clojure-and-seriousness/comment-page-1/#comment-28227 Michael Mon, 11 Apr 2011 02:30:27 +0000 http://www.3ofcoins.net/?p=78#comment-28227 One more issue I forgot to mention. I think your concern about whether clojure will still work on the next release of the JVM is unfounded. At least unfounded as the concern that your CL compiler, or GCC won't work on Intel's next processor is. Both intel, and Sun / Oracle have made commitments to guarantee backward compatibility. So if you are concerned about clojure not working on the next version of the JVM, you also have to raise the same concerns about Intel breaking backward compatibility with their next CPU. With a CL compiler, the problem is even more insidious. Will your CL compiler still work on the next version of Linux? Especially if the Linux APIs have changed? With Clojure, as long as there is a compatible JVM for any given platform, Clojure will work. No matter how much the underlying platform changes. So again, I think when it comes to future-proofing your investment, once again, Clojure comes out on top. I'm not sure how you can claim, given everything I have pointed out, that Clojure is a toy. It's clearly a serious language that is getting serious attention in the enterprise environment. And thats something that quite frankly, CL has largely failed to do. One more issue I forgot to mention. I think your concern about whether clojure will still work on the next release of the JVM is unfounded. At least unfounded as the concern that your CL compiler, or GCC won’t work on Intel’s next processor is. Both intel, and Sun / Oracle have made commitments to guarantee backward compatibility. So if you are concerned about clojure not working on the next version of the JVM, you also have to raise the same concerns about Intel breaking backward compatibility with their next CPU.

With a CL compiler, the problem is even more insidious. Will your CL compiler still work on the next version of Linux? Especially if the Linux APIs have changed? With Clojure, as long as there is a compatible JVM for any given platform, Clojure will work. No matter how much the underlying platform changes.

So again, I think when it comes to future-proofing your investment, once again, Clojure comes out on top.

I’m not sure how you can claim, given everything I have pointed out, that Clojure is a toy. It’s clearly a serious language that is getting serious attention in the enterprise environment. And thats something that quite frankly, CL has largely failed to do.

]]> Comment on Common Lisp, Clojure, and seriousness. by Michael http://www.3ofcoins.net/2009/01/30/common-lisp-clojure-and-seriousness/comment-page-1/#comment-28224 Michael Mon, 11 Apr 2011 01:28:29 +0000 http://www.3ofcoins.net/?p=78#comment-28224 I realize this is old, but it came up at the top of a Google search. So here goes. First, I think your definition of "serious" language is somewhat flawed, and I think you place too much value on having a standard. Sure, CL has an ANSI standard. But it leaves so much undefined that there are still serious incompatibilities between the different CL implementations, and no guarantee code you develop for one will work in another. For example, the SBCL socket API, and the CLISP socket API, are very different. This has resulted in having to create compatibility layers such as usocket in order to write portable socket code in CL. Clojure, on the other hand takes advantage of the Java socket API. And the Java socket API is the same on all Java implementations running on all platforms. So whether you are using Sun Java. OpenJDK, IBM Java, or GCJ, you can be sure that the socket API will be the same on all of those platforms. So even though CL has a standard, Clojure still comes out ahead as far as guaranteeing portability. I also think you are greatly underestimating the value of Clojure being built on the JVM. The very fact that it is built on the JVM and can leverage existing Java code bases is what gives it a very good chance of becoming a "serious" language. On the other hand, many of the languages that have ANSI standards are basically academic toys that are difficult to use in the real world because of their inability to integrate with existing systems, as well as their lack of useful libraries to solve common day to day problems. When talking about Java, it's important to distinguish between Java the platform, and Java the language. Java the platform is still very powerful, flexible, and offers a lot of advantages. Java the language, on the other hand, has run its course except for systems programming. It was great for it's time. But by modern dynamic language standards, it's verbose, very complicated, and no one really wants to write new code in it. But there are billions of lines of Java infrastructure already in place. Rewriting all of it would both be cost prohibitive, and time prohibitive. And this is where Clojure comes in, and why it is so powerful. With Clojure, I get a modern lisp that gives me all the benefits of functional programming that I can write new code in. That new code can integrate seamlessly into my existing Java infrastructure. And I'd say that makes Clojure a serious language ready to real work. Not a "toy". I've got nothing against CL. But lets face it. It's rather difficult to use CL in the real world. It doesn't play nice with existing infrastructures built on Java or .NET. Despite having a standard, the standard is largely incomplete; and so different implementations are deeply fragmented anyway and often incompatible when it comes to things like sockets (as I mentioned above). And then there are the deployment issues. Sure I can write a a Web app in CL, but there is no standard way to deploy it. There are several CL Web servers out there, but once again, they aren't compatible with each other as far as how you are expected to write your code. Clojure wins here as well, as Web apps written in Clojure can be deployed under any standards compliant Java Servlet container. Again, I have nothing against CL. but when it comes down to it, I really think Clojure is going to be the lisp that gets taken seriously--specifically because of it's close relationship with the JVM (and now with the CLR). I realize this is old, but it came up at the top of a Google search. So here goes.

First, I think your definition of “serious” language is somewhat flawed, and I think you place too much value on having a standard. Sure, CL has an ANSI standard. But it leaves so much undefined that there are still serious incompatibilities between the different CL implementations, and no guarantee code you develop for one will work in another. For example, the SBCL socket API, and the CLISP socket API, are very different. This has resulted in having to create compatibility layers such as usocket in order to write portable socket code in CL.

Clojure, on the other hand takes advantage of the Java socket API. And the Java socket API is the same on all Java implementations running on all platforms. So whether you are using Sun Java. OpenJDK, IBM Java, or GCJ, you can be sure that the socket API will be the same on all of those platforms. So even though CL has a standard, Clojure still comes out ahead as far as guaranteeing portability.

I also think you are greatly underestimating the value of Clojure being built on the JVM. The very fact that it is built on the JVM and can leverage existing Java code bases is what gives it a very good chance of becoming a “serious” language. On the other hand, many of the languages that have ANSI standards are basically academic toys that are difficult to use in the real world because of their inability to integrate with existing systems, as well as their lack of useful libraries to solve common day to day problems.

When talking about Java, it’s important to distinguish between Java the platform, and Java the language. Java the platform is still very powerful, flexible, and offers a lot of advantages.

Java the language, on the other hand, has run its course except for systems programming. It was great for it’s time. But by modern dynamic language standards, it’s verbose, very complicated, and no one really wants to write new code in it. But there are billions of lines of Java infrastructure already in place. Rewriting all of it would both be cost prohibitive, and time prohibitive.

And this is where Clojure comes in, and why it is so powerful. With Clojure, I get a modern lisp that gives me all the benefits of functional programming that I can write new code in. That new code can integrate seamlessly into my existing Java infrastructure. And I’d say that makes Clojure a serious language ready to real work. Not a “toy”.

I’ve got nothing against CL. But lets face it. It’s rather difficult to use CL in the real world. It doesn’t play nice with existing infrastructures built on Java or .NET. Despite having a standard, the standard is largely incomplete; and so different implementations are deeply fragmented anyway and often incompatible when it comes to things like sockets (as I mentioned above). And then there are the deployment issues. Sure I can write a a Web app in CL, but there is no standard way to deploy it. There are several CL Web servers out there, but once again, they aren’t compatible with each other as far as how you are expected to write your code. Clojure wins here as well, as Web apps written in Clojure can be deployed under any standards compliant Java Servlet container.

Again, I have nothing against CL. but when it comes down to it, I really think Clojure is going to be the lisp that gets taken seriously–specifically because of it’s close relationship with the JVM (and now with the CLR).

]]> Comment on Darcs vs Git: mathematician versus engineer by michalpabis http://www.3ofcoins.net/2008/12/16/darcs-vs-git-mathematician-versus-engineer/comment-page-1/#comment-17224 michalpabis Wed, 29 Sep 2010 22:10:26 +0000 http://www.3ofcoins.net/?p=62#comment-17224 Info from end of year 2010 - check out darcs now, it improved alot. Info from end of year 2010 – check out darcs now, it improved alot.

]]> Comment on Common Lisp, Clojure, and seriousness. by Does anyone still think of Clojure as a toy language? | Smash Company http://www.3ofcoins.net/2009/01/30/common-lisp-clojure-and-seriousness/comment-page-1/#comment-15989 Does anyone still think of Clojure as a toy language? | Smash Company Thu, 02 Sep 2010 16:54:01 +0000 http://www.3ofcoins.net/?p=78#comment-15989 [...] looking for some Clojure info, I stumbled on this old 3 Coins post, from early 2009: Brian Carper described a few days ago, how Clojure is better (for him) than [...] [...] looking for some Clojure info, I stumbled on this old 3 Coins post, from early 2009: Brian Carper described a few days ago, how Clojure is better (for him) than [...]

]]> Comment on Yaclml in pictures, part II: Templating by Felipe D. http://www.3ofcoins.net/2010/01/21/yaclml-in-pictures-part-ii-templating/comment-page-1/#comment-8806 Felipe D. Wed, 27 Jan 2010 15:49:27 +0000 http://www.3ofcoins.net/?p=94#comment-8806 Thanks for posting this! I had no idea how to even approach TAL since the wiki page was pretty hard to follow but now it makes sense. This certainly opens up a few more possibilities for creating web apps with (or without) UCW. Thanks for posting this! I had no idea how to even approach TAL since the wiki page was pretty hard to follow but now it makes sense.

This certainly opens up a few more possibilities for creating web apps with (or without) UCW.

]]> Comment on Common Lisp, Clojure, and seriousness. by Edward Tate http://www.3ofcoins.net/2009/01/30/common-lisp-clojure-and-seriousness/comment-page-1/#comment-8754 Edward Tate Mon, 25 Jan 2010 14:34:20 +0000 http://www.3ofcoins.net/?p=78#comment-8754 As someone who uses Common Lisp to put grub on the table, I would say that using Lisp to do serious work works well. And I actually like CFFI. :) Boy am I glad to have left the C++ / C# / Java / Python etc world behind. I think the community that drifts from CL towards Clojure are those that deeply appreciate the JVM. Personally, I would have preferred Richs efforts to have taken place in SBCL, or one of the existing CL implementations. It definitely would have improved the state of Lisp VMs / Lisp libraries. Paul Graham also could have gone there - but I suppose his changes are purely syntactical anyway. Its funny because five years ago I had a lecturer who was addicted to C#, and when we spoke about Lisp he called it a Toy LanguageTM. His next question, which pushed his previous statement into the land of questionability, was: "But does it support interfaces?". As someone who uses Common Lisp to put grub on the table, I would say that using Lisp to do serious work works well. And I actually like CFFI. :) Boy am I glad to have left the C++ / C# / Java / Python etc world behind.

I think the community that drifts from CL towards Clojure are those that deeply appreciate the JVM. Personally, I would have preferred Richs efforts to have taken place in SBCL, or one of the existing CL implementations. It definitely would have improved the state of Lisp VMs / Lisp libraries. Paul Graham also could have gone there – but I suppose his changes are purely syntactical anyway.

Its funny because five years ago I had a lecturer who was addicted to C#, and when we spoke about Lisp he called it a Toy LanguageTM. His next question, which pushed his previous statement into the land of questionability, was: “But does it support interfaces?”.

]]>