[Haskell-cafe] Investing in languages (Was: What is yourfavourite Haskell "aha" moment?)

[Alexey Raga]

Hi Paul,

As someone who uses Haskell commercially for a couple of years now, I think
I have something to add.

A small disclaimer: none of the members of our team has an academic
background. We all have different backgrounds: C#, Java, Ruby, Python, C,
even Perl if I am not mistaken. Yet we ended up with FP first, and then
with Haskell.

We have switched to Haskell from Scala, which _is_ a multi-paradigm
language borrowing bits and pieces from other languages/paradigms and
mixing them together. It is an enormously hard work to do it and for that,
I very much respect Odersky and the core Scala team. But at the same time,
Scala is a very complicated language where pretty much nothing feels
consistent or conceptually finished. Too many things in Scala can get you
only that far before they become unprincipled. And then it justs stops and
you have to find a workaround.
This isn't a problem with Scala particularly though, it is exactly a
problem of borrowing bits of foreign concepts: they simply don't fuse into
one cohesive system.
As a result, the language becomes overly complicated and less useful.
In his talk (https://www.youtube.com/watch?v=v8IQ-X2HkGE) John De Goes
explains exactly the same problem, talking about Scala, but the reasoning
is applicable generally. One of the conclusions is very interesting: the
mix, the middle ground between different paradigms is often imagined as a
"paradise" that attracts peoples from all the sides. However, in reality,
it is the place where no one is happy, no one is really interested in it,
no one wants it. Watch the talk, it is fun.
Also: https://twitter.com/chris__martin/status/1016462268073209856

I bring this in because you name lots of languages, but when you speak
about "borrowing" you don't name any. So I did. We lived throuh such a
life, we felt it. Thank you very much, no desire to repeat it again.

I personally went through F# in my career (and I am still coming back to
F#, and I am writing F# right now).  With it, I have not exactly the same,
but similar experience.

Your joke about how Haskell has been made misses one point: it was
initially designed as a lazy language (at least as far as I know). Many
features that Haskell has now are there because of laziness: if you want to
be lazy, then you have to be pure, you have to sequence your effects, etc.

"Let's defer lambda, name it IO and let's call it Monad" -  this bit isn't
even funny. Monad isn't IO. IO happens to be a monad (as many things do,
List as an example), but monad isn't IO and has nothing to do with IO. A
horse is classified as Mammal, but Mammal doesn't mean horse _at all_.

Now back to your items:


   - No monads, no transformers

In a context of a lazy language, you need to sequence your effects
(including side effects), that's the first point. The second is that
instead of disappearing from Haskell, monads (and other concepts) are
making their way to other languages. Scala has them, F# has them, even C#
has them (however indirectly). Try to take away List Monad from C#
developers and they'll kill you ;)
Watch "What Haskell taught us when we were not looking" by Eric Torreborre (
https://www.youtube.com/watch?v=aNL3137C74c)
Also: https://twitter.com/Horusiath/status/1016593663626014720?s=09 :)


   - There are dependent types, linear types

Agree here.  And they are coming to Haskell, naturally and without breaking
it dramatically into another language.


   - There are other evaluation models/abstractions (not only lambda)

I think I made my point above.


   - Special syntax for records fields, etc

That would be nice. Although even coming from C# background, I don't
entirely understand why it is _that much_ important for some people. For me
personally, it is just a bit of annoyance. I have never felt like "Oh, I
could achieve so much more if only I had records!" :) Lenses and generic
lenses help, so be it. But I don't think that anything prevents Haskell
from having it, and I don't think that Haskell as a language needs a
dramatic change as you depict to make it happen. Just a feature.


   - Less operators noise, language extensions (but it’s very disputable)

I don't agree that operators are noise. You certainly can write Haskell
almost without operators if you wish.
As for extensions, I think that many more should be just switched on by
default.


   - Solve problems with numerous from/to conversions (strings, etc)

You mean that conversion should happen implicitly? Thank you, but no, thank
you. This is a source of problems in many languages, and it is such a great
thing that Haskell doesn't coerce types implicitly.


   - Solve problems with libraries

Surely, more libraries are better. I don't understand this "no business
value" statement. Value for which business? What does it mean "check types,
no business value"?
I also strongly disagree that there should only be one library for one
thing. Do you know many ways are there to, say, parse XML? Or Json? How
many different tradeoffs can be made while implementing a
parser/serialiser? Some are valuable in one "business" but totally not
acceptable in another, and vice versa. In our company, we have a set of
requirements such that _none_ of the tradeoffs made by the existing XML
parsers would satisfy them. So we had to write our own. Deliver business
value, yeah. And you say that there should only be one XML parser for a
given language? Absurd.
I think Haskell has only one problem with libraries: we need more of them.
And then it falls into a famous joke: "The problem with Open Source
Software is YOU because YOU are not contributing" :) Meaning that if we
want more good libs then we should write more good libs :)

Regards,
Alexey.



On Sat, Jul 14, 2018 at 5:05 PM Paul <aquagnu at gmail.com> wrote:

