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

141–150 of 186 posts

Re: Correctness – A paradigm for sustainable software development

#141

Post by int_19h »

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…

It was the intent of Smalltalk, but not Simula, so it's not universal among the originators. Simula had actors implemented on top of objects and method calls, not the other way around.

But in practice, does it really make that much difference? A method call is really just a synchronous message. So at that point we're really talking about what messages objects should have - and looking at something like String, Array or Stream in Smalltalk, I don't see how it's substantially different from what we see in mainstream OO languages today.

Re: Correctness – A paradigm for sustainable software development

#142

Post by int_19h »

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…

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

I wouldn't call it "super cheap and low effort", given that tests for stuff like "what if it's not an integer?" tend to be a large part of the overall unit test suite in dynamic languages. Just on the amount of code alone, I would say that it's far less effort to express that kind of stuff in types than in tests.

Re: Correctness – A paradigm for sustainable software development

#143

Post by int_19h »

iamleppert wrote: post #80

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…

It's definitely unreasonable. Not because we can't write code to such standards - some people can, and do. But those people are also generally paid a lot more than you for a lot less lines of code delivered in the same amount of time.

The same thing goes for the industry - I think that it's accurate to describe modern software engineering as "sloppy", in general, especially if you compare it to the standards in engineering proper. But we're there because this is what the market is willing to pay for. Much like all the people complaining about all the cheap Chinese junk in stores, but not willing to pay significantly more for quality.

Re: Correctness – A paradigm for sustainable software development

#144

Post by cannabis_sam »

pron wrote: post #118
Tehnix wrote: post #105

Earlier quoted context omitted.

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

That study: 1. Found a statistically significant, but a rather small effect (low single digit % IIRC) that cannot justify language/paradigm choice ( choose FP for 1.5% fewer bugs! ). If anything, it's evidence against a large effect. 2. Had most of even that small effect disappear on reproduction, which increases the evidence against a large effect: https://arxiv.org/abs/1901.10220

Which puts types in a different category than homeopathy, despite your attempts to associate the two.

Re: Correctness – A paradigm for sustainable software development

#145

Post by logicchains »

pron wrote: post #79

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

Can you point to a project as complex as CompCert (formally verified C compiler) that's been written and proven correct in an imperative language? Note I mean proven correct, proven to do exactly as specified, not just proven to lack certain classes of bugs.

Re: Correctness – A paradigm for sustainable software development

#146

Post by [deleted] »

ummonk wrote: post #93
tsimionescu wrote: post #89

Earlier quoted context omitted.

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…

[deleted]

Re: Correctness – A paradigm for sustainable software development

#147

Post by ljw1001 »

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…

> Java people posting their design pattern nonsense as if it was something good.

Design patterns were developed by C++ and Smalltalk people.

Re: Correctness – A paradigm for sustainable software development

#148

Post by ljw1001 »

pacala wrote: post #27
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…

Exactly right. "OOP" is a system design paradigm. Useful for the 5% of the time one is concerned with big picture system design, and counterproductive for the 95% of the time one is writing mundane functions pertaining to their business domain. Alas, "OOP" was/is sold as a solution for everything computing, including the 95% of the time it is not a good fit. I call that track record "abysmal", your mileage may vary.

> "OOP" was/is sold as a solution for everything computing, including the 95% of the time it is not a good fit. I call that track record "abysmal", your mileage may vary.

In terms of real programs in the real world, OOP in the form of Java/C++/C# is by far the most successful programming paradigm ever. It's sort of amazing that anyone would call it's track record 'abysmal'

Re: Correctness – A paradigm for sustainable software development

#149

Post by adrianmonk »

OneWordSoln wrote: post #119
adrianmonk wrote: post #103

Earlier quoted context omitted.

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…

>> If you hire a maid who always manages to miss a spot or two cleaning your bathroom, does it really matter? It depends on the spot missed: is it contaminated with fecal matter? There you get into the realm of risk management. The problem is that, with software, one bad mistake can leave the user with complete loss of data. Look at Microsoft's recent update debacle; some people lost a great deal of data. >> Namely,…

Thanks for the thoughtful reply. I feel like our industry is in two camps right now, one that firmly believes quality always pays off and one which believes it is more of a luxury.

Unfortunately, I don't see either side backing it up with anything that looks like real evidence. It's so complicated to evaluate that I don't think anyone really can prove either way. But you can't not have an opinion since it's an important question, so it seems like people join one camp or the other mostly because it suits their personality or working style.

If they take pride in their work and feel disappointment at the prospect of producing code they can't be proud of, they tend to believe quality is worth it in the end. If they are impatient and like to wrap up one thing quickly so they can move on to the next thing, they tend to be in the other camp.

I myself am in the quality and correctness camp, and I really would love to know that it always pays off because that would mean the way I prefer to develop software is also the most practical and reasonable way. But I can't really prove that it's the right view when you consider the economics.

Re: Correctness – A paradigm for sustainable software development

#150

Post by ljw1001 »

OneWordSoln wrote: post #119
adrianmonk wrote: post #103

Earlier quoted context omitted.

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…

>> If you hire a maid who always manages to miss a spot or two cleaning your bathroom, does it really matter? It depends on the spot missed: is it contaminated with fecal matter? There you get into the realm of risk management. The problem is that, with software, one bad mistake can leave the user with complete loss of data. Look at Microsoft's recent update debacle; some people lost a great deal of data. >> Namely,…

>The problem is that the people who pay for the creation of software (i.e. corporate directors) are usually ignorant about all things except for money and the vague desires of their customers.

Oversimplification. Solving a problem just well-enough to live to fight another day is baked into capitalism in a deep way through competition, whether that competition is internal or external. .

Post reply on HN