Fashion Sale Hier klicken Kinderfahrzeuge 1503935485 Cloud Drive Photos UHD TVs Learn More sommer2016 roesle Hier klicken Fire Shop Kindle Autorip Summer Sale 16 PrimeMusic
Profil für Dr. Chrilly Donninger > Rezensionen

Persönliches Profil

Beiträge von Dr. Chrilly Do...
Top-Rezensenten Rang: 1.080
Hilfreiche Bewertungen: 2060

Richtlinien: Erfahren Sie mehr über die Regeln für "Meine Seite@Amazon.de".

Rezensionen verfasst von
Dr. Chrilly Donninger "vulgo Chrilly" (Altmelon, Waldviertel)

Anzeigen:  
Seite: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11-20
pixel
Automatic Exchange Betting: Automating the Betting Process-From Strategy to Execution
Automatic Exchange Betting: Automating the Betting Process-From Strategy to Execution
von Colin Magee
  Taschenbuch
Preis: EUR 55,87

1 von 1 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen Detaillierte Beschreibung eines autonomen Pferdebots, 7. Juni 2014
Verifizierter Kauf(Was ist das?)
Der Autor hat mit Hilfe von Perlskripts einen vollständig automatisierten Bot für Betfair Pferdewetten entwickelt. Das Buch ist eine detaillierte Beschreibung dieser Skripts. Am Anfang fand ich den Text etwas mühsam und zäh. Es hat mir allerdings von Kapitel zu Kapitel besser gefallen. Am Ende war ich von der sorgfältigen Arbeit des Autors beeindruckt.
Die prinzipielle Logik des Bots ist sehr einfach gestrickt. Man lädt sich von freien und professionellen Quellen die Bewertung der Pferde herunter. Aus diesen Bewertungen werden Odds erstellt. Diese werden mit den Betfair-Preisen verglichen. Wenn der Betfair-Preis höher ist, setzt man auf das Pferd. Wobei Auswahl auf das oberste Drittel der Rangliste beschränkt ist.
Trotz dieser einfachen Grundstruktur ist der Aufwand für ein voll automatisiertes System erheblich. Magee geht auch auf die Mühen der Ebene ein. Z.B. ist die Schreibweise von Pferden nicht einheitlich. Er beschreibt auch sehr ausführlich den Testprozess und nebenbei die Leiden des Botentwicklers wenn sein Geisteskind erratisch vom grünen in den roten Bereich und wieder zurück wechselt. Ich kenne dieses Gefühl sehr gut aus meiner langjährigen Tätigkeit als Computerschach Profi.
Wie Magee im Buch auch betont, nützt der Bot nicht die vollen Möglichkeiten von Betfair aus. Diese Strategie könnte man auch gegen konventionelle Buchmacher spielen. Das Programm macht keine Lays und es schliesst auch nicht vorzeitig die Position. Es verwendet keine Muster in den Betfair Preisen, sondern setzt fix 5 Minuten vor dem Start. Von der Wettlogik her darf man sich von diesem Buch nicht sehr viel erwarten. Es geht um die handwerklichen Details des Bots. Wenn jemand eine gute Strategie entwickelt hätte, wäre er auch deppert, diese in einem Buch zu veröffentlichen.
Das Buch enthält das XML-API. Betfair stellt gerade auf ein JSON-RPC Konzept um. Die prinzipielle Logik ändert sich dadurch aber wohl kaum. Ich hatte auch nicht vor die Perl-Skripts direkt zu verwenden. Es ging mir darum den prinzipiellen Aufbau und auch den Aufwand für einen Bot zu studieren. Dazu ist das Buch sehr gut geeignet. In der präsentierten Form ist es 5% Inspiration und 95% Transpiration. Aber das ist auch bei einem Schachprogramm nicht anders. Das Buch verursacht ein leichtes Kribbeln in meinen Finger es selber auch einmal zu probieren. Wobei mich mehr der strategische Teil reizt. Aber der Aufwand ist nicht ohne.


Mastering Betfair: How to make serious money trading betting exchanges
Mastering Betfair: How to make serious money trading betting exchanges
von Pete Nordsted
  Taschenbuch
Preis: EUR 32,00

