RE: Re[2]: [Haskell-cafe] Re: A suggestion for the next high profile Haskell project
why you (and Donald) don't want to understand me. i say that imperative Haskell code is more efficient than pure (and especially lazy) one and that even such code in ghc is slower than C equivalent. I think the concern about execution speed of algorithms is a fairly recent topic. At least, the reason why compilers were developped at all was to save expensive memory capacity. Imagine to pay $3500 for 2kB memory! (http://www-03.ibm.com/ibm/history/exhibits/system7/system7_tpress.html) It would pay off to invest thinking in how to make programs short in terms of memory space usage. The counting of instruction cycles in speed context came only later when personal computers became mainstream. And nowadays, they use is an interesting idea of measuring performance in multimedia: Quality of Experience. I don't know exactly which parameters play a role, but it is interesting to relate speed to human perception. At least, speed is relative after all (with respect to the timebase we use: eons to femtoseconds). Patrick ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Book Haskell in real world
Hello Bulat, you are talking about the real world, but maybe it useful to think about, that the real world might have different forms, falls into different categories. What I mean: The real world for a computer game programmer, network service application developper, complex simulation software engineer, embedded system designer, business software developper or university researcher might look quite different. one of such points may be the book for commercial programmers that will show them how their real programs can be written Haskell and convince them that Haskell really cuts off development cycle and increase software reliability This sounds like an economical problem, and although there are certainly the benefits you describe it is important to think about the cost and risk of learning a new skill. I was thinking about this lately at the post office where they trained a new employee to send packets. Although all the efforts they made to make this simple activity smooth for the customer, I realized that they made a mistake with pricing at the end. Because I was already on my way home, the mistake caused by training the new employee costed them 1euro50. To make training or teaching material successful, the content should focus on reducing potential mistakes or overengineering (= the cost and risk of learning something so complicated as a functional programming language). Regards, Patrick ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mozart versus Beethoven (was: Writing Haskell For Dummies ...)
Another difference with music that strikes me is the level of abstraction : a note is a note. A line of code (especially in a imperative setting) is much more than a line of code. But this is exactly what semantics is about, or not? It is the question, when you have a set of symbols or abstractions, what sort of things do they represent. Interesting to think that the old greeks and chinese basically used only 4-5 sort of abstractions to explain the different forms of matter in the universe (http://en.wikipedia.org/wiki/Classical_element), whereas now we use at least 100 sort of atoms, and millions of sort of molecules. And without the simple abstractions by Euclid (point and lines), we could not evolve mathematics and most of modern sciences. And my point is, that abstractions (concepts) change over time depending on the tools or instruments we use. Without piano's, there would be no Bach, Mozart or Beethoven. And in general, music would have been far less differentiated without the introduction of new tools (compare the differences in compositions between Palestrina, Telemann, Corelli, Bach, Haydn, Mozart, Beethoven, Wagner, Schoenberg). Also, in painting you see the emergence of many new idea's by having better ways to make paint and colors, and by the uses of lenses. Similarly, Von Neumann machines allows us to think about programming in a certain way, i.e. step-by-step-by-step-by-step but it seems that we start to learn that the amount of steps we can execute per second is not really relevant for many sort of problems. Ok, there are still many area's where we can profit from better algorithms and machines that would improve the calculation of some FFT, but what counts more is often the WAY we think about our abstractions. I think this is why functional programming is interesting. This discussion on programming approaches reminds me as well on the fight between empiricism and rationalism. The former philosophers tried to learn and generalize by experience (maybe the hacker idea), while the latter tried to improve ways of deductive reasoning (the mathematical approach). I think only later philosophers such as Kant could merge concepts from both worlds (from the senses and ideas), but to my knowledge, this had more impact on politics and ethics, rather than science or mathematics. (The source codes by Kant are quite difficult to read. It seems he wanted to write this way to increase the level of thinking.) ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Mozart versus Beethoven (was: Writing Haskell For Dummies ...)
Not sure whether this is the right place to discuss computers and programming in general: But Dijkstra's metaphor is suggesting, that while Beethoven learned by experiment and debugging compositions, Mozart did not have a need for reflection while writing down music ? The observation above sounds to me more as a difference between youthful enthousiasm (= allows few time for reflection but a lot for action) and old wisdom (= no risk taking but few action for the young). Also this difference has already been documented in Aristotele's Rethorics. It is of course difficult to transmit the characteristics of old age to young age, or vice versa. Furthermore about Dijkstra's quote on computers and telescopes which I like more. Telescopes are indeed not saying anything at all about the laws of the universe, as computers themselves don't say anything at all about complexity. But I wonder if we would have concepts as gravity or general relativity if we would have never had observed the movement of planets and light with telescopes. Equally, what can parallelity in computers teach us about the concept of monad ? I also find the approach of the designers of telescopes (= computer architects) interesting to understand parallel processes: http://view.eecs.berkeley.edu/wiki/Main_Page I think they use the name dwarfs for monads. PS I like the idea of a book Hakell for Hackers ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mozart versus Beethoven (was: Writing Haskell For Dummies ...)
You're implying that there's a *more* appropriate forum somewhere for discussing analogies between music composition and programming languages? If so, I'd like to know what it is! Yes, music and programming languages are ultimately phenomena of our human brains/minds. Therefore, the expression of music or algorithms touch as much mathematics as they touch the field of philosophy (and here the philosophy of the mind). Sometimes there are interesting posts in comp.ai.philosophy and attempts to discuss the semantics in Mozart or Beethoven's style: http://groups.google.de/groups/search?hl=deq=beethoven+mozart+comparison I've been thinking about this. Are there really any programmers who are like Mozart in the way you describe? No, and I think Dijkstra perception is a bit flawed with respect to Mozart's compositions. Certainly, there are very strong rewarding mechanisms in the brain which can be activated by special circumstances and allow to develop special capabilities (Feynman spoke about falling in love with an idea). But it is not highly desirable for a society to have every member to develop radical new idea's or skills. A species would quickly stop to reproduce if everyone would be sitting in a room thinking about a certain abstract subject. Whereas it's conceivable to imagine somebody writing a piece of music that way, or a poem. I think in general it is underestimated how rare such moments of divine inspiration are in reality. There is this nice speech by Wislawa Szymborska about the difficulties of inspiration in poetry (http://nobelprize.org/nobel_prizes/literature/laureates/1996/index.html) and also the late Beethoven explains this in his music: Have a listening to the 3rd movement of his op.106. In my view, he explains about the suffering of a lonely genius, and then starts laughing about it because our own nature changes all the time, and that there is almost no way to control these changes, nor on time that passed away or predicting times to come, neither a judgement whether he is happy or not with this fact of life- I find it a very powerful observation on how learning works. ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
In my opinion it would be important to increase the understanding about semantics and processes. And it would be good to introduce the concepts in a similar way as Profokiev introduces the sound of classical music in Peter and the Wolf. If my suspicion is correct, functional programming would be very close to composing classical music (or concurrent algorithms and processes). Has anyone of you similar thoughts on music and programming ? What are the basic ingredients for making abstractions (like in music rythm, keys, tempo, ...) ? It would be useful to express different ways of expression by explaining first semantics of processes and abstractions. --- Kirsten Chevalier [EMAIL PROTECTED] schrieb: It's not as if this is the first time that this has been suggested, but some people have suggested that a practical book about Haskell would be a good idea. I agree. Some people have also suggested that the right moment for this hasn't arrived yet, and I see that as a challenge. I'm willing to take the lead in at least thinking about what such a book might look like. I'm potentially about to have some free time for such things, and am still young and foolish enough to think that writing a book would be a good idea. Of course, there are many good Haskell books out there already, but many of them are intended as class textbooks or are aimed at more theoretical-minded people. There's nothing wrong with that, but I think that it would be nice if a friendly, conversational, informal book about Haskell existed, since after all this is such a friendly and informal community. (If there already is a book like this, point it out, but I get the impression there's not.) There's also excellent Haskell documentation available on the web already, but people like to buy books and they like to have an artifact that they can hold in their hands without getting laser printer toner all over themselves. But if I were going to do this, I'd need all the help I could get, so if you're interested in working with me on this, email me off-list and we'll talk. Don't feel like you need to be named Simon for this; I don't think you need to be a Haskell guru to contribute to a book like this (I know I'm not one), though it wouldn't hurt. Being interested in good writing and explaining things to a wider audience is more important. And, the more people who are interested in working on this, the more we can all pool our various talents to create something awesome. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Everyone's too stupid. -- _Ghost World_ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
(to Kirsten, Akhmechet, cc: Haskell-Cafe) I would divide the book into two parts. The first part would introduce Haskell via traditional small examples. Quick sort, towers of Hanoi, etc. The second part would have two or three large examples - something that people would relate to. I'd take a web application, tetris, and perhaps a chat server. Tetris could be fun, because it would allow to present your software/learning curve to people without technology background, and maybe they would look into programming then as well. Your setup also reminds me on the book by Peter Seibel on learning Lisp. He shows how to program a small database to organise your CD collection (by writing a sort of SQL replacement.) I've often thought that reading code (if it's well-written code) is a little like reading a poem, which of course is also a little like listening to classical music. Indeed, poems are another form of abstract expression, and certainly it would be interesting to think about similarities with programming. Poems can be interesting because of multiple associations in words, e.g. an obvious meaning and hidden meaning. And this involves some parallel processes. But to me, the idea of parallel processes is more clearly to see in music. Processes are rendered in the voices of instruments, and every voice transmits or contributes to a certain message. In a way, the voices of an orchestra can be seen to describe a process (experience) or function. Another idea that comes to my mind is attributing processes to protagonists in a drama. (Another quote how programming shares aspects of making music. From the preface of Structure and Interpretation of Computer Programs: A computer is like a violin. You can imagine a novice trying first a phonograph and then a violin. The latter, he says, sounds terrible. That is the argument we have heard from our humanists and most of our computer scientists. Computer programs are good, they say, for particular purposes, but they aren't flexible. Neither is a violin, or a typewriter, until you learn how to use it. Marvin Minsky, ``Why Programming Is a Good Medium for Expressing Poorly-Understood and Sloppily-Formulated Ideas'') I've been thinking a lot lately about how to present computer science (and programming languages) to a popular audience, too. Yes, this is an important topic. But there is also the common misunderstanding that computers = Von Neumann machines. I think the concept of computer is better to see as sort of telescope or translator. Computers allow to look at processes (and complexity) which would otherwise not conceivable to our limited minds. The idea of computers as telescopes is from Daniel Dennett though. I will think about these ideas, and let you know my progress. Patrick ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
