sinnvollere Entwicklungsumgebung?

[erik-17]

Hallo Delphi-Freunde,

nach dem ich nun schon einige Tools mit Delphi (Festplatten-Aufräumer, binäre Uhr) und schon einige kleinere Tests mit Java (Eclipse, auch für kleine Android-Apps) programmiert habe, möchte ich mich jetzt der Netzwerkkommunikation zuwenden. Dabei sollte auch die Platformunabhängigkeit eine Rolle spielen (habe Linux + Windows zu hause am laufen), wofür nun Java besser geeignet wäre.

Jetzt meine Frage dazu: Mit welcher Umgebung lässt sich die Kommunikation über das (zunächst private) Netzwerk einfacher umsetzen? Hat jemand Erfahrung mit solchen speziellen Gebieten der jeweiligen Programmiersprache / Entwicklungsumgebung?

Falls es noch wichtig ist, ich werde die Programmierarbeit am Linux-Rechner vornehmen. Delphi (habe Version 3) wird dann durch Lazarus ersetzt, bzw. versucht mit wine zu laufen. Java läuft dann wahrscheinlich mit Eclipse (bzw. wenn Netzwerke in anderen Umgebungen besser umzusetzen sind, auch gerne mit anderen Umgebungen).

Würde mich über Antworten sehr freuen

[implementation]

Rein zur Plattformunabhängigkeit:

Bei Java hast du dann natürlich immer den GC am Hals (es gibt nichts, das ich mehr hasse als GCs), bei FreePascal (Lazarus) kannst du die gewohnte Sprache beibehalten (gibt nur einige wenige Differenzen). Bei Java brauchst du weiterhin immer eine installierte JRE, das setzt FreePascal nicht voraus.

Ich benutze FreePascal schon seit einer ganzen Weile für Cross-Platform, und es läuft wie geschmiert. Man muss sich einfach nur die windowsspezifischen Aufrufe abgewöhnen, und dann klappt das perfekt. Je nachdem, wie du's einstellst, benutzt die LCL unter Windows direkt die WinAPI und unter Linux GTK oder Qt. Es ist sehr praktisch, dass man sich darum nicht mehr kümmern muss.

Delphi 3 ist schon sehr, sehr alt, und da lohnt es sich dann doch nicht, das zu winen. Dass Lazarus als IDE mit neueren Delphis nicht mithalten kann, dürfte klar sein, aber D3 kannst du ohne schlechtes Gewissen im Regal stehen lassen

[erik-17]

Vielen Dank für deine Antwort
Also werde ich mich demnächst mal wieder ans Programmieren machen (und Lazarus kennenlernen).

[mjustin]

Für Java kann ich die NetBeans IDE sehr empfehlen (teilweise ist sie der aktuellen Delphi IDE um Lichtjahre voraus), auch für Netzwerkprogrammierung. Die saubere Apache Maven Integration und die Unzahl von Plugins - die sich leichter als bei Eclipse installieren lassen - machen die Arbeit sehr angenehm. Die einschlägigen Framework für Netzanwendungen wie z.B. Apache MINA oder Grizzly sowie Netty (Java NIO Client Server Socket Framework aus JBoss) sind sehr ausgereift und performant, unter anderem wegen NIO und IOCP Unterstützung, die man für Delphi noch nicht hat.

p.s. dass es in Java einen GC gibt weiss ich zwar, aber negativ aufgefallen ist er mir in den vergangen fünfzehn Jahren noch nicht

[Phoenix]

Also ich würde hier eher zu Mono als Plattform und dann wohl C# als Sprache greifen. Es gibt nichts geileres als eine moderne, managed Laufzeitumgebung. Du hast eine optimale automatische Optimierung an Deine jeweilige Plattform (auf x64 Systemen hast Du automatisch eine x64 Anwendung, ohne einen Finger zu rühren) und vor allem kann Mono (analog dazu auch Java) den Speicher viel optimaler verwalten als Du es manuell je könntest.

