8 ms·

> the resulting non-answer people come up with is: "Depends on your use-case." > We are dealing with computers here: virtual idealized worlds ripe for systemat

by Twisol 6y ago

> the resulting non-answer people come up with is: "Depends on your use-case." > We are dealing with computers here: virtual idealized worlds ripe for systematic formalism. I disagree with the premise. Generally, computers are the tool, not the product. The primary focus ought to be on the problem we're solving, not on the particular tool we use to construct a solution. You're right: design patterns are couched completely in terms of the software domain. Just knowing a handful of design patterns doesn't help you understand when or how to apply them. When you confuse the map for the territory, design patterns look like the tool, rather than a particular example of how the tool is used. No doubt, that's problematic. But I think you're under a similar illusion: that the computer _is_ the problem to be solved. The practice of software engineering sits at the nexus of (at least) two distinct domains: computer science and the problem domain, whatever it may be. Software architecture is fundamentally about understanding the shape and structure of the problem domain, understanding the capabilities of your engineering tools, and creating an architecture where both domains support each other. Your overall system architecture should flex where the problem domain flexes, and may be rigid where the problem doman is rigid. (It really does "depend on your use-case".) This kind of architecture isn't really about the computer. It's about the human developers and maintainers who have to inhabit this space for years, possibly decades. You have to think about the human factors, and understand (as best as possible) the problem domain you'll be working with. (And you have to be willing to tear it down once, finally, the problem has evolved sufficiently away from expectations.) Architecture is just a disciplne of making your life suck less later. It's not an easy discipline, and (clearly) not a well-understood one. But it's also not formal in the same way computer science or mathematics can be.

vvanders 6y ago
> Software architecture is fundamentally about understanding the shape and structure of the problem domain, understanding the capabilities of your engineering tools, and creating an architecture where both domains support each other. Your overall system architecture should flex where the problem domain flexes, and may be rigid where the problem doman is rigid. (It really does "depend on your use-case".) Can I just say that I really like this framing, I think it succinctly captures why you see such a broad range in languages/frameworks and why there hasn't been one software solution that fits most problems.
- Geminidog 6y ago
  It captured nothing in my view. Even a formal solution won't necessarily have a single solution for all problems. Likely there are several optimal solutions given for each problem that exists. What formality will tell us is whether or not that solution is definitively optimal. Right now our definition of an "optimal design" is whoever wins the "design argument" flame war.
