3 ms·

I thought the line The problem of software development is not “how to implement a solution to a given problem without shooting yourself in the foot”. It i

I thought the line The problem of software development is not “how to implement a solution to a given problem without shooting yourself in the foot”. It is to formalize something that in its nature is informal and unformalizable. was particularly good. This, I think, explains some of my dislike for static type systems. It's a formalization that doesn't help me with solving the problem I'm looking at. It's not necessarily formalizable.

ReactiveJelly 6y ago
I like static type systems because I don't like the idea of branching on types at runtime. So if every value is going to have one type anyway, I might as well check what it is before runtime. Lua has some functions that will take different types and do different things with them, but I'd rather do that with polymorphism than with dynamic types.
- lioeters 6y ago
  I see type systems like database schema, they're about domain modelling. Sometimes it can be a pain while the models are in flux, while the problem is being solved. But as the solution becomes clearer, having the models "formalized" in strong types provides a solid foundation, and supports long-term development and maintenance. --- To bring it back to the topic/article at hand, the author emphasizes the translating of business problems into conceptual models in software. Business and domain-specific problems as described by the user or client, is like the most ambiguous form of "software", communicated in human language. That includes dynamic or implicit typing, unstable and contradictory data schemata, scopes that leak into each other, unclear logic. That means, software developers ought to become more "multi-lingual" and fluent in the language and thinking process of the users. When the author says, "Software development is largely a communication problem", I also see it as a cross-cultural communication problem. The translation - "formalization" - into computer-speak, into hardware/software terms, can never be perferct, since like all translation, there are huge missing areas from one culture or language to another, some concepts don't translate well (or at all), and necessarily, the worldview and biases of the translator will shape the result. That metaphor also implies, what's important is the shared understanding between cultures, let's say the "business" and the "tech/software" side. I agree with the author that it's up to the latter experts, to take on the responsibility of cultivating such understanding, to provide the vocabulary and conceptual framework for the business side to express their needs and problems, to collaborate in their solution and formalization to software.

ReactiveJelly 6y ago

I like static type systems because I don't like the idea of branching on types at runtime. So if every value is going to have one type anyway, I might as well check what it is before runtime. Lua has some functions that will take different types and do different things with them, but I'd rather do that with polymorphism than with dynamic types.

lioeters 6y ago
I see type systems like database schema, they're about domain modelling. Sometimes it can be a pain while the models are in flux, while the problem is being solved. But as the solution becomes clearer, having the models "formalized" in strong types provides a solid foundation, and supports long-term development and maintenance. --- To bring it back to the topic/article at hand, the author emphasizes the translating of business problems into conceptual models in software. Business and domain-specific problems as described by the user or client, is like the most ambiguous form of "software", communicated in human language. That includes dynamic or implicit typing, unstable and contradictory data schemata, scopes that leak into each other, unclear logic. That means, software developers ought to become more "multi-lingual" and fluent in the language and thinking process of the users. When the author says, "Software development is largely a communication problem", I also see it as a cross-cultural communication problem. The translation - "formalization" - into computer-speak, into hardware/software terms, can never be perferct, since like all translation, there are huge missing areas from one culture or language to another, some concepts don't translate well (or at all), and necessarily, the worldview and biases of the translator will shape the result. That metaphor also implies, what's important is the shared understanding between cultures, let's say the "business" and the "tech/software" side. I agree with the author that it's up to the latter experts, to take on the responsibility of cultivating such understanding, to provide the vocabulary and conceptual framework for the business side to express their needs and problems, to collaborate in their solution and formalization to software.