Fefe rantet über C++...

Auch Assembler braucht nen Compiler für die Umwandlung in Maschinencode.
In der Tat. Wobei der Layer zwischen Assembler und Maschinencode extrem dünn ist. Nicht zu vergleichen mit C or whatever und Assembler.

Nicht jedes Performance-Problem lässt sich mit Hardware erschlagen
War auch so nicht gemeint. Ich wollte damit nur klar stellen, dass es eben mehrere Optionen gibt und auch in der Praxis mindestens genauso (wenn nicht gar häufiger) zum tragen können als irgendwelche Handoptimierungen.

ganz einfach weil keine unendliche schnelle Hardware existiert.
Während richtig geschriebenes C++ natürlich unendlich schnell ist. :-)

Wenn dein Problem sicher in 5min lösbar ist und unsicher in 20s, dann diskutiert man das nicht unbedingt einfach weg.
Das kommt ja meist noch hinzu. Bei C++ ist auch die Implementierung zeitaufwendiger.
Ich brauch länger und hab auch dann noch potentiell unsicherebn Code. Sprich: C++ setze ich nur ein, wenn es wirklich nicht anders geht.

Da ist das Vermeiden von [] in C++ jetzt auch nicht so das Mega-Problem.
Ja. Nur das eben C++ ein Flickenteppich ist und Du an allen Ecken und enden solche Späße hast.

Ich hab nur schon selbst Projekte gesehen, die in ziemlich große Performance-Probleme gerannt sind und letztendlich unsafe die einzige Lösung war.
Mit ich hab irgendwas von meinem Schwager gehört der irgendwo gesehen hat das lässt sich schwer diskutieren. Entweder Du hast ein konkretes Beispiel parat oder nicht. Alles andere ist unbrauchbar für eine Diskussion.

Hat niemand behauptet. Das Thema ist halt C++.
Bullshit. Über Rust und D und sogar C# wird hier im Thread auch gesprochen. Aber Fortran ist plötzlich ein No-Go.
Merkst selbst, ne?

Du wirst auch vermutlich im Nachwuchs-Markt für Programmierer nur noch wenig Leute finden die Fortran können.
Keine Ahnung.
Wieviel gibt es denn am Nachwuchsmarkt, die C++ können?

Huh? Darum gehts doch gar nicht.
Ich nehme nur auf, was DU sagst. Also beschwer Dich nicht bei mir.
Und auch ein C++ Compiler optimiert.

Ich erlaube dem Entwickler einen unsicheren Pfad für Performance-Kritische Stellen, oder ich knalle automatisch alles mit Sicherheits-Checks zu und hoffe, dass der Compiler schon selbst erkennt was ohne sowas auskommt. C++ ist im Standard eher unsicher, geht aber auch sicher
Nur alles sehr intransparent. Das geht wesentlich eleganter, wie schon erläutert.

Java ist Im Standard sicher, der Compiler versucht was er kann. Und das Thema ist jetzt C++ quasi in die Richtung der Java-Arbeitsweise zu kriegen.
Versteh ich nicht.

Niemand hat behauptet, dass C++ (oder sogar C) ein Write-Once-Compile-Anywhere ist.
Wie gesagt. Du kriegst ja schon Probleme beim Wechsel des Compilers. Bei Wechsel der Hardware dürfte die Hürde entsprechend noch höher sein.

Das betrifft natürlich nicht alle Projekte und ich bin durchaus dafür neue Projekte in einer Sprache wie Rust zu schreiben, wenn es möglich ist. Es löst aber halt trotzdem nicht alle Probleme.
Hab ich auch so nie gesagt. Genau genommen hab ich zu Rust gar keine Stellung bezogen. Du wirfst mir Rust andauernd vor die Füße und anhand dessen zu belegen, wo C++ gut ist. Und wenn man dann doch mal ne andere Sprache in die Diskussion bringt heißt nur lapidar das ist ein C++ Thread.

Unteranderem auch das wirkt so, als wolltest Du C++ schönreden. Und genau deshalb hab ich auch was in dem Thread geschrieben. Ich sehe keinen Grund Dinge schönzureden und benenne sie lieber klar wie sie sind. Das ich am Ende des Tages aus bestimmten Gründen trotzdem C++ schreibe steht auf einem anderen Blatt.
 
Klein! :) Aber der Blick aus der Ferne läßt manches erkennen was aus der Nähe nicht so ohne weiteres erkennbar ist. Und wo kämen wir hin wenn nur noch die Auffassung von Insidern gelten würden: Dann stimmt nämlich die Welt - bis auf Marginalien - immer!

Im übrigen: Das sind so rhetorische Argumente wenn man den zu den sachlichen nichts ernsthaftes sagen will oder kann...

Doch, genau das Argument ist der Kern der ganzen Diskussion. In jeder einzelnen dieser im weiteren Sinne "Man müsste alles neu schreiben"-Diskussionen. Den Teilnehmern, damit meine ich nicht einmal dich direkt, ist oft mangels eigener Erfahrung der riesige Wert vorhandenen Codes einfach nicht klar. Joel Splosky hat das schon vor 18 jahren umfassend beschrieben: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