- TeMPOraL 6y ago
  Except the framing is bad, in my experience. For any non-trivial software, the architecture quickly becomes 10% about problem domain, and 90% about internal code bureaucracy. The latter is something that's to a large extent problem-independent, and yet we're still spinning in circles about it for some reason. (By internal code bureaucracy I mean the art of structuring and connecting all the abstractions in your code, the coding of pathways the data travels and transformations it undergoes, etc. Ever had a situation where a seemingly simple feature required you to touch half of your system, as you routed and transformed a piece of information from a place that produced it to the place that consumed it? That's code bureaucracy.)
Geminidog 6y ago
I disagree with you and you've made a mistake. You're the one under the illusion. I'll explain. I know what you're getting at here. You just can't put it in words. And because you can't put it in words, you're unable to see the big picture. To put it plainly you're talking about this: For a specific context how do we organize and modularize code to maximize reuse-ability for a uncertain future with uncertain requirements? You think that this problem can't be formalized. And this is basically what you're trying to elucidate into words with your post. It's that simple. However, this is the exact problem I am saying is ripe for formalization. This is what I'm talking about and you've missed my point. Who says we can't formally define what a module is? and who says we can't formally define what it means for a module to be more re-useable? Who says we can't formally define program requirements? From these axioms we can define a calculus that allows us in the best case to calculate the most optimal program and in the worst case at least be able to know whether one design is "better" than another design. Instead what the industry does is write blog posts about a metaphor. Then give a bunch of examples of why that metaphor is cooler then some other design pattern. Then repeat the same thing every couple of years. Let me frame it for you so that you can wrap your head around what I'm talking about. Given tic-tac-toe we can formally play the game in a way we can never lose. This is definitely not a design problem and one that can be calculated. Very easy to see why this is the case because of the limited primitives your dealing with in tic-tac-toe. The "problem domain" defined within a computer is NO different. In computers You have a limited set of primitives in a rule based playing field: assembly language. The objective is not 3 in a row but whatever formal requirements your program has. Within this problem space there is either one or several configurations of assembly instructions that will fulfill that problem domain according to a formal definition of "optimal". That is the spirit of the formalization I'm talking about. A more complex tic-tac-toe problem. The notion of what it means for an algorithm to be faster has been formalized. So if the problem domain was "how do you sort a list of shoe sizes in the fastest way possible?" then we ALREADY have a formal and definitive way to determine the best possible configurations of assembly instructions to achieve this goal. The problem is solved partially for speed. Picking a faster algorithm is no longer a design choice. The next step is to formalize the notion of modularity and program organization and bring it out of the fuzzy realm of design and architecture and into a more formal realm where things are exactly defined. We came up with a number for speed (O(N)), who says we can't come up with a number for modularity? I don't blame you for making this mistake. "Luck" itself use to be a design problem. Intuitively it's very hard to think of the concept of "luck" as a measurement problem. It was utterly incomprehensible for a typical person to even visualize luck as something that can be calculated. It was only after the development of probability theory that people were able to see how it can be done, it is much harder to predict formal possibilities of a topic before the formalization has actually been done. It's the same thing for module organization. "Design." so to speak >Architecture is just a disciplne of making your life suck less later. It's not an easy discipline, and (clearly) not a You can't even define what it means to make you life "suck less." Are you talking about algorithmic speed? Because that's been formalized. Are you talking about less bugs? Because smaller error surface areas have been partially formalized with type theory and Rusts borrow checker... Are you talking about organization of modules? Because if you're talking about a formal way to organize modules, well that hasn't been done. But don't let that limit your mind into thinking it can't be done. Especially don't let that limit your mind into falling under the illusion of thinking that all of these endless circles and design philosophies that go in vogue and out of vogue throughout the industry are actually doing something to improve the software as a whole. If you ever wanted a good example of history repeating itself software design is the perfect example. In simple terms: the discipline of "architecture" is not well understood because it has NOT been formalized. At this point it's borderline fraudulent to even call it a discipline. Call it a career title, sure, but don't try to think of this stuff as anything on the same level as the sciences.
Geminidog 6y ago
I think you'll find this interesting. It's a bit random but in another part of this thread your name appeared out of pure coincidence from another poster: https://news.ycombinator.com/item?id=25557413 https://news.ycombinator.com/item?id=25557413 In the github thread (started in 2013) mentioned by pcen, you were part of the big debate on bringing more formalization to javascript promises. You were on the winning side (at the time) of NOT doing this. Your comment here: https://github.com/promises-aplus/promises-spec/issues/94#issuecomment-16188234 https://github.com/promises-aplus/promises-spec/issues/94#is... Likely you muted the thread since then but the conversation continued. Now in 2020, times have changed and Typed javascript is not the dominant paradigm. However, the decisions made by you and your brethren back in 2013 continue to echo through eternity. The final comments in that thread (dated 2019) sums it up perfectly: https://github.com/promises-aplus/promises-spec/issues/94#issuecomment-549868812 https://github.com/promises-aplus/promises-spec/issues/94#is... and also: https://github.com/promises-aplus/promises-spec/issues/94#issuecomment-553767177 https://github.com/promises-aplus/promises-spec/issues/94#is... This github thread was brought up to me as an example about how my Current thread is representative of history repeating the same mistakes. A decision to ignore formal theory in the past now results in a fundamental mistake that all JavaScript developers must live with. The irony is that you, Jonathan, are part of both histories, you made a mistake then, the question is are you repeating a similar mistake now? Regardless of whether you're right or wrong now, and disregarding the previous (minor) verbal scuffle we had... I thought you'd be interested in this tidbit of serendipity.
- Twisol 6y ago
  Ah, yeah, I reminisce on that thread every now and then. No, I don't have it muted. I was one of the more moderate voices, as I recall. (See my sole subsequent post, where I expressed interest in seeing the approach come to fruition, to help us understand what place it should have within the promises ecosystem. The thread was raging quite loudly by then, and as a much-junior developer, I stayed quiet after that.) At the time, I had only just started learning Haskell, and while I really liked what monads brought to the table, JavaScript wasn't in a place at the time where it was especially common. With hindsight, monadic promises was perhaps the earliest step toward taking FP seriously in JavaScript. >> You recall, perhaps, how electromagnetism and the weak force are actually part of the same mechanism, but only at very high temperatures? Well, we simply can't turn up the furnace that high in Javascript. Certain formalisms work beautifully in Haskell but fall flat in Javascript without support from the language. Haskell's static typing lets you offload a ton of work onto the compiler, but Javascript doesn't help much at all! Leaving aside how embarrassing my demeanor was, I still believe in the core idea here. You want to use a language that doesn't fight what you're trying to do with it. >> The fmap/bind divide is one of those places; it's just much easier to use the library if you combine the two together. I strongly disagree with myself here now. This was, as I recall, the crux of the entire debate, and I pretty strongly fall on the side of not auto-flattening since maybe only a year afterward. Yeah, it's "easier", but it's less predictable. (Even at the time, I was a proponent of making sure `.andThen()` wouldn't run the next step synchronously if the promise was always resolved, because that would make for an edge-case that you'd always have to keep in mind. "Is it resolved yet?". So I clearly had some sense of consistency, but I hadn't had the same realization about map vs. flatMap on promises.) But back to the present: > A decision to ignore formal theory in the past now results in a fundamental mistake that all JavaScript developers must live with. This is why I more or less recused myself from yesterday's thread. I don't appreciate having to tear down a strawman of myself -- I am, and have been for many years now, a proponent of strongly typed, well-structured, indeed formal approaches to software systems. I also see value in an informal, phenomenological stance, because there's no getting around the fleshy humans that have to work with and maintain these systems. I try not to take either to exclusionary extremes. > The irony is that you, Jonathan, [...] Everything else aside, it's a bit of a taboo to address someone by a name they are not presently identifying themselves by. It's unearned familiarity. > [...] the previous (minor) verbal scuffle [...] For what it's worth, the remark involving "illusion" was intended to be a rhetorical device connecting the example of design patterns to the present topic. It was not meant to be a personal dig. I'll be more careful in the future.

by Twisol 6y ago

vvanders 6y ago

> Software architecture is fundamentally about understanding the shape and structure of the problem domain, understanding the capabilities of your engineering tools, and creating an architecture where both domains support each other. Your overall system architecture should flex where the problem domain flexes, and may be rigid where the problem doman is rigid. (It really does "depend on your use-case".) Can I just say that I really like this framing, I think it succinctly captures why you see such a broad range in languages/frameworks and why there hasn't been one software solution that fits most problems.

Geminidog 6y ago
It captured nothing in my view. Even a formal solution won't necessarily have a single solution for all problems. Likely there are several optimal solutions given for each problem that exists. What formality will tell us is whether or not that solution is definitively optimal. Right now our definition of an "optimal design" is whoever wins the "design argument" flame war.
TeMPOraL 6y ago
Except the framing is bad, in my experience. For any non-trivial software, the architecture quickly becomes 10% about problem domain, and 90% about internal code bureaucracy. The latter is something that's to a large extent problem-independent, and yet we're still spinning in circles about it for some reason. (By internal code bureaucracy I mean the art of structuring and connecting all the abstractions in your code, the coding of pathways the data travels and transformations it undergoes, etc. Ever had a situation where a seemingly simple feature required you to touch half of your system, as you routed and transformed a piece of information from a place that produced it to the place that consumed it? That's code bureaucracy.)

Geminidog 6y ago

I disagree with you and you've made a mistake. You're the one under the illusion. I'll explain. I know what you're getting at here. You just can't put it in words. And because you can't put it in words, you're unable to see the big picture. To put it plainly you're talking about this: For a specific context how do we organize and modularize code to maximize reuse-ability for a uncertain future with uncertain requirements? You think that this problem can't be formalized. And this is basically what you're trying to elucidate into words with your post. It's that simple. However, this is the exact problem I am saying is ripe for formalization. This is what I'm talking about and you've missed my point. Who says we can't formally define what a module is? and who says we can't formally define what it means for a module to be more re-useable? Who says we can't formally define program requirements? From these axioms we can define a calculus that allows us in the best case to calculate the most optimal program and in the worst case at least be able to know whether one design is "better" than another design. Instead what the industry does is write blog posts about a metaphor. Then give a bunch of examples of why that metaphor is cooler then some other design pattern. Then repeat the same thing every couple of years. Let me frame it for you so that you can wrap your head around what I'm talking about. Given tic-tac-toe we can formally play the game in a way we can never lose. This is definitely not a design problem and one that can be calculated. Very easy to see why this is the case because of the limited primitives your dealing with in tic-tac-toe. The "problem domain" defined within a computer is NO different. In computers You have a limited set of primitives in a rule based playing field: assembly language. The objective is not 3 in a row but whatever formal requirements your program has. Within this problem space there is either one or several configurations of assembly instructions that will fulfill that problem domain according to a formal definition of "optimal". That is the spirit of the formalization I'm talking about. A more complex tic-tac-toe problem. The notion of what it means for an algorithm to be faster has been formalized. So if the problem domain was "how do you sort a list of shoe sizes in the fastest way possible?" then we ALREADY have a formal and definitive way to determine the best possible configurations of assembly instructions to achieve this goal. The problem is solved partially for speed. Picking a faster algorithm is no longer a design choice. The next step is to formalize the notion of modularity and program organization and bring it out of the fuzzy realm of design and architecture and into a more formal realm where things are exactly defined. We came up with a number for speed (O(N)), who says we can't come up with a number for modularity? I don't blame you for making this mistake. "Luck" itself use to be a design problem. Intuitively it's very hard to think of the concept of "luck" as a measurement problem. It was utterly incomprehensible for a typical person to even visualize luck as something that can be calculated. It was only after the development of probability theory that people were able to see how it can be done, it is much harder to predict formal possibilities of a topic before the formalization has actually been done. It's the same thing for module organization. "Design." so to speak >Architecture is just a disciplne of making your life suck less later. It's not an easy discipline, and (clearly) not a You can't even define what it means to make you life "suck less." Are you talking about algorithmic speed? Because that's been formalized. Are you talking about less bugs? Because smaller error surface areas have been partially formalized with type theory and Rusts borrow checker... Are you talking about organization of modules? Because if you're talking about a formal way to organize modules, well that hasn't been done. But don't let that limit your mind into thinking it can't be done. Especially don't let that limit your mind into falling under the illusion of thinking that all of these endless circles and design philosophies that go in vogue and out of vogue throughout the industry are actually doing something to improve the software as a whole. If you ever wanted a good example of history repeating itself software design is the perfect example. In simple terms: the discipline of "architecture" is not well understood because it has NOT been formalized. At this point it's borderline fraudulent to even call it a discipline. Call it a career title, sure, but don't try to think of this stuff as anything on the same level as the sciences.

Geminidog 6y ago

I think you'll find this interesting. It's a bit random but in another part of this thread your name appeared out of pure coincidence from another poster: https://news.ycombinator.com/item?id=25557413 https://news.ycombinator.com/item?id=25557413 In the github thread (started in 2013) mentioned by pcen, you were part of the big debate on bringing more formalization to javascript promises. You were on the winning side (at the time) of NOT doing this. Your comment here: https://github.com/promises-aplus/promises-spec/issues/94#issuecomment-16188234 https://github.com/promises-aplus/promises-spec/issues/94#is... Likely you muted the thread since then but the conversation continued. Now in 2020, times have changed and Typed javascript is not the dominant paradigm. However, the decisions made by you and your brethren back in 2013 continue to echo through eternity. The final comments in that thread (dated 2019) sums it up perfectly: https://github.com/promises-aplus/promises-spec/issues/94#issuecomment-549868812 https://github.com/promises-aplus/promises-spec/issues/94#is... and also: https://github.com/promises-aplus/promises-spec/issues/94#issuecomment-553767177 https://github.com/promises-aplus/promises-spec/issues/94#is... This github thread was brought up to me as an example about how my Current thread is representative of history repeating the same mistakes. A decision to ignore formal theory in the past now results in a fundamental mistake that all JavaScript developers must live with. The irony is that you, Jonathan, are part of both histories, you made a mistake then, the question is are you repeating a similar mistake now? Regardless of whether you're right or wrong now, and disregarding the previous (minor) verbal scuffle we had... I thought you'd be interested in this tidbit of serendipity.

Twisol 6y ago
Ah, yeah, I reminisce on that thread every now and then. No, I don't have it muted. I was one of the more moderate voices, as I recall. (See my sole subsequent post, where I expressed interest in seeing the approach come to fruition, to help us understand what place it should have within the promises ecosystem. The thread was raging quite loudly by then, and as a much-junior developer, I stayed quiet after that.) At the time, I had only just started learning Haskell, and while I really liked what monads brought to the table, JavaScript wasn't in a place at the time where it was especially common. With hindsight, monadic promises was perhaps the earliest step toward taking FP seriously in JavaScript. >> You recall, perhaps, how electromagnetism and the weak force are actually part of the same mechanism, but only at very high temperatures? Well, we simply can't turn up the furnace that high in Javascript. Certain formalisms work beautifully in Haskell but fall flat in Javascript without support from the language. Haskell's static typing lets you offload a ton of work onto the compiler, but Javascript doesn't help much at all! Leaving aside how embarrassing my demeanor was, I still believe in the core idea here. You want to use a language that doesn't fight what you're trying to do with it. >> The fmap/bind divide is one of those places; it's just much easier to use the library if you combine the two together. I strongly disagree with myself here now. This was, as I recall, the crux of the entire debate, and I pretty strongly fall on the side of not auto-flattening since maybe only a year afterward. Yeah, it's "easier", but it's less predictable. (Even at the time, I was a proponent of making sure `.andThen()` wouldn't run the next step synchronously if the promise was always resolved, because that would make for an edge-case that you'd always have to keep in mind. "Is it resolved yet?". So I clearly had some sense of consistency, but I hadn't had the same realization about map vs. flatMap on promises.) But back to the present: > A decision to ignore formal theory in the past now results in a fundamental mistake that all JavaScript developers must live with. This is why I more or less recused myself from yesterday's thread. I don't appreciate having to tear down a strawman of myself -- I am, and have been for many years now, a proponent of strongly typed, well-structured, indeed formal approaches to software systems. I also see value in an informal, phenomenological stance, because there's no getting around the fleshy humans that have to work with and maintain these systems. I try not to take either to exclusionary extremes. > The irony is that you, Jonathan, [...] Everything else aside, it's a bit of a taboo to address someone by a name they are not presently identifying themselves by. It's unearned familiarity. > [...] the previous (minor) verbal scuffle [...] For what it's worth, the remark involving "illusion" was intended to be a rhetorical device connecting the example of design patterns to the present topic. It was not meant to be a personal dig. I'll be more careful in the future.