I spent 13 years writing Object Pascal in Delphi full time, starting from Delphi 4 and ending right about where Embarcadero entered the scene.
They seriously dropped the ball by focusing on ticking enterprise boxes and charging insane amounts for it rather than evolving and fixing stuff.
Pascal was a great language, and I wonder how much we've lost by having it go by the wayside. It was strongly-typed, easy to read, cross-platform, produced native executables, and was lightning fast to compile and execute.
I say "was" a great language because it isn't widely used today. I miss it.
"Sane" strings that lead to incredible bloat and incompatibility, because there is no one true "sane" string type, so every module that doesn't know better forces their own way onto the user.
> "Sane" strings that discourage the developer from just coming up with a simple memory management scheme that fits the situation at hand.
"Sane" compilers that discourage the developer from considering the machine level instructions. It's turtles all the way down.
There's a reason that Python is so popular and it's not performance
Put another way: optimizing the management of strings in memory is almost never the best use of time to make progress toward an organization's objectives, and doubly so when that kind of micro-tuning can actually introduce security risks
I also don't really know why you assume that "sane" means "doesn't let you manage memory effectively".
That said, how many applications really are bottlenecked by string processing in the first place? I don't care if processing Unicode graphemes is slow, as long as it's correct and doesn't mangle users' names.
I always find it weird when people fret about bytes but not cycles, especially cycles that have to be spent waiting for memory reads.
Basically, no sane programmer in the 90s would be happy with a string type that wasted three bytes per object.
In other words, "reading the whole string from memory" could be a performance problem, but a less serious problem for machines of those days, compared to using a few more bytes to store the length.
… with all of them having been developed and run on 32-bit IBM mainframes and other big irons with «lots» of memory (e.g. 512 kB of RAM would have been considered huge in early 70-s).
C, on the other hand, was developed with limitations of early PDP-11's in mind that were often equipped with 56kB of RAM, so null-terminated strings in C was a rationalised design decision and/or a trade-off. Besides, both, UNIX and C started out as a research and a professional hobby project, not a fully fledged commercial product.
Since the internetworking had been inexistent slightly less than entirely, remote code execution that stemmed from buffer overruns was not an issue, either.
Read the DoD security assessment on Multics, https://multicians.org/b2.html
Afterwards you can read from Denis' own words,
> Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own.
Taken from https://www.bell-labs.com/usr/dmr/www/chist.html
So thanks to their fun, the world now suffers from C strings.
Precisely my point. The definition of fun is up for a personal interpretation.
In general, maybe, but we are talking about Borland here, so business logic apps mostly. String size is not a problem there.
For instance strncmp and (especially) strncpy make very little sense with C strings, but make sense for NUL-padded strings.
Though it was eventually eclipsed by C/C++/Objective-C on Apple platforms, I believe Pascal was the original application programming language for the Apple Lisa and Macintosh, and produced some revolutionary software in the 1980s.
Object Pascal/Delphi certainly enjoyed a fair amount of success in the 1990s.
Overall, it seems you didn't read my comment either. Or was I _that_ unclear?
I had a limited number of calls into a library and a need to do a few things that escape me with regard to interacting with -- I think -- an 16550 UART[0] and its driver, but I don't recall them being particularly nasty to deal with. I mean, all things relative -- I was expecting these to be nasty to deal with because they often involved inline assembler, so the problem of "making it behave with the string" wasn't quite as pressing as "what the hell am I actually doing here?" :)
[0] My huge project was a bulletin board system in the 90s.
Zero terminated strings still make some sense of course - ease of reading when looking at byte level representation, and moderate cost savings in packed structs (4, 8, or 16 byte strings). The former is why I zero terminate by default where possible, even when using a separate length field stored somewhere else (almost always).
And surely if you malloc(..) a block of memory in C and store a string in it, the memory allocation system is going to store how large a block that is anyway (even if it isn't visible to either C or Pascal probably.) I know not all strings will be malloc'd but a lot will be. And we seemed to deal with this overhead fine in the 90s?
> I know not all strings will be malloc'd but a lot will be. And we seemed to deal with this overhead fine in the 90s?
It's a common but deeply flawed assumption that allocations and lifetimes are so random that every little object should be individually allocated and later deallocated with malloc()/free() or with another generic allocator. I don't use malloc() to allocate string buffers - except in rare situtations of laziness, knowing it will come back to bite me later. Not only performance concerns but also the practical impossibility of matching each malloc() with a free() forbids that. Systems like RAII come to help to solve the latter issue, but I prefer to take the difficulty of matching everything up as an indication that the general approach is too complicated.
Instead I recommend to allocate strings using a fixed field (eg. char buf[16]) on a stack frame, or using a member in a struct, in order not to add any management overhead. Alternatively, for unbounded and dynamically sized strings, it's often a good idea to allocate them using linear allocators. For example, in a GUI renderer, it's a good idea to have a per-frame allocator that collects all allocations in a list of larger chunks, to minimize the allocation overhead to a few chunks (KBs to MBs) that were individually allocated from the system. With this, everything is freed using a single central function call after the frame was renderered and the data is now not needed any longer.
Except they were prefixes on the buffer which was bad and not sane, and greatly limited the size of the original pascal strings.
And technically they were UCSD strings, not standard pascal, and other implementations used e.g. padded strings.
Sounds like Go
Free Pascal/Lazarus has no problem with Linux or macOS. It was Delphi that stumbled around for some years about this, but presently can also be installed now on both. Of course, Delphi cost the big bucks.
"Break loop" being a function rather than keyword is serious PHP land.
It had better OO than C++, though. I admit it, they managed to have a sane and compact statically checked compilable OO.
OO in Object Pascal is a lot more sane than in C++, because the concept of an Object was more aligned to the existing Record type. It would be something like taking C and empowering its structs with methods. There wasn't an attempt to make radical changes, but simply extend the language with OO. Where with C++, in comparison to C, much more fundamental changes were made that created more conflicts in how the languages are used.
I could handle the xml madness but at least make sure the standard is a standard.
I'm pretty happy with rest apis on that front. I can always make them work.
There were some configuration behaviours on the standard that had opposite defaults.
Unlike gRPC, where RPC calls are just functions that take pure data arguments and return pure data structs, Cap'n Proto allows RPCs to return references to objects. The client can hold onto the reference and call methods on it, which invoke RPC calls, while the client and server runtimes keep track of what the references refer to. So you can treat remote objects as if they're local to your process.
This "location transparency" feature is at the heart of CORBA, and later, Microsoft DCOM and Java RMI. I've never used Cap'n Proto, but with CORBA/DCOM/RMI, this is a really powerful feature which allows you to work with APIs as if they're just in-process libraries. The downside is that if you pretend there's no network overhead, you might end up designing very inefficient applications, with each method call becoming a network roundtrip. It also means a client can, if you're not careful, "hog" a remote object and keep it from being deallocated, resulting in leaks or excessive memory usage.
Basic DCE-style RPC like gRPC is simpler and has more predictable performance, since you're forced to consider that you're talking to a remote API, just like REST.
Hiding network access and pretending it's all local is a recipe for disaster.
If you're writing a networked application, that's right up there on the list of things you need to focus on and never forget.
Delphi/Embarcadero went all out chasing enterprise dollars. The prices they charge burns holes in pockets for any little guys. Only in the last few years have they come to their senses with the free Community Edition and focusing again on making school/academic licenses easier to get and more accessible.
I googled it, but it wasn't clear if it was a buy-out, a rebrand, or something else.