|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
|
|
|
|
...kann ich endlich in meiner lieblingssprache programmieren. Java ist einfach eine wunderschöne Programmiersprache.
/* Nur wer schneller ist als der Strom hat die Kontrolle! */
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Java ist ein Krueppel, nix von wunderschoen. Wenn jemand schon seine eigene VM bastelt, warum macht er dann so ne laue Sprache dazu? Nur dass Java schoener ist als C++ will nix heissen: Java ist immer noch eine primitive Sprache. Ich hab das nur fuer den Fall gesagt... falls jemand deinen Sarkasmus nicht versteht ;)
http://www.paulgraham.com/javacover.html
Und noch eine "schoene" Programmiersprache:
http://people.csa.iisc.ernet.in/sreejith/frontends/spl/spl.htm
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 16. June 2004, 13:21 MEW (#20)
|
|
|
|
|
http://www.paulgraham.com/javacover.html
der Artikel ist veraltet: 3 Jahre sind in der IT viel, sehr viel.
|
|
|
|
|
|
|
|
|
|
|
|
|
Aber er sagt sehr schoen, warum Java nicht gut sein kann! Punkt.
|
|
|
|
|
|
|
|
|
|
|
|
|
Sorry, aber dieser Typ schreibt nur Bullshit. Wahrscheinlich um seine 'eigene' (Arc) Sprache zu bewerben.
Aber jeder der genügend in der Kappe hat, kann sich ja zum Glück seine eigene Meinung bilden.
kleines Beispiel:
Anti-Java: Historically, languages designed for other people to use have been bad[..] The good languages have been those that were designed for their own creators[..]
Pro-Arc: Our[...]goal to design a language for good programmers. (doch für andere??)
Hätte er doch nur mal Java genauer angeschaut..
|
|
|
|
|
|
|
|
|
|
|
|
|
Hmm, aus den Zitaten die du von ihm machst ergibt sich folgender Zusammenhang: "Dieser Typ" glaubt, dass er selbst ein guter Programmierer ist. Was hat das mit seiner Aussage ueber Java zu tun?
> Hätte er doch nur mal Java genauer angeschaut..
Und was haette er gefunden?
- Halbherzig objektorientierte Sprache (Unterscheidung in primitve Typen und Objekte?)
- Primitive Flow Control ('switch' kann nicht mal Strings vergleichen?)
- Klappriges Event-Handling (ich versuch grad rauszufinden wie man das Zeug einigermassen sauber benutzt)
Den Link hab ich gepostet weil ich eigentlich nicht auf die technische Ebene runterwollte. Java ist wirklich eine verdummte Sprache, genau wie er das beschreibt.
Sonst kann man auch das hier lesen :)
http://www.orton.demon.co.uk/ff/cpp_interview.html
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 16. June 2004, 18:48 MEW (#28)
|
|
|
|
|
Er glaubt aber auch dass er alles weiss und zusätzlich noch hellseherische Fähigkeiten aufweist. (er zählt COBOL zu den gescheiterten Sprachen??)
Eigentlich wollte ich zeigen, dass die Auflistung Schwachsinn ist und oft falsch.
>Halbherzig objektorientierte Sprache
- Doppelherzig implementierte Datentypen. Du kannst wählen, ob du die nativen Datentypen oder lieber deren Objekte benutzen willst. (macht es einen Sinn ein Objekt für eine Zählvariable in einer Schlaufe zu benutzen?)
>'switch' kann nicht mal Strings vergleichen?
- ersetze das switch durch eine implementierung des strategy pattern von GoF
>ich versuch grad[...]
- und (ver)urteilst es schon, passt zu deinem Vorbild..
>Java ist wirklich eine[...]
Glaub einfach nicht alles, sondern finde es selbst heraus.
Ich finde keine Programmiersprache dumm. Und hast Du auch eine eigene Meinung, oder nur Links?
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 16. June 2004, 19:15 MEW (#30)
|
|
|
|
|
ich gebe mal
(2:Punkte, Informativ) leider Annonymous ;)
|
|
|
|
|
|
|
|
|
|
|
|
|
- die nativen Datentypen oder lieber deren Objekte benutzen
Es waere einfacher, wenn ein int einfach ein Int waere und wie ein Objekt behandelt werden koennte wenn noetig. Java kennt ja den Type jeder Variable, also wuerde das 0 Overhead geben (Ausser beim Compiler)
- strategy pattern von Go
hm, ich sehe nicht wie mir eine Strategy Pattern weiterhilft. Ich moechte eigentlich ein einfaches switch mit Strings machen koennen. Verschachtelte case Statements werde ich hoffentlich nie machen.
- und (ver)urteilst es schon
Muss ich zehn Jahre Erfahrung haben um ueber etwas zu fluchen?
- Glaub einfach nicht alles, sondern finde es selbst heraus.
Bin dabei, ich koennte noch einige Dinge aufzaehlen die mir nicht passen...
- Ich finde keine Programmiersprache dumm.
Ich schon. Aber 'dumm' ist halt ein starkes Wort, sagen wir halt 'beschraenkt'. Java ist einfach irgendwo liegengeblieben, auf halbem Weg von C zur high-level Sprache. Was haeltst denn du von Java?
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 16. June 2004, 18:56 MEW (#29)
|
|
|
|
|
_FLOWControll_
Das Switch keine Stringvergleiche macht, mag einigen Programmierern (welche an Skriptsprachen
gewöhnt sind) als Nachteil erscheinen,
aber in anbetracht dessen das ein "String" in JAVA
theoretisch 2gb gross sein kann, und im 2byte Unicode codiert ist, wären Stringvergleiche
in Reihe (wie bei switch mit primitiven Typen (int/char)) schlichtweg ein Overkill,
zumal bei switch auch vielen Programmierern
ein AcidentalFallThrough passieren kann
(break; vergessen)
dafür gibt es die Methoden der String Klasse(die ein matching bereitstellen) und die darin implementierten Methoden des "java.util.regex", die den Vorteil haben das man sie Problemlos zur Laufzeit ändern kann, und der RegexCompiler die Anweisungen neu übersetzt.
- realisiert man soetwas mit Switch nimmt
die Länge dieser starren Struktur mit
der Anzahl der Variationen zu,
Vorauswahl durch parsen und dann wenn
man die Komplexität runtergebrochen hat,
eine elegante Matchingtabelle die
Verweise auf Methoden im Falle eines Matchings enthält, sofern parallelisierbar könnte man diese Methoden dann sogar in einen Thread auslagern,
und weitermatchen,
kennt man die Gegebenheiten kann man zwischen
Regex und "1:1"-Matching wählen
Ein Matching was einer minimalen Bedingung genügt, also er würde eher einen String unbekannter grösse parsen und parsen erfordert nicht ein immer wiederkehrendes FullMatching und durchlaufen eines Strings zum zigtausendsten mal, -> deshalb
wäre runterbrechen durch Vorauswahl sinnvoll
---
daher macht es wenig Sinn Strings 1:1 zur Laufzeit zu matchen (ausnahme Bashskripte! wo die Eingabevielfalt u. Verhaltensvielfalt annähernd bekannt sind),
---
natürlich wäre es für EingabeParameterParsing
eine praktische Angelgenheit, solange
die Auswahl nicht _zu_ Vielfältig wird,
und man vorher die Eingabeparameter auf eine
bestimmte Grösse geprüft hat, so das da nicht
gewaltige Datenmengen verarbeitet werden müssen,
|
|
|
|
|
|
|
|
|
|
|
|
|
Du hast ein Interface, das implementierst Du und anschliessend übergibst du die instanz der Klasse dem Objekt, welches den Event auslöst. Ich wüsste nicht was besser gelöst ist...
/* Nur wer schneller ist als der Strom hat die Kontrolle! */
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich erinnere mich an "typed procedures" (oder so aehnlich) in Delphi Pascal. Um einem Button zu sagen, was bei einem Klick passieren soll, brauchte man dem Button nur eine Referenz zu einem Procedure zu geben.
Nach allem was ich bis jetzt von Java gesehen hab, muss ich fuer jedes Event eine eigene Klasse basteln oder innerhalb der Methode unterscheiden woher das Event kommt => nicht sauber.
In Java brauche ich eine extra Klasse (und Instanz!) nur fuer einen Listener. In einem Beispiel, dass ich gefunden habe, implementierte einer eine Klasse mit einer actionPerformed Methode. Alle seine Buttons haben dann diese Klasse als ActionListener angegeben. Dann hat er innerhalb der actionPerformed Methode den Text des sendenden Buttons ausgelesen und damit in einer langen Reihe if-else Statements die passende Aktion rausgesucht.
Leider finde ich das Beispiel grad nicht mehr, aber hier was aehnliches, und da soll mir niemand sagen das sei sauber!
http://www.developer.com/java/other/print.php/874351
public void actionPerformed(ActionEvent e)
{
//check to see if the action command is equal to exit
if(e.getActionCommand().equalsIgnoreCase("exit"))
{
System.exit(0);
}
else if(e.getActionCommand().equalsIgnoreCase("Rectangle"))
{
Menu menu = getMenuBar().getMenu(1);
for(int i = 0;i menu.getItemCount();menu.getItem(i).setEnabled(true),i++);
getMenuBar().getShortcutMenuItem(new MenuShortcut(kControlR)).setEnabled(false);
panel.drawShape(rectangle);
}
else if(e.getActionCommand().equalsIgnoreCase("Circle"))
{
Menu menu = getMenuBar().getMenu(1);
for(int i = 0;i menu.getItemCount();menu.getItem(i).setEnabled(true),i++);
getMenuBar().getShortcutMenuItem(new MenuShortcut(kControlC)).setEnabled(false);
panel.drawShape(oval);
}
[...viiiiel mehr davon...]
|
|
|
|
|
|
|
|
|
|
|
|
|
C kann auch schneller sein als Assembler, wenn der Assemblercode nicht optimiert ist. Java kann nicht schneller sein als C, wenn Java in C programmiert ist. Da aber da Höhere Sprachen meisst direkt optimalere Algorithmen benutzen, kann es durchaus sein das Intepretierte Sprachen schneller sind.
Will heissen: Wenn man wenig Zeit in die Entwicklung stecken will, nimmt man eine Scriptsprache. Möchte man wirklich ein optimales Ergebnis, muss man die Algorithmen direkt auf dieses Programm abstimmen. Ob Assembler, Hochsprache oder Scriptsprache, man muss immer entscheiden, wie viel Zeit man in die Entwicklung stecken will.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
C++! Und C++ ist wirklich grausig, wenn man sieht, was der Compiler da alles einbaut. Dann wundert es auch nicht. Auch wenn mein erster Gedanke war, Java ist doch in C geschrieben. Klar, aber eben nicht in C++.
--
ok> boot net - install
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 16. June 2004, 14:11 MEW (#24)
|
|
|
|
|
Suns HotSpot (wurde aber in C++ geschriebe.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich nehme mal stark an die Java VM ist in C oder C++ oder sonst einer Hochsprache geschrieben? Java Byte Code läuft nun auf dieser Java VM. Wie kann nun ein Java Programm schneller sein als ein C/C++ Programm. Für mich ist eine Interpretierte Sprache immer langsammer als eine Sprache die direkt auf der Maschine aufsetzt.
Kennt sich da wer besser aus, warum das jetzt schneller ist?? Kann da jemand mal das Licht anzünden ;-)
Grüsse, ia97lies
Glaube einem Benchmark nur wenn du in selbst gefälscht hast ;-)) oder wie?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Heute kompiliert doch die JVM mit Justin Timecompile das Zeug schnell vor dem ausführen und dann - roar.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wenn eine Sprache bessere Abstraktionen hat, kann sich der Entwickler besser ausdruecken. Eine hoehere Abstraktion bedeutet nicht zwingend, dass die Programme langsamer laufen. Wie schnell ein Programm laeuft, ist vor allem eine Frage des Aufwands den du in die Entwicklung/Optimierung steckst. Der Aufwand ist umso groesser, je primitiver die Sprache ist.
In C musst du jedesmal Speicher reservieren und wieder freigeben. In Java uebernimmt das die Virtual Machine, wenn der Speichermanager der VM noch unbenutzten Speicher hat, kann er den sofort zuteilen. In C muesstest du diese Funktion selbst implementieren, wer macht das schon?
|
|
|
|
|
|
|
|
|
|
|
|
|
Ok das mit der Abstraktion und so ist mir geläufig. Nur Java ist doch Byte Code der von der JVM ausgeführt wird? also nicht direkt Maschinen Code. Kanns irgendwie nicht so glauben, dass das schneller sein soll....
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 16. June 2004, 22:47 MEW (#33)
|
|
|
|
|
Ein grosser Teil des Codes für die Standard Library dürfte wohl plattformspezisisch optimierter Code sein, z.B. IO-Operationen, die häufig verwendeten Datenstrukturen und Algorithmen (Heap, Hashtable, binäre Suche, Langzahlarithmetik, viele mathematische Operationen aller Art, Speicherverwaltung usw.). Dann erzeugt die JVM nur noch ein bisschen Gluecode, um die plattformspezifisch optimierten Libraries aufzurufen. Die laufen dann mindestens so schnell wie der C++ Code. Ausserdem kann die JVM zur Laufzeit optimieren, während der C++ Compiler immer konservative Annahmen zur Compilezeit treffen muss.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 16. June 2004, 13:28 MEW (#21)
|
|
|
|
|
Kennt sich da wer besser aus, warum das jetzt schneller ist?? Kann da jemand mal das Licht anzünden ;-)
eine JVM kann zur Laufzeit Optimierungen vornehmen, was bei bereits fix kompilierten Programmen nicht möglich ist. Die Hotspot-Engine merkt, welche Funktionen besonders oft verwendet werden und kompiliert diese besser optimiert. Es gibt viele Optimierungen, die man erst zur Laufzeit vornehmen kann. Beispielsweise wenn eine Schlaufe je nach Benutzereingaben einmal sehr häufig oder dann wieder gar nicht durchlaufen wird.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zumal bei dem Benchmark wohl wirklich nur die arithmetische Performance von Java getestet wurde. Das was bei Java wirklich Zeit saugt: Objekte anlegen und wegräumen, wurde bewusst weggelassen. Tja und der Speicherbedarf von Java ist wirklich immens: Schon bei mittleren Web-Apps brauchts mehre GByte, damit die Kiste ned anfängt, wie wild zu swappen. :-/
--
Addicted by code poetry...
|
|
|
|
|
|
|
|
|
|
|
|
|
Stop: Er hat 'nen Test, der Objekte instanziert:
objinst.cpp und objinst.java. Die Ergebnisse dieses Tests werfen mich aber wirklich aus der Bahn, wiedersprechen nämlich meinen Erfahrungen! Bin ich zu doof die JVM zu starten?
--
Addicted by code poetry...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Der Object-Creation Test ist IMHO ein Witz. Da Java einen Garbage-Collector hat, kann mit diesem Code gar nicht direkt verglichen werden. Warum:
Java:
for (int i=0; i<n; i++) {
Toggle toggle = new Toggle(true);
}
Objekte werden erzeugt. C++:
for (int i=0; i<n; i++) {
Toggle *toggle = new Toggle(true);
delete toggle;
}
Objekte werden erzeugt und wieder zestört, hmm... Die C++-Variante gibt bei jedem Durchlauf den Speicher wieder frei, die Java-Variante hingegen spart sich die Mühe auf später. Um den Vergleich vergleichbar durchzuführen, müsste das delete toggle von der C++-Variante auch auf später verschoben werden...
|
|
|
|
|
|
|
|
|
|
|
|
|
Hab's "delete" rausgenommen. Macht keinen Unterschied. Was aber 'n Unterschied macht: Die C++-Objekte statt auf dem Stack (statt dem Heap) anlegen, sprich: "Toggle toggle(true)" statt "Toggle *toggle = new Toggle(true)": Dann ist der C++-Code zwanzigmal schneller, als der Java-Code. Kann es sein, dass der Heap-Manager des gcc, der glibc oder des Kernels total im Arsch ist?
--
Addicted by code poetry...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... 21/03 gabs einen Effizienztest:
C#, Java, C++ und Delphi im Effizienztest, Teil 2
Know-how,.NET-Corner,Benchmark, ListList, ListList_OOP, objektverarbeitende Programmierung, Compiler, Optimierung, Konstruktoren
c't 21/03, Seite 222
leider nicht gratis: c't archiv
Dazu aber ein forum thread
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 16. June 2004, 12:16 MEW (#17)
|
|
|
|
|
JavaByteCode wird schon lange nicht mehr "nur"
interpretiert, wie hier schon jemand
richtig geschrieben hat, und jedem bekannt sein sollte, gibt es einen "Just in Timecompiler"(seit geraumer Zeit),
d.h. er wandelt die JVM_ByteCode Sequenzen in nativen Maschinencode um, das wäre ja so nichts besonderes,
aber anstelle davon, diesen Prozess sinnlos für
gleiche Sequenzen zu wiederholen, werden
die Sequenzen gecached, und diese Sequenzen
sind auch nicht zwangsweise statisch,
sondern werden zur Laufzeit wenn der Optimierer
"merkt" da kann man was machen, auch optimiert,
d.h. die Sequenzen die häufig benötigt werden,
erfahren auch eine besondere Beobachtung durch
den Optimierer, z.B. um Arraygrenzen auszuschliessen die niemals erreicht werden,
und der JIT und der Optimierer haben
schon einiges an Entwicklungszeit in sich,
der Unterschied ist, im Gegensatz zu statischem
Code, der nur "einmal(nein damit ist nicht singlepass gemeint!)" kompiliert und optimiert
wird, und sich nicht weiter zur Laufzeit verändert, damit schon erklärbar,
verbessern sich die Optimierungstrategien der JVM
und des JIT, verbessert sich auch,
und dass sich die JVM kontinuierlich verbessert,
kann man auch aus den Benchmarks mit jdk
1.4.2 und 1.5-beta rückschliessen,
welche von den Quake2->Jake2 Portierern gemacht wurden
( http://www.bytonic.de/html/benchmarks_de.html )
obwohl es hier wohl eher um die Optimierungen im
Threadhandling der JVM geht, und die Kommunikationsgeschwindigkeit mit nativen
Bibliotheken(hier OpenGL) dadurch verbessert wird.
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 16. June 2004, 14:26 MEW (#25)
|
|
|
|
|
damit mich keiner falsch versteht,
ich habe hier nicht gesagt, dass JAVA unbedingt schneller ist, sondern nur das die Möglichkeit besteht dass es gleichschnell oder auch schneller ist, und sich der Geschwindigkeitsaspekt zum Teil auch von den Fähigkeiten des Programmieres seinen
Code per Hand zu optimieren abkoppelt.
|
|
|
|
|
|
