Programmieren ohne Header Files

[darktrym]

Apple/LLVM hat ein Vorschlag präsentiert wie man das vermurkste Konstrukt Header Files besser umsetzt, nämlich via Modules(recht pythonisch).
Sehr interessant zum nachlesen: Die News, die Vortragsfolien

 

[Kamikaze]

Um ehrlich zu sein vermisse ich Header Files in anderen Sprachen.

In C++ bricht man mit inline und templates ständig das Konzept. Leider. Aber zumindest in C, finde ich Header Files uneingeschränkt gut.

 

[Yamagi]

Ich weiß es nicht... Ich halte (bezogen auf C, nicht C++) eigentlich den von Poul-Henning Kamp gemachten Vorschlag noch immer am besten. Lasst C einfach C sein und hört auf, an der Sprache etwas verbessern wollen. C ist sehr reif, C ist sehr verbreitet und C89 wird auch in 50 Jahren nicht schlecht sein. Schon die neueren beiden Standards C99 und C11 haben mehr Verwirrung als Verbesserung gebracht, zukünftige Standards werden dort sicher nicht anders sein. Steckt die Energie besser in ein C2, was zu C sehr ähnlich ist, aber nicht den Anspruch auf vollständige Rückkompatiblität auf Source-Ebene erhebt. Damit könnte man endlich historische Fehler (z.b. das Fehlen "echter" Arrays) ausbügeln, längst überholte Dinge abschaffen und aktuell benötigte Funktionen sauber implementieren. Altsoftware würde in C bleiben, neue Software in C2 entwickelt werden.

 

[darktrym]

Ich kann auf das Präprozessorprinzip gerne verzichten, macht die Dinge nicht einfacher und stammt aus einer Zeit bei den Speicher und Rechenleistung arg beschränkt waren und wirklich nicht mehr zeitgemäß sind.Und zu der Kompat., es gibt immer wieder Brüche in den Sprachen.

 

[-Nuke-]

Ach, sollen sie doch ruhig machen. Programmiersprachen sind doch eh der größte Fuckup den man finden kann. Jeder meint er könne es besser und schreibt eine eigene Sprache und wenn etwas Zeit vergeht, schreibt man vllt. auch noch eine zweite weil man es "noch besser" kann. Und im Endeffekt findet man dann trotzdem nur eine C/C++ Abart wieder.

Und der Großteil nimmt eh C/C++ wegen der "besseren Performance"...

Die ganzen "neuen" Meta-Sachen wie Annotationen und Co. in Java und C# sind geil weil sie den Code verkürzen, Closures sind toll und Java soll sie auch bald bekommen?
Haha... Sprachen wie Scheme lachen sich den Arsch ab. Trotzdem nutzt sie kaum einer, weil eben funktional und nicht "C-like" ist und somit fehlt auch sämtliche Toolchain-Unterstützung.

Ich finde, bevor man eine neue Sprache baut, sollte man sich vllt. erst mal alte Sprachen noch mal genau anschauen.

Will damit jetzt nicht sagen, dass ich überall Scheme haben will, aber ich gucke mir die gerade für die Uni an und bin erstaunt wie mächtig diese Sprache ist, obwohl sie verdammt alt ist.

 

[ralli]

Egal was geschrieben, angeblich modern, neu erfunden oder gar verschlimmbessert wird. Hochleistungssoftware wird noch immer in C oder C++ geschrieben. Kompetenz in C oder C++ zu haben, ist und bleibt auch weiterhin eine Investition in die Zukunft und veraltet nie!

 

[-Nuke-]

Hochleistungssoftware wird noch immer in C oder C++ geschrieben.

Ich würde eher sagen "Noch immer in Fortran". Gerade im wissenschaftlichen Bereich. In der Physik kommt auch gerne Mathematica zum Einsatz.

 

[Azazyel]

Lasst C einfach C sein und hört auf, an der Sprache etwas verbessern wollen.

