• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Keine moderne Sprache für Unix in Sicht?

hippodriver

Well-Known Member
Themenstarter #1
Oder auch: "Warum sind C und C++ immernoch die dominanten Sprachen im Unixumfeld?"

Auf meinen Streifzügen durch die Welt der Programmiersprachen begegnete ich manchem Juwel. Aber für den praktischen Einsatz unter Unix gibt es immer Einschränkungen.

Da sind zunächst die klassischen Sprachen aus der C Familie: C, C++, Object C, D, Java und C#. C ist in keiner Weise modern. Alle anderen sind wiederkehrende Aufgüsse von "C mit Klassen". Absoluter Spitzenreiter in dieser Kategorie ist C#; der 2. Versuch einer Kopie einer ehemals abgespeckten (C++)-Kopie, die später dicker wurde als das Original.

Die Pascal-Reihe fand mit Ada ihr Ende. Nebenläufigkeit im Sprechkern und die beste Unterstützung für eigene Datentypen, die ich je gesehen habe, können über die Mängel nicht hinwegtäuschen. Die Lizenzsituation ist bestenfalls unübersichtlich. Die Standardbibliothek unfasst keine Schnittstellen nach außen: Netzwerk, XML, RPC, Datenbanken, GUI, ... Es gibt kaum freie, gewartete Bibliotheken von Drittherstellern.

Die Basic Familie -- lassen wir das.

Die populären Skriptsprachen, Perl, Python, Ruby und (Lua) haben eine umfangreiche Bibliothek und lassen sich interaktiv nutzen. Python ist schon super. Ihre Probleme sind immer die gleichen: Big Interpreter Locks --> kein echtes multithreading, langsame Programmausführung, keine (optionale) statische Typisierung.

Ansi Common Lisp ist eine herausragende Sprache. Es gibt mehrere gute, freie Implementierungen. Die Syntax ist extrem einfach, das Objektsystem CLOS mächtig und die Macros einzigartig. Meiner Meinung nach die perfekte Sprache. Nur das ganze Drumherum passt nicht. Die Standardbibliothek entspricht nicht mehr den modernen Anforderungen, vgl. Ada. Es gibt nur wenige gepflegte, externe Bibliotheken. Die Bibliotheken sind oft abhängig von der jeweiligen Implementierung. Die Dokumentation der Bibliothekn ist, vorsichtig ausgedrückt, unterirdisch. Neuere Abkömmlinge haben auch wieder Probleme: Clojure braucht die JVM von Java. NewLisp hat wieder per default dynamic scope.

Dylan mixt die Stärken von Lisp mit einer Infixnotation und einer modernen Standardbibliothek. Leider ist die Entwicklungsumgebung opendylan nur unter Windows vollständig zu gebrauchen. Unter Unix läuft die IDE nicht. Der Listener, in anderen Sprachen auch als REPL oder Toplevel bekannt, steht nicht zur Verfügung. Es gibt kein GUI binding. Die Entwicklung ist so gut wie tot.

OCaml ist, unter praktischen Gesichtspunkten, die beste der modernen Sprachen. Wenn da nicht der giant lock auf der Runtime wäre. Aber sonst ist es toll: Ein interaktives Toplevel, Compiler für Bytecode und für native code, viele Bibliotheken, bindings für GTK2 und OpenGL, schnelle Programmausführung (native code). Der bytecode debuger ist lustig, der kann sogar rückwärts laufen. Es wird sowohl funktionale, wie auch prozedurale Programmierung gut unterstützt. Das Objektsystem ist allerdings langweilig. Das tollste an der ganzen Sache ist das type inference. Damit hat man statische Typisierung ohne jedesmal die Typen explizit angeben zu müssen.


Und jetzt meine Wunschliste für die moderne Sprache auf Unixsystemen:

  • Garbage Collection
  • Multithreading
  • moderne, umfangreiche Standardbibliothek
  • einfaches FFI für C
  • statische Typisierung mit type inference
  • Echte Makros, wie bei Lisp, kein C Präprozessor Gegurke
  • Objektsystem aus Common Lisp
  • Interaktives Toplevel
  • native compiler
  • bindings für GUI und OpenGL
  • IDE mit Emacs key bindings
  • Vollständige Dokumentation
  • freie Lizenz, nicht viral

Also um es kurz zu machen: eine Kreuzung aus Lisp, OCaml und Python.

Sollte es sowas geben, bin ich für Vorschläge offen. So bedauerlich es ist, aber am nächsten kommt den Anforderungen vermutlich F# für .NET.
 

hippodriver

Well-Known Member
Themenstarter #5
DAS sind natürlich die Kriterien überhaupt. ... :huth:
Hast Du schonmal versucht einem Editor, der eine Editorkomponenete von Qt oder GTK oder scintilla verwendet, emacs keybindings beizubringen? Diese elenden Dinger unterstützen keine Mehrfachsequenztastenkombinationen. Am besten ist es natürlich, wenn es einen gut ausgebauten Emacs Mode gibt. so wie bei Lisp mit SLIME oder OCaml mit Tuareg.

Die OpenGL bindings sind bei den populären Entwicklungsumgebungen selbstverständlich. Wenn FFI nach C hinreichen einfach ist, kann man darauf vieleicht verzichten. Aber mit einem Garbage Collector auf der einen und C auf der anderen Seite, wird es nie einfach. Wer hat meinen Speicher geklaut?
 
#6
C ist halt gut.
  • portabel
  • einfach zu lernen
  • ohne Syntax-Balast
  • universell
  • geht einem nicht auf die Nerven

Na gut. Ich bin ein Befürworter von C. :)

Man kann aber echt schöne Sachen damit anstellen, wie man sieht. Ich kann Java mindestens genauso lange wie C. Diese Sprache erfüllt zum Beispiel keine der Kriterien, die ich oben aufgezählt habe. Trotzdem gibt es Verwendung dafür.
 

hippodriver

Well-Known Member
Themenstarter #7
Wenn man der Dokumentation glauben darf, gibt es kein richtiges Multithreading http://docs.plt-scheme.org/reference/eval-model.html#(part._thread-model):

1.1.13 Threads

Scheme supports multiple threads of evaluation. Threads run concurrently, in the sense that one thread can preempt another without its cooperation, but threads currently all run on the same processor (i.e., the same underlying OS process and thread).
Das Objektsystem verwendet message passing statt generic functions wie bei CLOS. Das ist schade. Zumindest ist die Dokumentation besser.
 

hippodriver

Well-Known Member
Themenstarter #8
Ich sprach von modernen Sprachen. C ist zwar ein ganz netter Makro-assembler, aber doch keine moderne Sprache.

Die Referenzimplementierung von D läuft doch garnicht unter FreeBSD. Mal davon abgesehen, daß D auch nur ein weiterer Versuch ist, C++ neu zu erfinden.

Ich hatte eher gehofft, daß jemand Erfahrung hat mit: Oz/Mozart, Erlang oder Haskell.
 

indy

Der Hutträger
#9
Haskell ist geil, sofern man nichts großes entwickeln muss.
Bei mehr als einer Person im Projekt skaliert diese Sprache nicht ;-)

Ansonsten: Programmieren ist doch eh von gestern, heute rockt MDSD!

Der UML-Indy
 
