Was kommt nach der Objektorientierung?

nman

Xin schrieb:

dann entspricht der Gesamtthread vermutlich etwa der Diskussion, ob eine Sprache 'goto' enthalten sollte oder nicht.

Klar, klassischer Fall von Bikeshedding. Uninteressant und Zeitverschwendung.

Dies ist nicht das richtige Forum dafür[...]

Glaube ich sofort. Ist wohl auch nicht sinnvoll. Andererseits sind 500-Wort-Beitraege, die unimplementierte Projekte ohne technische Details oder auch nur Parallelen/Unterschiede zu anderen Sprachen beschreiben, auch nicht sehr zielfuehrend.

Ganz am Anfang wurde das ja schon erlaeutert: Es weisz wohl einfach niemand, was genau der Zweck deiner Posts ist.

Ich koche zB. oft Sachen, die mir und meinen Gaesten sehr gut schmecken, aber ein "Mein Essen wurde schon oft als koestlich bezeichnet, aber ich sage euch nicht, was es ist oder was fuer Zutaten ich heute Abend verwende."-Post waere trotzdem nicht so spannend und wuerde wohl auch auf Unverstaendnis treffen. ("Was zum Geier will der Typ mit diesem Post?")

Zum Rest: Klar. Wir haben alle irgendwelchen 0815-Mist und komplizierteren und/oder performancekritischeren Code, fuer den die Standardwerkzeuge anstrengend oder unbrauchbar sind oder Mikrotuning noetig ist. Das aendert aber nichts daran, dass dein erster Post hier vollgepackt mit unueberpruefbaren Behauptungen ist, die eben nicht mehr als Behauptungen sind bis du deine Sprache veroeffentlicht hast. Zum Threadthema traegt das leider nicht viel bei.

Gregor

Um mal wieder zum eigentlichen Thema des Threads zurueckzukommen...

Wir haben in den letzten Jahrzehnten gesehen, dass Programmiersprachen abstrakter werden und sich von der Hardware entfernen. Ich denke, dass dieser Trend bei den Mainstream-Sprachen anhalten wird. Zuasaetzliche Sprachmittel, die auf bestimmte Hardwaretrends eingehen, werden kommen, aber sie werden nicht bestimmend sein. Mikrooptimierungen, die Code nochmal um einen Faktor 2 oder so schneller machen, indem sie bestimmte Hardwaretricks ausnutzen, werden AFAIK nur in Nischenbereichen benoetigt. Und selbst da ist die Frage, ob man als Programmierer schlauer als der Optimierer im Compiler ist, meist nicht absolut eindeutig zu beantworten. Fuer die Softwareentwicklung im Grossen ist es wichtiger, dass die Programmierer die Komplexitaet der Problemstellung in den Code abbilden koennen, ohne dabei ueberfordert zu werden. Hierbei ist davon auszugehen, dass die Komplexitaet der Problemstellungen zunimmt. Das ist einfach deshalb der Fall, weil Moore's Gesetz dafuer sorgt, dass Softwareentwicklung in immer mehr Anwendungsbereiche vordringt, in denen immer komplexeres geleistet werden muss. Entsprechend gehe ich davon aus, dass es genau in dieser Hinsicht die Hauptentwicklung geben wird. Das betrifft nicht nur die Programmiersprachen selbst, sondern natuerlich auch die Frameworks und die Entwicklungswerkzeuge, wie zum Beispiel die IDEs.

Xin

Shade Of Mine schrieb:

Normalfall ist wohl PHP. Schau dir Marktanteilig an wieviele Server auf LAMP setzen.
Da kann PHP schon nicht so langsam sein.

nman schrieb:

Zum Rest: Klar. Wir haben alle irgendwelchen 0815-Mist und komplizierteren und/oder performancekritischeren Code, fuer den die Standardwerkzeuge anstrengend oder unbrauchbar sind oder Mikrotuning noetig ist.

Wir drehen uns im Kreis, denn eigentlich ist alles gesagt:

Xin schrieb:

Und ich frage andere - besondersgerne Nicht-Informatiker - was bei ihnen so normal ist. Die Informatiker haben meist keine Kritikfähigkeit mehr gegenüber dem, was sie tagtäglich benutzen. Sie sind betriebsblind.

Wer sich fragt, was in zukünftigen Sprachen interessant sein wird, darf gerne bemerken, dass es bereits Lösungen gibt, die heute normalerweise genutzt werden. Aber er darf sie nicht verteidigen, sondern muss sie in Frage stellen. Verbesserungen ergeben sich nicht dadurch, dass man den Stand der Dinge als ausreichend oder gar gut definiert, sondern als ungenügend. Und Dinge, die ungenügend sind, tauscht man durch Dinge aus, die besser sind.

Ich habe kein Problem damit, wenn Leute C++, C#, Java oder PHP nutzen. Aber in dem Thread ging es um die Frage, was Antworten von morgen sind und nicht, was die allgemein anerkannten Antworten von heute sind. Und wer's lesen will, findet in meinen Postings durchaus Hinweise auf realitische Anforderungen und realisierbare Entwicklungen.

nman

Xin schrieb:

Ich habe kein Problem damit, wenn Leute C++, C#, Java oder PHP nutzen. Aber in dem Thread ging es um die Frage, was Antworten von morgen sind und nicht, was die allgemein anerkannten Antworten von heute sind. Und wer's lesen will, findet in meinen Postings durchaus Hinweise auf realitische Anforderungen und realisierbare Entwicklungen.

Hoechstens sehr gut versteckt.

Xin

nman schrieb:

Xin schrieb:

Und wer's lesen will, findet in meinen Postings durchaus Hinweise auf realitische Anforderungen und realisierbare Entwicklungen.

Hoechstens sehr gut versteckt.

Ansichtssache. ^^

Ich finde, teilweise stoße ich den Leser regelrecht mit der Nase drauf, wenn er es bewusst liest und die Gedanken mal kurz von der Kette lässt, dann ist vieles eigentlich offensichtlich.

Es bleibt natürlich die Frage, ob man sich ein Orchester vorstellen kann, wenn man einen Geiger hört, aber um die Harmonie eines Orchester detailliert zu beschreiben brauche ich mehr Text. Ich baue aber kein Orchester mehr auf und beschreibe das Zusammenspiel, um dann "tl;dr" zu hören oder "Ich bevorzuge aber Trompetenmusik und deswegen will ich Blaskapelle statt Orchester und der Rest will ich nicht hören". Ich kann auch Blasmusik, aber interessant wird es doch erst, wenn alles Hand in Hand spielt.
Wer ein Konzert hören will, muss ich für meine Musik interessieren. Manchen zeige ich im Probenraum den aktuellen Stand der Implementierung.
Und wenn das Orchester das Werk brauchbar spielen kann, wird es auch öffentlich auftreten. Bis dahin gibt es nur ein Plakat und für Dich das Wissen, dass ich öfter im Probenraum bin, als jemand, der sich weniger mit Programmiersprachen beschäftigt.

