Programmiersprachen der Zukunft

SeppJ

@DocShoe sagte in Programmiersprachen der Zukunft:

@SeppJ
Erfolgsgarantie

Bin aber im Homeoffice

hustbaer

@DocShoe @SeppJ
Wenns um sowas krasses geht wie als Firma die Softwareentwicklung betreibt kein VCS zu verwenden, dann bin ich da nicht sehr diplomatisch und sage klar und unmisverständlich dass ich das für vollkommen wahnsinnig halte. Plus natürlich die sachlichen Argumente dazu warum.

Wenn die Argumente ignoriert bzw. wegdiskutiert werden ist der nächste Schritt dass ich sage "OK, wenn ihr glaubt dass wir das nicht brauchen, mir egal, glaubt es weiter, aber ich will es trotzdem haben". In einer Art und Weise die klar macht dass es sich dabei nicht um einen Wunsch handelt den die Firma ohne Konsequenzen ignorieren kann. Ist jetzt schwer da eine genaue Anleitung zu schreiben, aber im Prinzip geht es darum dem Gegenüber klar zu machen dass man sehr sehr angepisst sein wird wenn diesem Wunsch/dieser Forderung nicht entsprochen wird.

Vorausgesetzt natürlich die Forderung ist vernünftig. Aber ich kann mir wenig Gründe vorstellen warum die Forderung ein VCS zu verwenden in einem speziellen Fall unvernünftig sein könnte.

Und wenn auch das nichts hilft, und es mir wichtig genug ist, dann würde ich einfach kündigen. Bzw. davor vermutlich nochmal mit meinem Vorgesetzten sprechen und ihm erklären warum ich kündigen werde wenn sich nichts ändert. Wobei ein grosser Teil des Grundes dann sein wird dass ich keine Lust habe für eine Firma zu arbeiten die entweder glaubt dass ich Dinge wie ob es Sinn macht ein VCS zu verwenden nicht objektiv beurteilen kann oder die meint die Forderung aus einem anderen Grund ignorieren zu müssen/können.

Im Prinzip das selbe wie wenn ich deutlich unter Wert bezahlt werde und dann deswegen kündige - was ich bereits getan habe.

SeppJ

Ich weiß nicht. zip-Archive habe für uns immer gut funktioniert. Und ich habe mal git ausprobiert, das war total kompliziert. Die Leute jammern auch überall, dass es so kryptisch wäre. Ich denke auch nicht, dass wir dort unseren bisherigen zip-Archiv Workflow abbilden können.

hustbaer

@SeppJ Willst du jetzt ne Demo oder was soll das werden?

Davon abgesehen: git ist auch total kompliziert. Aber es muss ja nicht git sein. Subversion ist auch gut und viel einfacher. Und wenn die Devs sogar für Subversion zu doof sind gibt es immer noch Systeme wie SourceGear Vault.

Quiche Lorraine

@hustbaer
Ich glaube das ist nur Spaß.

Git mag auf der Console kompliziert sein, aber hierfür gibts Oberflächen wir TortoiseGit. Und ehrlich gesagt ist damit ist die Sache aus meiner Sicht einfach.

Aber ich habe auch diverse "Abgründe" in Sachen CVS bzw. ZIP Archiven erlebt. Meine Erwartungen an eine Versionsverwaltung sind daher ein wenig niedriger als vielleicht bei anderen Leuten.

@SeppJ
Und das Branching ist so einfach! Einfach [Strg]+[c], [Strg]+[v] und gut iss!

SCNR

@SeppJ sagte in Programmiersprachen der Zukunft:

Ich denke auch nicht, dass wir dort unseren bisherigen zip-Archiv Workflow abbilden können.

Doch, das geht ganz wunderbar. Seit wir die ZIP-Dateien in git versionieren ist noch nie eine verloren gegangen. Da einzige Problem ist der Platz. Das Repository ist jetzt 35TB gross und wächst täglich ...

hustbaer

@Quiche-Lorraine sagte in Programmiersprachen der Zukunft:

Git mag auf der Console kompliziert sein, aber hierfür gibts Oberflächen wir TortoiseGit. Und ehrlich gesagt ist damit ist die Sache aus meiner Sicht einfach.

Nö, ich meine nicht das Command-Line Interface. Ich meine Git ist konzeptionell kompliziert.
Nicht Rocket Science, aber erklär Git mal einer Dofnuss. Vor allem einer Dofnuss die es gar nicht verstehen will.

It0101

@DocShoe sagte in Programmiersprachen der Zukunft:

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".