Dem kann ich nur zustimmen. Man muss sich als Negativbeispiel nur das Frankenstein-Konstrukt namens C++11 anschauen.

Jeder meint er könne es besser und schreibt eine eigene Sprache und wenn etwas Zeit vergeht, schreibt man vllt. auch noch eine zweite weil man es "noch besser" kann. Und im Endeffekt findet man dann trotzdem nur eine C/C++ Abart wieder.

There are only two kinds of programming languages: those people always bitch about and those nobody uses.

Und der Großteil nimmt eh C/C++ wegen der "besseren Performance"...

Ein herrlicher Satz - immer wieder gern geäußert von Menschen, die Just-in-time-Kompilierung verschlafen haben.

Trotzdem nutzt sie kaum einer, weil eben funktional und nicht "C-like" ist und somit fehlt auch sämtliche Toolchain-Unterstützung.

Leider lassen sich viele Probleme in der realen Welt nicht in schöne und saubere Formeln verpacken, sondern benötigen hässliche Sachen wie Zustände, womit man wieder bei imperativen Konstrukten landet. Die kann man zwar z.B. mit Monaden unter den Teppich kehren und so tun, als wäre die Welt hübsch, aber gewonnen hat man nichts.

Trotzdem würden/werden natürlich viele Mainstream-Sprachen von funktionalen Konstrukten wie Closures profitieren.
Leider macht die mangelhafte Toolchain-Unterstützung Scheme für komplexe Projekte leider unproduktiver als Mainstream-Sprachen.

Ich finde, bevor man eine neue Sprache baut, sollte man sich vllt. erst mal alte Sprachen noch mal genau anschauen.

Das haben doch die Designer der heute verbreitesten Sprachen doch gemacht und erkannt, dass manche Features (z.B. Bequemlichkeit (Garbage Collection), eine vernünftige Standardbibliothek oder Ähnlichkeit mit bereits verbreiteten Sprachen) wichtiger sind als andere, die ihren Vorteil in der Praxis kaum ausspielen können.

Rückblickend sind natürlich viele Entscheidungen der Sprachdesigner unsinnig; teils weil es schlicht Fehlentscheidungen sind, teils weil sich die Voraussetzungen geändert haben.

Will damit jetzt nicht sagen, dass ich überall Scheme haben will, aber ich gucke mir die gerade für die Uni an und bin erstaunt wie mächtig diese Sprache ist, obwohl sie verdammt alt ist.

Wie ich selbst erfahren musste, sind die Unterschiede zwischen Uni und der realen Welt enorm. Je komplexer die Probleme werden, desto weniger bestimmt die Sprache allein as Ergebnis. Mit einer mäßigen Sprache mit guter Toolchain erreicht man ein besseres Ergebnis (Produktivität, Performance, Wartbarkeit, etc.) als mit einer guten Sprache mit schlechter Toolchain.

Egal was geschrieben, angeblich modern, neu erfunden oder gar verschlimmbessert wird. Hochleistungssoftware wird noch immer in C oder C++ geschrieben.

Definiere Hochleistungssoftware. Heutzutage werden selbst High-Frequency-Trading-Systeme, bei denen es auf Mikrosekunden ankommt, in Sprachen wie Java oder C# geschrieben.

Der Trend meines Eindrucks eher in die andere Richtung. Ich habe in diesem Jahrtausend persönlich kein einziges Greenfield-Projekt erlebt, das noch in C oder C++ gestartet wurde (abgesehen von Hardware-nahen Sachen).
In den meisten komplexen Projekten erreichen die JIT-Compiler von Haus aus eine bessere Performance, als man unter C oder C++ mit vertretbarem Aufwand - wenn überhaupt - je hinbekommt.

Kompetenz in C oder C++ zu haben, ist und bleibt auch weiterhin eine Investition in die Zukunft und veraltet nie!

Allein aufgrund der schieren Verbreitung (und dem Verständnis für Low-Level-Programmierung, das man beim Erlernen gewinnt) ist zumindest C grundsätzlich empfehlenswert.

Bei C++ wird es schon fraglicher - je nachdem, in welche Richtung man sich professionell entwickeln möchte. Es gibt Bereiche, in denen C und C++ praktisch nicht-existent sind.

 

[Kamikaze]

Ein herrlicher Satz - immer wieder gern geäußert von Menschen, die Just-in-time-Kompilierung verschlafen haben.

Wenn ich so was lese muss ich weinen.

 

[Crest]

Nicht nur du. Das letzte Mal als ich mit einem Entwickler von derartiger Tradingssoftware gesprochen habe war er dabei in C++ und Cuda geschrieben Code so zu optimieren, das es von Quad SLI Systemen gut profitiert.

 

[Azazyel]

Nicht nur du. Das letzte Mal als ich mit einem Entwickler von derartiger Tradingssoftware gesprochen habe war er dabei in C++ und Cuda geschrieben Code so zu optimieren, das es von Quad SLI Systemen gut profitiert.

Was aber weniger über die Performance von C/C++ sondern mehr über die enorme Performance der GPUs bei parallelisierbaren Aufgaben aussagt - weswegen ich in meinem Beitrag auch extra "abgesehen von Hardware-nahen Sachen" geschrieben habe.

 

[Kamikaze]

JIC macht interpretierte Sprachen schneller (beim 2. Aufruf von Code, beim 1. wird's erst mal langsamer). Aber doch nicht so schnell wie Maschinencode.

Ob C/C++ Vorteile hat hängt vor allem davon ab wie gut der Compiler in der Lage ist const auszunutzen.

Mangels const sehe ich für andere Sprachen kaum eine Handhabe performanter als C/C++ zu sein.

 

[Azazyel]

JIC macht interpretierte Sprachen schneller (beim 2. Aufruf von Code, beim 1. wird's erst mal langsamer). Aber doch nicht so schnell wie Maschinencode.

Das kommt auf den Einzelfall an. JIC kann zur Laufzeit Optimierungen vornehmen, die einem Compiler prinzipiell nicht möglich sind (vgl. Comparison of Java and C++).

Mangels const sehe ich für andere Sprachen kaum eine Handhabe performanter als C/C++ zu sein.

Aus meiner Erfahrung heraus lassen sich kleine Problemstellungen problemlos so optimieren, dass sie unter C++ schneller laufen.
Je komplexer eine Anwendung wird, desto weniger Low-Level-Optimierungen kann man unter C++ vornehmen. Irgendwann müssen es die (im Vergleich zu nativen Konstrukten) langsame STL und Boost sein, sollen nicht triviale Bugs die gesamte Anwendung in den Abgrund reißen. Ab dann ist auch der Performance-Vorteil von C++ vorbei und die interpretierten Sprachen gewinnen die Oberhand (vgl. Java vs. C performance).

 

[Frank]

@Azazyel
Bist Du ein Java Fanboy der in der Banken- und Versicherungswelt arbeitet?

 

[ralli]

Gut ich kann nur beschreiben, was ich als Amateur unter Euch Profis unter Hochleistungssoftware verstehe. Das ist für mich hardwarenahe Software, wie Treiber oder Ähnliches, wo es auch auf Performanz ankommt. Software für den Produktiveinsatz. Na, mit euch Fachkundigen kann ich nicht mithalten, wenngleich ich seit 32 Jahren programmiere, Basic, Turbo Pascal, Clipper unter DOS und seit 1996 GUI Programmierung mit Delphi 3 bis Delphi 7 (Objekt Pascal) Kylix und Lazarus, Visual Basic .net, Gtk und Gtk+, Qt 4 und ein bißchen Perl und Php. Selber habe ich mit den Hochsprachen nur berufliche Erfahrungen speziell in der Datenbankprogrammierung für die Qualitätssicherung sammeln dürfen. Der technische Bereich war nie so mein Ding... oder ich bin damit einfach nicht in Berührung gekommen. Und ich bin jetzt bei den Compilern auch nicht so in die Tiefe gegangen, das ich die technischen Spezifikationen im Einzelnen kenne. Mir fällt nur auf, das der GCC grottenlangsam ist bei Qt, aber mein PC ist ja auch nicht mehr der Jüngste. Ich habe großen Respekt vor Euren Kenntnissen, da kann ich allerdings nicht mithalten. Aber dafür, das ich keine Informatik studiert habe und mir alles autodidaktisch selber angeeignet, bin ich ganz zufrieden. Zur Zeit arbeite ich an einem Qt Workshop für die GUI Programmierung. Einfach nur aus Freude.

 

[Azazyel]

@Azazyel
Bist Du ein Java Fanboy der in der Banken- und Versicherungswelt arbeitet?

Fanboy? Wohl kaum.

Ich bin eigentlich systemnaher Unix/C++-Entwickler, dessen beruflicher Werdegang ihn in letzten Jahren auch in andere Bereiche getragen hat.
Dort musste ich dann leider feststellen, dass C++ für sehr viele Anforderungen in der Praxis nur noch zweite oder dritte Wahl ist.

Manchmal kommen aber hier Aussagen im Brustton der Überzeugung, bei denen man merkt, dass derjenige noch nie in seinem Leben bei einem größeren Projekt mit realen Anforderungen gearbeitet hat. Dann fühle ich mich doch dazu genötigt, ein paar Erfahrungen aus der Praxis beizusteuern.

 

[Frank]

Ich bin eigentlich systemnaher Unix/C++-Entwickler, dessen beruflicher Werdegang ihn in letzten Jahren auch in andere Bereiche getragen hat.

Gott sei Dank. Kein Java-Fanboy der sich der Banken und Versicherungswelt verschrieben hat

 

[Sickboy]

Gott sei Dank. Kein Java-Fanboy der sich der Banken und Versicherungswelt verschrieben hat

Was wäre so schlimm daran?

 

[Frank]

Was wäre so schlimm daran?

Eigentlich nichts. Eigentlich.
In meinem engsten Freundeskreis arbeiten 5 in der Kaffeebohnen-Java-Welt bei Banken oder Versicherungen.
Ich kann mit Ihnen nicht über FreeBSD, Monaden, Templates, Erlang und Lennart Poettering reden...
und sie nicht mit mir über Eclipse, Eskalationen, Pflichtenhefte, Kantinenessen und die jax.

Ich steh mehr auf C++....vielleicht nur weil ich die Sprache nach vielen Jahren immert noch nicht kann und ich was Programmiersprachen angeht masochistisch veranlagt bin.

So nun aber wieder zurück zum Thema.

 

[Kamikaze]

Was wäre so schlimm daran?

Verrat an der Menschheit.

 

[Rakor]

Könnten wir zum Thema zurück kommen bitte? Die berufliche und persönliche Entwicklung der User ist hier nicht Gegenstand der Diskussion.

 

[Crest]

Java Codemonkeys zurück in den Zoo!

 

[Azazyel]

Verrat an der Menschheit.

Sprach der Mensch, der seinen Forscherdrang in Projekten zur nutzlosen Verbrennung von fossilen Rohstoffen auslebt.

Aber auf die Gefahr hin, wieder on-topic zu werden: ich würde mich ja freuen, wenn die Modularisierung zum Erfolg führt - allein die Erfahrung lässt mich befürchten, dass dabei subtile Inkompatibilitäten eingeführt werden, die C++ um noch eine Komplexität erweitern.

 

[Sickboy]

Sprach der Mensch, der seinen Forscherdrang in Projekten zur nutzlosen Verbrennung von fossilen Rohstoffen auslebt.

Touché.

 

[h^2]

Wie wäre es stattdessen mit Programmieren ohne .C-Dateien? Wenn man schön stl und metaprogramming macht, braucht man nur ein kleine c-Datei...