Discussion:
Warum Java und nicht C#?
(zu alt für eine Antwort)
Christian Franzen
2009-01-13 10:11:47 UTC
Permalink
Hi.

Ich schreibe momentan mit ein paar Studienkollegen an einer
Seminararbeit, in der wir auf die Frage gestoßen sind, welche Gründe es
geben könnte, mit Java anstatt mit C# zu programmieren. Wenn man
bedenkt, dass C# einige Features besitzt, die Java nicht bieten kann und
inzwischen auch auf vielen gängigen Platformen zur Verfügung steht
(außer vielleicht Handys), gibt es eigentlich keinen Grund, warum man
einem Neuling sagen sollte: "Lern Java und nicht C#!". Wie seht ihr das?
Würde mich freuen wenn möglichst viele ihren Senf dazugeben könnten.

mfg Xion

P.S.: Wenn ich C# sage, dann meine ich natürlich C# und CLI, ansonsten
wäre ein vergleich mit Java wohl eher unzulässig.
Bernd Eckenfels
2009-01-13 10:19:40 UTC
Permalink
Post by Christian Franzen
Wenn man
bedenkt, dass C# einige Features besitzt, die Java nicht bieten kann
Dies ist auch umgekehrt der Fall. Besonders im Bereich OSS Bibliotheken
dürfte Java die Nase vorne haben.
Post by Christian Franzen
und
inzwischen auch auf vielen gängigen Platformen zur Verfügung steht
Aber nur sehr rudimentär (wenn du Mono meinst). Insbesondere die größeren
Frameworks und Dienste (die JEE entsprechen) fehlen.
Post by Christian Franzen
(außer vielleicht Handys), gibt es eigentlich keinen Grund, warum man
einem Neuling sagen sollte: "Lern Java und nicht C#!". Wie seht ihr das?
Anders :)

Aber wenn es dir nur im die Sprache geht mag das schon stimmen (allerdings
kann ich nichts zur Qualität von Mono als Runtime sagen)

Gruss
Bernd
Christoph Herrmann
2009-01-13 11:09:31 UTC
Permalink
Post by Christian Franzen
Hi.
Hi,
Post by Christian Franzen
Ich schreibe momentan mit ein paar Studienkollegen an einer
Seminararbeit, in der wir auf die Frage gestoßen sind, welche Gründe es
geben könnte, mit Java anstatt mit C# zu programmieren. Wenn man
bedenkt, dass C# einige Features besitzt, die Java nicht bieten kann und
inzwischen auch auf vielen gängigen Platformen zur Verfügung steht
(außer vielleicht Handys), gibt es eigentlich keinen Grund, warum man
einem Neuling sagen sollte: "Lern Java und nicht C#!". Wie seht ihr das?
Würde mich freuen wenn möglichst viele ihren Senf dazugeben könnten.
Ich würde zu einem Neuling sagen lerne was Software entwickeln bedeutet
und welche Grundlagen man dafür braucht (von "was ist Quellcode" über
Objektorientierung bis hin zu Datenbanken etc.) und nimm dafür eine
beliebige Sprache als Beispiel, schaue aber auch öfters über den
Tellerrand wie andere Sprachen die Themen angehen.

Und das wichtigste: Nutze eine Programmiersprache als Werkzeug und sehe
diese auch als solches an. Daher nehme nicht eine Programmiersprache und
denke damit kannst alles machen, sondern wähle die Sprache danach aus
wie gut sich das Problem lösen lässt. Natürlich auch in Gedanken
behalten was für Sprachen man schon kann. Es wäre dumm eine neue Sprache
zu lernen um ein kleines Problem zu lösen wenn man es ohne größeren
Mehraufwand auch mit einer Sprache lösen kann, die man schon kennt.

Als Neuling würde ich vorzugsweise eine Sprache nehmen, die ordentliche
Objektorientierung bietet (wie Java oder C#), nicht zu spezialisiert ist
(Nischensprache zur SPS Entwicklung zum Beispiel) und anfängerfreundlich
ist, daher Fehler früh anzeigt und Hilfestellungen bietet (wie Java mit
Eclipse oder C# mit Visual Studio), darüber hinaus eine ordentliche
Dokumentation (ein ordentliches Buch sollte auch nicht fehlen).

Ausnahmen können natürlich sein, wenn der Neuling jetzt schon weiß dass
er genau in die Richtung gehen will, was dann die Nischensprachen
bevorzugen könnte. Am Ende läuft es aber eh darauf hinaus, dass jemand
mehrere Sprachen lernt, allein schon weil man einen viel größeren
Überblick bekommt über die Möglichkeiten. :)

Zwischen Java und C# ist die Entscheidung dann eher Geschmackssache oder
eher eine Frage des Einsatzgebietes. C# würde ich für Desktop Windows
Anwendung bevorzugen. Für plattformübergreifende oder serverseitige
Anwendungen Java.

PS: Alles meine persönliche Meinung. :)
--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Andreas Gairing
2009-01-13 11:15:29 UTC
Permalink
Post by Christian Franzen
Ich schreibe momentan mit ein paar Studienkollegen an einer
Seminararbeit, in der wir auf die Frage gestoßen sind, welche Gründe es
geben könnte, mit Java anstatt mit C# zu programmieren. Wenn man
bedenkt, dass C# einige Features besitzt, die Java nicht bieten kann und
inzwischen auch auf vielen gängigen Platformen zur Verfügung steht
(außer vielleicht Handys), gibt es eigentlich keinen Grund, warum man
einem Neuling sagen sollte: "Lern Java und nicht C#!". Wie seht ihr das?
Würde mich freuen wenn möglichst viele ihren Senf dazugeben könnten.
Ich denke man kann da keine pauschale Aussage treffen. Das kommt immer
auf den Verwendungszweck und die eigenen Vorlieben an. Eine mögliche
Liste könnte so aussehen:

-wenn am richtiges obejktorientierte Programmieren anwenden möchte, ist
Smalltalk ganz gut geignet

-wenn man Wert auf ästhetischen Syntax liegt, könnte man Phyton nehmen

-wenn man funktional programmieren möchte, würde sich Haskell anbieten

-wenn man mit der primären Zielplattform Windows zufrieden ist, bietet
sich C# an

-wenn man als Zielplattform auch Linux hat und vielleicht auf
Drittbibliotheken aufsetzen möchte (und man evtl. MS nicht so mag) ist
evtl. Java die Wahl

Natürlich kann man die einzelnen Sprachen auch für andere Zwecke
einsetzen. Nicht immer macht es Sinn die für das Problem passsende
Programmiersprache zu erlernen (außer man hat viel Freizeit).

Gruß,
Andreas
Viktor Zacek
2009-01-13 12:00:42 UTC
Permalink
Post by Christian Franzen
Würde mich freuen wenn möglichst viele ihren Senf dazugeben könnten.
Für mich persönlich:
- Java kann ich direkt in Oracle-Datenbanken statt PL/SQL verwenden
- Java kann ich direkt in Lotus Notes statt LotusScript verwenden
- Java ist plattformübergreifender (z.B. Mono unterstützt noch nicht
alles)
- kenne viele, die Java können, und mir ggf. helfen können
- zu Java findet man viel gute Doku im Internet und in Büchern (z.B.
Head First Java)


Liebe Grüße,
Viktor
Uwe Seimet
2009-01-13 19:10:02 UTC
Permalink
Post by Viktor Zacek
- Java ist plattformübergreifender (z.B. Mono unterstützt noch nicht
alles)
- kenne viele, die Java können, und mir ggf. helfen können
- zu Java findet man viel gute Doku im Internet und in Büchern (z.B.
Sind Punkte, die neben anderen auch für mich wichtig sind. Hinzu kommt,
dass es für Java gleich mehrere gute Entwicklungsumgebungen gibt. Egal
ob Eclipe, Intellij, Netbeans, JDeveloper: Man hat die Wahl. Vielleicht
kann hier jemand etwas dazu sagen, ob es eine solche Auswahl auch bei C#
gibt.
Eine Sprache ohne gute IDE für Debugging, Refactoring, Code-Analyse etc.
würde mir den Spaß an der Sache gründlich verleiden und die Entwicklung
erschweren.
--
-----------------------------------------------------------------------
Dr. Uwe Seimet http://www.linkbylink.net/
Carsten Wohl
2009-01-14 10:58:46 UTC
Permalink
Post by Uwe Seimet
Sind Punkte, die neben anderen auch für mich wichtig sind. Hinzu kommt,
dass es für Java gleich mehrere gute Entwicklungsumgebungen gibt. Egal
ob Eclipe, Intellij, Netbeans, JDeveloper: Man hat die Wahl. Vielleicht
kann hier jemand etwas dazu sagen, ob es eine solche Auswahl auch bei C#
gibt.
Gerade das finde ich für Anfänger eher nachteilig. Bei C# hat man das
kostenlose Visual Studio Express und kann damit direkt alles machen,
inkl. GUIs. Bei Java hat man erst mal die Qual der Wahl, nicht nur bei
der Entwicklungsumgebung (Netbeans, Exlipse), sondern erst recht
dabei, wie man GUI schreibt. Mit welchem Framework, mit welchem Add-On
für Eclipse z.B.... Ich muss zugeben dass ich daran erst mal
gescheitert bin.
Es gibt schon eine Menge guter Bücher zur GUI-Programmierung mit Java,
aber dann wiederrum hat man als Anfänger Probleme überhaupt seine
Umgebung ans laufen zu kriegen. Bei diesem hier z.B::
http://www.amazon.de/Java-lernen-Eclipse-Programmieranfänger-Callisto-Paketes/dp/3898428729

Für die ( Windows-) GUI Programmierung finde C# (was man auch im
deutschen C-Sharp auspricht und nicht Cis) anfängerkompatibler.

Sonst: Bei Konsolenprogrammen ist für Anfänger eigentlich egal, was
man nimmt. Die Verbreitung der beiden Sprachen sollte AFAIK auch in
etwa gleich sein.

Ergo: Münze werfen welche man lernt ;-)
Malte Schirmacher
2009-01-14 13:21:15 UTC
Permalink
Post by Carsten Wohl
Gerade das finde ich für Anfänger eher nachteilig. Bei C# hat man das
kostenlose Visual Studio Express und kann damit direkt alles machen,
inkl. GUIs.
$ apt-cache search visual studio express
$

Finde ich ja voll günstig, da könnte ich ja direkt mal anfangen C# zu
lernen...
Marek Kubica
2009-01-14 13:45:08 UTC
Permalink
Servus,

On Wed, 14 Jan 2009 14:21:15 +0100
Post by Malte Schirmacher
$ apt-cache search visual studio express
$
Unter Linux gibts Monodevelop (und das ist das einzige was mir spezeill
zu C# einfällt), also auch da haben Anfänger keine Probleme sich zu
entscheiden :)

grüße,
Marek
Carsten Wohl
2009-01-14 14:17:41 UTC
Permalink
Post by Malte Schirmacher
$ apt-cache search visual studio express
$
Finde ich ja voll günstig, da könnte ich ja direkt mal anfangen C# zu
lernen...
Was meinst du?

Die Express Edition ist kostenlos:
http://www.microsoft.com/germany/Express/

Sonst kann man für den Einstieg aber ebenso wie bei Java erst mal gut
mit dem Komdozeilenübersetzer und einem Texteditor auskommen.
Viktor Zacek
2009-01-14 14:20:28 UTC
Permalink
Post by Carsten Wohl
Post by Uwe Seimet
Sind Punkte, die neben anderen auch für mich wichtig sind. Hinzu kommt,
dass es für Java gleich mehrere gute Entwicklungsumgebungen gibt. Egal
ob Eclipe, Intellij, Netbeans, JDeveloper: Man hat die Wahl. Vielleicht
kann hier jemand etwas dazu sagen, ob es eine solche Auswahl auch bei C#
gibt.
Gerade das finde ich für Anfänger eher nachteilig. Bei C# hat man das
kostenlose Visual Studio Express und kann damit direkt alles machen,
inkl. GUIs. Bei Java hat man erst mal die Qual der Wahl, nicht nur bei
der Entwicklungsumgebung (Netbeans, Exlipse), sondern erst recht
dabei, wie man GUI schreibt. Mit welchem Framework, mit welchem Add-On
für Eclipse z.B.... Ich muss zugeben dass ich daran erst mal
gescheitert bin.
Bezieht sich ja auf mein Posting... da ging es auch um
plattformübergreifende Entwicklung... das war dem darauf Antwortenden
(Uwe Seimet) auch wichtig.

Da jetzt dann nur das GUI-Design sich rauszupicken finde ich
unpassend... Besonders da Uwe und mir plattformübergreifend wichtig ist,
und genau das C# mit Visual Studio nicht bieten kann... oder kennst du
Visual Studio für Mac OS oder Linux?
Da hab ich dann lieber auf allen Umgebungen ein Eclipse mit Java.
Und so kompliziert ist das auch nicht, es gibt nur 2 große... aber
welches der beiden ich im Detail lernen will, hab ich mir auch noch
nicht angesehen... aber scheitern wirds daran sicher nicht.


Liebe Grüße,
Viktor
Carsten Wohl
2009-01-14 15:25:01 UTC
Permalink
Post by Viktor Zacek
Da jetzt dann nur das GUI-Design sich rauszupicken finde ich
unpassend... Besonders da Uwe und mir plattformübergreifend wichtig ist,
und genau das C# mit Visual Studio nicht bieten kann... oder kennst du
Visual Studio für Mac OS oder Linux?
GUI-Programmerierung habe ich genannt, da dass bei mir ein Punkt war,
der mir den Einstieg in diesen Bereich von Java sehr schwer gemacht
hat.

Wo wir gerade dabei sind: Kann jemand gute Ressourcen dazu empfehlen?
Also für jemanden, der bisher nur Konsolenprogramme in Java
geschrieben hat.

Sonst sag ich ja: Münze werfen, wenn ich mir mal so Jobangebote
anschaue sind C# und Java meiner Meinung nach ungefähr gleich
verbreitet. Wie es sich in Zukunft entwickelt mit .Net allgemein,
gerade mit dem Hinblick auf dem noch recht neuen Silverlight fürs Web
kann sicherlich keiner sagen. Ich tippe eher darauf, dass sich.Net /
C# durch die Marktdurchdringung und Gesamtintegration von Produktion
von MS weiter ausbreiten wird. Siehe vielleicht Programmierung von
Navision, Sharepoint oder was auch immer.
Just my 0,2 Cent und Blick in die Kristallkugel.

Man kann weder mit Java noch mit C# was falsch machen in dem man die
Sprache lernt.
Lothar Kimmeringer
2009-01-14 15:33:11 UTC
Permalink
Post by Carsten Wohl
Ich tippe eher darauf, dass sich.Net /
C# durch die Marktdurchdringung und Gesamtintegration von Produktion
von MS weiter ausbreiten wird. Siehe vielleicht Programmierung von
Navision, Sharepoint oder was auch immer.
Die Marktdurchdringung von Microsoft hat gerade die 90%
durchbrochen (also nach unten). Wuerde man diesen Trend
linear fortsetzen waere wohl Objective C mit Cocoa als
Zukunftsstrategie zu nennen ;-)


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Carsten Wohl
2009-01-15 11:58:00 UTC
Permalink
Post by Lothar Kimmeringer
Die Marktdurchdringung von Microsoft hat gerade die 90%
durchbrochen (also nach unten). Wuerde man diesen Trend
linear fortsetzen waere wohl Objective C mit Cocoa als
Zukunftsstrategie zu nennen ;-)
Bißchen OT: MS entwickelt ich ja gerade hefitg weg vom reinen
Betriebssystem und Netzwerkserverdiensten. Mit Navision räubern sie
z.B. im Einstiegsberech von SAP, Silverlight im Web, Sharepoint als
Groupware, SBS als Komplettlösung für kleine Netze etc.

Damit verbreiten sich MS-Applikation in immer mehr Feldern , und damit
z.B. auch der IIS. Vor gar nicht mal so langer Zeit war IIS ja eher so
was wie eine Exotenlösung, da ging meist nichts über Apache. Aber
durch die anderen Produkte muss man automatisch IIS einsetzen:
Virtual Server? -> IIS zur Verwaltung. Und das obwohl IIS nicht besser
geworden ist und apache nicht schlechter. Kann man sehen wie man will,
aber wenn man dann durch .Net eine Schnittstelle zu praktisch allem
hat ist das nicht zu verachten. Man merkts jetzt schon: Firefox im
Unternehmsnetz ist einfach ungleich weniger unpassbar als der IE mit
seinem entsprechnen GPO-Einstellungen im AD. Obwohl ich privat nur
den FF benutze, die Add-Ons sind einfach Gold wert.

Aber klar, praktisch ist man auf die Windows-Welt beschränkt, trotz
Mono und co.
Bernd Hohmann
2009-01-15 12:31:19 UTC
Permalink
Post by Carsten Wohl
Post by Lothar Kimmeringer
Die Marktdurchdringung von Microsoft hat gerade die 90%
durchbrochen (also nach unten). Wuerde man diesen Trend
linear fortsetzen waere wohl Objective C mit Cocoa als
Zukunftsstrategie zu nennen ;-)
Bißchen OT: MS entwickelt ich ja gerade hefitg weg vom reinen
Betriebssystem und Netzwerkserverdiensten. Mit Navision räubern sie
z.B. im Einstiegsberech von SAP, Silverlight im Web, Sharepoint als
Groupware, SBS als Komplettlösung für kleine Netze etc.
Es ist aber so, dass nur ein Narr jetzt neu Navision (oder wie es nun
heisst) bei einem Unternehmen einkaufen wird, das seine Kernkompetenz wo
ganz anders hat. Das Risiko, dass diese Produktlinie wegen Verlusten
stillschweigend eingestellt wird, wäre mir zu hoch - IBM Kunden kennen
das Problem hinreichend *fg*

Bernd
--
Well, there's egg and bacon; egg sausage and bacon; egg and
***@spamonly.de ; egg bacon and spam; egg bacon sausage
and ***@spamonly.net ; spam bacon sausage and spam;spam
egg spam spam bacon and ***@nixwill.de ; spam sausage
Daniel Urban
2009-01-17 13:23:58 UTC
Permalink
"Bernd Hohmann"
Post by Bernd Hohmann
Post by Carsten Wohl
Bißchen OT: MS entwickelt ich ja gerade hefitg weg vom reinen
Betriebssystem und Netzwerkserverdiensten. Mit Navision räubern sie
z.B. im Einstiegsberech von SAP, Silverlight im Web, Sharepoint als
Groupware, SBS als Komplettlösung für kleine Netze etc.
Es ist aber so, dass nur ein Narr jetzt neu Navision (oder wie es nun
heisst) bei einem Unternehmen einkaufen wird, das seine Kernkompetenz wo
ganz anders hat. Das Risiko, dass diese Produktlinie wegen Verlusten
stillschweigend eingestellt wird, wäre mir zu hoch - IBM Kunden kennen das
Problem hinreichend *fg*
Da Navision erst vor ein paar Jahren übernommen wurde, wäre vermutlich ein
Verkauf wahrscheinlicher, als eine Einstellung. Letztendlich habe ich
sowieso nicht den Eindruck, dass das Neukundengeschäft in dem Bereich so
toll läuft. Aber ich habe nun auch schon seit zwei Jahren nichts mehr mit
Navision zu tun, kann mich also irren.

Interessant ist doch, dass in dieses Marksegment offenbar auch seit ein oder
zwei Jahren von SAP mit einer eigenen speziellen Lösung umworben wird.
Offenbar gibt es in dem Bereich noch keinen echten Marktführer und alle
scheinen zu glaube, dort einiges verdienen zu können.

Gruß,

Daniel
Uwe Naumann
2009-01-18 12:49:46 UTC
Permalink
Post by Daniel Urban
Interessant ist doch, dass in dieses Marksegment offenbar auch seit ein
oder zwei Jahren von SAP mit einer eigenen speziellen Lösung umworben
wird. Offenbar gibt es in dem Bereich noch keinen echten Marktführer und
alle scheinen zu glaube, dort einiges verdienen zu können.
Naja, die Großen sind abgegessen, da gehts maximal noch über Verdrängung.
Und in dem Segment sind ERP-Systemwechsel extrem komplex und aufwändig.
Da man ja wachsen muss, geht man halt den Rest an. Wobei ich dabei immer
den Eindruck habe, das SAP und Co. ein etwas seltsames Verständnis von
Kleinunternehmen haben.
--
Gruss Uwe

