Programmiersprachen der Zukunft
-
@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.
-
@Quiche-Lorraine sagte in Programmiersprachen der Zukunft:
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.
-
@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.
-
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
-
@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.
-
Man muss aber auch nicht die ganze Git Feature Welt benutzen.
IMHO hängt das davon ab wie viele Menschen an einem repo arbeiten.
Je mehr dran arbeiten, desto mehr müssen alle git können. Beziehungsweise desto wichtiger wird es.
-
@hustbaer sagte in Programmiersprachen der Zukunft:
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?
Das Problem ist einfach. Ich habe zuviele Leute gesehen welche einfach nicht wollen, deren Gürtellinie auf der Stirn beginnt, gerne auch mal Diskussionskriege anfangen oder einfach LMAA als Lebensphilosophie haben.
Die Einführung von git beispielsweise erzeugte bei uns ein halbes Jahr nur Stunk. Einige wollten überhaupt keine Versionsverwaltung, andere wollten CVS, andere SVN, usw... Im Nachhinein natürlich. Und so macher Troll lief zur Höchstleistung auf. Manchmal hatte ich das Gefühl, die Leute hatten Angst sie müssten ihr Geschlecht wechseln, so emotional wurden die Diskussionen stellenweise.
Nach cirka einen halben Jahr legte sich dann die Aufregung und man begann sich mal ernsthaft mit git zu befassen. Und dann machte es bei vielen click.
Einen schlimmen Fall habe ich auch bei einem indischen Entwicklerteam gesehen, welches für mich zum Inbegriff der Gelassenheit und Schnarchnasigkeit wurde. Stell dir einfach mal vor, alle deine Sätze beginnen mit "Ist ja nicht so schlimm", "Mach ich morgen" oder "Passt schon". Mach das mal einen Tag, dann hast du einen ungefähren Blick in deren Mentalität. Ich habe es beispielsweise bis heute nicht geschafft denen die Idee aus Kopf zu schlagen mittels Polling auf das Ende eines nicht modalen Fensters zu warten. Oder das es nicht gut ist, wenn ein nicht modales Fenster sein Parent Fenster blockiert und in den Hintergrund gelegt werden kann. Oder das man einen Dateiexport nach X ms nicht einfach unterbricht.
Von daher überzeugt mich ein Argument "ein Tool muss möglichst einfach sein, damit es alle verstehen" nicht mehr so recht.
Manchmal hilft da einfach auch nur "Lernen durch Schmerzen"
-
@Quiche-Lorraine Den Krieg hast du vermutlich so oder so, ja. Aber ich denke es kann trotzdem Sinn machen mit einem einfacheren Tool anzufangen. Ich sage ja nicht es muss immer ein einfacheres Tool sein. Ich sage bloss es muss nicht immer Git sein.
Genau so wie es nicht immer C++ sein muss.
-
Back to Topic: Ich finde, fefe bringt es gut auf den Punkt, weshalb Rust zunehmend C und C++ ablösen kann und wird. Microsoft, Google und Co. wollen Rust ebenfalls zunehmend einsetzen.
-
@Steffo sagte in Programmiersprachen der Zukunft:
ablösen
Niemand wird den NT-Kernel oder Linux in Rust neu schreiben.
-
@Swordfish sagte in Programmiersprachen der Zukunft:
Niemand wird den NT-Kernel oder Linux in Rust neu schreiben.
Aber es gibt Gedanken Rust in den Linux Kernel zu integrieren.
-
Dieser Beitrag wurde gelöscht!
