Eigene OOP-Sprache

volkard

Programmiererer schrieb:

Hallo volkard (*sich freu, dass er wider da ist*),
ich verstehe ihrgendwie nicht, wie du das mit der funktion meinst ^^

template<typename T,int blocksize=nextPowOfTwo((4096-8)/sizeof(T))>
struct Queue{
...
};

nun muß die blocksize zur compilezeit bekannt sein. sie soll ja auch teil der statischen typprüfung sein.
aber int nextPowOfTwo(int x) will ich nicht rekursiv und mit templates bauen.

Reyx

Programmiererer schrieb:

Also eine Idee wäre es von mir schon mal die ganzen variablentypen wegzulassen, dass es php ähnlich wird.

Urgh ... Im Leben nicht! Bei Scriptsprachen bitte sehr, aber hast du eine Ahnung was man dann alles für Prüfungen und Abfragen in sein Programm einbringen müsste? Templates könntest du dann vergessen und void* sowieso.

Native Programmiersprache und schwache Typisierung ... Himmel hilft!

thordk

ich sehe eigentlich keinen trifftigen grund, der gegen schwache typisierung spricht.

es erschwert natürlich die analyse und ist fehleranfällig. aber mal ehrlich, wieviele speicherlecks und potentielle segmentation fault quellen hat das durchschnittliche c++ programm? da ist misbrauch von schwacher typisierung noch ein geringes übel.

c++ ist steinzeit. um jeden scheiss muss man sich selbst kümmern, nicht mal der müll wird einem vor die tür gebracht!
ein anständiger nachfolger sollte sich automatisch darum kümmern, dass a) kein müll rumliegt und b) der dem programm zugewiesene speicherbereich nie verlassen wird.

ok, das ist java jetzt muss man es nur noch hinbekommen, dass der code nativ wird oder alternativ optimal optimiert, sprich: schnell.

die ganzen verrenkungen mit c++ (eigentlich jeder sprache) um irgendwelche schleifen, strukturen etc. zu optimieren und schneller zu bekommen sind dinge, die in einer "fortschrittlichen" sprache nicht mehr nötig sein sollten, da der compiler (oder interpreter) automatisch die optimale variante findet.

leider unmöglich umzusetzen ^^

Reyx

thordk schrieb:

wieviele speicherlecks und potentielle segmentation fault quellen hat das durchschnittliche c++ programm? da ist misbrauch von schwacher typisierung noch ein geringes übel.

Ach so ... Weil es ein paar dickere Probleme gibt ist es OK, kleinere neu einzuführen? Das nenne ich mal 'ne Denkweise

c++ ist steinzeit. um jeden scheiss muss man sich selbst kümmern, nicht mal der müll wird einem vor die tür gebracht!
ein anständiger nachfolger sollte sich automatisch darum kümmern, dass a) kein müll rumliegt und b) der dem programm zugewiesene speicherbereich nie verlassen wird.

Was du Steinzeit nennst nenne ich Kontrolle, und zwar eine solche, die man in der Welt der dreifach-verschachtelten virtuellen Maschinen und verkorkster Garbage Collection nicht mehr hat.

ok, das ist java

Exakt, und Java hat ganz andere Ansprüche als C++ und passt sich da optimal hinein!

die ganzen verrenkungen mit c++ (eigentlich jeder sprache) um irgendwelche schleifen, strukturen etc. zu optimieren und schneller zu bekommen sind dinge, die in einer "fortschrittlichen" sprache nicht mehr nötig sein sollten, da der compiler (oder interpreter) automatisch die optimale variante findet.

Nötig sollten Sie nicht sein, aber möglich! Und das ist der Fall -> Du brauchst, dank aktueller Hardware, nicht mehr optimieren, kannst es aber tun!

volkard

thordk schrieb:

es erschwert natürlich die analyse und ist fehleranfällig. aber mal ehrlich, wieviele speicherlecks und potentielle segmentation fault quellen hat das durchschnittliche c++ programm?

keine.

da ist misbrauch von schwacher typisierung noch ein geringes übel.

