Wieso gibt es keine gute Programmiersprache?

Jodocus

Wutz schrieb:

Ich habe im Gegensatz zu dir hier vielfach qualifizierten, standardkonformen und somit superportablen C-Code gezeigt, von dir habe ich noch nicht eine qualifizierte Codezeile gesehen.

Superportabel? Wow! Es ist unglaublich schwierig, mit C portabel zu programmieren, wenn man bedenkt, wie schlecht die Sprache darauf ausgelegt wurde und wie wenige C-Compiler es für verschiedene Plattformen gibt! Merkst du eigentlich, was du schreibst? Außerdem habe ich gesagt, dass du kein ausreichendes Wissen um C++ hast, um es kritisieren zu können, wie du beispielsweise ja hier (aber nicht nur dort) bereits bewiesen hast. Deine C-Kenntnisse sind dafür vollkommen unerheblich.

Wutz schrieb:

Hör auf mit deinem Pubertärgeplärre wenn sich erwachsene C-Programmierer unterhalten.

Pubertär ist einzig deine trotzige Verteidigungshaltung ggü. C. Solches Verhalten beobachtet man in der Regel bei jungen Programmierern, die nicht viel mehr als eine Sprache können und für das Ei des Kolumbus halten, das sie verteidigen müssen.

Wutz schrieb:

Halt einfach die Klappe und trolle dich dahin wo du herkamst.

Wenn es dicht stört, kannst du jederzeit die Debatte verlassen. Es kam von dir sowieso nichts Konstruktives mehr.

HarteWare

Eine gute Programmiersprache wäre doch, wo ich im Klartext beschreibe was mein Programm tun soll und der Compiler spuckt das fertige Programm aus

HarteWare schrieb:

Eine gute Programmiersprache wäre doch, wo ich im Klartext beschreibe was mein Programm tun soll und der Compiler spuckt das fertige Programm aus

Aber genau das tun doch alle gängigen Programmiersprachen? Oder meinst du mit "im Klartext", dass die Sprache keine eigene Grammatik hat, sondern sich der deutschen oder der englischen Grammatik bedient?

könnte mal bitte jemand ein Code Review machen:

if(thread.title.match("(gute|schlechte|beste) Programmiersprache"))
{
   flamewar_probability = 1.0f - geometric_distribution(thread.numberMessages);
}

Finnegan

Wutz schrieb:

Bewerte den Inhalt nicht nach seinem Ausdruck.

"Da muss mehr kommen" - Herr Torvalds muss überhaupt nichts...

Abgesehen davon dass ich nicht einmal auf seine fragwürdige Ausdrucksweise eingegangen bin, sagst du mir tatsächlich zuerst, ich soll den Beitrag nach
seinem Inhalt bewerten, während du direkt im nächsten Satz implizit sagst, ich solle ihn eben nicht nach dem Inhalt, sondern nur nach Torvalds Person bewerten?

Mir bleibt da echt die Spucke weg - eigentlich müsste da nichts weiter zu schreiben
Ich weiss deinen Versuch zu würdigen, aber ich bin mittlerweile echt zu alt für so'n Scheiss. Such dir jemand anderes zum spielen.

Schönen Tach noch, und viel Spass in diesem Thread!
Finnegan

nachtfeuer

Finnegan schrieb:

Such dir jemand anderes zum spielen.

Tatsächlich ist gerade Linux als Plattform zum Spielen nicht so der Hit. Man fragt sich, wieso?

Bill Gates ist u.a. mit Basic groß geworden und mit programmiertechnischem "Leben und Leben lassen" (?)

Basic war früher langsam, und so hatte man gerne auch Pascal, C und Assembler eingesetzt. Die hatten aber auch Compiler und Linker und Basic öfter nur den Interpreter. Aber Quick Basic (4.5) von Microsoft bot einen Compiler und so Assembleroptimierung und so gibt es heute eben auch QB64.
Aktuelle Prozessoren/Compiler sind wohl eher C Optimiert.

Was spricht jetzt (unterm Strich) für C?
Der Sprachumfang ist klein. So ist C heute einfacher als Assembler, weil heute die Assemblerwelt viel komplexer geworden ist (1000 - 2000 Befehle, Prozessormodes, Betriebssysteminteraktionen, schlechte, nur teilweise und gar nicht Dokumentiertheiten usw.) und weil schon früher der Dialektwahn um sich gegriffen hatte. Der hatte sich auch bei Basic oder Lisp und anderen funktionalen Sprachen breitgemacht.
Der 2. Punkt ist, C ist standardisiert. Viele Jahre dialektfrei. C++, Objective C, Java, Python, Lua und alle anderen sind C-Dialekt. Python ist C mit Interpreter und Anleihen bei (modernen) funktionalen Konzepten und bei Basic.