Das vermisse ich auch. Eine Art
git pull --recurse-submodules

Ist aber eigentlich auch mein einziger Kritikpunkt an git. Wir arbeiten viel mit Submodules, weil nach reiflicher Überlegung die Alternativen noch verworrener erschienen.

It0101

@Quiche-Lorraine sagte in Programmiersprachen der Zukunft:

Git mag auf der Console kompliziert sein, aber hierfür gibts Oberflächen wir TortoiseGit.

Ich finde Git auf der Konsole im Rahmen des Daily Business überhaupt nicht kompliziert. Nachdem ich anfangs auch Konsolenverweigerer war, finde ich es jetzt super und nutze die GUI nur noch gelegentlich zur Visualisierung.

Quiche Lorraine

@hustbaer

Nö, ich meine nicht das Command-Line Interface. Ich meine Git ist konzeptionell kompliziert.
Nicht Rocket Science, aber erklär Git mal einer Dofnuss. Vor allem einer Dofnuss die es gar nicht verstehen will.

Was willst du mir damit sagen?

Den Zusammenhang zwischen "Doofnuss will nicht verstehen" und Kompliziertheit von Git verstehe ich nicht. Was kann Git dafür das jemand Git nicht verstehen will?

Für den Anfang reicht es doch zu wissen was ein Push, Pull, Commit und ein Diff macht. Oder etwa nicht?

wob

@Quiche-Lorraine sagte in Programmiersprachen der Zukunft:

Für den Anfang reicht es doch zu wissen was ein Push, Pull, Commit und ein Diff macht. Oder etwa nicht?

Nein, reicht nicht. Rebase und Merge musst du kennen. Was tust du, wenn ein Konflikt auftritt oder du den vorvorletzten Commit nochmal ändern musst? ("interactive rebase"). Und wie funktioniert das mit Branches, was sind tracking-Branches? etc. Was ist, wenn du "irgendeinen komischen Status" erreicht hast und nicht wieder zurückkommst? (Lösung a: Verzeichnis komplett kopieren, Repo neu clonen und Änderungen von Hand rüberkopieren?) Nur sollte doch in einer Softwarefirma sich irgendjemand finden lassen, der das kennt.

Leon0402

Was man können muss, um git zu können, ist dann doch sehr subjektiv.

Defintiv:

Push & Pull
add & commit (wobei das mit einer guten gui z.B. integriert in VS Code relativ selbsterklärend ist ... selbst als Konsolen Liebhaber, nutze ich dafür oft die gui)
Branches erzeugen können und zwischen diesen wechseln können (Und damit verbunden den Workflow kennen, den man verwendet)

Nun der Merge/Rebase Teil, meistens arbeitet man ja doch mit tools wie gitlab etc. und merge requests:

Man kann per Button mergen, wenn es keine merge Konflikte gibt
Mann muss das auch nicht unbedingt selbst machen ... Code Reviewen macht eh jemand anderes (hoffentlich) und einen git "Experten" wird es schon geben, der das Zeugs dann mergt
Wenn man es dann doch mal selbst können möchte, halte ich es auch nicht für zwingend notwendig rebase zu kennen. Sollte man können, wenn man es ernst meint, aber notwendig ist es nicht

Optionalerweise möchte man vlt. auch den Code von anderen reviewen können:

Auch hier kann man in gitlab / github schon recht weit kommen, wenn man diffs lesen kann
Will man es dann doch mal ausprobieren, sollte man fetch kennen und das Prinzip von remote tracking branches -> Im besten Fall guckt man sich hier auch mal an was denn HEAD bedeutet

In der historie rumspringen, die Historie verändern, cherry picken und anderer Kram sind optional. Klar sind das teilweise features, die git Nutzung erst rechtfertigen, aber man kommt eben auch relativ gut ohne aus (und zu wissen, dass man theoretisch davon Gebrauch machen könnte, kann ja als Begründung git zu nutzen ja schon ausreichen)

Vorraussetzung so ein bisschen ist natürlich, dass einer git zumindest akzeptabel kann (Das ist ist den meisten Fällen aber ja gegeben ... einer muss ja vorgeschlagen haben, es zu nutzen ;)). Dann sollte man mit einer 5min Einführung für alle anderen in git recht weit kommen.

Es ist nun mal auch ein wichtiges tool und ich würde grade von Entwicklern erwarten, dass sie mal sich 30min damit auseinandersetzen können. Ist immer schwierig sich von alten Gewohnheiten loszulösen, aber git ist jetzt auch nicht grade von gestern und so ein "Trend tool", was in 3 Monaten wieder abgelöst ist. Ein bisschen anpassen muss man sich eben an den Fortschritt.

