Re: Getter & Setter

* Jochen Theodorou:

Florian Weimer schrieb:
* Jochen Theodorou:

Es geht auch nicht direkt um Schwächen von Java in seinen
Konzepten. Aber die bisherige Weigerung zum Beispiel Typinferenz in
Java aufzunehmen in Kombination mit Generics halte ich für ein
brauchbares Beispiel.

Meinst Du echte Typinferenz oder bloße Vorwärtsverbreitung von
Typ-Information? Echte Typinferenz ist ziemlich schwierig, braucht wohl
Row Types und ist u.U. nicht richtig verträglich mit der Einführung von
Closures.

Vorwärtsverbreitung von yp-Informationen wäre doch schon mal ein
Anfang. Das mit den Closures musst du mir aber mal kurz erklären, weil
ich zum bEispiel auch nicht sicher bin was Row Types

Row Types sind so etwas wie ad-hoc-Interface-Typen, also "egal welche
Klasse, solange sie eine Methode foo(String) hat". Ich habe im
Hinterkopf, daß das herausbekommen von Varianz nicht ganz einfach ist,
und für die angepeilte knappe Closures-Syntax müßte man das wohl
machen.

Java ist mit dem Verzicht auf Typinferenz auch bei weitem nicht allein.
C++ und Ada machen das ebenfalls nicht (wobei Ada nur benannte Generics
hat und damit andere Probleme). Es gibt also in der Industrie eine lange
Tradition in diesem Bereich.

Viele Sprachen machen das nicht, vorallem scheinen manche Leute zu
denken, dass das eine Domäne der funktionalen Sprachen sei und bleiben
müsse.

C++0X wird damit aufräumen, auto ist angenommen.

Bei ML ist das Hauptproblem eher der Hack, die Klammern beim
Funktionsaufruf wegzulassen. Dadurch kann man Kombinator-Bibliotheken
schreiben, die zu Ausdrücken mit bildschirmfüllenden Typen führen.

Ich habe nie in ML programmiert, aber schon öfter kleine Programme in
ML gesehen... nur hatte ich mit den Typen da immer
Probleme. Vielleicht ein Mangel an Übung.

Die Typen sind ein Problem, das ist ähnlich wie bei C++-Templates.
Wenn es einen Fehler gibt, ist man bei den eleganten Bibliotheken erst
einmal aufgeschmissen.

Grundsätzlich halte ich Java gar nicht mal für *so* übel, was die
Balance zwichen Kosten und Nutzen durch Typisierung angeht.

su meinst eine starke, statische Typisierung mit einigen
Aufweichungen? Es gibt ja ganz verschiedene Typsysteme

Ja, mit Generics ist es doch gar nicht so schlimm. Jedenfalls kann man
die Sprache m.E. auch ohne IDE nutzen (auch wenn das vielleicht keine
mehrheitsfähige Meinung ist, weil JSR 269 schließlich sehr langsam
angenommen wird, wenn überhaupt).

Sicherlich ist ein Typsystem auf diesem Niveau in erster Linie eine
Optimierung, um den Code effizienter ausführen zu können, die auf
Kosten des Programmieraufwandes geht.

ehm.... ich denke du meinst damit dann statische Typisierung.

Eher das Fehlen von Dependent Types, einem Beweissystem usw., wo die
Typen viel weitergehende Aussagen über das Programm machen.

Allerdings muss man hier sehen, dass die "gute"
Performanz in Java hauptsächlich in den Methodenaufrufen zu finden
ist. Die sind wirklich schnell für eine objektorientierte Sprache.

Für eine objektorientierte Sprache, die eine offene Welt unterstützt
(also beliebigen Code zur Laufzeit nachladen kann), stimmt das. Mit
dem Aufwand, den man bis heute in die Referenzimplementierung gesteckt
hat und dem Wissen von heute hätte man wohl auch eine ähnlich
performante, weitaus dynamischere VM bauen können.

Von meiner Warte ist aber die Hauptkritik sowieso, daß Java vorrangig
eine Windows-Sprache ist, die nur halbherzig auf UNIX-ähnliche Systeme
(insbesondere solche mit lächerlich niedrigen Prozeßerzeugungskosten)
portiert wurde. 8-P

Ich jedenfalls sehe die Optimierung eher in der Wahl von single
dispatch anstatt von multiple dispatch, als daran statische Typen zu
wählen.

Die Möglichkeit, sehr einfach Ganz- und Gleitkommazahlen in Registern
zu übergeben und nicht geboxte Felder zu implementieren, ist m.E.
nicht zu unterschätzen. Das sind jedenfalls Dinge, die die Sprache
deutlich komplizierter machen, aber auch effizienteren Code gestatten
(bzw. dessen Erzeugung erheblich vereinfachen).
.

Relevant Pages

  • Re: Java Generics: limitations?
    ... cannot go around and do something similar to what I've said, then Java ... generics cannot be called generics, ... have pointed out, the HasXY interface is not necessary, and could be ... public int getX(); ...
    (comp.lang.java.programmer)
  • Re: Getter & Setter
    ... ich zumBbeispiel auch nicht sicher bin was Row Types ... C++ und Ada machen das ebenfalls nicht (wobei Ada nur benannte Generics ... Performanz in Java hauptsächlich in den Methodenaufrufen zu finden ...
    (de.comp.lang.java)
  • Re: unsafe or unchecked operations
    ... Generics are by far the most complicated thing I have encountered in ... The Java Glossaryhttp://mindprod.com ... same warning ... But how does casting happen when 'filters!= null'? ...
    (comp.lang.java.help)
  • Re: why doesnt ruby have generics?
    ... Why would you bind to a type in a language that doesn't really care ... cannot have generics in a language whose variables are typeless as ... Listin Java.) ... In Ruby you can do neither: you cannot cast because variables are ...
    (comp.lang.ruby)
  • Re: Problem beim starten eines jar
    ... Das hatte ich doch schon beschrieben..oder meinst ... > Java HotSpotClient VM ... Prev by Date: ... Next by Date: ...
    (de.comp.lang.java)