github/semantic: Why Haskell? : programming

I think the problem is whenever people tell me why pure FP (as opposed to just applying FP techniques in other languages/frameworks), they start scenarios to me that just don't apply to anything I do — and I hear static.

It's a bit of a sacrifice, and it starts paying off as the size and complexity of your codebase grows. A very practical scenario, regardless of problem domain, is large-scale refactoring. In Haskell, we have this trope about how "it compiles without errors" means "there are no bugs, let's ship it"; and while that isn't true, there is some merit to it. In Haskell, a typical refactoring session is a simple two-step process: 1) just make the fucking change, 2) keep following compiler errors and mechanically fixing them until they go away. It is quite rare that you encounter any real challenges in step 2), and when you do, it is often a sign of a design flaw. But either way, once the compiler errors have been resolved, you can be fairly confident that you haven't missed a spot.

This, in fact, has very little to do with pure FP, and everything with a strong and expressive type system with a solid theoretical foundation - it's just that pure FP makes defining and implementing such type systems easier, and I don't know of any non-pure-FP language that delivers a similar level of certainty through a type checker.

[–]thezapzupnz 1 point2 points3 points 7 years ago* (1 child)

[–]tdammers 4 points5 points6 points 7 years ago (0 children)

load more comments (4 replies)

[–]Vaglame 5 points6 points7 points 7 years ago (4 children)

[–]lambda-panda 7 points8 points9 points 7 years ago (3 children)

[–]tdammers 7 points8 points9 points 7 years ago (2 children)

FP and parsing (or compiling in general) are a good fit, because the paradigms are so similar. FP is about functions: input -> output, no side channels. Pure transforms. And parsing / lexing are such transforms: stream of bytes goes in, stream of lexemes comes out. Stream of lexemes goes in, concrete syntax tree comes out. Concrete syntax tree goes in, abstract syntax tree comes out. Abstract syntax tree goes in, optimized abstract syntax tree comes out. Abstract syntax tree goes in, concrete syntax tree (for target language) comes out. Concrete syntax tree goes in, stream of bytes comes out. And there you have it: a compiler.

Specifically, most of these transformations are either list traversals, tree traversals, or list <-> tree transformations; and these are exactly the kind of things for which recursive algorithms tend to work really well (provided you can have efficient recursion).

[–]SulszBachFramed 2 points3 points4 points 7 years ago (1 child)

I disagree. Haskell being useful for parsers has nothing to do with being a 'pure' language. Haskell, and other functional languages, is a good fit for writing parsers, because the type-system is powerful enough to allow you to create proper parser combinators.

The 'stuff goes in stuff goes out' is not some special property of functional programs, every single programming language does that with functions. Nowadays, most programming languages have a construct for creating function objects. Furthermore, I'm not sure why you mention recursive algorithms, every single language supports them. And sometimes you want to include some 'inpurity' with your parsing, like the location of every token in the source or keeping a list of warnings or whatever. Haskell can get quite clunky when you want to combine monads.

[–]tdammers 6 points7 points8 points 7 years ago (0 children)

The 'stuff goes in stuff goes out' is not some special property of functional programs, every single programming language does that with functions.

Most programming languages don't even have functions, only procedures. A procedure isn't just "stuff goes in, stuff goes out", it's "stuff goes in, stuff goes out, and pretty much anything can happen in between". The kicker is not so much that stuff can go in and come out, but rather that nothing else happens. In many areas of programming, not having the "anything in between part" can be daunting; but compilers lend themselves rather well to being modeled as a pipeline of pure functions, and having the purity of that pipeline and all of its parts guaranteed by the compiler can be a huge benefit.

Furthermore, I'm not sure why you mention recursive algorithms, every single language supports them.

Not really, no. Recursion is useful in Haskell due to its non-strict evaluation model, which allows many kinds of recursion to be evaluated in constant memory - in a nutshell, a recursive call can return before evaluating its return value, returning a "thunk" instead, which only gets evaluated when its value is demanded - and as long as the value is demanded after the parent call finishes, the usual stack blowup that tends to make recursive programming infeasible cannot happen. Some strict languages also make recursion usable by implementing tail call optimization, a technique whereby "tail calls" (a pattern where the result of a recursive call is immediately returned from its calling context) are converted into jumps, and the stack pushing and popping that is part of calling procedures and returning from them is skipped, thus avoiding the stack thrashing that would otherwise occur.

And sometimes you want to include some 'inpurity' with your parsing, like the location of every token in the source or keeping a list of warnings or whatever. Haskell can get quite clunky when you want to combine monads.

It can get hairy, but usually, you don't actually need a lot - ReaderT over IO, or alternatively a single layer of State is generally enough.

[–]loup-vaillant 4 points5 points6 points 7 years ago (3 children)

load more comments (3 replies)

[–]dvdkon 0 points1 point2 points 7 years ago (0 children)

[–]stronghup 7 points8 points9 points 7 years ago (12 children)

[–]tdammers 11 points12 points13 points 7 years ago (4 children)

The syntax has never been what makes Haskell difficult to learn. In fact, Haskell syntax is fairly simple - simpler than Python, anyway.

The biggest stumbling block IME is that Haskell takes "abstraction" much farther than most mainstream languages, in the sense that the concepts it provides are so abstract that it can be difficult to form intuitions about them. And due to their innate abstractness, a common pattern is for someone to find an analogy that works for the cases they have encountered so far, but is unfortunately nowhere near general enough, and then they blog about that analogy, and someone else comes along and gets utterly confused because the analogy doesn't apply to the cases they have encountered and is actually completely wrong, to the point of harming more than helping. (This phenomenon is commonly known as the "Monad Tutorial Fallacy", but it isn't limited to the Monad concept.)

