Wer ein Python-Buch geschrieben hat, weiss wie viel Arbeit dahinter steckt. Das Buch eines Kollegen als "Muell" zu bezeichnen kaeme einem Autor i.d.R. gar nicht erst in den Sinn.Peter Gerlach hat geschrieben:Also ein Buch als "Müll" abzutun sollte nur dem zustehen, der selbst ein besseres Buch geschieben hat.
Es inhaltlich gezielt zu kritisieren aber schon, aber das ist was ganz Anderes.Nein, sicher nicht.Peter Gerlach hat geschrieben:Also ein Buch als "Müll" abzutun sollte nur dem zustehen, der selbst ein besseres Buch geschieben hat.
Außnahmen gibt es natürlich immer, aber ich denke schon, dass zumindest Falschinformationen in Büchern die mit der Community entstehen seltener sind. Hängt natürlich auch von der Community ab.farid hat geschrieben:Es gibt aber auch community-driven Buecher, oder Buecher von aktiven community Mitgliedern, die nicht halten was sie versprechen.
Habe es selbst nicht gelesen aber ich war auf einem Treffen der RZUG wo das bei vielen auf dem Tisch lag und die es empfohlen haben. Daneben auch Web Component Development with Zope 3, wo der Autor wie mir scheint auch ziemlich in der Community drin steckt.farid hat geschrieben:Wie findest Du z.B. "Professional Plone Development"?
Es hängt auch immer ab, was man für einen Umfang haben will. Meiner Meinung nach ist es zumindest vom Sichtpunkt der Qualität gesehen sinnvoller ein Buch kürzer zu machen. Den Fehler halte ich Programming Python vor, das schlicht zu dick. Wenn man das durchgelesen hat, hat man einen Haufen unnötiges Wissen im Kopf und Zeit verschwendet die bei einem Buch was ein Drittel so lang wäre zu zwei dritteln in das Schreiben von Code investieren könnte. Das ist wohl zumindest ein Stück weit auch für das Galileo-Buch der Fall. Django zu behandeln finde ich schlicht überflüssig, zudem es sich ja immer ändert und womit auch schon die dedizierten Django-Bücher Probleme haben. Es sieht nur eben verlockend für Käufer aus wenn man um 40€ ein Buch mit 819 Seiten bekommt, verglichen mit wirklich großartigen Büchern wie dem Little Schemer, welches eher dünn für die geforderten 25€ ist. Ich ertappe mich auch regelmäßig dabei den Trugschluss umfassender ist besser zu ziehen.farid hat geschrieben:aber hmmm... wie soll ich sagen: es ist alles andere als ein Lehrbuch.
Für ein Anfänger-Buch: ja. Allerdings sehe ich bei den Autoren des Galileo-Buches auch kein solches Team, obwohl es sich an Anfänger richtet. Ich lese gerne was Matthias Felleisen dazu schreibt, in der PLT-Mailingliste bekommt man so etwas bei einigen Diskussionen manchmal mit.farid hat geschrieben:Ideal sind IMHO Buecher, die von Autoren-Tandems geschrieben werden: einer der Autoren sollte aktiver Entwickler sein, der die Materie 200% beherrscht und waehrend des Schreibens auch das Programm verbessert ueber das er schreibt; und der andere Autor sollte mehr didaktisch veranlagt sein, und auch nicht sooo tief in der Materie stecken, um Newbies nicht ganz aus dem Blickfeld zu verlieren.
Ja, das stimmt. Apress macht sowas manchmal, MIT Press auch, von O'Reilly ist mir so etwas gänzlich unbekannt.farid hat geschrieben:Insgesamt gehe ich davon aus, dass Buecher zu OSS in Zukunft immer haeufiger als open books entstehen werden. Aber noch sind das die wenigsten (loeblichen) Ausnahmen.
http://97-things.near-time.net/wiki `97 Things Every Software Architect Should Know' Wie weit das allerdings von O'Reilly ausgeht kann ich nicht sagen, sondern nur, dass die das eben veröffentlichenLeonidas hat geschrieben:Ja, das stimmt. Apress macht sowas manchmal, MIT Press auch, von O'Reilly ist mir so etwas gänzlich unbekannt.
Ja, es gibt auch die Cookbook-Serie, wo der Code aus dem Internet geholt ist. Das Buch allerdings hat noch weitere Beschreibungen und ist nicht frei verfügbar.cofi hat geschrieben:Wie weit das allerdings von O'Reilly ausgeht kann ich nicht sagen, sondern nur, dass die das eben veröffentlichen
Das finde ich auch. Wobei in diesen beiden Buechern es nicht die Dicke an sich, die mich persoenlich stoerte, sondern die fehlende Informationsdichte: was man in 2 oder 3 Seiten erklaeren kann muss man nicht unbedingt auf 10 Seiten ausdehnen.Leonidas hat geschrieben:Es hängt auch immer ab, was man für einen Umfang haben will. Meiner Meinung nach ist es zumindest vom Sichtpunkt der Qualität gesehen sinnvoller ein Buch kürzer zu machen. Den Fehler halte ich Programming Python vor, das schlicht zu dick. Wenn man das durchgelesen hat, hat man einen Haufen unnötiges Wissen im Kopf und Zeit verschwendet die bei einem Buch was ein Drittel so lang wäre zu zwei dritteln in das Schreiben von Code investieren könnte. Das ist wohl zumindest ein Stück weit auch für das Galileo-Buch der Fall.
Hmmm... das sehe ich anders. Die Frage ist immer, wie ausfuehrlich man es vorstellt. Wenn Django z.B., sagen wir mal, 20 Seiten in einem 800 Seiten Buch einnimmit und in Form eines einfuehrenden Tutorials dargestellt wird, kann man es auch so praesentieren, dass es trotz geringfuegiger API-Aenderungen immer noch eine interessante Ergaenzung darstellt.Leonidas hat geschrieben:Django zu behandeln finde ich schlicht überflüssig, zudem es sich ja immer ändert und womit auch schon die dedizierten Django-Bücher Probleme haben.
Full ack!Leonidas hat geschrieben:Es sieht nur eben verlockend für Käufer aus wenn man um 40€ ein Buch mit 819 Seiten bekommt, verglichen mit wirklich großartigen Büchern wie dem Little Schemer, welches eher dünn für die geforderten 25€ ist. Ich ertappe mich auch regelmäßig dabei den Trugschluss umfassender ist besser zu ziehen.
Ich finde das Ding äußerst toll und lerne daran Plone. Der kurze Umfang ist so in Ordnung, es steht ja alles drinn.farid hat geschrieben:Im Prinzip hast Du recht.
Es gibt aber auch community-driven Buecher, oder Buecher von aktiven community Mitgliedern, die nicht halten was sie versprechen.
Wie findest Du z.B. "Professional Plone Development"?
Ich hatte es mal paar Monate auf dem Schreibtisch liegen und bin nicht so sehr damit warm geworden. Ich habe im Regal noch "Scheme and the Art of Programming", was bis auf dass es etwas alt ist gar nicht so übel ist. Vielleicht sollte ich mir noch "How to Design Programs" ansehen, da kann man vermutlich noch den ein oder anderen Trick lernen.farid hat geschrieben:A propos Scheme: bist Du auch ein Fan von SICP (Wizard Book)?
Ich bin halt bis heute nicht durch ...Leonidas hat geschrieben:Ich hatte es mal paar Monate auf dem Schreibtisch liegen und bin nicht so sehr damit warm geworden.farid hat geschrieben:A propos Scheme: bist Du auch ein Fan von SICP (Wizard Book)?
Eli Bendersky schon, interessant sind auch seine Notizen dazu, such' im Blog einfach nach SICP.Craven hat geschrieben:Ich bin halt bis heute nicht durch ...
Ich bin ohne Vorkenntnisse in Scheme bzw. LISP überhaupt rangegangen und mein Verständnis hat dann quadratisch abgenommen.Leonidas hat geschrieben:Wenn man es als Scheme-Tutorial versteht, dann wird man enttäuscht.
Da bin ich momentan auch dabei das Verständnis zu verbessernCraven hat geschrieben:Ich bin ohne Vorkenntnisse in Scheme bzw. LISP überhaupt rangegangen und mein Verständnis hat dann quadratisch abgenommen.
Naja, die RnRS waren ja als Tutorials schon nicht schlecht...Craven hat geschrieben:Wobei ich zugeben muss, dass ich falsch an das Buch rangegangen bin. Wenn man es als Scheme-Tutorial versteht, dann wird man enttäuscht. Vielleicht sollte ich mir beizeiten zumindest die Videos ansehen.
SICP selbst war nie als Scheme-Tutorial gedacht, sondern als grundlegende Einfuehrungsvorlesung von CS/EE Kursen (nicht nur beim MIT). Scheme wird da nur als Vehikel benutzt, um die Grundkonzepte zu zeigen. Spaetestens bei Kapitel 4 (Metalinguistic Abstraction), zeigt sich, dass Scheme eine sehr gute Wahl war.