Um auf die obige Analogie mit Autobahnbrücken zurückzukommen, tatsächlich werden in Deutschland zwar munter neue Autobahnbrücken gebaut, aber nur in absoluten Ausnahmefällen, wenn es gar nicht anders geht, neue Brücken konstruiert. Man hat nämlich in den 1960er Jahren, als man das heutige Autobahnnetz baute, einige wenige Standardtypen von Autobrücken konstruiert. Über die Jahre hat man in diese Konstruktionen die Erkenntnisse aus Wartung, Verschleiß, Reparaturen und so weiter eingebracht. Man hat sie auf veränderte Rahmenbedingungen wie mehr Verkehr oder schwerere Fahrzeuge angepasst. So ist man schrittweise zu nahezu perfekten Autobahnbrückenkonstruktionen gekommen, die man nun einfach aus der Schublade holen und gute Gewissens bauen kann. Das ist übrigens auch der Grund weshalb die meisten Brücken sich sehr ähnlich bis gleich aussehen. :)

Software ist genauso. Jedes Mal wenn ein neues Feature eingebaut und damit der vorhandene Code refactored wird, wenn man Bugs fixt, Performanceverbesserungen vornimmt und weitere Dinge tut steigt das im Code enthaltene Know-How an. Und dieses Know-How steckt nur im Code, es lässt sich bei real existierender Software schon durch dessen Komplexität kaum extrahieren. An Doku braucht man gar nicht zu denken, selbst wenn sie existiert geht sie nicht ausreichend in die Tiefe. Das kann sie gar nicht.

Die Sprache zu wechseln bedeutet aber den Code neuzuschreiben und damit das darin enthaltene Know How zu verlieren. Das ist sowohl technischer als auch wirtschaftlicher Selbstmord, weshalb es so gut wie nie passiert. Was in letzter Konsequenz dazu führt, dass dort draußen noch Milliarden Zeilen Cobol im Einsatz sind. Oder an der Spitze des Eisbergs diese schöne Geschichte: http://lists.llvm.org/pipermail/llvm-dev/2017-June/114756.html Die ältesten Univac 2200 waren noch Röhrencomputer!

Selbst Giganten mit nahezu unbegrenzten Ressourcen machen es nicht. Als Twitter mit Ruby am Ende war, da die technischen Grenzen der Plattform erreicht haben, haben die auf JRuby portiert und selektiv kritische Teile in dank der JVM teilkompatiblen Java neugeschrieben. Google hat das in Python implementierte Youtube in Python gelassen und lieber einen Python->Go-Transcompiler gebaut. Facebooks Kampf aus PHP eine bessere Sprache zu machen ist ebenfalls fast episch... Auch Mozilla schreibt Firefox ja nicht in Ruby neu. Sie haben Rust so konzipiert, dass es ausreichend mit C/C++ kompatibel ist um gezielt die Bereich des C++-Codes durch Rust zu ersetzen, wo dessen Einsatz sinnvoll ist. Zum Beispiel der URL-Parser.

Aus diesen Gründen bin ich der Meinung, dass Sprachen wie D gut gemeint sind aber in der Praxis keine Chance haben. Sie zwingen einfach zu viel Know How wegzuwerfen, sind damit maximal für Neuprojekte interessant, oft aber durch vorhandene Bibliotheken und die Begrenzungen vorhandener Schittstellen nicht mal dort. Es ist daher immer sinnvoller vorhandene Sprachen zu verbessern, so wie die C++-Entwickler seit C++11 versuchen über die vorhandene Sprache eine neue, bessere aber zu 100% rückkompatible Sprache rüberzubauen.
Darum sind die auch die ganzen alternativen JVM- und CLR-Sprachen erstaunlich schnell groß geworden. Sie bauen durch ihre Kompatibilität mit anderen JVM und CRL-Sprachen eine Brücke, den alten Code weiternutzen und diesen schrittweise, an den Stellen, wo es Sinn hat auf eine neue, moderne Sprache zu portieren. Rust, dessen Entwickler von Beginn an Wert auf eine gute C-Schnittstelle legten, tut das ebenfalls.
Python 3000 baute aber zum Beispiel so eine Brücke nicht. Und obwohl die Unterschiede zwischen Python und Python 3000 überschaubar waren und die Portierung oft relativ einfach möglich, ohne allzu viel am vorhandenen Code verändern zu müssen, dauerte es viele lange Jahre, bis auch nur die Kern-Bibliotheken des Python-Ökosystems portiert waren. Ich sehe dann auch immer noch viel mehr Python 2.6 Anwendungen, als Python 3.x. Darauf angesprochen zucken die Entwickler mit den Schulter und sagen "Lass mal stecken. Könnte der Interpreter Python und Python 3000 parallel ausführen, wären wir schon lange da. Aber so? Warten wir erstmal ab."
 
@Yamagi: Das mit Python stimmt so nicht, man hat diverse Brücken gebaut auf beiden Seiten um keine der Seiten zu vergraulen.Es gibt auch einen gutes Video dazu, finde es gerade nicht. DIe ganzen __future__ Maßnahmen als Indiz.
 
