staging.inyokaproject.org

DocBriggs schrieb:

Ich sperre mich nur gegen die Aussage, Java sei nicht so mächtig wie andere Programiersprachen.

Brainfuck auch so mächtig wie Java, C oder irgendeine andere Sprache, man sollte schon wissen dass damit in diesem zusammenhang doch etwas anderes gemeint ist.

DocBriggs schrieb:

dass man mit Java alles schnell und sauber programmieren kann (nicht embedded, ok).

Sogar embedded, Stichwort JavaHandy 😉

Bei C reicht mir schon sowas hier ums kotzen zu kriegen:

int a=1, b=2;
if (a=b) {
printf("a ist gleich b\n");
};

Also vielleicht irre ich mich ja, aber verhält sich Java da nicht absolut gleich? (Ach ja, geliebte Pascal-Syntax).

Jedenfalls: Ich persönlich mag Java. Operatoren Überladung vermisse ich zwar auch, aber ohne den Rest kann ich auch ganz gut leben. Der Boilerplade-Code nervt zwar manchmal, ist aber immernoch zig mal besser als dieses Header- und Sourcefile Gebimmel bei C++.

Imho ist das hier ne reine Geschmacks-Diskussion.

Es ist jetzt schon also Wortklauberei, wenn man erst einmal darüber nachdenkt, worüber man überhaupt diskutieren will, bevor man selbiges tut?

Übrigens interessant, dass ich vorhin ein falsches Beispiel gewählt habe und es trotzdem niemand gemerkt hat. Der Comparator, der zwei Objekte anhand eines Members vergleicht, kann in Java sehr wohl generisch implementiert werden, nämlich per Reflection. Das ist umständlich und fehleranfällig, aber es geht. (Böse Zungen könnten behaupten, dass die Java-Apologeten ihre eigene Sprache nicht beherrschen - ich würde so etwas natürlich nie sagen).

Das if(a=b)-Beispiel ist übrigens IMO nicht sehr aussagekräftig, da der Compiler davor warnt.

derMani schrieb:

Was fehlt dir?

Meine Liste:

• Operatorüberladung: Macht Code lesbarer

• Funktionierende Generics: Trotz Generics darf man fröhlich weitercasten, weil die Typinformationen zur Laufzeit nicht mehr verfügbar sind

• Properties: Man muss keine stumpfen trivialen getter und setter mehr schreiben –> code lesbarer, da weniger

• Funktionszeiger: Wär ganz nett.

• Alles ein Objekt: Wäre schön, wenn die primitiven Datentypen verschwinden würden.

C# geht da schon deutlich in die richtige Richtung.

@DocBriggs: Geringe Ausdruckstärke bedeutet nicht, dass man mit Java nicht arbeiten kann. Nur, dass man es komplizierter machen muss, als es in anderen Sprachen nötig wäre. Und das ist bei Java der Fall.

• Properties: Man muss keine stumpfen trivialen getter und setter mehr schreiben –> code lesbarer, da weniger

Boah ja, gehen mir die setter und getter aufn Sack

• Funktionszeiger: Wär ganz nett.

Java hat sowas nicht?! Brauchte ich in Java noch nie, aber ich bin davon ausgegangen, dass es sie gibt.

Mit Reflection kann man, wie ich in meinem letzten Posting bereits sagte, einige Sachen notdürftig nachbauen (z. B. eben Methodenzeiger über die Method-Klasse des Reflection-APIs). Schön ist das aber nicht.

Hier übrigens ein ein interessantes Video über C++ aus der Sicht eines Code Begutachters ^[1]. Trotz des Fokus auf C++ ist es dennoch interessant, da beschrieben wird, wie einige der hier vermissten Features (z.B. Überladen von Operatoren) einem das Finden von Fehlern zum Albtraum machen kann.

^[1] http://chaosradio.ccc.de/camp2007_m4v_1951.html

Ferio schrieb:

Meine Liste:

• Operatorüberladung: Macht Code lesbarer

• Funktionierende Generics: Trotz Generics darf man fröhlich weitercasten, weil die Typinformationen zur Laufzeit nicht mehr verfügbar sind

• Properties: Man muss keine stumpfen trivialen getter und setter mehr schreiben –> code lesbarer, da weniger

• Funktionszeiger: Wär ganz nett.

• Alles ein Objekt: Wäre schön, wenn die primitiven Datentypen verschwinden würden.

C# geht da schon deutlich in die richtige Richtung.

@DocBriggs: Geringe Ausdruckstärke bedeutet nicht, dass man mit Java nicht arbeiten kann. Nur, dass man es komplizierter machen muss, als es in anderen Sprachen nötig wäre. Und das ist bei Java der Fall.