1 von 1 Kunden fanden die folgende Rezension hilfreich
3.0 von 5 Sternen Naja, 5. Juni 2014
Verifizierter Kauf(Was ist das?)
Betfair ist nicht wie ein traditioneller Buchmacher sondern wie eine Futures Börse organisiert. Man kann ein Ergebnis long (back) und short (lay) gehen. Wie an der Futures-Börse handelt man daher weniger auf das endgültige Ergebnis sondern auf die Bewegung der Preise vorher.
Der erste Teil des Buches beschreibt dieses Prinzip für meinen Geschmack ein bisserl zu umständlich. Vor allem wie man die Position schliesst bzw. in Backfair Termen sie "greent". Wahrscheinlich ist diese ausführliche Darstellung für Leser, die vom traditonellen Buchmacherwetten her kommen, aber durchaus nützlich.
Danach gibt es sehr viele Tipps der Sorte "Wette niemals mit geliehenen Geld". Die sind alle nicht falsch, aber sie sind in der Regel No-Na und helfen wahrscheinlich nicht viel weiter. Es hält sich der Autor auch selber nicht daran.
Er erwähnt mehrmals, dass er ca. 5000 Pfund Cash hat. Laut seinen Regeln soll man per Wette max. 1-2% davon aufs Spiel setzen. Er präsentiert dann aber einige Wetten bei denen es um 500 Pfund geht. Auch wenn er mit Stop-Loss arbeitet, ist er von seinen 1-2% Risiko weit entfernt. Man weiss nie ob man den Stop-Loss tatsächlich exekutieren kann.
Im letzten Teil des Buches präsentiert Nordsted Wettsysteme für Fussball, Cricket und Tennis. Die Ideen sind nicht uninteressant. Es dürfte aber im echten Betfair Leben nicht so einfach sein. Die von Nordsted beschriebenen Effekte sollten schon weitgehend eingepreist sein.
Das Buch ist nicht grossartig. Es ist aber auch nicht kompletter Unsinn. Im Grossen und Ganzen entsprach es meinen - nicht sehr hohen - Erwartungen.
Kommentar Kommentare (2) | Kommentar als Link | Neuester Kommentar: Aug 14, 2014 3:55 PM MEST


Taking Chances: Winning with Probability
Taking Chances: Winning with Probability
von John Haigh
  Taschenbuch
Preis: EUR 24,61

1 von 1 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen Angewandte Statistik für Mathematikmuffel, 4. Juni 2014
Verifizierter Kauf(Was ist das?)
Die Wurzel der Statistik ist das Glücksspiel. Berufsspieler konnten sich nicht erklären, warum manche Kombinationen häufiger vorkommen als andere. Sie kontaktierten die berühmtesten Mathematiker ihrer Zeit, damit die Licht ins Dunkel bringen.
Der Autor hat Beispiele aus der Welt des Glücksspiels zusammen getragen um grundlegende statistische Ideen zu präsentieren. Nachdem ich in Mathematischer Statistik dissertiert habe, kannte ich diese statistischen Konzepte. Ich fand das Buch trotzdem sehr lesenswert, weil mich die Spiele interessiert haben. Ein Teil davon ist very British (z.B. Cricket). Vieles ist aber auch außerhalb des Empire bekannt. Haigh beschränkt sich nicht nur auf klassische Spiele, sondern behandelt etwa auch die Statistik der Millionenshow. Das Buch ist sehr gut lesbar. Es war in den letzten Tagen meine Gute-Nacht-Lektüre.
Über den Untertitel "Winning with Probability" kann man diskutieren. Eigentlich zeigt Haigh, dass man bei den meisten Spielen am besten nicht spielt. Das Motto ist eher: Wie verliere ich am wenigsten. Man sollte sich generell kein "How To" Buch erwarten, sondern eine nette Erkundungsreise in die Welt des Spieles und der Statistik.
Als Statistikprofi kann ich nicht wirklich beurteilen, wie schwer/leicht sich ein Mathematikmuffel beim Lesen tut. Ich kann mir allerdings kaum vorstellen, dass man die Ergebnisse noch anschaulicher und leichter verständlich bringen kann. Das Buch ist Populärwissenschaft im besten Sinn des Wortes.


Advanced Java Optimization Techniques
Advanced Java Optimization Techniques
von Jason Arnold
  Taschenbuch
Preis: EUR 15,50

1 von 1 Kunden fanden die folgende Rezension hilfreich
2.0 von 5 Sternen Einen guten Ansatz dilettantisch vergurkt, 5. Mai 2014
Verifizierter Kauf(Was ist das?)
Ich habe mich in letzter Zeit mit der Optimierung eines in Java-EE (igitt) implementierten Finance-Servers beschäftigt. Dabei ist mir - zu meinem Horror - erst so richtig bewusst geworden, wie ineffizient viele "best practice" Techniken in Java sind (siehe dazu auch die untenstehende Liste von Buchbesprechungungen). Ein Buch mit effizienten Java-Techniken ist daher dringend notwendig.
Jason Arnold ist dafür aber nicht qualifiziert genug. Seine Beispiele sind hausbacken. Manchmal haben sie sogar etwas trivial Lächerliches an sich.

