Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I chose Common Lisp over Python, Ruby, and Clojure

postabon.posterous.com

Post reply on HN
Print view View original

131–140 of 143 posts

Re: Why I chose Common Lisp over Python, Ruby, and Clojure

#131

Post by sandGorgon »

aerique wrote: post #125
sandGorgon wrote: post #112

Earlier quoted context omitted.

it goes beyond CPAN - it would have been nice to have a "batteries-included" version that packs in most useful libraries (like Python's Image, lxml, etc libraries). The very argument that choice > standardization is something I dont get - even in Rails, you have the choice of not using the default templating engine, JavaScript framework, etc. But it doesnt mean that they dont package it in anyway. This accelerates ad…

Check out http://common-lisp.net/project/clbuild/ and http://libcl.com/ , although the latter is still in its testing phase.

thanks... this is something really interesting

Re: Why I chose Common Lisp over Python, Ruby, and Clojure

#132

Post by [deleted] »

nearestneighbor wrote: post #57
mahmud wrote: post #16

Did you really choose Lisp over alternatives? Before learning CL I was a fairly decent, C, C++ and Perl programmer. Did assembly, Pascal, TCL and Awk. Up to that point, I always had to pause a for a minute when starting a new project/script, think about its scope, and choose a language based on the necessary performance, development speed, expressiveness, available libraries, etc. (and whether whoever was going to re…

What is was it about CLOS that made you feel it was a killer language feature? Many seasoned Lisp programmers do not even consider it or OO in general particularly useful.

[deleted]

Re: Why I chose Common Lisp over Python, Ruby, and Clojure

#133

Post by pp »

Confusion wrote: post #124
pp wrote: post #122

Earlier quoted context omitted.

To my knowledge, the famous experiments of Kahnenman and Tversky have proven otherwise. When studying the effect of "anchoring", for example, they would actually explain to their subjects how their rational decisions are influenced by this irrational heuristic. Yet the subjects could not rid their decisions of that influence.

Which showed that there are probably irrational heuristics involved in every decision. However, it doesn't show that irrational heuristics are important, or even dominant, in every decision. On the Wikipedia page for 'Anchoring', there is an example about thinking of a number and subsequently bidding (experiment by Ariely). What happens when you tell people with a high number that they are likely to make a relatively…

Most studies that I'm aware of in behavioral psychology (granted, it's a young branch of science) confirm my point, though. When they tell people about the anchoring heuristic, people still continue to make similar mistakes.

One way to explain would be to think about the number of variables we should account for in virtually any everyday decision. Finding even a fairly optimal solution would consume too many resources and evolution has taught us to deal with this using emotional shortcuts. On the evolutionary time scale, the 50 years when the question of choosing a programming language was relevant would be a tiny dot.

On the other hand, rational knowledge can by absorbed subconsciousness eventually. But when it does, we become unaware of it, by definition.

Re: Why I chose Common Lisp over Python, Ruby, and Clojure

#134

Post by fauigerzigerk »

scott_s wrote: post #11

Python's multiprocessing library ( http://docs.python.org/library/multiprocessing.html ) provides a similar interface that one would expect from a multithreaded library. For example, from multiprocessing import Pool p = Pool(5) def f(x): return x*x p.map(f, [1,2,3]) I do not have direct experience with the library, but from what I've seen, the code you would write is not significantly different from the code you'd wr…

Multiple processes cannot share regular in memory data structures. That makes the multiprocessing library unsuitable for a growing class of applications. However, unladen swallow aims to remove the GIL, so there's still hope for Python.

Re: Why I chose Common Lisp over Python, Ruby, and Clojure

#135

Post by pge »

I appreciated the article, but I didn't find the reasoning compelling. What I took away from the article was the following line of reasoning: 1. You strongly prefer functional programming to OO programming (no reason given other than personal preference) 2. You don't have enough experience with any languages that are well-suited to FP other than CL that you would be comfortable undertaking a large project 3. You confirmed that many languages you are familiar with (Java, Python, Ruby) are better suited to OO than FP style (not a surprise at all except perhaps Python as I touch on below), so as a direct consequence of (1) and (2), you were left with CL.

CL is my first-choice language for certain kinds of projects as well, but I didn't come away any new insights from your article. Your choice seems to hinge around two key conclusions for which you give very little explanation: FP is better than OO for your project, and Python is not a good language for FP. I single out Python because I don't think anyone would argue that Java or Ruby is well-suited to FP. Guido insists that Python is not an FP language, but many users (myself included) would argue that it is reasonably well-suited for FP. That FP was better for your project does not require any further explanation. As others have noted, for a project where scalability of the development team is not an issue (i.e. you are the primary or only developer), it makes sense to choose the style and language you are most comfortable with. If you were starting a project that was going to require several years and a large number of developers, I would have found it more surprising if you committed to a functional programming model. But, given the nature of the project, it didn't seem like there was any need to defend that decision further.

All in all, I'm very excited to see CL being used for more commercial web apps, but I didn't find any insight in the thought process you laid out.

I am, however, much more interested in Pt. II - your description of rolling out a web app in CL. I learned CL ten years before I learned Python and would prefer to write in CL when possible, but for web apps, I have turned to Python for a number of reasons, most notably the obvious availability of libraries. I would love to hear what you used and hear a cogent argument that rapid commercial web app deployment can be done in CL as easily as in Python.

Thanks for sharing your story.

Re: Why I chose Common Lisp over Python, Ruby, and Clojure

#136

Post by igouy »

Periodic wrote: post #85
nearestneighbor wrote: post #74

Earlier quoted context omitted.

"and it ran as fast as C++" (emphasis added)

Right, the specific code that he wrote he claims ran as fast as C++. What type of code is this? Benchmarking program language speed is a very, very tricky thing because it is so multidimensional. - Were they both multi-threaded or Single-threaded? - What libraries were each one using? - Was it mostly IO, network, or user interaction? - Is he measuring load times, processing times, run/wait ratios? - What level of com…

Yes, there are several reasons it's called the benchmarks game and although you can read it the way you have, it's more to do with having a lot of spectators and some regular players, and more to do with a weariness with fatal shootouts.

Re: Why I chose Common Lisp over Python, Ruby, and Clojure

#137

Post by scott_s »

fauigerzigerk wrote: post #134
scott_s wrote: post #11

Python's multiprocessing library ( http://docs.python.org/library/multiprocessing.html ) provides a similar interface that one would expect from a multithreaded library. For example, from multiprocessing import Pool p = Pool(5) def f(x): return x*x p.map(f, [1,2,3]) I do not have direct experience with the library, but from what I've seen, the code you would write is not significantly different from the code you'd wr…

Multiple processes cannot share regular in memory data structures. That makes the multiprocessing library unsuitable for a growing class of applications. However, unladen swallow aims to remove the GIL, so there's still hope for Python.

There is an API for both communicating data explicitly, and for allocating shared memory data structures which can be shared implicitly.

Re: Why I chose Common Lisp over Python, Ruby, and Clojure

#138

Post by rbanffy »

mahmud wrote: post #21
herdrick wrote: post #18

Earlier quoted context omitted.

Really? What has improved in Common Lisp in the past two years? Thanks for this comment.

In the last two years? Clozure Common Lisp at least: an open source multithreaded Lisp implementation with unicode on Win32. Before then it was all Unix. Lisp platform independence is so good, I hack on win32 all day and when I am ready to deploy on Linux, the only warning I get is from git telling me it's converting line endings to Unix style. The staggering number of new and maturing infrastructure libraries; borde…

"an open source multithreaded Lisp implementation with unicode on Win32. Before then it was all Unix"

I half jokingly fail to see why running on Win32 would be considered an improvement...

(Burn, karma, burn!)

Re: Why I chose Common Lisp over Python, Ruby, and Clojure

#139

Post by pwnstigator »

gruseom wrote: post #123
pwnstigator wrote: post #113

Earlier quoted context omitted.

Common Lisp is very, very old. Tagbody and progv, anyone? It's an influential language, for sure, but I prefer Clojure for a number of reasons.

The automatic distaste in our industry for things that are old is a disease, a form of vanity. Old ideas are not inadequate because they are old. Most great ideas are old. Sometimes, of course, an old thing is a vestige of some ancient limitation that no longer applies. Those ones are good to clear away. But the prevailing thought process in the software industry, no less dominant for its astonishing primitivity, is…

You make a great point, and I think Lisp has enough fundamental value to deserve its place as the "100-year language". In 2060, people will still be using some descendant of Lisp. On the other hand, I think some aspects of CL are outmoded. I don't like the lack of support for maps as a top-level structure, and equality in CL is seriously broken, IMO.

I'd prefer to code in CL over Java/Blub, but I prefer Clojure over CL, and probably Haskell or ML over Clojure. (Lisp has better syntax, and macros are very cool, but static typing wins for large projects, in my opinion.)

Re: Why I chose Common Lisp over Python, Ruby, and Clojure

#140

Post by fauigerzigerk »

scott_s wrote: post #137
fauigerzigerk wrote: post #134

Earlier quoted context omitted.

Multiple processes cannot share regular in memory data structures. That makes the multiprocessing library unsuitable for a growing class of applications. However, unladen swallow aims to remove the GIL, so there's still hope for Python.

There is an API for both communicating data explicitly, and for allocating shared memory data structures which can be shared implicitly.

I know. That's why I said "regular in-memory data structures".
Post reply on HN