Correctness – A paradigm for sustainable software development • Hacker News Board

Re: Correctness – A paradigm for sustainable software development

#101

Post by adrianmonk » Fri, Apr 05, 2019, 10:42 PM UTC

perlgeek wrote: post #18

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…

I thought they did a good job of acknowledging that with the section called "Correctness does not mean perfection". They're trying to treat that as an issue which is also valid but is separate, which made sense to me.

Re: Correctness – A paradigm for sustainable software development

#102

Post by joe_the_user » Fri, Apr 05, 2019, 10:55 PM UTC

naasking wrote: post #75

joe_the_user wrote: post #72

Earlier quoted context omitted.

OOP definitely allows you to add both data abstraction and procedure abstraction. FP is opinionated concerning how one should abstract and OOP is fundamentally less opinionated - for good or ill (that is pretty much the debate).

> OOP definitely allows you to add both data abstraction and procedure abstraction. No it doesn't, not pure, typed OOP [1]. Unless you introduce dynamic types, then neither is more opinionated because you can just cast or dispatch at whim. [1] https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf

In the vast majority of OOP language, the object allows one to do virtually anything behind the scenes with a bit of construction (plus of course functional programming is opinionated. There are a whole variety of definitely bad practices an FP programmer will point to as being disallowed by the FP).

See: "Closures And Objects Are Equivalent" etc.

http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent

And

https://stackoverflow.com/questions/2497801/closures-are-poo...

Re: Correctness – A paradigm for sustainable software development

#103

Post by adrianmonk » Fri, Apr 05, 2019, 11:11 PM UTC

perfunctory wrote: post #11

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.

If you think of it as an economics problem, it raises a question, one which I'm not completely convinced I know the answer to.

Namely, is crappy software actually more efficient? Does it deliver more value for less cost? Or is it, instead, that crappy software is a bad value, but markets are not transparent enough, and it is too hard for clients to assess whether the software they have received is crappy and too hard for businesses to convince people to pay them for quality?

If you hire a maid who always manages to miss a spot or two cleaning your bathroom, does it really matter? Your bathroom is a lot cleaner than it would've been otherwise, so mission accomplished in the grand scheme of things.

On the other hand, if you hire a mechanic to overhaul your car engine, you might not be able to tell the difference when you drive it home from the repair shop, but if they did a poor quality job, it is going to come back to bite you. Quality is important even if you need to pay more to get it.

Which one of these two things is software more like? I could see it going either way. Maybe it depends. Maybe there are ways you can cut corners that are a win (more value / less cost) and other ways that are a loss.

Re: Correctness – A paradigm for sustainable software development

#104

Post by tathougies » Fri, Apr 05, 2019, 11:20 PM UTC

gambler wrote: post #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 toutin…

State handling in FP is a long solved problem. Actually, state handling in pure functional languages is often better and more easily understood than the wild wild west of imperative languages. I would probably try to understand the field more before offering criticism

Re: Correctness – A paradigm for sustainable software development

#105

Post by Tehnix » Fri, Apr 05, 2019, 11:21 PM UTC

pron wrote: post #92

marcosdumay wrote: post #91

Earlier quoted context omitted.

There is a large amount of evidence that shows that homeopathy isn't effective. As far as evidence goes, there is more evidence pointing that FP leads to correctness than otherwise, although none of it is conclusive.

> There is a large amount of evidence that shows that homeopathy isn't effective. That's not quite how evidence for the existence of effects works. Evidence for lack of an effect is the attempt, and subsequent failure, to find it. Few studies have been able to substantiate the hypothesis that homeopathy is very effective, just like the case for FP. It's just that there have been far fewer studies overall testing the…

>> there is more evidence pointing that FP leads to correctness than otherwise

> There isn't.

But there is. Take this paper for example, http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf "A Large Scale Study of Programming Languages and Code Quality in Github".

"The data indicates functional languages are better than procedural languages; it suggests that strong typing is better than weak typing; that static typing is better than dynamic; and that managed memory usage is better than un- managed. Further, that the defect proneness of languages in general is not associated with software domains. Also, languages are more related to individual bug categories than bugs overall."

Re: Correctness – A paradigm for sustainable software development

#106

Post by tathougies » Fri, Apr 05, 2019, 11:25 PM UTC

tombert wrote: post #66

yakshaving_jgt wrote: post #5

Earlier quoted context omitted.

> 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.