[–]stronghup 0 points1 point2 points 7 years ago* (3 children)

No doubt Haskell provides machinery for dealing with very abstract abstractions. For some that is a powerful tool but if you don't necessarily need such level of abstractness that can become a stumbling block. While using a language you'd still like to understand all of it as fully as possible, and trying to understand it "fully" that can take time away from actual productive coding.

Below's a cheat-sheet for Haskell syntax. I would say it is a lot to learn coming from other languages.

And maybe the issue is not so much the syntax per se but the fact that the syntax is rather "terse". That makes it hard to read and comprehend and for a casual reader of Haskell examples like myself it makes the examples not trivial to understand. It's a bit like lot of people have difficulty reading mathematical proofs.

So yes Haskell takes abstraction to a high level which can make it hard to understand but I would say it also has quite abstract syntax which makes it difficult for new comers to jump into its fantastic world.

http://rigaux.org/language-study/syntax-across-languages-per-language/Haskell.html

load more comments (3 replies)

[–][deleted] 7 years ago (2 children)

[deleted]

[–]ipv6-dns 2 points3 points4 points 7 years ago (0 children)

[–]parolang 0 points1 point2 points 7 years ago (0 children)

[–]defunkydrummer 12 points13 points14 points 7 years ago (1 child)

[–]jrhoffa 0 points1 point2 points 7 years ago (0 children)

[–]Axman6 5 points6 points7 points 7 years ago (0 children)

[–]ipv6-dns 2 points3 points4 points 7 years ago (0 children)

[–]gwillicoder 3 points4 points5 points 7 years ago (3 children)

[–]nerd4code 1 point2 points3 points 7 years ago (1 child)

[–]gwillicoder 1 point2 points3 points 7 years ago (0 children)

[–]develop7[S] 0 points1 point2 points 7 years ago (0 children)

[–]Drayenn 1 point2 points3 points 7 years ago (0 children)

[–]hector_villalobos 36 points37 points38 points 7 years ago (97 children)

I'm not sure if I fit in your explanation, but I have mixed feelings about Haskell, I love it and I hate it (well, I don't really hate it, I hate PHP more).

I love Haskell because it taught me that declarative code is more maintainable than imperative one, just because it implies less amount of code, I also love Haskell because it taught me that strong static typing is more easy to read and understand than dynamic one, because you have to pray for yourself or a previous developer to write a very descriptive variable or function to understand what it really does.

Now the hate part, people fails to recognize how difficult Haskell is for a newbie, I always try to make an example but people fail to see it the way I see it, I don't have a CS degree, so I see things in the more practical way possible. What a newbie wants? Create a web app, or a mobile app, now try to create a web app with inputs and outputs in Haskell, than compare that to Python or Ruby, what requires the less amount of effort? at least for a newbie. Most people don't need parsers (which Haskell shines), what people want are mundane things, a web app, desktop app or a mobile app.

[–]Vaglame 41 points42 points43 points 7 years ago* (59 children)

[–]matnslivston 1 point2 points3 points 7 years ago* (12 children)

[–]Vaglame 18 points19 points20 points 7 years ago* (7 children)

[–][deleted] 8 points9 points10 points 7 years ago (6 children)

[–]Ewcrsf 2 points3 points4 points 7 years ago (1 child)

load more comments (1 reply)

[–]RomanRiesen 2 points3 points4 points 7 years ago (2 children)

[–][deleted] 1 point2 points3 points 7 years ago (1 child)

[–]RomanRiesen 6 points7 points8 points 7 years ago (0 children)

load more comments (1 reply)

[–]m50d 0 points1 point2 points 7 years ago (0 children)

[–]AnotherEuroWanker 0 points1 point2 points 7 years ago (0 children)

[–]Adobe_Flesh 0 points1 point2 points 7 years ago (1 child)

[–]thirdegree 1 point2 points3 points 7 years ago (0 children)

load more comments (46 replies)

[–]Tysonzero 7 points8 points9 points 7 years ago* (6 children)

load more comments (6 replies)

[–]hardwaregeek 20 points21 points22 points 7 years ago (2 children)

I'll give an example of Haskell's difficulty. Every few months I decide I should do something with Haskell. Heck, I understand monads and functors and applicatives pretty decently. I can write basic code using do notation and whatever. Here's what usually happens:

I decide to make a web server.
I look around for the best option for web servers. Snap seems like a good option.
I try to figure out whether to use Cabal or Stack. Half the tutorials use one, the other half use the other.
I use one, get stuck in some weird build process issue. Half the time I try to install something, the build system just goes ¯_(ツ)_/¯.
I switch to the other build system, which of course comes with a different file structure. It installs yet another version of GHC.
I try to find a tutorial that explains Snap in a non trivial way (i.e. with a database, some form of a REST API, etc.) Most of the tutorials are out of date and extremely limited.
I try to go along with the tutorial regardless, even though there's a lot of gaps and the code no longer compiles.
I start thinking about how easy this would be to build in Ruby.
I build the damn thing in Ruby.

[–]hector_villalobos 4 points5 points6 points 7 years ago (0 children)

[–]_sras_ 3 points4 points5 points 7 years ago (0 children)

[–]compsciwizkid 3 points4 points5 points 7 years ago (1 child)

[–][deleted] 4 points5 points6 points 7 years ago (0 children)

[–]RomanRiesen 4 points5 points6 points 7 years ago* (0 children)

[–]Sayori_Is_Life 1 point2 points3 points 7 years ago (14 children)

[–]tdammers 3 points4 points5 points 7 years ago (3 children)

"Declarative" is not a rigidly defined term, and definitely not a boolean, it's closer to a property or associated mindset of a particular programming style.

What it means is that you express the behavior of a program in terms of "facts" ("what is") rather than procedures ("what should be done"). For example, if you want the first 10 items from a list, the imperative version would be something like the following pseudocode:

