Programmiersprachenfeatures - Was gibts?

Hallo.

Gast++ schrieb:

Btw Vielfach hört man dass Smalltalk die meistunterschäzte Sprache ist und in diversen Hypes zu Unrecht links liegen gelassen wurde.

Stimmt (leider), was die Anzahl Projekte angeht, die noch mit St unternommen werden.

Andererseits: wer wissen will, wie neu manche moderne Konzepte wie OO, GUI, IDE, Dynamische Typisierung sind, werfe mal einen Blick auf die 1972'er Version von St.
Auch Lisp-Features scheinen ja langsam Eingang in die Feature-Liste populärerer Sprachen zu finden.

Die knzeptionelle Reinheit des OO-Modells von St liegt für viele andere OO-Sprachen dennoch in vermutlich unerreichbarer Ferne, eben weil die gängigsten OO-Sprachen gar nicht rein objektorientiert, sondern Multi-Paradigmen-Sprachen sind.

Simon2

kleine Bemerkung schrieb:

...
Die knzeptionelle Reinheit des OO-Modells ...

Wobei das ja nicht unbedingt ein Qualitätsmerkmal ist - außerdem bleibt für mich die Frage, ob eine Sprache, die mehrere Paradigmen unterstützt, in OO schlechter/unreiner sein muss (in C++ kann man z.B. komplett ohne templates programmieren ... templates "verunreinigen" also die anderen Konzepte nicht).

Gruß,

Simon2.

Hallo

Simon2 schrieb:

außerdem bleibt für mich die Frage, ob eine Sprache, die mehrere Paradigmen unterstützt, in OO schlechter/unreiner sein muss (in C++ kann man z.B. komplett ohne templates programmieren ... templates "verunreinigen" also die anderen Konzepte nicht).
Simon2.

Ein gutes Argument. Es kommt darauf an, wie ernst man das Prinzip der OO nehmen will. Vom strengen Standpunkt aus sind templates keine Objekte und verhindern damit die Umsetzung des Prinzips `alles ist ein Objekt'. Im Gegensatz etwa zu
den Blcks in St.
Nimmt man dieses Prinzip bei der Sprachdefinition wirklich ernst, landet man eher bei einer Sprache wie St oder Flex als bei C++ oder Java.

Vielleicht ist es wahr, daß `die Welt noch nicht reif für OO' ist, wie es jemand Anderes einmal ausdrückte.

Möglicherweise ist reine' OO, wie sie von St verkörpert wird, auch gar nicht völlig kompatibel mit unserer momentanen Hardware- und Software-Welt. D.Ingalls, einer der maßgeblichen Entwickler von St schrieb (sinngemäße Übersetzung)Ein Betriebssystem ist eine Sammlung von Dingen, die nicht in eine Sprache passen. Ein solches sollte es nicht geben.'

Grüße.

Helium

Während ich in der rein funktionalen Programmierung einen wirklichen Vorteil sehe (nämlich beim Multithreading, Threads müssen sich nicht mehr gegenseitig blockieren) weiß ich nicht, welchen Gewinn ich in der Praxis durch reine OOP erziehle.

Gast++

Helium schrieb:

weiß ich nicht, welchen Gewinn ich in der Praxis durch reine OOP erziele.

ACK.

Z.B. Beim Thema "Threads" fällt es mir immer wieder auf wie blinder OO-Purismus schadet. Einige Fragen zum Thema aus der letzten Zeit zeigen mir dass "Thread-Klassen" offenbar ein Konzept realisieren das für mehr Verwirrung sorgt als es beseitigt.
Bei Formulierungen in Postings der Art "der Thread der Klasse" wird klar was passiert ist: das Konzept "Verhalten in Klassen zusammenfassen" ist soweit ausgedehnt worden das es erst beliebig wird und dann aus der Beliebigkeit falsch gefolgert wird.

Damit zusammenhängend ist die Implementierung der Java "main" Routine als statische Methode eines Applikationsobjektes - was soll sowas? Der einzige Grund der mir einfällt wäre es, konzeptionelle Geschlossenheit zu bewahren - das hat aber selbst in der Philosophie nicht geklappt.

Der OO-Hype lässt sich recht gut durch einem Scherz beschreiben:
"Schauen Sie mal! Hier haben ein Objekt vom Typ NT-OS dessen Methode Coredump uns gerade ein Objekt vom Typ Bluescreen geliefert hat! Mittels des Powerswitches rufe ich jetzt den Destruktor auf..."

Grüsse

*this

Gast++ schrieb:

Z.B. Beim Thema "Threads" fällt es mir immer wieder auf wie blinder OO-Purismus schadet. Einige Fragen zum Thema aus der letzten Zeit zeigen mir dass "Thread-Klassen" offenbar ein Konzept realisieren das für mehr Verwirrung sorgt als es beseitigt.
Bei Formulierungen in Postings der Art "der Thread der Klasse" wird klar was passiert ist: das Konzept "Verhalten in Klassen zusammenfassen" ist soweit ausgedehnt worden das es erst beliebig wird und dann aus der Beliebigkeit falsch gefolgert wird.

