In article <7xwr3fjff8....@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >Matej Cepl <mc...@redhat.com> writes: >> The point is that you are never interested in learning *a language*, >> everybody who has at least some touch with programming can learn most >> languages in one session in the afternoon. > >Really, that's only if the new language is pretty much the same as the >old ones, in which case you haven't really learned much of anything. >Languages that use interesting new concepts are challenges in their own >right. > >Here is an interesting exercise for statically typed languages, >unsuitable for Python but not too hard in Haskell: > >http://blog.tmorris.net/understanding-practical-api-design-static-typing-and-functional-programming/
When I'm satisfied with a program, it has this ethereal property that if the problem is slightly altered, the program is only slightly altered. Case in point:going to incorporate the extra 8 register from 64 bit pentium into a pre-existing 32 bit Pentium assembler. (Which is a in fact a somewhat large messy change that would trigger a rewrite in most assemblers.) I much doubt if e.g. the whowonordraw gives a compile time error on a non-finished board, that the program can be robust against a small change of the rules. Say strikes going through the lower left square are not counted as a win. It is sooo bloody artifical. A normal requirement would be an API that gives on any tic-tac-toe board one of: Iwin, youwin, draw, not-finished. Then there are static typed languages like Forth where the programmer is the judge whether there is a type error, and type errors are not generated by the compiler. A much more natural api is where a board is an object. You can send a move message -> accepted or nor You can send an inspect message -> won lost draw or not-finished. I can make that totally robust without storing lost or draw information using the type system. He requires that on several calls, if the data is wrong, you get a compile time error. How could that be a reasonable demand from a language like Python where the call can be made interpretively? Of course it is an exercise. But I think that it went this way: 1. solve it in Haskell 2. require incidental and non-useful features of the solution to work in other languages the same way. If he is bashing Scrum, I'm bashing staic typing. > >It doesn't require the use of any libraries, standards, style, or >culture. I can tell you as a fairly strong Python programemr who got >interested in Haskell a few years ago, it took me much longer than an >afternoon to get to the point of being able to solve a problem like the >above. It required absorbing new concepts that Python simply does not >contain. But it gave me the ability to do things I couldn't do before. >That's a main reason studying new languages is challenging and >worthwhile. I give you that. Mastering a functional language is a real step, but I don't think this tic-tac-toe exercise will entice me to do that. Maybe the solutions to http://projecteuler.net that are published in Haskell sometimes condensing a few pages of my sequential code in a few lines, will inspire me to take up Haskell. Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- http://mail.python.org/mailman/listinfo/python-list
