Wieso gibt es keine gute Programmiersprache?
-
turbo autist schrieb:
Jetzt mal ohne Witz, Computer Science existiert schon mehrere Dekaden und die Leute haben es noch immer nicht hinbekommen, eine gute Programmiersprache zu schreiben?
Doch haben sie, lustigerweise sehr früh am Anfang. Aber die Computer waren noch zu schwach und man musste sich erst mal mit C und Konsorten herumschlagen. Nach und nach wurden dann aber langsam die alten Konzepte auch in modernere Sprachen übernommen.
Leider sind die Leute heute so in ihrem Klammerwald gefangen, dass sie die perfekte Syntax nicht erkennen, weil sie zu viele Klammern sehen.
-
und worin besteht nun genau der durchgreifende syntaktische Vorteil von "klammerfreien" Sprachen?
Gut, man kann sich mit Python hin und wieder eine vergnügliche Debugging-Sitzung bereiten, falls man beim Editieren in der Hektik unbemerkt eine Tab-Einrückung gelöscht hat und damit versehentlich den Programmablauf verändert, aber sonst?
-
hmm.. mein Satz mit dem Klammerwald war etwas wirr und unsinnig...
Ich wollte darauf anspielen, dass viele Außenstehende ein Problem mit der Lisp/Scheme-Syntax haben aber nicht mit Java oder C++.
-
gute Programmiersprachen gibt es. Perfekte nicht.
Wie denn auch? Dafür müsste man eine Sprache veröffentlichen, warten was die Community nach Monaten und Jahren dazu für Feedback gibt, dann alles verwerfen und die Sprache neu aufsetzen.
Dann, wenn wieder ein neues Feature nötig ist, dieses so einbauen, dass es möglichst gut ins Gesamtbild passt, Abwärtskompatibilität ist egal.
Und so weiter.Ich persönlich finde mit guten Sprachen mein Auslangen, eine Programmiersprache ist ein Werkzeug, und jedes Werkzeug hat seine Vor und Nachteile und Einsatzbereiche. Dass trotzdem so emotional drüber diskutiert wird liegt wohl in den Genen der Informatiker
-
hfghfg schrieb:
gute Programmiersprachen gibt es. Perfekte nicht.
Aber manche sind nah dran an der Perfektion, zum Beispiel LISP, Smalltalk, Prolog.
-
Das hängt dann wohl von der persönlichen Definition von "Perfekt" ab.
-
"perfekt" heißt ja "vollendet" - was fehlt denn in LISP, Smalltalk oder Prolog?
-
Der Speed von C++14!
-
ich meine an Sprach-Features wie Syntaxelementen
-
Da gibts tatsächlich nichts zu mäkeln.
-
Trotzdem sind diese 3 Programmiersprachen alles andere als "Allrounder", d.h. z.B. für Kernel-, Treiber- oder Grafikprogrammierung doch eher nicht geeignet...
Es sind eher Lehrsprachen bzw. für bestimmte Themenfelder (wie KI) zu gebrauchen.
-
Aha. Dann zähle mal die Kernel+Treiber auf, die in Java oder C++ geschrieben sind.
Bei C++ dann natürlich nur die, die kein Fake-C sind.
-
Magenta ist zu einem Teil in C++ geschrieben.
-
Was ist Magenta?
-
Wutz schrieb:
Aha. Dann zähle mal die Kernel+Treiber auf, die in Java oder C++ geschrieben sind.
Bei C++ dann natürlich nur die, die kein Fake-C sind.Es gibt zwei Gründe, warum die meisten Kernel in C geschrieben sind:
1. Sie sind in einer Zeit entstanden, als es C++ nicht gab oder C++ noch nicht standardisiert war.
2. Deren Programmierer kein OOP verstehen oder verstehen wollen (da gibt es genug prominente Coder, wie Linus Torwalds oder John Carmack. Wobei John C. irgendwann doch noch OOP gelernt hat und dann begeistert C++ einsetzte. Linus ist dagegen ein seniler Mann, der nicht fähig ist aus seiner C-Kiste auszubrechen).
Aber um deine Frage zu beantworten: BeOS ist komplett in C++ programmiert. Dessen Opensource-Nachfolger Haiku-OS kannst du dir auch den Code anschauen. Und BeOS galt damals als das schnellste OS mit GUI.
So viel dazu, das es kein ernsthaftes OS gibt, das in C++ implementiert ist.
-
Magenta ist der Kernel des Betriebssystems Fuchsia. Der Kernel ist in C und in C++ geschrieben und das Userland afaik weitgehend in C++.
-
Das die Kernel und Userland (Tools) in C sind, ist doch alles historisch und nicht damit zu begründen, das C++ nicht das richtige Werkzeug wäre. Es ist ja auch verständlich, das man etwas, das viele Mannjahre Entwicklung gekostet hat, nicht einfach so neu implementiert. Wenn der alte bisherige Code in C funktioniert, kann man ihn so belassen.
Wir haben hier auch produktiven Cobol-Code (sehr viel Cobol-Code!) laufen. Den kann man einfach nicht in einer modernen Sprache neu implementieren, es wäre wirtschaftlicher Wahnsinn. Der Cobol-Code wird auch gepflegt und erweitert. Aber alles drum herum, was neu entwickelt wird, wird nicht in Cobol begonnen.Ein gutes Beispiel ist der GCC: der GCC wird seit einiger Zeit in C++ implementiert. Weil bis auf ein paar alte Männer, die ihre eingerostete Denkweise nicht ablegen können oder wollen, haben jüngere Entwickler kapiert, das man mit C++ ein mächtigeres Werkzeug hat. John Carmack hat damals auch gesagt, das C das geilste ist. Als er dann C++ verstanden hat, hat er seit dem seine Engines (ab Doom 3) in C++ programmiert. Der Mann hat sich weiter entwickelt.
-
tldr;
-
Mein Senf schrieb:
tldr;
Bezogen auf den ganzen Thread.
-
Artchi schrieb:
2. Deren Programmierer kein OOP verstehen oder verstehen wollen (da gibt es genug prominente Coder, wie Linus Torwalds oder John Carmack. Wobei John C. irgendwann doch noch OOP gelernt hat und dann begeistert C++ einsetzte. Linus ist dagegen ein seniler Mann, der nicht fähig ist aus seiner C-Kiste auszubrechen).
Geil. Wenn man also die Argumente anderer Personen nicht versteht, dann sind diese Personen gleich senil.
Leute, ich habe den Zeloten hier gefunden.Jonathan Day schrieb:
Originally, C++ interfaces were planned for. If you look at the early kernels, you’ll see provision was made for C++, but nobody ever used it.
The C++ library is very awkward if you’re writing an OS kernel, as you have to not use anything that requires an OS kernel. With Linux, you’ll notice that flags are set to prevent the linking in of any runtime library.
C++ generates large code. When Linux was first written, the top-line machines were 386SX’ with only a few megabytes of expanded memory. No co-processor was needed, small memory models were supported, no swap space was available. Fitting the compiler into memory along with the source was a challenge.
These machines were also very slow. You would not want to use a 16MHz computer today. Put it like this, compiling X11R4 took me about a day and a half. That’s just X Windows. The Manchester Computing Centre distribution included that, the kernel, a bunch of system utilities, games, possibly LaTeX as well, I can’t remember. I’m honestly amazed they got the distro compiled the same year.
There really wasn’t anything you would want or need objects for and most of the flexibility was introduced into C++ after 1991. In fact, I still can’t think of anything you’d want or need objects for.
Later, when Linux started being ported to other architectures (IIRC, the Atari ST was one), you had further constraints - existing source code had to compile on other platforms with no modification other than the architecture-specific elements. That meant that the compiler had to work on those platforms, reliably, within memory constraints, and generate clean binaries.
C is actually very flexible. Since nothing can be pulled in (so no STL, no libraries, nothing) and therefore everything had to be written from scratch, Linus, AC and the rest of the gang were absolutely free to write anything, any utilities, any macros, anything, they were at liberty to write pseudo-objects if they wanted. Not only did they not do so, they’ve belted people over the knuckles for code consolidation where this resulted in performance degradation. The large number of stacks, queues, etc, are not accidents but intentional to tune each implementation to the precise task involved with no slow-down.
The main competitor to Linux, at the time, was William Jolitz’ 386BSD (written in C and based off the BSD4.3 tapes). A second competitor, HURD (based off the MACH tapes), also existed around that time, along with commercial PC Unix’ from Dell and SCO. 386BSD died and was replaced by BSDI (which got sued to oblivion) and FreeBSD. Both 386BSD and FreeBSD were fairly solid pieces of code back then, working robustly and able to do most of the stuff people needed done, but they did have some performance issues. HURD got nowhere and eventually died from a surfeit of microkernel.
Linux survived because it was clean, compact and blazingly fast. It was also very easy to read and the number of programmers was extremely large (a few thousand by version 1, I think, and a few hundred thousand today).
FreeBSD also survived because, although there was bloat, it was stable and did most of the stuff people needed — and, again, by being written in C, was accessible to a very large number of programmers.
These days, C is still popular with OS developers, but for slightly different reasons. There are program validators for C, which means specialist kernels that are proven correct can be developed. Indeed, are. C is also very good at machine-level operations, so has displaced Forth as the language of choice for hardware developers. Since hardware developers are, by default, the best people at writing hardware drivers, you obviously want to appeal to them.
Aber hey, vielleicht lassen wir den senilen Mann auch mal zu Wort kommen?
Linus Torvalds schrieb:
In fact, in Linux we did try C++ once already, back in 1992.
It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
The fact is, C++ compilers are not trustworthy. They were even worse in
1992, but some fundamental facts haven't changed:- the whole C++ exception handling thing is fundamentally broken. It's
_especially_ broken for kernels.
- any compiler or language that likes to hide things like memory
allocations behind your back just isn't a good choice for a kernel.
- you can write object-oriented code (useful for filesystems etc) in C,
_without_ the crap that is C++.In general, I'd say that anybody who designs his kernel modules for C++ is
either
(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.Feel free to make up (d).
Und zumindest mit (b) kann ich ihm komplett zustimmen. Ich hatte letztens erst eine Diskussion darüber, wie wenn man alles wegnimmt, was in C++ komfortabel ist - STL, Exceptions, Templates - dass man dann im Grunde nur C hat. Mit einer anderen Syntax, klar. Aber effektiv nur C. Ein C, das zudem noch schwieriger zu debuggen ist.
Erinnert mich irgendwie an die Schnapsidee, die Sun mal hatte - einen Treiber in Java in den Kernel tun. Oracle hat den Blogeintrag nicht mehr, aber das Zitat habe ich noch gefunden:
The Java version took 178 microseconds and the C version took 63 microseconds. When a GC occurred during a copy, the Java version took 230 microseconds.
Artchi schrieb:
Aber um deine Frage zu beantworten: BeOS ist komplett in C++ programmiert.
Woher nimmst du diese Information?
Wikipedia schrieb:
Closed Source
...
The API was written in C++ [...]API != Kernel. Oder gehört der Kernel jetzt nicht mehr "komplett" zu BeOS?
