Welche Sprache

[audacia]

Shade Of Mine schrieb:

C# ist enorm toll. Du hast Support von der Industrie, du kannst Know How kaufen und es gibt massig Informationen.

Ich stimme zu, daß aus Karrieresicht die Entscheidung für C# zukunftssicherer ist.

Shade Of Mine schrieb:

Delphi bietet keine wirklichen Sprachfeatures mehr, maximal diese Klassenpolymorphie die so toll sein soll (wobei ich den Sinn hier generell nicht verstehe weil dann duck typing doch einfach besser geeignet wäre, oder?).

Ja, ganz offensichtlich verstehst du den Sinn nicht.

Shade Of Mine schrieb:

GUI Framework nehme ich an wird immernoch die VCL verwendet die nun gegenüber Qt keine Vorteile bietet (nur wieder weniger know how vorhanden)

Komponentenmarkt? Bessere Windows-Unterstützung? Bessere IDE-Unterstützung? Bessere Sprachunterstützung (moc anyone?)?

Shade Of Mine schrieb:

Denn von der Sprache her ist Delphi keine gute Lehrsprache - ergo für Anfänger ungeeignet da zuviel compiler magie.

Unfug. Im Übrigen wäre das bei C# nicht anders.

[Muetze187]

Nette Diskussion, auch wenn ich nur die Hälfte verstehe

Evtl. gut für die Zukunft wäre eine Sprache mit denen man so kleine Gadgets erstellen kann wie z.B. fürs iphone oder was die Zukunft so bringt. Ich behaupte einfach mal unwissender Weise das c++ die erste Wahl ist!?

mfg
muetze

[Gast]

Muetze187 schrieb:

Evtl. gut für die Zukunft wäre eine Sprache mit denen man so kleine Gadgets erstellen kann wie z.B. fürs iphone oder was die Zukunft so bringt.

Für das iPhone nimmt man wohl eher Objective C. Damit wirst du aber auch nur glücklich wenn du auch einen Mac hast.
Nimm die Sprache die dich am meisten interessiert. Irgendwas zu lernen weil du damit in Zukunft vielleicht etwas machen können wirst... das bringts nicht. Imo.

[DEvent]

Ich verstehe nicht wieso sich so manche an Sprachfeatures aufgeilen. Mich interessiert es ueberhaupt nicht ob Sprache X closures, named ctors, nested functions und was nicht alles tolles hat. Die Frage ob Sprache X das richtige Werkzeug fuer das Problem Y ist, ist weitaus wichtiger.

Fuer mich zaehlen die folgenden Eigenschaften einer Sprache:
a) Einfachheit der Sprache
b) die Bibliotheken die verfuerbar sind
c) die Kosten der Portierbarkeit
d) die Zeit fuer die Entwicklung

Z.B. C++ schneidet in a) und d) ganz schlecht ab, in b) sehr gut und in c) bedingt gut (kommt drauf an welche Bibliotheken man verwendet). C# ist in b) und d) sehr gut. Da die meisten sowieso nur fuer Windows entwickeln, spielt also fuer die meisten d) keine Rolle. Java ist IMHO sehr gut in allen 4 Punkten.

Vor allem deswegen haben sich Sprachen wie Java, C# oder PHP gegenueber C oder C++ durchgesetzt. Wozu brauche ich Templates und manuelle Speicherverwaltung wenn ich eine GUI oder eine Webanwendung schreiben will? Wozu brauche ich Structs, Operatorueberladung, Autoboxing?

Klar verschinden C/C++ dadurch nicht. C/C++ sind die generischen Sprachen, die sich fuer alles eignen, in denen man die maximale Freiheit hat. Java, C#, Php u.a. eigenen sich aber weitaus besser fuer spezielle Themen, wie GUI, Webanwendung, usw.

