Jump to content
Die Holländer

Delphi and "Use only memory safe languages"

Recommended Posts

41 minutes ago, dummzeuch said:

Actually, in my case it sometimes is "just because I can". I use Delphi not only to pay my bills, sometimes I just want to have some programming fun, and I imagine I'm not alone.

 

But yes, there are actual reasons to use features in Delphi that are frowned upon by some people, even the discouraged goto.

You're correct, of course. I just found the "just because you can" charge to be dismissive. He doesn't get that there are good reasons to use these features. Saying they are only used "just because you can" is ignorant, but also arrogantly so.

Share this post


Link to post
1 hour ago, JonRobertson said:

Hopefully not with :classic_rolleyes:

 

Shift-Alt-W (MMX Convert with statement) is a good friend of mine when "migrating" legacy Delphi code.

Even with has its uses. 

 

But a convert tool that can remove them sounds really interesting. Is that part of Uwe's MMX explorer?

Share this post


Link to post
2 minutes ago, dummzeuch said:

Is that part of Uwe's MMX explorer?

Yes, although more of a helper. Removes the with identifier do [and begin/end statements if present] and copies "identifier." to the clipboard so you can easily paste it where needed.

 

It does not automatically determine which fields need the "identifier." added. Very simple example:

 

Before:

  with Form1 do begin
    Left := 200;
    Top := 100;
  end;

Invoke MMX Convert with:

 

image.thumb.png.190e0693145aa008ee0d2a2f46bd2f28.png

 

After:

  Left := 200;
  Top := 100;

And "Form1." is in the clipboard to be manually pasted where needed.

  • Like 1
  • Thanks 2

Share this post


Link to post
Posted (edited)
On 4/15/2024 at 10:49 AM, Brandon Staggs said:

You're correct, of course. I just found the "just because you can" charge to be dismissive. He doesn't get that there are good reasons to use these features. Saying they are only used "just because you can" is ignorant, but also arrogantly so.

I think you're missing the point of this thread  -- which, BTW, I did not start. This has nothing to do with me. If you like waving sharp knives and axes around when people are saying, "Hey! That's DANGEROUS!" why are you lashing out at THEM and calling THEM names?

 

This isn't MY fight! 

 

As an aside, do you have any idea how many thousands of GUNS are taken off of people at TSA checkpoints at airports around the country? I suspect you'd call people who defend the need for TSA checkpoints ignorant and arrogant as well. 

Edited by David Schwartz

Share this post


Link to post
7 minutes ago, David Schwartz said:

As an aside, do you have any idea how many thousands of GUNS are taken off of people at TSA checkpoints at airports around the country? I suspect you'd call people who defend the need for TSA checkpoints ignorant and arrogant as well. 

Wow, you just drew a parallel between using pointer math and carrying weapons on to planes. I'm pretty sure this thread just jumped the shark.

 

I'll refrain from engaging in a conversation about personal sovereignty and weapons here, because it obviously has nothing to do with Delphi having features for doing pointer and bitwise math, LOL.

Share this post


Link to post
Posted (edited)
14 minutes ago, David Schwartz said:

If you like waving sharp knives and axes around when people are saying, "Hey! That's DANGEROUS!" why are you lashing out at THEM and calling THEM names?

I think this is more like telling a chef he shouldn't dare use a knife because knives are too dangerous and needs to learn how to prepare his food without knives and if he doesn't then he is like people who carry weapons into airports. Or something.

Edited by Brandon Staggs

Share this post


Link to post

Can we stay on the topic, please?

Are there any practical languages that are applicable to writing the same variety of solutions as Delphi, that are actually memory safe?

Even if you manage your memory in Delphi, it is not hard to get corrupted data due to a dangling or misdirected pointer, even in Delphi.

  • Like 2

Share this post


Link to post
Posted (edited)
On 4/16/2024 at 10:04 PM, Lars Fosdal said:

Are there any practical languages that are applicable to writing the same variety of solutions as Delphi, that are actually memory safe?

A solid question!

I don't know all the languages out there, but Java and C# (which are more memory safe than Delphi because of their GC), loose quite a bit of speed because they have to spend some time to check the GC and decide what to clean up (release). EVEN if they would spend very little on this task, they have to "stop the world" from time to time. There is no way to use such a language in time-critical systems (I worked on such a system in the past).

 

Therefore, these safer languages, have to pay a price for their safety. I am curious if there is any language out there that is as fast as Delphi and more memory safe.

 

