<div dir="ltr">When you get a deep run-time type incompatibility with a difficult to debug case, the Gothic Church that you talked about may change it's direction and function and chase after you at a very inappropriate midnight. :)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 11 Mar 2019 at 15:43, Damien Mattei <<a href="mailto:damien.mattei@gmail.com">damien.mattei@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-size:large">when i was talking about functional programming, i was thinking to Scheme not Haskell, when you use scheme there is no strong typing, no typing at all in almost cases... when you use map it's map, no need to ask yourself if it is mapM or Prelude.map or anything else.... there is no gothic cathedral only old strong roman church style ;-)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 11, 2019 at 11:55 AM PY <<a href="mailto:aquagnu@gmail.com" target="_blank">aquagnu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">11.03.2019 09:51, Damien Mattei wrote:<br>
 > a method of a class you always have to instantiate an object...<br>
<br>
not always, static methods do not need this.<br>
<br>
 > so after another people reading your code will say,  "hey what's all <br>
this mess?" , and you're code will be hard to read , and even for you <br>
when making big program you will have tons of classes, inheritance and <br>
will move in a maze of classes!!! a nightmare.... sometimes, i <br>
experienced it! at the opposite functional programming is so easy, so <br>
clear for your mind.<br>
<br>
Absolutely no matter what you slice the code: functions in modules or <br>
methods in classes. In Haskell we also have a lot of functions, modules, <br>
types, etc. But the cause of the complexity is not linked directly to <br>
the number of entities (and in most cases it's not): programming in <br>
Smalltalk/Java/VB/Python/etc is simple and fast and increasing of the <br>
number of used classes and methods does not need more specific knowledge <br>
of the language and can be done by newbie who already knows the syntax, <br>
as you said it before - it's enough to instantiate the object and to <br>
call some its method! By the way, Smalltalk, as I know, even has not DI <br>
- I suppose due to image :)<br>
<br>
And this is false for Haskell: it's not enough to know language syntax <br>
(it's relatively simple): each library can involve own level of <br>
abstraction, own eDSLs, etc. And if somebody built his library on <br>
arrows, pipes, free monads, etc - it's not enough to know language's <br>
syntax only. Imagine a big house built with simple and same bricks. And <br>
some Baroque theater where anything is complex and unique.<br>
<br>
So, languages like Haskell are more complex and need more time to learn <br>
and create valuable applications.<br>
</blockquote></div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>