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

Re: Correctness – A paradigm for sustainable software development

#91

Post by marcosdumay » Fri, Apr 05, 2019, 9:30 PM UTC

pron wrote: post #84

sevensor wrote: post #81

Earlier quoted context omitted.

There are certainly a lot of people who feel that way, though. Especially when the language has an expressive type system. Would you say these languages merely swap one kind of error for another?

There are certainly quite a lot of people who feel homeopathy is effective. In both cases, that feeling is a result of a complex process [1]. Explaining why it is unlikely (from a theory perspective) that languages like Haskell have a significant effect on correctness is easier [2], but it, too, requires much more space. What is simple to show is that organizations that develop in, say, Haskell do not produce more co…

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.

Re: Correctness – A paradigm for sustainable software development

#92

Post by pron » Fri, Apr 05, 2019, 9:32 PM UTC

marcosdumay wrote: post #91

pron wrote: post #84

Earlier quoted context omitted.

There are certainly quite a lot of people who feel homeopathy is effective. In both cases, that feeling is a result of a complex process [1]. Explaining why it is unlikely (from a theory perspective) that languages like Haskell have a significant effect on correctness is easier [2], but it, too, requires much more space. What is simple to show is that organizations that develop in, say, Haskell do not produce more co…

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 second hypothesis than the first. So while we can be more confident that, indeed, homeopathy isn't effective than in the case of FP, there is still no weight to the claim that FP is effective when it comes to correctness.

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

There isn't.

It's perfectly OK that people write about how much they like FP or OOP because the paradigm fits well with how they think, they like its aesthetics, or any similar reasons. It's not OK to try and justify the preference by making up completely unsupported empirical claims.

And by the way, even when there is no evidence one way or the other, you still cannot claim there is an effect.

Re: Correctness – A paradigm for sustainable software development

#93

Post by ummonk » Fri, Apr 05, 2019, 9:37 PM UTC

tsimionescu wrote: post #89

ummonk wrote: post #53

Earlier quoted context omitted.

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.

Yes, but the range of what 'static typing' means is so large that it is meaningless in this case. C is statically typed, and so are Java and OCaml. So is Idris. Of these, only Idris' type system has any power to model truly interesting properties (though the cost of doing so, in program complexity, is huge). Otherwise, even something as simple as rejecting `add(x, y) return x - y;` as a well typed function is beyond…

Formal systems obviously differ in their verification power and ease of use. E.g. with type systems, in terms of power on one end you have unsound type systems and on the other end you have dependent types. Sound type systems with algebraic data types tend to be quite common though and reasonably powerful.

As far as ease of use goes, type inference and flow analysis goes a very long way.

>Otherwise, even something as simple as rejecting `add(x, y) return x - y;` as a well typed function is beyond all of the others.

Why shouldn’t that be well typed (unless it is invoked with unsuitable argument types)? Are you saying the language should magically understand the english language meaning of “add”?

Re: Correctness – A paradigm for sustainable software development

#94

Post by UnFleshedOne » Fri, Apr 05, 2019, 9:39 PM UTC

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…

Metaphor survives if you then say that to take helicopter to the top you need to build a helicopter first and learn how to pilot it in mountain conditions. Suddenly taking an ice pick and just going up sounds simpler.

Re: Correctness – A paradigm for sustainable software development

#95

Post by endgame » Fri, Apr 05, 2019, 9:42 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…

> running a simulation (what OOP was invented for)

I used to believe that. I no longer do. Among other things, I watched this talk about Overwatch's architecture and it really seems like you have to go against your OO instincts to create larger simulations: https://www.youtube.com/watch?v=W3aieHjyNvw

Re: Correctness – A paradigm for sustainable software development

#96

Post by dual_basis » Fri, Apr 05, 2019, 10:00 PM UTC

gambler wrote: post #71

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…

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.

Re: Correctness – A paradigm for sustainable software development

#97