--------- cut here with a very sharp knife ---------
Uwe Naumann eMail: uwe[at]vieledinge[dot]de
Web: http://www.vieledinge.de http://www.swllog.de
Uwe Naumann
2009-01-18 12:47:54 UTC
Permalink
Post by Bernd Hohmann
Es ist aber so, dass nur ein Narr jetzt neu Navision (oder wie es nun
heisst) bei einem Unternehmen einkaufen wird, das seine Kernkompetenz wo
ganz anders hat. Das Risiko, dass diese Produktlinie wegen Verlusten
stillschweigend eingestellt wird, wäre mir zu hoch - IBM Kunden kennen
das Problem hinreichend *fg*
M$ macht zur Zeit ziemlich offensiv Marketing in den GF-Bereichen von
Partnern (kleinen Partnern) bezüglich einer wohl nächstes Jahr kommen
sollenden neuen Navision-Version, die auch KMUs adressieren soll. Was die
dann noch mit dem Ur-Navision zu tun haben wird weiß ich auch nicht. Mein
Chef springt dummerweise ziemlich gut drauf an... :-(
--
Gruss Uwe

--------- cut here with a very sharp knife ---------
Uwe Naumann eMail: uwe[at]vieledinge[dot]de
Web: http://www.vieledinge.de http://www.swllog.de
Florian Weimer
2009-01-14 20:08:42 UTC
Permalink
Post by Viktor Zacek
Da jetzt dann nur das GUI-Design sich rauszupicken finde ich
unpassend... Besonders da Uwe und mir plattformübergreifend wichtig ist,
und genau das C# mit Visual Studio nicht bieten kann... oder kennst du
Visual Studio für Mac OS oder Linux?
MSBUILD soll auch GCC aufrufen können, also ja.

(I.d.R. wird der Java-Server-Kram ja auch unter Windows entwickelt.)
Björn Sonntag
2009-01-13 12:30:53 UTC
Permalink
Hi Du,

Hmm Gründe weswegen man lieber Java denn C# programmiert... Also Java
läuft 100% auf mehreren Plattformen und dies sogar mit Unterstützung
des Herstellers SUN. Es gibt eine grössere Auswahl an Bibliotheken,
die man einsetzen kann.

Die J2EE Technologie ist imho ausgereifter als der .NET Kram.

Aber letztendlich ist es vollkommen egal welche Programmiersprache man
lernt, weil diese nur das Werkzeug ist um die Lösung eines Problems zu
implementieren.

Ich finde immer noch man sollte quasi jede Programmiersprache sich mal
angeschaut haben; auf jeden Fall mindestens eine aus den Bereichen
maschienennah (ASM), imperativ (Pascal oder C), OO (Smalltalk, Java,
C#), funktional (SML), Beschreibungssprachen (HTML / XML), Script -
Unsinn (PHP) und Datenbankzeugs (SQL).

Weil letztendlich nicht der Entwickler entscheidet wie das Projekt
umgesetzt werden soll, sondern in immer grösserer Zahl die Kunden...
und wer der sagt er will kein MS im Hause haben; kannst Du noch so
schöne Sachen mit ASP.NET + C# machen; es interessiert ihn nicht :-)

Oder wenn der sagt, dass kein Unix eingesetzt wird, sondern nur MS, da
würde ich dann eher zu .NET tendieren als zu Java... wichtig ist
letztendlich, dass man mehrere Sachen kann, wobei man 2 - 3 Sachen
RICHTIG gut können sollte :-)

In diesem Sinne.
Daniel Urban
2009-01-14 12:05:52 UTC
Permalink
"Björn Sonntag"
Post by Björn Sonntag
Hmm Gründe weswegen man lieber Java denn C# programmiert... Also Java
läuft 100% auf mehreren Plattformen und dies sogar mit Unterstützung
des Herstellers SUN.
Meiner Meinung nach absoluter Marketing-Blödsinn. Hierzu müsste mal in
diesem konkreten Fall definiert sein, was Plattform bedeutet. Auch die 100
Prozent sehe ich im Detail nicht. Unterstützung von Hersteller ist so
schwammig, auch hier müsste mal gesagt werden, was das konkret bedeutet.

Ich halte mal dagegen. C# läuft 100% auf mehreren Plattformen mit
Unterstützung von MS. Darin stecken natürlich mehere Einschränkungen:
Plattformen: Windows XP, Windows Vista, Mobile Windows (oder wie das Ding
zur Zeit heißt), 100 % für die jweilige Plattform (Mobile Windows eben nur
100% vom Compact .NET). Mit Untererstützung von MS, da sie für die meisten
Plattformen das .NET Framework implementieren und verbreiten.
Post by Björn Sonntag
Es gibt eine grössere Auswahl an Bibliotheken,
die man einsetzen kann.
Des einen Freud, des anderen Leid. Ich arbeite in mehreren Projekten, einige
in Java und einige in C#.

Am Beispiel für Webservices/Soap. In .NET gibt es AFAIK genau ein Framework,
es funktioniert und man hat keine größeren Probleme innerhalb der
Windows-Welt zu kommunizieren. In Java gibt es viele Frameworks (jax-ws,
Axis usw), welche von einzelnen Herstellern anders implementiert und ggf.
erweitert werden (IBM, Sun usw.) Daraus folgen gewisse Probleme. Etwas, was
mit der Sun-Implementierung unter Eclipse läuft, läuft dann nicht mehr im
JBoss. Kommunikation zwischen unterschiedlichen Frameworks können in
Projekten, wo mehrere Auftragnehmer existieren und mit unterschiedlichen
Frameworks arebiten auch Probleme breiten.

Letztendlich lassen sich alle Problem beheben (ggf. mit Work-araound), aber
es ist einfach deutlich komplizierter und aufwändiger.
Post by Björn Sonntag
Die J2EE Technologie ist imho ausgereifter als der .NET Kram.
Da .NET quasi JEE kopiert hat, kann ich das generell so nicht sehen. Aber da
mag es durchaus Einzelfälle auf der einen oder anderen Seite geben.

Gruß,

Daniel
Björn Sonntag
2009-01-14 13:21:58 UTC
Permalink
Post by Daniel Urban
Meiner Meinung nach absoluter Marketing-Blödsinn. Hierzu müsste mal in
diesem konkreten Fall definiert sein, was Plattform bedeutet.
vgl. Wiki ... http://de.wikipedia.org/wiki/Plattform_(Computer) aber
um es mal stumpf zu sagen; mit Plattform ist das System gemeint auf
dem die geschriebene Software zum laufen kommt, wie z.B. im Falle
einer WebApp auf dem Serversystem, was im Falle von .NET Windows xxx
Server + IIS ist und im Falle von Java div. App Server / TomCat und
quasi egal welches OS.

Unterstützung Hersteller, dass der Herrsteller selber dafür sorgt,
dass die Implementierung seiner Laufzeitumgebung auf möglich vielen
unterschiedlichen System zur Verfügung steht, vgl Java -> div. Unix
Derivate, Windows, Mac OS 9.X, MacOS X usw. .Net -> Windows.
Post by Daniel Urban
Post by Björn Sonntag
Es gibt eine grössere Auswahl an Bibliotheken,
die man einsetzen kann.
Des einen Freud, des anderen Leid. Ich arbeite in mehreren Projekten, einige
in Java und einige in C#.
Am Beispiel für Webservices/Soap. In .NET gibt es AFAIK genau ein Framework,
es funktioniert und man hat keine größeren Probleme innerhalb der
Windows-Welt zu kommunizieren.
Genau :D so lange es innerhalb der homogenen Windows Welt bleibt.
Post by Daniel Urban
In Java gibt es viele Frameworks (jax-ws,
Axis usw), welche von einzelnen Herstellern anders implementiert und ggf.
erweitert werden (IBM, Sun usw.) Daraus folgen gewisse Probleme.
Klar, weil die auch meistens in einem heterogenen Umfeld zum tragen
kommen :D Versuche mal das .NET Zeug auf einer Solaris oder auf einem
Mac OS X ans rennenzu bekommen und zwar genauso wie Du es vorher unter
Windows entwickelt hast ... ich behaupte mal, dass klappt nicht direkt
auf Anhieb.

Mit Java ist eben genau sowas kein Problem, weil es genau für SOWAS
konzipiert wurde !!
Post by Daniel Urban
Etwas, was mit der Sun-Implementierung unter Eclipse läuft, läuft dann nicht mehr im
JBoss. Kommunikation zwischen unterschiedlichen Frameworks können in
Projekten, wo mehrere Auftragnehmer existieren und mit unterschiedlichen
Frameworks arebiten auch Probleme breiten.
äähh ... dann hast was falsch gemacht :D Am besten Du bleibst in
Deiner schönen heilen .Net Welt und trollst Dich :D
Post by Daniel Urban
Da .NET quasi JEE kopiert hat, kann ich das generell so nicht sehen. Aber da
mag es durchaus Einzelfälle auf der einen oder anderen Seite geben.
Hmm jau... wie der Trabbi auch die Kopie des Mercedes Benz war ... ich
verstehe :-)

ja ja ich weiss dont feed the troll und so :D

in diesem Sinne ^^
Bernd Eckenfels
2009-01-14 14:16:44 UTC
Permalink
Post by Björn Sonntag
Unterstützung Hersteller, dass der Herrsteller selber dafür sorgt,
dass die Implementierung seiner Laufzeitumgebung auf möglich vielen
unterschiedlichen System zur Verfügung steht, vgl Java -> div. Unix
Derivate, Windows, Mac OS 9.X, MacOS X usw. .Net -> Windows.
Die Unterstützung von Java durch Sun ist nicht so prall auf Linux und
Windows, wenn man da Hilfe haben will wirds gleich teuer (bzw. als ISV
kompliziert). Dennoch, auf allen wichtigen Server Platformen läuft Java und
es ist auch Support zu bekommen:

Windows (2000,2003,2008) + XP + JME
Solaris x64, sparc
HP/UX HPPA, IA64
AIX PPC64
Linux x64, i386, ppc, ...
iOS
zOS

Jedoch duerfte bei den meisten auch Mono laufen.

Gruss
Bernd
Daniel Urban
2009-01-14 16:30:53 UTC
Permalink
"Björn Sonntag"
Post by Björn Sonntag
Post by Daniel Urban
In Java gibt es viele Frameworks (jax-ws,
Axis usw), welche von einzelnen Herstellern anders implementiert und ggf.
erweitert werden (IBM, Sun usw.) Daraus folgen gewisse Probleme.
Klar, weil die auch meistens in einem heterogenen Umfeld zum tragen
kommen :D Versuche mal das .NET Zeug auf einer Solaris oder auf einem
Mac OS X ans rennenzu bekommen und zwar genauso wie Du es vorher unter
Windows entwickelt hast ... ich behaupte mal, dass klappt nicht direkt
auf Anhieb.
Nein, habe ich auch nicht behauptet.
Post by Björn Sonntag
Post by Daniel Urban
Etwas, was mit der Sun-Implementierung unter Eclipse läuft, läuft dann nicht mehr im
JBoss. Kommunikation zwischen unterschiedlichen Frameworks können in
Projekten, wo mehrere Auftragnehmer existieren und mit unterschiedlichen
Frameworks arebiten auch Probleme breiten.
äähh ... dann hast was falsch gemacht :D
Klar, Du hast keine Ahnung, aber ich soll etwas verkehrt gemacht haben.

Du hast offenbar noch nie mit solchen Dingen gearbeitet. Die Implementierung
von Sun von jax-ws ist ziemlich anders als die von jax-ws im JBoss. Und
dadurch ergeben sich schon Probleme. Will man dann zum Beispiel auch noch
mit dem IBM Process Server kommunizieren, ergeben sich auch schon mal
Probleme. Die Implementierung innerhalb Axis 2 dürfte dann noch einmal
anders sein, mit entsprechenden Unterschieden. Jede Implementierung bringt
ihre eigenen Bugs, Erweiterungen und Vollständigkeit der Umsetzung der
Spezifikation mit.
Post by Björn Sonntag
Am besten Du bleibst in
Deiner schönen heilen .Net Welt
Meine (professionelle) Welt ist Java seit fast einem Jahrzehnt und .NET seit
ca. 4 Jahren.
Post by Björn Sonntag
und trollst Dich :D
Klar, Du bist der Blinde, der von Farbe redet, aber ich trolle rum.
Post by Björn Sonntag
Post by Daniel Urban
Da .NET quasi JEE kopiert hat, kann ich das generell so nicht sehen. Aber da
mag es durchaus Einzelfälle auf der einen oder anderen Seite geben.
Hmm jau... wie der Trabbi auch die Kopie des Mercedes Benz war ... ich
verstehe :-)
Nichts verstehst Du, aber bei diesen Antworten verwundert mich das nicht.

Gruß,

Daniel
Jochen Theodorou
2009-01-14 14:04:31 UTC
Permalink
Daniel Urban schrieb:
[...]
Post by Daniel Urban
Am Beispiel für Webservices/Soap. In .NET gibt es AFAIK genau ein
Framework, es funktioniert und man hat keine größeren Probleme innerhalb
der Windows-Welt zu kommunizieren. In Java gibt es viele Frameworks
(jax-ws, Axis usw), welche von einzelnen Herstellern anders
implementiert und ggf. erweitert werden (IBM, Sun usw.) Daraus folgen
gewisse Probleme. Etwas, was mit der Sun-Implementierung unter Eclipse
läuft, läuft dann nicht mehr im JBoss. Kommunikation zwischen
unterschiedlichen Frameworks können in Projekten, wo mehrere
Auftragnehmer existieren und mit unterschiedlichen Frameworks arebiten
auch Probleme breiten.
Du meinst wenn man überall in der .Net-Welt bleibt. Ein Client/Server
kann ja auch unter Java laufen. aber irgendwie misst man dann mit
zweierlei Maß... hat man zwei Gruppen von Komponenten und in der einen
Gruppe hat man keine Wahl, also nur eine Komponente X, und in der
anderen verschiedene, dann werden einfach all diejnenigen Komponenten
aus der Gruppe mit Auswahl als fehlerhaft deklariert, die nicht mit der
Komponente X zusammenarbeiten.

Und dabei ist es egal ob der Fehler ja eigentlich bei Komponente X liegt.

Unt wenn man jetzt bedenkt, dass MS mal gerne die Protokolle minimal
abwandelt, dann wird einem auch klar wie MS seine investitionen schützt.

Gruss theo
Daniel Urban
2009-01-14 16:41:24 UTC
Permalink
"Jochen Theodorou"
Post by Jochen Theodorou
[...]
Post by Daniel Urban
Am Beispiel für Webservices/Soap. In .NET gibt es AFAIK genau ein
Framework, es funktioniert und man hat keine größeren Probleme innerhalb
der Windows-Welt zu kommunizieren. In Java gibt es viele Frameworks
(jax-ws, Axis usw), welche von einzelnen Herstellern anders implementiert
und ggf. erweitert werden (IBM, Sun usw.) Daraus folgen gewisse Probleme.
Etwas, was mit der Sun-Implementierung unter Eclipse läuft, läuft dann
nicht mehr im JBoss. Kommunikation zwischen unterschiedlichen Frameworks
können in Projekten, wo mehrere Auftragnehmer existieren und mit
unterschiedlichen Frameworks arebiten auch Probleme breiten.
Du meinst wenn man überall in der .Net-Welt bleibt.
Ja. Hatte ich glaube ich auch geschrieben.

Kommunikation zwischen Java und .NET ergibt meiner Erfahrung nach sowohl auf
der einen Seite als auch auf der anderen Seite Probleme. Aber irgendwie
haben wir es auch immer gelöst.

Mir ging es aber in erster Linie um das Problem, dass mehrere Hersteller
einer Implementierung einer Spezifkation natürgemäß mehr Probleme macht, als
wenn man nur einen Hersteller hat. Wieso? Weil jede Implementierung seine
eigenen Bugs, Erweiterungen und Vollständigkeiten der Spezifkation
mitbringt. Das macht es nicht einfacher, wenn zwei Implementierungen von
zwei Herstellern miteinander arbeiten müssen. Mir erst vor einigen Monaten
passiert. Noch schwieriger wird es, wenn man wegen unterschiedlichen
Auftragnehmern und Produkten (wie zum Beispiel IBM Process Server) keinen
Einfluss auf die Anzahl der verschiedenen Hersteller und deren Versionsstand
hat.
Post by Jochen Theodorou
Unt wenn man jetzt bedenkt, dass MS mal gerne die Protokolle minimal
abwandelt, dann wird einem auch klar wie MS seine investitionen schützt.
Ich habe MS nicht heilig gesprochen. Ich habe nur gesagt, dass es sehr viel
komfortabler und weniger aufwändiger ist, wenn man nicht unterschiedliche
Implementierung zusammenbringen muss, weil es nur eine Implementierung gibt.
Dass diese sich dann leider nicht immer toll verhält, weil nicht alle
benötigten Features angeboten werden, ist dann der Nachteil.

Gruß,

Daniel
Marek Kubica
2009-01-14 13:42:59 UTC
Permalink
On Tue, 13 Jan 2009 04:30:53 -0800 (PST)
Post by Björn Sonntag
Hmm Gründe weswegen man lieber Java denn C# programmiert... Also Java
läuft 100% auf mehreren Plattformen und dies sogar mit Unterstützung
des Herstellers SUN.
Hat Java nicht eine Tradition dass es ewig braucht bis es ein
Release für OS X gibt[1][2][3]? Oder zählt du das gar nicht als
Platform?

Ich bin ja jetzt kein Apple-User, aber gerade bei sowas beginnt man
dann zu überlegen ob da nicht gewisse Platformen Second Class Citizens
sind. Dann ist man genauso weit wie bei .NET mit Mono auch.

grüße,
Marek

[1] http://www.symphonious.net/?name=Apple+And+Java+1.5
[2] http://www.symphonious.net/?name=Wheres+Java+1.5?+Redux
[3] http://developers.slashdot.org/article.pl?sid=08/05/03/1929212
Lothar Kimmeringer
2009-01-14 13:48:56 UTC
Permalink
Post by Marek Kubica
On Tue, 13 Jan 2009 04:30:53 -0800 (PST)
Post by Björn Sonntag
Hmm Gründe weswegen man lieber Java denn C# programmiert... Also Java
läuft 100% auf mehreren Plattformen und dies sogar mit Unterstützung
des Herstellers SUN.
Hat Java nicht eine Tradition dass es ewig braucht bis es ein
Release für OS X gibt[1][2][3]? Oder zählt du das gar nicht als
Platform?
Das galt frueher auch fuer Linux, weil die JVMs nicht von SUN
kamen, sondern von externen Teams entwickelt wurden. Auch bei
anderen Betriebssystemen dauert es ein bisschen, bis der ent-
sprechende Hersteller mit aktuellen Versionen herauskommt, Fakt
ist aber, dass wesentlich mehr Hersteller eine Java Virtual
Machine fuer ihr Betriebssystem herstellen als dies bei .NET
der Fall ist.
Post by Marek Kubica
Ich bin ja jetzt kein Apple-User, aber gerade bei sowas beginnt man
dann zu überlegen ob da nicht gewisse Platformen Second Class Citizens
sind. Dann ist man genauso weit wie bei .NET mit Mono auch.
Sorry, aber bei Java fehlen bei keiner Plattform kritische
Elemente der Library (ausser man zaehlt SWT als diese). Dass
mancher Hersteller etwas laenger braucht, um komplett neue
Javaversionen zu veroeffentlichen (Apple hat ewig fuer Java 6
gebraucht), ist weder ueberraschend noch ein Grund auf .NET zu
setzen, wo es z.B. fuer Apple meines Wissens ueberhaupt keine
Unterstuetzung gibt (ausser man installiert Fusion, ist schon klar).


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Marek Kubica
2009-01-14 22:25:38 UTC
Permalink
On Wed, 14 Jan 2009 14:48:56 +0100
Post by Lothar Kimmeringer
Das galt frueher auch fuer Linux, weil die JVMs nicht von SUN
kamen, sondern von externen Teams entwickelt wurden. Auch bei
anderen Betriebssystemen dauert es ein bisschen, bis der ent-
sprechende Hersteller mit aktuellen Versionen herauskommt, Fakt
ist aber, dass wesentlich mehr Hersteller eine Java Virtual
Machine fuer ihr Betriebssystem herstellen als dies bei .NET
der Fall ist.
Jetzt kommen die JVMs eigentlich auch nicht mehr von Sun. Meine JVM ist
IcedTea also eher von RedHat zusammengebaut.
Post by Lothar Kimmeringer
Sorry, aber bei Java fehlen bei keiner Plattform kritische
Elemente der Library (ausser man zaehlt SWT als diese).
Meinst du Winforms? Gtk# tut auf Linux und auf Windows, auf dem OS X
auch, nur dass es X11 braucht (ich schätze aber dass es demnächst GTK+
für Mac ohne X11 geben wird). Umabhängig davon existiert Cocoa# was den
Vorteil hat dass man für Macs auch SWT-like native Interfaces bauen
kann was Mac-User sicherlich zu schätzen wissen. Ich meine auch dass
die Winforms-API auf ein GTK-Backend verpflanzt wird was nicht ganz
trivial ist und wo ich nicht weiß wie weit die damit sind.