Mein Tipp an den Thread Ersteller ist es: Wenn du Programmieren lernen willst, dann lern C. Fuer Webanwendungen nimm Php, Java, Ruby (ich habe sehr schlechte Meinung ueber C#, deswegen empfehle ich C# nicht).

Hier ist auch eine gute Seite die meine Meinung ueber C# bestaerkt:
http://www.geocities.com/csharpfaq/

Auch meine Meinung ueber unchecked exceptions spiegelt die Seite sehr gut wieder:

Unchecked exceptions results in shorter but less robust code.

[audacia]

DEvent schrieb:

Ich verstehe nicht wieso sich so manche an Sprachfeatures aufgeilen. Mich interessiert es ueberhaupt nicht ob Sprache X closures, named ctors, nested functions und was nicht alles tolles hat. Die Frage ob Sprache X das richtige Werkzeug fuer das Problem Y ist, ist weitaus wichtiger.

Und daß es da eine Korrelation geben kann, ist dir unbegreiflich?

[tfa]

audacia schrieb:

DEvent schrieb:

Ich verstehe nicht wieso sich so manche an Sprachfeatures aufgeilen. Mich interessiert es ueberhaupt nicht ob Sprache X closures, named ctors, nested functions und was nicht alles tolles hat. Die Frage ob Sprache X das richtige Werkzeug fuer das Problem Y ist, ist weitaus wichtiger.

Und daß es da eine Korrelation geben kann, ist dir unbegreiflich?

Ich glaube auch, die Features einer Sprache sind eher zweitranging für die Frage, ob sie sich als Werkzeug für ein bestimmtes Problem eignet oder nicht. Wenn man sich techikverliebt zu sehr an den tollen Features "aufgeilt", verliert man am Ende andere, wichtigere Aspekte aus den Augen.
Einige davon hat DEvent ja schon genannt. Ich würde unbedingt hinzufügen:
e) Verfügbarkeit von Entwicklern und Beratern

Und ich glaube, da scheidet Delphi nicht besoders gut ab verglichen mit C++, C# oder Java.

Der erste Punkt (Einfachheit) ist auch wichtig. Was nützen tolle Sprachkonstrukte, die man selten braucht, die nicht jeder versteht und anwenden kann und am Ende eher Probleme schaffen als lösen?
(Nur interessehalber: Welche Vorteile haben benannte Konstruktoren gegenüber Fabrikmethoden?)

DEvent schrieb:

Fuer Webanwendungen nimm Php, Java, Ruby

PHP verstößt ganz massiv gegen deinen Punkt a) - lieber nicht.

DEvent schrieb:

Auch meine Meinung ueber unchecked exceptions spiegelt die Seite sehr gut wieder:

Unchecked exceptions results in shorter but less robust code.

Bei diesem Punkt irrt diese Seite ganz gewaltig IMHO. Aus meiner Java-Erfahrung würde ich eher sagen:

Checked Exceptions results in longer and less robst code.

Ich glaube, diese Meinung verbreitet sich auch in Java immer mehr (ich hoffe es zumindest).

[audacia]

tfa schrieb:

Einige davon hat DEvent ja schon genannt. Ich würde unbedingt hinzufügen:
e) Verfügbarkeit von Entwicklern und Beratern

Und ich glaube, da scheidet Delphi nicht besoders gut ab verglichen mit C++, C# oder Java.

Richtig. Dennoch gilt für Delphi wie für fast jede andere Sprache: ein erfahrener Programmierer kann sie bei Bedarf innerhalb kurzer Zeit erlernen. Warum sollte man nicht einen C#-Programmierer in einem Delphi-Job beschäftigen können, eine grundsätzliche Agilität des Programmierers vorausgesetzt?

tfa schrieb:

(Nur interessehalber: Welche Vorteile haben benannte Konstruktoren gegenüber Fabrikmethoden?)

Eine Frage der Begünstigung. In Delphi bist du grundsätzlich gezwungen, deinem Konstruktor einen Namen zu geben; in C++/Java/... sind unbenannte Konstruktoren üblich, und du mußt i.d.R. einen Konstruktor und eine Factory-Methode schreiben, wenn du eine aussagekräftige Konstruktorbenennung willst.

