Diese Website existiert nur weil wir Werbung mit AdSense ausliefern.
Bitte den AdBlocker daher auf dieser Website ausschalten! Danke.
Bitte den AdBlocker daher auf dieser Website ausschalten! Danke.
java noch angesagt?
Moderator: Moderatoren
-
- Newbie
- Beiträge: 48
- Registriert: 22. Feb 2004, 14:19
- Wohnort: hannover
- Kontaktdaten:
Hi zusammen,
also irgendwie habe ich das Gefühl so manch einer hat hier relativ wenig Ahnung davon, was Java überhaupt ist - ich weiss, provokante Aussage aber wenn man sich die bisherigen Antworten mal so ansieht...
Java ist schonmal gar kein Ersatz für SQL. Das eine hat mit dem anderen recht wenig zu tun. SQL ist eine Datenbankabfragesprache, Java eine echte Programmiersprache.
Und dann zum immer wieder gerne angesprochenen Thema Java sei langsam: Diese pauschale Aussage ist schlicht und ergreifend falsch. Die ersten Java-Versionen waren nicht gerade der Knüller was Geschwindigkeit angeht, das ist ohne Frage richtig. Inzwischen jedoch besteht so gut wie kein Unterschied mehr zwischen nativ kompilierten Programme und Java-Anwendungen. Es gibt sogar Fälle wo Java durch den Hotspot JIT-Compiler schnelleren und performanteren Code erzeugt als das in C jemals möglich wäre. Wie das geht? Zur Laufzeit werden die Hauptperformance-Engpässe bestimmt und genau dafür wird dann der passende native Code compiliert und ausgeführt.
Sicherlich: Wenn's auf Geschwindkeit put ankommt, und ich number-crunching bist zum erbrechen durchführe dann ist logischweise C oder FORTRAN die Programmiersprache die man wählen sollte - aber in eigentlich allen anderen Anwendungsbereichen hat man mit Java da keinerlei Probleme mehr. Selbst für's Gamen gibt's inzwischen brauchbare Tools.
Ciao
Chris
P.S. Es heisst Java und nicht JAVA genauso wie es Delphi und nicht DELPHI heisst
also irgendwie habe ich das Gefühl so manch einer hat hier relativ wenig Ahnung davon, was Java überhaupt ist - ich weiss, provokante Aussage aber wenn man sich die bisherigen Antworten mal so ansieht...
Java ist schonmal gar kein Ersatz für SQL. Das eine hat mit dem anderen recht wenig zu tun. SQL ist eine Datenbankabfragesprache, Java eine echte Programmiersprache.
Und dann zum immer wieder gerne angesprochenen Thema Java sei langsam: Diese pauschale Aussage ist schlicht und ergreifend falsch. Die ersten Java-Versionen waren nicht gerade der Knüller was Geschwindigkeit angeht, das ist ohne Frage richtig. Inzwischen jedoch besteht so gut wie kein Unterschied mehr zwischen nativ kompilierten Programme und Java-Anwendungen. Es gibt sogar Fälle wo Java durch den Hotspot JIT-Compiler schnelleren und performanteren Code erzeugt als das in C jemals möglich wäre. Wie das geht? Zur Laufzeit werden die Hauptperformance-Engpässe bestimmt und genau dafür wird dann der passende native Code compiliert und ausgeführt.
Sicherlich: Wenn's auf Geschwindkeit put ankommt, und ich number-crunching bist zum erbrechen durchführe dann ist logischweise C oder FORTRAN die Programmiersprache die man wählen sollte - aber in eigentlich allen anderen Anwendungsbereichen hat man mit Java da keinerlei Probleme mehr. Selbst für's Gamen gibt's inzwischen brauchbare Tools.
Das hat doch mit Objektzuständen nichts zu tun. Beim Testing kannst du niemals 100% Zweigabdeckung erreichen, was aber überhaupt nicht am Unterschied objektorientiert/imperativ liegt sondern viel mehr an der Art und Weise _wie_ man diese Paradigmen umsetzt und wie man sein Programm gestaltet. Schonmal mit JUnit gearbeitet? Dann wirst du schnell merken, dass Testen auch (oder gerade) in Java schnell, einfach und ohne Probleme machbar ist.Peedee hat geschrieben:Außerdem hat OOP auch Nachteile. Z.B. kann man wegen der vielen möglichen Objektzustände nicht richtig Testen.
Ciao
Chris
P.S. Es heisst Java und nicht JAVA genauso wie es Delphi und nicht DELPHI heisst