ähm, mit schwacher typisierung hätte es aber welche.

c++ ist steinzeit. um jeden scheiss muss man sich selbst kümmern, nicht mal der müll wird einem vor die tür gebracht!

das machen die destruktoen von allein.

das einzige, was gegen c++ spricht, ist, daß man es steinzeitlich benutzen kann und dann kommt auch nur mist raus. also einsteiger-unfreundlich.

hmm ... die Ideen sind ja schon mal gut, nur leider hat jetzt jeder eine andere Ansicht von "gut und schlecht". Ich warte einfach auf mehr antworten

Jochen Kalmbach

volkard schrieb:

schreibenden zugriff auf den parse-baum und die symboltabelle haben.

Das gibt es schon! Zumindest bei MS als research Projekt... sogar schon zum Runterladen. Der neue Compiler heisst "Phoenix" und wird wohl in Zukunft der Compiler für *alle* MS Produkte... lässt sich prima erweitern mit eigenen PlugIns, wo Du vollen Zugriff auf den Parse-Baum hast (und diesen auch verändern kannst...)
Wenn ich ein wenig mehr Zeit hätte, dann hätte ich schon längst einen Artikel über dieses Geile Projekt geschrieben...

rüdiger

* Lambda
* Design-by-Contract
* optionaler Garbagecollector
* Reflections
* Laufzeiterzeugung von Klassen

Das meiste sind sogar Sachen die für C++0x vorgeschlagen werden.

Helium

Da die hier diskutierte Grundlage (C++ bzw. D) nicht nach meinen Vorstellungen ist, würde es auch keinen Sinn machen eine darauf aufbauende Sprache zu entwerfen.

Ansonsten kann ich natürlich auch einfach mal Schlagworte reinwerfen, z.B. das Pattern Matching.
Man kann auch über Aspekte (AOP) nachdenken usw.
Man könnte versuchen logische Ansätze (logisches Paradigma) zu integrieren. Bisher habe ich schon recht gute Ansätze gesehen logisch mit funktional zu kombinieren, logisch mit prozedural oder oo habe ich zwar ebenfalls schon gesehen, jedoch nie in überzeugender Form.

Jedoch würde ich, bevor ich mir irgendwelche Gedanken mache, gerne wissen, wofür ich mir diese Gedanken machen sollte.

Xin

Programmiererer schrieb:

Eigentlich war das kein trollversuch. C++ kann noch garnicht ausgereift sein, denn alle C++/smaltalk programmierer die ich kennen, programmieren lieber mit Smaltalk als mit C++.

Also eine Idee wäre es von mir schon mal die ganzen variablentypen wegzulassen, dass es php ähnlich wird.

Ich programmiere kein Smalltalk, aber PHP.
Wenn PHP zur Maxime einer Programmiersprache erhoben wird, dann bleibe ich doch mit Freude bei C++.

Reyx schrieb:

Moderne sprachen haben alles, was man braucht, und wenn die Quantencomputer erstmal laufen, brauchen wir eh etwas völlig neues.

