Programmiersprachenfeatures - Was gibts?

Regulären Ausdrücken?
großes Feature z.B. von Perl (jaja Ruby kanns auch teilweise, aber bestimmt noch mehr)

Gast++

Policies, Prä- und Postkonditionen (Eiffel, letztere z.Zt. unter C++ mit Sentries nachzubilden)

Btw Vielfach hört man dass Smalltalk die meistunterschäzte Sprache ist und in diversen Hypes zu Unrecht links liegen gelassen wurde. Da ich wie gesagt zu dumm für St bin (was mir allerdings auch etwas über die Sprache sagt) trifft für mich dies viel eher auf Eiffel zu - man betrachte ggf. mal die Features
http://de.wikipedia.org/wiki/Eiffel_(Programmiersprache)#Aufbau_eines_Eiffel-Programms

Und das hier

http://www.eiffel.com/developers/faqs/eiffel-language.html#classic-compilestoc
(oben) ist vielleicht nice to know.

Grüsse

*this

Continuations wurden glaube ich noch nicht genannt.
Damit kann man auch ganz tolle Sachen machen.

Simon2

featuring schrieb:

Es gibt Sprachen bei denen Strings eingebaute Datentypen sind und nicht nur Klassen.

Es gibt auch Sprachen, bei denen sind Arrays eingebaute Datentypen.
Inwieweit sind "eingebaute Datentypen" ein besonderes Qualitätskriterium (und nicht viel eher eine Begrenzung von Generizität) ?

Gruß,

Simon2.

Helium

Simon2 schrieb:

Inwieweit sind "eingebaute Datentypen" ein besonderes Qualitätskriterium (und nicht viel eher eine Begrenzung von Generizität) ?

Inwiefern schränken eingebaute Typen die "Generizität" ein?

Christoph

Simon2 schrieb:

featuring schrieb:

Es gibt Sprachen bei denen Strings eingebaute Datentypen sind und nicht nur Klassen.

Es gibt auch Sprachen, bei denen sind Arrays eingebaute Datentypen.
Inwieweit sind "eingebaute Datentypen" ein besonderes Qualitätskriterium (und nicht viel eher eine Begrenzung von Generizität) ?

In manchen Sprachen ist auch gar nicht so klar, wo die Grenze zwischen "eingebaut" und "nicht eingebaut" zu ziehen ist. In manchen Sprachen sind sogar Basis-Typen wie Int und Char in der Standard-Bibliothek definiert. Wenn man diese Datentypen als eingebaut ansieht, sind aber auch Arrays, Listen, Maps, Sets und vieles mehr eingebaut.

Array, Listen und Maps gehören zum Sprachstandard von C++. In einem gewissen Sinn sind diese Typen also eingebaut.

message passing wurde iirc noch nicht erwähnt.

Simon2

Helium schrieb:

Simon2 schrieb:

Inwieweit sind "eingebaute Datentypen" ein besonderes Qualitätskriterium (und nicht viel eher eine Begrenzung von Generizität) ?

Inwiefern schränken eingebaute Typen die "Generizität" ein?

Vielleicht nicht notwendigerweise, aber in den mir bekannten Sprachen sind sie das.
Z.B. kann man von int nicht ableiten ... schade.
Zumindestens in Java haben eingebaute Typen eine andere Semantik (andere Operationen, nicht als Referenzen übergebbar, ...) als "selbstgebaute Typen".

Sind so zwei Beispiele, aber ich denke prinzipiell: Sobald zwischen "eingebauten/primitiven" und "selbstgemachten" Typen unterschieden wird/werden kann, bedeutet das, dass sie sich unterschiedlich verhalten .... und das ist IMO eine "Einschränkung der Generizität", weil man eben generischer Code diese Unterschiede berücksichtigen muss - und danmit nicht komplett generisch sein kann.

Gruß,

Simon2.

Helium