Gregor ist mit seinem letzten Posting jedenfalls auch auf einem eigentlich offensichtlich richtigen Weg. Er beschreibt den Trommler.

hab die letzten seiten kurz überflogen...

hut ab xin, du bist wahrlich der größte raketenwissenschaftler und findest trotzdem noch zeit, hier tausende zeichen lange schwanzvergleiche zu verfassen und darüber zu schwadronieren, wie toll du algorithmen mit lächerlich langer laufzeit optimieren kannst. respekt!

Dravere

Xin schrieb:

Dravere schrieb:

Aktuell erstelle ich eine Software im Bereich der Verwaltung, welche ausschliesslich auf Windows laufen soll. Wieso um alles in der Welt sollte ich dazu C++ nehmen?

Muss man nach "Bereich der Verwaltung" noch kommentieren?

Keiner verlangt von Dir C++ zu nehmen. Du hast eine lineare Aufgabe. Datensatz anlegen, aufsammeln, abstempeln, zurückschreiben, löschen. Wobei Abstempeln das einzige ist, wo ein wenig Algorithmik auftritt. GUI davor packen, fertig.
Sorry, ich will Dein Projekt nicht abwerten - der Bereich der Verwaltung ist notwendig, Du stellst dafür sicherlich ein wertiges und hilfreiches Produkt her, aber Verwaltung ist jetzt nicht unbedingt als herausforderndes Problem bekannt.

Deine Aufgabe ist der Inbegriff des Normalfalls.

Ja ...
Und du stimmst mir also zu, dass C# geeignet ist für Normalfälle?
Was soll dann deine ganze Argumentation?

Wieso soll dann C++ besser als C# sein?

Xin schrieb:

Ich habe in C# noch nichts gesehen, was in C++ ein Problem darstellt.

Ich habe solche Dinge schon gesehen. Aber kommt natürlich darauf an, wie du "Problem" definierst? Wenn du den Aufwand nicht mitzählst, dann kannst du natürlich alle Probleme problemlos lösen. Zeit kostet dann ja nichts.

Nenn mir nur mal ein gutes Äquivalent in C++ für System.Decimal . Das ist ein ganz einfaches Problem
Man merke bitte, dass ich nicht nur den Typ möchte, sondern auch die Unterstützung dafür in der Datenbankanbindung, usw. usf.

Aber auch ein GUI ist mit C# einfach schneller erstellt als in C++. Klar kannst du es auch in C++ lösen, aber niemals mit der Einfachheit von C#. C# abstrahiert eben Dinge weg und macht das Leben für den Programmierer einfacher. Dafür kommt es halt mit gewissen Kosten, aber die kann man problemlos in Kauf nehmen.

Java EE bietet z.B. ein super DI per Container an. Probier das mal mit C++ umzusetzen mit der gleichen Einfachheit wie in Java EE.

Xin schrieb:

Im Quelltext ergibt sich das gleich: datensatz.write( datenbank ) - wobei Datensatz von einer bestimmten Basisklasse abgeleitet wurde, die die Daten "greifbar" macht und auf verschiedene Wege persistent machen kann, z.B. an eine SQL-DB.

Hast du dich mal einigermasen mit DB-Konzepten in Java oder C# in den letzten Jahren auseinander gesetzt? Mir scheint das nicht so der Fall zu sein. Annotations/Attributes sind z.B. etwas sehr schönes in Java und C#, was du in C++ nicht hinbekommen wirst. Nein, der Datensatz erbt in C# und Java nicht von einer gemeinsamen Basisklasse. Damit kannst du in Java und C# einfach deutlich schneller entwickeln, als du es in C++ könntest. Und um nichts anderes geht es schlussendlich. Es geht um den Aufwand, um ein Problem zu lösen.

Xin schrieb:

Ich verstehe die Aussage nicht. Bei mir ist es jedenfalls kein Glücksfall, wenn was Gutes dabei rauskommt, das plane ich üblicherweise vorher.

Wer definiert was gut ist? Du?

Xin schrieb:

Man hätte vergleichsweise wenig Resourcen gebraucht, um C++ für den Normalfall besser mit Standards auszustatten.

Die Frage ist, ob die Ressourcen so eingesetzt worden wären, wie du es dir gewünscht hättest, oder ob die Entwicklung ganz woanders hingegangen wäre. Das meinte ich mit meiner Aussage. Und darauf will ich auch mit der Frage vorhin hinaus: Wer definiert was gut ist?

Xin schrieb:

Dravere schrieb:

Ich habe hierbei weder in C++, C# oder Java ein Problem. Keine Ahnung was du damit meinst. Argumente?

Das Argument steht da, dass Du das Problem nicht hast, macht das Argument nicht nichtig.

Nein, du hast nur eine Aussage gemacht, dass dies schlecht sei. Du hast nie gesagt, wieso dies eigentlich schlecht ist. Die Argumente schwirren irgendwo in deinem Kopf herum, aber du hast sie nie aufgeschrieben. Wir können nicht in deinen Kopf sehen und haben andere Meinungen als du. Somit sind diese Argumente für uns nicht offensichtlich.

Xin schrieb:

Dravere schrieb:

Java ist zu 100% abwärtskompatibel.

Nopes, ist es nicht. Gerade als 1.5 rauskam, war das Geschrei groß, so dass erstmal stark zurückgerudert werden musste.

Mir ist nicht bekannt, dass es heute eine Inkompatibilität gibt. Kannst du mir da Beispiele nennen? Übrigens, da fehlen eben auch wieder Argumente. Du machst nur Aussagen, aber untermauerst diese nie. Den Rest hast du dann auch ignoriert. Wieso es z.B. überhaupt schlecht ist, die JVM mitauszuliefern.

Xin schrieb:

Ich finde, teilweise stoße ich den Leser regelrecht mit der Nase drauf, wenn er es bewusst liest und die Gedanken mal kurz von der Kette lässt, dann ist vieles eigentlich offensichtlich.

Ich glaube eher, dass du gewisse Vorstellungen hast und nicht merkst, dass deine Aussagen nur aus deiner Sicht Sinn ergeben. Die Leute kommen aus einem anderen Kontext und können daher deine Gedankengänge nicht nachvollziehen. Den anderen Leuten dann vorzuwerfen, dass sie blind sind, hilft da auch nicht weiter.

Grüssli

nman

Xin schrieb:

Ich finde, teilweise stoße ich den Leser regelrecht mit der Nase drauf, wenn er es bewusst liest und die Gedanken mal kurz von der Kette lässt, dann ist vieles eigentlich offensichtlich.

Ich finde du schreibst unheimlich lange und substanzlose Posts mit vielen Allgemeinplaetzen, aber ohne tatsaechliche Aussagen.

Versteh mich nicht falsch, ich habe grundsaetzlich nichts gegen Gebashe existierender Programmiersprachen, aber ein bisschen fundierter als du das betreibst, darf es ruhig sein.

