Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jonlennartaasenden.wordpress.com

Post reply on HN
Print view View original

111–120 of 162 posts

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

#111

Post by FpUser »

pjmlp wrote: post #107
FpUser wrote: post #105

Earlier quoted context omitted.

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.

My servers use proprietary protocols and one of the first thing my protocol handlers do is check validity of the input. You will not find generic "read until EOL/Whatever" in my code. The low level logic knows exactly what to expect at each point and how to validate it. All over encrypted connection.

Good luck hiring dedicated expert or team willing to break it. I am not Google and cost of trying to break my software where it matters far exceeds any potential benefits.

So sure, I am not the a prime choice as security target which makes it even better.

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

#112

Post by FpUser »

thijsvandien wrote: post #109
FpUser wrote: post #106

Earlier quoted context omitted.

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.

Let's just disagree. I think your definition of "better" is vastly different from mine. I also think that a mess most use as a current web development stack using "safe languages" poses way more danger security wise then my proprietary client/servers ever will.

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

#113

Post by ognarb »

tim-- wrote: post #46
AlexanderDhoore wrote: post #30

Earlier quoted context omitted.

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

They have not changed any licensing. They have changed the way they are releasing their product. The only thing really that is different here is the fact that they are pushing less code as open source for their stable LTS releases. If you rely on having a stable Qt, why not pay the company that develops the software? You and I, the developers that use Qt without paying for it, still get the latest and greatest Qt, wi…

Actually Qt was not always LGPL, it was first under the QPL, then the GPL, and now the LGPL. So it is quite an improvement from a license forbidding commercial uses to a permissive license.

There is also a legal framework to make sure Qt will remain open source forever: the KDE Free Qt Foundation.

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

#114

Post by jonnypotty »

danielbarla wrote: post #102
jonnypotty wrote: post #96

Earlier quoted context omitted.

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

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.

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

#115

Post by thePunisher »

monocasa wrote: post #32
thePunisher wrote: post #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-le…

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.

Pascal was originally an application programming language, not a systems programming language.

These days you can probably mix assembly within your Pascal code or access pointers directly with some custom language extensions, but these weren't part of the original Pascal specification.

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

#116

Post by thePunisher »

FpUser wrote: post #39
monocasa wrote: post #32

Earlier quoted context omitted.

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.

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

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.

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

#117

Post by thePunisher »

FpUser wrote: post #106
thijsvandien wrote: post #72

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.

But those would be logic errors, not memory management errors. If someone is stupid enough to pass user input directly to a shell or database then yes, they will get compromised.

But these comprise only 30% of all security errors as the research shows. Most are due to memory management issues.

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

#118

Post by tim-- »

ognarb wrote: post #113
tim-- wrote: post #46

Earlier quoted context omitted.

They have not changed any licensing. They have changed the way they are releasing their product. The only thing really that is different here is the fact that they are pushing less code as open source for their stable LTS releases. If you rely on having a stable Qt, why not pay the company that develops the software? You and I, the developers that use Qt without paying for it, still get the latest and greatest Qt, wi…

Actually Qt was not always LGPL, it was first under the QPL, then the GPL, and now the LGPL. So it is quite an improvement from a license forbidding commercial uses to a permissive license. There is also a legal framework to make sure Qt will remain open source forever: the KDE Free Qt Foundation.

Historically you are correct, yes. I should have had an asterisk and explanation next to 'always'.

The fun fact that this also brings up is that the KDE Free Qt Foundation also means that if Qt does not keep supporting open source Qt, then the framework code becomes licensed under the BSD.

It is literally in Qt's best interests to keep the open source community by it's side.

This does not detract from my point that the license of Qt is not changing.

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

#120

Post by karmakaze »

danielbarla wrote: post #45
trixie_ wrote: 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…

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…

Working on a number of quarantine projects, I have come close to this now. Currently make single fullstack repo for the app with backend and frontend code committed together and deployed separately. Client goes to Netlify. Backend to a hosted VM that can autoupdate from Github and apply schema migrations.

Local dev, autorefreshes the Vuejs frontend code (yarn serve) and backend autorefreshes with `air` if Go-based or Intellij debug hot-reload if Jvm-based. I can whip up a db schema, backend, and frontend in a day with a good amount of layout and styling. It just took repetition and templating a few things.

Which is to say it doesn't take a lot of tooling to be productive--as long as it's focused.

Post reply on HN