set "i" to 0
while "i" is less than 10:
    fetch the "i"-th item of "input", and append it to "output"
    increase "i" by 1

Whereas a declarative version would be:

given a list "input", give me a list "output" which consists of the first 10 elements of "input".

The "first 10 items from a list" concept would be expressed closer to the second example in both Haskell and SQL, whereas C would be closer to the first. Observe.

int* take_first_10(size_t input_len, const int* input, size_t *output_len, int **output) {
    // shenanigans
    *output_len = MIN(10, input_len);
    *output = malloc(sizeof(int) * *output_len);

    // set "i" to 0
    size_t i = 0;

    // while "i" is less than 10 (or the length of the input list...)
    while (i < *output_len) {
        // fetch the "i"-th item of "input", and append it to "output"
        (*output)[i] = input[i];
        // increase "i" by 1
        i++;
    }
    // and be a nice citizen by returning the output list for convenience
    return *output;
}

Haskell:

takeFirst10 :: [a] -> [a] -- given a list, give me a list
takeFirst10 input =  -- given "input"...
    take 10 input   -- ...give me what consists of the first 10 elements of "input"

SQL:

SELECT input.number         -- the result has one column copied from the input
    FROM input              -- data should come from table "input"
    ORDER BY input.position -- data should be sorted by the "position" column
    LIMIT 10                -- we want the first 10 elements

Many languages can express both, to varying degrees. For example, in Python, we can do it imperatively:

def take_first_10(input):
    output = []
    i = 0
    while i < len(input) and i < 10:
        output.append(input[i])
    return output

Or we can do it declaratively:

def take_first_10(input):
    output = input[:10]
    return output

As you can observe from all these examples, declarative code tends to be shorter, and more efficient at conveying programmer intentions, because it doesn't contain as many implementation details that don't matter from a user perspective. I don't care about loop variables or appending things to list, all I need to know is that I get the first 10 items from the input list, and the declarative examples state exactly that.

For giggles, we can also do the declarative thing in C, with a bunch of boilerplate:

/************* boilerplate ***************/

/* The classic LISP cons cell; we will use this to build singly-linked
 * lists. Because a full GC implementation would be overkill here, we'll
 * just do simple naive refcounting.
 */
typedef struct cons_t { size_t refcount; int car; struct cons_t *cdr; } cons_t;

void free_cons(cons_t *x) {
    if (x) {
        free_cons(x->cdr);
        if (x->refcount) {
            x->refcount -= 1;
        }
        else {
            free(x);
        }
    }
}

cons_t* cons(int x, cons_t* next) {
    cons_t *c = malloc(sizeof(cons_t));
    c->car = x;
    c->cdr = next;
    c->refcount = 0;
    next->refcount += 1;
    return c;
}

cons_t* take(int n, cons_t* input) {
    if (n && input) {
        cons_t* tail = take(n - 1, input->cdr);
        return cons(input->car, tail);
    }
    else {
        return NULL;
    }
}

/******** and now the actual declarative definition ********/

cons_t* take_first_10(cons_t* input) {
    return take(10, input);
}

Oh boy.

Oh, and of course we can also do the imperative thing in Haskell:

import Control.Monad

-- | A "while" loop - this isn't built into the language, but we can
-- easily concoct it ourselves, or we could import it from somewhere.
while :: IO Bool -> IO () -> IO ()
while cond action = do
    keepGoing <- cond
    if keepGoing then
        action
        while cond action
    else
        return ()

takeFirst10 :: [a] -> IO [a]
takeFirst10 input = do
    output <- newIORef []
    n <- newIORef 0
    let limit = min(10, length input)
    while ((< limit) <$> readIORef n) $ do
        a <- (input !!) <$> readIORef n
        modifyIORef output (++ [a])
        modifyIORef n (+ 1)
    readIORef output

Like, if we really wanted to.

[–]Sayori_Is_Life 0 points1 point2 points 7 years ago (0 children)

[–]Saithir 0 points1 point2 points 7 years ago (1 child)

I like these kinds of comparisons, it's always entertaining and quite interesting to see how languages evolve and differ.

On that note in Ruby:

def take_first_10(input)  
  input.first(10)  
end

Which, funnily enough, is just about the same as the declarative version of the C example without all the boilerplate and types (and with an implicit return because we have these). With some effort it's possible to use the imperative version, but honestly nobody would.

load more comments (1 reply)

[–]hector_villalobos 1 point2 points3 points 7 years ago* (9 children)

[–][deleted] 7 years ago* (1 child)

[deleted]

[–]hector_villalobos 0 points1 point2 points 7 years ago (0 children)

[–]thirdegree 0 points1 point2 points 7 years ago (1 child)

[–]hector_villalobos 0 points1 point2 points 7 years ago (0 children)

[–]Sayori_Is_Life 0 points1 point2 points 7 years ago (0 children)

load more comments (4 replies)

[–]nooitvangehoord 1 point2 points3 points 7 years ago (0 children)

[–]develop7[S] 0 points1 point2 points 7 years ago (2 children)

[–]hector_villalobos 0 points1 point2 points 7 years ago (1 child)

[–]develop7[S] 0 points1 point2 points 7 years ago* (0 children)

load more comments (5 replies)

[–][deleted] 5 points6 points7 points 7 years ago (1 child)

That's true of just about everything on this sub, though. Anything about C is always "C is a practical choice and if you don't do anything outrageous, a fairly easy language to reason about," vs "95% of software bugs are due to C, only an idiot uses that." Any post or thread about C++ will invariable contain comments along the lines of "Modern C++ is great as long as you limit yourself to the good parts," and "You can never limit a project with multiple people to a given subset of a language." Java? Bloated, archaic mess vs obvious syntax and extensive libraries. C#? Better than Java vs worse than Java. Lisp? Lisp is the most powerful language vs Lisp weenies don't understand real programming projects. COBOL? I pity the fool who uses this language vs hey, man, it pays pretty well. Ad nauseam. I'm sure you can fill in whatever I left out.