> I understand that my points are disputable, sure, example, multi-pardigm
> Oz – dead 😊 Any rule has exceptions. But my point was that people don’t
> like elegant and one-abstraction languages. It’s my observation. For me,
> Smalltalk was good language (mostly dead, except Pharo, which looks cool).
> Forth – high-level “stack-around-assembler”, mostly dead (Factor looks
> abandoned, only 8th looks super cool, but it’s not free). What else?
> Lisp? OK, there are SBCL, Clojure, Racket... But you don’t find even
> Clojure in languages trends usually. APL, J – super cool! Seems dead (I
> don’t know what happens with K). ML, SML? By the way, Haskell role was to
> kill SML community, sure it is sad to acknowledge it, but it’s 100% true...
>
>
>
> Haskell try to be minimalistic and IMHO this can lead to death. Joachim,
> I’m not talking “it’s good/it’s bad”, “multiparadigm is good” or else... I
> don’t know what is right. It’s my observations only. Looks like it can
> happen.
>
>
>
> If we will look to Haskell history then we see strange curve. I’ll try to
> describe it with humour, so, please, don;t take it seriously 😊
>
>    - Let’s be pure lambda fanatics!
>    - Is it possible to create a big application?
>    - Is it possible to compile and optimize it?!
>    - Let’s try...
>    - Wow, it’s possible!!! (sure, it’s possible, Lisp did it long-long
>    ago).
>    - Looks like puzzle, can be used to write a lot of articles (there
>    were articles about combinators, Jay/Cat/Scheme, etc, now there are a lot
>    of Haskell articles – big interesting in academia. But IMHO academia
>    interest to language can kill it too: Clean, Strongtalk, etc)
>    - Stop! How to do I/O? Real programming?!!
>    - Ohh, if we will wrap it in lambda and defer it to top level
>    (main::IO ()), it will have I/O type (wrapper is hidden in type)
>    - Let’s call it... Monad!!
>    - Wow, cool! Works! Anybody should use monads! Does not your language
>    have monads? Then we fly to you! (everybody forgot that monads are
>    workaround of Haskell limitation and are not needed in another languages.
>    Also they lead to low-performance code)
>    - But how to compose them???!?!
>    - We will wrap/unwrap, wrap/unwrap.. Let’s call it... transformers!!!
>    “Monad transformers” – sounds super cool. Your language does not have
>    “lift” operation, right? Ugh...
>    - How to access records fields... How... That’s a question. ‘.’ - no!
>    ‘#’ - no! Eureka! We will add several language extensions and voila!
>    - To be continued... 😊
>
>
>
> I love Haskell but I think such curve is absolutely impossible in
> commercial language. With IT managers 😊 To solve problem in a way when
> solution leads to another problem which needs new solution again and reason
> is only to keep lambda-abstraction-only (OK, Vanessa, backpacks also 😉)
> Can you imagine that all cars will have red color? Or any food will be
> sweet? It’s not technical question, but psychological and linguistic. Why
> native languages are not so limited? They even borrow words and forms from
> another one 😊
>
>
>
> Haskell’s core team knows how better then me, and I respect a lot of
> Haskell users, most of them *helped me A LOT* (!!!). It’s not opinion
> even, because I don’t know what is a right way. Let’s call it observation
> and feeling of the future.
>
>
>
> I feel: Haskell has 3 cases: 1) to die 2) to change itself 3) to fork to
> another language
>
> How I see commercial successful Haskell-like language:
>
>    - No monads, no transformers
>    - There are dependent types, linear types
>    - There are other evaluation models/abstractions (not only lambda)
>    - Special syntax for records fields, etc
>    - Less operators noise, language extensions (but it’s very disputable)
>    - Solve problems with numerous from/to conversions (strings, etc)
>    - Solve problems with libraries
>
>
>
> Last point needs explanation:
>
>    - There is a lot of libraries written to check some type concepts
>    only, no any business value. Also there are a lot of libraries written by
>    students while they are learning Haskell: mostly without any business
>    value/abandoned
>    - There is situation when you have alternative libraries in one
>    project due to dependencies (but should be one only, not both!)
>    - Strange dependencies: I have installed Agda even! Why???!
>
>
>
> IMHO problems with libraries and lambda-only-abstraction lead to super
> slow compilation, big and complex compiler.
>
> So, currently I see (again, it’s my observation only) 2 big “camps”:
>
>    1. Academia, which has own interests, for example, to keep Haskell
>    minimalistic (one-only-abstraction). Trade-off only was to add language
>    extensions but they fragmentizes the language
>    2. Practical programmers, which interests are different from 1st “camp”
>
>
>
> Another my observation is: a lot of peoples tried Haskell and switched to
> another languages (C#, F#, etc) because they cannot use it for big
> enterprise projects (Haskell becomes hobby for small experiments or is
> dropped off).
>
>
>
> Joachim, I’m absolutely agreed that a big company can solve a lot of these
> problems. But some of them have already own languages (you can compare
> measure units in Haskell and in F#, what looks better...).
>
>
>
> When I said about killer app, I mean: devs like Ruby not due to syntax but
> RoR. The same Python: sure, Python syntax is very good, but without Zope,
> Django, TurboGears, SQLAlchemy, Twisted, Tornado, Cheetah, Jinja, etc –
> nobody will use Python. Sure, there are exceptions: Delphi, CBuilder, for
> example. But this is bad karma of Borland 😊 They had a lot of compilers
> (pascal, prolog, c/c++, etc), but... On the other hand after reincarnation
> we have C# 😊  Actually all these are only observations: nobody knows the
> future.
>
>
>
>
>
> /Best regards, Paul
>
>
>
> *From: *Joachim Durchholz <jo at durchholz.org>
> *Sent: *13 июля 2018 г. 21:49
> *To: *haskell-cafe at haskell.org
> *Subject: *Re: [Haskell-cafe] Investing in languages (Was: What is
> yourfavourite Haskell "aha" moment?)
>
>
>
> Am 13.07.2018 um 09:38 schrieb PY:
>
> > 1. Haskell limits itself to lambda-only. Example, instead to add other
>
> > abstractions and to become modern MULTI-paradigm languages,
>
>
>
> "modern"?
>
> That's not an interesting property.
>
> "maintainable", "expressive" - THESE are interesting. Multi-paradigm can
>
> help, but if overdone can hinder it - the earliest multi-paradigm
>
> language I'm aware of was PL/I, and that was a royal mess I hear.
>
>
>
> > So, point #1 is limitation in
>
> > abstraction: monads, transformers, anything - is function. It's not
>
> > good.
>
>
>
> Actually limiting yourself to a single abstraciton tool can be good.
>
> This simplifies semantics and makes it easier to build stuff on top of it.
>
>
>
> Not that I'm saying that this is necessarily the best thing.
>
>
>
> > There were such languages already: Forth, Joy/Cat, APL/J/K... Most of
>
> > them look dead.
>
> Which proves nothing, because many multi-paradigm languages look dead, too.
>
>
>
> > When you try to be elegant, your product (language) died.
>
> Proven by Lisp... er, disproven.
>
>
>
> > This is not my opinion, this is only my observation. People like
>
> > diversity and variety: in food, in programming languages, in relations,
>
> > anywhere :)
>
>
>
> Not in programming languages.
>
> Actually multi-paradigm is usually a bad idea. It needs to be done in an
>
> excellent fashion to create something even remotely usable, while a
>
> single-paradigm language is much easier to do well.
>
> And in practice, bad language design has much nastier consequences than
>
> leaving out some desirable feature.
>
>
>
> > 2. When language has killer app and killer framework, IMHO it has more
>
> > chances. But if it has _killer ideas_ only... So, those ideas will be
>
> > re-implemented in other languages and frameworks but with more simple
>
> > and typical syntax :)
>
>
>
> "Typical" is in the eye of the beholder, so that's another non-argument.
>
>
>
> > It's difficult to compete with product,
>
> > framework, big library, but it's easy to compete with ideas. It's an
>
> > observation too :-)
>
>
>
> Sure, but Haskell has product, framework, big library.
>
> What's missing is commitment by a big company, that's all. Imagine
>
> Google adopting Haskell, committing to building libraries and looking
>
> for Haskell programmers in the streets - all of a sudden, Haskell is
>
> going to be the talk of the day. (Replace "Google" with whatever
>
> big-name company with deep pockets: Facebook, MS, IBM, you name it.)
>
>
>
> > language itself is not argument for me.
>
>
>
> You are arguing an awful lot about missing language features
>
> ("multi-paradigm") to credibly make that statement.
>
>
>
> > Argument for me (I
>
> > am usual developer) are killer apps/frameworks/libraries/ecosystem/etc.
>
> > Currently Haskell has stack only - it's very good, but most languages
>
> > has similar tools (not all have LTS analogue, but big frameworks are the
>
> > same).
>
>
>
> Yeah, a good library ecosystem is very important, and from the reports I
>
> see on this list it's not really good enough.
>
> The other issue is that Haskell's extensions make it more difficult to
>
> have library code interoperate. Though that's a trade-off: The freedom
>
> to add language features vs. full interoperability. Java opted for the
>
> other opposite: 100% code interoperability at the cost of a really
>
> annoying language evolution process, and that gave it a huge library
>
> ecosystem.
>
>
>
> But... I'm not going to make the Haskell developers' decisions. If they
>
> don't feel comfortable with reversing the whole culture and make
>
> interoperability trump everything else, then I'm not going to blame
>
> them. I'm not even going to predict anything about Haskell's future,
>
> because my glass orb is out for repairs and I cannot currently predict
>
> the future.
>
>
>
> Regards,
>
> Jo
>
> _______________________________________________
>
> Haskell-Cafe mailing list
>
> To (un)subscribe, modify options or view archives go to:
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
> Only members subscribed via the mailman list are allowed to post.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180714/9344f086/attachment.html>