1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Firefox 9 Beta: Dank Type Inference…

Type Inference ist auch bei statisch-stark-typisierten Sprachen praktisch

  1. Thema

Neues Thema Ansicht wechseln


  1. Type Inference ist auch bei statisch-stark-typisierten Sprachen praktisch

    Autor: andi_lala 11.11.11 - 10:11

    Ich bin auch erst vor kurzem draufgekommen, dass man in C# mit dem "var" Schlüsselwort Variablen deklarieren kann, deren Typ automatisch mittels Type Inference ermittelt wird.
    Das funktioniert natürlich nicht in jedem Fall, aber dann beschwert sich eh der Compiler.

    Ganz praktisch ist das vor allem in For-Each Schleifen, da man hier nicht jedes mal den Typ angeben muss:

    for(var entity in entityList) { ... }

    Zwar erhält man dadurch keine Performance-Verbesserung, da die Typen ja so oder so zur Compilezeit feststehen, aber dafür wird der Code leserlicher und man kann Änderungen meistens deutlich schneller durchführen.
    Außerdem erlaubt dieses Konzept auch die typsichere Verwendung von anonymen Typen, welche ansonsten problematisch wäre.

    Ich bin allerdings leicht verwundert, dass Type Inference in Mainstream OOP Sprachen, so lange auf sich warten gelassen hat.



    1 mal bearbeitet, zuletzt am 11.11.11 10:12 durch andi_lala.

  2. Re: Type Inference ist auch bei statisch-stark-typisierten Sprachen praktisch

    Autor: Karlos2 11.11.11 - 10:42

    fand ich bei scala auch ganz angenehm

  3. Re: Type Inference ist auch bei statisch-stark-typisierten Sprachen praktisch

    Autor: soc 11.11.11 - 10:48

    Ich gebe Dir grundsätzlich Recht, auch wenn der Sinn und Zweck von Typ-Inferenz in untypisierten/typisierten Sprachen ein anderer ist.

    In untypisierten Sprachen macht TI auf Sprachebene nicht sehr viel Sinn, weil der Compiler die Informationen nicht vor der Laufzeit auswertet, hier wird eher Typ-Rekonstruktion zur Laufzeitoptimierung betrieben.

    Aber Du hast Recht, fehlende TI in Sprachen ist völlig inakzeptabel.
    Es gibt nur einen Grund für fehlende TI und das ist Faulheit auf Seiten des Sprach-/Compilerbauers.

  4. Re: Type Inference ist auch bei statisch-stark-typisierten Sprachen praktisch

    Autor: andi_lala 11.11.11 - 11:23

    soc schrieb:
    --------------------------------------------------------------------------------
    > In untypisierten Sprachen macht TI auf Sprachebene nicht sehr viel Sinn,
    > weil der Compiler die Informationen nicht vor der Laufzeit auswertet, hier
    > wird eher Typ-Rekonstruktion zur Laufzeitoptimierung betrieben.

    Ja, das stimmt natürlich. Es ist ja auch nicht nötig auf Sprachebene so etwas einzuführen. Bei statisch typisierten Sprachen braucht man aber so etwas aus syntaktischen Gründen.

    Bei Sprachen mit dynamischen Typ-System kann dann ja halt der JIT dadurch eben bessere Optimierungen durchführen, und dadurch gewisse Nachteile vom dynamischen Typsystem im Vergleich zu statischen ausgleichen.

    Es ist jedenfalls zu begrüßen, da es ja nur Vorteile bietet.

  5. Re: Type Inference ist auch bei statisch-stark-typisierten Sprachen praktisch

    Autor: andi_lala 11.11.11 - 11:27

    Mit scala hab ich selber noch keine Erfahrung.
    Ich bin mit Type-Inference das erste mal durch oCaml in Berührung gekommen.

  6. Re: Type Inference ist auch bei statisch-stark-typisierten Sprachen praktisch

    Autor: ChilliConCarne 11.11.11 - 12:01

    Mal allgemein gesprochen, abseits von C#, dh. eher theoretisch und mit gedanklichen Implementierungen von Übersetzer/Interpreter/Ausführung. Ich entschuldige mich im Vorraus für mögliche Fehler. Typentheorie und Übersetzerbau sind schon eine Weile her.

    andi_lala schrieb:
    > Zwar erhält man dadurch keine Performance-Verbesserung,
    Jein. Wenn - zu dem 'wenn' komme ich im nächsten Absatz - in der jeweiligen Sprache der Typ der zu iterierenden Liste nicht klar ist und bei der betreffenden Sprache, typischerweise erst zur Laufzeit geprüft wird (wenn überhaupt) ob die Typen von Laufvariable und Liste zusammen passen (oder zumindest implizit transformiert werden können), dann hat man in deinem Beispiel der impliziten Typisierung einen möglichen Performancevorteil, da der Interpreter/Übersetzer sagen kann "Ok, die Variable ist von mir geprüft, hier braucht es keinen Laufzeitcheck mehr". Ganz im Gegensatz zur expliziten Angabe, bei der möglicherweise der Übersetzer sagt "Alles *soweit* ok", aber zur Laufzeit dennoch geprüft werden muss oder wird. Im Allgemeinen ist es jedoch sicher so, dass implizite Angaben ein mu inperformanter sind, wenn man Übersetzung/Interpretierung/Ausführung zusammenzählt. Man übergibt der Infrastruktur ja die Arbeit der Klassifizierung der Variable.

    Nun zum 'wenn'.

    > da die Typen ja so
    > oder so zur Compilezeit feststehen,
    Jein. Mal folgendes Pseudobeispiel:

    if(random() < 0.5)
    liste aus strings
    else
    liste aus integern

    Hier kann nur *ausschließlich* zur Laufzeit bekannt sein, aus was für einem Typ die Liste besteht. Man kann in der Sprache jetzt natürlich verlangen, die Typen *vorher* zu Deklarieren. Wie in C zum Beispiel. Jedoch hat C den Cast Operator, womit man sich wieder Orakelei einfangen kann. Einfach im Beispiel die Zuweisungen durch casts ersetzen.

    Typinferenz zur Übersetzungszeit ist dann nicht mehr möglich, wenn sich der Typ nicht nur aus der Syntax/Semantik der Sprache und einem jeweiligen Element der Sprache (also einem konkreten Programmtext) herleiten lässt, sondern dieser vom Algorithmus selbst, in nicht mehr (effizient) berechenbarer Weise abhängt.

    > aber dafür wird der Code leserlicher
    Bei strikter Typisierung kann es unschön werden, wenn man Operatoren für alles mögliche definieren muss. Auch kann man gerne mal den Überblick verlieren, wenn der Programmtext nur so vor Inferenzen strotzt und man jedes mal neu aus seinem 'axiomatisierten Typen' (ja ich weiß, schwammiger Ausdruck) den der Variablen herleiten darf. Lässt sich aber mit sauberem Programmierstil und guter DevDoku vermeiden. Im Allgemeinen, sehe ich das aber genau wie du.

    > und man kann Änderungen meistens deutlich schneller durchführen.
    Ja.

    > Außerdem erlaubt dieses Konzept auch die typsichere Verwendung von anonymen
    > Typen, welche ansonsten problematisch wäre.
    Hm ... das müsstest du jetzt genauer formulieren.

    > Ich bin allerdings leicht verwundert, dass Type Inference in Mainstream OOP
    > Sprachen, so lange auf sich warten gelassen hat.
    Definiere hier 'Mainstream OOP' und 'so lange'. Wie im zweiten Absatz beschrieben hängt letzten Endes vieles von der Sprache selbst ab. Mein Eindruck ist der, dass hier die Forschung einfach nicht so weit war/ist. Ich weißt nicht ob das jetzt OCaml war/hieß, aber ich kann mich an Vorträgen zu Implementierungen erinnern die OO+Funktional zusammenführten, was letzten Endes eher in OO mit ein bisschen funktionaler Würze endete. Ich kann mir da nur schwer vorstellen, dass hier ein so striktes und komplexes Typsystem wie sagen wir in Haskell existiert, bei dem sich Interferenz so dermaßen weit durch die Sprache erstreckt.

  7. Re: Type Inference ist auch bei statisch-stark-typisierten Sprachen praktisch

    Autor: andi_lala 11.11.11 - 12:30

    ChilliConCarne schrieb:
    --------------------------------------------------------------------------------
    > [..] Im
    > Allgemeinen ist es jedoch sicher so, dass implizite Angaben ein mu
    > inperformanter sind, wenn man Übersetzung/Interpretierung/Ausführung
    > zusammenzählt. Man übergibt der Infrastruktur ja die Arbeit der
    > Klassifizierung der Variable.
    Das stimmt natürlich so. Meine Aussage hab ich allerdings rein auf die Laufzeit bezogen und nicht auf die Compilezeit.

    > Nun zum 'wenn'.
    > Jein. Mal folgendes Pseudobeispiel:
    >
    > if(random() < 0.5)
    > liste aus strings
    > else
    > liste aus integern
    >
    > Hier kann nur *ausschließlich* zur Laufzeit bekannt sein, aus was für einem
    > Typ die Liste besteht. Man kann in der Sprache jetzt natürlich verlangen,
    > die Typen *vorher* zu Deklarieren. Wie in C zum Beispiel. Jedoch hat C den
    > Cast Operator, womit man sich wieder Orakelei einfangen kann. Einfach im
    > Beispiel die Zuweisungen durch casts ersetzen.
    >
    > Typinferenz zur Übersetzungszeit ist dann nicht mehr möglich, wenn sich der
    > Typ nicht nur aus der Syntax/Semantik der Sprache und einem jeweiligen
    > Element der Sprache (also einem konkreten Programmtext) herleiten lässt,
    > sondern dieser vom Algorithmus selbst, in nicht mehr (effizient)
    > berechenbarer Weise abhängt.

    Hmm...da kann ich jetzt nicht so ganz zustimmen. Wir reden hier ja von statisch typisierten Sprachen anhand des Beispiels C#. Die Zuweisungen müssen ja kompatibel sein und einem gemeinsamen Supertyp entsprechen. In deinem Beispiel wäre das einfach List. Das heißt also, dass beide Listen den selben Supertyp haben müssen. Dieser steht dann ja auch zur Compile fest. Das muss er ja auch bei einer statisch typisierten Sprache.

    Falls du allerdings später den Typ casten würdest, wäre das ja auch prinzipiell kein Problem, denn ab diesem Zeitpunkt an dem gecastet wird, muss ja auch wieder zur Compilezeit Typinformationen feststehen, ansonsten könntest du den Typ nicht verwenden (außer natürlich mit Reflectionmechanismen und ob dort TypeInference große Vorteile bietet glaub ich auch eher nicht).

    > Bei strikter Typisierung kann es unschön werden, wenn man Operatoren für
    > alles mögliche definieren muss. Auch kann man gerne mal den Überblick
    > verlieren, wenn der Programmtext nur so vor Inferenzen strotzt und man
    > jedes mal neu aus seinem 'axiomatisierten Typen' (ja ich weiß, schwammiger
    > Ausdruck) den der Variablen herleiten darf. Lässt sich aber mit sauberem
    > Programmierstil und guter DevDoku vermeiden. Im Allgemeinen, sehe ich das
    > aber genau wie du.
    Gut da kommt es natürlich stark auf die IDE an. Im VisualStudio sieht man auf einem Blick, was die Variable für einen Typ hat und welche Methoden usw. existieren.


    > > Außerdem erlaubt dieses Konzept auch die typsichere Verwendung von
    > anonymen
    > > Typen, welche ansonsten problematisch wäre.
    > Hm ... das müsstest du jetzt genauer formulieren.

    In C# wurden anonyme Typen eingeführt, welche durch Type-Inference typsicher verwendet werden können. Hier ein kleines Beispiel:
    > var v = new { Amount = 108, Message = "Hello" };
    >
    > // Rest the mouse pointer over v.Amount and v.Message in the following
    > // statement to verify that their inferred types are int and string.
    > Console.WriteLine(v.Amount + v.Message);

    In Linq wird massiv gebrauch gemacht von anonymen Typen.

    > Definiere hier 'Mainstream OOP' und 'so lange'. Wie im zweiten Absatz
    > beschrieben hängt letzten Endes vieles von der Sprache selbst ab. Mein
    > Eindruck ist der, dass hier die Forschung einfach nicht so weit war/ist.
    Naja in Java hat es ja mal bis mindestens Java 6 noch nicht Einzug gehalten. Obs bei Java 7 schon verwendet wird, oder erst bei Java 8 weiß ich (noch) nicht. Aber auch in C# wurde Type-Inference eher spät eingeführt, gerade wenn man bedenkt, dass entsprechende Konzepte ja schon sehr lange existieren. Selbst oCaml ist bereits in den 90er entstanden und Type-Inference wurde, wenn ich mich nicht täusche, bereits in den deutlich älteren ML-Sprachen eingesetzt. Mir ist zwar schon klar, dass es sich hier um funktionale Sprachen handelt, aber eine ergänzende Type-Inference kann ich mir jetzt jedenfalls nicht so schwer zum implementieren vorstellen. Gerade bei einfachen Variablen Zuweisungen nach einem "new" Operator.

    > Ich weißt nicht ob das jetzt OCaml war/hieß, aber ich kann mich an
    > Vorträgen zu Implementierungen erinnern die OO+Funktional zusammenführten,
    > was letzten Endes eher in OO mit ein bisschen funktionaler Würze endete.
    > Ich kann mir da nur schwer vorstellen, dass hier ein so striktes und
    > komplexes Typsystem wie sagen wir in Haskell existiert, bei dem sich
    > Interferenz so dermaßen weit durch die Sprache erstreckt.
    Naja, oCaml hat eigentlich schon ein sehr schönes Typsystem und man muss eigentlich nur sehr selten den Typ explizit angeben. Immerhin basiert oCaml auf den ML-Sprachen.

  8. Re: Type Inference ist auch bei statisch-stark-typisierten Sprachen praktisch

    Autor: ssssssssssssssssssss 11.11.11 - 13:47

    schau's dir mal an, bestes typsystem auf dem markt :)
    konsistent und im grunde muss man nirgends explizite typinformationen verwenden, da alles inferiert werden kann :)

  9. Re: Type Inference ist auch bei statisch-stark-typisierten Sprachen praktisch

    Autor: ShinGouki 11.11.11 - 13:56

    Hallo mit einander!
    Solch diskusionen ist man ja gar nicht vom Golem Forum gewöhnt ;)
    Zum Thema , dieser Vortrag erklärt die grundlegenden Konzepte: http://screencasts.chariotsolutions.com/uncovering-the-unknown-principles-of-type-inference-
    Folien:
    http://chariotsolutions.com/presentations/uncovering-the-unknown-principles-of-type-inferenc
    Der entscheidend Punkt beim Thema typinferenz ist ob das typsystem 'structural' Oder 'nominal' ist. Hier noch paar mehr Erläuterungen dazu: http://en.wikipedia.org/wiki/Structural_type_system
    Siehe auch : sum types, product types
    Und so wie ich das sehe haben die Mainstream OOP Sprachen ein nominales typsystem (C# ggf hybrid)

  10. Re: Type Inference ist auch bei statisch-stark-typisierten Sprachen praktisch

    Autor: ChilliConCarne 11.11.11 - 16:21

    andi_lala schrieb:
    --------------------------------------------------------------------------------
    > Hmm...da kann ich jetzt nicht so ganz zustimmen. Wir reden hier ja von
    > statisch typisierten Sprachen anhand des Beispiels C#.
    Gut stimmt. Ich gebe zu, ich habe vorher den Diskussionspunkt ein bisschen umgelenkt, um allgemein über Typisierung und Übersetzung zu schreiben.

    Statisch bedeutet erstmal genaugenommen nur, dass die Typisierung der Variablen soweit vorausberechnet wird, wie es der Programmtext ermöglicht. Dazu ist Starke Typisierung ein Garant by Design (gut, hier existiert ein Interpretations- und Definitionsspielraum für 'stark'), dass eine wirklich allumfassende Typisierung der Programmelemente stattfindet. Und C# ist, soweit ich weiß, wie du sagst nur statisch und nicht stark typisiert.

    > In
    > deinem Beispiel wäre das einfach List. Das heißt also, dass beide Listen
    > den selben Supertyp haben müssen.
    Sobald ich einen Operator auf die Elemente der Liste habe und es sich um eine Sprache handelt, bei der auch innerhalb von Kontrollstrukturen - zB. 'if' - Typdeklarationen erlaubt sind, was ja immer noch nicht gegen statische Typisierung spricht, kann dieser eben ins Schlauchen kommen, wenn ein Typ rauskommt, den dieser nicht kennt. Ich kenne mich in C# wie gesagt nicht wirklich genau aus, aber sowas könnte C# nur handhaben, wenn verlangt wird dass zu Beginn eines Scopes für entsprechende Variablen von vornherein der Typ deklariert werden muss. Dann würde bzw. könnte erst der C# Übersetzer bei meinem Pseudocode meckern.
    Habe ich einen Operator der auf generische Listen, bzw. in diesem Beispiel den Container 'lineare Liste' geeicht ist, geht mit diesem 'Supertyp' natürlich alles in Ordnung.

    > Dieser steht dann ja auch zur Compile
    > fest. Das muss er ja auch bei einer statisch typisierten Sprache.
    Siehe letzten Absatz.

    > Falls du allerdings später den Typ casten würdest, [...]
    > muss ja auch wieder zur Compilezeit Typinformationen feststehen
    Selbes Problem. Siehe vorletzten Absatz.

    > Gut da kommt es natürlich stark auf die IDE an. Im VisualStudio sieht man
    > auf einem Blick, was die Variable für einen Typ hat und welche Methoden
    > usw. existieren.
    Muss nichtmal eine IDE sein. Ein gut dokumentiertes, vernünftiges und möglichst elegantes Typsystem, kann sehr selbsterklärend und intuitiv sein. Aber sicherlich sind IDEs hier eine Hilfe und merzen die ein oder andere Schwierigkeit, sei es wegen Sprachenschwäche oder holprige Codestellen, aus.

    > In C# wurden anonyme Typen eingeführt, welche durch Type-Inference
    > typsicher verwendet werden können. Hier ein kleines Beispiel:
    > > var v = new { Amount = 108, Message = "Hello" };
    > >
    > > // Rest the mouse pointer over v.Amount and v.Message in the following
    > > // statement to verify that their inferred types are int and string.
    > > Console.WriteLine(v.Amount + v.Message);
    Ach so. Ähnliches Konzept wie bei anonymen Funktionen. Selbes Spiel wie oben :-). Geht für den Compiler so lange gut, bis ihm der Algorithmus einen Strich durch die Rechnung macht.

    Ich möchte mit dem Ganzen aber nicht sagen, dass man mit C# genauso in Typeclashes geraten kann, wie mit zB mit C. Soweit ich weiß ist C# hier ein Hybrid. Es wird zur Übersetzungs- und Ausführungszeit eine Typeninferenz durchgeführt, eben wegen des oben genannten Falls bzw. um solch einen gar nicht erst zum Problem werden zu lassen.

    > In Linq wird massiv gebrauch gemacht von anonymen Typen.
    Linq kenne ich jetzt ehrlich gesagt gar nicht.

    > Mir ist zwar schon klar, dass es sich hier
    > um funktionale Sprachen handelt, aber eine ergänzende Type-Inference kann
    > ich mir jetzt jedenfalls nicht so schwer zum implementieren vorstellen.
    > Gerade bei einfachen Variablen Zuweisungen nach einem "new" Operator.
    Der 'new' Operator ist nur die Spitze des Eisbergs. Wenn man für so eine Sprache wirklich vernünftig machen möchte, kommt dann noch die Lehre über Typenklassen etc. hinzu. Das ist zu den eigentlichen Programmiersprachen ein komplett eigenes Gebiet und da geht es erst richtig los. Man merkt dann schnell, dass das alles andere als trivial ist.

    > Naja, oCaml hat eigentlich schon ein sehr schönes Typsystem und man muss
    > eigentlich nur sehr selten den Typ explizit angeben. Immerhin basiert oCaml
    > auf den ML-Sprachen.
    Mir ging es hier weniger um die Eleganz, sondern mehr um die Frage ob es möglich ist in diesen OO+Funktional Sprachen wirklich so stark zu typisieren, wie es in reinen funktionalen oder einigen deklarativen Sprachen der Fall ist.

  11. Re: Type Inference ist auch bei statisch-stark-typisierten Sprachen praktisch

    Autor: ChilliConCarne 11.11.11 - 16:27

    Ach na ja. Ich habe auch nicht immer Lust, große Weisheiten von mir zu geben :).

    Muss man bei Chariot angemeldet sein um die Inhalte sehen zu können? Der meckert bei mir rum. Summen- und Produkttypen machen in dieser Diskussion jetzt denke ich, eher weniger Sinn. Es sind eigentlich nur zwei Herangehensweisen wie ich einen neunen Typ konstruiere.

    Ich vermute alle imperativen Sprachen, oder dessen Weiterentwicklungen haben ein nominales Typsystem. Ich kann mir jedenfalls kaum vorstellen, wie bei Funktionen mit Seiteneffekten sowas sauber über Strukturen ablaufen soll.

  12. Re: Type Inference ist auch bei statisch-stark-typisierten Sprachen praktisch

    Autor: andi_lala 11.11.11 - 17:01

    ChilliConCarne schrieb:
    --------------------------------------------------------------------------------
    > Gut stimmt. Ich gebe zu, ich habe vorher den Diskussionspunkt ein bisschen
    > umgelenkt, um allgemein über Typisierung und Übersetzung zu schreiben.
    >
    > Statisch bedeutet erstmal genaugenommen nur, dass die Typisierung der
    > Variablen soweit vorausberechnet wird, wie es der Programmtext ermöglicht.
    > Dazu ist Starke Typisierung ein Garant by Design (gut, hier existiert ein
    > Interpretations- und Definitionsspielraum für 'stark'), dass eine wirklich
    > allumfassende Typisierung der Programmelemente stattfindet. Und C# ist,
    > soweit ich weiß, wie du sagst nur statisch und nicht stark typisiert.
    Hmm...hier gehen die Meinungen etwas auseinander. C# wird meistens (so wie übrigens auch C++ oder Java) als stark typisiert angesehen.


    > Sobald ich einen Operator auf die Elemente der Liste habe und es sich um
    > eine Sprache handelt, bei der auch innerhalb von Kontrollstrukturen - zB.
    > 'if' - Typdeklarationen erlaubt sind, was ja immer noch nicht gegen
    > statische Typisierung spricht, kann dieser eben ins Schlauchen kommen, wenn
    > ein Typ rauskommt, den dieser nicht kennt.
    Das versteh ich jetzt nicht, weil üblicherweise kommt aus einem Block keine Variable mehr "heraus" wenn sie darin deklariert wurde".

    Normale Zuweisungen in C# müssen nominell-kompatibel sein, im Unterschied zu Zuweisungen von anonymen Typen, welche nur struktur-kompatibel sein müssen.

    > Habe ich einen Operator der auf generische Listen, bzw. in diesem Beispiel
    > den Container 'lineare Liste' geeicht ist, geht mit diesem 'Supertyp'
    > natürlich alles in Ordnung.
    Ich gehe davon aus, dass du jetzt Listen, welche einen Supertyp verlangen meinst und nicht sowas wie Generics, da ja dort wieder zu Compilezeit die verschiedenen Typen berechnet werden und diese Listen auch nicht untereinander kompatibel sind.

    Ich kann mir wirklich nicht vorstellen, wo oder wie es da den Compiler werfen könnte. Man muss aber schon sagen, dass Type-Inference in C# natürlich nicht die vollen Ausmaße annimmt wie bei funktionalen Sprachen, wobei dies ja auch oft nicht nötig ist, da man ja auch anders programmiert. Es wird nämlich eigentlich nur bei der Deklaration (welche gleichzeitig die Erstzuweisung der Variable sein muss) von Variablen verwendet, da man hier statt des Typs einfach "var" schreibt. Das funktioniert immer, wenn für den Compiler der zugewiesene Typ klar ist.

    > Ich möchte mit dem Ganzen aber nicht sagen, dass man mit C# genauso in
    > Typeclashes geraten kann, wie mit zB mit C. Soweit ich weiß ist C# hier ein
    > Hybrid. Es wird zur Übersetzungs- und Ausführungszeit eine Typeninferenz
    > durchgeführt, eben wegen des oben genannten Falls bzw. um solch einen gar
    > nicht erst zum Problem werden zu lassen.

    C ist structurel typisiert (außer struct ironischer weise), aber C# ist (für das meiste) nominell typisiert, deshalb dürfte es etwas schwieriger mit Clashes werden (ausgenommen sind natürlich anonyme Typen, aber da will man das ja auch).

    > Der 'new' Operator ist nur die Spitze des Eisbergs. Wenn man für so eine
    > Sprache wirklich vernünftig machen möchte, kommt dann noch die Lehre über
    > Typenklassen etc. hinzu. Das ist zu den eigentlichen Programmiersprachen
    > ein komplett eigenes Gebiet und da geht es erst richtig los. Man merkt dann
    > schnell, dass das alles andere als trivial ist.
    Es kommt halt drauf an, wie mächtig man das ganze implementiert. In C# kann zum Beispiel kein inferierter Typ direkt in einer Methode zurückgegeben werden, dadurch wird Type-Inference zwar massiv beschnitten, aber dafür verschont man sich auch von viel zusätzlicher Komplexität.

    > Mir ging es hier weniger um die Eleganz, sondern mehr um die Frage ob es
    > möglich ist in diesen OO+Funktional Sprachen wirklich so stark zu
    > typisieren, wie es in reinen funktionalen oder einigen deklarativen
    > Sprachen der Fall ist.
    ML sind rein funktionale Sprachen und oCaml würd ich eher als funktionale Sprache mit einer zusätzlichen OOP-Unterstützung ansehen, welche halt massiv auf Performance ausgelegt ist.

  13. Re: Type Inference ist auch bei statisch-stark-typisierten Sprachen praktisch

    Autor: irata 12.11.11 - 16:16

    andi_lala schrieb:
    --------------------------------------------------------------------------------
    > Ich bin allerdings leicht verwundert, dass Type Inference in Mainstream OOP
    > Sprachen, so lange auf sich warten gelassen hat.

    Wahnsinn, wenn man bedenkt, dass das Konzept seit den 1950ern existiert (Curry, Feys) .

  14. Re: Type Inference ist auch bei statisch-stark-typisierten Sprachen praktisch

    Autor: ShinGouki 13.11.11 - 17:11

    Warum keine typinferenz in OOP Sprachen? Schon mal meinen anderen post gelesen? ;)

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. WBS GRUPPE, deutschlandweit (Home-Office)
  2. Hays AG, Deutschland
  3. Universitätsmedizin der Johannes Gutenberg-Universität Mainz, Mainz
  4. Debeka Kranken- und Lebensversicherungsverein a.G., Koblenz

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 11,69€ (Bestpreis!)
  2. (aktuell u. a. Amazon Basics günstiger (u. a. AXE Superb 128 GB USB 3.1 SuperSpeed USB-Stick für...
  3. (u. a. Digitus S7CD Aktenvernichter für 24,99€, Krups Espresso-Kaffee-Vollautomat EA 8150 für...
  4. (u. a. Sandisk Extreme PRO NVMe 3D SSD 1TB M.2 PCIe 3.0 für 145,90€ (mit Rabattcode...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programmiersprache Go: Schlanke Syntax, schneller Compiler
Programmiersprache Go
Schlanke Syntax, schneller Compiler

Die objektorientierte Programmiersprache Go eignet sich vor allem zum Schreiben von Netzwerk- und Cloud-Diensten.
Von Tim Schürmann


    Pixel 4a im Test: Google macht das Pixel kleiner und noch günstiger
    Pixel 4a im Test
    Google macht das Pixel kleiner und noch günstiger

    Google macht mit dem Pixel 4a einiges anders als beim 3a - und eine Menge richtig, unter anderem beim Preis. Im Herbst sollen eine 5G-Version und das Pixel 5 folgen.
    Ein Test von Tobias Költzsch

    1. Smartphone Google stellt das Pixel 4 ein
    2. Android Googles Dateimanager erlaubt PIN-geschützten Ordner
    3. Google Internes Dokument weist auf faltbares Pixel hin

    Ryzen 7 Mobile 4700U im Test: Der bessere Ultrabook-i7
    Ryzen 7 Mobile 4700U im Test
    Der bessere Ultrabook-i7

    Wir testen AMDs Ryzen-Renoir mit 10 bis 35 Watt sowie mit DDR4-3200 und LPDDR4X-4266. Die Benchmark-Resultate sind beeindruckend.
    Ein Test von Marc Sauter

    1. Renoir Asrock baut 1,92-Liter-Mini-PC für neue AMD-CPUs
    2. Ryzen Pro 4750G/4650G im Test Die mit Abstand besten Desktop-APUs
    3. Arlt-Komplett-PC ausprobiert Mit Ryzen Pro wird der Büro-PC sparsam und flott