Programmiersprachen der Zukunft
-
@It0101 sagte in Programmiersprachen der Zukunft:
Aber es gibt auch einige, denen ich den Übergang vom CVS ( älter als die Welt ) auf GIT ( state-of-the-art ) regelrecht mit der Peitsche einbläuen musste.
GIT = Git Ist Toll
Vor allen Dingen gehen Dinge damit wesentlich einfacher. Ein Vergleich von Datei XYZ Version ABC zu dem aktuellen Working Tree ist mit TortoiseGit nur ein paar Mausclicks entfernt.
Wenn ich da an CVS denke, so endete das meistens in einer etwas längeren Recherche in der Doku.
Aber ich kenne viele Leute welche GIT bis heute nicht verstanden haben und auch nicht verstehen wollen sondern eher bei CVS bleiben wollen. Wie sagt man so schön: "Was der Bauer nicht kennt, frisst er nicht."
-
@It0101
Ich erlebe es eigentlich häufiger genau anders herum, dass nämlich irgendwelche jungen, neuen Leute nach dem zweiten Arbeitstag wissen, dass man doch viel besser das Buzz-Word-Tool xy nehmen muss.
-
@It0101 Dann sei froh. Ich musste schon Leuten erklären wozu sie überhaupt Versionskontrolle brauchen. Für die reichte ein Verzeicnisbaum voller zip files.
-
@Tyrdal Das hat nach meiner Erfahrung mit dem Alter nixe zu tun.
@Quiche-Lorraine Zum Thema Git ist toll: nein, Git ist nicht toll. Es ist alles in allem ein akzeptables Tool. Wobei dummerweise übersehen wird dass Git bestimmte Dinge nicht kann und für wieder andere einfach nicht sehr gut ist.
Nebenbei auch witzig dass viele von den Jungen nichtmal wissen was Git nicht kann, weil sie nie mit 'was anderem gearbeitet haben und nichtmal auf die Idee kommen dass ein Versionskontrollsystem das können könnte."Git ist toll" ist Gehirnwäschepropaganda. Genau so wie die Glorifizierung des veralteten durchwachsenen Haufens schlecht entworfener APIs der sich da POSIX schimpft.
-
@hustbaer sagte in Programmiersprachen der Zukunft:
Zum Thema Git ist toll: nein, Git ist nicht toll.
welches vcs empfiehlst du stattdessen?
-
@hustbaer sagte in Programmiersprachen der Zukunft:
@Quiche-Lorraine Zum Thema Git ist toll: nein, Git ist nicht toll. Es ist alles in allem ein akzeptables Tool.
Ich finde Git toll. Es gibt zwar auch mit Git immer mal wieder Probleme, aber alles in allem habe ich deutlich weniger Probleme, als ich es früher z.B. mit SVN hatte. Sicherlich gibt es Sachen, die man vlt besser machen könnte und wahrscheinlich kenn ich mich mit Git immer noch nicht gut genug aus um mir ein allumfassendes Urteil bilden zu können, aber für meine Anforderungen ist es das beste Tool für sein Einsatzgebiet, also toll
-
@Schlangenmensch sagte in Programmiersprachen der Zukunft:
@hustbaer sagte in Programmiersprachen der Zukunft:
@Quiche-Lorraine Zum Thema Git ist toll: nein, Git ist nicht toll. Es ist alles in allem ein akzeptables Tool.
Ich finde Git toll. Es gibt zwar auch mit Git immer mal wieder Probleme, aber alles in allem habe ich deutlich weniger Probleme, als ich es früher z.B. mit SVN hatte. Sicherlich gibt es Sachen, die man vlt besser machen könnte und wahrscheinlich kenn ich mich mit Git immer noch nicht gut genug aus um mir ein allumfassendes Urteil bilden zu können, aber für meine Anforderungen ist es das beste Tool für sein Einsatzgebiet, also toll
GIT kann extrem viel. Vieles davon reizen wir derzeit gar nicht aus. Bei GIT ist vor allem wichtig, dass man eine konkrete Strategie hat, wie man wann Branches nutzt. Ich bin mit den Branches am Anfang sehr oft durcheinander gekommen und habe mir mehr oder weniger mein Projekt zerschossen. Das lag zum einen daran, dass ich eine GUI benutzt habe und zum anderen daran, dass mir noch Wissen gefehlt hat. Seit ich die GIT-Bash nutze und mich mit den Kommandos beschäftigt habe läuft es viel besser.
-
@KahnSoft
warum hast du eigentlich alle deine Beiträge hier gelöscht. War doch gar nichts schlimmes dabei?
-
@Bushmaster sagte in Programmiersprachen der Zukunft:
@hustbaer sagte in Programmiersprachen der Zukunft:
Zum Thema Git ist toll: nein, Git ist nicht toll.
welches vcs empfiehlst du stattdessen?
Kommt drauf an was man braucht. Für viele ist vermutlich immer noch Subversion besser. Und: wenn ich sage Git ist nicht toll heisst das nicht automatisch dass ich etwas anderes für (insgesamt) besser halte.
Git ist OK und vermutlich oft der beste Kompromiss. Aber Git ist definitiv nicht toll.
-
Dieser Beitrag wurde gelöscht!
-
Dieser Beitrag wurde gelöscht!
-
Entweder man steht zu seiner Meinung oder eben nicht.
-
Dieser Beitrag wurde gelöscht!
-
@It0101 sagte in Programmiersprachen der Zukunft:
warum hast du eigentlich alle deine Beiträge hier gelöscht. War doch gar nichts schlimmes dabei?
das hättest du nicht schreiben sollen.
-
@hustbaer Was genau vermisst du denn bei git? Binärdaten?
-
@Tyrdal
Rename-Tracking, Cherry-Picking mit vernünftigem Merge-Tracking
-
Wie geht Ihr denn damit um, wenn andere Leute sich negativ über Eure präferierte Programmiersprache + Ökosystem äußern? Als junger/relativ frischer Entwickler muss ich schon sagen, dass mich das verunsichert.
Ich hatte auf der Arbeit erst vor kurzem wieder so ein Fall. Ich war an einem ~4 monatigen Java-Projekt
(mit etwa 10 Entwicklern) beteiligt, das am Ende dann aufgrund der zu hohen entstehenden Kosten abgesagt wurde. Gerade von neueren Kollegen (die wohl davor mit anderer Technologie gearbeitet haben) hat man am Ende des Projekts dann auch gerne mal die "Java ist aber auch sch***" Aussage gehört. Es sei alles viel zu umständlich, alles over-engineered und viel langsamer und verboser als das beispielsweise bei node.js oder anderen Sprachen der Fall wäre. Gerade das Spring Framework wäre totaler Müll und insgesamt müsste man doch in der Firma mal anfangen, die anderen Alternativen zu verwenden. In den anderen Sprachen "macht man einfach" und muss nicht vorher erstmal alles in 5 Schichten aufteilen.
Ich kann grundsätzlich zu sowas nicht viel sagen, weil ich selber noch nie in realen, größeren Projekten mit sowas wie node.js gearbeitet habe. Mir fehlt da also völlig der Vergleich und auch das Vorstellungsvermögen. Keine Ahnung ob das alles viel schneller und besser geht.
Da frage ich mich dann schon, ob ich mir vielleicht nicht Gedanken machen sollte, mal Zeit und Energie zu investieren, um die Alternativen zu erforschen. Ich stelle mir das aber sehr schwer vor, da auch das generelle Strukturieren vom Code irgendwie reiner Erfahrungswert ist. Ich persönlich strukturiere meinen Code so, wie ich es während der Arbeit in Java-Projekten von anderen Senior-Entwicklern gelernt habe. Macht man halt so. Hier in der Web-Welt teilt man halt nach MVC auf, baut sich seine Controller, Services, Repositories, DTOs, Converter, etc. Dann hat man gelernt was ungefähr der Controller übernehmen sollte, was der Service, was das Repository und so weiter. Aber auch dazu hört man immer mal wieder, wie umständlich das doch ist. Inversion of control ist auch unnötig, sowas wie dependency injection braucht man nicht und so weiter und so fort.
Wo soll man da ansetzen? Einfach mal die anderen Sprachen ausprobieren und schauen, ob man persönlich auch der Meinung ist? Kann man als junger Software-Entwickler überhaupt seiner eigenen Meinung vertrauen?
-
@Reconsider sagte in Programmiersprachen der Zukunft:
Wo soll man da ansetzen? Einfach mal die anderen Sprachen ausprobieren und schauen, ob man persönlich auch der Meinung ist?
Das wird sicherlich nicht schaden.
Ansonsten ist das viel BlaBla von Fanboys. Ja, manche Sachen gehen in manchen Sprachen besser. Das zu beurteilen bedarf dann Erfahrung. Die kommt mit der Zeit. Also hilft tatsächlich mal links und rechts über den Tellerrrand zu schauen.
-
@Tyrdal sagte in Programmiersprachen der Zukunft:
@hustbaer Was genau vermisst du denn bei git? Binärdaten?
Bin zwar nicht hustbaer, aber das stört mich bei git ganz gewaltig:
Es ist nicht möglich, Snapshots anderer Repositories in einen Snapshot aufzunehmen. Angenommen ich habe ein Projekt, das von libA, libB und libC anhängen. Ich möchte im Projekt Repository einen Snapshot anlegen, der von libA Rev 1, libB Rev 2 und libC Rev 1.2 abhängt. Das geht mit git nur, wenn ich die einzelnen Libs als Submodule zum Repository hinzufüge, aber damit habe ich einen Klon des Originals im Repo. Wenn im Klon was geändert wird (zB. Bugfixes) muss ich die wieder in den Master mergen. Bei einem Projekt ist das ok, aber wenn ich einige Projekte mit mehreren Klonen habe muss ich die überall mergen, und das gefällt mir nicht.
Was ich wirklich vermisse ist ein Feature, das einen Pull mit Abhängigkeiten in anderen Repositories macht und dabei die Repositories, zu denen Abhängigkeiten bestehen, automatisch "mitpullt".
-
@DocShoe Für sowas setzen wir hier conan ein. Da wird mittels git eine config für conan gespeichert und conan holt alles für den Entwickler notwendige.
