50 Years of Pascal and Delphi Is in Power
blog.marcocantu.com
blog.marcocantu.com
But I would like to mention what exactly made Delphi so nice to work with: language enabling design-time information, run-time type information, flexible memory management (some of it automatic, but also possible to do it manually), 95% of time safety but still possible to mess with internals, component architecture, clear exception handling and a very nice community.
I've also worked on a Delphi based CRM and I've wasted man months of my life time on a task we called "checking forms". You see, Delphi's UI designer is (was?) pixel based (widgets have fixed x/y/w/h), but strings translated to different human languages have different lengths (in pixel). (Complicated by dynamically calculated and variable length strings.)
And so for every release, for every language version (of which there were like 15), engineers would click through every single form in this product. Then fix any widgets were the text was cut off specifically for that language manually in a shitty commercial i18n tool that can show you Delphi forms, but only the outlines of controls.
It took an engineer about 3 weeks of effort to go through the product in one language. I may never forget what "Ok" and "Cancel" mean in several languages I otherwise do not know at all.
Java and C# changed everything for me with their constraint based layouts. I believe later Delphi versions added that, but it was definitely after others lead the way.
(Maybe there was a better way to do it with Delphi, but this was >10 years ago ago, and the product was _old_ even back then, and it was my first job and I didn't question why things were done this way.)
The translation systems were really atrocious. I had to develop one myself because the ones that I evaluated were useless.
It took me a couple of weeks, but once I found the right (and only reasonable) way, with the help of library introspection features it was very easy to add new automated translations.
I wrote it down in my defunct blog, 15 years ago. I guess you didn't find it at the time.
WinForms designer is actual C# code, you can copy and execute that code outside of the designer. It's possible to search for references to a control in the designer, just the same as any other code. Often in Delphi, trying to accomplish the same thing in code as in the designer had a very obscure relationship. WPF feels much closer to the way Delphi did things, where your GUI is defined in different format than your code.
In WinForms, creating a new control requires, well, just write a class that descends from Control, compile, and then you can start using it. In Delphi, creating a new control means you need an independent project, compile it into a package, and figuring out how to install it. I remember fighting Delphi trying to understand the package management system, and it was way more complicated.
In WinForms, when you design a new control, it actually executes your code, so design time behaviors actually reflect what will happen at runtime. I remember having stuff in Delphi where a large control would be collapsed into a single line, and you couldn't actually tell what you were working with until you run it.
That's because the guy in charge of Delphi left for Microsoft and is still in charge of Visual Studio :)
Delphi – why won't it die? (2013)
The most serious problem I have with it (I can't afford Delphi, or I would buy my way out) is the lack of actual documentation. Sure, there is a wiki, but it is just the output of a program stripping docstrings, nothing actually useful when you just need to use a part from a given library.
There are no working code examples, or tips about corner cases, etc.
Turbo Pascal had very good documentation, and it got better over time.
Idera specializes in extending a very thin lifeline to technologies which can still be milked for licenses and support.
There's no real development or innovation behind products gobbled by Idera.
Prior to that Borland was already severely lagging behind in dev tools.
Free Pascal + Lazarus is a fine free alternative if the language suits you.
Basically they decided that they did not want to serve millions of developers that loved their product but to instead focus on fewer, bigger enterprise accounts.
This left the market open for Jetbrains to take over the loved-by-devs position and they learned that the books were right: in tech, the low end always eats the high end.
I remember seeing a plethora of amazing GUI plugins for Delphi too ..
No getter/setter bs. When creating a class you declared a field a property, it looked like this
type
private
FBar: Integer;
procedure SetBar(Value: Integer);
published
property Bar read FBar write SetBar
One codebase, compile everywhere. Small executables, compiled rapidly. Cross platform. LGPL. Super friendly community with a LOT of awesome talent.
It's really great!
There are no native GUI components, everything is the same old and ancient custom Lazarus VCL design. Why can't I just drag, drop, and use a native Qt5 component?
They struggled for years getting a dockable interface, and it's still shockingly bad bordering unusable. The community seems stuck in the Delphi 7-interface era.
I used to love and use Delphi. It was my first "proper" programming language, and it's what I learned. But I just cannot advocate for its use in the current climate, especially after having been exposed to other developer communities and the superior tooling and availability. I try to go back every couple of years or so and try to use it, but it's just not there.
Anyone who could comment on any sort of support in Lazarus and fcl/lcl for the following would be appreciated:
- HTTP(S) servers
- SOAP
- REST
- gRPC
- GraphQL
But it doesn't really have the sort of structure that one would expect from a mature web framework, feels a bit worse than PHP (no automatic (de)serialization of objects, path variable and query parameter expansion, middleware etc.).
Is there anything like Spring/Django/Express.js/ASP.NET Core in the world of Lazarus/FreePascal?
Of course it's unfair to expect that Lazarus would have support for everything out of the box, so are there any external frameworks that are as mature as any of the above?
I've only found the following:
- https://github.com/fanoframework/fano
- https://github.com/risoflora/brookfreepascal
- https://wiki.lazarus.freepascal.org/Category:Android
- https://wiki.freepascal.org/Category:iOS
Yes, but not compared with just about anything else. I used to make some of my living as a Delphi consultant, but I had to give it up as you couldn't make any money doing it, particularly when compared with C#, C++ and Java.
Unfortunately it will not happen because Embarcadero current strategy revolves around milking their existing enterprise customers while their IT policies require that an aplication in production is built with components that have a support contract in place.
I am betting it is going the Delphi way.
- if you’re alluding to the idea that Kotlin would be driven in the direction of closed source compilers and tooling in order to “milk” enterprise adopters: that would require a bizaare set of changes, including changing the license of both the tooling and the compiler - neither of which require copyright assignment, so JetBrains are not even free to do.
- if you’re betting on an open compiler but closed tooling, again that would require changing the license of the tooling, which JetBrains is not entirely free to do since it does not get assigned copyright on contributions.
I don’t know what agreement JetBrains has in place with Google, but I’d wager it precludes making Kotlin proprietary.
And the active role to make it a InteliJ language for most part, withdrawing support for Eclipse.
Now after a couple of changing hands, about 4 of them, they are trying to grow back the numbers of the small shops.
Likewise JetBrains seems to have forgotten the JVM roots of Kotlin and is now trying to go beyond JVM, comprising language design choices on features that don't have the same semantics, e.g. value types on JVM vs JS/ART/Native, or the incompatible memory semantics of immutable types on Kotlin/Native.
The fact that they have a freemium model is irrelevant to that goal of owing the Kotlin IDE space.
The free offering you mention is used both for funnelling or for having customers do the market segmentation themselves, as there are customers that want to pay for everyone in the team, there are customers who want to pay for only some of members of the team and those who do not want to pay for anyone in the team.
https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-need...
> The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. We’re working on a new language, but we do not plan to replace the entire ecosystem of libraries that have been built for the JVM. So you’re likely to keep using Spring and Hibernate, or other similar frameworks, in your projects built with Kotlin. And while the development tools for Kotlin itself are going to be free and open-source, the support for the enterprise development frameworks and tools will remain part of IntelliJ IDEA Ultimate, the commercial version of the IDE. And of course the framework support will be fully integrated with Kotlin.
I don't see it getting wide adoption, but it's not bad for open source. But compared with C# (which is basically Delphi as it should originally have been, by the same designer) - nah.
I acquired my "10K hour" badge with Pascal in the late 70s (CDC Cyber 6600) and Mid 80s (PC) and then again with Perl (late 80s to early 2Ks) when each of these peaked. Coming back to the 2015+ versions (Lazarus / Perl 5.24+) of both was nostalgic but the communities were in the backwaters of programming due to viral success of some many others.
A compelling event would have to happen to elevate them again. It could happen: Something pushed Ada to almost triple its "popularity" ( to < 1%.) According to PYPL (https://pypl.github.io/PYPL.html) in the last year.
It will get it, eventually. It can produce native executables without cross compiling on ARM systems too, which is a huge selling point to me. Think Raspberry PI, other small ARM boards, etc. and the PinePhone too.
https://forum.lazarus.freepascal.org/index.php?topic=52217.0
I still remain a total newbie but that's not because of Lazarus.
Microsoft and Sun did not. So they could both give their products away for free and open source them, plus keep people working on those products.
I like Pascal but its scope rules are Crazy compared to C/Java/C#, nerveless Pascal compiler is reported faster than Java one
Admittedly a long time since I used Pascal proper, but my recollection (and a quick search seems to confirm) that its scope rules are "simply" lexical scoping. Variables are visible only within the area they are declared and not outside, and variables can shadow variables from a higher level. So a global variable can become shadowed by a procedure variable. That's pretty much the same as the other languages use.
Who knows, maybe Rust and something like Ada++ http://www.adapplang.com/ will be able to dethrone C++, or Java some day.
I love Lazarus, and Delphi before it, and Pascal before that ... but I gotta say, the language, readable though it is, is a pain in the rear to write.
An instance of a class is not the same thing as an object.
By default, the file open/read/write/close routines don't return error values so the caller has to do extra work to check statuses after each use of these functions (IIRC, those error codes from Assign(), Reset(), etc weren't thread-safe either!)
Some conditional expressions cannot have parenthesis (compilation error) while other conditional expressions must have parenthesis (also a compilation error).
Some builtin functions can't be easily 'wrapped' because while the function may take variadic arguments, the language doesn't allow the programmer to write variadic argument functions.
It's death by a thousand cuts; each little problem, surmountable on its own, adds to the overall friction when developing.
What I really like in Pascal:
1. Programmer-defined range types: enums are not a replacement for those. 2. Bounds checking on arrays; I'd rather crash with an exception than silently overrun the array. 3. Nested functions (although, now with almost all languages supporting anonymous functions nested functions probably aren't really needed).
I have no idea what you mean here, sorry.
> By default, the file open/read/write/close routines don't return error values
Those file IO methods are for backwards compatibility with Turbo Pascal. They haven't changed semantics since DOS. They don't support Unicode. They are heavily deprecated. Today, try using TFileStream.
> while the function may take variadic arguments, the language doesn't allow the programmer to write variadic argument functions
Pascal isn't C. You can consume variadic methods written in a C library, but the Delphi way to write the same thing is an 'array of const'. Here's the Format method, for example: http://docwiki.embarcadero.com/Libraries/Sydney/en/System.Sy...
> each little problem, surmountable on its own, adds to the overall friction when developing.
You may have better luck not thinking of it from a C background but as similar to, say, Python: some things are different.
>> An instance of a class is not the same thing as an object.
> I have no idea what you mean here, sorry.
This explains the issue quite well: https://forum.lazarus.freepascal.org/index.php/topic,43622.m...
> Today, try using TFileStream.
I have used it and was not as unhappy with it as I was with the Standard Pascal file IO functions. I was never able to figure out from the exception why a TFileStream method failed. The most you could infer was that an error occurred, but not what error.
This makes for a very poor interface to the user in the resulting application, as they have no idea what to do to fix the error before retrying. In most other languages (that Delphi and Lazarus compete with) you can let the user know what they should do to fix the error before retrying.
> You can consume variadic methods written in a C library,
That doesn't apply to what I was saying. I meant that a programmer could not write a Pascal procedure that wrapped a variadic-args Pascal procedure. C has nothing to do with this.
This is occasionally useful (say, for logging), and its ommission is one of those tiny things that add friction.
With all that being said, I still prefer doing native GUI apps in Lazarus to almost everything else out there. It's insanely readable even after a prolonged period.
> I have no idea what you mean here, sorry.
This explains the issue quite well: https://forum.lazarus.freepascal.org/index.php/topic,43622.m..."
I am not sure how Lazarus implements stuff behind the scene but I can tell you 100% for sure that in Delphi every declared class has TObject as ancestor class, so when you instantiate a class in Delphi, you are creating an object.
Like I said, my experience is quite old (circa 2004 with Delphi), but last I used Delphi, it functioned identically to the way that link for Lazarus said it did.
You could create your own class, then instantiate it, and what you got was different from creating an instance of an object.
There is a hierarchical namespace based on units, and also there is lexical scope.
Delphi was not a failure by _any_ stretch of imagination. In terms of RAD, it was only second to VB.
Also keep in mind that a lot of people at the time knew Pascal, in that regard Delphi was completely esthetically pleasant.
Think of Qt, WinUI, CUDA, Unreal, Visual Studio debugger, C++ Builder kind of tooling.
func Foo (X : C.int) return C.bool with Import, External_Name => "Foo";
I suppose though that you are right. A majority of modern programmers probably view sophisticated tools and pre-built packages (a la NPM) as necessities and hardly care about performance or code quality.
case Variable:
when 0 => Put_Line ("Zero");
when 1 .. 9 => Put_Line ("Positive Digit");
when 10 | 12 | 14 | 16 | 18 =>
Put_Line ("Even Number between 10 and 18");
when others => Put_Line ("Something else");
}
case Variable is -- was : above
..
end case; -- replaced by } above
And regarding package management, Alire does exist and is starting to become interesting for Ada users. The list of crates is still small, but it's functional and (somewhat) easier than managing it manually.
EDIT: Fixed some things like "it's" to "its" and "process" to "procedure". It's Saturday morning and my coffee was still brewing.
Possibly part of the reason. Pascal has a very readable syntax, but for some (most?) programmers it is too "verbose" and that is enough for them to never consider it. This is probably true of any language labelled "verbose".
Python and Ruby advocates probably feel these languages have found the right level of conciseness and readability. But everyone has a different opinion. Of new languages, Nim and Julia seem aiming for the same balance: not too terse, but still easy to read. Have they succeeded?
I find it fascinating that C's influence on language syntax continues today with new languages (e.g. Rust, Zig) in a way that Pascal does not.
But give it its due, the stuff you could do with Delphi for example COM made it probably the only Win 32 compatible language to compete with C++. It was the Betamax to the VHS of VB...
Virtually all third party commercial libraries had source available, which had a raft of benefits (even if you often needed to pay more for the library to get the source.)
Meanwhile for other languages, libraries were often sold without any source, and you were royally screwed if you had a problem later.
In all modern languages that is a build system responsibility.
Anders Hejlsberg wrote the first Compass Pascal compiler when he was 16. And it still lives on in Delphi so many years later. Anders is now driving TypeScript development at Microsoft.
I ended up hacking on some leaked Telegard source code, decided to scrap it after discovering something I thought was suspicious and realizing I couldn't expect to understand every detail of these thousands of lines of code that I shouldn't have had in the first place. I ended up completely rewriting it in time to run it on my own, and a few friends' BBSes for about two years until we all found romance, the internet or both.
Just thinking about one of the reasons why I did the rewrite reminds me of how incredible that language/ecosystem was--given the early-90s when I used it. The "final nail in the coffin" for me was the code that authenticated a user. Bear in mind, this is the early 90s. You had a "handle" and a number, which a 16-bit unsigned integer (0-65535), assigned sequentially with the admin always being "0", and you could login with the number. Passwords were not only stored in plain-text in a relatively readable format in a file on the drive, but the Admin panel helpfully displayed the user's password every time a 'sysop' viewed a user's account. The background is provided to make clear: this was not a complicated login routine designed to avoid side-channel attacks, perform string comparisons in deterministic times, etc -- if they were, it'd be an amazing waste of time given the total disregard for security throughout the code (and most projects of this era)... and if it were, I wouldn't have been a good enough developer to even identify it.
However, this code had a few `goto` statements, and some inline assembly. The three places that had inline assembly in this code were the ANSI implementation, that I wrote, the 16550 UART driver, that I wrote and this login routine that I did not write and as far as I could tell had absolutely no good reason to be there. After hours of refactoring, I broke the code out into "code that logs a user in" and "code that makes something"; That "something", IIRC, was a round-about way to generate a "master password" that could be used to login with any account (and `0` was `root`). During testing, I discovered that my "skipping the code that makes something" part resulted in an empty string value which meant I could login with no password to any account. I rewrote the whole login routine, and then the whole thing.
Would kind of love to look into that, now, since I'd actually be able to understand what is going on, now (maybe!).
[0] IIRC, the IDE fit on a 5.25" floppy, and Version 5.0 had a whole bunch of new, elaborate, syntax highlighting. It was amazing.
"The sequence Pascal—Modula—Oberon is witness to my attempts to achieve [perfection]."
At the same time, OCaml's ML heritage greatly simplifies the majority of the syntax (getting rid of semicolons, making identifiers case-sensitive), and bringing the expressive power of functional programming.
It fuses together the best of both worlds. It's why I often say that OCaml is like a midpoint between Haskell and Go. The 'Go parts' are from their common ancestor, Pascal.