6 ms·
I really disagree that composition is error prone. It makes it easier to test and isolate errors by easily allowing different implementations along the pipeline
by cultus 6y ago
I really disagree that composition is error prone. It makes it easier to test and isolate errors by easily allowing different implementations along the pipeline. You get abstraction and it's less error-prone. Abstraction usually is a win for reliability, because abstraction means less information and less entropy.
- nendroid 6y agoHe used javascript so he's probably talking about composition without type checking. But yes more important then just composition is to use combinators and segregate your combinators from IO.
- marcosdumay 6y agoNotice that the post is written in Javascript. Abstraction and composition are great to surface the main characteristics of your algorithm. A compiler then can take those characteristics and verify if they make sense. Different compilers can do that in different amounts, and the Javascript one does the absolute minimum possible. On this case, you get no safety, just more complex code. Go ask a Haskell developer and the first reaction you will get is probably "wait, you were running getData inside the original function?!"
- remexre 6y ago> Go ask a Haskell developer and the first reaction you will get is probably "wait, you were running getData inside the original function?!" Haskell developer here, this was indeed my first reaction :P
- tluyben2 6y agoIt would be more interesting to see these things in multiple languages so it shows how it would be done (best) in those. Learning things js centered is is not good for everyone.
- stopachka 6y agoHey team, author here: I agree with the statement that composition won't make the code unreliable. When I wrote mistake, the kind of mistake I was referring too was a mistake in abstraction boundaries, rather than execution. (for an extreme case consider a DSL: if you abstract a DSL from only one example, you'd likely get the core abstractions wrong)