3 ms·

This is someone who is confronting basic limits of representation and information flow and blaming OOP. There is no one best way to organize code just like ther

This is someone who is confronting basic limits of representation and information flow and blaming OOP. There is no one best way to organize code just like there is no one best sentence to describe a rose.

api 8y ago
"There is no one best way" summarizes what I think is a major unheralded realization in software engineering in the past 10 years. Before that it was the search for the One Way. OOP and functional programming were probably the two biggest opposing schools during that era, but now the trend is languages that easily allow both plus plain vanilla procedural programming. It's the programmer's job to pick a paradigm for the problem being solved.
- slavik81 8y ago
  "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity" ~ Fred Brooks, No Silver Bullet (1986)
  - tyingq 8y ago
    The explosion of variety has actually pushed the other way. It was expensive, but MVS shops could push out highly available apps with a consistent UI very quickly. It seems we've really only made progress on unit cost and ubiquity. I think this is roughly why cloud is popular. It's not cheap, but if you're using their standard pieces (RDS, lambda, ECS, ELB, CloudWatch etc), you're working in a defined box with fewer choices.
- tyingq 8y ago
  I'm curious if this is the way older and more established engineering progressed. I would be interested in how, for example, designing and building a bridge to suit a specific use case has evolved over time.
  - 0x445442 8y ago
    Software not being bound by physical constraints like other engineering disciplines is a huge distinction. So much so that I think software development is closer to writing a novel or movie script than it is to building a bridge. However, I would say the closer the software is to bare metal the closer it is to "real" engineering.
  - astazangasta 8y ago
    There are two major concerns in software, performance and legibility. These concerns are somewhat orthogonal but neither can be abandoned, and the challenge is balancing them. By contrast in bridge-building (etc.) the two main concerns (performance and aesthetics) have been largely separated by discipline, into engineering and architecture, the former a purely mechanical discipline, the latter almost entirely artistic. The main result of Modernism has been the subservience of the latter to the former, and in general the almost wholescale abandonment of aesthetic concerns. This is starting to come apart a little bit as people realize that this separation is unhealthy, and maybe we shouldn't build brutal, ugly flyovers through our cities because they have measurable effects on happiness, and thus property values, etc. (i.e., aesthetic concerns have functional consequences). Similarly I think many software "engineers" take a long time to realize that one of their main functions is writing code that others can read; this is an aesthetic, artistic discipline that I think many developers reject as outside their domain. This, too, is starting to come apart as we slowly figure out that code's maintainability is a key determinant of its long-term success - that is, aesthetic concerns have functional consequences.

api 8y ago

"There is no one best way" summarizes what I think is a major unheralded realization in software engineering in the past 10 years. Before that it was the search for the One Way. OOP and functional programming were probably the two biggest opposing schools during that era, but now the trend is languages that easily allow both plus plain vanilla procedural programming. It's the programmer's job to pick a paradigm for the problem being solved.

slavik81 8y ago
"there is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity" ~ Fred Brooks, No Silver Bullet (1986)
- tyingq 8y ago
  The explosion of variety has actually pushed the other way. It was expensive, but MVS shops could push out highly available apps with a consistent UI very quickly. It seems we've really only made progress on unit cost and ubiquity. I think this is roughly why cloud is popular. It's not cheap, but if you're using their standard pieces (RDS, lambda, ECS, ELB, CloudWatch etc), you're working in a defined box with fewer choices.
tyingq 8y ago
I'm curious if this is the way older and more established engineering progressed. I would be interested in how, for example, designing and building a bridge to suit a specific use case has evolved over time.
- 0x445442 8y ago
  Software not being bound by physical constraints like other engineering disciplines is a huge distinction. So much so that I think software development is closer to writing a novel or movie script than it is to building a bridge. However, I would say the closer the software is to bare metal the closer it is to "real" engineering.
- astazangasta 8y ago
  There are two major concerns in software, performance and legibility. These concerns are somewhat orthogonal but neither can be abandoned, and the challenge is balancing them. By contrast in bridge-building (etc.) the two main concerns (performance and aesthetics) have been largely separated by discipline, into engineering and architecture, the former a purely mechanical discipline, the latter almost entirely artistic. The main result of Modernism has been the subservience of the latter to the former, and in general the almost wholescale abandonment of aesthetic concerns. This is starting to come apart a little bit as people realize that this separation is unhealthy, and maybe we shouldn't build brutal, ugly flyovers through our cities because they have measurable effects on happiness, and thus property values, etc. (i.e., aesthetic concerns have functional consequences). Similarly I think many software "engineers" take a long time to realize that one of their main functions is writing code that others can read; this is an aesthetic, artistic discipline that I think many developers reject as outside their domain. This, too, is starting to come apart as we slowly figure out that code's maintainability is a key determinant of its long-term success - that is, aesthetic concerns have functional consequences.