What is your favourite Haskell "aha" moment?

classic Classic list List threaded Threaded
114 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: What is your favourite Haskell "aha" moment?

Joachim Durchholz
Am 13.07.2018 um 01:40 schrieb Tony Morris:
> On python, we are fixing it (WIP):
> https://github.com/qfpl/hpython

Some poisonous aspects of Python are unfixable.
E.g. having declarations as program-visible update to a global state
causes all kinds of unnecessary pain, such as having to deal with
half-initialized peer modules during module initialization.

> Did you see the recent "default mutable arguments" post?
> https://lethain.com/digg-v4/

Yeah, the "default parameter is an empty list but that's then going to
be updated across invocations" classic.
Other languages have made the same mistake. Default data needs to be
either immutable or recreated on each call.
Such mistakes can be mitigated, but they cannot be fixed while staying
backwards-compatible.

Python actually did an incompatible switch from 2 to 3, but for some
reason Guido didn't fix the above two, or some other things (such as
Python's broken idea of multiple inheritance, or the horribly
overcomplicated way annotations work).
Python is nice for small tasks. If you accept its invitation to extend
it you get fragility (due to the inability to define hard constraints so
whatever you extend will violate *somebody's* assumptions), and if you
scale to large systems you get fragility as well (because Python
modularization is too weak).

Well, enough of the off-topic thing here.

> On 07/12/2018 07:58 PM, Brett Gilio wrote:
>> Python is poison, indeed. ;)
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: What is your favourite Haskell "aha" moment?

Tony Morris-4
I am not fixing python. I am fixing the consequences of the fact that it
exists.


On 07/13/2018 04:47 PM, Joachim Durchholz wrote:

> Am 13.07.2018 um 01:40 schrieb Tony Morris:
>> On python, we are fixing it (WIP):
>> https://github.com/qfpl/hpython
>
> Some poisonous aspects of Python are unfixable.
> E.g. having declarations as program-visible update to a global state
> causes all kinds of unnecessary pain, such as having to deal with
> half-initialized peer modules during module initialization.
>
>> Did you see the recent "default mutable arguments" post?
>> https://lethain.com/digg-v4/
>
> Yeah, the "default parameter is an empty list but that's then going to
> be updated across invocations" classic.
> Other languages have made the same mistake. Default data needs to be
> either immutable or recreated on each call.
> Such mistakes can be mitigated, but they cannot be fixed while staying
> backwards-compatible.
>
> Python actually did an incompatible switch from 2 to 3, but for some
> reason Guido didn't fix the above two, or some other things (such as
> Python's broken idea of multiple inheritance, or the horribly
> overcomplicated way annotations work).
> Python is nice for small tasks. If you accept its invitation to extend
> it you get fragility (due to the inability to define hard constraints
> so whatever you extend will violate *somebody's* assumptions), and if
> you scale to large systems you get fragility as well (because Python
> modularization is too weak).
>
> Well, enough of the off-topic thing here.
>
>> On 07/12/2018 07:58 PM, Brett Gilio wrote:
>>> Python is poison, indeed. ;)
> _______________________________________________
> 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.

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Investing in languages (Was: What is yourfavouriteHaskell "aha" moment?)

Paul
In reply to this post by Chris Smith-31
12.07.2018 23:48, Chris Smith wrote:
This is a good question, and I think it depends on your goals.

If your goal is to inspire interest and attract children to programming, then you are best served by making it obvious what can and can't be done, and making it very difficult to make a mistake.  Some visual languages are very good at this, and Scratch, for example, is a good example.  Going even further, Scratch and similar languages are often used in situations where the students can do literally anything, and *something* interesting happens, inspiring that spark of excitement and feeling of "I did that!"  This is a magical moment, and it can change lives.

On the other hand, building new skills is the point of educating.  Avoiding the need for new skills means avoiding the opportunity to learn.  Children often still struggle with precise perception.  I've seen plenty of students as old as 12 to 13 who literally cannot see whether there's a comma in an expression, or whether a word is spelled "ie" or "ei", without extreme measures like covering the surrounding text.  Their brain just skips over these concerns.  Of course, they struggle in mathematics, and also basic language and communication.  Once again, one can avoid the problem and try to help them to be successful

Yes! Even more, mature brain has such selectivity too :)
We can miss something totally, because most people are thinking in traditional, standard ways (something like good known roads) and will not take new knowledge but will dispute with new knowledge and to try to ignore it or "destroy it mentally", but this is a slightly different disease ;)

without needing that skill, which a visual language is great at.  But of course, they ultimately do need the skill in order to communicate in the first place!  So there's also value in placing them in an environment where they need to learn it.  When making this decision, though, it's important to focus on skills that are truly necessary, and not (for example) remembering what order to write "public static void main" in their Java programs.

On Thu, Jul 12, 2018 at 2:16 PM Paul <[hidden email]> wrote:

Wooow! Yes!!