#10
Hast Du schonmal versucht einem Editor, der eine Editorkomponenete von Qt oder GTK oder scintilla verwendet, emacs keybindings beizubringen? Diese elenden Dinger unterstützen keine Mehrfachsequenztastenkombinationen. Am besten ist es natürlich, wenn es einen gut ausgebauten Emacs Mode gibt. so wie bei Lisp mit SLIME oder OCaml mit Tuareg.

Die OpenGL bindings sind bei den populären Entwicklungsumgebungen selbstverständlich. Wenn FFI nach C hinreichen einfach ist, kann man darauf vieleicht verzichten. Aber mit einem Garbage Collector auf der einen und C auf der anderen Seite, wird es nie einfach. Wer hat meinen Speicher geklaut?
Ach so, du meinst das auch noch ernst?!
 

hippodriver

Well-Known Member
Themenstarter #11
Ach so, du meinst das auch noch ernst?!
Bibliotheken und Entwicklungsumgebungen (in meinem Fall OpenGL und emacs) sind in der Praxis wichtiger als irgendwelche Sprachfeatures. Deshalb führen Java, C#, PHP und Perl in der Verbreitung. Die schlechtesten Sprachen haben sich damit durchgesetzt. Sun und Microsoft haben das Prinzip verstanden. Dort gibt es das Komplettpaket aus Bibliotheken, Compilern, Entwicklungsumgebungen und Dokumentation. Auch Trolltech/Nokia ist mit Qt auf dem Weg dort hin: Bibliothek, Dokumentation, QtCreator, g++ und MOC.

Eine tolle Sprache alleine bringt überhaupt nichts. Es braucht auch einen Emacs-Mode. Anspruchsvollere Zeitgenossen würden gleich eine IDE fordern.
 

Amin

Well-Known Member
#12
Oder auch: "Warum sind C und C++ immernoch die dominanten Sprachen im Unixumfeld?"
Was spricht denn wirklich gegen C und C++? Bzw. warum sollte man sie nicht verwenden dürfen, wenn es doch offensichtlich Alternativen gibt, die du weiter unten selber nennst?
Auf meinen Streifzügen durch die Welt der Programmiersprachen begegnete ich manchem Juwel. Aber für den praktischen Einsatz unter Unix gibt es immer Einschränkungen.
Aha! Und warum sollte man dann diese "Alternativen" einsetzen, wenn sie nur Einschränkungen haben?
Da sind zunächst die klassischen Sprachen aus der C Familie: C, C++, Object C, D, Java und C#.
Was hat Java und C# mit C zu tun? Weil sie geschweifte Klammern nutzen?:confused: Ich programmiere beruflich täglich mit Java, und habe mal beruflich C++ programmiert (Spielebranche)... und ich weiß bis heute nicht, was an Java C-ähnlich sein soll? Bis auf ein paar Syntax-Erben ist da nichts C-artig. Und eine Syntax macht eine Sprache noch nicht aus... zumindest nicht so wie du es hinstellst.

...Ada... Nebenläufigkeit im Sprechkern und die beste Unterstützung für eigene Datentypen, die ich je gesehen habe, können über die Mängel nicht hinwegtäuschen. Die Lizenzsituation ist bestenfalls unübersichtlich. Die Standardbibliothek unfasst keine Schnittstellen nach außen:
Was? Die Lizenz ist unübersichtlich? Ada ist meines Wissens eine ISO-Norm, und somit kann jeder den Begriff Ada frei nutzen und diese Sprache implementieren. Das ist freier als manche Mainstream-Sprache, wie z.B. Java, wo man seine Implementierung nur gegen eine Lizenzgebühr an SUN "Java" nennen darf.
C++ ist z.B. auch ISO-normiert... jeder kann einen Compiler implementieren und ihn ohne Bedenken C++-Compiler nennen... selbst wenn er nicht 100% C++ versteht. Übersichtlicher kann eine "Lizenz" nicht sein.

Zu den Schnittstellen: ich kenne Ada nur von weitem, aber als C++ler und Javaner weiß ich nur eines: alle erdenklichen Schnittstellen in der Standardlibrary bringen nur Anfängern einen Vorteil. Sobald man komplexere und anspruchsvollere Systeme entwickelt, muß eine externe Library herhalten. Selbst in unserem Java-Swing-Client haben wir 50 MByte JAR-Libs im Schlepptau, weil die Std-Java-Lib absolut nicht das bietet, was wir alles brauchen... so sieht die Realität aus. Wir haben im Konzern Projekt-Teams, die sogar Swing nicht benutzen und dafür SWT nehmen. Eine Standard-GUI? Interessiert die überhaupt nicht!

Ich brauche z.B. in C++ keine GUI-Lib im Standard... ich würde diese eine wahrscheinlich eh nicht benutzen, weil irgendwas an ihr nicht meine Erwartung erfüllen würde. Und wahrscheinlich brauche ich nicht mal eine GUI, weil der Server keine GUI hat. Warum soll das C++-Standard-Komitee sich mit GUIs rumschlagen, wenns nachher eh niemand benutzen will?

Die populären Skriptsprachen, Perl, Python, Ruby und (Lua) haben eine umfangreiche Bibliothek und lassen sich interaktiv nutzen. Python ist schon super. Ihre Probleme sind immer die gleichen: Big Interpreter Locks --> kein echtes multithreading, langsame Programmausführung, keine (optionale) statische Typisierung.
Es sind ja auch nur Skriptsprachen! Wobei der Lua-Erfinder Sprachen wie Python und Ruby auch schon nicht mehr als Skriptsprachen ansieht, sondern als dynamische Programmiersprachen.


Und jetzt meine Wunschliste für die moderne Sprache auf Unixsystemen:
  • Garbage Collection
    Kannst du in C und C++ haben. Mußt nur eine Library hinzufügen, die das kann:
    http://www.hpl.hp.com/personal/Hans_Boehm/gc/
    Jeder Leak-Detector ist praktisch schon ein GC.
    Wobei ich ehrlich gesagt in C++ lieber std::tr1::shared_ptr<T> benutze. Ist kein GC, aber erfüllt seinen Zweck sich nicht mehr um Leaks kümmern zu müssen.
  • Multithreading
    Kannst du in C++ mit boost.thread haben. Bzw. ab C++0x (dem kommenden C++-Standard), wird es direkt eine Thread-API geben. Es ist möglich! Wo ist also das Problem #include <boost/thread.hpp> hinzuschreiben?
  • moderne, umfangreiche Standardbibliothek
    Wie oben bereits gesagt: was bringt dir das? Du wird auch an einer Std-Lib immer was zu meckern haben. Und was ist umfangreich? Wo soll es enden?
    Und was ist modern in deinen Augen? Was ist das Kriterium? Viele C++ler finden z.B. Template-Metaprogrammierung modern. Andere werden sagen, das ist nicht modern. Andere werden sagen, sie verstehen das Konzept dahinter nicht. usw.
  • Echte Makros, wie bei Lisp, kein C Präprozessor Gegurke
    Lisp kenne ich leider nur vom Hören sagen. Aber in C++ benutzt man z.B. auch ungerne C-Makros, man bedient sich da meistens den Templates.
  • Interaktives Toplevel
    Kannst du das näher erläutern oder einen informativen Link posten? Sagt mir leider nichts...
  • native compiler
    C, C++, Ada?!
  • bindings für GUI und OpenGL
    C und C++?! Wahrscheinlich auch Ada...
  • IDE mit Emacs key bindings
    Was hat eine Programmiersprache mit Keybindings einer IDE zu tun? Tools und Sprache sind zwei getrennte Dinge.
  • Vollständige Dokumentation
    ISO-Norm-Dokus von C, C++ und Ada?!
  • freie Lizenz, nicht viral
    ISO-Norm?! Wobei, wie kann eine Sprach-Lizenz viral sein? Eine Sprache ist ja erstmal (meistens jedenfalls) nur eine Spezifikation. Und ich kann diese dann implementieren... diese ist dann meistens eine andere Lizenz. Meistens darf man bei strengen Sprach-Lizenzen z.B. nicht schreiben "Ist zu Sprache X kompatibel". Weil der Markenname geschützt ist oder so... Du meinst aber wahrscheinlich die Implementierung?