Als IDE bietet sich dann natürlich MonoDevelop an. Zusammen mit InternetPack (eine OpenSource Komponentensammlung vergleichbar mit den Indy's für Mono und .NET) hast Du dann eine saubere Basis um Netzanwendungen zu schreiben.

[Hisoka]

Naja C# würde ich eher nicht wählen. Denn die Entwicklung der Desktop-Version ist beinahe eingeschlafen. So gibt es aktuell keine Anbindung an neuere UI-Bibliotheken wie GTK3 und die Zukunft von Xamarian ist eher ungewiss und sonst sind eher wenige Firmen an der Entwicklung beteiligt(Novell hat ja alle Entwickler gefeuert).

Mit den Anbindungen an andere Toolkits sieht es nicht unbedingt besser aus:
Qyoto => ist nicht aktuell( und aktuell scheint keine Arbeit gemacht zu werden)
qt4dotnet => tot
WX.Net => fraglich ob es noch lebt


Soll nur als Hinweis dienen. C# ist ja keine schlechte Sprache und MonoDevelop keine schlechte IDE, aber wer setzt schon gerne auf ein "totes" Pferd.

[implementation]

Zitat von mjustin:

p.s. dass es in Java einen GC gibt weiss ich zwar, aber negativ aufgefallen ist er mir in den vergangen fünfzehn Jahren noch nicht

Der speziell mir auch noch nicht, da ich Java noch nicht genutzt habe, aber ein anderer von *hust*hust* Microsoft, während meines Ausflugs nach *hust*hust* C#.
Und seitdem habe ich eine grundsätzliche Abneigung gegen GCs:

• Statt die Sachen, die ich aus dem Regal hole, wieder wegzupacken, wenn ich sie nicht mehr brauche, lasse ich sie auf dem Boden liegen
• Irgendwann, wenn der Raum schon bis auf Hüfthöhe voll ist und ich kaum mehr gehen kann, kommt mein Sklave namens Garbage Collection vorbei, und beginnt langsam aufzuräumen
• ... so langsam, dass ich schneller neue Sachen ausm Regal hole, als er wegräumen kann
• Mittlerweile geht mir der Müll bis zum Hals
• Am Ende ersticken wir beide

Da räum ich meinen Dreck dann doch lieber selber weg

[EDIT]
Und damit beißt sich mein Beitrag dann mit den Aussagen:

Zitat von Phoenix:

Es gibt nichts geileres als eine moderne, managed Laufzeitumgebung. [...] und vor allem kann Mono (analog dazu auch Java) den Speicher viel optimaler verwalten als Du es manuell je könntest.

Dan scheint es mich wohl einfach nicht zu mögen

[Phoenix]

Zitat von Hisoka:

Naja C# würde ich eher nicht wählen. Denn die Entwicklung der Desktop-Version ist beinahe eingeschlafen. So gibt es aktuell keine Anbindung an neuere UI-Bibliotheken wie GTK3 und die Zukunft von Xamarian ist eher ungewiss und sonst sind eher wenige Firmen an der Entwicklung beteiligt(Novell hat ja alle Entwickler gefeuert).

Erm.. Gtk#3 wird aktiv weiterentwickelt. Xamarin ist schon lange in den (sehr) schwarzen Zahlen, von daher ist die Zukunft nicht wirklich fragwürdig.

Ausserdem geht es hier um Netzwerk-Programme und nicht um Desktop-Programme, von dehr ist GUI wohl eher kein Thema. Und managed Umgebungen wie Java und .NET/Mono sind nunmal naturgemäß im Server- bzw. Backend-Bereich stärker, von daher passt das.

Zitat von Hisoka:

Soll nur als Hinweis dienen. C# ist ja keine schlechte Sprache und MonoDevelop keine schlechte IDE, aber wer setzt schon gerne auf ein "totes" Pferd.

Das Pferd ist quietschfidel

[mjustin]

Zitat von implementation:

[*]... so langsam, dass ich schneller neue Sachen ausm Regal hole, als er wegräumen kann

Weder für Java noch für C# schreibt die Spezifikation vor, dass der Garbage Collector langsam sein muss

Seit Java 5 ist die parallele Garbage Collection per Default eingeschaltet, wenn es sich um eine Maschine mit mehreren Prozessoren oder -kernen handelt. (Siehe Angelika Langer, Generational Garbage Collection, http://www.angelikalanger.com/Articl...oungGenGC.html) - dann können neben den Anwendungsthreads mehrere GC Threads laufen, die sich die einzelnen GC Strategien und Speichertypen untereinander effizient aufteilen können.

Dass man in Delphi alles selber machen darf ist schön, schön ist aber auch wenn einem die Arbeit abgenommen werden kann - weniger Codierungsaufwand für das Schreiben von Destruktoren, weniger Kopfzerbrechen über den 'richtigen' Zeitpunkt ab dem ein Objekt freigegeben werden kann, mehr Zeit für andere Pfadfindertugenden

Beispiel, was so ein Garbage Collector bringt: wenn eine Reihe von Objekten zyklisch referenziert sind (A -> B -> C -> A), und nur auf eines der Objekte in diesem Ring noch über eine Variable zugegriffen werden kann, darf man natürlich die anderen noch nicht freigeben. Sobald aber diese eine Variable nicht mehr aus dem Programm erreichbar ist (bei Verlassen einer Prozedur in der diese Referenz existierte, oder wenn sie auf nil gesetzt wird), dann sind die daran hängenden Objekte A bis C nicht mehr erreichbar. In Java werden solche Dateninseln erkannt und freigegeben. In Delphi hat man viel Spass mit der Programmierung eines entsprechenden Aufräumalgorithmus...

[implementation]

Zitat von mjustin:

dann können neben den Anwendungsthreads mehrere GC Threads laufen, die sich die einzelnen GC Strategien und Speichertypen untereinander effizient aufteilen können.

Oh Wow, füttern wir ihn mit noch mehr wertvoller Rechenleistung