<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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
(<a class="moz-txt-link-freetext" href="https://github.com/dotnet/csharplang/blob/master/proposals/patterns.md#arithmetic-simplification">https://github.com/dotnet/csharplang/blob/master/proposals/patterns.md#arithmetic-simplification</a>
-- 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#...<br>
</p>
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).<br>
<br>
<div class="moz-cite-prefix">12.07.2018 13:28, Vanessa McHale wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4a921b10-8221-6d59-962d-f9bf01c507e6@iohk.io">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap=""> 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? <a class="moz-txt-link-freetext" href="https://qfpl.io/posts/2018-canberra-intro-to-fp/">https://qfpl.io/posts/2018-canberra-intro-to-fp/</a>
On 07/12/2018 04:23 PM, Joachim Durchholz wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Am 11.07.2018 um 16:36 schrieb Damian Nadales:
</pre>
<blockquote type="cite">
<pre wrap="">
I speak only from my own narrow perspective. I'd say programming is
hard, but functional programming is harder.
</pre>
</blockquote>
<pre wrap="">
Actually it's pretty much the opposite, I hear from teachers.
</pre>
<blockquote type="cite">
<pre wrap="">Maybe that's why Java replaced Haskell in some universities
curricula
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap=""><a class="moz-txt-link-freetext" href="https://chrisdone.com/posts/dijkstra-haskell-java">https://chrisdone.com/posts/dijkstra-haskell-java</a>. For some reason
most programmers I know are not scared of learning OO, but they fear
functional programming.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""> I think the reason might be that OO concepts
</pre>
<blockquote type="cite">
<pre wrap="">like inheritance and passing messages between objects are a bit more
concrete and easier to grasp (when you present toy examples at least).
</pre>
</blockquote>
<pre wrap="">
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.)
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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:
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a>
Only members subscribed via the mailman list are allowed to post.
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a>
Only members subscribed via the mailman list are allowed to post.
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a>
Only members subscribed via the mailman list are allowed to post.
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a>
Only members subscribed via the mailman list are allowed to post.</pre>
</blockquote>
<br>
</body>
</html>