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

111–120 of 186 posts

Re: Correctness – A paradigm for sustainable software development

#111

Post by dope99 »

UnFleshedOne wrote: post #94
aeorgnoieang wrote: post #46

Earlier quoted context omitted.

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.

Ah, so you are referring to Haskell.

Re: Correctness – A paradigm for sustainable software development

#112

Post by mlthoughts2018 »

dope99 wrote: post #110
mlthoughts2018 wrote: post #70

Earlier quoted context omitted.

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…

I think most bugs are that kind that the compiler can catch. But yes absolutely a program can compile and be dead wrong. I’m writing a regex engine and lol at types saving me from all the mistakes I can make with building and transforming finite automata. I’d still much rather have a slightly slow compilation than verify types in my head every time I’m in that area of code, or writing unit tests for every configurati…

My experience has been the opposite. Compilers are not just a little slow, but introduce a significant slowdown for every read-edit-test loop, which adds up to such huge productivity losses that any small gains from the compiler catching typo-style / wrong arguments sorts of bugs is totally erased.

Re: Correctness – A paradigm for sustainable software development

#113

Post by naasking »

joe_the_user wrote: post #102
naasking wrote: post #75

Earlier quoted context omitted.

> 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

In the vast majority of OOP language, the object allows one to do virtually anything behind the scenes with a bit of construction (plus of course functional programming is opinionated. There are a whole variety of definitely bad practices an FP programmer will point to as being disallowed by the FP). See: "Closures And Objects Are Equivalent" etc. http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent And https://stacko…

Yes, because those objects are a fusion of OOP and ADTs. Pure OOP does not permit violating procedural abstraction.

To summarise, FP provides good reasoning in the small, and OO is needed in the large to orchestrate stateful services via protocols.

Re: Correctness – A paradigm for sustainable software development

#114

Post by OneWordSoln »

perfunctory wrote: post #11

Correctness is not an engineering problem. It's an economics problem. As long as IT Industry is able to extract money from their clients while delivering crappy software, they will keep delivering crappy software.

I'd say it's two-part problem:

(1) Specification (2) Implementation

Specification has always been the primary problem, the simple reason being that we are trying to quantify human desires regarding information flow. As we are finding out, it's non-trivial to say the least.

This goes back to an earlier talk I learned about here and watched just this morning by the outstanding MIT professor Nancy Leveson, https://www.youtube.com/watch?v=WBktiCyPLo4, who has analyzed various engineering problems (including the Challenger disaster) and even published an entirely new methodology for analyzing large-scale systems. Her book can be downloaded for free at http://sunnyday.mit.edu/safer-world.pdf.

Of course, economics factors into everything people endeavor to do these days, but strictly within the domain of creating correct information management systems -- from a purely technical level -- the problems are specification and implementation, in that order. Getting someone to pay for the time and team needed to do the job correctly is a completely different story, and not a pleasant one, it seems.

Re: Correctness – A paradigm for sustainable software development

#115

Post by fjfaase »

Software engineering is still mostly a craft, not a type of engineering. We should not start another FP versus OOP war. I think it misses the point. We should start thinking about languages where it is possible to precisely define implementation, like: X implements Y using representation R under conditions C. For example, a CPU instruction for adding two numbers works with modular arithmitics presuming a certain representation of numbers, nowadays, usually 2-complement with a certain power of 2. If you want it to represent the addition of two numbers then that is only possible if the sum of the two numbers does not cause an 'overflow'. There are algorithms to implement additions of much larger numbers using other representations and combinations of machine instructions. Writing an implementation for a certain problem, like summing a sequence of numbers, should begin with specifying the characteristics of the kind of sums one want to calculate. If one would have a library of implementation, one could engineer a 'correct' solution, without having to write an implementation by yourself.

Re: Correctness – A paradigm for sustainable software development

#116

Post by marmaduke »

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…

> Opaque callbacks are the functional equivalent of goto statements

in some sense they are worse because you can't just grep for the call site of an anonymous closure, like you can for a goto, it could be almost anywhere in the code base

Re: Correctness – A paradigm for sustainable software development

#117

Post by wwright »

gambler wrote: post #74
chalst wrote: post #68

Earlier quoted context omitted.

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

This sounds like “persistent data structures,” which are offered in most modern FP environments (including JavaScript, if you use libraries.)

Those structures don’t behave as objects themselves, but it’s not uncommon for Haskell monads, for example, to have very object-like behavior when you build them up a high layer, while each step in the monad is still an immutable value with cheap mutation-copies.

Re: Correctness – A paradigm for sustainable software development

#118

Post by pron »

Tehnix wrote: post #105
pron wrote: post #92

Earlier quoted context omitted.

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

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

Re: Correctness – A paradigm for sustainable software development

#119

Post by OneWordSoln »

adrianmonk wrote: post #103
perfunctory wrote: post #11

Correctness is not an engineering problem. It's an economics problem. As long as IT Industry is able to extract money from their clients while delivering crappy software, they will keep delivering crappy software.

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, is crappy software actually more efficient?

Never. As the Chinese expression goes: Pay a lot, cry once.

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. The folks that can specify and implement the systems rarely have the clout to allocate the resources necessary to get the job done well.

>> Which one of these two things is software more like?

Information systems (software that must run over and over again against the same data, often concurrently) are actually engines in that they must withstand stopping and starting; of course, the information engines that run continuously are even more difficult to keep functioning as their uptime stretches on. Therefore, the answer to your question is that software is most certainly more like an engine because information systems are engines, just that their fuel is data (including user input) and their output is information (data made meaningful to human beings) and changes to its information base.

We can all see how the poorly designed information engines of the world accrue ugly cruft that eventually leads to their needing to be "re-built", which, for example for Windows, means re-installing from scratch.

Post reply on HN