Was würdest du sonst, außer GUIs, als kritische Elemente der Library
zählen die .NET nicht bietet? Einfach mal aus Interesse würde ich das
gerne wissen.
Post by Lothar Kimmeringer
Dass mancher Hersteller etwas laenger braucht, um komplett neue
Javaversionen zu veroeffentlichen (Apple hat ewig fuer Java 6
gebraucht), ist weder ueberraschend noch ein Grund auf .NET zu
setzen, wo es z.B. fuer Apple meines Wissens ueberhaupt keine
Unterstuetzung gibt (ausser man installiert Fusion, ist schon klar).
Auf der Webseite von Mono gibt es durchaus aktuelle Versionen für Mac
OS X, also brauchen die eigentlich nicht so lange.

Und seien wir mal ehrlich, sowohl Sun als auch Apple haben durchaus das
Geld und die Entwickler um sofort, von Tag 1 eine aktuelle Version
bereitzustellen. Zudem ich kaum von "komplett neue Version" beim Sprung
von 1.5 auf 1.6 sprechen würde. 1.5 vielleicht, aber auch da halten
sich die stark platformspezifischen Sachen wo man die meiste
Portierarbeit vermuten würde eher in Grenzen.

Mein Anliegen war jetzt auch weniger .NET als platformunabhängiger als
die JVM zu bezeichnen, aber die Betonung von so starker Unterstützung
scheint mir nun doch übertrieben.

grüße,
Marek
Lothar Kimmeringer
2009-01-15 08:58:45 UTC
Permalink
Post by Marek Kubica
On Wed, 14 Jan 2009 14:48:56 +0100
Post by Lothar Kimmeringer
Sorry, aber bei Java fehlen bei keiner Plattform kritische
Elemente der Library (ausser man zaehlt SWT als diese).
Meinst du Winforms?
Unter anderem, wobei das inzwischen glaube ich bei der aktuellen
Version von Mono dabei ist. Hier ist was Mono selbst unter
http://www.mono-project.com/Guidelines:Application_Portability
als u.a. fehlend darstellt:

| Missing Functionality
|
| Mono lacks a number of features available on the .NET, here
| are some of the main missing features.
|
| No Enterprise.Services
|
| If your application requires EnterpriseServices, your software
| will not likely run on Mono as we have not implemented it.
|
| No cross-process transactions
|
| Mono currently supports only local-process transactions.
| No COM
|
| COM does not exist on Unix as part of the operating system and
| Mono does not currently provide support for it.
Post by Marek Kubica
Gtk# tut auf Linux und auf Windows, auf dem OS X
auch, nur dass es X11 braucht (ich schätze aber dass es demnächst GTK+
für Mac ohne X11 geben wird). Umabhängig davon existiert Cocoa# was den
Vorteil hat dass man für Macs auch SWT-like native Interfaces bauen
kann was Mac-User sicherlich zu schätzen wissen. Ich meine auch dass
die Winforms-API auf ein GTK-Backend verpflanzt wird was nicht ganz
trivial ist und wo ich nicht weiß wie weit die damit sind.
Was würdest du sonst, außer GUIs, als kritische Elemente der Library
zählen die .NET nicht bietet? Einfach mal aus Interesse würde ich das
gerne wissen.
Da hast Du mich glaube ich falsch verstanden. Es ging nicht
darum, was .NET von Java unterscheidet, sondern welche Pro-
bleme man hat, wenn man eine .NET-Applikation von Windows auf
z.B. Linux portieren moechte. Und da fehlen bei .NET mit Mono
einige meiner Ansicht nach kritische Bibliotheken (COM mag
man als veraltet ansehen, ist aber noch im Gebrauch). Und
dieses Problem habe ich bei Java nicht (ausser ich setze
auf JNI-Wrapper wie SWT). Auch bei java gibt es Probleme,
z.B. hat die JVM von BS2000 bei einem InputStream.read(byte[])
eine IOException geworfen, wenn der Puffer groesser 32768 Bytes
war, aber das sind Peanuts im Vergleich zu dem Problem, das
man hat, wenn man feststellt, das komplette Teile seines
Programms gar nicht erst kompilieren, geschweige denn laufen.
Post by Marek Kubica
Post by Lothar Kimmeringer
Dass mancher Hersteller etwas laenger braucht, um komplett neue
Javaversionen zu veroeffentlichen (Apple hat ewig fuer Java 6
gebraucht), ist weder ueberraschend noch ein Grund auf .NET zu
setzen, wo es z.B. fuer Apple meines Wissens ueberhaupt keine
Unterstuetzung gibt (ausser man installiert Fusion, ist schon klar).
Auf der Webseite von Mono gibt es durchaus aktuelle Versionen für Mac
OS X, also brauchen die eigentlich nicht so lange.
Auf der Monowebseite gibt es aktuelle Versionen von Java? Glaub
ich Dir nicht ;-)

Die Situation duerfte sich mittelfristig aendern, da Java ja
inzwischen Open Source ist und man nicht davon abhaengig ist,
dass eine Firma Apple um das Thema kuemmert, sondern man setzt
sich zur Not selbst hin und tut was.
Post by Marek Kubica
Und seien wir mal ehrlich, sowohl Sun als auch Apple haben durchaus das
Geld und die Entwickler um sofort, von Tag 1 eine aktuelle Version
bereitzustellen. Zudem ich kaum von "komplett neue Version" beim Sprung
von 1.5 auf 1.6 sprechen würde. 1.5 vielleicht, aber auch da halten
sich die stark platformspezifischen Sachen wo man die meiste
Portierarbeit vermuten würde eher in Grenzen.
Die Kosten fuer so einen Aufwand muessen aber durch Einnahmen
gedeckt werden, die im Falle von Java quersubventioniert sind.
Dass da die Prio nicht ganz so hoch gesetzt wird wie man sich
das Entwickler wuenschen wuerde.
Post by Marek Kubica
Mein Anliegen war jetzt auch weniger .NET als platformunabhängiger als
die JVM zu bezeichnen, aber die Betonung von so starker Unterstützung
scheint mir nun doch übertrieben.
Es ist meiner Ansicht nach nicht uebertrieben. Egal wo ich hin-
schaue, ist Java normalerweise schon vorhanden. Moechte ich mich
also im Serverumfeld bewegen wuerde ich mir keine grossen Ge-
danken machen und Java vor .NET bevorzugen. Bei GUI-Anwendungen
sieht das meiner Ansicht wiederum etwas anders aus, vor allem,
wenn ich als Zielplattform Windows im Auge habe. Hier hat .NET
seine Berechtigung und wenn man bei der Implementirung die Ein-
schraenkungen von Mono beachtet, kann man sogar recht guenstig
seinen Kundenkreis erweitern.


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Viktor Zacek
2009-01-14 14:20:28 UTC
Permalink
Post by Marek Kubica
Hat Java nicht eine Tradition dass es ewig braucht bis es ein
Release für OS X gibt[1][2][3]? Oder zählt du das gar nicht als
Platform?
Doch doch, das ist schon so... Apple ist da etwas lahm ;-)

Aber gibt ja glücklicherweise noch andere Möglichkeiten Java auf seinen
Mac zu bekommen. (Virtuelle Maschine, MacPorts, ...)


Liebe Grüße,
Viktor
Björn Sonntag
2009-01-14 16:07:34 UTC
Permalink
Doch ich zähle auch Mac OS X bzw generell Mac OS als Platform, weil
ich auch einige Zeit mit einem Mac gearbeitet habe ... so weiss ich
z.B. dass unter Mac OS 9.X immer noch 1.1.3 zum Einsatz kam, während
1,4 schon lange draussen war.

Aber hier kommt ja auch teilweise die Firmen Politik von Steve Jobs
mit ins Spiel würde ich sagen.

imho macht es hier keinen Sinn nen Flamewar auf zu machen nach dem
Motto "Mit Java wäre das nicht passiert", weil es einfach müssig
ist ...

BEIDE Systeme haben ihre Daseinsberechtigung ... und dies ist auch gut
so ... es liegt komplett im Auge des Kunden für was für ein System er
sich entscheidet.

Z.B. kann er für ein kosteneffizientes Linux entscheiden
(Anschaffungskosten) oder für ein vergleichsweise teures Windows
System ... er kann sich für den IIS entscheiden oder für Apache +
TomCat oder was auch immer. Wo der Kunde eben seine Kompetenzen hat.

Letztendlich ist es völlig egal ... weil was der Kunde wünscht,wird
gemacht, weil er zahlt die Brötchen und wenn er eine gewisse Affinität
in einer bestimmten Richtung hat, dann ist es völlig egal ob man doch
lieber in eine andere Richtung gehen möchte.

Aus diesem Grund auch eben meine Aussage, dass man am besten alle 3
Systeme beherrscht, Java, .Net und Scripting Zeugs ala Perl, Python
etc.

Oder man versteift sich auf ein System und geht damit eben auch die
Gefahr ein, dass man verschiedene neue Kundenanforderungen nicht
bedienen kann.

Um noch mal back to topic zu kommen.... Ich würde immer noch java
empfehlen; weil es für mich einfach einen ganz subjektiven charme hat,
den MS mir nicht liefern konnte ... ein Beispiel war da z.B. in
ASP.NET gab es keine Tab Pane von Haus aus ... in JSF ist das
Standard ... Sicher kann man hier auch andere Sachen nennen, die
in .NET sind aber in Java nicht, aber letztendlich ist es egal ...
weil immernoch der Kunde bestimmt welchen Weg man geht !

Die Zeiten in denen man dem Kunden quasi das System aufzwingen konnte
sind schon lange vorbei und das ist verdammt gut so.

In diesem Sinne.

@ Christoph
Auswahl an Bibliotheken? Ich will keine Auswahl, ich will eine Bibliothek die funktioniert :)
Dann solltest Du nicht .NET 3.5 nehmen, weil dort sind z.B. einige
imho Basis Komponenten gar nicht vorhanden :P

Weil es gibt nicht DIE Bibliothek, die alle Anforderungen erfüllt. Man
kommt immer wieder in die Gelegenheit neue Komponenten von extern
hinzuzunehmen.
Daniel Urban
2009-01-14 17:17:37 UTC
Permalink
"Björn Sonntag"
[...]
Post by Björn Sonntag
Die Zeiten in denen man dem Kunden quasi das System aufzwingen konnte
sind schon lange vorbei und das ist verdammt gut so.
Das gilt sicher für kleinere und mittlere Firmen. Aber wenn ein
Account-Manager von SAP, MS, Sun, Oracle, IBM oder so bei einem Kunden
vorstellig wird, dann führt das gelegentlich genau zu diesem unpassendem
Aufzwingen. Mit der Auswirkung, dass man oft auch nicht mehr aus der Schiene
rauskommt, weil eine Umstellung oft sehr teuer ist.

Gruß,

Daniel
Christoph Herrmann
2009-01-14 13:49:00 UTC
Permalink
Post by Björn Sonntag
Hmm Gründe weswegen man lieber Java denn C# programmiert... Also Java
läuft 100% auf mehreren Plattformen und dies sogar mit Unterstützung
des Herstellers SUN. Es gibt eine grössere Auswahl an Bibliotheken,
die man einsetzen kann.
Ein C Programm nach dem Posix (hoffe richtig geschrieben) läuft auf
praktisch allen Systemen wenn man es auf dem Zielsystem neu übersetzt.

Java läuft auf einer Handvoll Systemen die SUN als wichtig erachtet (Ist
da überhaupt Mac OS dabei, da gab es doch Probleme oder?).

Auswahl an Bibliotheken? Ich will keine Auswahl, ich will eine
Bibliothek die funktioniert :)
--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Lothar Kimmeringer
2009-01-14 13:55:25 UTC
Permalink
Post by Christoph Herrmann
Post by Björn Sonntag
Hmm Gründe weswegen man lieber Java denn C# programmiert... Also Java
läuft 100% auf mehreren Plattformen und dies sogar mit Unterstützung
des Herstellers SUN. Es gibt eine grössere Auswahl an Bibliotheken,
die man einsetzen kann.
Ein C Programm nach dem Posix (hoffe richtig geschrieben) läuft auf
praktisch allen Systemen wenn man es auf dem Zielsystem neu übersetzt.
... und es laeuft auch viel schneller als diese lahmen
Javaprogramme, um die in diesem Zusammenhang gern genannten
Vorurteile aufzuzaehlen.
Post by Christoph Herrmann
Java läuft auf einer Handvoll Systemen die SUN als wichtig erachtet
SUN entwickelt ihre JVMs nur fuer eine Handvoll Systeme, das
ist korrekt.
Post by Christoph Herrmann
(Ist da überhaupt Mac OS dabei,
nein
Post by Christoph Herrmann
da gab es doch Probleme oder?).
Apple hat ihre JVM 1.5 nach kurzen Onlinestellen gleich wieder
zurueckgezogen. Hat aber nichts mit SUN oder Java zu tun.
Post by Christoph Herrmann
Auswahl an Bibliotheken? Ich will keine Auswahl, ich will eine
Bibliothek die funktioniert :)
localuser> ls -l dowhatiwant.jar
drwxr-xr-x 3 localuser users 152 Apr 29 2006 854761231324

Ist aber nicht so leicht zu deployen.


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Christoph Herrmann
2009-01-14 14:03:43 UTC
Permalink
Post by Lothar Kimmeringer
... und es laeuft auch viel schneller als diese lahmen
Javaprogramme, um die in diesem Zusammenhang gern genannten
Vorurteile aufzuzaehlen.
Wieso ist das Argument von mir ein Vorurteil?

Dass Java (derzeit noch) langsamer ist ist ja bekannt, dass es als
Argument bei der heutigen Hardware ein (in der Regel) irrelevantes
Argument ist ist mir zumindest bekannt. :)
Post by Lothar Kimmeringer
SUN entwickelt ihre JVMs nur fuer eine Handvoll Systeme, das
ist korrekt.
[...]
Apple hat ihre JVM 1.5 nach kurzen Onlinestellen gleich wieder
zurueckgezogen. Hat aber nichts mit SUN oder Java zu tun.
für mich schon. Was bringt mir das wenn Java Plattformunabhängig ist und
dann doch nur auf ein paar Systemen funktioniert?

Soo Plattformunabhängig ist Java dann ja anscheinend doch nicht wie
immer angepriesen wird.
--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Lothar Kimmeringer
2009-01-14 14:13:15 UTC
Permalink
Post by Christoph Herrmann
Post by Lothar Kimmeringer
SUN entwickelt ihre JVMs nur fuer eine Handvoll Systeme, das
ist korrekt.
[...]
Apple hat ihre JVM 1.5 nach kurzen Onlinestellen gleich wieder
zurueckgezogen. Hat aber nichts mit SUN oder Java zu tun.
für mich schon. Was bringt mir das wenn Java Plattformunabhängig ist und
dann doch nur auf ein paar Systemen funktioniert?
Soo Plattformunabhängig ist Java dann ja anscheinend doch nicht wie
immer angepriesen wird.
Java existiert auf so ziemlich jedem System, das ich kenne,
vom iPhone mal abgesehen. Die einzigen Probleme, die man hat
ist, wenn man auf die neuesten Sprachversionen aufsetzen moechte,
aber fuer 1.4 kann ich ziemlich sicher sagen, dass es ueberall
funktioniert, fuer 1.5 muesste das inzwischen (danke Apple)
ebenfalls gelten.

Posix C ist da wesentlich weniger verbreitet und ich spare
mir bei Java sogar das Neukompilieren. Von C# mit .Net mal
ganz abgesehen, da sieht es ja noch spaerlicher aus, wenn
man ein bisschen mehr in seiner Applikation machen moechte,
als die Tutorials durchzugehen.


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Christoph Herrmann
2009-01-14 14:22:59 UTC
Permalink
Dieser beitrag ist möglicherweise unangemessen. Klicken sie auf, um es anzuzeigen.
Lothar Kimmeringer
2009-01-14 14:32:38 UTC
Permalink
Post by Christoph Herrmann
Post by Lothar Kimmeringer
Posix C ist da wesentlich weniger verbreitet und ich spare
mir bei Java sogar das Neukompilieren. Von C# mit .Net mal
Habe ich beim Studium scheisse gelernt? ^^
Weiss ich nicht ;-)
Post by Christoph Herrmann
Posix C Programme funktionieren auf jedem System auf dem ein C Compiler
existiert der den 99er C Standard einhält (oder sowas in der Art war es
doch, bin mir nicht ganz sicher, ich bin kein Vollblut C Entwickler).
Posix C schliesst z.B. schon mal saemtliche Windowssysteme aus,
die kein cygwin installiert haben (ein POSIX-Layer).
Post by Christoph Herrmann
Und bevor an Java gedacht wird läuft vorher auf jeden Fall ein C
Programm, da die JVM ja auch in C geschrieben ist (oder C++?). Also kann
es gar nicht sein, dass Java eher verbreitet ist. Aber C Compiler gibt
es doch für quasi jedes System.
Ob in den C-Sourcen aber POSIX-Threads oder etwas anderes
verwendet wird, um z.B. Java Threads abzubilden (die Linux-
JVM von vor 10 Jahren hat da z.B. jeweils einen Subprozess
pro Thread gestartet), ist nicht vorgschrieben. Die Linux-
JVM nutzt z.B. (inzwischen) Posix-Funktionen fuer Threads,
waehrend das bei den Windows-Sourcen nicht der Fall ist.
Das hat z.B. zur Folge, dass ein Thread.sleep(50) unter
Linux unter gewissen Umstaenden ueber eine Stunde braucht
um zurueckzukommen, das unter Windows aber nicht passiert.


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Bernd Eckenfels
2009-01-14 14:49:14 UTC
Permalink
Post by Christoph Herrmann
Habe ich beim Studium scheisse gelernt? ^^
Nein, aber vermutlich hast du keine grossen praktischen Erfahrungen damit?
Natuerlich kann man portierbare C(++) Programme schreiben, sogar mit
Threading und Gui, aber Spass macht es keinen.

Gruss
Bernd
Christoph Herrmann
2009-01-14 15:30:10 UTC
Permalink
Post by Bernd Eckenfels
Nein, aber vermutlich hast du keine grossen praktischen Erfahrungen damit?
Natuerlich kann man portierbare C(++) Programme schreiben, sogar mit
Threading und Gui, aber Spass macht es keinen.
In der Tat, das habe ich auf jeden Fall nicht. Dass es keinen Spass
macht kann ich mir vorstellen, unsere C++ Anwendung musste bis vor
kurzem auf Windows und OS/2 laufen, das war auch nicht immer spaßig.

Das ist einer der Gründe warum man dafür gerne Bibliotheken nimmt, die
das Ganze erledigen und abstrahieren für den Entwickler.
--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Bernd Eckenfels
2009-01-14 14:47:22 UTC
Permalink
Post by Lothar Kimmeringer
Java existiert auf so ziemlich jedem System, das ich kenne,
vom iPhone mal abgesehen.
Also mein iPhone hat eine VM - aber ich habs noch nicht probiert da was zu
deployen (und natürlich nicht offiziell geeignet):

iPhone:~ mobile$ uname -a

Darwin iPhone 9.4.1 Darwin Kernel Version 9.4.1: Sat Nov 1 19:09:48 PDT 2008; root:xnu-1228.7.36~2/RELEASE_ARM_S5L8900X iPhone1,2 arm N82AP Darwin

iPhone:~ mobile$ java -version

java version "1.5.0"
JamVM version 1.5.1
Copyright (C) 2003-2008 Robert Lougher <***@lougher.org.uk>
...
Execution Engine: direct-threaded interpreter with stack-caching
Compiled with: gcc 4.2.1 (Based on Apple Inc. build 5555)

Boot Library Path: /usr/lib/classpath
Boot Class Path: /usr/share/jamvm/classes.zip:/usr/share/classpath/glibj.zip

iPhone:~ mobile$ apt-cache search java

classpath - open source implementation of Java
fastjar - faster native alternative to Java's jar
iphone-java - example applications (with source) in Java
jamvm - small, intricate, fast Java interpreter
javasqlite - JNI bindings and JDBC driver for SQLite
jikes - native faster alternative to Java's javac
jocstrap - Java/Objective-C connection library


Das HelloJava läuft jedenfalls und zeigt mir mein Addressbuch an.

Gruss
Bernd
Bernd Hohmann
2009-01-14 17:45:09 UTC
Permalink
Die einzigen Probleme, die man hat ist, wenn man auf die neuesten
Sprachversionen aufsetzen moechte, aber fuer 1.4 kann ich ziemlich
sicher sagen, dass es ueberall funktioniert, fuer 1.5 muesste das
inzwischen (danke Apple) ebenfalls gelten.
Solange man nicht Swing braucht kommt man mit Java 1.1 letzter Stand
(1.1.8) überall durch.