Sorry, aber vieles haben die von dir nicht-modern angeprangerten Sprachen schon.

Übrigens, warum sind C und C++ nicht tot zukriegen? Das kann ich dir gerne sagen:
Weil sie die Sprachen sind, mit denen du ALLES machen kannst.
Ein ganz einfaches Beispiel ist Java. Kann ich mit Java einen Garbage Collector implementieren? Nein, natürlich nicht! Ich kann aber mit C und C++ einen GC implementieren! Mit Java geht es nicht, weil ich gar keine Resourcen manuell freigeben kann. Das Feature einer GC-Implementierung schlecht hin!
Man kann die Liste von Anforderungen ewig weiter führen. ;-)

Wenn du alle Sprachen verbieten würdest, und nur noch eine von diesen erlauben würdest, um weiterhin alle Programmierprobleme lösen zu können. Welche Sprache würde da wohl der Kandidat sein? (kannste dir selber ausmalen...)

So schön Sprachen wie Lisp für spezielle Anforderungen genial sein mag, oder so umfangreich die Std-Java-Lib sein mag... sie sind zu speziell!

Mit C kannst du z.B. sogar einen C64 programmieren. Weil es für diesen Computer einen C-Compiler gibt. Es ist, wie hier jemand schon sagte, ein besserer Makro-Assembler. Ich kann damit wirklich die Basics entwickeln.

C++ ist eine Sprache, die mächtig ist.. sehr mächtig. So mächtig, das du dir damit in den Fuß schiessen kannst. Aber C++ hat dafür keine Konkurrenz, weil es alles kann: besserer Makro-Assembler, HiLevel-Abstraktion, OOP und Template-Metaprogrammierung. Und wenn C++ etwas fehlt, implementiere ich mir das Feature in C++! :-)

Wenn du C und C++ nicht magst, dann probier es doch einfach mit einer anderen Sprache. Nur wirst du leider nicht die perfekte Sprache finden. Weil Sprachen entweder zu allgemein sind, oder zu speziell. Alles hat seine Vor- und Nachteile.

Deshalb kann man z.B. auch Sprachen in seinen Projekten kombinieren. Die ganzen Games sind heute in C++ (Engine) und Lua (Spielablauf usw.) entwickelt. Auch Anwendungssoftware wird in Sprachen gemixt. Meistens C oder C++ und dann noch ein Script-Interpreter rein. Also wie bei den Games.

Auch in Client-Server-Umgebungen ist das der Fall. Wir auf Arbeit haben diese Kombis:

Mainframe: COBOL (ja, wir entwickeln damit noch! weil sehr spezielle Sprache!)
Gateway: C
Client: Java-Swing (mag ich nicht, mache ich aber, weil der Kunde das so will)

Naja... tot kriegen wirst du die alten Sprachen nie! Und deshalb sind C und C++ die Basis in Unix und Windows... ach, auf jeder Plattform!
 
Zuletzt bearbeitet:
#13
Ich sprach von modernen Sprachen. C ist zwar ein ganz netter Makro-assembler, aber doch keine moderne Sprache.
C ist low-level genug und high-level genug. Genau richtig positioniert, um universell zu sein. Außerdem ist der heutige Standard 10 Jahre alt. Wo ist das denn bitte alt?

Ich hatte eher gehofft, daß jemand Erfahrung hat mit: Oz/Mozart, Erlang oder Haskell.
Oje... die Sprachen, die allgemein in der Wissenschaft und Bildung gebräuchlich sind, sind oft für die Wissenschaftler als Individuen "cool". Nach dem Motto "ich hab hier was gefunden, womit ich mich identifizieren kann". Für die reale Welt ist es genug, die Dinger zu kennen und zu wissen wann man Abstand davon nimmt. Oft ist es nämlich so, dass in 99 von 100 Fällen davon Abstand zu nehmen ist.

Nochmal zu dieser Frage:
"Warum sind C und C++ immernoch die dominanten Sprachen im Unixumfeld?"
Sie müsste korrekterweise lauten: "Warum gibt es außer C nichts Vernünftiges womit ein Unix-Programmierer arbeiten kann?".
 

Daemotron

Well-Known Member
#14
@Amin:

Ja, Du kannst mit C letztlich (fast) alles machen. Dennoch ist C (C++ kenne ich zu wenig, v. a. nicht im professionellen Umfeld) eigentlich nicht mehr so fürchterlich zeitgemäß, wenn man nicht gerade Systemprogrammierung (Treiber und anderes OS-nahes Zeugs) betreibt.

Warum ich diese Meinung habe? C ist sehr viel weniger produktiv als modernere OO-Sprachen. Nehmen wir als Vergleich einmal Python (in meinen Augen keine reine Interpretersprache mehr, und mit der Möglichkeit, eigene Python-Module in C zu implementieren oder den Python-Interpreter in C-Projekte einzubinden verwischen diese Grenzen zusehends). Python stellt - anders als C - viele im Entwickleralltag nützliche Datenstrukturen wie z. B. Listen und Dictionaries bereit.

Ich kann mich bei der Entwicklung also auf die Dinge konzentrieren, die das Wesensmerkmal meines Programms ausmachen und muss nicht erst X Mannstunden investieren, um mit struct, typedef, Pointern und vielen malloc()- und free()-Aufrufen solche Datentypen zu emulieren, bevor ich mich meinem eigentlichen Problem zuwenden kann.

Ähnlich kann man auch für Java argumentieren (obwohl man dort im Vergleich zu Python immer noch viel FUD in die Kiste hacken muss, bevor das Teil überhaupt erst mal zuckt). Bei Java sind es aber eher die unzähligen vorhandenen Bibliotheken - böse Zungen behaupten, jedes beliebige Problem ließe sich in Java dadurch lösen, dass man ein paar bereits vorhandene Bibliotheken zusammenstöpselt und ein bisschen "Glue" dazwischenschreibt.

Ein weiteres Problem von reinen Compiler-Sprachen ist der Entwicklungszyklus: Ich glaube, es wird kaum jemand bestreiten, dass es ungleich aufwändiger ist, einen Fehler mittels dbg oder anderen Debuggern zu jagen, als einfach den Code schrittweise auszuführen, bis man auf die Zeile mit dem Fehler trifft. Selbst professionelle C-Entwicklungsumgebungen wie Sun Studio können einen Entwickler nur bedingt beim Debugging unterstützen.

Um nicht mißverständlich rüberzukommen: Ja, natürlich kann ich auch bei C gewisse Snippets oder ganze Bibliotheken recyclen, und zugegebenermaßen macht es auch Spaß, sich mal so richtig durch die Untiefen dynamischer Speicherverwaltung zu wurschteln. Für das bessere Verständnis der Funktionsweise von Programmen ist es auch eine überaus wertvolle Erfahrung, das mal gemacht zu haben.

