Programmiersprachenfeatures - Was gibts?

Christoph

Gast++ schrieb:

Welche Smalltalk-Implementierung würdest Du unter Windows einsetzen?
Und welche einem C++ Programmierer für den Einstieg empfehlen?
Hab nichts konkretes damit vor; will lediglich mitreden können.

Ich hatte mal ein bisschen mit Squeak gespielt: http://www.squeak.org
Diese Implementierung läuft gut unter Windows, aber auch auf anderen Betriebssystemen. Außerdem wird Squeak soweit ich weiß noch weiterentwickelt.

Gast++ schrieb:

]Meine letzte Berührung damit verlief wenig erfreulich; ich versuchte "Hello World" zu schreiben und stellte fest dass zwar "Hello World" ausgegeben wurde aber irgendwelche Compiler-Messages den Inhalt meines Editor-Fensters überschrieben...
Welche Implementierung das war weiss ich nicht mehr aber der Effekt könnte bekannt sein.

Btw kennst Du noch andere Sprachen die Metaklassen anbieten ausser Smalltalk und Python (mit Perl geht's auch, wie wohl alles, aber das meine ich nicht )?

Ich meine dass Common Lisp mit CLOS etwas in der Richtung kann. Aber mit CLOS habe ich fast nichts gemacht, deswegen unter Vorbehalt.

Gast++

Christoph schrieb:

Ich hatte mal ein bisschen mit Squeak gespielt: http://www.squeak.org
Diese Implementierung läuft gut unter Windows, aber auch auf anderen Betriebssystemen.

Erstmal danke für den Link!

Aber ich bin zu dumm dafür; ich habe jetzt hier gefunden wie ich 'Hello World' http://wiki.squeak.org/squeak/2230 schrieben können soll.
Das habe ich auch getan und schon wieder seh ich dass 'Hello World' in meinen Source reingeworfen wird!

Christoph schrieb:

Ich meine dass Common Lisp mit CLOS etwas in der Richtung kann. Aber mit CLOS habe ich fast nichts gemacht, deswegen unter Vorbehalt.

Ja, klar. Danke! CLOS - Irgendwie hab Lisp-Dialekte systematisch verdrängt. Hab mich immer so "umklammert" gefühlt

(und(Dank)(Gruesse(von-an(Gast++)(Christoph))))

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.