Post by dual_basis » Fri, Apr 05, 2019, 10:07 PM UTC

Jtsummers wrote: post #48

l_t wrote: post #38

Earlier quoted context omitted.

Not the OP, but I might have some context. I think of OOP as a message passing paradigm . It's concerned with how messages are passed from one part of the system to another. It is not particularly concerned with how those messages are implemented under the hood. In that sense it's a higher level paradigm because OOP is all about building abstractions ("objects") and defining how they communicate, rather than wiring c…

When viewed that way, you're not dealing with most mainstream OO languages anymore. But it is the intent of the originators of OO and I prefer the same view. Especially because at that point it becomes orthogonal to imperative/functional approaches. Message passing can be used with a functional language (Erlang) or an imperative language (Go) to great effect. It can also be added onto (as a library) most other langua…

Where can I learn more about this perspective on OOP? I would really like to understand it in a way which is orthogonal to FP. In particular, do you think this perspective allows you to write better code in "multi-paradigm" languages that claim to support both FP and OOP? (I'm specifically thinking of Scala and OCaml here.) I have always felt that languages that try to do both end up being worse as a result, but maybe if I could understand the two concepts in orthogonal perspectives then I could make it work.

Re: Correctness – A paradigm for sustainable software development

#98

Post by loup-vaillant » Fri, Apr 05, 2019, 10:12 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…

> If you know what a monad is, you should also know the founding ideas behind OOP.

You know full well that those founding ideas are mostly irrelevant to what most people mean by "OOP" nowadays. "OOP" right now is C++, Java, C#, Python…

What Alan Kay was talking about is now called the "actor model", of which the most prominent champion is Erlang, which sells itself as a functional language.

Different times, different terms. Which is why I can say with a straight face that OOP sucks and Alan Kay is brilliant.

Re: Correctness – A paradigm for sustainable software development

#99

Post by scroot » Fri, Apr 05, 2019, 10:19 PM UTC

sevensor wrote: post #85

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 to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. This seems to be Kay's key point. The description of object orientation is very unlike any modern system I've used, and he mentions elsewhere that even modern…

> My problem with this vision of OOP is that it would seem to take a great deal more support from the programming environment to make it work, compared to FP

One way to think about this is that there isn't a difference between your programming environment and the rest of your computing environment. There are no real "applications". There are just message sends and objects floating around. This is what Smalltalk was/is like.

Re: Correctness – A paradigm for sustainable software development

#100

Post by wellpast » Fri, Apr 05, 2019, 10:22 PM UTC

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

The only mindset required to avoid long-term bugs and maintenance problems is a personal conscientiousness, a personal approach to defensive programming based on (ideally, extensive) personal experience, which will inevitably include a very-hard-earned skillset of decoupling.

Everything else is trivial (borderline bike-shedding) in comparison.

Static types, OO, functional programming, agile, TDD, etc, etc -- these will not save you from your own personal deficiencies. Only long, hard practice will.

A skilled practitioner can build a large, complex system in Visual Basic or PHP using entirely OO idioms. Now he or she may do a somewhat quicker (and happier) job if he or she is able to employ some convenient tools of the trade (eg syntactic niceties, functional-orientation, immutable libs, testing libs, etc etc etc). But the quality and manageability of the system is entirely a function of experience-based skillsets that far transcend the particulars of the programming paradigms that we currently have available to us.

I've seen many a strong static typer, who thinks they have found God, make an absolute mess of everything including its leverage of the type system over time.

I've seen many a developer write OO code within a functional language and vice versa and the success or failure in these cases is irregardless of even the slight misapplication of the tool in hand.

Can you articulate a real world problem into a sound domain model? Can you decouple the behaviors of your system into composable parts? Are you conscientious enough to informally "prove" the transformations (ie git commits) you make to your software system?

If you can do these things, you avoid a mess of a system regardless of your PL and programming paradigms.

If you cannot do these things then no matter what kind of process you bring to the table, you will not be saved.