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

81–90 of 143 posts

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

#81

Post by riobard »

yummyfajitas wrote: post #52
riobard wrote: post #41

Earlier quoted context omitted.

Well, FP is mostly about nesting, but it's uniform and people get used to thinking that way. List comprehensions, on the other hand, are more like procedure code (conceptually), and it sucks to nest them. Nesting aside, it's the different level of abstraction that matters for FP-ers. Plus, you get 5 mentions (3 y's and 2 x's) of some intermediate variables instead of 0 in your code, so both token-wise and char-wise,…

List comprehensions are not conceptually like procedural code at all. They are completely declarative. List comprehensions: the set contains this. Map/filter: apply these functions to the set. Procedural: follow this recipe for turning one list into another.

Maybe it's just me ... Every time I see something like

    [fn(x) for x in xs for xs in xss if cond(xs)]
I always think it's a loop, then an inner loop (and loops -> procedure ... then get confused which is inner and which is outer :|

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

#82

Post by swannodette »

wheels wrote: post #36
smanek wrote: post #12

Earlier quoted context omitted.

I think you drawing that conclusion may be a result of how I structured my essay (I introduced my conclusion, then my reasoning). I freely admit my personal biases and experiences eliminated a lot of potentially good options without ever giving them due consideration (e.g., Haskell, Scheme, Lua). But I really did try to give the 3 options listed in the article a fair shake at the time. For what it's worth - I was abo…

I too thought the logic was weak. Here was my basic objection: you chose not to use two popular web programming languages because of their potential volatility, but then went with one that has been so infrequently used in web programming that it almost certainly has opaque deffeciencies. It's not that your reasons were bogus, they just didn't carry the decision.

Django/Python and Ruby/Rails present their own (sometimes very significant) opaque complexities. Being complex, they actually hide their deficiencies for a long time. Enough so that sometimes rolling your own thing is not a significant time sink in comparison.

This also alludes to the popularity of do-it-yourself microframeworks. If you're planning on using a microframework anyway, I'm not sure your argument really holds up. You can pretty much use whatever not-completely-marginal language you want and be just fine.

Honestly the only valid argument that I come up with is that you can't find enough programmers that know or are excited to know that language to join your team.

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

#83

Post by riobard »

riobard wrote: post #46
frig wrote: post #32

Earlier quoted context omitted.

It depends slightly on how you came to functional programming. You can arguably trace Python's list comprehension syntax all the way back to setl, a "set-theoretic programming language", and the resemblance to mathematical set-builder notation is intentional; compare - let B = { g(a) s.t. | a \in A and f(a) holds} - B = [g(a) for a in A if f(a)] If you're used to thinking in sets having to decompose into "maps" and "…

Python's lambda sucks, but that does not necessarily mean map/filter sucks with it too. Of course there are cases where list comprehensions are more convenient and more powerful (esp. if they are more like their "real" counterparts in Haskell and friends). But in cases when map/filter are more convenient, I like the option of using them.

[NOTE: copied from another branch for easy reading for others]

A saner map/filter/product 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)))

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

#84

Post by Periodic »

coffeemug wrote: post #56
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…

Come on, man. If you're doing something worthwhile, it likely takes 2-3 months (if you're lucky) to just understand the problem. Common Lisp is an amazing language and development environment, but it won't help you actually solve the problem any faster, only to implement the solution. No silver bullets and all. I love Common Lisp, but the whole "code this in a weekend" thing has got to stop. Good software takes a dam…

That first 80% always takes only 20% of the time, and that's the first month for you. Some languages seem to let you do that month of work in three weeks, or two weeks, or with a framework it might take a week. But that last 20% is the part that always takes 80% of the time, and it often seems like whatever language you use, there are always the same, small, insidious errors and tweeks that need to be done.

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

#85

Post by Periodic »

nearestneighbor wrote: post #74
[deleted] wrote: post #72

Earlier quoted context omitted.

[deleted]

"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 compiler optimization where they both using?

- Was the program large or small?

There's a reason they call it the "Computer Language Benchmark Game": http://shootout.alioth.debian.org/

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

#86

Post by Confusion »

scott_s wrote: post #14
WilliamLP wrote: post #8

Basically: I started with my conclusion, and then went through all the other options and rationalized them away until it seemed like my choice was based on objective reasoning.

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 decision when you explain your reasoning: you are simply remembering/recreating the process that lead to the initial, perhaps even rational, decision.

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

#87

Post by frig »

riobard wrote: post #79
frig wrote: post #47

Earlier quoted context omitted.

I have a longer comment here that argues the opposite: list-comprehensions are only a syntactic pun or two away from set-builder notation, which is a higher level-of-abstraction (it declaratively states what it is) than map+filter (which specify a procedure to generate it, albeit at higher level of abstraction than a for-loop). If you can put together a nontrivial usage of map+filter with at least three source collec…

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 toss-up.

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

http://books.google.com/books?id=RvY5BM0Xt1wC&lpg=PT367&...

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

#88

Post by SwellJoe »

nearestneighbor wrote: post #69
SwellJoe wrote: post #68

Earlier quoted context omitted.

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...

I'm not disagreeing, but to be fair, "common lisp" is often referred to as "lisp" or "CL". So the phrase is good for (down)trends, but not for comparisons.

True, I should have shortened it to just lisp. Here we go:

http://www.google.com/trends?q=perl%2C+python%2C+ruby%2C+lis...

Yep, still noise.

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

#89

Post by atamyrat »

aerique wrote: post #80
herdrick wrote: post #42

Earlier quoted context omitted.

* Few years ago you couldn't just download a random lisp library and expect it to work * Yeah, that was my painful experience as a noob. Now dependency libraries get downloaded behind the scenes. You mean ASDF takes care of dependencies for you?

She might be talking about clbuild.

Mahmud is a boy's name.

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

#90

Post by maxtilford »

frig wrote: post #47
riobard wrote: post #41

Earlier quoted context omitted.

Well, FP is mostly about nesting, but it's uniform and people get used to thinking that way. List comprehensions, on the other hand, are more like procedure code (conceptually), and it sucks to nest them. Nesting aside, it's the different level of abstraction that matters for FP-ers. Plus, you get 5 mentions (3 y's and 2 x's) of some intermediate variables instead of 0 in your code, so both token-wise and char-wise,…

I have a longer comment here that argues the opposite: list-comprehensions are only a syntactic pun or two away from set-builder notation, which is a higher level-of-abstraction (it declaratively states what it is) than map+filter (which specify a procedure to generate it, albeit at higher level of abstraction than a for-loop). If you can put together a nontrivial usage of map+filter with at least three source collec…

Using do-notation is probably cheating, but what do you think of this? (in Haskell):

  do { w
We're trading horizontal space for vertical space. I think it's much clearer than either list comprehensions or plain map/filters. It's the best of both worlds.
Post reply on HN