Was kommt nach der Objektorientierung?
-
redrew99 schrieb:
Xin schrieb:
Ich stelle die Frage absolut wertfrei: Warum sollte man das tun?
Welchen Vorteil versprichst Du Dir davon, Quelltexte in 3D zu beschreiben?Ich könnte mir vorstellen, daß durch eine zusätzliche Dimension komplexere Programme möglich sind.
Evtl. sollte auch schnelleres Programmieren möglich sein.
Ich tue mich sehr schwer damit, Ideen als Unfug abzutun, wenn ich sie nicht verstehe. Diese Idee verstehe ich nicht, habe aber den Verdacht, dass Du derzeit auch kein Konzept hast. Jedenfalls lassen "könnte mir vorstellen" und "eventuell möglich" darauf schließen.
Könntest Du ein konkretes Beispiel, einen konkreten Anwendungsfall beschreiben - unter Berücksichtigung, das der Mensch nur in der Lage ist, 2D Informationen mit einer ungefähren Entfernung wahrzunehmen, aber nicht 3D-Informationen. Um den Unterschied zu verdeutlichen: Du siehst den Monitor, Du siehst, dass er etwa 60cm vor Dir steht, aber Du siehst nicht, was hinter dem Monitor ist. Der Mensch sieht immer einen kleinen Ausschnitt der ihm zugewandten Ebene. Das Hauptsinnesorgan des Menschens ist das Gedächtnis, nicht das Auge. Entsprechend wird jede Kommunikationsform scheitern, die den Menschen überfordert.
Das höchste der Gefühle sind Ebenenwechsel, gewissermaßen kontextabhängige, also integere Schritte durch eine 3. Dimension, die jedoch mehr als Filter, denn als Sprachdimension funktioniert. Und das wiederum gibt es bereits in einfacher Form, auch wenn ich auf den derzeit populären Systemen keine brauchbare Umsetzung kenne.
redrew99 schrieb:
So könnte z.B. ein Vektor mit einem bestimmten Gebilde dargestellt werden, wo man den Datentyp durch Veränderung der Farbe bestimmt. Der "Vektor" könnte darüberhinaus Buttons haben oder andere Eigenschaften(evtl. Displays?), um weitere Verändungen vornehmen zu können. Auch mit Tönen könnte man arbeiten.
Bis auf die Töne verstehe ich nur Bahnhof und da pfeift bei mir der Zug.
Man könnte mit Tönen arbeiten, das kann ich mir mal vorstellen... damit hätten wir eine zusätzliche Dimension. Aber was sollte man dadurch zusätzlich ausdrücken? Und überflieg mal einen Buch und ein Tonband. Das Tonband geht Dir sehr schnell auf den Keks.redrew99 schrieb:
Xin schrieb:
Und was soll die dritte Dimension abbilden?
Die dritte Dimension könnte die "Grammatik" der Sprache abbilden.
Definiere Grammatik.
Die Grammatik einer Sprache lässt sich in C, wie auch in Deutsch, wunderbar in einer einzigen Dimension (eine Zeile bestehend aus Buchstaben/Wörtern) abbilden. Die zweite Dimension (Zeilen) benötigen wir nur, damit wir nicht endlos nach links und rechts scrollen müssen, wie z.B. die Turing-Maschine.
redrew99 schrieb:
Womöglich könnte man z.B. einen Zeiger als einen echten Zeiger darstellen.
Ein Zeiger ist ein Integerwert. Das ist nicht sonderlich intuitiv, aber Zeiger konkret abzubilden würde einem Spaghetti-Teller entsprechen. Ebenfalls nicht meine erste Assoziation mit "intuitiv".
redrew99 schrieb:
Natürlich könnte auch die jeweilige Anordung der Gebilde im Raum eine bestimmte Funktion haben.
Neben dem Darstellungsproblem, wie auch Problem der menschlichen Unfähigkeit 3D-Informationen wahrnehmen zu können, erscheint mir das ganze... weit hergeholt.
Solltest Du Bezug nehmen auf Hollywoodfilme, wird Dir sicher aufgefallen sein, dass alle Geheimagenten grundsätzlich futuristische Betriebsysteme verwenden, die supertoll sind, aber niemals Windows und in jedem Film läuft ein Super-Nerd rum, der nie mehr als 3 Minuten benötigt, um sich in die geheimsten Anlagen reinzuhacken. Außerdem können sie aus vier Pixeln ein Bild rechnen, in dem man in der Spiegelung der Sonnenbrille noch genug Qualität hat, um ein Fahndungsfoto zu generieren.
Science Fiction beschreibt eine mögliche Zukunft. Aber die Wahrscheinlichkeit, dass wir irgendwann durch einen Spalt in den Erdkern fallen und dann mittig in der Luft schweben, wird auch in Zukunft mehr Fiktion als Science sein.Hier geht's um komplexe Aufgaben, nicht nur darum mit einer Handbewegung ein Foto rotieren zu lassen: Hier ist die Technik soweit, aber man scheitert daran, sinnvolle Aufgaben für die Technik zu finden - die Beschreibung hat Hollywood nämlich nicht mitgeliefert.
-
Programmieren in einer stylischen 3D-Umgebung, wie du sie dir vorstellst, wird es sicher nicht geben, höchstens mal als Spaßprojekt von ein paar Studenten oder so. Ich könnte mir nichts unpraktischeres vorstellen. Du guckst zu viele Hacker-Filme.
Selbst bei grafischer Programmierung wie beispielsweise per LabView kann ich mir nur schwer vorstellen, welche Verbesserung eine dritte Dimension bringen soll. Höchstens könnte man mehrere Vi's in einem Control darstellen. Wird ein Sub-Vi aufgerufen, könnte es hinter dem aktuellen vi angezeigt werden o.ä. Aber das wäre absolut keine Weiterentwicklung des Programmierens an sich, sondern nur ein modisches Grafik-Gimmick ohne echten Mehrwert.
-
Eigentlich gab es in den letzten 50 Jahren nur 2 "Trends", die sich halten konnten: Strukturierte Programmierung und (viel später) Objektorientierung. Ich denke, dass die Objektorientierung erhalten bleiben wird, sich aber weiterentwickeln muss. Die Grundidee ist sehr gut und unterstützt das Prinzip der Low Representational Gap. Man orierntiert sich an Konzepten, die es in der Realität offensichtlich gibt und abstrahiert dann.
Funktionale Programmiersprachen haben einen schweren Stand, weil das Paradigma so völlig quer steht zu praktisch allem, was etabliert ist. Klar, spezialisierte Anwendungen gibt es immer, aber verbreitet sind diese Sprachen nicht.
Die grossen objektorientierten Sprachen (ich denke da an .NET-Sprachen, C++ und Java etc.) werden in Zukunft noch mehr Rosinenpickerei betreiben und sich die besten Elemente der funktionalen Sprachen (und andere Konzepte) stehlen.
-
/rant/ schrieb:
Die grossen objektorientierten Sprachen (ich denke da an .NET-Sprachen, C++ und Java etc.) werden in Zukunft noch mehr Rosinenpickerei betreiben und sich die besten Elemente der funktionalen Sprachen (und andere Konzepte) stehlen.
Das Wort stehlen passt nicht.
Funktionale Programmierung ist - wie auch OOP - auch in C möglich und(!) wird auch betrieben. Es ist beides etwas unhandlicher als bei Sprachen, die OOP bzw. FP besser unterstützen.
Deswegen sehe ich hier auch keine Paradigmen, sondern Problemlösungen: Entwurfsmuster.
Die funktionale Programmierung ist allerdings ein etwas umständlicheres Konzept, was dank Multi-Threading derzeit Aufwind erhält.Schlussendlich sind funktional ausgelegte Sprachen lediglich Sprachen, die diese Problemlösung syntaktisch hervorheben, bzw. bevorzugen, während imperative Sprachen mehr der Idee eines Kochrezeptes folgen, wo man auch mal was in eine Schüssel geben darf und das dann später weiter verwendet. Gerade dieses "Vorkochen" von Ergebnissen war früher deutlich wichtiger. Ein Programm reagierte nur durchgehend flüssig, wenn bei komplexen Berechnungen zuvor schon einiges vorbereitet war. Das passt aber nicht so gut in die Idee der FP.
Funktionale Design-Patterns wurden in der Vergangenheit also seltener benötigt. Sprachen wandeln sich entsprechend der Anforderungen. So vereinfacht sich die C++-Syntax nun zur funktionalen Programmierung hin, wie sie sich ursprünglich aufbauend von C zu OOP gewandt hat und anschließend zur generischen Programmierung gewandelt hat.
Das ist Evolution, eine Anpassung an die Wünsche und Bedürfnisse der Benutzer. Nicht stehlen.
Wer Programmieren als "Kampf der Paradigmen" hochstilisiert, hat offenbar nichts besseres zu tun.
-
redrew99 schrieb:
Ich könnte mir vorstellen, daß durch eine zusätzliche Dimension komplexere Programme möglich sind.
Darin scheint mir den Denkfehler zu liegen das eine komplexere Abbildung der Sprache komplexere Programme ermöglich.
Genau das Gegenteil ist der Fall. Komplexere Probleme können heute nur dadurch bewältigt werden, weil die Darstellung vereinfacht wurde.
redrew99 schrieb:
Evtl. sollte auch schnelleres Programmieren möglich sein.
Komplexität => mehr Denkarbeit => mehr Chancen auf Fehler ==> langsameres Programmieren.
redrew99 schrieb:
So könnte z.B. ein Vektor mit einem bestimmten Gebilde dargestellt werden, wo man den Datentyp durch Veränderung der Farbe bestimmt.
Farben sind abhängig vom Monitor und der Sehfähigkeit des Benutzers (-> rot/Grün Schwäche, Farbenblindheit etc). Allein das ist erzeugt ein Problem. Ausserdem erzeugst Du nur eine Abstraktionseben. Anstatt den Datentyp direkt zu shene (long) musst Du lernen das Rot = long ist, Grün = int usw. Die Darstellung eigener Datentypen wird dann schon eine Herausforderung. UNd so viele unterscheidbare Farben gibt es gar nicht.
redrew99 schrieb:
Auch mit Tönen könnte man arbeiten.
Ok, alle die Hand heben die eindeutig den Ton C erkennen wenn er gespielt wird. Dafür braucht man ein absolutes Gehör und das ist sehr selten.
redrew99 schrieb:
Natürlich könnte auch die jeweilige Anordung der Gebilde im Raum eine bestimmte Funktion haben.
Eines der wichtigsten Kriterien für eine Sprache ist, das man sich auch mit anderen Menschen darüber unterhalten kann. So, jetzt beschreib mal die Anordnung der Konstelllation Kassiopeia eindeutig nur durch Worte so das jemand anders begreift, das Du Kassiopeia meinst.
-
redrew99 schrieb:
Vielleicht hast Du Recht. Allerdings - gab es auch mal Zeiten, wo man sich nicht vorstellen konnte, daß Hochsprachen wie C++ ein derart hohes Leistungsniveau erreichen können.
Was wurden die Leute niedergemacht, ein Mehr an Abstraktion führe zwangsläufig
zu Geschwindigkeitseinbußen, etc.,etc.Da gibts aber einen ganz wichtige Unterschied. C++ und Objektorientierung sind Sachen, die grundsätzlich nützlich und einleuchtend sind. Dass man sich früher nicht vorstellen konnte, dass man sie ohne gravierende Nachteile in der Praxis einsetzen können wird, ist eine andere Sache, das waren technische Probleme, die gelöst wurden. Wenn du von "3D Programmierung" reden, ist es etwas, wo sich niemand (außer Hollywood) vorstellen kann, wie das gehen soll und was es für einen Sinn haben sollte, außer dass es stört und ablenkt.
Man kann C++ sicher nicht in die dritte Dimension erweitern. Du bringst Daten und Darstellung durcheinander. Die Darstellung hat nichts mit der Sprache zu tun. Du könntest also (rein hypothetisch) statt vector<int> irgendwie vector und in der Z-Ebene int schreiben. Das wäre eine andere Darstellung. Irgendwie. Kannst aber nicht in die Sprache einbringen, nicht richtig beschreiben, speichern, nichts. Stört nur. Und natürlich kann ich viel schneller vector<int> eintippen, als irgendwie in die dritte Dimension zu wechseln, int einzugeben, und dann zurückzuwechseln. Das macht von vorne bis hinten überhaupt keinen Sinn.
Selbst so grafische "Programmiersysteme" wie Workflows, die z.B. Geschäftsprozesse beschreiben kann ich mir nicht dreidimensional vorstellen. Ich kann jetzt überhaupt keinen Vorteil darin erkennen, aber zusätzliche Komplexität.
Töne macht genauso überhaupt keinen Sinn. Versuch bloß nicht, irgendwelche Zusätzlichen Dimensionen reinzubringen, KISS. Geschriebenen Code kann man sehr schnell überfliegen und versteht oft gleich, was es macht. Etwas, was da aus der Reihe tanzt, eine zusätzliche Dimension von Tönen z.B. macht es schon sehr viel schwieriger. Das muss man im Hirn synchronisieren. Und dann hat man sich verhört und denkt sich, hä, nochmal... Weil mans eben nicht sehen kann
Ansonsten: YMMD
-
Marty Mc Fly schrieb:
Wildes Spekulieren über Softwareentwicklung in 10, 30 oder 50 Jahren.
Würde mich interessieren wie ihr euch die Zukunft der Programmierung vorstelltIch denke, dass schon die Fragestellung veraltet ist. In den Achtzigern und Neunzigern wurde die Programmierung als die Schlüsselstelle angesehen, die die Effektität des Einsatzes von IT maßgeblich beeinflusst.
Tatsächlich aber hat sich an den in der Softwarekrise benannten Problemen in den letzten vierzig Jahren eigentlich nichts verändern.Ich halte deshalb die Fragestellung schon für das Problem selbst: Die Vorstellung, dass die Lösung von üblichen Problemen der Softwareentwicklung in der Findung eines technischer Mittels (Hardwarearchitekturen, Programmiersprache, Entwurfsmuster, Softwareentwicklungsprozess, Modellierungswerkzeug) läge.
Ciao, Allesquatsch
-
Allesquatsch schrieb:
Ich halte deshalb die Fragestellung schon für das Problem selbst: Die Vorstellung, dass die Lösung von üblichen Problemen der Softwareentwicklung in der Findung eines technischer Mittels (Hardwarearchitekturen, Programmiersprache, Entwurfsmuster, Softwareentwicklungsprozess, Modellierungswerkzeug) läge.
Also Hardwarearchitekturen, Programmiersprachen, Entwurfsmuster, Softwareentwicklungsprozesse, Modellierungswerkzeuge - das sind mMn. alles Dinge die in der Vergangenheit massiv viel gebracht haben. OK, über Modellierungswerkzeuge kann man vielleicht streiten, aber der Rest...?!?
Einige davon sind vermutlich noch nicht ausgereizt, andere (was die Lösung von "üblichen Problemen der Softwareentwicklung" angeht) vermutlich schon. Nur ... wenn es in der Vergangenheit solche "technischen Mittel" gab, die viel gebracht haben, wieso sollte es dann in Zukunft nicht wieder so sein?
-
Im Bezug auf Visualisierung könnte sich aber schon noch was tun. Das müssen ja nicht gleich Hologramme und Steuerung à la Minority Report sein.
Automatisch generierte Klassendiagramme sind schon ein Anfang. Der nächste Schritt wäre, solche Darstellungen auch während der Laufzeit anzupassen. Für Debugging könnte man Datenstrukturen grafisch darstellen und Beziehungen untereinander sichtbar machen. Beispielsweise Zeiger als Pfeile oder Veränderungen von Werten durch Animationen (und evtl. Soundeffekten). Um den Spaghettiteller zu vermeiden, bildet man eben nicht den ganzen Adressraum, sondern nur relevante Teile ab. Interessant sind vielleicht auch Grafiken, welche den zeitlichen Verlauf miteinbeziehen.
Fürs Schreiben des Codes sehe ich diesbezüglich aber eher weniger Potential. Wizards können zwar einzelne Boilerplate-Aufgaben übernehmen, aber der Grossteil des Codes wird wohl weiterhin von Hand (u.U. mit Unterstützung von Vervollständigungstools) geschrieben.
-
Nexus schrieb:
Beispielsweise Zeiger als Pfeile oder Veränderungen von Werten durch Animationen (und evtl. Soundeffekten).
Sicher könnte man was verbessern, evtl. sogar viel. Weiß nur noch nicht wie. Aber was du vorschlägst schaut für mich schon wieder nach Spielereien aus. Visual Studio Debugger markierte Werte, die sich geändert haben rot. Damit komme ich durchaus zurecht. Ich will da keine Animation und bloß keine Soundeffekte. Würde nur ablenken und stören.
Und ein Pfeil für Zeiger? Auf was soll er zeigen und wie soll das ausschauen? Wenn der Debugger den Zeigertyp kennt (und das tut er, wenn man nicht grad void* verwendet), dann zeigt er den Wert an, den kann man aufklappen usw... Find ich schon durchaus brauchbar gelöst.
Was mich beim Visual Studio C++ Debugger stört ist die autoexp.dat. Ich finde sie nicht intuitiv genug um damit viel anfangen zu können. Viel zu kryptisch, ich muss mich jedesmal reindenken und rumprobieren (und dabei Visual Studio neustarten). Der C# Debugger ist da z.B. wesentlich besser, allein schon weil es eine ToString Methode gibt, die man überschreiben kann und die in 98% der Fälle beim Debuggen enorm weiterhilft, und weil man eigene Visualizer programmiern kann, was man aber selten braucht.
-
hustbaer schrieb:
Also Hardwarearchitekturen, Programmiersprachen, Entwurfsmuster, Softwareentwicklungsprozesse, Modellierungswerkzeuge - das sind mMn. alles Dinge die in der Vergangenheit massiv viel gebracht haben. OK, über Modellierungswerkzeuge kann man vielleicht streiten, aber der Rest...?!?
Da stimme ich Dir auch zu und ich selbst finde diese Ansätze auch wunderbar. Aber es gab immer eine große Diskrepanz zwischen den Erwartungen und dem, was nachher wirklich passiert ist. (Und es waren nicht nur die Marketing-Jungs, die diese Erwartungen hatten. Noch heute begegnen mir genügend Techniker, die daran glauben, dass die konsequente Anwendung der Innovation XY in x Jahren die üblichen Probleme beseitigen würde.)
Natürlich ist die technische Infrastruktur, Standard- und Individualsoftware immer mächtiger geworden, aber bei den klassischen Kriterien der Softwarequalität hat es nicht den erwarteten Sprung gegeben: Korrektheit, Zuverlässigkeit, Robustheit, Effizienz, Benutzerfreundlichkeit, Wartbarkeit, Wiederverwendbarkeit, Portabilität.
Zumindest habe ich nicht den Eindruck, dass sich die Quote der erfolgreichen, in Time&Budget gebliebenen Softwareprojekte nicht verändert hat, dass Programme nicht fehlerfreier oder korrekter geworden sind.
Natürlich sind die Entwicklungen positiv und konsequent: Von strukturierter Programmierung zur Objektorientung zur Serviceorientierung.
Aber die Kluft zwischen dem fachlichen Bedarf und den produzierten Lösungen ist geblieben.Ciao, Allesquatsch
-
Allesquatsch schrieb:
Natürlich ist die technische Infrastruktur, Standard- und Individualsoftware immer mächtiger geworden, aber bei den klassischen Kriterien der Softwarequalität hat es nicht den erwarteten Sprung gegeben: Korrektheit, Zuverlässigkeit, Robustheit, Effizienz, Benutzerfreundlichkeit, Wartbarkeit, Wiederverwendbarkeit, Portabilität.
Ich würde sagen dass sich auch in diesen Bereichen viel getan hat.
Nicht so viel wie sich einige erwartet haben, aber mehr als sich andere erhofft haben.
Davon abgesehen ist Software heute wie auch damals so gut wie man sie macht. Und natürlich ist da Software keine Ausnahme. Wir sind in vielen Bereichen technisch so weit, dass wir Dinge mit unglaublicher Qualität fertigen könnten, wenn wir nur die Preise verlangen könnten die vor 10 oder 100 Jahren dafür verlangt wurden.
Bloss können bzw. wollen wir heute nicht mehr einen Uhrmacher 5 Jahre lang an einer Armbanduhr arbeiten lassen. Wir wollen lieber einen €10 Quarzwecker oder vielleicht maximal noch einen €200 Seiko Chronograph. Und mit Software ist es nicht anders.
Dass man dabei gleichzeitig die Qualität steigern konnte sehe ich als grossen Fortschritt.
-
Allesquatsch schrieb:
Zumindest habe ich nicht den Eindruck, dass sich die Quote der erfolgreichen, in Time&Budget gebliebenen Softwareprojekte nicht verändert hat, dass Programme nicht fehlerfreier oder korrekter geworden sind.
Das wohl nicht, aber ich denke, die Software ist mittlerweile auch wesentlich umfangreicher und die Anforderungen wesentlich höher als früher. Ich würde vorsichtig behaupten, dass es eine Explosion der Komplexität gegeben hat. Natürlich kann man das nicht pauschal behaupten, auch früher gab es komplexe Software und grad im High End Bereich gab es schon immer sehr hohe Ansprüche. Aber die "Standardsoftware" und die Erwartungen an sie ist doch deutlich komplexer geworden. Wo früher vielleicht ein kleines Konsolentool gereicht hat, das irgendwas berechnet und in einer Pseudodatenbank speichert, erwartet man heute von einem ähnlichen Projekt vielleicht schon eine Anbindung an 2-3 ERP Systeme, eine Webgui mit Benutzerverwaltung, Webservices, Load Balancing, Statistik mit 3D Diagrammen, Export an Word/Excel/PDF, und das alles bitte in einer Woche, ist ja Standard.
-
hustbaer schrieb:
Allesquatsch schrieb:
Natürlich ist die technische Infrastruktur, Standard- und Individualsoftware immer mächtiger geworden, aber bei den klassischen Kriterien der Softwarequalität hat es nicht den erwarteten Sprung gegeben: Korrektheit, Zuverlässigkeit, Robustheit, Effizienz, Benutzerfreundlichkeit, Wartbarkeit, Wiederverwendbarkeit, Portabilität.
Ich würde sagen dass sich auch in diesen Bereichen viel getan hat.
Ich würde sagar behaupten, dass Java die IT-Welt (im Bereich Design von Programmiersprachen) um etwa 15 bis 20 Jahre zurückgeworfen hat.
Mit großem Marketing ("Java ist sicher, weil es keine Zeiger hat") wurde das Java-Konzept gehypt und als den Gral der IT dargestellt. Ich habe Java nachdem ich es gelernt habe (2000) sofort für tot erklärt. Und auch wenn das natürlich gerade in Zeiten des Java-Hypes belächelt wurde und doch heute, wo Java weiterhin stark im Rennen ist, ist der Hype vorbei und C++, das von der damaligen Mehrheit für tot erklärt wurde, davon unberührt. Es findet eine Rückbesinnung statt zu nativen Code, zu den Möglichkeiten, die C++ schon in den 90ern bot.
Mit viel Aufwand wurde daran gearbeitet, Java mit dem JIT-Compilern Beine zu machen, dank des Garbage-Collectors muss man Speicher nicht mehr freigeben und für Anwendungen, die eine kontrollierte Laufzeit haben, kann man den GC abstellen und muss dann nur "Disposen". Es wurde viel Zeit verwendet, Java beizubringen, was C++ schon kann.
Hätte man die Energie, die man in Java gesteckt hätte in C++ gesteckt und in deren Libs und Frameworks, wären wir schon deutlich weiter - imho.
-
Xin schrieb:
Hätte man die Energie, die man in Java gesteckt hätte in C++ gesteckt und in deren Libs und Frameworks, wären wir schon deutlich weiter - imho.
naja, java ist doch auch nur ein programm. ich denke c++ hat sich relativ unabhängig entwickelt.
btw. ich könnte fast kotzen, wenn ich eine library nutzen muss, die in c++ designed ist. für anwendungen und große software - okay, aber für eine lib die entweder total exotisch, extrem klein, oder aus mögl. vielen anderen sprachen aufgerufen werden soll? total ungeeignet!
-
kellerkindanwärter schrieb:
Xin schrieb:
Hätte man die Energie, die man in Java gesteckt hätte in C++ gesteckt und in deren Libs und Frameworks, wären wir schon deutlich weiter - imho.
naja, java ist doch auch nur ein programm. ich denke c++ hat sich relativ unabhängig entwickelt.
Hätte man weniger Zeit damit verschwendet, den Leuten eine billige Programmierausbildung in Java als "modern" zu verkaufen und stattdessen C/C++ geschliffen, wären wir imho weiter.
kellerkindanwärter schrieb:
btw. ich könnte fast kotzen, wenn ich eine library nutzen muss, die in c++ designed ist. für anwendungen und große software - okay, aber für eine lib die entweder total exotisch, extrem klein, oder aus mögl. vielen anderen sprachen aufgerufen werden soll? total ungeeignet!
Und hier hätten wir schon einen Punkt, an dem man hätte schleifen können, denn das Object-Format ist imho das erste, wo man hätte ansetzen können. Niemand verlangt schließlich, dass C-Compiler nach .o kompilieren müssen.
Hat man aber nicht. Man hat sich mit Java des Problems entledigt und sich einfach einen Sack voll neuer, moderner Probleme aufgeladen, die bereits gelöst waren.
-
Xin schrieb:
...Und hier hätten wir schon einen Punkt, an dem man hätte schleifen können
für meinen geschmack ist c++ schon verschliffen. der stein hat einfach zu viele facetten!
-
Fast2 schrieb:
Tut mir leid, dass das jetzt aus dem Gesprächsfluss heraussticht, aber ich dachte, ich hätte es schon gestern abgesendet, allerdings hatte ich dabei nur auf Vorschau geklickt.
Feriuko schrieb:
Die Symbolkraft endet an der Tastatur.
Solange ich da nicht die speziellen Unicodesymbole direkt und per default mit einem Tastendruck eintippen kann, werden Symbole für eine Programmiersprache keine Chance haben.
Ein kleines bisschen Hoffnung habe ich ja schon, dass sich endlich mal alternative Tastenbelegungen zumindest so weit verbreiten, dass ingendwann wenigstens mehr als 30% der Computernutzer überhaupt davon wissen, dass es die gibt …
http://neo-layout.org/Das neo Layout ist ein alter Hut und es wird sich niemals durchsetzen.
Wenn eine Sekräterin eine Arbeitsstelle suchst, was meinst du, wird sie vorfinden?
Natürlich QWERTZ/Y und das wird sie auch als Tippse können müssen.Der Einzelne Freak mag sein Layout umstellen, aber 99 % der Masse macht es nicht und die Tastaturen bleiben bei einem aufgedrcukten QWERTZ/Y Layout.
Dazu kommen dann noch die tausende von Programmen, die QWERTZ/Y als gegeben hinnehmen und darauf ihre Shortcuts optimieren.
Bei manchen Programmen darf man die Shortcuts nichtmal verändern und bei denen wo man es kann, ist ein großer Teil nur umständlich und eine Insellösung.Solange man hier also nicht global über das OS auf das NEO Layout umstellen und trotzdem gute Shortcuts (hier entscheidet dann die Position der Taste, nicht das, was ausgegeben wird, wenn draufgedrückt wird) haben kann, sind die Chancen für das NEO Layout = 0.
Insofern ist das ne Illusion und dann müßte der einzelne ja noch umlernen wollen.
Ich kann mit QWERTZ/Y recht schnell tippen, die speziellen Symbole die NEO bieten würde, habe ich zwar nicht, aber das umschreibt man einfach durch Text oder vergleichbarem.
Auch Matheprogramme machen das so, z.b. SQRT anstatt das Quadratwurzelzeichen.Insofern hat NEO eigentlich keine Chance, es bleibt eine Insellösung und wer es nutzen will, der hat es sehr umständlich und muss alles und jedes Programm daran anpassen.
-
Xin schrieb:
Mit großem Marketing ("Java ist sicher, weil es keine Zeiger hat") wurde das Java-Konzept gehypt und als den Gral der IT dargestellt. Ich habe Java nachdem ich es gelernt habe (2000) sofort für tot erklärt. Und auch wenn das natürlich gerade in Zeiten des Java-Hypes belächelt wurde und doch heute, wo Java weiterhin stark im Rennen ist, ist der Hype vorbei und C++, das von der damaligen Mehrheit für tot erklärt wurde, davon unberührt. Es findet eine Rückbesinnung statt zu nativen Code, zu den Möglichkeiten, die C++ schon in den 90ern bot.
Das sehe ich nicht so.
Inzwischen dringt Java auch in Bereiche vor, wo man aus Performancegründen immer noch auf C++ setzte.
Und eines ist ganz klar, die Entwicklung in Java ist wesentlich günstiger, die Programmierer kosten weniger und meistens setzt sich das günstigere System durch und nicht das Qualitativ* bessere.
* Wobei es hier bei C++ dann schon auf die Anwendung und die Umsetzung ankommt, wenn man von Qualitativ sprechen möchte, denn so pauschal kann man das nicht sagen.
Vorteile hat C++ z.B. natürlich nach wie vor im Resourcenverbrauch und wenn das ein Maßstab für Qualität ist, dann ist C++ natürlich keine schlechte Wahl.
Sind die Programmierer aber Stümper, dann dürfte Java die bessere Wahl sein.Es wurde viel Zeit verwendet, Java beizubringen, was C++ schon kann.
Hätte man die Energie, die man in Java gesteckt hätte in C++ gesteckt und in deren Libs und Frameworks, wären wir schon deutlich weiter - imho.
C++ ist eine gewachsene Sprache, die natürlich ihre Altlasten mit sich bringt und die können dann auch stören.
Wenn wir also von "Wünsch dir Was" sprechen wollen, dann würde ich eher sagen: Würde die gesamte IT Branche auf eine von Grund auf moderne neue Sprache (z.B. D) umschwenken und die Zeit in entsprechende Libs und Frameworks stecken, dann könnten wir Java und C++ zu den Akten legen und bestenfalls nur noch für Nischenlösungen (z.b. Plattformunabhängigkeit auf Binärebene) benötigen.
Aus so einer Sicht ist also auch C++ nicht die erste Wahl.
Die Sprache ist ein gewachsene Monstrum, ich muss nicht erwähnen, wie lange es dauert, bis ein Programmierer wirklich gut darin geworden ist.
-
Feriuko schrieb:
Inzwischen dringt Java auch in Bereiche vor, wo man aus Performancegründen immer noch auf C++ setzte.
...und zieht sich gleichzeitig aus ihrem Umfeld zugunsten anderer Sprachen, darunter auch C++, wieder zurück.
Auf dem Mac gehört Java inzwischen schon nicht mehr zur Standardinstallation, was ich durchaus bemerkenswert finde.
Feriuko schrieb:
Und eines ist ganz klar, die Entwicklung in Java ist wesentlich günstiger, die Programmierer kosten weniger und meistens setzt sich das günstigere System durch und nicht das Qualitativ* bessere.
Richtig. Der Punkt ist hier, dass sich die günstigen Programmierer langfristig nicht bezahlt machen. Schon mal ein Programm gesehen, was Exception-Ping-Pong spielt? Eine Java-Designschwäche, die mir schon offensichtlich war, als ich Java vor 11 oder 12 Jahren lernte. Das ist heiter zu debuggen. Den Java-Programmierer braucht man um den Bug einzubauen, aber das Match beenden soll dann bitte der C++-Programmierer.
Ich habe schon als Java-Entwickler gearbeitet.Feriuko schrieb:
Sind die Programmierer aber Stümper, dann dürfte Java die bessere Wahl sein.
In diesem Satz sind wir uns einig und da steckt soviel Wahrheit drin, dass ich nicht einfach löschen wollte.
Feriuko schrieb:
Wenn wir also von "Wünsch dir Was" sprechen wollen, ... Aus so einer Sicht ist also auch C++ nicht die erste Wahl.
Und auch hier sind wir uns einig.
Java und C# zeigen nur eins deutlich: Alle warten auf die Generation nach C++. C++11 ist ein Weg in diese Richtung, aber die Altlasten bleiben. Java und C# beweisen, dass der Wunsch so groß ist, dass man sogar bereit ist, komplett neue Infrastruktur zu akzeptieren und aufzubauen.
Also... das Wunschkonzert ist eröffnet.