Im ersten Kapitel geht es um I/O. Arnold kommt zu der nicht sehr überraschenden Erkenntnis, das FileChannels aus dem NIO beim sequentiellen Lesen eines Files die Sache erheblich beschleunigt. Bei Random-Access bremsen sie hingegen.
Das zweite Beispiel in diesem Kapitel, die Kompression von Socket-IO, ist der Höhepunkt des Buches. Allerdings funktioniert das nur, wenn man sowohl die Server- als auch die Client-Seite unter Kontrolle hat. Meistens ist das nicht der Fall.

Das nächste Kapitel über Memory-Usage ist besonders dürftig. Arnold schildert den grauslichen Overhead von Strings. Ohne allerdings eine Alternative dafür anzubieten. Ansonsten rät er die Trove-Library statt den Standard-Collections zu verwenden. Zum Abschluss philosophiert er noch über eine "Disk Based Collection Class". Man erfährt aber nichts Genaueres "The code of such a class is much too complex for me to include in this book". Er dürfte nicht nur für das Buch, sondern für den Autor selber zu komplex sein. Ich habe diese Idee für Schach-Endspieldatenbanken ausprobiert. Das Resultat war niederschmetternd. Disks sind einfach unendlich langsam. Wenn man einmal zu Swappen beginnt, hat man schon verloren. Dieses Gebiet ist ein heisses Forschungs- und Entwicklungsgebiet für Datenbanken. Arnold tut so, als hätte er das Problem enpassant gelöst.

Die restlichen Beispiele sind von der Sorte: Man präsentiert zuerst besonders dummen Kode. Dann implementiert man dasselbe Problem ganz bieder-normal und hat einen ungeheuren Speedup.
In Kapitel "Getting Better Concurreny" teilt Arnold die Integration eines Kreises auf verschiedene Threads auf. In der dummen Lösung synchronisieren sich die Threads nach jedem Rechenschritt. Das dauert natürlich eine kleine Ewigkeit. Wer auf diese Art und Weise ein Problem parallelisiert, der sollte für den Rest seines Lebens Programmierverbot bekommen. Danach integriert jeder Thread sein Segment vollständig und es wird erst am Ende synchronisiert. Und viola, das ist um Häuser schneller.

Im letzten Teil über effizienten Kode wird es noch absurder. Zuerst wird die String-Repräsentation von 1000 Zufallszahlen mit String-Cat schrittweise zusammen gefügt. Das ist natürlich wieder unendlich langsam. Danach verwendet Arnold die StringBuilder Klasse und es ist - welches Wunder - um 2 Faktoren schneller. Wer einen String durch aneinanderhängen von 1000 Substrings zusammen fügt, der gehört - bevor man das lebenslange Programmierverbot ausspricht - zuvor noch ausgepeitscht.

Wesentlich kompetenter dürften die Autoren des schon lange angekündigten Buches
Mitchell N., Schonberg E., Sevitsky G.: Efficient Java: A Practical Guide to Memory-Conscious Programming
sein. Leider ist einer der Autoren verstorben und so hängt das Buchprojekt in der Luft.

Weitere Buchbesprechungen in denen ich mich mit dem Problem von effizienter Programmierung beschäftige sind:
Douglas Comer: Operating System Design: The Xinu Approach. "Genial KISS".
Jon Louis Bentley: Writing Efficient Programms. "Das Zen des Programmierens".
J. Bloch: Effective Java: A Programming Language Guide. "Eine effektive Anleitung für möglichst ineffizienten Kode"
Erich Gamma: Design Patterns. Elements of Reusable Object-Oriented Software. "Ein überbewertetes Buch mit üblen Nebenwirkungen".
Martin Odersky: Programming in Scala. "Gründliche Einführung in eine überzüchtete Sprache".


Operating System Design: The Xinu Approach, Linksys Version
Operating System Design: The Xinu Approach, Linksys Version
von Douglas Comer
  Gebundene Ausgabe
Preis: EUR 93,23

