"java suck"

~fricky schrieb:

Shade Of Mine schrieb:

~fricky schrieb:

das ist kein fehler. der hashcode bezieht sich auf die objekte, nicht deren inhalt.

in der tat.

bei strings könnte man meinen, es wäre anders. das liegt aber nur daran, dass strings unveränderlich sind und daher dürfen alle strings mit gleichem inhalt auch das gleiche objekt sein. beispiel:
String a = "hallo";
String b = "hallo";
String c = a;
String d = a.substring(0);
^^ sieht nach 3 oder 4 verschiedenen objekten aus. tatsächlich gibt es "hallo" aber nur ein mal.

Lol? Und dann über C++ lästern

Wie sinnvoll ist es denn bitte Objekte nach Identität und nicht nach Gleichheit zu hashen?

C++-Progger schrieb:

Wie sinnvoll ist es denn bitte Objekte nach Identität und nicht nach Gleichheit zu hashen?

sehr sinnvoll. kommt so ein objekt z.b. über eine netzwerkverbindung angeflogen, kannste es sofort identifizieren. seine daten, sein innerer zustand etc. sind dafür erstmal zweitrangig. was bedeutet für dich eigentlich 'gleichheit'?

C++-Progger schrieb:

Lol? Und dann über C++ lästern

das lass mal bleiben. hier ist doch der java-lästerthread.

byto

C++-Progger schrieb:

Wie sinnvoll ist es denn bitte Objekte nach Identität und nicht nach Gleichheit zu hashen?

Objekte werden in Java nach Gleichheit gehasht. Aber der Hash von Arrays geht halt per Default nicht auf die Elemente. Anders ist das bei Collections (List, Set, Map). Der Hash von Arrays ist aber trotzdem konsistent mit der Gleichheit von Arrays, denn equals() geht auch hier nicht auf die Elemente. Möchte man dieses Verhalten für Arrays haben, dann benutzt man Arrays.equals(array1, array2) bzw. Arrays.hashcode(array1, array2). Oder man programmiert nach Schnittstellen und nimmt gleich ne (Array)List. Dann hat man Gleichheit / Hashcode auf den Elementen + Array Realisierung.

DEvent

Shade Of Mine schrieb:

byto schrieb:

Die Lösung ist recht simpel (Arrays.equals(array1, array2)) und existiert seit Version 1.2, also seit rund 11 Jahren.

Das Problem ist nicht 2 Zeichenketten auf gleichheit zu überprüfen sondern den hash einer bytefolge zu nehmen.

habe ich persönlich nie gebraucht, aber wenn 2 identische bytearrays unterschiedlichen hash code liefern, ist das ein fehler.

Was hinder dich daran sowas zu schreiben:

class ArrayContainer {
    private byte[] bytes;

    public ArrayContainer(byte[] bytes) { ... }

    public int hashCode() { return Arrays.hashcode(bytes); }

    public boolean equals(Object that) {return Arrays.equals(that); }
}

Und dann ArrayContainer anstatt dem Array in deine HashMap aufzunehmen? In dem Artikel wird zwar das Ableiten von Hashtable, Ableiten von Array und das Schreiben einer eigener HashMap vorgeschlagen, aber sowas einfach wie das Kapseln von Array wird natuerlich nicht erwaehnt.

Der ganze Artikel ist einfach Bloedsinn. Der Author ist bestimmt ein C/C++ Programmierer und erwartet das alle Sprachen sich wie diese verhalten muessen. Das faengt ja schon mit dem ersten Punkt an

It's hard to live with none of: lexically scoped local functions; a macro system; and inlined functions.

dafür, dass java so schlecht ist, ist es viel zu weit verbreitet

looooooooool schrieb:

dafür, dass java so schlecht ist, ist es viel zu weit verbreitet

ist doch mit vielen dingen so. suboptimales zeug stirbt nicht einfach aus, weil es besseres gibt. gerade bei programmiersprachen scheint's sowas wie 'natürliche selektion' nicht zu geben.
btw, ^^das soll nicht gegen java gerichtet sein. ich mag java ganz gern.

