Re: [Catalyst] Re: So, what do we want in the -next- book?
On Mon, Apr 28, 2008 at 7:29 AM, Jonathan Rockway [EMAIL PROTECTED] wrote: 2) Learn how to use Catalyst (read my book) Sorry to say this, but your book is not a good book! I cannot in good faith recommend it to anyone. Please consider believing the bad review your book got, because they are correct. One of the reasons we need a second book, is that because your book was so bad. People right away started asking and hoping for a second book. Please read this review: http://dave.org.uk/reviews/catalyst.html Dave is being too nice to you, blaming the publisher. The good reviews your book got where from nice people who were excited catalyst got a book, any book, doesn't matter how poorly written it is. Dont believe me: http://www.amazon.com/review/product/1847190952/ref=cm_cr_pr_helpful Your book reviews ordered by most helpful first! The bad reviews come first! ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: So, what do we want in the -next- book?
* Jonathan Rockway [EMAIL PROTECTED] [2008-04-28 06:40]: Am I the only person here that has ever started a job and had to just dive into the code, code without docs or tests? I assume not, but nobody is asking your boss to write a book about how your internal code works. You just dive in and understand it. Just because largely undocumented internal codebases are the norm doesn’t mean they are an inevitable fate. Anything that takes more than a week of effort requires a design document, with specific sections that have to be filled out, and with feedback from primary and secondary reviewers of your choice. The net result is that for any significant piece of code at Google, you can find almost a whole book about it internally, and a well-written one at that. —Steve Yegge But in any case, most companies are not in the business of creating free software libraries that hope to attract programmers as users and contributors, so the comparison is a category error to begin with. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: So, what do we want in the -next- book?
* On Mon, Apr 28 2008, Ali M. wrote: On Mon, Apr 28, 2008 at 7:29 AM, Jonathan Rockway [EMAIL PROTECTED] wrote: 2) Learn how to use Catalyst (read my book) Sorry to say this, but your book is not a good book! I cannot in good faith recommend it to anyone. Please consider believing the bad review your book got, because they are correct. One of the reasons we need a second book, is that because your book was so bad. People right away started asking and hoping for a second book. Now I can see why people are lining up to write another book. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: So, what do we want in the -next- book?
Jonathan Rockway wrote: * On Mon, Apr 28 2008, Ali M. wrote: Sorry to say this, but your book is not a good book! One of the reasons we need a second book, is that because your book was so bad. People right away started asking and hoping for a second book. Now I can see why people are lining up to write another book. Except that the views expressed by Ali M are pretty extreme, and I would say do not reflect the view of most contributors to this list, whether sympathetic to your efforts or not. Many people (myself included) might like to see another book to *extend* yours - the question of course is what form it should take. But such sour contributions, which actually contribute so very little to the debate, should not be weighed in the same balance as the many substantially more reasoned arguments already put. -- Richard Jones ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: So, what do we want in the -next- book?
* J. Shirley [EMAIL PROTECTED] [2008-04-27 19:30]: If you want to know the internals of catalyst, do as Jonathan said and fire up a code browser and get started. Putting together a map of a mountain by examining it one pebble at a time is not particular efficient nor easy. Did you ever notice that the only people who say this are the ones who already know the code intimately? Alternatively, just read the pod for all the Catalyst components; they are very well documented and easy to understand. Easy to say when you’ve been on personal terms with the codebase throughout its evolution. For someone completely new to the code, things are far less obvious. As I try to make sense of the codebase I keep stumbling over places where the setup is quite incestuous: components often do not really set themselves up, they are just glorified structs that expect whoever instatiates them to do all the work. Which expectation is nowhere to be found in the docs – so much for “well documented.” In OO design terms, this is really crummy. There is also a lot of indirection – for good reason, of course, but readability suffers from it just the same. As a result, a lot of the code is not nearly as self-contained as it could be, which means that you need to already understand a lot of the codebase before you can understand most of the codebase. It’s by no means an insurmountable task (which is a happy side effect of the modest size of the codebase and not in any way a property of the design itself), but it would be miles easier if there was a high-level overview of the architecture. If no one else does write such a thing, I will, once I’ve come out the other side. Depending on the extent of the task, it might also lead to a patch or two to untangle and isolate parts of the code from each other, although I’m not sure how far this can be taken while respecting the stability/backcompat imperative. But in the meantime please quit shifting the laziness blame to the users. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: So, what do we want in the -next- book?
On Sun, Apr 27, 2008 at 11:05 AM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: * J. Shirley [EMAIL PROTECTED] [2008-04-27 19:30]: If you want to know the internals of catalyst, do as Jonathan said and fire up a code browser and get started. Putting together a map of a mountain by examining it one pebble at a time is not particular efficient nor easy. Mapping a mountain when you need a mole hill is equally silly of an analogy. I don't think we need analogies to make our points. If you think that reading the Catalyst source is too much work, do as I said and read the pod for the packages in the Catalyst-Runtime dist. Did you ever notice that the only people who say this are the ones who already know the code intimately? And... most people with enough energy have read it in the course of a weekend. It really isn't that complex to read the core bits. When you get into the attributes things get a bit more hairy. Alternatively, just read the pod for all the Catalyst components; they are very well documented and easy to understand. Easy to say when you've been on personal terms with the codebase throughout its evolution. For someone completely new to the code, things are far less obvious. Nonsense. I read the pod for the packages in Catalyst-Runtime (well, before the split) before I ever looked at the Catalyst source.It is very simple. Keep in mind, all of my points are about people _requesting_ to learn the internals of Catalyst. These are the best resources, period. If people don't want to read source or pod, they do not really want to know the internals. As I try to make sense of the codebase I keep stumbling over places where the setup is quite incestuous: components often do not really set themselves up, they are just glorified structs that expect whoever instatiates them to do all the work. Which expectation is nowhere to be found in the docs – so much for well documented. In OO design terms, this is really crummy. Funny, I think that new vs. COMPONENT time is pretty well documented. There is a document for Internals. http://search.cpan.org/~mstrout/Catalyst-Manual-5.701004/lib/Catalyst/Manual/Internals.pod While I agree that the design (in terms of pure OO) isn't the best, it does work and I think it does make plenty of sense. If you look at the debug output on server startup, you can easily figure out what is being loaded and how. There is also a lot of indirection – for good reason, of course, but readability suffers from it just the same. As a result, a lot of the code is not nearly as self-contained as it could be, which means that you need to already understand a lot of the codebase before you can understand most of the codebase. Right. If you want to understand the codebase you will have to understand the codebase. My point is that people may think they need to understand the codebase when in fact they just need to not be lazy and write better code. It's by no means an insurmountable task (which is a happy side effect of the modest size of the codebase and not in any way a property of the design itself), but it would be miles easier if there was a high-level overview of the architecture. If no one else does write such a thing, I will, once I've come out the other side. Depending on the extent of the task, it might also lead to a patch or two to untangle and isolate parts of the code from each other, although I'm not sure how far this can be taken while respecting the stability/backcompat imperative. But in the meantime please quit shifting the laziness blame to the users. If a user wants to know the internals without reading any code, they are lazy. Pure and simple. This thread is about what goes into the next book. I offered a collaboration and proffered points as to why I think the idea of documenting the internals in the form of a book is not a good idea. Your disagreements(?) above are more about the difficulties in understanding the internals, but that doesn't really address the point that I brought up about the quality of a book discussing said internals. Then you call it laziness blame. That's pretty confusing, to be honest. I think that it is far more work to collaborate between Jifty, Catalyst, the various ORM guys and whoever else is relevant on a BPB for Web apps, which seems to me to be a better book (both for the publishers, authors and readers). It's obviously something that could be broken into multiple volumes (Frameworks, ORMs, General Design in a Perl way, etc). But to think that the internals need a deadtree version, that's silly. Internals should be in .pod; for developers by developers -- not users. -J ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site:
[Catalyst] Re: So, what do we want in the -next- book?
* J. Shirley [EMAIL PROTECTED] [2008-04-27 23:45]: On Sun, Apr 27, 2008 at 11:05 AM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: As I try to make sense of the codebase I keep stumbling over places where the setup is quite incestuous: components often do not really set themselves up, they are just glorified structs that expect whoever instatiates them to do all the work. Which expectation is nowhere to be found in the docs – so much for well documented. In OO design terms, this is really crummy. Funny, I think that new vs. COMPONENT time is pretty well documented. There is a document for Internals. http://search.cpan.org/~mstrout/Catalyst-Manual-5.701004/lib/Catalyst/Manual/Internals.pod I’m not talking about COMPONENT. I’m talking about classes with accessors for which they never set a value themselves. I don’t remember specific examples since it was two or three weeks ago, but it had to do with the dispatcher, and I stumbled this way in two or three places when I didn’t have time to read the entire source, so I gave up and switched to a different approach. While I agree that the design (in terms of pure OO) isn't the best, it does work and I think it does make plenty of sense. If you look at the debug output on server startup, you can easily figure out what is being loaded and how. Yes, as I said, one can certainly figure out the code. There’s just no reason it couldn’t and shouldn’t be easier, and I mean for those who are willing to read source. I say so particularly because it’s not as easy as it should be to understands parts of Catalyst in isolation. My point is that people may think they need to understand the codebase when in fact they just need to not be lazy and write better code. That seems a little weird, but I think I can follow the logic, and if I am following, then that is true, but not directly relevant to my (itself tangential) point. If a user wants to know the internals without reading any code, they are lazy. Pure and simple. If they want to know in detail, sure. Are you also saying they *should not* even *want* to have an overview of the architecture if they are not interested in every last detail? This thread is about what goes into the next book. […] To think that the internals need a deadtree version, that's silly. Internals should be in .pod; for developers by developers -- not users. OK, yes, that got mixed up a bit. I wasn’t really arguing about the book; mainly about the fact that there needs to be more and better POD. I certainly do NOT mean that the internals warrant an entire dedicated book. However, it would definitely make sense to have a chapter on the internals in a Catalyst book. If it was a generic Perl webapps book, then I agree it doesn’t make sense for that. Then you call it laziness blame. That was not about the book at all. Sorry for the confusion. I was addressing the oft-repeated assertion that users who ask for an architectural overview should just man up and read the source. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: So, what do we want in the -next- book?
On Sun, Apr 27, 2008 at 5:19 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: I'm not talking about COMPONENT. I'm talking about classes with accessors for which they never set a value themselves. I don't remember specific examples since it was two or three weeks ago, but it had to do with the dispatcher, and I stumbled this way in two or three places when I didn't have time to read the entire source, so I gave up and switched to a different approach. Agreed on some parts, but it is getting better. That's the sort of thing that is patches welcome and I think the Moose work will help that (or hurt it, I suppose we'll have to see). 5.8 ftw! While I agree that the design (in terms of pure OO) isn't the best, it does work and I think it does make plenty of sense. If you look at the debug output on server startup, you can easily figure out what is being loaded and how. Yes, as I said, one can certainly figure out the code. There's just no reason it couldn't and shouldn't be easier, and I mean for those who are willing to read source. I say so particularly because it's not as easy as it should be to understands parts of Catalyst in isolation. I guess my point is that in my experience with similarly complex code bases, I've found Catalyst better than average in nearly every aspect. There are a few rusty nails poking out, but by and large one can get a good overview just by reading Pod (I think that Catalyst::Manual::Internal and ::ExtendingCatalyst give most of what people would want to know). My point is that people may think they need to understand the codebase when in fact they just need to not be lazy and write better code. That seems a little weird, but I think I can follow the logic, and if I am following, then that is true, but not directly relevant to my (itself tangential) point. I wasn't really sure what your point was, but the second email clarified some points. My point is that the market for people who actually _need_ (or, have the aptitude to properly grasp what they are learning) is minuscule. The vast majority want to write better applications, but you don't need to know the details of the tool you use in order to utilize it well. Anything that can be done to debunk the mysticism of Catalyst is a good thing, in my opinion. Far too many people hold the opinion Catalyst internals do something magic when in reality it is just perl. Aside from some of the accessors that you've brought up earlier, and the method attributes, everything is quite straight forward. People still don't _need_ to know this stuff to write killer applications. What they _need_ to know is how to write good code, and that is a separate issue from Catalyst. If a user wants to know the internals without reading any code, they are lazy. Pure and simple. If they want to know in detail, sure. Are you also saying they *should not* even *want* to have an overview of the architecture if they are not interested in every last detail? I think they're two separate things. An overview of what architecture? The dispatch cycle or initialization? What MVC really means? Why you shouldn't write a plugin? Too many questions and far too many answers, many of which are opinions. This thread is about what goes into the next book. […] To think that the internals need a deadtree version, that's silly. Internals should be in .pod; for developers by developers -- not users. OK, yes, that got mixed up a bit. I wasn't really arguing about the book; mainly about the fact that there needs to be more and better POD. I certainly do NOT mean that the internals warrant an entire dedicated book. However, it would definitely make sense to have a chapter on the internals in a Catalyst book. If it was a generic Perl webapps book, then I agree it doesn't make sense for that. If there is a next book, I can see an Extending Catalyst chapter but I still don't see the need for an Internals. Outside of the initialization steps and component base classes, I don't think it would help many users. I tend to see Extending Catalyst as a very very separate thing than Internals though, mainly because I hope one can extend Catalyst without ever having to read Catalyst source. That's a separate mailing list thread though (which, afaik, doesn't exist). Then you call it laziness blame. That was not about the book at all. Sorry for the confusion. I was addressing the oft-repeated assertion that users who ask for an architectural overview should just man up and read the source. I suppose my statements on the contrary are more along the lines of Read the POD first. If they have questions after that, I think many people would be happy to answer them in exchange for some pod patches. I think that there should be a completely documented manual segment about extending Catalyst. But for Internals... you can't know it without reading the source, and I
Re: [Catalyst] Re: So, what do we want in the -next- book?
Books can be made big, I just checked my copy of Perl Cookbook and its almost 900 pages If there is a new Catalyst Book, I think the book can have the first 100 -150 or so pages explaining how catalyst work + some nice diagrams of how the pieces fit together + the much asked for how are subroutines attributes are use And the ramaining 800 pages can be cookbook-ish. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: So, what do we want in the -next- book?
On Mon, 28 Apr 2008, Aristotle Pagaltzis wrote: I’m not talking about COMPONENT. I’m talking about classes with accessors for which they never set a value themselves. I don’t remember specific examples since it was two or three weeks ago, but it had to do with the dispatcher, and I stumbled this way in two or three places when I didn’t have time to read the entire source, so I gave up and switched to a different approach. A good example is Catalyst::Request. Several other classes poke into it's internal hashref, including Catalyst.pm and Catalyst::Engine. It's pretty nasty. I think the Catalyst 5.8x+Moose branch has improved this a bit. -dave /*== VegGuide.Org Your guide to all that's veg ==*/___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: So, what do we want in the -next- book?
* On Sun, Apr 27 2008, Aristotle Pagaltzis wrote: * J. Shirley [EMAIL PROTECTED] [2008-04-27 19:30]: If you want to know the internals of catalyst, do as Jonathan said and fire up a code browser and get started. Putting together a map of a mountain by examining it one pebble at a time is not particular efficient nor easy. Did you ever notice that the only people who say this are the ones who already know the code intimately? Yeah, and we all learned it from a super secret book we're not sharing. Here's how to learn the catalyst internals: 1) Learn how to use OO Perl (read Intermediate Perl) 2) Learn how to use Catalyst (read my book) Now you know how the pieces of Catalyst fit together, and you know what OO is. You're halfway there. Now you figure out what you want to know. Hmm, I wonder how the :Local attribute works. Now you grep for Local and find _parse_Local_attribute. Then you follow that path until you understand it. If statically reading the code doesn't do it for you, stick in a breakpoint (or Carp::REPL) and start your app. When you're in there, poke the data structures until you understand them. Then continue reading the source. Another good thing to do is try to add a new feature. It's not going to be easy the first time, but that's the point of practicing. You're not going to get good by reading books. You're going to get good by reading the source. Finally, a book about the internals might be worthwhile if we were sure that This Is The Best Way To Do Things, but Catalyst isn't. It's *a* way that works, but certainly not the best. If you want to read about the best read some of Knuth's books. TeX is a literate program. Alternatively, just read the pod for all the Catalyst components; they are very well documented and easy to understand. Easy to say when you’ve been on personal terms with the codebase throughout its evolution. For someone completely new to the code, things are far less obvious. Am I the only person here that has ever started a job and had to just dive into the code, code without docs or tests? I assume not, but nobody is asking your boss to write a book about how your internal code works. You just dive in and understand it. Diving into Catalyst is even easier, because it has docs, tests, and thousands of working applications that use it. (Search CPAN for catalyst. Lots of people have figured it out.) As I try to make sense of the codebase I keep stumbling over places where the setup is quite incestuous: components often do not really set themselves up, they are just glorified structs that expect whoever instatiates them to do all the work. Which expectation is nowhere to be found in the docs – so much for “well documented.” In OO design terms, this is really crummy. As I said above... yeah... Catalyst sucks. It is not God's Gift To The World. It's some useful code that works. But in the meantime please quit shifting the laziness blame to the users. People are responsible for themselves. If they want to understand something, they can't expect understanding to be handed to them on a silver platter. They will just have to dive in and try to understand. It's called programming. Anyway, if someone wants to pay me $250/hr to document Catalyst's internals, I'll do it. But I bet you'll find that it's not worth it. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: So, what do we want in the -next- book?
Kinda opposed to popular demand,
I would like the next book to be the equivilant of the camel book
programming perl .
I would like to know how Catalyst Work, so I can better figure things
on my one, instead of the desired receipe approach of a cookbook
I would like to learn the concepts behind catalyst.
I documentation if not great in this area, and I read the TOC and free
sample chapter of the first book, and it also seem to follow a receip
approach telling me the steps, but not explain in enough detail how
things work? and why?
So I want a theory and concept book, and I promise to buy it!
On Fri, Apr 4, 2008 at 6:22 PM, Lance A. Brown [EMAIL PROTECTED] wrote:
Ash Berlin said the following on 4/4/2008 8:37 AM:
Moose is in there for InstancePerContext, so that you can do:
$c-model('File')-cd('foo/bar');
$c-model('File'')-slurp('file.txt');
to access the contents of $configured_root_dir/foo/bar/file.txt.
I could have written the ACCEPT_CONTEXT sub myself, but DRY and all that.
And I'd like to say a nice public Thank You! for writing C::M::File. It
made an app I'm writing much easier. :-)
--[Lance]
--
GPG Fingerprint: 409B A409 A38D 92BF 15D9 6EEE 9A82 F2AC 69AC 07B9
CACert.org Assurer
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: So, what do we want in the -next- book?
* Ali M. [EMAIL PROTECTED] [2008-04-06 12:35]: I would like to know how Catalyst Work, so I can better figure things on my one, instead of the desired receipe approach of a cookbook ++ I think this is a massive hole in the Catalyst documentation in general. I try to read the source and figure it out as I go, but that’s far more time-consuming and slow a process than it needs to because no big-picture map of the source exists. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: So, what do we want in the -next- book?
Ash Berlin said the following on 4/4/2008 8:37 AM:
Moose is in there for InstancePerContext, so that you can do:
$c-model('File')-cd('foo/bar');
$c-model('File'')-slurp('file.txt');
to access the contents of $configured_root_dir/foo/bar/file.txt.
I could have written the ACCEPT_CONTEXT sub myself, but DRY and all that.
And I'd like to say a nice public Thank You! for writing C::M::File.
It made an app I'm writing much easier. :-)
--[Lance]
--
GPG Fingerprint: 409B A409 A38D 92BF 15D9 6EEE 9A82 F2AC 69AC 07B9
CACert.org Assurer
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: So, what do we want in the -next- book?
* Ali M. [EMAIL PROTECTED] [2008-03-27 13:45]: Education (or knowledge depending on how you translate it) is As Indispensable As Water and Air -- Taha Hussein (an Egyptian scholar) I’m not sure why you’re quoting this, because the water I drink is certainly not free, and my education cost both the taxpayer and myself plenty of money. I’m sure the situation is similar for most participants on this mailing list. One of the maing benefits of Free Software is Free education, I don't understand when a Free Software proponent do not also support just as much free education in the form of free docs and books No one is stopping you from doing that. No one is forcing you to buy the book. What is your problem? Your sense of entitlement? Are you trying to say Jonathan should not have written the book if he didn’t want to publish it for free? If so, have you stopped to consider whether that attitude serves Catalyst? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: So, what do we want in the -next- book?
Ali M. said the following on 3/27/2008 8:29 AM: Education (or knowledge depending on how you translate it) is As Indispensable As Water and Air -- Taha Hussein (an Egyptian scholar) One of the maing benefits of Free Software is Free education, I don't understand when a Free Software proponent do not also support just as much free education in the form of free docs and books Perhaps 'cause food and drink costs money. :-) Dude's gotta make a buck somehow. --[Lance] -- GPG Fingerprint: 409B A409 A38D 92BF 15D9 6EEE 9A82 F2AC 69AC 07B9 CACert.org Assurer ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
