Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Or how about in Clojure?

(map (partial reduce +) (partition 7 7 daily))

Edit: Possibly that should be partition-all from seq-utils to sum the remainder days if the length of daily isn't divisible by 7.



That's pretty unreadable for someone who doesn't know clojure.


Is this better?

map(partial(reduce, +), partition(7, 7, daily))

Personally I'd be much much more happy to be using this code than the snippet in the article. In fact, I don't program Python regularly and it did take quite a while to figure out what was going on in the code.

weekly = [sum(daily[j:j+7]) for j in range(0, len(daily), 7)]

Now if you look back at the top snippet, its just normal function calls, so you can be happy to know what's going on after reading documentation for the names "partition" and "daily".

If you don't know what "map", "partial", "reduce" and "+" mean, sure you have to look up their documentation too, but they occur frequently enough that you can remember what they do after that.

The Clojure version is much more high level and less likely to introduce bugs.

Edit:

Oh and it should be said that "sum" is equivalent to partial(reduce, +) so I can now say:

map(sum, partition(7, 7, daily))

See? The code is just melting away before your eyes. Also note how I have literally no idea what either of the snippets do but am already happily changing one of them.


Just because you already happen to have a certain function at your disposal doesn't mean your language is suddenly superior.

  def partition(n, step, coll):
    for i in range(0, len(coll), step):
      yield coll[i:i+n]
allows

  weekly = [sum(week) for week in partition(7, 7, daily)]
Using Python's map() function you can even do

  map(sum, partition(7, 7, daily))
making it exactly the same as your example. And no, I probably haven't written more Python than you in my life.


Please consider my comment. Firstly, it was in response to this comment:

> That's pretty unreadable for someone who doesn't know clojure.

The real reason for commenting was to show that it is readable and yes, providing the "readable" Python equivalent.

There are two points - firstly, Clojure is (or is becoming?) a lazy language and the list type is different, so no they are definitely not exactly the same.

This brings us to a broader point in that even if you were to have laziness in Python it still wouldn't matter because I'm not the only coder in the world and there are a lot of Pythonists like the author of the article who do it the Pythonic way, which as already hinted, I think is just braindead.


I will not argue the first point, but as for the second one: how does that one author determine what is 'the Pythonic way'? I think

  [sum(week) for week in partition(7, 7, daily)]
is 'the Pythonic way' and I find that quite a bit easier to comprehend than

  map(sum, partition(7, 7, daily))
The reason for that is as simple as it runs counter to what people usually preach: it is less concise. In the former, it is immediately clear that you are partitioning a list of days into partitions of weeks and summing over those weeks, resulting in a list of weekly sums. The extra word 'week', repeated twice, makes all the difference: all ingredients for comprehension are readily provided. The latter case, on the contrary, requires you to do a few mental operations to expand the expression into something meaningful, mentally adding the concept of a 'week' to understand what the code is doing. You need to do that everytime you read the code, which makes it less easy to understand.


> Just because you already happen to have a certain function at your disposal doesn't mean your language is suddenly superior.

You are certainly correct in that. That's not what makes Lisps superior to all other languages though, "it's the syntax stupid."

Edit: Sorry, I know that comment appears trollish (and it is), what I meant to say is that unlike Python, Lisp(s) have virtually no syntax, and are more powerful because they treat code as data. It would take me a blog post to explain why that's important, but if you give the language a shot you will see why that is (and compare how long it takes you to learn it to how long it took you to learn Python!).


Isn't there more to power than that? For example, in clojure you can't change the binding of a function in a namespace after it has been compiled. In python or ruby you do have the power to do that.


I'm not a Clojure expert, so I can't directly address that, but from the little that I know of Clojure though, I think you can do that by binding a function to a var, and then changing the binding of the var. (Can any Clojure experts exlaborate?)

Regardless, every Lisp that I am able to comment on (newLISP, elisp, Scheme, CL) can do that easily, so I doubt that Clojure would have difficulty with this.


It does have difficulty with this, check the mailing list. Just because something using s-expressions doesn't mean you can override functions in a namespace.

http://groups.google.com/group/clojure/browse_thread/thread/...;


Thanks for that interesting thread! I do know though that newLISP can do this easily with a simple 'set' call.


That's pretty unreadable for someone who doesn't know clojure.

And that Python is pretty unreadable for someone who doesn't know Python.


That specific python example is very readable for someone who understands basic math (sets and functions). The clojure example, not so much.


That could be said for any language. It's just that the first language someone usually learns borrows more from algol than from lisp. This leads to the idea that Python/Ruby/PHP/Javascript are easier to learn than Clojure/Common Lisp/Scheme.


Python/Ruby/PHP/Javascript are easier to learn because most people already know a similar language. Just because it seems unfair doesn't mean it's not true.


Python and Ruby do one particular thing right that Smalltalk didn't:

Operator Precedence for Algebras.

Implementing an Algebra is a very important thing for a language to be good at. Being able to use algebras without having to switch mental gears is a good thing for scientists, mathematicians, and technical people of all stripes.

IMHO, the ability to easily implement your own algebra is a hallmark of a great language. Having that with the operator precedence is a bit of very justified syntactic sugar.


Algol languages are taught first for good reason: Algol-derived languages resemble English; Lisp isn't natural or intuitive to anyone who doesn't already know Lisp.


Oh, come on, folks. It's a perfectly reasonable comment -- Lisp is powerful and expressive, but it is not an intuitive language for beginners.


Perhaps it seems that way to you because you are more familiar with Algol syntax than Lisp syntax, or because you have gone on to learn the more advanced Lisp features. But Scheme syntax and semantics, for example, are arguably at least as simple as that of an Algol language. Scheme has been used successfully as a first programming language in high school computer science courses: http://www.teach-scheme.org/


You're making a bad assumption about my skill and preferences, and trying to use it as an argument. That's a logical fallacy. My argument doesn't depend on my personal experience: Algol-derived languages resemble English, and are therefore easier for new programmers to learn.

While I am sure that some high school courses may start with Scheme, it's certainly not a common beginner's language. I'm sure if I searched hard enough, I could find a high school class learning assembly -- but that doesn't make assembly a good beginner's language, either.


Yes, ALGOL-derived languages contain English words, and chunks of code can be read as English if you imagine the right words being inserted, but the same is true of Scheme code, and to about the same extent. In fact, it's true of most programming languages. The languages that it is most true of -- languages like Ada, Cobol, Inform, etc. -- are not notable as good beginners' languages.

Here, for example, is typical C code, right out of K&R:

  for (count = 0; count < MAX; count++)
    printf("\narr[%d] = %d.", count, arr[count]);
To read this in English, you need to fabricate a lot of words, like this: "Repeat for several times, first initializing count to zero, as long as count is less than MAX and, after each step, taking count and adding one to it: call the printf function with the arguments...". How is that exercise any worse for the equivalent PLT Scheme code?

  (for ([count (in-range 0 MAX)])
    (display (format "\narr[~a] = ~a." count (vector-ref arr count))))
An English translation of C's "while" statement is easier; the "switch" statement is harder; a C function declaration is nearly impossible without sounding awkward. Yes, actual ALGOL would be easier translate to English than C, but there are even less people starting with ALGOL than with your hypothetical assembler -- which suggests that the real reason people start with the languages they do is primarily because the languages are popular, not because of the degree of similarity to English.


> Possibly that should be partition-all from seq-utils

As of June 20th, there is now an optional padding argument in clojure.core/partition.


Good to know, thanks.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: