Ist RemObjects die Zukunft von Delphi?

[Furtbichler]

Ausgehend von diesem Blogpost muss an sich doch glatt überlegen, weshalb man Emba noch die Treue halten soll. RemObjects ist so viel volatiler und besser in eigentlich allem, was sie anpacken. Der Preis ist -unterm Strich- auch nicht viel höher als eine brauchbare Delphi-Version aber dafür bekommt man doch viel viel mehr (von einer sehr stabilen IDE mal ganz abgesehen).

Ich habe bisher die Delphi-Welt (auch rückblickend mich selbst) belächelt, weil sie Listen noch in Steinzeitmanier in Schleifen durchlaufen, obwohl LINQ einem 99% dieser Arbeit abnehmen kann. Nun baut RemObjects das einfach selbst und bietet es -soweit ich das verstanden habe- plattformübergreifend an. Ach, und wer den Delphi-Dialekt ablehnt, der kann trotzdem zu RemObjects, weil die nun auch ihr C# auf den Markt werfen. Respekt Leute, weiter so.

:thumb:

[jaenicke]

Wenn sie jetzt noch ein natives Compilerbackend für Windows anbieten würden, wäre das auch wirklich interessant für mich.

So hätte ich zwar eine schöne Sprache und auch viele Möglichkeiten, kann z.B. sogar Java-Bytecode für Android erzeugen, aber ohne .NET geht es trotzdem unter Windows nicht. Solange sich das nicht ändert, wird zumindest unsere Hauptanwendung sicher nie mit Oxygene geschrieben werden.
Auch wenn wir einzelne DLLs auch schon mit Prism umgesetzt hatten, aber das war keine schöne Erfahrung. Das Deployment enthält deutlich mehr Ballast und ohne Setup geht auf den Zielrechnern gar nichts. Ein No-Go in manchen Bereichen.

[sh17]

Auf lange Sicht wird Oxygene unsere Delphi-Ablösung.

[Der schöne Günther]

Pascal, sicher. ("In der Tat.")
Aber Delphi? Delphi ist für mich immer ein Synonym für das Embarcadero-Produkt sowie das Pascal-Derivat (analog Oxygene).

Oder verstehe ich schon das falsch?

(PS: Warum grade immer LINQ als Heilsbotschaft von .net?)

[Union]

Zitat:

Zitat von Der schöne Günther (Beitrag 1250473)

(PS: Warum grade immer LINQ als Heilsbotschaft von .net?)

Schreibfaulheit, wie bei Generics. Und damit man sich abhängig macht und nicht mehr weiß, was im Hintergrund tatsächlich passiert.

[Furtbichler]

Zitat:

Zitat von Union (Beitrag 1250474)

Zitat:

Zitat von Der schöne Günther (Beitrag 1250473)

(PS: Warum grade immer LINQ als Heilsbotschaft von .net?)

Schreibfaulheit, wie bei Generics. Und damit man sich abhängig macht und nicht mehr weiß, was im Hintergrund tatsächlich passiert.

Eher, damit man seine Zeit nicht mit diesem Schleifenmumpitz verplempert. Ich habe wirklich Besseres zu tun, als irgendeinen Filter, Suche, Umsortierung, Umformung etc. schon wieder als For-Schleife zu implementieren. Mir reichen schon die ganzen IF-Schleifen :stupid:
Heute schreibt man ja auch kein Assembler mehr, verwendet die Win-API, diverse Frameworks etc. Wieso nicht einfach mal ein 'Listen-Framework'?

Im Ernst: Wer einmal mit Linq gearbeitet hat, wird es einfach nie wieder missen wollen.

Zitat:

Zitat von jaenicke (Beitrag 1250467)

...aber ohne .NET geht es trotzdem unter Windows nicht. Solange sich das nicht ändert, wird zumindest unsere Hauptanwendung sicher nie mit Oxygene geschrieben werden.
Auch wenn wir einzelne DLLs auch schon mit Prism umgesetzt hatten, aber das war keine schöne Erfahrung

Ich verstehe die Problematik zwischen Win32 und .NET DLL, aber wieso keine reine .NET-Anwendung?

[sh17]

Zitat:

Zitat von Furtbichler (Beitrag 1250475)

Mir reichen schon die ganzen IF-Schleifen.

:shock:

[sh17]

Bei .NET ist mir noch nicht ganz klar, worauf setzt man vernünftiger Weise? WPF (tot) WinRT (hmm) GTK# (+Linux), ...

[Furtbichler]

Zitat:

Zitat von sh17 (Beitrag 1250480)

Bei .NET ist mir noch nicht ganz klar, worauf setzt man vernünftiger Weise? WPF (tot) WinRT (hmm) GTK# (+Linux), ...

WinForms fehlt in deiner Auflistung. Bloß weil WPF (und WinForms?) nicht weiterentwickelt wird, ist das doch nicht tot. Schau mal bei Microsoft nach, was die darüber schreiben. WinForms, WPF sind einfache Techniken, um Windows-Applikationen mit 'ner GUI zu schreiben. Wenn Du Metro Apps (meinst Du das mit WinRT) schreiben willst, bitte sehr.

Allerdings ist es schon so, das man für WPF etwas vom MVP/MVVM-Pattern verstehen muss, und für Metro/WinRT bestimmte Patterns und Techniken einsetzen muss. Wenn man den Sinn dahinter nicht versteht, dann bleibt man am Besten bei Delphi, Visual FoxPro und ähnlichen.

Ein guter Softwareentwickler macht sich ja mittlerweile doch unabhängig vom Frontend und schreibt seine Anwendungen so, das sie ohne großen Aufwand an andere GUI angepasst werden können. Insofern ist das doch ziemlich egal, was gerade in Mode ist.

[sh17]

MVP/MVVM-Pattern - vollkommen richtig - und WinRT-nein möchte ich eigentlich nicht nutzen.

Wenn ich nun schon versuche alle 3 "wichtigen" Plattformen nativ zu unterstützen, was ist der momentane (technische) optimale Weg?

Windows Linux MacOS
WPF GTK# Cocoa
WinForms WinForms Cocoa

[Lemmy]

Hi,

ich persönlich finde Oxygene bzw Hydrogene sehr interessant. Mit Prism/Oxygene bin ich aber nicht warm geworden - die Sprache gleicht zu sehr Delphi, das Backgroud ist aber ein komplett anderes. Der Umgang mit c# ist mir da wesentlich leichter gefallen, obwohl ich an c angelehnte Sprachen überhaupt nicht gerne mag.

Vor allem plattformübergreifend sehe ich RemObjects mit ihrem Toolset ganz klar vor Embarcadero. Leider habe ich aber Probleme damit meine Begeisterung (z.B. an Futures) an meine Kollegen weiter zu geben: die wollen nicht aus einer Nische in eine noch kleinere Nische wechseln :-)

aber vielleicht kann ich die jetzt mit Hydrogene ködern - ist immerhin C#. Zwar deutlich erweitert, aber mir käme ein Framework sehr gelegen das die Hauptplattformen abdeckt - das wäre mit Oxygene/Hydrogene gegeben.

Zumindest für mein privates Zeugs werden Alternativen zu Dephi immer interessanter - so leid es mir auch um Delphi tut....

[Der schöne Günther]

Zitat:

Zitat von Lemmy (Beitrag 1250484)

[...] mit Hydrogene ködern - ist immerhin C#. Zwar deutlich erweitert,[...]

Ich dachte, genau anders herum?

[stahli]

Ich bin noch an einem Projekt, bei dem ich weiter bei XE3 und VCL bleibe.

Etwas neues werde ich bei Emba nicht mehr kaufen.

RemObjects wirkt deutlich attraktiver und kompetenter.

Mir graut etwas vor einem Wechsel, insbesondere wegen meinem schlechten Englisch. Mit .NET wollte ich mich zwar ursprünglich nicht anfreunden, aber wenn es keine gute Alternative gäbe...!?

Vielleicht ist mittelfristig auch eine www.RO-Praxis.net denkbar. ?

[Lemmy]

Zitat:

Zitat von Der schöne Günther (Beitrag 1250487)

Zitat:

Zitat von Lemmy (Beitrag 1250484)

[...] mit Hydrogene ködern - ist immerhin C#. Zwar deutlich erweitert,[...]

Ich dachte, genau anders herum?

Wie meinen?

[Phoenix]

Zitat:

Zitat von Lemmy (Beitrag 1250490)

Zitat:

Zitat von Der schöne Günther (Beitrag 1250487)

Zitat:

Zitat von Lemmy (Beitrag 1250484)

[...] mit Hydrogene ködern - ist immerhin C#. Zwar deutlich erweitert,[...]

Ich dachte, genau anders herum?

Wie meinen?

Hydrogene ist C# (für .NET) bzw. ein Subset von C# für die Cocoa/Objective-C Runtime (z.B. gehen dort keine Generics, da das die Runtime nicht kann). Das was hier erweitert wurde ist z.B. der für Cocoa benötigte Support für Multipart-Method Names.

Ansonsten ist das "nur" ein Compiler mit 3 Backends (.NET, Java Bytecode, Obj-C) für die Sprache C# - da ist nichts "deutlich" erweitert, sondern nur minimal wo unbedingt nötig.

[sh17]

Zitat:

Zitat von stahli (Beitrag 1250489)

Vielleicht ist mittelfristig auch eine www.RO-Praxis.net denkbar. ?

Vielleicht schreibt mir Marc ja noch was dazu - aber ein deutsches Forum wäre in jedem Fall vorteilhaft zum Austausch.

[Phoenix]

Zitat:

Zitat von Furtbichler (Beitrag 1250462)

Ist RemObjects die Zukunft von Delphi?

Nein. Wollen sie aber auch nicht sein. Müssen sie auch nicht.

RemObjects bietet für Pascal (und jetzt C#) sprechende Entwickler einen sehr individuellen Zugang zu neuen Plattformen, nämlich indem sie die Zielplattformen ohne Abstraktionen 1:1 an den Entwickler durchreichen.

Der Entwickler wird bewusst auf die Problematik Plattform <--> Code reduziert. Es gibt - auch wieder bewusst - keine zusätzlichen Libraries wie die RTL oder VCL die einen von der nativen Zielplattform weg bewegen würden. Man arbeitet mit dem Bare Metal. Man muss viel von Hand machen.

Das ist ein Ansatz, der dem typischen Delphi-Entwickler (RTL, VCL, freie Komponenten, ggf. zugekaufte Komponenten die alles irgendwie für einen schon erledigen) sehr befremdlich vorkommt und ihn zum Teil etwas Hilflos dastehen lässt:

Zitat:

Zitat von Entwickler

Vorher habe ich ein TDingsbums da drauf gezogen, mit TBummens verbunden und hatte meine Daten auf dem Form - wo ist hier mein Formdesigner?

Der Entwickler wird sozusagen gezwungen, sich mit der Zielplattform intensiv auseinanderzusetzen, und sich im Umfeld der Zielplattform ggf. mit dort verfügbaren Libraries auseinanderzusetzen. Der Entwickler lernt so mehr über das Umfeld und kann es mittel- bis Langfristig daher auch intensiver ausnutzen.

Das ist meiner Meinung nach per se ein sehr intelligenter und lobenswerter Ansatz. Nur ist der eben nicht unbedingt mit jeder Entwicklermentalität kompatibel. Das heisst im großen Stil wird das (leider?) nicht funktionieren (auch wieder meine persönliche Meinung). Auch wenn es wünschenswert wäre.

Nichts desto trotz ist das ein Ansatz, der denjenigen denen er zusagt, viel Erfahrung bringen kann und es ihnen ermöglicht, wirklich das letzte Quäntchen an UX, Performance und Plattformüberlegenheit aus seiner App zu quetschen. Diese Möglichkeit haben von der Plattform weg abstrahierte Entwickler niemals in diesem Umfang, und dieser Vorteil wird die, die sich darauf einlassen, zu einer sehr elitären Truppe machen.

[jaenicke]

Zitat:

Zitat von Phoenix (Beitrag 1250497)

Diese Möglichkeit haben von der Plattform weg abstrahierte Entwickler niemals in diesem Umfang

Das gilt aber auch für .NET auf der Windows-Plattform. Und das ist es genau was mich an der Stelle stört.

[Lemmy]

Zitat:

Zitat von Phoenix (Beitrag 1250493)

Ansonsten ist das "nur" ein Compiler mit 3 Backends (.NET, Java Bytecode, Obj-C) für die Sprache C# - da ist nichts "deutlich" erweitert, sondern nur minimal wo unbedingt nötig.

ähm.. Oxygene wird ja z.B. mit "Futures" beworben - ich bin davon ausgegangen dass solche Sprachfeatures auch in c#-Hydrogene dabei sind... auf das bezog sich das erweitert....

[Phoenix]

Zitat:

Zitat von Lemmy (Beitrag 1250509)

ähm.. Oxygene wird ja z.B. mit "Futures" beworben - ich bin davon ausgegangen dass solche Sprachfeatures auch in c#-Hydrogene dabei sind... auf das bezog sich das erweitert....

Nein, sind sie nicht. C# wurde so nach am ECMA-Standard belassen wie möglich.

[Phoenix]

Zitat:

Zitat von jaenicke (Beitrag 1250499)

Zitat:

Zitat von Phoenix (Beitrag 1250497)

Diese Möglichkeit haben von der Plattform weg abstrahierte Entwickler niemals in diesem Umfang

Das gilt aber auch für .NET auf der Windows-Plattform. Und das ist es genau was mich an der Stelle stört.

.NET IST die Windows-Plattform. Noch nativer als einheitlich über alle Windows-Varianten - inklusive RT - (wo steht da nochmal das Windows-"Native" Delphi?) geht es nicht.

[jaenicke]

Zitat:

Zitat von Lemmy (Beitrag 1250509)

ähm.. Oxygene wird ja z.B. mit "Futures" beworben - ich bin davon ausgegangen dass solche Sprachfeatures auch in c#-Hydrogene dabei sind... auf das bezog sich das erweitert....

Welche Sprachfeatures dabei sind findet man im Wiki:
http://www.elementswiki.com/en/Hydro...age_Extensions

[jensw_2000]

Zitat:

Zitat von Phoenix (Beitrag 1250493)

Hydrogene ist C# (für .NET) bzw. ein Subset von C# für die Cocoa/Objective-C Runtime (z.B. gehen dort keine Generics, da das die Runtime nicht kann). Das was hier erweitert wurde ist z.B. der für Cocoa benötigte Support für Multipart-Method Names.

Ansonsten ist das "nur" ein Compiler mit 3 Backends (.NET, Java Bytecode, Obj-C) für die Sprache C# - da ist nichts "deutlich" erweitert, sondern nur minimal wo unbedingt nötig.

Hi,
das ist nicht ganz richtig. Ich habe gerade mein frisch installiertes RO C# gestartet und 2 Sachen probiert:

Delphi-Quellcode:

class RootViewController : UIViewController

{
private NSArray<String> MyStringarray = new NSArray<String>;  // Generics gehen unter iOS / Linq auch :o)
private Class1 MyPascalClass; // das ist der Hammer. Eine Oxygene (Pascal) Klasse im gleichen Projekt. Kompiliert und rennt :o))

 ...
}

Noch ein PS:
Man kann auch CS Dateien in Oxygene Projekte hängen und die Klassen normal benutzen. Gerade getestet mit einem DevExpress C# Template. 
Ich tauche dann mal für ein paar Tage unter. Muss jetzt unbedingt mal schnell alles umbauen ;)

PS:
und für Furtbichler, unserem Prediger für "sprechende Methodennamen und Parameter" ;)

RO C# kann laut RemObjects 100% des MS C# zzgl. der Gimmicks die RO mit eingebaut hat.
Die Multipart Methodnames sind glaube ich genau das richtige für deinen Geschmack.

Code:

namespace ConsoleApplication1
{
   static class Program
   {
      public static Int32 Main(string[] args)
      {

                        LogAdditionResultOfInt(1) AndInt(2);
                        return 0;
      }

        private static void LogAdditionResultOfInt(int Summand1) AndInt(int Summand2)
        {
            Console.WriteLine("{0}+{1}={2}",Summand1,Summand2,Summand1+Summand2);
        }
        
    }
}

Ausgabe:
1+2=3
wäre zur Not auch im Kopf gegangen, aber die Multipartnames liebe ich seit iOS.

[jfheins]

Da hier ja gerade fleißig über Hydrogene Spachfeatures gequatscht wird, täten mich zwei Sachen mal interessieren:

1. Kann man char immer noch implizit in int konvertieren? (Finde ich persönlich uncool)
2. Gibt es Code-Contracts ähnlich wie in Oxygene?

[jensw_2000]

Implizite Char Konvertierung geht sowohl unter RO C# als auch unter MS Visual C#.

Code:

char c = 'a';
int i = 0;
Console.WriteLine(c+1);
Ausgabe: 98

Zu den Code Contracts kann ich noch nichts sagen. Habe das komplette Elements erst seit einer Stunde auf dem Rechner. Da der Backend Compiler gleich ist würde ich vermuten dass Contracts unterstützt werden. Zur Not hängst Du dir einfach eine Oxygene Klasse samt Contracts mit in das C# Projekt. Sowas kann man offenbar frei mischen, wenn man Oxygene und Hydrogene im Bundle installiert hat.

[Phoenix]

Zitat:

Zitat von jfheins (Beitrag 1250775)

Da hier ja gerade fleißig über Hydrogene Spachfeatures gequatscht wird, täten mich zwei Sachen mal interessieren:

1. Kann man char immer noch implizit in int konvertieren? (Finde ich persönlich uncool)
2. Gibt es Code-Contraacts ähnlich wie in Oxygene?

1.) Hängt von der Plattform ab.

Ein .NET Char (also das Objekt im .NET Framework) bringt die Implizite Konvertierung zu Int mit: http://msdn.microsoft.com/en-us/library/y5b434w4.aspx

Auch in Java konvertiert die Runtime einen Char (2 byte) implizit in einen int (4 byte), da es eine widening conversion ist.

Wie das in der Cocoa/Objective-C runtime ist kann ich nicht mit Bestimmtheit sagen, aber ich würde darauf tippen, das das hier noch nichtmal eine implizite conversion ist, sondern der Char direkt gecastet (bzw. als int interpretiert) werden kann, da Objective-C nicht so wirklich typesafe ist (weil es eben dann doch im inneren erstmal C ist).

2.) Nicht direkt. C# wurde in der Hinsicht nicht erweitert. Aber Du könntest so etwas ggf. mit Attributen und Cirrus nachbauen.

[michaelthuma]

Diskussionen über Sprachfeatures sind zumeist ideologisch motiviert. Indoktrination und MS Fanboyism gehört zusammen. Das ändert mal nichts an der Nützlichkeit von LINQ. .net kann sich nicht auf viel Ruhm stützen. LINQ für ERP beim Zugriff auf mystische Welten ist schon gut. Mich stört die Integration in die Sprache, genauso wie die Generics.


Man bekommt mit WPF und Teilen von .net für Komplexe GUIs selbst über mehrere Forms ein relativ konsistentes verhalten auf schmaler Codebasis hin. Auf der anderen Seiten sind viele Konstrukte eher dem Manko - alles ist ein Objekt geschuldet. Es scheint nach außen so.

Für jeden Windows Programmier ist .net eine Entgegenkommen auf bekanntem Terrain. Delphi Pascal solange man in der eigenen Welt bleibt ist es friktionsfrei. Remobjects hat den Vorteil der Zugang zur Problemlösung ist straight.

Die Probleme die Remobjects löst sind ganz andere. In dem Sinne kann RO nicht die Nachfolge antreten. Auf einer 400m Laufbahn sind die schon eher beim Überrunden. Die laufen dann zwar wenn der Schlusspfiff kommt möglw. knapp vor den anderen ins Ziel, aber die anderen hätten noch eine Runde. Ob das subjektiv betrachtet so segensreich ist, ich als Hobbyist lege eher Wert auf Gemütlichkeit. Man kann den Fortschritt nicht einholen, aber er holt einen ein. Das ist das Paradox und deswegen ist eine Technologie nicht zu wechseln nie falsch.

Wenn in der Welt zum selben Problem viel Lösungen existieren wird über die Einengung des Geistes - das ist bei Frameworks schwingt eine Denke mit - gearbeitet. .net Progammierer tragen ab dem 2ten Jahr ein Holzfällerhemd :-D Mir wäre dann der eher puristischere Zugang lieber. Die BASH ist eh schon genug an sich. Man bekommt mit den RO Features ganz nette Vorschläge den Code zu verbessern. So XCode like und eigentlich mehr. Das ist recht nützlich.

Zitat:

Zitat von Union (Beitrag 1250474)

Zitat:

Zitat von Der schöne Günther (Beitrag 1250473)

(PS: Warum grade immer LINQ als Heilsbotschaft von .net?)

Schreibfaulheit, wie bei Generics. Und damit man sich abhängig macht und nicht mehr weiß, was im Hintergrund tatsächlich passiert.

[Medium]

Und dann gibt es noch Leute, die mit Softwareentwicklung ihr täglich Brot verdienen müssen...

[Phoenix]

Zitat:

Zitat von michaelthuma (Beitrag 1250809)

Diskussionen über Sprachfeatures sind zumeist ideologisch motiviert. [...] .net kann sich nicht auf viel Ruhm stützen. LINQ für ERP beim Zugriff auf mystische Welten ist schon gut. Mich stört die Integration in die Sprache, genauso wie die Generics. [...]
ich als Hobbyist lege eher Wert auf Gemütlichkeit.
[...]
Mir wäre dann der eher puristischere Zugang lieber. Die BASH ist eh schon genug an sich.

Dann stehst Du vermutlich auch auf esoterische Programmiersprachen wie Whitespace oder Brainfuck? Viel puristischer geht es ja kaum noch.

Zitat:

Zitat von Medium (Beitrag 1250821)

Und dann gibt es noch Leute, die mit Softwareentwicklung ihr täglich Brot verdienen müssen...

Das ist eher der Punkt. Es geht bei der Sprachentwicklung primär um usability und ease of use.

Jede Zeile die ich als Entwickler nicht mehr schreiben muss, ist schonmal eine Zeile weniger die einen Bug enthalten könnte und eine Zeile weniger die ich testen muss.

Im professionellen (= man verdient Geld damit) Bereich ist man auf Mittel angewiesen, die die Produktivität steigern und es gleichzeitig erlauben, sehr sauberen, gut les- und wartbaren Code zu produzieren der am Ende auch noch funktioniert.

[Union]

Zitat:

Zitat von Phoenix (Beitrag 1250840)

Jede Zeile die ich als Entwickler nicht mehr schreiben muss, ist schonmal eine Zeile weniger die einen Bug enthalten könnte und eine Zeile weniger die ich testen muss.

Jede Zeile die ich auf diese Art und Weise spare wurde von jemand anders geschrieben und ich habe auf Bugs in den Compilern / Frameworks nur begrenzt Einfluss.

[Phoenix]

Zitat:

Zitat von Union (Beitrag 1250844)

Zitat:

Zitat von Phoenix (Beitrag 1250840)

Jede Zeile die ich als Entwickler nicht mehr schreiben muss, ist schonmal eine Zeile weniger die einen Bug enthalten könnte und eine Zeile weniger die ich testen muss.

Jede Zeile die ich auf diese Art und Weise spare wurde von jemand anders geschrieben und ich habe auf Bugs in den Compilern / Frameworks nur begrenzt Einfluss.

Prinzipiell korrekt. Nur wenn man das konsequent durchzieht müsstest Du ja erstmal anfangen Deinen eigenen Compiler zu bauen.

Nun kann man aber zum glück davon ausgehen, das ein Compiler der z.B. von Microsoft bereitgestellt wird - genauso wie das .NET Framework - eine extrem intensive QA durchläuft. Trotzdem durchgerutschte Bugs fallen bei einer Nutzerbasis in der Größenordnung dann aber auch eher früher als später auf und werden in aller Regel auch gefixt.

Aber ja, natürlich sind da auch tatsächlich mal Bugs drin. Ich bin auch kürzlich mal über einen gestolpert. Da gab es dann aber auch schon einen Hotfix für. Einen Webserver selber schreiben würde ich dann eben doch nicht unbedingt wollen.

[mquadrat]

Zitat:

Zitat von Phoenix (Beitrag 1250840)

Jede Zeile die ich als Entwickler nicht mehr schreiben muss, ist schonmal eine Zeile weniger die einen Bug enthalten könnte und eine Zeile weniger die ich testen muss.

Kommt drauf an wie lesbar das ganze am Ende noch ist. Bei manchen "Vereinfachungen", die mir über den Weg gelaufen sind, muss man 10 Minuten nachdenken, bevor man verstanden hat, was der Programmierer da eigentlich gemacht hat. Dann lieber drei Zeilen mehr und man versteht es sofort. Kurz ist nicht immer besser.

[Phoenix]

Zitat:

Zitat von mquadrat (Beitrag 1250851)

Kommt drauf an wie lesbar das ganze am Ende noch ist. Bei manchen "Vereinfachungen", die mir über den Weg gelaufen sind, muss man 10 Minuten nachdenken, bevor man verstanden hat, was der Programmierer da eigentlich gemacht hat. Dann lieber drei Zeilen mehr und man versteht es sofort. Kurz ist nicht immer besser.

Stimmt, deswegen schrieb ich ja auch:

Zitat:

Zitat von Phoenix (Beitrag 1250840)

Im professionellen (= man verdient Geld damit) Bereich ist man auf Mittel angewiesen, die Produktivität steigern und es gleichzeitig erlauben, sehr sauberen, gut les- und wartbaren Code zu produzieren der am Ende auch noch funktioniert.

;-)

[jaenicke]

Zitat:

Zitat von mquadrat (Beitrag 1250851)

Bei manchen "Vereinfachungen", die mir über den Weg gelaufen sind, muss man 10 Minuten nachdenken, bevor man verstanden hat, was der Programmierer da eigentlich gemacht hat.

Vor allem LINQ erinnert manchmal eher an Brainfuck als an C#. Ich hatte da mal ein Beispiel vor mir, da habe ich nur noch gedacht WTF. Das lag in dem Fall auch daran, dass die Variablen a bis g hießen, aber selbst nach deren Ersetzung habe ich minutenlang nachdenken müssen.

Natürlich gibt es auch schöne LINQ Beispiele, keine Frage. Aber es ist ein Beispiel für ein Feature, bei dem man mehr auf die Lesbarkeit aufpassen muss als anderswo.

[Furtbichler]

Zitat:

Zitat von jaenicke (Beitrag 1250855)

Natürlich gibt es auch schöne LINQ Beispiele, keine Frage. Aber es ist ein Beispiel für ein Feature, bei dem man mehr auf die Lesbarkeit aufpassen muss als anderswo.

Das richtige Werkzeug in der Hand eines Kretins mutiert zum Folterwerkzeug. So gesehen ist Delphi die schlimmste Sprache, die es gibt, weil ich einmal ein Delphiprogramm gesehen habe, das ganz schlimm war.

So wie es auch C-Freaks gibt (und sogar Wettbewerbe), wie ich am meisten Funktionalität in am wenigsten Code reinquetsche (Prinzip der maximalen Boshaftigkeit), gibt es natürlich auch Frickler, die mit Linq/Delphi/You name it Dinge anstellen, die grauslig sind. Dies nun als Argument anzuführen, das Linq/Delphi/You name schlecht ist, ist schlecht.

[vagtler]

http://www.delphipraxis.net/1242331-post8.html

[p80286]

Zitat:

Zitat von Phoenix (Beitrag 1250840)

Im professionellen (= man verdient Geld damit) Bereich ist man auf Mittel angewiesen, die die Produktivität steigern und es gleichzeitig erlauben, sehr sauberen, gut les- und wartbaren Code zu produzieren der am Ende auch noch funktioniert.

Zunächst muß der Code funktionieren, dann sollte er wartbar und verständlich sein!

Gruß
K-H

[Furtbichler]

Zitat:

Zitat von p80286 (Beitrag 1250887)

Zunächst muß der Code funktionieren, dann sollte er wartbar und verständlich sein!

Falsch. Zunächst sollte der Code verständlich und wartbar sein. Denn dann wird er auch funktionieren bzw. kann dazu gebracht werden. Es gibt eigentlich nichts Schlimmeres als die Einstellung 'Hauptsache, et läuft', das ist nämlich mit mangelndem Qualitätsbewustsein gleichzusetzen. Nicht falsch verstehen: Code muss funktionieren, nur wie man dahinkommt, ist mittlerweile ausschlaggebend und unterscheidet zwischen guter oder schlechter Qualität.

@vagtler: :thumb:

[Sherlock]

Oh, wie ich mir wünsche, Beiträge bewerten zu dürfen!
Dein Beitrag, Furtbichler, leuchtet ganz oben bei den wirklich wichtigen Beiträgen zur Software-Entwicklung.
:thumb:

Hmm, das hört sich ziemlich ironisch an, ist aber absolut ernst gemeint!

Sherlock

[p80286]

Zitat:

Zitat von Furtbichler (Beitrag 1250888)

Code muss funktionieren, nur wie man dahinkommt, ist mittlerweile ausschlaggebend und unterscheidet zwischen guter oder schlechter Qualität.

Das kann ich voll unterschreiben.

Gruß
K-H