Lokführer - Fahrdienstleiter & ZUSI 3.0

[r.h.]

Java und VB sind Tools der Klasse "Rapid Prototyping", ideal um mal eben einen horizontal prototype zu generieren - dann drag and drop ja sehr einfach. Wenn es performant werden soll ist man mit C/C++ doch besser beraten.
Oli

Meinst Du, in der Welt von Java gibt es nur Visuelle Editoren? Schau Dich doch mal nach J2EE um und verate mir, wo dort mit Java NUR geprototypt wird.

Auch VB wird in vielen Bereichen ernsthaft eingesetzt. Es gibt viele Medizin-Applikationen die mit VB entwickelt worden. Einige Anbieter von Steuerungen für Industriemaschinen schwören auf VB für die Oberflächenprogrammierung dank seiner Fähigkeiten zur OCX-Kommunikation. Und gerade in diesen Beispielen ist Performance schon ein Schlag(kräftiges)wort.

C/C++ hat klare Performance-Vorteile. Aber auch hier gilt, daß man diese erstmal kennen und auch effektiv umsetzen sollte. Ansonsten kann ein C++ Programm noch viel lahmer werden, als ein Java-Programm. Es ist alles eine Frage der Erfahrung!

Und - um mal polemisch zu werden - C bzw. auch C++ ist auch die typische Programmiersprache für die Pragmatiker: Hauptsache mal schnell das Feature zum laufen gebracht - mir doch egal ob in zwei Jahren noch jemand meinen Code zwecks Fehlersuche verstehen muß.

In diesem Sinne,
r.

[Roland Ziegler]

Feine Diskussion. Ich auch jetzt Senf dazugeben:

Im professionellen Bereich ist Delphi ein ziemlicher Exot. In den späten 80ern und frühen 90ern wurde auf der PC-Plattform unter 16bit viel mit Turbo-Pascal gemacht. aber seitdem höre ich in meinem beruflichen Umfeld den Namen Borland praktisch kaum noch. Wegen seines proprietären Charakaters ist Delphi diesbezüglich wohl mit VB(6) vergleichbar. Aber VB ist trotz maximaler Plattform- und Herstellerabhängigkeit doch die am meisten verbreitete Programmiersprache.

Bei uns dominieren C++ und Java.

Java hat allgemeine Vor- und Nachteile. Es ist für die Mehrzahl der Entwickler einfacher zu nutzen, bei anderen aber aufgrund seines Konzeptes (z.B. eben keine Mehrfachvererbung, oder keine Destruktoren) nicht sehr beliebt. Java-Anwendungen sind zudem häufig ziemlich ressourenfressend.

Java ist per se plattformunabhängig, sicher ein Vorteil. Bei C++ benötigt man dafür Middleware, aber dann hat man Plattformunabhängigkeit auch dort. Aber C++ ist was für Profis. Wer z.B. nicht zwischen Shallow- und Deep-Copies unterscheiden will oder kann, der sollte die Finger davon lassen. Und natürlich programmiert der C++-Entwickler mit Templates und der STL. Da aber viele Java-Entwickler, die mal bei C++ reingeschaut haben, gar nicht mit den Feinheiten in Berührung kamen, fehlten ihnen die Templates z.B. nicht, sie kannten sie einfach nicht.

Java und C++ besitzen aber leider keine Schnittselle untereinander, die den Namen verdient. Wir nehmen deshalb dafür CORBA.

Innerhalb der .Net-Sprachen ist das ganz eindeutig anders, ein wesentlicher Aspket bei .Net.

C# ist die modernere Ausgabe von Java, sehr ähnlich, etwas konsistenter und einheitlicher im Guss und bietet mit voll durch konzipierten Generics bei Templates mehr als das halbherzige Java mit 1.5 - auf Kosten einer Inkompatibilität. Die .Net-Library kann hingegen z.B. bei Collections nicht mit Java mithalten. Das Konzept der Collections, sofern man von einem Konzept sprechen kann, erinnert an Borland oder MFC. Die C++ STL legt die Latte vielleicht recht hoch, aber man gewöhnt sich dran.

