Into the Tar Pit

Re:Into the Tar Pit by wry_discontent on Saturday May 23, 2020 @09:45AM (#23282886)

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.

[ Parent | on HN ]

Re:Into the Tar Pit by ReactiveJelly on Saturday May 23, 2020 @11:51AM (#23283921)

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.

[ Parent | on HN ]

Re:Into the Tar Pit by lioeters on Saturday May 23, 2020 @12:28PM (#23284252)

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.

[ Parent | on HN ]