But today there is serious competition (Smalltalk, Python; I planned Scratch – but it’s for children of 7-9 years). I thing you are good teacher 😊

Btw, what do you think: what is better – textual programming or visual programming for children? For me, Labview/G was insight in 90s 😊 Today there is Luna language – it’s visual too. IMHO visual programming better illustrates ideas/concepts, or?

 

From: [hidden email]
Sent: 12 июля 2018 г. 21:00
To: [hidden email]
Subject: Re: [Haskell-cafe] Investing in languages (Was: What is yourfavouriteHaskell "aha" moment?)

 

Perhaps you mean something fun and visual like this? https://code.world/#PhFFj32Bx0FcpQvvoVJW0xw

 

These are written in the simplified variant of Haskell that I teach, which uses a custom Prelude that skips type classes and other advanced features, uses rebindable syntax to simplify types (for example, you'll see Number instead of Int, Double, etc.), and automatically provides graphics functions that work in the browser.

 

On Thu, Jul 12, 2018 at 1:54 PM Paul <[hidden email]> wrote:

Hmm, Chris, thanks for answer. Interesting. I was surprised when I first learned that someone somewhere is teaching the children to Haskell, but if you say so – then it’s possible and may be it’s good! 😊  

Sometimes children don’t like right things, but like fun. So, I though that more preferable to show them some bright demo: UI, graphics, some simple games, databases, to rise the interest, you know – this feeling of first code. First “wooow! It works!!!” 😊 Haskell, for me, looks pedantic, not for fun. May be I’m not right, I have not such experience.

 

 

From: [hidden email]
Sent: 12 июля 2018 г. 19:59
To: [hidden email]
Subject: Re: [Haskell-cafe] Investing in languages (Was: What is yourfavourite Haskell "aha" moment?)

 

I'll answer this, since I have been teaching Haskell to children for six years or so. :)

 

I think it's important to distinguish between Haskell AS USED in most of the community, and Haskell as it COULD be used.  I agree that you don't want to teach the first of those to children.  But Haskell is still a great teaching choice, mainly because GHC is so configurable that you can create the environment you want, and just build it with a Haskell compiler.  With GHC plugins, this is becoming even more true, but it already arises from a combination of (a) very lightweight and intuitive core syntax in the first place, (b) great support for custom preludes, and (c) the RebindableSyntax extension, and the fact that so much syntax is defined in terms of desugaring.

 

If you're seriously talking about teaching children, then your concerns about web frameworks and such are a bit silly.  (Unless by "children" you meant mid to late teens and after, in which case this becomes relevant.)  "Advanced" type features are also not particularly relevant (though there's some fuzziness about what counts as "advanced"; for instance, I've recently decided it's better to teach GADT syntax as the only option for defining algebraic data types, even though I never expect most students to take advantage of the extra power of GADTs.)

 

The main concern I have with F#, though, is that the semantics are far too complex.  It has all the power of a functional language, but none of the semantic simplicity. If students already struggle with compositional programming (and they do), they struggle even more when the simplest way to understand what's going on -- namely, substitution -- is taken away from them.  If you're going to teach a computational model based on sequencing actions on a global state (the state being the screen, network, etc.), then you might as well include mutable variables in that global state, and you might as well teach Python, which will at least be more intuitive, if not simpler.

 

On Thu, Jul 12, 2018 at 7:46 AM PY <[hidden email]> wrote:

I am afraid that it can lead to flame again, but F# has super-capacity: you can check measuring units, type providers, computation expressions, active patterns, static/dynamic types constraints, constraints on existing method, etc... It's clean, borrows some ideas from Haskell, some are original and Haskell borrows them (but with worse implementation). IMHO for children teaching to FP F# is the best. Even more, currently C# also has a lot of FP features (https://github.com/dotnet/csharplang/blob/master/proposals/patterns.md#arithmetic-simplification  -- is not it super easy and beauty?). Rust is more low level: you should think about memory "management", OOP has some problems... And serious argument for children teaching: salary trends (joke sure) :-) But you can compare salary in F# and Haskell, for example - people often choice language after check current salaries in the market. Also F# is more focused on realistic tasks and business value. It lacks performance, UWP yet (but in progress)... To feel how F# is sexy compare Web application written in Websharper and in any Haskell framework. Haskell is beauty but I'm afraid its fate unfortunately will be the same as one of Common Lisp, NetBSD, etc - it's ground for ideas and experiments and has disputable design. Also it's more-more difficult to teach children to Haskell than to F#...

IMHO is general to teach FP is more easy than to teach OOP if FP is not Haskell (some language which targets more eager/efficient/dynamic/real goals instead of abstract types playing).

12.07.2018 13:28, Vanessa McHale wrote:

I wouldn't say Rust has a large capacity for FP. I am not familiar with
F#. The thing that makes FP infeasible in Rust is not the lack of purity
but rather the fact that affine types make it difficult to treat
functions as first-class values.
 
 
On 07/12/2018 01:40 AM, Brett Gilio wrote:
Tony,
 
