HobbyProgrammer hat geschrieben: Sa 26. Okt 2024, 08:37
Und ich finde es schade das Du uns hier scheinbar Deine Art und Weise aufzwingen willst um Lazarus/Fpc zu installieren.
Ich hab absolut kein Problem damit wie jemand sein FPC installiert. Mich stört nur wenn etwas das nicht mal Mittelmaß ist angepriesen wird als wäre es das beste seit geschnitten Brot.
Ich mein Pascal ist nicht die einzige Sprache da draußen, und daher sollte man auch direkte Vergleiche ziehen. Z.B. das Programm was vermutlich am nächsten zu dem ist wofür hier FPCUp verwendet wird was ich kenne ist GHCUp, der Updater für den Glasgow Haskell Compiler. GHCUp ist nicht besonders gut, ich hab mehr als genug probleme damit, aber es ist welten besser als FPCUp:
1. Man installiert GHCUp durch einen installer, maintained durch die GHC entwickler und bereitgestellt durch die Offizielle GHC Website. Gut Dokumentiert as der standardinstaller für GHC. Nicht irgendeine third party Github page mit releases bei denen man sich die richtige Version rauspicken muss und dann eine Dubiose 11MB executable runterlädt, bei der einen das OS warnt ob man sie wirklich ausführen will.
2. Es wird eine GHCUp installation durchgeführt, womit ein sich selbst updatende GHCUp version installiert wird, sodass man nach erstmaliger Installation nie wieder neue versionen runterladen muss.
3. GHCUp hat ein CLI ein TUI und ein GUI alles in der gleichen App, sodass man nicht 3 verschiedene Apps aus 3 verschiedenen Repos braucht (fpcup, fpclazup und fpclazupdeluxe)
4. GHCUp Zeigt alle verfügbaren versionen mit detailierten Informationen wie Basislib version, Kompatibilitäten zu anderen tools, etc. an, nicht einfach nur eine Liste mit Versionsnummern
5. GHCUp kann mehrere installationen parallel verwalten, ohne das man manuell die Ordnerstrukturen anlegen und wählen muss. Switchen der Defaultumgebung zwischen versionen geht ganz einfach über das TUI, GUI oder CLI von GHCUP, und man kann in seinen Projekteinstellungen in Cabal oder Stack einstellen welche version benutzt werden soll und dann sucht sich das buildsystem transparent die korrekte version raus ohne das man 20 installationen manuell managen muss.
6. GHCUp installiert GHC Binaries, und muss die nicht erst bauen
GHCUp ist in ordnung, nicht perfekt aber gutes Mittelmaß und es ist um welten besser als FPCUp. Ich will mich nicht mit unterdurchschnittlichen Tools zufrieden stellen, vor allem wenn man auf irgendeine andere. Haskell ist zwar jetzt nicht die große Sprache (in etwa vergleichbar von Verbreitung mit Pascal), ich hab das Beispiel nur genommen weil GHCUp genau das macht wofür FPCUp hier verwendet wird und sich daher der Vergleich anbietet.
Aber man kann auch auf andere Tools schauen. In python gibts PyEnv mit dem man mehrere python versionen managen kann, hat auch viele der punkte oben von GHCUp abgebildet.
Das ist nicht nur ein Problem von FPCUp sondern generell vom tooling. Wie oft lese ich hier wie toll OPM ist, und ja wenn man nix anderes kennt ist OPM im vergleich zu kein OPM richtig angenehm. Wenn man aber die alternativen wie pip, npm, cabal, etc. kennt ist OPM ein absoluter Witz.
1. OPM hat kein CLI was es komplett ungeeignet für automatisierte Buildsysteme macht
2. OPM muss manuell bedient werden, bei cabal oder npm werden einfach alle dependencies aus Projekten ausgelesen und automatisch installiert, ohne das man sich als Nutzer um irgendwas kümmern muss
3. OPM hat keine Submission schnittstelle, man muss die Maintainer bitten die Packages in die Packageliste aufzuenhmen.
4. OPM hat keine einheitliche Schnittstelle. Das format der
packagelist.json ist absolut grauenhaft und die Felder wie Download URL und Hompage haben austauschbare und variierende Semantiken je nach Paket, dependencies sind als plaintext codiert, etc. Ich könnte nicht mal was besseres bauen selbst wenn ich wollte weil das Package Repository bereits schon kaputt ist.
5. OPM basiert, enforced durch das Format der Paketliste, auf der ineffizienten JSON implementierung von fpjson. Wenn man fpjson verbessern würde, würde das erst mal OPM kaputt machen, was änderungen an OPM und an der Packagelist bräuchte, was bedeutet man muss mindestens einen vollen Lazarus und FPC release Zyklus abwarten. Daher werden wir vermutlich nie eine effizientere fpjson implementierung haben können
Das Stört mich halt an der Community insgesammt. "Grade so besser als nichts" wird hier als das non plus ultra hochgehalten, und da wundert man sich warum von außen Pascal nur so belächelt wird. Wir sind was tooling angeht bestimmt 20 Jahre hinter anderen Programmiersprachen, und aus irgendeinem Grund wird das gefeiert
Verein
Links
Suche