Ich programmiere - soweit es meine Zeit zuläßt - eine eigene Programmiersprache, die auf C++ aufbaut, die C++ ähnlich ist, aber nicht mehr kompatibel zu C++ ist. (http://genesys.xsd.eu, wobei ich leider sagen muss, dass ich für die Homepage noch weniger Zeit habe als für den Compiler)

Ich arbeite konkret an dem Konzept meiner Sprache seit etwas über 4 Jahren. Um herauszufinden, was eigentlich wichtig ist, habe ich mal eine Umfrage gestartet.
Aus dieser Umfrage las ich, dass die Informatiker in der Regel ihr Werkzeug benutzen, aber nicht hinterfragen.
Demzufolge ist Reyx Informatiker.
Physiker, Mathematiker, Ingeneure, Geschäftsführer oder Projektleiter sind da vergleichsweise SEHR kreativ.

44% der Leute (416 Teilnehmer, die die Umfrage vollständig mitgemacht haben), hatten spontan eine oder mehrere Ideen auf die Frage, was sie sich den für ihre Programmieraufgaben wünschen.

Es gibt vieles an aktuellen Programmiersprachen zu verbessern. Ich hab' zwei Jahre Ideen gesammelt und dann beschlossen "Joah, fängste mal an..."
Später habe ich Berufserfahrung an realen Projekten gesammelt, was darin resultierte, dass ich regelmäßig (teils mehrfach täglich) auf Probleme stieß, die man besser machen kann. Ich schrieb' mir dann jeweils eine Mail mit dem Problem und nach Möglichkeit einer Lösung.

Inzwischen habe ich mehrere Aktenordner zu dem Thema, die ich letztes Jahr auf einen Entwurf von rund 200 Seiten brachte, der sich nur mit Erweiterungen und Änderungen zu C++ beschäftigt.

Mein Lieblingsthema dabei ist die Vermeidung von Redundanz, denn da gibt es viel zu erzählen und das ist - zumindest für mich - eine meiner Lieblingsfehlerquellen.

personenkult

Aus dieser Umfrage las ich, dass die Informatiker in der Regel ihr Werkzeug benutzen, aber nicht hinterfragen.
Demzufolge ist Reyx Informatiker.

Reyx

Xin schrieb:

Demzufolge ist Reyx Informatiker.

Nein, Realist und Rationalist.

Ich brauche nicht über die Features nachzudenken, die mir irgendeine Sprache in x Jahren einmal bieten wird. Klar, auch ich würde mir Dinge in C++ anders wünschen, aber ich brauche nicht zu protokollieren, welche. Wenn jemals eine solche Sprache komen möge, dann arbeite ich mich da rein und gut. Wenn Sie nicht kommen sollte, habe ich meine Zeit nicht mit irrationalen Gedangengängen verschwendet, wie eine Programmiersprache sein könnte, die ich niemals zu Gesicht bekommen werde. Das Gegenteil davon nennt man übrigens Träumer.

Anders sähe die Sache aus, wenn ich mich mal mit Compilerbau und .co beschäftigen würde: Dann würde ich mir selbstverständlich Gedanken darüber machen, was ich verbessern könnte und was mal innovativ und neu währe und mir das Leben erleichtern würde.

Du verwechselst da etwas grundlegend: Ich stelle nicht meine Werkzeuge in Frage (im Gegenteil, ich erwäge sehr gewissenhaft, in welcher Sprache unter welcher IDE für welches System in was realisiere), sondern das Grundprinzip deiner Frage!

Zumal ein Compiler für eine so "geniale" Sprache sowieso nicht mehr von einer Person alleine programmiert werden kann

Anders sähe die Sache aus, wenn ich mich mal mit Compilerbau und .co beschäftigen würde: Dann würde ich mir selbstverständlich Gedanken darüber machen, was ich verbessern könnte und was mal innovativ und neu währe und mir das Leben erleichtern würde.

Ich beschäftige mich aber damit und vom copiler (den ich eh nicht allene machen würde) bin ich neu weit entfernt. Ich bin grade dabei die sprache zu entwickeln. Deßhalb frage ich ja auch jetzt.

Xin

Reyx schrieb:

Xin schrieb:

Demzufolge ist Reyx Informatiker.

Nein, Realist und Rationalist.

Verrätst Du mir Deinen Beruf und wie Du in Deiner Sparte tätig bist?
Bist Du hier, weil Du als Mathematiker, Physiker, Wirtschaftler programmierst oder als Informatiker?

Reyx schrieb:

Ich brauche nicht über die Features nachzudenken, die mir irgendeine Sprache in x Jahren einmal bieten wird. Klar, auch ich würde mir Dinge in C++ anders wünschen, aber ich brauche nicht zu protokollieren, welche. Wenn jemals eine solche Sprache komen möge, dann arbeite ich mich da rein und gut. Wenn Sie nicht kommen sollte, habe ich meine Zeit nicht mit irrationalen Gedangengängen verschwendet, wie eine Programmiersprache sein könnte, die ich niemals zu Gesicht bekommen werde. Das Gegenteil davon nennt man übrigens Träumer.

Stimmt, aber damit irgendeine Sprache in x Jahren mal was bieten wird, sollte irgendwer sich damit beschäftigen. Also protokolliere ich mal und ja, ich träume auch ein wenig. ^^

Reyx schrieb:

Anders sähe die Sache aus, wenn ich mich mal mit Compilerbau und .co beschäftigen würde: Dann würde ich mir selbstverständlich Gedanken darüber machen, was ich verbessern könnte und was mal innovativ und neu währe und mir das Leben erleichtern würde.

Genesys als Compiler funktioniert noch nicht, es gibt nur eine theoretische Programmiersprache. Aber es gibt GeCCo, eine "Sparversion" von Genesys, ein funktionierender Compiler, der eben nur C übersetzt (GEnesys C COmpiler) und ein paar Genesys-Erweiterungen.
In meinem Fall sieht die Sache also anders aus, als Du sie siehst.

Reyx schrieb:

Du verwechselst da etwas grundlegend: Ich stelle nicht meine Werkzeuge in Frage (im Gegenteil, ich erwäge sehr gewissenhaft, in welcher Sprache unter welcher IDE für welches System in was realisiere), sondern das Grundprinzip deiner Frage!

Ich habe eine Frage gestellt? Welche?

Ich stelle mal eine Frage: Welche Sprache beherrschst Du richtig gut, wenn Du die Sprache entsprechend Deines aktuellen Projektes wechseln musst?
Mich persönlich nervt das. Ich überlegte auch schon mehrfach meine dynamischen Websites mit C++ zu erstellen. Warum Syntax in PHP neu lernen, wenn ich C++ kann?!
Ich komme mit PHP inzwischen soweit klar, Datenbanken, dynamische Grafiken, alles kein Problem. Aber die Sprache PHP bleibt trotzdem eine Krankheit.

Reyx schrieb:

Zumal ein Compiler für eine so "geniale" Sprache sowieso nicht mehr von einer Person alleine programmiert werden kann

Vor einiger Zeit kam ich in einen Chat, das Thema ging auch um meinen Compiler, da ich Ideen von anderen Entwicklern sammelte. Schließlich ging es um die Verwendung von YaCC und Bison. Ich sagte, dass ich auf diese Tool verzichte und die Sache lieber selber programmiere. Daraufhin sagte man mir, dass das unmöglich wäre, viel zu viel Arbeit für eine Person, einen brauchbaren Parser zu entwickeln.
Dass der Parser bereits in einer brauchbar optimierten Form vorliegt und funktioniert, nahm man zur Kenntnis, aber es ist vollkommen unmöglich für eine Person alleine daraus einen Compiler zu bauen.
Da der Parser nur Teil eines bereits vorhandenen und funktionierenden Compilers ist, widerlegte binen einer Minute bereits die nächste Unmöglichkeit.
Der Besuch in dem Chat brachte keine neuen Ideen mit sich. Jeder wußte etwas zu sagen, warum das, was ich tue nicht möglich ist. Aber keiner wußte etwas zu sagen, was man ausprobieren kann.

"Always listen to experts. They tell you what can't be done and why.
Then do it." ^^

Ich sammle nicht nur Tipps zu Programmiersprachen, sondern auch passende Zitate dazu

Ich weiß nicht warum, aber meine Projekte sind immer solange unmöglich, bis ich mich zurücklehne und "Fertig" sage. Das dauert manchmal etwas, weil ich inzwischen nebenher ja auch Geld verdienen muss, aber irgendwie ist immer alles unmöglich, was ich mache.

Programmieren ist die Umsetzung einer Idee in Sourcecode. Dazu muss man nicht sehr kreativ sein, wenn die Idee schon vorhanden ist.

Vor ein paar Jahren fand ich dazu ein schönes Zitat von einem vermutlich unbestritten kreativen Menschen: Walt Disney.
Dieses Zitat findet sich seitdem in meiner Mail-Signatur - wie und auch hier.

In diesem Sinne: Have fun!

Mario Sandler

Wie weit bist du denn mit dem Compiler?
Gibts schon ne testversion? mich würde unglaublich intressieren ws du in 4 jahren wenn ich dich richtig verstanden habe erreicht hast.

Was genau programmierst du eigentlich? Du hast einen Parser und machst aus dem nen compiler. Also ist die Programmiersprache selbst soweit fertig?

SideWinder

Mit immer neuen Programmiersprachen fährt man sich ohnehin fest. Sprachen setzen sich nur noch wirklich durch, wenn sie entweder für ein bestimmtes Spezialgebiet top sind oder von großen Firmen gepusht werden. Eine neue Sprache alleine reicht ganz einfach nicht mehr. Die Faktoren rundherum zählen: Ordenliche IDEs, Code-Generatoren, Designer, Debugger, Libraries, etc. etc.

Viel zu viele Sprachen orientieren sich außerdem viel zu nahe am Maschinencode - und damit auch an den bisherigen Sprachen. Richtige Entwicklung ist kaum zu sehen, man schleift das Rad seit nunmehr knapp 15 Jahren nur noch mit feineren Feilen rund.

Java und jetzt auch C# haben endlich mit Frameworks darunter wieder eine kleinere Entwicklung eingeleitet. .NET kann sprachenunabhängig benutzt werden, die all-in-one-Sprachenlösung braucht man also nicht mehr unbedingt. 4GL-Sprachen wie Oracle Forms machen datenbankbasierte Anwendungen noch viel einfacher.

Der nächste große Schritt braucht noch etwas mehr Hardware-Leistung. Aber wenn man zurück sieht auf die letzten 30 Jahre Entwicklung, dann traue ich den nächsten 30 Jahren ohne weiteres zu es zu schaffen: Ich zeige dem Computer nur noch wie das Ergebnis aussehen soll und er erzeugt selbständig den (nur noch für ihn nötigen) Code.

Deswegen verstehe ich die Abneigung gegen UML hier auch nicht unbedingt. Viele kommen mit Argumenten wie "Braucht doch niemand solche Diagramme vorher. Den Code den ich daraufhin abschreibe versteht man auch so." Genau da liegt aber der entscheidende Fehler. Die Diagramme ergänzen nicht den Code sondern sollen ihn in absehbarer Zukunft komplett ersetzen.

Programmierung wird zum Webdesign-Job der Zukunft. Ferialpraktikant darf die Diagramme für den Chef zeichnen und auf den Go-Button drücken. Programmierung wird zum Lehrberuf. Der FAFI ist neue Haushaltassistenten-Bezeichnung für diese Lehre.

Edit: Wer geglaubt hat, die Programmierung bringt den sicheren Job für die nächsten 50 Jahre der irrt imho gewaltig. Werdet bloß anständige Informatiker und kommt mit allen Entwicklungen in der Informatik-Branche zurecht. Datenverwaltung und vor allem Datenverarbeitung werden wichtiger. Die Programmierung ist die jederzeit durch andere Methoden ersetzbare Hilfsarbeit.

MfG SideWinder

@storm: kannst du nicht lesen?

thordk

das einzige, was gegen c++ spricht, ist, daß man es steinzeitlich benutzen kann und dann kommt auch nur mist raus. also einsteiger-unfreundlich.

das argument ist allerdings erschlagend. man kann sich mit c++ eben das bein wegschiessen. und in diesem thread ging es um die frage, was eine eigene OO-sprache als nachfolger von c++ leisten können sollte.

und meiner ansicht nach müsste ein sinnvoller nachfolger eben genau sowas effektiv verhindern. und das geht nur, indem es die sprache gar nicht mehr zulässt, dass man sich selbst ins bein schiessen kann.

klar ist das für das ego der c++ freaks nicht gerade zuträglich aber das argument "ich hab gern volle kontrolle!" nutzt sehr schnell ab.
wofür braucht man denn volle kontrolle? doch nur, weil es eben zig verschiedene wege gibt, irgendein problem zu lösen.

und deshalb mein lakonischer ansatz: geht alles automatisch.

ein compiler, den ich beispielsweise mit nem automaten füttere und der mir daraus hochoptimierten code bastelt, wär doch z.b. ne feine sache.

c++ ist eine extreme low level sprache. das mag für manche schön sein, aber ist meiner meinung nach eher der produktivität hinderlich. wen interessierts, in welche register oder welchen speicherblock irgendwas geschoben wird?
mich juckts ja auch nicht, wie der einspritzer meines autos funktioniert, solang der verbrauch gering ist und das ding schnell fährt

Xin

Storm.Xapek.de schrieb:

Wie weit bist du denn mit dem Compiler?

Es gibt einen Compiler, aber eben nicht den Compiler. GeCCo ist interessant, weil ich die Sourcecode selber geschrieben habe und genau weiß, was in diesem Programm passiert und wie ich ihn erweitern kann.
Er ist als Compiler aber noch nicht sinnvoll produktiv einsetzbar.

Storm.Xapek.de schrieb:

Gibts schon ne testversion?

Nein. Es wird auch keine geben, bis es eine für mich zufriedenstellende Version 1.0 gibt. Da ich mich leider nicht mehr ausschließlich um dieses Projekt kümmern kann, sondern auch Geld verdienen muss - u.a. auch für dieses Projekt - wird das dauern. Außerdem bin ich nicht leicht zufrieden zu stellen ;->

Storm.Xapek.de schrieb:

mich würde unglaublich intressieren ws du in 4 jahren wenn ich dich richtig verstanden habe erreicht hast.

Besagten Parser, der programmiertechnisch nicht der Rede wert ist, den GeCCo-Compiler, welcher über einen brauchbaren Codegenerator für eine virtuelle endian-unabhängige Maschine verfügt, besagte virtuelle Maschine, dazwischen liegt ein etwas aufwendigeres Chunk-Basiertes Dateiformat, das entsprechend geschrieben und gelesen werden kann.
Die VM ist kein Spielzeug, weil ich unfähig wäre korrekte Opcodes für eine CPU zu produzieren. Ich habe vor dem Compiler bereits einige Programme geschrieben, die lauffähige Executables schrieben.

Die VM arbeitet wie eine normale CPU. Ich orientiere mich ein wenig an der MC68000er CPU. Entsprechend werden Ausdrücke auf einfachste Befehle zerlegt und diese in die entsprechenden Opcodes verschlüsselt. Es wird genauso mit Zeigern und IP- und SP-Registern gearbeitet, wie man es in Assembler tun würde.
Damit ich was zu gucken hab' gibt es allerdings auch Opcodes, die für einfachste Testbefehle stehen, wie z.B. eine Zahl auf den Bildschirm zu schreiben.

Da die VM keinen JIT-Compiler integriert hat, kann der Spaß mit Java natürlich noch nicht mithalten, aber im Vergleich zu PHP ist Faktor 2 drin. Perl ist (noch) im Vergleich zu GeCCo minimal schneller. :-\

Was programmiert wurde ist okay, aber nur ein Bereich. GeCCo zeigt mir vor allem, dass man als Sprachentwickler viele Hebel hat, an denen keiner bisher zieht. Entsprechend habe ich mich erstmal um die Hebel gekümmert - was kann man damit eigentlich alles sinnvolles machen. Und wenn man direkt an den Hebeln sitzt, dann kann man einiges machen.
Also habe ich mich wieder hingesetzt und die Sprache so überdacht, dass man an die Hebel rankommt. Das ist allerdings noch nicht implementiert.
Es gibt einen gedruckten Entwurf, den ich derzeit in ein Wiki verfrachte, damit ich daran rumfummeln kann und eine Doku da ist, wenn ich irgendwann mal etwas freigebe. Der Entwurf hat sich im letzten Jahr allerdings nur noch marginal verändert. Die Sprache selbst deckt also meine Anforderungen inzwischen ab.

Das, würde ich sagen, ist der interessanteste Fortschritt in der Zeit.

Storm.Xapek.de schrieb:

Was genau programmierst du eigentlich? Du hast einen Parser und machst aus dem nen compiler. Also ist die Programmiersprache selbst soweit fertig?

Derzeit versuche ich rauszufinden, was noch notwendig ist, um Cluster direkt zu unterstützen (also richtige Computer). Glücklicherweise stehen keine 50m von hier drei Cluster und der Admin von zweien wohnt im Haus neben meinem, da trinkt man schonmal 'n Bier zusammen ;->

Ansonsten würde ich sagen, dass die Sprache größenteils bereit für die Umsetzung ist.

Xin

SideWinder schrieb:

Der nächste große Schritt braucht noch etwas mehr Hardware-Leistung. Aber wenn man zurück sieht auf die letzten 30 Jahre Entwicklung, dann traue ich den nächsten 30 Jahren ohne weiteres zu es zu schaffen: Ich zeige dem Computer nur noch wie das Ergebnis aussehen soll und er erzeugt selbständig den (nur noch für ihn nötigen) Code.

Vor 20 Jahren läutete man das Zeitalter der Bildtelefonie ein - wir erinnern uns? ISDN! Wir brauchen alle Bildtelefone, niemand wird mehr einfach nur telefonieren wollen.

Mein Händi hat zwei integriete Kameras. Für Videophonie! Mehr als eine Videophobie sehe ich allerdings nicht, den irgendwie rufen die Leute immer ganz normal bei mir an....

Wer heute sagt, was in 30 Jahren ist, der hat entweder eine funktionierende Kristallkugel (unwahrscheinlich) oder rät einfach (1-unwahrscheinlich).
Für den zweiten Fall haben wir Fachkräfte in der Politik. ^^

Nehmen wir ein anderes Szenario, das nicht aus einer Kristallkugel stammt, sondern ein tatsächlich mögliches Szenario darstellt: In etwa 20 Jahren bleibt der Golfstrom aufgrund der Klimaerwärmung stehen. Daraufhin wird eine unglaublich hohe Wärmemenge nicht mehr nach Europa transportiert und Nordeuropa erlebt die nächste Eiszeit. Halb Europa ist unter dem Eis verschwunden, die Weltwirtschaft bricht zusammen und egal, ob Du UML oder C++ programmierst, spätestens dann solltest Du mit einem Feuerstein Ergebnisse produzieren können. :->

Die optimistischeren Prognosen, dass der Golfstrom erst in rund 200 Jahren zum Stillstand kommt wurden laut Spiegel Online vor drei Wochen etwa auf 100 Jahre bis zur Eiszeit korrigiert.

Also, wenn Du weißt, was in 30 Jahren alles so passiert... Respekt!

SideWinder schrieb:

Deswegen verstehe ich die Abneigung gegen UML hier auch nicht unbedingt. Viele kommen mit Argumenten wie "Braucht doch niemand solche Diagramme vorher. Den Code den ich daraufhin abschreibe versteht man auch so." Genau da liegt aber der entscheidende Fehler. Die Diagramme ergänzen nicht den Code sondern sollen ihn in absehbarer Zukunft komplett ersetzen.

Bis ich das Diagram gezeichnet habe, habe ich das Programm geschrieben.
Wenn ich die Funktionen da hübsch reinschreibe, weiß der Computer noch nicht, was ich von ihm will. Wenn ich anfange Struktugramme zu zeichnen, um zu programmieren, dann frage ich mich, warum das heute wohl keiner macht?!

SideWinder schrieb:

Edit: Wer geglaubt hat, die Programmierung bringt den sicheren Job für die nächsten 50 Jahre der irrt imho gewaltig.

Ich habe nichts gegen Deine Zukunft einzuwenden. Mir gefällt sie. Mir gefällt auch, dass immer mehr Leute auf Java und C# ausgebildet werden. Wer nicht aus Erfahrung weiß, was ein Zeiger macht, hat in meinen Augen keine Ahnung.

Je weniger Leute keine Ahnung haben, desto höher mein Gehalt. ^^