Delphi 2024
-
I am curious. What's the current state of the Delphi programmimng language and their IDE? Is it something modern and shiny, or is it a treasure trove of
?
It does not seem to be very fashionable. But what's your opinion?
-
@BernieTheBernie my impression last time I checked things from embarcadero they are just milking people that are taking their time to migrate to something else
-
@BernieTheBernie It looks like they're just milking the cow as much as they can.
The Community edition is still free, so that's what I used the last time I needed to build a quick GUI app, since I used Delphi for more than 10 years and know it a bit.
I would never pay for this
-
@BernieTheBernie said in Delphi 2024:
Is it something modern and shiny, or is it a treasure trove of
?
"Modern and shiny" definitely doesn't exclude the possibility of "a treasure trove of
".
-
When I was first starting out, all I had access to was BASIC and assembly language. Then I got a copy of Delphi's great-grandfather, Borland Turbo Pascal, which I thought was pretty good. By the time it morphed into Delphi I had already moved on to other stuff.
-
@Gern_Blaanston Turbo Pascal was great. It was fast and relatively easy to understand. Once I got what it wa doing, I was then able to transfer my knowledge to C. C was less great, but with a whole lot more code available and less restricted memory models; back in the days of DOS 6, C had near and far pointers, and Turbo Pascal had a single weird hybrid memory model (with annoying limits on the sizes of memory blocks that needed tricky code to work around).
The x86 real mode memory model was horrific, really.
-
@dkf said in Delphi 2024:
@Gern_Blaanston Turbo Pascal was great. It was fast and relatively easy to understand.
Yes. Pascal was sort of similar to BASIC and I was able to figure it out pretty quickly.
Once I got what it was doing, I was then able to transfer my knowledge to C. C was less great, but with a whole lot more code available and less restricted memory models
I was never able to get interested in C, and then C++ .... just made my brain hurt.
-
@Gern_Blaanston said in Delphi 2024:
I was never able to get interested in C, and then C++ .... just made my brain hurt.
C++ pretends to be a nice language, but has more hidden traps than a whole Indiana Jones movie intro.
-
@Gern_Blaanston said in Delphi 2024:
Turbo Pascal
Oh ye good old days of the early 1990ies (or was it late 1980ies?).
-
@dkf when I got my hands on it, probably quite a while later, Turbo Pascal (and probably Turbo C too) had 6 different memory models to deal with near and far pointers. IIRC they called them something like tiny, small, medium, compact, large, and huge. Tiny was the .com style, with only near pointers and CS, DS, and SS all the same segment, while huge was the only far pointers other extreme. The options between mixed them differently (with medium and compact, or whatever they were called, both sitting in the middle with no clear linear ordering.)
It also had a library feature for “overlays”, which was something weird I don’t quite remember for handling stuff too large to fit into memory.Never used any of that stuff, but I still enjoyed it as a learning language.
-
@BernieTheBernie said in Delphi 2024:
@Gern_Blaanston said in Delphi 2024:
Turbo Pascal
Oh ye good old days of the early 1990ies (or was it late 1980ies?).
And Turbo Basic and .... Turbo Assembler.
Object Oriented Assembly Language
-
@HardwareGeek said in Delphi 2024:
@BernieTheBernie said in Delphi 2024:
Is it something modern and shiny, or is it a treasure trove of
?"Modern and shiny" definitely doesn't exclude the possibility of "a treasure trove of
".Not only does it not exclude it, I'm fairly sure including it is a requirement.
-
@topspin said in Delphi 2024:
Turbo Pascal (and probably Turbo C too) had 6 different memory models to deal with near and far pointers. IIRC they called them something like tiny, small, medium, compact, large, and huge. Tiny was the .com style, with only near pointers and CS, DS, and SS all the same segment, while huge was the only far pointers other extreme. The options between mixed them differently (with medium and compact, or whatever they were called, both sitting in the middle with no clear linear ordering.)
I used Turbo Pascal in university, but I don't remember anything about it. I did use Turbo C (and later Turbo C++) at home after I graduated, and IIRC those are exactly the same memory models it had.
-
@HardwareGeek then maybe it was only in that one and I remembered wrong.
-
@topspin said in Delphi 2024:
@dkf when I got my hands on it, probably quite a while later, Turbo Pascal (and probably Turbo C too) had 6 different memory models to deal with near and far pointers. IIRC they called them something like tiny, small, medium, compact, large, and huge. Tiny was the .com style, with only near pointers and CS, DS, and SS all the same segment, while huge was the only far pointers other extreme. The options between mixed them differently (with medium and compact, or whatever they were called, both sitting in the middle with no clear linear ordering.)
I think it effectively used one of the memory modes in the middle (the one with large data pointers but small code pointers). I remember that you could address more than 64kB of memory, but individual memory entities (arrays, really; strings had much smaller limits) had to be no more than 64k in size, as it wouldn't issue segment adjustment instructions for offset accesses. Which required gross workarounds when working with larger datasets.
Most C code at the time either used the tiny (all near pointers) or the huge models (all far pointers). I eventually learnt Linux so I could have sane memory handling for everything by default. (Except... early Linux wasn't ELF but it's own insane mess. I'm pleased that changed, despite some misgivings at the time.)
It also had a library feature for “overlays”, which was something weird I don’t quite remember for handling stuff too large to fit into memory.
That was for handling code that was too large to fit into 64kB. It would load the other code from disk, overwriting the current code segment, but that was OK because the code would be in the overlay think at the time, which was always put in the same place in the code segment.
Never used any of that stuff, but I still enjoyed it as a learning language.
Quite. I'm very glad my code never needed that.
-
@Gern_Blaanston said in Delphi 2024:
When I was first starting out, all I had access to was BASIC and assembly language. Then I got a copy of Delphi's great-grandfather, Borland Turbo Pascal, which I thought was pretty good. By the time it morphed into Delphi I had already moved on to other stuff.
I used Delphi 5 and 2005 and it was quite nice too.
Their community was quite helpful that they offer quite some libraries free of charge that you'd have to pay for if you work in other programming languages.
-
@dkf said in Delphi 2024:
@topspin said in Delphi 2024:
@dkf when I got my hands on it, probably quite a while later, Turbo Pascal (and probably Turbo C too) had 6 different memory models to deal with near and far pointers. IIRC they called them something like tiny, small, medium, compact, large, and huge. Tiny was the .com style, with only near pointers and CS, DS, and SS all the same segment, while huge was the only far pointers other extreme. The options between mixed them differently (with medium and compact, or whatever they were called, both sitting in the middle with no clear linear ordering.)
I think it effectively used one of the memory modes in the middle (the one with large data pointers but small code pointers). I remember that you could address more than 64kB of memory, but individual memory entities (arrays, really; strings had much smaller limits) had to be no more than 64k in size, as it wouldn't issue segment adjustment instructions for offset accesses. Which required gross workarounds when working with larger datasets.
I did some googling. You're right, it apparently used a fixed one of those models (but I did remember the names correctly), the "Large" one. That used far pointers everywhere but, as you said, no segment adjustment so no blocks spanning several segments.
Memory Models and Far Pointers
The Amiga port for Simulated Evolution is making good progress, but it’s not quite in a releaseable state yet. There also, so far, isn’t much we haven’t already seen; maybe a few …
-
@dkf said in Delphi 2024:
strings had much smaller limits
IIRC pascal strings use a length prefix instead of the null terminator which is common in C. Thus the string length is bounded by the size of the length field, which would probably have been (and might still be) 1 byte, meaning strings cannot be longer than 255 bytes.
-
@topspin said in Delphi 2024:
6 different memory models to deal with near and far pointers. IIRC they called them something like tiny, small, medium, compact, large, and huge.
laughs in Motorola 680xx
-
@PleegWat said in Delphi 2024:
@dkf said in Delphi 2024:
strings had much smaller limits
IIRC pascal strings use a length prefix instead of the null terminator which is common in C. Thus the string length is bounded by the size of the length field, which would probably have been (and might still be) 1 byte, meaning strings cannot be longer than 255 bytes.
Exactly that. Counted strings are a (very) good idea (especially if you also track the buffer size for modifiable strings), but using a single byte for the length isn't; a max length of 255 was always minuscule. C, for all its faults, at least didn't impose a small artificial upper limit on string sizes.
-
@dkf said in Delphi 2024:
@PleegWat said in Delphi 2024:
@dkf said in Delphi 2024:
strings had much smaller limits
IIRC pascal strings use a length prefix instead of the null terminator which is common in C. Thus the string length is bounded by the size of the length field, which would probably have been (and might still be) 1 byte, meaning strings cannot be longer than 255 bytes.
Exactly that. Counted strings are a (very) good idea (especially if you also track the buffer size for modifiable strings), but using a single byte for the length isn't; a max length of 255 was always minuscule. C, for all its faults, at least didn't impose a small artificial upper limit on string sizes.
Btw, .NET strings are also Pascal string internally (because C# and Delphi shares the same father), with size field of int32 (i.e. max. 2,147,483,647 characters)
-
@dkf said in Delphi 2024:
@PleegWat said in Delphi 2024:
@dkf said in Delphi 2024:
strings had much smaller limits
IIRC pascal strings use a length prefix instead of the null terminator which is common in C. Thus the string length is bounded by the size of the length field, which would probably have been (and might still be) 1 byte, meaning strings cannot be longer than 255 bytes.
Exactly that. Counted strings are a (very) good idea (especially if you also track the buffer size for modifiable strings), but using a single byte for the length isn't; a max length of 255 was always minuscule. C, for all its faults, at least didn't impose a small artificial upper limit on string sizes.
And any advantages of null-terminated strings in splitting strings up can be countered by supporting string slices. I think rust does that, but I do not know if that is on top of null terminated or counted strings, or something yet different.
-
@BernieTheBernie said in Delphi 2024:
@Gern_Blaanston said in Delphi 2024:
Turbo Pascal
Oh ye good old days of the early 1990ies (or was it late 1980ies?).
Definitely 80s.
I used Turbo Pascal on CP/M, so that must have been 1985-ish.
If I remember correctly, initially in version 2 but shortly after I started using it, version 3 came out.Never used it much on PC, because when I went to university in 1987 they had just switched to Modula-2 for the initial programming courses.
-
@ixvedeusi said in Delphi 2024:
@topspin said in Delphi 2024:
6 different memory models to deal with near and far pointers. IIRC they called them something like tiny, small, medium, compact, large, and huge.
laughs in Motorola 680xxI always thought that was a far more rational architecture. Too bad it's not the one that became popular.
-
@cheong said in Delphi 2024:
@dkf said in Delphi 2024:
@PleegWat said in Delphi 2024:
@dkf said in Delphi 2024:
strings had much smaller limits
IIRC pascal strings use a length prefix instead of the null terminator which is common in C. Thus the string length is bounded by the size of the length field, which would probably have been (and might still be) 1 byte, meaning strings cannot be longer than 255 bytes.
Exactly that. Counted strings are a (very) good idea (especially if you also track the buffer size for modifiable strings), but using a single byte for the length isn't; a max length of 255 was always minuscule. C, for all its faults, at least didn't impose a small artificial upper limit on string sizes.
Btw, .NET strings are also Pascal string internally (because C# and Delphi shares the same father), with size field of int32 (i.e. max. 2,147,483,647 characters)
No, that's because .NET 1.0 is 90% clone of Java. Or because, as @dkf said, it's an obvious and good idea.delegateis the Delphi part .NET
-
@Kamil-Podlesak said in Delphi 2024:
@cheong said in Delphi 2024:
@dkf said in Delphi 2024:
@PleegWat said in Delphi 2024:
@dkf said in Delphi 2024:
strings had much smaller limits
IIRC pascal strings use a length prefix instead of the null terminator which is common in C. Thus the string length is bounded by the size of the length field, which would probably have been (and might still be) 1 byte, meaning strings cannot be longer than 255 bytes.
Exactly that. Counted strings are a (very) good idea (especially if you also track the buffer size for modifiable strings), but using a single byte for the length isn't; a max length of 255 was always minuscule. C, for all its faults, at least didn't impose a small artificial upper limit on string sizes.
Btw, .NET strings are also Pascal string internally (because C# and Delphi shares the same father), with size field of int32 (i.e. max. 2,147,483,647 characters)
No, that's because .NET 1.0 is 90% clone of Java. Or because, as @dkf said, it's an obvious and good idea.
-
@PleegWat said in Delphi 2024:
And any advantages of null-terminated strings in splitting strings up can be countered by supporting string slices. I think rust does that, but I do not know if that is on top of null terminated or counted strings, or something yet different.
C++'s
stringandstring_vieware that as well (though plainstringis still guaranteed to be nul terminated). One of the problems is that you need to go back to nul terminated strings for system calls and similar, so the legacy of C strings will continue to hang around.I think the C strings had a place for a while, but nowadays, spending something like 3 extra bytes on a 32-bit size is probably the better choice. (Knowing the size upfront enables a few neat optimizations for some common use cases, e.g., when used as keys in a hash table.)
-
@cvi said in Delphi 2024:
(Knowing the size upfront enables a few neat optimizations for some common use cases, e.g., when used as keys in a hash table.)
The key optimization is that you can do amortized string growth costs (provided you track capacity and length separately). Building strings by concatenation of little bits onto the end of a working buffer is an extremely common thing in a lot of code, so making it very fast is a massive win.
-
@dkf said in Delphi 2024:
provided you track capacity and length separately
Random thought
:
Why is capacity always tracked separately? For standard growth strategies, capacity could be made a pure function of size.
-
@dkf I was thinking of subsampled hashing. You can't really do this with nul-terminated strings, since you can't skip things. Table lookups with strings are arguably even more common than building strings from pieces, but the optimization only helps with relatively long keys, so it's not clear who wins.
-
@topspin That's actually kinda interesting. You might still want an "exact size" buffer for largely immutable things, but that's still just a bit you can smuggle in somewhere (*cough*pointer alignment*cough*).
-
@topspin said in Delphi 2024:
@dkf said in Delphi 2024:
provided you track capacity and length separately
Random thought
:
Why is capacity always tracked separately? For standard growth strategies, capacity could be made a pure function of size.Linear has its own problems with excessive buffer growths, and exponential is only cheap if the factor is 2.
-
@PleegWat said in Delphi 2024:
@topspin said in Delphi 2024:
Why is capacity always tracked separately? For standard growth strategies, capacity could be made a pure function of size.
Because shrinking the used space is also a thing. Less common, but does happen. You could shrink the buffer then... but nobody does that.
Linear has its own problems with excessive buffer growths, and exponential is only cheap if the factor is 2.
The cost of using a larger factor can be fine. It doesn't matter that much unless you need very large allocations or extra fast reallocation. Exponential is exponential, after all. Linear growth is definitely worse because that ends up making things take excessive amounts of time copying the buffer from one place to another. (It's the Schlemiel the Painter problem.)
A different approach is to keep a sequence of buffers. That's cheaper when you have bounded sized add and remove, but the code is quite a bit more complicated. It tends to only be seen in the guts of high-performance I/O libraries (where copies are death).
-
@PleegWat I think MSVC has 1.5. GCC has 2. Not sure what clang/libc++ does.
Folly and other custom implementations also have lower than 2 (1.5 seems common).
With 2, you can never fit the new allocation into a combination of old ones. With lower factors, you can. (E.g., with 1.5 the sequence is something like 1, 2, 4, 6, 9, 13, 19, .. and 13 = 1+2+4+6.)
-
@cvi said in Delphi 2024:
@PleegWat I think MSVC has 1.5. GCC has 2. Not sure what clang/libc++ does.
Folly and other custom implementations also have lower than 2 (1.5 seems common).
With 2, you can never fit the new allocation into a combination of old ones. With lower factors, you can. (E.g., with 1.5 the sequence is something like 1, 2, 4, 6, 9, 13, 19, .. and 13 = 1+2+4+6.)
For some reason, that sequence reminds me of Fibonacci numbers. It isn't... but they might be a reasonable growth strategy. Not that I care enough to investigate...
-
@dkf Yeah, I'm pretty sure I've seen that in discussions around this (essentially growth rate of golden ratio). But I don't think it works well, because the previous alloc is still alive when you make the next one. Also, irrational numbers = eww.
Even with 1.5 you have to wait 4 allocs before you fit into the accumulated space of previous ones. Going lower means you can do it earlier.
-
@cvi I'd just double the capacity every time. Not worth trying to be smarter without putting enough effort in to be possibly publishable (as a case study if nothing else).
-
@Kamil-Podlesak said in Delphi 2024:
@cheong said in Delphi 2024:
@dkf said in Delphi 2024:
@PleegWat said in Delphi 2024:
@dkf said in Delphi 2024:
strings had much smaller limits
IIRC pascal strings use a length prefix instead of the null terminator which is common in C. Thus the string length is bounded by the size of the length field, which would probably have been (and might still be) 1 byte, meaning strings cannot be longer than 255 bytes.
Exactly that. Counted strings are a (very) good idea (especially if you also track the buffer size for modifiable strings), but using a single byte for the length isn't; a max length of 255 was always minuscule. C, for all its faults, at least didn't impose a small artificial upper limit on string sizes.
Btw, .NET strings are also Pascal string internally (because C# and Delphi shares the same father), with size field of int32 (i.e. max. 2,147,483,647 characters)
No, that's because .NET 1.0 is 90% clone of Java. Or because, as @dkf said, it's an obvious and good idea.delegateis the Delphi part .NETNot really. They've diverged quite a bit since, but .NET 1.0 was, if anything, "a 90% clone of Delphi" rewritten to look like Java, because Microsoft wanted something that would compete with Java and be palatable to Java developers, but the guy they got to do it was the inventor of Delphi.
-
@Gern_Blaanston said in Delphi 2024:
When I was first starting out, all I had access to was BASIC and assembly language. Then I got a copy of Delphi's great-grandfather, Borland Turbo Pascal, which I thought was pretty good. By the time it morphed into Delphi I had already moved on to other stuff.
Wait. Are you me?
-
@Mason_Wheeler said in Delphi 2024:
@Kamil-Podlesak said in Delphi 2024:
@cheong said in Delphi 2024:
@dkf said in Delphi 2024:
@PleegWat said in Delphi 2024:
@dkf said in Delphi 2024:
strings had much smaller limits
IIRC pascal strings use a length prefix instead of the null terminator which is common in C. Thus the string length is bounded by the size of the length field, which would probably have been (and might still be) 1 byte, meaning strings cannot be longer than 255 bytes.
Exactly that. Counted strings are a (very) good idea (especially if you also track the buffer size for modifiable strings), but using a single byte for the length isn't; a max length of 255 was always minuscule. C, for all its faults, at least didn't impose a small artificial upper limit on string sizes.
Btw, .NET strings are also Pascal string internally (because C# and Delphi shares the same father), with size field of int32 (i.e. max. 2,147,483,647 characters)
No, that's because .NET 1.0 is 90% clone of Java. Or because, as @dkf said, it's an obvious and good idea.delegateis the Delphi part .NETNot really. They've diverged quite a bit since, but .NET 1.0 was, if anything, "a 90% clone of Delphi" rewritten to look like Java, because Microsoft wanted something that would compete with Java and be palatable to Java developers, but the guy they got to do it was the inventor of Delphi.
Yeah, yeah, I remember these arguments from that time
Nobody ever explained what does this "Delphiness" actually mean (except he delegate, as I have already mentioned), but apparently it was very real. Trust me bro.
At the same time, I have had a job at a "Windows+AS/400 shop" and spent some time converting C# code to Java (a vice versa) by a simplesedscript.TBH, since that time, C# did indeed diverged a lot and mostly for the better.
-
@Kamil-Podlesak said in Delphi 2024:
@Mason_Wheeler said in Delphi 2024:
Not really. They've diverged quite a bit since, but .NET 1.0 was, if anything, "a 90% clone of Delphi" rewritten to look like Java, because Microsoft wanted something that would compete with Java and be palatable to Java developers, but the guy they got to do it was the inventor of Delphi.
Yeah, yeah, I remember these arguments from that time
Nobody ever explained what does this "Delphiness" actually mean (except he delegate, as I have already mentioned), but apparently it was very real. Trust me bro.
At the same time, I have had a job at a "Windows+AS/400 shop" and spent some time converting C# code to Java (a vice versa) by a simplesedscript.TBH, since that time, C# did indeed diverged a lot and mostly for the better.
Actually, no. C# is what Delphi would be under C family syntax. It's development is not related to Java.
The one that is related is J#, one of the first .NET family inhabitant that has been ditched shortly after 2005 version.
-
@Kamil-Podlesak said in Delphi 2024:
@Mason_Wheeler said in Delphi 2024:
@Kamil-Podlesak said in Delphi 2024:
@cheong said in Delphi 2024:
@dkf said in Delphi 2024:
@PleegWat said in Delphi 2024:
@dkf said in Delphi 2024:
strings had much smaller limits
IIRC pascal strings use a length prefix instead of the null terminator which is common in C. Thus the string length is bounded by the size of the length field, which would probably have been (and might still be) 1 byte, meaning strings cannot be longer than 255 bytes.
Exactly that. Counted strings are a (very) good idea (especially if you also track the buffer size for modifiable strings), but using a single byte for the length isn't; a max length of 255 was always minuscule. C, for all its faults, at least didn't impose a small artificial upper limit on string sizes.
Btw, .NET strings are also Pascal string internally (because C# and Delphi shares the same father), with size field of int32 (i.e. max. 2,147,483,647 characters)
No, that's because .NET 1.0 is 90% clone of Java. Or because, as @dkf said, it's an obvious and good idea.delegateis the Delphi part .NETNot really. They've diverged quite a bit since, but .NET 1.0 was, if anything, "a 90% clone of Delphi" rewritten to look like Java, because Microsoft wanted something that would compete with Java and be palatable to Java developers, but the guy they got to do it was the inventor of Delphi.
Yeah, yeah, I remember these arguments from that time
Nobody ever explained what does this "Delphiness" actually mean (except he delegate, as I have already mentioned), but apparently it was very real. Trust me bro.For the big obvious one, have a look at WinForms and how it looked and functioned so very much like the VCL, and not at all like anything Java was doing at the time.
-
@Mason_Wheeler said in Delphi 2024:
@Kamil-Podlesak said in Delphi 2024:
@Mason_Wheeler said in Delphi 2024:
@Kamil-Podlesak said in Delphi 2024:
@cheong said in Delphi 2024:
@dkf said in Delphi 2024:
@PleegWat said in Delphi 2024:
@dkf said in Delphi 2024:
strings had much smaller limits
IIRC pascal strings use a length prefix instead of the null terminator which is common in C. Thus the string length is bounded by the size of the length field, which would probably have been (and might still be) 1 byte, meaning strings cannot be longer than 255 bytes.
Exactly that. Counted strings are a (very) good idea (especially if you also track the buffer size for modifiable strings), but using a single byte for the length isn't; a max length of 255 was always minuscule. C, for all its faults, at least didn't impose a small artificial upper limit on string sizes.
Btw, .NET strings are also Pascal string internally (because C# and Delphi shares the same father), with size field of int32 (i.e. max. 2,147,483,647 characters)
No, that's because .NET 1.0 is 90% clone of Java. Or because, as @dkf said, it's an obvious and good idea.delegateis the Delphi part .NETNot really. They've diverged quite a bit since, but .NET 1.0 was, if anything, "a 90% clone of Delphi" rewritten to look like Java, because Microsoft wanted something that would compete with Java and be palatable to Java developers, but the guy they got to do it was the inventor of Delphi.
Yeah, yeah, I remember these arguments from that time
Nobody ever explained what does this "Delphiness" actually mean (except he delegate, as I have already mentioned), but apparently it was very real. Trust me bro.For the big obvious one, have a look at WinForms and how it looked and functioned so very much like the VCL, and not at all like anything Java was doing at the time.
Ok, fair enough, GUI libraries were nothing like those in Java. It was before "suicide by copy" became Microsoft's motto.
-
@Zerosquare said in Delphi 2024:
@Gern_Blaanston said in Delphi 2024:
When I was first starting out, all I had access to was BASIC and assembly language. Then I got a copy of Delphi's great-grandfather, Borland Turbo Pascal, which I thought was pretty good. By the time it morphed into Delphi I had already moved on to other stuff.
Wait. Are you me?
You're both @boomzilla, and boomzillaness is transitive, so yes.
Anders Hejlsberg - Wikipedia