-
- Member
- Beiträge: 89
- Registriert: 19. Jun 2004, 01:28
Du hast alles begründet, warum nicht diese These?perdian hat geschrieben:P.S. Es heisst Java und nicht JAVA genauso wie es Delphi und nicht DELPHI heisst

Und was JUnit angeht: Wenn man sowieso durch Tests nicht gewährleisten kann das etwas sauber läuft macht es IMHO auch keinen Sinn mit JUnit Entwicklungszeit zu verplempern.
Mit solchen Testverfahren macht man sich eigentlich nur selber etwas vor. Denn wer gewährleistet mir die Richtigkeit der Tests???? Die sind genauso fehleranfällig wie das was getestet werden soll.
*g* Kein Problem. BASIC beispielsweise ist ein Akronym und steht für "Beginner's All Purpose Symbolic Instruction Code". Java hingegen ist kein Akronym sondern einfach der Name einer Insel, die nach dieser Sprache benannt wurde (ehmmm... oder war das doch andersrum? *g*) und deshalb wird der Name der Sprache auch genauso "normal" geschrieben wie die besagte Insel.Killerfritte hat geschrieben:Du hast alles begründet, warum nicht diese These?perdian hat geschrieben:P.S. Es heisst Java und nicht JAVA genauso wie es Delphi und nicht DELPHI heisst![]()
Oh nein, das kann man so auch nicht sagen. Du kannst mit Testing nie wirklich 100%ig sicher sein, dass dein Programm _überall_ und _immer_ korrekt läuft, aber du kannst zumindestens durch gutes Testing die Anzahl der Fälle in denen es sauber läuft _deutlich_ erhöhen! Nur zu sagen "Ich werde eh nie wirklich Sicherheit erlangen, also lassen wir es ganz" läuft genauso am Problem vorbei.Killerfritte hat geschrieben:Und was JUnit angeht: Wenn man sowieso durch Tests nicht gewährleisten kann das etwas sauber läuft macht es IMHO auch keinen Sinn mit JUnit Entwicklungszeit zu verplempern.
Nein das stimmt auch nicht. Ein guter Test zeichnet zeichnet sich dadurch aus, dass du damit eine große Bandbreite an möglichen Anwendungsfällen "erschlägst". Und deshalb muss auch _vorher_ klar sein, was durch den Test erreicht werden soll, bzw. was verhindert werden soll.Killerfritte hat geschrieben:Mit solchen Testverfahren macht man sich eigentlich nur selber etwas vor. Denn wer gewährleistet mir die Richtigkeit der Tests???? Die sind genauso fehleranfällig wie das was getestet werden soll.
Wenn ich einen Testfall habe, der beispielsweise eine Bestellaufnahme kontrolliert, so kann ich genau wie einem chemischen Experiment hingehen und erstmal auflisten, was ich eigentlich habe: Bestelldaten (2x Artikel 1, 1x Artikel 2, usw.) und meine Kundendaten. Genauso weiss ich was rauskommen soll, nämlich eine Rechnung über X EUR, ausgestellt auf Kunde XYZ. Das sind 100% verifizierbare Ergebnisse. Jetzt lasse ich mein Programm laufen, und vergleiche hinterher den Output.
Sicherlich kann es vorkommen, dass auch hier ein Fehler im Test selber steckt - man steckt halt nicht in allem drin

