Correctness 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 – A paradigm for sustainable software development
11–20 of 186 posts
Re: Correctness – A paradigm for sustainable software development
#12I hope this article strikes a chord. Two quibbles: Haskell is prone to something that might be considered a class of bug that Rust avoid: the space and time performance of idiomatic Haskell code can be very surprising. I also wonder at the possible answers you give to " “When” would you say that the software had a bug?" - the most obvious answer to me is when the commit is made to the codebase that introduces possibl…
You're not wrong about unpredictability (to an extent), but the idea that Haskell is 'slow' has really got to go. Compared to languages commonly in use today, Python, Ruby, etc, Haskell goes like lightning with basic optimization (the kind C and C++ programmers are used to). The fact is that, for the vast majority of workloads, which are not heavily algorithm dependent, idiomatic Haskell is going to be much faster th…
> idiomatic Haskell is going to be much faster than what most people are using.
I am not trying to be pedantic, but your point is moot if you consider what "most people" are using are not dynamically typed interpreted languages like Python Ruby or PHP, but rather statically typed, compiled languages like Java, C#, and C++. Java by itself dwarfs Python and Ruby combined.
Re: Correctness – A paradigm for sustainable software development
#13I started learning to write Haskell a while ago. My current reflection is while it’s easy to start learning to write simple code and correct code it a much larger step to actually be able to write performant code that is generic. Performant idiomatic Haskell requires a good enough understanding of the functional paradigm.
Re: Correctness – A paradigm for sustainable software development
#14>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 touting their FP horn and bashing OOP without any qualifiers. This is getting as annoying as Java people posting their design pattern nonsense as if it was something good.
If you know what a monad is, you should also know the founding ideas behind OOP.
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
The ideas make sense. Moreover, Kay has an amazing track record of saying unpopular things and being proven right in the long run. If you spend some time looking into it, you should see that his high-level intuitions about software architecture are proving to be correct, despite many of his critics. A lot of hyped-up modern technologies are implicit, ad-hoc, overly complex implementations of OOP ideas done without realizing they are such. The whole IT industry would be far better off if people took time to look into and understand the original ideas behind OOP.
1. OOP is a higher-level paradigm than FP, so people comparing them directly usually are missing the point to begin with. OOP systems can be implemented in functional languages or use functional-flavored components.
2. It is beneficial to model algorithms without using state. FP is very good that that. (Boring but practical example: LINQ vs loops and variables in C#. Functional LINQ pretty much always "wins", just like Streams always win in Java.) However, large-scale systems almost always have state. If you do not have some wise approach for handling it, your designs will have issues at system level. OOP is one such approach and at that level its ideas have a lot of value.
I'll edit this post later to add a few more points.
Re: Correctness – A paradigm for sustainable software development
#15I 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 efficiently scaling mountains requires a broader scope. This is why I think formal methods are starting to break into the mainstream: they give us tools to use to simulate and verify designs (model checking, system design validation), validate implementations (verification, proof), and generate provably correct code from high level specifications (synthesis).
Grumpy programmers who think maths is for academics are going to miss out I think. It's an exciting field and the cost for something that used to be only used for extreme circumstances has been coming down so rapidly that it can be effectively used in small businesses as well.
It all comes down to clarity: in communication, in thought, and in practice.
Re: Correctness – A paradigm for sustainable software development
#16I'm honestly having a hard time figuring out what the take-away from this article is. It claims to to lay out a paradigm but it doesn't really seem to lay it out all that clearly.
Re: Correctness – A paradigm for sustainable software development
#17Unfortunately, there are increasingly important areas where correctness isn't even well-defined, including social networks, machine learning, performance, and UI design. Things can go very wrong without violating a traditional algorithmic correctness constraint.
But it helps to eliminate large classes of bugs where you can, so you can concentrate on other things.
Re: Correctness – A paradigm for sustainable software development
#18This 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 "correct" software in such a context, whatever that means?
How do I deal with low quality of input data, when I can't ask my product owner to create a matrix of each case of missing data and behavior, because that would be exponential in size?
Phrased another way, the problems with correctness that seem to trouble the author are not the problems with correctness that I tend to encounter often in my work.
The case where there is a clear-cut bug in an algorithm tend to be easier to debug and fix than a bug that stems from several department having subtly different ideas of what certain pieces of data and action mean.
Re: Correctness – A paradigm for sustainable software development
#19>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?
Re: Correctness – A paradigm for sustainable software development
#20>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?
If functional programming were implemented as widely and abused as much as OOP is, would it really fare any better?