11–20 of 59 posts
Heh, all of these points could easily be applied to Python as well. All the concepts are there in addition to the for loop. It's nice how you can do a lot of functional programming in Python with these simple tools (map, filter and reduce (Haskell's foldl). I wonder why there aren't more people advocating the use of these functions in Python programs instead of for loops.
Heh, all of these points could easily be applied to Python as well. All the concepts are there in addition to the for loop. It's nice how you can do a lot of functional programming in Python with these simple tools (map, filter and reduce (Haskell's foldl). I wonder why there aren't more people advocating the use of these functions in Python programs instead of for loops.
Java's younger cousin C# also has this with Select, Where and Aggregate. But sometimes the foreach and even the for loop actually makes more sense, in particular when dealing with very imperative algorithms or are not acting over a (full) sequence at all. I'm usually only reading and not writing python but I think list comprehensions are more idiomatic. Based on some comments I've seen here I also kind of get the imp…
We prefer the terms:
"brother by a different mother"
or if they're being naughty:
"red headed step-child".
Heh, all of these points could easily be applied to Python as well. All the concepts are there in addition to the for loop. It's nice how you can do a lot of functional programming in Python with these simple tools (map, filter and reduce (Haskell's foldl). I wonder why there aren't more people advocating the use of these functions in Python programs instead of for loops.
For example, I have nothing against the code like this:
if any(foo.is_cond for foo in foos):
do(bar)
It may work better in ML-derived functional languages because function definitions there, both anonymous and named, are extremely lightweight. This part of the language is highly optimized by necessity as high order functions is the only way to express iteration and other control flow constructs. But in Python, though not particularly heavyweight, function definitions don't mix well with regular code.
Also I'm not sure if the author is completely fair with his loop example. Add a few local variables, `break` or `continue`, and the high order form may actually become less intuitive.
String s = "";
for (int i = 0; i s += array[i] + "\t";
My next thought was "what happens if there are no args?" E.g. args.length returns 0, and they try to access the first element in the list (due to heritage from c pointers we start counting at 0) which is the 'zeroth' one, which doesn't exist... it should throw an array out of bounds exception.
-----
The reason I ask, is that based on the comments, the people reading the blog think the problem is in the operator overloading. Are they expecting this iteration through the args list to sum the args, and then assign the sum to the string?
If so, then I don't see how the bug could remain undetected:
"it could take weeks to get a bug report, and weeks more to get a fix ready"
Whereas in the unlikey event that I'm right, I still don't see how it would be hard to fix?
What am I missing?
A closure is an runtime structure used to implement static scope of locally-defined first-class functions. Closures allow locally-defined functions to "remember" variable bindings in their enclosing scope.
Beside that you can implement this feature WITHOUT closures (e.g. source rewriting), none of the examples presented actually require static scope!!
It boggles my mind that programmers can have such strong opinions on language features without actually knowing what they're called.
Colour me stupid, but in the article it gives this code as having some horrible hard to find bug: String s = ""; for (int i = 0; i Now, as soon as I looked at that I immediately thought "well, they're not putting anything in between the params when they concatenate them", e.g. I would expect to see: s += array[i] + "\t"; (or a comma or newline instead of a tab) My next thought was "what happens if there are no args?"…
I feel this post is more an argument for first class functions than closures. It is true that much of the usefulness of first class functions is lost without closures, so having useful first class function almost necessitates (though does not guarantee) closures. But in none of the examples is the key attribute of closing over free variables emphasized, which is the powerful and dangerous part. A simple example showi…
It is a much weaker argument for adding summation, since you'd have to get into the down and dirty details of whatever operation your summation represents, e.g. is it associative? You can see how it get ugly fast in the discussion about the differences between foldl and foldr (presumably fold-left and fold-right respectively)
----
Now, Java had filtering in one of the libraries, I remember using filtering with folder operations many moons ago, so it's not like you can't roll your own. Likewise with a "do this thing to everything in the list" operation.
For loops have a use, specifically when you want to do things in a particular order. Reading lines from a file for instance you might want the lines you're putting into your data structure to be in the same order as they are in the file (as a specific counter-example, I once wrote a 'unique line' app where it didn't care about the ordering, of course if I'd been on unix there would have been some command line tool to do it for me, but it was fun and fast to write and hand tuning the grep would have been a PITA)
BUT, there are a lot of tiems I've used for loops where the sequential nature of the loop is irrelevant, and here I could see someone making an argument that the for loop is clumsy and random (from the article they object because it uses too many tokens! The horror! :D )
I could also see someone making the counter-argument that what that actually means is that the for loop is powerful (never mind that we have no objective standard for what that means. Perhaps 'powerful' in the sense of 'easy to blow your own foot off with' would fit here :D )
Colour me stupid, but in the article it gives this code as having some horrible hard to find bug: String s = ""; for (int i = 0; i Now, as soon as I looked at that I immediately thought "well, they're not putting anything in between the params when they concatenate them", e.g. I would expect to see: s += array[i] + "\t"; (or a comma or newline instead of a tab) My next thought was "what happens if there are no args?"…
There is no check that array[i] actually exists. If array[] has 2 items but args[] has 5, you will overflow the array.
I was mentally substituting args[i] for array[i]
Talk about code blindness. What a colossal blunder.
Colour me stupid, but in the article it gives this code as having some horrible hard to find bug: String s = ""; for (int i = 0; i Now, as soon as I looked at that I immediately thought "well, they're not putting anything in between the params when they concatenate them", e.g. I would expect to see: s += array[i] + "\t"; (or a comma or newline instead of a tab) My next thought was "what happens if there are no args?"…
There is no check that array[i] actually exists. If array[] has 2 items but args[] has 5, you will overflow the array.
' String s = ""; for (int i = 0; i I deduce from this that the error was in the copy/paste. The line that was supposed to be changed to 's+= args[i]' was accidentally left as 's+= array[i]'
As such, its a simple failure to replace all instances of 'array' in the pasted code, rather than anything to do with 'operator overloading', or even to do with checking if 'array[i]' was out of bounds - there is simply no variable 'array' supposed to be in that context.
I wish Turoff had been less obtuse about it, especially as the original Elliotte post seems to have been silently updated.