3 ms·

I think not letting you encode relational, functional and domain-specific higher level thinking is by design. I review a lot of code, and have been programming

by t8sr 5y ago

I think not letting you encode relational, functional and domain-specific higher level thinking is by design. I review a lot of code, and have been programming for 20 years. I think most programmers go through a phase, after 2-5 years of experience, where they get really into higher-level thinking. Everything is written according to a mantra like TTD, functional design, or everything-is-an-object, and they spend most of their complexity budget on abstractions. The code people write in that stage of their careers looks to them like an improvement over the simpler concepts they started with, it ends up being so much technical debt 12 months later, because almost nobody is good at predicting which higher-level concepts you are going to need, and by the time you realize you were wrong, it’s too expensive to remove them. It’s hard for a language to encourage this kind of you-ain’t-gonna-need-it thinking without seeming patronizing, but I promise you that the next 10 years of your career will change your mind. (I realize I also sound patronizing and I’m sorry: I typed this on a phone, so left out some caveats, such as I don’t know you and your background.)

dgb23 5y ago
I agree with your points generally, but I already went through that phase and "recovered". I get a bit of an allergic reaction from unnecessary abstractions, design patterns and purism since quite a while. But I think that "phase" is important, because it pushes/pushed us to dive more deeply into topics around abstraction and to make mistakes to learn from. And to keep to good parts so we can apply them accordingly. I'm convinced that some of those things are almost timeless and just 'correct' for their given use-case. Avoiding side-effects and composing functions isn't a fad, nor does it add complexity but reduces it. The issue emerges when we act as if we can do that completely and absolutely. Relational data modelling and APIs are not things you can even avoid, many seem to try to do this only to come back full circle and re-implement them ad-hoc. Similarly there are a ton of other data-structures and patterns like this that have more limited applicability, but work really well if so and reduce the mental overhead to understand and extend a program, make them simpler and more robust. Another good example would be data-driven/oriented: Pulling concrete stuff out of procedures and putting it into plain, boring data, possibly into structured text (JSON, XML, YAML...). It's boring(!) to program like this once you have settled on the right structure/schema, but in a very good way as in it is relaxing and productive. I would even go as far to say that this is one of the most productivity enhancing force multipliers in programming, but it requires a bit of up-front thinking or at least rewriting/refactoring as opposed to going full-on-procedural. Again, I hear you, I've been there too. Abstraction is hard and requires experience and constant learning. Doing mistakes in that regard is very expensive (time and mental taxation). But lets not pretend like abstraction is inherently evil or misguided, especially not if we choose patterns and data-structures that have stood the test of time like the above. So I think abstraction should be treated as a kind of investment, it has a cost (including opportunity costs) and a possible long term payoff. So we need to be considerate and careful.
cannabis_sam 5y ago
>(I realize I also sound patronizing and I’m sorry: I typed this on a phone, so left out some caveats, such as I don’t know you and your background.) Yet your comment is extremely dismissive of young people’s experiences. I personally had to fight for what I considered to be trivial design decisions, because a senior dev was pushing programming techniques based on his experience with Lisp in the literal 80s. Now I love lisp (although I prefer to work in Haskell), but I had to rewrite this old fart’s shitty and slow java application in a vaguely object-oriented way, so that we would have a hope in hell to attract new devs. And when we actually employed new devs, I had to simplify my code even further to help onboarding, thankfully I had exercised most of the idiotic code at that point, so we built a simplified codebase that was accessible to anyone who had a vague understanding of an MVC-style web app. (Today that would probably be some kind of basic React/Vue app.)

by t8sr 5y ago

dgb23 5y ago

I agree with your points generally, but I already went through that phase and "recovered". I get a bit of an allergic reaction from unnecessary abstractions, design patterns and purism since quite a while. But I think that "phase" is important, because it pushes/pushed us to dive more deeply into topics around abstraction and to make mistakes to learn from. And to keep to good parts so we can apply them accordingly. I'm convinced that some of those things are almost timeless and just 'correct' for their given use-case. Avoiding side-effects and composing functions isn't a fad, nor does it add complexity but reduces it. The issue emerges when we act as if we can do that completely and absolutely. Relational data modelling and APIs are not things you can even avoid, many seem to try to do this only to come back full circle and re-implement them ad-hoc. Similarly there are a ton of other data-structures and patterns like this that have more limited applicability, but work really well if so and reduce the mental overhead to understand and extend a program, make them simpler and more robust. Another good example would be data-driven/oriented: Pulling concrete stuff out of procedures and putting it into plain, boring data, possibly into structured text (JSON, XML, YAML...). It's boring(!) to program like this once you have settled on the right structure/schema, but in a very good way as in it is relaxing and productive. I would even go as far to say that this is one of the most productivity enhancing force multipliers in programming, but it requires a bit of up-front thinking or at least rewriting/refactoring as opposed to going full-on-procedural. Again, I hear you, I've been there too. Abstraction is hard and requires experience and constant learning. Doing mistakes in that regard is very expensive (time and mental taxation). But lets not pretend like abstraction is inherently evil or misguided, especially not if we choose patterns and data-structures that have stood the test of time like the above. So I think abstraction should be treated as a kind of investment, it has a cost (including opportunity costs) and a possible long term payoff. So we need to be considerate and careful.

cannabis_sam 5y ago

>(I realize I also sound patronizing and I’m sorry: I typed this on a phone, so left out some caveats, such as I don’t know you and your background.) Yet your comment is extremely dismissive of young people’s experiences. I personally had to fight for what I considered to be trivial design decisions, because a senior dev was pushing programming techniques based on his experience with Lisp in the literal 80s. Now I love lisp (although I prefer to work in Haskell), but I had to rewrite this old fart’s shitty and slow java application in a vaguely object-oriented way, so that we would have a hope in hell to attract new devs. And when we actually employed new devs, I had to simplify my code even further to help onboarding, thankfully I had exercised most of the idiotic code at that point, so we built a simplified codebase that was accessible to anyone who had a vague understanding of an MVC-style web app. (Today that would probably be some kind of basic React/Vue app.)