a programming -> a programming language 2015-08-28 1:36 GMT+02:00 Alberto G. Corona :

My impression is that a programming is a tool for solving problems and the perceived beauty of a tool is a mix of many impression: One is the personal level of mastering of the tool, but also what the tool promises to achieve when you reach the next levels. Otherwise when you master it completely, it looses his interest.

This second part is what makes haskell attractive: it has no limits

2015-08-27 23:08 GMT+02:00 Olaf Klinke :

...

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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Alberto.

-- Alberto.

To add to Nicola's mail, I think what would be cool is to provide the "complex" parts to students, ie: IO handling, complex structure manipulation,... well, all that is not the focus of the current lesson nor a thing they learned in a previous course. For example, you can provide this kind of program: isSquare :: Int -> Bool isSquare n = undefined -- Don't touch for the moment main :: IO () main = do putStrLn "Square checker: check that an integer is the square of another integer." putStrLn "Input the integer to check: " input <- getLine let number = (read input :: Int) if (isSquare number) then putStrLn (show number ++ " is a square!") else putStrLn (show number ++ " is not a square!") (Maybe isSquare is not the best function for a student to create for a first time, but you get the idea) What can be a good idea is to make the students create their own set of functions as exercise and then create a bigger project reusing these. I can remember my own programming course where the code I created was then ditched for the reason it was only for an exercise. It was a bit disappointing. My whole point is: show your students the immense reusability of Haskell code and the enjoyment of its composability. -- Romain 2015-08-28 12:12 GMT+02:00 Nicola Gigante :

...

Il giorno 27/ago/2015, alle ore 23:08, Olaf Klinke < olf@aatal-apotheke.de> ha scritto:

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.

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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Il giorno 28/ago/2015, alle ore 17:45, Silvio Frischknecht 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

Exactly Mike, The destruction of pedagogy and innovation by Rationalism: http://nocorrecto.blogspot.com.es/2014/05/the-destruction-of-pedagogy-and.ht... 2015-08-28 19:19 GMT+02:00 Mike Meyer :

On Fri, Aug 28, 2015 at 11:23 AM Nicola Gigante wrote:

...

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

Have you seen this?

https://www.maa.org/external_archive/devlin/LockhartsLament.pdf

It pretty much hits the nail on the head for most high school math curricula.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Alberto.

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 Nicola Gigante schrieb am Sa., 29. Aug. 2015 11:49:

Il giorno 28/ago/2015, alle ore 22:17, Alberto G. Corona < agocorona@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.ht...

Wright brothers and Watt were tinkerers, not scientists? Well, maybe they were not _formally educated theoretical_ scientists. Science is every bit about trial-error experimentation as is about rational thinking. Science lives on the curiosity of a human being that wants to know what happens if he does something of which he cannot anticipate the effects. So 19th and 20th century pioneers were scientists, and good ones indeed. That post misses it.

And talking about formalism, I’d like to ask the author of that post who he thinks has brought humanity from Wright’s flying patch of metal pieces to the Apollo 11 mission, and from Watt’s experiments to 15nm intel CPUs. Certainly not other tinkering, but engineers that do hard physics backed by a strong mathematical background. It is true that naked formalism is not pedagogical, but even when you start learning at young age you have to learn that to do new things, _in this century_, you have to understand how things work. Easy tinkering things have already all been discovered, we missed that train.

Anyway I’m sorry, this was a bit OT, so I promise to not talk further about it.

Bye :) Nicola _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On Fri, Aug 28, 2015 at 11:07 PM, Silvio Frischknecht < silvio.frischi@gmail.com> wrote:

...

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 More heretically I draw your attention to Bob Harper's SECP «everyone knows that algorithms as welearned them at school are irrelevant to practice. » http://www.cs.cmu.edu/~rwh/papers/secp/secp.pdf In my view «CS is the science of algorithms» is one of those memes that has held back our field because it underplays data. And traditional programming pedagogy (aka imperative programming) is wrong because it emphasizes code at the cost of data

...

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.

I see a lot of naivete in this thread (not just your claims). Every programming language will do some things niftily and (many) others clumsily. And when as teachers we consider the importance of Law of Primacy https://en.wikipedia.org/wiki/Principles_of_learning#Primacy we need to carefully consider the order in which we introduce material. A case could be made [as Donn Cave does below] for assembly.

From my pov getting Hindley-Milner intuitions right should take primacy over updatable data structures. Likewise the best language of your choice will be based on what you consider primary. How do we come to an objective evaluation of that??? Dunno...

