+ Antworten
Ergebnis 1 bis 3 von 3

Thema: Rich Hickey - Spec-ulation

  1. #1
    User Viertel Megabyte Themenstarter
    Avatar von inv_zim
    Registriert seit
    31.07.2013
    Ort
    Rhein-Main Gebiet
    Fachbeiträge
    370
    Genannt
    31 Post(s)
    Ich bin gestern über diesen Talk gestolpert: https://www.youtube.com/watch?v=oyLBGkS5ICk

    Gehalten von Rich Hickey, dem Schöpfer von Clojure (keine Angst, der Talk ist nicht Sprachspezifisch). Er stellt die These auf, dass die klassische Versionierungsart MAJOR.MINOR.PATCH 'broken' ist und wir Software ohne Breaking Changes ändern sollten, immer. Die Funktion braucht einen Parameter mehr? Dann schreiben wir eine neue Version, lassen die alte bestehen. Also in etwa das selbe Vorgehen, mit dem Webservices versioniert werden (sollten). Eine knappe Stunde ist natürlich nicht schnell angeschaut, aber ich fand es lohnenswert, wenn auch nicht 100% umsetzbar. Irgendwo wird es immer breaking changes geben, und wenn es durch regulatorische Anforderungen ist. Aber es sind einige gute Ansätze dabei, die ich in meinem Softwaredesign zukünftig gerne berücksichtigen möchte.
    I am obsessed with the ancient science of "puzzle-ometry". I have discovered that within puzzles lies the secret of human intelligence, that which separates us from the common beast.

  2. #2
    Global Moderator Viertel Gigabyte
    Registriert seit
    05.08.2008
    Fachbeiträge
    4.948
    Genannt
    321 Post(s)
    Das hat einige Parallelen zu meinem "Lieblingstalk" https://www.infoq.com/presentations/...ive-api-design - aber ich muss sagen, dass der Hickey (im Gegensatz zum Josh Bloch, und zumindest in diesem Talk (und anderen, die ich bisher von ihm gesehen habe)) nicht gerade sehr ein sehr effectiver Speaker zu sein scheint. In der ersten halben Stunde hat er (für mich) nicht viel mehr rübergebracht als:

    Public APIs are forever! und When in doubt, leave it out!

    Die vermeintliche (!) Systematik, mit der er das aufbaut (~"change gibt es nicht, nur add oder break") könnte zwar inspirierend sein, aber es scheint bisher nur ein seeeehr weites Breittreten der Tatsachen zu sein, derer sich jeder im Klaren sein sollte, der o.g. talk gesehen hat.

    Dass SemVer bzw. sein MAJOR-Teil in diesem Sinne broken ist, stört mich zwar auch, aber das liegt schließlich im Verantwortungsbereich des Erstellers. Eine Library mit Version "18.Y.Z" würde bei mir schon eine gewisse Skepsis hervorrufen. So etwa wie Guava. Die haben mit "@Beta" und klar definierten Deprecation-Regeln den Problemen aber zumindest entgegen gewirkt, die er beschreibt. (Sie sind nicht behoben! - und abgedämpft). An anderer Stelle WURDE eine "Major Change" tatsächlich durch einen neuen Namen gelöst - z.B. bei Antlr, wo die Versionsnummer (3 bzw. 4) wirklich im packagenamen steht.

    Dass es spezielle Fälle geben kann, in denen man "Major changes" machen kann, deutet er ja an, aber richtig eingeordnet als absolute Sonderfälle.

    (Ansonsten .... für mich war da jetzt nicht sooo viel neues drin, aber ... das sehe ich nur als eine Bestätigung bestimmter Aspekte der Ansichten, die ich bisher hatte. Von den ~25 libraries, die ich bisher auf GitHub gestellt habe, haben zwar praktisch alle eine Versionsnummer "0.0.Z", aber ... sind sicher "stabiler" als vieeele, die meinen, "etablierte Standardsoftware" zu entwicklen. Dass ich willkürliches Versionsnummernwürfeln und spec-freies Entwickeln bzw. willkürliches Ändern von "Specs" kritisiert habe, mag einer der Gründe sein, warum ich mir das jetzt ansehen konnte, aber vielleicht ist das ja nur die Filterblase, von der in letzter Zeit immer geredet wird...)

  3. Es bedanken sich:
    stefan- (07.12.2016), Timothy_Truckle (07.12.2016)
  4. #3
    User Viertel Megabyte Themenstarter
    Avatar von inv_zim
    Registriert seit
    31.07.2013
    Ort
    Rhein-Main Gebiet
    Fachbeiträge
    370
    Genannt
    31 Post(s)
    Zitat Zitat von Marco13 Beitrag anzeigen
    aber ich muss sagen, dass der Hickey (im Gegensatz zum Josh Bloch, und zumindest in diesem Talk (und anderen, die ich bisher von ihm gesehen habe)) nicht gerade sehr ein sehr effectiver Speaker zu sein scheint.
    Da muss ich leider zustimmen, das mit dem Präsentieren hat er nicht so. Seinen Talk von der Java One z.B. fand ich aber hingegen etwas besser, da hatte er auch mehr Inhalt. Immerhin war es eine Keynote, da ist das ja alles ein bisschen lascher...

    Ich glaube, das ist nicht nur mit public APIs zu sehen. Wenn ich überlege, wie oft ich schon bei diversen Enteprise SOA Projekten gehört habe.. "... und diese Schnittstelle passen wir an..." oder "...kommt weg...", mit Umschalten zum Stichtag, da frage ich mich schon wo ich gelandet bin

    Du sagst ja, diese Thematik sollte jedem klar sein, aber trotzdem gibt es genug Gegenbeispiele. Da redet man sich vielleicht doch lieber ein, "da mache ich eine Major Version, da weiß ja jeder dass sie nicht kompatibel ist". Mein Favorit zum Beispiel Primefaces, die neben neuen Komponenten mit jeder Major Version auch Funktion brechen. Da wird die Migration wirklich schmerzhaft, aber trotzdem hat die neue Version die Komponente die jetzt so gut passt...

    Ich werde mir den von dir verlinkten Talk mal anschauen, das klingt gut.
    I am obsessed with the ancient science of "puzzle-ometry". I have discovered that within puzzles lies the secret of human intelligence, that which separates us from the common beast.

+ Antworten Thema als "gelöst" markieren

Direkt antworten Direkt antworten

Gib folgenden Captcha-Code ein: F9H5J2

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Ähnliche Themen

  1. MVC 1.0 aus Java EE 8 Spec gestrichen
    Von inv_zim im Forum Java Enterprise Edition (Java EE)
    Antworten: 0
    Letzter Beitrag: 28.09.2016, 06:10

Berechtigungen

  • Neue Themen erstellen: Ja
  • Themen beantworten: Ja
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •