
Why C# coders should shut up about Delphi (2016) - tones411
https://jonlennartaasenden.wordpress.com/2016/10/18/why-c-coders-should-shut-up-about-delphi/
======
trixie_
It's hard being an old programmer as some technologies that you used in the
past, that were more productive than certain technologies today, are no longer
popular. Creating client side apps in the 90s was arguably easier than
creating web apps today with the soup of html/css/js frameworks that are
changing every month.

edit/mass reply: I've been coding web apps with the rest of you guys for 20
years. The web isn't the problem, the tooling just isn't there yet. The
solution space is large and we're still in the 'throw things at the wall'
stage. It will eventually be figured out and web dev will be nice and stable
just like the backend and database layers.

~~~
danielbarla
Delphi certainly was supremely productive for the kinds of one-off, bespoke
enterprise apps that I was involved with, and it is valid to question why that
was the case. I don't think the tooling was necessarily all that superior, the
industry trend was simply way towards "slap a grid on top of that SELECT *
FROM Orders".

Clearly, there are many things wrong with that, but the fact that one could
whip up several screens and essentially ship them in a few hours makes it a
worthwhile thought exercise to think about what has been gained, and what
lost. Most enterprise apps that I encounter seem to be massively
overcomplicated for what they actually do.

~~~
jonnypotty
What the hell else to business apps do? I'm genuinely interested to know what
you think is the clear issue with showing users data from database tables.

~~~
danielbarla
I'm not sure I 100% understand your question, and it's also hard to respond
without more context.

Many Delphi apps back in those days were very lazily slapped together, with
thin layers of code (or none) on top of whatever queries got the job done.
There are performance issues, security issues, correctness issues (in terms
of: does the app allow you to do some things that should not be allowed).
There are also meta-level issues that came into play, as anything that did not
fit into the out of the box patterns was so outrageously more expensive to
develop that companies opted away from it, and in many cases UX suffered.

On the other hand, we have now overreacted in the opposite direction, with
many business apps having empty layers of code that do nothing except pass on
the exact same message to the next layer, because, well, "that's how it's done
in the real world", or something. Tons of boilerplate code get created that
never end up adding any real value. Other than this specific example, there
are plenty of YAGNI violations.

I prefer something of a balance between the two.

~~~
jonnypotty
I guess I don't buy the idea that anything has changed. If a straight query
shows you the data you need why would you put anything else but a thin layer
of software over the top? More software is worse, not better. Apps are still
lazily created by people downloading frameworks and plugging them into
whatever shit they happen to be creating at the time.

The issues you state. Security, correctness and performance. None of these are
solved by having more software. It might seem safer if you have more layers of
shit between the user and the valuable data, but it isn't. Having a mental
idea that now I use 'model and view' im going to be quicker, more correct or
more secure I think demonstrably isn't true.

~~~
danielbarla
This could be argued infinitely, I think. I do appreciate your points; yes,
simply adding code - by default or by itself - does not resolve those things I
mentioned. But, it's important to view my comments within the context of what
we were talking about, which was the defacto development style that grew
around Delphi, especially in the early days (before their libraries got
smarter). In the case of my "SELECT *" example, this was quite often literally
the case - queries were not optimised in the least bit regarding the columns
and rows that were being retrieved (mostly due to lack of awareness or
laziness). In terms of correctness, you can bet that business rules were
usually sprinkled around the UI in a happenstance kind of way, rather than
being collected in a relatively well defined, easy to verify and unit test
business object, say. Again, while I do agree in theory that "more code" does
not necessarily solve anything, these are the kinds of practicalities I am
arguing about, not on a pure level. The tooling was great for getting things
done instantly, but encouraged a laziness that caused a counter revolution
which went too far in the opposite direction.

~~~
jonnypotty
My work until recently was working on one of the Delphi apps you're talking
about. Not in terms of unoptimised queries but bad separation of business
logic and ui. But the product has passed between 4 diffent companies and is
over 20 years old now, I just don't see how you prevent these issues. I do see
what you're saying, but I think the real issues is humans which hasn't
changed.