Wer Verschlüsselung braucht, kommt um 1.3 oder 1.4 nicht herum.

1.6 scheint richtig krank zu sein, jedenfalls muss ich bei allen Sachen
die mit Lohn&Gehalt und ELSTER-API zu tun haben immer genau die
Java-Version bereithalten, die das Scheissding braucht.

Bernd
--
Well, there's egg and bacon; egg sausage and bacon; egg and
***@spamonly.de ; egg bacon and spam; egg bacon sausage
and ***@spamonly.net ; spam bacon sausage and spam;spam
egg spam spam bacon and ***@nixwill.de ; spam sausage
Florian Weimer
2009-01-14 20:05:59 UTC
Permalink
Post by Lothar Kimmeringer
Posix C ist da wesentlich weniger verbreitet
Welche Plattform ist denn *nicht* POSIX und hat trotzdem eine
Java-Implementierung (außer Windows)?

J2ME zählt übrigens für mich nicht als Java.
Lothar Kimmeringer
2009-01-14 21:23:25 UTC
Permalink
Post by Florian Weimer
Post by Lothar Kimmeringer
Posix C ist da wesentlich weniger verbreitet
Welche Plattform ist denn *nicht* POSIX und hat trotzdem eine
Java-Implementierung (außer Windows)?
OS/400
S/390
Symbian (kein J2ME)

Weitere fallen mir nicht ein, wenn mir ein Hersteller seine
Sourcen schicken sollte, sage ich bescheid, wenn da ein
nicht-POSIX darunter ist.


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Florian Weimer
2009-01-18 21:18:09 UTC
Permalink
Post by Lothar Kimmeringer
Post by Florian Weimer
Post by Lothar Kimmeringer
Posix C ist da wesentlich weniger verbreitet
Welche Plattform ist denn *nicht* POSIX und hat trotzdem eine
Java-Implementierung (außer Windows)?
OS/400
Kann ich nicht beurteilen.
Post by Lothar Kimmeringer
S/390
Ist das nicht eher z/OS heutzutage (und S/390 ist die Hardware)? Da
gibt's wohl eine POSIX-Schicht (also keine eigene VM), aber ich weiß
nicht, wie brauchbar das ist.
Post by Lothar Kimmeringer
Symbian (kein J2ME)
Also halbwegs vollständiges J2SE? Nett.

Aber z/OS hin oder her, das ist recht dünne, um als Argument pro
Java/contra POSIX durchzugehen. Die Vor- und Nachteile liegen m.E.
ganz wo anders.
Jochen Theodorou
2009-01-14 15:02:51 UTC
Permalink
Post by Christoph Herrmann
Post by Lothar Kimmeringer
... und es laeuft auch viel schneller als diese lahmen
Javaprogramme, um die in diesem Zusammenhang gern genannten
Vorurteile aufzuzaehlen.
Wieso ist das Argument von mir ein Vorurteil?
Dass Java (derzeit noch) langsamer ist ist ja bekannt, dass es als
Argument bei der heutigen Hardware ein (in der Regel) irrelevantes
Argument ist ist mir zumindest bekannt. :)
Genau das ist ja mal ein Vorurteil...

1.) Was genau langsamer als was?
2.) Was wird getestet?

Man kann leicht Programme in Java schreiben die schneller sind als
C-Programme und anders herum ebenso. Das einzige, was ich irklich gelten
lassen würde ist, dass Javaprogramme für den Desktop oer Server in der
Regel mehr Speicher verbrauchen als C-Programme.

Wenn man allerdings C# und Java vergleicht, dann sieht die Sache bei
Geschwindigkeit und Speicher schon wieder völlig anders aus.

Was POSIX-konforme C-Programme betrifft empfehle ich mal das Lesen von
http://en.wikipedia.org/wiki/POSIX

Soweit ich weiss unterstützt Windows nur POSIX 1, kein 1b oder 1c. Sowas
elementares wie Threads sind also nicht darin. Mit dem Effekt, dass das
äusserst beliebte fork unter Windows so nicht unterstützt wird.

Dan gäbe es danoch das
http://de.wikipedia.org/wiki/Microsoft_Windows_Services_for_UNIX das so
ähnlich wie cygwin ist... allerdings nicht auf Windows XP Home läuft und
eigentlich eine ganze Umgebung ist... Soweit ich mich erinnere wird das
jetzt eingestellt. Für Vista braucht es ein Enterprise oder Ultimate,
damit das läuft.... und welche Zukunft das Subsystem hat steht in den
Sternen... Das originale sufu jedenfalls wird nach 2009 nicht mehr
weiterentwickelt, da es in Vista ja jetzt was anderes ist... wie lange
diese Komponente leben wird... keine Ahnung.

Cygwin ist jedenfallskeine Alternative, wenn dein Programm nicht nacher
GPL sein soll... oder habe ich die Lizenz falsch im Kopf?

Und POSIX alleine bringt es ja auf dem Desktop auch nicht, denn POSIX
hat nix mit GUIs zu tun. Dafür braucht man dann schon eine
X11-Emulation, die durch Cygwin und diese Services for Unix ja im
Prinzip geliefert werden... aber eben auch mit den entsprechenden
Problemen...

Ausserdem sollte man doch mal bedenken, dass die Zeiten in denen jeder
seine Programme selber übersetzt hat schon eine ganze Weile vorbei sind,
oder? Nicht jeder Anwender ist schließlich auch ein Programmierer, der
sich Makefiles um die Ohren schlagen läßt.

Zudem mag es zwar sehr viele Systeme geben für die ein ANSI-C Programm
compiliert werden kann, allerdings muss man da auch erstmal an den
Compiler kommen. Und laufen sollte das Programm ja nacher auch noch ;)
Post by Christoph Herrmann
Post by Lothar Kimmeringer
SUN entwickelt ihre JVMs nur fuer eine Handvoll Systeme, das
ist korrekt.
[...]
Apple hat ihre JVM 1.5 nach kurzen Onlinestellen gleich wieder
zurueckgezogen. Hat aber nichts mit SUN oder Java zu tun.
für mich schon. Was bringt mir das wenn Java Plattformunabhängig ist und
dann doch nur auf ein paar Systemen funktioniert?
Sun arbeitet da mit Apple zusammen und wenn Apple so langsam macht, dann
kann da Sun wenig dafür. Aber das OpenJDK verspricht zunehmend Abhilfe,
weil daran gearbeitet wird, dass das auch für den Mac kompiliert werden
kann.... IMHO geht das schon mehr oder weniger gut.

Gruss theo
Marek Kubica
2009-01-14 22:47:05 UTC
Permalink
On Wed, 14 Jan 2009 16:02:51 +0100
Post by Jochen Theodorou
Post by Christoph Herrmann
Dass Java (derzeit noch) langsamer ist ist ja bekannt, dass es als
Argument bei der heutigen Hardware ein (in der Regel) irrelevantes
Argument ist ist mir zumindest bekannt. :)
Genau das ist ja mal ein Vorurteil...
1.) Was genau langsamer als was?
2.) Was wird getestet?
Ja, wenn wir noch weiter kleinlich sein wollen dann können wir auch
feststellen dass Sprachen gar keine Geschwindigkeit haben und wir somit
Implementationen vergleichen müssten und da haben wir mit GCC, ICC,
TCC, Suns Java, Jikes und noch weiteren genug zur Auswahl.

Aber ich glaube wir sind uns wohl einig dass Java schnell genug ist für
viele Aufgaben und dass ein guter Algorithmus viel wert ist. Weiter
braucht das wohl nicht aufgespalten zu werden.
Post by Jochen Theodorou
Soweit ich weiss unterstützt Windows nur POSIX 1, kein 1b oder 1c.
Sowas elementares wie Threads sind also nicht darin. Mit dem Effekt,
dass das äusserst beliebte fork unter Windows so nicht unterstützt
wird.
Windows-Ports von C-Programmen verlassen sich eigentlich sowieso nicht
auf POSIX, das wäre ja doch zu schmerzhaft.
Post by Jochen Theodorou
Cygwin ist jedenfallskeine Alternative, wenn dein Programm nicht
nacher GPL sein soll... oder habe ich die Lizenz falsch im Kopf?
Scheint schon so zu stimmen. Wenn dein Programm FOSS ist, dann kann es
die Lizenz beibehalten, ansonsten wirst du bei RedHat eine Lizenz
brauchen. Wobei, vielleicht lohnt sich das auch.
Post by Jochen Theodorou
Und POSIX alleine bringt es ja auf dem Desktop auch nicht, denn POSIX
hat nix mit GUIs zu tun. Dafür braucht man dann schon eine
X11-Emulation, die durch Cygwin und diese Services for Unix ja im
Prinzip geliefert werden... aber eben auch mit den entsprechenden
Problemen...
Oder ein Toolkit, von denen es ja genügend gibt, auch welche die ohne
X11 auskommen.
Post by Jochen Theodorou
Ausserdem sollte man doch mal bedenken, dass die Zeiten in denen
jeder seine Programme selber übersetzt hat schon eine ganze Weile
vorbei sind, oder? Nicht jeder Anwender ist schließlich auch ein
Programmierer, der sich Makefiles um die Ohren schlagen läßt.
Im Gegensatz zu Linux laufen für Windows kompilierte Binaries meistens
Problemlos auf verschiedenen Versionen des Betriebssystems (wenn man
keine spezifische Funktionalität verwendet, aber das versteht sich von
selbst), somit kann man es einmal kompilieren und die User laden es
sich runter. Scheint eigentlich passabel zu funktionieren.
Post by Jochen Theodorou
Zudem mag es zwar sehr viele Systeme geben für die ein ANSI-C
Programm compiliert werden kann, allerdings muss man da auch erstmal
an den Compiler kommen. Und laufen sollte das Programm ja nacher auch
noch ;)
GCC läuft auf vielen, vielen Platformen. Und auf denen auf denen es
nicht läuft, bietet der Hersteller meist auch einen entsprechenden
Compiler an. Irgendwie muss man das Ding ja programmieren können ;)
Aber ich glaube hier sprechen wir von irgendwelchen Nischen, denn das
Argument dass es nicht überall C-Compiler gibt ist zwar gültig, aber
für die Platformen gibt es auch keine JVM, weil irgendwie muss die ja
auch kompiliert werden.

grüße,
Marek
Jochen Theodorou
2009-01-15 01:47:53 UTC
Permalink
Post by Marek Kubica
On Wed, 14 Jan 2009 16:02:51 +0100
Post by Jochen Theodorou
Post by Christoph Herrmann
Dass Java (derzeit noch) langsamer ist ist ja bekannt, dass es als
Argument bei der heutigen Hardware ein (in der Regel) irrelevantes
Argument ist ist mir zumindest bekannt. :)
Genau das ist ja mal ein Vorurteil...
1.) Was genau langsamer als was?
2.) Was wird getestet?
Ja, wenn wir noch weiter kleinlich sein wollen dann können wir auch
feststellen dass Sprachen gar keine Geschwindigkeit haben und wir somit
Implementationen vergleichen müssten und da haben wir mit GCC, ICC,
TCC, Suns Java, Jikes und noch weiteren genug zur Auswahl.
das ist Punkt (1): "Was genau langsamer als was?" ;)
Post by Marek Kubica
Aber ich glaube wir sind uns wohl einig dass Java schnell genug ist für
viele Aufgaben und dass ein guter Algorithmus viel wert ist. Weiter
braucht das wohl nicht aufgespalten zu werden.
Ja, das sind wir uns einig.

[...]
Post by Marek Kubica
Post by Jochen Theodorou
Und POSIX alleine bringt es ja auf dem Desktop auch nicht, denn POSIX
hat nix mit GUIs zu tun. Dafür braucht man dann schon eine
X11-Emulation, die durch Cygwin und diese Services for Unix ja im
Prinzip geliefert werden... aber eben auch mit den entsprechenden
Problemen...
Oder ein Toolkit, von denen es ja genügend gibt, auch welche die ohne
X11 auskommen.
stimmt ansich. Da hat man sich allerdings schon weit von "man braucht
nur einen C99 Compiler" entfernt. Aber prinzipiell stimme ich dir
natürlich zu.
Post by Marek Kubica
Post by Jochen Theodorou
Ausserdem sollte man doch mal bedenken, dass die Zeiten in denen
jeder seine Programme selber übersetzt hat schon eine ganze Weile
vorbei sind, oder? Nicht jeder Anwender ist schließlich auch ein
Programmierer, der sich Makefiles um die Ohren schlagen läßt.
Im Gegensatz zu Linux laufen für Windows kompilierte Binaries meistens
Problemlos auf verschiedenen Versionen des Betriebssystems (wenn man
keine spezifische Funktionalität verwendet, aber das versteht sich von
selbst), somit kann man es einmal kompilieren und die User laden es
sich runter. Scheint eigentlich passabel zu funktionieren.
Im Gegensatz zu Linux? Hast du da eine konkrete Erfahrung gemacht?
Post by Marek Kubica
Post by Jochen Theodorou
Zudem mag es zwar sehr viele Systeme geben für die ein ANSI-C
Programm compiliert werden kann, allerdings muss man da auch erstmal
an den Compiler kommen. Und laufen sollte das Programm ja nacher auch
noch ;)
GCC läuft auf vielen, vielen Platformen.
und kann sogar Java in native code compilieren ;)
Post by Marek Kubica
Und auf denen auf denen es
nicht läuft, bietet der Hersteller meist auch einen entsprechenden
Compiler an. Irgendwie muss man das Ding ja programmieren können ;)
na, da wäre noch immer Assembler ;) Ne, natürlich gibt es meist
irgendeinen compiler. Aber als ich damals vor etlichen Jahren mit
Programmieren angefangen habe, fand ich es (aus der Windowswelt kommend)
besonders schwer an einen Compiler zu geraten, den ich mir leisten kann.
Und ja, ich meine da Windows, nicht eine unorthodoxe Plattform ohne OS.
Inzwischen ist die Situation allerdings anders meine ich. Ich persönlich
halte das auch für ein Verdienst von Java, weil es gezeugt hat dass eine
freier Compiler auch nicht schlecht ist... und ich halte es auch für
einen Verdienst von GCC, der immer noch besser wird.
Post by Marek Kubica
Aber ich glaube hier sprechen wir von irgendwelchen Nischen, denn das
Argument dass es nicht überall C-Compiler gibt ist zwar gültig, aber
für die Platformen gibt es auch keine JVM, weil irgendwie muss die ja
auch kompiliert werden.
Hmm.... war da nicht mal was mit einer VM in Hardware, die Bytecode
direkt ausführen kann? Dann existiert zwar auch eine VM, allerdings im
Chip... wobei es um dieses Modell relativ still geworden ist

Gruss theo
Thomas Thiele
2009-01-15 19:12:17 UTC
Permalink
Post by Jochen Theodorou
Hmm.... war da nicht mal was mit einer VM in Hardware, die Bytecode
direkt ausführen kann? Dann existiert zwar auch eine VM, allerdings im
Chip...
Es sollte mal einen Microcontroller geben.
Aber ist dass dann noch ein VM wenn Bytecode *direkt* ausgeführt wird?
Marek Kubica
2009-01-16 22:44:26 UTC
Permalink
On Thu, 15 Jan 2009 02:47:53 +0100
Post by Jochen Theodorou
Post by Marek Kubica
Im Gegensatz zu Linux laufen für Windows kompilierte Binaries
meistens Problemlos auf verschiedenen Versionen des Betriebssystems
(wenn man keine spezifische Funktionalität verwendet, aber das
versteht sich von selbst), somit kann man es einmal kompilieren und
die User laden es sich runter. Scheint eigentlich passabel zu
funktionieren.
Im Gegensatz zu Linux? Hast du da eine konkrete Erfahrung gemacht?
Unter Linux läuft Zeug aus Debian Unstable gerne mal nicht in Debian
Stable, weil die libc zu alt ist. Oder irgendwelche anderen Pakete.
Daher kompilieren viele Leute den Kram den sie weiterverteilen wollen
auf irgendwelchen alten Systemen wo sie davon ausgehen können dass es
dann auch auf neueren läuft (PLT Scheme kompiliert etwa auf Fedora 7
und das tut dann auch noch auf Debian 5.0).
Und die Problematik mit den ganzen verschiedenen Paketformaten mal
außen vor gelassen.
Post by Jochen Theodorou
Hmm.... war da nicht mal was mit einer VM in Hardware, die Bytecode
direkt ausführen kann? Dann existiert zwar auch eine VM, allerdings
im Chip... wobei es um dieses Modell relativ still geworden ist
Die "Java-CPU" ist genauso tot wie Lisp-Maschinen, die die Idee schon
ein paar Jahre früher aufgegriffen haben.

grüße,
Marek
Malte Schirmacher
2009-01-17 00:22:21 UTC
Permalink
Post by Marek Kubica
On Thu, 15 Jan 2009 02:47:53 +0100
Post by Jochen Theodorou
Post by Marek Kubica
Im Gegensatz zu Linux laufen für Windows kompilierte Binaries
meistens Problemlos auf verschiedenen Versionen des Betriebssystems
(wenn man keine spezifische Funktionalität verwendet, aber das
versteht sich von selbst), somit kann man es einmal kompilieren und
die User laden es sich runter. Scheint eigentlich passabel zu
funktionieren.
Im Gegensatz zu Linux? Hast du da eine konkrete Erfahrung gemacht?
Unter Linux läuft Zeug aus Debian Unstable gerne mal nicht in Debian
Stable, weil die libc zu alt ist. Oder irgendwelche anderen Pakete.
Daher kompilieren viele Leute den Kram den sie weiterverteilen wollen
auf irgendwelchen alten Systemen wo sie davon ausgehen können dass es
dann auch auf neueren läuft (PLT Scheme kompiliert etwa auf Fedora 7
und das tut dann auch noch auf Debian 5.0).
Und die Problematik mit den ganzen verschiedenen Paketformaten mal
außen vor gelassen.
Hä? Genau das gleiche Problem hast du auf Wintendo auch. So ist es
nuneinmal wenn man Features von neusten Versionen vorraussetzt.
Jochen Theodorou
2009-01-18 00:30:12 UTC
Permalink
Post by Marek Kubica
On Thu, 15 Jan 2009 02:47:53 +0100
Post by Jochen Theodorou
Post by Marek Kubica
Im Gegensatz zu Linux laufen für Windows kompilierte Binaries
meistens Problemlos auf verschiedenen Versionen des Betriebssystems
(wenn man keine spezifische Funktionalität verwendet, aber das
versteht sich von selbst), somit kann man es einmal kompilieren und
die User laden es sich runter. Scheint eigentlich passabel zu
funktionieren.
Im Gegensatz zu Linux? Hast du da eine konkrete Erfahrung gemacht?
Unter Linux läuft Zeug aus Debian Unstable gerne mal nicht in Debian
Stable, weil die libc zu alt ist. Oder irgendwelche anderen Pakete.
das ist ja nun relativ spezifisch zu Debain und in den langen
Releasezeiten begründet. Häufig gibt es deswegen ja backports.
Allerdings benutzt du dann auch die neusten Versionen von Software, die
inkompatible Teile zu alen Versionen hat.. bzw. Bugfixes, die du
unbedingt brauchst/willst. Was würdest du unter Windows machen? einfach
die Dll mitgeben, oder? Geht auch unter Linux so, wenn du das so machen
willst.
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html gibt
Hinweise wie das geht. Der Unterschied ist aber die Art und Weise in der
nach Bibliotheken gesucht wird. Windows such meist zuerst im aktuellen
Verzeichnis (normalerweise dass, der Applikation) nach der DLL, bevor es
woanders sucht. Dadurch lässt sich relativ einfach etwas einschmuggeln.
Aber sowas geht unter Linux auch, ist halt dort nicht der Standard.

Tatsächlich will man sich unter Linux doch einfach nicht diese Mühe
machen. Es gibt ja schliesslich ein Paketverwaltungssystem, dass
normalerweise bibliotheken für mich findet und installiert. Unter
Windows gibt es das nicht, da murkst jeder rum wie er will und das wird
dann Windows auch noch zu Gute gehalten...
Post by Marek Kubica
Daher kompilieren viele Leute den Kram den sie weiterverteilen wollen
auf irgendwelchen alten Systemen wo sie davon ausgehen können dass es
dann auch auf neueren läuft (PLT Scheme kompiliert etwa auf Fedora 7
und das tut dann auch noch auf Debian 5.0).
Sind und Zweck dieser Aktion ist ja nicht gegen die neuen Header files
zu kompilieren denke ich mal. Zum einen muss ich ehrlich gesagt sagen,
dass mir unklar ist warum man das so macht... ich meine wenn man sich
auf die Funktionen beschränkt, die nur in der alten Version zur
Verfügung steht, dann müsste das doch gehen, oder? gibt natürlich auch
inkompatible Änderungen... dann muss man aber sowieso den spezielleren
Namen der Bibliothek benutzen. Und zum anderen kann man doch die
Includes des Compilers beeinflussen... dann kann man sich das doch alles
entsprechend zusmamensetzen.