3 von 4 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen Genial KISS, 3. Mai 2014
Verifizierter Kauf(Was ist das?)
Ein OS gehört wohl zu den komplexesten Software Artefakten. Beim Lesen dieses Buches hatte ich aber öfters den Eindruck: Das ist ja enttäuschend einfach. Interessanter Weise betraf das gerade jene Funktionalität wie z.B. Context-Switch, Process-Management oder Message-Passing, die ich mir als besonders kompliziert vorgestellt hatte.
Wobei die Einfachheit keineswegs durch eine oberflächliche Darstellung der Thematik erreicht wurde. Das Buch enthält den vollständigen Kode von Xinu. Es wird daher auf jedes Detail genau eingegangen. Es ist vielmehr die geniale Art und Weise wie Schicht für Schicht ein komplettes OS aufgebaut wird. Der Kode beweist auch noch etwas anderes. Es ist gutes altes C. Die Autoren kommen ohne die heute üblichen syntaktischen Kanonen aus. Es kommen auch keine Patterns der Viererbande und der übrigen Pattern-Industrie vor. Sauberer und klarer Kode ist primär eine inhaltliche Frage. Man muss das Problem das man lösen will verstehen. Man soll auch immer nur das Problem lösen, dass man hat. Und nicht fiktive Probleme die irgendwann einmal auftauchen könnten. Es gibt natürlich auch in diesen Kode allgemeine Muster. Z.B. werden Treiber durchgehend in einen Low- und High-Level Part aufgeteilt. Aber es kommt ohne das ganze Pattern Gewäsch aus. Es geht immer um die Lösung eines konkreten Problems.
Der C-Kode verhindert auch, dass alle möglichen und unmöglichen OS-Konzepte telefonbuchartig vorgetragen werden. "Und das gibt es auch noch, und das auch, for further references see...". Stattdessen sagt Comer, wir haben einen Microcontroller und wir machen das nun aus diesen und jenen Gründen so und nicht anders. Enpassant lernt man eine Reihe von netten und effizienten Kode-Techniken. Z.B. eine äusserst kompakte Listendarstellung, oder Delta-Delay Listen für die Implementierung von sleep(). Die Listen werden iterativ und an keiner einziger Stelle rekursiv durchlaufen. Gerade das ist in letzter Zeit unter dem Schlagwort funktionale Programmierung chic geworden (z.B. in Scala). Aber bei Xinu geht es darum, wie man aus einem relativ leistungsschwachen Microcontroller das Maximum herausholt. Und nicht um die Erfüllung des Wirthschen Gesetzes.

Es haben mir auch schon iBoys mit leuchtenden Augen erzählt, wie super so ein iPad ist. Da gibt es praktisch keine Einschalt bzw. Aufwachzeiten. Nach dem Studium des Buches ist man davon nicht besonders beeindruckt. Das iPad ist ein fix und fertig verlötetes Kastl. Das OS kann man daher statisch vorkonfigurieren. In diesem Fall geht das Hochfahren des OS Ruck-Zuck.

Ich hätte auch Lust Xinu auf dem Rasberry oder dem neuen Arduino-Board zu implementieren. Ein Blick auf die anstehenden Projektaufgaben zeigt aber, dass das eines der vielen Projekte sein wird, die man auf die Pension verschiebt. Wobei ich da gleich auch einen eigenen Prozessor (in FPGAs) mit designen möchte. Das ist ein alter Traum von mir. Durch das Buch habe ich mir zumindest die Illusion erhalten, dass das alles eigentlich gar nicht so schwer ist. Man müsste nur die Zeit dazu haben.


Einfach genial gärtnern!: Meine besten >>Mach-es-so<<-Tipps
Einfach genial gärtnern!: Meine besten >>Mach-es-so<<-Tipps
von Karl Ploberger
  Gebundene Ausgabe

3 von 7 Kunden fanden die folgende Rezension hilfreich
3.0 von 5 Sternen Nettes, aber oberflächliches Bilderbuch, 2. Mai 2014
Die Mama hat mir dieses Buch geschenkt. Der Bua tut ja jetzt gärtnern und der Ploberger redet immer so gut im Radio.
Das Buch ist professionell gemacht, die Bilder sind schön, der Ploberger wirkt sympathisch, die Tipps sind nicht falsch.
Der Bua ist zwar noch lange kein Gartenprofi, aber über die Tipps von Ploberger ist er doch schon hinaus. Die Paradeiser soll man nicht zuviel giessen und die Chili mögen es warm. Wobei beim Ploberger die Paradeiser keine Paradeiser sondern Tomaten sind.


Writing Efficient Programs (Prentice-Hall Software Series)
Writing Efficient Programs (Prentice-Hall Software Series)
von Jon Louis Bentley
  Taschenbuch

