[aaronlevin]

> Ideally, I can use patterns in multiple languages, so my experience can seamlessly transfer.

In many cases you are not guaranteed via the type system that one individual's implementation of the Observer pattern (for example) is not full of bugs, contains side effects, or closely adheres to the pattern's spec.

I believe Gabriel is hinting at the theoretical underpinnings of what it means to be composable, as opposed to just talking about how things can be mashed together (via pattern or interfaces or contracts or testing or whatever).

[twic]

> In many cases you are not guaranteed via the type system that one individual's implementation of the Observer pattern (for example) is not full of bugs, contains side effects, or closely adheres to the pattern's spec.

Nor are you in Haskell, of course. Nothing about that language prevents code being full of bugs, nor failing to adhere to a specification, nor, given the existence of unsafePerformIO, having side effects.

Certainly, a competent Haskell programmer will not write bugs, will adhere to the specification, and will not introduce hidden side-effects. But then, nor will a competent programmer in any other language.

[tel]

What is the barrier to "stupidity" in a language. In Haskell there is a deliberate, powerful barrier in the form of a compiler which will yell at you repeatedly until you stop violating the constraints encoded in the types. You either learn to work along the lines laid out by the types or you cheat.

To cheat you import a module called System.IO.Unsafe or Unsafe.Coerce and get sudden access to a magic hammer. If you use it to subvert the type system in a dramatic way then you'll immediately get so many massive runtime errors that you'll be forced to rescind. If you use it on a project that enforces -XSafe then the compiler will still reject you.

To get past both of those barriers you probably have to have a really, really great desire to break the system or a deep understanding of why and when it's valuable to use these unsafe types.

Again, nothing is actually stopping a terrifically bad programmer from breaking your statics, but there are a lot of things making their life much harder in the process.

The wager is that you can detect and avoid people who are willing to cross higher barriers much more easily.

[dllthomas]

Also, it's much easier to notice and reject a patch that imports Unsafe stuff than it is to notice and reject a patch that has a subtle type error.

[mightybyte]

Actually, yes. With Safe Haskell you can preclude unsafePerformIO, and therefore having side effects.

[eru]

> Nothing about that language prevents code being full of bugs, [...]

Certain classes of bugs are impossible. You can still introduce all the possible bugs.

> Certainly, a competent Haskell programmer [..] will not introduce hidden side-effects.

I know this was meant as sarcasm, but even an incompetent Haskeller can not introduce hidden side-effects.

[PeterisP]

A particular side-effect that an incompetent Haskeller can (and will, multiple times) introduce is wiriting code that gives correct results and is seemingly correct, but will suddenly run out of memory on larger (but still reasonable-sized) data due to unexpected laziness.

[mightybyte]

In practice this doesn't happen very often. Laziness is unique to Haskell, but the phenomenon that bad programmers can introduce subtle bugs is most definitely not.

[aaronlevin]

You can encode a specification within Haskell's type system and get guarantees that are very difficult in other languages. Gabriel's pipes library is a great example of this (see a Pipe's associativity laws).

[aaronlevin]

twic: yes, if you take my statement literally you are correct: it is possible to introduce bugs in a Haskell program.

[twic]

Oh, sure. Haskell's type system is famously powerful. But the simple fact is that it does not preclude bugs. It is possible to have bugs in Haskell programs!

[tel]

Nobody who knows what they're talking about says that Haskells types (or even Idris/Agda/Coq's types) "preclude bugs" but instead that they "eliminate some classes of bugs so long as you don't behave really pathologically".

That's a much weaker statement, but still a valuable property.

[aaronlevin]

I did not say it was impossible to write Haskell with bugs. I simply stated that you are not guaranteed that a particular implementation of a design pattern adheres to the patterns semantics, therefore introducing a bug. With good usage of Haskell's type system, you can wholly avoid such bugs, and a great example of this, as I stated, is the associativity laws within the pipes library.

Semantics! :)

[freyrs3]

That's like saying that because it's possible that the roof may occasionally leak you shouldn't have a roof over your head at all.

[mercurial]

No language "precludes bugs". You can get bugs because you didn't leverage Haskell's type system ("let's use String for everything"), logic bugs, or simply bugs caused by a faulty understanding of the problem. What you're not going to get is NPEs, or unwanted side-effects. Since it takes very little work in Haskell to ensure statically that two numbers which represent two different notions (say, mass and velocity) have different types, it's going to be lot easier to get a robust program.

But no, Haskell is not a silver bullet, and comes with a number of significant drawbacks.

[Dewie]

Obviously it's a difference of degree. But Haskell offers more assurances in some areas than other languages. There are escape hatches, but that's exactly what they are - things that any reasonable programmer shouldn't reach for unless they really have to. You can give a function the value 'undefined' and the compiler won't care. But that is really only meant as "not implemented yet", "there are no sensible value to give back for this value", etc, not par for the course like for example the way null pointers are used in some other languages.

But since the world isn't perfect and programs can always have bugs, I guess we should just throw our hands up and proclaim that it doesn't really matter what we use.