Why Should a C-Sharper Learn Delphi?

[Qasim Shahzad 0]

I plan to create some introductory videos for my DelphiTube channel on this topic:

Delphi for C-Sharpers

 

The question is, why should a C-Sharper (C# user) learn Delphi? I am definitely biased toward Delphi, but is it really beneficial for a C-Sharp user?

 

My thoughts are:

1. Learning another language is a good option.
2. Delphi can create standalone executable that do not need third-party frameworks.
3. You can build cross-platform native applications with Delphi.
4. It would be an easy move if you joined through the C++ Builder path.
5. Delphi is highly productive.

What's your point of view? Can you add some reasons? Please guide.

Thank you so much for your attention and participation.

[programmerdelphi2k 237]

@Qasim Shahzad

As the popular saying goes: Knowledge does not occupy space! (unlike knowledge books 🙂

 

That said, there's not much to argue about knowing something more and enriching your knowledge! What other arguments will be just rhetorical, and, in the end, will not make much sense to anyone who wants to gain knowledge! (like you).

 

Okay, maybe it's not as commercial or popular in the environment you work in. Bear in mind that the "market" will always dictate the rules!

 

But what about your personal fulfillment? If it is not suitable in your business environment, it may be to your personal satisfaction. And thus make your day-to-day more productive, even if you use another programming language at work!

[Qasim Shahzad 0]

Thanks @programmerdelphi2k

Those are valid points, and I totally agree with you here.

But then someone might say, why not learn Python or something else instead of Delphi? As you said, the market will dictate its rules. I believe there are productivity and life-cycle maintenance benefits to using Delphi. But how can we logically convey these benefits to others?
 

For example, we can say that Delphi can target many processors. Moreover, we can port our Delphi code to Free Pascal Compiler, and it can target many processor architectures. Like:

1. Intel x86 (16 and 32 bit)
2. AMD64/x86-64
3. PowerPC
4. PowerPC64
5. SPARC
6. SPARC64
7. ARM
8. AArch64
9. MIPS
10. Motorola 68k
11. AVR
12. JVM

[programmerdelphi2k 237]

@Qasim Shahzad  and more... 

• Build Native Apps 5x Faster With One Codebase ( Delphi1 running under Delphi11.3 compilation, yeah! it's possible, respecting the "changes over years")
• For Windows, Android, iOS, macOS, and Linux + Internet of Things (IoT)
• https://www.embarcadero.com/products/delphi/features/internet-of-things-iot

DONT FOGET: and the "BUGs...."  😂  but, where it does not exists, isnt?

Edited May 20, 2023 by programmerdelphi2k

[Qasim Shahzad 0]

Thanks @programmerdelphi2k
Yes some more great reasons.

What BUGs

[David Heffernan 2345]

5 hours ago, Qasim Shahzad said:

You can build cross-platform native applications with Delphi.

Can you? You can with VCL but FMX isn't native. 

 

5 hours ago, Qasim Shahzad said:

Delphi can create standalone executable that do not need third-party frameworks.

Is that really a significant advantage over C#? 

[programmerdelphi2k 237]

maybe a typo  

Quote

• RAD Studio gives your development team the tools they need to create high performance native multi-device apps.
• Prototype and develop native apps in standard C++ or the Delphi Object Pascal language for multiple devices simultaneously.
• Take full advantage of Multi-Core CPUs with the parallel programming library.

 

• How do true native apps differ from what others might call "native"?

  True native apps are script-free and run directly on hardware CPU delivering the following advantages: 

  • Fast – Uncompromised native device performance with full native API and CPU control when you need it, and not limited by or slowed by script interpreters and virtual machines.
  • Predictable – Apps run directly on the device CPU, as intended by the device vendors, and are not slowed by additional software layers and processes, such as random garbage collection.
  • Better User Experience (UX) – Apps take full advantage of device capabilities and performance.
• Many tool vendors are using the term "native" app development to describe web technologies and scripts wrapped into an app package to deliver an app-like user experience. This approach can impose limits on app performance and capabilities.

 

Quote

https://www.embarcadero.com/products/rad-studio/multi-device-true-native

 

Edited May 20, 2023 by programmerdelphi2k

[David Heffernan 2345]

It depends what native is important. FMX doesn't use native GUI widgets and toolkits. 

 

But it's native in the sense that the compiler emits code that runs on the metal. 

 

To me it feels like the former is an important limitation and the latter is just not relevant. 

[Qasim Shahzad 0]

2 hours ago, David Heffernan said:

It depends what native is important. FMX doesn't use native GUI widgets and toolkits. 

 

But it's native in the sense that the compiler emits code that runs on the metal. 

 

To me it feels like the former is an important limitation and the latter is just not relevant. 

Respected @David Heffernan. Thanks for your explanation. You are right. I think this is one of the main reasons Delphi does not natively support Right-To-Left Languages on Android because it is not using native components.

What is your view about FPC and its nativeness?

[David Heffernan 2345]

11 hours ago, Qasim Shahzad said:

What is your view about FPC and its nativeness?

I don't know about FPC, but FPC is just a pascal compiler. You are asking about libraries. And I certainly don't know anything about them. 

[David Schwartz 426]

I'd have a hard time justifying to anybody that there's a clear benefit in learning Delphi just for Delphi's sake, unless you just want to broaden your language horizons. There are very few Delphi jobs around, and most of them seem to be to help maintain legacy platforms or keep a system running while another team is migrating it to something else. And the language itself is several years behind where others are today.

 

Consider a sligtly different perspective....

 

How about also adding TMS WEB Core into the mix and say, "Here's a very simple and easy way to write WEB APPs that runs pretty much EVERYWHERE!" And, oh, BTW, you can also build native apps for several platforms that use common (FMX) or even native components if you like.

 

That is, give them a reason to learn this platform that's not nearly as easy elsewhere.

 

(I guess it begs the question of whether Delphi + WEB Core is unique enough to justify learning it on its own merits, or if it's just a way for old Delphi geeks to slide into a new application domain with minimal effort.)

 

Unlike IntraWeb (which has been around for over a decade), TMS WEB Core does not depend on a server or special run-time to make it work. It runs inside of the web browser because it's transpiled to javascript. 

 

That said, you'll probably need to also build some kind of REST service to provide back-end support for your app, and Delphi has several out-of-the-box solutions for that as well (not to mention, TMS has XData).

 

While you can use a bunch of common Delphi components (two different libraries TMS offers, both based on VCL components), you can also work entirely within the wider HTML/CSS/JS world and leverage any number of existing JS libs. 

 

Moreover, you don't even need to use the Delphi IDE! 

 

But the code you write is 100% Object Pascal that, with a bit of care, can be compiled and run as a normal Delphi program in Windows.

 

There is another benefit for C-Sharper's: the same guy wrote both platforms, and they're very similar, so the learning curve won't be very difficult.

[David Heffernan 2345]

49 minutes ago, David Schwartz said:

How about also adding TMS WEB Core into the mix and say, "Here's a very simple and easy way to write WEB APPs that runs pretty much EVERYWHERE!"

There must be lots of other ways to do this that use more mainstream languages

[357mag 2]

On 5/23/2023 at 3:28 PM, David Schwartz said:

I'd have a hard time justifying to anybody that there's a clear benefit in learning Delphi just for Delphi's sake, unless you just want to broaden your language horizons. There are very few Delphi jobs around, and most of them seem to be to help maintain legacy platforms or keep a system running while another team is migrating it to something else. And the language itself is several years behind where others are today.

 

Consider a sligtly different perspective....

 

How about also adding TMS WEB Core into the mix and say, "Here's a very simple and easy way to write WEB APPs that runs pretty much EVERYWHERE!" And, oh, BTW, you can also build native apps for several platforms that use common (FMX) or even native components if you like.

 

That is, give them a reason to learn this platform that's not nearly as easy elsewhere.

 

(I guess it begs the question of whether Delphi + WEB Core is unique enough to justify learning it on its own merits, or if it's just a way for old Delphi geeks to slide into a new application domain with minimal effort.)

 

Unlike IntraWeb (which has been around for over a decade), TMS WEB Core does not depend on a server or special run-time to make it work. It runs inside of the web browser because it's transpiled to javascript. 

 

That said, you'll probably need to also build some kind of REST service to provide back-end support for your app, and Delphi has several out-of-the-box solutions for that as well (not to mention, TMS has XData).

 

While you can use a bunch of common Delphi components (two different libraries TMS offers, both based on VCL components), you can also work entirely within the wider HTML/CSS/JS world and leverage any number of existing JS libs. 

 

Moreover, you don't even need to use the Delphi IDE! 

 

But the code you write is 100% Object Pascal that, with a bit of care, can be compiled and run as a normal Delphi program in Windows.

 

There is another benefit for C-Sharper's: the same guy wrote both platforms, and they're very similar, so the learning curve won't be very difficult.

I would say that just because the same man wrote both languages does not make them similar. Delphi is definitely different than C#.  C# is easier to grasp than Delphi is.

[dummzeuch 1505]

40 minutes ago, 357mag said:

I would say that just because the same man wrote both languages does not make them similar. Delphi is definitely different than C#.  C# is easier to grasp than Delphi is.

David was talking about the platform, not the language. That would be the dotNet framework and the Delphi VCL/RTL.

 

I can't really say whether that's true or not, I've never used dotNet and I'm unlikely to ever do that. (Unless after retirement I find that dotNet is a good solution for writing Linux programs for personal use and for fun, because I plan to ditch Windows when that time comes.)

[David Schwartz 426]

You don't need to copy an entire post (especially long ones) simply to reply to it. Just say'n....

 

14 hours ago, 357mag said:

I would say that just because the same man wrote both languages does not make them similar. Delphi is definitely different than C#.  C# is easier to grasp than Delphi is.

 

C++ was initially described as "c with classes". It was implemented as a pre-processor that ran before the C compiler. It translated this new code into C. The first several releases of the language were actually pre-processors. I don't recall the first actual C++ compiler being released until nearly 4 years after the first C++ pre-processor escaped from Bell Labs (circa 1989).

 

TurboPascal always had a 'record' type because it was derived from Pascal, and records were already in Pascal. TP7 added a new type called 'object'. I suspect it was experimental, and the next evolution of the language, targeted as TP8, added a new type called 'class' that looked a lot more like what C++ had (both were modeled after Modula).

 

The TP language team also did a couple of things that were very unusual for Pascal: One was that every definition of a 'class' was made so it derived from a common base object called 'TObject'. I believe there were two other OOP language did that at the time, but not C++.

 

The other was that every instance of a 'class' type was created from the heap, like in C++, so variables that referred to them were technically POINTER types; but to simplify things, the compiler was made to automatically de-reference them so you never needed to use the ^ operator with them. C++ lets you declare things as pointers by adding a '*' to their declaration (requiring '->' to dereference fields), and as references by adding a '&' instead of a '*' (allowing the 'dot' operator (.) to be used to de-reference fields, like in Records). ObjectPascal didn't have that distinction; it just ensured that every variable declared as a 'class' type could be used as simply as a 'record' type, that is without the '^' to de-reference them  as a POINTER. 

 

This just explains what happened to the language after TP7 was released. It was supposed to be TP8. But a funny thing happened on the way to releasing "Object Pascal" -- it got an IDE. The resulting product was code-named "Delphi" and instead of being named "Turbo-Pascal 8" as was planned, it was simply called "Delphi". At that point, the TP compiler family died and was superceded by Delphi's "Object Pascal". 

 

That said, I seriously doubt Microsoft would have hired Anders (or anybody) just for making these changes to the Pascal language. They'd have been far better off just hiring NIcholas Wirth who invented Pascal and Modula, among other languages. Besides, MS already had plenty of talent on-hand when it came to compilers. (And I'm not even sure Anders did this part. He was a member of the TP team that built Delphi, for sure.)

 

I don't know how long they were working on the IDE's design, but the team that built the Delphi IDE created something revolutionary for its time. Namely, it was built in the same language it supported -- Object Pascal. And it was designed to support "plugin components" that could themselves be built in the same language and installed into the IDE much as any other "plugins" might be.

 

Up to that point in time, everything Microsoft was doing that worked with "plugins" required them to be written in MSVC as a quirky kind of DLL. They evolved to become 'OCX' files, that I believe were called "Active-X" components. MS built a diagramming tool called Visio to demonstrate this wondrous technology, and the whole collection of plugins were so huge that a full set of them could crash the average desktop computer of the time. It's likely that Active-X technology laid the conceptual groundwork for the .NET framework.

 

Microsoft's reasoning for this was that by adding this single run-time library (.NET) to Windows, it would make all Windows programs much smaller since the runtime library would already be there. (Delphi has an RTL, and it's way, way smaller than .NET ever was!) BTW, Delphi has an option that lets you "compile as modules" that builds an EXE and a bunch of BDL units, which are basically DLLs. Most people just build a single EXE because managing a bunch of BDL and/or DLL files is just a horrific mess over time.)

 

Again, I don't know for sure, but I suspect Bill Gates wanted Anders to work for Microsoft to help them simplify their main programming platform and all of that huge overhead that the use of Active-X was creating. NOT because he helped adding classes to Pascal.

 

I've spent some time here and there with C# and Visual Studio ... enough to notice a couple of things they have in common, and one they do not. One is that the VS IDE is so similar to Delphi's IDE that it took me no time at all to get working in it. (Changing a few of the key mappings would have made it nearly identical.) I also found C# to share most of the common semantics of C++, something that Object Pascal also has in common. So the languages didn't seem that different to me, either. (Over time, the C# language has evolved considerably while Delphi's Object Pascal has mostly petrified -- something EMBT considers to be a "major feature" of the language.)

 

The other thing I noticed was how vastly different the two platforms worked regarding database connectivity. Microsoft created this generic connectivity layer that they added to Windows called ODBC, and C#/VS required you to set it up to connect with a DB server. Specifically, it was external to both the language and the IDE. As it happens, my understanding is that Anders was involved with the original Delphi development while another team was working on D2 that had database support integrated into it. Anders was hired by Microsoft after Dephi was released, and probably about the time D2 went into beta-testing, so he was not likely to have gotten much insight into how the plumbing for DB support was built into Delphi. (It showed up as "data-aware components", a completely separate implementation of the regular VCL components shipped in D1.) So the complete lack of integration of DB support into the VS and .NET platform is NOT surprising to see.

 

In contrast, Borland released their own DB tool called the Borland Database Engine, or BDE, with Dephi 2; it was a big improvement over ODBC for known servers. It worked hand-in-glove with Data-Aware Controls that made it ridiculously easy to build apps connected to DBs. Later, the BDE itself was superceded by better DB component libraries that had native connectors built-in for accessing DBMS servers in Windows. You can still use the older ODBC technology if you want, AFAIK. But the last time I played around with VC and C# (years ago), you had to create connections to your DB using ODBC first before you could work with your DB. It was always much simpler with Delphi.

 

In summary, I don't know how much Anders was involved in adding classes to TurboPascal, but that much alone sure wasn't worth hiring him to lead all of Microsoft's language and run-time platforms. It's easy to see how his experience with Delphi influenced Visual Studio and to a lesser extent how their dev platforms evolved from there, especially without the nicely-integrated support for DB access that Delphi has had since D2.