C# und .Net haben zudem den gemeinsamen Nachteil unter Unix nur beschränkt verfügbar zu sein. Wenn das aber kein Problem ist, dann kann man wunderschöne Anwendungen z.B. mit Delphi-Net, native C++, Managed C++ und C# zusammenbauen, mit OO-Schnittstellen zwischen den Sprachen, die man fast gar nicht spürt.

Ich selbst bin bekanntlich massiver C++-Anhänger. Meine bisherigen Java- und C#-Ausflüge waren durchaus nett. Sie beschränkten sich glücklicherweise auf einfache Dinge, bei denen der Rapid-Aspekt zum Tragen kam, aber mir fehlte einfach die Flexibilität und Universalität von C++.

Ach, noch was. Java und C# sind beschränkte Sprachen, im positiven Sinne. Deswegen sind z.B. Refactoring in der IDE oder UML Code-Generierung damit wesentlidh einfacher als bei den Klassikern.

[Carsten Hölscher]

also nichts gegen eine Diskussion, aber muß es gleich ins persönliche gehen?

Carsten

[Christopher Spies]

Und - um mal polemisch zu werden - C bzw. auch C++ ist auch die typische Programmiersprache für die Pragmatiker: Hauptsache mal schnell das Feature zum laufen gebracht - mir doch egal ob in zwei Jahren noch jemand meinen Code zwecks Fehlersuche verstehen muß.

Auch in Java kann man Code schreiben, den in 2 Jahren keiner mehr versteht, genau wie in jeder anderen Sprache. Eine neue Sprache ist niemals ein Allheilmittel gegen schlechte Software.

also nichts gegen eine Diskussion, aber muß es gleich ins persönliche gehen?

So ist das ja immer -- ein Glaubenskrieg eben (genau wie beim Thema Betriebssysteme).
Ich hatte nicht damit gerechnet, hier auf derart viele IT-Profis zu stoßen...

- Christopher

[Daniel Rüscher aka Merlin]

Hier is durchaus Fachwissen aus allen Bereichen vorhanden, und davon nich zu wenig...

[Roland Ziegler]

Pragmatismus hat übrigens auch was mit Wirtschaftlichkeit zu tun. Auftragsarbeiten ohne spezielle Anforderungen, wie z.B. realtime nahe Sachen, sind an mancher Stelle durchaus billiger mit Java als mit C++ zu machen.

Wenn allerdings jemand auf die Idee kommt, eine Telefonvermittlung in Java zu realisiern, und dann mit der Totalblockade durch Garbage-Collection in Konflikt gerät, dann ist ihm wohl nicht mehr zu helfen.

Seit ich diese Geschichte und die eher hilflosen Versuche, die GC-Probleme in den Griff zu bekommen, ausgerechnet bei Sun lesen durfte, sehe ich die scheinbaren Vorteile solcher speicherselbstverwaltenden Systeme sehr nüchtern.

