5 ms·

> Data Structures Are Antithetical to Functional Programming Interestingly I've heard a similar pov from the 'pure OO' (Smalltalk style) world as well. Specifi

> Data Structures Are Antithetical to Functional Programming Interestingly I've heard a similar pov from the 'pure OO' (Smalltalk style) world as well. Specifically avoiding 'data structures' and embracing late binding.

jcelerier 9y ago
And both styles lead to equally unreadable code. If you can't take an average new graduate, put it in front of your code and have him be productive in your codebase in a few days it's no good.
- dmit 9y ago
  An average new graduate wouldn't be productive in any codebase in a few days. And even if they were, that's a terribly low bar to set. Software development education sucks and most people have to learn on the job. So why not teach them ways to write more reliable and maintainable code.
  - Tarean 9y ago
    That is probably good advice but this style of coding (which comes down to lawless type classes without inherent utility) does make it much more difficult to read unknown code. Usually documentation isn't fleshed out in internal modules so I end up flipping between various instances and call sides just to figure out what the type class is supposed to do. This doesn't mean that there aren't valid use cases for this but please don't use it as default.
- runeks 9y ago
  > If you can't take an average new graduate, put it in front of your code and have him be productive in your codebase in a few days it's no good. So if a piece of code for securely transferring funds from one back account to another is not readable by a new graduate in a few days, it's no good? Should we remove safety abstractions from this code safe in order for the new graduate to be able to understand it in a week? A large part of software is safety-critical. How can you argue that safe abstractions, which reduce or eliminate faults, are not worth it if they can't be learned in a week or so? You wouldn't happen to work as an Equifax code-reviewer, would you?
- philipov 9y ago
  Sounds like you have a bias for hiring inexperienced, cheep developers, and not providing them with any mentoring.
- shalabhc 9y ago
  > And both styles lead to equally unreadable code. Perhaps because the languages used aren't a good fit for these styles?
bluetech 9y ago
On the other hand, from Linus Torvalds: > I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. https://lwn.net/Articles/193245/ https://lwn.net/Articles/193245/
- chriswarbo 9y ago
  I don't think Torvalds' quote applies in this case: it's not really "killing datastructures", so much as "using abstract datastructures"; i.e. it's like programming to an interface rather than a concrete instance. In fact, that's exactly what it is, since he's using typeclasses (which can be thought of as a sort of interface). We could achieve a similar thing with existential types (AKA modules). I understood the Torvalds quote as being more like: would it be worse if some chunk of your library code disappeared, or if some chunk of your datastructures disappeared? If it's the former, then your library functions are "too smart", i.e. they're probably doing non-obvious things to their inputs. If it's the latter, then the data is more "self-describing". Note that I use the phrase "library functions", since (first-class) functions are a perfectly good way to represent data (e.g. Church encoding and its variants).
  - barrkel 9y ago
    First-class functions can perfectly represent data, but that doesn't mean they're a perfectly good way to represent data. For example, if you use Church encoding for your numbers, how do you do static analysis of bounds checking? If you implement if-statements by passing two functions to a function which calls one or the other for truth and falsity, how do you determine dead code at compile time? You just move a bunch of problems from compile time to run time, where they're harder to reason about, in most Turing-complete languages.
    - shalabhc 9y ago
      > move a bunch of problems from compile time to run time Perhaps this is an artificial dichotomy? What we really want is verification that some properties hold. These properties should be specified in a uniform way, irrespective of the time that the check can apply. When I specify a property, why do I have to also pick the time - 'run time' or 'compile time' and why the language used to specify exactly the same property is so different in each case? I think there is some unnecessary conflation here.

jcelerier 9y ago

And both styles lead to equally unreadable code. If you can't take an average new graduate, put it in front of your code and have him be productive in your codebase in a few days it's no good.

dmit 9y ago
An average new graduate wouldn't be productive in any codebase in a few days. And even if they were, that's a terribly low bar to set. Software development education sucks and most people have to learn on the job. So why not teach them ways to write more reliable and maintainable code.
- Tarean 9y ago
  That is probably good advice but this style of coding (which comes down to lawless type classes without inherent utility) does make it much more difficult to read unknown code. Usually documentation isn't fleshed out in internal modules so I end up flipping between various instances and call sides just to figure out what the type class is supposed to do. This doesn't mean that there aren't valid use cases for this but please don't use it as default.
runeks 9y ago
> If you can't take an average new graduate, put it in front of your code and have him be productive in your codebase in a few days it's no good. So if a piece of code for securely transferring funds from one back account to another is not readable by a new graduate in a few days, it's no good? Should we remove safety abstractions from this code safe in order for the new graduate to be able to understand it in a week? A large part of software is safety-critical. How can you argue that safe abstractions, which reduce or eliminate faults, are not worth it if they can't be learned in a week or so? You wouldn't happen to work as an Equifax code-reviewer, would you?
philipov 9y ago
Sounds like you have a bias for hiring inexperienced, cheep developers, and not providing them with any mentoring.
shalabhc 9y ago
> And both styles lead to equally unreadable code. Perhaps because the languages used aren't a good fit for these styles?

bluetech 9y ago

On the other hand, from Linus Torvalds: > I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. https://lwn.net/Articles/193245/ https://lwn.net/Articles/193245/

chriswarbo 9y ago
I don't think Torvalds' quote applies in this case: it's not really "killing datastructures", so much as "using abstract datastructures"; i.e. it's like programming to an interface rather than a concrete instance. In fact, that's exactly what it is, since he's using typeclasses (which can be thought of as a sort of interface). We could achieve a similar thing with existential types (AKA modules). I understood the Torvalds quote as being more like: would it be worse if some chunk of your library code disappeared, or if some chunk of your datastructures disappeared? If it's the former, then your library functions are "too smart", i.e. they're probably doing non-obvious things to their inputs. If it's the latter, then the data is more "self-describing". Note that I use the phrase "library functions", since (first-class) functions are a perfectly good way to represent data (e.g. Church encoding and its variants).
- barrkel 9y ago
  First-class functions can perfectly represent data, but that doesn't mean they're a perfectly good way to represent data. For example, if you use Church encoding for your numbers, how do you do static analysis of bounds checking? If you implement if-statements by passing two functions to a function which calls one or the other for truth and falsity, how do you determine dead code at compile time? You just move a bunch of problems from compile time to run time, where they're harder to reason about, in most Turing-complete languages.
  - shalabhc 9y ago
    > move a bunch of problems from compile time to run time Perhaps this is an artificial dichotomy? What we really want is verification that some properties hold. These properties should be specified in a uniform way, irrespective of the time that the check can apply. When I specify a property, why do I have to also pick the time - 'run time' or 'compile time' and why the language used to specify exactly the same property is so different in each case? I think there is some unnecessary conflation here.