2 von 2 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen Das Zen des Programmierens, 27. April 2014
Verifizierter Kauf(Was ist das?)
Dieses Buch lese ich immer wieder. Die Beispiele sind inzwischen teilweise etwas angegraut. Aber der Geist der durch die Zeilen weht hat zeitlose Gültigkeit. Das Studium hat auch eine therapeutische Wirkung. Es graust mir, wie sorg- und ahnungslos heute mit den Ressourcen umgegangen wird. Es geht mir wie meinem Vater der ausgerastet ist, wenn man Brot weggeworfen hat. Als meine Schwester das Auto zu Schrott gefahren hat war hingegen seine Reaktion "Hauptsach dir ist nix passiert".

So sind in typischen Java-Anwendungen nur ein Bruchteil des Heap-Spaces Nutzdaten ([1],[2]). Das viel gefeierte "Effective Java" von J. Bloch ist eine effektive Anleitung möglichst ineffizienten Kode zu schreiben. Wenn der Grausen wieder einmal zu gross wird, ziehe ich Bentley oder Knuth aus dem Bücherregal und bewundere die Kunst und die Sorgfalt der Zen-Meister. Ich stell zu meinem Schrecken fest, dass auch meine eigenen Programme teilweise schon unnötig aufgebläht geworden sind. Und tröste mich damit, dass sie im Verhältnis was sonst so üblich ist noch immer sehr schlank und rank sind.

Man müsste eine moderne Fassung dieses Buches schreiben dass sich z.B. mit effizienten Datenstrukturen in modernen Sprachen wie Java oder den dynamischen Sprachen wie Javascript beschäftigt. Teilweise ist das allerdings ein Widerspruch in sich selbst. Wenn man einmal ein größeres Programm in Javascript schreibt, ist die Bande frommer Scheu vor den Ressourcen sowieso schon gefallen.
Ein derartiges Buch könnte
Mitchell N., Schonberg E., Sevitsky G.: Efficient Java: A Practical Guide to Memory-Conscious Programming
sein. Es ist allerdings schon seit längerem angekündigt und noch nicht erschienen. Vielleicht gibt es in Zeiten in denen selbst ein Drittel der Lebensmittel wegeworfen werden keinen Bedarf an Vorschlägen, wie man mit Memory sparsam umgeht. Vielleicht bin ich aber nur ahnungslos und ist dieses Buch eh schon geschrieben worden. In diesem Fall ersuche ich den Leser dieser Zeilen um zweckdienliche Hinweise.

[1]: N. Mitchell, Sevitsky G.: The Causes of Bloat, The Limits of Health.
[2]: Chis A., Mitchell N., Schonberg E. et al.: Patterns of Memory Inefficiency.
Kommentar Kommentare (2) | Kommentar als Link | Neuester Kommentar: Feb 24, 2015 6:26 PM CET


Effective Java (2nd Edition): A Programming Language Guide (Java Series)
Effective Java (2nd Edition): A Programming Language Guide (Java Series)
von Joshua Bloch
  Taschenbuch
Preis: EUR 33,36

11 von 27 Kunden fanden die folgende Rezension hilfreich
2.0 von 5 Sternen Eine effektive Anleitung für möglichst ineffizienten Kode., 26. April 2014
In vielen Java Programmen machen die Nutzdaten nur einen Bruchteil des allokierten Heaps aus [1]. Bei kurzen Strings wie sie z.B. in Personen- oder Städteverzeichnissen vorkommen, ist der interne Header viel größer als die eigentliche Information. Dasselbe gilt bei kleinen Objekten. Der Object-Header ist typischer Weise 16-Byte. Noch übler wird es, wenn diese kleinen Objekte/Strings in Collections gespeichert werden. Eine besonders aufgeblähte Datenstruktur sind die allseits beliebten Hashmaps und Hashsets [2]. Beim Boxing einer Integer hat man 80% bürokratischen Overhead und 20% Nutzdaten. Derselbe Effekt tritt bei Enums auf. Eine Enum ist kein Integer wert, sondern eine Klasse und man schleppt damit den Klassen-Overhead mit herum. In der Regeln werden sie aber nur als symbolische Konstanten vulgo Integers verwendet.

Dieses Buch ist eine systematische Anleitung wie man im Namen von Effektiver Programmierung Daten möglichst gross aufbläst und das Programm möglich abstrakt-kompliziert macht. All die oben aufgezählten "Memory-Bloats" werden als die alleinseligmachende Art der Javaprogrammierung präsentiert. Wobei nicht klar ist, was der Autor unter "Effektiv" versteht. Mit Sicherheit nicht effizienter Kode.

