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

Re: Correctness – A paradigm for sustainable software development

#61

Post by User23 » Fri, Apr 05, 2019, 6:44 PM UTC

Without a specification the correctness of a program is necessarily undefined. This means that most buggy software isn’t incorrect. In fact most buggy software isn’t even unpleasant, at least insofar as users prefer using it to not and continue to pay.

It follows that as commonly used the term bug refers to a pleasantness defect rather than a correctness defect. And this stands up to our day to day experience. In the overwhelming majority of cases users report bugs because they are displeased by a behavior, not because they studied the specification and discovered a correctness error.

Re: Correctness – A paradigm for sustainable software development

#62

Post by agentultra » Fri, Apr 05, 2019, 6:45 PM UTC

nickpsecurity wrote: post #60

gtirloni wrote: post #21

Earlier quoted context omitted.

Amy pointers to documentation that's approachable by beginners?

Check out the Alloy model checker. Simple with GUI, too. One guy I know says he just uses it like SQL. Hillel Wayne just published Practical TLA+. It helps with concurrency and distributed systems. There's the book on SPARK Ada which lets you do system code that's provably safe. Finally, the easiest method to use in any language is Design-by-Contract. https://www.betterworldbooks.com/product/detail/Practical-TL... ht…

I recently started using Alloy for small models. Great for searching for constraints and state machines.

Re: Correctness – A paradigm for sustainable software development

#63

Post by chalst » Fri, Apr 05, 2019, 6:51 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…

I agree that the "whole IT industry would be far better off if people took time to look into and understand the original ideas behind OOP". I also agree that OOP can be great at modelling system-level state. And about the compatibility between OO and FP, coming from a pure-FP background, I became very impressed by the advantages of combining FP with OO when I started to learn an ancestor of OCaml in the late 90s.

But... dynamic dispatch is a source of errors when it is very often possible to get the benefits via type classes, giving strong compile-time guarantees.

It's possible to understand "OOP is a higher-level paradigm than FP" in more than one way. I see no fundamental reason why you can't model the top-level interactions of a system using FP. And if state has been wrapped in a monad, you can chase the state through the codebase looking at the typeclasses inferred.

Re: Correctness – A paradigm for sustainable software development

#64

Post by bsmith » Fri, Apr 05, 2019, 6:59 PM UTC

I know this is a nit, but the incorrect use of commas is making this a really tough read for me...pet peeve of mine, I suppose. Anyway, salient points: use the right tools for the right jobs and all that jazz. Depends on the required level of correctness for the application. Are we coding for an airplane control system, or a slack bot that lets us know when the build biffs?

Re: Correctness – A paradigm for sustainable software development

#65

Post by gambler » Fri, Apr 05, 2019, 7:03 PM UTC

beders wrote: post #41

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…

OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for). But you are not staying in your pure OO-world nowadays. There's always the boundary issue where you are giving up your careful encapsulation and where state needs to be transferred instead of being hidden away in some object (like exporting to JSON). Poof, your encapsulation is gone. Furtherm…

Sorry, but you're just validating my stereotype of a typical OOP critic.

OOP != Java.

>OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for).

Most problems most programmers solve are simulation in some sense. Including DevOps. I wish larger number of people realized this. Things would become much simpler.

The problem with class-oriented languages like Java is precisely that they are horrible for making simulations. Been there, done that.

>There's always the boundary issue where you are giving up your careful encapsulation and where state needs to be transferred instead of being hidden away in some object (like exporting to JSON). Poof, your encapsulation is gone.

Solving boundary issues is what OOP was designed for. Like, that's literally the original goal of the whole concept, as explained by Alan Kay many, many times.

You were able to send objects over the wire in Smalltalk in the 70s. Every time you open a webpage with JavaScript you're performing an ad-hoc reenactment of the same idea. The fat that this idea is implemented badly on the web doesn't mean this is a bad idea.

>Furthermore, may OOP languages don't deal with ownership at all. If I'm a constructor and someone passes me an object A or worse, a list of As. Can I hold onto that list? Should I make a shallow copy? Should I make a deep copy, because I need the A objects in the state they are currently in?

This problem has been solved in 1978.

http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-20...

>Can I call methods on objects from multiple threads? I need to rely on the documentation to figure that out or provide synchronization myself just to make sure I'm not breaking things.