Ich habe diese Diskussion mit großer Aufmerksamkeit und Interesse verfolgt. Meineserachtens gibt es die "Programmiersprache" nicht. Eine Programmiersprache wird deshalb favorisiert oder bevorzugt, weil sie eine spezielle Aufgabe effizient löst. Das kann je nach Aufgabenstellung und Anforderungsprofil eben C, C++, Java oder x ..... sein. Jede Sprache hat Vor- und Nachteile, dessen bin ich mir auch schon bewußt. Schlußendlich spielen auch die Resourcen Zeit und Geld eine nicht untergeordnete Rolle, denn sie sind nicht unendlich. C++ wurde von Bjarne Stroustrup erfunden, weil Programme immer komplexer wurden. Daher war diese Weitentwicklung von C zu C++ unumgänglich. Das ist jetzt zwar verkürzt dargestellt, aber so habe ich es gelernt. Und hier gibt es eine Menge Kompetenz, aber vieles scheint mir eher theoretischer Natur zu sein. Und deshalb frage ich provokatorisch in die Runde, welchen Stellenwert hat die Erfahrung und die Programmierpraxis? Gibt es vorzeigbare Projekte, die praktikabel im Alltagsleben eines Nutzers einen Mehrwert darstellen, weil es die tägliche Arbeit erleichtert? Oder einfach nur Neugier, um den Programmierhorizont (theoretisch) zu erweitern? Es macht doch wirklich keinen Sinn, von einer Hochsprache zur anderen zu wechseln, bevor ich nicht eine einzige Sprache richtig verstanden habe. Und wie lange braucht es, um in einer einzigen Hochsprache wirklich kompetent zu sein und damit meine ich wirklich ein Profi zu sein, der ein Problem eher spielerisch löst? Heute weiß ich, das es mindestens 10 Jahre dauert, bis das jemand von sich behaupten kann. Und diese Zeitspanne gilt nicht nur für Programmierer, sondern läßt sich auch auf viele anderen Bereiche anwenden.

Ich habe mal ein paar Links zusammengetragen, wobei ich den ersten als sehr wichtig erachte:

http://userpage.fu-berlin.de/~ram/pub/html_jf47ht81Ht/21-tage

https://lerneprogrammieren.de/wie-lange-braucht-man-zum-programmieren-lernen/

https://codingtutor.de/programmieren-lernen-wie-lange-dauert-es/

https://www.gutefrage.net/frage/wie...oennnen-und-andere-profis-und-hat-jemand-tips

https://entwickler.de/online/development/10-skills-softwareentwickler-255336.html

Denkt mal drüber nach .... ;)
 
Unteranderem auch das wirkt so, als wolltest Du C++ schönreden. Und genau deshalb hab ich auch was in dem Thread geschrieben. Ich sehe keinen Grund Dinge schönzureden und benenne sie lieber klar wie sie sind. Das ich am Ende des Tages aus bestimmten Gründen trotzdem C++ schreibe steht auf einem anderen Blatt.

Ich kann gerade gar nicht mal so wirklich nachvollziehen, was dir gerade für eine Laus über die Leber gelaufen ist, vor allem wenn du dir plötzlich Aussagen von mir ausdenkst oder eigenartig interpretierst. Ich hab auch ehrlich gesagt gerade keine Lust "auf dem Level" mit dir darüber zu diskutieren. Nimm von mir aus die Programmiersprache die du willst. Mir ist das unterm Strich vollkommen egal.
 
Doch, genau das Argument ist der Kern der ganzen Diskussion. In jeder einzelnen dieser im weiteren Sinne "Man müsste alles neu schreiben"-Diskussionen. Den Teilnehmern, damit meine ich nicht einmal dich direkt, ist oft mangels eigener Erfahrung der riesige Wert vorhandenen Codes einfach nicht klar.

Das ist das ärgerliche an solchen Diskussionen: Sprache ist nun einmal Kontextsensitiv und wir sind darauf angewiesen (wenn wir denn ernsthaft miteinander reden wollen) dass wir den jeweiligen Kontext in unserer Verständnis einbeziehen und den jeweils gmeinten Sinn entschlüsseln, und nicht in das gesagte die eigenen Vorurteile hineinlesen. Niemand hier, und ich am allerwenigsten, hat die "man müßte alles neu schreiben" Position vertreten, - das wäre ja auch ausgemachter Unsinn!

Ich weiss nicht ob Joel Splosky in o.g. Artikel recht hat oder nicht. Ich weiss aber dass es eine Menge Projekte gibt - Software, Hardware, Real-Life - die gescheitert sind, aus diesen oder jenen, oder auch ganz anderen Gründen. Und jedes Beispiel ist eine Auswahl aus der Vielzahl an Fällen. Es mag sein das Splosky richtig liegt, in diesen Fällen, aber ist das ausreichend um daraus eine allgemeine Regel zu machen? Und unter welchen Bedingungen gilt dann die Regel? Derartige Regeln stellen Weichen in unserem Denken und setzen uns auf Schienen in denen nur noch bestimmtes möglich erscheint, eine Vielzahl von Möglichkeiten aber von vorne herein ausgeschlossen wird.