Nur weil manche es nicht richtig verstehen, ist OO doch nicht schlecht. Viele verstehen auch nicht OO Sachen nicht.

DEvent

Damit zusammenhängend ist die Implementierung der Java "main" Routine als statische Methode eines Applikationsobjektes - was soll sowas? Der einzige Grund der mir einfällt wäre es, konzeptionelle Geschlossenheit zu bewahren - das hat aber selbst in der Philosophie nicht geklappt.

Naja wie willst du es sonst machen? Einfach eine Methode main ganz oben (oder unten) hin, ohne ein Klassen-Scope?

int main(String[] args)
{
}

class Foo
{
}

Eine eigene Main.java, in der einfach nur die main-Funktion drinner steht?

Man könnte ja auch direkt im Run-Dialog eingeben, das man eine Instanz einer Klasse erstellen soll, eine Main-Klasse?

class Main // vielleicht implements Runnable?
{
    public Main(String[] args) { }
    public int run() { }
}

Welche Vorteile würde den das bringen?

Simon2

kleine Bemerkung schrieb:

...`die Welt noch nicht reif für OO' ...

Das finde ich gar nicht so schlecht .... wenn auch vllt. in einem etwas anderen Sinn als der Autor meinte: "Die Welt" ist einfach nicht komplett "OO" (und wird es auch nie sein.
Gute Programmierer wissen, wann eine Problemlösung "gut" durch OO umgesetzt werden kann und wann nicht.

Daneben gibt es natürlich auch genug Programmierer, die "noch nicht reif für OO" sind ... aber nicht selten sind es die realen Fragestellungen (oder eben "die Welt"), sich einer "OOisierung" widersetzen (blöde Realität ).

Gruß,

Simon2.

Gast++

@DEvil:

Was wird denn gebraucht - irgendein Einsprungpunkt; sei für einen jmp der realne Maschine oder für die VM. Eine Klassensemantik an der Stelle zu fordern reduziert doch nicht Komplexität, sondern erhöht sie.

Das Konzept einer einfachen main()-Routine wie man es bei C/C++ oder m.E. bei Python (da kann man sowas machen; muss es aber nicht) findet ist doch völlig ausreichend.

Grüsse

*this

Gast++

naja schrieb:

Nur weil manche es nicht richtig verstehen, ist OO doch nicht schlecht. Viele verstehen auch nicht OO Sachen nicht.

Das hab ich auch nicht behauptet; ich sprach von OO-Puritanismus.

DEvent

Gast++ schrieb:

@DEvil:

Was wird denn gebraucht - irgendein Einsprungpunkt; sei für einen jmp der realne Maschine oder für die VM. Eine Klassensemantik an der Stelle zu fordern reduziert doch nicht Komplexität, sondern erhöht sie.

Das Konzept einer einfachen main()-Routine wie man es bei C/C++ oder m.E. bei Python (da kann man sowas machen; muss es aber nicht) findet ist doch völlig ausreichend.

Grüsse

*this

Ich bin nicht DEvil
Wie willst du die main() dann ansprechen? Man hat z.B. mehrere main()s, je nachdem was man testen will. Entweder man verpakt sie in ein Package, dann ist aber nur eine main() pro Package möglich oder man verpakt sie in package+Klassen-Scope. Dann hat kann man pro Klasse eine main()-Methode. Finde ich so weitaus praktischer. Da die main()-Methode eine einfache Static-Methode ist, kann man sie auch private machen, also vor anderen verstecken.

Eine Klasse musst du in Java so oder so machen. Das ist ja kein C++, wo du dich zwischen verschiedenen Paradigmen entscheiden kannst.

Hallo Simon2

Simon2 schrieb:

Gute Programmierer wissen, wann eine Problemlösung "gut" durch OO umgesetzt werden kann und wann nicht.

Was wäre denn Deiner Meinung nach der Prototyp (dieses Wort jetzt mal bitte nicht in der wörtlichen OO-Bedeutung interpretieren ) einer Anwendung, die sich nicht für OO eignet ?

Simon2 schrieb:

Daneben gibt es natürlich auch genug Programmierer, die "noch nicht reif für OO" sind ... aber nicht selten sind es die realen Fragestellungen (oder eben "die Welt"), sich einer "OOisierung" widersetzen (blöde Realität ).
Simon2.

ja, die blöde Realität... Glücklicherweise ist das Universum nach Einstein endlich, das vereinfacht die Aufstellung eines Objekt-Modells derselben

Spaß beiseite; ich frage mich, ob OO schon die letzte größere theoretische
Design-Methode ist und wenn nicht, was kommt nach der OO?

Reine Funktionale Programmierung wird ja von der Mehrheit der Entwickler ebenso brüsk abgelehnt wie reine OO a la St oder Flex, obwohl beides durch eine
Art `Hintertür' in Form einiger in Mode gekommenen Skriptsprachen (Ruby ist vergleichsweise rein objektorientiert und Python hat einige funktionale Elemente) doch langsam, aber sicher, Einzug in die Entwicklungsmethodik feiert.

Gruß.