Das Standardargument für diesen Ressourcenwucher ist: Was kostet schon ein Giga Memory oder gar Plattenplatz gegen einen Programmierer. Effizientes Programmieren bedeutet jedoch nicht automatisch geringere Produktivität oder mehr Bugs. Ganz im Gegenteil, es setzt vorraus, dass man das Problem gründlich versteht und dass man sein Fach von Grund auf beherrscht. Wer seine Datenstrukturen ohne viel Nachzudenken was intern geschieht in eine Java-Collection wirft, wer niemals gemessen hat, wie lange Methode A braucht und ob nicht Methode B schneller ist, wird niemals ein richtiger Programmierer werden. Wahrscheinlich wird er niemals irgendetwas richtig können, weil ihm der Sinn für die gründliche Auseinandersetzung mit einem Gegenstand fehlt.

Tatsächlich wachsen die Anforderungen mindestens genauso schnell wie die Hardware. Jedes ernsthafte Programm stößt über kurz oder lang an Performance und Ressourcen Grenzen. Z.B. haben wir einen Finance-Server gebaut. Ursprünglich für ein paar hundert verschiedene Assets und tägliche Daten. Inzwischen sind es ein paar Tausend mit High-Frequency Zeitreihen. Der Server erreichte damit in der ursprünglichen Konzeption die Grenzen des Wachstums. Ich habe mich daher in den letzten Wochen intensiv mit effizienten Java-Strukturen beschäftigt. Die neue Version ist 5-100 x so schnell und verbrät nur einen Bruchteil von Plattenplatz und Memory. Das geht natürlich nicht mit kleinen kosmetischen Veränderungen. Es musste z.B. auch die MySQL-Datenbank daran glauben. Es wurden aber auch handgeschnitzte und effektive Datenstrukturen für Zeitreihen entwickelt. Ein Element einer Zeitreihe besteht typischer Weise aus einem Zeitstempel (int oder long) und einem Wert (double). Es ist höchst uneffektiv für jedes Element ein Objekt zu erzeugen und dieses z.B. in einer ArrayList der Reihe nach zu speichern (komplexerere Container sind noch übler). Stattdessen speichert man die Zeitstempel in eine Integer- und den Wert in eine Double-Array. Nachdem man die Frequenz der Daten und den Zeitbereich kennt, kann man die Größe der Array von vornherein sehr gut abschätzen. Man benötigt keine dynamischen Strukturen. Dieses Design ist gegen alle in diesem Buch gepredigten Regeln. Es ist jedoch einfach, schnell und auch nicht fehleranfälliger wie all die Regeln der schönen neuen Programmierwelt. Es ist nur weniger allgemein. Es braucht aber auch nicht allgemeiner sein. Und falls die Datenstruktur sich einst doch als zu starr erweist, schreibt man sich halt eine neue TimeseriesExtended Klasse. Von vornherein alle möglichen und unmöglichen Erweiterungen in Datenstrukturen einzubauen gehört laut [2] zu den 12 Patterns vulgo Ursünden für aufgeblähten Kode. Man muss Kode sowieso von Zeit von Zeit wegschmeissen und gänzlich neu schreiben.

Man kann auch den in C++ geschrieben Kode von H. Press et. al.: Numerical Recipes 3rd Ed. hernehmen. Der Kode verstößt massiv gegen die Regeln der C++ "Effective-Gurus". Er löst aber auf sehr effiziente Weise das jeweilige Problem, dass er lösen soll.

Meiner Meinung nach sind Bloch, Myers et. al. Sektenprediger die dem staunenden Publikum Snake-Oil verkaufen. Man sollte stattdessen Bücher von ernsthaften Leuten die D. Knut, H. Press oder D. Comer lesen.
Auch das gute alte "Writing Efficient Programs" von J. Bentley ist es wert immer wieder einmal gelesen zu werden. Die Beispiele mögen teilweise veraltert sein, der Geist, die Einstellung, die es ausstrahlt, jedoch nicht. Es ist die Antithese zu einer allgemeinen Einstellung die vollkommen unverantwortlich mit Ressourcen - sei es nun Lebensmittel, Energie oder Memory - umgeht.

[1]: N. Mitchell, Sevitsky G.: The Causes of Bloat, The Limits of Health.
[2]: Chis A., Mitchell N., Schonberg E. et al.: Patterns of Memory Inefficiency.
Kommentar Kommentare (4) | Kommentar als Link | Neuester Kommentar: Dec 3, 2014 5:58 AM CET


