4 ms·
I wouldn't really call Pascal elegant ... it's downright weird in places, and seems poorly thought out. For example you can't have a one-character string const
by HarHarVeryFunny 4y ago
I wouldn't really call Pascal elegant ... it's downright weird in places, and seems poorly thought out.
For example you can't have a one-character string constant in (ISO standard) Pascal since it regards 'c' as a char, while '12' (both single quotes) is a "string"! Of course Pascal didn't even really have strings, but it at least allowed you to write (print) any "packed array [1..N] of char" to a "text" file, so that was sort of a string...
The only parameter type your own functions could take that would accept any such (for different N) "strings" was using a variable length "conformant array" parameter "packed array [lo..hi:integer] of char", but this would have to be a value parameter (entailing an inefficient array copy) if you wanted it to accept string constants as well as other "packed array [1..N] of char" strings... However, god forbid one function taking a conformant array "string" parameter wanted to pass that to another function taking the same type of parameter, since Pascal didn't allow conformant arrays to be used this way.
Pascal's standard I/O system was downright weird too. You could open files (reset/rewrite) but not close them, the language itself had no way to associate a filename with a file (!!), although it did say that any files given as parameters to "program" were "permanent" (presumably named, with the name coming from who knows where!) files, as opposed to others which were transient temporary ones. Then there's Pascal's file "buffer variables", whereby file.bv was treated as a pointer to the item at the current read/write position in the file...
Umm.. or how about for loops with separate keywords for loops that count up (for to) as opposed to down (for downto), which I suppose was a necessity given that you couldn't actually specify the loop increment (i.e only implicit 1 or -1).
Ugh.
Although not a Wirth language, perhaps Ada comes closest to being a usable, if cumbersome, language from the same mindset. I'm not familar with Oberon though.
- lproven 4y agoThanks for the real-world perspective. There's a lot of stuff I didn't know in there. > Although not a Wirth language, perhaps Ada comes closest to being a usable, if cumbersome, language from the same mindset. A legit point. I find it very amusing (in a tragi-comic sort of way) that despite regularly ranking as the fastest language outside the C family in the "Benchmarks Game" – https://benchmarksgame-team.pages.debian.net/benchmarksgame https://benchmarksgame-team.pages.debian.net/benchmarksgame – it gets overlooked or ignored compared to trendier languages for xNix types. (Interestingly, getting that link, I see that it's changed in the last year or so since I last looked. E.g. Julia is doing well, which is impressive: it is designed to be fast at numerical stuff, but even so, it's not compiled.) Ada was seen as huge and bloated in the '80s, yes. Compared to most 20th century languages, it's positively lean and svelte. > I'm not familar with Oberon though. It's been a research interest of mine for years now; cf. https://www.theregister.com/2015/12/02/pi_versus_oberton/ https://www.theregister.com/2015/12/02/pi_versus_oberton/ I got some interest from the Squeak community a while ago. Not sure if anything will come of it, though. I am in an Oberon Telegram chat channel, but it's in Russian, a language of which I understand very little. Various Russian institutions have been working with Wirthian languages for 30+ years now. There is active interested and R&D going on there. I think it's worth a look. A complete compiler, together with its own IDE and self-hosted on its own (somewhat rudimentary) OS, in just a few tens of thousands of lines of code. It's got the functionality of an early x86 Unix but it's down around the size of mid-era MS-DOS. I am not aware of anything else that compares to it. A list of its characteristics I thought notable: • a clean, simple OS, with SMP support, that supported pre-emption, memory management etc. • in a type-safe language, with a native-object-code compiler — not JITTed, not using a VM or runtime • and a readable language, not something far outside the Algol family of imperative HLLs • that was portable across different architectures • that was FOSS and could be forked • that was documented and had a user community who knew it • that can be built with FOSS tools (which RISC OS fails, for instance) • which is or was used by non-specialists for general purpose computing • which can usefully access the Internet • which runs on commodity hardware