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

Re: Correctness – A paradigm for sustainable software development

#71

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

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 enough to virtually eliminate low-level coding bugs.

You can still get some surprising behaviors from 3d-party libraries and stronger FP can help with that a bit, but it's nowhere near as drastic of an improvement as many people present.

There are two big classes of errors I do often see in real life.

1. Spec omissions aka systems Broken As Designed. Your system works the way you expect it to work, but produces results users did not anticipate.

2. Emergent problems. Like someone shutting down your service for a day, causing queue backup, causing a huge batch of data being sent to vendor when the service is back online, causing vendor to throttle you, causing all other jobs being delayed.

#1 seems to be mostly a matter of experience and knowing when to show people some diagrams. OOP and especially agent-oriented programming can actually help you when reasoning about #2.

Re: Correctness – A paradigm for sustainable software development

#72

Post by joe_the_user » Fri, Apr 05, 2019, 8:02 PM UTC

naasking wrote: post #52

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…

> 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. It's not higher-level, it just allows different types of abstraction. OOP is about procedural abstraction, ie. a set of procedures permits you to add new types, FP is about data abstraction, ie. a given…

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

Re: Correctness – A paradigm for sustainable software development

#73

Post by EdSharkey » Fri, Apr 05, 2019, 8:09 PM UTC

"Make it work, Make it right, Make it fast." - Kent Beck

My take on correctness is this: for ethical reasons, a developer should never be the final say on whether their solution is correct.

The users, whose voices are concentrated in the one and only Product Owner, should always have the final say on the correctness of our production code.

The tricky bit is proving to the Product Owner and ourselves that we have met the users' expectations.

I believe this is where testing and refactoring comes in. Language and programming paradigm choices are window dressing if the actual code is a slapdash mess with no formal proofs of correctness.

Until some genius comes up with something better, those proofs must take the form of fully passing, comprehensive test suites.

Re: Correctness – A paradigm for sustainable software development

#74

Post by gambler » Fri, Apr 05, 2019, 8:17 PM UTC

chalst wrote: post #68

gambler wrote: post #65

Earlier quoted context omitted.

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.

Pharo SmallTalk is getting some steam right now and worth checking out. Elixir is pretty cool. But I don't think either are the holy grail of OOP.

I would really like to see some OOP language that implements James Reed's reference versioning or at lest a weaker implementation where every object "mutation" creates an effective copy with the changes, without touching anything that would be referenced previously. It would fix a lot of low-level annoyances people have with SmallTalk, JavaScript and so on. Would be extra amazing if it was based on prototypes, not classes. But at this point it sounds like I would have to write it myself.

Re: Correctness – A paradigm for sustainable software development

#75

Post by naasking » Fri, Apr 05, 2019, 8:22 PM UTC

joe_the_user wrote: post #72

naasking wrote: post #52

Earlier quoted context omitted.

> 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. It's not higher-level, it just allows different types of abstraction. OOP is about procedural abstraction, ie. a set of procedures permits you to add new types, FP is about data abstraction, ie. a given…

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

Re: Correctness – A paradigm for sustainable software development

#76

Post by balfirevic » Fri, Apr 05, 2019, 8:30 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…

There was a big discussion on HN recently about what exactly the message-passing-oop is, with no apparent consensus: https://news.ycombinator.com/item?id=19416511

I don't have a strong opinion on the topic of OOP vs FP, but it's worth keeping in mind that people mean different things when they say OOP. Furthermore (and more importantly for this particular discussion), it also appears that people mean different things even when they specify they mean alan-kay/message-passing variant of OOP.

For many, it's something like Smalltalk and Ruby, with their very late binding and ability for objects to respond to messages even without matching methods. Others find Erlang and Elixir to be good embodiment of Alan Kay's vision. And the third groups seems to define it as "kind of like how bacteria communicate, and kind of like microservices", which is really too fuzzy for meaningful discussion.

In your link, Alan says: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."

That is... quite vague.

Re: Correctness – A paradigm for sustainable software development

#77

Post by pron » Fri, Apr 05, 2019, 8:35 PM UTC

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…

When I made that comparison I meant to highlight the fact that physics determines a certain minimal amount of work required to raise a body of a certain mass to the top of the mountain. Any improvements in efficiency is small in comparison to that required work. So that is the first thing we must understand: there is a large cost to building something complex, and nothing can drastically reduce it.

Formal methods -- or any other useful technique -- are beneficial only once you understand this. Most of the cost is determined by what you build, not how you build it, so the only way to drastically cut it is to build drastically less. Once you've decided what it is that you need to build, you must be ready to pay the cost.

Re: Correctness – A paradigm for sustainable software development

#78

Post by tombert » Fri, Apr 05, 2019, 8:37 PM UTC

yakshaving_jgt wrote: post #69

tombert wrote: post #66

Earlier quoted context omitted.

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.

Oh, definitely don't disagree with you there (PG's article about the "Blub" language is one of my favorites); I definitely think that Haskell is one of the least-bad languages out there overall.

I will say that personally I have become somewhat enamored with Idris, but I think that most of the people that work on it claim that it is not production ready, and I've not used it for anything but personal projects. Still, I love that it gives me everything that I like about Haskell, and it's young enough to not have many of the drawbacks, at least not yet.

Re: Correctness – A paradigm for sustainable software development

#79

Post by pron » Fri, Apr 05, 2019, 8:39 PM UTC

As someone who practices and encourages others to employ formal methods in software development, I'm disappointed to read a post that claims FP has some significant effect on correctness. This has not been established, and does not at all appear to be the case. There are many aspects, including techniques and tools, that can positively affect program correctness. The choice of a programming language or even a paradigm is not high on the list if it is on it at all. Not only does the little data we have not substantiate the hypothesis that FP has a significant positive effect on correctness, there are even significantly fewer anecdotal reports supporting that hypothesis than other, apparently more effective techniques. In short, any connection between FP and correctness is, at this point in time, nothing more than wishful thinking, and the efforts of those who really care about correctness are better spent elsewhere (i.e. not on picking a new language).

Re: Correctness – A paradigm for sustainable software development

#80

Post by iamleppert » Fri, Apr 05, 2019, 8:43 PM UTC

I just got off a job where my boss was under the impression that bugs are because of incompetence or laziness. He literally expected the code I produced to be of perfect quality, or else, using his words “you don’t know what you’re doing”. I told him about how most major companies have QA teams and engineers spend a lot of time fixing bugs and reviewing others’ work.

My (now former) boss was non-technical. Wondering if anyone else has encountered such a person? Coming from other industries, is it common that people view software engineers as somehow sloppy or lazy in their work? Is it really true? Is it unreasonable to expect a competent engineer produce working, correct & bugfree performant code on the first try? I’ve definitely had my moments of brilliance where it all “just worked” but that usually isn’t the case and I’m wondering if it could be something wrong with me?