Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Correctness – A paradigm for sustainable software development

nonullpointers.com

Post reply on HN
Print view View original

51–60 of 186 posts

Re: Correctness – A paradigm for sustainable software development

#51

Post by pierrebai »

I've been thinking about this subject for a while and been on the verge of writing about it.

The thing is, I've come to the opposite conclusion.

My conclusion is that programmers have been trained to think about correctness. What they should be trained on and design is to account for inevitable failures. My main paradigm is the floating point design. It incorporates a built-in invalid value, which neatly propagates itself. Objective-C also has this concept of propagating a chain of failures accross function calls.

Your programs will be buggy, your data will be wrong. Design to support propagating it with null actions and detect it at the top of your action loop.

(One of the unfortunate heritage of computin ghistory is the missed opportunity of the binary system imbalance around zero. Both 1-complement and 2-complement have abnormal values. In 1-comp, it's negative zero. In 2-comp, it's the fact that the most negative number has no positive value and is its own negation (- INT_MIn == INT_MIN). It was an opportunity to reserve such value for invalid integers. Then you design your null pointer to be that value too, and NAN to be that bit pattern. Than all your fundamental invalid values map to the same bit pattern that can easily be propagated. Oh well.)

Re: Correctness – A paradigm for sustainable software development

#52

Post by naasking »

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 set of data types permits you to add new procedures.

Most OOP languages are not pure OOP, so they permit some data abstraction as well, and FP languages with good module systems also permit procedural abstraction.

Re: Correctness – A paradigm for sustainable software development

#53

Post by ummonk »

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…

Formal methods are to programming like ropes are to mountain climbing.

>Whether you use functional programming or dynamic typing it only affects small, local problems in the practice of climbing mountains.

Static typing is a type of formal method.

Re: Correctness – A paradigm for sustainable software development

#54

Post by microtherion »

skybrian wrote: post #17

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

I agree. Reasoning about correctness can be a very powerful tool for some of the algorithmic parts of a system. But large parts of a system are not really amenable to formal reasoning about correctness.

As an example, if you try to write our own web search engine, the linear algebra or neural network operations you may be using are certainly amenable to mathematical reasoning, but the relevancy of the returned results is not something you can prove mathematically.

And in my opinion, this fact often leads "correctness" fanatics to retreat to safe areas where their methods work, and snipe at all the rest of the world. Characteristically, the article quotes E.W.Dijkstra, whose much beloved notes are full of explorations of mathematical toy problems, and catty dismissals of anybody trying to make real world use of computers.

When Knuth was dissatisfied with the results of early computer typesetting, he spent years of his life developing TeX. Meanwhile, Dijkstra kept hand writing his papers and having staff turn them into printed form. That, to me, is the epitome of the "correctness über alles" mindset.

Re: Correctness – A paradigm for sustainable software development

#55

Post by agentultra »

aeorgnoieang wrote: post #46
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…

One problem with your metaphor about mountain climbers and mountain climbing is that the most efficient way to scale a mountain is probably to just take a helicopter to the top. Mountain climbing, like lots of other things, _must_ be constrained, in some way, to be _meaningful_, and the constraints _chosen_ reflect the _purpose_ of the endeavor. But then, specific constraints, e.g. the tools and methods 'allowed', be…

It's an analogy. There are holes in every analogy.

The image I was trying to invoke and the idea implied was that programming languages are insufficiently expressive enough on their own to solve the hard problems in designing systems. They lack the ability to reason abstractly about other processes, agents, and shared state such that they cannot prove anything about their behavior in the context of a larger system. They can't express invariants about the complicated universe of possible behaviors. And the kinds of problems we're tackling today are built on large systems: several interacting processes over an unreliable network working in concert across the globe to keep your data consistent and always available: that's the mountain. Arguing about which programming language or paradigm to use has only a small part to play in the solution to the problem.

Re: Correctness – A paradigm for sustainable software development

#56

Post by dpc_pw »

agsamek wrote: post #37
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…

To add more specific examples. If you want to understand OOP idea do not think about Java/C# classes and inheritance. Think about OS processes/IPC or microservices. These are Objects. This is the basic idea behind OOP. Getter/setter is the main anti-pattern of OOP design.

Personally, I call that "Actors", not "Objects". In my experience OOP in practice means: objects, classes, inheritance, class hierarchies, despite the original intention (think Smalltalk-like).

Re: Correctness – A paradigm for sustainable software development

#57

Post by Jtsummers »

microtherion wrote: post #54
skybrian wrote: post #17

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

I agree. Reasoning about correctness can be a very powerful tool for some of the algorithmic parts of a system. But large parts of a system are not really amenable to formal reasoning about correctness. As an example, if you try to write our own web search engine, the linear algebra or neural network operations you may be using are certainly amenable to mathematical reasoning, but the relevancy of the returned result…

That seems to be an unfair assessment of Dijkstra's interests and activities. He made major contributions in algorithms, language design, concurrent computing, and distributed contributing, among other fields. He is basically the face of the Structured Programming movement (and coined the term) which led to the common design elements of many languages used today (both the presence of certain elements, and the absence of others).

I think it'd do you some good to read a bit more of his work and the history of computing.

Re: Correctness – A paradigm for sustainable software development

#58

Post by nickpsecurity »

pierrebai wrote: post #51

I've been thinking about this subject for a while and been on the verge of writing about it. The thing is, I've come to the opposite conclusion. My conclusion is that programmers have been trained to think about correctness. What they should be trained on and design is to account for inevitable failures. My main paradigm is the floating point design. It incorporates a built-in invalid value, which neatly propagates i…

"What they should be trained on and design is to account for inevitable failures."

That is pretty much the design philosophy of Erlang. You should check it out if you haven't.

Re: Correctness – A paradigm for sustainable software development

#59

Post by abdulhaq »

thraway-burnout wrote: post #19
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…

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 you're unclear on who is peaceful and who is aggressive, take a look at whose army is in whose country.

Re: Correctness – A paradigm for sustainable software development

#60

Post by nickpsecurity »

gtirloni wrote: post #21
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…

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

https://www.betterworldbooks.com/product/detail/Building-Hig...

https://hillelwayne.com/post/pbt-contracts/

Post reply on HN