Würde man unter Windows mit Visual Studio kompilieren, dann wäre das
doch genau so... unter Linux beschwert man sich aber dann, wenn man es
auch so machen soll.. Aber unter Windows ist es halt der einzige Weg und
unter Linux nicht der "saubere", also ist es für Windows egal, aber für
Linux schlecht...
Post by Marek Kubica
Und die Problematik mit den ganzen verschiedenen Paketformaten mal
außen vor gelassen.
Nun, das stimmt... ein einheitliches Paketsystem wäre wirklich super...
zum Glück benutzen schon recht viele das Debian-Paketsytem.

Gruss theo
Michael Bruschkewitz
2009-01-17 11:40:10 UTC
Permalink
Post by Jochen Theodorou
Post by Marek Kubica
Im Gegensatz zu Linux laufen für Windows kompilierte Binaries meistens
Problemlos auf verschiedenen Versionen des Betriebssystems (wenn man
keine spezifische Funktionalität verwendet, aber das versteht sich von
selbst), somit kann man es einmal kompilieren und die User laden es
sich runter. Scheint eigentlich passabel zu funktionieren.
Im Gegensatz zu Linux? Hast du da eine konkrete Erfahrung gemacht?
Du hast mich zwar nicht gefragt, aber: Ja. Mehrfach.

Insbesondere bekommst Du Probleme, wenn Du irgendwelchen proprietären
Fremdkot integrieren musst, der ohne Adapterschicht auf Hardwareresourcen
zugreift (für die es wiederum nicht für alle Linux-Versionen Treiber gibt),
der sich auf veraltete Bibliotheken (und dazugehörige Header) verlässt, und
der zur Krönung irgendwelche Systembibliotheken (die ja im Quelltext
verfügbar sind) zu eigenen Zwecken modifiziert und umwidmet.

Das kann dann ganz schnell zu Zusatzaufwand im Mannmonatsbereich führen
(wofür natürlich dann kein Budget mehr da ist) bzw. die beabsichtigte
Implementierung völlig unmöglich machen.
Mit ein bisschen Glück kannst Du den ganzen Mist noch in einen eigenen
Prozess auslagern, evtl. musst Du eine extra Maschine danebenstellen (VM
reicht nicht, da Hardware involviert) und diese über TCP oder gar seriell
ankoppeln.

Portabilität unter Linux halte ich für einen Witz, sobald man das Niveau von
"Hello world" und Office-Anwendungen verlässt.

Fehlende Treiber gibt es auch bei Windows, allerdings ist bei Windows die
Anzahl der möglichen Plattformen nicht so gross.
Die anderen oben beschriebenen Probleme sind bei Windows eher
unwahrscheinlich.

Michael B.
Jochen Theodorou
2009-01-18 00:02:14 UTC
Permalink
Post by Michael Bruschkewitz
Post by Jochen Theodorou
Post by Marek Kubica
Im Gegensatz zu Linux laufen für Windows kompilierte Binaries meistens
Problemlos auf verschiedenen Versionen des Betriebssystems (wenn man
keine spezifische Funktionalität verwendet, aber das versteht sich von
selbst), somit kann man es einmal kompilieren und die User laden es
sich runter. Scheint eigentlich passabel zu funktionieren.
Im Gegensatz zu Linux? Hast du da eine konkrete Erfahrung gemacht?
Du hast mich zwar nicht gefragt, aber: Ja. Mehrfach.
Insbesondere bekommst Du Probleme, wenn Du irgendwelchen proprietären
Fremdkot integrieren musst, der ohne Adapterschicht auf Hardwareresourcen
zugreift (für die es wiederum nicht für alle Linux-Versionen Treiber gibt),
der sich auf veraltete Bibliotheken (und dazugehörige Header) verlässt, und
der zur Krönung irgendwelche Systembibliotheken (die ja im Quelltext
verfügbar sind) zu eigenen Zwecken modifiziert und umwidmet.
wenn man
keine spezifische Funktionalität verwendet, aber das versteht sich von
selbst
etwas deinem Fall entsprechendes kann es so unter Windows ja nicht
geben. Aber nicht weil Windows wirklich besser wäre, sondern weil man
uner Windows normalerwiese keine im Quelltext vorhandenen
Sysembibliotheken vorliegen hat. Wenn ich da an so manche Software uas
Zeiten von NT oder Windows95 denke, dann geht das heute auch nicht alles
auf einem Vista-System. Wenn dein Windows95-Programm einfach lustig
irgendwelche Dlls rumkopiert, dann freut das Vista überhaupt nicht zum
Beispiel..

Unter Windows würde man dann sagen:"Geht nicht", unter Linux will man
die Frickellösung durch noch mehr Frickelei retten... nur weil es
vielleicht theoretisch möglich ist... finde ich schon seltsam. Oder man
würde das machen:

[...]
Post by Michael Bruschkewitz
Mit ein bisschen Glück kannst Du den ganzen Mist noch in einen eigenen
Prozess auslagern, evtl. musst Du eine extra Maschine danebenstellen (VM
reicht nicht, da Hardware involviert) und diese über TCP oder gar seriell
ankoppeln.
schon seltsam...
Post by Michael Bruschkewitz
Portabilität unter Linux halte ich für einen Witz, sobald man das Niveau von
"Hello world" und Office-Anwendungen verlässt.
Du meinst Software die in Ring 0 laufen muss, oder was? Abgesehen davon
dürften 99% der Anwendungen doch auf dem Niveau liegen, oder?

Gruss theo
Michael Bruschkewitz
2009-01-19 00:12:30 UTC
Permalink
Post by Christoph Herrmann
wenn man
keine spezifische Funktionalität verwendet, aber das versteht sich von
selbst
"man" ist in diesen Fällen schon weg bzw. nicht dazu zu bewegen, noch etwas
zu ändern.
Und wenn, dann ist "man" nicht in der Lage oder Willens, die Zulieferung
auch termingerecht zu erledigen.
Denn zu ordentlicher Arbeit hat es ja schon vorher nicht gereicht.

"versteht sich von selbst" - selten so gelacht. Schon mal was von Praxis
gehört? Was, wenn die "spezifische Funktionalität" genau das Kernstück der
zu lösenden Aufgabe ist?
etwas deinem Fall entsprechendes kann es so unter Windows ja nicht geben.
Kann es, müssen ja nicht unbedingt die Systembibliotheken sein, die im
Quelltext vorliegen. MFC reicht schon.
Quelltext war ja nur eine Problemversion.
Aber nicht weil Windows wirklich besser wäre, sondern weil man uner
Windows normalerwiese keine im Quelltext vorhandenen Sysembibliotheken
vorliegen hat.
Eher, weil es von Windows nicht so viele Varianten gibt. Vielleicht auch,
weil es betreffend Windows weniger Dogmatiker gibt.

Wenn ich da an so manche Software uas
Zeiten von NT oder Windows95 denke, dann geht das heute auch nicht alles
auf einem Vista-System. Wenn dein Windows95-Programm einfach lustig
irgendwelche Dlls rumkopiert, dann freut das Vista überhaupt nicht zum
Beispiel..
Das setzt aber auch niemand voraus.
Unter Windows würde man dann sagen:"Geht nicht", unter Linux will man die
Frickellösung durch noch mehr Frickelei retten...
"Geht nicht" geht gar nicht. Höchstens für Studenten oder Praktikanten.
Ansonsten ist auch eine schlechte Lösung besser als gar keine.
schon seltsam...
Kannst Du gern so bezeichnen, wenn das in Deinem Universum eine Umschreibung
für "brauchbare, termintreue und preisgünstige Lösung" ist.
Du meinst Software die in Ring 0 laufen muss, oder was? Abgesehen davon
dürften 99% der Anwendungen doch auf dem Niveau liegen, oder?
"Ring 0" ist kein Kriterium. Schlechter "Stil" ist OS-unabhängig verfügbar.
Und kann jedem mal passieren.

Die 99% will ich nicht diskutieren, ich bin z.B. der Meinung, dass 99% aller
_relevanten_ Anwendungen hardwareabhängig sind.
Und dann spielt Portabilität sowieso keine Rolle.


Viele Grüsse,
Michael B.
Jochen Theodorou
2009-01-19 02:08:46 UTC
Permalink
Post by Michael Bruschkewitz
Post by Christoph Herrmann
wenn man
keine spezifische Funktionalität verwendet, aber das versteht sich von
selbst
"man" ist in diesen Fällen schon weg bzw. nicht dazu zu bewegen, noch etwas
zu ändern.
Und wenn, dann ist "man" nicht in der Lage oder Willens, die Zulieferung
auch termingerecht zu erledigen.
Denn zu ordentlicher Arbeit hat es ja schon vorher nicht gereicht.
wenn man das vorher weiss dann ist ja gut... ehm.. ok, der Chef sollte
es wissen ;)
Post by Michael Bruschkewitz
"versteht sich von selbst" - selten so gelacht. Schon mal was von Praxis
gehört? Was, wenn die "spezifische Funktionalität" genau das Kernstück der
zu lösenden Aufgabe ist?
Kommt auf den Einzefall an, aber neu schreiben ist oft besser. Wenn man
das nicht kann, dann sollte man sich das Projekt wirklich nochmal neu
überlegen.

[...]
Post by Michael Bruschkewitz
Aber nicht weil Windows wirklich besser wäre, sondern weil man uner
Windows normalerwiese keine im Quelltext vorhandenen Sysembibliotheken
vorliegen hat.
Eher, weil es von Windows nicht so viele Varianten gibt. Vielleicht auch,
weil es betreffend Windows weniger Dogmatiker gibt.
was meisnt du denn mit Varianten in dem Fall?
Post by Michael Bruschkewitz
Wenn ich da an so manche Software aus
Zeiten von NT oder Windows95 denke, dann geht das heute auch nicht alles
auf einem Vista-System. Wenn dein Windows95-Programm einfach lustig
irgendwelche Dlls rumkopiert, dann freut das Vista überhaupt nicht zum
Beispiel..
Das setzt aber auch niemand voraus.
ja, aber das eine Software, die für Kernel 1.8 geschrieben wurde mit
Kernel 2.6 läuft scheints schon.
Post by Michael Bruschkewitz
Unter Windows würde man dann sagen:"Geht nicht", unter Linux will man die
Frickellösung durch noch mehr Frickelei retten...
"Geht nicht" geht gar nicht. Höchstens für Studenten oder Praktikanten.
Ansonsten ist auch eine schlechte Lösung besser als gar keine.
kommt darauf an... wenn man etwas unbedingt will und das geht nur mit
dieser Software... dann muss man halt auch ein System für diese Software
aufsetzen, fertig. Da sehe ich keinen Unterschied zwischen den
Betriebssystemen. Manchmal ist eine neue, weniger umfassende Lösung besser
Post by Michael Bruschkewitz
schon seltsam...
Kannst Du gern so bezeichnen, wenn das in Deinem Universum eine Umschreibung
für "brauchbare, termintreue und preisgünstige Lösung" ist.
in meinem Universum? Kein Grund aggresiv zu werden... wir sind hier
nicht in einer "meins ist größer als deins"-Diskussion. Ich habe
reichlich Erfahrung mit solchen Lösungen... ganz OS-unspezifisch. Und
die Erfahrung ist, dass preisgünstig die Wartung meist nicht mit
einschließt. Kaufe ich ein Komplettprodukt und es macht was es soll,
dann muss ich mich als Kunde bei soclhen Lösungen damit abfinden, dass
eine später Erweiterung oder simple Modifikation unmöglich ist. Als
Programmierer muss ich mich damit abfinden, dass ich große Teile der
Software vielleicht neu schreiben muss. Richtig zur Hölle wird es, wenn
man die fehlerhaften Teile dann unbedingt behalten muss. Das ehemals
preisgünstige Produkt kann so nochmal richtig teuer werden.

Nervig sind auch die Bugs, die durch diese Frickelei entstanden sind und
sich dann vielleicht garnicht mehr richtig fixen lassen. Aber man hat ja
termingerecht und preisgünstig geliefert
Post by Michael Bruschkewitz
Du meinst Software die in Ring 0 laufen muss, oder was? Abgesehen davon
dürften 99% der Anwendungen doch auf dem Niveau liegen, oder?
"Ring 0" ist kein Kriterium. Schlechter "Stil" ist OS-unabhängig verfügbar.
Und kann jedem mal passieren.
Sehe ich absolut auch so... aber darum ging es doch eigentlich garnicht.
Post by Michael Bruschkewitz
Die 99% will ich nicht diskutieren, ich bin z.B. der Meinung, dass 99% aller
_relevanten_ Anwendungen hardwareabhängig sind.
Und dann spielt Portabilität sowieso keine Rolle.
was meinst du dann mit relevanten Anwendungen?

Gruss theo
Michael Bruschkewitz
2009-01-19 08:33:00 UTC
Permalink
Post by Michael Bruschkewitz
"man" ist in diesen Fällen schon weg bzw. nicht dazu zu bewegen, noch
etwas zu ändern.
Und wenn, dann ist "man" nicht in der Lage oder Willens, die Zulieferung
auch termingerecht zu erledigen.
Denn zu ordentlicher Arbeit hat es ja schon vorher nicht gereicht.
wenn man das vorher weiss dann ist ja gut... ehm.. ok, der Chef sollte es
wissen ;)
Dummerweise weiss man es (als Externer) ja nicht vorher. Ich nehme es jetzt
aber als Defaultwert an und bin dann lieber positiv überrascht. Selten
genug.
Kommt auf den Einzefall an, aber neu schreiben ist oft besser. Wenn man
das nicht kann, dann sollte man sich das Projekt wirklich nochmal neu
überlegen.
Wenn es um eine Beauftragung im Mannjahr-Bereich und ein Projekt im Umfang
von mehreren Mannjahrzehnten geht?
was meisnt du denn mit Varianten in dem Fall?
Windows: z.Z. relevant eigentlich nur XP 32 Bit (64-Bit Varianten
normalerweise irrelevant).
Oberfläche, Systembibliotheken, APIs stabil bis auf Security-Fixes.
ja, aber das eine Software, die für Kernel 1.8 geschrieben wurde mit
Kernel 2.6 läuft scheints schon.
Hat bisher noch niemand vorausgesetzt. Hatte ich aber auch nicht angeführt.
kommt darauf an... wenn man etwas unbedingt will und das geht nur mit
dieser Software... dann muss man halt auch ein System für diese Software
aufsetzen, fertig. Da sehe ich keinen Unterschied zwischen den
Betriebssystemen. Manchmal ist eine neue, weniger umfassende Lösung besser
Der Aufwand typischer Projekte bewegt sich im Mannjahrbereich.
Die aus Stilgründen neu aufzusetzen bezahlt niemand.
Post by Michael Bruschkewitz
Kannst Du gern so bezeichnen, wenn das in Deinem Universum eine
Umschreibung für "brauchbare, termintreue und preisgünstige Lösung" ist.
in meinem Universum? Kein Grund aggresiv zu werden...
In meinem Universum ist das nicht aggressiv :)
Ich habe reichlich Erfahrung mit solchen Lösungen... ganz OS-unspezifisch.
Und die Erfahrung ist, dass preisgünstig die Wartung meist nicht mit
einschließt.
Da sind wir auf einer Wellenlänge. Es liegt aber auch nicht im Interesse der
jeweiligen Zulieferer, Wartung preisgünstig zu gestalten.
M.E. gestalten einige Zulieferer ihre Produkte so, dass sie möglichst viel
Wartung verursachen. Und das kann ich belegen, allerdings nicht hier.
Kaufe ich ein Komplettprodukt und es macht was es soll, dann muss ich mich
als Kunde bei soclhen Lösungen damit abfinden, dass eine später
Erweiterung oder simple Modifikation unmöglich ist.
Sprichst Du hier als Kunde aus Erfahrung oder stellt Du Deine
Entwicklersicht dar?
Meist sieht es doch so aus: Der Kunde ist der Meinung, etwas wenn schon
nicht ganz Tolles (denn dann würdest Du ja nicht beauftragt) aber doch
zumindest ganz brauchbares eingekauft zu haben. Das will/muss er in ein
grösseres/anderes Projekt integrieren. dafür braucht er eine Lösung. Die
Zulieferung ist so gross, dass eine Neuerstellung weder in die Termine noch
in das Budget passt und ausserdem auch die entsprechende Kompetenz nicht
verfügbar ist. (Bzw. wird Dir nicht zugetraut oder Kunde blockt um Macht zu
sichern.)
Ausserdem ist es immer schwierig, dem Kunden klar zu machen, was in der
Zulieferung alles mies ist, denn damit stellst Du ja seine bisherige Arbeit
in Frage.
Da ich selbst normalerweise nicht die Kompetenz des Kunden in Frage stelle -
sehr oft sitzen ja auch da kompetente Leute - setze ich auch voraus, dass
die Zulieferungen einigermassen in Ordnung sind. Dass sich bei Projektleiter
X die Probleme in den Zulieferungen häufen und sich die Architektur des
Gesamtprodukts in Richtung "Klumpatsch" bewegt, weiss man erst nach ein paar
Jahren.
Als Programmierer muss ich mich damit abfinden, dass ich große Teile der
Software vielleicht neu schreiben muss. Richtig zur Hölle wird es, wenn
man die fehlerhaften Teile dann unbedingt behalten muss. Das ehemals
preisgünstige Produkt kann so nochmal richtig teuer werden.
Ich schreibe gern neu, wenn es der Kunde bezahlt. Nur leider liegt genau da
das Problem.
Das preisgünstig (??? Nicht mal das.) vom Kunden erworbene Zulieferprodukt
musst Du im Folgeprojekt verabeiten.
Teuer wird es dann nur für Dich, wenn Du das nicht rechtzeitig merkst, den
entstehenden Mehraufwand kannst Du kaum zu 100% an den Kunden weitergeben.
Da kannst Du zufrieden sein, wenn Du 50% des Mehraufwands weitergeben kannst
(Nachtrag).
Nervig sind auch die Bugs, die durch diese Frickelei entstanden sind und
sich dann vielleicht garnicht mehr richtig fixen lassen. Aber man hat ja
termingerecht und preisgünstig geliefert.
Wenn man selbst frickeln muss, muss das Konzept schon stimmen. Dann klappt
es schon mit dem Fixen.
Sehe ich absolut auch so... aber darum ging es doch eigentlich garnicht.
Wir sind sowieso schon meilenweit OT.
was meinst du dann mit relevanten Anwendungen?
Bsp.:
Alle Arten von Fzg.-Steuerungen, z.B. Bahntechnik, Flugsicherung,
Schiffahrt, Raumfahrt, Strassenbahn, Kfz.
Anlagensteuerungen in Chemiebetrieben, bei Lebensmittelherstellern,
Wasserwerke, Kraftwerke.
Medizintechnik.
(Bis hierher alles Life-Critical Anwendungen.)
In diesen Fällen kannst Du nicht frickeln. Beim Test derselben musst Du das
oft.

Comsumerprodukte wie Satellitenreceiver, Kameras, Handies, MP3-Player,
Waschmaschinen, Geschirrspüler.
Telekommunikationsanbieter, Banken.
(Hier z.T. Enterprise-Critical Anwendungen, also auf jeden Fall Projekte mit
hoher wirtschaftlicher Auswirkung.)
Hier wird gefrickelt was das Zeug hält. (Man merkts auch.)

Die Listen kannst Du beliebig erweitern.

Soweit so gut.

Aber: Warum Java und nicht C#?


In diesem Sinne,
viele Grüsse.
Jochen Theodorou
2009-01-19 09:09:21 UTC
Permalink
[...]
Post by Michael Bruschkewitz
Post by Jochen Theodorou
Kommt auf den Einzefall an, aber neu schreiben ist oft besser. Wenn man
das nicht kann, dann sollte man sich das Projekt wirklich nochmal neu
überlegen.
Wenn es um eine Beauftragung im Mannjahr-Bereich und ein Projekt im Umfang
von mehreren Mannjahrzehnten geht?
Ich muss ehrlich sagen dass ich in so einem Projekt noch nie war.
Entweder ich kannte das Projekt schon vorher und konnte selbst
beurteilen ob ich das (in welcher Zeit auch immer) schaffen kann. Oder
der umfang ist wesentlich kleiner gewesen. Aber ehrlich gesagt habe ich
schon immer, wenn möglich, die Finger von einem Projekt gelassen, wenn
es darum ging eine alte, über viele Jahre gewachsene, Speziallösung zu
erweitern. So ein Fall ist mir ehrlich gesagt auh selten unter gekommen.
Liegt wahrscheinlich daran, dass ich eher in anderen Bereichen
arbeite... also zum Beispiel nicht in der Produktion.