Unterm Strich ist es (zumindest im kommerziellen Umfeld) aber so, dass Du als Programmierer nur dafür bezahlt wirst, eine bestimmte Funktionalität zu implementieren. Geht es um einen Festpreisauftrag, bleibt mehr für mich, wenn ich mit der Implementierung schnell bin. Bei dynamisch beauftragten Projekten steche ich mit meinem Angebot die Konkurrenten aus, wenn ich aufgrund eines kurzen Entwicklungszyklus weniger Mannstunden veranschlagen kann und so ein günstigeres Angebot abgeben kann.

Deswegen behaupte ich auch, dass Geld einer der Gründe ist, aus denen sich C im Open Source Umfeld so hartnäckig hält - weil es hier eben nicht (so) darauf ankommt. Es gibt keine Deadlines (zumindest keine mit existenzbedrohenden Vertragsstrafen bei Nichteinhaltung), und ein Programm wird mehr nach seinem Nutzen, ein Programmierer nach der Eleganz seines Codes beurteilt - und nicht nach seiner Time to Market.

Für die meisten meiner Zwecke ist Python heute schon die ideale Sprache. Mit den Schwächen, die Python hat, kann ich besser leben, als mit den Schwächen, die meine selbst gebauten C-Programme zwangsweise enthalten würden (nicht (nur) aus Inkompetenz, sondern v. a. aus dem Zeitdruck resultierend). Für die Zukunft würde ich mir allerdings wünschen, dass dynamische Typisierung vom Muss zum Kann wird, dass der Big Fat Ugly Lock aus dem Interpreter-Kern verschwindet (manchmal ist Multithreading doch nützlicher als Multiprocessing) und dass analog zu py2exe ein py2elf-Tool dazukommt - das würde die Distribution erheblich vereinfachen und Hemmungen bei (potenziellen) Kunden abbauen, und ich würde nicht ständig Gefahr laufen, auf dem Zielsystem mit einer der vielen Inkompatibilitäten aus der Versionshistorie von Python zu kollidieren.
 
Zuletzt bearbeitet:

Amin

Well-Known Member
#15
@Amin:

Ja, Du kannst mit C letztlich (fast) alles machen. Dennoch ist C (C++ kenne ich zu wenig, v. a. nicht im professionellen Umfeld) eigentlich nicht mehr so fürchterlich zeitgemäß, wenn man nicht gerade Systemprogrammierung (Treiber und anderes OS-nahes Zeugs) betreibt.

Warum ich diese Meinung habe? C ist sehr viel weniger produktiv als modernere OO-Sprachen. Nehmen wir als Vergleich einmal Python (in meinen Augen keine reine Interpretersprache mehr, und mit der Möglichkeit, eigene Python-Module in C zu implementieren oder den Python-Interpreter in C-Projekte einzubinden verwischen diese Grenzen zusehends). Python stellt - anders als C - viele im Entwickleralltag nützliche Datenstrukturen wie z. B. Listen und Dictionaries bereit.
Deshalb habe ich ja nicht nur C aufgeführt, sondern auch C++. Ich habe ja nicht gesagt, das die anderen Sprachen unnütz sind. Jede Sprache ist für einen Zweck erfunden worden.

Aber dein Beispiel mit den nützlichen Datenstrukturen asu Python. Die gibt es natürlich auch für C++. C würde ich heute nicht für komplexe Anwendungen/Systeme verwenden. Sondern für Basics. Du hast in der Standard-Library von C++ natürlich alle möglichen Datencontainer:
  • vector
    dynamisches Array - der Speicher muß laut ISO-Norm zusammenhängend sein!
  • list
    verkettete Liste
  • map
    sortiertes Key-Value dictionary
  • unsorted_map
    map als Hash-map implementiert
und noch ein paar andere Container-Typen.

Beispiel in C++ gefällig:
Code:
// Map mit Strings als Key und Values instanzieren:

map<string, string> m;

// Map füllen:

m["Hans"] = "Wurst";
m["Peter"] = "Lustig";

// Wert zum Schlüssel Hans auslesen:

string s = m["Hans"];
Geht in Python, Java oder so bestimmt nicht kürzer, oder?

Es gibt natürlich viele Standard-Algorithmen, die du auf die Container anwenden kannst, wie find, sort, count usw. Das geht mit einer Zeile Code.

Du hast natürlich eine echte String-Klasse in C++. Ich muß also nicht mit Char-Arrays rumhantieren:

Code:
string str("Hallo");
str.append(" Welt!");
Deshalb habe ich ja geschrieben, das C++ sehr mächtig ist. Viele Menschen kennen C++ nicht wirklich, sondern nur von weitem und denken, es ist ein erweitertes C. Aber es ist natürlich kein C, es ist C++.

Ich selber kenne C wiederrum nur von weitem, ich benutze die C-Std-Library praktisch garnicht. Aber ich könnte, da es von C++ aus geht. :D

Natürlich kann ich z.B. in Python oder überhaupt in dynamischen Sprachen rapid development machen. Aber ein kritisches und komplexes System würde ich damit nicht entwickeln. Dafür haben statische Sprachen wie C++ oder Ada schon ihre Daseinsberechtigung.

Noch zu dem Debugger: ein Debugger hat nichts mit der Sprache zu tun. Ein Debugger ist ein Tool für eine Sprache. Und ich habe z.B. (und das muß man Microsoft einfach lassen!) unter VisualC++ den genialsten C++-Debugger. Ich kann z.B. im MS-Debugger während ich debugge Code on the fly ändern (Codereplacement) und der Debugger macht in der selben Debug-Session mit dem geänderten Code weiter. So wie man es z.B. von Javas Eclipse her kennt.

Codereplacement und andere geniale Features sind in C++ möglich, WENN du das richtige Tool hast. Denn C++ gibt ja keine Einschränkungen vor. Nein, ISO-C++ kennt nicht mal den Begriff "Debugger". Das ist Sache der C++-Implementierung. Wenn SUN einen schlechten Debugger hat, ist das SUNs verfehlung. Das hat nichts mit C++ zu tun. Denn du kannst auch für Python einen schlechten Debugger entwickeln, gell?
 
Zuletzt bearbeitet:
#16
Also OO ist keine Spracheneigenschaft, sondern ein Paradigma. Das bedeutet, dass man sehr wohl nach OO-Art in C programmieren kann. Dass die Sprache C OO schlecht unterstützt ist hierbei vielleicht nennenswert.

Das mit den Mannstunden ist auch etwas übertrieben. Ich glaube, dass man in Java, wenn man genügend Erfahrung hat, etwa doppelt so schnell ein Programm schreiben kann, angenommen, dass beide Sprachen für den Zweck geeignet sind. Ich behaupte aber einfach, dass ein äquivantes C-Programm in den meisten Fällen seinen "doppelten Preis" wert ist.

Das was ich bis jetzt Java-typisches gesehen habe, in bekannten namhaften Unternehmen und Unis und kleinen Klitschen, entspricht nicht dem Standard der Programmierung, welchen ich gewohnt bin.

