4 ms·

> Strategies for building systems that can be adapted for new situations with only minor programming modifications. The problem is I'd rather make a medium si

> Strategies for building systems that can be adapted for new situations with only minor programming modifications. The problem is I'd rather make a medium size changes to a simple system than a minor change to a complex system. >The authors explore ways to enhance flexibility by:• Organizing systems using combinators to compose mix-and-match parts, ranging from small functions to whole arithmetics, with standardized interfaces• Augmenting data with independent annotation layers, such as units of measurement or provenance• Combining independent pieces of partial information using unification or propagation• Separating control structure from problem domain with domain models, rule systems and pattern matching, propagation, and dependency-directed backtracking• Extending the programming language, using dynamically extensible evaluators And this doesn't sound like a simple system.

dgb23 6y ago
If you squint, these seem to be (optional) layers of transformation (data and code). I would rather navigate code with a clear, high level pipeline of transformations, rather than each path having its own idiosyncratic low level data assembly.
asdfman123 6y ago
Bob Marley answers this dilemma: "The truth is, everyone is going to hurt you. You just got to find the ones worth suffering for." To some degree or another, everything sucks and complexity is unavoidable. You just have to find the type of complexity you're willing to live with. That being said -- I suppose if you're used to that kind of complicated stuff and used to typing out the boiler plate code, it doesn't seem quite so inscrutible. Tedious, but it doesn't blow up in your face. It's like I had a hard time understanding the strategy pattern the first time I saw it, especially when generics were involved. It felt mind bending. Now I happily use it and it's all straightforward. The formerly intellectually difficult parts are now autopilot for me. And it's a hell of a lot less stressful than adding another set of random if statements to an important code path. And keep in mind many of these phrases are very fancy ways of something that makes intuitive sense if you're familiar with it.
- JamesBarney 6y ago
  Lets hope the next time someone has their mind bent while modifying your code a really good QA person tests it afterwards :). > And keep in mind many of these phrases are very fancy ways of something that makes intuitive sense if you're familiar with it. Every piece of code is easy to deal with once you're familiar with it. But maintainable code is about allowing other people to easily work on it. I pity the guy trying to fix some old legacy code base, while also trying to figure out what the hell a combinator is https://en.wikipedia.org/wiki/Combinatory_logic https://en.wikipedia.org/wiki/Combinatory_logic
  - asdfman123 6y ago
    But see, the difference is something that is confusing to a beginner is quite a bit different than something that is just overwhelmingly complex for anyone. And "simple" code has far more risk of side effect than well architected code, which is quite the opposite of what you assert. Getting to the bottom of what you need to change is complicated if you're new, but once you get past the learning curve it's straightforward. On the other hand, a "simple" code structure can becoming a steaming pile of garbage if you want to make any real changes to it. To be very clear, I'm talking using something like composition instead of making a big file with cyclomatic complexity -- not arguing for some of those other things, which in all honesty I'm not completely familiar with. Really just arguing that sometimes this stuff seems impossible and dumb when you're starting out, but easy and intuitive when you learn more. > I pity the guy trying to fix some old legacy code base, while also trying to figure out what the hell a combinator is That goes to my other point: it's wrapped up in excessively formal language, but the actual ideas are simple. I think they might be for instance just advocating the use of functional programming, and juniors use Javascript lambdas every single day without knowing what the hell a combinator is.
    - 9wzYQbTYsAIc 6y ago
      Very good points. Even though they might feel the same, on a human level, there’s clearly a difference between being early in the learning curve and facing down a complex system.
oreally 6y ago
Yea all the quotes are contradictory to the goal of 'flexibility'. What's more flexible than being able to write the code that does the thing you want it to do, rather than creating, then mixing and matching objects/abstractions that you very likely have a surface level understanding of? There's a huge misunderstanding of 'flexibility' within codebases. You can achieve 'flexibility' via the lack of programming rules. Yet objects/abstractions/encapsulations are literal rules applied onto code to achieve some benefit (less code, increased surface understandability, etc), it's less about flexibility. And the quoted systems feel like they have little benefit to one's codebase.
jlg23 6y ago
> The problem is I'd rather make a medium size changes to a simple system than a minor change to a complex system. Spending one hour thinking to make a one-line change might not feel productive if one is used to just hacking away, but, IMHO, it is a net win by some orders of magnitude (assuming we are working on some software with solid abstractions). > And this doesn't sound like a simple system. Unless one understands it, in which case that list sounds like a collection of solutions/patterns one would come up with after the n-th rewrite anyway. If, and that is were we often fail, we manage to document the design decisions adequately, code can be easier to read as well.
codebje 6y ago
> The problem is I'd rather make a medium size changes to a simple system than a minor change to a complex system. The risk there is you (or someone else less disciplined on your team) doesn't make the medium size change. They instead hack in the smallest possible size change they can get away with to satisfy the current problem. After a few changes like that, you have a complicated system and all changes are major.
- asdfman123 6y ago
  It's hardly a small problem either. I can see it unfold every single day in my code base. I've spent weeks trying to make minor changes to code like that because I'm afraid changing one variable is going to backfire because it's used in some unexpected way somewhere else. On the other hand I've also been the bad guy before, too. I've realized how much work refactoring is going to be, and instead of making the project managers mad at me I just slapped in some additional cyclomatic complexity. Everyone wins... in the present. We get to check off our to do lists. Everyone in the future loses. Technical debt is an apt metaphor.
