3 ms·

This is not a BASH problem. Ok, well this example is, but more generally it is an example of an "untyped" vs. "typed" problem. Types are the way to write soft

This is not a BASH problem. Ok, well this example is, but more generally it is an example of an "untyped" vs. "typed" problem. Types are the way to write software that has longevity. Even better, while writing software that is typed, learning of type errors sooner is better than learning about them later, and learning about them at runtime when your tools tell you everything is OK is the worst of all. Statically typechecked languages win the day, here. BASH has value, Python has value, JavaScript has value, and typed languages all have more value, more longevity, and more provability than any untyped or dynamically typechecked languages. Please use statically typechecked, compiled languages when writing load-bearing software. /soapbox

akhmatova 5y ago
Sadly, alas -- not only are there plenty of ways that code written in typechecked/compiled languages can (despite these benefits) easily begin the irreversible slide into becoming unmaintainable (or otherwise high-maintenance) slop -- but many of the more popular choices for such languages seem almost expressly designed to facilitate this slide. Which also presents a risk to your "load-bearing" software (whatever that means). We get the theory and correctness parts. But in the trenches and on the ground, there are other factors to consider.
- naikrovek 5y ago
  I'm on the ground, too, you know. fighting different battles, I'm sure, but I'm fighting, same as everyone else. except I have something of a superpower that not everyone has: two and a half decades of hindsight. my experience tells me, without question, that smart development practices (which are never ever what you hear among the technological fetishists in this field, who chase newness and do not chase improvements) are almost always the ugliest and least structured up-front, and the most pleasant projects of all time by the time those projects are mature. there is no rule to guide you, other than to simply write what you need right now, and no more. when you need more, write more. Do not try to predict what you will need, because today is the day you are the least experienced you will be from this point onwards. you will be a better developer tomorrow. so write today only what you need today. tomorrow you will know more, need more, and you can add more, and fix what was already written by the less experienced you. there is no framework, no paradigm, no approach of any kind that creates good software (of any size) that does not evolve as the project itself evolves and as the developers evolve. none. and finally, the curse: when you're at an age no one listens to you, you will realize this as well.
  - akhmatova 5y ago
    Totally agree with you there (except for the 3 percent of the time when actually we do want to apply predictive branching, as it were, and brace ourselves for tomorrow's need rather than simply today's. That is arguably how the future gets built, in fact. But that there are outlier cases doesn't invalidate the main point of the principle you cite, of course). The rest -- frameworks, methodologies -- are window dressing (or at best training wheels), mostly.
johnthescott 5y ago
> Please use statically typechecked, compiled languages when writing load-bearing software. load-bearing ... gone steal that phrase. excellent.

akhmatova 5y ago

Sadly, alas -- not only are there plenty of ways that code written in typechecked/compiled languages can (despite these benefits) easily begin the irreversible slide into becoming unmaintainable (or otherwise high-maintenance) slop -- but many of the more popular choices for such languages seem almost expressly designed to facilitate this slide. Which also presents a risk to your "load-bearing" software (whatever that means). We get the theory and correctness parts. But in the trenches and on the ground, there are other factors to consider.

naikrovek 5y ago
I'm on the ground, too, you know. fighting different battles, I'm sure, but I'm fighting, same as everyone else. except I have something of a superpower that not everyone has: two and a half decades of hindsight. my experience tells me, without question, that smart development practices (which are never ever what you hear among the technological fetishists in this field, who chase newness and do not chase improvements) are almost always the ugliest and least structured up-front, and the most pleasant projects of all time by the time those projects are mature. there is no rule to guide you, other than to simply write what you need right now, and no more. when you need more, write more. Do not try to predict what you will need, because today is the day you are the least experienced you will be from this point onwards. you will be a better developer tomorrow. so write today only what you need today. tomorrow you will know more, need more, and you can add more, and fix what was already written by the less experienced you. there is no framework, no paradigm, no approach of any kind that creates good software (of any size) that does not evolve as the project itself evolves and as the developers evolve. none. and finally, the curse: when you're at an age no one listens to you, you will realize this as well.
- akhmatova 5y ago
  Totally agree with you there (except for the 3 percent of the time when actually we do want to apply predictive branching, as it were, and brace ourselves for tomorrow's need rather than simply today's. That is arguably how the future gets built, in fact. But that there are outlier cases doesn't invalidate the main point of the principle you cite, of course). The rest -- frameworks, methodologies -- are window dressing (or at best training wheels), mostly.

johnthescott 5y ago

> Please use statically typechecked, compiled languages when writing load-bearing software. load-bearing ... gone steal that phrase. excellent.