C ist pragmatisch, praktisch aufgebaut, modular angelegt und auch funktional und bewährt schnell.

Haskell ist dagegen hightech-wissenschaftlich (gut), fundiert theoretisch aufgebaut (interessant) und traditionell eher langsam (man wundert sich).
Haskell ist (leider) linuxoid (c eher nicht, c ist eher die Basis für Unixe, Bashscripting, Perl).
Wie bei Linuxen gibt es dann eben keine Spielereien. Wozu auch? Wozu überhaupt Haskell und nicht gleich den Backend-C - Compiler mit C benutzen?
(Die Hardware ist u.a. durch Spielereien so stark geworden. Durch die starken Grafikkarten profitieren wissenschaftliche Berechnungen - indirekt von Spielerei)

Eine "Prelude" (Haskell), die eher an das Bett des Procrustes erinnert ( http://quittenbaum-consult.de/das-bett-des-procrustes-erkennen-und-verandern-sie-ungesunde-rahmenbedingungen/ ) .
Es überrascht, dass der ghci bei der Eingabe von Sonderzeichen nicht abstürzt.

In der Basic-Welt gibt es eben viel zu Spielen, funktionierende Sonderzeichen, extrem performante Grafikkartentreiber, ordentliche Druckergebnisse und viele Programme (eine Unzahl), die völlig ohne Abhängigkeitenärger laufen.

Linux selbst macht Anleihen in der Dos-/Basic-/Assemblerwelt (MC) oder auch in der Welt der Lisp-Maschinen (Emacs).
Basic-Interpreter sind nirgends in der Linuxwelt vorinstalliert. Nur Ruby und Python. Andere Sprachen wie Haskell/Ghci natürlich (auch) nicht.

Auf der Linux-Assembly - Bootdiskette( http://asm.sourceforge.net/asmutils.html ) nur Assemblertools zum Vorzeigen und konsolesurfen, nichts zum selber entwickeln (außer von außen bzw. wie mit cat allein entwickeln?).

Das wirkt, wie ein Dogmatismus mit C. Dieser Dogmatismus führt teilweise zu Java, Sonderzeichenhorror, mager bis gar nicht laufende Hardware (Drucker, Grafikkarten und sonst) - auch absurde Vorurteile über Assembler - und zu einer Spielunfreundlichen OS-Plattform. Wer weiß, wohin das sonst noch führt.

Turbopascal ging einen anderen Weg.

hustbaer

nachtfeuer schrieb:

C++, Objective C, Java, Python, Lua und alle anderen sind C-Dialekt. Python ist C mit Interpreter und Anleihen bei (modernen) funktionalen Konzepten und bei Basic.

Geh, Blödsinn.
Bevor Python ein C Dialekt ist ist es noch ein LISP Dialekt.

Artchi

dachschaden schrieb:

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?

Guckst du Sourcecode, siehst du Kernel etc. in C++. Haiku-OS ist ein BeOS, 100% kompatibel und nachprogrammiert.
Schaust du Kernel, Virtual Memory etc. Siehst du C++ mit Klassen, Vererbung usw.
http://cgit.haiku-os.org/haiku/tree/src/system/kernel

Zeus

@Artchi

Ich selbst hab man vor lange Zeit wiedersprochen, dass der BeOS Kernel in C++ geschrieben ist, ich weiß auch dass ich dafür ne Quelle hatte, aber egal, kenne sie nicht mehr xD

Artchi

@Wutz! Nichts gegen die Leistung von Linus Torvads per se. Aber du tust ja gerade mal so, als ob er Erfinder und erster Implementierer von Kernels und Betriebssystemen ist. LOL

Ich weiß nicht wie alt oder jung du bist, aber du solltest wissen, das LT einfach nur versucht hat ein Unix nachzuprogrammieren. Nichts gegen diese Leistung an sich, aber man sollte auch nicht so tun, als ob er jetzt etwas revolutionäres erfunden hat. Er hat sehr gute Fleißarbeit geleistet und dadurch Know How erworben.

Aber vor ihm haben schon viele andere Menschen Betriebssysteme designt und implementiert. Das wird jetzt dein Weltbild zerstören... tut mir leid, ist aber die Wahrheit.

Jedenfalls weiß ich nicht, warum er als Prophet angesehen wird? Und ich ihm abkaufen soll, das C++ total ätzend und C geil sein soll.

Haiku-OS ist jedenfalls der Beweis, das man ein OS in C++ implementieren kann. Probier es aus, es funktioniert erstaunlich gut und flott. (abgesehen von vielleicht fehlenden Hardware-Treibern, das hat aber mit C++ per se nichts zu tun).

Artchi

Zeus schrieb:

@Artchi

Ich selbst hab man vor lange Zeit wiedersprochen, dass der BeOS Kernel in C++ geschrieben ist, ich weiß auch dass ich dafür ne Quelle hatte, aber egal, kenne sie nicht mehr xD

Kann ja sein, das der BeOS-Kernel nicht in C++ implementiert wurde. Aber Haiku ist dann halt ein anderer BeOS-Kandidat... und der ist FLOSS.

Bitte ein Bit

nachtfeuer schrieb:
C++, Objective C, Java, Python, Lua und alle anderen sind C-Dialekt. Python ist C mit Interpreter und Anleihen bei (modernen) funktionalen Konzepten und bei Basic.

Geh, Blödsinn.
Bevor Python ein C Dialekt ist ist es noch ein LISP Dialekt.

Huch, mir lief es gerade eiskalt den Rücken herunter...

(setq defun 0)

(defun HalloWelt( a / )
  (if (= a nil)
    1
    0
  )
  2
)

Ich hasse LISP! :p

hustbaer schrieb:

Bevor Python ein C Dialekt ist ist es noch ein LISP Dialekt.

um "Python" richtig auszusprechen, muß man lisp-eln. Ok.

Ansonsten hat Python mit LISP nicht sehr viel gemein. Die eine ist eine dynamische Skriptsprache mit entfernt an C erinnernder Syntax und draufgeklatschtem Objektmodell, die andere eine listen-basierte Sprache mit Präfix-Notation und minimaler Syntax.

Mechanics

Ich hab eine zufällige cpp Datei im Haiku Kernel aufgemacht, scroll etwas runter und seh sowas:

void *
get_boot_item(const char *name, size_t *_size)
{
if (name == NULL || name[0] == '\0')
return NULL;

Das schaut für mich doch sehr nach C aus

Ansonsten ja, schaut auch so ein bisschen nach C++ aus.

hustbaer

@Bitte ein Bit & zufallswert
http://www.norvig.com/python-lisp.html

Tyrdal

Mechanics schrieb:

Ich hab eine zufällige cpp Datei im Haiku Kernel aufgemacht, scroll etwas runter und seh sowas:

void *
get_boot_item(const char *name, size_t *_size)
{
if (name == NULL || name[0] == '\0')
return NULL;

Das schaut für mich doch sehr nach C aus

Ansonsten ja, schaut auch so ein bisschen nach C++ aus.

Und hier eine andere:

namespace {

struct TimerLocker {
	Team*	team;
	Thread*	thread;

	TimerLocker()
		:
		team(NULL),
		thread(NULL)
	{
	}

	~TimerLocker()
	{
		Unlock();
}

Das geht definitiv nicht in C, auch wenn es teilweise recht oldschool ist.

Das "Problem": So ziemlich alles was in C geht geht in C++ auch.

Artchi

Genau, das Beispiel von Mechanics lässt sich locker ohne jeglichen Performance-Verlust durch eine non-virtual-String-Klasse ersetzen.

Haiku ist wahrscheinlich auch historisch durch mehrere Hände gegangen und somit nicht konsequent in C++-Style implementiert, also von Personen die halt kein C++ können. Aber ich wette, man könnte den C-lastigen Part nach C++ refactoren. Und der Code würde dadurch erstens noch besser lesbar, zweitens fehlerfreier und drittens trotzdem ohne Performance-Verlust laufen.

Die Haiku-Developer-Community ist bestimmt unterbesetzt. Da könnte man mit mehr C++-Manpower mehr raus holen.

Es ist aber auch klar, das um so tiefer man in die Schichten rein geht, und sich der Hardware nähert, immer prozeduraler Code und sogar Assembler Code nötig ist. C++ ist ein Werkzeug, das einem ab einer bestimmten Ebene unter die Arme greif, wo man mit ASM oder C viel mehr Handarbeit machen muss. Und das ist ja gerade der Punkt.

Bitte ein Bit

@hustbaer
Lisp hat aber ein völlig anderes Konzept als Python. In Lisp ist alles eine Liste. Listen beginnen mit ( und enden mit ). Selbst Funktionen sind Listen. Es gibt Funktionen mit denen man alle vorhandenen Funktionen im LISP Interpreter suchen kann. Und so manches LISP Forummitglied kritisierte an mir, dass ich so sequenziell denke...

Nebenbei hatte die Lisp Variante, welche ich nutzte, ganz massive Macken. Die Hauptmacke war die Fehlermeldung "Error around Expression". Ab und zu war es eine fehlende Klammer an eine komplett anderen Stelle. Oder eine Variable hatte den gleichen Namen wie eine Systemfunktion. Und manchmal stürzte die Software komplett ab weil man eine Funktion mit dem falschen Typ fütterte.

Daher gruselt es mich wenn man Python mit LISP vergleicht. Inwiefern hier jetzt ein Python for LISP Developers helfen soll weiß ich nicht. Ich will nicht C mit C++, Java mit Javascript oder Sand mit Sandkuchen miteinander vergleichen. Jede Sprache hat ihre eigene Interressengruppen, ihre eigenen Konzepte, ihre eigene Einsatzgebiete.

Und am Schluss möchte man die eierlegende Wollmilchsau als Programmiersprache und wundert sich dann warum man mehrere GByte an SDK Daten bzw. Frameworks herunterladen muss.

hustbaer

Bitte ein Bit schrieb:

Daher gruselt es mich wenn man Python mit LISP vergleicht. Inwiefern hier jetzt ein Python for LISP Developers helfen soll weiß ich nicht.

Hast du den Artikel gelesen (oder wenigstens überflogen)? Für mich liest sich das so als ob sehr viel von dem was man in LISP so macht, man in Python auch machen kann. Mit anderer Syntax und z.T. komplett anders intern umgesetzt, aber man kann quasi identisch programmieren.

Bitte ein Bit schrieb:

Ich will nicht C mit C++, Java mit Javascript oder Sand mit Sandkuchen miteinander vergleichen. Jede Sprache hat ihre eigene Interressengruppen, ihre eigenen Konzepte, ihre eigene Einsatzgebiete.

Ja, klar. Man kann vergleichen oder halt nicht vergleichen. Wenn man überhaupt nicht vergleichen möchte, dann will man auch nicht Python mit LISP vergleichen. Irgendwie logisch. Anderenfalls finde ich es aber sehr seltsam Python als C-Dialekt zu bezeichnen. C kennt keine Klassen, keine Objekte, schon gar nicht dynamisch modifizierbare, ist statisch typisiert vs. dynamisch uswusf. - alles ganz ganz anders als in Python. Beide sind primär imperativ - aber da hören sich die grossen Gemeinsamkeiten für mich dann auch schon auf.

Bitte ein Bit

Hast du den Artikel gelesen (oder wenigstens überflogen)? Für mich liest sich das so als ob sehr viel von dem was man in LISP so macht, man in Python auch machen kann. Mit anderer Syntax und z.T. komplett anders intern umgesetzt, aber man kann quasi identisch programmieren.

Jaein.

Natürlich kann man sehr viel, was man in Lisp machen kann, auch in Python programmieren.

Aber darauf möchte ich nicht hinaus. Ich möchte darauf hinaus dass man in Lisp ein völlig anderes Programmierkonzept hat und man nach einiger Zeit Programmierung auch in komplette anderen Bahnen denkt. Erstens kommt dies durch die Präfixnotation und zweitens ist in Lisp alles eine Liste. Anweisungen waren Listen, Funktionen waren Listen, Komplexe Datenstrukturen waren Listen,...

Stell dir vor ein C Experte ohne Erfahrung in C++ müsste von heute auf morgen mit C++ arbeiten und müsste statt "for" "std::for_each" nutzen. So fühlte ich mich beim Einstieg in Lisp. Und nach meiner Lisp Zeit musste ich mich erst wieder einmal daran gewöhnen 1 + 2 zu schreiben anstatt (+ 1 2).

Deswegen gruselt mich der Vergleich Python Lisp.

Anderenfalls finde ich es aber sehr seltsam Python als C-Dialekt zu bezeichnen.

Ich finde nachfeuer generell seltsam.