~fricky schrieb:

looooooooool schrieb:

dafür, dass java so schlecht ist, ist es viel zu weit verbreitet

ist doch mit vielen dingen so. suboptimales zeug stirbt nicht einfach aus, weil es besseres gibt. gerade bei programmiersprachen scheint's sowas wie 'natürliche selektion' nicht zu geben.
btw, ^^das soll nicht gegen java gerichtet sein. ich mag java ganz gern.

...du magst auch C ganz gern!

Ja aber... schrieb:

du magst auch C ganz gern

eigentlich schon. ist doch kein widerspruch, oder?

Doch :p

byto schrieb:

C++-Progger schrieb:

Wie sinnvoll ist es denn bitte Objekte nach Identität und nicht nach Gleichheit zu hashen?

Objekte werden in Java nach Gleichheit gehasht. Aber der Hash von Arrays geht halt per Default nicht auf die Elemente.

Per default wird nach Object.hashCode() gehasht und das macht es, wenn man es nicht überschreibt, für die Identität. Ebenso wie equals(). Egal ob für array oder nicht array, da gibt es keinen Unterschied. Überhaupt arbeiten diese beiden Methoden zusammen und man sollte entweder keine oder beide redefinieren.

@C++-Progger: Das ist nützlich, wenn es darum geht, genau das selbe Objekt schnell wieder zu finden und entspricht in etwa einem hashen nach Adresse. Die Nützlichkeit davon steht wohl außer Frage.

In den Collections kann man meines Wissens nach ggf. einen anderen Functor verwenden, wenn man nicht an der Identität interessiert ist. Das finde ich sauberer, als die Methoden von Object zu überschreiben, so schön wie boost.unordered macht es die Sache aber schon nicht.

Gregor

~fricky schrieb:

looooooooool schrieb:

dafür, dass java so schlecht ist, ist es viel zu weit verbreitet

ist doch mit vielen dingen so. suboptimales zeug stirbt nicht einfach aus, weil es besseres gibt. gerade bei programmiersprachen scheint's sowas wie 'natürliche selektion' nicht zu geben.

Doch doch. Diese Selektion gibt es durchaus. Aber anscheinend ist es gerade bei Programmiersprachen so, dass vielen Leuten die Bewertungskriterien nicht klar sind. Da fokussiert man sich auf irgendwelche kleinen Sprachdetails und meint, daraus herleiten zu können, dass eine Sprache gegenüber einer anderen irgendwie minderwertig ist. Aber letztendlich spielen derartige Details ungefähr gar keine Rolle. Was zählt, ist ein Gesamtpaket, zu dem sogar noch wesentlich mehr als die Sprache ansich gehört.

DEvent

Gregor schrieb:

~fricky schrieb:

looooooooool schrieb:

dafür, dass java so schlecht ist, ist es viel zu weit verbreitet

ist doch mit vielen dingen so. suboptimales zeug stirbt nicht einfach aus, weil es besseres gibt. gerade bei programmiersprachen scheint's sowas wie 'natürliche selektion' nicht zu geben.

Doch doch. Diese Selektion gibt es durchaus. Aber anscheinend ist es gerade bei Programmiersprachen so, dass vielen Leuten die Bewertungskriterien nicht klar sind. Da fokussiert man sich auf irgendwelche kleinen Sprachdetails und meint, daraus herleiten zu können, dass eine Sprache gegenüber einer anderen irgendwie minderwertig ist. Aber letztendlich spielen derartige Details ungefähr gar keine Rolle. Was zählt, ist ein Gesamtpaket, zu dem sogar noch wesentlich mehr als die Sprache ansich gehört.

Mir gefaellt an Java vor das Gesamtpaket, vor allem aber die Sprache an sich, das Konzept dahinter, die IDE und die Bibliothek. Die Build-Tools sind leider alle noch etwas Beta, zumindest Maven2. Es ist auf jeden fall ein gewaltiger Vortschritt im Gegensatz zu C oder C++.

DEvent schrieb:

Vortschritt

EPIC FAIL :p

java noob

wie eine gute Programmiersprache aussieht, zeigt die relativ neue Programmiersprache Cobra von cobra-language..com:

einfache Python-ähnliche Syntax, wahlweise statisch oder dynamisch typisiert, design-by-contract, Bytecode. Zum Vergleich mit java sage ich jetzt nichts.

u_ser-l schrieb:

wie eine gute Programmiersprache aussieht, zeigt die relativ neue Programmiersprache Cobra von cobra-language..com:

einfache Python-ähnliche Syntax, wahlweise statisch oder dynamisch typisiert, design-by-contract, Bytecode. Zum Vergleich mit java sage ich jetzt nichts.

Nimm doch lieber gleich eine richtige Programmiersprache mit der man auch effizient Arbeiten kann: python.

Oder eine Sprache, in der du so tun kannst, als ob du effektiv wärst:
Java.

Oder vielleicht eine Sprache, in der du effektiv Programmieren musst, um nicht innerhalb der ersten wochen zu verzweifeln, wobei am ende meist eh nix effizientes rauskommt (in Anbetracht des zeitaufwandes):
C++

Python is broken by design.
Cobra wird über den Zustand der Irrelevanz nie hinauskommen, wurde sogar aus Wikipedia gelöscht: http://de.wikipedia.org/wiki/Wikipedia:Löschkandidaten/26._November_2008#Cobra_.28Programmiersprache.29_.28gel.C3.B6scht.29

Man sollte gleich das Original nehmen: Groovy!

qwertzu schrieb:

Cobra wird über den Zustand der Irrelevanz nie hinauskommen, wurde sogar aus Wikipedia gelöscht

DAS hat gar nichts zu bedeuten

Löschipedia sucks schrieb:

qwertzu schrieb:

Cobra wird über den Zustand der Irrelevanz nie hinauskommen, wurde sogar aus Wikipedia gelöscht

DAS hat gar nichts zu bedeuten

Niemand interessiert sich für den Quatsch. :p

die Zeit ist reif für eine Sprache mit der Typisierungs-Flexibilität und der eleganten Syntax von Esterbrook's Cobra.

in der englischen wiklpedla existiert der Eintrag übrigens.

Schneewittchen

u_ser-l schrieb:

die Zeit ist reif für eine Sprache mit der Typisierungs-Flexibilität und der eleganten Syntax von Esterbrook's Cobra.

in der englischen wiklpedla existiert der Eintrag übrigens.

Also ich habe eben in den wikipedia Eintrag geschaut.

Ich fasse mal zusammen:
"It is strongly influenced by Python," -> okay hat sich was von python und paar anderen Sprachen was abgeguckt. Nichts neues.

"and runs on the Microsoft .NET " -> BAMM, und schon hat cobra (unnötigerweise) die Vorzüge einer portablen Sprache verspielt.

"Appeared in 2006" -> Muss ja echt ausgereift sein.

"It supports both static and dynamic typing." -> Haut mich jetzt nicht vom Stuhl. Bei der dynamischen Typisierung kannst du immer noch auf den Typ testen. In python kannst du dir beispielsweise (wenn gewünscht) (Funktions-)dekoratoren erstellen, die für dich den typ der Argumente oder des Rückgabewerts überprüfen/festlegen und bei Bedarf ne Exception werfen, wenn der Typ nicht passt. Funktionsdekoratoren sind nicht umständlicher als die explizite Angabe des Typs. Wozu man hier auch noch unbedingt statische Typisierung braucht, ist mir nicht klar.

Und naja, in dem wikipediaartikel befindet sich in der "Features"-Liste auch nichts neues, was einen dazu bewegen könnte diese Sprache zu erlernen.

Wieder eine "neuartige" Sprache die man getrost mit einem müden Gähnen vernachlässigen kann.

EDIT: Auch noch witzig:
Unter den "Features" stand: "shebang line (#!)" Tolles feature.
Das normalste auf der Welt unter den unix-scripten.

&quot;java suck&quot;

"java suck"