See the paper above.

BTW, guess how I found it? Alan Kay's talks.

>Too bad if someone then passes me data that only fits the old classes and too bad if consumers of my library are getting nasty surprises.

Again, getting rid of "raw data" was one of the core motivations behind OOP. See the email above.

Re: Correctness – A paradigm for sustainable software development

#66

Post by tombert » Fri, Apr 05, 2019, 7:09 PM UTC

yakshaving_jgt wrote: post #5

chalst wrote: post #2

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

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 you use the Conduit library, but that's just one example.

Re: Correctness – A paradigm for sustainable software development

#67

Post by axlprose » Fri, Apr 05, 2019, 7:34 PM UTC

ummonk wrote: post #50

depressed wrote: post #20

Earlier quoted context omitted.

If functional programming were implemented as widely and abused as much as OOP is, would it really fare any better?

You can already see examples of this. Take callback hell. Opaque callbacks are the functional equivalent of goto statements. Also, many functional programmers, particularly Haskell programmers, seem not to care about readability and maintainability. They're focused on maximizing their own productivity as an individual coder, and writing cool concise and abstracted code that might not actually be easy for another engi…

>particularly Haskell programmers, seem not to care about readability and maintainability

Say what you want about the foreign-ness of the syntax, but Haskell code is some of the most maintainable code out there. I can often times dive into another person's haskell code and grok it more easily than the equivalent code in a "friendlier" language like python or ruby, nevermind a more comparable language like scala. Haskell is also a breeze to refactor, the compiler and type system make changing and moving arbitrary chunks of code around pretty straight-forward, even when the code is using abstractions you're not familiar with; something which cannot be said for many other languages. The biggest downside to haskell (apart from the learning curve) is having to deal with cabal+stack.

Re: Correctness – A paradigm for sustainable software development

#68

Post by chalst » Fri, Apr 05, 2019, 7:41 PM UTC

gambler wrote: post #65

beders wrote: post #41

Earlier quoted context omitted.

OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for). But you are not staying in your pure OO-world nowadays. There's always the boundary issue where you are giving up your careful encapsulation and where state needs to be transferred instead of being hidden away in some object (like exporting to JSON). Poof, your encapsulation is gone. Furtherm…

Sorry, but you're just validating my stereotype of a typical OOP critic. OOP != Java. >OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for). Most problems most programmers solve are simulation in some sense. Including DevOps. I wish larger number of people realized this. Things would become much simpler. The problem with class-oriented languages…

I'm curious as to which languages you do recommend. You don't see Smalltalk being used a whole lot in devops.

Actually, class-based handling of raw data can be done very nicely if you have multiple dispatch, which solves the so-called expression problem. Cf Julia.

Re: Correctness – A paradigm for sustainable software development

#69

Post by yakshaving_jgt » Fri, Apr 05, 2019, 7:44 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…

I appreciate criticism like that, because it's helpful and valid. I happen to be aware of this and I do use Conduit often, but it certainly bears talking about. Haskell isn't a panacea, but I absolutely do not believe that all technologies are ultimately equivalent.

Re: Correctness – A paradigm for sustainable software development

#70

Post by mlthoughts2018 » Fri, Apr 05, 2019, 7:56 PM UTC

l_t wrote: post #45

agentultra wrote: post #15

I 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…

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 if you get your program to compile, it’s very likely to be correct and run without error. I’ve emphatically never found that to be true.

The types of bugs that compilers can help with are very simplistic most of the time. Requesting a method or attribute that doesn’t exist, typos, confusion about arguments passed to a function.

In dynamic typing, you also solve these same things in a super cheap and low effort way with unit tests.

Additional behavioral unit tests are where real effort becomes required, and these are needed in any paradigm.

Compilers are also not free. My experience with the Scala compiler for example was awful. It is so incredibly slow to compile that I absolutely would rather give up type checking and just use some cheap unit tests to have a much faster development cycle. When you make 1 or 2 small changes and even a smart incremental compiler setup like zinc needs to recompile 30 code units and it takes ~ 3 minutes before you can run tests, this is maddening, and the cycle repeats the whole time you’re working, so it’s this constant extremely disruptive expense.

I’ve had similar thinga happen in legacy code bases with Haskell too.