Was kommt nach der Objektorientierung?
-
Dobi schrieb:
Xin schrieb:
Dass Java keine Pointer besitzt und deswegen sicher ist oder dass Runtimefehler besser als Fehler beim Kompiliervorgang sind, das stand früher auf Suns Website.
Im Ernst? Das ist ja so extrem dämlich, dass man sich das kaum vorstellen kann. Wie kommt jemand drauf, dass es gut ist, Fehler spät, häufig und beim Kunden zu finden statt früh, einmal und direkt bei sich? Findest du das irgendwo auf archive.org? Ich will mal laut lachen.
1. Java hat intern natürlich Pointer. Was Java nicht hat, ist Pointer-Arithmetik. Ich persönlich habe die auch noch nicht vermisst. Du kannst in Java nicht einfach auf irgendwelche Speicherbereiche zugreifen, die nicht genau dafür vorgesehen sind. Du kannst nichtmal Arraygrenzen überschreiten, ohne dass eine Exception geschmissen wird.
2. Keine Ahnung, wo das mit den Laufzeitfehlern gegenüber den Compilezeitfehlern herkommt. Aber eigentlich kann es sich nur auf Typsicherheit beziehen. In Java hatte man vor der Einführung von Generics in die Sprache nur dynamische Typsicherheit. Jetzt hat man zusätzlich auch statische Typsicherheit. Ich hatte eigentlich nie Probleme damit, dass die statische Typsicherheit fehlte. Eine "ClassCastException" ist zur Laufzeit praktisch nie geflogen. Aber die dynamische Typsicherheit ist durchaus auch sehr wichtig. Die Frage ist, ob Du von allem den Typ zur Compilezeit kennst. Braucht man dynamische Polymorphie? Wenn man sie in einer Sprache anbietet, dann sorgt man zumindest besser auch für dynamische Typsicherheit.
Im Übrigen gibt es jede Menge Sprachen, die die Typsicherheit noch lockerer sehen als Java sie damals gesehen hat: Alle dynamisch typisierten Sprachen, zum Beispiel Python.
2a. Was allerdings definitiv der Fall ist, ist, dass Laufzeit-Fehlermeldungen in Java wesentlich aussagekräftiger als in nativ compilierenden Sprachen sind. Es werden mehr Informationen und Checks in die Laufzeit übernommen, so dass in Fehlermeldungen meistens sofort die genaue Stelle im Code ersichtlich ist, die für den Fehler verantwortlich ist. Debugging von Java Code ist unglaublich einfach und angenehm.
-
Ohne den Thread jetzt weiter verfolgen zu wollen (viel zu lange Texte, gefuehlt wenig Neues).
Xin schrieb:
Ui, soviel Gegenwind und doch nichts Neues.
Liegt wohl daran, dass du relativ wenige harte technische Fakten auflistest bzw. dein System nicht offen ist.
Aka "Wenn es so toll ist, warum kann ich es nicht selbst ausprobieren und abklopfen?"
Wie toll etwas werden wird, glaube ich genau dann, wenn ich es selbst ausprobieren konnte oder zumindest funktionierenden Beispielcode fuer Standardsachen und ein paar technische Daten dazu gesehen habe.
Wir beide schaffen es nicht unsere Server mit einem einzelnen anfragenden Rechner auszulasten. Bei PHP reichen wenige Anfragen pro Sekunde.
Ich mag PHP nicht. Ueberhaupt nicht. Und vielleicht gibt es tatsaechlich pathologische Faelle, wo so etwas moeglich ist. Aber allgemeingueltig ist diese Aussage definitiv nicht.
-
Ich denke es gibt vor allen Dingen einen Bereich, der nach wie vor eines der Kernprobleme in der Programmierung ist:
- Einfinden, Verständnis und Pflege bzgl. Programmcode
Es wird IMO einfach unterschätzt, wie viel Zeit man tatsächlich damit verbringt, Code zu verstehen. Sowohl den eigenen, den man ein paar Monate mal nicht auf dem Schirm hatte, als auch Fremdcode (den sowieso).
Kommentare oder externe Dokumentation in Form von z.B. JavaDoc und Konsorten helfen da kaum. Sie sind entweder veraltet oder unzureichend und zeigen meistens nicht das Kernproblem: Zusammenhänge und Abhängigkeiten zwischen Klassen, Methoden und Attributen. Das ist jedoch genau das, wonach man i.d.R. sucht.
UML geht zwar teilweise dieses Problem an, aber es ist anscheinend so unzulänglich, dass es nicht wirklich ein inhärenter Bestandteil von Tools oder gar der Sprache selbst ist. Wenn hier einer auf den Trick kommt, wie man die von mir beschriebene Problematik irgendwie grafisch oder teilweise grafisch überzeugend darstellen kann UND sie integraler Bestandteil der Sprache ist UND entsprechend von den IDEs unterstützt wird, dann kann man hier wahrscheinlich UNMENGEN an Zeit und Nerven sparen, und die Qualität der Produkte erhöhen.
Aber dieses halbherzige Kommentieren oder die halbgaren Versuche irgendwie UML in den Entwicklungsprozess einzuführen scheitern alle daran, dass sie nicht zentraler Bestandteil einer Sprache sind, und so (zurecht) ignoriert werden. Genausowenig lassen sich Planung und Implementierung aber strikt voneinander trennen, weil die Programmierung ein dynamischer Prozess ist, der zum Teil die Planung entweder einfach überholt oder zumindest verwässert. Umgekehrt kann die Planung nie so detailliert werden, dass Sie für sich alleine genommen die Aufgabe einer Darstellungen der Zusammenhänge bewältigen kann. Irgendwie fehlt hier das Bindeglied.
-
Dobi schrieb:
Ich verfolge die Diskussion mit Interesse, und hab mal eine Zwischenfrage.
Xin schrieb:
Dass Java keine Pointer besitzt und deswegen sicher ist oder dass Runtimefehler besser als Fehler beim Kompiliervorgang sind, das stand früher auf Suns Website.
Im Ernst? Das ist ja so extrem dämlich, dass man sich das kaum vorstellen kann. Wie kommt jemand drauf, dass es gut ist, Fehler spät, häufig und beim Kunden zu finden statt früh, einmal und direkt bei sich? Findest du das irgendwo auf archive.org? Ich will mal laut lachen.
Ich habe das gegen 2000 oder 2001 irgendwo auf der Website gelesen. Vor etwa zwei Jahren habe ich einen Artikel CPP vs Java und es gesucht, aber nicht mehr gefunden. Ich hatte allerdings auch nicht die Muße, 2 Jahre Sun-Website zu durchforsten.
Gregor schrieb:
1. Java hat intern natürlich Pointer. Was Java nicht hat, ist Pointer-Arithmetik. Ich persönlich habe die auch noch nicht vermisst. Du kannst in Java nicht einfach auf irgendwelche Speicherbereiche zugreifen, die nicht genau dafür vorgesehen sind. Du kannst nichtmal Arraygrenzen überschreiten, ohne dass eine Exception geschmissen wird.
Erkläre das mal den Java-Jüngern. Oder den Leuten, die das unterrichten.
Das kontrollieren der Arraygrenzen kostet übrigens Zeit - auch dann, wenn Dein Algorithmus fehlerfrei arbeitet. Das Überschreiten beim Entwickeln meldet mir auch Valgrind, die Release hingegen läuft ohne Handbremse. Und mir kann keiner erklären, dass er OutOfArrayBoundsExceptions abfängt - wer beim Kundeneinsatz daneben greift, der jagt das Programm in die Luft - egal ob C++ oder Java. Ich sehe hier den Vorteil von Exceptions nicht, außer dass die Frage, ob eine geworfen werden soll die Ausführung verlangsamt.
Was die Pointer-Arithmetik angeht: Ich benutze das überall da, wo ich kompromisslos Speed brauche. Das sind gerade grundlegende Datenstrukturen, die auf Speed gezüchtet sind.
Wenn Du Algorithmen hochgradig optimierst, so dass ein i+1 bereits zwischengespeichert wird, weil das auf einer modernen CPU schneller rennt, als i+1 erneut auszurechnen, dann liegen zwischen Iteratoren oder Arrayzugriffen und Pointer-Arithmetik Welten.Wörter zählen für Fortgeschrittene
Gregor schrieb:
2. Keine Ahnung, wo das mit den Laufzeitfehlern gegenüber den Compilezeitfehlern herkommt. Aber eigentlich kann es sich nur auf Typsicherheit beziehen. In Java hatte man vor der Einführung von Generics in die Sprache nur dynamische Typsicherheit. Jetzt hat man zusätzlich auch statische Typsicherheit. Ich hatte eigentlich nie Probleme damit, dass die statische Typsicherheit fehlte. Eine "ClassCastException" ist zur Laufzeit praktisch nie geflogen. Aber die dynamische Typsicherheit ist durchaus auch sehr wichtig. Die Frage ist, ob Du von allem den Typ zur Compilezeit kennst. Braucht man dynamische Polymorphie? Wenn man sie in einer Sprache anbietet, dann sorgt man zumindest besser auch für dynamische Typsicherheit.
Wer hindert Dich in C++?
Gregor schrieb:
Im Übrigen gibt es jede Menge Sprachen, die die Typsicherheit noch lockerer sehen als Java sie damals gesehen hat: Alle dynamisch typisierten Sprachen, zum Beispiel Python.
Yepp, habe Python gelernt und deswegen sofort wieder aussortiert.
Die Messlatte sollte man vielleicht nicht bei denen setzen, die es schlechter machen.
Gregor schrieb:
2a. Was allerdings definitiv der Fall ist, ist, dass Laufzeit-Fehlermeldungen in Java wesentlich aussagekräftiger als in nativ compilierenden Sprachen sind. Es werden mehr Informationen und Checks in die Laufzeit übernommen, so dass in Fehlermeldungen meistens sofort die genaue Stelle im Code ersichtlich ist, die für den Fehler verantwortlich ist. Debugging von Java Code ist unglaublich einfach und angenehm.
Das interessiert mich als Anwender nicht. Und als Ex-Java-Entwickler muss ich Dir leider sagen, dass Exception-Ping-Pong alles andere als leicht zu debuggen ist.
nman schrieb:
Ohne den Thread jetzt weiter verfolgen zu wollen (viel zu lange Texte, gefuehlt wenig Neues).
tl;dr sind mir die Liebsten.
nman schrieb:
Aka "Wenn es so toll ist, warum kann ich es nicht selbst ausprobieren und abklopfen?"
Wie toll etwas werden wird, glaube ich genau dann, wenn ich es selbst ausprobieren konnte oder zumindest funktionierenden Beispielcode fuer Standardsachen und ein paar technische Daten dazu gesehen habe.
Was möchtest Du abklopfen?
Meine Sprache? Ich bemühe mich lediglich, die Fehler, die ich in anderen Sprachen finde auszubügeln. Das Design ist fertig, die Implementierung wird noch einiges an Zeit in Anspruch nehmen. Bis dahin muss jeder seinen Kopf selbst benutzen und auf vorgekaute Produkte verzichten.
nman schrieb:
Wir beide schaffen es nicht unsere Server mit einem einzelnen anfragenden Rechner auszulasten. Bei PHP reichen wenige Anfragen pro Sekunde.
Ich mag PHP nicht. Ueberhaupt nicht. Und vielleicht gibt es tatsaechlich pathologische Faelle, wo so etwas moeglich ist. Aber allgemeingueltig ist diese Aussage definitiv nicht.
Gibt es allgemeingültige Aussagen?
1+1 ist nicht allgemeingültig 2, es kann auch 0 sein im Fall, dass + als Substraktion implementiert wird. Wenn man im C Service ein sleep(1) einbaut, dann wird PHP schneller als C. Im Regelfall, darf man allerdings davon ausgehen, dass 1+1 zwei ergibt, auch ohne die exakte Definition von + vorher herzuleiten. Können wir uns darauf einigen?
xaoC schrieb:
Umgekehrt kann die Planung nie so detailliert werden, dass Sie für sich alleine genommen die Aufgabe einer Darstellungen der Zusammenhänge bewältigen kann. Irgendwie fehlt hier das Bindeglied.
xaoC - schöner Beitrag! Ein Bindeglied habe vor Jahren mal mit einem BWLer diskutiert. Der hatte zu dem Thema sehr viele Ideen, die - soweit mir bekannt sind - nie implementiert wurden.
Hier geht noch einiges, wenn man das Paradigma aufgibt, dass Quelltexte kein Binärformat haben dürfen.
-
Xin schrieb:
tl;dr sind mir die Liebsten.
Deine Texte laden einfach unheimlich zu tl;drs ein. Nichts fuer ungut.
Ich habe das allermeiste gelesen, ich meinte nur, dass ich jetzt dann damit aufhoeren werde, weil ich seitenlanges Allgemeinplaetze rollen nicht spannend finde.
Was möchtest Du abklopfen?
Meine Sprache?
Ja. Wenn man nichts fertig implementiertes posten kann, ist es zumeist hilfreich, zumindest technisch konkretere Aussagen zu taetigen. Hier klingt einfach alles unheimlich vage.
Bis dahin muss jeder seinen Kopf selbst benutzen und auf vorgekaute Produkte verzichten.
Ach, mein Flaschenhals sind nur selten meine Programmiersprachen. Ich verwende viele verschiedene und aergere mich ueber jede einzelne davon, aber ich habe auch aufgehoert an Silberkugeln zu glauben oder welche entwerfen zu wollen.
Im Regelfall, darf man allerdings davon ausgehen, ...
Genau das ist eben der Punkt. Im Regelfall darf man durchaus nicht von pathologischer Worst-Case-Performance bei PHP-Code ausgehen, wenn selbiger nicht extremer Schrott und das Serversetup Muell ist.
Klar lassen sich solche Setups kuenstlich herstellen und gibt es sogar wenige Faelle, wo PHP tatsaechlich ein Flaschenhals sein wird; Normalfall -- wie von dir angedeutet -- ist das aber durchaus nicht.
(Nochmal, ich halte PHP fuer eine der schlechtesten aktiv verwendeten Programmiersprachen da drauszen und ruehre grundsaetzlich keinen PHP-Code an, aber deine Aussage ist einfach nur irrefuehrend.)
-
Xin schrieb:
Ui, soviel Gegenwind und doch nichts Neues.
Wahrscheinlich weil du viel zu absolute Aussagen machst und dabei nicht mal eine Argumentation lieferst. Ich gehe hier nur auf die Antwort auf meine Aussagen ein.
Xin schrieb:
C# ist im Vergleich zu C++ ein Witz, im Vergleich zu Java ein guter Fortschritt.
Da hätten wir so eine Aussage. Wo ist bitte deine Argumentation dazu?
Ich möchte anmerken, dass ich in C++ und C# entwickle. 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? Mit C# habe ich das Programm deutlich schneller fertig und habe auch alle Möglichkeiten direkt zur Hand. C# ist für diesen Fall gegenüber C++ deutlich überlegen. Ich hatte übrigens die Version 1.0 dieser Software in C++ geschrieben gehabt. Ich weiss also recht gut wovon ich hier spreche.Es gibt aber andere Fälle, wo ich auf keinen Fall C# nehmen würde, sondern dann zu C++ greife. Zum Beispiel wenn ich an meine Bachelorarbeit denke, wo ich Berechnungen in der Fluiddynamik gemacht habe, welche möglichst performant laufen sollten. Dafür war z.B. C++ perfekt und C# gegenüber deutlich überlegen.
Und darauf wollte ich eigentlich mit meinem ganzen Beitrag hinaus. Es kommt auf den Anwendungsfall drauf an, ob eine Sprache besser geeignet ist oder nicht.
Xin schrieb:
Dravere schrieb:
DIE ABSOLUTE SPRACHE gibt es nicht und auch C++ wird das nie werden.
Soweit sind wir uns einig. Bedauerlicherweise ist C++ aber das Werkzeug, das am nächsten dran ist.
Nein. Weder C# noch C++ ist am nächsten dran. Es kommt ganz auf den Anwendungsfall an.
Xin schrieb:
Sie sind nicht in C++ geflossen. Wäre nur ein Zehntel davon bei C++ gelandet, hätte das locker gereicht.
Du weisst schon, dass man nicht einfach Ressourcen irgendwo investieren kann und dann kommt automatisch was gutes dabei raus, oder?
Xin schrieb:
Was C++ fehlt ist das Standard-Framework drumherum. Da wo Boost ansetzt.
Die Frage ist, ob dies auch das Standardkomitee möchte. Das scheint mir nämlich nicht so der Fall zu sein. Und daher bringen deine Ressourcen-Investitionen auch nichts
Xin schrieb:
C++ hat viele Frameworks, nur dafür muss man Google bemühen. In Java sind die Grundlagen standardisiert. Inzwischen auch mehrfach. Vieles ist obsolete. Eigentlich ist es da inzwischen genauso chaotisch, aber es heißt Standard.
Ich habe hierbei weder in C++, C# oder Java ein Problem. Keine Ahnung was du damit meinst. Argumente?
Xin schrieb:
Und wenn man einen Standard hat, dann weiß man wo man dran ist. Sofern zwischenzeitlich keiner die JVM aktualisiert. Deswegen installiert man besser die JVM mit, auf der man sich sicher ist, dass das eigene Programm läuft... auch das war Standard, bei allen Firmen, bei denen ich gearbeitet habe und die Java einsetzen.
Java ist zu 100% abwärtskompatibel. Ein Grund wieso es immer noch viele Programme gibt, welche in 1.5 entwickelt werden, da wohl kaum jemand eine Java Version von vor 2004 einsetzt. Gibt auch auch viele Firmen, welche 1.6 einsetzen. Heisst, bei den Firmen wo du gearbeitet hast, wurde das vielleicht so gemacht, aber muss ja nicht gleich für alle gelten. Und auch wenn sie es so machen, wie du beschreibst, was ist daran schlecht?
Grüssli
-
nman schrieb:
Deine Texte laden einfach unheimlich zu tl;drs ein. Nichts fuer ungut.
Nein, kein Problem. Ich finde das gut, wenn man das offen kommuniziert, denn...
nman schrieb:
Was möchtest Du abklopfen?
Meine Sprache?
Ja. Wenn man nichts fertig implementiertes posten kann, ist es zumeist hilfreich, zumindest technisch konkretere Aussagen zu taetigen. Hier klingt einfach alles unheimlich vage.
...es gibt mir sehr gute Hinweise darauf, wen ich mit konkreten Aussagen belasten darf und wen nicht. Und ich meine wirklich belasten. Das Für und Wider abzuwägen ist keine Sache, die man mal in einer lockeren Unterhaltung macht. Das verlangt Engagement für die Sache, ein "Ich wollt's halt mal wissen aber mich nicht tiefergehend damit beschäftigen" hilft keinem von uns beiden.
Wenn ich Dir die Begründung für ein Sprachkonstrukt gebe und sich diese halt über eine Betrachtung von verschiedenen Anfängerlevels über den Hobbyentwickler zum Semi-Professionellen bis hin zum Hochprofessionellen oder Programmiergott begibt, dann entspricht der Gesamtthread vermutlich etwa der Diskussion, ob eine Sprache 'goto' enthalten sollte oder nicht.
Meine Sprache enthält goto.
Das kannst Du schlecht finden, weil goto böse ist. Das sehe ich ähnlich, aber um mich geht's hier nicht.Warum sollte ich das hier erklären, wenn einerseits "tl;dr" und "Hier klingt alles unheimlich vage" aufeinander trifft. Es ist doch Zeitverschwendung. Und genau das ist der Regelfall in allgemeinen Foren, die sich nicht auf genau dieses Thema spezialisiert haben.
Dies ist nicht das richtige Forum dafür, ich habe es bereits vor ein paar Jahren ausprobiert.
Du kannst mir glauben, dass ich mich sehr mit dem Thema Sprachdesign beschäftige und meine Aussagen ohne Begründung als Indiz nehmen oder es lassen. Es ist nicht relevant für die Entwicklung meiner Sprache. Sollte die Implementierung ein Level erreichen, dass ich was zeigen will, werde ich einen Link in meiner Signatur ergänzen.nman schrieb:
Ach, mein Flaschenhals sind nur selten meine Programmiersprachen. Ich verwende viele verschiedene und aergere mich ueber jede einzelne davon, aber ich habe auch aufgehoert an Silberkugeln zu glauben oder welche entwerfen zu wollen.
Eben: Deiner.
Ich mache aber andere Software und mit Feinoptimierungen wie i+1 habe ich einen Algorithmus auf 30% der ursprünglichen (optimierten) Laufzeit gedrückt bekommen. Das Ding lief am Ende 6 Stunden. Ohne diese Optimierungen wären es 20 Stunden gewesen. Der Ursprungsalgorithmus lief 14 Tage pro Datensatz. i+1 ist kein Flaschenhals. Aber solche Details in verschachtelten Schleifen können deutliche Unterschiede machen.
Darum ist es leicht zu sagen, dass sich meine Arbeit nicht lohnt, sei es dabei optimierte Algorithmen zu formulieren oder eine Sprache zu designen, wenn man davon ausgeht, dass andere die gleichen Probleme haben, wie man selbst.
nman schrieb:
Klar lassen sich solche Setups kuenstlich herstellen und gibt es sogar wenige Faelle, wo PHP tatsaechlich ein Flaschenhals sein wird; Normalfall -- wie von dir angedeutet -- ist das aber durchaus nicht.
Lösungen für den Normalfall findest Du bei Java und C#.
Leider kommt bei mir der sogenannte Normalfall selten vor.
Ich programmiere für den Normalfall und das, was bei mir normal ist. 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.-------------------------------------
@Dravere: Ich kürze mal. Sollte Dir irgendwas auf der Seele brennen, wirf es entsprechend markiert wieder rein.
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.
Dravere schrieb:
Es gibt aber andere Fälle, wo ich auf keinen Fall C# nehmen würde, sondern dann zu C++ greife. Zum Beispiel wenn ich an meine Bachelorarbeit denke, wo ich Berechnungen in der Fluiddynamik gemacht habe, welche möglichst performant laufen sollten. Dafür war z.B. C++ perfekt und C# gegenüber deutlich überlegen.
Und denkst Du, dass es Dir leichter fällt, Datenbankzugriffe und GUI einfach in C++ verfügbar zu haben oder dass Du C# möglichst performant bekommst?
Ich habe in C# noch nichts gesehen, was in C++ ein Problem darstellt.Mit Reflection konnte ich ein paar schöne Dinge zaubern, die in C++ aufwendiger sind. Allerdings war der Zauber auch nicht ohne, so dass ich im Schnitt mit der C++-Lösung wieder besser fahre.
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.
Dravere schrieb:
Xin schrieb:
Sie sind nicht in C++ geflossen. Wäre nur ein Zehntel davon bei C++ gelandet, hätte das locker gereicht.
Du weisst schon, dass man nicht einfach Ressourcen irgendwo investieren kann und dann kommt automatisch was gutes dabei raus, oder?
Ich verstehe die Aussage nicht. Bei mir ist es jedenfalls kein Glücksfall, wenn was Gutes dabei rauskommt, das plane ich üblicherweise vorher.
Man hätte vergleichsweise wenig Resourcen gebraucht, um C++ für den Normalfall besser mit Standards auszustatten.
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.
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.
-
Xin schrieb:
Lösungen für den Normalfall findest Du bei Java und C#.
Leider kommt bei mir der sogenannte Normalfall selten vor.
Ich programmiere für den Normalfall und das, was bei mir normal ist. 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.Normalfall ist wohl PHP. Schau dir Marktanteilig an wieviele Server auf LAMP setzen.
Da kann PHP schon nicht so langsam sein.
-
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.
-
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.
-
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.
-
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.
-
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!
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