Noch etwas zu malloc()/free(): wenn man die direkte Kontrolle über den Speicher haben will, dann soll man sie halt haben. Ich sehe da überhaupt keinen Grund welcher dagegen spricht. Ich sehe aber viele Gründe dagegen, wenn einem die Kontrolle entzogen wird. Außerdem gehört es zum täglichen Brot des Programmierers die Module vernünftig zu gestalten und damit die Komplexität entsprechend zu verpacken. Am Ende sollen "sprechende Programme" entstehen, wenn es die Komplexität erfordert.

Jedes Programm (egal welche Sprache) ist schon irgendwie ein kleines Kunstwerk. Jeder hat eine eigene Handschrift. Sie kann auch unglaublich hässlich sein, wie man es oft sieht. Wenn man eine Sprache mit wenig syntaktischen Mitteln sucht, die einen Programmierer zum Einfallsreichtum zwingt und guten Gespür für edle Programmierung, dann nimmt man halt C. Will man in die breite gehen und sehr viele unterschiedliche Features gebrauchen, oft aus Unwissen wie sie eigentlich realisiert werden, aber dafür mit viel auswendig Gelerntem und Erkennungssinn für Mustererkennung beim Programmieren ("so hab ich das schon mal realisiert"), dann ist vielleicht Java oder C++ richtig.

Ich mag lieber meine kleinen "Kunstwerke" in C, die einfach passen und wie angegossen sitzen, anstatt den Einheitsbrei in Java. Java wähle ich nur, wenn ich keine Zeit habe etwas edles zu entwickeln und irgendetwas auf die Schnelle quick and dirty realisieren will.

Außerdem wenn ich einen "erfahrenen C-Programmierer" mit "erfahrenem Java-Programmierer" vergleiche, dann stelle ich fest, dass Java kein gutes Bild abgibt. Die Java-Lösungen werden schneller unübersichtlich und fehlerträchtig. Ich rede jetzt nicht von Hello-World-Programmen.

Anders gefragt... wer möchte gerne vim, OpenSSL, OpenSSH oder irgendwelche Video-Codecs in Java programmiert benutzen?
 

oxy

Staatl. gepr. Destroyer
#17
Da sind zunächst die klassischen Sprachen aus der C Familie: C, C++, Object C, D, Java und C#. C ist in keiner Weise modern. Alle anderen sind wiederkehrende Aufgüsse von "C mit Klassen". Absoluter Spitzenreiter in dieser Kategorie ist C#; der 2. Versuch einer Kopie einer ehemals abgespeckten (C++)-Kopie, die später dicker wurde als das Original.
C# ist ja wohl nicht der Versuch einer Kopie etc. bla.

C# entwickelt sich immer mehr zu einer Mulitparadigmenprogrammiersprache.
Du hast natürlich Objektorientierung, es gibt funktionale Programmierung (Lambda Ausdrücke), ab .NET 4.0 auch noch dynamische Teile.

(Automatic) Properties (objekt.propertie = "bla", Getter/Setter können aber auch überschrieben werden, die Möglichkeit die Werte beim Initialisieren anzugeben) ist eigentlich ein recht simples Feature, aber trotzdem sehr praktisch, weil man das ständig braucht.

LINQ ist auch nochmal richtig Innovativ.

Viele der Sachen (bis auf LINQ) kann man übrigens mit Groovy z.B. haben - was im Gegensatz zu C# in der Java VM läuft und damit unter Unix-ähnlichen Systemen gleich erheblich besser als C#.

Groovy unterstütz viele Softwarepatterns teilweise direkt von den Libaries, wie z.B. der XML oder Swingbuilder wenn sich das mal einer angucken will.

Was mich bei Groovy letztens - obwohl ich schon seit längerem privat immer mal wieder mit Groovy rummache - total vom hocker gehauen hat ist dieser Codeschnipsel: http://www.heise.de/ix/artikel/2006/07/131/01.shtml

Ob Groovy nun alles auf deiner Wunschliste erfüllt (alles verstehe/kenne ich nicht) weiß ich nicht.
Die beste Groovy Ide (IntelliJ Idea) kostet leider Geld, dafür gibts ein kostenloses VI (!) Plugin. Wer will denn schon Emacs? :-P
Aber Groovy ist definitv geil, modern und läuft halt da wo Java läuft.

Was ist mit Ruby? Das ist doch auch Hip und Modern?
 

hippodriver

Well-Known Member
Themenstarter #18
Was spricht denn wirklich gegen C und C++? Bzw. warum sollte man sie nicht verwenden dürfen, wenn es doch offensichtlich Alternativen gibt, die du weiter unten selber nennst?
Woher soll ich wissen, warum Du sie nicht verwenden sollst?

Aha! Und warum sollte man dann diese "Alternativen" einsetzen, wenn sie nur Einschränkungen haben?
Weil C und C++ auch Einschränkungen haben.

Was hat Java und C# mit C zu tun? Weil sie geschweifte Klammern nutzen?:confused: Ich programmiere beruflich täglich mit Java, und habe mal beruflich C++ programmiert (Spielebranche)... und ich weiß bis heute nicht, was an Java C-ähnlich sein soll? Bis auf ein paar Syntax-Erben ist da nichts C-artig. Und eine Syntax macht eine Sprache noch nicht aus... zumindest nicht so wie du es hinstellst.
C ist mit Java direkt überhaupt nicht verwandt, sondern über das Bindeglied C++.

Was? Die Lizenz ist unübersichtlich? Ada ist meines Wissens eine ISO-Norm, und somit kann jeder den Begriff Ada frei nutzen und diese Sprache implementieren. Das ist freier als manche Mainstream-Sprache, wie z.B. Java, wo man seine Implementierung nur gegen eine Lizenzgebühr an SUN "Java" nennen darf.
C++ ist z.B. auch ISO-normiert... jeder kann einen Compiler implementieren und ihn ohne Bedenken C++-Compiler nennen... selbst wenn er nicht 100% C++ versteht. Übersichtlicher kann eine "Lizenz" nicht sein.
Für Unix gibt es nur eine Implementierung, nämlich GNAT. Der Kompiler steht als Teil von gcc unter GPL. Die Bibliotheken stehen unter -- das ist die Frage: Es hängt davon ab, ob man eine Version von der FSF oder eine AdaCore erwischt. Technisch sind die identisch, aber die eine steht unter GPL ohne und die mit linking exception.

Zu den Schnittstellen: ich kenne Ada nur von weitem, aber als C++ler und Javaner weiß ich nur eines: alle erdenklichen Schnittstellen in der Standardlibrary bringen nur Anfängern einen Vorteil. Sobald man komplexere und anspruchsvollere Systeme entwickelt, muß eine externe Library herhalten. Selbst in unserem Java-Swing-Client haben wir 50 MByte JAR-Libs im Schlepptau, weil die Std-Java-Lib absolut nicht das bietet, was wir alles brauchen... so sieht die Realität aus. Wir haben im Konzern Projekt-Teams, die sogar Swing nicht benutzen und dafür SWT nehmen. Eine Standard-GUI? Interessiert die überhaupt nicht!
Wenn es bessere externe Bibliotheken gibt, um so besser. Für Ada gibt es aber garnichts. Eine große Standardbibliothek garantiert zumindest ein Minimum an Funktionalität. Bei Python zum Beispiel enthält die Standardbibliothek für praktisch jeden Einsatzzweck ein Modul. Es ist nicht immer das beste oder umfangreichste, aber man kann ich darauf verlassen, daß es da ist. Erfolgreiche externe libs werden in die Standardbibliothek integriert. So wie bei den Borg. Ok, die Standard-GUI, tkinter, benutzt kaum jemand.