Solche Regeln sind durchaus wichtig da sie eine gewisse Kontinuität im Denken und Handeln sicher stellen und man sich dann, wenn sie anerkannt werden, relativ leicht verständigen kann. In größerem Zusammenhang spricht man da ja von Paradigmen. Allein es ist die Frage unter welchen Bedingungen und wie lange solche Paradigmen sinnvoll sind denn wenn sich die Situation wesentlich verändert, können sie genau so zu einem ernsthaften Hindernis werden. Es kommt dabei also auf die Bewertung der jeweiligen (historischen) Situation an.
Software ist genauso. Jedes Mal wenn ein neues Feature eingebaut und damit der vorhandene Code refactored wird, wenn man Bugs fixt, Performanceverbesserungen vornimmt und weitere Dinge tut steigt das im Code enthaltene Know-How an. Und dieses Know-How steckt nur im Code, es lässt sich bei real existierender Software schon durch dessen Komplexität kaum extrahieren. An Doku braucht man gar nicht zu denken, selbst wenn sie existiert geht sie nicht ausreichend in die Tiefe. Das kann sie gar nicht.
Argumentierst du hier für oder gegen die Neuentwicklung von Scratch denn man kann das in beide Richtungen auslegen. ;)
Die Sprache zu wechseln bedeutet aber den Code neuzuschreiben und damit das darin enthaltene Know How zu verlieren. Das ist sowohl technischer als auch wirtschaftlicher Selbstmord, weshalb es so gut wie nie passiert.
Wieso denn das? Interoperationalität ist doch heute kein Hexenwerk mehr. Ich kann mich nicht erinnern das in einer der Sprachen mit denen ich mich beschäftigt habe nicht zumindest ein Interface zu C oder C++ vorhanden ist, sei es als FFI oder über einen Stack wie in Lua. Ich denke es gibt eine Reihe von Gründen hierfür, die Sprache allein wohl kaum.
... Auch Mozilla schreibt Firefox ja nicht in Ruby neu. Sie haben Rust so konzipiert, dass es ausreichend mit C/C++ kompatibel ist um gezielt die Bereich des C++-Codes durch Rust zu ersetzen, wo dessen Einsatz sinnvoll ist.
Eben! Das ist für mich ein gutes Beispiel für incrementielle Überarbeitung von veraltetem Code. Das ist natürlich aufwendig, aber vermutlich lohnt es sich. Genau so etwas meine ich mit "aufräumen". Das könnte auch manche Sprache selbst gebrauchen..
Aus diesen Gründen bin ich der Meinung, dass Sprachen wie D gut gemeint sind aber in der Praxis keine Chance haben. Sie zwingen einfach zu viel Know How wegzuwerfen, sind damit maximal für Neuprojekte interessant, oft aber durch vorhandene Bibliotheken und die Begrenzungen vorhandener Schittstellen nicht mal dort
Den Schlussfolgerungen stimme ich im wesentlichen zu. D hängt an 2 Leuten und hat, anders als z.B. Go, unzureichende industrielle Unterstützung. Gute Ideen allen reichen nirgendwo aus um irgend etwas zu bewegen!
Es ist daher immer sinnvoller vorhandene Sprachen zu verbessern, so wie die C++-Entwickler seit C++11 versuchen über die vorhandene Sprache eine neue, bessere aber zu 100% rückkompatible Sprache rüberzubauen.
Darum sind die auch die ganzen alternativen JVM- und CLR-Sprachen erstaunlich schnell groß geworden. Sie bauen durch ihre Kompatibilität mit anderen JVM und CRL-Sprachen eine Brücke, den alten Code weiternutzen und diesen schrittweise, an den Stellen, wo es Sinn hat auf eine neue, moderne Sprache zu portieren. Rust, dessen Entwickler von Beginn an Wert auf eine gute C-Schnittstelle legten, tut das ebenfalls.
Wo liegt eigentlich unser Dissenz? :rolleyes: Natürlich ist das der richtige Weg! Aber das sollte uns doch nicht hindern auf bestimmte Fehlentwicklungen und Limitierungen der in Rede stehenden Sprachen hinzuweisen und diese - zu recht oder unrecht - zu kritisieren. Nichts anderes war doch der Beitrag des OP. Es versteht sich dass das nichts mit "alles neu" zu tun hat! Und man beschäftigt sich doch nur ernsthaft mit Dingen denen man ein gewisses Maß an Wertschätzung entgegenbringt. Natürlich gibt es auch Kritikaster die an allem und jedem rumnörgeln, - aber dagegen hilft nur schweigen!
 
Zuletzt bearbeitet:
Eben! Das ist für mich ein gutes Beispiel für incrementielle Überarbeitung von veraltetem Code. Das ist natürlich aufwendig, aber vermutlich lohnt es sich. Genau so etwas meine ich mit "aufräumen". Das könnte auch manche Sprache selbst gebrauchen..
Wo liegt eigentlich unser Dissenz? :rolleyes: Natürlich ist das der richtige Weg! Aber das sollte uns doch nicht hindern auf bestimmte Fehlentwicklungen und Limitierungen der in Rede stehenden Sprachen hinzuweisen und diese - zu recht oder unrecht - zu kritisieren.
Wir haben keine. :) Wir haben uns nur missverstanden. Ich dachte du willst allen Code wegwerfen und neu beginnen, während ich "nur" überarbeiten möchte und sozusagen inkrementell aufräumen. Nachdem wir uns nun mit letzterem einig sind, lass ich euch in Ruhe weiterdiskutieren...
 
@Yamagi: Das mit Python stimmt so nicht, man hat diverse Brücken gebaut auf beiden Seiten um keine der Seiten zu vergraulen.Es gibt auch einen gutes Video dazu, finde es gerade nicht. DIe ganzen __future__ Maßnahmen als Indiz.
Ja, da hast du recht. Python war zwar das erste Beispiel, was mir einfiel, aber kein wirklich gutes.
 