Ciao
Chris
dijee!!
bin zwar kein profi in programmieren...
aber was pedian gesagt hat, da muss ich ihm voll recht geben! testen sollte von vornherein miteingeplant werden und auch durchgeführt werden!!!
was ich so die erfahrung gemacht habe stehn noch viele firmen auf C/C++,
in der firma, wo ich derzeit praxis mache ist vor allem Delphi vorn dabei! so ziemlich das einzige!
(bis auf VBA, wo ich arbeiten durfte)
und ein programm gibts dann noch in C...
aber ka wo Delphi noch eingesetzt wird, bei hardwarenahen sachen sollts halt super sein...und wenn man sich länger damit beschäftigt ist Delphi schon sehr gut...sehr schnell...und bietet auch arrays von buttons, imgs usw...
nja, musste halt auch meinen senf dazugeben!
bin zwar kein profi in programmieren...
aber was pedian gesagt hat, da muss ich ihm voll recht geben! testen sollte von vornherein miteingeplant werden und auch durchgeführt werden!!!
was ich so die erfahrung gemacht habe stehn noch viele firmen auf C/C++,
in der firma, wo ich derzeit praxis mache ist vor allem Delphi vorn dabei! so ziemlich das einzige!
(bis auf VBA, wo ich arbeiten durfte)
und ein programm gibts dann noch in C...
aber ka wo Delphi noch eingesetzt wird, bei hardwarenahen sachen sollts halt super sein...und wenn man sich länger damit beschäftigt ist Delphi schon sehr gut...sehr schnell...und bietet auch arrays von buttons, imgs usw...
nja, musste halt auch meinen senf dazugeben!