Es sind ja auch nur Skriptsprachen! Wobei der Lua-Erfinder Sprachen wie Python und Ruby auch schon nicht mehr als Skriptsprachen ansieht, sondern als dynamische Programmiersprachen.
Die Dinger sind ungemein beliebt. Der neue TeX-Compiler besteht zu 100% aus Lua.

[*]Garbage Collection
Kannst du in C und C++ haben. Mußt nur eine Library hinzufügen, die das kann:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
Jeder Leak-Detector ist praktisch schon ein GC.
Wobei ich ehrlich gesagt in C++ lieber std::tr1::shared_ptr<T> benutze. Ist kein GC, aber erfüllt seinen Zweck sich nicht mehr um Leaks kümmern zu müssen.
In Qt hat sogar von vorneherein reference counting für alles, was von QObject abgeleitet ist. Aber eine durchgängige, transparente Lösung ist mir lieber.

[*]Multithreading
Kannst du in C++ mit boost.thread haben. Bzw. ab C++0x (dem kommenden C++-Standard), wird es direkt eine Thread-API geben. Es ist möglich! Wo ist also das Problem #include <boost/thread.hpp> hinzuschreiben?
Multithreading war mit pthread noch nie ein Problem. Aber diese Liste war ja auch nicht explizit gegen C++ gerichtet.

[*]moderne, umfangreiche Standardbibliothek
Wie oben bereits gesagt: was bringt dir das? Du wird auch an einer Std-Lib immer was zu meckern haben. Und was ist umfangreich? Wo soll es enden?
Und was ist modern in deinen Augen? Was ist das Kriterium? Viele C++ler finden z.B. Template-Metaprogrammierung modern. Andere werden sagen, das ist nicht modern. Andere werden sagen, sie verstehen das Konzept dahinter nicht. usw.
Mit modern meine ich, daß heute eingesetzte Technologien abgedeckt werden. Dieser Punkt bezieht sich vor allem auf Sprachen, die ich schon lange nicht mehr weiterentwickelt haben. Die Standardbibliothek von Common Lisp zum Beispiel entstand vor XML und vor dem Durchbruch des Internets.

[*]Echte Makros, wie bei Lisp, kein C Präprozessor Gegurke
Lisp kenne ich leider nur vom Hören sagen. Aber in C++ benutzt man z.B. auch ungerne C-Makros, man bedient sich da meistens den Templates.
Lisp Makros transformieren den Syntaxbaum eines Programms während des Kompiliervorgangs. Sie erweitern sozusagen den Compiler.

[*]Interaktives Toplevel
Kannst du das näher erläutern oder einen informativen Link posten? Sagt mir leider nichts...
Unter Lisp heist das Ding Read-Eval-Print-Loop. Es fühlt sich an wie ein Interpreter. http://en.wikipedia.org/wiki/Read-eval-print_loop.

[*]bindings für GUI und OpenGL
C und C++?! Wahrscheinlich auch Ada...
C braucht ja nichtmal bindings. Aber bei Ada sieht es mal wieder schlecht aus: das GTK binding ist veraltet und für Qt gibt es nichts.

[*]IDE mit Emacs key bindings
Was hat eine Programmiersprache mit Keybindings einer IDE zu tun? Tools und Sprache sind zwei getrennte Dinge.
Nur nutzt das eine nicht viel ohne das andere.

[*]Vollständige Dokumentation
ISO-Norm-Dokus von C, C++ und Ada?!
Ja und, was hilft mir das bei Dylan oder OCaml? Ich glaube wirklich, Du hast die Liste fehlinterpretiert. Sie trägt nicht die Überschrift: "Meine Kritikpunkte an C++". Daher müssen auch nicht alle Punkte auf C++ zutreffen.

[*]freie Lizenz, nicht viral
ISO-Norm?! Wobei, wie kann eine Sprach-Lizenz viral sein? Eine Sprache ist ja erstmal (meistens jedenfalls) nur eine Spezifikation. Und ich kann diese dann implementieren... diese ist dann meistens eine andere Lizenz. Meistens darf man bei strengen Sprach-Lizenzen z.B. nicht schreiben "Ist zu Sprache X kompatibel". Weil der Markenname geschützt ist oder so... Du meinst aber wahrscheinlich die Implementierung?
Viele Sprachen sind nicht standardisiert. Dann ist die Implementierung die Sprache und umgekehrt.

Übrigens, warum sind C und C++ nicht tot zukriegen? Das kann ich dir gerne sagen:
Weil sie die Sprachen sind, mit denen du ALLES machen kannst.
Natürlich ist bis zu einem gewissen Niveau eine Sprache wie C oder Pascal notwendig. Aber oberhalb des Betriebssytems oder der Virtuellen Maschine kommt man ohne aus.

Man kann die Liste von Anforderungen ewig weiter führen. ;-)
Ja natürlich. Aber das sind die für mich wichtigsten Punkte.

Wenn du alle Sprachen verbieten würdest, und nur noch eine von diesen erlauben würdest, um weiterhin alle Programmierprobleme lösen zu können. Welche Sprache würde da wohl der Kandidat sein? (kannste dir selber ausmalen...)
Pascal natürlich.

Deshalb kann man z.B. auch Sprachen in seinen Projekten kombinieren. Die ganzen Games sind heute in C++ (Engine) und Lua (Spielablauf usw.) entwickelt. Auch Anwendungssoftware wird in Sprachen gemixt. Meistens C oder C++ und dann noch ein Script-Interpreter rein. Also wie bei den Games.
Das ist ja bei allen drei Sprachen in meiner Wunschkombination auch üblich. Deshalb hatte ich ja das einfache Interface zu C gefordert. Damit man Low-Level-Dinge auslagern kann.

Naja... tot kriegen wirst du die alten Sprachen nie! Und deshalb sind C und C++ die Basis in Unix und Windows... ach, auf jeder Plattform!
Und im Bootloader von FreeBSD lebt noch Forth. Aber mir ging es mehr um die Anwendungssoftware. Wenn man FreeBSD plus alle Ports betrachtet, ist die überwältigende Mehrheit der Programme in C oder C++ geschrieben, obwohl das nicht zwingend notwendig wäre.
Microsoft und Apple versuchen beide davon wegzukommen, mit mäßigem Erfolg.
Gleiches gilt für Gnome.
 

FierceOne

Kampfmaschine
#19
Also OO ist keine Spracheneigenschaft, sondern ein Paradigma. Das bedeutet, dass man sehr wohl nach OO-Art in C programmieren kann. Dass die Sprache C OO schlecht unterstützt ist hierbei vielleicht nennenswert.
D'accord!

nakal hat gesagt.:
Das mit den Mannstunden ist auch etwas übertrieben. Ich glaube, dass man in Java, wenn man genügend Erfahrung hat, etwa doppelt so schnell ein Programm schreiben kann, angenommen, dass beide Sprachen für den Zweck geeignet sind. Ich behaupte aber einfach, dass ein äquivantes C-Programm in den meisten Fällen seinen "doppelten Preis" wert ist.
Naja ich bin nicht sicher wieviel besser ein Programm sein kann um den doppelten Preis zu rechtfertigen. Vorausgesetzt die Java Version ist akzeptabel (ordentliche Doku, etc). Mir fallen allerdings auch wirklich wenige Beispiele ein wo C als auch Java hervorragend geeignet sind.

