Correctness – A paradigm for sustainable software development
nonullpointers.com
Correctness – A paradigm for sustainable software development
1–10 of 186 posts
Re: Correctness – A paradigm for sustainable software development
#2I 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 possibly observable incorrect behaviour.
Re: Correctness – A paradigm for sustainable software development
#3I 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…
I think it's experimental right now, but Idris (which I consider the "Child of Haskell"), has basic support for linear types [1], which could at least help the space-prediction problems. Doesn't hurt that Idris isn't lazy-by-default either.
My point is that I actually think that Idris could end up being successful in an industrial sense, due to the fact that it gives you all the correctness guarantees of Haskell (and more), but has managed to (thus far) avoid a lot of the cruft that has built up in the ~30 years Haskell has been around. Fingers crossed.
[1] http://docs.idris-lang.org/en/latest/reference/uniqueness-ty...
Re: Correctness – A paradigm for sustainable software development
#4> Developers — focusing on correctness. This is the paradigm shift that we are starting to see.
I haven't seen this yet, but I sure hope to. I'm stuck in the "everyone does devops now" paradigm :(
Re: Correctness – A paradigm for sustainable software development
#5I 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…
> the space and time performance of idiomatic Haskell code can be very surprising.
That is indeed one of Haskell’s drawbacks, though personally it’s one I am comfortable with given the alternatives. I’m happy for a program to be correct and less performant than fast and wrong. The performance issues are also not intractable. The tools for measuring this are pretty good.
Re: Correctness – A paradigm for sustainable software development
#6The biggest problem is communication and setting expectations. I constantly hear/see people saying "oh that will be quick!" without any real evaluation of the work. Simply saying "this is hard, it will take some time" makes focusing on correctness a hell of a lot easier. In no uncertain terms: don't be a pushover. If it can't be done well in the amount of time you suggest, don't say that it can be. You're just digging a hole for yourself (both present and future) and any one you work with.
Re: Correctness – A paradigm for sustainable software development
#7The biggest problem is communication and setting expectations. I constantly hear/see people saying "oh that will be quick!" without any real evaluation of the work. Simply saying "this is hard, it will take some time" makes focusing on correctness a hell of a lot easier. In no uncertain terms: don't be a pushover. If it can't be done well in the amount of time you suggest, don't say that it can be. You're just diggin…
This is easy to say and not unheard of, but in organizations it is common (in my experience at least) that if you say too often "this is hard and might take some time", people will just start to bypass you (and/or your input/judgement) in order to get stuff done quickly but less correctly.
Re: Correctness – A paradigm for sustainable software development
#8I 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 than what most people are using. For the algorithm dependent ones, a Haskell programmer familiar with GHC's optimization layer should suffice to get very good performance. I've written several high performance Haskell programs, and it's moderately time consuming but not anymore difficult than other languages.
Re: Correctness – A paradigm for sustainable software development
#9There are several strongly typed (and functional) languages being built for the web that compile to JavaScript:
ReasonML - OCaml - https://reasonml.github.io
PureScript - Haskell - http://www.purescript.org
TypeScript - https://www.typescriptlang.org
Scala.js - http://scala-js.org
Elm - https://elm-lang.org
ghcjs - Haskell (https://github.com/ghcjs/ghcjs)
Re: Correctness – A paradigm for sustainable software development
#10I 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…
If Haskell allows you to express code as simple and correct at the expense of being fast, I think arguments can be made both ways as to whether or not that's a bug. If we accept the premise that the first two are more important than the last, then I think it follows that it's not a bug.
To your second point, I think the author is making an argument that it can perhaps even be earlier than that: the bug is introduced when the programmer's model of the behavior differs from reality. That is to say, the "bug" exists purely in the developer's mind. After that it's a matter of course for the bug to be transferred from there to the codebase.
If the developer chooses to interrogate their model before committing it to code, there is the possibility of the bug being caught before it ever makes it into the codebase. But perhaps it is still correct to say the bug still existed, for a short time, at least.