wenn man Studenten, Schülern, Interessierten die Lust am freien Denken und Programmieren nehmen will und sie zu Code-erzeugenden Zombies erziehen will, dann geht das hervorragend mit OOP.
Das objektorientierte C++ Kauderwelsch ist dann die Krönung - und wird nur noch durch die sprachliche Kommunikation von Menschen getoppt, die unter schweren Psychosen leiden!
 
Kann ich nur teilweise zustimmen, weil es gilt aus meiner Sicht nur für riesige propertiäte Projekte. Wenn ich mir heute ansehe, was ich 1996 mit Delphi produziert habe, dann würde ich heute die eine oder andere Datenbankanwendung anders programmieren. Mit größerer Erfahrung und neuen Erkenntnissen ist das ein ganz normaler Prozess. Wir entwickeln uns ja hoffentlich weiter und damit wird der selbst produzierte Code auch les- und wartbarer. Und dabei geht es nicht nur um die technische Architektur, sondern auch ums Programm Design, die Benutzerfreundlichkeit und vieles mehr. Und wenn wir nur auf die Kosten fokussiert sind, dann gibt es sicherlich auch Projekte, die sich ein einer Sackgasse oder Einbahnstraße manövriert haben, so das es billiger kommt, den Code ganz neu zu schreiben. Und wenn es auch ausgewiesene Experten gibt, so dürfen wir nicht aufhören, selbst zu denken und uns auch unsere eigene Meinung zu bilden.
 
Zuletzt bearbeitet von einem Moderator:
Andererseits leidet ja gerade Delphi darunter, dass zu viele Menschen neu mit besser verwechseln.
 
Eine Programmiersprache wird deshalb favorisiert oder bevorzugt, weil sie eine spezielle Aufgabe effizient löst.
Weiß ich nicht. Es ist zumindest nicht immer so zu beobachten. Und ich würde es selbst auch nicht bedingungslos so empfehlen. Klar. Es wird immer so daher gesagt: Der Profi nimmt für das was er gerade machen will die bestgeeigneste Werkzeug also die bestgeeigneste Programmiersprache.

Der Erfahrung zeigt, dass es eben nicht unbedingt der Regelfall ist das Programmierer mehrere Programmiersprachen wirklich sehr gut beherrschen.

Es kann also durchaus sinnvoll sein dann den Programmierer wirklich eine Sprache nehmen zu lassen, die vielleicht nicht so gut geeignet ist aber die er gut kennt als umgekehrt: Eine Sprache die perfekt geeignet ist aber die der Programmier nicht gut kennt.
Sehr oft ist das Ergebnis im ersteren Fall fehlerfreier und schneller fertig.

Klar. Es kommt natürlich immer auf den berühmten Einzelfall an.

Daher war diese Weitentwicklung von C zu C++ unumgänglich.
Man muss aber dazu auch klar sagen, dass C++ nicht der einzige Anwärter war, um die angesprochenen Probleme zu lösen.

Und deshalb frage ich provokatorisch in die Runde, welchen Stellenwert hat die Erfahrung und die Programmierpraxis?
Einen hohen Stellenwert. Das ist so ein wenig wie mit na ich sag mal ganz vereinfacht: Fahrrad fahren. Du kannst es nicht lernen ohne Dich wirklich mal aufs Fahrrad zu setzen. Du kannst kein Maler werden, wenn Du nicht regelmäßig Bilder malst. Klar gibt es auch so was wie Talent. Aber das wirklich Wesentliche ist das (regelmäßige) Tun.

Gibt es vorzeigbare Projekte, die praktikabel im Alltagsleben eines Nutzers einen Mehrwert darstellen, weil es die tägliche Arbeit erleichtert?
Viel Programmierung fiel vor allem im beruflichen Umfeld an. Aber natürlich fällt auch privat mehr oder weniger regelmäßig neben her immer mal was ab.

Oder einfach nur Neugier, um den Programmierhorizont (theoretisch) zu erweitern? Es macht doch wirklich keinen Sinn, von einer Hochsprache zur anderen zu wechseln, bevor ich nicht eine einzige Sprache richtig verstanden habe.
Es macht sicher kein Sinn planlos hin und her zu wechseln. Was aber durchaus Sinn macht ist, sich verschiedene Programmiersprachen anzugucken. Ganz einfach, weil die durchaus unterschiedliche Konzepte mit einbringen. Und am ehesten macht es auch Sinn wenn die Sprache ein bestimmtes Paradigma erzwingt, weil man auch nur dann wirklich angehalten ist sich damit auseinander zu setzen und es einem nicht so leicht passiert, dass man in bekannte Muster zurück fällt. Als Beispiel: Lerne Haskell, wenn Du funktional programmieren lernen willst. Nimm Smalltalk, wenn Du das objektorientierte Paradigma kennen lernen willst.

Ob man dann immer die Sprache bis zum Exzess lernen muss, da hab ich so meine Zweifel ob das dann wirklich was bringt. Spätestens wenn Du die wichtigsten Konzepte verinnerlicht hast kommt dann halt nicht mehr wirklich Wesentliches hinzu. Oder ums mal so zu formulieren: Wenn Du das objektorientierte Paradigma beherrschst bist Du auf dem Level wo es dann um Smalltalk-soezifische Dinge geht die Du lernst. Nicht das das verkehrt wäre, aber es hat eben nix mehr damit zu tun objektorientiert programmieren zu lernen.