nakal hat gesagt.:
Das was ich bis jetzt Java-typisches gesehen habe, in bekannten namhaften Unternehmen und Unis und kleinen Klitschen, entspricht nicht dem Standard der Programmierung, welchen ich gewohnt bin.
Uiiijuuii. Diese Beobachtung laesst sich 100pro mit der Sprache erklaeren :rolleyes: Mit solch induktive Schluessen waere ich vorsichtig. Gut, ok, ich kenne Dein brutales Level an C Expertise auch nicht. Ich kann es lediglich erahnen und erblasse vor Neid.

nakal hat gesagt.:
Noch etwas zu malloc()/free(): wenn man die direkte Kontrolle über den Speicher haben will, dann soll man sie halt haben. Ich sehe da überhaupt keinen Grund welcher dagegen spricht. Ich sehe aber viele Gründe dagegen, wenn einem die Kontrolle entzogen wird. Außerdem gehört es zum täglichen Brot des Programmierers die Module vernünftig zu gestalten und damit die Komplexität entsprechend zu verpacken. Am Ende sollen "sprechende Programme" entstehen, wenn es die Komplexität erfordert.
D'accord!

nakal hat gesagt.:
Jedes Programm (egal welche Sprache) ist schon irgendwie ein kleines Kunstwerk. Jeder hat eine eigene Handschrift.
... wie vor langer Zeit schon Donald E. Knuth anmerkte...

nakal hat gesagt.:
Sie kann auch unglaublich hässlich sein, wie man es oft sieht. Wenn man eine Sprache mit wenig syntaktischen Mitteln sucht, die einen Programmierer zum Einfallsreichtum zwingt und guten Gespür für edle Programmierung, dann nimmt man halt C.
Uiiijiiiii, die Worte eines Durchblickers! Ich wuenschte wir waeren alle so schlau wie Du! Da wuerden wir nur noch C programmieren und die Welt waere besser.

