

Why functional programming? Why Haskell? - tosh
http://book.realworldhaskell.org/read/why-functional-programming-why-haskell.html

======
solomatov
Haskell is badly designed language in many respects which promotes ugly code.
I think, it won't be mainstream statically typed functional language in any
time.

Here is my list of bad language features:

1\. It doesn't support dot notation for records.

2\. Record names can't be overloaded.

3\. Monads might lead to messy code due to verbose syntax. For example,
instead of writing c <\- openDbConnection (readConfigData), I have to write
ugly code

    
    
      do
        conf <- readConfigData
        c <- openDbConnection
    

The situation becomes worse, the more side effecting parameters you need for a
function call.

5\. Many extensions, essential for productive development are out of the
language standard. For example, multi param type classes, existential types.
Haskell' standard is in progress for a very long time, and still isn't
finished.

~~~
sanxiyn
I do think 2 is a real problem, but it seems Haskell people couldn't agree on
the solution. Simon Peyton Jones (Haskell 98 standard editor) proposed a
change but many people didn't like it.

[http://ghc.haskell.org/trac/haskell-
prime/wiki/TypeDirectedN...](http://ghc.haskell.org/trac/haskell-
prime/wiki/TypeDirectedNameResolution)

~~~
merijnv
FWIW, there is currently a GSoC project supervised by SPJ that is working on
making overloadable fields available in GHC.

------
davidw
> Since pure code has no dealings with the outside world, and the data it
> works with is never modified, the kinds of nasty surprise in which one piece
> of code invisibly corrupts data used by another are very rare.

If you're trying to sell me on Haskell, right there you just made me think
"uh, ok, guys, but _my_ code does not live in an ivory tower, and very much
needs to deal with the real world, messy data, users, and so on".

I realize that Haskell can handle that, too, but in terms of copy writing, it
leaves something to be desired.

They subsequently go on to write much more interesting reasons why you might
consider Haskell, including examples of companies using it in the real world,
but they should not lead with talk of 'purity'.

~~~
wunki
The power of Haskell is that it acknowledges the fact that it's a messy world
and deals with it with the help of Monads.

You could turn it around and say that non-haskell programs live in an ivory
tower and ignore the messy world below :)

~~~
aristidb
I downvoted you because you're putting Monads on a pedestal and
misrepresenting their purpose. When you mean IO (or perhaps ST and State)
please don't say "Monads". Remember that [] is an instance of Monad too, and
it has nothing at all to do with dealing with the messy world. A monad is just
a typeclass with two operators that behave according to certain identity and
associativity laws, and a _lot_ of types fulfil them.

------
tbirdz
If you're not quite ready to whole hog on the functional purity aspect, I'd
suggest you take a look at OCaml. OCaml supports many modern programming
amenities, such as Garbage Collection, Higher-order Functions, Static Type-
Checking, Generics, Immutable Data Structures, Algebraic Data Types and
Pattern Matching, Automatic Type Inference while still allowing for imperative
programming when you need it.

I'd recommend taking a look at the Real World OCaml book:
[https://realworldocaml.org](https://realworldocaml.org)

~~~
seanmcdirmid
Doesn't Scala support the exact same features? I know OCaml is based on ML and
is mostly structural, while Scala more of a Java-like curly brace lang that is
nominal, but your feature list makes them sound the same.

~~~
silentOpen
Things Scala lacks which OCaml has:

1\. Tail call elimination 2\. A full-featured module system 3\. Functors
(functions at the module level) 4\. First-class modules 5\. GADTs 6\.
Polymorphic variants 7\. A decidable type system 8\. ... more?

Things OCaml lacks which Scala has:

1\. Traits 2\. Implicits 3\. Trivial Java FFI 4\. Seamless syntactic macros
(c.f. camlp4) 5\. ... more?

~~~
seanmcdirmid
Scala has 1, 5, and 6.

It lacks 7, and about 2/3, which are basically the same, where scala at least
supports mixin constructions (which you can also get from class-parameter ised
functors, though maybe not in Ocamel).

~~~
silentOpen
Could you elaborate on Scala's TCO support? I was under the impression that
only self-tail calls are eliminated and only if the stack trace would be
provably unused. Doesn't the JVM require stack traces? Can you use CPS in
Scala?

I see now that Scala can encode GADTs in case classes. What mechanism is
available to encode polymorphic variants? Particularly, I am interested in
writing matches over unions of polymorphic variant types.

I disagree that 2 and 3 are the same (structural module subtyping, nesting,
inclusion differs from applicative functors). I believe you can achieve mixins
with OCaml through the object system but it's not clear to me that this
addresses functor signature checking.

Another Scala bonus: 5\. Objects can implicitly be null.

~~~
seanmcdirmid
Scala has TCO support, but maybe not as advanced as Ocaml, being limited by
the JVM and all. CPS is heavily used in scala these days, as far as I can tell
by reading Ingo Meir's work.

I was confused about polymorphic variants. Scala doesn't seem to have that.

I did a lot of work with units (dr. scheme-style functors) before, and when I
moved to scala for my postdoc, I found all my patterns expressible using
mixins and nominal types...I didn't miss the modules (1st class or otherwise).

Scala has a non-null-ability option, but most programmers I think would find
null damn convenient.

------
unono
Having programmed at least 10k locs in all major paradigms, I've come to the
conclusion that relational programming (prolog and sql) are the best. Haskell
talks a good game and a lot of OO procedural code has been written, but for
programming succinct, elegant code, which also happens to be the most
lucrative - sql databases underlying most business - the relational paradigm
cannot be beat.

It's the most beautiful invention of computer science, Programming in prolog,
especially, is the closest a programmer can come to achieving a state of
nirvana. A place where the mind is at one with the problem at hand.

~~~
jacquesm
Good luck controlling your ABS system using prolog.

Having programmed more than I care to remember (since we're establishing
credibility by tossing unverifiable facts in there) I think it takes the right
tool for the right job. Sometimes that's prolog, sometimes that's assembly and
sometimes it's something else entirely.

Every language that is in use today has a niche, no single language manages to
span more than a few such niches and the larger the impedance mismatch between
the problem and the language the more work you have to do.

~~~
unono
Prolog can be used in embedded systems
[http://www.hercsmusicsystems.com/](http://www.hercsmusicsystems.com/)

~~~
jacquesm
Embedded and hard real time are not the same thing.

------
Vektorweg
"Why Haskell matters" is a way better explanation than this, i think.

~~~
tome
Also "Why Functional Programming Matters"

[http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pd...](http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf)

------
sseveran
People about to hate on haskell...go

~~~
seanmcdirmid
Hate is a feeling I reserve for corrupt politicians, taxi drivers who ignore
me, the guy who whistles in my open office, and...C++.

Everything else is either interesting or not. I think Haskell is interesting
from an academic research perspective, but I'm not interested in using it to
write programs.

