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

[Alexey Raga]

> Oh, my 1st question will be: did you try Eta, Frege?
Yes, I tried Eta for some time, implemented a couple of Kafka-related
libraries in it (Kafka Client, Schema Registry, etc.)
Eta is Haskell 7.10.3 with C FFI replaced with Java FFI (plus some features
ported from GHC 8)

>  Eta should support Haskell libraries as well as Java ones?
Eta does. Through a very nice FFI. But so does Haskell. We have nice FFI to
use C libs. I maintain a couple of libs that use it extensively, works
quite well.
There are also things like "inline-c", "inline-r", "inline-java" in
Haskell, so we CAN call to another languages/paradigms quite nicely. I
don't see your point here making parallels with Eta.

>  expressions are not monads but step forward, “monads++”
Can I have a definition and laws of "monad++"? Otherwise, I don't
understand what you are talking about. If it obeys monadic laws it is a
monad. But I'll wait for the definition.

> Prolog can be “pure” and to do I/O without monads, also Clean can as well
as F#.
But it is not lazy - one. Remember, laziness is our requirement here.
Whatever you propose _must _ work in a context of laziness.
Second, the inability to track side effects in F# is not "simplification"
and is not a benefit, but rather a limitation and a disadvantage of the
language and its type system.
It is _just a bit_ less dramatic in F# because F# is not lazy, but it is
quite a miss anyway.
Third, AFAIK CLR restrictions do not allow implementing things like
Functor, Monad, etc. in F# directly because they can't support HKT. So they
workaround the problem.
But again, F# cannot be expressive enough: no HKT, no ability to express
constraints, no ability to track effects...

> I’m not unique in my opinion: https://www.youtube.com/watch?v=rvRD_LRaiRs
I've watched this talk and I haven't got the point. I don't take
"unfamiliar means bad" or "unfamiliar means complex" points.

> overengineering due to mentioned limitation. No such one in ML, F#.
Really?  You keep mentioning F#, and I struggle with it right now _because_
of such limitations. There are no meaningful ways abstract over generics,
it is impossible to reason about functions' behaviours from their type
signatures (because side effects can happen anywhere), it has Option, but
you still can get Null, you can't have constraints, etc., etc. It is
sooooo muuuuch mooore limited.

> I can achieve Maybe effect with nullable+exceptions or ?-family operators,
No, you can't.

> Nobody will remember them after 5-10 years...
OCaml exists for 22 years now, doing well and solves problems it has been
designed for very well. So _already_ more than twice compare to your
prediction.

>  fields are not starting with “_” prefix, so I need to create lenses
explicitly
No you don't. You don't have to have "_" prefix to generate a lense. You
have total control here.

> What is the business value of such code: nothing
Can you define "business value" please? You mention it for a couple of
times, so I am puzzled. Otherwise, it reminds me of
https://twitter.com/newhoggy/status/999930802589724672

> For non-Haskell programmer it looks like you try to solve non-existing
problem
For Haskell programmers, Java solves non-existing problems all the time :)
Every single time you see on twitter or here something like "I replaced
hundreds of lines of Java code with a single 'traverse'" you get the proof.
And it happens so often.
Also, what exactly is that "non-existent problem"?
In an immutable environment (and C# gives you that, F# does, even JS does),
how do these languages solve that non-existing problem that lens setters
do? I'll answer this question myself: they don't. So even in JavaScript my
non-FP colleagues working on frontend in JavaScript use JS lens library.
Precisely because it _does_ solve their very existing problems.

>  Haskell code needs help from IDE, types hints, etc.
Types are written and read by programmers. Java is impossible without IDE.
What is the point here?

> And I often meet a case when somebody does not understand what monads are
in “do” blocks.
Familiarity again. They learn and then they understand.
I don't understand C++. I barely understand C. I don't understand Ruby
(every time I have to work with it, it is a nightmare for me). I don't
understand Erlang.
Does it mean that all these languages are bad and need to die or change? Or
does it just mean that I am ignorant to learn them? I thinlk it is second.
I also understand English, I can understand Russian but not Japanese or
Swiss German. Or Tajik. Does it mean that Tajik is complicated? No, it is a
very simple  language I used to speak fluently when I was a child :)
Familiarity means nothing. I repeat: don't bring familiarity, it means
nothing.

> Text, also ByteString, lazy/strict, the same with the numbers
(word/int/integer)
But the problem is not with Text/ByteString! The problem is with the
perception that there must be just one string that rules them all!  But it
is wrong!
These types are different, for different use cases and with different
tradeoffs! It is good that I can choose what I need according to my
requirements.
Int/Word are not even close to being the same! Words cannot be negative, at
least.
If you do bits manipulations you want Words, not Ints! Java doesn't have
unsigned numbers, so bits manipulations are insanely hard in Java since you
_always_ need account to the sign bits. This the _real_ problem.

> Better is to have one good solid library bundled with GHC itself
(“batteries included”) and only specific things will live in libraries and
frameworks.
Better for whom? Definitely NOT better for me and my team using Haskell
commercially. Again, to effectively meet requirements, functional and
non-functional, we don't want just a mediocre compromise thing. I gave you
an example with parsers already: different parsers have different
tradeoffs. It is often a GOOD thing that there are many different libraries
doing the same thing differently.

As a person using Haskell commercially, I specifically don't want a
"batteries included, one way of doing things" solution.

