3 ms·

After people learn something they don't find it entirely cryptic any more, but that doesn't mean it isn't cryptic. No evidence that using map instead of loops

by pekk 13y ago

After people learn something they don't find it entirely cryptic any more, but that doesn't mean it isn't cryptic. No evidence that using map instead of loops "frees up brainpower."

porlw 13y ago
There are many common operations in programming, and it's worthwhile building a consistent syntax for them. Over time, as one layer of abstraction solidifies it's possible to see common patterns at the next level up. It saves brainpower because you you don't need to analyse the logic within the structure to understand what the operation is intended to produce. E.g. in the old days: 10 I=1 20 PRINT A[I] 30 I=I+1 40 IF I <= 10 THEN GOTO 20 You need to parse the logic to realise "Ah, this is a for loop". The I variable and the IF statement are bookkeeping code that doesn't have any relevance to the actual effect you're trying to produce. This construct is common enough that the for-loop was developed. Likewise with the if/else construct and others. The old fogeys would say "we don't need this structured programming nonsense, gotos are more flexible. I can easily look at this and understand what's going on". Structured programming is now widespread enough that we don't think of it as anything special, it's just part of "programming" in general. Now there are several common operations that we do when looping over a list of items. Things like maps, folds and gathers are just building another level on top of structured programming, hiding the bookkeeping code and making similar operation similar, so you can concentrate on the unique aspects of the program.
loup-vaillant 13y ago
What to you mean by "cryptic"? Something you struggle with? An abstraction? You're not used to maps, folds, and filters (the bulk of sequence comprehension), so they don't free up your brain power. But seriously, they're not complicated, and using them instead of regular loops often reduce the amount of code by a factor of 3 to 5. Simple code, where the same idioms come back over and over —just like in regular loops, only shorter. Don't tell me that doesn't free brainpower, eventually.
- emsy 13y ago
  Cryptic to me means that I have to translate (decrypt) the code in order to understand it. I have no problem when list comprehension is used to achieve a simple, single goal. But when I see whole algorithms implemented with list comprehension, I find that rather stupid. Amount of code is not my most important metric when writing code. Time is. I don't care if code is 3 to 5 times smaller when everybody that encounters it need 10 times longer to understand it.
  - loup-vaillant 13y ago
    Assembly was cryptic in the same sense: you had to translate it to get to the "real" machine code. Fortran was cryptic in the same sense: you had to perform even more complex translation to get to the "real" assembly. In other words, you're doing it wrong. You think in sequential terms, loops… and are translating list comprehension to that. Just don't. There are more direct ways. In a list comprehension, there's generally a filter part, and a map part. While they are interleaved during the execution, they are logically separate, and you should think of them that way. I once specified the processing of a sequence of data as a pipe of maps and filters. A colleague came to me and told "how can you waste all that memory, generating all those lists around?". Dude, this is a specification of the end result, not a computational model. Of course I won't generate 10 big arrays. Simply put, you need to separate the "what" from the "how".
- seanmcdirmid 13y ago
  Functional orgami is hella hard to debug. Their is a reason functional programming relies so heavily on equational reason and pure FP relies heavily on static typing: the alternative, actually debugging programmers, is so painful that you just want to avoid that at all costs. A loop is way easier to debug than a filter or a map, you just step through it. Who cares about code length? Haskell doesn't become a usable language until someone comes up with a decent dataflow debugger, if that's even possible.
  - icebraining 13y ago
    A loop is way easier to debug than a filter or a map, you just step through it. Why can't you just step through the function being called by map/filter? You set a breakpoint on the function and examine the values when it is called.

by pekk 13y ago

After people learn something they don't find it entirely cryptic any more, but that doesn't mean it isn't cryptic. No evidence that using map instead of loops "frees up brainpower."

porlw 13y ago

There are many common operations in programming, and it's worthwhile building a consistent syntax for them. Over time, as one layer of abstraction solidifies it's possible to see common patterns at the next level up. It saves brainpower because you you don't need to analyse the logic within the structure to understand what the operation is intended to produce. E.g. in the old days: 10 I=1 20 PRINT A[I] 30 I=I+1 40 IF I <= 10 THEN GOTO 20 You need to parse the logic to realise "Ah, this is a for loop". The I variable and the IF statement are bookkeeping code that doesn't have any relevance to the actual effect you're trying to produce. This construct is common enough that the for-loop was developed. Likewise with the if/else construct and others. The old fogeys would say "we don't need this structured programming nonsense, gotos are more flexible. I can easily look at this and understand what's going on". Structured programming is now widespread enough that we don't think of it as anything special, it's just part of "programming" in general. Now there are several common operations that we do when looping over a list of items. Things like maps, folds and gathers are just building another level on top of structured programming, hiding the bookkeeping code and making similar operation similar, so you can concentrate on the unique aspects of the program.

loup-vaillant 13y ago

What to you mean by "cryptic"? Something you struggle with? An abstraction? You're not used to maps, folds, and filters (the bulk of sequence comprehension), so they don't free up your brain power. But seriously, they're not complicated, and using them instead of regular loops often reduce the amount of code by a factor of 3 to 5. Simple code, where the same idioms come back over and over —just like in regular loops, only shorter. Don't tell me that doesn't free brainpower, eventually.

emsy 13y ago
Cryptic to me means that I have to translate (decrypt) the code in order to understand it. I have no problem when list comprehension is used to achieve a simple, single goal. But when I see whole algorithms implemented with list comprehension, I find that rather stupid. Amount of code is not my most important metric when writing code. Time is. I don't care if code is 3 to 5 times smaller when everybody that encounters it need 10 times longer to understand it.
- loup-vaillant 13y ago
  Assembly was cryptic in the same sense: you had to translate it to get to the "real" machine code. Fortran was cryptic in the same sense: you had to perform even more complex translation to get to the "real" assembly. In other words, you're doing it wrong. You think in sequential terms, loops… and are translating list comprehension to that. Just don't. There are more direct ways. In a list comprehension, there's generally a filter part, and a map part. While they are interleaved during the execution, they are logically separate, and you should think of them that way. I once specified the processing of a sequence of data as a pipe of maps and filters. A colleague came to me and told "how can you waste all that memory, generating all those lists around?". Dude, this is a specification of the end result, not a computational model. Of course I won't generate 10 big arrays. Simply put, you need to separate the "what" from the "how".
seanmcdirmid 13y ago
Functional orgami is hella hard to debug. Their is a reason functional programming relies so heavily on equational reason and pure FP relies heavily on static typing: the alternative, actually debugging programmers, is so painful that you just want to avoid that at all costs. A loop is way easier to debug than a filter or a map, you just step through it. Who cares about code length? Haskell doesn't become a usable language until someone comes up with a decent dataflow debugger, if that's even possible.
- icebraining 13y ago
  A loop is way easier to debug than a filter or a map, you just step through it. Why can't you just step through the function being called by map/filter? You set a breakpoint on the function and examine the values when it is called.