Awesome Pascal – A curated list of Delphi, FreePascal, and Pascal shiny things | Hacker News Reader

Awesome Pascal – A curated list of Delphi, FreePascal, and Pascal shiny things

github.com

There's a tender place in my heart for Pascal. The first language I was taught was Turbo Pascal (I had sort of taught myself QBasic before that, as much as one can from reading the help manual and stumbling through), and the built-in libraries was as close to the liberty and scope of Python as you could get in those days. It really inspired me to continue down the path of software development.

I also have fond memories of BBS door games and software, a large portion of which was built with Pascal.

I digress: but it's nice to reminisce about those old days.

> and the built-in libraries was as close to the liberty and scope of Python as you could get in those days

And even better with Delphi that additionally had better rapid UI creation possibilities than Visual Basic, and on top of that, differently than Visual Basic, produced a self containing executable, not depending on anything external.

Yeah, but the VB executables themselves were tiny (in P-Code form, which was the default, they were also much more compact than machine code) and while a single exe+runtime itself was larger than the ~300K a minimum that Delphi 2/C++ Builder would produce (with +~100K for a program that did something interesting), it would take 3-4 programs sharing the runtime to quickly win that difference back.

This is actually a (minor) issue i have with Lazarus - the executable files do not depend on anything, but they are too large (~2MB minimum nowadays, if you remove all debug info, etc) so if i want to create several "small" utilities that focus on one thing instead of a multi-tool, i waste a lot of space (and most importantly nowadays, bandwidth).

At least with Delphi you can compile the executable with the runtime library as a separate file to be shared among the programs (my guess is that they wanted to do something the VB shared runtime, but it didn't seem to catch on as nobody used it like that).

> the VB executables themselves were tiny (in P-Code form, which was the default, they were also much more compact than machine code)

Now that you mention and I think about it, as VB was compiled to the p-code and depended on the big common runtime which executed it, it can be seen as one Windows-specific spiritual precursor of... Java.

Yeah, actually Microsoft used P-Code way before VB1 - AFAIK their C compiler was able to emit it and several of their products were compiled as P-Code instead of machine code, which helped to save disk space (a premium at the time, especially considering it could make a difference on how many floppy disks they shipped) and quickly port their applications to other emerging platforms at the time (like the Macintosh).

Both Microsoft's P-Code and Java were really inspired by UCSD Pascal which only emitted P-Code to be executed by a runtime they implemented quickly in a lot of systems (including the original IBM PC).

> Both Microsoft's P-Code and Java were really inspired by UCSD Pascal which only emitted P-Code

Yes, and I've actually experimented with UCSD Pascal on a 8-bit machine (Apple II). Turbo Pascal was, of course, much faster on it (using Z-80 card).

The designer of Pascal, prof. Niklaus Wirth, evolved the language into Modula-2 and then Oberon. Oberon is a refreshingly lean language. The specification is only 17 A4-pages long:

https://www.miasap.se/obnc/oberon-report.html

Note that this is Oberon-07, not Oberon, the latter is a bit different (and there are other Oberons). Also the spec is indeed small, but it doesn't address qustions like what happens when you assign an integer to a byte that is outside the range that a byte can represent.

Oberon-07 is simply the latest version of Oberon, like Python 3 is the latest version of Python. Other non-Wirthian Oberons are best viewed as forks of the original.

The result of assigning an integer > 255 to a byte is unspecified; it's the same with numeric overflow in arithmetic operations.

You'll find that a lot of people who work with Oberon explicitly state the dialect/variant they use (they are different dialects, not just versions) and Oberon usually refers to either the original or the language family.

Yes, the result is unspecified, that is what i'm talking about: it doesn't specify what it happens, meaning that the implementations will have to figure that out themselves, potentially in an incompatible manner (although in general implementations do try to be compatible with each other, but this is by communicating among themselves and trying to fill the holes in the Oberon-07 spec).

The programmer should make sure that an integer is within the range of a byte before assigning it to a byte variable. It's no more complicated than that.

The question is what happens if the programmer doesn't do that. If you are implementing a compiler, what do you do in that case? Are you using whatever is the first or last byte in memory (depending on the machine endianess)? Are you wrapping the value around to keep it consistent between implementations? Are you generating code that aborts the program?

Similar question is also about pointers, what happens if you try to use p^ when p is nil? Do you try to access whatever address nil represents? Do you abort?

C has the notion of undefined behavior and it is explicitly mentioned, but Oberon-07 doesn't mention this at all meaning that implementations need to make those decisions.

If you are implementing a compiler you do what makes most sense for the target language/machine. On the other hand, if you specify exactly how each ill-defined operation should be handled you

1. restrict the freedom of compiler writers. On very small systems, for instance, array bound checking may not be implemented,

2. make programmer rely on non-obvious behaviour/results which makes programs harder to understand and maintain,

3. make the language specification more complicated.

Or you can simply type "Integer to byte conversion and nil dereference are machine dependent" (or implementation dependent if you prefer, but the point is to have something).

No way! I too stumbled through QBASIC. A guy I knew was 7 years older and in high school. They were learning Turbo Pascal. Every Sunday I would go to him after church to enquire about what else he could teach me. Then I would go home to try it and if I wrote it down wrong or wasn't listening it was a whole week before I could ask for help. It's so cool to see someone else walked that road

Wow, that's a comprehensive list! I've been searching for the most useful resources I've used in 25 years and they're all there.

On the other hand, I see that Delphi usenet forums have been closed for a year... long time I had not checked.

If you're looking for a relatively active community, you can check this subsection of a long-running German forum, recently created to replace the Google+ group that's closing down: https://en.delphipraxis.net.

Thanks for sharing that link. Will check it out. Was feeling bad about the fact that the comp.lang.pascal.delphi (name right?) group (a Usenet group, and then gatewayed via Google Groups) was not very active, and/or had spam (but that was common to many Google groups - yes, I mean Google, not Google+, though I know you said Google+, although some time later I noticed that Google may have done something about the spam issue on Google groups, and it came down a lot, IIRC).

Delphi is still relatively used in Germany, with an yearly conference taking place.

Had heard of this (and in fact more generally that (ex-)Borland products are popular there, which is good, but thanks for mentioning it.

With the amount of slow electron apps these days I wish more people would write native programs in Pascal / Delphi. It’s blazingly fast and easy to write (although the language has a few idioms it takes time to get used to).

Same wish here. I think more people would use Pascal - in its modern incarnations like Delphi (despite the cost, for some who can afford it) and FreePascal (which is free as in beer as well as speech) - if they knew more about it and did not have misconceptions about it, some of which might stem from (wrongly) thinking of those incarnations as being as limited as early versions of standard Pascal (which was probably meant as a teaching language). They are not as limited, they are a lot more, a hell of a lot more.

I think that there is room for improvement... Flutter is something very interesting, though yet another language (Dart). React Native is also interesting, but actually creating for cross-platform has some niggles. I would think a nice cross-platform UI toolkit for Rust, once async/await drop could be huge. WebAssembly + Canvas|WebGL|SVG as a generic runtime base could go a long way to also bridging a gap.

In the end, it really just depends. Right now electron is the closest we've had to a cross-platform application base with a UI that is easily styled and a single codebase for write once, run anywhere that we've had. Most of the cross-platform UI tooling that's come before has kind of sucked. Even getting build pipelines for multiple platforms (even just Linux, Windows and Mac) has been pretty painful. Electron bridges a lot of gaps at the expense of a more bloated baseline.

I think things will get interesting and we'll see some new/old paradigms show up.

I rather use JavaFX or Qt for that.

If it can be done just with HTML 5, CSS, JavaScript, then its place is the browser.

Why would anyone use Delphi these days? Except the case of maintaining legacy code.

It is a cross-platform product which readily comes with server components, logger components, IPC, many DB connectors and UI components if you are on windows, android or iOS.

Language-wise, UI design-time lets you execute code such as db queries while designing your screens. It is almost completely orthogonal. It has no GC which makes for a faster runtime and writing free in finally is not something that is easy to forget (remember orthogonal) and immediately jumps out as an error when skimming code. Data modules enforce a separation of concerns, visually seeing component properties enables another form of remembering setup parameters.

Tooling-wise, you have runtime stack traces thanks to jedi library. It can show memory leaks on shutdown by enabling a flag. You have package manager baked into the UI, compiler is blazingly fast and generates fast executables.

With all this, for example, you could concoct a db editor easily in a few hours.

Is it still maintained? Believe FreePascal and Lazarus IDE are.

Delphi is very much alive. I exited the scene after Delphi 2009, re-entered in 2014 during Delphi XE7 to do some web service and android work. I don't use delphi anymore, but latest version is Delphi 10.3 released a few months ago.

http://docwiki.embarcadero.com/RADStudio/Rio/en/Compiler_Ver...

Yes, it is. But the prices are violently high for Embarcadero products.

They are maintained but last time i heard after it was sold to Idera they fired some of their most of their programming team, including some (or all? I don't remember details) of the programmers who where there since the earlier days and went for outsourcing development. There was several posts/discussions about it in a few Delphi-related blogs, but i didn't follow beyond that.

I'm close to the end of initial development of a product which basically turns Microsoft Word into a desktop CMS like WordPress (it utilize Bootstrap 4 so the result is not what you might think ;))

There no reason not to use Delphi for this project - it compiles really fast and natively, it allows me to make nice UI fast without limits, I've got a lot of reusable code.

I wouldn’t use it for my projects, but Delphi still has some strengths that are not so common these days:

- very fast compile times

- great backwards compatibility

- non programmers can create simple programs

"non programmers can create simple programs"

What does that mean? You can be a non programmer and make simple programs in most general purpose programming languages.

Are you talking about the VCL library? In that case, there are many other languages that include the same like C# for example.

Delphi is hard to beat in ease-of-use of the GUI editing. It's not just that it ships with the component library, it's that the editor integrates it so well.

...and before someone tries to counterpoint that Visual C# has WinForms which is similar to Delphi, yes it is similar, but the functionality available in terms of design in Visual Studio 2019 isn't up to par with Delphi 2.

The libraries with source like other languages also do today, but also that the language is verbose like Visual Basic did.

> great backwards compatibility

How good was Delphi at hiding MS-DOS quirks? I know C from that platform tended to be nonstandard with near and far pointers to accommodate memory segmentation, but was Delphi any better?

Delphi was a Windows-only product. Delphi 1 and its predecessor, Turbo Pascal, only supported far pointers to data, and could support far or near procedure calls with an annotation (essentially, a compiler pragma).

> only supported far pointers to data

Which meant that as long as you didn't have to call C functions you just had to know and write that "it's a pointer" and nothing more.

Probably to write Windows apps without being dependant to JVM/.NET ?

That's somewhat fair... GUI in JVM generally sucks all around, and while I appreciate XAML in .Net space, it comes with a lot bigger cost than the output of Delphi.

Though, iirc, Delphi is really expensive as a product.

Mostly because those devs haven't bothered reading books like "Filthy Rich Clients", and also only care for programmer art.

Reply on news.ycombinator.com