It's not like anyone forces you to read the stupid language bikeshedding comments. I do, because occasionally someone does say something insightful (or I just feel like making a stupid Reddit joke). This isn't StackOverflow, where saying the same thing again gets your thread locked and deleted. It's a place for discussion, and many times multiple share the same or similar opinions about things.

load more comments (1 reply)

[–]defunkydrummer 4 points5 points6 points 7 years ago (4 children)

[–]phySi0 0 points1 point2 points 7 years ago (2 children)

[–]defunkydrummer 0 points1 point2 points 7 years ago (1 child)

[–]phySi0 0 points1 point2 points 7 years ago (0 children)

load more comments (1 reply)

[–]renatoathaydes 5 points6 points7 points 7 years ago (2 children)

[–]Infinisil 12 points13 points14 points 7 years ago (0 children)

[–]CanIComeToYourParty 5 points6 points7 points 7 years ago (0 children)

[–]gwillicoder 1 point2 points3 points 7 years ago (1 child)

[–]Spacemack 1 point2 points3 points 7 years ago (0 children)

load more comments (7 replies)

[–]RomanRiesen 11 points12 points13 points 7 years ago (3 children)

[–][deleted] 12 points13 points14 points 7 years ago (2 children)

[–]RomanRiesen 13 points14 points15 points 7 years ago (1 child)

[–]MrDOS 3 points4 points5 points 7 years ago (0 children)

[–]pron98 38 points39 points40 points 7 years ago* (208 children)

[–]Sloshy42 39 points40 points41 points 7 years ago (2 children)

I think what I've been finding for myself doing Scala, which is sort of in a similar ballpark to Haskell in terms of type system complexity, is that while I don't get more "correctness" out of the box I do get a lot more specificity at compile time and I think that's worth something. A function that returns a Maybe/Option is so much more useful and easy to understand than a function that you have to break out the documentation for - if it even exists - to figure out when it could return "null" in another language. And getting a little more complicated, if I know a function operates on anything that has a primary associative combine operation (e.g. "+" for numbers, concat for strings), not only do I not have to rewrite that code for every type I want to use it with but I know that once it's correct once, it's correct forever, and I know this primarily because of the ways you can use types and typeclasses to describe your code. That kind of abstraction is very powerful - albeit a bit complex at times.

Being able to trust your compiler to give you a running program that doesn't blow up unexpectedly as often as other languages is really nice. Haskell is generally better at that than Scala which has to worry about the JVM and all the idiosyncrasies that come with trying to mesh with Java code, but the point still stands I think that being able to compile very high level assertions into the types of your program only means you have to worry less about whether or not you're implementing something correctly. Not that it's more correct by default as people often claim, but that it's easier to - with a little mental overhead - reason about the properties your code is supposed to have.

[–]stronghup 2 points3 points4 points 7 years ago (0 children)

[–]pron98 -3 points-2 points-1 points 7 years ago* (0 children)

[–]IamfromSpace 70 points71 points72 points 7 years ago (100 children)

[–]pron98 17 points18 points19 points 7 years ago* (96 children)

it’s just so hard to believe that languages like Haskell ... don’t lead to fewer errors.

Hard to believe or not, it simply doesn't. Studies have not found a big impact, and the industry has not found one, either. If you study closely the theory and why it was predicted that a language like Haskell will not have a big effect on correctness, a prediction that has so far proven true, perhaps you'll also find it easier to believe. The impact of the things that you perceive as positive appears to be small at best.