I am curious on your attitude towards multi-paradigm and ML-like
languages. I agree that functional programming is easily the better of
the bundle in many forms of application logic and elegance (which is
why I have come to love Scheme and Haskell), but do you see any room
for those languages like F# or Rust which have large capacities for FP
but are either functional-first (but not pure) or a hybrid?
 
Brett Gilio
 
On 07/12/2018 01:35 AM, Tony Morris wrote:
  I used to teach undergrad OOP nonsense. I have been teaching FP for 15
years. [^1]
 
The latter is *way* easier. Existing programmers are more difficult than
children, but still way easier to teach FP than all the other stuff.
 
[^1]: Canberra anyone? https://qfpl.io/posts/2018-canberra-intro-to-fp/
 
 
On 07/12/2018 04:23 PM, Joachim Durchholz wrote:
Am 11.07.2018 um 16:36 schrieb Damian Nadales:
 
I speak only from my own narrow perspective. I'd say programming is
hard, but functional programming is harder.
 
Actually it's pretty much the opposite, I hear from teachers.
 
Maybe that's why Java replaced Haskell in some universities
curricula
The considerations are marketable skills.
A considerable fraction of students is looking at the curriculum and
at job offers, and if they find that the lists don't match, they will
go to another university.
Also, industry keeps lobbying for teaching skills that they can use.
Industry can give money to universities so this gives them influence
on the curriculum (and only if they get time to talk the topic over
with the dean). This aspect can vary considerably between countries,
depending on how much money the universities tend to acquire from
industry.
 
https://chrisdone.com/posts/dijkstra-haskell-java. For some reason
most programmers I know are not scared of learning OO, but they fear
functional programming.
 
Programmers were *very* scared of OO in the nineties. It took roughly
a decade or two (depending on where you put the starting point) to get
comfortable with OO.
 
 
   I think the reason might be that OO concepts
like inheritance and passing messages between objects are a bit more
concrete and easier to grasp (when you present toy examples at least).
 
OO is about how to deal with having to pack everything into its own
class (and how to arrange stuff into classes).
Functional is about how to deal with the inability to update. Here,
the functional camp actually has the easier job, because you can just
tell people to just write code that creates new data objects and get
over with it. Performance concerns can be handwaved away by saying
that the compiler is hyper-aggressive, and "you can look at the
intermediate code if you suspect the compiler is the issue".
(Functional is a bit similar to SQL here, but the SQL optimizers are
much less competent than GHC at detecting optimization opportunities.)
 
Then you have design patterns, which have intuitive names and give
some very general guidelines that one can try after reading them (and
add his/her own personal twist). I doubt people can read the Monad
laws and make any sense out of them at the first try.
 
That's true, but much of the misconceptions around monads from the
first days have been cleared up.
But yes the monad laws are too hard to read. OTOH you won't be able to
read the Tree code in the JDK without the explanations either.
_______________________________________________
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.
 
_______________________________________________
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.

 

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: What is your favourite Haskell "aha" moment?

Paul
In reply to this post by Tony Morris-4
13.07.2018 02:40, Tony Morris wrote:
On python, we are fixing it (WIP):
https://github.com/qfpl/hpython

Did you see the recent "default mutable arguments" post?
https://lethain.com/digg-v4/

Here is a Haskell program that transforms any python program that uses
default mutable arguments:
https://github.com/qfpl/hpython/blob/master/example/FixMutableDefaultArguments.hs

Someone once said that python will never have tail call optimisation.
Here is the Haskell program that transforms any Python (direct only)
tail call into a loop:
https://github.com/qfpl/hpython/blob/master/example/OptimizeTailRecursion.hs

Two python programmers once argued over preferred indentation levels.
Let's put their disagreement into a Haskell function so that they can
stop arguing:
https://github.com/qfpl/hpython/blob/master/example/Indentation.hs

IMHO will be good to port such successful "experiments" to PyPy project in some way, if it's possible


On 07/12/2018 07:58 PM, Brett Gilio wrote:
Python is poison, indeed. ;)

Brett Gilio
[hidden email] | [hidden email]
Free Software -- Free Society!

On 07/12/2018 04:56 AM, Graham Klyne wrote:
Although I don't program regularly in Haskell these days (my poison
is Python, mainly for Web framework support), I do occasionally find
myself coding tricky manipulations in Haskell first as I find it
easier to concentrate on the essentials of an algorithm.  Once I have
the Haskell code written and tested, I generally find it fairly easy
to map the algorithm into Python (using higher order functions as
appropriate).

Here are some examples:

https://github.com/gklyne/annalist/blob/master/spike/rearrange-list/move_up.lhs

https://github.com/gklyne/annalist/blob/master/spike/tree-scan/tree_scan.lhs


And the corresponding code in the actual application:

https://github.com/gklyne/annalist/blob/4d21250a3457c72d4f6525e5a4fac40d4c0ca1c8/src/annalist_root/annalist/views/entityedit.py#L2489