Das man von Integern ableiten kann gibts vielleicht in wenigen Sprachen, aber auch das gibt es. wobei fraglich sit, wie oft man das wirklich will.
Die Unterscheidung in Java ist natürlich etwas doof. In C# ist es immerhin so, dass man auch wertartige Tyen definieren kann, die sich wie die eingebauten verhalten.

ronny

es ist durchaus praktisch - z.b. wenn man die erstellungs-semantik verändern will, oder die representation nach außen

üblicherweise muss man dann die "ist ein" beziehung durch ein "hat ein" ausdrücken, was unschön ist

deetee

Die Idee dieses Thread gefällt mir, aber die Übersicht fehlt leider. Jemand da der die Liste freiwillig ergänzt?

Mal nen bissle neues aus der .Net Welt:

Lambda Expressions
Extension Methods
Anonyme Typen
Implizit typisierte lokale Variablen

Gerade die letzten beiden Features sind was tolles. Volle Typsicherheit obwohl man gar keinen namentlich bekannten Typ verwendet

otze

Zwergli schrieb:

Mal nen bissle neues aus der .Net Welt:

Lambda Expressions

das ist aber nichts net spezifisches

Helium

Zwergli schrieb:

Mal nen bissle neues aus der .Net Welt:

Lambda Expressions
Extension Methods
Anonyme Typen
Implizit typisierte lokale Variablen

Gerade die letzten beiden Features sind was tolles. Volle Typsicherheit obwohl man gar keinen namentlich bekannten Typ verwendet

LOL, su meinst ein bischen uralten Kram, den .Net jetzt "wiederentdeckt" (war nie wirklich verschwunden).

Lambda Expression => siehe z.B. Lisp aus den 1960ern. In jeder Funktionalen Sprache grundlage.

Extension Methods => CLOS, Dylan, ...

Anonyme Typen => OK, ich zeig dir jetzt mal ein wenig SML-code:

type foo = {x:int, y:float, s:string ref}

val bar = {x=0, y=3.14, s=ref ""}

Kommt dir das bekannt vor? Vergleichbares geht in so gut wie jeder funktionalen Sprache.

"Implizit typisierte lokale Variablen" => Zeig mir eine einzige funktionale Sprache, die keine Type deduction hat.

Alles, was C# 3.0 jetzt als neu verkauft ist ein alter Hut (bis auf vielleicht Linq, wobei das ja nur eine nette Synthax für filter, mapping, etc. ist, so wie list comprehensions im Grunde auch.)

Helium schrieb:

Zwergli schrieb:

Mal nen bissle neues aus der .Net Welt:

Lambda Expressions
Extension Methods
Anonyme Typen
Implizit typisierte lokale Variablen

Gerade die letzten beiden Features sind was tolles. Volle Typsicherheit obwohl man gar keinen namentlich bekannten Typ verwendet

LOL, su meinst ein bischen uralten Kram, den .Net jetzt "wiederentdeckt" (war nie wirklich verschwunden).

Lambda Expression => siehe z.B. Lisp aus den 1960ern. In jeder Funktionalen Sprache grundlage.

Extension Methods => CLOS, Dylan, ...

Anonyme Typen => OK, ich zeig dir jetzt mal ein wenig SML-code:
type foo = {x:int, y:float, s:string ref}

val bar = {x=0, y=3.14, s=ref ""}
Kommt dir das bekannt vor? Vergleichbares geht in so gut wie jeder funktionalen Sprache.

"Implizit typisierte lokale Variablen" => Zeig mir eine einzige funktionale Sprache, die keine Type deduction hat.

Alles, was C# 3.0 jetzt als neu verkauft ist ein alter Hut (bis auf vielleicht Linq, wobei das ja nur eine nette Synthax für filter, mapping, etc. ist, so wie list comprehensions im Grunde auch.)

ganz locker bleiben bubi. er meinte doch nur, dass es das in .net gibt. brauchste net gleich halb durchdrehen

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