Re: Re[2]: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
On 31/01/07, Joe Re [EMAIL PROTECTED] wrote: Instead of having someone work in solitude with occasional mailings back and forth on the list, I would rather have an open wiki for the collection of ideas from everyone. Then, if you really wanted, a single person can use those to create an 'editor edition' page that is only editable by them. Best of both worlds, or do you see it differently? That's roughly how the O'Reilly Python Cookbook was done - open website for recipes, with the best taken and tidied up, filled out and published as a book by an editorial team. From my POV it worked well - the book is an excellent resource, and the website is still going strong as well. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[4]: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
Hello Michael, Wednesday, January 31, 2007, 4:50:17 AM, you wrote: I disagree with this part. Books written by committee lack cohesion unless they have an overbearing editor at the helm. i've provided several urls of wikipages written by us together. and this pages seems to be very popular and good appreciated -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
On 31/01/07, Michael T. Richter [EMAIL PROTECTED] wrote:
I disagree with this part. Books written by committee lack cohesion
unless they have an overbearing editor at the helm. What I've seen on the
Wiki as regards idioms, standard practices, etc. -- and this is true of
every language wiki I've ever seen -- is one proposed answer and then a
chain of but you could do it this way instead with
ever-increasingly-obscure ways of doing things. Which would be the precise
*opposite* of what a Haskell for the Working Programmer book should be
like.
I agree up to a point - there's a huge risk that increasingly advanced
solutions will obscure the point. A reasonable amount of editorial control
could keep this in check, though.
A book like this should be clear, straightforward and provide an *
introduction* to Haskell for a working programmer, but an introduction
that gets said programmer up and on the job quickly. After using the
(possibly even less than ideal) solutions provided in the book, the reader
can then comfortably hone the newfound skills provided.
I do like the idea of developing a table of contents first and backfilling
it, though. I would amend the process, however, to avoid the WikiBloat that
seems to inevitably follow when documentation projects get too open.
Instead of Wikifying it, I'd suggest instead that a call for proposals be
put on the mailing list. I'm working on a chapter dealing with database
programming. I need to know how to do insert whatever in Haskell. Could
anybody interested in helping please submit some commented, functioning code
for possible inclusion? Then the submissions could be made by email (and
possibly even discussed on-list) and the editor/author of the book can take
an executive decision and choose one if there are competing camps.
Possibly. From my own point of view, though, I'm usually only after fairly
simple snippets of code - certainly not enough for a book chapter (although
they could be grouped into chapters by topic).
Here's a slightly extended example: a key snippet for me would be execute a
query against a database and get the results. Naively, I see this as an IO
action, much like reading a file. So I'd expect something like
connect :: String - String - String - IO dbHandle
connect user password db = {- some magic to connect and give me a DB
handle -}
close :: dbHandle - IO ()
close dbh = {- magic to close the handle -}
query :: dbHandle - String - IO [String]
query dbh sql = {- more magic to do the query and return results -}
I'd use this as
do dbh - connect system manager my_oracle_db
results - query dbh select * from all_users
close dbh
return results
(I'd see it as being in the IO monad, so that I can intersperse other IO
actions. Maybe that's not necessary, but that's a different recipe - how do
I intersperse actions in 2 different monads - that I'd class as quite
advanced).
It's not remotely functional, it's likely not to be the best way and it's
probably making the advanced users squirm, but that's not the point. It fits
my beginner's mental model - I'm new to Haskell, I've grasped the concept of
IO and probably a little bit of how monads are great for structuring code
(I'd probably write my own auto-close control structure for this - and
soon after, find that it already exists!) but I'm not really worried. To me,
Haskell is brilliant for slinging data around in clever ways. So this is
just annoying boilerplate I need to get the data into my program - it
doesn't even have to be efficient, because I'm only grabbing a few tens of
rows here (getting data lazily would be a *separate* recipe, that I'd look
at for the million-row query I'll try once I feel like getting more
advanced).
The point of this is that to me, pulling data out of databases is *boring*.
The interesting bit is manipulating that data - and that's the bit that drew
me to Haskell because other languages make the data manipulation tedious and
boring as well. So I want easily tailorable snippets of code to get me past
the boring stuff - I'm busy learning interesting things elsewhere in Haskell
at the moment.
Of course, in the above you could easily substitute any number of tasks for
querying a database. Grabbing web pages, displaying a GUI, etc. The point
is the same - they aren't (yet) the interesting bit.
Sorry, that went on a bit - I hope it was useful nevertheless.
Paul.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
On 31/01/07, Michael T. Richter [EMAIL PROTECTED] wrote: I disagree with this part. Books written by committee lack cohesion unless they have an overbearing editor at the helm. While that might be a problem for a 'Haskell for the Working Programmer Book' it wouldn't be a problem at all for a Cookbook style book (which I believe is what the OP was referring to here) IMO. The point of the Cookbook is that all the 'recipes' should be self contained as far as is practical, they are 'dipping in' books rather than 'read right through' books, and in this case the cohesion isn't so important. As I understand it, the Python Cookbook (published by O'Reilly) was created in large part from user contributions ( http://aspn.activestate.com/ASPN/Python/Cookbook/ ). Rob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
Hello Steve, Friday, January 26, 2007, 10:03:09 PM, you wrote: Haskell _is_ hard, although I don't think it's _too_ hard, or I wouldn't ... The audience for programming languages like Haskell is always going to be small, because it appeals to those who want to understand how the TV works, i don't think so :) imho, we just don't have good _teachers_. in 70's, OOP audience was also small, but it was popularized later and now every student know about polymorphism via inheritance. but most of OOP programmers don't reinvent the wheels, they just use patterns described in OOP bestselling books i have a positive experience of making complex concepts easy and available for wide audience ([1]-[5]), [1] was even used to teach students in some college. and i guess that good Haskell books, such as yaht and printed ones, also make it easy to learn Haskell. but we need to gather much more attention to Haskell to make it as patternized as structured-programming and OOP. _nowadays_ there is no even one advanced Haskell or Haskell in Real World book and this means that anyone who want to learn Haskell in deep should study those terrible papers (well, it's very like higher education in Russia - no one really teaches you at our colleges so you should either learn yourself or die :) but this means that at least whose who still alive, are Real Machos :) the same apply to Haskell - now the only way to learn it is to learn yourself, so we all definitely are cool mans. once i even got C# job offer only because i know Haskell :) [1] http://haskell.org/haskellwiki/IO_inside http://haskell.org/haskellwiki/OOP_vs_type_classes http://haskell.org/haskellwiki/Modern_array_libraries http://haskell.org/bz/th3.htm http://haskell.org/bz/thdoc.htm -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
Hello Donald, Saturday, January 27, 2007, 10:18:44 AM, you wrote: I've never taken a graduate-level class in category theory, or any course on category theory, and I'm a Haskell implementor. So perhaps I haven't done any graduate level category theory either, and I hack Haskell 24/7! Let's form a union!! yes! we hate category theory!!! :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
Hello Kirsten, Saturday, January 27, 2007, 10:05:15 AM, you wrote: On the other hand, Meijer also has a PhD in computer science... is his judgment on Haskell's difficulty or lack thereof worthless, too? If not, then surely, judgments about whether Haskell is too hard can't have much to do with who has a PhD and who doesn't. let's count that he is implementor of another language ;) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
Hello Paul, Monday, January 29, 2007, 5:06:42 PM, you wrote: I'm very serious about the need for a Haskell for the Working Programmer book. And by this I mean a book and not a tutorial on some part of Haskell which proves difficult. Agreed. Something I can keep on my desk for reference, as well as browsing. how about developing a contents for this book and for cookbook? just a list of problems you want to learn how to solve. perhaps, then someone can fill some chapters. haskellwiki is a good place to start it -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
On Wed, 2007-31-01 at 03:25 +0300, Bulat Ziganshin wrote: I'm very serious about the need for a Haskell for the Working Programmer book. And by this I mean a book and not a tutorial on some part of Haskell which proves difficult. Agreed. Something I can keep on my desk for reference, as well as browsing. how about developing a contents for this book and for cookbook? just a list of problems you want to learn how to solve. perhaps, then someone can fill some chapters. haskellwiki is a good place to start it I disagree with this part. Books written by committee lack cohesion unless they have an overbearing editor at the helm. What I've seen on the Wiki as regards idioms, standard practices, etc. -- and this is true of every language wiki I've ever seen -- is one proposed answer and then a chain of but you could do it this way instead with ever-increasingly-obscure ways of doing things. Which would be the precise opposite of what a Haskell for the Working Programmer book should be like. A book like this should be clear, straightforward and provide an introduction to Haskell for a working programmer, but an introduction that gets said programmer up and on the job quickly. After using the (possibly even less than ideal) solutions provided in the book, the reader can then comfortably hone the newfound skills provided. I do like the idea of developing a table of contents first and backfilling it, though. I would amend the process, however, to avoid the WikiBloat that seems to inevitably follow when documentation projects get too open. Instead of Wikifying it, I'd suggest instead that a call for proposals be put on the mailing list. I'm working on a chapter dealing with database programming. I need to know how to do insert whatever in Haskell. Could anybody interested in helping please submit some commented, functioning code for possible inclusion? Then the submissions could be made by email (and possibly even discussed on-list) and the editor/author of the book can take an executive decision and choose one if there are competing camps. -- Michael T. Richter Email: [EMAIL PROTECTED], [EMAIL PROTECTED] MSN: [EMAIL PROTECTED], [EMAIL PROTECTED]; YIM: michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber: [EMAIL PROTECTED] I have never seen the poor people being so familiar with their heads of state as they were with [Michele Duvalier]. It was a beautiful lesson for me. I've learned something from it. --Mother Theresa signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
[I apologize for odd quoting, but I dislike sending html emails] I do like the idea of developing a table of contents first and backfilling it, though. I would amend the process, however, to avoid the WikiBloat that seems to inevitably follow when documentation projects get too open. Instead of Wikifying it, I'd suggest instead that a call for proposals be put on the mailing list. I'm working on a chapter dealing with database programming. I need to know how to do insert whatever in Haskell. Could anybody interested in helping please submit some commented, functioning code for possible inclusion? Then the submissions could be made by email (and possibly even discussed on-list) and the editor/author of the book can take an executive decision and choose one if there are competing camps. Instead of having someone work in solitude with occasional mailings back and forth on the list, I would rather have an open wiki for the collection of ideas from everyone. Then, if you really wanted, a single person can use those to create an 'editor edition' page that is only editable by them. Best of both worlds, or do you see it differently? -- Joe Re ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
On 29/01/07, Michael T. Richter [EMAIL PROTECTED] wrote: I started, given that I could actually have the free time now, looking at Haskell again about a year ago. (It's a major point in Haskell's favour that it always stuck around in my mind after first encountering and rejecting it, incidentally!) The documentation situation is better now, yes. Far better. But still not useful for people who are actively developing software in the C++/Java/C#/crap-solution-of-the-day daily grind. Now, at least, there actually *is* useful information. Finding it, however, takes up valuable time when you've got Yet Another Laughable Deadline ahead of you from your boss who is still unfamiliar with the Triangle of Quality (Fast = Cheap = Good : pick any two) and who has no patience for your strange ideas which you can't explain *because you yourself aren't sure of the ideas yet*. And I'm positive that this drives people off. I'm positive because it drove me off and I'm far more prone to experimentation with oddball technologies than most of the people I've ever worked with. Agreed. I'm in the same boat. I can't realistically use Haskell at work until I can pull together the building blocks *fast*. That means, half an hour grabbing a reference and fiddling a bit to get a trivial database query working. Another half hour checking up on how I bolt together the boilerplate needed to add logging to a server. Etc. It *has* to be possible to do this - I can do it in Python, or Perl, or even Java. So if I can't do it in Haskell, then I'm back stuck with one of those languages. I may not like it, but it's a practical reality in my job. I can try to learn at home (and I do!) but I don't have the same sort of issues at home, or the resources to simulate them (100+ databases running over a WAN that I need to query simultaneously, in parallel, just to provide viable response times, for example :-)). So home problems end up being toy problems, and I'm only learning for the intellectual exercise (a good reason, but not helping with work). I'm very serious about the need for a Haskell for the Working Programmer book. And by this I mean a book and not a tutorial on some part of Haskell which proves difficult. Agreed. Something I can keep on my desk for reference, as well as browsing. ... and closing with a cookbook of Haskell solutions to real-world problems (networking, database, general I/O, common algorithms, etc.) featuring Best Known Approaches (which remain, nonetheless approachable) to them. Yes, a cookbook approach is an excellent resource. It doesn't have to cover everything, but it needs to focus on practical problems, and just do this, and you're started solutions. The other thing that is needed, IMHO - and this is visibly improving, but can still get better - is availability and ease of use of libraries. I'd like to be able to just download a Windows binary for libraries I need - logging, DB access, HTTP, client access to Windows COM objects, a GUI framework, sending emails, etc ... Again, it's the I need it now issue - I can spend time searching out or even developing such things, but when I don't even have the time to write the code I need for my job (hence wanting a high-level language like Haskell to speed up development :-)) what chance do I have if I have to spend time locating libraries as well? Python does well here with its batteries included approach, and the cheeseshop package index. Perl has CPAN, but quality and ease of installation issues have hit me there in the past. Haskell seems to be getting there, but it feels to me like there's a critical mass point it still has to get over. But there's clearly an interest in the community for this type of thing, so I suspect it's only a matter of time. I'll stop rambling now. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
Frederick Ross wrote: here's my completely anecdotal view of the history of hard in programming... This history is accurate and insightful. ...when the kids... and the professors pretend that it was always this way... then they will grow up... Until then, I will continue to hear people say that [Haskell] is... scary It does not have to wait until then. And it should not. The resulting mess across the entire software industry would really be a shame. Haskell is _not_ inherently hard - any more than any other programming language. But it is different. So right now, Haskell is hard only because we need more documentation that is designed to make Haskell seem easy. Literature for university students sometimes needs to give the message: Things are not as easy as they look; you need to learn to think in new ways. Much of the Haskell literature is written in this style. Literature for programmers in industry needs to give the opposite message: This is easy, even fun. You can start getting real work done right away. And then, look at all of the advantages. This interview illustrates how much people are noticing Haskell of late - Haskell is hot. If there were more written in the second style, a lot more people would start using Haskell. I think it can be done. Some nice work has been done in this direction, but it is only a start. they characterize Haskell as being an impractical language, only useful for research... programming in Haskell is too hard... like assembly programming! These are people whose opinions should not be taken lightly. So then, how can they say these things that to us seem so obviously false? The answer, in my opinion, is that it's not the language. It's the documentation. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
On Fri, 2007-26-01 at 22:01 -0600, Collin Winter wrote: I find it incredibly insulting for you to assert that people who complain about Haskell's difficulty are too lazy and aren't really interested in a better solution. Maybe they just don't want to have to take graduate-level classes in category theory to get their job done. That would be a good way to think, yes. I look for practical solutions to real problems in my work. Haskell looks like it has these solutions, but extracting them from the noise level of ivory tower debates is a real problem. I think many of the users of Haskell forget that there are a lot of people out there who are not career academics working with pure mathematics day-in and day-out. My last math class? Was over fifteen years ago. And in, you know, the real world of programming you don't face mathematical problems as your bread and butter. You face problems in a messy world of too-short deadlines, too-few resources, too-poorly-communicated requirements and too-many-hours work. I would like to see a guide to Haskell that shows Haskell's place in those problems, not in Yet Another Elegant Mathematical Proof of the utterly useless in real life. Now given my privileged position of having escaped that ghetto of toos five years ago, I actually have the time and the energy to work this stuff out on my own. But your average working programmer? Just doesn't have the damned time to decode the arcane and obtuse wording and mathematics to get to what in the end turns out to be concepts verging on the trivial. (I'm looking at monads here) Maybe I'm the one that has to write the book Haskell for the Working Programmer sometime. You know. When I understand the language enough to write it. -- Michael T. Richter Email: [EMAIL PROTECTED], [EMAIL PROTECTED] MSN: [EMAIL PROTECTED], [EMAIL PROTECTED]; YIM: michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber: [EMAIL PROTECTED] I have never seen the poor people being so familiar with their heads of state as they were with [Michele Duvalier]. It was a beautiful lesson for me. I've learned something from it. --Mother Theresa signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
Hi, As I am taking a break from writing code and doing laundry, here are my thoughts. Restating the obvious: I agree with you that it is amazing how use of the word Monad has brought out so many people's feeling towards math. Obligatory disclaimer: Like many people, I have learned to write code in Haskell and I never took a course in Category theory. Nor do I have a CS degree. My math and physics degrees were not applicable to learning Haskell. I had never use a similar type system or type inferencing. The combination of the new type system and the new approach to IO took a little while to sink in. (I had learned BASIC, Pascal, Turbo Pascal with Objects, C, some Fortran, C++, Scheme, Java) But I think the biggest advance in Haskell is the explicit separation of IO operations enforced by the type system / compiler. Other languages may get type inference and may get closer to parametric polymorphism (java generics) and they may even get STM but they are unlikely to be able to evolve this IO separation and maintain much backward compatibility. Michael T. Richter wrote: On Fri, 2007-26-01 at 22:01 -0600, Collin Winter wrote: I find it incredibly insulting for you to assert that people who complain about Haskell's difficulty are too lazy and aren't really interested in a better solution. Maybe they just don't want to have to take graduate-level classes in category theory to get their job done. It is probably true that having such a course would let you directly understand the mathematical structure. But such understanding is different from knowing how to read and write Haskell programs. That would be a good way to think, yes. I look for practical solutions to real problems in my work. Haskell looks like it has these solutions, but extracting them from the noise level of ivory tower debates is a real problem. There are CS PhD people who publish papers and who talk about Haskell. These are largely irrelevant to reading and writing Haskell. Some papers are relevant to designing extensions to Haskell, but unless you are trying to build a new Haskell compiler extension these are not needed. I think many of the users of Haskell forget that there are a lot of people out there who are not career academics working with pure mathematics day-in and day-out. GHC seems to be developed by several people at Microsoft Research. They are not career academics. I am less familiar with the other compilers. For example: The latest extension proposal on haskell-cafe mailing list is about View patterns. This is all about making the code easier and clearer to write and to encourage interfaces that hide implementation details. That is about practical changes to help people and not about academics. My last math class? Was over fifteen years ago. And in, you know, the real world of programming you don't face mathematical problems as your bread and butter. If you have already created the algorithm or data structure then you are right. If you can simply reuse existing libraries and solutions you are right. But creating algorithms is a type of math. And Haskell exposes this better than most languages. You face problems in a messy world of too-short deadlines, too-few resources, too-poorly-communicated requirements and too-many-hours work. The bottom line: Learning Haskell without a background in similar languages takes time. If you cannot take that time from the world, then Haskell will be very hard to acquire. The previous post about educating the next generation at Universities makes the same point. Aside: One could make a good case that there there is a synergy between learning Haskell and learning the use the up and coming features of Visual Basic (LINQ) and C# (STM) and Java (Generics vs Type Classes and Parametric Polymorphism) and even Perl 6 (since it is taking so many ideas from Haskell). And thus taking the time to learn Haskell is useful. Haskell is not the one and only cutting edge source of such language features, but it does let you use many of them simultaneously and has good compilers available today. Note that I have not mentioned laziness. This is because it only helps to solve problems more elegantly -- other languages can model infinite computations / data structures when it is useful to do so. I would like to see a guide to Haskell that shows Haskell's place in those problems, not in Yet Another Elegant Mathematical Proof of the utterly useless in real life. Perhaps: http://haskell.org/haskellwiki/Why_Haskell_Matters There are many learning links at hakell.org, though many resources may be newer than when you learned Haskell: http://haskell.org/haskellwiki/Haskell_in_5_steps http://haskell.org/haskellwiki/Learning_Haskell (such as Haskell Tutorial for C Programmers) http://haskell.org/haskellwiki/Books_and_tutorials (such as Programming in Haskell published January 31, 2007) (such as
Re: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
Haskell is _not_ inherently hard - any more than any other programming language. But it is different. So right now, Haskell is hard only because we need more documentation that is designed to make Haskell seem easy. Well, I think it's harder to get a program compiled in Haskell than in Java, for example. It's not too hard, although debugging might be a little difficult. I think this has to do with the type system. Althought it sounds bad, it's actually a good thing. Once you get a Haskell program compiled, chances are much higher that it's correct. You do a bit more work up front, but chances of a bug are way lower. The way I see it, programming in Haskell is an investment. If you're from a OOP-background, some (trivial) things might take a lot more time. But in the end, it does make you more productive. You spend less time tracking bugs, and it's easier to refactor. Not everybody is willing to make an investment when they've got something that works. For example, if you know one imperative language, you can switch to another without taking too much risk. On the other hand, if you switch to a language that is completely different, you don't know if it will get your job done. It doesn't feel safe. -chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
On 1/28/07, Chris Kuklewicz [EMAIL PROTECTED] wrote: I think many of the users of Haskell forget that there are a lot of people out there who are not career academics working with pure mathematics day-in and day-out. GHC seems to be developed by several people at Microsoft Research. They are not career academics. I am less familiar with the other compilers. There's no need for the seems to be. The excellent History of Haskell paper: http://research.microsoft.com/~simonpj/papers/history-of-haskell/index.htm discusses the history of every extant Haskell compiler, in section 9. If I'm reading correctly, every one of these compilers (except possibly for jhc, it's not clear) began as an academic research project at a university -- that includes GHC, which was developed by academics at the University of Glasgow (hence the G in GHC), and it was only later that some of them moved to MSR. Be careful about conflating academic with not practical. It's true that academics haven't always had time to explain the useful, practical techniques they discover in ways that are understandable by programmers who don't have formal mathematical backgrounds (and be careful about conflating having a PhD with having mathematical background or experience, too). In the same way that programmers have jobs to do and thus have limited time to puzzle out new languages, academics have jobs that don't tend to reward them for spending time making those puzzles clearer to practitioners. As a challenge to everyone posting on this thread: rather than excoriating academia for its sins, why not start creating the documentation (or tutorials or libraries or applications) you wish to see? Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt No one's actually said 'O great America, thank you for saving us from the evil communist bug-eyed aliens, and, can we have fries with that?' yet have they? -- Debra Boyask ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
On Jan 26, 2007, at 23:01 , Collin Winter wrote: You have a PhD in computer science from Princeton, so your measure of what's hard and what isn't in this regard is nearly worthless. Uh, I don't have a degree, and discussions about mathy stuff like category theory generally go flying way over my head. Somehow I still managed to learn Haskell and seem to be getting fairly good at it. -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
On 1/26/07, Collin Winter [EMAIL PROTECTED] wrote: I find it incredibly insulting for you to assert that people who complain about Haskell's difficulty are too lazy and aren't really interested in a better solution. Maybe they just don't want to have to take graduate-level classes in category theory to get their job done. Maybe they want a solution that meets them half-way, one that doesn't require that they understand how to build their own resistors and capacitors in order to make their TV work again (to use your analogy). That's what Meijer means when he says that Haskell is too hard. I have an odd background in programming (never took a compsci class, did take a graduate computational physics course in my first year of undergrad, taught by an old nuclear physicist, who used nothing but Forth...beat that for bizarre), but since physicists represent an interesting conglomeration of snapshots of the mainstream of programming through the ages, I do have a bit of an archaeological perspective on how people think about hard. In case the following seems far fetched, let me assure you that four years ago I worked in a high energy physics group on a codebase of a few hundred thousand lines of FORTRAN 77, with no documentation. It had GOTOs. The folks working on this regarded C as a newfangled, difficult language, and some of them were still writing FORTRAN IV or RATFOR. So here's my completely anecdotal view of the history of hard in programming: In the beginning there was GOTO. Well, actually there was machine language, then assembler, but we'll skip that. GOTO was king. And then there was this movement among the ivory tower computer scientists called structured programming. It was considered difficult and complicated, with lots of hard concepts. And then the compsci departments made a concerted effort, taught a generation of students in the new style with no reference whatsoever to what came before. Structured programming suddenly became blasé. How else would you program? And then similar, though smaller and often partial repetitions of this break happened: designing nicer data structures when the Wirth languages came to their height; object oriented programming (which I regard as one of the great intellectual failures of programming). So when the kids are presented with exercises on functors, ADTs, and monads in intro compsci, and the professors pretend that it was always this way, there was never any other way, then they will grow up, they will go forth, and these will be the everyday things. Until then, I will continue to hear people say that map is a scary, unfamiliar object that makes the meaning of code obscure. -- Frederick Ross Graduate Fellow, (|Siggia + |McKinney)/sqrt(2) Lab The Rockefeller University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
On Fri, 26 Jan 2007 17:13:43 - (GMT), you wrote: world. It also highlights some of the misconceptions that still exist and need to be challenged, e.g. the idea that Haskell is too hard or is impractical for real work. Haskell _is_ hard, although I don't think it's _too_ hard, or I wouldn't be here, obviously. Haskell is hard in the sense that in order to take advantage of its ability to better solve your problems, you have to THINK about your problems a lot more. Most people don't want to do that; they want the quick fix served up on a platter. And even the intermediate camp, the ones who are willing to invest some effort to learn a better way, are only willing to go so far. My analogy for this is the Sams PHOTOFACT series (If you're not old enough to already know what these are, visit http://www.samswebsite.com/photofacts.html). With an appropriate Sams PHOTOFACT in hand, and some very basic skills with a voltmeter and maybe an oscilloscope, you can diagnose and repair your TV with virtually no understanding of electronics at all. The audience for programming languages like Haskell is always going to be small, because it appeals to those who want to understand how the TV works, perhaps to the extent of being able to modify an existing TV or even design one from scratch. And those kind of people are much fewer and farther between than those who simply want to localize the problem enough to be able to unplug the malfunctioning part and plug in a new one. It makes sense to publicize Haskell; you can't take advantage of something you've never heard of. But I think evangelical effort is largely wasted. The people who are going to gravitate towards Haskell are the ones who are already searching for something better (they just aren't sure what it is). The rest aren't really interested, and if at some future point they become interested, they'll find the way on their own. Steve Schafer Fenestra Technologies Corp. http:/www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
On 1/26/07, Steve Schafer [EMAIL PROTECTED] wrote: On Fri, 26 Jan 2007 17:13:43 - (GMT), you wrote: world. It also highlights some of the misconceptions that still exist and need to be challenged, e.g. the idea that Haskell is too hard or is impractical for real work. Haskell _is_ hard, although I don't think it's _too_ hard, or I wouldn't be here, obviously. Haskell is hard in the sense that in order to take advantage of its ability to better solve your problems, you have to THINK about your problems a lot more. Most people don't want to do that; they want the quick fix served up on a platter. And even the intermediate camp, the ones who are willing to invest some effort to learn a better way, are only willing to go so far. My analogy for this is the Sams PHOTOFACT series (If you're not old enough to already know what these are, visit http://www.samswebsite.com/photofacts.html). With an appropriate Sams PHOTOFACT in hand, and some very basic skills with a voltmeter and maybe an oscilloscope, you can diagnose and repair your TV with virtually no understanding of electronics at all. The audience for programming languages like Haskell is always going to be small, because it appeals to those who want to understand how the TV works, perhaps to the extent of being able to modify an existing TV or even design one from scratch. And those kind of people are much fewer and farther between than those who simply want to localize the problem enough to be able to unplug the malfunctioning part and plug in a new one. It makes sense to publicize Haskell; you can't take advantage of something you've never heard of. But I think evangelical effort is largely wasted. The people who are going to gravitate towards Haskell are the ones who are already searching for something better (they just aren't sure what it is). The rest aren't really interested, and if at some future point they become interested, they'll find the way on their own. You have a PhD in computer science from Princeton, so your measure of what's hard and what isn't in this regard is nearly worthless. I find it incredibly insulting for you to assert that people who complain about Haskell's difficulty are too lazy and aren't really interested in a better solution. Maybe they just don't want to have to take graduate-level classes in category theory to get their job done. Maybe they want a solution that meets them half-way, one that doesn't require that they understand how to build their own resistors and capacitors in order to make their TV work again (to use your analogy). That's what Meijer means when he says that Haskell is too hard. Collin Winter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
On 1/26/07, Collin Winter [EMAIL PROTECTED] wrote: You have a PhD in computer science from Princeton, so your measure of what's hard and what isn't in this regard is nearly worthless. I find it incredibly insulting for you to assert that people who complain about Haskell's difficulty are too lazy and aren't really interested in a better solution. Maybe they just don't want to have to take graduate-level classes in category theory to get their job done. I've never taken a graduate-level class in category theory, or any course on category theory, and I'm a Haskell implementor. So perhaps the people who think they need to taken graduate-level classes in category theory in order to use Haskell are barking up the wrong tree (or perhaps I'm not a very good Haskell implementor, which is always possible.) Maybe they want a solution that meets them half-way, one that doesn't require that they understand how to build their own resistors and capacitors in order to make their TV work again (to use your analogy). That's what Meijer means when he says that Haskell is too hard. On the other hand, Meijer also has a PhD in computer science... is his judgment on Haskell's difficulty or lack thereof worthless, too? If not, then surely, judgments about whether Haskell is too hard can't have much to do with who has a PhD and who doesn't. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Would you be my clock if I promise not to hang you / Too close to the window or the picture of the pope? / I won't set you back and I won't push you forward / I just want to look in your face and see hope -- Dom Leone ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
catamorphism: On 1/26/07, Collin Winter [EMAIL PROTECTED] wrote: You have a PhD in computer science from Princeton, so your measure of what's hard and what isn't in this regard is nearly worthless. I find it incredibly insulting for you to assert that people who complain about Haskell's difficulty are too lazy and aren't really interested in a better solution. Maybe they just don't want to have to take graduate-level classes in category theory to get their job done. I've never taken a graduate-level class in category theory, or any course on category theory, and I'm a Haskell implementor. So perhaps the people who think they need to taken graduate-level classes in category theory in order to use Haskell are barking up the wrong tree (or perhaps I'm not a very good Haskell implementor, which is always possible.) I haven't done any graduate level category theory either, and I hack Haskell 24/7! Let's form a union!! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