From what I heard, Rust is not using a GC, while still being fast and safe. I would like to see some speed comparison between Delphi and Rust. I heard that its speed is only slightly smaller than C++'s speed (and from here we can extrapolate to Delphi's speed). But its compilation time is even higher than C++ compilation time, which compared to Delphi... well... we all know how ridiculous C++ is at this chapter. 🙂

Also, Rust cannot do GUI natively, like Delphi. So, you cannot even compare Delphi and Rust at this chapter. In Rust, you must opt for GTK, QT (ha ha ha) or do some web-based GUIs - with all their known drawbacks. So, I would say, Rust is more oriented towards "systems" (DB, servers, automations, embedded systems, robots, etc.) not towards desktop apps.

 

So, as you Lars said, I would like to see a language that is memory safe and executes fast, and compiles fast and comes with 500 visual components out of the box.

 

 

__________


Note:

Note: When I say Delphi is safe, I assume that the programmer played safe and didn't abuse the pointers and didn’t override Delphi’s strong typing system. I worked on a system that look like it was written by a C programmer. Procedures like DoSomething(var P); all over the place, and half of the parameters passed are raw pointers. But as somebody said above, give a bold programmer a safe language, and it would find a way to abuse it. It would take a bit more creativity than in Delphi which puts the pointers (almost directly) on the table, but sure you can screw up in the end.

Edited by FreeDelphiPascal

Share this post


Link to post
Posted (edited)

Why are Delphi developers so obsessed with doing GUI - I assume most software that operates the world is non-GUI stuff. And I also believe that this is typically the software that should be rock solid. The code that crashed Ariane 5 or caused security vulnerabilities in the recent past was hardly some GUI application.

 

And Delphi code is only comparably fast with other languages that are top-tier in that category when you write it in a non-idiomatic way (i.e. pointers) - read some mormot Code if you don't believe me.

 

Just one example:

In other languages it does not matter if you are using some indexed-based loop (if that is even allowed) or some for-in/for-each loop - the compiler there knows its stuff and turns it into the fastest code possible while not sacrificing any safety.

Sometimes the performance is even better when you are using built-in functions because internally the runtime and/or compiler devs did some incredible work optimizing stuff. Here is just one of the many examples of .NET 7.

 

In Delphi, you almost always pay a cost for every abstraction although the compiler could make it zero-cost - one of the major tasks of modern compilers: enable the developer to write idiomatic and descriptive/declarative code without sacrificing performance.

Edited by Stefan Glienke
  • Like 4

Share this post


Link to post
5 minutes ago, Stefan Glienke said:

Why are Delphi developers so obsessed with doing GUI - I assume most software that operates the world is non-GUI stuff

I have a lot of respect for your knowledge and experience, seeing some of the work you have done. However, I think that is a fairly bold assumption.

 

Since 1996, I have preferred Delphi over other development tools/languages/frameworks. I do not enjoy doing GUI work. But I believe a lot of what "operates the world" is line of business apps, whether they be for commerce, government, health care, or hundreds of other industries.

 

Computers can't read our minds (thankfully). And voice recognition is not that reliable. I see proof of that every time my mother-in-law sends a text. :classic_laugh:

Share this post


Link to post
Posted (edited)
2 hours ago, JonRobertson said:

But I believe a lot of what "operates the world" is line of business apps, whether they be for commerce, government, health care, or hundreds of other industries.

And unless they are implemented as thick 2-tier clients directly accessing some shared database they probably talk to some backend code where the interop with other systems is implemented.

 

But let me make a slight correction about the particular Delphi situation: I know some people successfully build mobile apps but the majority are Windows (and some Mac OS) desktop applications

I am also leaving out all the web stuff because Delphi does not play a significant role in that area (yes, I know about the various frameworks for doing web stuff with Delphi), and depending on what technology is used most of it is backend code.

 

There has to be some reason why some recently very famous programming languages don't have some easy-to-use UI frameworks - either because they run almost everywhere including your toaster which makes it hard to provide some all-in-one solution (how often have UI frameworks tried that already?) or because it's code that does not require some rich UI.

Edited by Stefan Glienke

Share this post


Link to post
2 hours ago, Stefan Glienke said:

Why are Delphi developers so obsessed with doing GUI

Isn't the reason that Delphi is good at building GUI apps, at least it was for vcl back in the day. And it's still good for pure Win32 apps. 

  • Like 2

Share this post


Link to post
5 minutes ago, Stefan Glienke said:

unless they are implemented as thick 2-tier clients directly accessing some shared database

Unfortunately, many are still just that.

Share this post


Link to post
On 4/16/2024 at 12:39 PM, Brandon Staggs said:

Wow, you just drew a parallel between using pointer math and carrying weapons on to planes. I'm pretty sure this thread just jumped the shark.

 

I'll refrain from engaging in a conversation about personal sovereignty and weapons here, because it obviously has nothing to do with Delphi having features for doing pointer and bitwise math, LOL.

Uh, no, it's the TSA that PREVENTS you from carrying weapons onto planes! TSA is there to PROTECT PEOPLE FROM THEIR OWN STUPID  IDEAS.

 

One of them that some people make is, "the only SAFE plane is one where EVERYBODY is armed!" In the computing field, that would be like saying, "We don't need the language or compiler to protect us from bad coding practices because ... WE KNOW WHAT WE'RE DOING!

 

Code reviews and compiler checks (both compile-time and run-time) are like the TSA of software dev teams. Yet in my experience, they're all talk and no walk -- that is to say, I may have participated in two or three code reviews in the past 20 years, only because they were mandatory for some reason or other. We had agile demos every sprint, but NOBODY ever looked at the code. (One project I worked on briefly was required by the client to do regular code reviews as part of their Agile process. But most of the time was spent listening to a lecture by someone followed by people commenting on the funky variable names and how the code itself was structured. There was no effort to look at the code's logic itself. I don't consider these "code reviews" since they never uncovered anything meaningful. Like, what if TSA never found any guns even when they were planted? That has happened at some airports, to be sure.)

 

As I've mentioned elsewhere, at one place I worked, I found over 100 instances of bugs in the code of a large software product that stemmed from 8 erroneous coding patterns that were spread throughout the code using a copy-and-paste coding practice employed by the original programmer. I wrote up a paper documenting them and sent it to the team and my management team. Then I set up a code review meeting to discuss my findings in detail and Management cancelled it with a note saying we were too busy working on a deadline to get distracted with this "nonsense". I tried everything I could think of, and was eventually kicked to the curb because they just didn't want anybody to know about this crappy code. And these guys claimed they were totally committed to climbing this latter of ISO 900x, CMMI, and other high-level certifications to show they had it on the ball.)

 

And, oh, BTW, these errors were all due to memory faults that were mostly "invisible" to not just the compiler, but human readers. They had been in the code for over a decade at that point, causing all sorts of weird and unpredictable errors to show up. Their extensive test suites were unable to detect them. Exactly the things we're talking about here. Where's TSA when you need them?

 

Programmers all like to think we're smart and are capable of writing great code that "breaks the rules" SAFELY -- even those considered "unsafe". The problem isn't now, but what might happen later on down the road?

 

How many incidents turned up when compilers switched from 16-bit code to 32-bit code, and hand optimizations using pointers broke? Ditto for 32-bit to 64-bit code. How many people have the presence of mind to add conditional compiler statements there -- WHEN THEY WROTE THE CODE -- that raise a compiler warning when something they DID think of actually breaks the code LATER?

 

Better yet, how many things did they NOT think of? The older and more experienced you are, the more likely you are to think of more situations to be guarded against, right? But that's just one set of eyes.

 

How many people actually DO participate in regular code reviews and DO look at stuff like this? 

 

 

Share this post


Link to post
Posted (edited)
On 4/22/2024 at 2:53 AM, FreeDelphiPascal said:

 

I don't know all the languages out there, but Java and C# (which are more memory safe than Delphi because of their GC)

 

Sorry, but while GC might address SOME issues, it's hardly a panacea. There's a memory manager you can link into Delphi that lets you turn on things that scan for stuff and flag things that turn up, both in real-time and when the program quits. 

 

There are syntactically correct expressions that Delphi will compile without any hints or warnings that are deadly. Most of them are hangovers from old TurboPascal days that haven't been addressed, mostly because the code they allowed is not used today.

 

 

Edited by David Schwartz

Share this post


Link to post
Posted (edited)
On 4/22/2024 at 10:19 AM, Stefan Glienke said:

 

Just one example:

In other languages it does not matter if you are using some indexed-based loop (if that is even allowed) or some for-in/for-each loop - the compiler there knows its stuff and turns it into the fastest code possible while not sacrificing any safety.

 