Design Patterns. Elements of Reusable Object-Oriented Software.
Design Patterns. Elements of Reusable Object-Oriented Software.
von Erich Gamma
  Gebundene Ausgabe
Preis: EUR 42,95

10 von 27 Kunden fanden die folgende Rezension hilfreich
2.0 von 5 Sternen Die Cargo-Cult-Programming Bibel, 9. April 2014
"Cargo cult programming is a style of computer programming characterized by the ritual inclusion of code or program structures that serve no real purpose". (Wikipedia Cargo_cult_programming)

"In other words, it seems that fanatical advocates of the New Programming are going overboard in their strict enforcement of morality and purity in programs"
(D.E.Knuth: Structured Programming with go to Statements).

I had a problem so I thought to use patterns.
Now I have a ProblemFactory.
(Frei nach harmful-cat).

Donald Knuth nannte seine fundamentalen Werke nicht umsonst "The Art of Computer Programming". Es gibt auch in der Kunst grundlegende handwerkliche Techniken. Hier wird aber der Versuch gemacht die Kunst auf eine Ansammlung von Legobausteinen zu reduzieren. Wie bereits von anderen Reviewern kritisiert, gibt es im Buch kein längeres zusammenhängendes Beispiel. Das ist kein Zufall oder eine Auslassung. Man bekommt mit diesen Legobausteinen keine schöne Hütte zusammen.
Mir ist schon öfters Kode untergekommen bei dem ich mich gefragt habe: Warum ist das mit der Kirche ums Kreuz programmiert? Man kommt dann - auch auf Grund der Namensgebung - drauf: Der Autor ist den Designpattern sklavisch gefolgt. Da reiht sich wie in einer Matroschka Fassade auf Fassade und irgendwann in einer kleinen Ecke wird dann wirklich was gemacht. Das Wirthsche Gesetz: "Software wird schneller langsamer, als die Hardware schneller wird" zehrt ganz wesentlich von diesem Pattern-Fetischismus. Das Java-EE Monster ist ein klassisches Beispiel für Patterns in Action. Effizientes Programmieren kommt in der Pattern Welt gar nicht vor.
Das Buch legte auch den Grundstein für eine ganze Pattern-Industrie. Gescheiterte Programmierer leben davon anstatt konkreter und eleganter Lösungen allgemeine Ratschläge zu verkaufen. Letztendlich ist das ein Pseudoreligiöses Business ganz ähnlich der evangelikalen Sekten.

Es gibt allerdings auch Vorzüge. Wenn man auf die Pattern-Terminologie stösst, weiss man, was der Programmierer im Schilde geführt hat. Man weiss auch, dass man den Kode so schnell wie möglich wegwerfen und neu schreiben sollte. Außerdem weiß man, dass man sich ein Buch mit dem Schlagwort "Pattern" nicht zu kaufen braucht. Das ist die Dialektik der Pattern-Aufklärung. Sie bilden ein Antipattern um das man so gut wie möglich einen Bogen macht. In diesem Sinn ist das Buch auch wieder nützlich.
Das ist kein Plädoyer für "anything goes" sondern für selbständiges Nachdenken wie man ein Problem am besten löst.

Wer wirklich an grundlegenden Techniken des Programmierens interessiert ist sollte
Douglas Comer: Operating System Design, The Xinu Approach
lesen. Comer demonstriert an einem komplexen Problem wie man Software strukturiert. Er zeigt, dass die grundlegenden Probleme inhaltlicher Natur sind und nicht auf einzelne Programmiertricks reduziert werden können. Das Wort "Pattern" ist mir im Comer Buch nicht untergekommen. Der Pattern-Gläubige erwartet allerdings einfache Botschaften und Lösungen. Dafür ist das Comer Buch wieder nicht geeignet.

P.S.: Das Knuth-Zitat bezieht sich nicht auf die Viererbande. Aber es passt zu allen Versuchen Programmieren in ein Prokrustes Bett zu stecken.
Kommentar Kommentare (5) | Kommentar als Link | Neuester Kommentar: Jan 23, 2015 10:18 AM CET


Programming In Scala
Programming In Scala
von Martin Odersky
  Taschenbuch
Preis: EUR 54,90

