8 ms·

I've only been in the industry for ~15 years, but it still feels like every year, some ecosystem discovers the value of something that another ecosystem has tak

by m12k 5y ago

I've only been in the industry for ~15 years, but it still feels like every year, some ecosystem discovers the value of something that another ecosystem has taken for granted for decades - type-checking, immutability, unidirectional data-flow, AOT-compilation, closures, pure functions, you name it. I'm glad we seem to be converging on a set of best practices as an industry, but sometimes I wish we were spending less time rediscovering the wheel and more time building on top of and adding to the actual state of the art.

axiosgunnar 5y ago
I think the problem is to figure out what the best practices actually are. What we are observing here is „the market fixing it“. The process is messy and redundant, but effective.
- deleted 5y ago
  [deleted]
taeric 5y ago
I've been alive long enough to see that most things are useful, and all things are oversold. More, the nice easy things to build with major restrictions pretty much gets thrown out the window for complicated things that have constraints that most efforts don't have. This isn't just a software thing. Building a little shed outside? Would be silly to use the same rigor that goes into a high rise. Which would be crazy to use the same materials engineering that goes into a little shed.
- nllsh 5y ago
  Not that I disagree, but I feel like you are overselling the simplicity of [building a shed](https://en.wiktionary.org/wiki/bikeshedding https://en.wiktionary.org/wiki/bikeshedding).
  - taeric 5y ago
    My point is that all methods and techniques probably have worked for someone doing something. And I should have leaned in on how much is still left to implementation in terms of "shed." From weather, to what is being stored. It isn't like there is a universal shed design that will make everyone happy. Nor is this saying that some things aren't truly valuable. Just recognize that some places they don't help as much as you would like. This isn't saying they are bad or worthless. Just acknowledging that they are oversold.
- Zababa 5y ago
  The metaphor doesn't really works, as in software lots of high rise start as a little shed.
  - taeric 5y ago
    Quite the contrary, in my opinion. Lots of what makes various parts of the physical hard are in the infrastructure surrounding them. This is very similar to the complexity in software setups. Take game systems, as an example; far far more effort will be spent in the art and general asset management than is true for many business software setups. Which is why many of the business best practices haven't necessarily moved over to games. Similarly, look at the general practices around building and maintaining bridges in physical world. We call all bridges by the same name, but reality basically dictates that what works in some locations cannot and will not work in others. Now, you are right that we can grow large software out of smaller in ways that the physical can't do. But, it is a common fallacy to stall out a project by trying to be at google's scale from the start. Ironic, in many ways, as not even google was built to be at their scale from the start.
    - Zababa 5y ago
      I'm not sure what you're trying to say. Something like "the software world is complex, and so is the physical world, so comparing the two makes sense"? If that's what you meant, you're right, but the problem is that comparing the two doesn't lead to better insight in those. If that's not what you meant, then sorry, I didn't understand. I think that in general we should stop using so much metaphors in the software world. There's no need to go look for a shed. If we had to statically type and test every shell commands we typed, we would lose lots of productivity. On the other hand, maintaining those very large scripts that started as a simple line and are now used for deploying all of our application, and tend to fail in surprising ways, would be easier. The other problem with metaphors is that they are also hard to refute. I've never built a shed, nor worked on a high rise. I don't see why that experience would be relevant to building software, or necessary in a discussion about static typing.
      - 5y ago
- aaron695 5y ago
  > Building a little shed outside? Would be silly to use the same rigor that goes into a high rise. This is a bad analogy. They both have 1000's of years of shared development (some high rises still use bricks), 100's in an industrial age and 20 years in the internet age. (Testing is only ~70 years old) People today use shed technology that pre-internet builders would not have know about or not existed. But that 1000 years also includes how to use workers to get the job done. That's not going into the rigor required in many places to build a shed. Watch Still Mine (2012) https://www.imdb.com/title/tt2073086/ https://www.imdb.com/title/tt2073086/ about a couple wanting to build a house themselves, it's not a shed, but fights to build sheds against local governments are less romantic. (And it's a good movie)
jeffbee 5y ago
Yes, and when that ecosystem discovers these obvious facts, the discovery is always described as a "journey" in the accompanying blog post. Having sense and good taste at the beginning of a project doesn't warrant a blog post but slowly stumbling over isolated aspects of good taste, now that's a journey.
d0mine 5y ago
Programming is sufficiently complex field that we can find examples when the opposite things are the best: it depends on context whether you need more or less types.
AlexCoventry 5y ago
I think the limiting factor in the case of python getting type hints was that it was never designed for type safety in mind, and that it took a while to establish consensus on a good type-hinting system. I don't think it's a matter of reinventing the wheel, in this case, more a matter of bolting something like a wheel on a system which didn't start with wheels.

by m12k 5y ago

axiosgunnar 5y ago

I think the problem is to figure out what the best practices actually are. What we are observing here is „the market fixing it“. The process is messy and redundant, but effective.

deleted 5y ago
[deleted]

taeric 5y ago

I've been alive long enough to see that most things are useful, and all things are oversold. More, the nice easy things to build with major restrictions pretty much gets thrown out the window for complicated things that have constraints that most efforts don't have. This isn't just a software thing. Building a little shed outside? Would be silly to use the same rigor that goes into a high rise. Which would be crazy to use the same materials engineering that goes into a little shed.

nllsh 5y ago
Not that I disagree, but I feel like you are overselling the simplicity of [building a shed](https://en.wiktionary.org/wiki/bikeshedding https://en.wiktionary.org/wiki/bikeshedding).
- taeric 5y ago
  My point is that all methods and techniques probably have worked for someone doing something. And I should have leaned in on how much is still left to implementation in terms of "shed." From weather, to what is being stored. It isn't like there is a universal shed design that will make everyone happy. Nor is this saying that some things aren't truly valuable. Just recognize that some places they don't help as much as you would like. This isn't saying they are bad or worthless. Just acknowledging that they are oversold.
Zababa 5y ago
The metaphor doesn't really works, as in software lots of high rise start as a little shed.
- taeric 5y ago
  Quite the contrary, in my opinion. Lots of what makes various parts of the physical hard are in the infrastructure surrounding them. This is very similar to the complexity in software setups. Take game systems, as an example; far far more effort will be spent in the art and general asset management than is true for many business software setups. Which is why many of the business best practices haven't necessarily moved over to games. Similarly, look at the general practices around building and maintaining bridges in physical world. We call all bridges by the same name, but reality basically dictates that what works in some locations cannot and will not work in others. Now, you are right that we can grow large software out of smaller in ways that the physical can't do. But, it is a common fallacy to stall out a project by trying to be at google's scale from the start. Ironic, in many ways, as not even google was built to be at their scale from the start.
  - Zababa 5y ago
    I'm not sure what you're trying to say. Something like "the software world is complex, and so is the physical world, so comparing the two makes sense"? If that's what you meant, you're right, but the problem is that comparing the two doesn't lead to better insight in those. If that's not what you meant, then sorry, I didn't understand. I think that in general we should stop using so much metaphors in the software world. There's no need to go look for a shed. If we had to statically type and test every shell commands we typed, we would lose lots of productivity. On the other hand, maintaining those very large scripts that started as a simple line and are now used for deploying all of our application, and tend to fail in surprising ways, would be easier. The other problem with metaphors is that they are also hard to refute. I've never built a shed, nor worked on a high rise. I don't see why that experience would be relevant to building software, or necessary in a discussion about static typing.
    - 5y ago
aaron695 5y ago
> Building a little shed outside? Would be silly to use the same rigor that goes into a high rise. This is a bad analogy. They both have 1000's of years of shared development (some high rises still use bricks), 100's in an industrial age and 20 years in the internet age. (Testing is only ~70 years old) People today use shed technology that pre-internet builders would not have know about or not existed. But that 1000 years also includes how to use workers to get the job done. That's not going into the rigor required in many places to build a shed. Watch Still Mine (2012) https://www.imdb.com/title/tt2073086/ https://www.imdb.com/title/tt2073086/ about a couple wanting to build a house themselves, it's not a shed, but fights to build sheds against local governments are less romantic. (And it's a good movie)

jeffbee 5y ago

Yes, and when that ecosystem discovers these obvious facts, the discovery is always described as a "journey" in the accompanying blog post. Having sense and good taste at the beginning of a project doesn't warrant a blog post but slowly stumbling over isolated aspects of good taste, now that's a journey.

d0mine 5y ago

Programming is sufficiently complex field that we can find examples when the opposite things are the best: it depends on context whether you need more or less types.

AlexCoventry 5y ago

I think the limiting factor in the case of python getting type hints was that it was never designed for type safety in mind, and that it took a while to establish consensus on a good type-hinting system. I don't think it's a matter of reinventing the wheel, in this case, more a matter of bolting something like a wheel on a system which didn't start with wheels.