[Haskell-cafe] Why Haskell is beautiful to the novice
Olaf Klinke
please correct me if questions like this should not go via this mailing list.
Presumably everyone on this list agrees that Haskell stands out as a beautiful and pleasant language to have. The recent nitpicking and real-world problems like cabal hell don't change that. However, statements supporting Haskell's beauty usually involve: "In Haskell it is so much clearer/easier/faster to ... than in another language." That is, the beauty of Haskell presents itself to those who can compare it to other imperative or not strongly typed languages that one learned before Haskell.
My question is, for what reason should anyone not acquainted with any programming language find Haskell beautiful? Maybe it does not look beautiful at all to the novice. The novice can not draw on the comparison, unless he takes the effort to learn more than one language in parallel. The novice likely also does not have the mathematical background to see the beautiful correspondence between the language and its semantics. (My reason to love FP is because it is executable domain theory.) One might argue that it is not the language itself that is beautiful, but rather the concepts (data structures, algorithms, recursion) and Haskell does a great job to preserve their beauty into the implementation. Do you agree?
Disclaimer: I am about to start teaching a first course in computer science in secondary school. I can teach whatever I want, since this is the first CS course the school ever had. I want to teach beautiful things. I love functional programming. I need not start teaching programming right away. But I am reluctant to expose the pupils to something whose beauty escapes them completely.
-- Olaf
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Elliot Cameron
________________________________________
From: Haskell-Cafe <haskell-ca...@haskell.org> on behalf of Olaf Klinke <o...@aatal-apotheke.de>
Sent: Thursday, August 27, 2015 5:08 PM
To: haskel...@haskell.org
Subject: [Haskell-cafe] Why Haskell is beautiful to the novice
Alberto G. Corona
Alberto G. Corona
Nicola Gigante
In my opinion, the first CS course in school (and to some extent
the math and physics courses as well) should aim, more than teaching specific
skills or knowledge, to transmit to student the beauty of programming _itself_
(respectively math and physics).
The student should be able to perceive the feelings of wonder and enlightenment
that rise from solving a challenging problem, or to understand some
previously obscure phenomenon, by applying math and reasoning.
This objective is well suited for a CS course because students can also
be initially motivated by the promise of learning something really useful.
Haskell is particularly well suited for this task, not because the student would
necessarily be able to perceive the beauty of Haskell itself, but because
Haskell does not obscure, and in some ways enhance, the beauty of
programming as a whole. In contrast, when first CS courses start with
convoluted or low level languages such as C or Java, students loose
the point of everything, overwhelmed by pointers, useless OOP,
obscure syntax, low-level technical details. Wonder and enlightenment
become pain and frustration.
Btw, if you want to _also_ teach computer architecture in addition to
programming, I think that is best suited to a different part of the course
and does not need to be interleaved with learning programming, so
I wouldn’t bother with C and the like. Or better, you can explain C
as a tool to better understand computers and operating systems, but
after they’ve learnt how to program, not as a tool to learn programming.
Using Haskell (specifically some kind of concepts, e.g. equational reasoning)
will also make easier for students to see the connection between math
and programming, making them more motivated to learn math as well.
To me, your choice to start the CS course by teaching Haskell is
a wonderful choice and your students will thank you in a few years.
Go ahead!
> — Olaf
Greetings,
Nicola
Romain Gehrig
Nicola Gigante
> Il giorno 28/ago/2015, alle ore 15:37, Torsten Otto <torste...@hamburg.de> ha scritto:
>
> What an interesting topic to discuss!
>
>> Am 28.08.2015 um 12:12 schrieb Nicola Gigante <nicola....@gmail.com>:
>>
>> Using Haskell (specifically some kind of concepts, e.g. equational reasoning)
>> will also make easier for students to see the connection between math
>> and programming, making them more motivated to learn math as well.
>
>
It depends on the age of the students and the math they already know.
I don’t have specific examples of in-class exercises or things like that.
However, the point is that writing Haskell code you can
often come up with shorter or more elegant solutions by
manipulating terms exactly as done in elementary algebra.
Starting from a 10lines function and coming up with
a simple and readable oneliner is fun and rewarding,
and shows one of the possible connections to math,
especially if you can make them reason about types,
in which case the task becomes very similar to theorem
proving than to algebraic manipulations alone.
Another possible connection arise when you teach things
such as the Monoid typeclass.
Even if students have not been exposed to abstract
mathematics, they can still appreciate the usefulness of
abstracting similar operations (addition in this case) to
being able to uniformly reason about apparently different
concepts. Abstraction is the core of mathematics, but is
also a fundamental concept in programming, of course,
so you’re implicitly teaching two things at once.
> Regards,
> Torsten
Silvio Frischknecht
In my opinion, Haskell is a terrible first language to learn.
It has a very complicated type-system, and it's restriction to purely
functional programming does not convey very well how (current) computers
work. Current computers work by you giving them an step by step guide
what to do. This I think is what should be at the base of any
beginners-programming course.
There are also a lot of very basic data structures that can simply not
be used in purely functional code like hash tables, pipes or random
access arrays.
Haskell also requires quite a bit of intelligence and perseverance to
master. So unless your kids are all geniuses I would not recommend it.
Python would by my language of choice. You won't have to worry about low
level stuff or typing, but can still write those step by step programs.
Cheers
Silvio
Rustom Mody
Haskell is a nice – but not necessarily the only – vehicle for these.
Nicola Gigante
> Il giorno 28/ago/2015, alle ore 17:45, Silvio Frischknecht <silvio....@gmail.com> ha scritto:
>
> Hi,
>
> In my opinion, Haskell is a terrible first language to learn.
>
> It has a very complicated type-system, and it's restriction to purely
> functional programming does not convey very well how (current) computers
> work. Current computers work by you giving them an step by step guide
> what to do. This I think is what should be at the base of any
> beginners-programming course.
>
I kindly disagree. If the focus is to teach computer architecture, you are
not teaching programming. If the focus is on programming, then it should
focus on the conceptual aspects of programming, not on computers.
A course at school should of course teach both, but in my opinion not
concurrently. There’s no point in teaching something implicitly by using
the teaching of something else.
We are not talking about undergraduates here, but kids or teenagers.
Think about which is the reason why you are teaching something to them.
It is not to teach some specific skill or to make them be advantaged in
future undergraduate courses. It is to teach them to reason.
Functional programming is just more reasoning than technicalities.
That’s also why I don’t agree with the math curriculum in high-school
(only elementary algebra, trigonometry and basic calculus, at least here in Italy).
If a student doesn’t go to college or studies something non-scientific
(or even some low-math science), he’ll never see an abstract
mathematical concept (see e.g. groups) in all his lives, thus living
forever by completely ignoring what math is all about.
(and this is really connected with the record-low public trust in science
that we are suffering).
My reasoning applies to any functional language, not just Haskell.
If you don’t want to worry with the type system, you can turn to
Common Lisp or Racket. I started with scheme and it was indeed pretty
amazing.
> There are also a lot of very basic data structures that can simply not
> be used in purely functional code like hash tables, pipes or random
> access arrays.
Why do you think that manipulating arrays is a better skill to teach
to kids than manipulating linked lists?
>
> Haskell also requires quite a bit of intelligence and perseverance to
> master. So unless your kids are all geniuses I would not recommend it.
>
There was a nice article on reddit of a parent that was in progress of teaching
Haskell to his/her 10-years old, and it was a great experience. I cannot find it anymore.
Remember, kids (motivated kids, at least) are way smarter than what school
usually seems to think.
> Python would by my language of choice. You won't have to worry about low
> level stuff or typing, but can still write those step by step programs.
>
Python would be also my first choice if I had to choose an imperative language,
that’s granted.
> Cheers
>
> Silvio
Cheers,
Nicola
Mike Meyer
Hi,
In my opinion, Haskell is a terrible first language to learn.
It has a very complicated type-system, and it's restriction to purely
functional programming does not convey very well how (current) computers
work. Current computers work by you giving them an step by step guide
what to do. This I think is what should be at the base of any
beginners-programming course.
Python would by my language of choice. You won't have to worry about low
level stuff or typing, but can still write those step by step programs.
Will Yager
> On Aug 28, 2015, at 10:45, Silvio Frischknecht <silvio....@gmail.com> wrote:
>
> Hi,
> In my opinion, Haskell is a terrible first language to learn.
>
Mike Meyer
That’s also why I don’t agree with the math curriculum in high-school
(only elementary algebra, trigonometry and basic calculus, at least here in Italy).
If a student doesn’t go to college or studies something non-scientific
(or even some low-math science), he’ll never see an abstract
mathematical concept (see e.g. groups) in all his lives, thus living
forever by completely ignoring what math is all about.
(and this is really connected with the record-low public trust in science
that we are suffering).
Silvio Frischknecht
This being a haskell mailing list, I expected that :)
> If the focus is to teach computer architecture, you are
> not teaching programming. If the focus is on programming, then it should
> focus on the conceptual aspects of programming, not on computers.
> A course at school should of course teach both, but in my opinion not
> concurrently. There’s no point in teaching something implicitly by using
> the teaching of something else.
It's more about algorithms than computer architecture. An imperative
program very clearly describes algorithms; Haskell does not. Unless you
have a very good understanding of things like lazyness, non-strictness
and tail recursion, you wont know what happens when and how.
> We are not talking about undergraduates here, but kids or teenagers.
> Think about which is the reason why you are teaching something to them.
> It is not to teach some specific skill or to make them be advantaged in
> future undergraduate courses. It is to teach them to reason.
> Functional programming is just more reasoning than technicalities.
All the more reason not to teach Haskell. To CS undergraduates you might
teach your favorite programming paradigm. They can take it, and they
will also learn others anyway. To teenagers who might never learn
another language, it is not a good idea.
>> There are also a lot of very basic data structures that can simply not
>> be used in purely functional code like hash tables, pipes or random
>> access arrays.
>
> Why do you think that manipulating arrays is a better skill to teach
> to kids than manipulating linked lists?
What about double linked lists then. Most updatable data structures are
just clumsy in Haskell.
> There was a nice article on reddit of a parent that was in progress of teaching
> Haskell to his/her 10-years old, and it was a great experience. I cannot find it anymore.
> Remember, kids (motivated kids, at least) are way smarter than what school
> usually seems to think.
Some kids are smarter, some less so. In secondary school you should have
a curriculum that most students can follow.
Cheers
Silvio
Donn Cave
...
> operation, so if you're going to drop Haskell for not having one, you
> should also drop Python for not having the other.
a rationalization, for the basic proposition that Python is easier to
deal with. Which may be true, but that wasn't the question.
I've never used Smalltalk, but assuming that its virtues had something
to do with the large number of subsequent OOP languages, that might
be one to look at.
I think it's fair to say that Haskell is an exceptionally interesting
language, for those who are interested in such things. I wouldn't bet
my life that a novice would see anything beautiful about it.
Historically, many of the guys I worked with, I guess including myself,
were attracted to assembly language for reasons that were in no way
practical. It's terrible for productivity and even worse for maintenance,
but we looked forward to the chance to write a few lines of it now and then.
I'm not proposing an assembly language course, maybe just trying to shed
some light on the distinction between a "good" (practical) programming
choice and an esthetic choice.
Donn
Francesco Ariis
> Python would by my language of choice. You won't have to worry about low
> level stuff or typing, but can still write those step by step programs.
be much time available.
I love Haskell, but let's compare the time/effort to program a simple
game in Python/Lua and in Haskell and you'll see it just makes more sense
in this situation.
Rustom Mody
> I kindly disagree.
This being a haskell mailing list, I expected that :)
> If the focus is to teach computer architecture, you are
> not teaching programming. If the focus is on programming, then it should
> focus on the conceptual aspects of programming, not on computers.
> A course at school should of course teach both, but in my opinion not
> concurrently. There’s no point in teaching something implicitly by using
> the teaching of something else.
It's more about algorithms than computer architecture. An imperative
program very clearly describes algorithms; Haskell does not. Unless you
have a very good understanding of things like lazyness, non-strictness
and tail recursion, you wont know what happens when and how.
«It is easier to optimize correct code than to correct optimized code.»
--Bill Harlan
«everyone knows that algorithms as welearned them at school are irrelevant to practice. »
http://www.cs.cmu.edu/~rwh/papers/secp/secp.pdf
> We are not talking about undergraduates here, but kids or teenagers.
> Think about which is the reason why you are teaching something to them.
> It is not to teach some specific skill or to make them be advantaged in
> future undergraduate courses. It is to teach them to reason.
> Functional programming is just more reasoning than technicalities.
All the more reason not to teach Haskell. To CS undergraduates you might
teach your favorite programming paradigm. They can take it, and they
will also learn others anyway. To teenagers who might never learn
another language, it is not a good idea.
>> There are also a lot of very basic data structures that can simply not
>> be used in purely functional code like hash tables, pipes or random
>> access arrays.
>
> Why do you think that manipulating arrays is a better skill to teach
> to kids than manipulating linked lists?
What about double linked lists then. Most updatable data structures are
just clumsy in Haskell.
From my pov getting Hindley-Milner intuitions right should take primacy over updatable data structures.
> There was a nice article on reddit of a parent that was in progress of teaching
> Haskell to his/her 10-years old, and it was a great experience. I cannot find it anymore.
> Remember, kids (motivated kids, at least) are way smarter than what school
> usually seems to think.
Some kids are smarter, some less so. In secondary school you should have
a curriculum that most students can follow.
Christopher Allen
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Tikhon Jelvis
Personally, I would try to start with something with immediate feedback. Introduce functions on numbers with the REPL, something they are presumably familiar with. Then go on to show how we can use and manipulate things other than numbers in exactly the same way.
A fun place to go quickly is the diagrams package. Just like we can have functions and operations with numbers, we can have them with shapes. Hook it up to something like IHaskell so that students can render shapes in the REPL just like they did with numbers. It'll take some setup: IHaskell is a pain to install and you might want to create your own wrapper around diagrams to have simpler types.
But I think it would be worth it: you'll get an intuitive example of functions producing more complex outputs with immediate feedback in the form of pictures, made up by putting shapes together. The students will be able to produce designs that look cool by experimenting with the library while getting the hang of Haskell.
Alberto G. Corona
The destruction of pedagogy and innovation by Rationalism:
http://nocorrecto.blogspot.com.es/2014/05/the-destruction-of-pedagogy-and.html
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Kosyrev Serge
> I love Haskell, but let's compare the time/effort to program a simple
> game in Python/Lua and in Haskell and you'll see it just makes more sense
> in this situation.
Now, how is this different from a comparison of the amount of effort
spent on the relevant libraries?
..where the difference is still enormous, like multiple orders of magnitude.
--
с уважениeм / respectfully,
Косырев Серёга
--
“And those who were seen dancing were thought to be insane
by those who could not hear the music.”
– Friedrich Wilhelm Nietzsche
Francesco Ariis
> Now, how is this different from a comparison of the amount of effort
> spent on the relevant libraries?
>
> ..where the difference is still enormous, like multiple orders of magnitude.
I must say the suggestion to use `diagrams` (made by Tikhon Jelvis)
makes really sense: it's fun, it's easy/quick to set up, it's powerful.
[1] http://gaspull.geeksaresexytech.netdna-cdn.com/wp-content/uploads/2011/02/essays.png
Alberto G. Corona
Mike Meyer
On Sat, Aug 29, 2015 at 12:26:04AM +0300, Kosyrev Serge wrote:
> Now, how is this different from a comparison of the amount of effort
> spent on the relevant libraries?
>
> ..where the difference is still enormous, like multiple orders of magnitude.
That's exactly the point (amusingly illustrated in this comic [1]).
I must say the suggestion to use `diagrams` (made by Tikhon Jelvis)
makes really sense: it's fun, it's easy/quick to set up, it's powerful.
Donn Cave
> I think that Haskell has a lot of accidental complexity in many areas.
> There is a kind of pseudo-mathematical cargo cult that make some problems
> artificially difficult.
Donn
Alberto G. Corona
Rustom Mody
https://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budget%20Council%20concerning%20Haskell.pdf
Thanks for that Will
M Farkas-Dyck
> It has a very complicated type-system, and it's restriction to purely
> functional programming does not convey very well how (current) computers
> work. Current computers work by you giving them an step by step guide
> what to do. This I think is what should be at the base of any
> beginners-programming course.
Actually we ought to start with semiconductor physics, VLSI
fabrication, and such.
cuz that's how current computers work.
> There are also a lot of very basic data structures that can simply not
> be used in purely functional code like hash tables, pipes or random
> access arrays.
> Haskell also requires quite a bit of intelligence
> and perseverance to
> master.
Unlike imperative languages, which require no perseverance to master, yeah?
> Python would by my language of choice. You won't have to worry about low
> level stuff or typing, but can still write those step by step programs.
function what wants a gizmo and have it cheerfully barf some cryptic
exception and stack trace at one, what fun!
Oh, by the way, Python isn't how computers work either.
On 28/08/2015, Mike Meyer <m...@mired.org> wrote:
> Python is a good language if you want an imperative language
Python, while Haskell mostly performs better, is less verbose, and
catches type errors. Worse yet, I see counsel to learn it as a first
language.
On 28/08/2015, Silvio Frischknecht <silvio....@gmail.com> wrote:
> Some kids are smarter, some less so. In secondary school you should have
> a curriculum that most students can follow.
someone needs extra help, they ought to get it, but not while boring
others partly to death like they do in Ontario at least.
Ideally each student would have their own program, but that's
practically difficult, so some stratification may be needed, but not
teaching the more stimulating at all lest some slower folks need to
work harder is toxic.
[0] https://hackage.haskell.org/package/hashtables
[1] https://hackage.haskell.org/package/array
Mike Meyer
On Fri, Aug 28, 2015, 23:17 M Farkas-Dyck <stra...@gmail.com> wrote:
> Python is a good language if you want an imperative language
Python is a good language if you want pain.
Probably better to use the more exact language in the original.
M Farkas-Dyck
Donn Cave
> ... I see much praise of
> catches type errors. Worse yet, I see counsel to learn it as a first
> language.
It is kind of embarrassing when Haskell enthusiasts see Python as a
better language for beginners. But in either case I think we'd expect
only a fairly superficial treatment of the language, right? I mean,
for example, back in the day, one of my colleagues picked up Python
for random minor utilitarian purposes, and when I talked to him he
hadn't used classes for anything, so for him it was only incidentally
OOP inasmuch as some of the built in functions were addressed as object
member functions. A beginning student doesn't need to learn OOP in
any kind of depth. He or she would need to learn about the IO monad,
but maybe not monads in general. I suppose that might somewhat limit
one's potential appreciation of Haskell's beauty, if we're still
talking about that.
Donn
Mike Meyer
On Sat, Aug 29, 2015, 00:57 M Farkas-Dyck <stra...@gmail.com> wrote:
On 28/08/2015, Mike Meyer <m...@mired.org> wrote:
> Probably better to use the more exact language in the original.What more exact language?
"Imperative language" instead of "pain".
M Farkas-Dyck
> "Imperative language" instead of "pain".
It's no more exact. I'm not disputing whether Python is an imperative
language; I'm rather disputing whether it's good ☺
On 28/08/2015, Mike Meyer <m...@mired.org> wrote:
> I have to disagree, and for much the same reason that Nicola does: these
> details matter if you're teaching computer architecture, but not if you are
> teaching programming. At least, not in an introductory course.
Here I fully agree.
If one is teaching computer architecture, assembly is uniquely appropriate.
If one is teaching programming, Haskell is non-uniquely appropriate,
but I would not consider Python appropiate.
Haskell is a better imperative programming language than Python. It
has mutable state where needed, in the ST monad.
Beautiful is better than ugly.
Explicit is better than implicit.
Haskell is better than Python.
Mike Meyer
On Sat, Aug 29, 2015, 01:50 M Farkas-Dyck <stra...@gmail.com> wrote:
Haskell is a better imperative programming language than Python.
Except that teaching beginners to write imperative code in Haskell is doing both them and Haskell a grave disservice. If you're going to do that, you ought to pick a language that was designed for it.
Alexey Muranov
Alexey.
Nicola Gigante
Il giorno 28/ago/2015, alle ore 22:17, Alberto G. Corona <agoc...@gmail.com> ha scritto:Exactly Mike,
The destruction of pedagogy and innovation by Rationalism:
http://nocorrecto.blogspot.com.es/2014/05/the-destruction-of-pedagogy-and.html
Alberto G. Corona
Benno Fünfstück
In my opinion, the focus on beauty of the language is simply inappropriate for a teaching language. An experienced programmer or mathematician might enjoy transforming a ten line function into a simple one with only one line, but I think for many students, it won't be so interesting to transform one working program into a nicer one. Not all people see simplicity of math as a beautiful thing, for them a simpler formula is not much more interesting than an equal more complicated one. I believe that you need some experience to appreciate simplicity and elegance.
Just my two cents,
Benno
Alexey Muranov
Tobias Dammers
> IMO, what attracts a big part of kids to programming is the possibility to
> program side effects.
largely a choice the designers of their language have made for them.
> It seems to me that Haskell takes a big care to "seal off" the side
> effects and does it in a nontrivial way. This may complicate
> introduction to programming.
loopholes like unsafePerformIO). Making effects explicit complicates
some things and simplifies others.
> Telling the kids to "just use the IO monad and don't worry want a
> 'monad' is, it is just a magic word, it comes from Category Theory,
> don't try to understand, just follow me" might not be a good way to
> teach.
effects are orthogonal concerns. What we should teach people is that:
- IO is the type we use to describe real-world actions
- IO actions can be combines to construct complex effectful programs
from simple building blocks
- Many of the ways in which we can combine IO actions follow the Monad
pattern, just like we can combine Strings in ways that follow the
Monoid pattern.
- You don't need to fully grasp the Monad pattern in order to use it
with IO; just get used to how monad operations work for IO and go from
there. The more general intuitions will follow in due time.
> I've seen assembly language mentioned here, and what attracted me to it,
> when i was a kid, was the possibility to program "side effects" explicitly.
> Even if i could not observe those side effects, like change of a register
> value, directly, they could be tested indirectly.
and thus suitable for a learning trajectory that roughly follows the way
programming language design has unraveled over the past 60 years or so.
Assembly language is, in fact, an abstraction already: by mapping
mnemoics to machine instructions, we make them more palatable for
humans. The observation that instead of looking up the bit patterns for
machine instructions in a printed manual ourselves, we could have the
computer do it for us, is what I consider the spark that bootstrapped
the entire field of programming language design.
That doesn't mean, however, that this is the only possible trajectory -
it's a thorough one, and a very suitable one for people like me who want
to understand it all before moving to the next level of abstraction, but
most people, I realize, aren't like me.
>
> Alexey.
>
> On Saturday, August 29, 2015 at 8:10:58 AM UTC+2, Donn Cave wrote:
> >
> > > ... I see much praise of
> > > Python, while Haskell mostly performs better, is less verbose, and
> > > catches type errors. Worse yet, I see counsel to learn it as a first
> > > language.
> >
> > Sure - "Programming for Everybody" is practically a Python trademark!
> >
> > It is kind of embarrassing when Haskell enthusiasts see Python as a
> > better language for beginners. But in either case I think we'd expect
> > only a fairly superficial treatment of the language, right? I mean,
> > for example, back in the day, one of my colleagues picked up Python
> > for random minor utilitarian purposes, and when I talked to him he
> > hadn't used classes for anything, so for him it was only incidentally
> > OOP inasmuch as some of the built in functions were addressed as object
> > member functions. A beginning student doesn't need to learn OOP in
> > any kind of depth. He or she would need to learn about the IO monad,
> > but maybe not monads in general. I suppose that might somewhat limit
> > one's potential appreciation of Haskell's beauty, if we're still
> > talking about that.
> >
> > Donn
> > _______________________________________________
> > Haskell-Cafe mailing list
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskel...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Tobias Dammers - tdam...@gmail.com
Kosyrev Serge
> On Sat, Aug 29, 2015 at 01:41:52AM -0700, Alexey Muranov wrote:
>> IMO, what attracts a big part of kids to programming is the possibility to
>> program side effects.
>
> What attracts them are the effects. Implementing them as side effects is
> largely a choice the designers of their language have made for them.
How very nicely put! Alexey's statement had bugged me quite the same,
and your formulation is just about exactly what I would have said.
--
с уважениeм / respectfully,
Косырев Серёга
Donn Cave
[... re assembly language]
> it's a thorough one, and a very suitable one for people like me who want
> to understand it all before moving to the next level of abstraction, but
> most people, I realize, aren't like me.
assembly language interesting. Believe me, we truly wanted to write
programs in assembly language.
If we're out walking in the woods, and I jump up on a fallen log, do
you think I must have done this because I want to strengthen my thighs
and buttocks? At some primal unconscious level, perhaps that really
is part of the motivation for such behaviors, but if so, we can let
nature take care of itself.
Similarly, some people have a natural compulsion to grapple with bits
that can be combined in certain ways to make something that spins
around and makes noises. These people (maybe anyone, to some degree)
can satisfy this urge with computer programming. I can't say for sure
why assembly language would delight such a person, but just guessing,
it's the complete transparency - you aren't making some deal with a
compiler to translate your notional program into instructions, rather
you see exactly what you're doing in the computer's own language.
I think Haskell has a peculiar appeal of its own, at this level,
but of course it's quite different, and shows up in compulsive
refinement.
Donn
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
Silvio Frischknecht
> just can't skip details the way you can with experienced programmers.
> This isn't that much different from teaching adults who aren't
> experienced programmers.
and logic. But I know a lot of people who love CS and even do it
professionally who think of math as a bit of a chore. Most of those take
one look at Haskell and say "I'm not interested". With Python or
Javascript/HTML you will be able to motivate a much bigger part of your
audience. HTML was one of the first things I learned in CS.
Also just wanted to add an example of how Haskell can be really tricky
for very simple things.
Let's consider the simplest loop I can think of. The function to sum up
all the numbers up to N. Anyone new to Haskell will implement this in
the straight forward way.
sumToN 0 = 0
sumToN n = sumToN (n-1) + n
It's very elegant. It's more of a definition than an algorithm, really.
The equivalent python code would probably do a loop (4-5 lines).
Now, if you run your python code for a billion, it will eventually
return the correct result because you specified the algorithm more
clearly. If you run the Haskell function for a billion however, it will
crash your computer and set your house on fire.
Now, you will have to explain tail recursion and why you won't get a
StackOverflow despite the fact that you build up a huge stack. I have
done Haskell for a quite a while, and I'm still unsure sometimes if
something will work in constant space or not.
Cheers,
Silvio
Manuel Gómez
<silvio....@gmail.com> wrote:
> Also just wanted to add an example of how Haskell can be really tricky
> for very simple things.
>
> Let's consider the simplest loop I can think of. The function to sum up
> all the numbers up to N. Anyone new to Haskell will implement this in
> the straight forward way.
>
> sumToN 0 = 0
> sumToN n = sumToN (n-1) + n
>
> It's very elegant. It's more of a definition than an algorithm, really.
> The equivalent python code would probably do a loop (4-5 lines).
>
> Now, if you run your python code for a billion, it will eventually
> return the correct result because you specified the algorithm more
> clearly. If you run the Haskell function for a billion however, it will
> crash your computer and set your house on fire.
>
> Now, you will have to explain tail recursion and why you won't get a
> StackOverflow despite the fact that you build up a huge stack. I have
> done Haskell for a quite a while, and I'm still unsure sometimes if
> something will work in constant space or not.
I understand what you’re trying to get at, and why this simplified
example is supposed to stand in for a more general, complex, elaborate
situation. However, I believe a more thorough, explicit description
of this sort of situation may reveal such a simplified example is not
adequately representative of the general problem.
The function to sum up all the naturals up to N is most commonly
written thus, in Haskell and Python:
sumToN n = n * (n + 1) `div` 2
def sum_to_n(n): return n * (n + 1) / 2
No loops, no worries about stacks, no recursion or induction or
intuition about computational processes supporting complexity.
Depending on the student’s background, this may be the first solution
that is attempted for the given problem. The general point of this
observation is that it often happens in computer programming that a
programming-oriented solution is accidentally complex because it goes
for a brute-force approach that ignores important qualities of the
underlying problem space that enable solutions that avoid complexity.
Granted, alternate strategies with lower complexity are not always
available, and sometimes you do need some kind of aggregation. These
are likewise easy in Haskell and Python:
sumToN n = sum [1..n]
def sum_to_n(n): return reduce(add, range(n + 1))
It’s noteworthy that both of these solutions have terrible performance
for somewhat similar reasons unless you specifically go out of your
way to avoid the issue. In GHCi, asking for the value of this sum at
one billion seems to produce a very large list, and it depletes my
machine’s RAM quite quickly. Doing the same in Python also creates a
very large list and likewise starves my machine for memory.
These issues can be solved by both programming environments.
If you test the Haskell bit in a simple complete program compiled with
`-O2`, it takes a while to run with a billion as `n`, but it does
finish in a few seconds without consuming memory in proportion to `n`.
GHC can optimize that list away, but you need to be aware of the issue
to understand how to solve it: some things fuse away in compilation
and stay around in interpreted code.
The Python bit isn’t magically optimized by CPython 2.7. However, the
recommended approach to these issues is to use `xrange` instead, which
returns a generator object that produces results lazily, one by one,
much like the list in Haskell, and `reduce` doesn’t need to hold onto
the whole list of results since it’s actually working like a strict
left fold. In fact, new versions of Python altogether skip the old
list-building `range` function, and their `range` is Python 2.7’s
`xrange`, so this issue goes away if you can use a new version of the
language. Perhaps a future version of GHC may fuse lists away in
GHCi.
You may now argue that summing is only meant to stand in for some more
elaborate computation, so this whole deal misses the point. I agree.
In fact, this is a much more fair comparison:
sumToN n = foldl1 (+) [1..n]
def sum_to_n(n): return reduce(add, xrange(n + 1))
Indeed, both of these fail on empty ranges, and they have similar
performance if the Haskell version is compiled with optimisation.
There are many variations of these solutions, such as enabling them to
use 0 as the result for empty summations or expressing them in terms
of different primitives. But indeed these are two somewhat
representative ways of expressing processes that need to perform
aggregation of results over a range, both expressed in ways that are a
natural fix **for the problem** as specified, ignoring issues related
to language communities, preferences and idioms.
You may now argue that the point of your original statements is
precisely about idioms. I don’t know what the recommended, dominant
idiom may be for any given portion of the Python community. I suppose
it largely depends on the background of the sample you take from the
Python community. This StackOverflow answer seems to suggest some
people recommend `reduce` with lambdas for this sort of construct, yet
others recommend `for` loops:
http://stackoverflow.com/questions/13840379/python-multiply-all-items-in-a-list-together
Perhaps this solution is even more representative of common idioms in
a way that is somewhat less specific to the toy problem of performing
simple summations:
sumToN n = foldl1 (\ x y → x + y) [1..n]
def sum_to_n(n): return reduce(lambda x, y: x + y, xrange(n + 1))
Do these perform the same as before? I don’t know about the one in
Haskell; I didn’t check. I suppose it may possibly depend on whether
tests are performed in GHCi or compiled code with various optimization
options. It should be absolutely trivial for the GHC simplifier to
reduce both into the same code, but does it work quite the same in
GHCi? I don’t know. The Python versions do appear to differ a bit in
performance according to comments in that StackOverflow post.
In any case, loops are also a common, recommended idiom in Python:
sumToN n = runST $ do
s <- newSTRef 0
for_ [1..n] $ \ i -> do
modifySTRef' s (+ i)
readSTRef s
def sum_to_n(n):
s = 0
for i in xrange(n + 1):
s += i
return s
I’m pretty sure most Haskell novices wouldn’t write this one, just as
I’m pretty sure most Python novices wouldn’t use `reduce`. These two
behave more or less the same: they don’t leak space. They would leak
space if you didn’t know you had to use `xrange` instead of `range`,
or if you didn’t know you had to use `modifySTRef'` instead of
`modifySTRef` (although the specific mechamism for the space leak is
not precisely the same, but the causes are quite similar). Python
solved this issue in recent versions by getting rid of the one that’s
arguably less useful; in Haskell, there are warnings in the
documentation: https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-STRef.html#v:modifySTRef
I must confess I fell into the trap when I wrote the Haskell version:
I forgot to use `modifySTRef'`. I also fell into the `range` trap a
few days ago writing Python 2.7 at work; the only reason I avoided it
today is that it bit me very recently. I’ve been programming for 16
years and writing Haskell and Python for work and leisure for about 6
years.
My point is that understanding these subtleties is important and you
cannot be an effective software engineer if you don’t know how to
avoid these sorts of pitfalls in whatever technology and style of
expression you pick. Moreover, a modern, “multi-paradigm” language
will support and provide incentives for various styles of expression
to varying degrees, and they come with code quality and performance
tradeoffs that are not necessarily clear-cut.
Programming is tricky and abstractions leak. Python uses fewer
abstractions than Haskell, and Haskell’s abstractions (of comparable
abstractness) leak less, and that’s how they both manage to be used
successfully by practitioners. I prefer Haskell, because in the long
run, having abstractions leak less allows me to compose taller towers
of abstraction, which gives me more power as a software engineer.
Whether this is relevant for a novice depends, I suppose, on where the
novice wishes to go.
Note: Some imports and pragmas may be necessary to make these examples
work in their respective languages. I believe it’s fair to leave them
out in all cases; providing a batteries-included default namespace is
a significant issue, but it’s somewhat independent of these musings.
mant...@gsd.uwaterloo.ca
Going through your email I was wondering which one is "more beautiful" for each case and it's clear that Haskell is optimized for functional style and Python for imperative style, and things in their respective opposite styles look clumsy. That's it, end of story.
Michał
Original Message
From: Manuel Gómez
Sent: Saturday, August 29, 2015 2:30 PM
To: Silvio Frischknecht
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] Why Haskell is beautiful to the novice
Silvio Frischknecht
> They would leak space if you didn’t know you had to use `xrange`
> instead of `range`.
I might have run into that as well. I don't really know Python that
well. It is a problem I never came across in any imperative languages,
so I foolishly assumed it wouldn't happen in Python either. But as you
said they seem to have fixed it. Still, I would think the python space
leak is relatively easy to spot and explain. Esp. when compared to
tail-recursion modulo Constructors.
Silvio
JK
> it's clear that Haskell is optimized for functional style and Python for imperative style, and things in their respective opposite styles look clumsy.
I am not entirely sure what is the real meaning of "optimized for" in
your phrasing, but what is clear is that Python 'optimizes' without
being asked for, e.g. when you use generators in order to cascade some
sequence processing, as in the "sum" example, nothing wrong happens,
while lazy lists reserve several nasty surprises. -O2 optimization, or
explicit strictness annotations (and BangPatterns) are there, and may
save our lives, but "what is clear" is that teaching Haskell as a
practical language usable for large data, is quite non-trivial, and its
beauty for novices evaporates quite fast.
[This 'sum' example under GHCi will be problematic anyway].
I taught Haskell so long, that I became reckless, and my students got a
rather tiresome project based on Haskell OpenGL. It was a massacre, a
general unhappiness... Two years later my dept. decided to abandon
advanced Haskell (with monads of all sorts), and left only the 2nd year
introduction to functional programming, its style and algorithmics. I
couldn't defend the "professional Haskell" too hard, the gap between the
elementary FP, and the "true stuff" became too big in the context of our
curriculum.
Just my three cents...
Anyway this threads degenerates a bit, and begins to contain statements
I find dubious, or too restricted, e.g.,
> A beginning student doesn't need to learn OOP in
> any kind of depth.
etc.
I suspect that the author of this phrase was not yet born when I began
to teach programming... Now, I would never dare to declare what a
beginning student *really needs*. Programming is a kind of art, a
fragment of culture, a vision of the world, and the Pursuit of Happiness
is different for different people. Linguists (or historians, etc.) may
*begin* with logic/relational programming, biologists with objects, and
mathematically-oriented yougsters, with FP.
Or not.
Jerzy Karczmarczuk
/Caen, France/
Donn Cave
...
> I find dubious, or too restricted, e.g.,
>
>> A beginning student doesn't need to learn OOP in
>> any kind of depth.
>
> to teach programming... Now, I would never dare to declare what a
> beginning student *really needs*.
invented, so computer programming pedagogy when I was born - that must
have been a dry job, my hat is off to fellows like you!
> ... Programming is a kind of art, a
> is different for different people. Linguists (or historians, etc.) may
> *begin* with logic/relational programming, biologists with objects, and
> mathematically-oriented yougsters, with FP.
>
> Or not.
Donn
Jerzy Karczmarczuk
> I was already 4 when Lisp was
> invented, so computer programming pedagogy when I was born - that must
> have been a dry job
Some years later as well.
My first language (learnt and also taught some years later) was Algol60
[replaced very soon by Fortran]. The relationship between our
computation needs and the coding styles, paradigms, algorithm
structuring, etc. was quite obscure at the time, and our main source of
inspiration was the collection of algorithms in CACM, published in Algol.
I suspect strongly that those - fundamental AND practical - materials
conditioned the opinion of the community (at least mine: physicists)
about "what is needed, and what should be taught" (and perhaps also
"what is elegant"). Moreover, they played (I am not certain) a
significant role in specifying what should be the "main stream" of
languages, and gave a strong push to the development of compilers of all
them -- Jovial, Pascal, C, Java...
If, at the beginning of the '60ties, the Lisp community had published
more code recipes, more algorithm presentations, more practical
functional codes, perhaps the evolution of programming languages would
be different. Perhaps the evolution of computer architectures would be
also a bit different (more importance for hardware stack architectures)
We have seen some nice psychological paradoxes. Anthony Hearn told me
that he recognized the importance of Lisp for the symbolic computations
very early, but he found out that his colleagues abhorred its syntax so
strongly, that his Computer Algebra package Reduce became Lisp disguised
in an Algolish language... Now, the Beauty and the Beast, where were
they?...
On the other hand, around 1963, Martinus Veltman (his Nobel had to wait
more 36 years...) found out that the "fast", and low level Fortran for
such needs was useful as well, but as an implementation platform, not
the front-end. He conceived his computer algebra system Schoonschip
(name chosen "among others to annoy everybody not Dutch", quote from
Wikipedia, probably authentic, knowing the personal character of
Veltman) upon Fortran, and assembly language, but he manufactured a
*rewriting system*, completely different from any other language! The
result was that for many years only theoretical physicists used it,
because it worked, but others (e.g. people from an engineering school to
whom I proposed a course of Schoonschip) refused to touch the "monster".
Well..., this "monster" evolved to FORM of Jos Vermaseren (also
initially coded in Fortran, it still exists and is used). It inspired
Cole and Wolfram at Caltech in their work on the computer algebra
rewriting system SMP, that you know well.
Oh, you don't?
Yes, you do, only that it is called now "Mathematica".
You don't use it? But you *DO USE* another rewriting system, only
perhaps you don't know that it is one. It is called TeX...
I repeat again:
Programming languages evolve as the Culture does, with redundancies,
inspirations, contradictions, and re-discoveries of the same paradigms
several times. (Some people teach Prolog and say that it was the first
known language which used logical non-determinism. But Colmerauer began
to work on it at the beginning of '70, while Snobol was there for almost
10 years, and Griswold introduced into it the non-deterministic
string-processing algorithms since the beginning.)
I find it pityful that nowadays some young people learn 2 - 3
programming languages, and quarrel about which one is "better" or
"worse"... Recall please one silly discussion between Van Gogh and
Gauguin, when Van Gogh accused Gauguin that he gets everything false,
that his world is flat, which is ugly and silly. Gauguin answered that
the world *IS* flat, and that all these pointilistic details of Van Gogh
are useless, false, and go nowhere.
Well, both masters are great and they are still with us. Their
discussion, perhaps invented, is almost forgotten, but it can be used as
a /memento/. Their colours remain. Be colourful!
==
Jerzy Karczmarczuk
/Caen, France/
Olaf Klinke
first of all thanks for all the elaborate answers. I did not imagine to trigger such an avalanche of opinions.
Let me try to steer away from the Python/Haskell comparison (as comparison is what I wanted to avoid) and collect some points I found important in the past discussion.
1.
There is a difference between teaching how the machines we call computers work and how computers are used to solve problems. What is computer science? The science about computers or science that can be executed on a computer? Both subjects are beautiful, in different ways. Haskell, I used to think, was designed explicitly to abstract away from how its programs are actually run on the hardware, to the point where one can not even tell (and care) what order certain computations are executed in, or whether they are executed at all. Therefore Haskell is certainly not the best language to teach about the mechanics of computing. Similarly, there are practical problems that may be more difficult to express in a functional language, because the problem may be already of a sequential, mutable, effect-full nature (e.g. writing an adventure game).
2.
For teaching purposes, the remark that kids want something they can show off to others should not not be under-estimated. In order to quickly obtain showable results, one might choose a toy language (DSL?) or program robots. For this reason I considered HTML as a first introduction to syntax, even if it is not a programming language as such. But there exist syntax checkers and one can create and view HTML on every modern device. By the way, is there a live CD (not DVD) image that contains the Haskell platform and some other languages?
3.
One skill/revelation that I want to install in the students of both math and CS, and which I believe Haskell is more suitable for than imperative languages, is the fact that in mathematics and computer science there are no hidden layers/aspects, no mysteries. Everything is composed of smaller, simpler parts. And if one wishes, one can unwrap one layer and look inside. How deeply one wishes to look inside is a question of audience, then. The layering might consist of recursion, classes, objects. It does not matter. The important point is that the path to a solution must descend the layers to the simple parts. This is in contrast with arts and humanities, where one can study the same piece of art, the same novel, several times in a lifetime and each time discover new things, and probably still miss others which require expert education. Mergesort, once grasped, is there in all its completeness, simplicity and beauty, there is no further interpretation.
As others have remarked in this discussion, the `no mysteries' only applies to the denotational semantics, but not the operational semantics in case of Haskell. For assembler it might very well be the other way around.
Thanks,
Olaf
Silvio Frischknecht
> 2. For teaching purposes, the remark that kids want something they
> can show off to others should not not be under-estimated.
solver. The seemed pretty impressed by that, and it seems a problem that
is relatively well suited for Haskell. You might want to try that.
Cheers
Silvio
Silvio Frischknecht
> solver. The seemed pretty impressed by that, and it seems a problem that
> is relatively well suited for Haskell. You might want to try that.
me a bit over an hour. Not everything is trivial to program. But the
consistency checks should be easy to do even for relatively new programmers.
Code appended
Silvio
Richard A. O'Keefe
On 29/08/2015, at 8:41 pm, Alexey Muranov <alexey....@gmail.com> wrote:
> IMO, what attracts a big part of kids to programming is the possibility to program side effects.
Take this example:
PRINT *, 'HELLO WORLD!'
END
That's a complete Fortran (77, 90, 95, '04, '08) program.
The print statement has an EFFECT. That effect is not a
*SIDE* effect. Here's the definition of "side effect":
1. A subsidiary consequence of an action, occurrence,
or state of affairs; an unintended secondary result.
2. An effect (usually for the worse) of a drug or other
chemical other than that for which it is administered
In the case of the little program above, the fact that
output is sent to a destination is neither subsidiary,
nor unintended, nor secondary, nor other than that for
which the program was constructed.
I flatly deny that "UNINTENDED ... results" are what
attracts ANYONE to programming. Effects, *YES*;
*side* effects, NO.
As a young programmer, decades ago, I learned to be
perfectly happy with *effects* but wary of *side effects*.
(By getting it wrong of course, how else?)
Confusion of *words* leads to confusion of *thought*:
I didn't want anyone taking my READ and PRINT statements
away but I *loved* the idea of languages where you told
the compiler "this procedure can read these variables and
write those variables", as in SPLint for C.
To call the main, principal, intended consequences of a
program element, the entire reason for its existence in
the program, to call *that* a "side effect" is just to
blue a vital distinction.
You see, when people in the programming world got worried
about side effects, they were not in the least worried about
known, intended effects. They were worried about "functions"
that printed output, "functions" that changed hidden variables.
Nobody minded things like
CALL RANDOM_NUMBER(HARVEST = X)
or even
U = NRAND(SEED) ! update SEED
They were worried about things like
lu = random();
which *purports* to be a function call, and is called in
order to obtain a value, but *also* has a "subsidiary
consequence" which is hidden from the programmer, the
compiler, or both.
Now what Haskell does is to banish side effects completely.
You can have all the effects you want, but *something*
about the scope of the effects must be visible in the type,
and effectful operations have to be explicitly chained in
a way that "pure" operations do not.
If we screw up our language by calling all effects "side
effects", we can't even *think* "Haskell makes effects easy
but side effects hard".
To anyone who wants to defend the abuse of "side effect",
what do you think is the point of the word "side" in that
phrase if not to distinguish side effects from some other
kind of effects?
Richard A. O'Keefe
On 29/08/2015, at 4:17 pm, M Farkas-Dyck <stra...@gmail.com> wrote:
>
> Actually we ought to start with semiconductor physics, VLSI
> fabrication, and such.
> cuz that's how current computers work.
I did start a computer architecture lecture once
with a 10 minute explanation of what a field effect
transistor does. The physicist in me was only partly
appeased by the consideration that this was all the
students were _ever_ going to be told about what was
really going on underneath. Some of the students
thanked me for it. Some, didn't.
As for Python, remember that the people who are praising
Python as an initial language are probably comparing it
with Java or C++.
William Yager
The print statement has an EFFECT. That effect is not a
*SIDE* effect. Here's the definition of "side effect":
1. A subsidiary consequence of an action, occurrence,
or state of affairs; an unintended secondary result.
2. An effect (usually for the worse) of a drug or other
chemical other than that for which it is administered
In the case of the little program above, the fact that
output is sent to a destination is neither subsidiary,
nor unintended, nor secondary, nor other than that for
which the program was constructed.
I flatly deny that "UNINTENDED ... results" are what
attracts ANYONE to programming. Effects, *YES*;
*side* effects, NO.
Richard A. O'Keefe
In another mailing list I have been trying to explain
to someone how to write a JSON parser in a functional
language.
If anything unexpected comes up, like an error message,
he freezes, then calls the mailing list for help.
The error messages will say things like
foobar is unused
fooBar is undefined
and he'll sit there baffled.
I know a bright statistician who *hated* programming
because of the compiler error messages (for a fairly
simple imperative language, too).
For *some* novice programmers, the quality of the error
messages may be more important than almost anything else,
which means that for *them*, the language as such may be
almost irrelevant, except indirectly as it makes it easier
or harder to generate really clear error messages.
Richard A. O'Keefe
On 29/08/2015, at 5:37 am, Silvio Frischknecht <silvio....@gmail.com> wrote:
>> Why do you think that manipulating arrays is a better skill to teach
>> to kids than manipulating linked lists?
>
> What about double linked lists then. Most updatable data structures are
> just clumsy in Haskell.
Doubly linked lists are an exotic advanced data structure
which are appropriate *FAR* less often (and I'm thinking of
imperative languages like Pascal, C, Ada, &c here) than
people who have been taught them believe.
I've sometimes thought that teaching doubly linked lists in
CS1 or CS2 should be a punishable offence.
Richard A. O'Keefe
On 31/08/2015, at 2:47 pm, William Yager <will....@gmail.com> wrote:
>
> Wrong definition, my friend.
>
> https://en.wikipedia.org/wiki/Side_effect_(computer_science)
Richard A. O'Keefe
If you had troubled to read the Wikipedia article with care,
you'd have seen this right at the beginning:
In computer science, a function or expression is
VVVVVVVVVVVVVVVVVVVVVVVV
said to have a side effect if, in addition to returning
^^^^^^^^^^^^^^^^^^^^^^^^
a value, it also modifies some state or has an observable
interaction with calling functions or the outside world.
You have a function, whose purported effect is to return a
value. "IN ADDITION TO" that, it has "A SUBSIDIARY CONSEQUENCE",
"A SECONDARY RESULT". The Wikipedia definition is slightly
wonky in that if you take it literally, a Fortran subroutine =
Pascal or Ada procedure = C 'void function' can't have a side
effect, which is obviously wrong. A subprogram that does not
return a value *CAN* have a second result other than the one it
is declared to have, and the need to consider history in
reasoning about resultless procedures is none the less because
of this glitch in the Wikipedia's definition.
Donn Cave
> VVVVVVVVVVVVVVVVVVVVVVVV
> said to have a side effect if, in addition to returning
> ^^^^^^^^^^^^^^^^^^^^^^^^
> a value, it also modifies some state or has an observable
> interaction with calling functions or the outside world.
>
> You have a function, whose purported effect is to return a
> value. "IN ADDITION TO" that, it has "A SUBSIDIARY CONSEQUENCE",
> "A SECONDARY RESULT". The Wikipedia definition is slightly
> wonky in that if you take it literally, a Fortran subroutine =
> Pascal or Ada procedure = C 'void function' can't have a side
> effect, which is obviously wrong. A subprogram that does not
> return a value *CAN* have a second result other than the one it
> is declared to have, and the need to consider history in
> reasoning about resultless procedures is none the less because
> of this glitch in the Wikipedia's definition.
change as a side effect of a discussion that references it.
But the modified definition seems to make even less sense. If I
understand your objection above, the answer could simply be that
these subprograms return a value like our (), for the sake of
semantics. But the new definition requires us to identify a
"purported main effect" in order to say what's a side effect.
If foo :: IO Int prints a string and returns the string's
length, do we need to know how important the string length is
to the caller, or is that as the function type automatically
its purported main effect? I'm sure I've encountered real
life subprograms with two or more main effects.
I'm also troubled by the change from "In functional programming,
side effects are rarely used" to "In functional programming,
effects are rarely used." This must be an error.
Donn
o...@cs.otago.ac.nz
> change as a side effect of a discussion that references it.
> I'm also troubled by the change from "In functional programming,
> side effects are rarely used" to "In functional programming,
> effects are rarely used." This must be an error.
Because it means EXACTLY what the original text was meant to
mean; the only difference is that the original text used
"side effect" to mean "effect".
I see someone has changed it back to the old muddled wreck, sigh.
Alexey Muranov
> Sorry, cliekd the wrong button.
> If you had troubled to read the Wikipedia article with care,
> you'd have seen this right at the beginning:
>
> In computer science, a function or expression is
> VVVVVVVVVVVVVVVVVVVVVVVV
> said to have a side effect if, in addition to returning
> ^^^^^^^^^^^^^^^^^^^^^^^^
> a value, it also modifies some state or has an observable
> interaction with calling functions or the outside world.
>
> You have a function, whose purported effect is to return a
> value. "IN ADDITION TO" that, it has "A SUBSIDIARY CONSEQUENCE",
> "A SECONDARY RESULT".
Alexey.
Donn Cave
...
to call an effect that's clearly central to a computation a "side effect."
That said, it sure is widely used that way, and an attempt to correct
this is not only swimming upstream, it also encounters ambiguities that
the common definition avoids.
Maybe it would be more productive to see this an opportunity to talk
about how FP and Haskell in particular organize effectful computations
to avoid the problems with side effects.
I think the FP paragraph on this page could be much better - "The
functional language Haskell expresses side effects such as I/O and
other stateful computations using monadic actions." That's it?
Can this be written so it would address what Haskell brings to
the problem, in a way that would make sense to a Java programmer?
Donn
Tobias Dammers
> quoth <o...@cs.otago.ac.nz>
> ...
> > I see someone has changed it back to the old muddled wreck, sigh.
>
> I sympathize with what I understand to be the point, that it's silly
> to call an effect that's clearly central to a computation a "side effect."
>
> That said, it sure is widely used that way, and an attempt to correct
> this is not only swimming upstream, it also encounters ambiguities that
> the common definition avoids.
Seriously though, the distinction between an *effect* and a *side
effect* is important, and using the term "side effect" to indicate
either is just as ambiguous.
> I think the FP paragraph on this page could be much better - "The
> functional language Haskell expresses side effects such as I/O and
> other stateful computations using monadic actions." That's it?
> Can this be written so it would address what Haskell brings to
> the problem, in a way that would make sense to a Java programmer?
further fueling the Monad Confusion. Haskell expresses effects by making
them first-class, i.e., introducing values that represent the effects,
functions to combine and manipulate them in a pure fashion, and the
convention that the value bound to Main.main represents the computation
we want the runtime to execute. IO also happens to be a valid Monad
instance, but that's more a convenience thing, it's not essential to
encoding effects at all - one could easily implement an IO minilanguage
that doesn't implement Monad; it would end up taking a Monad shape at
some point though, so it makes sense to make it official by having it
implement the Monad typeclass. But that's not essential for the
mechanism at play here - it just so happens that effectful computations
usually end up forming monads.
M Farkas-Dyck
>
> On 29/08/2015, at 4:17 pm, M Farkas-Dyck <stra...@gmail.com> wrote:
> >
> > Actually we ought to start with semiconductor physics, VLSI
> > fabrication, and such.
> > cuz that's how current computers work.
>
> I did start a computer architecture lecture once
> with a 10 minute explanation of what a field effect
> transistor does. The physicist in me was only partly
> appeased by the consideration that this was all the
> students were _ever_ going to be told about what was
> really going on underneath. Some of the students
> thanked me for it. Some, didn't.
Computer architecture, tho, is to my knowledge largely due to implementational constraints, so it seems quite appropriate to teach the foundational technologies at least briefly.
> As for Python, remember that the people who are praising
> Python as an initial language are probably comparing it
> with Java or C++.
Mike Meyer
I could compare Java and COBOL; it wouldn't make Java worthy.
Alexey Muranov
> Seriously though, the distinction between an *effect* and a *side
> effect* is important, and using the term "side effect" to indicate
> either is just as ambiguous.
Definition from Oxford dictionary:
side effect -- a secondary, typically undesirable effect of a drug or medical treatment.
Since we are not talking about drugs but about programs, i fail to see any example of a "side effect" in the sense of this definition, other than, possibly, effects of bugs.
Previously my intuitive understanding of "side effects" in the sense of FP was quite clear: any effect that cannon happen if you execute the program in your mind or with pencil and paper, that is any interaction with the real world (think of programs as calculations).
I agree however that it was not clear if getting user input should be called a "side effect", or an oracle, or something else.
See also http://programmers.stackexchange.com/questions/40297/what-is-a-side-effect
Alexey.
M Farkas-Dyck
> Of course not. There are application areas for which COBOL is clearly
> superior to - and hence more worthy than - Java. Or Haskell.
Alberto G. Corona
At last, a productive programming language must guide the programmer for creating valid and efficient solutions fast. The haskell type system helps in the first very well and this is a great advance, but it does not help on the latter. There are too much alternatives, too much abstraction and with a lot of impedance between them. All of this in combination with Monad transformers and the abstruse errors kill any hope of making Haskell a productive language.
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Mike Meyer
On 31/08/2015, Mike Meyer <m...@mired.org> wrote:
> Of course not. There are application areas for which COBOL is clearly
> superior to - and hence more worthy than - Java. Or Haskell.
Name one.
Neil Davies
Miguel Mitrofanov
01.09.2015, 11:30, "Mike Meyer" <m...@mired.org>:
Alberto G. Corona
Neil Davies
Jerzy Karczmarczuk
Le 01/09/2015 08:59, Mike Meyer a écrit :
> There are application areas for which COBOL is clearly superior to -
> and hence more worthy than - Java. Or Haskell.
But could you
1. Tell us which application areas? Concretely.
2. Explain what does it mean "superior"?
3. Explain WHY Java is inferior?
Jerzy Karczmarczuk
/Caen, France/
Alberto G. Corona
James Crayne
Somewhat worryingly, but also understandably, the stress and emphasis placed on these values has actually lessoned over time, due to other important values becoming greater.
Consider what the equivalent of sum types and product types and sums of product types look like in these languages. I think a very strong case can be made that Haskell is _objectively_ more "beautiful" than these languages, and if I am correct, even a complete novice will be able to discern this, given the examples to demonstrate.
Dear cafe,
please correct me if questions like this should not go via this mailing list.
Presumably everyone on this list agrees that Haskell stands out as a beautiful and pleasant language to have. The recent nitpicking and real-world problems like cabal hell don't change that. However, statements supporting Haskell's beauty usually involve: "In Haskell it is so much clearer/easier/faster to ... than in another language." That is, the beauty of Haskell presents itself to those who can compare it to other imperative or not strongly typed languages that one learned before Haskell.
My question is, for what reason should anyone not acquainted with any programming language find Haskell beautiful? Maybe it does not look beautiful at all to the novice. The novice can not draw on the comparison, unless he takes the effort to learn more than one language in parallel. The novice likely also does not have the mathematical background to see the beautiful correspondence between the language and its semantics. (My reason to love FP is because it is executable domain theory.) One might argue that it is not the language itself that is beautiful, but rather the concepts (data structures, algorithms, recursion) and Haskell does a great job to preserve their beauty into the implementation. Do you agree?
Disclaimer: I am about to start teaching a first course in computer science in secondary school. I can teach whatever I want, since this is the first CS course the school ever had. I want to teach beautiful things. I love functional programming. I need not start teaching programming right away. But I am reluctant to expose the pupils to something whose beauty escapes them completely.
-- Olaf
Donn Cave
> Seriously though, the distinction between an *effect* and a *side
> effect* is important, and using the term "side effect" to indicate
> either is just as ambiguous.
every change to state context a side effect, then you're down
to fine points about state, context, etc.
Anyone can see the importance of a distinction between effect
and side effect, but that doesn't make it easy to draw up a
definition that could easily be applied to any expression to
tell us whether the effect is a side effect or not.
Rather what I'm saying is, let the billions of flies have it
their way, but use the FP paragraph to illustrate more appealing
culinary techniques for clean and wholesome dining. Functional
languages are by nature less dependent on side effects, with
features like single assignment, efficent recursion, am I right?
I agree with your thought to deemphasize the monad part of the
Haskell explanation. It might be a mistake to try to really
explain how Haskell does it, maybe better to just say that
Haskell rigorously distinguishes expressions that have external
side effects and provides a mechanism for their ordered execution.
If you get too deep into it, you have to explain that, well, IO
isn't just for side effects but accounts for any external state
dependency, etc. - and all in terms that will easily be understood
by an average Java programmer. (That's why I'm pursuing this,
in my position as surely the least erudite member of this
mailing list, I hope to be able to recognize a suitably simple
minded explanation when I see one.)
DOnn
Mike Meyer
Le 01/09/2015 08:59, Mike Meyer a écrit :
> There are application areas for which COBOL is clearly superior to -
> and hence more worthy than - Java. Or Haskell.
Perhaps.
But could you
1. Tell us which application areas? Concretely.
2. Explain what does it mean "superior"?
3. Explain WHY Java is inferior?
Rustom Mody
On 31/08/2015, Mike Meyer <m...@mired.org> wrote:
> Of course not. There are application areas for which COBOL is clearly
> superior to - and hence more worthy than - Java. Or Haskell.
Name one.
Rustom Mody
Richard A. O'Keefe
On 31/08/2015, at 8:27 pm, Alexey Muranov <alexey....@gmail.com> wrote:
>
> In my opinion, with such interpretation there can be no documented side effects: if some effect is documented, it is purported (an probably used by someone), so not secondary.
public class Record {
private static final AtomicLongFieldUpdater<Record> VERSION =
AtomicLongFieldUpdater.newUpdater(Record.class, "version");
private volatile long version = 0;
public long update() {
return VERSION.incrementAndGet(this); // THIS LINE IN JAVA
}
}
For comparison, here's basically the same thing in C on OSX:
struct Record {
volatile int64_t version = 0;
};
// Atomic this->version++
int64_t update(struct Record *this) {
return OSAtomicIncrement64(&this->version); // THIS LINE IN C
}
THIS LINE IN C has an effect. It's obvious from the code
that the variable `version' may be affected.
THIS LINE IN JAVA doesn't as much as mention `version'.
Surely there is a qualitative difference here that *matters*?
Historic note: Java forbade 'var' or 'reference' parameters
in the name of object-oriented purity. i have never been able
to figure out what they meant. What they have instead is, and
I kid you not, AtomicLongFieldUpdate is an official Java public
class, is POINTER ARITHMETIC. (AtomicLongFieldUpdater basically
holds a reference to a class and an offset within that class,
which gets added to the argument to find the actual variable.)
I just learned about AtomicLongFieldUpdater yesterday and still
feel sick. Java just moved from "I don't particularly like it
but it could be worse" to "heck, I might as well just use C" in
my estimation. What I am still having difficulty swallowing is
the Java enthusiasts who think this feature is wonderful.
But this is a Haskell mailing list, not a Java or C one.
For *Haskell*, the type system doesn't encode *all* the
effects of an operation (although a functional language
type system *could* do so), but it forces you to reveal
that an operation has *some* effect other than returning
a value and *encourages* you to factor your state space
into chunks smaller than the whole world. If you have two
state monads and you need to update both, you *know* you
have an issue.
Richard A. O'Keefe
it's worth remembering that there have been several major
versions of COBOL with major differences.
COBOL 68 was, well, meh.
COBOL 74 was quite a dramatic improvement,
arguably bigger than Fortran 66 -> Fortran 77.
COBOL 85 was another dramatic improvement,
finally permitting structured programming
with user-defined procedures. About comparable
to the Fortran 77 -> Fortran 90 jump, where
Fortran got free format, full set of structured
programming structures, modules, nested procedures,
and other good stuff.
COBOL development did not stop there.
COBOL 2002 added free format, user defined functions
(that is, usable expressions), recursion (just 42 years
after Algol 60...), locales, Unicode, a Boolean data type,
pointers, form-based screen interfaces. Oh, and object
orientation! I have to say that OO COBOL is in my view
uniquely horrible.., but this is not the place to defend
that view.
COBOL 2014 added native support (seriously weird native
support, but native support) for XML, and a set of
container classes (these had been issued by 2009).
One of the merits of COBOL 85 was that the language lacked
features that make static analysis difficult, so it was
possible to analyse COBOL programs quite thoroughly.
The additions to COBOL 2002 have pretty comprehensively
destroyed that property, without making COBOL into anything
an OO programmer would really _want_ to use. Perhaps it is
not surprising that a large amount of COBOL code is still
said to be fairly straight COBOL 85, even COBOL 74.
The non-business world seems to mostly thinks of COBOL as if
it were still 1970, such as the non-heavy-duty-numerics world
seems to still think of Fortran as if it were still 1970.
Back when it *was* the 1970s, COBOL enjoyed a good reputation
for portability, which more academically favoured languages
by and large did not. Much of this comes down to arithmetic:
77 MY-COUNT PICTURE S999999 USAGE COMPUTATIONAL.
makes it clear that I want something that can hold at least
-999,999 .. +999,999 that's good for calculating with, and
the rules of COBOL say that I *must* get it, even on a 16-bit
machine. In contrast, if I write
INTEGER MYCNT -- Fortran
or var mycount: integer; -- Pascal
then I get what I'm given, and even if I ask for
var mycount: -999999 .. 999999;
a Pascal compiler is under no obligation to satisfy me.
So COBOL gave accountants portable decimal arithmetic on
numbers of up to 18 digits (now 31), *regardless* of the
underlying machine. With overflow detection a *standard*
feature (still not available in Java or C#).
Commercial COBOL compilers have got very good at what they
do, and the idea of replacing a COBOL program working on
COBOL-like data by a Java program using BigDecimal is not
one that appeals unless you are desperate to slow down a
computer that's too fast.
Of course, nothing says you couldn't have a decent
structured modular programming language with strong static
typing that was capable of working on COBOL data. It's
called Ada. And again, nothing stops someone making a
nice structured language whose compiler targets COBOL.
Come to think of it, there's no reason there couldn't be
a Haskell compiler with really efficient support for
fixed-point decimal numbers. It just seems unlikely that
Haskell programmers would want it.
As other people have noted, sometimes the environment of a
language is as important as the language itself. I've never
used Eclipse -- though I've tried and failed -- but Eclipse
support for COBOL is said to be excellent.
Bruce Richardson
On Friday, 28 August 2015 16:45:53 UTC+1, Silvio Frischknecht wrote:
Current computers work by you giving them an step by step guide
what to do. This I think is what should be at the base of any
beginners-programming course.
I think that is a terrible idea. It will mostly create graduates who will never be able to see the forest for the trees (an English metaphor for never being able to see the big picture because of obsession with details).
When I first started to seriously learn about programming, PCs (then and now the most common environment in which people learn computing) were single-core with no support for threading, no pre-emptive multitasking, no virtual memory, no memory-protection, no memory-mapped files, one megabyte of RAM which was shared with the OS and hardware devices, no hard disks, floppy disks which measured their storage in kilobytesk no operating system worthy of the name. Writing any large or complex software meant constantly fighting all those deficiencies.
When the 80386 processor arrived and all of those constraints disappeared, the habits ingrained by them continued to dominate software development for nearly two decades (some still persist).
- Binary configuration files persisted even though their original purpose (to save space and discourage users from tampering) was irrelevant with much larger storage and secure, multi-user filesystems.
- Windows programmers were still locking (and being taught to lock) memory pages to stop them from being swapped to disk (Hello? Virtual Memory and page faults?)
- The windows registery stored many flags as bits in single keys, requiring bitmasks to read or change them (same reason as for binary config files).
- Drive Letters! Drive letters are still here!
I could go on. It's a long and depressing list.
It's a very common habit for people not only to learn to live with the artificial constraints of a system but to accept and respect them. It's a form of Stockholm Syndrome. I can remember, in 2001, a Visual Basic programmer colleague dismissing the concept of the UNIX virtual filesystem as an abstract, fragile and unnecessary conceit. As if his drive letters were not themselves virtual, but somehow more real. As if they were still necessary, despite the fact that his PC would not let him remove a floppy disk that was in use. Stockholm syndrome persisting long after the kidnappers had departed.
(I don't mean to be rude, but your belief that imperative programming is more obvious and natural seems like much the same syndrome.)
Worse, remembering the details of these obstacles is seen as expertise, not an encumbrance. Such people are resistant to change not only from habit but because removing the constraints makes their "expertise" obsolete, which is a threat. If they had ever learned an appreciation of the bigger picture, the removal of the old system would simply give them the opportunity to learn how those grander concepts are expressed in the new one.
Start teaching the bigger concepts. They are actually less complicated than the trivial and transitory implementation details. The brighter students will learn the system details for themselves, anyway (often better than the teacher). The less bright will not truly understand the complexities of the system if they have to learn their details before they learn the concepts and will be severely hampered when they are confronted with those concepts later on.
Would anybody ever suggest that physics students should be required to be taught the workings of the internal combustion engine before they can learn that speed = distance / time? I don't think so. And yet the equivalent is regularly insisted upon with regard to computer science.
The minds of teenagers are, in many cases, more flexible, imaginative and receptive than they will ever be again. Teaching them not to think is a terrible waste.
Now, I want to go back to one thing you said:
"Current computers work by you giving them an step by step guide
what to do."
Current computers require you to request memory before you create a data structure and release it when you are done. When is the last time that you, as a Python coder, had to call malloc or free? How often have you had to take care to safely dereference a pointer? If you think Python is a step-by-step guide to a computer, there's an army of C-coders over there who would like to have a word.
I see no logic to saying that Python's set of constraints and freedoms represents "real computing" while Haskell's do not. The only thing of which Python can be said to be definitively representative is GvR's personal preferences and eccentricities.
There are also a lot of very basic data structures that can simply not
be used in purely functional code like hash tables, pipes or random
access arrays.
That's simply not true.
Haskell also requires quite a bit of intelligence and perseverance to
master. So unless your kids are all geniuses I would not recommend it.
Haskell's expression syntax is actually significantly simpler than that of imperative languages. The more complex aspects can be tackled later. You can learn how to write simple programs without ever writing a function signature. And for those simple programs, laziness is an invisible background implementation detail just like garbage collection. You can write an expressive quicksort implentation without having to progress to any of those complexities. OK, it won't be efficient but neophyte students won't be able to type enough data into the REPL for it to matter at that stage.
A Haskell "hello world" program is no more complex than a Python one. But I would keep learners away from any IO for as long as possible. They don't need it if they are learning in the REPL, where they will benefit greatly from directly inspecting the results of their computations without ever having to dirty their hands by printing them out. Using println as a debugging tool is a terrible, terrible habit that many imperative coders never learn to discard.
Python would by my language of choice. You won't have to worry about low
level stuff or typing, but can still write those step by step programs.
And yet you'll have to perform cartwheels to create something as simple as a linked list.
--
Bruce
Edward Kmett
And again, nothing stops someone making a nice structured language whose compiler targets COBOL.