Regards,
Alexey.

On Sun, Jul 15, 2018 at 1:28 AM Paul <aquagnu at gmail.com> wrote:

> Hello Alex!
>
>
>
> > 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
>
>
>
> Oh, my 1st question will be: did you try Eta, Frege? May be I’m wrong but
> Eta should support Haskell libraries as well as Java ones? They allow you
> to use libraries from the both world...
>
>
>
> > As a result, the language becomes overly complicated and less useful.
>
>
>
> Yes, this is another side. You know, anything has several sides: good and
> bad...
>
>
>
> > 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.
>
>
>
> True. Laziness makes Haskell unique. I think Haskell makes laziness so
> popular in modern languages although it was known long ago (as data in
> “infinite streams”, etc). I think, Miranda was lazy, so Haskell is lazy too
> 😊 And IMHO there was some lazy dialect of ML (may be, I’m not right).
>
>
>
> > "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_.
>
>
>
> Sure. I mean, the need of side-effects (and firstly I/O) led to the monads.
>
>
>
> > 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 ;)
>
>
>
> Better IMHO to have less infrastructure code. Better is to hide all
> “machinery” in compiler.
>
>
>
> My point was that monads are workaround of Haskell problem, this was
> historically reason of their appearance. And if I have not such limitation
> in my language I don’t need any monads. What are the monad benefits in ML,
> for example? They are using in F#, but 1) comp. expressions are not monads
> but step forward, “monads++” and 2) they play different role in F#:
> simplifying of the code. And you *can* avoid them in all languages except
> Haskell. For example, Prolog can be “pure” and to do I/O without monads,
> also Clean can as well as F#. Monads have pros, sure, but they are not
> composable and workaround leads to another workaround – transformers. I’m
> not unique in my opinion: https://www.youtube.com/watch?v=rvRD_LRaiRs All
> of this looks like overengineering due to mentioned limitation. No such one
> in ML, F#. D has keyword “pure”, and didn’t introduce monads. Performance
> is very important feature of the language, that limitation is the reason #1
> why Haskell has bad and unpredictable performance. “do”-block is not the
> same as “flat” block of C# statements and its performance is not the same.
> I can achieve Maybe effect with nullable+exceptions or ?-family operators,
> List with permutations/LINQ, guard with if+break/continue and to do it
> without sacrificing performance.. ListT/conduits – are just
> generators/enumerators. Benefit of monads IMHO is small, they are
> workaround of Haskell problem and are not needed in other languages. Sure,
> there are monads in Ocaml, Javascript, Python (as experimental libraries),
> but the reason is hype. Nobody will remember them after 5-10 years...
>
>
>
> Actually this is very-very subjective IMHHHHO 😊
>
>
>
> > 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.
>
>
>
> When I have legacy code, there are a lot of types which fields are not
> starting with “_” prefix, so I need to create lenses explicitly...
> “Infrastructure” code. What is the business value of such code: nothing.
> For non-Haskell programmer it looks like you try to solve non-existing
> problem 😊  (*very-very provocative point: all Haskell solutions looks
> very overengineering. The reason is: lambda-abstraction-only. When you try
> to build something big from little pieces then the process will be very
> overengineering. Imagine that the pyramids are built of small bricks*).
>
>
>
> > I don't agree that operators are noise. You certainly can write Haskell
> almost without operators if you wish.
>
>
>
> Here I’m agree with D. Knuth ideas of literature programming: if code can
> not be easy read and understand on the hard-copy then used language is not
> fine. Haskell code needs help from IDE, types hints, etc. And I often meet
> a case when somebody does not understand what monads are in “do” blocks.
> Also there are a lot of operators in different libraries and no way to know
> what some operator means (different libraries, even different versions have
> own set of operators).
>
>
>
> > As for extensions, I think that many more should be just switched on by
> default.
>
>
>
> +1
>
>
>
> > 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.
>
>
>
> No... Actually, I have not idea what is better. Currently there are a lot
> of conversions. Some libraries functions expect String, another - Text,
> also ByteString, lazy/strict, the same with the numbers (word/int/integer).
> So, conversions happen often.
>
>
>
> > I don't understand this "no business value" statement. Value for which
> business? What does it mean "check types, no business value"?
>
> There are libraries which nothing do in run-time. Only types playing. Only
> abstractions over types. And somebody says: oh man, see how many libraries
> has Haskell. But you can compare libraries of Haskell, Java, C#,
> Javascript, Perl, Python 😊 All libraries of Java, Python... have
> business value. Real-world functionality. Not abstract play with types. But
> more important point is a case with installed Agda 😊 or alternative
> libraries which does the same/similar things. The reason is important:
> Haskell moves a lot of functionality to libraries which is not good design
> IMHO. This is the root of the problem. Better is to have one good solid
> library bundled with GHC itself (“batteries included”) and only specific
> things will live in libraries and frameworks. Monads and monads
> transformers are central thing in Haskell. They a located in libraries.
> There is standard parser combinators in GHC itself, but you will have in
> the same project another one (or more than 1!). Etc, etc...
>
>
>
> Also installed GHC... Why is it so big!? IMHO it’s time to clear
> ecosystem, to reduce it to “batteries” 😊
>
>
>
> > 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 :)
>
>
>
> Absolutely true 😊
>
>
>
> 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/20180715/6f825e1c/attachment-0001.html>