3 ms·

> Those 10 lines can be 10 lines of assembly, 10 lines of c++ or 10 lines of haskell. I seriously doubt the validity of this. 10 lines of assembly is usually r

> Those 10 lines can be 10 lines of assembly, 10 lines of c++ or 10 lines of haskell. I seriously doubt the validity of this. 10 lines of assembly is usually reasonably clear-cut what is about. 10 lines of Haskell can take hours of mindfuck trying to peer through the functor and monad operators, trying to work out which operation does what and which operator takes precedence where. And then you need to start worrying about which data-type are you actually working on. And how does that type implement lift and bind. Etc etc. Basically 10 seems like a BS number taken out of thin air, because it looks good in a base 0x0a number-system.

Jtsummers 11y ago
The origin of this idea, for my first introduction I guess, was in The Mythical Man Month. I don't have a copy at hand, so I can't read what Fred Brooks wrote specifically. 10 is very precise, but really the writing was about the order of magnitude that people can manage in a day. It's about the level of complexity involved. 10 lines of assembly is very clear about what exactly is happening. It's a sequence of adds, loads, branches, stores, moves, etc. Each step is incredibly clear, but what are they operating on? Now it's not so clear. What is R2 at this point in the program? Am I calling a subroutine? On this architecture is there some way to automatically handle this with storing the PC and everything, or am I going to use a regular branch instruction? Regular branch? Ok, now I'm storing the PC and other information away per our calling convention. C: Oh, I'm calling a function. I'm calculating a formula. I have named variables, so it's clear what I'm operating on (hopefully, this is at least possible here, even if not well done in practice). With typedefs, good naming conventions, structs and enums, you can maintain an order of magnitude greater complexity in the same time as an assembly programmer, in an order of magnitude lower amount of code. Haskell: I have functions, I have types, I operate over these types transforming them from one to another. Collecting objects of a type here, transforming them there, zipping them with those, and back again. And I've written a function that would take dozens of lines of C or grosses of lines of assembly, and it took me an hour. Again, an order of magnitude more complexity can be entertained in another order of magnitude less code. Don't get stuck on the specific number, that's incredibly pedantic and unhelpful. It's about the degree and magnitude.
codygman 11y ago
> 10 lines of Haskell can take hours of mindfuck trying to peer through the functor and monad operators, Please stop. Can you even come up with one example that supports this? Alright, now how about 10 lines from a "real world"* Haskell project. *real world meaning has at least 1 user besides it's developer
- saurik 11y ago
  I think the more important counter-argument is "that ten lines of assembly just barely did one thing; the ten lines of Haskell was most of the program: clearly it will be easier for you to understand a single wire or switch than to understand an entire computer, but that isn't a valuable insight".
  - codygman 11y ago
    Hyperbole (if that is what the commenter was using and didn't seriously think it) should be used carefully when it reinforces stereotypes that are so damaging.

Jtsummers 11y ago

The origin of this idea, for my first introduction I guess, was in The Mythical Man Month. I don't have a copy at hand, so I can't read what Fred Brooks wrote specifically. 10 is very precise, but really the writing was about the order of magnitude that people can manage in a day. It's about the level of complexity involved. 10 lines of assembly is very clear about what exactly is happening. It's a sequence of adds, loads, branches, stores, moves, etc. Each step is incredibly clear, but what are they operating on? Now it's not so clear. What is R2 at this point in the program? Am I calling a subroutine? On this architecture is there some way to automatically handle this with storing the PC and everything, or am I going to use a regular branch instruction? Regular branch? Ok, now I'm storing the PC and other information away per our calling convention. C: Oh, I'm calling a function. I'm calculating a formula. I have named variables, so it's clear what I'm operating on (hopefully, this is at least possible here, even if not well done in practice). With typedefs, good naming conventions, structs and enums, you can maintain an order of magnitude greater complexity in the same time as an assembly programmer, in an order of magnitude lower amount of code. Haskell: I have functions, I have types, I operate over these types transforming them from one to another. Collecting objects of a type here, transforming them there, zipping them with those, and back again. And I've written a function that would take dozens of lines of C or grosses of lines of assembly, and it took me an hour. Again, an order of magnitude more complexity can be entertained in another order of magnitude less code. Don't get stuck on the specific number, that's incredibly pedantic and unhelpful. It's about the degree and magnitude.

codygman 11y ago

> 10 lines of Haskell can take hours of mindfuck trying to peer through the functor and monad operators, Please stop. Can you even come up with one example that supports this? Alright, now how about 10 lines from a "real world"* Haskell project. *real world meaning has at least 1 user besides it's developer

saurik 11y ago
I think the more important counter-argument is "that ten lines of assembly just barely did one thing; the ten lines of Haskell was most of the program: clearly it will be easier for you to understand a single wire or switch than to understand an entire computer, but that isn't a valuable insight".
- codygman 11y ago
  Hyperbole (if that is what the commenter was using and didn't seriously think it) should be used carefully when it reinforces stereotypes that are so damaging.