4 ms·

Thank you. If I want to design excellent architecture I will crack open SICP and transpose it to the fabric of modern computing. I also take issue with much o

Thank you. If I want to design excellent architecture I will crack open SICP and transpose it to the fabric of modern computing. I also take issue with much of what Fowler et al say, but that's another conversation.

notus 7y ago
SICP isn't going to teach you excellent architecture for large systems, it's going to teach you excellent architecture for small programs.
- crimsonalucard 7y ago
  The design of small programs is isomorphic to the design of large programs at all levels. You're just referring to real world caveats and details, but the overall concepts taught in SICP apply to all layers of programming from assembly to the architectural level. Small programs: Q = A -> B W = B -> C R = C -> D T = D -> E Large Programs L = W . Q K = T . R Architecture M = L . K The above description works at every layer. SICP deals with abstraction and architecture at all layers of programming. It does not talk about real world idiosyncrasies of the system. For example it won't talk about whether the assembly instructions of the small program being executed is efficient and it won't talk about network latency.
  - dwaltrip 7y ago
    > The design of small programs is isomorphic to the design of large programs at all levels Good software design is not scale invariant. Significant scale deltas change things in fundamental ways. Designs that work and are maintainable, from a human perspective, at one scale often will fail at a larger scale. Some designs scale better than others, this is true. But no design scales infinitely, and the vast majority of designs would start performing poorly at scales that are still relevant to human concerns This shouldn't be surprising. Most things (nearly everything?) that we care about are not scale invariant.
    - AnimalMuppet 7y ago
      I seem to recall something like the "rule of 10" - for every factor of 10 in scale, a new set of problems dominates. And, from experience, there's some truth to it.
    - crimsonalucard 7y ago
      The concept of abstraction and process IS scale invariant. What is not scale invariant is the real world details like I mentioned above. 1. What assembly language instructions a language compiles to 2. Network latency / topology / etc.. Scheme or other programming languages hides real world detail #1 so we don't have to deal with it (as much). While there is a lot of work done for #2. we currently do not have as good abstractions for #2. as we do for #1. Therefore usually a programmer must exit the abstraction and deal with the real world issues. Hence the confusion. You usually don't have to deal with assembly language or even know about it because a good abstraction exists but you do have to deal with "network architecture" and know about it because no good abstraction exists (yet). This is what is actually going on. You are dealing with real world details because those details change. But the concepts of abstraction that SICP talks about remain invariant. That being said my statement about SICP is correct. My diagram that illustrates abstraction and design from a high level point of view the way SICP does is correct. Even with real world details in mind there is nothing about my diagram that is incorrect. The diagram I drew IS scale invariant. SICP teaches such concepts and is thus in itself a good book that is also "scale invariant." If you feel there is something about that diagram that is incorrect please point it out. If you can find a flaw without going into lower level details like network topology or assembly language then you can prove my statement definitely incorrect. But as such my statement is correct and the diagram is still correct. The ideal is to come up with a language that can compile down into both applications and a network of computers with minimal leakage. The concept of abstraction that SICP introduces remains applicable to all layers even if we currently lack the technology to stay within the abstraction. I think what's going on is you're just mistaken. You think that abstraction is not scale invariant simply because of the way we deal small programs and large programs is different. Actually it's the same, we just don't currently have the tech to hide the details for large architectures like we do for small architectures... work is being done on this front though... Terraform, docker, cloud computing all these things move it in the right direction but we don't yet have an abstraction over this area like we do for single applications. This does not mean it's impossible. Who's to say I can't write an entire web app in one language and it compiles down to server app, networked physical servers, cache and database automatically? This is a very viable architecture. Why not let a compiler tune network topology like it tunes assembly instructions? Of course, it's not viable yet, but definitely in the realm of future possibility.
charlieflowers 7y ago
I think one of the notions behind the Fowler criticism is something like this: "Early on, a bunch of people got famous as programming thought leaders, but later we all found out there were much deeper, smarter thinkers who didn't get all the buzz." So the "early" ones might be Fowler, Uncle Bob, Beck, Grady Booch, Evans (DDD), etc. And the "deeper" ones would be the authors of SICP, or Peter Norvig, or Chris Lattimer. I can see where this sentiment is coming from, and there's no doubt truth to it. I'd say SICP is _without a doubt_ deeper and more insightful than most or maybe all of what Fowler has written. From that standpoint, SICP should be more famous than Fowler, but it doesn't seem to be the case. It definitely was not the case 10 years ago. Still, let's not throw the baby out with the bathwater. Fowler's writing has explained some difficult concepts very clearly. And he chooses topics wisely (but not perfectly in hindsight). So yes, there are two "tiers" of "experts" about building software. Clearly there is a "tier 1" that is better, more proven, deeper, than Fowler/Martin/et al. That puts Fowler and some others at tier 2 (or lower, all subjective of course). That doesn't mean tier 2 is entirely worthless though. IMO far from it.

