Fun-Soft - Programmierforum

Autor

Thread - Seiten: [ 1 ] [ 2 ] > 3 < [ 4 ] [ 5 ] [ 6 ] [ 7 ]

020
23.11.2006, 08:16 Uhr
ao

(Operator)

Zitat:

Referenzen u. Pointer sind nicht Allheilmittel. Aber es ist schön, sie benutzen zu können!

Wofür, wenn die Sprache gute Alternativen hat? Welche konkreten Möglichkeiten fehlen dir?

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

021
23.11.2006, 08:37 Uhr
0xdeadbeef
Gott
(Operator)

Was mich an Java stört, sind im Grunde drei Dinge.

1. Alle Objekte liegen auf dem Heap

Ich hab im Grunde kein Problem mit garbage-collection, aber das Konzept ist nicht so mächtig, wie es zunächst den Anschein hat. Abgesehen davon, dass ein GC sich in aller Regel nur um Speicher kümmert, was meines Erachtens eine etwas beschränkte Sicht auf anforderbare Ressourcen darstellt, ist das Problem mit allen mir bekannten Implementierungen eines garbage collectors, dass man keine Ahnung oder Kontrolle hat, wann das Objekt denn zerstört wird. Das macht Destruktoren nahezu nutzlos, und Freigabeautomatismen, wie zum Beispiel zu beobachten in den Lock-Klassen der Boost.Thread-Bibliothek, werden ein Ding der Unmöglichkeit. Davon abgesehen ist der Heap auch mit Garbage-Collector deutlich ineffizienter zu bevölkern als der Stack, also wünschte ich mir eine Möglichkeit, Objekte auf den Heap zu legen.

2. Inkonsistenzen in der Sprache, z.B. bezüglich java.lang.String.

Java hat keine Operatorüberladung. Das ist im Grunde nicht schlimm, auch wenn ich das Feature in C++ wirklich gerne mag. Das Problem ist aber, dass die Sprache semantische Ausnahmen macht, um dem Einsteiger die Arbeit zu vereinfachen - so kann java.lang.String per +-Operator verbunden werden. Auch sind einige andere Konzepte eher halbherzig durchgezogen worden, so ist z.B. die Idee, dass alles von Object abgeleitet sein soll, durchaus vertretbar, aber das muss dann im Interesse der Konsistenz auch auf numerische Typen ausgeweitet werden.

3. lazy binding

Ich bin mir bewusst, dass dieses Konzept in letzter Zeit sehr modern ist, aber persönlich halte ich es für einen Schritt in die völlig falsche Richtung, das Programm die Arbeit des Compilers übernehmen zu lassen. Die bloße Existenz einer "NoSuchMethodError"-Klasse ist in meinen Augen ein Zeichen für mieses Sprachdesig.

Mit etwas Überlegung fielen mir möglicherweise noch mehr ein, aber das sind so ziemlich die drei Hauptpunkte. Mir ist bewusst, dass einiges davon Geschmackssache ist, aber es stört mich halt.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

022
23.11.2006, 09:11 Uhr
Guybrush Threepwood
Gefürchteter Pirat
(Operator)

Also mit Java kenne ich mich nicht aus aber mal was zur GC

Zitat:

dass man keine Ahnung oder Kontrolle hat, wann das Objekt denn zerstört wird. Das macht Destruktoren nahezu nutzlos

Stimmt, aber dafür sollte es dann normalerweise Alternativen geben. Unter C# zum Beispiel kann man seine Klasse dann von einem Bestimmten Interface ableiten das die Möglichkeit dafür bietet oder seine Variablen in einem using Block deklarieren.

Zitat:

In C sind Speicherfehler die bei weitem schlimmste Klasse von Fehlern, was die Häufigkeit angeht und die Schwierigkeit, sie zu finden

Die meisten Entwickler leiden aber unter dem Irrglauben das sie es selbst besser könnten.

Dieser Post wurde am 23.11.2006 um 09:11 Uhr von Guybrush Threepwood editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

023
23.11.2006, 09:44 Uhr
0xdeadbeef
Gott
(Operator)

Ich sag ja, ich hab prinzipiell nichts gegen garbage collection. Aber ich will zumindest die Möglichkeit, selbst zu entscheiden, wann ein Objekt zerstört wird. Und ich will am besten einen Automatismus, wie es in C++ üblich ist.

Was C angeht, der Vergleich zwischen C und Java ist marginal unfair, da Java Paradigmen implementiert, die, als C entwickelt wurde, noch gar nicht erfunden worden waren.

Am Ende muss man aber auch sehen: Es gibt keine beste Sprache als solche. Je nach Anwendung empfiehlt sich mal die eine, mal die andere. Java hat seine Nische bei Webservices, aber ich käme nie auf die Idee, Firmware in Java zu schreiben. Für viele mathematische Anwendungsbereiche ist LISP eine gute Alternative - mal versucht, in C++ eine Funktion zu integrieren?
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

024
23.11.2006, 13:54 Uhr
Reyx
IT-fetischistischer Wurstsalat mit rostigem Berghorn
(Operator)

Zitat von Lensflare:

Es wird aber nicht die Java-Datei interpretiert sondern der bytecode.
Die Java-Datei wird in den bytecode übersetzt, genauso wie eine C++ Datei in Maschinencode übersetzt wird.
Den Maschinencode liest der Prozessor und den bytecode liesst die virtual machine.
Wie die virtual machine den bytecode liest und ihn für den Prozessor übersetzt, ist ihre Sache.
Das hat doch nichts mehr mit der Java-Datei zu tun.

