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.
Why C# coders should shut up about Delphi (2016)
101–110 of 162 posts
Re: Why C# coders should shut up about Delphi (2016)
#102Earlier 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.
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)
#103Earlier 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...
Re: Why C# coders should shut up about Delphi (2016)
#104Earlier 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?
Re: Why C# coders should shut up about Delphi (2016)
#105Earlier 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.
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)
#106Earlier 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.
Re: Why C# coders should shut up about Delphi (2016)
#107Earlier 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.
Re: Why C# coders should shut up about Delphi (2016)
#108This 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…
Re: Why C# coders should shut up about Delphi (2016)
#109Earlier 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.
Re: Why C# coders should shut up about Delphi (2016)
#110First, 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.