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

121–130 of 143 posts

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

#121

Post by aerique »

telemachos wrote: post #106
aerique wrote: post #78

Earlier quoted context omitted.

As a beginner just grab the XML lib which is easiest to install and looks comfortable to use. If it doesn't work out try another one. I really don't get all the complaints in this thread about the lack of a central library repository. How hard is it to use Google? Libraries aren't suddenly bad because they're not from Lib Grand Central. In other languages, Perl specifically, I've tried libraries from CPAN that were t…

Perhaps it's possible to get lucky and find good libraries using nothing but Google and patience, but I'm baffled that anyone would deny the value of something like CPAN. CPAN's structure enforces good practices: (e.g., tests, docs, bug tracking). CPAN provides not one but two excellent search pages. It also contains many reviews, and makes it trivial to see the source of any library or app before you download it. CP…

I'm not denying the value but I do think too much value is put in it. I certainly wouldn't use the lack of something like CPAN as an argument not to learn an otherwise fine language.

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

#122

Post by pp »

Confusion wrote: post #86
scott_s wrote: post #14

Earlier quoted context omitted.

To be fair, I think most explanations for the decisions we make work this way.

I think it just seems that way, because it takes effort to explicitly pull all those arguments into our consciousness, to explain a decision that was taken subconsciously. The subconscious is often equated with the emotional or the irrational, but there is no reason to suppose the subconscious is incapable of rational decision making. Looking at it from that perspective, you are not rationalizing an irrational decisi…

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.

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

#123

Post by gruseom »

pwnstigator wrote: post #113
gruseom wrote: post #109

Earlier quoted context omitted.

Indeed, we figured out recently that it's basically embedded Algol 68... which seems superbly fitting somehow.

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 to reject the old per se. The will to novelty is so extreme that it doesn't matter if the new thing is worse, only that it is newer. We want to program in new languages like we want to drive new cars (a bad analogy in Common Lisp's case, unless you assume that the older car is both faster and more fuel efficient). Lisp in general, and Common Lisp in particular, is up against this dynamic. You can't understand the reactions to it without accounting for that.