Edit: Und vermutlich sind meine "Must Haves" sogar noch viel zu hoch gegriffen. In erster Linie muss es ja erstmal nur den zip Workflow ersetzen und entweder braucht man dann gar keine branches oder zumindest kein mergen, sondern kann wie gewohnt den Code manuell rüber kopieren auf den master

wob

@Leon0402 sagte in Programmiersprachen der Zukunft:

Nun der Merge/Rebase Teil, meistens arbeitet man ja doch mit tools wie gitlab etc. und merge requests:

Man kann per Button mergen, wenn es keine merge Konflikte gibt
Mann muss das auch nicht unbedingt selbst machen ... Code Reviewen macht eh jemand anderes (hoffentlich) und einen git "Experten" wird es schon geben, der das Zeugs dann mergt
Wenn man es dann doch mal selbst können möchte, halte ich es auch nicht für zwingend notwendig rebase zu kennen. Sollte man können, wenn man es ernst meint, aber notwendig ist es nicht

Das kommt aber wirklich stark darauf an!

Wir verwenden hier Gerrit als Review-Tool (so eingerichtet, dass jeder +2 geben kann und dann "Submit" klicken kann, sofern Jenkins nichts dagegen hat) und haben entschieden, dass es klarer/einfacher ist, wenn wir normalerweise immer git pull --rebase; gerrit_push_review machen, wobei letzteres ein Alias ist auf git push origin HEAD:refs/for/$(git symbolic-ref --short -q HEAD).

Merges führen gerne zu wilder Historie.

Aber das kommt sicher total darauf an, wie man arbeitet. Wir haben meist nur einen Haupt-Branch (und ggf. Branches für große, langfristige Features, die dann auch irgendwann gemerget werden, sowie Branches für Release-Fixes). Also im Prinzip machen wir zu 99% rebase und nur ganz selten mal einen merge.

Kommt aber mit Sicherheit total auf die Anzahl der Entwickler, das Team etc. an. Jendenfalls hatten wir das bei meinem ehemaligen Arbeitgeber so und ich habe das dann seit Anfang an in der Firma, wo ich jetzt bin, so eingeführt - und es funktioniert gut.

Ich benutze auch VSCode (wir haben hier 90% Python und 10% C++) und kommt mit dem grafischen Git-Zeugs überhaupt nicht klar - da weiß ich nie, was ich tatsächlich gerade mache

Leon0402

@wob sagte in Programmiersprachen der Zukunft:

Merges führen gerne zu wilder Historie

Ich will dir auch gar nicht widersprechen, rebases haben schon ihre Berechtigung. Aber gewissermaßen sind sie eben nur nice to have. Git Historie kann man eh erstmal vergessen, denn wer neu mit git anfängt macht nur commits wie "Aktueller Stand, ich mach Feierabend, bis morgen!"
Kommt natürlich auch drauf an mit welcher begründung man git verwendet ... für mich ist der absolute Hauptgrund erstmal, dass man im Team angenehm zusammen arbeiten kann. Aus diesem Grund ist meine Liste mit den absoluten Grundanforderungen auch nur gering. Wenn dann mal jeder git für ein paar Wochen benutzt hat und sich einigermaßen sicher damit fühlt, würde ich natürlich auch dafür sorgen wollen, dass die anderen Vorteile von git gut genutzt werden können

@wob sagte in Programmiersprachen der Zukunft:

Ich benutze auch VSCode (wir haben hier 90% Python und 10% C++) und kommt mit dem grafischen Git-Zeugs überhaupt nicht klar - da weiß ich nie, was ich tatsächlich gerade mache

Echt nicht? Also im allgemeinen bin ich wirklich absoluter Konsolen fan, was git (und viele weiter tools angeht) und hier so ne git gui wie sie z.B. in pycharm drin ist, wo man dann alle branches sieht und buttons zum pushen/pullen/fetchen etc. hat geht einfach gar nicht.
Aber den git tab von VsCode finde ich wirklich eine große Erleichterung ... ich sehe auf einen Blick welche Dateien sind geändert haben, kann sie anklicken für einen diff und per maus klick adden. Auch commiten geht damit vergleichweise einfach.
Sehr minimalistisch gehalten!
Ich adde allerdings auch oft über die Konsole und commite, gerade wenn ich eig. alles adden will und das genau im Blick habe