nakal hat gesagt.:
Will man in die breite gehen und sehr viele unterschiedliche Features gebrauchen, oft aus Unwissen wie sie eigentlich realisiert werden, aber dafür mit viel auswendig Gelerntem und Erkennungssinn für Mustererkennung beim Programmieren ("so hab ich das schon mal realisiert"), dann ist vielleicht Java oder C++ richtig.
Also fuer die Flachzangen unter uns :( . Naja koennen wir ja froh sein das fuer "Auswendiglerner" und "Unwissende" Sprachen wie C++ existieren. :gpaul: -> ich sehe Du hast das genau erkannt. Wunderbar! Bitte verzeih auch dass Mustererkennung und Coderecycling '("so hab ich das schon mal realisiert")' eigentlich Gang und Gebe sind, bzw. sein sollten. Damit man das Rad nicht immer neu erfindet (Moment, sogar C hat ne Standardbib :confused: , naja ist wohl eher fuer die C Weicheier). Gut, ich weis, nix fuer Denker! Also hop hop immer schoen von vorne programmieren, das macht das Ergebnis dann besonders "edel".

nakal hat gesagt.:
Ich mag lieber meine kleinen "Kunstwerke" in C, die einfach passen und wie angegossen sitzen, anstatt den Einheitsbrei in Java. Java wähle ich nur, wenn ich keine Zeit habe etwas edles zu entwickeln und irgendetwas auf die Schnelle quick and dirty realisieren will.
Geht doch nix ueber ein *gesundes* Mass an Selbstkritik!

nakal hat gesagt.:
Außerdem wenn ich einen "erfahrenen C-Programmierer" mit "erfahrenem Java-Programmierer" vergleiche, dann stelle ich fest, dass Java kein gutes Bild abgibt. Die Java-Lösungen werden schneller unübersichtlich und fehlerträchtig. Ich rede jetzt nicht von Hello-World-Programmen.
Also liebe Java-Programmierer, wuerdet ihr C programmieren wuerdet ihr ein besseres Bild abgeben! Insofern ihr ueber Hell O world hinaus gekommen seid.

nakal hat gesagt.:
Anders gefragt... wer möchte gerne vim, OpenSSL, OpenSSH oder irgendwelche Video-Codecs in Java programmiert benutzen?
Niemand! Also ich benutze grundsaetzlich nur Software, die in C geschrieben wurde! Die Programmierer sind dort wesentlich klueger und cooler!

*SCNR*
 
#20
Ich will jetzt nicht sagen, dass ich ein hervorragender Experte bei C und Java bin. Ich glaube, Du hast da etwas missverstanden. Allerdings habe ich ein Auge für ekeligen Code. Und das findet man prominenterweise bei "Java-Experten". Das sind genau die Leute, die durch die zahlreichen Abstraktionen nicht mehr durchblicken und Dir ein A für ein B verkaufen. Durch die oft falsche Wiederverwendung durch Unkenntnis der Implementierung, die dahinter steht kann nur Mist dabei herauskommen.

Und das ist eben das Ergebnis, wenn man lediglich auf dem Java-Trip ist. Meistens ist das eben dann so, dass ein C-Programm doppelt so viel kostet und hervorragend läuft und ein Java-Programm zwar dann billiger ist, aber ein völliger Müllhaufen. Die Leute, die auf die Sprache fixiert sind, sind völlig abgehoben und kennen grundsätzliche Konzepte nicht mehr.

Übertreib hier nicht so einseitig... ich hab nirgendwo erzählt, dass man keine Java-API oder die C-Standbibliotheken nicht benutzen soll. Das wäre bloß schön, wenn die Hälfte der Java-Programmierer überhaupt die Java-API kennen würden und den Umgang damit. Das entbindet sie aber trotzdem nicht davon ein Gespür dafür zu kriegen wie man programmiert. Dazu braucht man eben noch mehr als die Dokumentation.
 

FreeBSDuser

Well-Known Member
#21
Wikommen im Religionsthread 2.0. Voten sie jetzt für grün, blau oder rot.

Mal ernsthaft, es ist Tatsache, dass viele Leute programmieren aber nur ein kleiner Anteil davon es wirklich gut kann. Da hilft auch keine 42ste neue Super-Sprache. Ausserdem ists dann ja nicht die Schuld der Sprache, die kann wenig dafür, dass der Benutzer diese nicht beherrscht (ein wunderbares Wort in diesem Zusammenhang).
 

Elwood

Naiver Mutmaßlicher
#22
Halte solche Diskussionen auch für wenig zweckmässig.
1. Es gibt viele Wege die nach Rom führen und analog die Programmiersprachen, um ans Ziel zu kommen.
2. Spielt natürlich die persönliche Präferenz eine Rolle. Der eine mag halt eher die Eine, als die andere Sprache.
3. Eine Rohrzange kann einen Schraubendreher nicht ersetzen. Für ein bestimmtes Problem gibt es halt auch bestimmte Programmierwerkzeuge. Universielle Werkzeuge sind meist schlechte Kompromisse.
 

Daemotron

Well-Known Member
#23
Amin hat gesagt.:
Code:
// Map mit Strings als Key und Values instanzieren: 
map<string, string> m; 
// Map füllen: 
m["Hans"] = "Wurst"; 
m["Peter"] = "Lustig"; 
// Wert zum Schlüssel Hans auslesen: 
string s = m["Hans"];
Geht in Python, Java oder so bestimmt nicht kürzer, oder?
Wie bereits gesagt, C++ ist nicht mein Gebiet - ich stelle mir nur grade den C-Code vor, den man bräuchte, um obiges Beispiel zu implementieren. Halten wir also fest, das C++ produktiver ist als ANSI C. In Python wäre es tatsächlich nicht wesentlich kürzer als in C++:
Code:
m = {'Hans' : 'Wurst', 'Peter': 'Lustig'}
s = m['Hans']
Natürlich kann ich mit mit C ein entsprechendes Framework zusammenklopfen, das structs und Function Pointer zu "Objekten" verheiratet - dann habe ich im Endergebnis aber wieder etwas, was andere schon vor mir getan haben. Die Schnittstelle zu diesem Framework bedarf einer bestimmten Syntax, und schon habe ich das, was ich als OO-Sprache bezeichne.

Das mit den Mannstunden ist auch etwas übertrieben. Ich glaube, dass man in Java, wenn man genügend Erfahrung hat, etwa doppelt so schnell ein Programm schreiben kann, angenommen, dass beide Sprachen für den Zweck geeignet sind. Ich behaupte aber einfach, dass ein äquivantes C-Programm in den meisten Fällen seinen "doppelten Preis" wert ist.
Wir sind wohl noch nicht so häufig mit der unternehmerischen Realität konfrontiert worden, was? Mal ehrlich, betriebliche Software (und damit meine ich jetzt nicht Standard-Lösungen, sondern das, was sich ein Betrieb individuell für einen speziellen Zweck zusammenklopfen lässt) hat meiner Erfahrung nach eine durchschnittliche Lebenserwartung von 2-3 Jahren - danach muss die Software oft grundlegend überarbeitet und dem veränderten Geschäftsmodell angepasst werden. Bei einem eleganten C-Programm wäre ich als Unternehmen erstens darauf angewiesen, wieder denselben coolen Hacker zu engagieren (dessen Stundensatz sich dann rein zufällig verdoppelt hat:grumble:), und zweitens müsste es wieder Unsummen für die Anpassung ausgeben. Ergo bekommt der von mir (Unternehmen) den Auftrag, der eine kostengünstige, modulare Lösung liefern kann, die billig anzupassen ist.

Das was ich bis jetzt Java-typisches gesehen habe, in bekannten namhaften Unternehmen und Unis und kleinen Klitschen, entspricht nicht dem Standard der Programmierung, welchen ich gewohnt bin.
Da ist es wieder... Eleganz, ja selbst Effizienz spielen bei Unternehmensanwendungen nur die zweite Geige. Für die Gründe siehe oben. Und glaub mir, Java ist noch nicht der Boden des Fasses... was ich schon an wüstem Zeug in Oracle APEX (haupts. PL/SQL) gesehen habe, wird nur noch von noch wüsteren MS-Office-VBA-Hacks übertroffen - aber auch die gibt es in Unternehmen häufiger, als einem lieb sein kann.

Jedes Programm (egal welche Sprache) ist schon irgendwie ein kleines Kunstwerk. Jeder hat eine eigene Handschrift. Sie kann auch unglaublich hässlich sein, wie man es oft sieht. Wenn man eine Sprache mit wenig syntaktischen Mitteln sucht, die einen Programmierer zum Einfallsreichtum zwingt und guten Gespür für edle Programmierung, dann nimmt man halt C. Will man in die breite gehen und sehr viele unterschiedliche Features gebrauchen, oft aus Unwissen wie sie eigentlich realisiert werden, aber dafür mit viel auswendig Gelerntem und Erkennungssinn für Mustererkennung beim Programmieren ("so hab ich das schon mal realisiert"), dann ist vielleicht Java oder C++ richtig.
Diese Einschätzung zeugt von Überheblichkeit. Ich weiß nicht, ob und was Du beruflich machst, aber meiner Erfahrung nach findet man eine solche Haltung vor allem in den Elfenbeintürmen der Unis und FOSS-Projekte...

Ach ja, da es hier genannt wurde (ich finde grade den betreffenden Beitrag nicht wieder): Die Plattform-Unabhängigkeit von C ist ein Märchen. Klar, Hell-o-World kompiliert überall - bei komplexeren Themen wie Sockets, Threading, Prozesssteuerung etc. hört die Freundschaft auf. Schaut euch einfach mal den Code von Lighttpd an - in C geschrieben, und die Problemstellung hat überschaubare Komplexität. Und jetzt zählt mal die Zeilen mit #ifdef, die der Portabilität geschuldet sind...

FreeBSDuser hat gesagt.:
Wikommen im Religionsthread 2.0. Voten sie jetzt für grün, blau oder rot.
Ooch, ich hätte gerne gelb gehabt. Menno.:D
Aber Du hast recht, die Fakten wurden aufgezählt, die persönliche Entscheidung jedes einzelnen ist Geschmackssache. Deshalb ist für mich hier EoD.
 

FierceOne

Kampfmaschine
#24
Ich will jetzt nicht sagen, dass ich ein hervorragender Experte bei C und Java bin. Ich glaube, Du hast da etwas missverstanden. Allerdings habe ich ein Auge für ekeligen Code. Und das findet man prominenterweise bei "Java-Experten". Das sind genau die Leute, die durch die zahlreichen Abstraktionen nicht mehr durchblicken und Dir ein A für ein B verkaufen. Durch die oft falsche Wiederverwendung durch Unkenntnis der Implementierung, die dahinter steht kann nur Mist dabei herauskommen.

Und das ist eben das Ergebnis, wenn man lediglich auf dem Java-Trip ist. Meistens ist das eben dann so, dass ein C-Programm doppelt so viel kostet und hervorragend läuft und ein Java-Programm zwar dann billiger ist, aber ein völliger Müllhaufen. Die Leute, die auf die Sprache fixiert sind, sind völlig abgehoben und kennen grundsätzliche Konzepte nicht mehr.

Übertreib hier nicht so einseitig... ich hab nirgendwo erzählt, dass man keine Java-API oder die C-Standbibliotheken nicht benutzen soll. Das wäre bloß schön, wenn die Hälfte der Java-Programmierer überhaupt die Java-API kennen würden und den Umgang damit. Das entbindet sie aber trotzdem nicht davon ein Gespür dafür zu kriegen wie man programmiert. Dazu braucht man eben noch mehr als die Dokumentation.
Du hast sicher Recht. Java hin oder her; es gibt sicher viele Leute die einseitig auf eine Sprache fixiert sind und daher blind fuer (gute) Konzepte werden, bzw. die Ideen dahinter. Ich stimme Dir auch zu dass es einen Riesenunterschied zwischen einem lauffaehigem und einem guten Programm gibt. Ich habe mich halt ein wenig dran gestossen das Ganze so auf die jeweilige Sprache zu fixieren. Auch wenn es sicher auch hier Haeufungpunkte gibt.

Ja das viel geruehmte Gespuer fuer die Programmierung. Wohl das Wichtigste ueberhaupt. Meines Einachtens nach kann man das nur bekommen wenn man ordentlich viel liest und, noch viel wichtiger, selber aktiv wird. :belehren: Das Dumme dabei ist, so geht es zumindest mir, je mehr man macht desto oefter stellt man fest dass man eigentlich noch nicht annaehernd genug gemacht hat. ;'(