~~~
danielbarla
Agreed, and I also don't have a real answer. At least, not a technological
one. The closest we can get it is a bunch of developers who care about a
product, ask themselves lots of "why do we do it this way", and "could this be
done better", and try to come up with some solid answers. Of course, with
products that survived 10+ years of maintenance, it is highly unlikely that
enough time will be afforded to any team.

Circling back to what I was trying to say with the first comment - I suspect
the rapid development promise and culture back in the day led to a lot of
these apps being developed. The tooling was just an enabler.

------
ComputerGuru
It’s a really good crash course on the shared origins of Delphi and C# plus a
brief reminder of all the modern features offered by Delphi that have flown
under the radar, but the anger and emotion is rather immature and really
detracts from the argument. Those words could have been better spent selling
its strengths further.

That aside, things have changed rapidly in the last five years in the C#/.NET
world first with .NET Native then with .NET Core and CoreRT. Exciting times,
really.

~~~
pjmlp
Unfortunately .NET Native seems to be on the way out with the project Project
Reunion, and it is not clear how AOT support will be like post NET 5 release.

So far they are demoing single file release, which is basically packing
everything into the same exe, but you get a JIT + MSIL instead.

~~~
ComputerGuru
I agree. .NET Native was always for the full framework only; I think CoreRT
was supposed to be the future there but it seems to be put by the wayside now
as with .NET Core 3 the official recommendation for AOT was Mono with no
mention of CoreRT in the roadmap. I would love to hear from Miguel what the
plans are there.

Ironically this comes at the same time that C# the language has become much
more usable without GC or with minimal GC thanks to the work that went into
implementing Span but I think that was more a matter of necessity to support
advanced async features for web usage (although I found it also made P/Invoke
a joy and eliminated virtually all my need for marshaling in a few codebases..
and would have eliminated all the performance issues the led the OS team to
abandon C#). It does seem that the ASP/Blazor team is driving the show and
calling the shots after the UWP failure in terms of adoption, and I’m not
seeing too much that would indicate it’s not the case even with Project
Reunion. I’ve been testing WinUI 3, MSIX, and WebView2 and have been
disappointed at the lack of story for putting all the parts together. It seems
like side-loading packages with sparse package projects is intended to replace
“native” UWP packages (“regular” AppX packages require .NET native unless
side-loaded and I can’t get apps pulling in WinUI/STJ/Buffers/etc code to
compile to .NET Native without an undeclared dependency on
System.Private.CoreLib and without serious hacks to enable RTTI which makes me
think they’re not meant to be used in that way any longer) but as always MS
isn’t very forthcoming about the future of UWP components more than a single
step at a time with all bets clearly hedged.

~~~
rogihee
In C# 9 there will be Source Generators, an easy way to generate code in a
build task before compilation. That will remove the need for Reflection in
many areas. Work is also underway to identify and remove all "linker"
dangerous code. Once the SDK is linker safe and has a lot less reflection, AOT
becomes a lot easier.

Mono is now part of the dotnet family so I suspect they are going to use that
for AOT in C# forwards. Starting with Blazor.

------
johnny_reilly
I love this post. My first gig was slinging Delphi for a telecoms company, my
second was C# and I've been involved with TypeScript since it was announced.
I'm a complete fan of Anders Hejlsberg work. To the extent that I gave genuine
consideration to naming one of my son's "Anders". My wife was not onboard.

~~~
cosmodisk
Could you have gotten away with naming him 'Sharp' instead?

~~~
folbec
No the logical name is C@, the great successor of C# (
[https://www.reddit.com/r/C_AT/](https://www.reddit.com/r/C_AT/) )

------
greatgib
> Some people seem to think that Delphi ended with version 7 back in the 90s

For me it is the case. Before Delphi was a really the greatest, smartest and
easiest RAD IDE. I even think that today dev tools are in a bad state and
nothing match what we once had back then! Especialy for creating 'responsive'
Gui apps easily.

Then, as shitty companies always do, they changed completely the tool and the
language with the new bad .net like one. Despite it to be wrong, they claimed
that this was better than what we had before and forced it on users. But it
was not anymore the Pascal Object that we liked!

------
rblatz
This is one heck of a rant. I couldn’t make it through to the end to see if he
ever got to the point.

~~~
KONAir
Delphi doesn't get the respect it deserves and C# people are mean.

~~~
thePunisher
We are all slaves to the whim of companies. Sure I could've continued using
Delphi beyond the late '90's but that would've meant that I wouldn't have been
able to hold a job as a developer in the '00's when .NET became all the rage.

Sometimes you just have to make do with what your customers want. And besides,
C# is IMHO the best computer language ever invented.

------
boznz
as a delphi Programmer who works next to a C# programmer we agree to agree
that neither of us will ever use the others shit language, we also agree that
all the other languages are worse :-)

------
Animats
Delphi is one of those languages which was a good product from a failing
company - Borland. Just as Modula 3 was a good product from a failing company
- DEC.

~~~
toohotatopic
Have they been failing by themselves or have they been destroyed by Microsoft,
e.g. [1]?

[1] [http://techrights.org/2009/09/14/ms-admits-draining-to-
destr...](http://techrights.org/2009/09/14/ms-admits-draining-to-destroy-
borland/)

~~~
andi999
I remember having read the story about Borland as follows: upper management
decided software products was a thing of the past and the company had to
switch to services. They did that and were out of business in 6 month.

~~~
pjmlp
Borland is still in business, although with another name, Embarcadero.

What happened was that decided indies weren't any longer their target
demographic and they wanted to be enterprise and focus on product and process
lifecycle management (PPLM) tooling instead.

So Delphi and C++ Builder got priced accordingly and they renamed themselves
to Inprise.

After 20 years they are trying to get back the indies with community editions,
but the damage is already done, and 100% of their customers are enterprise
shops.

So unless you are working for a Fortune 500, you will hardly come in touch
with Delphi / C++ Builder nowadays.

------
me551ah
I am a C# coder and I don't hate or talk about Delphi at all, I didn't even
know people still used it. ¯\\_(ツ)_/¯

------
pjmlp
Satire or not, one thing I do fully agree.

It was a big mistake not embracing AOT from day one, C++ wouldn't have kept
its king position in MS ecosystem if the original .NET had been like .NET
Native since the begging and kept Delphi like features for low level coding
(some of each are have been added since C# 7.x).

JIT support could still be an additional option as well, just like on
languages like Eiffel.

Instead we got NGEN (with basic optimizations), .NET Native (out of Midori,
but which seems on the death march with Project Reunion), MDIL/Bartok (out of
Singularity, used only in Windows 8.x), and all remaining efforts are from
third parties (Xamarin pre-acquisition), Unity, CosmOS.

And no one really knows if CoreRT will ever be integrated into the main
product.

~~~
lostmsu
I've been doing C# for over 10 years, and so far the AOT trend just gets in my
way. I would prefer .NET Core on all platforms to just function similarly to
.NET Framework on Windows: shared runtime(s) with major releases for breaking
changes, and point releases for in place improvements.

Case in point: when Windows RT jailbreak came out, my .NET Framework AnyCPU
apps just worked there. Now when I package, I very often have to list the
target architectures in advance.

When I hear Java announcing JIT in Java and catching up with C# on syntax
sugar, I feel that C# + .NET might start to lag behind in innovation.

~~~
pjmlp
.NET has had lot of innovation, AOT was there since the beginning via NGEN,
although there was never a big investment in its optimizing capabilities.

Then there was Axum, Cω, Phoenix Compiler (LLVM like in .NET), Singularity,
Midori, Rosylin, MDIL, .NET Native.

GraalVM goes back to MaximeVM and JikesRVM, so JIT in Java is also quite old.

What all these projects need is the money and political willigness to keep
driving them forward, and here is probably the main issue with some .NET
research projects, because since the begging Windows Development (which kind
of owns the C and C++ story) teams aren't that willing into having too much
.NET on their turf.

------
jasonlhy
I have colleague who still write desktop application in Delphi. I sometimes
work with him and to observe how he write Delphi, which is quite impressive,
and the performance is remarkable. However, it is really bad at some points.

First, it is not friendly to web, we have some special web requirements, we
decided to spawn a node process to do it.

Second, the tooling is so much better in Visual Studio. And the compiler is so
much smart with sophisticated and syntactic analysis.

Last but not least, it really lacks 3rd party libraries so people always need
to implement themself.

C# may not be the best option for any application. But it is general enough to
almost support every types of application.

------
JamesBarney
I kept waiting for the tangents to end and the reasons for why Delphi was
great would start.

He never got around to it.

------
bsder
Except that C# worked on 64-bit OS's practically from the start and Delphi--
still only marginally does.

And this isn't theoretical--Altium actually did a _full code rewrite_ in order
to get off of Delphi because of this.

~~~
dmz73
Unfortunately C# and the rest of .NET ecosystem (and for that matter Java and
rest of JVM) are not fully 64bit capable to this day and will probably not be
fully 64bit capable for the next decade if ever. What do I mean with this?
.NET and JVM native arrays use 32bit indexes and most standard container
classes also use 32bit indexes so you cannot have more than 2^31 elements. Who
needs that many elements in the array? No-one who develops in these
environments...because they can't have them so they move to something that
can.

~~~
olvy0
I think you can, but it does involve a configuration switch [0]. The index
accessor for arrays has always been allowed to be of type long, the runtime
was the one causing the trouble. As for List<T>, it's still problematic since
all the methods still accept an int.

[0] [https://docs.microsoft.com/en-
us/dotnet/framework/configure-...](https://docs.microsoft.com/en-
us/dotnet/framework/configure-apps/file-
schema/runtime/gcallowverylargeobjects-element)

------
mikeabraham
I miss Delphi. I miss Clipper Summer '87\. I miss BeOS. I miss simpler times.
Those were good times....

------
locusm
This brought back fond memories of C++ Builder and the Jedi OSS library.

~~~
locusm
It lives! [https://wiki.delphi-
jedi.org/wiki/JVCL_Component_Overview](https://wiki.delphi-
jedi.org/wiki/JVCL_Component_Overview)

------
binarycrusader
_Some 3 years after this satire post was published..._

Satire and (2016)

------
ville
(2016)

------
cttet
This was published in 2016.

And the title included "C# coders". I am not a C# coder, but all C# GUI coders
I know had praised Delphi for its design and convenience for GUI...

edit:grammar

~~~
Jaruzel
The one thing that bugged me about Delphi apps on Windows, was that they used
their own custom buttons on the forms (with little graphics of crosses and
ticks etc.). I am not a Delphi programmer, but I always wondered why this was.

~~~
pjmlp
Because developers want to be fancy.

That was an additional custom controls library that you could enable, you
could choose to use the standard L&F as well.

It was also available for the C++ products from Borland and it traces back to
their first Windows 3.x compilers.

My first experience with it was in Turbo Pascal for Windows 1.5 (the last TP
before Delphi was born).

Also, similar libraries existed for MFC or plain C Win32, sold by companies
like ComponentOne.

------
thePunisher
This blog is not an article but a rant full of half-truths and outright lies.
The author doesn't realize that most C# developers have no knowledge of the
history of both Pascal and C (I'm old enough to know) because they were born
decades after these languages came into being.

The author also misses the point that C and C++ are systems programming
languages (for developing operating systems, device drivers and low-level
stuff such as compilers) and Pascal is an application programming language. C
and C++ were pressed into service for developing application programming
because many nerds thought it cool to have the fastest benchmark speed test
result and ignored the fact that these languages are unsafe to use on a day-
to-day basis. That's why C# and Java were invented.

~~~
monocasa
I don't think the distinction you're making about C and C++ being systems
languages, and Pascal being an application language totally holds.

Pascal is a totally fine system s language. AEGIS (a from scratch Unix like)
was written in Pascal and by all accounts was a great option at the time.

And what makes C and C++ unsafe exists in Pascal.

~~~
FpUser
Modern C++ is actually pretty safe. Pascal is reasonably safe as well if you
know what you're doing. And all this safety talk is over-hyped anyways. Just
learn hot to program properly. I do not really remember when was the last time
I had problem with "safety" in either Delphi or C++. My commercial apps (C++,
Delphi and C for firmware run for years without a single crash report).

~~~
thePunisher
C++ is safe if you know how to use it properly, but this does incur overhead
and many people aren't willing to incur any overhead because they want the
fastest raw speed available. So they usually mess around with C like
constructs in their C++ programs.

Pascal OTOH is 100% safe no matter what you do because you can't access
pointers directly or do pointer math or out-of-bounds array access. The
pointers available in Pascal are "managed" pointers which prevent you from
accessing the underlying machine hardware.

This all incurs a little overhead, but you won't find any insecure Pascal
programs due to memory mismanagement.

~~~
monocasa
You can typecast integer to pointers in Pascal. It's not memory safe.

~~~
FpUser
You know, I can always jump from that cliff. Still keep wondering why don't I
do it.

~~~
monocasa
Please take your projected inadequacies elsewhere.

~~~
FpUser
I could not reply to your message one below so moving it here: > _You 're the
one that has three times now commented on one of my posts trying to prove to
yourself that everything you're doing is fine and there's nothing you could be
doing better from a security perspective._

I am just expressing my opinion. You know, taking distraction from mundane
work to talk technical things. I am not trying nor do I need to prove how I do
my development/design and what tools do I use and frankly I do not give a
flying hoot what others might think about it. I run my own business after all.

As to you particular point of language being unsafe because it allows typecast
pointer to integer: allowing unsafe features in my view does not make language
unsafe as long as it provides safe way of doing things as well. It is called
flexibility in my book.

Security wise: could I've done better? Sure. Anything could be done better but
you've probably heard about the law of diminishing returns. Does the fact that
I use language that have unsafe feature automatically make my software unsafe
if I do not use said features - big fat NO. Even if do use such feature (and
rarely but sometimes I do for the sake of efficiency) it does not really
change the main point.

~~~
monocasa
What's your business?

As senior engineer at a security conscious firm, who used to freelance by
writing exploits for code written by developers with your attitude, I want to
make sure we don't use your software.

~~~
FpUser
You can save this theatricals for Broadway.

~~~
monocasa
I'm serious. I'd like to make sure that we're not using your code.

Are you seriously afraid to promote your business because it might be attached
to your comments? That should tell you something.

~~~
FpUser
I think you should go and get help if you do not understand why people on
newsgroups often prefer to stay anonymous.

And if you are as you say major security guy as you claim you probably already
checked all the software you allow to use for security breaches. So you either
found the problem and got rid of said software or you're just full of it.

And if your business recommendations to your company are base on "attitude"
picked from internet chat or shall I say you personal likes why don't you
submit this conversation to your employer.

And finally the last thing I feel like doing is promoting my business/services
to people like yourself.

~~~
monocasa
> And if you are as you say major security guy as you claim you probably
> already checked all the software you allow to use for security breaches. So
> you either found the problem and got rid of said software or you're just
> full of it.

Do you know what an 0 day is?

> And if your business recommendations to your company are base on "attitude"
> picked from internet chat or shall I say you personal likes

My recommendations to my employer are based on many things, including overall
security posture. The world's best engineers ship memory unsafety bugs in C
and C++, including modern C++. Your statements belay an overall lack of
respect for the problem space, which in my experience leads to an increase of
issues, even above the general steady state.

> why don't you submit this conversation to your employer.

I plan to as soon as there is actionable information.

> And finally the last thing I feel like doing is promoting my
> business/services to people like yourself.

You're the one who's been regularly deciding to comment on my posts trying to
convince yourself that everything you're doing is fine, and you can't do
better. "People like [my]self" are just telling you that you can do better,
and only when you decide to go out of your way to start shit.

I'd prefer if you stopped commenting on my posts.

