Ist RemObjects die Zukunft von Delphi?

[Phoenix]

Zitat von jaenicke:

Zitat von Phoenix:

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 von Lemmy:

ä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 von Phoenix:

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 von 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-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 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 von Union:

Zitat von Der schöne Günther:

(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 von michaelthuma:

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 von Medium:

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 von Phoenix:

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.