I love Haskell, so I say this with all the love in the world, but the unpredictable nature of Haskell's performance actually can lead to incorrect code. For example, due to laziness, file-streaming with lazy IO can end up with files being closed before you're done consuming. This is almost certainly never what you want, so Haskell's system actually hurt correctness. In that particular case it's easy to get around if…

File streaming with lazy IO is widely considered an anti pattern though. So while your criticism was true in the past, we have very good and performant alternatives today

Re: Correctness – A paradigm for sustainable software development

#107

Post by dragonwriter » Fri, Apr 05, 2019, 11:25 PM UTC

gambler wrote: post #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 toutin…

> However, large-scale systems almost always have state

Managing state is a central part of what FP systems do; a normal Haskell program is, in a sense, a function that returns an imperative program for handling stateful interaction. The stateful and stateless parts are clearly distinguished so that the problems associated with state can be managed more effectively and don't make it hard to reason about parts of the program that have no reason to be state-sensitive.

While the mechanisms are different, that separation seems broadly the point of most pure FP systems and many impure ones.

Re: Correctness – A paradigm for sustainable software development

#108

Post by Karrot_Kream » Fri, Apr 05, 2019, 11:29 PM UTC

dual_basis wrote: post #96

gambler wrote: post #71

Earlier quoted context omitted.

Too late for editing. Here is what I wanted to add: Low-level code correctness is overrated. With some experience it's trivial to achieve even in a crappy language like Java. Nothing except horrible syntax stops you from writing "functional" code in Java (and even that became easier in Java 8). This is what I and all sensible engineers I know are doing. In my experience, this "weak" version of FP plus a few tests is…

I don't have the experience to assess your comments regarding the classes of errors you have seen in practice, but I'm interested in the other argument I have often heard of in favor of FP, that it is substantially better for concurrent coding.

Problems like #2 are all about emergent behavior problems, so thinking through 2nd and 3rd order effects. Isolating things in stateless functional units and using higher level constructs doesn't actually gift the engineer with the foresight to think through these problems. I agree with GP, these problems are orthogonal from using FP or OOP.

Re: Correctness – A paradigm for sustainable software development

#109

Post by toast0 » Fri, Apr 05, 2019, 11:33 PM UTC

dual_basis wrote: post #96

gambler wrote: post #71

Earlier quoted context omitted.

Too late for editing. Here is what I wanted to add: Low-level code correctness is overrated. With some experience it's trivial to achieve even in a crappy language like Java. Nothing except horrible syntax stops you from writing "functional" code in Java (and even that became easier in Java 8). This is what I and all sensible engineers I know are doing. In my experience, this "weak" version of FP plus a few tests is…

I don't have the experience to assess your comments regarding the classes of errors you have seen in practice, but I'm interested in the other argument I have often heard of in favor of FP, that it is substantially better for concurrent coding.

Not having shared memory eliminates a whole host of popular errors in concurrent languages; handling messaging explicitly as messaging forces an ordering on events, which is nice too.

Of course, you can still deadlock yourself; and read-modify-write can still be done in a racy fashion. Emergent properties of a system are still hard to reason about, but individual processes should be easy to reason about.

Re: Correctness – A paradigm for sustainable software development

#110

Post by dope99 » Fri, Apr 05, 2019, 11:38 PM UTC

mlthoughts2018 wrote: post #70

l_t wrote: post #45

Earlier quoted context omitted.

Interesting point. I think I've been feeling this lately as a desire to have, basically, smarter compilers. It's actually incredible to me when I think about how many minutes of human thought are wasted among myself and my peers to informally verify facts about our programs. Obviously, types and tests help. But it's astonishing how much incidental complexity creeps into one's everyday work with our current tools. Und…

I’ve programmed professionally in Haskell, Scala and Python in large projects across several jobs. In my experience, the compiler is rarely helpful at catching bugs. Most bugs, whether in a dynamic typing language or otherwise, are behavioral bugs that occur at runtime without generating explicit runtime errors, just incorrect but uninterrupted behavior. I always heard people make grandiose claims about Haskell, like…

I think most bugs are that kind that the compiler can catch. But yes absolutely a program can compile and be dead wrong. I’m writing a regex engine and lol at types saving me from all the mistakes I can make with building and transforming finite automata.

I’d still much rather have a slightly slow compilation than verify types in my head every time I’m in that area of code, or writing unit tests for every configuration of code which basically just validate I haven’t returned any nulls.

Typed compilation may take time, but it results in faster running programs. And unit tests also take time. I find the errors generated by a type checker come quicker and give more useful diagnostics for deep areas of the code.