[...]
Post by Michael Bruschkewitz
Post by Jochen Theodorou
kommt darauf an... wenn man etwas unbedingt will und das geht nur mit
dieser Software... dann muss man halt auch ein System für diese Software
aufsetzen, fertig. Da sehe ich keinen Unterschied zwischen den
Betriebssystemen. Manchmal ist eine neue, weniger umfassende Lösung besser
Der Aufwand typischer Projekte bewegt sich im Mannjahrbereich.
Die aus Stilgründen neu aufzusetzen bezahlt niemand.
ich glaube das geht zu sehr ins Detail für eine Diskussion hier. Ich
kann nur sagen, dass meine Erfahrungen da ein wenig anders sind.
Zumindest Teilersetzungen sind oft möglich. Aber letzlich kommt es da
auf den konkreten Fall an und da sind mir vielleicht andere Fälle unter
gekommen als dir.

[...]
Post by Michael Bruschkewitz
Post by Jochen Theodorou
Ich habe reichlich Erfahrung mit solchen Lösungen... ganz OS-unspezifisch.
Und die Erfahrung ist, dass preisgünstig die Wartung meist nicht mit
einschließt.
Da sind wir auf einer Wellenlänge. Es liegt aber auch nicht im Interesse der
jeweiligen Zulieferer, Wartung preisgünstig zu gestalten.
M.E. gestalten einige Zulieferer ihre Produkte so, dass sie möglichst viel
Wartung verursachen. Und das kann ich belegen, allerdings nicht hier.
Ich denke da kommt es daruaf an ob es ein Wegwerfprodukt ist, oder ob
das eine Produktlinie ist, bei der man mit der Zeit eine neuere Version
der Software wird verkaufen wollen. Im letzteren Fall ist die
Codequalität wichtig, im ersteren interessieren sich zunächst wenige
dafür. Beim Kunden kann trotzdem viel Wartung notwendig sein... oder
besser noch, man kann das Problem schnell lösen läßt das aber trotzdem
einiges kosten. Aber auch hier kommt es auf den Einsatzbereich an und
vorallem auf das Produkt.
Post by Michael Bruschkewitz
Post by Jochen Theodorou
Kaufe ich ein Komplettprodukt und es macht was es soll, dann muss ich mich
als Kunde bei solchen Lösungen damit abfinden, dass eine später
Erweiterung oder simple Modifikation unmöglich ist.
Sprichst Du hier als Kunde aus Erfahrung oder stellt Du Deine
Entwicklersicht dar?
ein bischen beides ;)
Post by Michael Bruschkewitz
Meist sieht es doch so aus: Der Kunde ist der Meinung, etwas wenn schon
nicht ganz Tolles (denn dann würdest Du ja nicht beauftragt) aber doch
zumindest ganz brauchbares eingekauft zu haben. Das will/muss er in ein
grösseres/anderes Projekt integrieren. dafür braucht er eine Lösung. Die
Zulieferung ist so gross, dass eine Neuerstellung weder in die Termine noch
in das Budget passt und ausserdem auch die entsprechende Kompetenz nicht
verfügbar ist. (Bzw. wird Dir nicht zugetraut oder Kunde blockt um Macht zu
sichern.)
Ausserdem ist es immer schwierig, dem Kunden klar zu machen, was in der
Zulieferung alles mies ist, denn damit stellst Du ja seine bisherige Arbeit
in Frage.
hehe, ja... oft wird ja gesagt: "das haben wir damals so teuer
eingekauft" oder ähnliches. Ich will garnicht sagen dass der kunde
unbedingt seine Macht sichern will, er glaubt auf diese Weise seine
Investitionen zu sichern. Neue Software heisst oft genug auch dass ein
haufen Angestellte umgeschult werden muss... sind alles kosten. Kommt
man als Externer Einzelkämpfer in eine Firma um eine Software zu
erweitern hat man da natürlich eine ganz andere Position als eine Firma,
die ein Produkt verkauft.
Post by Michael Bruschkewitz
Da ich selbst normalerweise nicht die Kompetenz des Kunden in Frage stelle -
sehr oft sitzen ja auch da kompetente Leute - setze ich auch voraus, dass
die Zulieferungen einigermassen in Ordnung sind. Dass sich bei Projektleiter
X die Probleme in den Zulieferungen häufen und sich die Architektur des
Gesamtprodukts in Richtung "Klumpatsch" bewegt, weiss man erst nach ein paar
Jahren.
ja, stimmt.

[...]
Post by Michael Bruschkewitz
Post by Jochen Theodorou
was meinst du dann mit relevanten Anwendungen?
Alle Arten von Fzg.-Steuerungen, z.B. Bahntechnik, Flugsicherung,
Schiffahrt, Raumfahrt, Strassenbahn, Kfz.
Anlagensteuerungen in Chemiebetrieben, bei Lebensmittelherstellern,
Wasserwerke, Kraftwerke.
Medizintechnik.
(Bis hierher alles Life-Critical Anwendungen.)
In diesen Fällen kannst Du nicht frickeln. Beim Test derselben musst Du das
oft.
Comsumerprodukte wie Satellitenreceiver, Kameras, Handies, MP3-Player,
Waschmaschinen, Geschirrspüler.
Telekommunikationsanbieter, Banken.
(Hier z.T. Enterprise-Critical Anwendungen, also auf jeden Fall Projekte mit
hoher wirtschaftlicher Auswirkung.)
Hier wird gefrickelt was das Zeug hält. (Man merkts auch.)
ja, da stimme ich zu.
Post by Michael Bruschkewitz
Die Listen kannst Du beliebig erweitern.
Soweit so gut.
Aber: Warum Java und nicht C#?
Also ich glaube bei der Steuerung des Raumfahrzeugs der nächsten
Generation wird wohl weder C# noch Java benutzt werden ;)
Steuerungssoftware ist nicht unbedingt ein typischer Fall für Java. Bei
C# weiss ich es nicht. Existiert die Steueruungssoftware und soll man
nur eine Eine Schicht dafür programmieren ist es meist relativ egal ob
Java oder C#

Gruss theo
Michael Bruschkewitz
2009-01-19 09:58:12 UTC
Permalink
Post by Jochen Theodorou
Post by Michael Bruschkewitz
Aber: Warum Java und nicht C#?
Also ich glaube bei der Steuerung des Raumfahrzeugs der nächsten
Generation wird wohl weder C# noch Java benutzt werden ;)
Steuerungssoftware ist nicht unbedingt ein typischer Fall für Java. Bei C#
weiss ich es nicht. Existiert die Steueruungssoftware und soll man nur
eine Eine Schicht dafür programmieren ist es meist relativ egal ob Java
oder C#
Bei Life-Critical-Anwendungen kommt es vor allem auf eine komplett
verifizierte Toolchain an, und auf harte Echtzeitanforderungen.
(Und natürlich auf ausreichende Qualifikation und Einhaltung der Prozesse,
vollständige Tests auf allen Architekturebenen etc.)
Die kann man (nach meinen Kenntnissen) weder in Java noch in C# realisieren,
ich habe noch keine Kenntnisse von einem derartigen Projekt.

Wichtig ist es, dass der Compiler Code erzeugt, der unter allen Umständen
die gleichen Reaktionen auf gleiche Eingangsparameter hervorruft.
(Da dürfte der GC in Java und C# schon mal das grösste Problem darstellen.)
C,C++,Ada,Modula-2,Pascal und natürlich Assembler sind da die Sprachen, die
ich aus solchen Projekten kenne.

Aber zum Test und für unkritische Funktionen könnte durchaus Java bzw. C#
benutzt werden, z.B. bei der Konfiguration und beim Test kommt es ja auch
auf Usability an.
Schlechte Usability der Testumgebung mach das Erkennen von Fehlern schwerer
und widerspricht z.B. dem Best-Practice-Grundsatz.

Viele Grüsse auch,
und jetzt lass uns mal wieder Geld verdienen.

Daniel Urban
2009-01-14 17:24:12 UTC
Permalink
"Christoph Herrmann"
Post by Christoph Herrmann
Post by Lothar Kimmeringer
SUN entwickelt ihre JVMs nur fuer eine Handvoll Systeme, das
ist korrekt.
[...]
Apple hat ihre JVM 1.5 nach kurzen Onlinestellen gleich wieder
zurueckgezogen. Hat aber nichts mit SUN oder Java zu tun.
für mich schon. Was bringt mir das wenn Java Plattformunabhängig ist und
dann doch nur auf ein paar Systemen funktioniert?
Plattformunabhängig ist ein Marketing-Buzzword. Java läuft überall, wo es
eine implementierte VM gibt. C läuft überall, wo es einen implementierten
C-Compiler gibt. Jetzt dürft ihr Euch streiten, wer mehr Plattformen
unterstützt.

Die Diskussion hatten wir in der Gruppe auch schon öfter. Für mich ist noch
zu unterscheiden, dass man für verschiedene Plattformen implementieren kann
(mehere Implementerierungen) und dem Write-Once-Run-Everywhere
Marketing-Buzzword, was für mich in der Praxis mit der notwendigen Ergonomie
sehr selten möglich sein dürfte.

Gruß,

Daniel
Daniel Urban
2009-01-14 17:32:04 UTC
Permalink
Post by Daniel Urban
Die Diskussion hatten wir in der Gruppe auch schon öfter. Für mich ist
noch zu unterscheiden, dass man für verschiedene Plattformen
implementieren kann (mehere Implementerierungen) und dem
Write-Once-Run-Everywhere Marketing-Buzzword, was für mich in der Praxis
mit der notwendigen Ergonomie sehr selten möglich sein dürfte.
Um die Diskussion an dieser Stelle nicht ausufern zu lassen, ergänze ich
noch, dass sich o.g. Aussage in erster Linie auf Programme mit GUI bezieht.

Gruß,

Daniel
Bernd Eckenfels
2009-01-14 18:35:34 UTC
Permalink
Post by Daniel Urban
Plattformunabhängig ist ein Marketing-Buzzword. Java läuft überall, wo es
eine implementierte VM gibt. C läuft überall, wo es einen implementierten
C-Compiler gibt. Jetzt dürft ihr Euch streiten, wer mehr Plattformen
unterstützt.
Da gibts nix zu streiten... C ist ja wohl der klare Sieger.

Gruss
Bernd
Gunter Herrmann
2009-01-15 04:15:42 UTC
Permalink
Hi!
Post by Daniel Urban
Plattformunabhängig ist ein Marketing-Buzzword. Java läuft überall, wo
es eine implementierte VM gibt. C läuft überall, wo es einen
implementierten C-Compiler gibt. Jetzt dürft ihr Euch streiten, wer mehr
Plattformen unterstützt.
Bei C ist noch etwas zu beachten:
Die Zielplattform muß keinen C-Compiler implentiert haben.
Es genügt auch, eine Crosscompiler zu haben, der auf dem
Entwicklungssystem läuft und und eine Executable für die
Zielplattform erstellt.

Beste Grüße

Gunter
--
Gunter Herrmann
Orlando, Florida, USA
Jochen Theodorou
2009-01-15 13:29:05 UTC
Permalink
Post by Gunter Herrmann
Hi!
Post by Daniel Urban
Plattformunabhängig ist ein Marketing-Buzzword. Java läuft überall, wo
es eine implementierte VM gibt. C läuft überall, wo es einen
implementierten C-Compiler gibt. Jetzt dürft ihr Euch streiten, wer mehr
Plattformen unterstützt.
Die Zielplattform muß keinen C-Compiler implentiert haben.
Es genügt auch, eine Crosscompiler zu haben, der auf dem
Entwicklungssystem läuft und und eine Executable für die
Zielplattform erstellt.
na das ist nicht nur bei C so ;) Idealerweise ist natürlich der Compiler
selbst in C geschrieben. das bedeutet sobald man den Crosscompiler hat,
kann man den Compiler mit sich selbst übersetzen und hat schon einen
neuen Compiler, der auf der Zielplattform läuft.

Achja... Vorlesung Compilerbau 1 ;)

Gruss theo
Thomas Thiele
2009-01-15 19:14:11 UTC
Permalink
Post by Jochen Theodorou
na das ist nicht nur bei C so ;) Idealerweise ist natürlich der Compiler
selbst in C geschrieben. das bedeutet sobald man den Crosscompiler hat,
kann man den Compiler mit sich selbst übersetzen und hat schon einen
neuen Compiler, der auf der Zielplattform läuft.
Jain.
Die Zielplattform muss genügend Ressourcen für den Compiler haben.
Michael Bruschkewitz
2009-01-16 23:50:43 UTC
Permalink
Post by Thomas Thiele
Die Zielplattform muss genügend Ressourcen für den Compiler haben.
Plus die Libs, mindestens File-IO.
Günter Vollmer
2009-01-15 10:12:36 UTC
Permalink
Post by Christoph Herrmann
für mich schon. Was bringt mir das wenn Java Plattformunabhängig ist und
dann doch nur auf ein paar Systemen funktioniert?
Soo Plattformunabhängig ist Java dann ja anscheinend doch nicht wie
immer angepriesen wird.
ich denke, die unterstützten Systeme dürften mit Windows, Linux und Solaris
sicher 98% aller installierten Systeme umfassen.

Ein anderes Problem mit C hast Du, daß Du für dieselbe Unterstützung wie mit
Java schon mal drei verschiedene Programme anbieten mußt - wenn Du nicht
dem Anwender das Compilieren und den Quellcode überlassen willst.

Und auch wenn Du von den verbleibenden 2% der Betriebssysteme UND/ODER CPUs
weitere 1,99% erreichst, so hast Du am Ende sicherlich 10 verschiedene
Versionen zum Verteilen/Verkaufen.

Ob es DAS wirklich besser macht???


GV
Christoph Herrmann
2009-01-15 10:17:50 UTC
Permalink
Post by Günter Vollmer
Ob es DAS wirklich besser macht???
Das Kompilieren und Bereit stellen kann man doch automatisieren und wenn
der Kunde beim Download halt noch auswählen muss was für eine Plattform
er hat ist es auch kein Beinbruch, oder?

Hat Mac OS eigentlich so wenig Marktanteile, also unter 2%? ;)
--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Günter Vollmer
2009-01-15 10:26:30 UTC
Permalink
Post by Christoph Herrmann
Post by Günter Vollmer
Ob es DAS wirklich besser macht???
Das Kompilieren und Bereit stellen kann man doch automatisieren und wenn
der Kunde beim Download halt noch auswählen muss was für eine Plattform
er hat ist es auch kein Beinbruch, oder?
Hat Mac OS eigentlich so wenig Marktanteile, also unter 2%? ;)
äh ja, sorry, hatte ich vergessen. Also Win+Mac+Linux+Solaris = 98%.

OK, automatisiert ist das vielleicht einfacher, aber damit immer noch nicht
getestet, wohingegen sich die einzelnen JRE gleich verhalten sollten - und
wenn nicht, habe ich keinen Einfluß darauf ;-)

GV
Bernd Eckenfels
2009-01-15 14:24:12 UTC
Permalink
Post by Günter Vollmer
OK, automatisiert ist das vielleicht einfacher, aber damit immer noch nicht
getestet, wohingegen sich die einzelnen JRE gleich verhalten sollten - und
wenn nicht, habe ich keinen Einfluß darauf ;-)
Nein das kannst du vergessen, du musst immer auf allen Platformen testen und
auch Support Kompetenz aufbauen. Zumindest bei enterprise anwendungen. Sonst
sind die Kunden nicht glücklich.

Gruss
Bernd
Jochen Theodorou
2009-01-15 17:01:24 UTC
Permalink
Post by Bernd Eckenfels
Post by Günter Vollmer
OK, automatisiert ist das vielleicht einfacher, aber damit immer noch nicht
getestet, wohingegen sich die einzelnen JRE gleich verhalten sollten - und
wenn nicht, habe ich keinen Einfluß darauf ;-)
Nein das kannst du vergessen, du musst immer auf allen Platformen testen und
auch Support Kompetenz aufbauen. Zumindest bei enterprise anwendungen. Sonst
sind die Kunden nicht glücklich.
mich würde da die Art der Supportanfragen und Fehler interessieren...
Ich könnte mir vorstellen, dass die bei Javaprogrammen andere sind, als
bei nativen Programmen.

Gruss theo
Bernd Eckenfels
2009-01-15 18:15:56 UTC
Permalink
Post by Jochen Theodorou
mich würde da die Art der Supportanfragen und Fehler interessieren...
z.b.

"wie stelle ich das ulimit fuer files hoch"
"wo sehe ich wieviel physikalischer ram die vm hat"
"warum crashed der JIT compiler"
"wie bekomme ich x-server zugang"
"wie installiere ich software auf einem terminal server shared"
"wieso ist das so langsam (falscher san treiber)"
"wieso kann ich kein -Xms2100M nehmen unter win32"
"wo erhöhe ich die anzahl der threads/user in aix"
"welche patches muessen unter hpux eingespielt sein um java zu nutzen"
"wieso sind von den 10 logischen cpus nur 5 belegbar"
"wo schalte ich direct2d ab das geht nicht mit pcanywhere"
...
Post by Jochen Theodorou
Ich könnte mir vorstellen, dass die bei Javaprogrammen andere sind, als
bei nativen Programmen.
Nicht wesentlich, ausser dass dir die traditionallen DBAs und Sysadmins bei
Java nicht weiterhelfen koennen.

Gruss
Bernd
Bernd Hohmann
2009-01-15 10:40:08 UTC
Permalink
Post by Günter Vollmer
Post by Christoph Herrmann
Soo Plattformunabhängig ist Java dann ja anscheinend doch nicht wie
immer angepriesen wird.
ich denke, die unterstützten Systeme dürften mit Windows, Linux und Solaris
sicher 98% aller installierten Systeme umfassen.
Leider nützen Dir die 98% nicht viel. Windows ist viel GUI (das Thema
hatten wir ja schon ausgiebigst) und wenn man es richtig machen will,
wirds mit Java krampfig. Wenn Du dich auf Serverlösungen stürzt (was wir
hier letztendlich gemacht haben) hast Du auch recht schnell die grossen
Hobel am Hals die eben nicht immer die aktuellsten Runtimes vorhanden
oder auch aktiv haben.

Bernd
--
Well, there's egg and bacon; egg sausage and bacon; egg and
***@spamonly.de ; egg bacon and spam; egg bacon sausage
and ***@spamonly.net ; spam bacon sausage and spam;spam
egg spam spam bacon and ***@nixwill.de ; spam sausage
Bernd Eckenfels
2009-01-15 14:22:52 UTC
Permalink
Post by Günter Vollmer
ich denke, die unterstützten Systeme dürften mit Windows, Linux und Solaris
sicher 98% aller installierten Systeme umfassen.
Naja, das ist viel zu optimistisch. Auch im Server Bereich gibts noch andere
Systeme. Und dann fragt sich ob sich das auf Sites oder Server bezieht
(letzteres ist für ein Softwarehaus nicht so wichtig wie ersteres).

Und im Embedded Bereich/Handhelt Bereich ist Java auch nicht dominant genug
um sich da alleinig drauf zu verlassen.

Gruss
Bernd
Michael Bruschkewitz
2009-01-16 23:55:52 UTC
Permalink
Post by Günter Vollmer
Ein anderes Problem mit C hast Du, daß Du für dieselbe Unterstützung wie mit
Java schon mal drei verschiedene Programme anbieten mußt - wenn Du nicht
dem Anwender das Compilieren und den Quellcode überlassen willst.
Und auch wenn Du von den verbleibenden 2% der Betriebssysteme UND/ODER CPUs
weitere 1,99% erreichst, so hast Du am Ende sicherlich 10 verschiedene
Versionen zum Verteilen/Verkaufen.
Ob es DAS wirklich besser macht???
Der Aufwand für den Build (und die Erstellung desselben, plus Erstellung der
Lieferung) ist immer gering im Vergleich zum Gesamtaufwand.
Die wichtigsten Funktionen müssen sowieso auf allen Plattformen getestet
werden, wenn es sich um ernsthafte Entwicklung handelt.
Dazu gehört auch der Kompatibilitätstest der Libs.

DAS ist also kein Argument.
Bernd Eckenfels
2009-01-14 14:17:58 UTC
Permalink
Post by Christoph Herrmann
Ein C Programm nach dem Posix (hoffe richtig geschrieben) läuft auf
praktisch allen Systemen wenn man es auf dem Zielsystem neu übersetzt.
Ohne Gui?