Es kommt halt sehr auf den Schwerpunkt an. Was lernt man warum. Was ist das Ziel. Und wenn das Ziel erreicht ist, gibts ja eigentlich keinen wirklichen Grund mehr weiter zu machen.
Wobei auch das leicht gesagt ist. Schon das sich klar machen eines Ziels kann ein schwieriger Prozess sein der auch dann noch nicht abgeschlossen ist, wenn Du mit dem lernen angefangen hast.

Heute weiß ich, das es mindestens 10 Jahre dauert, bis das jemand von sich behaupten kann.
Ich seh das komplett anders. :-) Aber jetzt nicht unbedingt auf eine Sprache bezogen, sondern was das programmieren im Allgemeinen angeht.

Am Anfang guckt man natürlich etwas wie ein Schwein ins Uhrwerk. :-) Aber wenn man Interesse und Geduld mitbringt, ist das auch kein wirkliches Problem.
Nach ein bis zwei Jahren denkt man, man kann programmieren. Nach 3 bis 4 Jahren denkt man, man wäre derbeste Programmierer der Welt. Nach 6 Jahren muss man zugeben, dass man im 3., 4. Jahr eigentlich noch der totale Anfänger war. Aller Code aus der Zeit ist Mist. Nach 8 Jahren erkennt man das Schema. Jetzt ist nämlich der Code aus dem 6 Jahr Mist. :-)
Nach spätestens 10 Jahren hat man endgültig realisiert, dass es ein stetiges lernen ist. Das ist auch so ungefähr der Zeitpunkt an dem es zu kippen beginnt. Denn bisher dachte man noch naiverweise, dass man irgendwie irgendwann einen Masterlevel erreicht und gibt sich der Illusion hin das der Weg der vor einem liegt auf jeden Fall kürzer ist als der Wegt der hinter einem liegt. Aber es macht sich zunehmend die Erkenntnis breit, dass mit zunehmenden Skill man begreift, was man noch alles nicht weiß. Und das eher mehr wird als weniger.


Ich kann gerade gar nicht mal so wirklich nachvollziehen, was dir gerade für eine Laus über die Leber gelaufen ist
Ich nehme Deine Kapitulation an. ;-)


wenn man Studenten, Schülern, Interessierten die Lust am freien Denken und Programmieren nehmen will und sie zu Code-erzeugenden Zombies erziehen will, dann geht das hervorragend mit OOP.
Ich weiß nicht wie Du darauf kommst. Klar kann einem die konkrete Sprache das mehr oder weniger schwer machen.
Wenn Du OOP richtig umgesetzt erleben willst, probiere **Smalltalk**.
 
Ich nehme Deine Kapitulation an. ;-)

Wenn's dich glücklich macht. War zwar mehr eine Empfehlung an deiner Ausdrucksweise zu arbeiten, aber nun gut. Meine Meinung vor deinem Post zu dem Thema hat sich damit nicht geändert. Wenn du meinen Beitrag noch mal ordentlich liest und vernünftig darauf eingehst und keine Aussagen verdrehst, kannst du es gerne noch mal probieren :)
 
Wenn's dich glücklich macht. War zwar mehr eine Empfehlung an deiner Ausdrucksweise zu arbeiten
Soso. Die Ausdrucksweise ist Dir wichtiger als das Thema. Wobei ich eher glaube, das ist nur ne Ausrede. Aber sei es drum.

keine Aussagen verdrehst, kannst du es gerne noch mal probieren :)
Jaja. Angeblich Aussagen verdrehen, aber nicht sagen wo.
Immer sind die Anderen schuld.
 
Andererseits leidet ja gerade Delphi darunter, dass zu viele Menschen neu mit besser verwechseln.

An Delphis Situation ist eher der jeweilige Eigentümer von Delphi Schuld.

Der Vorgänger Turbo Pascal war ja sehr erfolgreich und hat teilweise Maßstäbe gesetzt und war nicht umsonst in den 80er jahren bis hinein in die 90er sehr verbreitet.

Dann ist halt das passiert, was vielen Erfolgreichen Produkten passiert. Man ruht sich so ein wenig auf den Erfolg aus und denkt, es geht einfach so weiter von man nur an bewährten Konzepten festhält und/oder wird auch von Neuentwicklungen überrascht.

Bei Turbo Pascal war die Neuentwicklung Windows. Wobei ich jetzt Turbo Pascal für Windows nicht soo schlecht fand und immer noch besser als viele der Alternativen die es dazu mal für die Windows Entwicklung gab. Aber Microsoft holte halt auf. Dazu herrschte zu jener Zeit ein gewisser *C++ *Hype. Irgendwie alles und jeder wollte einen C++ Compiler rausbringen. Borland natürlich auch.

Gerade der C++ Builder lieferte sich ja mit dem Microsoft Pendant ein Kopf-an-Kopf-Rennen. Ein Rennen das natürlich auch Ressourcen kostet, die dann an anderer Stelle auch mal fehlen. Man hätte eher bei Pascal/Delphi bleiben sollen als sich dem auszusetzen (aber gut; hinterher ist man immer schlauer).

Dann noch die starke Fokussierung auf Datenbank-Anwendungsentwicklung. Auch hier hatte man mit Microsoft Access einen starken Gegenpart, wenngleich man das sicherlich nur bedingt vergleichen kann.

Auf die nächste Neuerung, nämlich Internet, hatte man schlicht gar keine Antwort.