Wenn das Ergebnis einer Datei (Ergebnis -> z.B. Bytecode!) interpretiert werden muss, dann handelt es sich um eine Interpretersprache. Ob das nun vorher zu einem Zwischending kompiliert wurde oder nicht, ist wurscht. Es wird interpretiert, und somit ist es eine Interpretersprache.

Im Bezug auf Speicherlöcher:

Zitat:

Die meisten Entwickler leiden unter dem Irrglauben, das sie es selbst besser könnten.

Der Rest glaubt nur leider, dass es niemand könne, und somit verboten gehörte.

Dieser Post wurde am 23.11.2006 um 13:57 Uhr von Reyx editiert.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

025
23.11.2006, 14:20 Uhr
Guybrush Threepwood
Gefürchteter Pirat
(Operator)

Zitat von Reyx:

Es wird interpretiert, und somit ist es eine Interpretersprache.

und das ist schlimm weil...?

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

026
23.11.2006, 15:31 Uhr
KaraHead

Java wird zwar interprtiert aber dank Hot-Spot Optimierung und der Rechenleistung heutiger PCs ist das doch kein Thema mehr.

Zitat:

Proprietäre Sprache, wennauch wohl demnächst OpenSource.

Du sagst es selber, Java wird OpenSource auch wenn es noch eine Weile dauern wird.
Außerdem bin ich froh, dass Java keinem Standard-Komitee unterliegt, weil sonst Änderungen/Verbesserungen zu lange dauern würden, siehe C++0x.
Ich finde, dass Sun seinen Job bis jetzt ganz gut macht.

Aber wie 0xdeadbeef schon gesagt hat, hat jede Sprache sein Einsatzgebiet.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

027
23.11.2006, 15:39 Uhr
Guybrush Threepwood
Gefürchteter Pirat
(Operator)

Zitat von KaraHead:

Außerdem bin ich froh, dass Java keinem Standard-Komitee unterliegt, weil sonst Änderungen/Verbesserungen zu lange dauern würden, siehe C++0x.

Naja das ist ein zweischneidiges Schwert. Ein Standard versichert dir auch das sich nicht plötzlich das verhalten einer Funktion ändert und sie was anderes macht als bisher. Was ja bei Java soweit ich weiß schon vorgekommen ist.

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

028
27.11.2006, 22:34 Uhr
J-jayz-Z
Perl Crack ala Carte
(Operator)

Zitat von Guybrush Threepwood:

Was ja bei Java soweit ich weiß schon vorgekommen ist.

Kannst du das auch belegen oder "hat das nur mal einer gesagt der was von nem Kumpel gehört hat dessen Kumpel Java programmiert" ?

Nicht böse nehmen, ich hoffe du weißt, worauf ich hinaus will. Java mag nicht die beste Sprache sein und mitSicherheit auch nicht die schnellste. Aber es ist zusammen mit C#, so meine Meinung, mit Sicherheit eine der "schönsten" Sprachen. Die Sprache verleitet zu gutem Design und das ist evtl. schon die halbe Miete ... Ich mach in letzter Zeit ziemlich wenig damit,merke aber auch, das die Theoriedie man bei Java "eingehämmert" bekommt Niet und Nagelfeste OOP Theorie ist.Mein Stil ist seid ich Java kann mit Sicherheit um einiges schöner wie vorher. Die beste Sprache zum lernen und die schönste für große Projekte. So meine Aussage. Auch wenn ich Performance einbüßen muss, bringt Java in den meisten Fällen doch alles mit, was man benötigt.

Ich halte es für totalen Schwachsinn (sorry, wenn ich das so deutlich sage) Java nicht als Programiersprache anzuerkennen. Nur weil man nicht grad C, C++ oder was weiß ich was macht wird man als "schlechterer" Programmierer abgestempelt. Wenn ich schon so Zeug hör wie "Was programmierst du den? Ha, Perl. Perl? Perl ist doch keine Programmiersprache!" könnt ich schon fast das kotzen kriegen ... Na ja, egal. Frust abgelassen, war ein harter Tag heute

--
perl -Mstrict -Mwarnings -e 'package blub; sub new { bless {} } sub bar {my $self=shift; $self->{bla}="66756e2d736f66742e6465"; return $self->{bla};} my $foo=blub->new();print "Hallo ";print pack("H*",$foo->bar()); print "\n"'

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

029
28.11.2006, 11:07 Uhr
ao

(Operator)

Zitat von Reyx:

Im Bezug auf Speicherlöcher:

Zitat:

Die meisten Entwickler leiden unter dem Irrglauben, das sie es selbst besser könnten.

Der Rest glaubt nur leider, dass es niemand könne, und somit verboten gehörte.

Ich habe nicht gesagt, dass es *niemand* kann. Aber es ist offensichtlich, dass viele Entwickler sich selber hier überschätzen, oder wie sonst ist zu erklären, dass freigegebene Programmversionen immer noch so reichlich "Access Violations" und "Buffer overflows" produzieren, obwohl das ganze Team nächtelang gebugfixt hat?

Ja klar, schuld sind die Manager, die den Entwicklern immer weniger Zeit zum Testen lassen, obwohl die Projekte immer komplizierter werden. Aber diese Entschuldigung ist auch nicht mehr neu, und wenn die Aufgaben komplizierter werden, muss man sich eben bessere Werkzeuge verschaffen, auch das gehört zu den Aufgaben eines Entwicklers. Eine Sprache mit eingebautem Speichermanagement ist da zumindest ein interessanter Ansatz.

ao

Profil || Private Message || Suche

Download || Zitatantwort || Editieren || Löschen || IP

Seiten: [ 1 ] [ 2 ] > 3 < [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ Anregungen ]

ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: