Hi DF!

Mich interessiert, welche Sprachen ihr benutzt, da ich mit meinem Repertoire momentan nicht glücklich bin, und zwar aus verschiedenen Gründen:

PASCAL: naja, das klärt sich ja von selbst...
Delphi: eigentlich recht schick, aber ich will mich nicht an etwas binden, das nur kostenpflichtig Updates erhält. Schnell, schicke Bibliothek. Trotzdem eine Sprache, in der man meiner Meinung am produktivsten ist.
C++: eigentlich meine Traumsprache => schnell, kostenlos, nativ, multiplattform, man darf wählen zwischen großer Bibliothek (Qt) oder kleiner Bibliothek (STL), ABER: Ich für meinen Teil bin in der Sprache nicht produktiv. Nicht, dass die Sprache so schwer wäre (das ist Haskell), liegt mein LOC-Schnitt trotzdem nur bei ca. 100/Minute, was ich als sehr langsam empfinde). Was mich an C++ wirklich stört, ist, dass man jede Zeile 2 oder 3-mal durchdenken muss, damit sie einem nicht im Gesicht explodiert, und wenn sie es dann doch tut, findet man den Fehler schwer. Ich weiß nicht, ob das mit der Erfahrung weggeht, deswegen würde mich hier mal interessieren, ob eure LOC-Zahl in eurer Programmiererlaufbahn mit C++ gewachsen ist und wie ihr programmiert (einfach drauflos, durchgeplant, XP...)
Java: kostenlos, gigantische Bibliothek und multiplattform, ABER: die Sprache an sich und ihre Verhaltensweisen (siehe Seite 100 hiervon, der Rest ist auch wahr) missfallen mir sehr: keine Pointer, Interfaces für jeden Kram (=>Event-Listener, hier wären Pointer doch einfach wunderbar, oder wenigstens delegates wie in C#), Klassenzwang, Code ist einfach reverse zu engineeren (oder so), kein nativer Code (=> langsam) etc.
C#: gefällt mir viel besser als Java (bei ähnlicher Bibliothek), aber leider gibt es das nur für Windows... Wie gut der Mono-Support ist, weiß ich nicht, aber auch zu dieser Sprache greife ich ungern.


Haskell ist sicherlich auch interessant, aber ich muss da ehrlich zugeben, dass ich das funktionale Programmieren noch nicht durchschaut habe.

Obwohl ich weiß, dass es eine solche Sprache nicht gibt, meine Wunschsprache sieht so aus:

-pfeilschnell wie C++ (kein Muss)
-eine Bibliothek wie Java, C# oder Delphi
-einfach wie Delphi oder C#, kein einfacher Fehlereinbau wie in C++.
-kein Klassenzwang, trotzdem sollte man Klassen schreiben dürfen, wenn man es will.
-Pointer (zumindest delegates)
-möglichst kostenfrei
-multiplattform (eigentlich der wichtigste Punkt)

Gibt es wenigstens eine Sprache, die dem nahe kommt?


Ihr dürft mich gerne wegen den Sachen, die ich beschrieben habe, zerreißen, mehr als Diskussionen suche ich aber Antworten auf meine Fragen!

Viele Grüße,

Mitmischer

Schreib sie dir doch selbst Was du völlig unter den Tisch fallen lässt: Oberflächengestaltung oder sogar ansprechende Oberflächengestaltung (um QT mal auszuschließen).

Ich habe mir, wie viele andere in diesem Forum sicherlich auch, Gedanken dazu gemacht. Vorweg: es gibt sie nicht. Zwei Gedanken dazu: Um die Multiplattform-Fähigkeit zu gewährleisten, brauchst du Virtualisierung. Damit erschwerst du dir aber eine performante Ausführung. Wenn du mit Bibliotheken programmierst, dann produzieren diese in Kombination mit deiner Anwendung wieder mehr Fehler.
Eine (Skript-)Sprache, die funktionieren könnte: JavaScript mit HTML. Letztendlich immer noch ein guter Kompromiss, um alle Bedürfnisse abzudecken. Zudem kommt noch die relativ gute Umsetzung von Austauschformaten wie JSON und XML.

Letztendlich gibt es nicht die perfekte Sprache. Allerding gibt es die perfekte Sprache für ein Problem.

Zitat:

liegt mein LOC-Schnitt trotzdem nur bei ca. 100/Minute

Na klar. 90% der Leute die sich Softwareentwickler nennen schaffen nicht mal 100 Tastenanschläge/Minute beim Code abschreiben (Fehlerfrei schon gar nicht). Aber du machst 100 Zeilen frisch ausgedachten Code pro Minute und meinst du bist langsam? Respekt.

Zitat:

Schreib sie dir doch selbst

Bei seiner Leistungsfähigkeit fragst du in ca. 3h nochmal nach dann sollte er fertig sein Morgen früh gibst dann auch die äquivalente Bibliothek ala VCL bzw. BCL für die relevanten Plattformen dazu.


Nicht die eine Sprache macht es sondern die Kombination der Sprachen passend zu den zu lösenden Problemen (Systemnahe Programmierung, OS-nahe Programmierung, UI, Numbercrunshing, Businesslogik oder was auch immer bzw. für wenn wird programmiert - zum eigenen Vergnügen, Inhouse Applikation, Shrink Wrapped Software etc.). Je nach Problem ist die Antwort eine andere. Je nachdem was du tust sollten eventuell alle 4 Sprachen (und ein paar andere) zu deinem Toolset gehören. Und die Anzahl LOCs die man mit denen jeweils schafft ist eigentlich total irrelevant. Softwareentwicklung ist mehr als Code abzusondern. Ab einem bestimmten Punkt im Entwicklungszyklus ist der bei mir sowieso oft negativ. Deswegen ist die benutzte Programmiersprache noch lange nicht schlecht oder ich bin ein schlechter Programmierer.

Hallo Mitmischer,

Mitmischer 1703 hat folgendes geschrieben :

Ich für meinen Teil bin in der Sprache nicht produktiv. ... liegt mein LOC-Schnitt trotzdem nur bei ca. 100/Minute, was ich als sehr langsam empfinde

Langsam bekomme ich hier im Forum akute Minderwertigkeitskomplexe. Außer, dass ich eine Menge Themen gar nicht verstehe, schaffe ich an "guten" Tagen nicht mal 100 LOC je Tag(!); normalerweise weniger als 50! D.h., ich bin mindestens 2500 mal langsamer als Du.
Ich werde mich wohl zurückziehen müssen!
Beste Grüße
Mathematiker

Also, angelsächsisch und dann auch noch abgekürzt (Akronym), das geht gar nicht. Verstehe nicht, warum nicht dort Deutsch verwendet wird, wo es möglich ist. Nichts geht über die eigene Muttersprache, auch bei Anglophilie. Erst dem Kontexte dieser Diskussion konnte ich den ominösen drei Buchstaben ihr Geheimnis entreißen: LOC ist keine orthographisch verunglückte gleisgebundene Zugmaschine, sondern anscheinend "lines of code" (warum nicht einfach Quelltextzeilen??).

Bezieht man die vielen Korrekturen und Änderungen ein, so kommt - das las ich mal irgendwo - selbst ein professioneller Programmierer nicht mehr als auf einige Quellcodezeilen pro Tag (!), so in der Größenordnung von einem Dutzend, vielleicht 15 oder auch 20 (je nachdem, wie komprimiert man schreibt). Wenn ich bei meinen bescheidenen Amateurprojekte, in denen ich seit einigen wenigen Jahren "rummache", die Anzahl der Zeilen ins Verhältnis zur vermuteten Bearbeitungsszeit (im Bereiche einiger hundert Stunden sicherlich) setze.....

Mit der Tippgeschwindigkeit hat das übrigens relativ wenig zu tun, als "Tippse" ist man nur anfänglich marginal im Vorteil und gerät ohne Informatikprofessionalität durch das viele Lesen in den Foren, MSDN & Co. schnell ins Hintertreffen; zudem ist der eigene Quelltext auch danach oft nicht optimal.

Zitat:

LOC-Schnitt trotzdem nur bei ca. 100/Minute

sicher daß da nicht irgendwelche Einheiten durcheinander geraten sind?

Nachdem jetzt genug über die Einheiten gerätselt wurde , würde ich gerne deine Argumente hinterfragen. Natürlich wird C++ gerne hinterher gesagt, dass es die ideale Sprache für Fußverletzungen sei, aber wo genau siehst du die versteckte Komplexität? In zu wenig Abstraktion von der Hardware oder zu viel davon in einer Zeile (Meta-Programmierung, yay...)? Letzteren Punkt kann man kaum der Sprache oder Library ankreiden (die Abstraktionsstufe zu verringern ist fast immer möglich), bei Ersterem bekomme ich immer den Eindruck, die Leute programmieren eher C als C++11 .
Und warum du ungern zu C# greifst, hast du noch gar nicht erörtert.

Viele LOC bedeutet, dass die Sprache nicht produktiv ist, nicht umgekehrt.

In Delphi kann ich z.B. heute dank Generics extrem Code sparen gegenüber älteren Delphiversionen. Dann schreibe ich nur noch zwei Zeilen statt 40 in älteren Versionen. Das geht natürlich viel schneller. Und in C# mit LINQ kann man auch Sachen in einer Zeile verschlüsseln, die in Delphi 20 oder mehr brauchen (hinterher verstehen tun es allerdings viele nicht, deshalb "verschlüsseln" ).

Jedenfalls kommt beim Entwickeln ja zusätzlich noch die Prüfung des Codes beim Einchecken usw. dazu. Auch bei kleineren privaten Projekten mache ich das mittlerweile. Dank Version Insight geht auch das in Delphi mittlerweile sehr gut.

Zu deinen Wunschpunkten:
Eigentlich erfüllt C# die doch alle, oder? Klar, Klassen werden immer benutzt, auch wenn du nur in der main-Methode arbeitest, aber das ist heutzutage eigentlich meistens so und auch sinnvoll. Für Plattformunabhängigkeit gibt es ja Mono.

Dann gibt es noch Lazarus, das zwar nicht viel kann, aber dafür kostenlos und plattformunabhängig ist. Das kann ich zwar nicht guten Gewissens empfehlen, aber es wäre eine Möglichkeit.

Und generell musst du dich entscheiden was dir wichtiger ist: kostenlos oder wirklich gut, beides zusammen ist eigentlich immer ein Kompromiss

Mitmischer 1703 hat folgendes geschrieben :

Ich weiß nicht, ob das mit der Erfahrung weggeht, deswegen würde mich hier mal interessieren, ob eure LOC-Zahl in eurer Programmiererlaufbahn mit C++ gewachsen ist und wie ihr programmiert (einfach drauflos, durchgeplant, XP...)

Insgesamt ist sie eher gesunken, da ich nichtmehr wie früher Copy&Paste mache.

Mit C++ selbst stehe ich auf Kriegsfuß (leider werde ich dazu gezwungen es zu nutzen ). Mal davon abgesehen, dass ich jedes mal ewig brauche bis ich Compiler, Linker, Debugger und IDE soweit besänftigt habe, dass sie sich nichtmehr gegenseitig umbringen wollen, kommen noch viele (meiner Meinung nach Bugs) dazu:


und schon haben wir eine sehr hübsche "endlos"-Schleife produziert. (Tipp: s.length() ist cardinal, was natürlich nicht angezeigt wird, weil der typ kryptisch als size_type umgenannt wurde).

Pfeilschnell ist auch so eine Sache. z.B. habe ich Delphi-Code nach C++ portiert (Qt Creator + MinGW)...naja, und das läuft langsamer als der Delphi-Code (liegt wohl am Compiler).

Ich programmiere jetzt in Delphi und konvertiere es dann, wenn der Code fertig ist. Das ist für mich sehr viel produktiver als komplizierte Algorithmen in C++ direkt zu programmieren. Genau wie du sagst, in C++ Fehler suchen ist die Hölle Hab mir mal Delphi2Cpp angeschaut, das hilft beim konvertieren. Aufgrund des Preises muss man sich leider mit der Demo zufrieden geben.

Mitmischer 1703 hat folgendes geschrieben :

Delphi: eigentlich recht schick, aber ich will mich nicht an etwas binden, das nur kostenpflichtig Updates erhält.

Da würde ich lieber mit Lazarus arbeiten als dass ich auf C++ ausweiche

Was ist mit Python?

Xion hat folgendes geschrieben :

(Tipp: s.length() ist cardinal, was natürlich nicht angezeigt wird, weil der typ kryptisch als size_type umgenannt wurde).

Diesen (teilweise) Unfug, daß aus Typen einfach redundanterweise neue Typen generiert, eher nur benannt werden, ohne etwas substantiell neues zu (er)schaffen, gibt es aber auch in Delphi(-Quelltexten), auch den originalen, die vom Hersteller mitgeleifert werden.

Zitat:

Was ist mit Python?

Ist auch eine nette Sprache. Aber solange Mitmischer nicht mitmischt und uns keinerlei Hinweis gibt welche Art von Problemen er lösen möchte werden wir locker mehrere Dutzend Sprachen zusammenbekommen die für irgendein Aufgabengebiet die geeignetste wäre.

Ralf Jansen hat folgendes geschrieben :

Aber solange Mitmischer nicht mitmischt und uns keinerlei Hinweis gibt welche Art von Problemen er lösen möchte werden wir locker mehrere Dutzend Sprachen zusammenbekommen die für irgendein Aufgabengebiet die geeignetste wäre.

Logo und Turbo-Pascal 6.0 zum Zeichnen der Peano-, Drachen-, Hilbert-, Koch- und Gosperkurve sowie weiterer solcher fraktaler, "flächenfüllender" Kurven.

Mitmischer 1703 hat folgendes geschrieben :

Hi DF! Java: kostenlos, gigantische Bibliothek und multiplattform, ABER: die Sprache an sich und ihre Verhaltensweisen (siehe Seite 100 hiervon, der Rest ist auch wahr) missfallen mir sehr: keine Pointer, Interfaces für jeden Kram (=>Event-Listener, hier wären Pointer doch einfach wunderbar, oder wenigstens delegates wie in C#), Klassenzwang, Code ist einfach reverse zu engineeren (oder so), kein nativer Code (=> langsam) etc. C#: gefällt mir viel besser als Java (bei ähnlicher Bibliothek), aber leider gibt es das nur für Windows... Wie gut der Mono-Support ist, weiß ich nicht, aber auch zu dieser Sprache greife ich ungern.

Vermutlich wird die nahe Zukunft auch bei uns mehr C# und weniger Java bringen (dennoch sind die aktuellen Projekte weiterhin in Java), was ich persönlich auch begrüße.
Jedoch muss man auch das (nach dem beliebten "Microsoft-bashing" zweitbeliebteste) "Java-bashing" kritisch hinterfragen. Bei dem Autor in dem Link fällt mir auf, dass er zwar
zu denjenigen gehört, die immer die allerneusten Features nutzen und ausreizen, dann aber bei den Basics schwächeln. Ich meine, auf Seite 100 vergleicht er Objekte mit dem "==" Operator
und wundert sich über das komische Ergebnis. Schon in einem Java-Anfängerkurs lernt man z.B. String Objekte mit equals(...) zu vergleichen anstelle von ==.
Bei Integer Objekten ist es ebenso. Meine IDE gibt da sogar eine Warnung aus, wenn ich versuche, zwei Integer-Objekte mit == zu vergleichen.
Das ist so, wie wenn jemand Wurzeln ziehen kann, aber Probleme mit den Grundrechenarten hat.

Pointer sind auch nur Mittel zum Zweck. Frage: was könntest du in einem Java mit Pointern machen, was du derzeit nicht kannst?
Geht es dabei nur um die Sache, weniger Code schreiben zu müssen? (Gerade bei jemandem, der ja sehr schnell zu schreiben scheint, ist dieses Argument eher etwas verwunderlich)
Es ist mir oft aufgefallen, dass Leute, die mehr als ich von Java verstehen, diesem Argument stets sehr skeptisch gegenüberstehen.
Weniger Code heisst nicht unbedingt besser.

Klassenzwang: nunja, Delphi ist da ja nicht so streng, Java mag halt keine "freischwebenden" Methoden, die einfach irgendwo abhängen.
Ist das wieder der Nachteil, mehr tippen zu müssen?

Reverse Engineering: Problem hatte ich in der Praxis noch nie.

langsam: das ist ja der klassische Vorwurf, der aber auch sehr stark differenziert werden sollte. Eine Sprache an sich hat keinerlei Geschwindigkeit,
die erstellten Programme haben für bestimmte Aktionen natürlich entsprechende Geschwindigkeiten (die wiederum nur zu einem Teil mit der Sprache selbst zusammenhängen).
Also muss spezifiziert werden, welche Aktion genau langsam ist. Natürlich braucht man eine VM, aber so etwas bräuchte man für C# auch, wenn man dort ähnliche Plattformunabhängigkeit
wie bei Java herstellen will. Wenn man übrigens mathematische Algorithmen schreibt, ist Java m. E. keineswegs langsam.

Über JNI kann man schon native Sachen benutzen, wenn man denn will.

Aber mir gefällt C# auch, sicher. Natürlich hat auch Java seine Nachteile, das gebe ich zu (wer z.B. Swing entwickelt hat, hätte sich mal besser die entsprechenden Sachen in Delphi anschauen sollen) (diese jedoch waren z.T. der Preis für die auch unbestreitbaren Vorteile) Eine Sprache, die nur Vorteile hat und keine Nachteile, scheint es wohl nicht zu geben.

freundliche Grüße
Olli

C++11: C++11 definiert sehr viele gute und sehr nützliche Mechanismen, die die Produktivität wesentlich erhöht haben. C++ hat dabei neben der Geschwindigkeit noch den großen Vorteil, dass die Community und die vorhandene Infrastruktur recht groß ist. Die Template-Engine erlaubt einem extrem effizient Code zu schreiben, man denke nur mal an Boost oder die STL. C++ erlaubt es einem Programme auf einem sehr hohen Niveau zu schreiben und zusätzlich noch mit einer atemberaubenden Geschwindigkeit im Vergleich zu vielen anderen Sprachen zu versehen. C++11 ist aus meiner Sicht für Anfänger schon relativ komplex, allgemein denke ich, dass C++ leider nicht die einfachste Sprache ist. Aktuelle Neuerungen wie constexpr, variadic templates und die neue STL machen C++ für viele Anwendungsfälle in meinem Fall zur ersten Wahl.

C++ in der realen Welt: Meine Erfahrungen mit C++ im professionellem Umfeld sind eher schlecht. Die Fähigkeiten eines normalen C++-Entwicklers sind leider eher schlecht als recht, was neben hoher Fehleranfälligkeit auch zur erschwerter Wartbarkeit führt.

Meine Empfehlung: Wenn C++, dann richtig. Desweiteren ist es für 80% der Entwickler ziemlich irrelevant, wie schnell eine spezifische Sprache in der Ausführung ist. Wichtig ist die Produktivität, die mit dieser Sprache erreicht werden kann. Die Geschwindigkeit von C++ braucht man vielleicht in der Echtzeitgrafik, dem Compilerbau oder allgemein in der Computergraphik, sowie Datenbanken oder anderen hoch-komplexen Systemen. Allerdings sehe ich keinen Grund, normale Applikationen noch in C++ zu schreiben.

C#: Sehr angenehme und moderne Sprache. Würde ich jederzeit Java vorziehen.

Produktivität kann man nicht in LOC/h messen, weil Produktivität viel zu komplex ist, um nur von einem simplen Wert beschrieben zu werden. Meiner Meinung nach definiert sich die Produktivität eines Entwicklers aus einem Zusammenspiel an Tools, Semantik und Syntax der genutzten Sprache, sowie Erfahrung des Entwicklers. Ich bin mit C++ aktuell am produktivsten, obwohl die Sprache bei weitem nicht die produktivste Sprache darstellt. C# halte ich für eine sehr produktive Sprache, allerdings bin ich mit C# nicht ansatzweise so schnell wie mit C++, einfach weil ich über die Jahre viel C++ praktiziert habe. Bei der Wahl einer geeigneten Programmiersprache für ein spezielles Projekt gehe ich meist so vor:

1. Welche Anforderungen habe ich an eine Sprache?
2. Welche Sprache, die ich einigermaßen beherrsche, bietet mir alle gewünschten Features?
3. Bietet die spezielle Sprache die entsprechenden Bibliotheken und Tools?
4. Macht die Sprache Spaß?
5. Ist die Sprache nicht Visual Basic?

Diese grundlegende Methodik hilft einem etwas bei der Auswahl. Allerdings gehe ich bei dieser Methode immer von bereits bekannten Sprachen aus.

Wenn du meinst, dass du nicht besonders produktiv mit einer Sprache bist, dann fehlt dir eventuell einfach noch die Praxis, welches sich aber mit der Zeit ergibt. Wenn du unbedingt noch weitere Sprachen ausprobieren möchtest, würde ich dir Groovy, Haskell oder D empfehlen. Wobei D einfach klein ist und keine große Community hat.

Zitat:

und schon haben wir eine sehr hübsche "endlos"-Schleife produziert. (Tipp: s.length() ist cardinal, was natürlich nicht angezeigt wird, weil der typ kryptisch als size_type umgenannt wurde).

Das was du hier als kryptisch bezeichnest, ist ein sehr grundlegendes und wichtiges Element von C++ bzw. der STL. Der size_type( meist ein size_t ) ist grundlegend für Erweiterbarkeit und Flexibilität.
Siehe hier:



Das steht in der Definition von basic_string und typedeft alle Typen, die die basic_string Klasse braucht. Die eigentlichen Typen werden dabei nicht in basic_string definiert, sondern im Allocator(_CharT_alloc_type). Das hat den Sinn, dass du je nach Allocator eventuell andere Basistypen definieren willst. Die ganze STL baut auf diesem Prinzip auf, nur sehr selten werden in den High-Level Classes wirklich die Typen direkt definiert. Aber das ganze dient eh der Erweiterbarkeit.

Zur Portierung: Dann hast du da bei der Portierung was falsch gemacht. Der GCC ist pfeilschnell.

Nachtrag: Für Schleifen über Strings und andere Container bieten sich immer Iteratoren an.

Zitat:

Meine Empfehlung: Wenn C++, dann richtig.

Rhetorische Preisfrage: Wie springt man den von Anfänger nach 'dann richtig' ohne den ganzen Mist dazwischen zu produzieren den irgendwer (im besten Fall nur man selbst) ertragen muss?

Rhetorische Preisantwort: Ich bezog mich da noch auf die professionelle Anwendung von C++ und nicht auf Hobbyisten. Das man C++ auch irgendwie lernen muss, ist ja klar.

Zitat:

Ich bezog mich da noch auf die professionelle Anwendung

Macht keinen Unterschied. Die meisten lernen 'on the job' (wenn wir uns auf das professionell Attribut konzentrieren). Eigentlich kenne ich niemand der professionelle Softwareentwicklung außerhalb eines konkreten Jobs/Projektes gelernt hat. Bezweifle sogar das das möglich ist.

Hallo,

vorab erstmal vielen Dank für eure Antworten. Ich muss mich korrigieren, natürlich meine 100 LOC/Stunde und nicht pro Minute. Ich wollte damit niemanden verwirren .

Ich bin zwischendurch mit den Zitaten durcheinander gekommen, ich hoffe, es haben sich keine Fehler eingeschlichen.

Regan hat folgendes geschrieben :

Schreib sie dir doch selbst Was du völlig unter den Tisch fallen lässt: Oberflächengestaltung oder sogar ansprechende Oberflächengestaltung (um QT mal auszuschließen).

Da stimme ich dir zu, Delphi's Art und Weise, Forms zu erstellen, finde ich da deutlich angenehmer (ich sage nur: anchors). Die Resultate sind jedoch bei Qt fast immer die schöneren (meine Meinung).

Regan hat folgendes geschrieben :

Ich habe mir, wie viele andere in diesem Forum sicherlich auch, Gedanken dazu gemacht. Vorweg: es gibt sie nicht. Zwei Gedanken dazu: Um die Multiplattform-Fähigkeit zu gewährleisten, brauchst du Virtualisierung. Damit erschwerst du dir aber eine performante Ausführung.

Hmm, aber C++ scheint den Spagat ja hinzubekommen, und das schneller als jede andere Multiplattform-Sprache. Mir geht es wohlgemerkt nicht um ein compile once, run everywhere, sondern um ein "can compile everywhere".

Regan hat folgendes geschrieben :

Wenn du mit Bibliotheken programmierst, dann produzieren diese in Kombination mit deiner Anwendung wieder mehr Fehler.

Gibt es da keine ausgereiften Bibliotheken? Sowohl Delphi als auch Qt und Java habe ich immer als sehr fehlerfrei empfunden.

Regan hat folgendes geschrieben :

Eine (Skript-)Sprache, die funktionieren könnte: JavaScript mit HTML. Letztendlich immer noch ein guter Kompromiss, um alle Bedürfnisse abzudecken. Zudem kommt noch die relativ gute Umsetzung von Austauschformaten wie JSON und XML.

Das hört sich ja sehr exotisch an!! Wie weit kann man denn mit dieser Kombination gehen?

Regan hat folgendes geschrieben :

Letztendlich gibt es nicht die perfekte Sprache. Allerding gibt es die perfekte Sprache für ein Problem.

Kannst du mir da mal einen Überblick geben? Welche Sprache fehlt mir da noch in meinem "Werkzeugkasten"?

Ralf Jansen hat folgendes geschrieben :

Ab einem bestimmten Punkt im Entwicklungszyklus ist der bei mir sowieso oft negativ.

Kannst du das mal genauer erläutern?

Delphi-Laie hat folgendes geschrieben :

Also, angelsächsisch und dann auch noch abgekürzt (Akronym), das geht gar nicht. Verstehe nicht, warum nicht dort Deutsch verwendet wird, wo es möglich ist. Nichts geht über die eigene Muttersprache, auch bei Anglophilie.

Wenn du so auf Muttersprache stehst, so verwende doch auch bitte hier eine deutsche Umschreibung. Wer ohne Sünde ist, der werfe den ersten Stein.

Delphi-Laie hat folgendes geschrieben :

Erst dem Kontexte dieser Diskussion konnte ich den ominösen drei Buchstaben ihr Geheimnis entreißen: LOC ist keine orthographisch verunglückte gleisgebundene Zugmaschine, sondern anscheinend "lines of code" (warum nicht einfach Quelltextzeilen??).

Jeder Softwareentwickler sollte diese ominösen drei Buchstaben auch kontextlos mit "Lines Of Code" assoziieren. Gerade weil Englisch die Sprache des Programmierens ist. In deinem Code tauchen ja auch keine Denglisch-Konstrukte wie cout << Eisenbahnschiene; auf, hoffe ich! Ich liebe die deutsche Sprache und verwende sie, wo möglich, aber nicht,wo das Englisch bequemer. Und ja, ich stehe dazu. Ich sage Laptop statt Klapprechner, Compiler statt Übersetzer, Computer statt Rechner, Chat statt elektronischer Telekommunikationsmöglichkeit, Linker statt Programmkomponentenschweißgerät.

Delphi-Laie hat folgendes geschrieben :

Bezieht man die vielen Korrekturen und Änderungen ein, so kommt - das las ich mal irgendwo - selbst ein professioneller Programmierer nicht mehr als auf einige Quellcodezeilen pro Tag (!), so in der Größenordnung von einem Dutzend, vielleicht 15 oder auch 20 (je nachdem, wie komprimiert man schreibt). Wenn ich bei meinen bescheidenen Amateurprojekte, in denen ich seit einigen wenigen Jahren "rummache", die Anzahl der Zeilen ins Verhältnis zur vermuteten Bearbeitungsszeit (im Bereiche einiger hundert Stunden sicherlich) setze.....

Danke, das war mir nicht bewusst.

Kha hat folgendes geschrieben :

Nachdem jetzt genug über die Einheiten gerätselt wurde , würde ich gerne deine Argumente hinterfragen. Natürlich wird C++ gerne hinterher gesagt, dass es die ideale Sprache für Fußverletzungen sei, aber wo genau siehst du die versteckte Komplexität?

Komplexität will ich gar nicht gesagt haben (ich halte es für ein Gerücht, dass C++ schwer oder komplex sei), aber warum um Gottes Willen erlaubt C++ zum Beispiel so was:



Konstrukte wie...

..., also mit zugewiesener Variable, finde ich super und verwende ich auch oft, das erste Beispiel wird mittlerweile glaube ich sogar verwarnt, trotzdem ärgerlich, wenn solch ein dummer Fehler Zeit raubt und sich kaum finden lässt.

Kha hat folgendes geschrieben :

In zu wenig Abstraktion von der Hardware oder zu viel davon in einer Zeile (Meta-Programmierung, yay...)? Letzteren Punkt kann man kaum der Sprache oder Library ankreiden (die Abstraktionsstufe zu verringern ist fast immer möglich), bei Ersterem bekomme ich immer den Eindruck, die Leute programmieren eher C als C++11 .

C++11 ist toll, C++ allgemein ist toll! Aber ich komme nicht so gut mit der Sprache aus.

Kha hat folgendes geschrieben :

Und warum du ungern zu C# greifst, hast du noch gar nicht erörtert.

Für C# glit ähnliches wie für Delphi: Ich habe die Sprache gern und schreibe auch gern Code mit ihr (vor allem LINQ hat es mit angetan), aber ich muss unter Windows für Windows entwickeln - und auf meinem Laptop, auf dem ich überwiegend programmiere, läuft ein fröhlich auf Windows pfeifendes Ubuntu, sodass das Entwickeln mit C# hier unmöglich ist.

jaenicke hat folgendes geschrieben :

Viele LOC bedeutet, dass die Sprache nicht produktiv ist, nicht umgekehrt.

Hmm... aber wenn ich in Delphi mit 100 LOC 3 Funktionen implementiere, in C++ analog mit 20 LOC in gleicher Zeit nur eine Funktion, spräche das ja auch für C++ als produktiverer Sprache!

jaenicke hat folgendes geschrieben :

Jedenfalls kommt beim Entwickeln ja zusätzlich noch die Prüfung des Codes beim Einchecken usw. dazu. Auch bei kleineren privaten Projekten mache ich das mittlerweile. Dank Version Insight geht auch das in Delphi mittlerweile sehr gut.

Das hört sich ja interessant an. Ist das eine Art lokales Versionierungssystem?
skype

jaenicke hat folgendes geschrieben :

Zu deinen Wunschpunkten: Eigentlich erfüllt C# die doch alle, oder? Klar, Klassen werden immer benutzt, auch wenn du nur in der main-Methode arbeitest, aber das ist heutzutage eigentlich meistens so und auch sinnvoll.

Manchmal ist es aber wirklich zu viele, bei manchen Klassenstrukturen bekomme ich wirklich die Krise, weil überspitzt gesagt alle fünf Zeilen an zusammenhängenden Code natürlich sofort in eine eigene Klasse ausgelagert werden.

jaenicke hat folgendes geschrieben :

Für Plattformunabhängigkeit gibt es ja Mono. Aber Mono hängt doch deutlich hinterher und ist ja auch nur eine Behelfslösung.

jaenicke hat folgendes geschrieben :

Und generell musst du dich entscheiden was dir wichtiger ist: kostenlos oder wirklich gut, beides zusammen ist eigentlich immer ein Kompromiss

Hmm...das ist schade.

Xion hat folgendes geschrieben :

Mit C++ selbst stehe ich auf Kriegsfuß (leider werde ich dazu gezwungen es zu nutzen ). Mal davon abgesehen, dass ich jedes mal ewig brauche bis ich Compiler, Linker, Debugger und IDE soweit besänftigt habe, dass sie sich nichtmehr gegenseitig umbringen wollen,

Genau das meine ich

Xion hat folgendes geschrieben :

, kommen noch viele (meiner Meinung nach Bugs) dazu: markieren Quelltext     1: 2: 3: 4: std::string s=""; int pos=0; while (pos<s.length()-1)   pos++; und schon haben wir eine sehr hübsche "endlos"-Schleife produziert. (Tipp: s.length() ist cardinal, was natürlich nicht angezeigt wird, weil der typ kryptisch als size_type umgenannt wurde).

Hmm, ich bin recht sicher, dass ich ähnlichen Code schon verwendet habe und dieser fehlerfrei funktioniert hat.

baka0815 hat folgendes geschrieben :

Was ist mit [url=python.org/]Python[/url]?

Schau ich mir mal an

Ralf Jansen hat folgendes geschrieben :

Aber solange Mitmischer nicht mitmischt und uns keinerlei Hinweis gibt welche Art von Problemen er lösen möchte werden wir locker mehrere Dutzend Sprachen zusammenbekommen die für irgendein Aufgabengebiet die geeignetste wäre.

Allerlei Art von Problem! Es war wahrscheinlich naiv von mir, nach der perfekten Sprache zu fragen, die Frage nach dem perfekten Werkzeugkasten wäre wohl optimaler gewesen.

Oliver Maas hat folgendes geschrieben :

Mitmischer 1703 hat folgendes geschrieben : Hi DF! Java: kostenlos, gigantische Bibliothek und multiplattform, ABER: die Sprache an sich und ihre Verhaltensweisen (siehe Seite 100 hiervon, der Rest ist auch wahr) missfallen mir sehr: keine Pointer, Interfaces für jeden Kram (=>Event-Listener, hier wären Pointer doch einfach wunderbar, oder wenigstens delegates wie in C#), Klassenzwang, Code ist einfach reverse zu engineeren (oder so), kein nativer Code (=> langsam) etc. C#: gefällt mir viel besser als Java (bei ähnlicher Bibliothek), aber leider gibt es das nur für Windows... Wie gut der Mono-Support ist, weiß ich nicht, aber auch zu dieser Sprache greife ich ungern. Vermutlich wird die nahe Zukunft auch bei uns mehr C# und weniger Java bringen (dennoch sind die aktuellen Projekte weiterhin in Java), was ich persönlich auch begrüße. Jedoch muss man auch das (nach dem beliebten "Microsoft-bashing" zweitbeliebteste) "Java-bashing" kritisch hinterfragen. Bei dem Autor in dem Link fällt mir auf, dass er zwar zu denjenigen gehört, die immer die allerneusten Features nutzen und ausreizen, dann aber bei den Basics schwächeln. Ich meine, auf Seite 100 vergleicht er Objekte mit dem "==" Operator und wundert sich über das komische Ergebnis. Schon in einem Java-Anfängerkurs lernt man z.B. String Objekte mit equals(...) zu vergleichen anstelle von ==.

Du magst da ja Recht haben, aber das ist anders als intuitiv. Da gefällt mir C+ doch deutlich besser, wo durch die Deklaration festgelegt wird, ob ein (foo == bar) genügt oder ein (*foo == *bar) her muss.

Oliver Maas hat folgendes geschrieben :

Pointer sind auch nur Mittel zum Zweck. Frage: was könntest du in einem Java mit Pointern machen, was du derzeit nicht kannst?

Das Hauptargument ist natürlich die deutlich höhere Geschwindigkeit. Auch die gemeinsame Objektnutzung über shared_ptr finde ich sehr angenehm. Ich will mich da aber nicht aus dem Fenster lehnen, da ich Java's Rückgabetyp-Behandlung nicht kenne.

Oliver Maas hat folgendes geschrieben :

Klassenzwang: nunja, Delphi ist da ja nicht so streng, Java mag halt keine "freischwebenden" Methoden, die einfach irgendwo abhängen. Ist das wieder der Nachteil, mehr tippen zu müssen?

Nein, es ist einfach unnötig. Wenn ich statische Hilfsfunktionen, die keine Member verwenden (wie seperate struct-Initializierer) habe, brauchen die keine Klasse. Punkt. Und da will ich keinen Overhead haben! Klassen bedeuten ja auch immer höheren Ressourcenanspruch und geringere Performance. Ein Namespace wie in C++ wirkt syntaktisch ähnlich und ist doch der bessere Ansatz, wenn ich die coolen Features einer Klasse nicht benötige.

Oliver Maas hat folgendes geschrieben :

Reverse Engineering: Problem hatte ich in der Praxis noch nie.

Es wird ja auch niemand auf dich zugehen und dir beichten, dass er deinen Code hat .

Oliver Maas hat folgendes geschrieben :

langsam: das ist ja der klassische Vorwurf, der aber auch sehr stark differenziert werden sollte. Eine Sprache an sich hat keinerlei Geschwindigkeit, die erstellten Programme haben für bestimmte Aktionen natürlich entsprechende Geschwindigkeiten (die wiederum nur zu einem Teil mit der Sprache selbst zusammenhängen). Also muss spezifiziert werden, welche Aktion genau langsam ist. Natürlich braucht man eine VM, aber so etwas bräuchte man für C# auch, wenn man dort ähnliche Plattformunabhängigkeit wie bei Java herstellen will. Wenn man übrigens mathematische Algorithmen schreibt, ist Java m. E. keineswegs langsam.

Diese Meinung teile ich leider überhaupt nicht. Java-GUIs sind lahm (was mir in der letzten Mathe-Klausur zum Verhängnis geworden ist) und mathematische Algorithmen in Java sind auch lahm. Iterieren über Container eine Qual!

Oliver Maas hat folgendes geschrieben :

Über JNI kann man schon native Sachen benutzen, wenn man denn will. Aber mir gefällt C# auch, sicher. Natürlich hat auch Java seine Nachteile, das gebe ich zu (wer z.B. Swing entwickelt hat, hätte sich mal besser die entsprechenden Sachen in Delphi anschauen sollen) (diese jedoch waren z.T. der Preis für die auch unbestreitbaren Vorteile) Eine Sprache, die nur Vorteile hat und keine Nachteile, scheint es wohl nicht zu geben.

Java hat Vorteile, das kann man nicht leugnen

j.klugmann hat folgendes geschrieben :

C++11: C++11 definiert sehr viele gute und sehr nützliche Mechanismen, die die Produktivität wesentlich erhöht haben. C++ hat dabei neben der Geschwindigkeit noch den großen Vorteil, dass die Community und die vorhandene Infrastruktur recht groß ist. Die Template-Engine erlaubt einem extrem effizient Code zu schreiben, man denke nur mal an Boost oder die STL. C++ erlaubt es einem Programme auf einem sehr hohen Niveau zu schreiben und zusätzlich noch mit einer atemberaubenden Geschwindigkeit im Vergleich zu vielen anderen Sprachen zu versehen. C++11 ist aus meiner Sicht für Anfänger schon relativ komplex, allgemein denke ich, dass C++ leider nicht die einfachste Sprache ist. Aktuelle Neuerungen wie constexpr, variadic templates und die neue STL machen C++ für viele Anwendungsfälle in meinem Fall zur ersten Wahl.

Dass ich das von dir höre, hätte ich ja nie zu träumen gewagt! Ich finde auch, dass mit C++11 große Schritte nach vorne gemacht wurden, aber eine STL zur GUI-Erstellung vermisse ich immer noch (Qt ist ein akzeptabler Ersatz).

j.klugmann hat folgendes geschrieben :

C++ in der realen Welt: Meine Erfahrungen mit C++ im professionellem Umfeld sind eher schlecht. Die Fähigkeiten eines normalen C++-Entwicklers sind leider eher schlecht als recht, was neben hoher Fehleranfälligkeit auch zur erschwerter Wartbarkeit führt.

D.h. in der realen Welt wird C mit C++-Compiler geschrieben?

j.klugmann hat folgendes geschrieben :

Meine Empfehlung: Wenn C++, dann richtig. Desweiteren ist es für 80% der Entwickler ziemlich irrelevant, wie schnell eine spezifische Sprache in der Ausführung ist. Wichtig ist die Produktivität, die mit dieser Sprache erreicht werden kann. Die Geschwindigkeit von C++ braucht man vielleicht in der Echtzeitgrafik, dem Compilerbau oder allgemein in der Computergraphik, sowie Datenbanken oder anderen hoch-komplexen Systemen. Allerdings sehe ich keinen Grund, normale Applikationen noch in C++ zu schreiben.

Welche Sprachen nimmst du (außer Haskell )?

j.klugmann hat folgendes geschrieben :

5. Ist die Sprache nicht Visual Basic?

j.klugmann hat folgendes geschrieben :

Diese grundlegende Methodik hilft einem etwas bei der Auswahl. Allerdings gehe ich bei dieser Methode immer von bereits bekannten Sprachen aus. Wenn du meinst, dass du nicht besonders produktiv mit einer Sprache bist, dann fehlt dir eventuell einfach noch die Praxis, welches sich aber mit der Zeit ergibt. Wenn du unbedingt noch weitere Sprachen ausprobieren möchtest, würde ich dir Groovy, Haskell oder D empfehlen. Wobei D einfach klein ist und keine große Community hat.

Dankeschön!