Why Lisp Did Not and Never Will Gain Enough Traction(kresimirbojcic.com)
kresimirbojcic.com
Why Lisp Did Not and Never Will Gain Enough Traction
http://kresimirbojcic.com/2012/08/14/why-lisp-did-not-and-never-will-gain-enough-traction.html
11 comments
"Clojure basically obsoletes Ruby and Python" "Clojure is a uniform attack on everything of value in the Ruby, Python and Node.js world"
This kind of smugness[1] is one reason why Clojure will never take over the world. It seems to be some kind of unwritten rule that every Clojure evangelist has to knock another language in any post anywhere [2]. Ugh.
I am a great admirer of Rich Hickey (the man is a genius), and am happily using Clojure in my present project, but this kind of triumphalist rhetoric is a big turn off. I don't think Clojure "obsoletes" Ruby or Python, anymore than Haskell or Erlang "obsoletes" the various lisps.
[1] This attitude seems particularly endemic amongst people who've moved to Clojure from the early Ruby on Rails community, where sneering at alternative frameworks was part of the culture.
Rich Hickey, while justifiably proud of his language, as he should be, never makes silly statements like this.
[2] see http://news.ycombinator.com/item?id=4272186 for an embedded gratuitous swipe at Scala in an otherwise insightful post.
This kind of smugness[1] is one reason why Clojure will never take over the world. It seems to be some kind of unwritten rule that every Clojure evangelist has to knock another language in any post anywhere [2]. Ugh.
I am a great admirer of Rich Hickey (the man is a genius), and am happily using Clojure in my present project, but this kind of triumphalist rhetoric is a big turn off. I don't think Clojure "obsoletes" Ruby or Python, anymore than Haskell or Erlang "obsoletes" the various lisps.
[1] This attitude seems particularly endemic amongst people who've moved to Clojure from the early Ruby on Rails community, where sneering at alternative frameworks was part of the culture.
Rich Hickey, while justifiably proud of his language, as he should be, never makes silly statements like this.
[2] see http://news.ycombinator.com/item?id=4272186 for an embedded gratuitous swipe at Scala in an otherwise insightful post.
I am not going to be your proxy for every perceived irritant in the course of discussing lisp. Asking me to be this is unfair.
You can say I am some sort of hater and now it's Rails's turn, but I've been consistent with this even when I was a full time rails programmer [1]. You can find essays by me on the inadequacies of Rails dating back years now [2]. The very things I was complaining about in 2007 are now the glaring flaws in modern Rails. So I made the decision to strike out for tools that don't have a cultural bias against progress in areas I believe important.
So, if I am a Smug Lisp Weenie, then surely I am also a Smug Scala Weenie. And a Smug Erlang Weenie. And a Smug Haskell Weenie. And a Smug Ruby Weenie. And a Smug Hadoop Weenie. And a Smug C weenie... Because one thing I've made very clear is that I think attachment to tools is the problem. We should always aim to use the best tools at our disposal, and I think the place where Python and Ruby are the best tools are shrinking under the onslaught of the competition. Argument from familiarity is something I simply cannot bear to listen to anymore.
If believing this makes me smug then I guess I am smug.
[1] http://www.oreillynet.com/ruby/blog/2007/06/multicore_hardwa...
[2] http://dave.fayr.am/posts/2008-11-20-the-opposite-of-momentu...
You can say I am some sort of hater and now it's Rails's turn, but I've been consistent with this even when I was a full time rails programmer [1]. You can find essays by me on the inadequacies of Rails dating back years now [2]. The very things I was complaining about in 2007 are now the glaring flaws in modern Rails. So I made the decision to strike out for tools that don't have a cultural bias against progress in areas I believe important.
So, if I am a Smug Lisp Weenie, then surely I am also a Smug Scala Weenie. And a Smug Erlang Weenie. And a Smug Haskell Weenie. And a Smug Ruby Weenie. And a Smug Hadoop Weenie. And a Smug C weenie... Because one thing I've made very clear is that I think attachment to tools is the problem. We should always aim to use the best tools at our disposal, and I think the place where Python and Ruby are the best tools are shrinking under the onslaught of the competition. Argument from familiarity is something I simply cannot bear to listen to anymore.
If believing this makes me smug then I guess I am smug.
[1] http://www.oreillynet.com/ruby/blog/2007/06/multicore_hardwa...
[2] http://dave.fayr.am/posts/2008-11-20-the-opposite-of-momentu...
"You can say I am some sort of hater and now it's Rails's turn"
Oh but that's not what I said. I said that claims of Clojure "obsoleting" Ruby/Python reek of smugness once prevalent in RoR and Common Lisp communities, and do turn off intelligent people. You can like and evangelize Clojure without making such rabid claims, especially when they are unsupported by data or strong arguments.
"We should always aim to use the best tools at our disposal,"
This is a non controversial position. The "smugness" is in going beyond such sane positions and declaring Clojure to be some kind of uber Ruby/Python killer without any supporting data or arguments.
"and I think the place where Python and Ruby are the best tools are shrinking under the onslaught of the competition."
This is more dubious. Do you have any supporting data? What do you see as "competition" to Ruby or Python? Clojure? in terms of deployed systems, Clojure is barely a blip (wrt RoR, say). I know many intelligent devs using and liking Clojure, but also other intelligent devs using and liking Python and Ruby. I even know (horror!) people who know all three and don't always choose Clojure.
Also, it is pretty hard to characterize Clojure as an "onslaught" on Ruby in any fashion (afaik Rich Hickey doesn't have such an onslaught as part of his goals for Clojure development), or as an "obsoleting" language, which is a very strong claim. Strong claims require strong supporting evidence.
In fairness to you, you did say " I think that .. " which brings me to
"Argument from familiarity is something I simply cannot bear to listen to anymore."
Totally agreed. Now apply that to your Clojure evangelism/praise. ;-)
Fwiw I am working on a Clojure project, and quite like the language. It is extremely well designed and (given the limitations of the JVM) very elegant.
But I don't have a stake in proclaiming it to "obsolete" Ruby/Python etc - at least not without some very convincing arguments - certainly not just "argument from familiarity" ;-)
All that said, I gladly concede that Clojure is some kind of ultra uber language in your experience, in the interest of stopping this thread from expanding fruitlessly.
PS: Decent essays btw. Now apply the same critical eye to Clojure :)
Oh but that's not what I said. I said that claims of Clojure "obsoleting" Ruby/Python reek of smugness once prevalent in RoR and Common Lisp communities, and do turn off intelligent people. You can like and evangelize Clojure without making such rabid claims, especially when they are unsupported by data or strong arguments.
"We should always aim to use the best tools at our disposal,"
This is a non controversial position. The "smugness" is in going beyond such sane positions and declaring Clojure to be some kind of uber Ruby/Python killer without any supporting data or arguments.
"and I think the place where Python and Ruby are the best tools are shrinking under the onslaught of the competition."
This is more dubious. Do you have any supporting data? What do you see as "competition" to Ruby or Python? Clojure? in terms of deployed systems, Clojure is barely a blip (wrt RoR, say). I know many intelligent devs using and liking Clojure, but also other intelligent devs using and liking Python and Ruby. I even know (horror!) people who know all three and don't always choose Clojure.
Also, it is pretty hard to characterize Clojure as an "onslaught" on Ruby in any fashion (afaik Rich Hickey doesn't have such an onslaught as part of his goals for Clojure development), or as an "obsoleting" language, which is a very strong claim. Strong claims require strong supporting evidence.
In fairness to you, you did say " I think that .. " which brings me to
"Argument from familiarity is something I simply cannot bear to listen to anymore."
Totally agreed. Now apply that to your Clojure evangelism/praise. ;-)
Fwiw I am working on a Clojure project, and quite like the language. It is extremely well designed and (given the limitations of the JVM) very elegant.
But I don't have a stake in proclaiming it to "obsolete" Ruby/Python etc - at least not without some very convincing arguments - certainly not just "argument from familiarity" ;-)
All that said, I gladly concede that Clojure is some kind of ultra uber language in your experience, in the interest of stopping this thread from expanding fruitlessly.
PS: Decent essays btw. Now apply the same critical eye to Clojure :)
I've found the Clojure community at large to be well reasoned in general and very intelligent. KirinDave's posts may be a little hot, but I think it is a sign of growth for Clojure. Ruby/Rails also had (has? ;-) ) a problem with smugness as it was gathering rabid following. Let's hope that this is a sign that Clojure is also building up a gathering of all sorts of interesting characters :-)
> Oh but that's not what I said.
Actually, it is. Basically when someone says, "____ is smug," what they're really doing is making a soft, attitude based argument for dismissing the more substantive arguments. Same as calling someone a hater.
> You can like and evangelize Clojure without making such rabid claims, especially when they are unsupported by data or strong arguments.
I can support the arguments quite well. And I can make the same argument for Go, Scala, Erlang, and Dart. We simply haven't had the space or opportunity to really expound on it here, since the context is a post that attacks "lisp" with spurious complaints.
> Strong claims require strong supporting evidence.
This is true, but what you're doing is ignoring the context of the conversation after the fact to try and weaken my position. I can make a case for these claims, and in fact in many of my blog posts I have made a case for these claims. Saying I never have in this thread is a little disingenuous.
> I even know (horror!) people who know all three and don't always choose Clojure.
You then have the horror of knowing me, the person you have mischaracterized as a Clojure evangelist instead of a modern software tools evangelist.
> at least not without some very convincing arguments
Allow me to just list out Clojure's strong points with respect to Ruby, since that's close at hand. Because you keep acting like I an a Clojure fanatic, dedicated with laser-like precision to the cause of promoting Hickey's work, let me re-iterate: _I COULD DO THE SAME WITH A HALF-DOZEN OTHER TOOLKITS._
1. Ruby and Clojure are both dynamic langages with a variety of beyond-the-Java features but... a. Clojure's answer to the "expression problem" is safer, faster, and cleaner [1]. b. Clojure has explicitly modeled multi-methods, something that observations of the industry suggest would be useful for clarifying a lot of existing code [2]. c. Clojure can support functional programing and OO programming directly. It often ends up having "cleaner" (less punctuation and repetition) expressions of OO call stacks than its host language, Java. [3]
2. Clojure and Ruby both have rich collection libraries, but... a. Clojure's core data structure libraries are somewhat richer (e.g., better set support, some better numerics), and safer in multi-threaded use because of their persistent design. b. Clojure's libraries implement the same "pass in a block" pattern as Ruby, but with more universal names in most cases, and with more consistency (which is important due to the thrush combinators). c. When the standard persistent data structures cannot meet your performance needs, high performance mutable structures are available from the Java toolkit. Ruby usually has to appeal to C to get faster results, the binding process of which is fraught with peril even with 1.9 (and is excruciatingly difficult in 1.8 due to fundamental design mistakes).
3. Both languages support concurrency primitives but.... a. Ruby's concurrency primitives never allow for parallel processing except in a tiny minority of implementations, whereas in all but a tiny minority of implementations Clojure's primitives do. b. Ruby's concurrency primitives are basic, whereas Clojure not only offers the Java primitives (themselves ranging from basic atomic references to the contents of java.util.concurrent) but also offers a Software Transactional Memory implementation which emphasizes reasonable performance and ease of use.
4. Both communities value brevity and meta-programming, but... a. Clojure's half-hygenic macros with quasi-quoting provide an approachable way to make arbitrary syntax extensions to the language; in this Lisp is only challenged by other Lisps and perhaps the Haskell and ML world. b. Many similar abstractions like Sinatra vs. Compojure exist in the "Ruby and Clojure"-verse, but because of macros the Clojure side can always go further. In the context of the above points, Clojure almost always has a significant performance advantage, too.
5. Both languages have excellent deployment strategies... a. Ruby has a suite of integrated in-language tools and a lot of service vendors that directly support it for distributed software projects. b. Clojure is deployable almost anywhere Java is deployable, which is "almost almost" everywhere. c. Clojure has a mixed blessing in that it has access to ".war" and "uberjar" type deployments. These can be more confusing, but often eminently more easy for an operations (or devops) team.
I'll stop for now, but I want to re-iterate I could make cases against many popular languages for a variety of other languages when the situation warrants. For example, when correctness and ease of distributed processing is your goal, Erlang is unmatched.
[1] http://kirindave.tumblr.com/post/658770511/monkey-patching-g... for more on this.
[2] http://homepages.ecs.vuw.ac.nz/~alex/files/MuscheviciPotanin...
[3] http://java.ociweb.com/mark/clojure/article.html and grep for "noisy" for a casual treatment.
Actually, it is. Basically when someone says, "____ is smug," what they're really doing is making a soft, attitude based argument for dismissing the more substantive arguments. Same as calling someone a hater.
> You can like and evangelize Clojure without making such rabid claims, especially when they are unsupported by data or strong arguments.
I can support the arguments quite well. And I can make the same argument for Go, Scala, Erlang, and Dart. We simply haven't had the space or opportunity to really expound on it here, since the context is a post that attacks "lisp" with spurious complaints.
> Strong claims require strong supporting evidence.
This is true, but what you're doing is ignoring the context of the conversation after the fact to try and weaken my position. I can make a case for these claims, and in fact in many of my blog posts I have made a case for these claims. Saying I never have in this thread is a little disingenuous.
> I even know (horror!) people who know all three and don't always choose Clojure.
You then have the horror of knowing me, the person you have mischaracterized as a Clojure evangelist instead of a modern software tools evangelist.
> at least not without some very convincing arguments
Allow me to just list out Clojure's strong points with respect to Ruby, since that's close at hand. Because you keep acting like I an a Clojure fanatic, dedicated with laser-like precision to the cause of promoting Hickey's work, let me re-iterate: _I COULD DO THE SAME WITH A HALF-DOZEN OTHER TOOLKITS._
1. Ruby and Clojure are both dynamic langages with a variety of beyond-the-Java features but... a. Clojure's answer to the "expression problem" is safer, faster, and cleaner [1]. b. Clojure has explicitly modeled multi-methods, something that observations of the industry suggest would be useful for clarifying a lot of existing code [2]. c. Clojure can support functional programing and OO programming directly. It often ends up having "cleaner" (less punctuation and repetition) expressions of OO call stacks than its host language, Java. [3]
2. Clojure and Ruby both have rich collection libraries, but... a. Clojure's core data structure libraries are somewhat richer (e.g., better set support, some better numerics), and safer in multi-threaded use because of their persistent design. b. Clojure's libraries implement the same "pass in a block" pattern as Ruby, but with more universal names in most cases, and with more consistency (which is important due to the thrush combinators). c. When the standard persistent data structures cannot meet your performance needs, high performance mutable structures are available from the Java toolkit. Ruby usually has to appeal to C to get faster results, the binding process of which is fraught with peril even with 1.9 (and is excruciatingly difficult in 1.8 due to fundamental design mistakes).
3. Both languages support concurrency primitives but.... a. Ruby's concurrency primitives never allow for parallel processing except in a tiny minority of implementations, whereas in all but a tiny minority of implementations Clojure's primitives do. b. Ruby's concurrency primitives are basic, whereas Clojure not only offers the Java primitives (themselves ranging from basic atomic references to the contents of java.util.concurrent) but also offers a Software Transactional Memory implementation which emphasizes reasonable performance and ease of use.
4. Both communities value brevity and meta-programming, but... a. Clojure's half-hygenic macros with quasi-quoting provide an approachable way to make arbitrary syntax extensions to the language; in this Lisp is only challenged by other Lisps and perhaps the Haskell and ML world. b. Many similar abstractions like Sinatra vs. Compojure exist in the "Ruby and Clojure"-verse, but because of macros the Clojure side can always go further. In the context of the above points, Clojure almost always has a significant performance advantage, too.
5. Both languages have excellent deployment strategies... a. Ruby has a suite of integrated in-language tools and a lot of service vendors that directly support it for distributed software projects. b. Clojure is deployable almost anywhere Java is deployable, which is "almost almost" everywhere. c. Clojure has a mixed blessing in that it has access to ".war" and "uberjar" type deployments. These can be more confusing, but often eminently more easy for an operations (or devops) team.
I'll stop for now, but I want to re-iterate I could make cases against many popular languages for a variety of other languages when the situation warrants. For example, when correctness and ease of distributed processing is your goal, Erlang is unmatched.
[1] http://kirindave.tumblr.com/post/658770511/monkey-patching-g... for more on this.
[2] http://homepages.ecs.vuw.ac.nz/~alex/files/MuscheviciPotanin...
[3] http://java.ociweb.com/mark/clojure/article.html and grep for "noisy" for a casual treatment.
You make some decent arguments pro Clojure as compared to Ruby in this post.
Whether they actually prove anything like your conclusion, I'll leave to the judgement of the other readers.
(rest of this too long reply deleted as too snarky and not worthy of HN. Sorry guys)
Whether they actually prove anything like your conclusion, I'll leave to the judgement of the other readers.
(rest of this too long reply deleted as too snarky and not worthy of HN. Sorry guys)
I don't think these things are as random as you would like to believe. A large number of people tried for a large number of years to get lisp to take off. It isn't just bad luck that lisp didn't take off, and I think this article does a good job of outlining some reasons why.
I don't have to personally know every language. Languages grow in popularity by picking up users. It is clear lisp was and is very popular with certain segments of programmers, and ever caught on with others.
I don't have to personally know every language. Languages grow in popularity by picking up users. It is clear lisp was and is very popular with certain segments of programmers, and ever caught on with others.
> A large number of people tried for a large number of years to get lisp to take off.
You know, it was fairly popular for a time.
> I don't have to personally know every language. Languages grow in popularity by picking up users.
This is a tautology.
But let's pretend for a second what you meant to say was "Languages deserve the usership they gain in a sort of mindshare stock exchange." Then let's rewind 10 years and show you Clojure, Ruby, Java, and Javascript.
Can you ever imagine someone from 2002 picking Javascript over those alternatives? Someone sane, I mean. All praise to the pragmatism of the 'net, but Javascript's popularity is a function of its largely unrequested deployment and the failure of competing products (mostly due to artificial and non-technical business-enforced nonsense).
And yet here we are with Javascript being so popular that startups are raising $9m just to build frameworks in them. And yet by any reasonable metric Javascript is a "worse" language. The most highly-recommended starter book for javascript is "The Good Parts", because a whole lot of the language is just so bad it has to be ignored or worked around.
All we're really doing is appealing to popularity as a justification for using perceived popularity instead of real technical metrics. Which is–to some extent, anyways–fine and good; it certainly is traditional for people to do this. But let's not pretend we have access to some deeper insight while we're doing it.
You know, it was fairly popular for a time.
> I don't have to personally know every language. Languages grow in popularity by picking up users.
This is a tautology.
But let's pretend for a second what you meant to say was "Languages deserve the usership they gain in a sort of mindshare stock exchange." Then let's rewind 10 years and show you Clojure, Ruby, Java, and Javascript.
Can you ever imagine someone from 2002 picking Javascript over those alternatives? Someone sane, I mean. All praise to the pragmatism of the 'net, but Javascript's popularity is a function of its largely unrequested deployment and the failure of competing products (mostly due to artificial and non-technical business-enforced nonsense).
And yet here we are with Javascript being so popular that startups are raising $9m just to build frameworks in them. And yet by any reasonable metric Javascript is a "worse" language. The most highly-recommended starter book for javascript is "The Good Parts", because a whole lot of the language is just so bad it has to be ignored or worked around.
All we're really doing is appealing to popularity as a justification for using perceived popularity instead of real technical metrics. Which is–to some extent, anyways–fine and good; it certainly is traditional for people to do this. But let's not pretend we have access to some deeper insight while we're doing it.
Kirin, I think you pretty much hit the nail on the head. More of this stuff is due to luck and randomness than most people admit. We look back and find a few contributing factors, put them in a pile, and call it a theory, and believe we understand it.
But does that theory actually limit what we'd predict about the future? Does it retroactively predict all the past data that we've seen? As you pointed out, Lisp was quite popular for a bit.
What if we just said, Lisp isn't popular because it didn't get/stay lucky?
That anti-theory isn't quite as satisfying, but at least it doesn't pretend at knowledge that it doesn't have.
One really nice thing, in my opinion, about JavaScript programmers is that they don't sit around kvetching about why the wrong language won. We all know it was a fluke, but the fluke happened, and here we are, so you can either squawk about languages, or get real things done instead, and improve the tools and software that you have.
But does that theory actually limit what we'd predict about the future? Does it retroactively predict all the past data that we've seen? As you pointed out, Lisp was quite popular for a bit.
What if we just said, Lisp isn't popular because it didn't get/stay lucky?
That anti-theory isn't quite as satisfying, but at least it doesn't pretend at knowledge that it doesn't have.
One really nice thing, in my opinion, about JavaScript programmers is that they don't sit around kvetching about why the wrong language won. We all know it was a fluke, but the fluke happened, and here we are, so you can either squawk about languages, or get real things done instead, and improve the tools and software that you have.
> You know, [Lisp] was fairly popular for a time.
I'm afraid I have to dispute this. I'm about as dedicated a Lisper as you'll find -- learned it at the feet of Bernie Greenberg, Gerry Sussman, and David Moon in the late 1970s, and still use it when I get the chance. (Oh and I think my Symbolics machine still works, though I haven't fired it up in several years.) I was around during the time you're probably thinking of -- the AI bubble of the mid-1980s -- and even then, Lisp was the language a lot of people loved to hate, if they knew anything about it at all.
There was some interest in Lisp, to be sure, but I think "fairly popular" is putting it too strongly. It has always been a fringe language.
On another note -- it struck me the other day that if history had gone a little differently, we might be using Dylan instead of JavaScript. Oh well...
I'm afraid I have to dispute this. I'm about as dedicated a Lisper as you'll find -- learned it at the feet of Bernie Greenberg, Gerry Sussman, and David Moon in the late 1970s, and still use it when I get the chance. (Oh and I think my Symbolics machine still works, though I haven't fired it up in several years.) I was around during the time you're probably thinking of -- the AI bubble of the mid-1980s -- and even then, Lisp was the language a lot of people loved to hate, if they knew anything about it at all.
There was some interest in Lisp, to be sure, but I think "fairly popular" is putting it too strongly. It has always been a fringe language.
On another note -- it struck me the other day that if history had gone a little differently, we might be using Dylan instead of JavaScript. Oh well...
I grant it may not be quite as important in the industry, but got a lot of popularity in Academia, and some very modest inroads in the industry.
But you're right, it never had the singular popularity that Javascript, Java, or Python now enjoy. Sorry if in my haste I gave a false impression. Not what I meant to imply.
But you're right, it never had the singular popularity that Javascript, Java, or Python now enjoy. Sorry if in my haste I gave a false impression. Not what I meant to imply.
What's with the strawman? CJefferson didn't even mention Javascript.
Javascript is not the only language that surpassed Lisp in popularity, far from it.
Javascript is not the only language that surpassed Lisp in popularity, far from it.
It's more of a case-in-point than a straw man. Javascript is a great example of how unpredictable language popularity can be. The implicit argument, "Languages deserve the userbase they attract," is what's under attack.
One could use Javascript to argue that while midlevel languages tend to live in a sort of meritocracy that the very top level of languages always have some sort of immensely-powerful backer that they ride on. JS rode on top of Netscape at time when they were just that powerful. Java rode on Sun. C# and Objective C are there because of their powerful backers Microsoft and Apple.
> by and large Clojure basically obsoletes Ruby and Python
Care to qualify how Clojure obsoletes Ruby or Python? Both of those languages have great tools (rails, for example) that those in the Clojure communities have great respect for. As a Clojure and Ruby/Rails programmer, I share your enthusiasm for Clojure and lisp, but I can't see Clojure pushing either Ruby or Python out of the water any time soon.
Care to qualify how Clojure obsoletes Ruby or Python? Both of those languages have great tools (rails, for example) that those in the Clojure communities have great respect for. As a Clojure and Ruby/Rails programmer, I share your enthusiasm for Clojure and lisp, but I can't see Clojure pushing either Ruby or Python out of the water any time soon.
> Both of those languages have great tools (rails, for example)
I am surprised a Clojure programmer would have much respect for Rails. Its aggressive share-nothing approach leads to inconsistency, poor performance, awkward architectures, and over-reliance on external state management.
Perhaps one might admire it for making a bold claim about configuration vs. convention, but a valid criticism of Rails is that they went so far along the convention line in rebellion of bad tools like Spring that now they get accused of excessive magic.
> But I can't see Clojure pushing either Ruby or Python out of the water any time soon.
Like I said, success is fashion. But then, people said this to me about Git Vs. SVN after I gave a tech talk to a bunch of ruby folks about how git would take over the world. Two people left that talk and went on to found Github, so... "High Fashion."
Clojure has all the power of Ruby's dynamism, but with a better solution to the expression problem (protocols are namespace contained, allowing for monkey-patching that doesn't taint the world). It has access to a lot of fantastic high-performance libraries. It can safely deal with high degrees of parallelism with a degree of ease few environments can claim. It has a minimalist syntax which can compete with even the most terse and convention-driven ruby syntax (i.e., Compojure vs. Sinatra).
Similar complaints can be leveled at Python with less of a performance angle and more of a power angle; Clojure gives you access to many of those features that the python community feels are "too awkward" to use in the OO world, but are entirely natural in the Lisp world.
So yeah, every time someone writes a server in Node.js I think to myself, "You could have done it in Clojure and had just as much dynamism during development, just as easy a deployment story, and also perform easily an order magnitude faster under load, and you don't have to run like a scared child from parallelism."
I am surprised a Clojure programmer would have much respect for Rails. Its aggressive share-nothing approach leads to inconsistency, poor performance, awkward architectures, and over-reliance on external state management.
Perhaps one might admire it for making a bold claim about configuration vs. convention, but a valid criticism of Rails is that they went so far along the convention line in rebellion of bad tools like Spring that now they get accused of excessive magic.
> But I can't see Clojure pushing either Ruby or Python out of the water any time soon.
Like I said, success is fashion. But then, people said this to me about Git Vs. SVN after I gave a tech talk to a bunch of ruby folks about how git would take over the world. Two people left that talk and went on to found Github, so... "High Fashion."
Clojure has all the power of Ruby's dynamism, but with a better solution to the expression problem (protocols are namespace contained, allowing for monkey-patching that doesn't taint the world). It has access to a lot of fantastic high-performance libraries. It can safely deal with high degrees of parallelism with a degree of ease few environments can claim. It has a minimalist syntax which can compete with even the most terse and convention-driven ruby syntax (i.e., Compojure vs. Sinatra).
Similar complaints can be leveled at Python with less of a performance angle and more of a power angle; Clojure gives you access to many of those features that the python community feels are "too awkward" to use in the OO world, but are entirely natural in the Lisp world.
So yeah, every time someone writes a server in Node.js I think to myself, "You could have done it in Clojure and had just as much dynamism during development, just as easy a deployment story, and also perform easily an order magnitude faster under load, and you don't have to run like a scared child from parallelism."
> I am surprised a Clojure programmer would have much respect for Rails. Its aggressive share-nothing approach leads to inconsistency, poor performance, awkward architectures, and over-reliance on external state management.
When evaluating what tool to use for a project, there are many things to take into account other than the technical superiority of the tools. Relevance Inc, one of the strongest backer of Clojure, still make use of Rails for client projects. Rails' huge web dev ecosystem really made many common tasks as simple as importing a gem here and there and making a few method calls. It all comes down to the right tool for the right job. I'm interested in your take on how Rails' "share-nothing approach", awkward architectures etc.
> Clojure has all the power of Ruby's dynamism
Yes, and then some. Without repeating what you have already said, I would add efficient persistent data structure to the Clojure's list of awesome tricks. Doing functional programming in ruby and python, for example, will force you to trade value immutability with efficiency -- a penalty that one does not have to pay in Clojure.
Clojure is definitely gathering a lot of following. Like many others, I have picked it up, played with it, and never looked back.
But going back to what was said before. Yes, Clojure is awesome. No, Clojure is not obsoleting Ruby or Python any more than those obsoleted PHP, at least not now.
When evaluating what tool to use for a project, there are many things to take into account other than the technical superiority of the tools. Relevance Inc, one of the strongest backer of Clojure, still make use of Rails for client projects. Rails' huge web dev ecosystem really made many common tasks as simple as importing a gem here and there and making a few method calls. It all comes down to the right tool for the right job. I'm interested in your take on how Rails' "share-nothing approach", awkward architectures etc.
> Clojure has all the power of Ruby's dynamism
Yes, and then some. Without repeating what you have already said, I would add efficient persistent data structure to the Clojure's list of awesome tricks. Doing functional programming in ruby and python, for example, will force you to trade value immutability with efficiency -- a penalty that one does not have to pay in Clojure.
Clojure is definitely gathering a lot of following. Like many others, I have picked it up, played with it, and never looked back.
But going back to what was said before. Yes, Clojure is awesome. No, Clojure is not obsoleting Ruby or Python any more than those obsoleted PHP, at least not now.
I enjoyed programming in Clojure, but chose Python once more for a new project because w/ Clojure I don't know which projects are doing well. (Templating? Web app library? Postgresql?).
Wrt Python I know I'll do fine w/ Django, Flask, Jinja2, Psycopg2, Tornado...
Wrt Python I know I'll do fine w/ Django, Flask, Jinja2, Psycopg2, Tornado...
You have successfully gotten me to commit myself to looking into Clojure. Any good resources on learning/setting up, or should I go by the seat of my pants?
I find Clojure Programming (http://www.clojurebook.com/) to be an easy and practical introduction of the language. It often compare and contrast the Clojure way of doing things vs scripting languages like Ruby. After that, Joy of Clojure (http://joyofclojure.com/) dives deep into the whys of the language. Even though it was written against Clojure 1.2, it covers advanced topics like continuation passing style that were left out of Clojure Programming.
Cheers; this is going to be fun weekend :)
There are some great books out there, so pick a few and go to town.
[deleted]
Indeed, is there a Clojure equivalent of Scipy / Numpy / Matplotlib? These are invaluable for scientific computing.
Clojure arithmetic is fast enough if you add optional type annotations or otherwise take advantage of unboxed values. Ordinary calculation-intense code will be hundreds of times faster than in Python which might be enough in most cases.
If you need deeper support for vector math, scientific calculations, and the like then Incanter is probably what you want. It does all the complicated fast math stuff that always benefits from carefully planned and hand-tuned libraries.
If you need deeper support for vector math, scientific calculations, and the like then Incanter is probably what you want. It does all the complicated fast math stuff that always benefits from carefully planned and hand-tuned libraries.
To be clear... the benefit of Scipy / Numpy / Matplotlib that I'm alluding to is not (necessarily) runtime efficiency -- though, given that many of the linked libraries are standards (eg. LAPACK) and compiled C / Fortran, it is efficient for many operations.
The benefits to scientists are the developer efficiency (rapid prototyping), comprehensive libraries (scientific functions and plotting), interfaces similar to MatLab (eg. slicing), and its standing in the scientific community. It would sort of defeat the purpose to spend valuable research time to reinvent the wheel in another language -- though I would switch to a LISP variant in a heartbeat if there was comparably functionality.
The benefits to scientists are the developer efficiency (rapid prototyping), comprehensive libraries (scientific functions and plotting), interfaces similar to MatLab (eg. slicing), and its standing in the scientific community. It would sort of defeat the purpose to spend valuable research time to reinvent the wheel in another language -- though I would switch to a LISP variant in a heartbeat if there was comparably functionality.
Take a look at Incanter:
http://incanter.org/
http://incanter.org/
Why do you think it obsoletes Ruby&Python? It does target Ruby developer with borrowing some syntax, but the paradigm shift needed to jump on the "functional" train is quite big. It is nice language but it solves the problem that I don't have (performance&concurrency) so I am not all that eager to make a switch.
Everyone has performance and concurrency problems, eventually. What's great about Clojure is it gives you a path to ease into them.
Compare a Noir or even bare Compojure web service vs. a Sinatra web service. Is there really a big winner on brevity?
Compare a Noir or even bare Compojure web service vs. a Sinatra web service. Is there really a big winner on brevity?
I didn't try Compojure, but Noir seems succinct enough. It's just that functional programming doesn't blend well with my brain. For some problem it does, for some it doesn't. Since you mention performance, I am wondering and was not able to find any benchmarks in Noir vs. Sinatra for rest server for example.
Noir is a series of extensions on Compojure.
Anyways, I can give you bullshit benchmarks if you want. The numbers are sort of meaningless, the benchmark synthetic, the methodology poor but it's almost all against the server's favor.
Again, these numbers are not precise or useful. They're just there to put some flags in the ground for further exploration should you want to do a rigorous comparison.
Anyways, I can give you bullshit benchmarks if you want. The numbers are sort of meaningless, the benchmark synthetic, the methodology poor but it's almost all against the server's favor.
(GET "/hello" [] {:status 200 :body "Yo!"}))
~ > httperf --hog --server localhost --port 9999 --uri=/hello --num-conn 5000 --num-calls 1
...
Connection rate: 4769.8 conn/s (0.2 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 0.2 avg 0.2 max 3.8 median 0.5 stddev 0.1
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000
...
Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 0.2 transfer 0.0
Reply size [B]: header 98.0 content 3.0 footer 0.0 (total 101.0)
Reply status: 1xx=0 2xx=4999 3xx=0 4xx=0 5xx=0
Again, these numbers are not precise or useful. They're just there to put some flags in the ground for further exploration should you want to do a rigorous comparison.
Did I understand you correctly?
3ms vs. 0.2ms
So we might be talking about order of a magnitude here?
3ms vs. 0.2ms
So we might be talking about order of a magnitude here?
I agree, some algorithms didn't translate well from Python to Clojure. Also, I wouldn't want to process mp3 files in Clojure... but that is probably a good match for Java.
>Because to assume otherwise that would imply that everyone knows every language and some are uniform winners over others. Do you know every language you have rejected? Heck, do you even know the general characteristics of Lisp, or Haskell, or ML, or Anic, or Pike, or APL? No, and to really try and learn all of them would take a lot of time unless you're quite gifted. So the premiere and popular programming languages are as unpredictable as fashion.
That's quite a jump to an (invalid) conclusion.
Sure, no programmer has knows of all the languages he does not use or has rejected. But that doesn't mean that there is not a reason some language gain traction and get to be known by lots of programmers and others do not.
You seem to have the simple minded view that simply because I haven't heard of all the languages I don't use, it is random which ones I do use. That's not how it works.
It works by statistics and aggregates. I may not know language X I do not use, and I might know Y, which I do use. But this is not random, it's because of various forces at play, that made Y more widely known and X less so. For example, C provided raw speed with less memory use at a time it was very crucial, was easy to learn, had free/cheap compilers available, it was the language UNIX was written in, and it was simple enough. Oh, and portable. Those things got it traction. Lisp was mostly used in academia-AI, was slow at the time, compilers cost an arm and a leg and Lisp Machines even more so, and was associated with the "AI winter". Those are some reasons it did not do well.
That's quite a jump to an (invalid) conclusion.
Sure, no programmer has knows of all the languages he does not use or has rejected. But that doesn't mean that there is not a reason some language gain traction and get to be known by lots of programmers and others do not.
You seem to have the simple minded view that simply because I haven't heard of all the languages I don't use, it is random which ones I do use. That's not how it works.
It works by statistics and aggregates. I may not know language X I do not use, and I might know Y, which I do use. But this is not random, it's because of various forces at play, that made Y more widely known and X less so. For example, C provided raw speed with less memory use at a time it was very crucial, was easy to learn, had free/cheap compilers available, it was the language UNIX was written in, and it was simple enough. Oh, and portable. Those things got it traction. Lisp was mostly used in academia-AI, was slow at the time, compilers cost an arm and a leg and Lisp Machines even more so, and was associated with the "AI winter". Those are some reasons it did not do well.
> You seem to have the simple minded view that simply because I haven't heard of all the languages I don't use, it is random which ones I do use. That's not how it works.
But then:
> But this is not random, it's because of various forces at play, that made Y more widely known and X less so.
Where "various forces" is furious handwaving for the sheer randomness that made that set available to you. And let's say in a slightly different history that set is slightly different (but still contains your current choice), how do you know you would have ended up the same?
But perhaps I am being lamentably simple minded. Every decision you make is deliberate and justifiable.
But then:
> But this is not random, it's because of various forces at play, that made Y more widely known and X less so.
Where "various forces" is furious handwaving for the sheer randomness that made that set available to you. And let's say in a slightly different history that set is slightly different (but still contains your current choice), how do you know you would have ended up the same?
But perhaps I am being lamentably simple minded. Every decision you make is deliberate and justifiable.
>Where "various forces" is furious handwaving for the sheer randomness that made that set available to you.
You keep using that word, random. I don't think it means what you think it means.
A coin toss is random. C picking up for the stuff we did in the eighties is not random. Lisp losing traction after the AI winter is not random. Javascript gaining traction with the web is not random.
That the creation of C was effected by random events (the experiences of Ken Thompson, the position of AT&T, the decision to provide the source, etc), does not mean that the success was random.
The success was logical and repeatable given the needs of the era and how the language came to be. To put it in another way, if another language had taken the role of C in the industry at the time, it would have been pretty similar to C, and with external qualifications (availability of source, portability, etc) similar to C.
From this aspect, the (random) fact that it was C after all and not some other C-like language, doesn't matter at all. The language that would have filled C's role would have quacked like C, and that is the non-random, and substantial part.
Read the "Worse is better" for some background.
You keep using that word, random. I don't think it means what you think it means.
A coin toss is random. C picking up for the stuff we did in the eighties is not random. Lisp losing traction after the AI winter is not random. Javascript gaining traction with the web is not random.
That the creation of C was effected by random events (the experiences of Ken Thompson, the position of AT&T, the decision to provide the source, etc), does not mean that the success was random.
The success was logical and repeatable given the needs of the era and how the language came to be. To put it in another way, if another language had taken the role of C in the industry at the time, it would have been pretty similar to C, and with external qualifications (availability of source, portability, etc) similar to C.
From this aspect, the (random) fact that it was C after all and not some other C-like language, doesn't matter at all. The language that would have filled C's role would have quacked like C, and that is the non-random, and substantial part.
Read the "Worse is better" for some background.
> A coin toss is random. C picking up for the stuff we did in the eighties is not random. Lisp losing traction after the AI winter is not random. Javascript gaining traction with the web is not random.
Why is a coin toss any more random than a specific language gaining traction? It's called "(extreme) sensitivity to initial conditions." Many of which are neither observable nor predictable.
Why is a coin toss any more random than a specific language gaining traction? It's called "(extreme) sensitivity to initial conditions." Many of which are neither observable nor predictable.
>Why is a coin toss any more random than a specific language gaining traction? It's called "(extreme) sensitivity to initial conditions." Many of which are neither observable nor predictable.
Because my argument was not about a "specific" language.
It was about C-capability language gaining and Lisp-capability language losing ground at that era.
That the C-capability language was C itself, well, that be more or less random.
But that people DID need a portable, close to the metal, constrained with regards to memory use, pointer using, simple to create compilers for, close to assembly language at the time because CPUs and memory were constrained, that was not random, that was a necessity.
And, no, there wasn't "extreme sensitivity to initial conditions" to that. The initial conditions varied at the ten odd years it took for the language to gain traction. And Lisps (including CL, Clojure etc) have been going up and down since the early sixties. It's not like some initial condition set the tone, tons of decisions, several of them important and with predictable consequences set the tone.
Because my argument was not about a "specific" language.
It was about C-capability language gaining and Lisp-capability language losing ground at that era.
That the C-capability language was C itself, well, that be more or less random.
But that people DID need a portable, close to the metal, constrained with regards to memory use, pointer using, simple to create compilers for, close to assembly language at the time because CPUs and memory were constrained, that was not random, that was a necessity.
And, no, there wasn't "extreme sensitivity to initial conditions" to that. The initial conditions varied at the ten odd years it took for the language to gain traction. And Lisps (including CL, Clojure etc) have been going up and down since the early sixties. It's not like some initial condition set the tone, tons of decisions, several of them important and with predictable consequences set the tone.
> It was about C-capability language gaining and Lisp-capability language losing ground at that era.
And why didn't Fortran win? It meets these requirements. Didn't Forth exist back then too? That meets these requirements.
And why didn't Fortran win? It meets these requirements. Didn't Forth exist back then too? That meets these requirements.
Perhaps you missed the part of my comment where I SPECIFICALLY addressed that issue.
That is, the part where I wrote:
my argument was not about a "specific" language. It was about C-capability language gaining and Lisp-capability language losing ground at that era. That the C-capability language was C itself, well, that be more or less random.
Either the languages competing were close to what was needed for the machines of the era and the dynamics of the marker (in which case they were more or less similar and which one won was random) or the languages had very different characteristics (in which case which "style" of languages won can be explained).
Languages close together (e.g C and Pascal) won or lost for less significant and more random reasons than the ones that led whole language families to win or lose.
That is, the part where I wrote:
my argument was not about a "specific" language. It was about C-capability language gaining and Lisp-capability language losing ground at that era. That the C-capability language was C itself, well, that be more or less random.
Either the languages competing were close to what was needed for the machines of the era and the dynamics of the marker (in which case they were more or less similar and which one won was random) or the languages had very different characteristics (in which case which "style" of languages won can be explained).
Languages close together (e.g C and Pascal) won or lost for less significant and more random reasons than the ones that led whole language families to win or lose.
I don't mean to nit-pick, but although I found the content to be very interesting, I also found it difficult to follow because it feels like the author's grasp of English isn't quite where it needs to be (although it's very close).
In particular, the phrase "back in a day" is used twice and I'm still not 100% certain whether it means that the actions were performed in a single day (which would be odd phrasing) or, more likely, if it's meant to be "back in the day", in the sense of "at an unspecified point in the past".
That said, I don't wish to put people off from blogging in English, especially considering it was an interesting article that I would not have been able to enjoy if it was written in Croatian. My (intended to be friendly) advice is to recruit native-English proof-readers. I think you won't need them for long.
In particular, the phrase "back in a day" is used twice and I'm still not 100% certain whether it means that the actions were performed in a single day (which would be odd phrasing) or, more likely, if it's meant to be "back in the day", in the sense of "at an unspecified point in the past".
That said, I don't wish to put people off from blogging in English, especially considering it was an interesting article that I would not have been able to enjoy if it was written in Croatian. My (intended to be friendly) advice is to recruit native-English proof-readers. I think you won't need them for long.
Hey, thanks for the feedback. I was supposed to be "back in the day". But I feel it is best to just throw it out since it sounds kind of fake.
The 'ball of mud' analogy is spot-on. An artist can create wonderful sculptures with it, but a beginner won't be able to do much, besides flinging it around and making a mess.
And that is not a bad thing. But really, how many Picassos and Da Vincis and Michelangelos have we produced so far? That's not something you could ever call "mainstream"...
And that is not a bad thing. But really, how many Picassos and Da Vincis and Michelangelos have we produced so far? That's not something you could ever call "mainstream"...
I think that this article was posted a while back. I agree with most points, except for the one about lack of "pre choice" - I've been playing around with Racket (formerly PLT Scheme) for a while, and the one thing I've been amazed at is the amount of choice. There are a ridiculous number of built-ins.
I think that the failure of Lisp to gain traction is probably better attributed to the other point about too much minimalism being madness. Some of the forms in Racket are pretty crazy.
I think that the failure of Lisp to gain traction is probably better attributed to the other point about too much minimalism being madness. Some of the forms in Racket are pretty crazy.
The failure of Lisp to gain traction historically might also be a result of marketing. Now that people are associating Clojure with things like startups, Heroku, concurrency, and the JVM, it seems to be catching on outside of the Lisp community.
I just found this chart (http://tinyurl.com/9f7pxnq) of languages Clojure users came from [or are still using] from cemerick's 2012 State of Clojure survey, which suggests that Clojure is not only catching on outside of the LISP community, but almost exclusively so.
Lisp being too minimalistic or offering too many choices is an interesting argument. It's not wholly untrue. Lisps culturally offer power and flexibility.
Many- most perhaps - developers don't want that. They want a golden road to deployment, a KISS mechanism to write basic code to do basic things and keep doing them. Flexibility and power expand the solution space too much for their taste.
Well, that's OK for them. I'll just be doing my Lisp as much as I can.
Many- most perhaps - developers don't want that. They want a golden road to deployment, a KISS mechanism to write basic code to do basic things and keep doing them. Flexibility and power expand the solution space too much for their taste.
Well, that's OK for them. I'll just be doing my Lisp as much as I can.
It's not that developers don't want flexibility or power. It's that it comes at a cost of collaboration with other developers and tools.
Dick Gabriel, IIRC, mentioned that many PL research was done in lisp, but your PhD would look dull if it was just a set of lisp macros, so students devised a concrete syntax and built a separate native compiler. I believe lisp as an atom will never be more popular than in the Symbolics era (lisp from top to metal, hard to beat), lisp genes,though, are all over the place recently.
One other thing to consider is when it's so easy to roll out your own [server|language|framework] no single implementation gains critical mass and fragmentation prevents newcomers from joining in.
And Beethoven will never beat out the Beatles. It's a pop culture, baby! Live with it.
How much is "enough"?
I don't know. Maybe to be in the top 10 on TIOBE index? It's paradoxal that you have this superior paradigm that not only is not dominating but it's not even in top 5 languages that are used. (Not to mention that all dialects account for that 13-th place, so if you disperse percentage on all of them - they are of the chart)
Tbe reason that functional programming languages, including LISP, will never dominate the world is because most people are doing engineering, not maths or getting out CS papers.
CS people like to abstract away the computation from physical hardware, but the apparent fact is computation _is_ physical, and it's limits lie in physics and not in mathematics or philosophy (see Shor's algorithm for instance).
It's only natural to write programs in a language that follows the same flow as the underlying physical computer. A classical computer is represented by it's assembly language, thus it makes sense to have languages like C. Concepts like "stateless programs" don't even exists in a classical computer. It's as crazy as trying to build a quantum algorithm that does away with measurements!
In addition the physical world does not work anything like a stateless machine. As most useful programs imitate a physical process rather than a pure mathematical object, the notion of writing programs in such languages is not-intuitive and requires transformation of the actual problem at a both low (hardware) and high (software output) level.
Finally I would like to speculate that the whole concept will never be intuitive in the future (post-quantum computer era). In the era of quantum computers, because they will always be physical objects with a particular state, and it's this very fact that they have a well-defined state allows us to perform a computation.
CS people like to abstract away the computation from physical hardware, but the apparent fact is computation _is_ physical, and it's limits lie in physics and not in mathematics or philosophy (see Shor's algorithm for instance).
It's only natural to write programs in a language that follows the same flow as the underlying physical computer. A classical computer is represented by it's assembly language, thus it makes sense to have languages like C. Concepts like "stateless programs" don't even exists in a classical computer. It's as crazy as trying to build a quantum algorithm that does away with measurements!
In addition the physical world does not work anything like a stateless machine. As most useful programs imitate a physical process rather than a pure mathematical object, the notion of writing programs in such languages is not-intuitive and requires transformation of the actual problem at a both low (hardware) and high (software output) level.
Finally I would like to speculate that the whole concept will never be intuitive in the future (post-quantum computer era). In the era of quantum computers, because they will always be physical objects with a particular state, and it's this very fact that they have a well-defined state allows us to perform a computation.
I don't think the relationship between a language's model of computation and the physical computing mechanism is particularly important. It's more important for a language to follow our MENTAL model of computing. Fortunately, the mental model of computing can change over time as you become familiar with new paradigms.
The same thing can be said about "which model of computation resemble physical reality." Each of us can have different mental models of physical systems. Personally, the functional paradigm is closer to my mental model than declarative, but imperative still feels the most natural. This isn't a statement about reality, but rather about how you think about it.
The same thing can be said about "which model of computation resemble physical reality." Each of us can have different mental models of physical systems. Personally, the functional paradigm is closer to my mental model than declarative, but imperative still feels the most natural. This isn't a statement about reality, but rather about how you think about it.
I think there is a confusion here: our "mental" grasp of a physical process and intuition is tightly related to how the world works. We develop our intuition from real-world experience. They're not two separate things. This's also why quantum physics is so non-intuitive for us, and why we struggle dealing with it (counter-intuitive it is, we do it anyways, because that's just the way the Nature works --it's not something man-made like Lisp).
That being said, the physical processes don't depend on people's understanding. Physics doesn't depend on how you think about the world. The quantum state (or a classical state) is there, and it won't go away just because you want mathematical elegance or try to see things in a different way in your inner world as hard as you can.
That being said, of course it matters the way you write your software. There is a huge gap between actual CPU instructions and Lisp. Between Lisp and the machine is an automated, soft layer of emulation, which may or may not be optimal and is extra work anyway.
That being said, of course it matters the way you write your software. There is a huge gap between actual CPU instructions and Lisp. Between Lisp and the machine is an automated, soft layer of emulation, which may or may not be optimal and is extra work anyway.
There are plenty of ways of accurately representing reality that don't rely on mutable state.
F=MA is a function, and it isn't mutable. I could calculate force from some other function (e.g. Gm1m2/r^2). I can compose those functions together to get a new function. Still nothing mutable. I could continue this to create a model of a physical system that turns into one big function. That function models the system, and it can take some outputs to give whatever outputs you want. All without storing state internally.
So, it's certainly possible to accurately represent physical systems without keeping track of state along the way.
F=MA is a function, and it isn't mutable. I could calculate force from some other function (e.g. Gm1m2/r^2). I can compose those functions together to get a new function. Still nothing mutable. I could continue this to create a model of a physical system that turns into one big function. That function models the system, and it can take some outputs to give whatever outputs you want. All without storing state internally.
So, it's certainly possible to accurately represent physical systems without keeping track of state along the way.
Please tell me you were trolling. Or that you're 10. Otherwise go read some basic mechanics from Goldstein's Classical Mechanics. And learn some basic mathematics.
Classical state of a particle lives in the 2n-dimensional manifold known as phase space. The coordinates of the phase space are the configuration space and the corresponding conjugate momenta. The state is a single point on the phase space, corresponding to the initial conditions of the problem. The Hamiltonian determines the time evolution in the phase space, which is a trajectory.
To make is simpler for you to understand: 1. Position and momentum couples form the physical state. And of course, for any physical system, it exists. 2. You need 2 initial conditions to solve a 2nd order differential equation. You can't solve a differential equation without initial conditions (of course to use this fact, you would need to understand that F=ma is a differential equation, not a function) (Maybe it's better if you read some good introductory text, such as Feynman Lectures on Physics Vol 1, Chapter 9).
If still not clear for you: the initial state in a two body problem is determined by the initial position and velocity. They are the initial conditions of your "function" F=ma, which is actually a second order differential equation. F determines how this initial state will change over time.
Classical state of a particle lives in the 2n-dimensional manifold known as phase space. The coordinates of the phase space are the configuration space and the corresponding conjugate momenta. The state is a single point on the phase space, corresponding to the initial conditions of the problem. The Hamiltonian determines the time evolution in the phase space, which is a trajectory.
To make is simpler for you to understand: 1. Position and momentum couples form the physical state. And of course, for any physical system, it exists. 2. You need 2 initial conditions to solve a 2nd order differential equation. You can't solve a differential equation without initial conditions (of course to use this fact, you would need to understand that F=ma is a differential equation, not a function) (Maybe it's better if you read some good introductory text, such as Feynman Lectures on Physics Vol 1, Chapter 9).
If still not clear for you: the initial state in a two body problem is determined by the initial position and velocity. They are the initial conditions of your "function" F=ma, which is actually a second order differential equation. F determines how this initial state will change over time.
Parentheses.
If this really is what turns you off to Lisps, then probably programming is only going to get harder and harder for you.
Lisp's parenthetical syntax is not, and never has been, its problem. You say "parenthesis" as a cute excuse to avoid doing any meaningful defense of your rejection of lisp.
Lisp's parenthetical syntax is not, and never has been, its problem. You say "parenthesis" as a cute excuse to avoid doing any meaningful defense of your rejection of lisp.
In fact, the syntax of s-expressions is the key to Lisp's power. The form of program and data are the same, which allows the powerful macro facility and the functions read and eval.
I've wondered for years why people latch onto the parenthesis thing. When I learned lisp for a class, I never gave it a second's thought. To me it feels like people are looking for a handy reason to put Lisp down, perhaps either because they don't understand it or because they do understand it and they are jealous of some of the features of Lisp.
I've wondered for years why people latch onto the parenthesis thing. When I learned lisp for a class, I never gave it a second's thought. To me it feels like people are looking for a handy reason to put Lisp down, perhaps either because they don't understand it or because they do understand it and they are jealous of some of the features of Lisp.
When people say they hate "parentheses" in Lisp, I'm pretty sure what they really mean is "I hate s-expressions." You may find them natural to work with, but it's pretty clear most programmers do not. Witness the crazy amount of work compiler writers put into writing parsers that could be trivially done away with if they just switched to using s-expressions.
Personally I prefer both Forth's RPN and C/C++ (Algol?) style notation to Lisp's s-expressions.
Personally I prefer both Forth's RPN and C/C++ (Algol?) style notation to Lisp's s-expressions.
S-expressions are neither wonderful nor terrible. They are just A Decision. Certainly you can have bad syntaxes and good syntaxes, as well.
From my perspective, it comes from being used to parentheses in English. Specifically, you have a man thought, then you have some other modifiers that may expand on that concept which you enclose in parentheses. This fits well with C style functions, for example. But with Lisp, the main thought (the function name) is also enclosed in parentheses along with all its modifiers, which makes it a bit harder to follow the code.
However, I do like the overall elegance that this brings to the code, where code and data are the same. Which is why I also like Postscript -- it does the same thing but in an RPN style (a function is actually an executable array).
However, I do like the overall elegance that this brings to the code, where code and data are the same. Which is why I also like Postscript -- it does the same thing but in an RPN style (a function is actually an executable array).
The parentheses may seem like a disaster at first, but one can quickly learn to use and abuse them.
Also, there is great support from lisp-friendly editors to handle parentheses management (e.g. paredit for emacs http://emacswiki.org/emacs/ParEdit).
Also, there is great support from lisp-friendly editors to handle parentheses management (e.g. paredit for emacs http://emacswiki.org/emacs/ParEdit).
I've been seriously spoiled by paredit. It is a brilliant, absolutely brilliant way to edit code. Editing code written in those so called free form readable languages is absolute pain compared to structured editing in paredit. It is a reason to program in Lisps by itself. You don't need that filter on your data? Easy, you just need one keystroke (M-r) to raise the inner expression. Everyone should experience it, it certainly makes me want to write more and more code in Clojure.
Readability
Do you mean because the syntax isn't sugary or because Lisp lends itself to a DSL-driven style of development where user-defined constructs are used more extensively than in any other language family? If the former, I'd argue that's just because you're not used to looking at Lisp code. If anything, its extreme concision should make visually parsing code faster than parsing equivalent code in other languages.
If the latter, pg makes a good argument in section 4.8 of On Lisp:
"So yes, reading a bottom-up program requires one to understand all the new operators defined by the author. But this will nearly always be less work than having to understand all the code that would have been required without them.
If people complain that using utilities makes your code hard to read, they probably don’t realize what the code would look like if you hadn’t used them. Bottom-up programming makes what would otherwise be a large program look like a small, simple one. This can give the impression that the program doesn't do much, and should therefore be easy to read. When inexperienced readers look closer and find that this isn’t so, they react with dismay."
If the latter, pg makes a good argument in section 4.8 of On Lisp:
"So yes, reading a bottom-up program requires one to understand all the new operators defined by the author. But this will nearly always be less work than having to understand all the code that would have been required without them.
If people complain that using utilities makes your code hard to read, they probably don’t realize what the code would look like if you hadn’t used them. Bottom-up programming makes what would otherwise be a large program look like a small, simple one. This can give the impression that the program doesn't do much, and should therefore be easy to read. When inexperienced readers look closer and find that this isn’t so, they react with dismay."
"Its extreme concision should make visually parsing code faster than parsing equivalent code in other languages."
You know, I don't think this is true at all. Concision can make things harder to read, because you have to understand everything you read from scratch. A language where some common patterns come with a bit of boilerplate allow you to orient yourself via that boilerplate. The visual representation of a common pattern provided by the sugary syntax of some languages is, in one sense a waste of space and typing, but it can make code easier to read than a more concise language would be.
You know, I don't think this is true at all. Concision can make things harder to read, because you have to understand everything you read from scratch. A language where some common patterns come with a bit of boilerplate allow you to orient yourself via that boilerplate. The visual representation of a common pattern provided by the sugary syntax of some languages is, in one sense a waste of space and typing, but it can make code easier to read than a more concise language would be.
I'm not quite sure I understand your point, but you're disagreeing with the above quote whereas I agree wholeheartedly with the quote.
Compare a language which forces you to write this
Contrast the above with
Compare a language which forces you to write this
ll = []
for x in xx:
if bar(x):
ll.append(x)
Contrast the above with
ll = [x for x in xx if bar(x)]
filter bar xx
To be honest that Python list comprehension is really hard for me to internalize.
I find Ruby way much more natural.
xx.select { |x| bar(x) }
Even Clojure is better
(filter (fn[x](bar x)) xx)
or
(filter #(bar %) xx)
I find Ruby way much more natural.
xx.select { |x| bar(x) }
Even Clojure is better
(filter (fn[x](bar x)) xx)
or
(filter #(bar %) xx)
Sure, I do, too. Ruby is one of the languages that made me experience how expressive the higher-order function pattern really is.
That said, in Python, you have to take what you can get, though. And generally I expect more people are familiar with Python than Haskell. Probably I should've used Ruby. Oh well.
That said, in Python, you have to take what you can get, though. And generally I expect more people are familiar with Python than Haskell. Probably I should've used Ruby. Oh well.
BTW, friendly tip: if you want code formatting, try using four spaces of indent. You might only need two, actually. Let's see. Two spaces:
filter foo xx
filter foo xxhttp://news.ycombinator.com/item?id=1803815
Pseudocode is better expressed in Python than Lisp, therefore much better in the academic world.
My point stands: READABILITY.
Pseudocode is better expressed in Python than Lisp, therefore much better in the academic world.
My point stands: READABILITY.
Indeed, criticizing "lisp" is difficult because it isn't really clear what you mean. Common Lisp? Well that has a lot of work done for you. Scheme? That's deliberately minimalist because it's not meant for everyday work until you go outside the core spec (e.g., PLT Scheme's libraries). Clisp? MacLisp? What?
Lisp didn't take off because it didn't take off. There isn't some deep unconscious wisdom being tapped by the masses that we can read with tea leaves and subtlety. These things are random. There is a parallel universe not far from this one where Anic is a big deal and Pike took off in place of Python.
Because to assume otherwise that would imply that everyone knows every language and some are uniform winners over others. Do you know every language you have rejected? Heck, do you even know the general characteristics of Lisp, or Haskell, or ML, or Anic, or Pike, or APL? No, and to really try and learn all of them would take a lot of time unless you're quite gifted. So the premiere and popular programming languages are as unpredictable as fashion.
All you and I can do in our quest to be great software engineers is try and choose tools that split the difference between The Best For the Job and the Best We Can Manage.