Wieso gibt es keine gute Programmiersprache?

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.

hustbaer

Naja ich glaube es kommt drauf an wer sich Python anguckt.

Jemand der aus der C/C#/C++/Java/Pascal/... Welt kommt
Jemand der aus der LISP/... Welt kommt
Jemand der mit Python als erste Sprache anfängt

Die drei Gruppen werden wohl sehr unterschiedliche Pyhton Programme schreiben