Live data from Hacker News

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

jonlennartaasenden.wordpress.com

101–110 of 162 posts

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

#101

Earlier quoted context omitted.

I'm overall surprised at how unpopular/unknown wxWidgets is when the discussion turns to cross platform UI toolkits. I've used it a lot, as well as other popular toolkits (Qt, GTK, etc.) and I find that wx is, at the very least, the least bad option and overall programming in it hasn't been a pain, regardless of which binding I used. I guess my only complaint would be that it's a bit harder to do something way outsid…

I am surprised too. It is easy to talk to the devs about issues and also the documentation is good. There are some rough spots here and there but all in all I am really baffled why you don't see more use of it. I use it in C++ for all my GUIs.

The wxPython demo (which spawns many apps that show use of many widgets, including complex ones), is very good too. And is a non-trivial wxPython app itself. Separately downloadable from wxPython itself, last I used it. All apps come with source (of course), good for learning from and adapting to your own app needs.

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

#102

Earlier quoted context omitted.

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

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.

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.

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

#103
post #41

Earlier quoted context omitted.

As someone that also used languages designed by Anders I'm also a huge fan of his work. Too bad there are just a few quality interviews with him: https://www.artima.com/intv/anders.html

There's a chapter from Anders on [1]. 1: https://www.amazon.com/Masterminds-Programming-Conversations...

Right! I remember now buying the book just to read the chapter about Anders. Was not disappointed. (for the record other "masterminds" were also interesting).

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

#104
post #83
post #38

Earlier quoted context omitted.

I am not sure what you mean under marginally. Delphi and FreePascal/Lazarus have no troubles producing 64bit executables. I have ongoing commercial product in Delphi and it is 64bit only.

Was it available in Delphi in 2016?

It was available since Delphi XE2 which was released in 2011.

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

#105
post #62
post #39

Earlier quoted context omitted.

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).

Yep really safe, Google and Microsoft security centers can confirm that.

Security centers can also confirm that any other language / software / system has holes.

I am not Microsoft/Google/etc and do not give flying hoot about their language preferences. I ran my own business and my clients are happy. As already said not a single complaint.

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

#106
post #39

Earlier quoted context omitted.

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).

While unsafe memory access can have consequences for stability, it has much broader implications than that. A system can keep running reliably while being heavily exploited.

I am really tired of this FUD. Any system can be like this. You can have perfectly memory safe language and still be compromised. If you have enough dosh you hire experts and have them try to poke holes in your systems or analyze whether those have been compromised already. Until then all this security talk is not worth much.

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

#107
post #105
post #62

Earlier quoted context omitted.

Yep really safe, Google and Microsoft security centers can confirm that.

Security centers can also confirm that any other language / software / system has holes. I am not Microsoft/Google/etc and do not give flying hoot about their language preferences. I ran my own business and my clients are happy. As already said not a single complaint.

Not 70% caused by memory corruption bugs, I guess said clients are not a security target.

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

#108

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

[deleted]

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

#109
post #106

Earlier quoted context omitted.

While unsafe memory access can have consequences for stability, it has much broader implications than that. A system can keep running reliably while being heavily exploited.

I am really tired of this FUD. Any system can be like this. You can have perfectly memory safe language and still be compromised. If you have enough dosh you hire experts and have them try to poke holes in your systems or analyze whether those have been compromised already. Until then all this security talk is not worth much.

I don't see how it's FUD. Yes, any system can have security problems, but some are more likely to than others. "Just try harder" is no solution. With equal effort, better (suitable) tools still give better results.

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

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

Post reply on HN