Das Paradigma "Alles ist ein Objekt" kann man hervorragend in Java mit den Wrapperklassen Integer und co umsetzen. Wer es möchte kann somit genau das erreichen.

Ansonsten konnte mir immer noch niemand bisher erklären, was so speziell an primitiven Datentypen sein soll, dass man dafür ein Objekt benötigen würde. Ein primitiver Datentyp ist das elementarste was es gibt, nichts abstraktes ... es ist die minimalste Form von Element was vorkommen kann, deshalb ist es schlichtweg eigentlich total unnötig da Objekte raus zu basteln...

Naja wie gesagt, das Thema beschäftigt die OO nun schon seit Jahren, und wer will kann in Java halt anders programmieren 😉

Zu den anderen Punkten:

Operatorüberladung... weiß nich, nie gebraucht, brauchen nur C-Leute... ich finde Methoden übersichtlicher und leichter lesbar. Generics stimme ich dir zu, werden leider nur vom Compiler verifiziert soweit ich weiß und nicht zur Laufzeit ausgewertet. Properties.... stimmt wäre nett, so schlimm find ich es nun nicht, da Eclipse und diverse andere IDEs ja das automatische Erstellen der Getter/Setter-Methoden beherrschen.

Es stimmt schon Java verfüt vllt nicht über einige "codesparenden" Dinge, aber die Stärke der Sprache ist definitiv die dahinterliegende API die vieles wieder wettmacht.

Gruß Mani

derMani schrieb:

Operatorüberladung... weiß nich, nie gebraucht, brauchen nur C-Leute...

In C gibt es keine Operatorüberladung...

Hello World schrieb:

[...]das if(a=b)-Beispiel ist übrigens IMO nicht sehr aussagekräftig, da der Compiler davor warnt.

Wenn das kein schlechter Code ist, dann weiß ich auch nicht.

derMani schrieb:

Ansonsten konnte mir immer noch niemand bisher erklären, was so speziell an primitiven Datentypen sein soll, dass man dafür ein Objekt benötigen würde.

Wenn an denen nicht speziell ist, warum dann eine Extrawurst? Primitive Datentypen verhalten sich anders als Objekte. Und bei den Wrapperklassen gibt es plötzlich Operatorüberladung. Auch nett:

1
2
3
4
5
6

        Integer a = 2;
        Integer b = 2;
        Integer c = 60000;
        Integer d = 60000;
        System.out.println(a == b); // true
        System.out.println(c == d); // false

Das Verhalten ist zwar erklärbar, aber alles andere als intuitiv verständlich.

Naja wie gesagt, das Thema beschäftigt die OO nun schon seit Jahren, und wer will kann in Java halt anders programmieren 😉

Gegen die Sprache zu programmieren ist nie eine gute Idee.

Operatorüberladung... weiß nich, nie gebraucht, brauchen nur C-Leute... ich finde Methoden übersichtlicher und leichter lesbar.

Ich persönlich finde a.add(b.divide(c)) nicht lesbarer als a + b/c. Auch a == b ist lesbarer als a.equals(b). Und Operatorüberladung ist ganz bestimmt keine Erfindung von C++.

DocBriggs schrieb:

Hello World schrieb:

[...]das if(a=b)-Beispiel ist übrigens IMO nicht sehr aussagekräftig, da der Compiler davor warnt.

Wenn das kein schlechter Code ist, dann weiß ich auch nicht.

Hier ein gültiges Beispiel dieses Codes; und der Compiler warnt nicht!

$ cat t.c
#include <stdio.h>

void copy(const char* a, char* b)
{
   while (*b++ = *a++);
}

int main()
{
   const char a[] = "abc";
   char b[sizeof(a)];
   copy(a, b);
   puts(b);
   return 0;
}

$ gcc -o t t.c

$ ./t
abc

$ gcc --version
gcc-4.2 (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Über die Schönheit/Lesbarkeit des Kopierkonstruktes lässt sich natürlich streiten.

Wer jetzt allerdings sagt, kein Programmierer mit 2 Gramm Hirn im Schädel würde sowas machen: Das Beispiel kommt so ganz änhlich in Kernigan/Ritchie "The C Programming language" vor ... als guter Code.

Und wenn Java wirklich so crap ist wieso ist es dann so verbreitet und eigentlich auch beliebt?

vlc

Hier ein gültiges Beispiel dieses Codes; und der Compiler warnt nicht!

Kommt auch keine Warnung, wenn man sich alle Warnungen anzeigen lässt mit dem Schalter -Wall?