Gruss
Bernd
Christoph Herrmann
2009-01-14 14:25:30 UTC
Permalink
Post by Bernd Eckenfels
Post by Christoph Herrmann
Ein C Programm nach dem Posix (hoffe richtig geschrieben) läuft auf
praktisch allen Systemen wenn man es auf dem Zielsystem neu übersetzt.
Ohne Gui?
klar ohne GUI, die ist ja in der Regel systemabhängig, aber ging ja
nicht um GUI Programme. ;)

Wobei es gerade für die GUI Bibliotheken gibt die eine ebenso
"Portabilität" garantieren. QT läuft ja zum Beispiel auch auf Windows,
Linux und Mac OS.
--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Marek Kubica
2009-01-14 22:31:36 UTC
Permalink
On Wed, 14 Jan 2009 15:25:30 +0100
Post by Christoph Herrmann
Wobei es gerade für die GUI Bibliotheken gibt die eine ebenso
"Portabilität" garantieren. QT läuft ja zum Beispiel auch auf
Windows, Linux und Mac OS.
Wobei ich jetzt nicht weiß ob man aus dem angesprochenen C-Programm so
einfach Qt (oder wxWidgets) nutzen kann, da diese für C++ gedacht. Aber
mit GTK+ sollte es hinhauen.

Davon mal abgesehen bietet Qt insbesondere für C++-Programmierer noch
ein paar andere Goodies wie Netzwerk und Datenbanken platformunabhängig
mit.

grüße,
Marek
Christoph Herrmann
2009-01-14 22:39:33 UTC
Permalink
Post by Marek Kubica
Wobei ich jetzt nicht weiß ob man aus dem angesprochenen C-Programm so
einfach Qt (oder wxWidgets) nutzen kann, da diese für C++ gedacht. Aber
mit GTK+ sollte es hinhauen.
Ein C Programm kann das nicht, das muss dann schon C++ sein. :)

Zumindest wüsste ich keine Möglichkeit Klassen in C zu benutzen und da
QT eine Klassenbibliothek wird dürfte es recht schwer werden.
--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Marek Kubica
2009-01-15 07:27:00 UTC
Permalink
On Wed, 14 Jan 2009 23:39:33 +0100
Post by Christoph Herrmann
Zumindest wüsste ich keine Möglichkeit Klassen in C zu benutzen und
da QT eine Klassenbibliothek wird dürfte es recht schwer werden.
GObject und GLib generell bieten auch Klassen in C (womöglich auch APR).
Nicht unbedingt bequem, aber man ist ja auch selbst schuld wenn man das
nutzen will ;)

grüße,
Marek
Bernd Hohmann
2009-01-13 12:49:45 UTC
Permalink
Post by Christian Franzen
(außer vielleicht Handys), gibt es eigentlich keinen Grund, warum man
einem Neuling sagen sollte: "Lern Java und nicht C#!". Wie seht ihr das?
Würde mich freuen wenn möglichst viele ihren Senf dazugeben könnten.
Die "Sprache der Wahl" ist immer eine Sache des persönlichen Geschmacks.
und vorallem der Zielsetzung.

Eine Faktura/FiBu/Lohn für Windows würde ich persönlich eher mit einer
Monolithischen Sprache wie VisualBasic oder COBOL schreiben (bzw mit
allem, was Numerische- und Stringvariablen by reference übergibt)

Multithreaded Serveranwendungen eher mit einer OOP-Sprache da sich hier
automatisch eine Objekthierarchie herausbildet.

Bei Java und C# definiert sich die Auswahl über die Zielplattform und
was man dafür an Libaries vorfindet. Eine schicke Windowsanwendung hat
man unter C# schneller zusammengewürfelt als mit Java. Dafür findet sich
für Java (sofern man auf diversen Sprachschnickschnack verzichtet) für
jede Betriebssystem-Plattform und einige µC eine Runtime.

Bernd
--
Well, there's egg and bacon; egg sausage and bacon; egg and
***@spamonly.de ; egg bacon and spam; egg bacon sausage
and ***@spamonly.net ; spam bacon sausage and spam;spam
egg spam spam bacon and ***@nixwill.de ; spam sausage
Alexander Draeger
2009-01-13 14:51:12 UTC
Permalink
Für Java spricht die Verbreitung in der Wirtschaft. Java war eher da und
ich wüsste nichts, was dafür spricht, C# zu lernen. Java und C# sind
sich einfach zu ähnlich.

Interessanter dürften die dynamisch typisierten Sprachen sein, mit denen
man sehr abstrakt entwickeln kann. Deren Produktivität ist etliches
höher. Vernachlässigt werden leider auch die streng typisierten
funktionalen Sprachen.

Das Reizvolle an Java ist nicht die Sprache, sondern die Plattform. Eine
positive Entwicklung ist daher, dass viele Sprachen aus den oben
erwähnten Kategorien (Python, Ruby, OCaml, Haskell) in den Code einer
populären virtuellen Maschine übersetzt werden und nicht jeder seine
eigene VM zwingend voraussetzt.
Stefan Ram
2009-01-13 15:51:51 UTC
Permalink
Wenn man bedenkt, dass C# einige Features besitzt, die Java
nicht bieten kann
»Guy Steele wrote:

Please remember that the design of a programming language
consists not just in a laundry list of features, but also
in making judicious choices of what to *omit* and, more
importantly, in establishing design principles that are
easy to understand.«

http://google.to/search?q=%22Please+remember+that+the+design+of+a+programming+language%22
und inzwischen auch auf vielen gängigen Platformen zur
Verfügung steht
»Today, with over 6 million developers (according to Sun)
Java clearly dominates the software development industry
[...] and [is ]perhaps the most successful software
development platform in the history of computing.«

http://apsblog.burtongroup.com/2007/11/why-microsoft-l.html

»3.3 billion Java devices worldwide«

http://web.archive.org/web/20060615162523/http://java.sun.com/javaone/sf/sessions/general/javacompatibility_thursday.jsp

»Java Swing with 47% use, has surpassed WinForms as the
dominant GUI development toolkit, an increase of 27% since
fall 2004.« (nach: Evans Data Corporation, Spring 2005
report)

http://weblogs.java.net/blog/hansmuller/archive/2005/10/official_swing.html

»Im Rahmen ihres regelmäßig erhobenen Marktmonitors
registrierte die Hamburger Auftragsbörse "projektwerk" zu
Beginn des zweiten Quartals wieder eine zunehmende
Nachfrage nach IT-Spezialisten - insbesondere
Java/J2EE-Experten wurden im April vermehrt gesucht.«

http://www.heise.de/newsticker/meldung/print/107475

»TIOBE Programming Community Index for January 2009 (November 2006)
Java 19.022% (20.400%)
C# 5.609% (3.023%) «

http://www.tiobe.com/content/paperinfo/tpci/index.html

(Einige der obigen Quellen findet man nur noch über
»archive.org«.)
Thomas Thiele
2009-01-13 19:57:57 UTC
Permalink
Post by Christian Franzen
Ich schreibe momentan mit ein paar Studienkollegen an einer
Seminararbeit, in der wir auf die Frage gestoßen sind, welche Gründe es
geben könnte, mit Java anstatt mit C# zu programmieren.
Dazu wurde schon was gesagt.
Mit C# habe ich nicht wirklich gearbeitet, weil ich es nicht gebraucht
habe. Insofern würde ich mich den meisten anschliessen und Java benutzen
weil ich es kann, schon immer so gemacht habe, da könnt ja jeder
kommen...;-)
C# macht aber einen durchdachteren Eindruck als Java.

Btw. C# spricht sich im Deutsch übrigens Cis und nicht C-scharp oder
C-raute. Weil es sich auf den Ton bezieht.
Post by Christian Franzen
gibt es eigentlich keinen Grund, warum man
einem Neuling sagen sollte: "Lern Java und nicht C#!". Wie seht ihr das?
Es gibt keinen Grund einen Neuling zu sagen, er solle als erste Sprache
Java lernen. Java ist für prozedurale Programmierung schlechter
geeignet, hat bei OOP Defizite und ist für andere Programmierparadigmen
gar nicht geeignet.
Als erste Sprache für ein konkretes Projekt, vielleicht ein bisschen GUI
ist sie ganz ok. Also lerning by doing. Ganz einfach weil der Support im
Netz der beste aller Sprachen ist.

Java spielt seine Stärken in großen Projekten aus. Für kleine Projekte
ist auch C++ besser geeignet, weil u.a. diverse Restriktionen nicht
bestehen. Oder eben Sprachen wie Python.

Um prozedurale Programmierung kennenzulernen für blutige Einsteiger
stört der OOO (Objektiorientierte Overhead) von Java.
In Python und C++ lässt man ihn einfach weg.
Für OOP bietet sich eine Sprache wie Smalltalk an. Oder wenn dann schon
C++, weil damit alle Konzepte der OOP umsetzbar sind.

Für private Projekte nehme ich fast immer Python. Es sei denn ich muss
C(++) aus irgendeinen Grund benutzen. Und da Java irgendwo in der Mitte
zwischen beiden liegt, gibt es privat für mich keinen Grund Java zu
benutzen. In der Firma sieht es anders aus. Sieht man von der
vorhandenen Java-Architektur und -Knowhow ab, würde ich bei größeren
Teams (>2 Personen) Java bevorzugen. Weil beide andere Sprachen die ich
sehr gut beherrsche zu viel Freiraum für Geschlumpere lassen.
Viel Freiheit - viel Verantwortung. Das ist hier genauso.
Und manche Menschen benötigen halt Ketten, Zwang und Vorschriften...

Die größte Gefahr besteht bei Java, ein Java-Scheuklappen-Programmierer
zu werden, der architekturelle Ansätze an der Machbarkeit in Java mist.
Und mulitiple Vererbung, Operatorüberladung und handgemachte
Speicherverwaltung für Teufelszeug hält, denn hätte Gott gewollt, dass
wir diese Dinge benutzen, hätte er sie ihn Java ja eingebaut...

Zu eurer Entscheidung: ich würde Java nehmen.
Christoph Herrmann
2009-01-13 20:12:34 UTC
Permalink
Post by Thomas Thiele
[...]
Zu eurer Entscheidung: ich würde Java nehmen.
Nach dem Text würde ich dir klar zu C# raten. Ordentliches OOP wie Java
(Interfaces etc.), in gewissen Bereichen besser umgesetzt (Events, using
Block etc.) und mehr Freiheiten (Operatorüberladungen, Zeiger etc.). ;)
--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Thomas Thiele
2009-01-13 20:14:20 UTC
Permalink
Post by Christoph Herrmann
Post by Thomas Thiele
Zu eurer Entscheidung: ich würde Java nehmen.
Nach dem Text würde ich dir klar zu C# raten. Ordentliches OOP wie Java
*ich* würde Java nehmen. An *meiner* Stelle, nicht an *deren* Stelle.
Bernd Hohmann
2009-01-13 20:28:34 UTC
Permalink
Post by Thomas Thiele
Java spielt seine Stärken in großen Projekten aus. Für kleine Projekte
ist auch C++ besser geeignet, weil u.a. diverse Restriktionen nicht
bestehen. Oder eben Sprachen wie Python.
Ich möchte an dieser Stelle vorsichtig darauf hinweisen, dass keine
Programmiersprache auf diesem unseren Planeten es unmöglich macht, damit
ganz winzigkleine und/oder ganz riessiggrosse Projekte abzuwickeln.

Und glaub es mir einfach, dass es mit Idealismus und Vorbildung durch
Hochschulen möglich ist, eine unwartbare Programmierung in
Markroassembler durch eine unwartbare Programmierung in einer beliebigen
"aktuelle Sau, die durchs Dorf getrieben wird"-Sprache zu ersetzen.

Es bleibt dabei, dass jede Sprache ihre Nischen hat wo sie sehr stark
ist und je mehr es zur allgemeinen Verwendung übergeht, jede Sprache
soweit an die Grenzen stösst, dass ein Wechsel notwendig ist.

Um ein konkretes Beispiel zu nennen: Die Logik eines 3D Actionshooters
kannst Du in C, C++, Java, COBOl, FORTRAN, FORTH, Assembler, ALGOL oder
PLANKALKÜL realisieren (selbst reine Interpretersprachen der ersten
Generation reichen dafür aus) - für die Grafikengine selber wirst Du
aber eine Sprache auswählen, die sich per Compiler sehr Hardwarenah
umsetzen lässt (C, C++, Fortran...).

Bernd
--
Well, there's egg and bacon; egg sausage and bacon; egg and
***@spamonly.de ; egg bacon and spam; egg bacon sausage
and ***@spamonly.net ; spam bacon sausage and spam;spam
egg spam spam bacon and ***@nixwill.de ; spam sausage
Lothar Kimmeringer
2009-01-14 12:25:28 UTC
Permalink
Post by Bernd Hohmann
Und glaub es mir einfach, dass es mit Idealismus und Vorbildung durch
Hochschulen möglich ist, eine unwartbare Programmierung in
Markroassembler durch eine unwartbare Programmierung in einer beliebigen
"aktuelle Sau, die durchs Dorf getrieben wird"-Sprache zu ersetzen.
A real programmer can write FORTRAN-programs in any language.


Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: ***@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
Daniel Urban
2009-01-14 11:50:26 UTC
Permalink
"Christian Franzen"
Post by Christian Franzen
Ich schreibe momentan mit ein paar Studienkollegen an einer
Seminararbeit, in der wir auf die Frage gestoßen sind, welche Gründe es
geben könnte, mit Java anstatt mit C# zu programmieren.
Hierzu wurde bereits eine Menge richtiges hier in der Gruppe geschrieben.
Aber noch einmal kurz die wichtigsten Punkte:

1. Kundenanforderung (keine echte Wahl)
2. Mit welcher Sprache lassen sich die Anforderungen besser umsetzen.

Wobei bei 2. immer der Aufwand mit zu berücksichtigen ist.
Einarbeitungsaufwand gegenüber Programmieraufwand mit ungeigneter Sprache.
Post by Christian Franzen
Wenn man
bedenkt, dass C# einige Features besitzt, die Java nicht bieten kann und
inzwischen auch auf vielen gängigen Platformen zur Verfügung steht
(außer vielleicht Handys),
C# Compact .NET gibt es auf PDA, MDA usw. bereits, auf echten Handys bisher
wohl nicht.
Post by Christian Franzen
gibt es eigentlich keinen Grund, warum man
einem Neuling sagen sollte: "Lern Java und nicht C#!". Wie seht ihr das?
Ein Neuling? Wenn er das professionell macht, dann wird der Rahmenplan
seines Ausbildungsplatzes oder des Studiums die Reihenfolge welche
Programmierparadigmen und mit welchen Sprachen man das macht wohl mehr ioder
weniger vorgeben.

Für jemanden, der das nur Hobby-mäßig macht, sollte die korrekte Wahl
zwischen C# und Java unwichtig zu sein. Münze werfen.

Gruß,

Daniel
Jochen Theodorou
2009-01-14 14:09:50 UTC
Permalink
Daniel Urban schrieb:
[...]
Post by Daniel Urban
Für jemanden, der das nur Hobby-mäßig macht, sollte die korrekte Wahl
zwischen C# und Java unwichtig zu sein. Münze werfen.
oder sich ein paayr Sachen überlegen, die er vielleicht mal so schreiben
will und Beispiele und Grndlagen dafür im Internet suchen. Was einen
besseren Eindruck macht, das nimmt man dann halt.

Gruss theo
Michael Bruschkewitz
2009-01-16 23:40:58 UTC
Permalink
Doku zu MS-Produkten generell sehr gut und leicht erfassbar.
Dadurch keine Zeitverschwendung bei Suche nach API-Details.
Klares Plus für C#/MS/Windows.

Plattform ganz klares Plus für Java, wie kompatibel/portabel ist Mono
eigentlich wirklich?

Ansonsten entscheidet Kunde.

Bei Wahlfreiheit würd ich sowieso C++ empfehlen.
Jochen Theodorou
2009-01-18 00:47:11 UTC
Permalink
Post by Michael Bruschkewitz
Doku zu MS-Produkten generell sehr gut und leicht erfassbar.
Dadurch keine Zeitverschwendung bei Suche nach API-Details.
Klares Plus für C#/MS/Windows.
Also ich würde mal sagen, dass was die API-Doku zu Java und C# angeht,
dass beides recht gut ist. Das Problem kommt wenn man Bibliotheken
Dritter einsetzen möchte. Und dass man das unter C#+Windows vielleicht
weniger schnell möchte, könnte man als Plus für C#/MS/Windows sehen.
Weil ja alles von einem Hersteller kommt funktionieren die Sachen auch
oft gut miteinander... dafür ist man dem einem Hersteller dann oft auch
auf Gedeih und Verderb ausgesetzt.
Post by Michael Bruschkewitz
Plattform ganz klares Plus für Java, wie kompatibel/portabel ist Mono
eigentlich wirklich?
gute Frage... Winforms soll ja angeblich laufen, es lassen sich also
bestimmt viele Dinge mit .Net machen, die auf zum Beipsiel Linux und
Windows laufen. .Net macht es in seiner Art dem Programmierer allerdings
sehr viel einfacher native Sachen einzubinden, was dann meist unter
Linux natürlich nicht tut. Ich denke die Verführung ist groß mal hier
und da eine spezielle Dll zu schreiben, weil etwas nicht schnell genug
ist oder so... Hat MS ja selbst vorgemacht wenn ich richtig gehört habe.
Post by Michael Bruschkewitz
Ansonsten entscheidet Kunde.
fast immer ;)
Post by Michael Bruschkewitz
Bei Wahlfreiheit würd ich sowieso C++ empfehlen.
ehrlich gesagt ist mir auf dem Level C sympatischer.... aber gut...
diese Diskussion brauchen wir hier jetzt nicht zu führen denke ich ;)


Gruss theo
Michael Rauscher
2009-01-19 03:51:01 UTC
Permalink
Post by Michael Bruschkewitz
Doku zu MS-Produkten generell sehr gut und leicht erfassbar.
Wie unterschiedlich die Ansichten doch sein können ;)

Da es aber um C# (und damit wohl auch mehr oder weniger um .NET) ging
habe ich mir eben - nur ganz kurz - die .NET-Doku am Beispiel von
DateTime angeschaut und muss sagen, dass diese zumindest auf den ersten
Blick ganz ordentlich aussieht. Wobei mir gleich ein paar Dinge
aufgefallen, die ich nicht gut finde.

Erstens: "Stellt einen Zeitpunkt dar, der normalerweise durch Datum und
Uhrzeit dargestellt wird." ?!?

Ich musste den Satz erst ein paar mal lesen, um zu verstehen, was
gemeint ist. Das muss ich relativieren: Zumindest glaube ich zu ahnen,
welche der Interpretationsmöglichkeiten gemeint sein könnte...

Zweitens interessieren Werbeaussagen wie "bietet ... ein Hohes Maß an
Flexibilität" niemanden - zumindest nicht mich.

Drittens, was soll die Prosa über "implementierte Schnittstellen"?

Viertens: warum muss es mich interessieren, ob ein DateTime ein
64-Bit-Feld enthält, das aus einem privaten Kind-Feld und dem Ticks-Feld
zusammengesetzt ist? Warum muss es mich interessieren, wie DateTime
intern arbeitet?

Dann diese ewigen Beispiele. Man wird das Gefühl nicht los, man versucht
in die Doku gleich noch einen Anfängerkurs mit einzubauen. Manchmal ist
weniger halt mehr.

Allerdings sollte man es damit nicht übertreiben, wie diese seltsame
Doku zeigt, die Access mitbringt. Da ist auch viel Blabla dabei dennoch
kann man sich gleichzeitig glücklich schätzen, wenn man nach Lesen der
Dokumentation tatsächlich weiß, was die Funktion eigentlich macht bzw.
was man zurückbekommt o.ä. Von den ständigen Umleitungen ganz zu schweigen.

Natürlich gibt es auch bei der Java Dokumentation Kritikpunkte. Trotzdem
gefällt mir persönlich die Sun Doku insgesamt wesentlich besser. Kurz &
bündig.

Objektive Punktevergabe dürfte jedoch nie möglich sein. Ich kenne
einige, denen die MS Doku besser gefällt.

Gruß
Michael
Stefan Ram
2009-01-19 05:05:23 UTC
Permalink
Post by Michael Rauscher
Erstens: "Stellt einen Zeitpunkt dar, der normalerweise durch Datum und
Uhrzeit dargestellt wird." ?!?
Ich musste den Satz erst ein paar mal lesen, um zu verstehen, was
gemeint ist.
Es handelt sich um eine Verbalphrase, aber nicht um einen Satz;
dazu fehlt ihr das Subjekt.