Aber trotzdem: Hat man eine durchschnittliche Aufgabe und durchschnittliche Programmierer, wird das Ergebnis in Java (oder C#) wohl den Wunschvorstellungen am weitesten entgegenkommen.

Unlesbaren Code kann man in der Tat in jeder Sprache produzieren. Die Erfahrung sagt mir, dass am unteren Ende meist VB rangiert. Das hat nur bedingt mit der Sprache zu tun.

PS: Gerade eine kleine Gateway-Klasse in C++ implementiert, die Mehrfachvererbung nutzt. 5 verschiedene Basisklassen. Im Prinzip alles nur Schnittstellen, mit aber von mir direkt genutzter Basisfunktionalität. Würde in Java oder C# nur per Delegation zu machen sein.

[Carsten Hölscher]

ähm, bevor es zu Mißverständnissen kommt, mein Beitrag da oben hatte sich mit Rolands überschnitten.

Carsten

[Roland Ziegler]

War zumindest mir durchaus klar, hatte Deinen Beitrag auch nicht auf meinen bezogen.

[r.h.]

also nichts gegen eine Diskussion, aber muß es gleich ins persönliche gehen?

Carsten

Ersetze "Du" durch "Man" in meinem Beitrag und habe bitte Verständnis für den ursprünglichen Schnellschuß.

Ich führe diese Diskussion nun schon seit etlichen Jahren mit wechselnden Gesprächspartnern. Leider haben viele dieser Gesprächspartner in der Tiefe der Materie keine Ahnung, brüskieren sich aber lautstark gegen eine bestimmte Sprache.

Roland hat wie damals auch schon, zwei Nachteile (Clone-Problem, GC-Problem) aus tiefem Fachwissen von der Materie angeführt, wohin gegen andere das Argument des "Spielzeugs" anführten, was so nicht stehen bleiben darf.

Ich habe für mich vor 4 Jahren meine Entscheidung pro Java getroffen, nachdem ich mit fast allen Programmiersprachen weitergehende Erfahrungen gesammelt habe, die über einfaches "mal damit programmieren" weit hinaus gehen. Noch heute benutze ich jedoch noch viele weitere Sprachen, sei es Perl für CGIs, Delphi um Wartungsarbeiten an meinen früheren Produkten vorzunehmen oder C und Assembler um Mikrocontroller zu programmieren (Naja, das Basic für meinen alten 8bitter vernachlässige ich mal...)

Beruflich habe ich an der Erstellung eines CASE-Tools mitgearbeitet, welches - zwangsweise - die Feinheiten der einzelnen Sprachen berücksichtigen mußte.

Immer und immer wieder geraten in diese Diskussion die polemischen Ausdrücke "Java sei langsam", "Delphi ist eine Click-Sprache" oder "C ist so super toll". Ohne daß mal jemand den Versuch unternimmt, diese Argumente zu untermauern.

Ich warte bis heute darauf, daß mir jemand einen Benchmark eines komplexen Algorithmus vorlegt (also nicht nur eine einfache Zählschleife), aus dem man tatsächlich - praxisrelevant!!! - herauslesen kann, daß Java langsam sei und der Geschwindigkeitsvorteil anderer Programmiersprachen nicht durch weitere Argumente für Java wettgemacht werden kann.

Irgendwann hat man dann langsam, ehrlich gesagt, die Schnauze voll, immer wieder von 13-17jährigen Bubis lesen zu müssen, wie toll sie die ein oder andere Sprache finden und sich "Programmierer" oder noch schlimmer "Entwickler" schimpfen, weil sie mal ein Start-Menü-Programm mit Delphi zusammen geclickt haben.

Ich denke, es ist offensichtlich:

Roland verdient sein Geld mit C(++)-Programmierung
Carsten mit Delphi
und ich mit Java/J2EE

Als Schüler/Student sollte man sich an so einer Diskussion ohne entsprechendes Fachwissen gar nicht erst beteiligen oder wenigstens diese Allerweltsunweißheiten sein lassen.

Danke, sagt entnervt
Robert

PS: An alle, die nochmal mit dem Spielzeug- oder "Schnell mal was programmieren" - Argument kommen, verweise ich auf die vielen Firmen, die ihre proprietären C-Anwendungen heute massenweise auf die Java-Platform oder .net-Platform migrieren! M7N ist schließlich nicht umsonst das in Geschäftsberichten meißtgelesenste Wort!

[Roland Ziegler]

Java und "Spielzeug" würde in der Tat deutlich am tatsächlichen Sachverhalt vorbeigehen.

Nicht zufällig habe ich einem der vorigen Postings das Wort "nett" gebraucht. In sehr weitem Bereich ist der Umgang mit Java ausgesprochen straightforward und angenehm. Und wer sauber OO lernen will, ist mit Java oder C# zunächst aus meiner Einschätzung besser bedient als mit C++ (oder mit Delphi).

Dass die hohe Wissenschaft in der Informatik durchaus kräftig mit Java beschäftigt ist, hat direkt wieder mit der Klarheit, Eindeutigkeit und Umgrenztheit der Sprache zu tun (würde für C# genauso gelten).

Spannend wird das neue C++ .Net. Managed C++ hat mich nicht überzeugen können. Funktioniert und ist dadurch schon wichtig als Kapselung für native C++, aber nichts, was man sich freiwillig antut. Die Überarbeitung, die ja zur Standardisierung vorliegt, sieht sehr viel sauberer aus (bleibt aber natugemäß komplexer als C#)

@Robert: Original-C (ohne ++) versuche ich nach Möglichkeit zu vermeiden. Ich habe zwar damals den Umstieg von Pascal zu C vollzogen, aber nach einem großen Projekt in C danach C mit C++ ersetzen können.

Übrigens: Recht verrufen sind sogenannte "MFC-Programmierer". MFC ist ein Framework von MS, um die Win32-Schnittstelle insbesondere beim direkten Windows-Handling mit C++ zu kapseln. MFC ist aber recht komplex geraten und ziemlich überladen, z.B. auch durch das dort mit reingebrachte Model-View-Controller Pattern (Document/View-Architecture). Der gewöhnliche "MFC-Programmierer" zeichnet sich leider häufig dadurch aus, dass er seine Oberflächen so oberflächlich programmiert, dass einem die Haare zu Berge stehen. Man kann die MFC nämlich leider und recht leicht auch dazu missbrauchen, grausamen, unstrukturierten Code zu erzeugen, der mit OO nur die von MFC generierten Klassennamen gemeinsam hat.

[Christian Gründler]

Java und "Spielzeug" würde in der Tat deutlich am tatsächlichen Sachverhalt vorbeigehen.

Danke, Roland,

dann lag ich vor ein paar Tagen ja garnicht so falsch.

Etwas überraschend ist die Heftigkeit, mit der hier diskutiert wird. Es sollte eigentlich ohne Weiteres möglich sein, die Stärken und Schwächen der jeweiligen Programmiersprache aufzuzählen und unter Berücksichtigung des vorgesehenen Einsatzzwecks vorurteilsfrei zu bewerten. Mehr wollte ich eigentlich nicht erreichen, als ich so penetrant "Warum?" gefragt habe.

M.f.G. Christian

[Audisline]

Moje,

sämtliche Stellwerksspiele so nenne ich sie mal bekommt man in der Ausbildung zum FDl.
Wo allerdings auch alles so klappt wie in echt darunter fallen dann Sesam und das mechanische Stellwerk.
die dürfen wir natürlich nur für UNS benutzen ^^
Vor 2 Wochen kam dann entlich das ESTW für daheim zum Üben raus.
Coole Sache
Wer also Geld zu viel hat für 8 monitore und eine ausbildunf zum eib F machen will, nur los.

[Pascal E.]

Nur für uns? Also nehm ich mal an dass du "Trainer" bei DB Training bist und Seminare wie "Einführung in den Bahnbetrieb" oder "Fahrdienst auf den Betriebsstellen" unterrichtest ?

[Jens Strumberg]

Wo allerdings auch alles so klappt wie in echt darunter fallen dann Sesam und das mechanische Stellwerk.

Das war jetzt schon Ironie, oder? Bei Sesam kann ich das aber absolut nicht unterschreiben...

[Lutz Troitzsch]

mich würde mal das mechanische Stellwerk interessieren.

Mfg

Lutz

[Audisline]

Ja, Sesam hat seine Maken das war ironisch.
Nein, ich bin ein Azubi und kein Trainer wir haben aber Sesam, Mechaniches Stellwerk und das ESTW bekommen zum lernen.

[Plokky]

Sesam ist alt. Uralt... und auch sehr fehlerhaft.

Die Stellwerksimulatoren wie die neue Version von Bonn Hbf, Hürth-Kalscheuren und Köln Hbf können wesentlich mehr als Sesam. (und auch nicht nur Sp Dr S 60)

Und eine Kupplung an Zusi wäre ich durchaus interessiert. (wie im Anfang vom Faden)

Editor für den Stellwerks-Simulator: gibt es, aber ein Stellwerk erstellen kann u.U. mehr Arbeit sein als eine Strecke in dem Umfang zu bauen. (Schon mal wegen der benötigten Fachkenntnisse)) Und eigentlich nur deswegen ist sie nicht öffentlich. Einfach keine Lust da eine 10.000 Seiten Anleitung zu schreiben.

Dennoch sehe ich durchaus Möglichkeiten für eine Kopplung zwischen Zusi und den Stellwerk-Simulator.