vinay_ys 6y ago
I think the goal of any such pursuit is to reduce/manage the cognitive load that any one person has to deal with while they are trying accomplish something. Things like "Separating control structure from problem domain" enable separation of concerns so that the person deal with resource utilization – efficiency/capacity-planning and scalability can be an expert in systems domain and doesn't have to deal with functional domain understanding and its complexity (and vice versa). Solving for separation of concerns in such a way that it also enables separation of roles and responsibilities and hence facilitates developing expertise/specialization in a particular orthogonal discipline is super powerful. In my experience, this is one of the most effective ways to scale a fundamentally human endeavor of building large software projects.

dgb23 6y ago

If you squint, these seem to be (optional) layers of transformation (data and code). I would rather navigate code with a clear, high level pipeline of transformations, rather than each path having its own idiosyncratic low level data assembly.

asdfman123 6y ago

Bob Marley answers this dilemma: "The truth is, everyone is going to hurt you. You just got to find the ones worth suffering for." To some degree or another, everything sucks and complexity is unavoidable. You just have to find the type of complexity you're willing to live with. That being said -- I suppose if you're used to that kind of complicated stuff and used to typing out the boiler plate code, it doesn't seem quite so inscrutible. Tedious, but it doesn't blow up in your face. It's like I had a hard time understanding the strategy pattern the first time I saw it, especially when generics were involved. It felt mind bending. Now I happily use it and it's all straightforward. The formerly intellectually difficult parts are now autopilot for me. And it's a hell of a lot less stressful than adding another set of random if statements to an important code path. And keep in mind many of these phrases are very fancy ways of something that makes intuitive sense if you're familiar with it.

JamesBarney 6y ago
Lets hope the next time someone has their mind bent while modifying your code a really good QA person tests it afterwards :). > And keep in mind many of these phrases are very fancy ways of something that makes intuitive sense if you're familiar with it. Every piece of code is easy to deal with once you're familiar with it. But maintainable code is about allowing other people to easily work on it. I pity the guy trying to fix some old legacy code base, while also trying to figure out what the hell a combinator is https://en.wikipedia.org/wiki/Combinatory_logic https://en.wikipedia.org/wiki/Combinatory_logic
- asdfman123 6y ago
  But see, the difference is something that is confusing to a beginner is quite a bit different than something that is just overwhelmingly complex for anyone. And "simple" code has far more risk of side effect than well architected code, which is quite the opposite of what you assert. Getting to the bottom of what you need to change is complicated if you're new, but once you get past the learning curve it's straightforward. On the other hand, a "simple" code structure can becoming a steaming pile of garbage if you want to make any real changes to it. To be very clear, I'm talking using something like composition instead of making a big file with cyclomatic complexity -- not arguing for some of those other things, which in all honesty I'm not completely familiar with. Really just arguing that sometimes this stuff seems impossible and dumb when you're starting out, but easy and intuitive when you learn more. > I pity the guy trying to fix some old legacy code base, while also trying to figure out what the hell a combinator is That goes to my other point: it's wrapped up in excessively formal language, but the actual ideas are simple. I think they might be for instance just advocating the use of functional programming, and juniors use Javascript lambdas every single day without knowing what the hell a combinator is.
  - 9wzYQbTYsAIc 6y ago
    Very good points. Even though they might feel the same, on a human level, there’s clearly a difference between being early in the learning curve and facing down a complex system.

oreally 6y ago

Yea all the quotes are contradictory to the goal of 'flexibility'. What's more flexible than being able to write the code that does the thing you want it to do, rather than creating, then mixing and matching objects/abstractions that you very likely have a surface level understanding of? There's a huge misunderstanding of 'flexibility' within codebases. You can achieve 'flexibility' via the lack of programming rules. Yet objects/abstractions/encapsulations are literal rules applied onto code to achieve some benefit (less code, increased surface understandability, etc), it's less about flexibility. And the quoted systems feel like they have little benefit to one's codebase.

jlg23 6y ago

> The problem is I'd rather make a medium size changes to a simple system than a minor change to a complex system. Spending one hour thinking to make a one-line change might not feel productive if one is used to just hacking away, but, IMHO, it is a net win by some orders of magnitude (assuming we are working on some software with solid abstractions). > And this doesn't sound like a simple system. Unless one understands it, in which case that list sounds like a collection of solutions/patterns one would come up with after the n-th rewrite anyway. If, and that is were we often fail, we manage to document the design decisions adequately, code can be easier to read as well.

codebje 6y ago

> The problem is I'd rather make a medium size changes to a simple system than a minor change to a complex system. The risk there is you (or someone else less disciplined on your team) doesn't make the medium size change. They instead hack in the smallest possible size change they can get away with to satisfy the current problem. After a few changes like that, you have a complicated system and all changes are major.

asdfman123 6y ago
It's hardly a small problem either. I can see it unfold every single day in my code base. I've spent weeks trying to make minor changes to code like that because I'm afraid changing one variable is going to backfire because it's used in some unexpected way somewhere else. On the other hand I've also been the bad guy before, too. I've realized how much work refactoring is going to be, and instead of making the project managers mad at me I just slapped in some additional cyclomatic complexity. Everyone wins... in the present. We get to check off our to do lists. Everyone in the future loses. Technical debt is an apt metaphor.

vinay_ys 6y ago

I think the goal of any such pursuit is to reduce/manage the cognitive load that any one person has to deal with while they are trying accomplish something. Things like "Separating control structure from problem domain" enable separation of concerns so that the person deal with resource utilization – efficiency/capacity-planning and scalability can be an expert in systems domain and doesn't have to deal with functional domain understanding and its complexity (and vice versa). Solving for separation of concerns in such a way that it also enables separation of roles and responsibilities and hence facilitates developing expertise/specialization in a particular orthogonal discipline is super powerful. In my experience, this is one of the most effective ways to scale a fundamentally human endeavor of building large software projects.