Auch Linux-Ambitionen a-la Kylix lässt sich nur als Fehlschlag bewerten.

Immerhin hat man sich in einer Nische etabliert in der man nun auch schon eine ganze Weile überlebt. Ob das auf Dauer ausreicht, wird man sehen.

Ich denke aber nicht, dass es die Leute sind die daran schuld sind die zu Delphi nicht greifen, weil es altes Zeug ist.

Man muss auch ganz klar sagen, dass es heutzutage viel mehr Auswahl gibt. Und viele Sachen sind halt auch prominenter vertreten (man denke nur an Javascript). Ob zu Recht oder zu Unrecht sei mal dahingestellt. Aber Delphi hat halt kaum jemand auf dem Radar und schon deshalb kommen damit nur wenige überhaupt in Kontakt.
 
Ich seh das komplett anders. :-) Aber jetzt nicht unbedingt auf eine Sprache bezogen, sondern was das programmieren im Allgemeinen angeht.

Am Anfang guckt man natürlich etwas wie ein Schwein ins Uhrwerk. :-) Aber wenn man Interesse und Geduld mitbringt, ist das auch kein wirkliches Problem.
Nach ein bis zwei Jahren denkt man, man kann programmieren. Nach 3 bis 4 Jahren denkt man, man wäre derbeste Programmierer der Welt. Nach 6 Jahren muss man zugeben, dass man im 3., 4. Jahr eigentlich noch der totale Anfänger war. Aller Code aus der Zeit ist Mist. Nach 8 Jahren erkennt man das Schema. Jetzt ist nämlich der Code aus dem 6 Jahr Mist. :-)
Nach spätestens 10 Jahren hat man endgültig realisiert, dass es ein stetiges lernen ist. Das ist auch so ungefähr der Zeitpunkt an dem es zu kippen beginnt. Denn bisher dachte man noch naiverweise, dass man irgendwie irgendwann einen Masterlevel erreicht und gibt sich der Illusion hin das der Weg der vor einem liegt auf jeden Fall kürzer ist als der Wegt der hinter einem liegt. Aber es macht sich zunehmend die Erkenntnis breit, dass mit zunehmenden Skill man begreift, was man noch alles nicht weiß. Und das eher mehr wird als weniger.
Hier liegt ein Mißverständnis vor, genau das war gemeint, mindestens 10 Jahre, aber in Wirklichkeit hat das Lernen kein Ende. Und so war es auch gemeint ....

Einen hohen Stellenwert. Das ist so ein wenig wie mit na ich sag mal ganz vereinfacht: Fahrrad fahren. Du kannst es nicht lernen ohne Dich wirklich mal aufs Fahrrad zu setzen. Du kannst kein Maler werden, wenn Du nicht regelmäßig Bilder malst. Klar gibt es auch so was wie Talent. Aber das wirklich Wesentliche ist das (regelmäßige) Tun.
Und hier kann ich ein selbst erlebtes Beispiel beisteuern. Nach meiner Halswirbeloperation vor 3 Jahren (Stenose) mußte ich das Laufen ganz neu lernen wie ein Kleinkind. Und ich habe mir immer gesagt, wie lernst Du laufen? Indem ich laufe, immer wieder und immer wieder. Heute kann ich wieder laufen ohne Hilfsmittel....:) Du hast schöne Beispiele gebracht, das gefällt mir, weil es so anschaulich ist, das ich es mir auch vorstellen kann. Auch sehr gut finde ich, das Du dialogfähig bist und Dich einläßt. Selber bin ich weder Profi noch ein guter Programmierer, aber ich bemühe mich als Autodidakt ohne Studium zurecht zu kommen. Und es scheint gelungen zu sein, denn für meine Lebensleistung bekomme ich heute eine auskömmliche Rente. Zeigt mir, das ich nicht alles verkehrt gemacht habe. Manchmal fehlt es mir an technischem Verständnis, weil mir höhere Mathematik fehlt, denn ich habe auch kein Abitur. Aber ich muß auch nicht professionell programmieren können, denn meine Stärken liegen eher im literarisch schriftstellerischen Bereich. Welcher Programmierer kann schon Gedichte oder Essays schreiben? Gewiss nur wenige. So nun bin ich ein wenig abgedriftet, genug, mein Anspruch ist eben nicht, mit den Besten unter Euch mitzuhalten, dazu fehlt mir die Ausbildung.
 
Der Vorgänger Turbo Pascal war ja sehr erfolgreich und hat teilweise Maßstäbe gesetzt und war nicht umsonst in den 80er jahren bis hinein in die 90er sehr verbreitet.
Und einer der Väter des Erfolges war der unschlagbare Preis. Ein vergleichbares Pascal oder eine andere Hochsprache kosteten ein Vielfaches. Und das hat ebenfalls zu so einer Verbreitung beigetragen.
 
Hier liegt ein Mißverständnis vor, genau das war gemeint, mindestens 10 Jahre, aber in Wirklichkeit hat das Lernen kein Ende. Und so war es auch gemeint .
Ja. Ich glaube schon, dass ich Dich verstanden hab. :-)
Ich fand halt nur die Beobachtung so faszinierend, dass man quasi umso mehr man weiß das Gefühl hat, immer weniger zu wissen. Und genau das wollte ich damit zum Ausdruck bringen.