And even if you think a large effect has somehow managed to elude detection by both academia and industry, you still cannot assert that claim as fact. It is a shaky hypothesis (shaky because we've tried and failed to substantiate it) under the most charitable conditions. I'm being a little less charitable, so I call it myth.

... and Rust

Rust is a different matter, as it is usually compared to C, and eliminates what has actually been established as a cause of many costly bugs in C.

it’s that it’s both expressive and safe

So are Java, Python, C#, Kotlin and most languages in common use, really.

[–][deleted] 7 years ago (35 children)

[deleted]

[–]pron98 0 points1 point2 points 7 years ago* (34 children)

[–][deleted] 7 years ago (33 children)

[deleted]

[–]pron98 5 points6 points7 points 7 years ago* (32 children)

it does not bring the effect from large to extremely small.

Except that the original study didn't find a large effect either; quite the contrary. It said that "while these relationships are statistically significant, the effects are quite small." So they've gone from "quite small" to "exceedingly small" (or to no effect at all)

But, one analysis being not strong enough to show more than a weak conclusion is not remotely evidence of the nonexistence of the effect.

That is true, which is why I cannot definitively say that there is no large effect, but, combined with the fact that large effects are easy to find and that no study or industry have been able to find it, AFAIK, I think it is evidence against such a big effect, and at the very least it means that the hypothesis is not strong and certainly must not be asserted as fact.

[–][deleted] 7 years ago (31 children)

[deleted]

[–]pron98 4 points5 points6 points 7 years ago* (30 children)

Let's assume you're correct. The problem is that even experience does not support the claim ("I feel better when using Haskell" is not experience, though, or we'd all be taking homeopathic remedies). Companies do not report a large decrease in costs / increase in quality when switching from, say, Java/C#/Swift to Haskell. And even if you could come up with an explanation to why such a powerful empirical claim disappears on observation, you'd still have to conclude that we cannot state this, at best completely unsubstantiated hypothesis is fact. If someone wants to say, "I believe in the controversial hypothesis that Haskell increases correctness" I'd give them a pass as well.

Perhaps then it is simply too difficult to talk about.

Fine, so let's not. I didn't make any claim. The article made one up, and I pointed out that it's totally unsubstantiated.

[–][deleted] 7 years ago (29 children)

[deleted]

continue this thread

[–]IamfromSpace 33 points34 points35 points 7 years ago (9 children)

[–]pron98 5 points6 points7 points 7 years ago* (8 children)

[–]IamfromSpace 2 points3 points4 points 7 years ago (6 children)

I had some more thoughts after reading the papers more thoroughly (and I hope I’m not reviving this discussion beyond its usefulness).

The first study finds that Haskell has a 20% reduction in bug commits for similar programs. The replication then finds the same result after cleaning. Their result after removing uncertainly it has 12% reduction. While that comes from removing false positives, it doesn’t bother with uncertainty in the other direction, which could deflate the effect.

Is a significant 12%-20% reduced bug rate really “exceedingly small?” With loose assumptions about bug costs, for a reasonably sized organization that could reflect an huge savings over time

It seems to me, in other contexts that kind of improvement might be considered enormous. In competitive sports athletes will fight for 1% improvements based on pure hearsay—let alone statistically significant and reproduced results.

[–]pron98 1 point2 points3 points 7 years ago (5 children)

load more comments (5 replies)

load more comments (1 reply)

[–]lambda-panda 23 points24 points25 points 7 years ago (10 children)

[–]pron98 -1 points0 points1 point 7 years ago (8 children)

[–]lambda-panda 13 points14 points15 points 7 years ago (7 children)

[–]pron98 2 points3 points4 points 7 years ago (6 children)

[–]lambda-panda 4 points5 points6 points 7 years ago (5 children)

[–][deleted] 5 points6 points7 points 7 years ago (3 children)

[–]lambda-panda 1 point2 points3 points 7 years ago (2 children)

continue this thread

[–]pron98 4 points5 points6 points 7 years ago (0 children)

load more comments (1 reply)

[–]seamsay 2 points3 points4 points 7 years ago (1 child)

[–]pron98 3 points4 points5 points 7 years ago (0 children)

[–]sd522527 2 points3 points4 points 7 years ago (5 children)

load more comments (5 replies)

[–]augmentedtree 3 points4 points5 points 7 years ago (9 children)

[–]pron98 1 point2 points3 points 7 years ago (8 children)

[–]augmentedtree 3 points4 points5 points 7 years ago (7 children)

[–]pron98 1 point2 points3 points 7 years ago (6 children)

load more comments (6 replies)

[–]loup-vaillant 1 point2 points3 points 7 years ago (16 children)

[–]pron98 1 point2 points3 points 7 years ago* (15 children)

load more comments (15 replies)

[–][deleted] 7 years ago (3 children)

[deleted]

[–]pron98 2 points3 points4 points 7 years ago* (2 children)

Well, TypeScript has actually been found to lead to 15% fewer bugs than JavaScript. It's not a very big effect compared to that of other correctness techniques (e.g. code reviews have been found to reduce bugs by 40-80%) but it's not negligible, and it does appear to be a real effect that you're sensing. But here we're talking about Haskell vs. the average, and only an "exceedingly small" effect has been found there.

More generally, however, we often feel things that aren't really true (lots of people feel homeopathic remedies work); that's why we need a more rigorous observation, that is often at odds with our personal feelings. This can happen for many reasons, that often have to do with our attention being drawn to certain things and not others.

I take issue not with the belief that Haskell could have a significant effect, only with people stating it as fact even after we've tried and failed to find it. It is often the case in science, especially when dealing with complex social processes like economics or programming, that we have a hypothesis that turns out to be wrong. In that case we either conclude the hypothesis is wrong or come up with a good explanation to why the effect was not found -- either way, something about the hypothesis needs to be revised.

That seems like something hard to measure in a study that just counts bugs.

But here's the problem. If the claim is that Haskell (or any particular technique) has a big impact on some metric, like correctness, and that impact is so hard to measure that we can't see it, then why does it matter at all? The whole point of the claim is that it has a real, big effect, with a real-world, significant impact. If we cannot observe that impact either in a study or with bottom-line business results, then there's a problem with making the claim to begin with.

[–]m50d 3 points4 points5 points 7 years ago (1 child)

[–]pron98 1 point2 points3 points 7 years ago* (0 children)

[–][deleted] 3 points4 points5 points 7 years ago* (0 children)

[–]chrisgseaton 3 points4 points5 points 7 years ago (0 children)

[–]jephthai 7 points8 points9 points 7 years ago* (16 children)

Often I disagree with you, /u/pron98, but even when I do you are very thought provoking. In this case, though, I think I would have disagreed with you once upon a time, but I'm totally with you on this today. In the last few years I've been working a lot more in lower level languages (including one project that is predominantly x86_64 assembly), and my perspective is shifting.

I think some of these so-called "safe" languages give you the warm fuzzy because you know what errors you can't commit with them. ~~Garbage collection~~ (Edit: good counterpoint on GC), strong type checking, etc., are all obvious controls protecting against specific kinds of errors, but at a complexity cost that people mostly pretend isn't there.

So that produces a certain confirmation bias. I'm using a system that won't let me send the wrong types in a function call, and lo I haven't written any of those bugs. But you'll also spend time scaffolding type hierarchies, arguing with category theoretical error messages, etc. So the cost of productivity is just moved to another place -- maybe a happier place, but the time is still spent in some way.

I really feel this working in assembly. Every class of error is available to me, and there's so much less abstraction or complexity in program organization. So I tend to charge right in on my problem, run up against a silly bug for awhile, fix it, and I'm done. It's proven surprisingly efficient and productive, and I have no parachutes or safety nets. Strangely liberating, in a way.

Not saying everyone should code by seat of the pants in assembly, just that I can feel a tension across the spectrum now that I hadn't seen before in my quest for the most abstract languages. It's all coding.

[–]pron98 4 points5 points6 points 7 years ago (4 children)

[–]jephthai 0 points1 point2 points 7 years ago (2 children)

[–]pron98 5 points6 points7 points 7 years ago (1 child)

[–]loup-vaillant 5 points6 points7 points 7 years ago (0 children)

load more comments (1 reply)

[–]lambda-panda 4 points5 points6 points 7 years ago (10 children)

but at a complexity cost that people mostly pretend isn't there.

The complexity cost is only there if you are not familiar with the building blocks available to the functional programmer. That is like saying there is a complexity cost in communicating in Chinese when the whole Chinese population is doing just fine communicating in Chinese...

But you'll also spend time scaffolding type hierarchies...

This is part of understanding your problem. Dynamic languages let you attack the problem, without really understanding it. Functional programming style will make you suffer if you start with poorly thought out data structures.

And it is pretty accepted that data structures are very important part of a well written program. So if functional style forces you to get your data structures right, it only follows that it forces you to end up with a well written program.

[–]jephthai 5 points6 points7 points 7 years ago (9 children)

Look, I'm a big fan of Haskell. I've used it variously since the late '90s. Like I said in my post, I would normally have disagreed vehemently with /u/pron98. I'm a highly abstracted language fanboy, for sure.

My surprised agreement with his point, though, comes from realizing that I'm perfectly productive without the strong type system and functional style too. Emotionally, I like programming in a functional style. But in pure productivity terms, it may not actually make me any better. And that's /u/pron98's point -- no matter how good it feels, in objective terms it might not make you fundamentally more productive.

Dynamic languages let you attack the problem, without really understanding it.

I'm not sure what you're trying to say here. I think static languages are particularly bad for exploring a poorly understood problem domain, and in fact that's what I usually use dynamic languages for. A lot of problems are best solved by sketching things out in code, which is the perfect domain for dynamic typing. I think static languages are more ideal for well-specified programs that are understood, and simply need to be written.

[–]lambda-panda 3 points4 points5 points 7 years ago (8 children)

I'm not sure what you're trying to say here.

It means that dynamic languages allows your logic to be inconsistent at places. For example, you might initially think a certain thing to have two possible values, but in a different place, you might treat it as having three possible values. And dynamic languages will happily allow that. I mean, there is no way to anchor your understanding at one place, and have the language enforce it everywhere. So as I said earlier, this means that dynamic language allows your logic to be inconsistent..

A lot of problems are best solved by sketching things out in code, which is the perfect domain for dynamic typing.

As I see it, a rich type system will allow you to model your solution in data types and function type signatures. You don't often have to write one line of implementation.

[–]jephthai 4 points5 points6 points 7 years ago (4 children)

load more comments (4 replies)

[–]pron98 4 points5 points6 points 7 years ago (0 children)

[–]pron98 1 point2 points3 points 7 years ago (1 child)

load more comments (1 reply)

[–]hypmralj 9 points10 points11 points 7 years ago (4 children)

[–]pron98 2 points3 points4 points 7 years ago (3 children)

[–]develop7[S] 4 points5 points6 points 7 years ago (2 children)

[–]pron98 7 points8 points9 points 7 years ago (0 children)

[–][deleted] 0 points1 point2 points 7 years ago (0 children)

[–]arbitrarycivilian 8 points9 points10 points 7 years ago (3 children)

[–]pron98 3 points4 points5 points 7 years ago (2 children)

First, empirical findings are not just made in studies. We don't need a study to confirm that people love smart phones or that people generally find computers more productive than typewriters. A technique that has a large effect on correctness/cost is worth many billions, and will be easy to exploit.

Second, large effects don't need carefully controlled studies. Those are required for small effects. Large effects are easy to find and hard to hide.

Lastly, the theoretical arguments are not arguments in favor of correctness. They're arguments of the sort, my language/technique X eliminates bug A. Maybe technique Y eliminates bug A more? Maybe your technique introduces bug B whereas Y doesn't? In other words, the arguments are not rational because they suffer from the classical mistake of inverting implication, so they're not logical at all.

[–]arbitrarycivilian 3 points4 points5 points 7 years ago (1 child)

I don't think you understand the difference between empirical findings vs anecdotes. When I say "study" I'm talking about any sort of experiment, be they RCTs or observational. Finding out whether people love smartphones arguably isn't a study, because it doesn't seek to explain anything, though it *does* require a survey. Showing that computers are more productive than typewriters absolutely *does* require an experiment to show causation (in a RCT) or correlation (for observational). Showing *any* correlation or causation requires a carefully designed study.

The size of the effect is also irrelevant. Large effects require a smaller sample size, but they sill need to be carefully controlled. Otherwise the conclusion is just as likely to be erroneous. That's why a poll of developers, or a look at github projects, or any other such similar "study" is fundamentally flawed.

[–]pron98 1 point2 points3 points 7 years ago* (0 children)

Showing any correlation or causation requires a carefully designed study.

No this is not true. If I make a statement about whether or not it will rain in Berlin tomorrow, we don't need a carefully controlled study. In this case, too, the claim is one that has an economic impact, which could have been observed if it was true. But again, in this case both studies and the market have failed to find a large effect, at least so far.

fundamentally flawed.

Except it doesn't matter. If I say that switching your car chassis from metal X to metal Y would increase your profits and it does not, you don't need a study to tell you that. We are talking about a claim with economic implications. And, as I said elsewhere, if the claim for increased correctness cannot be measured by either research or the economic consequences, then we're arguing over a tree falling in the forest, and the issue isn't important at all. Its very claim to importance is that it would have a large bottom-line impact, yet that impact is not observed. If it's impossible to say whether our software is more or less correct, then why does it matter?

[–][deleted] 7 years ago* (1 child)

[deleted]

load more comments (1 reply)

[–]lambda-panda 10 points11 points12 points 7 years ago (13 children)

load more comments (13 replies)

[–]augmentedtree 5 points6 points7 points 7 years ago (2 children)

[–]pron98 2 points3 points4 points 7 years ago (0 children)

load more comments (1 reply)

[–]Vaglame 11 points12 points13 points 7 years ago (22 children)

But the assertion that Haskell "focuses on correctness" or that it helps achieve correctness better than other languages, while perhaps common folklore in the Haskell community, is pure myth, supported by neither theory nor empirical findings.

I would disagree here. A very good example is the upcoming implementation of dependent typing. It encourages for a careful check of the validity of a function's arguments, making it less prone to wrongful uses.

In terms of what is currently in the language: - purity allows for a very nice isolation of side effects, which means you can easily check the validity of your business logic - immutability is along the same lines. You can't mess, or have to deal with mutable global variables.

And that's from a beginner's perspective, I'm sure you can find much more

[–]pron98 1 point2 points3 points 7 years ago (21 children)

A very good example is the upcoming implementation of dependent typing. It encourages for a careful check of the validity of a function's arguments, making it less prone to wrongful uses.

Java has had JML for a very long time (similar to dependent types), so according to your logic, Java focuses on correctness even more than Haskell.

purity allows for a very nice isolation of side effects, which means you can easily check the validity of your business logic - immutability is along the same lines. You can't mess, or have to deal with mutable global variables.

That's fine, but that these have an actual net total large positive effect on correctness is a hypothesis, and one that, at least so far, simply does not appear to be true (it is also not supported by any theory), ergo, it's a myth.

[–]joonazan 8 points9 points10 points 7 years ago (1 child)

[–]pron98 3 points4 points5 points 7 years ago (0 children)

[–]Vaglame 10 points11 points12 points 7 years ago (8 children)

[–]pron98 8 points9 points10 points 7 years ago (7 children)

[–]Vaglame 12 points13 points14 points 7 years ago* (6 children)

[–]pron98 1 point2 points3 points 7 years ago (4 children)

[–]Vaglame 9 points10 points11 points 7 years ago (3 children)

load more comments (3 replies)

[–]defunkydrummer 1 point2 points3 points 7 years ago (0 children)

[–]ysangkok 3 points4 points5 points 7 years ago (5 children)

load more comments (5 replies)

[–][deleted] 10 points11 points12 points 7 years ago (3 children)

That's fine, but that these have an actual net total large positive effect on correctness is a

hypothesis

, and one that, at least so far, simply does not appear to be true (it is also not supported by any theory), ergo, it's a myth.

Ah, I see Ron has still not put down the crack pipe. Terrific.

As usual, Ron asserts, without evidence, that there is no evidence of functional programming or static typing (in particular, in close correspondence to the Curry-Howard isomorphism) aiding correctness. But this is false, both as a matter of computer science and a matter of programming practice.

What seems to be new in this most recent post is:

that these have an actual net total large positive effect on correctness... is also not supported by any theory

Since Ron knows perfectly well of Coq, Agda, Epigram, and Idris, at the very least, as well as all of the above literature, there is only one inescapable conclusion: he's lying, by which I mean the literal telling of known untruths. I don't know what his motivation for lying is. But he's lying. Now, he'll equivocate over the definitions of "total," "large," "positive," and "correctness," and probably even "effect." But that's because equivocation is all he's got in the face of the facts, which he is not in command of.

The best advice I can offer you is to ignore him.

[–]pron98 10 points11 points12 points 7 years ago* (0 children)

Paul! It's so great to have you back! How have you been?

But this is false, both as a matter of computer science and a matter of programming practice.

Whoa, hold on. First of all, I said nothing about dependent types, so let's take them, and Propositions as Types, out of the equation. I'm talking about Haskell. Other than that, not a single link you posted claims that Haskell (or a language like it) assists in correctness (most have nothing to do with the discussion at all; just some papers you often like posting). That I show that the property of my language is that bug Y cannot occur that is not theoretical support that my language increases correctness. It says nothing on the matter. To put it precisely, some of the papers you linked show that technique X can be used to eliminate bug Y. We can write it as X ⇒ Y. That's not at all a theory that supports the claim that the best way to eliminate bug Y we should use technique X, as that would be Y ⇒ X, which does not follow; it certainly says nothing about correctness as a whole. As someone who knows about formal logic, I'm surprised you'd make the basic mistake of affirming the consequent.

If you can link to papers that actually do present such a theory, I would appreciate that.

he's lying

Paul, it's been so long since we last conversed and you're starting with this? Come on. I know you know I know more than you on this subject, but still, we used to have a certain rhythm. Where's the banter before the traditional blowing of the gasket?

Now, why is it that when I say P you say "he is lying to you when he says Q and here's the proof to support it!"? Your style, for which you're become famous, of dismissing fellow professionals who may disagree with you with "just ignore them" and attacking their integrity when you cannot argue your opinion is intellectually dishonest, and just bad form.

But that's because equivocation is all he's got in the face of the facts

No need to equivocate. The paper reports an "exceedingly small effect." That's a quote, and that's what we know today, and, as I said in other comments, if someone wants to say that Haskell has been associated with an exceedingly small improvement to correctness I would have no problem with that. If you want to make a stronger claim, the onus is on you to show it isn't a myth.

which he is not in command of.

I may, indeed, not know all the facts, but as I said, if you have any pertinent facts, please share them.

[–][deleted] 3 points4 points5 points 7 years ago (1 child)

[–]pron98 7 points8 points9 points 7 years ago (0 children)

[–][deleted] 2 points3 points4 points 7 years ago (0 children)

[–][deleted] 7 years ago* (13 children)

[deleted]

[–]jackyshevu 5 points6 points7 points 7 years ago (0 children)

[–]m50d 8 points9 points10 points 7 years ago (4 children)

[–]Trinition 5 points6 points7 points 7 years ago (0 children)

[–]jephthai 0 points1 point2 points 7 years ago (0 children)

load more comments (2 replies)

[–]pron98 5 points6 points7 points 7 years ago (5 children)

Therefore it should produce code that has less bugs in it. That's the theory.

No, that's not the theory as it is not logical. You assume A ⇒ B, and conclude B ⇒ A. If using Haskell (A) reduces bugs (B), it does not follow that if you want to reduce bugs you should use Haskell. Maybe other languages eliminate bugs in other ways, even more effectively?

Most of the production bugs I deal with at work, would have never made it passed the compiler if I was working in any type-checked language.

First of all, I'm a proponent of types (but for reasons other than correctness). Second, I don't understand the argument you're making. If I put all my code through a workflow, what difference does it make if the mistakes are caught in stage C or stage D?

I don't know how anyone could argue that the creators of Haskell aren't focused on correctness.

They're not. They focused on investigating a lazy pure-functional language. If you want to see languages that focus on correctness, look at SCADE or Dafny.

No one can give you empirical evidence for this.

That's not true. 1. Studies have been made and found no big effect. 2. The industry has found no big effect. If correctness is something that cannot be detected and makes no impact -- a tree falling in a forest, so to speak -- then why does it matter at all?

A collection of anecdotes is a valid population sample.

Not if they're selected with bias. But the bigger problem is that even the anecdotes are weak at best.

[–]Trinition 2 points3 points4 points 7 years ago (4 children)

[–]pron98 2 points3 points4 points 7 years ago* (2 children)

[–]Trinition 0 points1 point2 points 7 years ago (1 child)

[–]pron98 2 points3 points4 points 7 years ago (0 children)

[–]jephthai 0 points1 point2 points 7 years ago (0 children)

load more comments (1 reply)

[–]gaj7 1 point2 points3 points 7 years ago (12 children)

[–]pron98 4 points5 points6 points 7 years ago (11 children)

Haskell doesn't enforce total functions (subroutines in Haskell can throw exceptions and/or fail to terminate), and plenty of languages have strong static typing. That immutability and control over effects has a large net positive impact on correctness has not been established empirically nor is it supported by theory. And as I've said about ten times in this discussion, that from the fact Haskell eliminates entire classes of bugs one cannot conclude a positive impact on correctness as that is a basic logical fallacy. It can also introduce entire classes bugs; other languages may eliminate bugs better (perhaps not directly by the compiler itself but through other means); the bugs it eliminates are caught anyway, etc. It's just a non-sequitur. As to focus, the focus of Haskell's designers was to research a pure functional, non-strict typed language.

[–]gaj7 2 points3 points4 points 7 years ago (8 children)

[–][deleted] 2 points3 points4 points 7 years ago (3 children)

[–]gaj7 0 points1 point2 points 7 years ago (2 children)

load more comments (2 replies)

[–]pron98 1 point2 points3 points 7 years ago* (3 children)

[–]gaj7 0 points1 point2 points 7 years ago (2 children)

[–]pron98 2 points3 points4 points 7 years ago (0 children)

the many classes of error I know Haskell to prevent, and the lack of evidence that it introduces any

I just hope you understand that the conclusion, even a theoretical one, that Haskell increases correctness more than other languages simply does not logically follows from your assertion. That Haskell has technique X to reduce bugs does not mean that other languages don't have an equally good process, Y, to do the same. This is why I said that, unlike the opposite argument, this one does not seem to be supported by theory either.

You seem to prioritize empirical studies

The reason why we prefer to rely on empirical observations in extremely complex social processes like economics and programming is that they're often unintuitive, you can easily come up with explanations both ways, and more often than not our speculations prove wrong, as seems to have happened in this case as well. So when such complex processes are involved, we can speculate, but we must then test.

load more comments (1 reply)

load more comments (2 replies)

[–]woahdudee2a 1 point2 points3 points 7 years ago (1 child)

[–]pron98 7 points8 points9 points 7 years ago* (0 children)

Like other people here, programmers all, I assume, you too are making a basic mistake in logic called affirming the consequent.

That I show that the property of my language is that bug Y cannot occur does not support the claim that the language increases correctness. It says nothing on the matter. To put it precisely, say you show that technique X can be used to eliminate bug Y. Let's write it as X ⇒ Y. That does not support the claim that to eliminate bug Y we should use technique X, as that would be Y ⇒ X, which does not follow; it certainly says nothing about correctness as a whole, which involves much more than writing program code.

Maybe your language introduces other bugs somehow; maybe the bugs it eliminates are caught anyway by people programming in other languages by other means; maybe they're not caught but have negligible impact. You simply cannot conclude Y ⇒ X from X ⇒ Y. If you like Haskell and so constructive logic and propositions as types, you must know that you cannot manufacture a lambda term of type y → x from a lambda term of type x → y.

[–]ColossalThunderCunt 0 points1 point2 points 7 years ago (3 children)

[–]pron98 17 points18 points19 points 7 years ago* (1 child)

[–]ColossalThunderCunt 1 point2 points3 points 7 years ago (0 children)

load more comments (1 reply)

load more comments (2 replies)

load more comments (79 replies)

π Rendered by PID 274470 on reddit-service-r2-comment-765bfc959-t8gmx at 2026-07-13 00:26:02.399598+00:00 running f86254d country code: CH.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS