Ex Delphi Best Way Forward?

(Bob Russell) #1

My journey ex Delphi began early this year. I was attracted to RemObjects and found a lively and helpful community. I naturally moved towards Oxygene as my platform and oscillated between WinForms and WPF. My first revelation was how much I did not know about how much Microsoft had moved on since my last encounter many years ago, having been insulated from this within the Delphi fold. The second, and related point, is that the vast amount of supporting material available is based on the C# or VB environment.
I am moving towards using DevExpress to enhance the UI and related aspects of my Applications, and have no need to migrate any existing Delphi projects to a new platform (other than a complete re-write from scratch)

Given all this, can I ask what is perhaps a dumb question? (But aren’t all questions dumb, by definition?).

What is the advantage of keeping within the Pascal (Oxygene) syntax?

Would it be better to “bite the bullet” and move all my learning and development effort to C#? (This would immediately give me easier access to learning and examples). I know that Oxidiser can do conversions, and that is helpful, but maybe I should move on.

Any thoughts / comments welcome
Bob Russell

(Alan Olson) #2

I think this is a very personal decision that any Elements developer has to make. There are many factors that would affect your decision. I think the choice of a language should be made by the developer, but I have it easy since I’m the only developer and work for myself. I know this will be different in other situations.

First and foremost, are you a sole developer? Or do you have a team? Is the team familiar with Oxygene/pascal? Or are they more experienced in C#? Swift? Java?

One other thing to remember is that in Elements you can mix languages. One unit can be Oxygene, and a second could be a C# unit, and it will all compile.

Alan

(marc hoffman) #3

There’s two parts to this.

1.

Choosing Oxygene as a language is mainly a matter of taste and preference. For various projects I work on, I switch between Oxygene, C# and Swift (can’t quite get myself to do a serious project in Iodine yet, though I should ;). All have their strengths and weaknesses, and we’re working on managing them out. Just today, I missed being able to use a for loop expression, in C# — only Oxygene can do that. Yesterday, i missed having if x is Foo foo in Oxygene, which (for now) is a C# thing.

But mostly it comes down to what syntax you like better, and one time, we’ll get most features into all languages.

2.

Choosing Elements over a different tool (in your case, Visual C#) has a lot of benefits, regardless of which language you choose — even more so (for you) once Water is out.

About 75% off my coding work is on Fire/Water, which is all C#. So when I work Windows side, that seems pretty unexciting — I could just use VC#, right? Nope. every time I’m forced to use Visual Studio (over Water), I wanna poke my eyes out. Yesterday I had to make some changes to a project (not mine) that still complied via VC#, and I was shocked about the stuff I take for granted works in RemObjects C# that doesn’t in Visual C#. (e.g. I could not implement a read-only interface property via a read/write-able property. insane!)

RemObjects C# is there better C# compiler. even if you only ever want to target .NET, even if you prefer using C#, Elements is the better option. Silver is the better Swift compiler. Even when I write a project that’s only ever gonna be Mac or iOS, I’d never even consider using Xcode instead of Silver — even though the language would be the same.

Of course on top of this come all the benefits from being able to use the same language, across multiple platforms. Or using two (or more) different languages in the same project. Or… Or… Or…

It’s worth getting familiar with C#, yes. But I wager even if you decide you prefer C#, you’re better of with our C# than you are with Microsoft’s.

but of course, with Elements it’s also not a question of none or the other. You can ix Oxygene and C# freely in your code. If/since you like Pascal, write the bulk of your code in Oxygene. If you find a nice class on-line that you wanna reuse, and you don’t wan’ to Oxidize it, then you can just use it as is, in the same project. Just add a .cs file and add it. You can even have the same class split cross multiple partial class files, in different languages.

(JohnMoshakis) #4

Have you changed your mind about this and worked out a better syntax ?

(marc hoffman) #5

we have not yet, no.

(Bob Russell) #6

Many thanks to Alan and Marc. I appreciate your comments. Gives me a lot to ponder, but it looks like a mix and match within Elements would be good. For the record, I am a sole developer, self “taught” going back from DBase II (wow that feels along time ago) before bailing out of Delphi at XE6. Actually it’s further back - I self built a FORTH interpreter from a pile of Z80 machine code, then developed a floppy disk file storage system using FORTH - just for me! Times have changed a bit.

I work basically for one main client in the USA, and the existing projects in Delphi won’t need to be converted - the ongoing maintenance of those is not hopefully a major issue.

So it’s all to play for in the new environment! Again many thanks to all who contribute to these forums!

Bob Russell

(Bob Russell) #7

One more question - Since I plan to use the DevExpress WPF suite, I test created a new DevExpress project (therefore in C#). Presumably I can add an Oxygene class or code file. Going to the “Add new Item” menu in VS2015, I couldn’t see how to enter anything other than DevExpress stuff - am I missing something?

Thanks for all help.

Bob Russell

(marc hoffman) #8

Is that a Visual C# project (ie using Microsoft’s compiler, and a .csproj) or RemObjects C# (.elements)? You can only mix Oxygene and C# in an Elements project, not with Visual C#.

Assuming you’re using a project template provided by DevExpress, that would generate a .csproj. The easiest way to get to where you want to be is to just create a new empty Elements (eg Oxygene) project in the same folder, and just add the .cs source files generated by DevEx’s template to the new project.

(Bob Russell) #9

Aha. Yes it was Visual C#. I’ll have a play as you suggested. Thanks.

(Working on Sunday - I’m impressed! :wink: )

(marc hoffman) #10

What’s this “Sunday” thing you are referring to? :wink:

(mtiede) #11

Bob, you may have already decided on C#, but I’d put my 2 cents in for Oxygene. Especially since you come from Delphi (as did I. I used ALL the versions of “Delphi” starting with Turbo Pascal so I go WAAAY back with the pascal language. I think the last version of Delphi I used was 9). I haven’t looked at the RemObjects C# for quite a while, but one of the things I really like about Pascal that C# doesn’t have is local procedures. And there are many other things that I prefer in pascal. So as Marc says, it is a personal preference, but I hope you give Oxygene a real shot.

There are a lot of examples in C# on the web. The good news is that you can use RemObject’s oxidizer to copy paste a bunch of C# and have it convert it to pascal. I used to do that a lot when I started.

I also haven’t looked at DevExpress for quite a while, but I found WPF all that I needed. It is so easy to make new components in WPF that I never looked for 3rd party stuff. Much easier than the Delphi stuff used to be and I assume still is.

(Bob Russell) #12

Many thanks for your thoughts - ah, so many contributions of good advice - the challenge is that they tend to point in different directions! Interesting that you stopped Delphi at Delphi 9, I felt that Delphi 10 was the last best - before they went all (badly) multi platform and complicated and bug ridden and …

On your specific points,
Local Procedures - yes I agree
Oxidiser - yes useful, provided I’ve figured out what I’m doing in the first place!
WPF - yes, I think I’ve finally decided to bite the bullet, even though XAML based stuff still feels strange, particularly when I want it to be user defineable dynamic stuff, which in Delphi I would have coded. Re DevExpress, in the Delphi past, I did play with their Quantum Grid, but eventually coded my own stuff. Looking today, however, their controls, like Grids and Dashboards, have a sophistication which I’d be hard pressed to match, so I’ll probably invest in that.

In summary, I’m thinking of a mixed approach -
WPF with RemObjects C# for set up and UI based stuff, using DevExpress for UI Layout / Controls, then Oxygene for the computational / algorithm based stuff of the Application. Most of my applications tend to need a common look and feel from a UI / User Configuration point of view, then individual operational/functional aspects, so separating like this might work well.

All I’ve got to do now is learn all this, preferably in the next 10 minutes!

Still, this gives life its meaning doesn’t it! :smile:

Bob Russell

#13

One thing you need to consider is that you might have problems if you want to work with others or sell your software.

As long as you work alone and only sell licences to use your software you can do whatever you want. Use Oxygene, Hydrogene, Silver, … whatever you like. Once you sell the software itself and not only licences to use it (i.e. you sell the source code) using esoteric and/or non-standard and incompatible systems might be a problem.

For example, my employer just bought a certain UWP app. It bought the app itself, not just licences to use. It’s written in C++/CX. That’s not ideal but tolerable. If it were written in any of the RemObjects languages it’s highly unlikely we would have bought it. We would have gone for one of the several alternatives we had.

In this scenario using a supposedly “better C#” is a disadvantage. There is one C# and that’s the C# Microsoft produces, the one tracked in the Microsoft GitHub repos, etc. It’s the C# csc.exe accepts and the meaning it assigns to the code it accepts. It’s the same language used in .NET Core, Mono etc. (csc.exe also supports the -langversion command-line options to specify C# version if you want to maintain compatibility with Mono, for example.)

If you tell me you’re giving me “C# code” and this code doesn’t compile under csc.exe or does something other than intended, that not C# in my book. I won’t accept this code and I doubt I’m the only one. The so-called “RemObjects C#” is not C#. Keeping the Hydrogene name (as with the other languages) would have been better and more honest.

Using GCC extensions in the Linux kernel or VC++ extensions on Windows is kind of alright because reasons, but “new ActiveXObject” ain’t JS and C++/CX (or C++/CLI) partial classes aren’t C++.

Again, as long as you work alone and don’t sell the source code itself it’s probably fine, but otherwise you should seriously consider this issue.

(marc hoffman) #14

Reminds me of when we first shipped RemObjects C# and Miguel de Icaza quipped on Twitter that it “wasn’t C#” because we didn’t have (full) generics support (yet). Turned out what we had then was was more than Xamarin actually had — and we added full generics literally weeks later, Xamarin never did. Go figure.

(Alan Olson) #15

Haters gonna hate hate hate hate hate…

#16

Would it be better to “bite the bullet” and move all my learning and development effort to C#? (This would immediately give me easier access to learning and examples)

I think C# is very readable from a Delphi users stand point, considering who the lead architect for C sharp is :smiley:

I have yet to find any C# snippets that I would not understand, would love to see some if you can share.

(Alan Olson) #17

Personally, I find Oxygene/Pascal syntax so much easier to read than C#. Again, this is all so personal to each developer, and again this is another feather in RO’s hat when they give you the option to mix and match Pascal, C#, Swift and Java.

(Theo) #18

A am just new to Oxygene. As I came from VB.Net I have no problem with the .Net stuff and In the past (long time ago when the dinosaurs walked around) I worked a few years with Delphi 1 and 2. So the Pascal language is also familiar.

I could easily have switched to C# (done a lot with it already), but I just do not fancy this C-ish+java-ish (+old delphi influences) language. I really don’t want to fill my days writing and reading this bastard language.

And indeed Pascal is easy to read - easy to write and easy to maintain (because of the type definitions, you never lose insight of your class structures).

(Wilfred Smith) #19

Bob,

I’m in a similar situation. However, I have experience with all the Elements languages…though I’m a bit light on Java (don’t really like Java).

After a few weeks of intensive usage, I’ve come to look at Elements in a different light. It’s very freeing NOT to have to choose a particular language. In fact, my intended approach now is to mix and match. For one of my projects, Pascal seems the most logical. For another, I plan to use a bunch of MIT-licensed Swift code. One day, I imagine C# will be a logical project choice, and if I’m drinking, I may even delve back into Java.

The most exciting thing is that my function libraries aren’t tied that heavily to one language or platform. I’m still working out how to hack my Objective C++ and Elixir code in a uniform way, but once I get that figured out, it may end up being a coin toss for a while - which language I use for a given set of functions.

It’s so liberating…

I’m hoping that RemObjects approach, moving forward, will be to let each language be true to its design, while providing reasonably glue logic that lets us continue to interoperate with other languages. I do Go and Haskell as well as some Node.JS/Vue.JS; those are a lot harder to draw on. I’m also trying to come up with a good UI framework of my own that targets the types of applications I write…trying to figure out programmatic creation of UI components so that I don’t have to learn each OS’ design tools. In fact, I also bought a license for RubyMotion so that I can create my own domain-specific languages for some of it.

I think the days of knowing only one programming language and living/dying by it are over. You need to be able the choose the right tools for the job. I agree with Theo that we don’t want muddy languages that have mish-mashed their strengths. We want the best Object Pascal, with sensible glue for linking with other languages, the best Swift, the best C# and (I have trouble using best as an adjective for anything related to Java, but) yeah…

(Bob Russell) #20

Many thanks to all who replied. Lots of good thoughts. The general impression is that the mix of languages is the strength, so I’ll go with that as a learning opportunity!

Regards

Bob Russell