https://github.com/gklyne/annalist/blob/master/src/annalist_root/annalist/models/entity.py#L245


#g
-- 


On 11/07/2018 13:10, Simon Peyton Jones via Haskell-Cafe wrote:
Friends
In a few weeks I'm giving a talk to a bunch of genomics folk at the
Sanger Institute<https://www.sanger.ac.uk/> about Haskell.   They do
lots of programming, but they aren't computer scientists.
I can tell them plenty about Haskell, but I'm ill-equipped to answer
the main question in their minds: why should I even care about
Haskell?  I'm too much of a biased witness.

So I thought I'd ask you for help.  War stories perhaps - how using
Haskell worked (or didn't) for you.  But rather than talk
generalities, I'd love to illustrate with copious examples of
beautiful code.

   *   Can you identify a few lines of Haskell that best
characterise what you think makes Haskell distinctively worth caring
about?   Something that gave you an "aha" moment, or that feeling of
joy when you truly make sense of something for the first time.
The challenge is, of course, that this audience will know no
Haskell, so muttering about Cartesian Closed Categories isn't going
to do it for them.  I need examples that I can present in 5 minutes,
without needing a long setup.
To take a very basic example, consider Quicksort using list
comprehensions, compared with its equivalent in C.  It's so short,
so obviously right, whereas doing the right thing with in-place
update in C notoriously prone to fencepost errors etc.  But it also
makes much less good use of memory, and is likely to run slower.  I
think I can do that in 5 minutes.
Another thing that I think comes over easily is the ability to
abstract: generalising sum and product to fold by abstracting out a
functional argument; generalising at the type level by polymorphism,
including polymorphism over higher-kinded type constructors.   Maybe
8 minutes.
But you will have more and better ideas, and (crucially) ideas that
are more credibly grounded in the day to day reality of writing
programs that get work done.
Pointers to your favourite blog posts would be another avenue.  (I
love the Haskell Weekly News.)
Finally, I know that some of you use Haskell specifically for
genomics work, and maybe some of your insights would be particularly
relevant for the Sanger audience.
Thank you!  Perhaps your responses on this thread (if any) may be
helpful to more than just me.
Simon



_______________________________________________
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.
_______________________________________________
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.


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Investing in languages (Was: What is your favourite Haskell "aha" moment?)

Paul
In reply to this post by Brett Gilio
13.07.2018 02:52, Brett Gilio wrote:
On 07/12/2018 06:46 AM, PY wrote:
 written in Websharper and in any Haskell framework. Haskell is beauty
but I'm afraid its fate unfortunately will be the same as one of Common Lisp, NetBSD, etc - it's ground for ideas and experiments and has disputable design. Also it's more-more difficult to teach children to Haskell than to F#...
https://jackfoxy.github.io/DependentTypes/
https://github.com/caindy/DependentTypesProvider
Discussion: https://news.ycombinator.com/item?id=15852517

Also F# has F*  ;)

I wonder if this is simply a result of the marketing of the language, itself, rather than the strength of the language. I agree, F# has a lot of beauty, but there remain many things that Haskell has a leg up on that F# lacks, like dependent types
IMHO there are several reasons:

1. Haskell limits itself to lambda-only. Example, instead to add other abstractions and to become modern MULTI-paradigm languages, it keeps lambda, so record accessors leading to names collision will lead to adding of 1,2 extensions to the language instead to add standard syntax (dot, sharp, something similar). So, point #1 is limitation in abstraction: monads, transformers, anything - is function. It's not good. There were such languages already: Forth, Joy/Cat, APL/J/K... Most of them look dead. When you try to be elegant, your product (language) died. This is not my opinion, this is only my observation. People like diversity and variety: in food, in programming languages, in relations, anywhere :)

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 :)  It's difficult to compete with product, framework, big library, but it's easy to compete with ideas. It's an observation too :-) You can find it in politics for example. Or in industry. To repeat big solution is more difficult, but we are neutrally to languages, language itself is not argument for me. 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).

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: What is your favourite Haskell "aha" moment?

Paul
In reply to this post by Joachim Durchholz
13.07.2018 09:47, Joachim Durchholz wrote:
> Am 13.07.2018 um 01:40 schrieb Tony Morris:
>> On python, we are fixing it (WIP):
>> https://github.com/qfpl/hpython
>
> Some poisonous aspects of Python are unfixable.
> E.g. having declarations as program-visible update to a global state
> causes all kinds of unnecessary pain, such as having to deal with
> half-initialized peer modules during module initialization.
>
I never understand that point. Mostly Python programs have not global
state, only global constants. You can have "application" monad in
Haskell (read), the same in Python: most Python programmers create some
Application class. Also OOP has long been solved "global state" problem,
for example, Smalltalk (similar idea you can find in Erlang): state is
hidden behind some FSM which is represented as class (process in
Erlang). You can not change state anywhere, you can only send message.
FSM guards you from any errors. Even more, FSM-style is super safe and
robust: you can visualize its behavior, to develop it very quickly, to
debug it easy, final code usually does not contain errors even...