In technischen Zusammenhängen treten stilistische Fragen, wie
die Vermeidung von Wortwiederholungen (hier: »darstellen«), in
den Hintergrund. Daher würde ich die Wiederholung von
»darstellen« zunächst nicht beanstanden, /wenn/ das wirklich
so gemeint ist. Da mir hier der Zusammenhang fehlt, kann ich
das letztere jetzt nicht beurteilen.

Im allgemeinen ist auch nicht ganz klar, was das Verb
»darstellen« genau bedeuten soll. Aber wahrscheinlich ist hier
die Beziehung zwischen einer Wert außerhalb der
Programmiersprache und seiner Darstellung innerhalb der
Programmiersprache gemeint. Etwa wie in: »Die ganze Zahl "2"
(ein mathematischer Begriff) kann in Java durch den int-Wert
"2" dargestellt werden (oder aber auch durch den short-Wert "2").«

Der Zeitpunkt, zu dem zum ersten Mal ein Mensch seinen Schuh
auf den Mond setzte, ist zunächst ein Begriff außerhalb der
Programmiersprache C#. Er kann aber vielleicht durch ein
bestimmtes C#-Objekt /dargestellt/ werden. Und solche ein
Zeitpunkt wird in unserem Kulturbereich normalerweise durch
Datum und Uhrzeit /dargestellt/ (plus Zeitzone):
»21. Juli 1969, 3.56 Uhr MEZ«. So gesehen ist die Verwendung
von »darstellen« doch akzeptabel.
Post by Michael Rauscher
Zweitens interessieren Werbeaussagen wie "bietet ... ein Hohes
Maß an Flexibilität" niemanden - zumindest nicht mich.
Es handelt sich weniger um eine Aussage (da die vorkommenden
Begriffe dazu nicht ausreichend scharf definiert sind),
sondern eher um einen Ausdruck von Emotionen oder ähnlichen
Phänomenen.
Post by Michael Rauscher
Drittens, was soll die Prosa über "implementierte Schnittstellen"?
Das ist für Leser Deines Postings schwer zu sagen, wenn sie
den Zusammenhang nicht kennen.
Post by Michael Rauscher
Dann diese ewigen Beispiele. Man wird das Gefühl nicht los, man
versucht in die Doku gleich noch einen Anfängerkurs mit
einzubauen. Manchmal ist weniger halt mehr.
Es gab von Sun Microsystems, Inc. einmal eine Aussage, nach
der Dokumentation keine Beispiele enthalten sollte. Leider
konnte ich diese später nicht mehr finden. Ich hätte sie sonst
ganz gerne einmal der folgenden Aussage gegenübergestellt, die
ich auf einer Webseite las und hier nach dem Gedächtnis zitiere:

»If it doesn't contain examples,
it is not documentation.«

Aber das habe ich mir wohl nicht ganz wörtlich gemerkt.
Das Original lautet wohl so:

»Can we stop pretending? Can you just mark everything as
undocumented until you get around to writing real
documentation for it? Maybe even include a "Click here to
vote to have this documented."

For a simple test, if it doesn't include a code example,
it's not documented. Just mark it as such and move on.«

http://www.codinghorror.com/blog/archives/000451.html

Ja, das sind wohl zwei diametral unterschiedliche Auffassungen
über Beispiele in Dokumentationen.

Auf einer Web-Seite von Sun Microsystems, Inc. finde ich immerhin:

»What separates API specifications from a programming
guide are examples, definitions of common programming
terms, certain conceptual overviews (such as metaphors),
and descriptions of implementation bugs and workarounds.«

http://java.sun.com/j2se/javadoc/writingdoccomments/

Demnach unterscheidet sich ein Programmierführer von einer
API-Spezifikation (Dokumentation) dadurch, daß er Beispiele
(und anderes) enthält. Das geht etwas in die Richtung zu
sagen, daß Dokumentation keinen Beispiele enthalten sollte.
Post by Michael Rauscher
Natürlich gibt es auch bei der Java Dokumentation Kritikpunkte.
Trotzdem gefällt mir persönlich die Sun Doku insgesamt
wesentlich besser. Kurz & bündig.
Die C#-Dokumentation kenne ich nicht. Aber ich weiß, daß
JavaDoc und die API-Spezifikation von Java oft selbst von
denen gelobt wird, die Java sonst nichts abgewinnen können.

Karsten Wagner schreibt beispielsweise in seinem Blog:

»So the real reason why I switched over to Java was not
the language itself, it was the combination of the
language, the IDE and the available, well documented and
comprehensive libraries.«
Bernd Eckenfels
2009-01-19 05:18:26 UTC
Permalink
Post by Stefan Ram
Post by Michael Rauscher
Erstens: "Stellt einen Zeitpunkt dar, der normalerweise durch Datum und
Uhrzeit dargestellt wird." ?!?
Im allgemeinen ist auch nicht ganz klar, was das Verb
»darstellen« genau bedeuten soll.
Ich finde die MS Doku generell ganz gut, aber Deutsch habe ich die noch nie beachtet. In dem Fall nehme ich mal an es hiess "represented" im Englischen. Den Satz kann ich allerdings auch nur in einer Form parsen:

"Ein Zeitpunkt wird mittels Datum und Uhrzeit repräsentiert."
Post by Stefan Ram
Post by Michael Rauscher
Drittens, was soll die Prosa über "implementierte Schnittstellen"?
Das ist für Leser Deines Postings schwer zu sagen, wenn sie
den Zusammenhang nicht kennen.
In der MS Doku werden generell Aufzählungen oft als Sätze repräsentiert
(sic!) das ist (da es sehr auffällig ist) anscheinend eine Art Policy.

Gruss
Bernd
Michael Rauscher
2009-01-19 07:17:16 UTC
Permalink
Post by Stefan Ram
Post by Michael Rauscher
Erstens: "Stellt einen Zeitpunkt dar, der normalerweise durch Datum und
Uhrzeit dargestellt wird." ?!?
Ich musste den Satz erst ein paar mal lesen, um zu verstehen, was
gemeint ist.
Es handelt sich um eine Verbalphrase, aber nicht um einen Satz;
dazu fehlt ihr das Subjekt.
Dann musste ich halt die Verbalphrase ein paar mal lesen :)

Allerdings, und das habe ich stillschweigend weggelassen, steht die
Phrase direkt unter der Überschrift "DateTime", so dass sich insgesamt
der Satz

"DateTime stellt einen Zeitpunkt dar, der normalerweise durch Datum und
Uhrzeit dargestellt wird"

lesen lässt.
Post by Stefan Ram
In technischen Zusammenhängen treten stilistische Fragen, wie
die Vermeidung von Wortwiederholungen (hier: »darstellen«), in
den Hintergrund. Daher würde ich die Wiederholung von
»darstellen« zunächst nicht beanstanden, /wenn/ das wirklich
so gemeint ist. Da mir hier der Zusammenhang fehlt, kann ich
das letztere jetzt nicht beurteilen.
Es ging mir nicht um die Wiederholung, sondern um die Aussage der
Verbalphrase (ich kipp vom Stuhl). Diese kann ich wie folgt interpretieren:

1. DateTime stellt einen Zeitpunkt dar, der ohne Verwendung von DateTime
mit Uhrzeit und Datum angegeben werden würde.

2. DateTime stellt einen Zeitpunkt dar, der durch Ausgabe von Datum
und/oder (normalerweise und) Uhrzeit angezeigt wird.

3. DateTime stellt einen Zeitpunkt dar. Die Angabe dieses Zeitpunkts
erfolgt in der Regel durch Datum und Uhrzeit (es reicht aber auch Datum
oder Uhrzeit)

Die englische Dokumentation lautet übrigens

"Represents an instant in time, typically expressed as a date and time
of day."

Allerdings geht es mir gar nicht so sehr um die konkrete Bedeutung. Mir
ist der Satz nur aufgefallen, weil die Aussage für mich nicht sofort und
unmissverständlich ersichtlich ist. Zuerst irritierte mich
"normalerweise". Und das war auch der Grund, warum ich mir die Phrase
genauer angesehen habe.

Aus *meiner* Sicht seltsam geschriebene Phrasen, Sätze und Ausdrücke
können nicht zu einer positiven Bewertung *meinerseits* beitragen.
Post by Stefan Ram
Post by Michael Rauscher
Zweitens interessieren Werbeaussagen wie "bietet ... ein Hohes
Maß an Flexibilität" niemanden - zumindest nicht mich.
Es handelt sich weniger um eine Aussage (da die vorkommenden
Begriffe dazu nicht ausreichend scharf definiert sind),
sondern eher um einen Ausdruck von Emotionen oder ähnlichen
Phänomenen.
Mich interessiert auch kein "Ausdruck von Emotionen oder ähnlichen
Phänomenen" in der Dokumentation.
Post by Stefan Ram
Post by Michael Rauscher
Drittens, was soll die Prosa über "implementierte Schnittstellen"?
Das ist für Leser Deines Postings schwer zu sagen, wenn sie
den Zusammenhang nicht kennen.
Den Zusammenhang meinte ich bereits gegeben zu haben: Dokumentation von
DateTime (MS .NET-Framework).

Hier der Auszug:

Implementierte Schnittstellen

Dieser Typ implementiert die Schnittstellen IComparable, IComparable,
IFormattable und IConvertible. Verwenden Sie für Konvertierungen die
Convert-Klasse anstelle der expliziten Implementierung der
Schnittstellenmember der IConvertible-Schnittstelle für diesen Typ.

Bernd hat übrigens recht: das zieht sich durch die gesamte
Dokumentation. Auch die Schnittstellen implementierenden Klassen werden
brav in einem Satz zusammengefasst :)
Post by Stefan Ram
Post by Michael Rauscher
Dann diese ewigen Beispiele. Man wird das Gefühl nicht los, man
versucht in die Doku gleich noch einen Anfängerkurs mit
einzubauen. Manchmal ist weniger halt mehr.
Es gab von Sun Microsystems, Inc. einmal eine Aussage, nach
der Dokumentation keine Beispiele enthalten sollte. Leider
konnte ich diese später nicht mehr finden. Ich hätte sie sonst
ganz gerne einmal der folgenden Aussage gegenübergestellt, die
»If it doesn't contain examples,
it is not documentation.«
Aber das habe ich mir wohl nicht ganz wörtlich gemerkt.
...
Post by Stefan Ram
Ja, das sind wohl zwei diametral unterschiedliche Auffassungen
über Beispiele in Dokumentationen.
Ich habe nichts gegen Beispiele, so lange sie dem Zweck der
Dokumentation dienen. Ich brauche aber doch nicht in jeder Klasse ein
Beispiel, wie ich ein Objekt der Klasse erzeuge. Das gehört in ein Buch
der jeweiligen Sprache aber doch nicht in die API-Doku.

Der Link von Dir zeigt das, was ich meine: viel Geschriebenes und
trotzdem wenig Info. Das hat aber nichts mit fehlenden Beispielen zu
tun, sondern mit schlechten Aussagen.

IBindingList.AddIndex:

Adds the PropertyDescriptor to the indexes used for searching.

An sich eine einfache Aussage. Aber von welchen "indexes" ist die Rede?
Man möchte meinen, man findet die Antwort daruf in der Typdoku von
IBindingList aber: ?!?

Naja, Microsoft hat ja Beispiele für diese Situationen:

// Unsupported Methods.
void IBindingList.AddIndex(PropertyDescriptor property)
{
throw new NotSupportedException();
}

ROTFL. SCNR.
Post by Stefan Ram
Post by Michael Rauscher
Natürlich gibt es auch bei der Java Dokumentation Kritikpunkte.
Trotzdem gefällt mir persönlich die Sun Doku insgesamt
wesentlich besser. Kurz & bündig.
Die C#-Dokumentation kenne ich nicht. Aber ich weiß, daß
JavaDoc und die API-Spezifikation von Java oft selbst von
denen gelobt wird, die Java sonst nichts abgewinnen können.
Das kann ich durchaus verstehen.

Gruß
Michael
Michael Bruschkewitz
2009-01-19 09:26:03 UTC
Permalink
Hallo Michael,
Post by Michael Rauscher
Implementierte Schnittstellen
Dieser Typ implementiert die Schnittstellen IComparable, IComparable,
IFormattable und IConvertible. Verwenden Sie für Konvertierungen die
Convert-Klasse anstelle der expliziten Implementierung der
Schnittstellenmember der IConvertible-Schnittstelle für diesen Typ.
Bernd hat übrigens recht: das zieht sich durch die gesamte Dokumentation.
Auch die Schnittstellen implementierenden Klassen werden brav in einem
Satz zusammengefasst :)
Das liest sich halt besser, solange Hyperlinks drin sind, ist es doch gut.
Hast Du schon mal eine 200-seitige API-Doku reviewt?
Wenn dort nur Tabellen und Funktionsdefinitionen drin sind, geht die
Aufmerksamkeit spätestens ab Seite 100 gegen Null.
(Steht da wirklich 2x IComparable? Dann schreib ein Feedback, angeblich
werden Änderungen und akzeptierte Wünsche auch kurzfristig eingearbeitet.)
Post by Michael Rauscher
Ich habe nichts gegen Beispiele, so lange sie dem Zweck der Dokumentation
dienen. Ich brauche aber doch nicht in jeder Klasse ein Beispiel, wie ich
ein Objekt der Klasse erzeuge. Das gehört in ein Buch der jeweiligen
Sprache aber doch nicht in die API-Doku.
Die Beispiele in der Online-Doku kannst Du sehr gut verwenden, um
Codefragmente in Deinen Quelltext einzuarbeiten.
Das geht auf jeden Fall schneller und besser, als sie aus dem Buch
abzutippen.
Schliesslich kostet die Anzeige der Bsp. fast nichts, ggf. kannst Du sie ja
ausblenden.
Post by Michael Rauscher
Der Link von Dir zeigt das, was ich meine: viel Geschriebenes und trotzdem
wenig Info. Das hat aber nichts mit fehlenden Beispielen zu tun, sondern
mit schlechten Aussagen.
Adds the PropertyDescriptor to the indexes used for searching.
An sich eine einfache Aussage. Aber von welchen "indexes" ist die Rede?
Man möchte meinen, man findet die Antwort daruf in der Typdoku von
IBindingList aber: ?!?
// Unsupported Methods.
void IBindingList.AddIndex(PropertyDescriptor property)
{
throw new NotSupportedException();
}
ROTFL. SCNR.
Die Sprache ist halt noch relativ neu. Entweder ist die Funktion bereits für
zukünftige Versionen angedacht oder bereits veraltet.
Oder vorhanden/möglich in von IBindingList abgeleiteten Schnittstellen.
Oder der Doku-Schreiber faul/nicht ausreichend kompetent. Soll ja vorkommen.

Aber: Warum Java und nicht C#?

Gruß
Michael
Michael Rauscher
2009-01-19 09:52:29 UTC
Permalink
Hallo Michael,
Post by Michael Bruschkewitz
Post by Michael Rauscher
Dieser Typ implementiert die Schnittstellen IComparable, IComparable,
...
Post by Michael Bruschkewitz
Post by Michael Rauscher
Bernd hat übrigens recht: das zieht sich durch die gesamte Dokumentation.
Auch die Schnittstellen implementierenden Klassen werden brav in einem
Satz zusammengefasst :)
Das liest sich halt besser, solange Hyperlinks drin sind, ist es doch gut.
Wie ich eingangs schon schrieb: wir haben eben unterschiedliche
Auffassungen. Das ist OK. Ich komme mit der MS-Doku nicht so gut
zurecht, wie mit der Java-Doku.
Post by Michael Bruschkewitz
(Steht da wirklich 2x IComparable? Dann schreib ein Feedback, angeblich
werden Änderungen und akzeptierte Wünsche auch kurzfristig eingearbeitet.)
Ja, das steht da tatsächlich. Wär mir nicht mal aufgefallen :) Wie
geschrieben: ich hab das Zeug nur überflogen.
Post by Michael Bruschkewitz
Post by Michael Rauscher
Ich habe nichts gegen Beispiele, so lange sie dem Zweck der Dokumentation
dienen. Ich brauche aber doch nicht in jeder Klasse ein Beispiel, wie ich
ein Objekt der Klasse erzeuge. Das gehört in ein Buch der jeweiligen
Sprache aber doch nicht in die API-Doku.
Die Beispiele in der Online-Doku kannst Du sehr gut verwenden, um
Codefragmente in Deinen Quelltext einzuarbeiten.
Ja - gehört für meinen Geschmack trotzdem nicht in die Doku. In 99 % der
Fälle will ich was wissen und nicht was kopieren, was ich sonst abtippen
müsste.

[Behandlung von IBindingList und IBindingList.AddIndex]
Post by Michael Bruschkewitz
Die Sprache ist halt noch relativ neu. Entweder ist die Funktion bereits für
zukünftige Versionen angedacht oder bereits veraltet.
Mir geht's auch nicht darum, MS-Doku schlechter zu machen als sie ist.
Das Beispiel mit AddIndex stammt übrigens nicht von mir, ich habe es nur
aufgegriffen.
Post by Michael Bruschkewitz
Oder vorhanden/möglich in von IBindingList abgeleiteten Schnittstellen.
Oder der Doku-Schreiber faul/nicht ausreichend kompetent. Soll ja vorkommen.
Aber: Warum Java und nicht C#?
Um das beurteilen zu können müsste ich C# lernen (nicht Oberflächlich
sondern richtig). Von der Doku her würde ich zu Java tendieren.

Gruß
Michael
Michael Bruschkewitz
2009-01-19 08:49:19 UTC
Permalink
Post by Michael Rauscher
Post by Michael Bruschkewitz
Doku zu MS-Produkten generell sehr gut und leicht erfassbar.
Wie unterschiedlich die Ansichten doch sein können ;)
Die Doku zu Solaris ist auch sehr gut. (Zumindest als es noch nicht "Open"
war.)
Post by Michael Rauscher
...
Ich musste den Satz erst ein paar mal lesen, um zu verstehen, was gemeint
ist. Das muss ich relativieren: Zumindest glaube ich zu ahnen, welche der
Interpretationsmöglichkeiten gemeint sein könnte...
Man muss nicht alles zu 100% verstehen, um es nutzen zu können.
Post by Michael Rauscher
Zweitens interessieren Werbeaussagen wie "bietet ... ein Hohes Maß an
Flexibilität" niemanden - zumindest nicht mich.
Kann auch als Hinweis gesehen werden, sich ggf. mit den Möglichkeiten
ausgiebiger zu beschäftigen.
Post by Michael Rauscher
...
Viertens: warum muss es mich interessieren, ob ein DateTime ein
64-Bit-Feld enthält, das aus einem privaten Kind-Feld und dem Ticks-Feld
zusammengesetzt ist? Warum muss es mich interessieren, wie DateTime intern
arbeitet?
Weil es etwas über die Granularität, Wertebereich und Genauigkeit der
Abbildung aussagt. Aber das muss Dich nicht interessieren; wenn Du solche
Frage stellst, willst Du wohl eher ein Geburtsdatum o.Ä. verarbeiten, da ist
es wahrscheinlich irrelevant.
Post by Michael Rauscher
Dann diese ewigen Beispiele. Man wird das Gefühl nicht los, man versucht
in die Doku gleich noch einen Anfängerkurs mit einzubauen. Manchmal ist
weniger halt mehr.
Die Win-API (inkl. angrenzende) ist so gross, dass mit ziemlicher Sicherheit
jeder bei mindestens 90% der API-Funktionen Anfänger ist.
Das ist auch in Java so, ebenso bei den verschiedenen Linux-API.
Und das ändert sich auch nicht nach 20 Jahren Programmiererfahrung, da neue
APIs ständig dazukommen.

Und bei einem Stundensatz von 60 Eu ist ein Tag Suche nach passender Doku
die Monatsmiete der Dienstwohnung, welche man zum Fenster hinauswirft.
Post by Michael Rauscher
Allerdings sollte man es damit nicht übertreiben, wie diese seltsame Doku
zeigt, die Access mitbringt. Da ist auch viel Blabla dabei dennoch kann
man sich gleichzeitig glücklich schätzen, wenn man nach Lesen der
Dokumentation tatsächlich weiß, was die Funktion eigentlich macht bzw. was
man zurückbekommt o.ä. Von den ständigen Umleitungen ganz zu schweigen.
Die Doku in Office ist für die Office-Entwickler gedacht. Die verstehen das
auch.
Wenn Du Jahre C++ und verschiedene andere Sprachen entwickelt hast, hast Du
natürlich einen anderen Blick.
Post by Michael Rauscher
Post by Michael Bruschkewitz
Natürlich gibt es auch bei der Java Dokumentation Kritikpunkte. Trotzdem
gefällt mir persönlich die Sun Doku insgesamt wesentlich besser. Kurz &
bündig.
Solange Dir das reicht.
Lesen Sie weiter auf narkive:
Loading...