(Beispiele fuer interessantere und technisch halbwegs fundierte Diskussionen zu experimentellen Programmiersprachen gibt's immer wieder auf Lambda the Ultimate und aehnlichen Seiten.)

Ich klinke mich damit wieder aus, kann mir beim besten Willen nicht vorstellen, dass hier noch irgendwas spannendes rauskommt, sorry.

Shade Of Mine

Gregor schrieb:

Wir haben in den letzten Jahrzehnten gesehen, dass Programmiersprachen abstrakter werden und sich von der Hardware entfernen. Ich denke, dass dieser Trend bei den Mainstream-Sprachen anhalten wird. Zuasaetzliche Sprachmittel, die auf bestimmte Hardwaretrends eingehen, werden kommen, aber sie werden nicht bestimmend sein.

Dem Stimme ich voll und ganz zu und erweitere es um Parallelismus. So Sachen wie PLINQ werden sich weiter verbreiten oder zumindest etwas ähnliches zu Parallel.For und Co. C# hat da schon einiges nettes und ich denke da werden die anderen Sprachen nachziehen.

@Xin:
Ich hab mittlerweile den Faden verloren was du eigentlich sagen willst...

PHP ist schnell genug für jede Art von Webseite. In extrem Situationen (zB Twitter, Facebook,...) kann es aber sinnvoll sein auf spezialisiertere Techniken zu gehen.

Und bei Webplatformen gibt es ganz andere Themen als die Sprache. Denn meistens ist die Sprache uninteressant. Es geht viel mehr um die Toolchain. PHP hat zB eine ziemlich gute Toolchain und wird deshalb verwendet. Python wäre cooler, hat aber keine brauchbare Toolchain als wird es nicht verwendet. Ruby hat aber wiederum eine nette Toolchain, auch wenn sie nicht so cool wie die von PHP ist und hat deswegen relevante Verbreitung.

Deshalb darf man Sprachen nicht für sich alleine gestellt betrachten.

Xin

Niemand ist gezwungen es zu lesen...

Dravere schrieb:

Ja ...
Und du stimmst mir also zu, dass C# geeignet ist für Normalfälle?
Was soll dann deine ganze Argumentation?

Wieso soll dann C++ besser als C# sein?

Warum ? Wenn ein Wert nicht positiv ist, bedeutet das nicht, dass er negativ ist... er kann auch neutral sein.

Natürlich stimme ich Dir zu, dass C# geeignet ist für Normalfälle.

Viele Projekte beginnen mit dem Normalfall und enden im Spezialfall. Die meisten Programmierer lernen den Normalfall, aber haben keine Ahnung vom Spezialfall. Mit Begeisterung beweise ich Informatikern, dass i == i+1 nicht zwangsläufig false ergeben muss.

Dravere schrieb:

Xin schrieb:

Ich habe in C# noch nichts gesehen, was in C++ ein Problem darstellt.

Ich habe solche Dinge schon gesehen. Aber kommt natürlich darauf an, wie du "Problem" definierst? Wenn du den Aufwand nicht mitzählst, dann kannst du natürlich alle Probleme problemlos lösen. Zeit kostet dann ja nichts.

Richtig. Die Frage ist halt, wieviel Zeit wurde in das Framework gesteckt und warum hat man die Zeit statt in ein Java und ein C#-Framework eigentlich nicht in ein C++-Framework gesteckt?

Statt die Zeit also doppelt zu nehmen, hätte man das auch einmalig für C++ formulieren können. Das wäre billiger.

Dravere schrieb:

Nenn mir nur mal ein gutes Äquivalent in C++ für System.Decimal . Das ist ein ganz einfaches Problem
Man merke bitte, dass ich nicht nur den Typ möchte, sondern auch die Unterstützung dafür in der Datenbankanbindung, usw. usf.

Ich kann Dir kein Äquivalent für System.Decimal geben, was nicht gleichbedeutend ist, dass es keins gibt. Die Unterstützung von Dezimal ist Datenbankabhängig und in C++ verfügbar und ansprechbar. Also muss es auch Möglichkeiten geben, Dezimalzahlen in C++ zu halten.

Das habe ich aber noch nie tun müssen, es ist aber naheliegend, dass das kein C++-Problem ist und auch kein Problem in C++.

Dravere schrieb:

Aber auch ein GUI ist mit C# einfach schneller erstellt als in C++. Klar kannst du es auch in C++ lösen, aber niemals mit der Einfachheit von C#. C# abstrahiert eben Dinge weg und macht das Leben für den Programmierer einfacher. Dafür kommt es halt mit gewissen Kosten, aber die kann man problemlos in Kauf nehmen.

Ich habe in C# GUIs gemacht und ich empfinde WinForms als extremst bescheiden. Daher musste ich WinForms aufboren, damit in einen Okay-Button nicht "Ok", sondern auch die französische Übersetzung passt. Ohne dabei die Buttons daneben zu überschreiben.
WPF soll da jetzt deutlich weiter sein, also ungefähr da, wo die C++-Lib MUI vor 20 Jahren auch schon war. Horray.

Ich lerne gerade Qt. Finde ich deutlich flexibler als WinForms. WPF ist sicher auch in Ordnung, aber damit habe ich noch nicht gearbeitet.

Dravere schrieb:

Java EE bietet z.B. ein super DI per Container an. Probier das mal mit C++ umzusetzen mit der gleichen Einfachheit wie in Java EE.

Zwei Buchstaben können viel bedeuten. DI sagt mir nix und google verweist mich auf etwas musikalisches.

Dravere schrieb:

Xin schrieb:

Im Quelltext ergibt sich das gleich: datensatz.write( datenbank ) - wobei Datensatz von einer bestimmten Basisklasse abgeleitet wurde, die die Daten "greifbar" macht und auf verschiedene Wege persistent machen kann, z.B. an eine SQL-DB.

Hast du dich mal einigermasen mit DB-Konzepten in Java oder C# in den letzten Jahren auseinander gesetzt? Mir scheint das nicht so der Fall zu sein. Annotations/Attributes sind z.B. etwas sehr schönes in Java und C#, was du in C++ nicht hinbekommen wirst.

Stimmt, wobei ich sie bisher nur brauchte, um Probleme zu lösen, die ich in C++ nicht hatte.

Mit Datenbanken unter C# habe ich mich zuletzt 2004/5 recht intensiv auseinander gesetzt. Hier verfüge ich sicherlich nicht über die aktuellsten Kenntnisse.
Klär mich gerne auf, wenn das Wort Reflections darin nicht vorkommt. Ansonsten wäre das exakt das, was ich 2004/5 gemacht habe.

Dravere schrieb:

Nein, der Datensatz erbt in C# und Java nicht von einer gemeinsamen Basisklasse. Damit kannst du in Java und C# einfach deutlich schneller entwickeln, als du es in C++ könntest. Und um nichts anderes geht es schlussendlich. Es geht um den Aufwand, um ein Problem zu lösen.

Logisch. In C++ benutze ich dafür eine Basisklasse, der ich eine Klassendefinition der abgeleiteten Klasse mitgebe. In C# Reflection.
Reflection löst hier das Problem, das ich in C++ mit der Basisklasse löse.
Ich halte beide Lösungen übrigens für Schwächen der jeweiligen Sprachen.

Dravere schrieb:

Xin schrieb:

Ich verstehe die Aussage nicht. Bei mir ist es jedenfalls kein Glücksfall, wenn was Gutes dabei rauskommt, das plane ich üblicherweise vorher.

Wer definiert was gut ist? Du?

Joah, würde ich schon sagen. Ich stehe vor einem Problem, plane eine Lösung und wenn das Problem dann sinnvoll gelöst ist - im Idealfall generisch, dann definiere ich das als "gut".

Dravere schrieb:

Xin schrieb:

Man hätte vergleichsweise wenig Resourcen gebraucht, um C++ für den Normalfall besser mit Standards auszustatten.

Die Frage ist, ob die Ressourcen so eingesetzt worden wären, wie du es dir gewünscht hättest, oder ob die Entwicklung ganz woanders hingegangen wäre. Das meinte ich mit meiner Aussage. Und darauf will ich auch mit der Frage vorhin hinaus: Wer definiert was gut ist?

Wenn es gut ist für den Normalfall, dann wurde es in den letzten 15 Jahren als State-of-the-Art definiert. Ich denke, wir lernen in den letzten Jahren, dass die meisten früher oder später vom Normalfall abweichen.

Dravere schrieb:

Nein, du hast nur eine Aussage gemacht, dass dies schlecht sei. Du hast nie gesagt, wieso dies eigentlich schlecht ist. Die Argumente schwirren irgendwo in deinem Kopf herum, aber du hast sie nie aufgeschrieben. Wir können nicht in deinen Kopf sehen und haben andere Meinungen als du. Somit sind diese Argumente für uns nicht offensichtlich.

Teile des Frameworks sind obsolete oder rausgenommen. Der Wechsel von 1.1 auf 1.2 war eine Katastrophe, der Wechsel von 1.4 auf 1.5 hakte ebenfalls deutlich. Danach habe ich das nicht mehr groß verfolgt. Ich finde, dass das offensichtliche Argumente sind, die einem als Java-Entwickler bekannt sein dürfen.

Ich lese bei solchen Threads immer "wir". ^^
Wisst "ihr" eigentlich schon, ob euch mehr verbindet, als in einigen Dingen zu glauben, nicht meiner Meinung zu sein.

Dravere schrieb:

Xin schrieb:

Dravere schrieb:

Java ist zu 100% abwärtskompatibel.

Nopes, ist es nicht. Gerade als 1.5 rauskam, war das Geschrei groß, so dass erstmal stark zurückgerudert werden musste.

Mir ist nicht bekannt, dass es heute eine Inkompatibilität gibt. Kannst du mir da Beispiele nennen? Übrigens, da fehlen eben auch wieder Argumente. Du machst nur Aussagen, aber untermauerst diese nie. Den Rest hast du dann auch ignoriert. Wieso es z.B. überhaupt schlecht ist, die JVM mitauszuliefern.

Wenn Dir missfällt, dass ich für jede Aussage Quellenangaben mache, dann muss ich "roflalter" recht geben: Soviel Zeit nehme ich mir für die Recherche für ein Posting hier auch nicht.
Ich erwarte durchaus, dass Java-Entwicklern aufgefallen ist, dass es Inkompatiblitäten zwischen den Versionen gibt.

Wieso es schlecht ist, die JVM mit auszuliefern? Weil "Portablität" keinen Sinn macht, wenn die mehrere komplexe Programme selbst auf einem Rechner unterschiedliche VMs benötigen.

Dravere schrieb:

Xin schrieb:

Ich finde, teilweise stoße ich den Leser regelrecht mit der Nase drauf, wenn er es bewusst liest und die Gedanken mal kurz von der Kette lässt, dann ist vieles eigentlich offensichtlich.

Ich glaube eher, dass du gewisse Vorstellungen hast und nicht merkst, dass deine Aussagen nur aus deiner Sicht Sinn ergeben. Die Leute kommen aus einem anderen Kontext und können daher deine Gedankengänge nicht nachvollziehen. Den anderen Leuten dann vorzuwerfen, dass sie blind sind, hilft da auch nicht weiter.

Ich werfe niemanden etwas vor.

Als Entwickler sieht man ein Problem, es macht "plink" im Kopf und man weiß, wie man das in seiner (Programmier-)Sprache formulieren würde. Das ist das übliche Vorgehen beim Entwickeln und man kann niemanden vorwerfen, Lösungen für seine Programmierprobleme zu finden.

Dieser Thread dreht sich um aber nicht darum existierende Lösungen zu entwickeln, sondern über den eigenen Horizont hinaus zu gehen. Nehmen wir ein faires Problem, wo beide Sprachen versagen:

int i=x;

while( i<10 )
  if( i == 5 )
  { 
    /* Code 5 */ 
    break;
  }
  else if( i == 7 )
  {
    /* Code 7 */
    break;
  }

*

Bei * weiß ich nicht mehr, ob die Schleife abgebrochen wurde oder gültig beendet wurde. Wenn ich Falle des gültigen Ablaufs etwas tun möchte, joah...

Ich muss am Ende nochmal alle Möglichkeiten abfragen (i!=5 && i!=7 => Redundanz), ob die Schleife abgebrochen wurde. Ich könnte eine Variable setzen, deren Wert ich vor jedem Break ändere (Redundanz/BoilerPlate). Oder ich werfe eine LoopBreaked-Exception, die zum einen teuer ist (okay, auf optimierten Code legt hier keiner wert, das habe ich schon mitbekommen) und zum anderen findet semantisch keine Ausnahme statt, sondern Regelfälle werden zur Ausnahme erklärt.

Also schreiben wir was Verbotenes:

int i=x;

while( i<10 )
  if( i == 5 )
  { 
    /* Code 5 */ 
    goto LoopBreaked;
  }
  else if( i == 7 )
  {
    /* Code 7 */
    goto LoopBreaked;
  }

/* while durchgelaufen */

LoopBreaked:

...

Nun haben wir die Gewissheit, dass die gesuchte Programmstatusinformation nie verloren geht. Sie also zusätzlich in einer Variable oder durch eine erneute Abfrage (i!=5 && i!=7) wieder zu beschaffen ist Laufzeitverschwendung.

Das Problem ist mit Pythonsyntax schöner gelöst:

int i=x;

while( i<10 )
  if( i == 5 )
  { 
    /* Code 5 */ 
    break;
  }
  else if( i == 7 )
  {
    /* Code 7 */
    break;
  }
else
{
  /* while durchgelaufen */
}

Die üblichen Antworten sind, dass eine Variable ja nicht so teuer ist, Moores Law diese Überlegung überflüssig gemacht hat und so weiter. Zu akzeptieren, dass hier etwas semantisch falsch ist oder nur durch goto ohne Laufzeitverlust korrekt abgebildet werden kann, da tut sich die Masse der Entwickler schwer mit.
Wenn es darum geht, etwas weiterzuentwickeln, dann ist die Antwort: Da muss man was tun.

Was Python nämlich nicht kann, ist einen Zweig definieren für den Fall, dass die Schleife abgebrochen wurde. Hier muss man Code auch redundant halten.
Also? "Brauche ich nicht" oder "Da muss man was tun?"

Hier ist eben nicht das Ziel zu belegen, dass man selbst gewisse Probleme gar nicht hat, lösbar wären oder dass PHP schnell genug für den Normalfall sein kann, sondern zu überlegen, wie man komplexe Problemlösungen soweit abstrahiert, dass sich ein Konstrukt ergibt. So wie OOP in C programmiert wurde und man anschließend erkannte, dass man daraus ein kompilierbares Standardkonstrukt machen kann: C with Classes.

Mit solchen Konstrukten fülle ich Aktenordner - bzw. inzwischen ein Wiki.
Ich sehe mich nicht in einer Rechenschaftspflicht, denn ich muss nicht beweisen, dass es eine zukünftige Weiterentwicklung von Sprachen gibt, ich argumentiere lediglich für das Bewusstsein, dass die Informatiker den Wunsch nach Weiterentwicklung kaum forcieren und dass Java und C# im Vergleich zu C++ ein Rückschritt sind. Ein Framework kann man in allen Sprachen schreiben, das ändert die Sprache selbst nicht mehr. Ein Framework ist praktisch - unbestritten.

Niemals stellt sich hier die Frage nach einer vorhandenen Lösung, sondern nur nach einer besseren Lösung. Für eine Klasse System.Decimal, die man auch in C++ repräsentieren kann auf sinnvolle Sprachfeatures zu verzichten, wie Const-Correctness, C++-Referenzen, Templates oder Mehrfachvererbung, halte ich für sehr fraglich. Diese Sachen sind in C# nicht repräsentierbar.
Umgekehrt stellt sich die Frage mit Reflection, hier wird es in C++ eng. Die Unterscheidung von ref und out ist gut, override ist mit C++11 endlich(!) vertreten, das habe ich sehr vermisst.

Bleibt die Frage, welche Features wichtiger sind. Meiner Meinung nach wiegt Const-Correctness, Referenzen, Templates und Mehrfachvererbung schwerer als Reflection und "out" - imho.
Das wird also entweder - entgegen der Aussage des C#-Entwicklers nachgereicht - oder C# wird sich auf Dauer nicht halten können und ähnlich wie Java mit der Zeit erst weggeschoben und später verdrängt werden.

Und da es um die Zukunft geht, stellt sich halt die Frage, wie man z.B. ORM in der Sprache abbilden kann, ohne Basisklassen oder Reflection als Hilfsmittel nutzen zu müssen. Eine von hunderten Fragen.

Shade Of Mine

Xin schrieb:

Statt die Zeit also doppelt zu nehmen, hätte man das auch einmalig für C++ formulieren können. Das wäre billiger.

Sorry aber ist das wirklich deine Meinung?

Wenn wir immer nur in bestehende Systeme investieren würden, hätten wir keine besseren Systeme. C++ ist für dynamische Elemente einfach schlecht geeignet. Ich halte C++ für eine der tollsten Sprachen überhaupt, aber gerade zB Datenbanklastige Anwendungen würde ich in C#/Java schreiben.

Es ist zwar schön dass in C++ vieles theoretisch gehen würde, aber das ist nicht der Punkt. Es bringt mir nichts wenn eine Lösung in der Theorie zwar funktionieren würde, aber der Aufwand dorthin zukommen einfach zu groß ist.

Im Web sieht man das aktuell sehr gut. Durch Ruby sind viele neue Tools entstanden ohne die es nicht mehr geht - auch wenn Rails selber nur mittelmäßig erfolgreich war.

Das ist etwas tolles, denn mit PHP geht ja auch alles (um deine pro C++ Diskussion aufzufangen) aber manchmal sind andere Tools einfach besser. Es ist toll dass nicht aller Aufwand in PHP gesteckt wird sondern wir von Ruby Tools wie SASS oder capistrano bekommen haben.

Stell dir mal vor Niemand hätte die Zeit in Java oder .NET gesteckt - dann hätten wir heute kein LINQ, keine Annotations keine Enterprise Beans und wahrscheinlich auch kein SOAP oder WSDL, etc.

Nur weil es technisch möglich ist fast alles in C++ zu lösen (und ich bin ein richtig großer C++ Fan) ist es noch lange nicht sinnvoll dies auch zu tun. Mir fallen unzäglige Situationen ein wo C++ einfach schlechter ist als zB Java.

PS:
Die Lösung bei deinem Codebeispiel lautet: Funktionen verwenden.

PPS:

Bleibt die Frage, welche Features wichtiger sind. Meiner Meinung nach wiegt Const-Correctness, Referenzen, Templates und Mehrfachvererbung schwerer als Reflection und "out" - imho.
Das wird also entweder - entgegen der Aussage des C#-Entwicklers nachgereicht - oder C# wird sich auf Dauer nicht halten können und ähnlich wie Java mit der Zeit erst weggeschoben und später verdrängt werden.

Auch wenn Java durch den Sun verkauf Lizenzprobleme hat, so ist Java noch lange nicht weggeschoben oder sonstwas.

Diese Aussage halte ich für sehr gewagt - denn die Codebasen von Java und .NET steigen rapide an. Aktuell sind das also Sprachen die im Vergleich zu C++ boomen.

Natürlich werden sie irgendwann überholt sein - das stelle ich ausser Frage - aber soweit sind wir noch lange nicht. Gerade was die Abstraktion von der Hardware betrifft bieten Java und .NET soviel tolles an. Und Microsoft pusht .NET - also keines von beiden wird so schnell verschwinden... Am ehesten wird Java vielleicht durch Scala oder sowas ersetzt werden, aber die Plattformen Java und .NET werden uns noch sehr sehr lange begleiten.

Xin

Shade Of Mine schrieb:

Xin schrieb:

Statt die Zeit also doppelt zu nehmen, hätte man das auch einmalig für C++ formulieren können. Das wäre billiger.

Sorry aber ist das wirklich deine Meinung?

Narf... nein, natürlich nicht, ich lasse das halbe Forum über mich herziehen, weil meine wahre Meinung so angepasst und langweilig ist.

SCNR ;->

Natürlich ist das meine Meinung. - SORRY, ich war schon immer unbequem.

Shade Of Mine schrieb:

Wenn wir immer nur in bestehende Systeme investieren würden, hätten wir keine besseren Systeme. C++ ist für dynamische Elemente einfach schlecht geeignet. Ich halte C++ für eine der tollsten Sprachen überhaupt, aber gerade zB Datenbanklastige Anwendungen würde ich in C#/Java schreiben.

Okay... und warum ist es so schwierig die Frage zu erlauben, weshalb "wir" nicht in eine der tollsten Sprachen überhaupt investieren, um z.B. datenbanklastige Anwendungen zu vereinfachen, statt mit Java und C# zwei neue Räder zu erfinden?

Womit sich die folgende Frage dann erledigen würde:

Shade Of Mine schrieb:

Es ist zwar schön dass in C++ vieles theoretisch gehen würde, aber das ist nicht der Punkt. Es bringt mir nichts wenn eine Lösung in der Theorie zwar funktionieren würde, aber der Aufwand dorthin zukommen einfach zu groß ist.

Ich investiere in C++ - und halt in etwas, was ich als Alternative aufbauen möchte. Als ich studierte, sollte ich C++ vergessen und in Delphi investieren. Dann in Java. Derzeit C#.

Ich investiere weiter, bis ich der Meinung bin, dass eine andere Sprache mehr Potential als C++ hat. Bis dahin akzeptiere ich hier und da etwas Mehraufwand. Mein privates C++-Framework war und ist viel Aufwand. Aber es existiert - auch für Datenbanken. Ein Framework ist für mich kein Argument gegen C++.
Es ist ein Grund sich zu überlegen, eine Anwendung in C# oder Java zu überlegen, aber die Frage lautet nicht, was das Framework der Zukunft ist, sondern es geht um die Sprache in der dann z.B. Frameworks implementiert werden.

Shade Of Mine schrieb:

Stell dir mal vor Niemand hätte die Zeit in Java oder .NET gesteckt - dann hätten wir heute kein LINQ, keine Annotations keine Enterprise Beans und wahrscheinlich auch kein SOAP oder WSDL, etc.

Warum sollten wir das denn nicht haben? SOAP ist doch uralt... <wikipedia anwerf> SOAP kam 1999 von MS, also vor C# und nicht von Sun.

So what?

Shade Of Mine schrieb:

Die Lösung bei deinem Codebeispiel lautet: Funktionen verwenden.

Danke, womit Du voll in die Kerbe geschlagen hast, wo ich den typischen Entwickler sehe, Du hast leider das falsche Problem gelöst. Es geht eben nicht darum, einen Workaround zu finden.

Gehe zurück zum Posting, ziehe keine 4000 Treuepunkte ein und lies das Posting nochmal.

Zu PPS: Den Eindruck habe ich so nicht. Dass Codebasen nicht schrumpfen ist normal, aber mein Eindruck ist, dass Java stagniert mit Tendenz nach unten, gehalten durch Android, C# ohne Tendenz steigt und C++ stagniert mit Tendenz nach oben.
Aber das ist alles sowieso nicht wirklich messbar. Mein Eindruck ist allerdings Basis meiner Projektplanung und liegt bisher recht gut. Java hält sich ziemlich genau an das, was ich vor 10 Jahren vorausgesagt habe. Hype, lange Stagnation, absinken (2015), verschwinden (Cobol/Fortran-Level) gegen 2025.
In meinen Augen ist Java damit tot.
PS: .NET traue ich mehr Zukunft zu, da Du natürlich richtig liegst, dass MS .NET mehr pusht.

Shade Of Mine

Xin schrieb:

Okay... und warum ist es so schwierig die Frage zu erlauben, weshalb "wir" nicht in eine der tollsten Sprachen überhaupt investieren, um z.B. datenbanklastige Anwendungen zu vereinfachen, statt mit Java und C# zwei neue Räder zu erfinden?

Habe ich denke ich schon in dem Posting erklärt. Nur in einer Welt zu leben ist furchtbar eintönig und hemmt den Fortschritt.

Und ich habe nicht gesagt dass Java alles coole erfunden hat, nur dass ein reines fokussieren auf eine Technik (zB C++) den Fortschritt enorm hemmt. Aber bitte: schau dir mal so coole Sachen an wie JIT. Sowas gäbe es nicht, wenn wir immer nur in C++ denken würden.

Tunnelblick kommt dabei raus. Wir wären ja nie über Basic hinweggekommen wenn wir die bestehenden Sprachen als Perfekt angesehen hätten. C++ gäbe es mit deinem Ansatz ja garnicht.

Danke, womit Du voll in die Kerbe geschlagen hast, wo ich den typischen Entwickler sehe, Du hast leider das falsche Problem gelöst. Es geht eben nicht darum, einen Workaround zu finden.

Gehe zurück zum Posting, ziehe keine 4000 Treuepunkte ein und lies das Posting nochmal.

Nein. Du hast einfach ein Prinzip der Programmierung missachtet: Eine Funktion - Eine Aufgabe. Deine Funktion macht mehrere Sachen, ergo hast du Probleme.

Da hilft dir keine Sprache.

Xin

Shade Of Mine schrieb:

Und ich habe nicht gesagt dass Java alles coole erfunden hat, nur dass ein reines fokussieren auf eine Technik (zB C++) den Fortschritt enorm hemmt. Aber bitte: schau dir mal so coole Sachen an wie JIT. Sowas gäbe es nicht, wenn wir immer nur in C++ denken würden.

Öhm... JIT kommt aus den 60ern... da gab's nichtmals C++. ^^

Ich stimme Dir zu, dass wir unterschiedliche Blickwinkel haben. Und während ich meine Meinung meistens nicht gegen den Zeitgeist verteidigen kann, ist Java nicht die erste Sprache, die ich zu ihrer Hochzeit für tot erkläre. Dazu gehört auch beispielsweise Pascal und Delphi.

Auch damals hatte ich keine Ahnung und Tunnelblick. Und recht.

Hätte ich damals auf die Leute gehört, hätte jetzt eine größere Delphi-Codebasis. Oder eine halb so große Java-Codebasis. Ich setze seit 94 auf C++ only, lerne neue Programmiersprachen, aber fand nichts, was C++ das Wasser reichen kann. Daher habe ich angefangen, mir selbst was auszudenken.
Sorry, das ist nicht von heute auf morgen fertig und wird noch Jahre in Anspruch nehmen. Aber ich entdecke auch in den Weiterentwicklungen von C++ und C#, dass die Entwickler ähnliche Wege gehen und ich im Design der Sprache noch ein paar Jahre Vorsprung habe. Ich muss nur mit der Implementation hinterherkommen.

Shade Of Mine

Xin schrieb:

Auch damals hatte ich keine Ahnung und Tunnelblick. Und recht.

Der Punkt ist, dass wenn alle so denken würden wie du - es C++ nie gegeben hätte. Denk einfach mal daran.

Aber ich entdecke auch in den Weiterentwicklungen von C++ und C#, dass die Entwickler ähnliche Wege gehen und ich im Design der Sprache noch ein paar Jahre Vorsprung habe. Ich muss nur mit der Implementation hinterherkommen.

Theorie und Praxis... Eine tolle Sprache in der Theorie zu haben ist trivial. Die Praxis ist das Problem. Wenn du aber wirklich so gute Ideen hast, warum nicht zB den Google Summer of Code und ähnliches nutzen um Resourcen zu bekommen? Oder auch hier im Forum meinetwegen... Wenn es nur um Implementierung geht, sollte das ja nicht das Problem sein. Notfalls an llvm dran hängen, dann hat man auch gleich ne ordentliche Basis.

Xin

Shade Of Mine schrieb:

Xin schrieb:

Auch damals hatte ich keine Ahnung und Tunnelblick. Und recht.

Der Punkt ist, dass wenn alle so denken würden wie du - es C++ nie gegeben hätte. Denk einfach mal daran.

Wir kommst Du darauf?

Ich nehme gutes und verbessere es. Im Gegensatz zu "Ich mache eine Sparversion und erkläre es für gut." - so würde ich Java und C# einordnen. Zu der Spar-Sprache kommt dann natürlich das Framework. Dass es sich um Sparversionen handelt, liest sich sehr schon an der Begründung, warum C# kein Const-Correctness hat. Wenn Du im Gegenzug Dich damit beschäftigst, was es bedeutet Const-Correctness zu implementieren, dann verstehst Du noch besser, warum ich hier schrieb, dass C# im Vergleich zu C++ ein Witz wäre.

Ich habe angefangen als Erweiterung zu C++. Dafür schrieb ich einen C-Compiler und erkannte, wieviele Hebel einem da zur Verfügung stehen, an denen niemand ziehen kann. Dann erkannte ich, wie sch... C/C++ eigentlich ist und fing von vorne an und plante die Syntax neu, ohne den Wunsch zu C++ kompatibel zu bleiben weiter zu verfolgen.

Trotzdem ist C++ das Beste, was derzeit verfügbar ist.

Shade Of Mine schrieb:

Theorie und Praxis... Eine tolle Sprache in der Theorie zu haben ist trivial.

ÄÄhh... nein. Das sind jetzt 13 Jahre experimentieren, planen, schreiben, verwerfen... teilweise in Vollzeit.
Das ist definitiv nicht trivial.

Shade Of Mine schrieb:

Die Praxis ist das Problem. Wenn du aber wirklich so gute Ideen hast, warum nicht zB den Google Summer of Code und ähnliches nutzen um Resourcen zu bekommen?

Weil ich keine Anfänger brauchen kann und Profis nicht kostenlos arbeiten.

Solange die Basis nicht steht, bringt es auch nichts 10 Jahre Quelltexte rauszugeben, um dann "tl;dr" und "Ich will aber Blasmusik" zu hören. Erst ist das Konzept umgesetzt, dann überlege ich, ob ich mir reinreden lasse und von wem.

Shade Of Mine schrieb:

Oder auch hier im Forum meinetwegen... Wenn es nur um Implementierung geht, sollte das ja nicht das Problem sein.

Die Implementierung wird tatsächlich langsam überschaubarer, aber trotzdem noch viel Arbeit und halt derzeit ein Freizeitprojekt, weil ich ja auch irgendwovon leben muss.

Shade Of Mine schrieb:

Notfalls an llvm dran hängen, dann hat man auch gleich ne ordentliche Basis.

Das ist nicht die Basis, die ich brauchen kann. Ansonsten funktionieren in meinem Compiler schon Sprachfeatures, die llvm-Sprachen nicht können. Was genau zeige ich gerne, wenn es soweit ist.
Ein Wechsel der Basis erscheint mir nicht mehr sinnvoll, ich würde quasi wieder bei Null anfangen - alleine die Einarbeitung würde mich Unmengen an Zeit kosten.

Dravere

Ich will hier nicht mehr gross mitdiskutieren, da ich den Sinn ebenfalls nicht mehr sehe. Daher nur drei kleine Anmerkungen, welche mir aufgefallen sind:

1. Du findest, ich müsste alle Inkompatibilitäten in den 17 Jahren der Weiterentwicklung von Java kennen, wenn man sich Java Entwickler nennen darf? Aber du weisst nicht mal, was DI im Kontext von Java EE und Container bedeutet? Gut, ich gebe zu, Java war nicht immer zu 100% binär abwärtskompatibel. Teilweise waren es nur 99.6%. Und von 1.4 auf 1.5 tatsächlich nur ca. 90%. Ich habe gerundet. C++ dagegen hat eine binäre Abwärtskompatibilität von 0%. Es ist nicht mal binär kompatibel in der gleichen Version

2.

Xin schrieb:

Öhm... JIT kommt aus den 60ern... da gab's nichtmals C++. ^^

Die Idee war schon in den 60ern vorhanden, korrekt. Aber meinst du wirklich, dass die Idee seither nicht weiterentwickelt wurde und Java zu dieser Weiterentwicklung keinen wertvollen Beitrag geleistet hat?

3.

Xin schrieb:

Ich nehme gutes und verbessere es.

Sag mir aber bitte nicht, dass du dieses "gutes" von irgendeiner anderen Sprache als C++ nimmst?

Und vielleicht noch eine Frage:
Wenn deine Sprache dann mal soweit ist, dass du sie tatsächlich umsetzt und veröffentlichst, was erwartest du dann? Wie werden die Leute darauf reagieren? Wird deine neue Sprache alle anderen in den Schatten stellen und diese verdrängen?

Grüssli

Xin

Dravere schrieb:

1. Du findest, ich müsste alle Inkompatibilitäten in den 17 Jahren der Weiterentwicklung von Java kennen, wenn man sich Java Entwickler nennen darf? Aber du weisst nicht mal, was DI im Kontext von Java EE und Container bedeutet? Gut, ich gebe zu, Java war nicht immer zu 100% binär abwärtskompatibel. Teilweise waren es nur 99.6%. Und von 1.4 auf 1.5 tatsächlich nur ca. 90%. Ich habe gerundet.

90%... tatsächlich? Ähh... jetzt aber nicht ernsthaft, so katastrophal hätte ich das jetzt nicht eingeschätzt.

Du hast Recht, ich habe keinen Plan worauf sich DI bezieht. Erstens kann ich mir Namen und Abkürzungen eh schlecht merken und zweitens hat jedes Konzept in der Informatik eh mindestens zwei Namen. Wenn Du mir also DI an den Kopf wirfst und ich es nicht kenne, verbuche ich es vielleicht unter einem anderen Namen.

Also nochmal... Auf Platz 7 zu "Java DI" findet sich "dependency injection". Wikipedia: "Sie kann als Verallgemeinerung der Fabrikmethoden verstanden werden." - "Dependency Injection überträgt die Verantwortung für das Erzeugen und die Verknüpfung von Objekten an ein extern konfigurierbares Framework, entsprechend einem Komponentenmodell."

Das ist ja der Wahnsinn. Damit ist Windows das extern konfigurierte Framework und die Plugin-DLL erzeugt das Objekt. Joah... wenn das alles war, was DI darstellt, dann wären mehr Buchstaben auch wirklich Verschwendung gewesen.

Dravere schrieb:

C++ dagegen hat eine binäre Abwärtskompatibilität von 0%. Es ist nicht mal binär kompatibel in der gleichen Version

Den Witz verstehe ich jetzt nicht.

Dravere schrieb:

2.

Xin schrieb:

Öhm... JIT kommt aus den 60ern... da gab's nichtmals C++. ^^

Die Idee war schon in den 60ern vorhanden, korrekt. Aber meinst du wirklich, dass die Idee seither nicht weiterentwickelt wurde und Java zu dieser Weiterentwicklung keinen wertvollen Beitrag geleistet hat?

Keine Ahnung, was Java dazu beigetragen hat. Ich sehe ehrlich gesagt auch nicht den Zusammenhang zwischen der Sprache Java und der Übersetzung von Bytecode zu nativen Code. Das gab's alles vor Java. Ich habe JIT übrigens durch NativeCode-JIT-Compiler kennengelernt, die native Programme anderer Computer auf Standard-PCs ausführten.

Das sich mit der Beschäftigung mit JIT-Compilern JIT-Compiler weiterentwickelt haben, ist jetzt auch logisch, aber auch da sehe ich nicht, wieso man dafür Java gebraucht hätte.

Dravere schrieb:

3.

Xin schrieb:

Ich nehme gutes und verbessere es.

Sag mir aber bitte nicht, dass du dieses "gutes" von irgendeiner anderen Sprache als C++ nimmst?

Klar. Ich habe nie gesagt, dass andere Sprachen grundsätzlich schlecht sind - im Gegenteil. Ich sage, dass unterm Strich, wenn ich eine Sprache wählen muss, die Wahl auf C++ fällt, weil der Rest nicht an C++ rankommt. Und ich wünschte, dass man die Resourcen auf C++ gelenkt hätte, damit Features wie override und out früher in C++ zu finden wären. Ich habe auch kein Problem mit Annotations und Reflection in C++ oder C++ auf eine Java oder .NET VM zu kompilieren.
Ich kritisiere Java und C#. Es geht hier um Programmiersprachen, also die Möglichkeit Gedanken zu Quelltext zu transformieren - nicht um Frameworks, nicht um VMs.

Dravere schrieb:

Und vielleicht noch eine Frage:
Wenn deine Sprache dann mal soweit ist, dass du sie tatsächlich umsetzt und veröffentlichst, was erwartest du dann? Wie werden die Leute darauf reagieren? Wird deine neue Sprache alle anderen in den Schatten stellen und diese verdrängen?

Hehehe, das wäre das Ziel, sicher. Wenn ich nicht danach streben würde, wäre der Aufwand ja unsinnig.

Ich bin mir aber bewusst, dass da nicht ein Xin vorbei kommt und mal eben die eine einzig wahre Programmiersprache hinlegt und alles andere vom Markt ist. Meine Erwartung ist, dass die Sache erst über Mundpropaganda läuft und sich dann hoffentlich langsam verbreitet.

Wenn ich Pech habe, interessiert es außer mir keine Sau. Das kann ich nicht beeinflussen. Ich kann nur mein möglichstes tun, gute Gründe zu liefern, sich näher mit der Sprache zu beschäftigen.
Ich entwickle seit 1986 Software und habe seitdem viel Mist gesehen, den ich angehe. Darum ist eine Diskussion über ein Feature auch aufwendig und nicht mal eben auf gut Glück implementiert. Wäre ich nicht optimistisch, hätte ich längst aufgegeben, aber Erwartungen...?
Ich lasse mich überraschen.

Dravere

@Xin,
Ok, hat wirklich keinen Sinn mehr. Ich warte mal auf deine alles veränderte Sprache, welche wahrscheinlich in etwa 200 Jahren kommen und sich dann in einem weiteren Bereich neben allen bereits etablierten Sprachen einnisten wird.

Grüssli

Shade Of Mine

Xin schrieb:

Shade Of Mine schrieb:

Xin schrieb:

Auch damals hatte ich keine Ahnung und Tunnelblick. Und recht.

Der Punkt ist, dass wenn alle so denken würden wie du - es C++ nie gegeben hätte. Denk einfach mal daran.

Wir kommst Du darauf?

Ich nehme gutes und verbessere es. Im Gegensatz zu "Ich mache eine Sparversion und erkläre es für gut." - so würde ich Java und C# einordnen.

Also C# und Java haben mit C++ nun echt nichts zu tun, bis auf dass die Syntax aehnlich ist.

Sie verwenden eine vollkommen andere herangehensweise an Probleme.

Und deshalb ist es wichtig in sowas Energie rein zustecken. Hotspot optimizer, starke VMs, schnelle JITer - das sind alles rein technische Entwicklungen die sich daraus ergeben dass Energie in Java gesteckt wurde. Davon haben dann auch andere Technologien profitiert - zB gaebe es JavaScript in der heutigen Form nicht wenn nicht soviel Energie in starke VMs gesteckt worden waere...

Deshalb waere es fatal zu sagen C++ ist das Mass aller Dinge und wir vergessen alles andere. Viele Entwicklungen gaebe es dann ja nicht.

Aber das ist nicht alles. Java hat andere Denkweisen etabliert. zB hat man in C++ flache Vererbungshierachien und in Java tiefe. zB das ignorieren von Resourcen Management in Java ist ein interessanter Ansatz. Schnelle GCs die es erlauben viel schneller zu allokieren als es C++ kann. Dazu Memory Fragmentation eliminieren... Das ist spannend weil es in C++ nicht wirklich geht. Annotations, Mixins oder andere Sprachen wie zB Prototype basierende Konzepte - totale asynchronitaet wie Node.js - viele viele spannende Konzepte ausserhalb der C++ Welt.

Nicht jedes Konzept ist perfekt, aber es ist wichtig sie zu erforschen. Neue Sprachen koennen so wieder mehr Konzepten waehlen und bessere Mixes entstehen lassen.

Wenn wir alles stehen und liegen lassen nur um C++ zu verbessern (oder eine andere Sprache) dann wuerden wir soviel verlieren.

Warum steckst du zB nicht deine Arbeit in einen C++ Compiler der deine Sprachfeatures anbietet anstatt eine neue Sprache zu entwickeln?

Trotzdem ist C++ das Beste, was derzeit verfügbar ist.

Ich habe heute vCards verarbeiten muessen - es ging dabei um Textersetzungen innerhalb eines gewissen Kontexts. C++ haette komplett gesuckt. Ich habe das zB in PHP in 10 Zeilen Code gemacht. Ich haette es auch in 10 Zeilen Perl oder 10 Zeilen Python oder 10 Zeilen Ruby hinbekommen. Aber in C++ waere das ausgeartet.

Ergo: C++ ist nicht immer das beste.

Ich bin immer an neuen Sprachen interessiert und wenn du gute Ideen hast ist das sicherlich nicht verkehrt darueber zu diskutieren. Alleine schon weil es unterschiedliche Blickwinkel auf Problemloesungen gibt.