Even I can imagine read monad with big record inside with a lot of
fields, flags, etc and to get absolutely the same spaghetti code with
flags manipulation and testing in Haskell, but under monad ;)

>> Did you see the recent "default mutable arguments" post?
>> https://lethain.com/digg-v4/
>
> Yeah, the "default parameter is an empty list but that's then going to
> be updated across invocations" classic.
> Other languages have made the same mistake. Default data needs to be
> either immutable or recreated on each call.
> Such mistakes can be mitigated, but they cannot be fixed while staying
> backwards-compatible.
>
> Python actually did an incompatible switch from 2 to 3, but for some
> reason Guido didn't fix the above two, or some other things (such as
> Python's broken idea of multiple inheritance, or the horribly
> overcomplicated way annotations work).
> Python is nice for small tasks. If you accept its invitation to extend
> it you get fragility (due to the inability to define hard constraints
> so whatever you extend will violate *somebody's* assumptions), and if
> you scale to large systems you get fragility as well (because Python
> modularization is too weak).
>


Interesting here is that there are a big enterprise products written in
Python and they are very useful:
https://www.codeinstitute.net/blog/7-popular-software-programs-written-in-python/



> Well, enough of the off-topic thing here.
>
>> On 07/12/2018 07:58 PM, Brett Gilio wrote:
>>> Python is poison, indeed. ;)
> _______________________________________________
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: What is your favourite Haskell "aha" moment?

Alex Queiroz-2
Hallo,

On 13/07/18 09:54, PY wrote:
> Application class. Also OOP has long been solved "global state" problem,
https://en.wikipedia.org/wiki/Singleton_pattern

Cheers,
--
-alex
https://unendli.ch/
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Investing in languages (Was: What is your favourite Haskell "aha" moment?)

Vanessa McHale
In reply to this post by Paul

The idea that Haskell is in the same category as Forth or APL is completely wrong and the idea that Haskell only has stack for tooling is just plain wrong. Haskell already has libraries that are superior to anything else available for certain use cases.

The idea that abstraction occurs only over functions is false. As of GHC 8.2.2, one can abstract over modules as well. Adding special syntax for record accesses would be inadvisable when principled approaches such as row polymorphism exist.

On 07/13/2018 02:38 AM, PY wrote:
13.07.2018 02:52, Brett Gilio wrote:
On 07/12/2018 06:46 AM, PY wrote:
 written in Websharper and in any Haskell framework. Haskell is beauty
but I'm afraid its fate unfortunately will be the same as one of Common Lisp, NetBSD, etc - it's ground for ideas and experiments and has disputable design. Also it's more-more difficult to teach children to Haskell than to F#...
https://jackfoxy.github.io/DependentTypes/
https://github.com/caindy/DependentTypesProvider
Discussion: https://news.ycombinator.com/item?id=15852517

Also F# has F*  ;)

I wonder if this is simply a result of the marketing of the language, itself, rather than the strength of the language. I agree, F# has a lot of beauty, but there remain many things that Haskell has a leg up on that F# lacks, like dependent types
IMHO there are several reasons:

1. Haskell limits itself to lambda-only. Example, instead to add other abstractions and to become modern MULTI-paradigm languages, it keeps lambda, so record accessors leading to names collision will lead to adding of 1,2 extensions to the language instead to add standard syntax (dot, sharp, something similar). So, point #1 is limitation in abstraction: monads, transformers, anything - is function. It's not good. There were such languages already: Forth, Joy/Cat, APL/J/K... Most of them look dead. When you try to be elegant, your product (language) died. This is not my opinion, this is only my observation. People like diversity and variety: in food, in programming languages, in relations, anywhere :)

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 :)  It's difficult to compete with product, framework, big library, but it's easy to compete with ideas. It's an observation too :-) You can find it in politics for example. Or in industry. To repeat big solution is more difficult, but we are neutrally to languages, language itself is not argument for me. 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).


_______________________________________________
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.

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Investing in languages (Was: What is your favourite Haskell "aha" moment?)

Joachim Durchholz
In reply to this post by Paul
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.
Reply | Threaded
Open this post in threaded view
|

Re: What is your favourite Haskell "aha" moment?

Joachim Durchholz
In reply to this post by Paul
Am 13.07.2018 um 09:54 schrieb PY:

> 13.07.2018 09:47, Joachim Durchholz wrote:
>> Am 13.07.2018 um 01:40 schrieb Tony Morris:
>>> On python, we are fixing it (WIP):
>>> https://github.com/qfpl/hpython
>>
>> Some poisonous aspects of Python are unfixable.
>> E.g. having declarations as program-visible update to a global state
>> causes all kinds of unnecessary pain, such as having to deal with
>> half-initialized peer modules during module initialization.
>>
> I never understand that point. Mostly Python programs have not global
> state, only global constants.