ciao baer
Naja
Also wenn man sich (die zugegebenermaßen nicht ganz realistischen) Stellenanzeigen anschaut, dann ist JAVA schon mit aufgeführt.
Beruflich scheint es sich in die anderen Programmiersprachen "einzugliedern".
Eigentlich schade, weil JAVA "ungefähr" was ich mir vor Jahren als
"entschärftes" C++ vorgestellt hatte.
JAVA kann man übrigens schneller machen, wenn übers Java Native Interface (JNI) hardware-abhängige Module einbindet.
Mit den entsprechenden Nachteilen (nicht ganz portabel) natürlich.
Beruflich scheint es sich in die anderen Programmiersprachen "einzugliedern".
Eigentlich schade, weil JAVA "ungefähr" was ich mir vor Jahren als
"entschärftes" C++ vorgestellt hatte.
JAVA kann man übrigens schneller machen, wenn übers Java Native Interface (JNI) hardware-abhängige Module einbindet.
Mit den entsprechenden Nachteilen (nicht ganz portabel) natürlich.
Programmieren macht Spaß und ärgert gleichzeitig
nachtrag
Äh, noch ein Nachtrag, C# von Microsoft ist eigentlich nur das Ergebnis eines verlorenen Prozesses gegen Sunsoft.
Visual J++ -----> C#
Ich find JAVA nicht schlecht. Nur das Filehandling und das Drucken find ich ätzend.
Visual J++ -----> C#
Ich find JAVA nicht schlecht. Nur das Filehandling und das Drucken find ich ätzend.
Programmieren macht Spaß und ärgert gleichzeitig
Re: nachtrag
Ist so pauschal nicht richtig.mampfi hat geschrieben:JAVA kann man übrigens schneller machen, wenn übers Java Native Interface (JNI) hardware-abhängige Module einbindet.
Mit den entsprechenden Nachteilen (nicht ganz portabel) natürlich.
Es gibt Situationen, in denen es Sinn machen kann JNI zu verwenden, um einen Performance-Gewinn zu erreichen. Das ist allerdings die Ausnahme. Zu Java 1.0/1.1 Zeiten konntest du über JNI noch massiv Performance gewinnen aber inzwischen hat sich die JVM Technologie deutlich weiterentwickelt. Hotspot leistet da meistens deutlich mehr als eine JNI optimierte Lösung, und in manchen Bereichen ist dadurch Java während der Ausführung von JIT compiliertem Code sogar schneller als ein vergleichbares C-Programm[1][2].
Das Drucken ist in der Tat etwas... gewöhnungsbedürftig. Aber was ist am Filehandling schlecht?mampfi hat geschrieben:Ich find JAVA nicht schlecht. Nur das Filehandling und das Drucken find ich ätzend.
Christian
[1] http://www.osnews.com/story.php?news_id=7372
[2] http://www.sys-con.com/story/?storyid=45250
Files und JAVA
Zugeben die IOStreams sind konsequent objektorientiert (sorry liebe Smalltalker).
Mir persönlichs wärs lieber wenns einen umfassenderen Daten Typ "File" gäbe.
Da kann man beispielsweise ne Zeile lesen und danach ein Zeichen.
Aber das ist Geschmackssache.
Visual Basic find ich gar nicht so schlecht.
War echt Wahnsinn, wie komplex das Schreiben von Windows-Programmen anfangs war, dann kam die "Stütze" VB und siehe da, die Shareware-Programme sprudelten aus dem Boden.
Aus der Diskussion über die großen Brocken J2ee usw. halt ich mich mangels Erfahrung lieber raus.
Mir persönlichs wärs lieber wenns einen umfassenderen Daten Typ "File" gäbe.
Da kann man beispielsweise ne Zeile lesen und danach ein Zeichen.
Aber das ist Geschmackssache.
Visual Basic find ich gar nicht so schlecht.
War echt Wahnsinn, wie komplex das Schreiben von Windows-Programmen anfangs war, dann kam die "Stütze" VB und siehe da, die Shareware-Programme sprudelten aus dem Boden.
Aus der Diskussion über die großen Brocken J2ee usw. halt ich mich mangels Erfahrung lieber raus.
Programmieren macht Spaß und ärgert gleichzeitig
Re: LOL
Es ist immer schade wenn sich Menschen Meinungen über etwas bilden, das sie garnicht wirklich kennen.deac hat geschrieben:klar kenne ich delphi, hab auch schon mit dem klicksi klacksi "programmiert".
nun sag mir eine größere firma, die den schrott verwendet...
Fakten:
1)Delphi ist in einigen Teilen der Welt sehr verbreitet. Dazu zählen die USA, aber auch die Ostblockstaaten.
2) Viele Firmeninterne Programme sind mit Delphi geschrieben. Diese gelangen natürlich nie nach außen, daher fallen sie nicht auf
3) Der "Macher" von Delphi, Anders_Hejlsberg, ist auch einer der wichtigsten Köpfe bei MS bezüglich Software Entwicklungstools.
http://de.wikipedia.org/wiki/Anders_Hejlsberg
4) Delphi ist kein Klicki-Bunti Tool, Borland hat es aber verstanden dem extrem schnellen und effizienten Object Pascal Compiler aus eigenem Haus eine sehr gute und beispielhafte (vergleich mal die VCL und QT, seltsame paralellen wie ,) ) Objectbiliothek mit samt einem ausgezeichneten grafischen RAD/Two-Way Editor bezulegen.
5) Man beurteilt nichts das man nur 5 Minuten gesehen hat. Lerne lieber von den Borland Entwicklern wie man sauberen Quellcode schreibt, lerne die VCL/CLX auswendig

