Wieso gibt es keine gute Programmiersprache?
-
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?
-
@Artchi
Toll, wie gut du Erkenntnisgewinne alter Männer von außen beurteilen kannst.
Ich kann das nicht.
Könnte es nicht auch sein, dass Torvalds trotz seiner von dir unterstellten Senilität mehr von Kernelprogrammierung versteht als du und ich zusammen es jemals tun werden und seinem Urteil demzufolge grundsätzlich mehr Praxisrelevanz zukommen muss?
Ich beurteile nur das, was ich sehe.
Und ich sehe, dass z.B. Dalvik auch überwiegend in C und eben nicht in C++ entwickelt ist.
Und allgemein alle mir bekannten VMs auch.
Und die Treiber aller meiner aktuellen Grafikkarten auch.
Und diverse Schnittstellen aus Programmiersprachenkontexten heraus werden nach wie vor C-basiert angeboten und, wenn überhaupt, zusätzlich in C++. (JNI,OracleDB,LUA,Matlab,...)Linus vs C++
und da wir grad dabei sind
Linus: Java sucksEs spricht auch überhaupt nichts dagegen, eine Symbiose - jede Sprache in ihrer ureigensten Domäne - einzusetzen. Smalltalk beispielsweise hat eine C VM, die Sprache selbst bietet pure OO - eine ideale Symbiose.
Es gibt natürlich auch Leute, die sich durchaus Gedanken über C in der heutigen Zeit gemacht haben - aber im Gegensatz zum Theoretiker Stroustrup - zu anderen Entscheidungen gekommen sind - und die heißt eben nicht C++:
Interview with Ken Thompson
By Andrew Binstock, May 18, 2011Post a Comment
The creator of UNIX discusses writing UNIX, the Go language, and collaborating with Dennis Ritchie
The Japan Prize, one of the highest honors awarded for outstanding contribution to science and technology, was awarded jointly this year to Ken Thompson and Dennis Ritchie for the creation of UNIX. The prize is normally given to the recipients at a lavish banquet in Tokyo attended by the emperor. However, due to the April earthquake and tsunami, the prizes this year were distributed at the honorees' place of work. I was able to attend the ceremony for Ken Thompson, held at Google headquarters, where he currently works. After the ceremony, he consented to this exclusive interview.DDJ: Congratulations on winning this prize.
KT: Thanks.
Developing UNIX
DDJ: You've received a lot of awards over the years for UNIX. At what point in UNIX's development did it become clear it was going to be something much bigger than you'd anticipated?KT: The actual magnitute, that no one could have guessed. I gather it's still growing now. I thought it would be useful to essentially anybody like me because it was not built for someone else or some third party. That was a perjorative term then. It was written for Dennis and me and our group to do its work. And I think it would have been useful to anybody who did the kind of work that we did. And therefore, I always thought it was something really good that was going to take off.
Especially the language [C]. The language grew up with one of the rewritings of the system and, as such, it became perfect for writing systems. We would change it daily as we ran into trouble building UNIX out of the language and we'd modify it for our needs.
DDJ: A symbiosis of sorts…
KT: Yeah. It became the perfect language for what it was designed to do. I always thought the language and the system were widely applicable.
DDJ: In the presentation today, it mentioned that UNIX was open source. Was UNIX open source from the beginning?
KT: Well there was no such term as "open source" then.
DDJ: I was under the impression that UNIX really became open source with the Berkeley distribution.
KT: No, we charged $100, which was essentially the reproduction cost of the tape, and then send it out. And we distributed, oh, probably close to 100 copies to universities and others.
Go Language
DDJ: Skipping several decades of work, let's speak about Go. I was just at the Google I/O Conference, where it was announced that Go will be supported on the Google App Engine. Does that presage a wider adoption of Go within Google, or is it still experimental?KT: It's expanding every day and not being forced down anybody's throat. It's hard to adopt it to a project inside of Google because of the learning curve. It's brand new and there aren't good manuals for it, except what's on the Web. And then, of course, its label of being experimental, so people are a little afraid. In spite of that, it's growing very fast inside of Google.
DDJ: In the presentation before the awarding of the Japan Prize today, you were quoted on the distinction between reasearch and development. [The former, Thompson stated, was directionless, whereas development had a specific goal in mind.] So in that context, is Go experimental?
KT: Yes. When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research. The three of us got together and decided that we hated C++. [laughter]
DDJ: I think there'd be a lot of people who are with you on that.
KT: It's too complex. And going back, if we'd thought of it, we'd have done an object-oriented version of C back in the old days.
DDJ: You're saying you would have?
KT: Yes, but we were not evangelists of object orientation. [Returning to Go,] we started off with the idea that all three of us had to be talked into every feature in the language, so there was no extraneous garbage put into the language for any reason.
DDJ: It's a lean language, indeed.
Collaboration with Dennis Ritchie
DDJ: Returning to UNIX, for a moment, when you and Dennis worked together, how did that collaboration operate? Were you working side by side?KT: I did the first of two or three versions of UNIX all alone. And Dennis became an evangelist. Then there was a rewrite in a higher-level language that would come to be called C. He worked mostly on the language and on the I/O system, and I worked on all the rest of the operating system. That was for the PDP-11, which was serendipitous, because that was the computer that took over the academic community.
DDJ: Right.
KT: We collaborated every day. There was a lunch that we went to. And we'd talk over lunch. Then, at night, we each worked from our separate homes but we were in constant communication. In those days, we had mail and writ (pronounced 'write'), and writ would pop up on your screen and say there was a message from so-and-so.
DDJ: So, IM essentially.
KT: Yes, IM. There was no doubt about that! And we discussed things from home with writ. We worked very well together and didn't collaborate a lot except to decide who was going to do what. Then we'd run and very independently do separate things. Rarely did we ever work on the same thing.
DDJ: Was there any concept of looking at each other's code or doing code reviews?
KT: [Shaking head] We were all pretty good coders.
DDJ: I suspect you probably were! [Laughter]
SCM
DDJ: Did you use any kind of source code management product when working together?KT: No, those products really came later; after UNIX. We had something like it, which we called "the code motel" because you could check your code in but you couldn't check it out! So, really, no we didn't.
DDJ: I bet you use SCM today in your work on Go.
KT: Oh, yes, Google makes us do that!
-
Wutz schrieb:
Ich verstehe nicht, weshalb diese "Kritik" so oft zitiert wird. Auf ihre Essenz eingedampft ist sie lediglich ein plumper Rundumschlag,
der am Ende nicht mehr zu bieten hat als "C++ ist scheisse" und "C++-Programmierer sind scheisse". Ich tendiere eher dazu,
einen Betrag nach dem Inhalt und nicht nach der Person zu bewerten, die ihn verfasst hat, und unter diesem Aspekt ist Linus' "Rant" ganz schön schwach.Finnegan
-
Linus Torvalds hat - quasi in einer one-man-show - sämtliche UNIX-Teams der global Player (IBM,HP,Sun...) brotlos gemacht und in der Praxis bewiesen, dass Kernelprogrammierung in C Hände gehört und nirgendwo anders hin.
Nebenbei hat er auf Open-Source gesetzt in einer Zeit, in der noch kein IT-Manager das Wort kannte.
Linus Torvalds hat in der Praxis bewiesen, dass ein Softwaremonolith nichts Schlechtes und auch in anschließenden Produktiv- und Wartungsphasen beherrschbar ist, und das auch neuerdings mit Git und nicht nur mit Linux.
Die Praxis hat immer recht.
Und die relevante Praxis (milliardenfache Installationen weltweit) nochmal mehr als ein Professoren-Elfenbeinturm:
http://www.pro-linux.de/news/1/9696/tanenbaum-vs-torvalds-reloaded.htmlWarum hat denn Stroustrup (der später übrigens auch Professor geworden ist, im Gegensatz zu o.g. K.Thompson+Pike, die immerhin bei Google angeheuert haben) sein eigenes C++ nicht selbst zur Kernelprogrammierung eingesetzt wenn es dafür doch so phänomenal und unschlagbar geeignet ist?
Die Voraussetzungen waren doch ideal:
- er hat über Jahre in derselben Firma wie K&R gearbeitet
- er hatte Zugriff auf den UNIX-Kernel von K&R usw.
- er hatte den direkten Draht zu den Originalschöpfern
Das kann ich dir sagen:
Weil er keine Ahnung Praxis hatte/hat, er hat es ja noch nicht mal geschafft, eine Referenzimplementierung eines Compilers für sein C++ abzuliefern geschweige denn, mit diesem Compiler was Praxisrelevantes (milliardenfache Installationen weltweit) anzubieten.
Die im Jahrestakt neu entstehenden C++-"Standards" sind nur der Beweis dafür, dass wirklich Praxisrelevantes von Stroustrup "vergessen" wurde; soviel zum Thema, was passiert, wenn sich ein Theoretiker eine neue Programmiersprache ausdenkt (das war, wie schon mehrfach von mir hier (in C-Forum) erwähnt, bei Ritchie anders).Fazit:
Leute, die jetzt behaupten, mit dem jetzigen C++-Standard und irgendwelchen Boost- oder sonstwelchen Erweiterungen sei ein Kernel allgemein übersichtlicher,schneller,besser wartbar etc. zu implementieren sind einfach nur naiv und ignorieren die Leistungsfähigkeit von C in der Hand von Könnern.
Wenn dem so wäre - bitte dann sollen sie es doch anhand zumindest eines praxisrelevanten Beispiels (milliardenfache Installationen weltweit) mal nachweisen, dass und wie man einen C++ Kernel schreibt.
Ich bezweifle, dies in den nächsten Jahrzehnten von jemandem bewiesen zu bekommen.Wenn dir die Torvalds-Ausdruckweise nicht gefällt - nimm es hin - die Menschen sind nun mal (zum Glück!) verschieden.
-
Wutz schrieb:
Linus Torvalds hat - quasi in einer one-man-show - sämtliche UNIX-Teams der global Player (IBM,HP,Sun...) brotlos gemacht und in der Praxis bewiesen, ...
Ich weiss wer Linus Torvalds ist und was er geleistet hat.
Das macht aber diesen speziellen Beitrag von ihm nicht automatisch zu einer qualifizierten Kritik - dafür hat er zu wenig Fleisch und ist zu schlecht begründet.
Die einzigen konkreten Kritikpunkte die dort ansatzweise angerissen werden sind Exceptions und schlechte Implementierungen der Standardbibliothek -
beides Dinge auf die man problemlos verzichten kann wenn es ein Projekt erfordert: Der LLVM-Code z.B. verwendet meines Wissens auch keine Exceptions
und diverse Projekte wie z.B. einige Spiele-Engines verwenden gut begründet an performancekritischen Stellen eigene, spezialisierte Datenstrukturen, statt
die aus der Standardbibliothek, deren Implementierungsqualität man nicht selbst kontrolliert.Beide Kritikpunkte lassen sich problemlos vermeiden, der Rest beschränkt sich auf "ist einfach scheisse". Da muss einfach mehr kommen - und ich bin wahrlich
nicht jemand der sich gut begründeter Kritik verweigern würde oder sich nicht auch davon überzeugen ließe.Der Beitrag des Königs hat in diesem Fall leider keine Kleider.
Finnegan