Well, try doing work on SymPy then.
I did. And I know for a fact that your idea is completely wrong; Python
has a lot of global state, first and foremost all its modules and the
data that lives inside them.

> Also OOP has long been solved "global state" problem, for example,
> Smalltalk (similar idea you can find in Erlang): state is hidden
> behind some FSM which is represented as class (process in Erlang).
No amount of TLAs will solve the issues with mutable global state.

Actually the Digg story was having mutable global state, in the form of
a default parameter. Now that's insiduous.

> You can not change state anywhere, you can only send message.
If the responses depend on the history of previous message sends, you
have mutable state back, just by another name.

> FSM guards you from any errors. Even more, FSM-style is super safe and
> robust: you can visualize its behavior, to develop it very quickly, to
> debug it easy, final code usually does not contain errors even...

This all holds only for trivial FSMs.
Once the FSM holds more than a dozen states, these advantages evaporate.

> Even I can imagine read monad with big record inside with a lot of
> fields, flags, etc and to get absolutely the same spaghetti code with
> flags manipulation and testing in Haskell, but under monad ;)

"Real programmers can write FORTRAN code in any language."
Sure.
Except that it's not idiomatic.

> Interesting here is that there are a big enterprise products written in
> Python and they are very useful:
> https://www.codeinstitute.net/blog/7-popular-software-programs-written-in-python/ 

Sure. Except they do not use some features, such as lists in default
parameters, or face the consequences (as the Digg story demonstrates).
Which means that this feature is conceptually broken. Except Python
can't fix it by mandating that default parameters need to be read-only,
which is impossible because Python has no hard-and-fast way to mark
read-only objects as such. (Read-only means: ALL function calls must
ALWAYS return the same results given equal arguments. With additional
constraints on argument behaviour vs. constness, but that's a pretty big
can of worm to define properly.)

Also, such companies use extra-lingual process to get the modularization
under control. Such as conventions, patterns, style guidelines - and woe
to the company where a programmer accidentally broke them.

Finally, that "but large software IS successfully written in unsuitable
languages" argument never held water. Entire operating systems have been
written in assembly language, and are still being written in C. Which is
a horrible misdecision from a reliability perspective, but it's being
done, and the inevitable security holes are being duct-taped to keep the
infrastructure limping along.
Which the large companies are doing, too. They just make enough money to
keep that infrastructure going. The same goes for Linux BTW, they have
enough paid^Wsponsored engineers to solve all the problems they're having.

The Haskell community does not have the luxury of excess engineers that
can hold all the ripped-up steel together with duct tape.
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Investing in languages (Was: What is yourfavourite Haskell "aha" moment?)

Paul
In reply to this post by Joachim Durchholz

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: [hidden email]
Sent: 13 июля 2018 г. 21:49
To: [hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: What is your favourite Haskell "aha" moment?

Paul
In reply to this post by Joachim Durchholz

I agreed with most of your the arguments.

 

Yes, Python has serious problem with modules locking mechanism in multi-process apps. And GIL. But it’s trade-off. And also not all Python implementations have GIL.

 

> "Real programmers can write FORTRAN code in any language."

The same with my example of read monad usage 😉 No problem to avoid manipulation of global state in a way which leads to spaghetti-code.

 

> Once the FSM holds more than a dozen states, these advantages evaporate.

This is point only where I can not agree. I used FSM with hundreds states/transitions. It was automatically generated, I only check them. Also I know that in car automatics FSM are widely used (BMW, Mercedes, Audi). Also it’s using in software for space industry widely. My IMHO is: FSM is most reliable way to do soft without bugs. Also it’s easy to verify them (for example, with transitions’ assertions)

 

From: [hidden email]
Sent: 13 июля 2018 г. 22:08
To: [hidden email]
Subject: Re: [Haskell-cafe] What is your favourite Haskell "aha" moment?

 

Am 13.07.2018 um 09:54 schrieb PY:

> 13.07.2018 09:47, Joachim Durchholz wrote:

>> Am 13.07.2018 um 01:40 schrieb Tony Morris:

>>> On python, we are fixing it (WIP):

>>> https://github.com/qfpl/hpython

>> 

>> Some poisonous aspects of Python are unfixable.

>> E.g. having declarations as program-visible update to a global state

>> causes all kinds of unnecessary pain, such as having to deal with

>> half-initialized peer modules during module initialization.

>> 

> I never understand that point. Mostly Python programs have not global

> state, only global constants.

 

Well, try doing work on SymPy then.

I did. And I know for a fact that your idea is completely wrong; Python

has a lot of global state, first and foremost all its modules and the

data that lives inside them.

 

> Also OOP has long been solved "global state" problem, for example,

> Smalltalk (similar idea you can find in Erlang): state is hidden

> behind some FSM which is represented as class (process in Erlang).

No amount of TLAs will solve the issues with mutable global state.

 

Actually the Digg story was having mutable global state, in the form of

a default parameter. Now that's insiduous.

 

> You can not change state anywhere, you can only send message.

If the responses depend on the history of previous message sends, you

have mutable state back, just by another name.

 

> FSM guards you from any errors. Even more, FSM-style is super safe and

> robust: you can visualize its behavior, to develop it very quickly, to

> debug it easy, final code usually does not contain errors even...

 

This all holds only for trivial FSMs.

Once the FSM holds more than a dozen states, these advantages evaporate.

 

> Even I can imagine read monad with big record inside with a lot of

> fields, flags, etc and to get absolutely the same spaghetti code with

> flags manipulation and testing in Haskell, but under monad ;)

 