In C++ ist es besonders schlimm, da man man Move-Semantik oder NRVO benötigt, um vector<SomeHeavyStruct>::createWithSize(3000) überhaupt benutzen zu können, außerdem muß man im Zweifelsfalle alle Argumente aus der Factory-Methode an den Konstruktor weiterreichen (-> Initialisierungsliste). Das sind alles Workarounds infolge einer (IMHO) grundlegenden Fehlkonzeption, die man in Delphi schlicht nicht braucht.

tfa schrieb:

Checked Exceptions results in longer and less robst code.

[Shade Of Mine]

audacia schrieb:

Richtig. Dennoch gilt für Delphi wie für fast jede andere Sprache: ein erfahrener Programmierer kann sie bei Bedarf innerhalb kurzer Zeit erlernen. Warum sollte man nicht einen C#-Programmierer in einem Delphi-Job beschäftigen können, eine grundsätzliche Agilität des Programmierers vorausgesetzt?

IO bietet deutlich tollere Features als Delphi - nehmen wir also alle IO

Ne ne ne.
So einfach ist das nicht. Du kannst dir Know How nicht so einfach zu kaufen. Vorallem wenn Delphi ja soviele Sprachfeatures bietet die sonst keiner kennt

Ne der Punkt ist der: Delphi war mal eine halbwegs verbreitete Sprache aber gerade die fragwuerdige Firmenpolitik und Zukunft der Sprache - ich wuerde nicht meine Firma an soetwas binden wollen.

Wenn du jetzt komplett neu anfangen wuerdest mit einem Unternehmen. Wuerdest du an Delphi binden? Erhliche Frage.

Sprachfeatures sind uebrigens das unwichtigste beim Aussuchen der passenden Sprache fuer ein Projekt

[audacia]

Shade Of Mine schrieb:

Wenn du jetzt komplett neu anfangen wuerdest mit einem Unternehmen. Wuerdest du an Delphi binden? Erhliche Frage.

Würde ich davon abhängig machen, was meine Firma für Anwendungen entwickeln soll. Webseiten? Nö, eher etwas in Richtung ASP.NET oder JSP. Datenbank-Server, Middle-Tier? Auch nicht; eher eine .NET-Lösung. Wissenschaftliche Anwendungen? Da nähme ich eher C++ aufgrund der größeren Kompatibilität mit bestehendem Code. Aber Rich-Client-UIs für Windows? Da würde ich Delphi wählen.

Shade Of Mine schrieb:

Sprachfeatures sind uebrigens das unwichtigste beim Aussuchen der passenden Sprache fuer ein Projekt

Nein, nur das Zweitwichtigste. Das wichtigste ist das "ecosystem" (irgendwie zweifle ich daran, daß "Ökosystem" hier eine passende Übertragung ist ). Und da muß sich die VCL keineswegs hinter WinForms verstecken, im Gegenteil. (Und WPF ist technologisch überlegen, praktisch aber noch nicht so weit.)

[bcbx]

Shade Of Mine schrieb:

Ne der Punkt ist der: Delphi war mal eine halbwegs verbreitete Sprache aber gerade die fragwuerdige Firmenpolitik und Zukunft der Sprache - ich wuerde nicht meine Firma an soetwas binden wollen.

Insbesondere wo gerade der Compiler völlig neu entwickelt wird und, wie gerade auf der Delphi Live Konferenz verkündet, native Entwicklung (Crosscompiling ?) für Linux und Mac hinzukommt.

Klar Weiterentwicklung muss sein, aber wer die Dramen um Kylix und den C++BuilderX erlebt hat, weiß wie das bei denen abläuft ...

[volkard]

audacia schrieb:

Das wichtigste ist das "ecosystem" (irgendwie zweifle ich daran, daß "Ökosystem" hier eine passende Übertragung ist ).

doch, ist es. es kann ohne informationsgewinn übersetzt werden.
bereits in der biologie ist sind die sätze mit "Ökosystem" drin seit jahrzehnten schwer zu hinterfragen oder zu widerlegen und das wort wird nicht zuletzt deswegen gerne verwendet. als neues wort in der informatik gilt das erst recht.

[tfa]

audacia schrieb:

tfa schrieb:

Und ich glaube, da scheidet Delphi nicht besoders gut ab verglichen mit C++, C# oder Java.