notus 7y ago

SICP isn't going to teach you excellent architecture for large systems, it's going to teach you excellent architecture for small programs.

crimsonalucard 7y ago
The design of small programs is isomorphic to the design of large programs at all levels. You're just referring to real world caveats and details, but the overall concepts taught in SICP apply to all layers of programming from assembly to the architectural level. Small programs: Q = A -> B W = B -> C R = C -> D T = D -> E Large Programs L = W . Q K = T . R Architecture M = L . K The above description works at every layer. SICP deals with abstraction and architecture at all layers of programming. It does not talk about real world idiosyncrasies of the system. For example it won't talk about whether the assembly instructions of the small program being executed is efficient and it won't talk about network latency.
- dwaltrip 7y ago
  > The design of small programs is isomorphic to the design of large programs at all levels Good software design is not scale invariant. Significant scale deltas change things in fundamental ways. Designs that work and are maintainable, from a human perspective, at one scale often will fail at a larger scale. Some designs scale better than others, this is true. But no design scales infinitely, and the vast majority of designs would start performing poorly at scales that are still relevant to human concerns This shouldn't be surprising. Most things (nearly everything?) that we care about are not scale invariant.
  - AnimalMuppet 7y ago
    I seem to recall something like the "rule of 10" - for every factor of 10 in scale, a new set of problems dominates. And, from experience, there's some truth to it.
  - crimsonalucard 7y ago
    The concept of abstraction and process IS scale invariant. What is not scale invariant is the real world details like I mentioned above. 1. What assembly language instructions a language compiles to 2. Network latency / topology / etc.. Scheme or other programming languages hides real world detail #1 so we don't have to deal with it (as much). While there is a lot of work done for #2. we currently do not have as good abstractions for #2. as we do for #1. Therefore usually a programmer must exit the abstraction and deal with the real world issues. Hence the confusion. You usually don't have to deal with assembly language or even know about it because a good abstraction exists but you do have to deal with "network architecture" and know about it because no good abstraction exists (yet). This is what is actually going on. You are dealing with real world details because those details change. But the concepts of abstraction that SICP talks about remain invariant. That being said my statement about SICP is correct. My diagram that illustrates abstraction and design from a high level point of view the way SICP does is correct. Even with real world details in mind there is nothing about my diagram that is incorrect. The diagram I drew IS scale invariant. SICP teaches such concepts and is thus in itself a good book that is also "scale invariant." If you feel there is something about that diagram that is incorrect please point it out. If you can find a flaw without going into lower level details like network topology or assembly language then you can prove my statement definitely incorrect. But as such my statement is correct and the diagram is still correct. The ideal is to come up with a language that can compile down into both applications and a network of computers with minimal leakage. The concept of abstraction that SICP introduces remains applicable to all layers even if we currently lack the technology to stay within the abstraction. I think what's going on is you're just mistaken. You think that abstraction is not scale invariant simply because of the way we deal small programs and large programs is different. Actually it's the same, we just don't currently have the tech to hide the details for large architectures like we do for small architectures... work is being done on this front though... Terraform, docker, cloud computing all these things move it in the right direction but we don't yet have an abstraction over this area like we do for single applications. This does not mean it's impossible. Who's to say I can't write an entire web app in one language and it compiles down to server app, networked physical servers, cache and database automatically? This is a very viable architecture. Why not let a compiler tune network topology like it tunes assembly instructions? Of course, it's not viable yet, but definitely in the realm of future possibility.

charlieflowers 7y ago

I think one of the notions behind the Fowler criticism is something like this: "Early on, a bunch of people got famous as programming thought leaders, but later we all found out there were much deeper, smarter thinkers who didn't get all the buzz." So the "early" ones might be Fowler, Uncle Bob, Beck, Grady Booch, Evans (DDD), etc. And the "deeper" ones would be the authors of SICP, or Peter Norvig, or Chris Lattimer. I can see where this sentiment is coming from, and there's no doubt truth to it. I'd say SICP is _without a doubt_ deeper and more insightful than most or maybe all of what Fowler has written. From that standpoint, SICP should be more famous than Fowler, but it doesn't seem to be the case. It definitely was not the case 10 years ago. Still, let's not throw the baby out with the bathwater. Fowler's writing has explained some difficult concepts very clearly. And he chooses topics wisely (but not perfectly in hindsight). So yes, there are two "tiers" of "experts" about building software. Clearly there is a "tier 1" that is better, more proven, deeper, than Fowler/Martin/et al. That puts Fowler and some others at tier 2 (or lower, all subjective of course). That doesn't mean tier 2 is entirely worthless though. IMO far from it.