"Real programmers can write FORTRAN code in any language."

Sure.

Except that it's not idiomatic.

 

> Interesting here is that there are a big enterprise products written in

> Python and they are very useful:

> https://www.codeinstitute.net/blog/7-popular-software-programs-written-in-python/

 

Sure. Except they do not use some features, such as lists in default

parameters, or face the consequences (as the Digg story demonstrates).

Which means that this feature is conceptually broken. Except Python

can't fix it by mandating that default parameters need to be read-only,

which is impossible because Python has no hard-and-fast way to mark

read-only objects as such. (Read-only means: ALL function calls must

ALWAYS return the same results given equal arguments. With additional

constraints on argument behaviour vs. constness, but that's a pretty big

can of worm to define properly.)

 

Also, such companies use extra-lingual process to get the modularization

under control. Such as conventions, patterns, style guidelines - and woe

to the company where a programmer accidentally broke them.

 

Finally, that "but large software IS successfully written in unsuitable

languages" argument never held water. Entire operating systems have been

written in assembly language, and are still being written in C. Which is

a horrible misdecision from a reliability perspective, but it's being

done, and the inevitable security holes are being duct-taped to keep the

infrastructure limping along.

Which the large companies are doing, too. They just make enough money to

keep that infrastructure going. The same goes for Linux BTW, they have

enough paid^Wsponsored engineers to solve all the problems they're having.

 

The Haskell community does not have the luxury of excess engineers that

can hold all the ripped-up steel together with duct tape.

_______________________________________________

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.
Reply | Threaded
Open this post in threaded view
|

Re: What is your favourite Haskell "aha" moment?

Fabien R
In reply to this post by Haskell - Haskell-Cafe mailing list
Definitely after reading the book "category theory for programmers" by Bartosz Milewski.
The next step is to get a link from algorithms to category theory to get:
 algorithms -> category theory -> haskell

--
Fabien
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: What is your favourite Haskell "aha" moment?

Takenobu Tani
In reply to this post by Haskell - Haskell-Cafe mailing list
Hi simon,

I feel a lot of aha in Haskell.
However, the most basic characterise I think are the following.

  * Algebraic data type (*Extremely wonderful*)
  * Pattern matches
  * Higher-order function
  * Partial application
  * Polymorphic type
  * Recursion and Lazy pattern


I show its features in the code below.

Simple code example 1:

    ```Haskell
    -- Algebraic data type
    data DNA = A | C | G | T
               deriving Show
   
    -- Using algebraic data type with list
    dna1 :: [DNA]
    dna1 = [A,A,T,C,C,G,C,T,A,G]
   
    -- Pattern matches
    abbrev :: DNA -> String
    abbrev A = "adenine"
    abbrev C = "cytosine"
    abbrev G = "guanine"
    abbrev T = "thymine"
   
    -- Higher-order function and Partial application
    abbrevDNAs = map abbrev

    -- Interactive example
    {-
    ghci> abbrevDNAs [A,A,C,G,A,T]
    ["adenine","adenine","cytosine","guanine","adenine","thymine"]
    -}
    ```


Simple code example 2:

    ```Haskell
    -- Algebraic data type
    data RNA = A | C | G | U
               deriving Show
   
    data Amino = Ala | Arg | Asn | Asp | Cys | Gln | Glu |
                 Gly | His | Ile | Leu | Lys | Met | Phe |
                 Pro | Ser | Thr | Trp | Tyr | Val | Error
                 deriving Show
   
    -- Pattern matches
    rna2amino :: [RNA] -> Amino
    rna2amino [A,A,A] = Lys
    rna2amino [A,A,G] = Lys
    rna2amino [G,A,A] = Glu
    rna2amino [A,U,G] = Met
    rna2amino [C,A,U] = His
    rna2amino _       = Error
   
    -- Higher-order function
    convert :: [RNA] -> [Amino]
    convert xss = map rna2amino $ splitN 3 xss
   
    -- Polymorphic type, Recursion and Lazy pattern
    splitN :: Int -> [a] -> [[a]]
    splitN _ [] = []
    splitN n xs = let (as,bs) = splitAt n xs
                  in as : splitN n bs

    -- Interactive example    
    {-
    ghci> convert [A,A,A,G,A,A,A,U,G,C,A,U]
    [Lys,Glu,Met,His]
    -}
    ```

