5 ms·

bottom up programming is actually what a lot of jr developers do when starting out their careers and i would advise against it. a top-down approach would be cl

bottom up programming is actually what a lot of jr developers do when starting out their careers and i would advise against it. a top-down approach would be clean and simple and the complexities are hidden away from interface: User.create(data) whereas, a bottom-up would be look like you just hacked things on top of each other: create_user( validate_user_data(format_user_data(data) ) ) but, i do know lisp kinda forces you to code that way, so pg's article may have a lot to do with that.

lambdamn 8y ago
You can still do something like User.create(data) using a bottom up approach in designing the interface. If we had a module User, we could do something like (using Haskell syntax, since that's the functional language I know): create = User (validate . format $ data) Only the create function needs be exposed, but the useful bit is that the create function is built out of the composition of smaller functions which makes it easy to change or completely swap out a component of the whole process. A top-down User.create function would likely be a rather large, monolithic chunk of code.
quikoa 8y ago
Interesting, I got the exact opposite experience with junior developers. They often try to design a system top-down. Fail to do so well enough because they don't have enough experience from the bottom up.
- deleted 8y ago
  [deleted]
- sriku 8y ago
  Concur. Same experience. And I did the same mistakes when I was one of them junior devs too :)
  - quikoa 8y ago
    Yes me too and so many times!
lioeters 8y ago
Interesting that your two examples would be called: object-oriented ("top-down") and functional ("bottom-up"). After a lifetime of programming, I actually prefer the latter approach: composing functions that are without side effects and independently testable. I'm not sure if your examples reflect the top-down/bottom-up concepts in the original article, and certain don't agree that "a lot of jr developers" prefer the bottom-up approach, or that it looks "hacked on top of each other". Maybe it's just personal preference..
- yen223 8y ago
  Yeah, I second the preference for the latter approach. It encourages more reusable components - you get to use `format_user_data` in situations which don't require data validation, for example. The one downside is the second style of code is a little uglier in languages without a good function composition operator, like Python. I enjoy writing stuff like user = data |> format_user_data |> validate_user_data in languages that support the pipeline operator.

lambdamn 8y ago

You can still do something like User.create(data) using a bottom up approach in designing the interface. If we had a module User, we could do something like (using Haskell syntax, since that's the functional language I know): create = User (validate . format $ data) Only the create function needs be exposed, but the useful bit is that the create function is built out of the composition of smaller functions which makes it easy to change or completely swap out a component of the whole process. A top-down User.create function would likely be a rather large, monolithic chunk of code.

quikoa 8y ago

Interesting, I got the exact opposite experience with junior developers. They often try to design a system top-down. Fail to do so well enough because they don't have enough experience from the bottom up.

deleted 8y ago
[deleted]
sriku 8y ago
Concur. Same experience. And I did the same mistakes when I was one of them junior devs too :)
- quikoa 8y ago
  Yes me too and so many times!

lioeters 8y ago

Interesting that your two examples would be called: object-oriented ("top-down") and functional ("bottom-up"). After a lifetime of programming, I actually prefer the latter approach: composing functions that are without side effects and independently testable. I'm not sure if your examples reflect the top-down/bottom-up concepts in the original article, and certain don't agree that "a lot of jr developers" prefer the bottom-up approach, or that it looks "hacked on top of each other". Maybe it's just personal preference..

yen223 8y ago
Yeah, I second the preference for the latter approach. It encourages more reusable components - you get to use `format_user_data` in situations which don't require data validation, for example. The one downside is the second style of code is a little uglier in languages without a good function composition operator, like Python. I enjoy writing stuff like user = data |> format_user_data |> validate_user_data in languages that support the pipeline operator.