Re: Files und JAVA
Es gibt sogar zwei *g*mampfi hat geschrieben:Mir persönlichs wärs lieber wenns einen umfassenderen Daten Typ "File" gäbe.
java.io.File und java.io.RandomAccessFile
Kannst du doch: Im RandomAccessFile kannst du readLine() und readChar() aufrufen - ist doch genau das, was du haben willst oder?mampfi hat geschrieben:Da kann man beispielsweise ne Zeile lesen und danach ein Zeichen.
Klar, die Frage ist bis zu welcher Komplexität du sowas treiben willst. Jede Sprache hat sicherlich Ihre Daseinsberechtigung (okay, C nicht aber das ist was anderes *g*) und für eine kleine Windows-Spielerei meinetwegen auch VB. Aber ein Warenwirtschaftssystem mit diversen Clients in VB programmieren? Ne ne.mampfi hat geschrieben:Visual Basic find ich gar nicht so schlecht.
War echt Wahnsinn, wie komplex das Schreiben von Windows-Programmen anfangs war, dann kam die "Stütze" VB und siehe da, die Shareware-Programme sprudelten aus dem Boden.
Genau dasgleiche mit Delphi: Wenn es um User-Interfaces im Desktop-Bereich geht ist die Sprache sicherlich vollkommen geeigent für den Job.
Chris
vb und delphi sind für mich sprachen, bei denen man bei einem etwas größeren projekt zwar recht schnelld die ersten, sagen wir mal 85% schafft, bei den restlichen 15% jedoch kläglich scheitert!
ich muss jedoch sagen, dass es mir damals schon spaß gemacht hat... da habe ich auch nicht viel anderes gekannt (außer assembler, pascal und c)
dann habe ich jedoch mit vc++ begonnen und später eben java...
ich kann nur sagen, ich will NIE wieder zurück *g*
da hast du ja genau die richtigen länder angesprochen! mit der hohen schulbildung! man mag es zwar nicht glauben, aber die ammis sind noch dümmer (auch/vorallem die programmierer). ich kann davon aus erster hand berichten! ich bin zur zeit auf "entwicklungshilfe" in den usa!1)Delphi ist in einigen Teilen der Welt sehr verbreitet. Dazu zählen die USA, aber auch die Ostblockstaaten.
VIELE is vielleicht ein wenig übertrieben, kann aber schon sein.... fakt is jedoch, das es jeden egal ist, wenn so ein teil mal stehen bleibt, oder irgendetwas halt nicht GANZ so geht, wie es geplant war!2) Viele Firmeninterne Programme sind mit Delphi geschrieben. Diese gelangen natürlich nie nach außen, daher fallen sie nicht auf
sollte das jetzt für oder gegen delphi sprechen?3) Der "Macher" von Delphi, Anders_Hejlsberg, ist auch einer der wichtigsten Köpfe bei MS bezüglich Software Entwicklungstools.
kann sein... ich habs mir nur bis zur version 6 (glaub i) angetan4) Delphi ist kein Klicki-Bunti Tool, Borland hat es aber verstanden dem extrem schnellen und effizienten Object Pascal Compiler aus eigenem Haus eine sehr gute und beispielhafte (vergleich mal die VCL und QT, seltsame paralellen wie ,) ) Objectbiliothek mit samt einem ausgezeichneten grafischen RAD/Two-Way Editor bezulegen.
es war dann doch eher ein jahr, oder so...5) Man beurteilt nichts das man nur 5 Minuten gesehen hat. Lerne lieber von den Borland Entwicklern wie man sauberen Quellcode schreibt, lerne die VCL/CLX auswendig
ich muss jedoch sagen, dass es mir damals schon spaß gemacht hat... da habe ich auch nicht viel anderes gekannt (außer assembler, pascal und c)
dann habe ich jedoch mit vc++ begonnen und später eben java...
ich kann nur sagen, ich will NIE wieder zurück *g*
Hier würde ich Jein sagendeac hat geschrieben:vb und delphi sind für mich sprachen, bei denen man bei einem etwas größeren projekt zwar recht schnelld die ersten, sagen wir mal 85% schafft, bei den restlichen 15% jedoch kläglich scheitert!

Grundsätzlich kann man mit allen Sprachen scheitern. Ich habe aber gerade größere Projekte in Delphi scheitern sehen, aber auch in anderen Sprachen.
Meiner Meinung nach hilft Delphi auch unerfahrenen Programmieren dort, wo sie mit anderen Sprachen scheitern würden, ein gewisser Filter für schlechte Programmierer fällt also weg.
Aber für erfahrene Programmierer gilt das nicht, für diese sind die Funktionen vor allem Erleichterungen.
Nur sollte man sich für Delphi VIEL Zeit nehmen, da die vielen Komponenten die mitgeliefert werden (je nach Version) wirklich kaum fix zu verstehen sind.