...

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.

Just to be clear I'd be pleasantly surprised if someone can show haskell is a good thing for school children. I dont know what is... Depends on the school and the child I guess?? On FP finally (50 years after Lisp!) making it to the abc level of CS-curricula: http://blog.languager.org/2015/06/functional-programming-moving-target.html

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. On Aug 28, 2015 7:46 PM, "Christopher Allen" wrote:

My coauthor Julie has written about running her 10 year old son through our Haskell book, though the book was written for adults. He's only gotten stuck arithmetical concepts he hasn't learned yet, nothing specific to Haskell or functional programming.

https://superginbaby.wordpress.com/2015/04/08/teaching-haskell-to-a-10-year-...

He'll resume learning Haskell soon. He wants to get back to the Haskell and hasn't asked at all about the Minecraft modding tutorials he was doing because he feels like with Haskell he is being taught how things actually work, whereas the Minecraft modding was copy-pasta with little/no explanation. Haskell is also Julie's first programming language. I've cc'd her so she can say more about this if she wants.

Haskell is great for teaching kids logic, math, data structures - you 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.

On Fri, Aug 28, 2015 at 1:12 PM, Rustom Mody wrote:

...

On Fri, Aug 28, 2015 at 11:07 PM, Silvio Frischknecht < silvio.frischi@gmail.com> wrote:

...

...

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

More heretically I draw your attention to Bob Harper's SECP

«everyone knows that algorithms as welearned them at school are irrelevant to practice. » http://www.cs.cmu.edu/~rwh/papers/secp/secp.pdf

In my view «CS is the science of algorithms» is one of those memes that has held back our field because it underplays data. And traditional programming pedagogy (aka imperative programming) is wrong because it emphasizes code at the cost of data

...

...

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.

I see a lot of naivete in this thread (not just your claims). Every programming language will do some things niftily and (many) others clumsily. And when as teachers we consider the importance of Law of Primacy https://en.wikipedia.org/wiki/Principles_of_learning#Primacy we need to carefully consider the order in which we introduce material. A case could be made [as Donn Cave does below] for assembly. From my pov getting Hindley-Milner intuitions right should take primacy over updatable data structures. Likewise the best language of your choice will be based on what you consider primary. How do we come to an objective evaluation of that??? Dunno...

...

...

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.

Just to be clear I'd be pleasantly surprised if someone can show haskell is a good thing for school children. I dont know what is... Depends on the school and the child I guess??

On FP finally (50 years after Lisp!) making it to the abc level of CS-curricula: http://blog.languager.org/2015/06/functional-programming-moving-target.html

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Chris Allen Currently working on http://haskellbook.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On Sat, Aug 29, 2015 at 10:49 AM, Silvio Frischknecht 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-l... 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:modi... 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.

Le 29/08/2015 20:59, mantkiew@gsd.uwaterloo.ca a écrit :

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/

Le 30/08/2015 03:29, Donn Cave a écrit :

I was already 4 when Lisp was invented, so computer programming pedagogy when I was born - that must have been a dry job Dry job?... I don't think so. It was a glorious period, I think. 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/

On 29/08/2015, at 5:37 am, Silvio Frischknecht 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.

On Fri, Aug 28, 2015 at 10:45 AM Silvio Frischknecht < silvio.frischi@gmail.com> wrote:

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

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 is a good language if you want an imperative language, but like Haskell it isn't a good choice for teaching computer architecture. For instance, computers manipulate values in a store. But Python and Haskell work with labels on values. A Python assignment statement doesn't change the value in storage as a computer would, but puts a label on a value. Manipulating storage is as fundamental to common computers as sequential operation, so if you're going to drop Haskell for not having one, you should also drop Python for not having the other.

https://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budget%20Council%20...

On Aug 28, 2015, at 10:45, Silvio Frischknecht wrote:

Hi, In my opinion, Haskell is a terrible first language to learn.

On Fri, Aug 28, 2015 at 05:45:45PM +0200, Silvio Frischknecht wrote:

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.

Amen brother! It's secondary school and I strongly suspect there won't 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.

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. [1] http://gaspull.geeksaresexytech.netdna-cdn.com/wp-content/uploads/2011/02/es...

quoth "Alberto G. Corona "

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.

Perhaps that's an esthetic thing, does this struggle make it more beautiful? Donn

On Fri, Aug 28, 2015 at 4:44 PM Francesco Ariis wrote:

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]).

