Live data from Hacker News

Why C# coders should shut up about Delphi (2016)

jonlennartaasenden.wordpress.com

21–30 of 162 posts

Re: Why C# coders should shut up about Delphi (2016)

#21
post #9

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 th…

Creating hello world and drawing trivial forms is just as simple with HTML/CSS/JS, you don't need a SPA MVC framework or component libraries or state management framework.

Looking back to VB and other WinForms RAD tools it's easy to do that stuff and there are HTML WYSIWYG tools but that double-click code behind logic doesn't scale - software these days is distributed, has more complex requirements and expectations. Once you bolt MVC or MVVM or whatever to one of those GUI toolkits you get very close to modern JS framework complexity.

Re: Why C# coders should shut up about Delphi (2016)

#22
post #15
post #4

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

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.

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.

Re: Why C# coders should shut up about Delphi (2016)

#24
post #13

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 wit…

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.

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.

Re: Why C# coders should shut up about Delphi (2016)

#25
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.

Re: Why C# coders should shut up about Delphi (2016)

#26
post #9

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 th…

Creating hello world and drawing trivial forms is just as simple with HTML/CSS/JS, you don't need a SPA MVC framework or component libraries or state management framework. Looking back to VB and other WinForms RAD tools it's easy to do that stuff and there are HTML WYSIWYG tools but that double-click code behind logic doesn't scale - software these days is distributed, has more complex requirements and expectations.…

I laugh because you'd think the distributed part would be the toughest one. But nope, it's pretty easy. In fact the client/server model was pretty well understood even in the 90s (or well before that even).

In my opinion what has exploded the complexity is the proliferation of environments. The execution environment of our software provides very few guarantees on what is available (no standard library) or even what language is supported (many JavaScript features and versions with varying support). That, combined with the explosion of devices including input modes, screen sizes, and resolutions has just made it extraordinarily difficult.

We don't even have standard ui primitives like we did in the past. Every major website is expected to have a team of world class designers and reinvent the wheel.

It doesn't need to be this way. But it's the way we have chosen. It has advantages, but I'd imagine the economic cost is enormous.

Re: Why C# coders should shut up about Delphi (2016)

#29
post #2

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.

I made it all the way. He doesn't, unless the point was C# devs are dummies who don't know that Anders in fact designed Delphi in addition to C#.

Re: Why C# coders should shut up about Delphi (2016)

#30
post #9

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 th…

I very badly want to get back to this. Maybe with Python and Qt on Mac?

I don't trust Qt licensing anymore. Whatever company owns Qt will forever try to squeeze it for money.

They recently changed their licensing AGAIN: https://www.qt.io/blog/qt-offering-changes-2020

Post reply on HN