This is an interesting example.

 

Off-by-one errors are extremely common, especially when you first start programming. Over time, you learn to prevent them.

 

Considering Delphi:

 

Given this declaration: var ary[10] : char; str[10] : string; 

 

One might be tempted to write:

 

for var i := 0 to 10 do  ary[ i ] := '';

 

and similarly

 

for var i := 0 to 10 do str[ i ] := '';

 

The first loop would blow up when i = 10, and the second would blow up when i = 0. And the compiler would fail to flag either as a possible problem.

 

A smarter programmer might write:

 

for var i := Min(ary) to Max(ary) do ary[ i ] := '';

for var i := Min(str) to Max(str) do str[ i ] := '';

 

But the safest way is to use this syntax (when it makes sense):

 

for var ch in ary do xyz(ch);

for var ch in str do xyz(ch);

 

There are other variations that can attract off-by-one errors (while ... do, repeat ... until, etc.) that the compiler is helpless to do anything about.

 

What's needed is a syntactical way to totally AVOID such off-by-one errors in the first place.

 

Well, the for ... in syntax is the safest, but it's not valid in some use cases -- like if you want to initialize the contents of the array, because it yields a value, not an index. Some languages have the ability to let you say "foreach ..." or "for ... each ...", but that's still a decade away from showing up in Delphi, if it ever will.

 

So we're left to use far less efficient libraries to provide these common-sense solutions, or just go bare-knuckle and let the cards fall where they may.

 

There are plenty of ways to make the language "safer" in many such respects, but if nobody is willing to actually make the compiler changes needed then it's a wasted discussion.

 

 

Edited by David Schwartz

Share this post


Link to post
8 hours ago, David Schwartz said:

Considering Delphi:

 

Given this declaration: var ary[10] : char; str[10] : string;

[dcc32 Error] Project1.dpr(10): E2029 ',' or ':' expected but '[' found
[dcc32 Error] Project1.dpr(10): E2029 '(' expected but ';' found
[dcc32 Error] Project1.dpr(10): E2029 Expression expected but ';' found
 

Share this post


Link to post
for var item in arr do

This is generally to be preferred, but sometimes you want the index as well as the item. In Python we write

for index, item in enumerate(arr):
	print(f"arr[{index}] = {item}")

The absence of such a feature, which also relies on tuple unpacking, makes such loops in Delphi less convenient. This is pretty much the only reason for still using classic for loops.

Share this post


Link to post
1 hour ago, David Heffernan said:

for var item in arr do

This is generally to be preferred, but sometimes you want the index as well as the item. In Python we write


for index, item in enumerate(arr):
	print(f"arr[{index}] = {item}")

The absence of such a feature, which also relies on tuple unpacking, makes such loops in Delphi less convenient. This is pretty much the only reason for still using classic for loops.

 

This should definitely be available in Delphi. Maybe in 5 years?

Share this post


Link to post
Posted (edited)
2 hours ago, dummzeuch said:

[dcc32 Error] Project1.dpr(10): E2029 ',' or ':' expected but '[' found
[dcc32 Error] Project1.dpr(10): E2029 '(' expected but ';' found
[dcc32 Error] Project1.dpr(10): E2029 Expression expected but ';' found
 

Aside from that, did you get anything from reading the post? (I don't have a compiler in my head, and I figured if I didn't show the declarations then someone would ding me on that.)

 

 

Edited by David Schwartz
  • Like 1

Share this post


Link to post
5 hours ago, David Schwartz said:

Aside from that, did you get anything from reading the post? (I don't have a compiler in my head, and I figured if I didn't show the declarations then someone would ding me on that.)

My point is that you can't declare variables or types like this in Delphi. This is C like syntax. In Delphi you have to give a low and a high limit for an array. So at least you don't have to guess.

Share this post


Link to post
1 hour ago, David Heffernan said:

You can for short strings

Oh, yes, I had totally forgotten about short strings. And also about that stupid idea of making strings zero based.

Share this post


Link to post
1 hour ago, dummzeuch said:

Oh, yes, I had totally forgotten about short strings. And also about that stupid idea of making strings zero based.

It would make far more sense for strings to be zero based. They are only one based because short strings stored their length in element 0.

Share this post


Link to post

They kept start index 1 to stay compatible with the short strings. At some point it might be desirable to change it, but ... well... Bye bye backwards compatibility.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×