3. Welche Sprache

Welche Sprache

  • S

    +fricky schrieb:

    Skalli schrieb:

    C++: [...] es ist schwerer sich in den Fuß zu schießen...

    du glaubst wohl jedem werbespruch.

    Nicht wirklich, imho trifft die Aussage es schon. Auch wenn es nicht sooo viel schwerer ist. Aber das ganze ist eigentlich alles andere als ein Werbespruch...

    0
  • ?

    Skalli schrieb:

    +fricky schrieb:

    Skalli schrieb:

    C++: [...] es ist schwerer sich in den Fuß zu schießen...

    du glaubst wohl jedem werbespruch.

    Nicht wirklich, imho trifft die Aussage es schon. Auch wenn es nicht sooo viel schwerer ist. Aber das ganze ist eigentlich alles andere als ein Werbespruch...

    das ist genau so dumm, wie die aussage "java ist einfach vieeeeeeel zu langsam".
    🙂

    0
  • A

    asc schrieb:

    Stimmt, es ist wirklich überaus kompliziert alle Windowsupdates einzuspielen (Zusammen mit den Optionalen hat man unter XP und Vista nämlich 3.5 SP1 automatisch).

    Erinnerst du dich daran, daß Microsoft XP SP1 deutlich länger als geplant unterstützen mußte? Oder was Vista bei Unternehmen für eine Quote hat? Klar, im Idealfall ist das alles kein Problem. Aber jede zusätzliche Abhängigkeit birgt zusätzliche Komplikationen. Und ich habe schon genug derartiger Probleme gesehen.

    ~fricky schrieb:

    die sprache schimpft sich 'object pascal'.

    Soweit ich weiß, wurde sie irgendwann angesichts der Tatsache, daß sie mit Wirths Pascal nicht mehr viel gemein hat, in "Delphi Language" umbenannt.

    Shade Of Mine schrieb:

    Noch nie Probleme mit JRE oder dotnetfx gehabt (wenn wir .NET 1.0 mal aussen vor lassen).

    Das ist schön, aber daß es dir bisher immer gut erging, widerlegt mein Argument nicht. Ich jedenfalls hatte schon eine Menge Probleme mit verschiedenen Versionen der .NET-Runtimes.

    Shade Of Mine schrieb:

    Klassenreferenzen gibt es

    Es gibt System.Type, aber du kannst damit nicht Klassenpolymorphie anwenden. Sieh dir lieber erstmal das Feature in Delphi an, bevor du so pauschal antwortest.

    Shade Of Mine schrieb:

    und virtuelle Ctors nennt sich factory.

    Ja, so nennt sich der Workaround, den man mangels virtueller Konstruktoren benutzen muß.

    Shade Of Mine schrieb:

    audacia schrieb:

    Gegenüber Java: Delphi unterstützt nichtvirtuelle Methoden, call by reference, Operatorenüberladung für Werttypen (record), objektgebundene Methodenzeiger und Closures.

    gilt nicht für c#.
    [...]

    audacia schrieb:

    Die direkte Verwendung von WinAPI-Schnittstellen und die Interaktion mit C-Code ist viel unkomplizierter. Das weiß man besonders dann zu schätzen, wenn man mal etwas Zeit mit JNI verbracht hat 😉

    gilt aber nicht für c#

    Deshalb schrieb ich auch "Java" und "JNI", Mr Redundancy 🙄

    Shade Of Mine schrieb:

    in c# hab ich auch deterministische destruktion wenn ich will

    Aber kein deterministisches Speichermanagement.

    Shade Of Mine schrieb:

    und gc bringt deutlich geschwindigkeit 😉

    Für viele Anwendungsfälle trifft das zu, aber wenn das ein Problem ist, kannst du ja auch in Delphi einen haben.

    Shade Of Mine schrieb:

    irrelevant da du diese werkzeuge so oder so brauchst.

    In der alltäglichen Arbeit ja. Aber ich starte nicht für jeden Codeschnipsel, den ich lesen will, gleich die IDE. Dennoch ist das hauptsächlich ein ästhetischer Vorteil. Um Delphi-Code lesbar zu machen, muß man nicht erst Regions, Code Folding etc. bemühen. Er ist einfach lesbar.

    Shade Of Mine schrieb:

    gibts wie sand am mehr.

    Gute UI-Frameworks für .NET? An welchem Meer?
    Die UI-Frameworks sind einer der größten Schwachpunkte bei .NET. WinForms ist träge (GDI+), und WPF ist noch längst nicht so verbreitet wie WinForms. Von AWT und Swing muß ich vermutlich gar nicht erst anfangen; auf Seiten Javas ist eigentlich nur SWT eine Option, wenn das Ergebnis unter Windows vernünftige Usability bieten soll.

    Shade Of Mine schrieb:

    und wie sehen die nachteile aus? 😉

    Die gibts natürlich ebenso. Vor allem wären das weniger umfangreiche RTTI und der Wegfall der Vorteile, die sich durch die Nutzung eines Managed Environments ergeben.

    Shade Of Mine schrieb:

    ne, ich sehe gegenüber c# keinen einzigen vorteil.

    Bei allem Respekt, aber weil du keinen Vorteil siehst, heißt das noch lange nicht, daß es keinen gibt.

    Vielleicht solltest du einfach mal eine Weile mit einer der neueren Delphi-IDEs arbeiten 😉

    0
  • S

    audacia schrieb:

    Bei allem Respekt, aber weil du keinen Vorteil siehst, heißt das noch lange nicht, daß es keinen gibt.

    Sollen wir mal die Nachteile von Delphi gegenüber C# oder Java aufzählen...? 😉

    Vielleicht solltest du einfach mal eine Weile mit einer der neueren Delphi-IDEs arbeiten 😉

    vermutlich hat sich seit 2006 wohl eine menge getan, wieder ein guter punkt gegen delphi, nicht wahr?

    0
  • A

    audacia schrieb:

    asc schrieb:

    Stimmt, es ist wirklich überaus kompliziert alle Windowsupdates einzuspielen (Zusammen mit den Optionalen hat man unter XP und Vista nämlich 3.5 SP1 automatisch).

    Erinnerst du dich daran, daß Microsoft XP SP1 deutlich länger als geplant unterstützen mußte? Oder was Vista bei Unternehmen für eine Quote hat? Klar, im Idealfall ist das alles kein Problem. Aber jede zusätzliche Abhängigkeit birgt zusätzliche Komplikationen. Und ich habe schon genug derartiger Probleme gesehen.

    Selbst ohne den Updatemechanismus war meine Unternehmenserfahrungen das die Probleme bezüglich Java/.Net sich nicht viel unterscheiden (Tendenziell habe ich sogar von mehr Javaproblemen mitbekommen, Java ist aber auch verbreiteter - Wobei ich selbst schon ca. 4x Probleme mit Javaversionen auf diversen Rechnern hatte, und nur einmal mit .Net).

    Ich gehe davon aus das beide Java wie .Net etwa gleich viele Installationsprobleme machen.

    cu André

    0
  • A

    Shade Of Mine schrieb:

    audacia schrieb:

    Bei allem Respekt, aber weil du keinen Vorteil siehst, heißt das noch lange nicht, daß es keinen gibt.

    Sollen wir mal die Nachteile von Delphi gegenüber C# oder Java aufzählen...? 😉

    Vielleicht wäre es besser, wenn du die potentiellen Vorteile von C# und Java gegenüber Delphi aufzählst; besonders, da du Delphi offenbar nicht allzu gut kennst 😉

    0
  • S

    audacia schrieb:

    Sollen wir mal die Nachteile von Delphi gegenüber C# oder Java aufzählen...? 😉

    Vielleicht wäre es besser, wenn du die potentiellen Vorteile von C# und Java gegenüber Delphi aufzählst; besonders, da du Delphi offenbar nicht allzu gut kennst ;)[/quote]
    Ja, mein wissen ist aus 2006. Da war Delphi Schrott.

    Aber ganz einfach: Know How ist für Java und C# en masse da.
    Warum sollte man ein Projekt jetzt mit Delphi anfangen oder es gar lernen wenn man Anfänger ist. Lustige Sprachfeatures kann ich zu hauf nennen. zB IO ist enorm toll. Aber was bietet Delphi wirklich? .NET Binding ist sicher toll, doch warum Delphi und nicht C#?

    C# ist enorm toll. Du hast Support von der Industrie, du kannst Know How kaufen und es gibt massig Informationen. 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?). GUI Framework nehme ich an wird immernoch die VCL verwendet die nun gegenüber Qt keine Vorteile bietet (nur wieder weniger know how vorhanden) oder eben .net wo du wieder wie C# dastehst.

    Ich habe mir nun http://entwickler.de/zonen/portale/psecom,id,101,online,1928.html durchgelesen und muss sagen die neuen Features in Delphi 2009 sind ein ziemlich alter Hut. Aber gut, es hat sicher features die andere Sprachen nicht haben - das steht ausser frage. Nur warum man Delphi nehmen sollte beantwortet das nicht. Denn von der Sprache her ist Delphi keine gute Lehrsprache - ergo für Anfänger ungeeignet da zuviel compiler magie. Und in der Industrie wegen fehlendem support auch nicht wirklich brauchbar.

    da müsste es schon sehr gute argumente geben warum man ein projekt damit machen sollte. Sprich: Ich kann mir nur legacy Gründe vorstellen warum man heute auf Delphi setzen will. Legacy Gründe sind schön und gut, keine Frage - wir setzen auch oft aus legacy Gründen auf suboptimale techniken - aber deshalb würde ich hier jetzt nicht unbedingt 4D als Datenbank lösung empfehlen 😉

    0
  • A

    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.

    0
  • M

    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

    0
  • ?

    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.

    0
  • D

    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.

    0
  • A

    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?

    0
  • T

    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).

    0
  • A

    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.

    👍

    0
  • S

    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 😉

    0
  • A

    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.)

    0
  • ?

    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 ...

    0
  • V

    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.

    0
  • T

    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)?

    0
  • ?

    ...ist sinnlos

    0
Anmelden zum Antworten