Of course, I am not familiar with genom :)

Regards,
Takenobu



2018-07-11 21:10 GMT+09:00 Simon Peyton Jones via Haskell-Cafe <[hidden email]>:

Friends

In a few weeks I’m giving a talk to a bunch of genomics folk at the Sanger Institute about Haskell.   They do lots of programming, but they aren’t computer scientists.

I can tell them plenty about Haskell, but I’m ill-equipped to answer the main question in their minds: why should I even care about Haskell?  I’m too much of a biased witness.

So I thought I’d ask you for help.  War stories perhaps – how using Haskell worked (or didn’t) for you.  But rather than talk generalities, I’d love to illustrate with copious examples of beautiful code.

  • Can you identify a few lines of Haskell that best characterise what you think makes Haskell distinctively worth caring about?   Something that gave you an “aha” moment, or that feeling of joy when you truly make sense of something for the first time.

The challenge is, of course, that this audience will know no Haskell, so muttering about Cartesian Closed Categories isn’t going to do it for them.  I need examples that I can present in 5 minutes, without needing a long setup.

To take a very basic example, consider Quicksort using list comprehensions, compared with its equivalent in C.  It’s so short, so obviously right, whereas doing the right thing with in-place update in C notoriously prone to fencepost errors etc.  But it also makes much less good use of memory, and is likely to run slower.  I think I can do that in 5 minutes.

Another thing that I think comes over easily is the ability to abstract: generalising sum and product to fold by abstracting out a functional argument; generalising at the type level by polymorphism, including polymorphism over higher-kinded type constructors.   Maybe 8 minutes.

But you will have more and better ideas, and (crucially) ideas that are more credibly grounded in the day to day reality of writing programs that get work done.

Pointers to your favourite blog posts would be another avenue.  (I love the Haskell Weekly News.)

Finally, I know that some of you use Haskell specifically for genomics work, and maybe some of your insights would be particularly relevant for the Sanger audience.

Thank you!  Perhaps your responses on this thread (if any) may be helpful to more than just me.

Simon


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Investing in languages (Was: What is yourfavourite Haskell "aha" moment?)

Alexey Raga
In reply to this post by Paul
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.

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)

  • 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 <[hidden email]> 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: [hidden email]
Sent: 13 июля 2018 г. 21:49
To: [hidden email]
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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Investing in languages (Was: What is yourfavouriteHaskell "aha" moment?)

Paul

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 <[hidden email]> 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: [hidden email]
Sent: 13 июля 2018 г. 21:49
To: [hidden email]
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.

 


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Investing in languages (Was: What is yourfavouriteHaskell "aha" moment?)

Brandon Allbery
On Sat, Jul 14, 2018 at 11:28 AM Paul <[hidden email]> wrote:

Better IMHO to have less infrastructure code. Better is to hide all “machinery” in compiler.


Hiding all "machinery" in the compiler leads to perl 5, PL/1, and similar monoliths. Which, if they do manage to catch on, eventually get discarded because the "compiler" can't keep up with the rest of the world without becoming a completely different language… which will move everything into the ecosystem so it can keep up.

Monoliths have one advantage: people can ignore all the stuff going inside the monolith, and therefore think they're easier to work with. Until they no longer do what those people need, and they get tossed on the trash heap, never to be seen again. The languages that stick around, that are still used, are the ones that are extensible instead of being monoliths.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Investing in languages

Jerzy Karczmarczuk
In reply to this post by Paul
Le 14/07/2018 à 17:28, Paul ["aquagnu"]a écrit :
By the way, Haskell role was to kill SML community, sure it is sad to acknowledge it, but it’s 100% true...

Could you please cite some serious source supporting this claim?
===
And IMHO there was some lazy dialect of ML (may be, I’m not right).

LML of Lennart Augustsson and Thomas Johnsson, 1984 ("LISP and Functional Programming"). It came before Miranda (1985)...
If you are not certain, read something, please...

Smalltalk was good language (mostly dead, except Pharo, which looks cool).
Well, Squeak is alive, its "children": Scratch, Snap, etc, as well. Pharo is a fork of Squeak as well.
The European Smalltalk User Group organizes in September quite a big conference in Cagliari.
It seems that you are exaggerating a bit, killing all the languages you have heard [a little...] about...

Jerzy Karczmarczuk
/Caen, France/


Garanti sans virus. www.avast.com

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Investing in languages (Was: What is yourfavouriteHaskell "aha" moment?)

Alexey Raga
In reply to this post by Paul
> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Sent: 13 июля 2018 г. 21:49
To: [hidden email]
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.

 


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Investing in languages (Was: What is yourfavouriteHaskell "aha" moment?)

Brett Gilio

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

I usually do not send "I agree" messages.

But, I without reservation agree.

--
Brett M. Gilio
Free Software Foundation, Member
https://parabola.nu | https://emacs.org
_______________________________________________
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.
123456