That CL contains TAGBODY is a brilliant thing. It amazes me that a language can be at once so high-level and so low-level. I haven't had occasion to use it yet, but the fact that it's there, and that the higher-level abstractions are built in terms of it, is a thing of beauty to me. (I don't know about PROGV.)

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

#124

Post by Confusion »

pp wrote: post #122
Confusion wrote: post #86

Earlier quoted context omitted.

I think it just seems that way, because it takes effort to explicitly pull all those arguments into our consciousness, to explain a decision that was taken subconsciously. The subconscious is often equated with the emotional or the irrational, but there is no reason to suppose the subconscious is incapable of rational decision making. Looking at it from that perspective, you are not rationalizing an irrational decisi…

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 high bid, so they should try to make a relatively low bid? Do they make 'normal' bids or extremely low bids?

This shows that saying people can't rid their decisions of that influence is an overstatement. When you are consciously aware of the heuristics and the decision is taken over a period of time, you can downplay them.

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

#125

Post by aerique »

sandGorgon wrote: post #112
telemachos wrote: post #106

Earlier quoted context omitted.

Perhaps it's possible to get lucky and find good libraries using nothing but Google and patience, but I'm baffled that anyone would deny the value of something like CPAN. CPAN's structure enforces good practices: (e.g., tests, docs, bug tracking). CPAN provides not one but two excellent search pages. It also contains many reviews, and makes it trivial to see the source of any library or app before you download it. CP…

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.

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

#126

Post by jcapote »

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…

"it's _good shit_. Get work done good. Think, hack, ship, bill for it good. 2-3 products per month good. You still have to know where things are, who is working on what, what's maintained and what's obsoleted by what. Sure. But there is absolutely no lack of libraries."

this is exactly how I feel about Ruby...

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

#127

Post by xtho »

SwellJoe wrote: post #68
nearestneighbor wrote: post #62

Earlier quoted context omitted.

> Cliki was launched, C-L.net, and the #lisp IRC channel was born and Google doesn't see any uptrend: http://www.google.com/trends?q=common+lisp

Not only that, it's noise compared to a few other dynamic languages: http://www.google.com/trends?q=perl%2C+python%2C+ruby%2C+com...

This could also mean that there is neither an opera named "common lisp", nor a comedy group, nor a gemstone fo the same name ... and well perl's fame is waning or fewer people misspell pearl.

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

#128

Post by vseloved »

pwnstigator wrote: post #108
vseloved wrote: post #60

It's funny, that the decision to choose Common Lisp for some project often has to defend itself (because of so much FUD around the language). CL has one killer feature, that will appeal to any mature developer: it's the only production-ready language around, in which you are virtually not constrained by any third-party design decision. That's it. Discussing other details just boils down to the question of tastes (tha…

What about Clojure, circa now? Do you not consider it "production ready"? I've used both CL and Clojure. I'd prefer either over Blub, but Clojure wins in my opinion.

Clojure is nice, although I didn't use it in production. But it is Java deep underneath (so not completely homoiconic) and comparing to CL there are restrictions, albeit mild.

For some specific tasks I might have preferred it (until CL catches up with concurrency support). But in general CL gives you more freedom.

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

#129

Post by riobard »

frig wrote: post #87
riobard wrote: post #79

Earlier quoted context omitted.

I'm not so sure if set notation is higher level, but for the example in your longer comment, map/filter/product is not that bad if you use it wisely. Here is my version: map(lambda (w,s,l): {'widget': w, 'sprocket': s, 'location': l} filter(lambda (w,s,l): l.hasInStock(w) and l.hasInStock(s) and w.isUsableWith(s), product(widgets, sprockets, locations))) Well, I agree it is not any conciser that its list comprehensio…

You'll be thrilled (lol) to know that the lambda-tuple syntax isn't in python 3 (!); it does make my examples more concise. The argument in favor of set-notation being higher level is it's less specific (it doesn't explicitly provide a sequence of operations, just an outcome). List comprehensions look like set notation but have an implicit procedural translation you have to keep in mind to use them well, so it's a to…

> You'll be thrilled (lol) to know that the lambda-tuple syntax isn't in python 3

Now you know why many people like me are gradually pissed off by Python and start the exile ... currently trying Scala and it seems a nice language (with list comprehension too! :)

> List comprehensions look like set notation but have an implicit procedural translation you have to keep in mind to use them well, so it's a toss-up.

Actually I think that's the problem I have with list comprehensions: I use them a lot in my code, usually 1~3 levels nested and then have a hard time tracking down the order of implicit loops (which is inner vs outer) and make sure the intermediate variables (x for x in y for y in z ...) do not clash ... OK maybe I'm using it too much and in the wrong way :(

> I prefer map/filter/reduce when sequencing has large performance implications but for simple filtering or raw-data-shaping comprehensions read more smoothly.

I didn't know map/filter is faster than list comprehensions? I thought both are optimized by Python interpreter. But I like the idea of knowing that at least map can be parallelized easily. But since Python does not utilize multicore in a decent way, all bets are off :(

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

#130

Post by riobard »

holygoat wrote: post #102
ramen wrote: post #19

Earlier quoted context omitted.

I know you all know this, but I feel like it bears mentioning that nobody is forcing you to use list comprehensions whether map/filter stay in Python's built-ins or not. They can be defined in around 3-4 lines of code each. Lisp aficionados, already accustomed to the bottom-up style of programming, ought to have no problem writing functions like these as necessary.

There's a difference between things being possible and being encouraged . De-emphasizing functional operations makes it more likely for libraries to work in a non-functional style, for tutorials to do so, etc. It's tiring fighting against a community and a (benevolent) dictator that disagree with you.

> It's tiring fighting against a community and a (benevolent) dictator that disagree with you.

That summarizes the problem I guess :D

Post reply on HN