Edit: Man kann übriegens auch in gitlab rebasen per Button soweit ich weiß (zumindest bei der properitären variante?)

hustbaer

@Leon0402 sagte in Programmiersprachen der Zukunft:

Es ist nun mal auch ein wichtiges tool und ich würde grade von Entwicklern erwarten, dass sie mal sich 30min damit auseinandersetzen können.

Wenn du dich 30min mit Git beschäftigst, dann hast du danach immer noch "überhaupt keine Ahnung" bis maximal "keine gute Vorstellung davon" wie Git funktioniert. Egal ob du vorher noch nie mit einem SCM gearbeitet hast oder schon Erfahrungen mit einem klassichen zentralen System wie SourceSafe oder SVN hast.

Wäre es so einfach, wäre es ja kein Problem. Ist aber eins. Nur wie gesagt: es muss nicht immer gleich Git sein.

Leon0402

@hustbaer Das war auch nicht die Anforderung Es ging ja darum, was das absolut notwendigste ist, dass man sein zip Workflow durch git ersetzen kann. Und das bringe ich jemanden in 5min bei.
Klar wenn man neu in ein Team mit 10 Git Experten kommt, die einen extrem komplexen Workflow haben (sicher auch begründet), dann ist das neue Teammitlgied total überfordert und wird git unglaublich komplex finden.
Alles ist komplex, wenn man nur tief genug einsteigt. Aber das muss ja nicht sein. Man muss nicht eine gute Vortstellung von git haben, um einigermaßen gut miteinander arbeiten zu können ... das kommt alles mit der Zeit, insbesondere wenn Leute neugierig sind und sich irgendwann von alleine Fragen "Kann man das hier nicht besser machen ... gibt es nicht feature xyz" und dann danach googeln oder jemand Fragen. So eine Neugier gehört eig. zu den Grundeigenschaften von den meisten Entwicklern, die ich so kenne
Und zumindest mir ging es irgendwann so, dass ich dann auch mal git besser verstehen wollte (z.B. was es mit diesem misteriösen HEAD auf sich hat ... wie branches eig. technisch realisiert werden ... wie so ein commit technisch aussieht etc.

hustbaer

@Quiche-Lorraine sagte in Programmiersprachen der Zukunft:

@hustbaer

Nö, ich meine nicht das Command-Line Interface. Ich meine Git ist konzeptionell kompliziert.
Nicht Rocket Science, aber erklär Git mal einer Dofnuss. Vor allem einer Dofnuss die es gar nicht verstehen will.

Was willst du mir damit sagen?

Den Zusammenhang zwischen "Doofnuss will nicht verstehen" und Kompliziertheit von Git verstehe ich nicht. Was kann Git dafür das jemand Git nicht verstehen will?

Ach du lieder Strohmann.

Git ist kompliziert. Das ist erstmal so, unabhängig von irgendwelchen Doofnüssen. Der Zusammenhang: Je komplizierter es ist, desto schwieriger ist es einer Doofnuss beizubringen. Und erst recht einer widerwilligen Doofnuss. Und je einfacher es ist, naja desto einfacher... muss ich das wirklich noch weiter ausführen?

Für den Anfang reicht es doch zu wissen was ein Push, Pull, Commit und ein Diff macht. Oder etwa nicht?

Hmja, Branchen und Rebasen sollte man denke ich noch können. OK. Und du meinst das sei einfach? Du musst davon ausgehen dass viele Entwickler die in so "source-zips auf file-shares" Firmen arbeiten noch nie irgend ein VCS Verwendet haben und daher auch null komma überhaupt gar keinen Plan davon haben. Da fehlen sämtliche Grundlagen.

hustbaer

@Leon0402 Wenn du mit einem VCS einfach und unkompliziert arbeiten willst, ohne dass du etliche wichtige Grundlagen gut verstanden hast, dann ist Git mMn. das total falsche Tool. Dafür kann man sich damit mMn. viel zu einfach selbst ins Knie schiessen. Da ist SVN oder das bereits erwähnte Vault viel besser.

Es ging ja darum, was das absolut notwendigste ist, dass man sein zip Workflow durch git ersetzen kann. Und das bringe ich jemanden in 5min bei.

"Jemandem" vielleicht. Der durchschnittlichen zip-Workflow Doofnuss eher nicht.

Alles ist komplex, wenn man nur tief genug einsteigt. Aber das muss ja nicht sein. Man muss nicht eine gute Vortstellung von git haben, um einigermaßen gut miteinander arbeiten zu können (...)

Uiuiui. Das sehe ich ganz anders. Klar, es muss nicht jeder Experte sein. Aber speziell wenn man versucht den Ball flach zu halten und z.B. erstmal ohne PR Workflow und mandatory Reviews arbeitet... also ich kann mir nicht vorstellen dass das lange gut geht.

Leon0402

Ich persönlich kenne jetzt svn nicht, was macht svn so viel einfacher?

Ich fand git gemessen an der Funktionalität von der Komplexität immer okay. So als Beispiel das man ne staging area hat ... das erscheint am Anfang erstmal unnötig komplex ... aber gleichzeitig kann man solange es man nicht braucht auch einfach immer git add . machen. Wenn ich allerdings das feature haben möchte, dann erscheint mir das vergleichweise unkomplex für die hohe Flexibilität, die ich dafür erlange
Ähnlich ist es mir dann auch mit nachfolgenden Sachen gegangen.
Es ist halt ein tool, was durchaus einige Poweruser features hat und die sind entsprechend komplex, aber das muss einen ja nicht kümmern.

Einfacher geht sicher immer, auf der anderen Seite nutzen ja vorwiegend Entwickler VCS. Und wenn jemand C++ lernt / kann, dann sollte derjenige eig. in der Lage sein git zu lernen ohne komplett zu verzweifeln. Ähnlich für jede andere Sprache (mit Ausnahme von python vlt )

Wenn ich an tools denke die ich sonst noch so gelernt habe zu nutzen z.B. Debugger, CMake etc. dann würde ich git schon fast als trivial zu lernen einstufen

hustbaer

@Leon0402 sagte in Programmiersprachen der Zukunft:

Ich persönlich kenne jetzt svn nicht, was macht svn so viel einfacher?

Ein wichtiger Punkt ist dass in SVN kaum jemand mit Feature-Branches arbeitet. (Technisch gesehen gibt es in SVN auch gar keine Branches, aber das ist dann wieder ein anderes Thema.)

Du checkst dir eine Working-Copy (quasi wie ein Checkout, KEIN lokaler Repo-Klon) vom Server aus, und arbeitest mit der. Wenn du was auf den Server zurückschieben willst dann commitest du es ("svn commit" erzeugt eine neue Revision am Server). Das geht aber nur, wenn die von dir geänderten Files dazwischen nicht auch am Server verändert wurden. Wenn doch, dann musst du erstmal "svn update"n (quasi ein "fetch + rebase origin/master" deiner Working-Copy) bevor du committen kannst. Wenn dabei Konflikte entstehen bekommst du nicht nur die üblichen Conflict-Marker in die Files geschreiben, sondern auch Kopien der drei beteiligten Versionen (common base, yours, theirs) in deiner Working-Copy. Dann behebst du die Konflikte, teilst SVN explizit mit dass du sie behoben hast, und kannst nochmal probieren zu committen.

Es gibt zwar "auto-merging" (bzw. auto-rebasing) beim "svn update", aber nicht beim "svn commit". Wenn ein commit eines Entwicklers Blödsinn erzeug that, dann hatte der Entwickler diesen Blödsinn immer 1:1 vorher so auf der Platte.

Sowas wie History-Rewriting gibt es bei SVN auch nicht. Es gibt einen (extrem aufwendigen, zeitintensiven) Umweg wie man es machen kann. Aber dazu braucht man direkten Zugriff auf den Server. Und kein vernünftiger Mensch macht das freiwillig.

Der Knackpunkt ist: SVN kann viel weniger, ist dadurch aber auch viel einfacher.

Und Systeme wie Vault sind - je nachdem wie man sie konfiguriert - nochmal viel einfacher. (Falls du MS Source-Safe noch kennst: Vault ist quasi eine reparierte und gepimpte Version von MS Source-Safe.)

dann sollte derjenige eig. in der Lage sein git zu lernen ohne komplett zu verzweifeln

Ja nur viele wollen das einfach nicht, weil es sie nicht interessiert. Die investieren dann genau so viel Zeit bis sie es irgendwie hinbekommen dass scheinbar das passiert was sie wollten. Und keine Sekunde mehr.

Bzw. viele folgen auch gerne stur irgendwelchen Anleitungen die ihnen jemand gegeben hat, ohne Rücksicht auf Verluste und ob dabei vielleicht ganz viel Unsinn passiert. Oder kombinieren auch gerne verschiedene Anleitungen aus verschiedenen Quellen.

Und dann hast du schnell viel Blödsinn beinander.