Schrift
[thread]10015[/thread]

Zeitintervall erzeugen (Seite 2)

Leser: 3


<< |< 1 2 >| >> 14 Einträge, 2 Seiten
Daxim
 2007-08-11 18:35
#97966 #97966
User since
2007-08-01
114 Artikel
BenutzerIn
[Homepage]
user image
Struppi+2007-08-11 09:31:30--
[DateTime] ist das unausgereifste Modul
Davon kann keine Rede sein, wenn es seit mindestens viereinhalb Jahren existiert.&#8304;

Struppi+2007-08-11 09:31:30--
Ausserdem sehe ich bei Date::Calc den 28.2.2007 als letztes Datum
Das stimmt nicht. Letztes Datum ist 2004-10-03.¹

Struppi+2007-08-11 09:31:30--
beides ist für mich nicht unbedingt "jahrelang"
Das Datum für Class::Date stimmt. Diese Daten liegen beide mehr als ein Jahr zurück. Der Ausdruck teilweise jahrelang nicht mehr aktualisiert worden ist umfassend gerechtfertigt.

Struppi+2007-08-11 09:31:30--
Zumal bei solchen Funktionen es keinen Anlaß gibt, ausser zur Bugsbeseitigung, einen Update zu machen. [...] Die oben genannten Module haben seit Jahren keinen Bugfix mehr benötigt
Das hab ich schon mal gehört. »But a non-recent release date is not necessarily a red flag. Nicholas Clarke raised this at the YAPC::Europe. Some modules are just perfect the way they are.«

Dummerweise gibt es Bugs, und die jeweiligen Maintainer der Module, an denen ich Kritik übe, beheben sie nicht.² Das mag wohl sein, weil es Einzelpersonen sind, die die Pflege aufgegeben haben. Dies kann mit der DateTime-Familie nicht passieren, weil sie gemeinsam von einem Team betreut wird.

Gerade bei Datum/Zeit kann nie Stabilität gewährleistet sein: Feiertage, Sommerzeitdaten und Zeitzonendefinitionen ändern sich nämlich mal alle paar Jahre, jüngst in Australien. Ich weiß nicht, ob die kritisierten Module von dem Beispiel betroffen sind, aber falls ja, haben sie's definitiv verpennt.

Struppi+2007-08-11 09:31:30--
während an DateTime noch gearbeitet wird und im kleinen Monatsabstand Bugfixes erfolgen.
Deshalb ist dies in Wirklichkeit ein green flag.
Daxim
 2007-08-11 18:35
#97967 #97967
User since
2007-08-01
114 Artikel
BenutzerIn
[Homepage]
user image
Struppi+2007-08-11 09:31:30--
Hier ein kleiner Artikel zum Thema (leider ohne DateTime)
Das stimmt nicht. DateTime wird sehr wohl genannt. Ich behaupte sogar, die Kernaussage dieses Artikels ist: »Jetzt haben wir X, Y, Z. Damit stimmen A, B, C nicht. Deshalb schreibe ich DateTime, und somit ist A, B, C besser.«
Struppi+2007-08-11 09:31:30--
Aber letztlich dürfte der eigene Geschmack entscheiden
Die Vernunft sollte entscheiden, nicht der Geschmack. Objektiv gute Kriterien sind:[ul][li]Ist es praktisch? (»P is for practical.«) Das obige Beispielprogramm hat mich insgesamt weniger als fünf Minuten gekostet.[/li][li]Macht es, was ich erwarte? (»DWIM.«) Dank Überladung der Relativoperatoren konnte ich intuitiv Uhrzeiten vergleichen. Das brauchte ich nicht mal nachschlagen.[/li][li]Ist der Einsatz risikobehaftet (Einzelmaintainer, lange Bugqueues) oder kompensiert (Homepage, Mailingliste, Bugs werden tatsächlich behoben)?[/li][/ul]

Diese Kriterien halte ich im Jahr 2007 für vernachlässigbar.
Struppi+2007-08-11 09:31:30--
reines Perlmodul
Aus welchem Grund möchte man PP den Vorzug geben? Ich kann nur mutmaßen.

»Man kriegt es auf Windows oder sonstigen Exoten mittels BFI installiert.« Wir haben die Vanilla-Perl-Reihe, selber kompilieren ist erheblich einfacher. Wir haben Freiwillige, die PPM-Distros bauen. Wir haben massives Aussterben exotischer Plattformen.

»XS-Module sind beim Installieren problematischer.« Generell ja, aber DateTime hat derzeit 100% PASS aus 59(!) auf testers.³

Struppi+2007-08-11 09:31:30--
nur eine begrenzte Funktionalität
Aus welchem Grund möchte man Krüppelware den Vorzug geben? Ich kann nur mutmaßen.

»Weniger RAM.« 300 KiB statt 3 MiB Speicher hört sich immer gut an, aber selbst auf 9 Jahre alter Hardware macht das keinen Unterschied.

»Softwarekomplexität sinkt.« Das ist zugegeben ein gewichtiges Argument. Jedoch eine gute Testsuite hilft, die Bugs in Schach zu halten.
Daxim
 2007-08-11 18:36
#97968 #97968
User since
2007-08-01
114 Artikel
BenutzerIn
[Homepage]
user image
Fazit:
Es gibt keinen Mechanismus, auszusagen, dass dieses oder jenes Modul überholt und durch ein anderes abgelöst ist. Dies ging bisher immer nur durch Diskussion, wie sie im Kloster oder hier betrieben wird. Das Perl5-Wiki bringt vielleicht Besserung.

Daxim+2007-08-10 16:58:22--
Die Familie um CPAN:DateTime (Homepage) ist von allen Datum-/Zeitmodulen am besten gepflegt.
Diese Aussage steht. Wenn du meinst, dem noch widersprechen zu müssen, liefere Belege.


&#8304; »Recently, I released alpha versions of the core object, DateTime.pm« (Dave Rolsky, 2003-03-13)
¹ http://search.cpan.org/dist/Date-Calc-5.4/
² Einige schöne Fehler herausgegriffen:[ul][li]Bug 19715, Class-Date-Class-1.1.9, Cannot parse an IS0 8601 date and time
Patch existiert seit einem Jahr.[/li][li]Bug 23998, Class-Date-Class-1.1.9, More time zone problems in strftime
Testcase existiert seit acht Monaten.[/li][li]Bug 17908, Date-Calc-5.4, Timezone broken at end of the month.
Nachvollziehbarer Bericht existiert seit über einem Jahr.[/li][/ul]³ http://cpantesters.perl.org/show/DateTime.html#Dat...

P.S. Drei Postings wegen 2000-Zeichen-Limit.
pq
 2007-08-11 19:28
#97971 #97971
User since
2003-08-04
12209 Artikel
Admin1
[Homepage]
user image
kann daxim nur zustimmen. nochmal: die modul-versionsnummer sagt so gut wie
gar nichts aus im vergleich zu anderen modul-versionsnummern.
und dass es viele releases und bugfixes gibt, sagt auch gar nichts darüber aus,
wie "reif" ein modul ist. es kommt ja auf die bugfixes an, welche features sie
betreffen und wie kritisch sie sind.
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
lesen: Wiki:Wie frage ich & perlintro Wiki:brian's Leitfaden für jedes Perl-Problem
<< |< 1 2 >| >> 14 Einträge, 2 Seiten



View all threads created 2007-08-09 16:45.