Und hier kann ich ein selbst erlebtes Beispiel beisteuern. Nach meiner Halswirbeloperation vor 3 Jahren (Stenose) mußte ich das Laufen ganz neu lernen wie ein Kleinkind. Und ich habe mir immer gesagt, wie lernst Du laufen? Indem ich laufe, immer wieder und immer wieder.
Ja. Wobei gerade das ja ein sehr interessanter Fall ist, weil man etwas neu lernt was man schon mal konnte. Ich könnte mir vorstellen das es zumindest anders ist, als wenn man komplett unbekanntes Terrain betritt.

Selber bin ich weder Profi noch ein guter Programmierer, aber ich bemühe mich als Autodidakt ohne Studium zurecht zu kommen.
Was auch ohne weiteres gut klappen kann. Jeder ist ja vom Lerntyp etwas unterschiedlich. Manche haben große Probleme mit dem autodidaktischen lernen. Die brauchen dann eher ein Kurs bzw. jemand der es ihnen beibringt.
Andere kommen damit sehr gut klar und den würden andere Lernmethoden jetzt nicht wirklich entscheidend voranbringen,

Manchmal fehlt es mir an technischem Verständnis, weil mir höhere Mathematik fehlt, denn ich habe auch kein Abitur.
Gut. Auch das kann man lernen. Aber gerade so Sachen wie Mathematik sind auch nicht immer so entscheidend. Das Informatikstudium z.B. legt sehr viel wert auf Mathematik. In der Praxis hat man aber eher selten damit Kontakt (gut; auch hier hängt es davon ab, was man macht; wenn man jetzt ne 3D Darstellung auf nen 2D Monitor umrechnen möchte{ohne fertige Bibliotheken zu benutzen}, dann kommt man da nicht drum rum). Aber so der übliche Feld, Wald und Wiesen-Kram geht auch so.

Welcher Programmierer kann schon Gedichte oder Essays schreiben? Gewiss nur wenige.
Ja. Das stimmt. Es gibt nur wenige, die in mehreren Bereichen passable Ergebnisse bringen. Oder mal anders gesagt; Die Spezialisierung hat sehr zugenommen. Zumindest ist das meine Wahrnehmung (möglicherweise lieg ich auch falsch).
Und das teilweise schon in einem Bereich selbst. Also ein Programmierer der seinen Rechner nicht administrieren kann und solche Scherze.
Andererseits hat man das Problem, dass Leute die eben nicht aus dem Bereich kommen das nicht nachvollziehen können.
Wenn irgendwie ne Frage zu Word kommt und ich dann darauf keine Antwort weiß und daraufhin die Entgegnung kommt: Wie jetzt? Du hast Du das studiert!!11!
Wo man dann erst mal erklären muss, dass das auch nicht unbedingt ein Elektriker wissen kann, obwohl der Computer mit Strom betrieben wird. :-)

Klingt zwar alles erst mal ganz lustig. Aber man muss sich natürlich vergegenwärtigen, dass in Gebieten in denen man sich selbst nicht auskennt ebenfalls solche Fallen lauern, in die man tappen kann.

So. Und nu bin ich auch ein wenig abgedriftet. :-)

mein Anspruch ist eben nicht, mit den Besten unter Euch mitzuhalten,
Das ist auch gar nicht entscheidend. Entscheidend ist, dass man seine Probleme irgendwie gelöst kriegt.
Manche Programmierer lächeln ja etwas abfällig z.B. über Leute, die sich dann da irgendwie ein Excel-Makro basteln. Und überhaupt. Das ganze VBA-Zeugs ist doch überhaupt nix Ernsthaftes.
Das stimmt zwar irgendwie. Und das was da zusammengeschrieben wird wirkt auch auf jemand der sich auskennt oftmals wie übelstes Gefrickel.
Aber das ist gar nicht der Punkt. Der blöde und belächelte VBA-Kram ermöglicht es nämlich den User sein persönliches Problem selbst zu lösen. Klar könnte man das ganze viel effizienter und viel besser mit C++ (or whatever) lösen. Aber das würde unser Excel-Freund eben alleine nicht hinkriegen. Der würde schon an dem lernen von C++ scheitern.
Insofern haben diese primitiven Sprachen durchaus ihre Berechtigung. Und demjenigen der sich da reingefuchst hat, obwohl ihm das vielleicht gar nicht liegt, dem ist eher Respekt zu zollen.

Und einer der Väter des Erfolges war der unschlagbare Preis. Ein vergleichbares Pascal oder eine andere Hochsprache kosteten ein Vielfaches.
Das kommt sicher noch hinzu. Heutzutage kann sich das ja kaum noch einer vorstellen, dass es mal usus war richtig viel Geld für nen Compiler hinzublättern. Verglichen mit damals haben wir jetzt diesbezüglich geradezu paradisische Zeiten.
 
Ist aber auch ein Nachteil: der Markt ist voller Hobbyisten. Harte Zeiten für uns Profis. :)

(Und selbstverständlich kann ich dichten.)
 
Ist aber auch ein Nachteil: der Markt ist voller Hobbyisten. Harte Zeiten für uns Profis. :)

Es ist echt hart. Man weiß gar nicht wohin mit den ganzen Job- und Projektangeboten (die Qual der Wahl macht bekanntermaßen unglücklich) und dann muss man auch noch ein teures Hobby entwickeln, um die verdiente Kohle wieder loszuwerden. :D
 
Zurück
Oben