This is a very backend/algorithm-centric view of correctness. What about user interfaces? What is a "correct" user interface? If a bug is "unexpected" behavior, and my user interface has several thousand users, how do I manage to not produce unexpected behavior to anybody? Many software supports workflows and processes in some enterprise, and those workflows shift subtly over time. How does Haskell help me write "cor…
Correctness – A paradigm for sustainable software development
31–40 of 186 posts
Re: Correctness – A paradigm for sustainable software development
#32>The thing you need to look at if you’re using say, a dynamic language, or object oriented design, is that in the long term, what is the language and mindset of “objects” with dynamic dispatch providing you apart from an endless stream of bugs that seem to keep reoccurring everytime you try an evolve the software to introduce a new requirement? I am sick and tired of the arrogant, willfully ignorant developers toutin…
This is a bit like the "Islam is a religion of peace" discourse. I'm sure it is, but: OOP as actually implemented and found in the wild isn't about Smalltalk or message passing. It's about transforming functions into methods by unnecessarily wrapping behaviour in classes, as an example of cargo-cult programming. OOP the idea is great. How do you actually find it in the world?
> How do you actually find it in the world?
It works. It is a sufficiently good model for many domains, even though it obviously is "impure" by combining the domain model and generally a whole lot of implementation details nee requirements.
It clearly is an unreasonably effective strategy that has no solid theoretical footing, yet that does not prevent it from working in practice.
Re: Correctness – A paradigm for sustainable software development
#33Earlier quoted context omitted.
If functional programming were implemented as widely and abused as much as OOP is, would it really fare any better?
exactly, I feel the same way. OOP is often criticised from functional programming, but also from data-driven programming, for example. You never hear functional programming advocates criticise data-driven programming. The use cases are so different that it wouldn't make sense. To use OOP properly is probably as complicated as doing functional programming or data-driven programming properly. The "problem" is that the…
I've seen data-driven code and it is full of OOP. Those are hardly orthogonal concepts. Arguably DD (on the pedal to the metal C/C++ level) doesn't quite match the OOP choir in terms of looks.
Re: Correctness – A paradigm for sustainable software development
#34This is a very backend/algorithm-centric view of correctness. What about user interfaces? What is a "correct" user interface? If a bug is "unexpected" behavior, and my user interface has several thousand users, how do I manage to not produce unexpected behavior to anybody? Many software supports workflows and processes in some enterprise, and those workflows shift subtly over time. How does Haskell help me write "cor…
A workflow can be modeled using something like a state machine or statecharts. That can be encoded into the type system in a language like Haskell. For front end stuff, you could model your system using something like [0] which uses statecharts. An example of unexpected behavior: Is it possible for a user of your application or site to end up in a state where the only next step is to close it and restart? Or can they properly navigate from nearly any display to any other? While the linked tool doesn't directly answer those questions, it will help you construct your models in a way that you can manually evaluate them more easily or convert to a TLA+ or similar specification and have the computer check that.
Could you, or should you, use formal methods for everything? No. But it can be applied pretty broadly if you're open to it, and in fairly lightweight ways (especially these days since there's been a ton of interest over the last few years).
Once you start recording your formal (or more formal) specs, you can also share them more easily. A major problem in coordinating with so many different groups is that they all have their own model for what's going on based on their interaction with the systems. By creating more formalized models that allow for clearer communication (a few statecharts versus pages and pages of prose; flow charts versus pseudocode) you can reduce the communication error between teams/departments. And with all the recent work going into it, and using more capable languages (or tools with less capable languages) you can encode much of this into your program and make correct system construction more feasible.
Re: Correctness – A paradigm for sustainable software development
#35Correctness is not an engineering problem. It's an economics problem. As long as IT Industry is able to extract money from their clients while delivering crappy software, they will keep delivering crappy software.
> Correctness is not an engineering problem. It's an economics problem
It could be argued that all engineering problems _are_ economic problems.
Re: Correctness – A paradigm for sustainable software development
#36Correctness is not an engineering problem. It's an economics problem. As long as IT Industry is able to extract money from their clients while delivering crappy software, they will keep delivering crappy software.
Note that as an economics problem is it important to ask if it is worth the cost. Most software doesn't actually need that level of correctness. As we get more and more automated more and more software will get there.
Right now there is no reason to think games will even need that level.
Re: Correctness – A paradigm for sustainable software development
#37>The thing you need to look at if you’re using say, a dynamic language, or object oriented design, is that in the long term, what is the language and mindset of “objects” with dynamic dispatch providing you apart from an endless stream of bugs that seem to keep reoccurring everytime you try an evolve the software to introduce a new requirement? I am sick and tired of the arrogant, willfully ignorant developers toutin…
To add more specific examples.
If you want to understand OOP idea do not think about Java/C# classes and inheritance. Think about OS processes/IPC or microservices. These are Objects. This is the basic idea behind OOP.
Getter/setter is the main anti-pattern of OOP design.
Re: Correctness – A paradigm for sustainable software development
#38>The thing you need to look at if you’re using say, a dynamic language, or object oriented design, is that in the long term, what is the language and mindset of “objects” with dynamic dispatch providing you apart from an endless stream of bugs that seem to keep reoccurring everytime you try an evolve the software to introduce a new requirement? I am sick and tired of the arrogant, willfully ignorant developers toutin…
> 1. OOP is a higher-level paradigm than FP , so people comparing them directly usually are missing the point to begin with. [emphasis added] How so?
Not the OP, but I might have some context.
I think of OOP as a message passing paradigm. It's concerned with how messages are passed from one part of the system to another. It is not particularly concerned with how those messages are implemented under the hood. In that sense it's a higher level paradigm because OOP is all about building abstractions ("objects") and defining how they communicate, rather than wiring code together directly. FP doesn't really have anything to say about how you design your abstractions, just how you implement them in code.
Re: Correctness – A paradigm for sustainable software development
#39I had a thread on twitter about this problem of "musicians nerding over gear." In our metaphor it was about mountain climbers. The programming language and its paradigms chosen may have some effect on how you scale the mountain but the real problem is the mountain. Whether you use functional programming or dynamic typing it only affects small, local problems in the practice of climbing mountains. The problem of effic…
"...but the real problem is the mountain." Terrific metaphor, thank you. I've been stuck with "the map is not the territory" for ages, which is too meta for polite convo. With "maps / territory", I never thought to ask "do we have to summit the mountain? can we take the valley, the pass? can we tunnel? go around?" "Grumpy programmers who think maths is for academics are going to miss out" Probably. I'm still stuck ea…
The original thread: https://twitter.com/pressron/status/1109974207243390977
Where I chimed in: https://twitter.com/agentultra/status/1112752548656660482
Re: Correctness – A paradigm for sustainable software development
#40I had a thread on twitter about this problem of "musicians nerding over gear." In our metaphor it was about mountain climbers. The programming language and its paradigms chosen may have some effect on how you scale the mountain but the real problem is the mountain. Whether you use functional programming or dynamic typing it only affects small, local problems in the practice of climbing mountains. The problem of effic…
Amy pointers to documentation that's approachable by beginners?