5 ms·

> I divide and conquer and get things done. I had the same insight after many years like the author - that every problem you do can be broken down into smaller

> I divide and conquer and get things done. I had the same insight after many years like the author - that every problem you do can be broken down into smaller problems, which can be worked independently and tested independently. Why it wasn't obvious to me early-on I have no idea. I guess I never developed the intuition to see the efficiency of the method. Did anyone else among you had the same experience?

nickff 10y ago
You are essentially describing 'test driven development', and many of us have either been taught the methodology, or stumbled on to it.[1] [1] https://en.wikipedia.org/wiki/Test-driven_development https://en.wikipedia.org/wiki/Test-driven_development
- AnimalMuppet 10y ago
  No, abc_lisper is describing decomposition of the problem. That may or may not be implemented in a TDD environment; it may not even involve tests at all.
  - nickff 10y ago
    abc_lisper specifically said: "every problem you do can be broken down into smaller problems, which can be worked independently and tested independently". Unless you delete or ignore "and tested" from that post, abc_lisper's approach definitely involves tests.
    - AnimalMuppet 10y ago
      I stand corrected; what abc_lisper said definitely involves tests. That's not necessarily TDD, though; see my post at https://news.ycombinator.com/item?id=13465459 https://news.ycombinator.com/item?id=13465459 for the difference.
      - nickff 10y ago
        I agree that abc_lisper did not 'exactly' describe test driven development, which is why I said he 'essentially' described test driven development. I am a believer in test driven development, yet I often write a bit of application code before I write the tests; I acknowledge that probably makes me a pariah, but I still keep tests (and TDD) in mind.
        AnimalMuppet 10y ago
        Meh, I think TDD has value, but I don't think a methodology should become a religion. Write a bit of application before your tests, write most of the tests before the code, you're good to call it TDD in my book. (Of course, being non-religious about methodology may make me a pariah, and not just on TDD; but I can't work up the energy to care...)
    - thibauts 10y ago
      Testing does not automatically imply automated tests. I do break down problems and follow the same kind of process, yet my goal is less automated testing than it is raw flexibility, ability to recombine pieces of code at will and move fast. Chasing automated tests, even if it supposedly yields this kind of composite constructs is in my opinion taking an interesting side-effect of good craft for an end in itself. Then of course, saying the code can be tested in isolation doesn't imply coding is driven by tests. TDD, in my opinion, like all idols in the history of cults is, as an end, the dawn of critical thinking and progress.
  - abc_lisper 10y ago
    I agree decomposing and testing go hand-in-hand, but it wasn't even apparent to me decomposition is the way to go. I guess I didn't know it is possible to design solutions to problems while breaking them down. Btw, I discovered (He hee) testing of modules independently very shortly after I found out about decomposing.
deleted 10y ago
[deleted]
leshow 10y ago
I agree, but I have an alternate intuition. Humans are only able to understand anything through decomposition to smaller problems, working out those problems, then recomposing to a whole again. This is evident not just in software development, but in everything. At some point you have to ask yourself: If this "decomposition" hammer is the only tool we have to use in the world, it's no surprise that everything looks like a nail.
- abc_lisper 10y ago
  > At some point you have to ask yourself: If this "decomposition" hammer is the only tool we have to use in the world, it's no surprise that everything looks like a nail. Agreed! I think this is why it was not intuitive to me. I was (reasonably) good at math in school, but I never tried to decompose the problem. I always tried to get a feel of the problem by looking at it from various angles and get the crux of the problem. That's the best I can say about my thinking method then.
  - kazinator 10y ago
    That makes sense. The thing about decomposition is that there is more than one (a toolbox with multiple hammers). So even if you decompose, you have to look at multiple angles before you choose a decomposition.
khedoros1 10y ago
I remember early on in my programming education having subroutines pounded into my head. I learned them grudgingly, because nothing that I'd written so far was complex enough to need them. It was always simpler to just write my <100 line program without any functions/subroutines. Things got more complex. Named subroutines started seeming logical to encapsulate certain behaviors. Eventually, it became natural to think "I wish this part of the program were separated out and implemented elsewhere, so that I could treat it as a solved problem." That's about the point where a divide-and-conquer approach started occurring to me, at least in a limited context. That context expanded over time.
bpchaps 10y ago
I definitely had that same experience. I've been writing code like that for about 15 years now and it's only started changing over the past two years or so. I think it stems from a few reasons - 1. I have a tendency to fix small problems that only need a one-time fix. So, lots of code, but disposable and messy. 2. HS programming classes lacked a lot of the meta stuffs, like refactoring, working in groups, etc. 3. Most of my coding years have been spent in a terminal where a combination of awk, sed, grep, xargs, etc works perfectly fine. A non-trivial number of problems can be solved that way, but it hits a wall pretty quickly. For the past few months, I've been writing a lot of Clojure and have found that it fits my mental model significantly better than Python, C, etc. What's interesting is that all other languages I code in have dramatically improved ever since Clojure "clicked". Hell, even my bash-fu has become cleaner, terser, faster and more bug free. Funny how that works..
- abc_lisper 10y ago
  Hey, I'm currently using Clojure too and I feel the same way! I think the reason it feels more natural is its emphasis on process instead of things. You think of computation as series of transformations, and that makes easy to establish causal relationships among events and thus help reason better about the system. (I think Steve Yegge first complained about Java, that it is a land of nouns) I think the failing of OOP for me is that I never got what an object is! To me, an object always felt like a weird plane in a n-dimensional axes(because an object contains other objects), and it was hard to reason about that. For example, my first (atleast in my latent consciousness) reaction about Abstract classes was, what is it abstract about? If it is abstract about a bunch of things, that are only related because of the flow of code, I guess I wasn't smart enough to crack that effectively.
antfarm 10y ago
That is only easy if the overall architecture has already been taken care of by someone else.

nickff 10y ago

You are essentially describing 'test driven development', and many of us have either been taught the methodology, or stumbled on to it.[1] [1] https://en.wikipedia.org/wiki/Test-driven_development https://en.wikipedia.org/wiki/Test-driven_development

AnimalMuppet 10y ago
No, abc_lisper is describing decomposition of the problem. That may or may not be implemented in a TDD environment; it may not even involve tests at all.
- nickff 10y ago
  abc_lisper specifically said: "every problem you do can be broken down into smaller problems, which can be worked independently and tested independently". Unless you delete or ignore "and tested" from that post, abc_lisper's approach definitely involves tests.
  - AnimalMuppet 10y ago
    I stand corrected; what abc_lisper said definitely involves tests. That's not necessarily TDD, though; see my post at https://news.ycombinator.com/item?id=13465459 https://news.ycombinator.com/item?id=13465459 for the difference.
    - nickff 10y ago
      I agree that abc_lisper did not 'exactly' describe test driven development, which is why I said he 'essentially' described test driven development. I am a believer in test driven development, yet I often write a bit of application code before I write the tests; I acknowledge that probably makes me a pariah, but I still keep tests (and TDD) in mind.
      - AnimalMuppet 10y ago
        Meh, I think TDD has value, but I don't think a methodology should become a religion. Write a bit of application before your tests, write most of the tests before the code, you're good to call it TDD in my book. (Of course, being non-religious about methodology may make me a pariah, and not just on TDD; but I can't work up the energy to care...)
  - thibauts 10y ago
    Testing does not automatically imply automated tests. I do break down problems and follow the same kind of process, yet my goal is less automated testing than it is raw flexibility, ability to recombine pieces of code at will and move fast. Chasing automated tests, even if it supposedly yields this kind of composite constructs is in my opinion taking an interesting side-effect of good craft for an end in itself. Then of course, saying the code can be tested in isolation doesn't imply coding is driven by tests. TDD, in my opinion, like all idols in the history of cults is, as an end, the dawn of critical thinking and progress.
- abc_lisper 10y ago
  I agree decomposing and testing go hand-in-hand, but it wasn't even apparent to me decomposition is the way to go. I guess I didn't know it is possible to design solutions to problems while breaking them down. Btw, I discovered (He hee) testing of modules independently very shortly after I found out about decomposing.

deleted 10y ago

[deleted]

leshow 10y ago

I agree, but I have an alternate intuition. Humans are only able to understand anything through decomposition to smaller problems, working out those problems, then recomposing to a whole again. This is evident not just in software development, but in everything. At some point you have to ask yourself: If this "decomposition" hammer is the only tool we have to use in the world, it's no surprise that everything looks like a nail.

abc_lisper 10y ago
> At some point you have to ask yourself: If this "decomposition" hammer is the only tool we have to use in the world, it's no surprise that everything looks like a nail. Agreed! I think this is why it was not intuitive to me. I was (reasonably) good at math in school, but I never tried to decompose the problem. I always tried to get a feel of the problem by looking at it from various angles and get the crux of the problem. That's the best I can say about my thinking method then.
- kazinator 10y ago
  That makes sense. The thing about decomposition is that there is more than one (a toolbox with multiple hammers). So even if you decompose, you have to look at multiple angles before you choose a decomposition.

khedoros1 10y ago

I remember early on in my programming education having subroutines pounded into my head. I learned them grudgingly, because nothing that I'd written so far was complex enough to need them. It was always simpler to just write my <100 line program without any functions/subroutines. Things got more complex. Named subroutines started seeming logical to encapsulate certain behaviors. Eventually, it became natural to think "I wish this part of the program were separated out and implemented elsewhere, so that I could treat it as a solved problem." That's about the point where a divide-and-conquer approach started occurring to me, at least in a limited context. That context expanded over time.

bpchaps 10y ago

I definitely had that same experience. I've been writing code like that for about 15 years now and it's only started changing over the past two years or so. I think it stems from a few reasons - 1. I have a tendency to fix small problems that only need a one-time fix. So, lots of code, but disposable and messy. 2. HS programming classes lacked a lot of the meta stuffs, like refactoring, working in groups, etc. 3. Most of my coding years have been spent in a terminal where a combination of awk, sed, grep, xargs, etc works perfectly fine. A non-trivial number of problems can be solved that way, but it hits a wall pretty quickly. For the past few months, I've been writing a lot of Clojure and have found that it fits my mental model significantly better than Python, C, etc. What's interesting is that all other languages I code in have dramatically improved ever since Clojure "clicked". Hell, even my bash-fu has become cleaner, terser, faster and more bug free. Funny how that works..

abc_lisper 10y ago
Hey, I'm currently using Clojure too and I feel the same way! I think the reason it feels more natural is its emphasis on process instead of things. You think of computation as series of transformations, and that makes easy to establish causal relationships among events and thus help reason better about the system. (I think Steve Yegge first complained about Java, that it is a land of nouns) I think the failing of OOP for me is that I never got what an object is! To me, an object always felt like a weird plane in a n-dimensional axes(because an object contains other objects), and it was hard to reason about that. For example, my first (atleast in my latent consciousness) reaction about Abstract classes was, what is it abstract about? If it is abstract about a bunch of things, that are only related because of the flow of code, I guess I wasn't smart enough to crack that effectively.

antfarm 10y ago

That is only easy if the overall architecture has already been taken care of by someone else.