Richtig. Dennoch gilt für Delphi wie für fast jede andere Sprache: ein erfahrener Programmierer kann sie bei Bedarf innerhalb kurzer Zeit erlernen. Warum sollte man nicht einen C#-Programmierer in einem Delphi-Job beschäftigen können, eine grundsätzliche Agilität des Programmierers vorausgesetzt?

Sicher, trotzdem ist das zu kurz gedacht. Die meisten Entwickler sind Gewohnheitstiere, die am liebsten in ihrer Sprache entwickeln (sieht man ja schon an vielen Forumsbeiträgen, wo Leute ihre Sprache verteidigen). Außerdem sind die reinen Syntaxkenntnisse auch nur ein geringer Anteil dessen, was man wissen muss. Möglichst umfangreiche Kenntnisse der Standard-API, Bibliotheken, Frameworks usw. sind sehr wichtig und nicht eben mal so in kurzer Zeit erlernbar. Und auch die Erfahrung zählt. Wie man die komplexen Spezialfeatures (da sind sie wieder!) einer Sprache einsetzt, ohne sich oder andere dabei in den Fuß zu schießen, lernt man erst mit der Zeit.

tfa schrieb:

(Nur interessehalber: Welche Vorteile haben benannte Konstruktoren gegenüber Fabrikmethoden?)

Eine Frage der Begünstigung. In Delphi bist du grundsätzlich gezwungen, deinem Konstruktor einen Namen zu geben; in C++/Java/... sind unbenannte Konstruktoren üblich, und du mußt i.d.R. einen Konstruktor und eine Factory-Methode schreiben, wenn du eine aussagekräftige Konstruktorbenennung willst.

Danke für die Erklärung. Ctor+Factorymethode sind sicher doppelter Aufwand. Können benannte Konstruktoren auch polymorph sein, d.h. kann ein Ctor der Klasse "BaseList" ein Objekt der Klasse "OptimizedSpecialList" zurückliefern (wie bei Fabrikmethode)?

[diediskussion...]

...ist sinnlos

[audacia]

bcbx schrieb:

Klar Weiterentwicklung muss sein, aber wer die Dramen um Kylix und den C++BuilderX erlebt hat, weiß wie das bei denen abläuft ...

Ja, was die OS X- und Linux-Ambitionen angeht, bin ich auch skeptisch. Da würde ich erst ein paar Jahre abwarten, um zu sehen, ob sich das stabilisiert.
Außerdem wäre interessant, was man bzgl. der GUI vorhat. Hoffentlich wird es nicht eine Neuauflage der CLX (aka VCL-Pendant für Linux/Mac). (CLX basierte übrigens auf Qt, was sich nicht unbedingt als gute Entscheidung erwies.)

tfa schrieb:

Sicher, trotzdem ist das zu kurz gedacht. Die meisten Entwickler sind Gewohnheitstiere [...]

