3. Programmiersprachenfeatures - Was gibts?

Programmiersprachenfeatures - Was gibts?

  • H

    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?

    0
  • C

    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.

    0
  • ?

    message passing wurde iirc noch nicht erwähnt.

    0
  • S

    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.

    0
  • H

    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.

    0
  • R

    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

    0
  • D

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

    0
  • ?

    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 🙂

    0
  • O

    Zwergli schrieb:

    Mal nen bissle neues aus der .Net Welt:

    Lambda Expressions

    das ist aber nichts net spezifisches 😉

    0
  • H

    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.)

    0
  • ?

    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 🙄

    0
  • ?

    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.

    0
  • S

    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.

    0
  • ?

    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.

    0
  • H

    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.

    0
  • G

    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

    0
  • ?

    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.

    0
  • D

    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?

    0
  • S

    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.

    0
  • G

    @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

    0
Anmelden zum Antworten