And that's what programming these days should be like: finding the right libraries to use, and the connecting them properly. Python does this really well because it comes bundled with a well-curated set of libraries, and excellent libraries built on top of those. Haskell should do it well because the language makes building composable functions easier than OOP languages, and the community encourages people who do so. In general, I've found combining Haskell libraries - where they exist - easier than doing the same for Python libraries.

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.

Part of it's power comes from having well-defined composable functions. It's also fairly complete, so I haven't really had a chance to integrate it with other libraries. This may be a module that favors Haskell the way PyGame favors Python.

On Fri, Aug 28, 2015, 23:17 M Farkas-Dyck 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.

On Sat, Aug 29, 2015, 00:57 M Farkas-Dyck wrote: On 28/08/2015, Mike Meyer wrote:

Probably better to use the more exact language in the original.

What more exact language? "Imperative language" instead of "pain".

On Sat, Aug 29, 2015, 01:50 M Farkas-Dyck 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.

IMO, what attracts a big part of kids to programming is the possibility to program side effects. 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. 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. 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. Alexey. On Saturday, August 29, 2015 at 8:10:58 AM UTC+2, Donn Cave wrote:

quoth M Farkas-Dyck javascript:>

...

... 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 Haskel...@haskell.org javascript: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

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.

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.

Haskell simply refuses to allow side effects at all (aside from 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.

IO being a monad and IO being the type we use to describe real-world 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.

The value of teaching assembly language is that it's close to the metal, 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:

...

quoth M Farkas-Dyck javascript:>

...

... 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 Haskel...@haskell.org javascript: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Tobias Dammers - tdammers@gmail.com

Quoth Tobias Dammers , [... re assembly language]

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.

Indeed, I think most people would have different reasons for finding 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

On Sun, Aug 30, 2015 at 8:20 PM, Richard A. O'Keefe wrote:

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.

Wrong definition, my friend. https://en.wikipedia.org/wiki/Side_effect_(computer_science)

On 31/08/2015, at 2:47 pm, William Yager wrote:

On Sun, Aug 30, 2015 at 8:20 PM, Richard A. O'Keefe wrote:

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.

Wrong definition, my friend.

https://en.wikipedia.org/wiki/Side_effect_(computer_science)

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

Ha ha, I think this may be the first time I've seen a wikipedia page change as a side effect of a discussion that references it.

How long did you say you've been around?

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.

This can ONLY be an error if the original text was 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.

On Mon, Aug 31, 2015 at 06:13:54PM -0700, Donn Cave wrote:

quoth ...

...

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.

"Eat feces; billions of flies can't be wrong!" 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?

It could certainly be better; it's not only vague, but also misleading, 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.

Quoth Tobias Dammers ,

On Mon, Aug 31, 2015 at 06:13:54PM -0700, Donn Cave wrote:

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.

It isn't, because they avoid the matter of intent. If you call 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

On Mon, Aug 31, 2015 at 1:57 PM, Alexey Muranov wrote:

On 31 août 2015, at 06:11, Richard A. O'Keefe wrote:

...

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

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.

I think this argument represents a generation gap: Those brought up on Pascal will find it obvious what Richard (is trying) to say: - a function either just returns a value or has side-effects - a procedure has effects -- nothing 'on the side' here. Unfortunately C screwed up a whole generation by removing this distinction from our thinking ontologies And the languages that have followed C are often worse eg python's None return is more ambiguous than C's void return eg. Ive found experienced python programmers dont understand that the 'procedure' appellation can only be applied to to functions that ALWAYS return None One could say that Haskell's monadic types reinstates Pascal's dichotomy More on this here: http://blog.languager.org/2015/06/functional-programming-moving-target.html

On 29/08/2015, at 4:17 pm, M Farkas-Dyck 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++.

On Tue, Sep 1, 2015 at 12:58 AM M Farkas-Dyck wrote:

I could compare Java and COBOL; it wouldn't make Java worthy.

Of course not. There are application areas for which COBOL is clearly superior to - and hence more worthy than - Java. Or Haskell. You seem to be suffering from the common misconception that there is some independent, objective measure of the quality of programming languages. That simply is not the case. It will depend on any number of constraints. For instance, much as I enjoy writing Haskell and appreciate it's virtues, it is less worthy than C/C++ for many of my current projects for the simple reason that Haskell code won't run on the processors those projects need to run on. The same goes for teaching an intro programming/CS/SE class. Your measure of "worthy" will depend on your goals and audience. Do you want to introduce programming as an art that can be criticized and enjoyed? Then I'd say Haskell is clearly the choice you want to make. But if the goal is to give the students a feel for what programing is like for most practicing programmers today, then Haskell falls well behind many other languages. And so on through a long list of other possible scenarios with there own metrics of worth.

On Tue, Sep 1, 2015 at 4:12 AM M Farkas-Dyck wrote:

On 31/08/2015, Mike Meyer 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.

Maintaining ~50-year old government systems that are written in COBOL.

That's not very different from "being forced to use COBOL by your employer". Surely, I'll use one in this case (or quit), but it doesn't make it superior. 01.09.2015, 11:30, "Mike Meyer" :

On Tue, Sep 1, 2015 at 4:12 AM M Farkas-Dyck wrote:

...

On 31/08/2015, Mike Meyer 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.

Maintaining ~50-year old government systems that are written in COBOL. ,

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Don't confuse "easy to read" with "easy to understand" with "easy to reason about" with "easy to prove" Long term support is not about the language, it is about the ability to take someone new to become suitably engaged with the system to diagnose, repair and extend. To reason about cobol programs you need to reason about them in the context of not just the programming language, but also the compiler peculiarities, the o/s environment etc. This is a *lot* easier in Haskell than in most environments - not perfect. Haskell has strictly defined areas of doubt and uncertainty that you know you have to engage with, in other languages the doubt and uncertainty is no where nearly as well contained. On 1 Sep 2015, at 09:49, Alberto G. Corona wrote:

COBOL is verbose but at least it is easy to understand. but the current practices in enterprise java programming make legacy Java code verbose, complicated, low level and impossible to understand without profuse documentation, diagrams, web references etc. That documentation will disappear sooner or latter...

2015-09-01 10:40 GMT+02:00 Miguel Mitrofanov : That's not very different from "being forced to use COBOL by your employer". Surely, I'll use one in this case (or quit), but it doesn't make it superior.

01.09.2015, 11:30, "Mike Meyer" :

...

On Tue, Sep 1, 2015 at 4:12 AM M Farkas-Dyck wrote:

...

On 31/08/2015, Mike Meyer 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.

Maintaining ~50-year old government systems that are written in COBOL. ,

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Alberto. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

In general I think that haskell has a very low productivity because there are too much distracting and the gap between the real problem and the libraries is very high since there is a lot of abstraction in them. In the current state, even the haskell EDSLs are far from being close to their respective domain problems, not because Haskell is not enough flexible, but because it is too much flexible and too much abstract. 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 is not a high level language in the usual sense, but an abstract metalanguage where the gap between the platform and the concrete solution is very long in terms of effort. Still there is a need for an embedded general purpose high level language in which a novice can start to program fast in Haskell by freely mixing effects without a master in monad transformers, packages idiosyncrasies and error intricacies. That is why I'm trying to create Transient: a flat monad with very high level effects included, (upto distributed computing). That eliminates the impedances and reduce complexity to a minimum level. 2015-09-01 8:59 GMT+02:00 Mike Meyer :

On Tue, Sep 1, 2015 at 12:58 AM M Farkas-Dyck wrote:

...

I could compare Java and COBOL; it wouldn't make Java worthy.

Of course not. There are application areas for which COBOL is clearly superior to - and hence more worthy than - Java. Or Haskell.

You seem to be suffering from the common misconception that there is some independent, objective measure of the quality of programming languages. That simply is not the case. It will depend on any number of constraints. For instance, much as I enjoy writing Haskell and appreciate it's virtues, it is less worthy than C/C++ for many of my current projects for the simple reason that Haskell code won't run on the processors those projects need to run on.

The same goes for teaching an intro programming/CS/SE class. Your measure of "worthy" will depend on your goals and audience. Do you want to introduce programming as an art that can be criticized and enjoyed? Then I'd say Haskell is clearly the choice you want to make. But if the goal is to give the students a feel for what programing is like for most practicing programmers today, then Haskell falls well behind many other languages. And so on through a long list of other possible scenarios with there own metrics of worth.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Alberto.

COBOL is at least an honest language, while Java-J2EE is an standard initially made by SUN and the big ones for selling monstruous servers to big departments which contract big consultancy companies for very long time as well as very expensive application servers. Java-J2EE was exactly what the mainframe server and the big consultancy firms and the big software departments of big companies needed to justify and maintain and augment their big budgets in the transition from mainframes to the "internet age" 2015-09-01 12:30 GMT+02:00 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.

Perhaps. 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/

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Alberto.

If anyone wants to talk about COBOL, 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.