Schon richtig. Aber einerseits wird das vorhandene Delphi-Know-how deutlich unterschätzt (viele C#-Entwickler haben früher mit Delphi gearbeitet und sind 2002-2003, als man noch allerorten hörte, daß das Windows-API zu einer Legacy-Schnittstelle degradiert und auf ganzer Linie durch WinFX aka .NET ersetzt werden solle, nach C# gewechselt), und andererseits sind .NET und Delphi sich keineswegs unähnlich (genauer gesagt hat .NET viele Konzepte aus Delphi übernommen).

tfa schrieb:

Danke für die Erklärung. Ctor+Factorymethode sind sicher doppelter Aufwand. Können benannte Konstruktoren auch polymorph sein, d.h. kann ein Ctor der Klasse "BaseList" ein Objekt der Klasse "OptimizedSpecialList" zurückliefern (wie bei Fabrikmethode)?

Ja; wenn du die Konstruktoren als virtual deklarierst, sind sie polymorph.

Edit: Du meinst vermutlich so etwas wie

class Compiler
{
public:
    static Compiler* Create (String fileExt);
};
class CppCompiler : public Compiler { ... };
class CsCompiler : public Compiler { ... };

Compiler* Compiler::Create (String fileExt)
{
    if (fileExt == ".cpp")
        return new CppCompiler;
    else if (fileExt == ".cs")
        return new CsCompiler;
    ...
}

Dafür braucht man in Delphi entweder eine Factory-Methode oder eine Methode, die eine Klassenreferenz zurückgibt, über die du dann einen polymorphen Konstruktor aufrufen kannst.

volkard schrieb:

<audacia wirft mit buzzwords um sich>

Was hast du gegen "ecosystem"? Ich finde das in diesem Kontext gut verständlich. Aber wenn du eine bessere Alternative hast, erleuchte mich bitte.

[muemmel]

Hi,

wenn man zum Ausgangspost zurückgeht, dann ergibt sich doch daraus, daß der Frager nicht eine Sprache zum Ausrichten eines Betriebes auf die Zukunft sucht, sondern eine Sprache für Hobby und Arbeit für kleine Programme.

Gerade dafür ist Delphi absolut ideal. Es ist eine im Vergleich zu C++, C# und Java noch relativ einfach zu erlernende Sprache die trotzdem alle für solche Zwecke benötigten Möglichkeiten bietet. Es steht eine kompfortable leistungsfähige und sehr einfach zu bedienende Möglichkeit für die Gestaltung von Benutzeroberflächen zur Verfügung, und es ist eine realtiv simpel zu bedienende Datenbankanbindung inbegriffen. Der Compiler ist im Vergleich zu C++ rasend schnell, die Sprache hat nicht viele Fallstricke und ermöglicht eine sauber objektorientierte Programmierung. Wenn man sich einmal mit Delphi eingearbeitet hat, ist es problemlos auf andere Sprachen umzusteigen. Durch die Unterschiedliche Darstellung der Sprache ist aber die Gefahr da später mit der nächsten Sprache was durcheinanderzubringen wesentlich geringer. Außerdem ist bei eingeschränktem Umfang für die ersten Schritte auch die Arbeit mit den kostenlosen Turboversionen möglich.
Und es entstehen immer richtig compilierte Programme, die ohne irgend eine Laufzeitumgebung oder Zwischenübersetzung sofort abarbeitungsfähig sind.
Gerade bei kleinen Programmen, die bie solchen Aufgaben wie er sie andeutet erst mal längere Zeit entstehen werden ist das optimal. Um aus 5 Werten einen sechsten zu berechnen oder ähnliches ist es absolut übertrieben erst Net oder Java zu starten und das Programm dann erst noch mal zu übersetzen.

Gruß Mümmel

[Bulli]

Wenn jemand Anfänger ist und Hobby-Programmierung als Ziel hat, würde ich immer BASIC empfehlen. Und das meine ich nicht abwertend!

Damals zu Homecomputer-Zeiten war es mehr als normal und sinnvoll BASIC zu lernen (vorallem weil jeder Heimcomputer BASIC eingebaut hatte). Warum muß es heute als Einstieg Java, C#, C++, Python o.ä. sein? Meiner Meinung nach viel zu komplex. Sowas kann man später lernen. Damals ist man von BASIC zu Assembler oder zu C gesprungen.

Also, meine Empfehlung: BASIC.

[+fricky]

Bulli schrieb:

Also, meine Empfehlung: BASIC.

^^volle zustimmung.

[volkard]

audacia schrieb:

<volkard kennt das tolle wort nicht>

mist, ertappt. jetzt schäme ich mich. warum bin ich auch so vorlaut?

[DEvent]

muemmel schrieb:

Hi,

wenn man zum Ausgangspost zurückgeht, dann ergibt sich doch daraus, daß der Frager nicht eine Sprache zum Ausrichten eines Betriebes auf die Zukunft sucht, sondern eine Sprache für Hobby und Arbeit für kleine Programme.

Gerade dafür ist Delphi absolut ideal. Es ist eine im Vergleich zu C++, C# und Java noch relativ einfach zu erlernende Sprache die trotzdem alle für solche Zwecke benötigten Möglichkeiten bietet. Es steht eine kompfortable leistungsfähige und sehr einfach zu bedienende Möglichkeit für die Gestaltung von Benutzeroberflächen zur Verfügung, und es ist eine realtiv simpel zu bedienende Datenbankanbindung inbegriffen. Der Compiler ist im Vergleich zu C++ rasend schnell, die Sprache hat nicht viele Fallstricke und ermöglicht eine sauber objektorientierte Programmierung. Wenn man sich einmal mit Delphi eingearbeitet hat, ist es problemlos auf andere Sprachen umzusteigen. Durch die Unterschiedliche Darstellung der Sprache ist aber die Gefahr da später mit der nächsten Sprache was durcheinanderzubringen wesentlich geringer. Außerdem ist bei eingeschränktem Umfang für die ersten Schritte auch die Arbeit mit den kostenlosen Turboversionen möglich.
Und es entstehen immer richtig compilierte Programme, die ohne irgend eine Laufzeitumgebung oder Zwischenübersetzung sofort abarbeitungsfähig sind.
Gerade bei kleinen Programmen, die bie solchen Aufgaben wie er sie andeutet erst mal längere Zeit entstehen werden ist das optimal. Um aus 5 Werten einen sechsten zu berechnen oder ähnliches ist es absolut übertrieben erst Net oder Java zu starten und das Programm dann erst noch mal zu übersetzen.

Gruß Mümmel

wenn man zum Ausgangspost zurückgeht, dann ergibt sich doch daraus, daß der Frager nicht eine Sprache zum Ausrichten eines Betriebes auf die Zukunft sucht, sondern eine Sprache für Hobby und Arbeit für kleine Programme.

Gerade dafür ist Java/Python/Perl/Ruby absolut ideal. Es ist eine im Vergleich zu C++, C# und Delphi noch relativ einfach zu erlernende Sprache die trotzdem alle für solche Zwecke benötigten Möglichkeiten bietet. Es steht eine kompfortable leistungsfähige und sehr einfach zu bedienende Möglichkeit für die Gestaltung von Benutzeroberflächen zur Verfügung, und es ist eine realtiv simpel zu bedienende Datenbankanbindung inbegriffen. Der Compiler/Linker sind im Vergleich zu C++ rasend schnell, die Sprachen haben nicht viele Fallstricke und ermöglicht eine sauber objektorientierte Programmierung. Wenn man sich einmal mit Java/Python/Perl/Ruby eingearbeitet hat, ist es problemlos auf andere Sprachen umzusteigen. Durch die Unterschiedliche Darstellung der Sprache ist aber die Gefahr da später mit der nächsten Sprache was durcheinanderzubringen wesentlich geringer. Außerdem ist bei eingeschränktem Umfang für die ersten Schritte auch die Arbeit mit den kostenlosen IDEs/Linker/Compilern möglich.
Und man braucht das Programm nicht fuer jede Plattform neu zu uebersetzen.
Gerade bei kleinen Programmen, die bie solchen Aufgaben wie er sie andeutet erst mal längere Zeit entstehen werden ist das optimal. Um aus 5 Werten einen sechsten zu berechnen oder ähnliches ist es absolut übertrieben erst Net oder Delphi Standard Lib zu starten.

SCNR

[muemmel]

Hi,

ich weis ja nicht, wieso Java so viel einfacher sein soll als Delphi.
Delphi hat den vorteil, daß alles was die Oberfläche betrifft in den dfm-Dateien abgelegt ist und die eigentliche Programmierseite davon sauber bleibt.
Mit aus 5 Zeilen eine 6. berechnen meinte ich mit Sicherheit nicht addieren.
Kaputtlachen könnte ich mich immer, wenn als wichtigstes aller Argumente die Portabilität aufgeführt wird. Und für was programmieren die Erfinder des Schießpulfers die am lautesten danach rufen dann wirklich? Für Windows!
Für große Projekte mag Portabilität sicher eine Beduetung haben, aber ich vermute mal, das mindestens 95 % aller Programmierer nie ihre Programme auf eine andere Basis als die Microsoft-Systeme heben.

Gruß Mümmel