5 von 8 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen Gründliche Einführung in eine überzüchtete Sprache, 20. März 2014
Verifizierter Kauf(Was ist das?)
Rezension bezieht sich auf: Programming In Scala (Taschenbuch)
Ich habe gemeinsam mit einem Kollegen einen Finance-Server (godotfinance) in Java-EE programmiert. Java-EE ist ein dicker, fetter Jumbo. Ein befreundeter Programmier hat mich auf das Play-Framework aufmerksam gemacht. Das schaut wesentlich eleganter aus. Play 2.0 ist in Scala programmiert. Das war die Motivation sich mit Scala näher auseinander zu setzen.
Das Buch ist eine sehr detaillierte Einführung in die Sprache. Für einen ersten Einstieg manchmal vielleicht sogar ein bisserl zu detailliert. Nachdem ich sonst über die Oberflächlichkeit der neuen Programmierbücher jammere, kann und will ich mich nicht beschweren, wenn jemand einmal ein sehr sorgfältig gemachtes Buch schreibt.

Die Sprache selbst hat mein Herz nicht erobert. Sie kommt mir eher wie eine akademische Übung vor. M. Odersky hat in die Sprache anscheinend alles hineingepackt, was er in den letzten Jahren über Type-Systemen geforscht hat. Ich verstehe nicht, warum man mit sprachlichen Geschützen auffährt, nur um ein paar triviale Tastenanschläge einzusparen. Laut dem Autor ist ein Scala Programm ungefähr halb so lang wie eine äquivalentes in Java. Auf den Fortschritt eines komplexen Projektes (wie z.B. ein Finance-Server) hat das keine nennenswerten Auswirkungen. In jedem halbwegs komplexe Projekt ist die Frage "welches Problem will man überhaupt mit welchen Methoden lösen" der dominierende Faktor. Die Frage, ob man bei einer Variablen noch den Datentyp hinzuschreiben muss oder nicht, ist vollkommen irrelevant. Beim Design von Scala wurden aber sehr viel Aufwand dafür verwendet. Das Ziel war eine streng typisierte Sprache die sich (fast) genauso wie die neuen nicht-typisierten Sprachen liest. "You can simply start by writing a function literal without the argument type, and, if the compiler gets confused, add in the type".

Meiner Meinung nach ist die neue Mode von dynamischen nicht typisierten Sprachen ein Beispiel dafür, was Alan Kay unlängst abwertend als Pop-Culture in Programming bezeichnet hat. Jeder alter Hase der einst in Basic ganz grausliche Bugs produziert hat, weil er statt "enpassantSqr" fälschlicher Weise "enpasantSqr" getippt hat, kennt aus leidvoller Erfahrung den Sinn von Type-Checking. Wer Fortran programmiert hat weiss, dass einrücken keine besonders gute Idee zur Strukturierung eines Programmes ist. In Coffeescript wird das als grosse Errungenschaft gefeiert.
Eine Popkultur besitzt jedoch kein Gedächtnis und es muss jede neue Generation aufs Neue auf die Nase fallen.
Einige Scala Konzepte wie z.B. Parser-Combinators sind sicherlich sehr nett um z.B. CHIEF (Chrilly's Easy-Finance-Language) zu implementieren. Für time-series analysis sehe ich hingegen keinen Vorteil gegenüber Java oder C. Es kommt halt immer auch darauf an, was man mit einer Sprache machen will. Scala hat auch einige Anleihen an LISP genommen (die unnötigen Klammern aber weggelassen). Dementsprechend werden Listen auch im bevorzugten Stil rekursiv abgearbeitet. Auch wenn der Autor behauptet "so ineffizient ist das gar nicht" beutelt es mich bei dieser Idee. LISP-Schachprogramme auf einer Workstation hatten gegen Assembler-Programme auf einem Waschmaschinen-Controller nicht den Funken einer Chance. Genaugenommen haben LISP-Schachprogramme nie richtiges Schach gespielt. Auf die Idee dafür LISP zu verwenden, sind auch nur akademische Teams gekommen. Die Profis haben immer Assembler und später dann auch C verwendet.

Eine wesentlich gelungere und um eine Grössenordnung einfachere neue Sprache ist Go. Leider gibt es meines Wissens kein entsprechendes Go-Framework.

Ich habe das Buch dennoch mit einigem Vergnügen gelesen. Auch wenn man mit den Prämissen nicht accord geht, ist es sehr spannend einen Einblick in die innere Logik dieser Sprache zu bekommen. Der Autor hat sich sowohl bei der Sprachkonzeption als auch bei der Abfassung dieses Buches einiges gedacht.
Kommentar Kommentare (2) | Kommentar als Link | Neuester Kommentar: Feb 19, 2016 2:39 PM CET


Seite: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11-20