Warum verwendet ueberhaupt noch irgendjemand C?
-
hustbaer schrieb:
Ausnahmen sind natürlich Sachen wie z.B. Kernel ohne C++ Unterstützung
Nicht mal da würde ich auf C++ verzichten wollen, auch die reinen Sprachfeatures ohne Standard-Library und ohne Exceptions sind schon ziemlich nett.
(Ich vermute mal dass mit C++ Unterstützung die Library gemeint ist, weil g++ kann man ja afaik mit dem gcc kompilieren.)
-
Es stellt sich immer die Frage der Anwendung. Bei uns ist es so, dass es zwar C++ Compilier für unsere Prozessoren gibt, die machen aber oft vieles so dermaßen falsch, dass man einfach C nehmen muss. (Optimierugen funktionieren nicht, Compilierbugs (Ableitungen erzeugen falschen Objektcode) etc...)
Von daher ist man gezwungen C einzusetzen. Ein weiterer Punkt sind auch die Mitarbeiter im Unternehmen. Wenn viele nur C beherschen ist C nun mal das Mittel der Wahl.
Gruß
Tobi
-
Tobias Gerg schrieb:
Es stellt sich immer die Frage der Anwendung. Bei uns ist es so, dass es zwar C++ Compilier für unsere Prozessoren gibt, die machen aber oft vieles so dermaßen falsch, dass man einfach C nehmen muss. (Optimierugen funktionieren nicht, Compilierbugs (Ableitungen erzeugen falschen Objektcode) etc...)
Das zaehlt heutzutage aber nicht mehr, denn es reicht, einen compiler fuer llvm-code anzubieten und schon hat man nicht nur den C-compiler, sondern auch gleich noch mehrere andere Programmiersprachen dabei.
Tobias Gerg schrieb:
Ein weiterer Punkt sind auch die Mitarbeiter im Unternehmen. Wenn viele nur C beherschen ist C nun mal das Mittel der Wahl.
Nein. Es gibt die Regel, dass man jedes Jahr eine Programmiersprache lernen soll und ich denke, man heutzutage von jedem Softwareentwickler erwarten kann, auch objektorientierte Programmierweisen zu koennen. Ich erwarte die Bereitschaft, neuere Programmiersprachen zu lernen und ich erwarte von Firmen, dass sie ihre Mitarbeiter ggf. zu entsprechenden Fortbildungen schicken.
-
Marthog schrieb:
Nein. Es gibt die Regel, dass man jedes Jahr eine Programmiersprache lernen soll und ich denke, man heutzutage von jedem Softwareentwickler erwarten kann, auch objektorientierte Programmierweisen zu koennen. Ich erwarte die Bereitschaft, neuere Programmiersprachen zu lernen und ich erwarte von Firmen, dass sie ihre Mitarbeiter ggf. zu entsprechenden Fortbildungen schicken.
Da erwartest du dir ziemlich viel.
In vielen Firmen wird's das einfach nicht spielen.
-
Marthog schrieb:
Nein. Es gibt die Regel, dass man jedes Jahr eine Programmiersprache lernen soll
Ach, Quatsch. Ich bin noch keine 30 und hab schon lange keine neue Sprache mehr gelernt. Seh ich auch überhaupt nicht ein. Die "wichtigen" weitverbreiteten Sprachen kann ich alle schon lang, und irgendwelche neuen Hypes mach ich nicht mit. Mich interessiert weder D noch Go. Hab in der IT mittlerweile andere Interessen und würd sicher keine Freizeit damit verschwenden, von sich aus irgendwelche Programmiersprachen zu lernen. Außer natürlich, ich würde die Sprache für irgendwas brauchen oder die würde mich aus irgendeinem Grund interessieren. Ist in den letzten Jahren aber eben nicht vorgekommen.
-
hustbaer schrieb:
Da erwartest du dir ziemlich viel.
In vielen Firmen wird's das einfach nicht spielen.Weiss ich. Ich habe nur geschrieben, wie es sein sollte.
-
@Marthog
Inwieweit entkräftet die Tatsache/Behauptung/Meinung dass etwas nicht wahr sein sollte ein Argument?
-
hustbaer schrieb:
Inwieweit entkräftet die Tatsache/Behauptung/Meinung dass etwas nicht wahr sein sollte ein Argument?
Firmen sollten ihre Mitarbeiter entsprechend fortbilden, damit die auch etwas anderes als C koennen. Das machen sie nicht, aber dennoch ist das kein vernuenftiger Grund, die Programme in C zu entwickeln, sondern fuehrt der Antwort, dass C verwendet wird, weil die Entwickler/Firmen inkompetent sind.
-
Es stellt sich immer die Frage der Anwendung. Bei uns ist es so, dass es zwar C++ Compilier für unsere Prozessoren gibt, die machen aber oft vieles so dermaßen falsch, dass man einfach C nehmen muss. (Optimierugen funktionieren nicht, Compilierbugs (Ableitungen erzeugen falschen Objektcode) etc...)
Kenne Ähnliches mit C Comilern, wo casts auf andere Datentypen des öfteren fehlerhafte Ergebnisse liefern. Ist vermutlich nur eine Frage des Alter des Compilers.
Von daher ist man gezwungen C einzusetzen. Ein weiterer Punkt sind auch die Mitarbeiter im Unternehmen. Wenn viele nur C beherschen ist C nun mal das Mittel der Wahl.
Würden sie doch nur C beherschen.
Nur weil man die grundlegenden Sprachmittel verstanden hat, heißt das noch lange nicht dass man die Sprache beherscht, geschweige denn die Grundkonzepte der Softwareentwicklung verstanden hat.
C ist für meinen Geschmack eine sehr offene Programmiersprache. Datenkapslung ist aufwendig nachzubauen.
Das beginnt schon bei private Membern. Will man dies nachbauen muss man entweder das Handle Konzept nutzen, oder man weicht das private Konzept auf und deklariert ein Member als private, und dokumentiert dies. Und die fehlt oft.
-
Bitte ein Bit schrieb:
C ist für meinen Geschmack eine sehr offene Programmiersprache. Datenkapslung ist aufwendig nachzubauen.
Datenkapselung ist irrelevant. Kennst Du die Members vom FILE?
Datenkapselung ganz leicht nachzubauen. Einfach die Members mit priv_ anfangen lassen.Bitte ein Bit schrieb:
Das beginnt schon bei private Membern. Will man dies nachbauen muss man entweder das Handle Konzept nutzen, oder man weicht das private Konzept auf und deklariert ein Member als private, und dokumentiert dies. Und die fehlt oft.
Das liegt aber nur an den Programmierern und nicht an der Sprache.
Jo, die einfache Lösung sieht keiner. C-Leute programmieren wie Höhlenmenschen, meistens wie besoffene Höhlenmenschen. C++-Leute sind Masochisten und schreiben von den typischen 5 Lösungen, die sich anbieten, immer die, die am schwierigsten zu lesen ist.
Man kann weder typische C- noch C++-Programmierer brauchen. Und die, die man brauchen kann, sind in jeder Sprache produktiv, aber man tut gut daran, ihnen C++ zu geben, weils damit schnell geht und einfach wenig Fehler ausgeliefert werden.
Spaßig ist natürlich, wenn wie so oft Programmierer wie Wirtschaftler und von Wirtschaftlern ausgewählt werden. Naja, für Außenstehende und die Konkurrenz ist es spaßig.
-
volkard schrieb:
Und die, die man brauchen kann, sind in jeder Sprache produktiv, aber man tut gut daran, ihnen C++ zu geben, weils damit schnell geht und einfach wenig Fehler ausgeliefert werden.
+1
volkard schrieb:
Spaßig ist natürlich, wenn wie so oft Programmierer wie Wirtschaftler und von Wirtschaftlern ausgewählt werden. Naja, für Außenstehende und die Konkurrenz ist es spaßig.
Ja. Für nicht-Außenstehende leider weniger
-
volkard schrieb:
Und die, die man brauchen kann, sind in jeder Sprache produktiv, aber man tut gut daran, ihnen C++ zu geben, weils damit schnell geht und einfach wenig Fehler ausgeliefert werden.
Bezieht sich das jetzt nur auf den Vergleich mit C oder auch auf andere Sprachen? Weil generell würd ich schätzen, gehört C++ ja schon eher auch zu den Sprachen, bei denen man Entwicklerzeit opfert um CPU-Zeit zu sparen. Und ich habe den Eindruck, dass man viele Projekte, bei denen Performance ziemlich egal ist, mit weniger Entwicklungsaufwand fehlerfreier in anderen Sprachen umsetzen kann. Meinst du nicht?
-
Dobi schrieb:
Und ich habe den Eindruck, dass man viele Projekte, bei denen Performance ziemlich egal ist, mit weniger Entwicklungsaufwand fehlerfreier in anderen Sprachen umsetzen kann. Meinst du nicht?
Das sehe ich gar nicht so. Man ist fuer C++ gezwungen, die Implementierung sehr genau auszuarbeiten und landet dadurch bei recht fehlersicherem und zuverlaessigem Code. Die gedankliche Arbeit, die man in die aufwaendigere Sprache steckt, bleibt dann oft aber natuerlich nicht zwangslaeufig in der Codequalitaet.
-
Denke dass Java für die meisten Projekte besser geeignet ist.
-
@Marthog: Naja, man könnte sich ja eine Sprache vorstellen, die zwar at runtime langsamer ist, aber dafür
- durch ein strengeres Typsystem zu noch mehr Genauigkeit zwingt
- keine memleaks zulässt
- nicht erlaubt über arraygrenzen hinauszulatschen
- den edit-Compile-test-cycle nicht so in die Länge zieht, dass man zwischendurch immer wieder aus Langeweile ins Forum guckt
- weniger legacy-Fallstricke hat
- usw.
Dann könnte man eventuell ja doch in weniger Zeit mit fehlerfreien features rauskommen. Ähnlich wie C++ einem bei vielem hilft, was bei C nervig ist, könnte eine solche Sprache einen ja noch mehr von den low-leveligen Details befreien.
@Ethon: Ja, oder außerhalb des "kingdom of nouns" dann halt C#, Clojure, D, F#, Go, Haskell, Lisp, Python, Ruby, Rust oder Scala.
Na gut, die Hälfte fliegt natürlich für viele direkt raus, weil dynamische Typisierung ja angeblich für große Projekte nix taugt, übrig bleiben ja trotzdem noch welche.
-
Dobi schrieb:
@Marthog: Naja, man könnte sich ja eine Sprache vorstellen, die zwar at runtime langsamer ist, aber dafür
- durch ein strengeres Typsystem zu noch mehr Genauigkeit zwingt
- keine memleaks zulässt
- nicht erlaubt über arraygrenzen hinauszulatschen
- den edit-Compile-test-cycle nicht so in die Länge zieht, dass man zwischendurch immer wieder aus Langeweile ins Forum guckt
- weniger legacy-Fallstricke hat
- usw.
Dann könnte man eventuell ja doch in weniger Zeit mit fehlerfreien features rauskommen. Ähnlich wie C++ einem bei vielem hilft, was bei C nervig ist, könnte eine solche Sprache einen ja noch mehr von den low-leveligen Details befreien.So eine Sprache haette ich sehr gerne, allerdings sind die einzigen beiden Sprachen, die die Bedingungen erfuellen und mir persoenlich zusagen Haskell und Rust. Fuer Haskell ist es mir oft zu viel Aufwand, alles funktional auszudruecken, besonders wenn man mit Dateiformeten oder grafischer Ausgabe hantiert und Rust bietet noch keine Garantie fuer Langzeitsupport.
P.S. Langsamer muessen sie gar nicht mal sein, weil ein strikteres System mehr Optimierungen zulaesst.
-
Dobi schrieb:
volkard schrieb:
Und die, die man brauchen kann, sind in jeder Sprache produktiv, aber man tut gut daran, ihnen C++ zu geben, weils damit schnell geht und einfach wenig Fehler ausgeliefert werden.
Bezieht sich das jetzt nur auf den Vergleich mit C oder auch auf andere Sprachen? Weil generell würd ich schätzen, gehört C++ ja schon eher auch zu den Sprachen, bei denen man Entwicklerzeit opfert um CPU-Zeit zu sparen. Und ich habe den Eindruck, dass man viele Projekte, bei denen Performance ziemlich egal ist, mit weniger Entwicklungsaufwand fehlerfreier in anderen Sprachen umsetzen kann. Meinst du nicht?
Ich beziehe mich insbesondere auf die Skriptsprachen, mit denen man ein Projekt anfängt und es sofort unerweiterbar ist.
Fehlerfreiheit als Designziel kommt beim Lesen von Struppi&Meyers doch bärenstark rüber. Die Sprache ist genau dafür gemacht. Daß man dafür nichtmal Laufzeit ausgeben muss, ist elend prima. Und ein Marketing-Nachteil(!!!), wenn ich Dich so höre. "Nur bittere Medicin kann gut sein." "Wenn man nichts dafür bezahlz, kann es auch nichts taugen."…
-
@volkard: OK, Fehlerfreiheit als Designziel kommt besonders in den Effektive-Büchern sehr gut rüber, finde ich auch.
Nur habe ich den Eindruck, dass es noch viel besser/schicker gehen müsste.
Wenn es das dann auch noch ohne Laufzeitkosten gibt, umso besser. Mit C++ gewinnt man ja auch vieles an Sicherheit/Einfachheit gegenüber C ohne dass es dadurch langsamer wird.Den Geschwindigkeitsverlust hatte ich nur erwähnt, weil ich oft die Performance als einziges Argument für C++ gegenüber anderen Sprachen höre. Und das finde ich bei vielen Anwendungen fehl am Platz.
In welcher Sprache man nun sicherer/einfacher programmieren kann, ist natürlich auch Geschmacks-/Gewöhnungssache. Ich merke nur bei mir, dass ich obwohl ich in C++ mit Abstand die meiste Erfahrung habe und das meiste drüber gelesen habe, mich mittlerweile in Python, Haskell und Elm irgendwie produktiver fühle.
-
Dobi schrieb:
@Marthog: Naja, man könnte sich ja eine Sprache vorstellen, die zwar at runtime langsamer ist, aber dafür
- durch ein strengeres Typsystem zu noch mehr Genauigkeit zwingtHä? NOCH mehr? Wann isses Dir zum letzten mal vorgekommen, daß strengere Typen Dir einen wichtigen Fehler aufgedeckt hätten? Ich grüble gerade und kein Fall fällt mir ein.
Dobi schrieb:
- keine memleaks zulässt
Mädel, memleaks kommen doch in C++ bereits nicht mehr vor. Seit Jahrzehnten übrigens. Für diese Sicherheit muss man keine Laufzeitkosten eingehen.
Dobi schrieb:
- nicht erlaubt über arraygrenzen hinauszulatschen
dito nebst facepalm
Dobi schrieb:
- den edit-Compile-test-cycle nicht so in die Länge zieht, dass man zwischendurch immer wieder aus Langeweile ins Forum guckt
dito. Ich kann Dir sagen, wo man einen i7 mit 16G kauft und SSD kauft. Wenn Du damit noch Sorgen hast, liegt der Fehler bei Dir.
Dobi schrieb:
- weniger legacy-Fallstricke hat
Jo, die Kompatibilität mit altem Code ist das Riesenproblem.
Dobi schrieb:
@Ethon: Ja, oder außerhalb des "kingdom of nouns" dann halt C#, Clojure, D, F#, Go, Haskell, Lisp, Python, Ruby, Rust oder Scala.
Na gut, die Hälfte fliegt natürlich für viele direkt raus, weil dynamische Typisierung ja angeblich für große Projekte nix taugt, übrig bleiben ja trotzdem noch welche.Hauen wir netterweise auch noch Sprachen weg, in denen man RAII nicht machen kann. Wor wollten doch typische Aus-Versehen-Fehler ein wenig vermeiden.
-
Dobi schrieb:
@volkard: OK, Fehlerfreiheit als Designziel kommt besonders in den Effektive-Büchern sehr gut rüber, finde ich auch.
Nur habe ich den Eindruck, dass es noch viel besser/schicker gehen müsste.Jo, die Rustikusse haben den (guten und notwendigen) Anfang gemacht. Leider weit am Ziel vorbei.
Unnötig weit von der Hardware entfernt.
Mystisches Patternmatching ohne daß ich auch nur entfernt einsehen könnte, welchen Sinn das Sprachmittel. Proggern wie in Prolog? Ballmer-Peak nicht getroffen sag ich da mal.
Templates abgelöst durch Makros, die doch dann viel zu schwach sind.Naja, ich hab ja Zeit. Noch schnell 10-20 Rust-Nachfolger abwarten und dann wird einer dabei sein, der was taugt. Der wird sich aber nicht durchsetzen, es wird kaum Libs geben.
