4 ms·

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),

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.
  - seanmcdirmid 13y ago
    Sometimes you don't have a line to break on, sometimes the code that is actually mapping and filtering is very generic and used in lots of places, sometimes you simply lack out per context when the break occurs because of laziness. When control flow becomes more indirect, debugging becomes more difficult, and functional orgami is all about making control flow indirect to rather emphasize dataflow. Someday, someone might discover how to do good dataflow debuggers that could work well for time-intensive (read: stateful) programs, and in that case, I would be happy to indirect my control flow a lot more than I do. But no one has figured out how to really do that yet.
    - loup-vaillant 13y ago
      Here is my guess: debuggers aren't the answer. We need to look somewhere else.
- infruset 13y ago
  I don't agree with this. Usually, the typing does half the debugging for you and when you have a real bug (as in, the program does something but not what you intended), you debug at the reasoning level, not at the "is there an overflow here?" level.

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.
- seanmcdirmid 13y ago
  Sometimes you don't have a line to break on, sometimes the code that is actually mapping and filtering is very generic and used in lots of places, sometimes you simply lack out per context when the break occurs because of laziness. When control flow becomes more indirect, debugging becomes more difficult, and functional orgami is all about making control flow indirect to rather emphasize dataflow. Someday, someone might discover how to do good dataflow debuggers that could work well for time-intensive (read: stateful) programs, and in that case, I would be happy to indirect my control flow a lot more than I do. But no one has figured out how to really do that yet.
  - loup-vaillant 13y ago
    Here is my guess: debuggers aren't the answer. We need to look somewhere else.
infruset 13y ago
I don't agree with this. Usually, the typing does half the debugging for you and when you have a real bug (as in, the program does something but not what you intended), you debug at the reasoning level, not at the "is there an overflow here?" level.