Modern Pascal is still in the race (2022)(blog.synopse.info)
blog.synopse.info
Modern Pascal is still in the race (2022)
https://blog.synopse.info/?post/2022/11/26/Modern-Pascal-is-Still-in-the-Race
159 comments
I'm surprised that you draw a sharp distinction between C and Pascal syntax. They have a shared lineage and are really very close to each other. Yeah, curly braces won over "begin" and "end", but that's not a matter of some huge conceptual rift, just convenience.
There are numerous languages today, including Haskell and Ocaml, that are far more removed from the Algol lineage than these two. Heck, the differences between Rust and C are probably more pronounced than between C and Pascal.
There are numerous languages today, including Haskell and Ocaml, that are far more removed from the Algol lineage than these two. Heck, the differences between Rust and C are probably more pronounced than between C and Pascal.
One huge difference between C and Pascal grammars us that Pascal is LR(1), so it can be parsed easily, which helps one-pass translation. It also helps humans read it.
C, on the other hand, has needlessly complicated syntax; a function definition is hard to detect, and a pointer to a function is hard to interpret, because it's literally convoluted: https://c-faq.com/decl/spiral.anderson.html
Sadly, this is a general stylistic difference: where Pascal tries to go for clarity, C makes do with cleverness, which is more error-prone.
C, on the other hand, has needlessly complicated syntax; a function definition is hard to detect, and a pointer to a function is hard to interpret, because it's literally convoluted: https://c-faq.com/decl/spiral.anderson.html
Sadly, this is a general stylistic difference: where Pascal tries to go for clarity, C makes do with cleverness, which is more error-prone.
You misremember. Pascal's grammar is "easy" because it is LL(1), not LR(1)!
C is almost LR(1), if we allow prior declarations to decide how some tokens are classified, like whether an identifier is a variable or type name.
Declarations like
LR(1) sentences are harder to read than LL(1) because you have to keep track of a long prefix of the input, looking for right reductions (if you follow certain LR algorithms). LR parsing algorithms use a stack which essentially provides unlimited lookahead, in comparison to LL(1). Both LL(1) and LR(1) have one symbol of lookahead, but qualitatively it's entirely different because the lookahead in LR is happening after an indefinitely long prefix of the sentence which has not been fully analyzed, and has been shunted into a stack, to be processed later. Many symbols can be pushed onto the stack before a decision is made to recognize a rule and reduce by it. Those pushed symbols represent a prefix of the input that is not yet reduced, while the reduction is happening on the right of that. So it is backwards in a sense; following what is going on in the grammar is bit like understanding a stack language like Forth or PostScript.
An LL(1) grammar allows sentences to be parsed in a left to right scan without pushing anything into a stack to reduce later. Everything is decidable based on looking at the next symbol. Under LL(1), by looking at one symbol, you know what you are parsing; each subsequent symbol narrows it down to something more specific. Importantly, the syntax of symbols that have been processed already (material to the left) are settled; their syntax is not left undecided while we recognize some fragment on the right.
Under LR(1) it's possible for a long sequence of symbols to belong to entirely unrelated phrase structures, only to be decided when something finally appears on the right. A LALR(1) parser generator outputs a machine in which the states end up shared by unrelated rules. The state transitions then effectively track multiple parallel contexts.
C is almost LR(1), if we allow prior declarations to decide how some tokens are classified, like whether an identifier is a variable or type name.
Declarations like
void (*signal(int, void (*fp)(int)))(int);
LR(1) sentences are harder to read than LL(1) because you have to keep track of a long prefix of the input, looking for right reductions (if you follow certain LR algorithms). LR parsing algorithms use a stack which essentially provides unlimited lookahead, in comparison to LL(1). Both LL(1) and LR(1) have one symbol of lookahead, but qualitatively it's entirely different because the lookahead in LR is happening after an indefinitely long prefix of the sentence which has not been fully analyzed, and has been shunted into a stack, to be processed later. Many symbols can be pushed onto the stack before a decision is made to recognize a rule and reduce by it. Those pushed symbols represent a prefix of the input that is not yet reduced, while the reduction is happening on the right of that. So it is backwards in a sense; following what is going on in the grammar is bit like understanding a stack language like Forth or PostScript.
An LL(1) grammar allows sentences to be parsed in a left to right scan without pushing anything into a stack to reduce later. Everything is decidable based on looking at the next symbol. Under LL(1), by looking at one symbol, you know what you are parsing; each subsequent symbol narrows it down to something more specific. Importantly, the syntax of symbols that have been processed already (material to the left) are settled; their syntax is not left undecided while we recognize some fragment on the right.
Under LR(1) it's possible for a long sequence of symbols to belong to entirely unrelated phrase structures, only to be decided when something finally appears on the right. A LALR(1) parser generator outputs a machine in which the states end up shared by unrelated rules. The state transitions then effectively track multiple parallel contexts.
> C is almost LR(1),
Does that include the C preprocessor?
Somehow, I recall someone here (maybe it was user walterbright) suggesting that implementing a C preprocessor was a lot of work - maybe months - so one might consider using Facebook's MIT licensed preprocessor:
https://github.com/facebookresearch/CParser
Does that include the C preprocessor?
Somehow, I recall someone here (maybe it was user walterbright) suggesting that implementing a C preprocessor was a lot of work - maybe months - so one might consider using Facebook's MIT licensed preprocessor:
https://github.com/facebookresearch/CParser
The C preprocessor is a purely functional language![1]
[1] https://web.archive.org/web/20230714010215/http://conal.net/...
[1] https://web.archive.org/web/20230714010215/http://conal.net/...
This is correct, thanks!
I'm very much not a C programmer, but I've never understood why it seems far more common to write `float *foo` instead of `float* foo`. The "pointerness" is part of the type and to me the latter expresses that far more clearly.
Because the syntax is:
This declares two pointers to char:
<specifiers> <declarator> {, <declarator>, ...} ;
This declares two pointers to char:
char *foo, *bar;
char* foo, bar;
On the other hand, for those of us who agree with the GP on this, one way around the pitfall is to have your project's style guide ban multiple declarations on a single line, or at least ban them for non-trivial variables— so `int x, y, z;` is permitted, but nothing more than that.
That's fine if it isn't used as a pretext for writing nonsense like char* p; which should likewise be banned in the same coding style document.
>This declares foo as a pointer to char, and bar as a char:
char* foo, bar;
Because it isn't - `float* foo, bar;` foo is a pointer, bar is not.
(There were suggestions back in the 90s that to make C easier to parse for humans (and not-coincidentally simplify the compiler grammar) this should be `foo, bar: float*;` and your model of pointerness could actually be true. Never got much more traction than some "huh, that would be better, too bad we've been using this for 10 years already and will never change it" comments :-) (with an occasional side of "maybe use typedefs instead")
(There were suggestions back in the 90s that to make C easier to parse for humans (and not-coincidentally simplify the compiler grammar) this should be `foo, bar: float*;` and your model of pointerness could actually be true. Never got much more traction than some "huh, that would be better, too bad we've been using this for 10 years already and will never change it" comments :-) (with an occasional side of "maybe use typedefs instead")
Good news (kinda): C23 allows (and GCC has for a long long time allowed) you to write typeof(float *) foo, bar; and declare two pointers. Not that I’d advocate writing normal declarations that way, but at least now you can write macros (e.g. for allocation) that don’t choke on arbitrary type names.
Which is why the convention is usually to not permit multiple declarations in one line.
If you value your codebase anyway.
If you value your codebase anyway.
Declaring X,Y and Z on separate lines for a graphics routine would just be silly, they're all the same type.
Defensive programming that extreme reminds me of the behavior I learned to avoid pissing off my drunk dad.
Defensive programming that extreme reminds me of the behavior I learned to avoid pissing off my drunk dad.
It's either that, or making a pointer type to bind things correctly. Convention is there to paper over shitty, shitty behavior in the language that is easy to trip yourself up on.
I think it is a manner of preference, both "float* foo" and "float *foo" are widely used.
Personally i used "float *foo" for years until at some point i found "float* foo" more natural (as the pointer is conceptually part of the type) so i switched to that, which i've also been using for years. I've worked on a bunch of codebases which used both though (both in C and C++) - in some cases even mixed because that's what you get with a codebase where a ton of programmers worked over many years :-P.
I do tend to put pointer variable declarations on their own lines though regardless of asterisk placement.
(and of course there is always "float foo[42]" to annoy you with the whole "part of the type" aspect :-P)*
Personally i used "float *foo" for years until at some point i found "float* foo" more natural (as the pointer is conceptually part of the type) so i switched to that, which i've also been using for years. I've worked on a bunch of codebases which used both though (both in C and C++) - in some cases even mixed because that's what you get with a codebase where a ton of programmers worked over many years :-P.
I do tend to put pointer variable declarations on their own lines though regardless of asterisk placement.
(and of course there is always "float foo[42]" to annoy you with the whole "part of the type" aspect :-P)*
Here's how I understand it.
One important (and beautiful) thing to understand about C is that declarations and use in C mirror each other.
Consider the same type written in Go and C: array of ten pointers to functions from int to int.
Go: var funcs [10]*func(int) int
C: int (*funcs[10])(int)
Go's version reads left to right, clearly. C version is ugly.
But beautiful thing about C version is that it mirrors how funcs can be used:
(*funcs[0])(5)
See how it's just like the declaration.
Go's version doesn't have this property.
So, now about the *.
Usage of * doesn't require spaces.
If p is a pointer to int, you use it like this: *p
And not like this: * p
And since type declarations follow usage, therefore "int *p" makes more sense.
There is also a good argument about "int *p, i". In the end, these usages follow from how the C grammar works.
There are many more musings about that on the web, but here is one of my favourites: https://go.dev/blog/declaration-syntax.
Edit: HN formatting.
One important (and beautiful) thing to understand about C is that declarations and use in C mirror each other.
Consider the same type written in Go and C: array of ten pointers to functions from int to int.
Go: var funcs [10]*func(int) int
C: int (*funcs[10])(int)
Go's version reads left to right, clearly. C version is ugly.
But beautiful thing about C version is that it mirrors how funcs can be used:
(*funcs[0])(5)
See how it's just like the declaration.
Go's version doesn't have this property.
So, now about the *.
Usage of * doesn't require spaces.
If p is a pointer to int, you use it like this: *p
And not like this: * p
And since type declarations follow usage, therefore "int *p" makes more sense.
There is also a good argument about "int *p, i". In the end, these usages follow from how the C grammar works.
There are many more musings about that on the web, but here is one of my favourites: https://go.dev/blog/declaration-syntax.
Edit: HN formatting.
The * binds the name, not the type.
https://godbolt.org/z/GsoxrWdrG
https://godbolt.org/z/GsoxrWdrG
For the same reason you don’t write x+y * z: because then the spacing contradicts the way the priorities work in the language.
We might wish for the C declaration syntax to be <type> <name>[, ...], but it’s not: it’s <specifier>[ ...] <declarator>[, ...], where int, long, unsigned, struct stat, union { uint64_t u; double d; }, and even typedef are all specifiers, and foo, (foo), (((foo))), *bar, baz[10], (*spam)(int), and even (*eggs)[STRIDE] are all declarators (the wisdom of using the last one is debatable, but it is genuinely useful if you can count on the future maintainer to know what it means).
Everybody is free to not like the syntax, but actively misleading the reader about its workings seems counterproductive.
We might wish for the C declaration syntax to be <type> <name>[, ...], but it’s not: it’s <specifier>[ ...] <declarator>[, ...], where int, long, unsigned, struct stat, union { uint64_t u; double d; }, and even typedef are all specifiers, and foo, (foo), (((foo))), *bar, baz[10], (*spam)(int), and even (*eggs)[STRIDE] are all declarators (the wisdom of using the last one is debatable, but it is genuinely useful if you can count on the future maintainer to know what it means).
Everybody is free to not like the syntax, but actively misleading the reader about its workings seems counterproductive.
I swear if I see one more "int* x, y" example I will flip a keyboard. This isn't the 90s anymore. Everyone and their mother knows about this one pitfall, repeated for decades by people who have yet to read the memo that we now declare one variable per line, so it is never an issue. Even if you make this mistake, it's the least of your worries when coding in C because the compiler will typically warn you when you try to use the integer as a pointer.
Get with the program: types on the left, names on the right, one declaration per line.
Get with the program: types on the left, names on the right, one declaration per line.
Humans can normally treat C as if it is LR and get away with it, except for a few places that they can often recognize and avoid. It is a bad shortcut, but still one that you can get by with taking in a lot of code.
Historically, the point of writing 'begin' and 'end' instead of using curly braces was mostly support for non-ASCII character sets where the curly braces are not included. It's why C also has an alternate syntax using <% and %> and COBOL goes as far as writing out arithmetical operators as English text, such as DIVIDE x INTO y GIVING z.
Ada, at least, uses begin...end in part because it prevents certain kinds of errors. In its syntax you have to specify what you are ending, reducing the risk of invalid matches and increasing the likelihood of the error report system guessing correctly what you intended. E.g.:
if X > 0 then
Y := 0;
end if;
Ngl, I think that's brilliant. Braces matching the wrong brace is like a daily occurrence. It's such a tedious small thing that constantly hounds me whenever I'm writing code
In languages without this feature (most of them), you sometimes see long blocks get labeled at the end anyway. On the other hand, you could argue that if your block is long enough it doesn't fit on the screen, then it should be its own function anyway.
Like this, except replace "..." with many lines of code.
Like this, except replace "..." with many lines of code.
if (z.p == z.p.p.left) {
...
} else { // z.p != z.p.p.left
...
} // if> In languages without this feature (most of them), you sometimes see long blocks get labeled at the end anyway.
True. However, in Ada at least, if the block types don't match then it's a syntax error detected at compile time by the compiler. Comments like those listed above are often not checked at compile time, and thus aren't very useful for preventing errors.
True. However, in Ada at least, if the block types don't match then it's a syntax error detected at compile time by the compiler. Comments like those listed above are often not checked at compile time, and thus aren't very useful for preventing errors.
Most programming languages now support reformatters out of the box. Part of the point of those is to make mismatched closing braces more visible.
Rainbow brackets, so the brackets themselves are color coded to match with their corresponding partner, are also a godsend.
I'm surprised that code folding has never really become good/popular enough to make all these things non-issues.
Often it's only for named blocks like functions, and not for the really unhelpful bits like that conditional branch that is long, simple and deep, but really does not deserve spamming a namespace with an unhelpful identifier. And I've yet to see a deliberately short-lived folding to lessen the out of sight, out of mind tax that code folding of associated with. If there was deliberately short-lived folding, perhaps auto-reexpanding whenever the section has scrolled out of view, I'd use folding all the time, to navigate the nesting. The quasi-permanent until explicitly re-expanded cold folding? Yeah, I hardly ever use it, to many bad experiences with forgetting to re-expand.
Often it's only for named blocks like functions, and not for the really unhelpful bits like that conditional branch that is long, simple and deep, but really does not deserve spamming a namespace with an unhelpful identifier. And I've yet to see a deliberately short-lived folding to lessen the out of sight, out of mind tax that code folding of associated with. If there was deliberately short-lived folding, perhaps auto-reexpanding whenever the section has scrolled out of view, I'd use folding all the time, to navigate the nesting. The quasi-permanent until explicitly re-expanded cold folding? Yeah, I hardly ever use it, to many bad experiences with forgetting to re-expand.
Code folding is phenomenal for understanding a codebase and I'm really surprised it wasn't utilized more.
Everybody getting burned by fold+forget exactly once would be my guess.
Perhaps new generation of editors ("post VSC") that experiments with non-uniform size could perhaps lead to some form of revival? Fold to "code minimap" excerpt instead of away. UI might want to consider cursor position in the leading whitespace for depth selection. In mouse terms, interact with the vertical line some editors display (not sure this could be helpful for keyboard knowitalls who'd select depth by repetition)
Or maybe this all exists but the shortcuts aren't sufficiently well known to reach my lowly knowledge levels, that's one of the more frustrating aspects of what-iffing editor UI.
Perhaps new generation of editors ("post VSC") that experiments with non-uniform size could perhaps lead to some form of revival? Fold to "code minimap" excerpt instead of away. UI might want to consider cursor position in the leading whitespace for depth selection. In mouse terms, interact with the vertical line some editors display (not sure this could be helpful for keyboard knowitalls who'd select depth by repetition)
Or maybe this all exists but the shortcuts aren't sufficiently well known to reach my lowly knowledge levels, that's one of the more frustrating aspects of what-iffing editor UI.
Even with all these helpers, there's too much cognitive overhead and not enough that IDEs or plugins can do to take that away. Rainbow braces are nice and all, but it's not enough when the underlying concept is broken.
Scala 3 actually has a brace-less mode that supports this.
You can do this with PHP, too, but it’s on the rare side except in some templating niches.
The reverse-reserved-word convention like ‘fi’ to end an if block in shell (and other?) languages seems like it functions this way too.
And I guess significant indentation also does this job, albeit with some of its own hazards.
The reverse-reserved-word convention like ‘fi’ to end an if block in shell (and other?) languages seems like it functions this way too.
And I guess significant indentation also does this job, albeit with some of its own hazards.
I was under the impression that COBOL's English syntax was intended to be a more human-readable approach, not so much a workaround for character set limitations.
Maybe both? COBOL predates the first draft of ASCII by several years. Character sets were far from standardized in those days.
Lots (most?) of classic COBOL used EBCDIC[0]
[0] https://en.wikipedia.org/wiki/EBCDIC
[0] https://en.wikipedia.org/wiki/EBCDIC
Well some of the great ideas of yesteryear are having a bit of a rebirth. Many of the safety concerns of Ada are being brought into the limelight with Rust. And of course Erlang blew up a while back after spending forever in the (relative) shadows.
Overall we're still stuck in a bit of a near-monoculture of JS(TS) and Python, but it's a far cry from back in the day where there was very little openness to the sole blessed corporate stack (Typically Java or C#/CLR). I think we can only handle so many mainstream languages, but I do love all the experimentation and openness going on.
Overall we're still stuck in a bit of a near-monoculture of JS(TS) and Python, but it's a far cry from back in the day where there was very little openness to the sole blessed corporate stack (Typically Java or C#/CLR). I think we can only handle so many mainstream languages, but I do love all the experimentation and openness going on.
My impression from my limited experience with Pascal (more recently only playing around a bit with Free Pascal) is that much of the basic parts of the language, that a beginner like me is mostly exposed to, is very safe with strong typing and range-checking on all arrays. I do not know how far you can get in practical programming while sticking to those parts of the language, or how unsafe it gets once you start playing with pointers? I think the pointers are supposed to at least be safer than in C, unless you go out of your way to break things?
> But these days folks are mostly used to the C style syntax. And I'm not even arguing that it is a better language than C or others. But the whole industry has gone overall into believing that anything newly 'invented' is good and anything that's been around a while is passé
Problem of the Pascal syntax is that it prevents adoption of certain constructs, which are just not nice. A few examples
- lambda expression: `begin` ... `end`, say goodbye to nice one liners;
- binary assign: FPC has `+=` `-=` but obviously not `mod=`, `and=`, etc;
On top of that there are other things like
- shortened boolean evaluation (e.g `if someInt` => `if someInt != 0` is not possible because `and` is a two headed creature
- locals are still not default initialized
I use to like Pascal (actually Delphi then ObjFPC) much but nowaday I think the only good parts are in certain semantics, e.g no fallback in the `case`...`of` construct, manual memory management BUT ref counted arrays.
I would tend more to like a C like syntax with certain semantics coming from the Pascal world.
Problem of the Pascal syntax is that it prevents adoption of certain constructs, which are just not nice. A few examples
- lambda expression: `begin` ... `end`, say goodbye to nice one liners;
- binary assign: FPC has `+=` `-=` but obviously not `mod=`, `and=`, etc;
On top of that there are other things like
- shortened boolean evaluation (e.g `if someInt` => `if someInt != 0` is not possible because `and` is a two headed creature
- locals are still not default initialized
I use to like Pascal (actually Delphi then ObjFPC) much but nowaday I think the only good parts are in certain semantics, e.g no fallback in the `case`...`of` construct, manual memory management BUT ref counted arrays.
I would tend more to like a C like syntax with certain semantics coming from the Pascal world.
The problem with "one liners" and other coding is that its generally to clever. One of the things I like about python (despite not liking it that much) is for certain constructs there is "the one true way", for example the required formatting trains people to all read the same code. With C/etc languages there are dozens of different but in the end identical ways to express and format the same construct its crazy. And it creates unnecessary mental overhead, nevermind the if..fi..else ambiguities that aren't even standardized behavior.
So, much of what you are complaining is largely pointless syntactic sugar issues, like people complaining about the difficulty of typing "begin" vs "{" when any modern editor can autocomplete, and nevermind the difficult parts of programming are rarely the limit on how fast one can type 5 characters vs 1. I might even go so far as to say, slowing down a bit probably actually increases the code quality.
(PS: I've programmed professionally in pretty much every mainstream language and quite a number that aren't mainstream. IMHO Object Pascal strikes a far better balance of performant code, ease of development and maintenance, and developer safety than most of the languages in modern use, maybe all of them. Its frankly a shame that more places don't take it more seriously and would rather invent yet another poor half baked language that takes another few thousand man years of effort for the compiler writers and the users to overcome as they are discovered).
So, much of what you are complaining is largely pointless syntactic sugar issues, like people complaining about the difficulty of typing "begin" vs "{" when any modern editor can autocomplete, and nevermind the difficult parts of programming are rarely the limit on how fast one can type 5 characters vs 1. I might even go so far as to say, slowing down a bit probably actually increases the code quality.
(PS: I've programmed professionally in pretty much every mainstream language and quite a number that aren't mainstream. IMHO Object Pascal strikes a far better balance of performant code, ease of development and maintenance, and developer safety than most of the languages in modern use, maybe all of them. Its frankly a shame that more places don't take it more seriously and would rather invent yet another poor half baked language that takes another few thousand man years of effort for the compiler writers and the users to overcome as they are discovered).
> - lambda expression: `begin` ... `end`, say goodbye to nice one liners;
If there's one thing I would eliminate from programming, despite their benefits, is the one liner lambda expressions. It has turned clean, readable Python code into muddy statements I need to pause to compile in my head to understand.
I am not a fan.
If there's one thing I would eliminate from programming, despite their benefits, is the one liner lambda expressions. It has turned clean, readable Python code into muddy statements I need to pause to compile in my head to understand.
I am not a fan.
BEGIN/END needn't be a showstopper for one-line lambdas. Ruby has nice one-line lambda expressions where you can substitute `{` ... `}` for `do` ... `end`. A Pascal implementation can't do exactly that, but it could use an alternative syntax.
[deleted]
elixir allows one-line lambdas with `fn ... end`. they don't look as nice as they would have with braces but the parser handles them fine.
Wirth's disdain for C++ leads sometimes to chuckles in the audience at public lectures("C with 2 plusses")
> C with 2 plusses
I read it as "C with two pulses"... Which is how I feel about C++ - unnecessarily complicated.
I read it as "C with two pulses"... Which is how I feel about C++ - unnecessarily complicated.
I don't understand the joke you're making.
How does "pulse" equate to complicated?
How does "pulse" equate to complicated?
Two redundant cardiovascular systems that don't work together, presumably in such a way that a heart attack or exsanguination in either is lethal (as opposed to modular redundancy for improved reliability, which mostly isn't relevant at the software level).
C++ isn't really one language, but a language family with dozens if not more dialects. If you read some codebases from different places, you will sometimes, or even often, barely recognise what's going on (unless you are an advanced user).
In C++, people very much tend to pick a subset, so different pulses beat concurrently, if you will.
In C++, people very much tend to pick a subset, so different pulses beat concurrently, if you will.
same here
> But these days folks are mostly used to the C style syntax.
Mostly, but I'm told the new Austral[1] language has syntax very similar to that of Pascal's.
1: https://austral-lang.org/
Mostly, but I'm told the new Austral[1] language has syntax very similar to that of Pascal's.
1: https://austral-lang.org/
Unfortunately, LOGO uses dynamic scope. It could easily be a viable language aside from that one misfeature.
So does ELisp, by default :-)
During home school my daughter was learning about how data structures are represented in memory, which gave us the opportunity to explore how to represent strings as arrays, and thus: Pascal strings vs C strings
>But the whole industry has gone overall into believing that anything newly 'invented' is good and anything that's been around a while is passé.
I think this is partially accepted to keep wages down. New languages allow fresh developers to be on a level playing field with more senior developers. Both have say 2 years experience in said new language. Fresh developers are cheaper and therefore push down wages.
I think this is partially accepted to keep wages down. New languages allow fresh developers to be on a level playing field with more senior developers. Both have say 2 years experience in said new language. Fresh developers are cheaper and therefore push down wages.
It’s almost like there are improvements in PL design.
Also, at better places the language itself is a tool - someone will be a senior in any other language as well.
Also, at better places the language itself is a tool - someone will be a senior in any other language as well.
>It’s almost like there are improvements in PL design.
Eh, not really, at least not in the last 10+ years. I'm sure some obscure hotness does something neat, but mostly inconsequential for the vast, vast majority of shops.
>someone will be a senior in any other language as well.
While I agree with you, that often isn't the opinion of people hiring. If someone is looking for 2 years of java, in most places, 10 years of C# isn't what they are willing to hire.
Eh, not really, at least not in the last 10+ years. I'm sure some obscure hotness does something neat, but mostly inconsequential for the vast, vast majority of shops.
>someone will be a senior in any other language as well.
While I agree with you, that often isn't the opinion of people hiring. If someone is looking for 2 years of java, in most places, 10 years of C# isn't what they are willing to hire.
Hmm meh. I have a soft spot for Delphi/Object Pascal but I think the case here is not great. What it looks like at a glance is they wrote a better Pascal program than the Go one it was competing against, rather than just idiomatically port it. A fine approach, but it doesn't tell us that much. Specifically, it doesn't tell us very much about programming languages.
Go has plenty of weaknesses versus Pascal, but two commonalities of the languages are lightning fast compile times and a pretty good experience for modelling data structures. Pascal is undoubtedly lower level and does not guarantee memory safety, whereas Go does but its GC is often less efficient and more memory-heavy than manual allocation.
Blow for blow, though, I'd say the largest weak point for Pascal is a somewhat archaic syntax and for Go, honestly, the concurrency model. (Channels are nice, until they are not. I feel as though it's easier, though not necessarily easy, to write correct programs using mutexes than Go channels in many cases. This is weird, because nothing has changed about the old shared memory with locks model since it was the source of so many problems. Yet, programmers, computers and toolchains have changed a lot. Rust with locks is a great example.)
But the biggest problem for Pascal is the lack of a strong killer app. Back in the day, libraries like VCL made Delphi amazingly productive for desktop apps. But VCL/LCL doesn't really hold up as well these days, where desktop apps are less important and the important features of GUIs has shifted a lot. That leaves Delphi and Object Pascal as a sort-of also-ran: It's not that Go is especially good, in fact I'd argue its claim to fame and namesake (the concurrency model) just wound up being kind of ... bad. But, now that it's here and popular, there's little reason for e.g. Go developers to switch to Object Pascal, a less supported language with less of a job market, less library support, etc.
And that really is a shame, because it isn't really a reflection of Object Pascal being unfit for modern software development.
Go has plenty of weaknesses versus Pascal, but two commonalities of the languages are lightning fast compile times and a pretty good experience for modelling data structures. Pascal is undoubtedly lower level and does not guarantee memory safety, whereas Go does but its GC is often less efficient and more memory-heavy than manual allocation.
Blow for blow, though, I'd say the largest weak point for Pascal is a somewhat archaic syntax and for Go, honestly, the concurrency model. (Channels are nice, until they are not. I feel as though it's easier, though not necessarily easy, to write correct programs using mutexes than Go channels in many cases. This is weird, because nothing has changed about the old shared memory with locks model since it was the source of so many problems. Yet, programmers, computers and toolchains have changed a lot. Rust with locks is a great example.)
But the biggest problem for Pascal is the lack of a strong killer app. Back in the day, libraries like VCL made Delphi amazingly productive for desktop apps. But VCL/LCL doesn't really hold up as well these days, where desktop apps are less important and the important features of GUIs has shifted a lot. That leaves Delphi and Object Pascal as a sort-of also-ran: It's not that Go is especially good, in fact I'd argue its claim to fame and namesake (the concurrency model) just wound up being kind of ... bad. But, now that it's here and popular, there's little reason for e.g. Go developers to switch to Object Pascal, a less supported language with less of a job market, less library support, etc.
And that really is a shame, because it isn't really a reflection of Object Pascal being unfit for modern software development.
"Channels are nice, until they are not. I feel as though it's easier, though not necessarily easy, to write correct programs using mutexes than Go channels in many cases."
The rule for mutexes is, never take more than one. As long as you only ever take one, life is pretty good.
When all you had was mutexes as your primitive, though, that became a problem. One is not enough. You can't build a big program on mutexes, and taking only one at a time.
But as you add other concurrency primitives to take the load off of the lowly mutex, and as you do, the mutex returns to viability. I use a lot of mutexes in my Go code, and I can, precisely because when I have a case where I need to select from three channels in some complicated multi-way, multi-goroutine choice, I have the channels for that case. The other concurrency mechanisms take the hard cases, leaving the easy cases for mutexes to be fine for once again.
The story of software engineering in the 1990s was a story of overreactions and misdiagnoses. This was one of them. Mutexes weren't the problem; misuse of them was. Using them as the only primitive was. You really, really don't want to take more than one at a time. That goes so poorly that I believe it nearly explains the entire fear of multithreading picked up from that era. (The remainder comes from trying to multithread in a memory-unsafe language, which is also a pretty big mistake.) Multithreading isn't trivial, but it isn't that hard... but there are some mistakes that fundamentally will destroy your sanity and trying to build a program around multiple mutexes being taken is one of them.
(To forestall corrections, the technical rule is always take mutexes in the same order. I consider experience to have proved that doesn't scale, plus, honestly, just common sense shows that it isn't practical. So I collapse that to a rule: Never have more than held at a time. As soon as you see you need more than one, use a different mechanism. Do whatever it takes to your program to achieve that; whatever shortcut you have in mind that you think will be good enough, you're wrong. Refactor correctly.)
The rule for mutexes is, never take more than one. As long as you only ever take one, life is pretty good.
When all you had was mutexes as your primitive, though, that became a problem. One is not enough. You can't build a big program on mutexes, and taking only one at a time.
But as you add other concurrency primitives to take the load off of the lowly mutex, and as you do, the mutex returns to viability. I use a lot of mutexes in my Go code, and I can, precisely because when I have a case where I need to select from three channels in some complicated multi-way, multi-goroutine choice, I have the channels for that case. The other concurrency mechanisms take the hard cases, leaving the easy cases for mutexes to be fine for once again.
The story of software engineering in the 1990s was a story of overreactions and misdiagnoses. This was one of them. Mutexes weren't the problem; misuse of them was. Using them as the only primitive was. You really, really don't want to take more than one at a time. That goes so poorly that I believe it nearly explains the entire fear of multithreading picked up from that era. (The remainder comes from trying to multithread in a memory-unsafe language, which is also a pretty big mistake.) Multithreading isn't trivial, but it isn't that hard... but there are some mistakes that fundamentally will destroy your sanity and trying to build a program around multiple mutexes being taken is one of them.
(To forestall corrections, the technical rule is always take mutexes in the same order. I consider experience to have proved that doesn't scale, plus, honestly, just common sense shows that it isn't practical. So I collapse that to a rule: Never have more than held at a time. As soon as you see you need more than one, use a different mechanism. Do whatever it takes to your program to achieve that; whatever shortcut you have in mind that you think will be good enough, you're wrong. Refactor correctly.)
> The rule for mutexes is, never take more than one. As long as you only ever take one, life is pretty good.
Is there any shortcoming you can't apply that to? Don't malloc unless you free. If you cast in your program, make sure to cast to the correct type.
> The story of software engineering in the 1990s was a story of overreactions and misdiagnoses. This was one of them.
The problem of multiple mutexes was diagnosed well before the 90s. "Dining philosophers" was formulated in 1965.
Is there any shortcoming you can't apply that to? Don't malloc unless you free. If you cast in your program, make sure to cast to the correct type.
> The story of software engineering in the 1990s was a story of overreactions and misdiagnoses. This was one of them.
The problem of multiple mutexes was diagnosed well before the 90s. "Dining philosophers" was formulated in 1965.
https://www.adit.io/posts/2013-05-11-The-Dining-Philosophers-Problem-With-Ron-Swanson.html
https://www.adit.io/posts/2013-05-15-Locks,-Actors,-And-STM-In-Pictures.htmlYeah, I can relate to this. When coding in Go I routinely combine mutexes and channels. Channels are useful for signalling and some other things. I am a bit miffed though since it absolutely feels like CSP concurrency and message passing COULD be better, it's just not in Go. Maybe I'll try Erlang some day and be imbued with the curse of knowledge.
Rust doesn't solve the problem of multiple mutexes being tricky, but it does at least solve most of the other problems with sharing memory. To gain a little more assurance with Go, I do sometimes use the checklocks analyzer from gVisor, which gets you some of the way.
Rust doesn't solve the problem of multiple mutexes being tricky, but it does at least solve most of the other problems with sharing memory. To gain a little more assurance with Go, I do sometimes use the checklocks analyzer from gVisor, which gets you some of the way.
"Maybe I'll try Erlang some day and be imbued with the curse of knowledge."
For the purposes of this discussion [1], Erlang is just Go except you don't have mutexes as an option at all, so anything you want locked has to be in a separate Erlang process (analog of goroutine). So if all you want is a shared dictionary to be used as a cache or something, it has to have its own process/goroutine, you don't get an option of just locking access.
Since that's how it works in Erlang, it has a bit of syntax grease around it, but not enough to make it just right; you've still got to do things like handle communication errors because it could be on a different node in a cluster whereas in Go it's just a local shared resource.
I think the main problem is that as useful as actors are as a concept, they're not a great foundational abstraction, which is to say, the base that everything is built on and you can't go below. It works, but then it means you're paying the full actor price for everything. But you don't always want the full actor price for everything, and you don't need to pay it because in practice "lack of actor isolation" is rarely the root cause for any particular problem, because that's too big a thing to be the root cause.
[1]: If that's too glib for you: https://news.ycombinator.com/item?id=34564228
For the purposes of this discussion [1], Erlang is just Go except you don't have mutexes as an option at all, so anything you want locked has to be in a separate Erlang process (analog of goroutine). So if all you want is a shared dictionary to be used as a cache or something, it has to have its own process/goroutine, you don't get an option of just locking access.
Since that's how it works in Erlang, it has a bit of syntax grease around it, but not enough to make it just right; you've still got to do things like handle communication errors because it could be on a different node in a cluster whereas in Go it's just a local shared resource.
I think the main problem is that as useful as actors are as a concept, they're not a great foundational abstraction, which is to say, the base that everything is built on and you can't go below. It works, but then it means you're paying the full actor price for everything. But you don't always want the full actor price for everything, and you don't need to pay it because in practice "lack of actor isolation" is rarely the root cause for any particular problem, because that's too big a thing to be the root cause.
[1]: If that's too glib for you: https://news.ycombinator.com/item?id=34564228
> The rule for mutexes is, never take more than one.
Ideally the actual rule is, never take a mutex while holding another mutex. You can take multiple mutexes simultaneously if the API supports it. (The problem is the API usually doesn't support it unless you implement the mutexes yourself using lower-level primitives, but that requires not actually using mutexes as your primitive.)
( > the technical rule is always take mutexes in the same order.
As you note, this doesn't actually work in practice, since you've given youself the opprotunity to get the order wrong every single time you do it.)
Ideally the actual rule is, never take a mutex while holding another mutex. You can take multiple mutexes simultaneously if the API supports it. (The problem is the API usually doesn't support it unless you implement the mutexes yourself using lower-level primitives, but that requires not actually using mutexes as your primitive.)
( > the technical rule is always take mutexes in the same order.
As you note, this doesn't actually work in practice, since you've given youself the opprotunity to get the order wrong every single time you do it.)
Mutexes aren't OK even if you only use one. They are error prone, you can forget to unlock. And of course, there is a temptation to avoid using it for efficiency reasons, because you "know" this part of the code is safe.
These days I develop servers on the JVM. We almost never think about mutexes or related things, libraries take care of that. I use Scala, and our entire data model is immutable, eliminating most race conditions. I think I had to declare something as volatile once or twice.
These days I develop servers on the JVM. We almost never think about mutexes or related things, libraries take care of that. I use Scala, and our entire data model is immutable, eliminating most race conditions. I think I had to declare something as volatile once or twice.
> They are error prone, you can forget to unlock
That's not a problem with mutexes but with resource management in some languages. In Rust mutexes use RAII and unlock automatically - you cannot accidentally forget to unlock.
That's not a problem with mutexes but with resource management in some languages. In Rust mutexes use RAII and unlock automatically - you cannot accidentally forget to unlock.
Yes but it is very easy to hold mutexes locked longer than needed because you usually don't think about when stuff is dropped in Rust, you just let it go out of scope.
I have gotten really annoying deadlocks because of this in the past.
I have gotten really annoying deadlocks because of this in the past.
Fair point, but in order to make a deadlock, you need a reference back to the object that holds the lock. And back references in Rust are hard to make. Most of the time if you unlock too late, you get a performance problem, not a deadlock.
> They are error prone, you can forget to unlock
That's a language issue though, rather than a mutex one. It's reasonably straightforward to fix that, as some languages (like Nim) do.
That's a language issue though, rather than a mutex one. It's reasonably straightforward to fix that, as some languages (like Nim) do.
> The story of software engineering in the 1990s was a story of overreactions and misdiagnoses.
This is a recurring theme, not one isolated to the 90s.
This is a recurring theme, not one isolated to the 90s.
I think it's better to avoid time-related adjectives like "archaic" when talking about PLs. For starters it doesn't really mean much in general: in software development fashions come, and go, and then reappear as "new" again. Secondly, Pascal syntax is of the same historical age as that of C, and the ML languages. Would you say that C# (or Haskell) is syntactically archaic?
OK, how about "cumbersome" or "unnecessarily verbose". I haven't used modern Pascal, but the ancient version I used was also very limited.
I am 60, have used many languages, and used to love C and C++. I consider C and C++ archaic and Java is border-line. I thought Java was cool 10-20 years ago, but I've moved on to Scala.
I am 60, have used many languages, and used to love C and C++. I consider C and C++ archaic and Java is border-line. I thought Java was cool 10-20 years ago, but I've moved on to Scala.
It's verbose for sure (though Pascal's overall amount of boileplate probably takes less space compared to Java code). Structurally it's almost the same beast (both inherited from Algol), with notable exceptions like for loop.
Scala feels more modern than C to me too, when talking about language concepts/features. Regarding syntax they are in the same basket.
Scala feels more modern than C to me too, when talking about language concepts/features. Regarding syntax they are in the same basket.
More people are familiar with Pascal and its syntax so I understand why people discuss it so much but it was succeeded by Modula-2, Ada, and Oberon which have better syntax.
One thing that is better about the syntax that I really like is the removal of BEGIN and END everywhere except around code in MODULEs and PROCEDUREs. IF/THEN/ELSE/END, FOR/DO/END, REPEAT/UNTIL, WHILE/DO/END, CASE/ELSE/END, no longer have BEGIN/END, even if there are multiple statements in them. This makes the code less verbose than C and C++ and equally or more compact vertically than them, depending on whether you put your braces on separate lines.
One thing that is better about the syntax that I really like is the removal of BEGIN and END everywhere except around code in MODULEs and PROCEDUREs. IF/THEN/ELSE/END, FOR/DO/END, REPEAT/UNTIL, WHILE/DO/END, CASE/ELSE/END, no longer have BEGIN/END, even if there are multiple statements in them. This makes the code less verbose than C and C++ and equally or more compact vertically than them, depending on whether you put your braces on separate lines.
I'm not convinced: the term archaic implies that something is obsolete or subjectively old-fashioned, not just that it's necessarily old. C# isn't archaic in part because C never stopped being relevant this whole time and because C# syntax has evolved significantly in recent years.
It's not something to differentiate between them: neither is obsolete as long as somebody uses it to earn, and Pascal dialects has been evolving as well as C#, while neither deviated significantly from their roots. TypeScript (which is rather new PL) uses Pascal-style for types. Haskell, and Ocaml are niche too, and the syntax is 98% from 70s, but it still feels like a new for someone who sees them for the first time. And let's not even touch what hardcore Pythonistas think about what "old-fashioned" means.
Pascal syntax is non-mainstream nowadays, as well as Lisps, MLs, and lots of others, but neither fits to the word "archaic"
Pascal syntax is non-mainstream nowadays, as well as Lisps, MLs, and lots of others, but neither fits to the word "archaic"
Sorry, I am not convinced. To me, Pascal's syntax and source code organization is archaic. Even more archaic would be COBOL and BCPL. On a somewhat similar level to Pascal, perhaps Erlang as well.
People's opinions do change over time, but I do not think it's likely that there is a renaissance awaiting Pascal's overall design decisions, specifically the ways in which Pascal differs from C. That's because differing from C is costly and requires justification. In some cases, I think Pascal's decisions just proved wrong; like the lack of short-circuiting in boolean expressions. I assume modern Pascal compilers have resolved this, but it's a good example of how I think things go: ideas that improve the status quo are worth bringing back, ideas that have a lot of switching costs are a hard sell.
I also understand that sometimes the difference may seem superficial, and that's because they are. Are Pascal units really vastly different from modern translation units/modules? Somewhat, but not that much. But it differs enough that someone not familiar with Pascal needs some time to adapt, whereas almost anyone with programming experience of any level can pick up Go, because it's stupidly simple. It does differ from C and other languages that are still contemporary, but when it does differ it's often good: the type syntax and declaration syntax is massively simpler than C, for example. (And yes, Pascal's type syntax is also better, at least by some measures.)
I'm happy to discuss these matters, but I will also be completely honest: I'm not particularly moved by this line of argument. It feels somewhere between semantics and an implicit desire to consider a future where Pascal syntax somehow becomes in vogue again as it was in the early 2000's. Maybe an evolved Pascal, but not the Pascal of today. And if I'm wrong, I'm wrong; I'm just calling it the way I see it.
People's opinions do change over time, but I do not think it's likely that there is a renaissance awaiting Pascal's overall design decisions, specifically the ways in which Pascal differs from C. That's because differing from C is costly and requires justification. In some cases, I think Pascal's decisions just proved wrong; like the lack of short-circuiting in boolean expressions. I assume modern Pascal compilers have resolved this, but it's a good example of how I think things go: ideas that improve the status quo are worth bringing back, ideas that have a lot of switching costs are a hard sell.
I also understand that sometimes the difference may seem superficial, and that's because they are. Are Pascal units really vastly different from modern translation units/modules? Somewhat, but not that much. But it differs enough that someone not familiar with Pascal needs some time to adapt, whereas almost anyone with programming experience of any level can pick up Go, because it's stupidly simple. It does differ from C and other languages that are still contemporary, but when it does differ it's often good: the type syntax and declaration syntax is massively simpler than C, for example. (And yes, Pascal's type syntax is also better, at least by some measures.)
I'm happy to discuss these matters, but I will also be completely honest: I'm not particularly moved by this line of argument. It feels somewhere between semantics and an implicit desire to consider a future where Pascal syntax somehow becomes in vogue again as it was in the early 2000's. Maybe an evolved Pascal, but not the Pascal of today. And if I'm wrong, I'm wrong; I'm just calling it the way I see it.
> like the lack of short-circuiting in boolean expressions. I assume modern Pascal compilers have resolved this
I think your ideas on Pascal are a little outdated if you assume short circuit boolean expression are a modern Pascal compiler change. Turbo Pascal, one of the by far most common dialects, had that since the 80s, meaning this change has been around for four decades (assuming Turbo Pascal didn't take it from some other popular at the time dialect like USCD Pascal).
I think your ideas on Pascal are a little outdated if you assume short circuit boolean expression are a modern Pascal compiler change. Turbo Pascal, one of the by far most common dialects, had that since the 80s, meaning this change has been around for four decades (assuming Turbo Pascal didn't take it from some other popular at the time dialect like USCD Pascal).
Delphi was really a "Concorde moment" in that it was actually rapid, both in terms of development speed, and performance, which was somehow forgotten as the web emerged.
Forgotten to the point that people thought Visual Basic was a good idea.
Forgotten to the point that people thought Visual Basic was a good idea.
Delphi was great but a major deal breaker was that is was not free to use.
Early versions of Delphi were cheap enough ($99) even a high schooler could pool the money to buy it (or, more realistically, ask their parents :-P). That lasted until Delphi 5 IIRC.
The real dumb move (though TBH i can only say that in hindsight) was that they made a free Linux version with Kylix, the license required any programs released to be under GPL but they didn't release Kylix itself as GPL.
This was in very early 2000s, when GPL wasn't the boogieman among developers that seems to be nowadays with all the permissive licenses, desktop software was still something people wanted, commercial software wouldn't touch GPL and yet a lot of new programmers were onboarding Linux. Having Delphi/Kylix full GPL with a CLA (like some other projects) would mean that a) Kylix would become part of various Linux distributions, especially during a time when distributions were the main source for tools for Linux users, b) anyone working on FLOSS would both use and improve the tool, c) mindshare among programmers would improve as anyone will be able to try it out for free (as long as they used Linux, but many programmers - especially younger programmers at the time - didn't mind that), d) companies, enterprises, etc that wanted to sell shareware or just didn't want the rules GPL imposed would still need to buy the full program
Sadly this seemed to be yet another case of when Borland started losing touch with programmers in the 90s.
The real dumb move (though TBH i can only say that in hindsight) was that they made a free Linux version with Kylix, the license required any programs released to be under GPL but they didn't release Kylix itself as GPL.
This was in very early 2000s, when GPL wasn't the boogieman among developers that seems to be nowadays with all the permissive licenses, desktop software was still something people wanted, commercial software wouldn't touch GPL and yet a lot of new programmers were onboarding Linux. Having Delphi/Kylix full GPL with a CLA (like some other projects) would mean that a) Kylix would become part of various Linux distributions, especially during a time when distributions were the main source for tools for Linux users, b) anyone working on FLOSS would both use and improve the tool, c) mindshare among programmers would improve as anyone will be able to try it out for free (as long as they used Linux, but many programmers - especially younger programmers at the time - didn't mind that), d) companies, enterprises, etc that wanted to sell shareware or just didn't want the rules GPL imposed would still need to buy the full program
Sadly this seemed to be yet another case of when Borland started losing touch with programmers in the 90s.
For students and hobbyist, yes and was probably a dumb MBA lead decision because it stops the developer pipeline.
OTOH, As many tool vendors will tell you its foolish to dismiss a tool simply based on price. If your paying your developers $100 an hour even tiny improvements in productivity can easily pay for a $1000 or more tool. Just the compilation speed alone vs C/etc is probably worth the 5+ mins a day in savings.
OTOH, As many tool vendors will tell you its foolish to dismiss a tool simply based on price. If your paying your developers $100 an hour even tiny improvements in productivity can easily pay for a $1000 or more tool. Just the compilation speed alone vs C/etc is probably worth the 5+ mins a day in savings.
It is, but it stops a large number of people from being conversant with your tool and that in turn almost guarantees market failure. I've got a super luxurious toolchain on my computer because of the free software movement and it may not be as flashy as what you can get commercially but it suffices for all of my needs.
The later versions (somewhere after 2005) were also very buggy and sluggish. They produced fast code, but you really needed a powerful workstation.
With 20 years of hindsight I am not saying I can objectively talk about it but I kinda hated Pascal, with syntax and everything and so I didn't really try Delphi.
Visual Basic 5 was kinda awesome.
It may very well be that if I had looked at both again after, say, 5 years of programming I might have different views, but even now I still look back fondly on VB, it got shit done, esp if you needed a quick UI with not a lot of business logic.
Visual Basic 5 was kinda awesome.
It may very well be that if I had looked at both again after, say, 5 years of programming I might have different views, but even now I still look back fondly on VB, it got shit done, esp if you needed a quick UI with not a lot of business logic.
Delphi (and probably also Free Pascal?) is not wholly memory safe, but at least it has bounds checking for arrays and a sane string type, which is more than you get with C...
I'm an ex-Delphi developer myself, and actually Go and Pascal are more closely related than you might think at first glance: Go code looks mostly like a C-family language, but the declaration syntax ("a int" instead of "int a") and the "package" concept which helps achieve fast compilation times are borrowed from Pascal. And both have a ":=" operator, although in Go it declares and assigns variable(s) with type inference, while in Pascal it's any assignment.
I'm an ex-Delphi developer myself, and actually Go and Pascal are more closely related than you might think at first glance: Go code looks mostly like a C-family language, but the declaration syntax ("a int" instead of "int a") and the "package" concept which helps achieve fast compilation times are borrowed from Pascal. And both have a ":=" operator, although in Go it declares and assigns variable(s) with type inference, while in Pascal it's any assignment.
This article reads more like an ad for mORMot 2 than Pascal. I've been out of the Pascal game for a few years, so I had to look up mORMot 2.[0] Apparently Synopse are the maintainers of it.
The article basically compare their CSV/JSON serialising library to Go's standard CSV/JSON libraries. Looking at the Go code, it's pretty clear why it has memory issues, it reads all the lines into a single object (well, `[][]string`) immediately, rather than reading line for line (which takes advantage of the stream).
I am not sure how this is remarkable and impressive for Pascal. They talk about how you don't need to use the `try..finally..Free` routine all the time, but that's only if the object in question is an interface. Interfaces are somehow handled by a reference counter in Object Pascal, so you need to know how to operate on objects vs interfaces, because they act very different. Pascal is full of these quirks.
[0] https://github.com/synopse/mORMot2
The article basically compare their CSV/JSON serialising library to Go's standard CSV/JSON libraries. Looking at the Go code, it's pretty clear why it has memory issues, it reads all the lines into a single object (well, `[][]string`) immediately, rather than reading line for line (which takes advantage of the stream).
I am not sure how this is remarkable and impressive for Pascal. They talk about how you don't need to use the `try..finally..Free` routine all the time, but that's only if the object in question is an interface. Interfaces are somehow handled by a reference counter in Object Pascal, so you need to know how to operate on objects vs interfaces, because they act very different. Pascal is full of these quirks.
[0] https://github.com/synopse/mORMot2
I have lingering distain for Pascal, unlike other people here...
In 1980 I was a freshman at UCSC, and the professors did not like C. So most classes used UCSD Pascal. While it apparently pioneered some cool ideas, it was not at all ready for industry use. The free function was just a suggestion, it didn't deallocate anything. Arrays were fixed size, and an array of size 80 was a different type than size 255 (and 255 was the maximum).
I remember the compiler class where we built a compiler-compiler using Pascal. It was pretty cool that the professor came up with a design that worked, but also quite dumb as we had to pass around a bunch of 255 char arrays. And also insane that we couldn't use the industrial strength tools like C and yacc available on the VAX / UNIX computers...
But what about Modulo-2? Well one professor would torture the class, making them use various not-C languages. One year it was PLZ (A PL/I based language created by Zilog Corporation). When I took the class, it was Modulo-2, using a compiler developed at CMU I think. It also implemented free() as a suggestion that did nothing, and had other warts. I was not impressed...
I realize that it is unfair complaining about shitty academic implementations, but that's what I lived through.
In 1980 I was a freshman at UCSC, and the professors did not like C. So most classes used UCSD Pascal. While it apparently pioneered some cool ideas, it was not at all ready for industry use. The free function was just a suggestion, it didn't deallocate anything. Arrays were fixed size, and an array of size 80 was a different type than size 255 (and 255 was the maximum).
I remember the compiler class where we built a compiler-compiler using Pascal. It was pretty cool that the professor came up with a design that worked, but also quite dumb as we had to pass around a bunch of 255 char arrays. And also insane that we couldn't use the industrial strength tools like C and yacc available on the VAX / UNIX computers...
But what about Modulo-2? Well one professor would torture the class, making them use various not-C languages. One year it was PLZ (A PL/I based language created by Zilog Corporation). When I took the class, it was Modulo-2, using a compiler developed at CMU I think. It also implemented free() as a suggestion that did nothing, and had other warts. I was not impressed...
I realize that it is unfair complaining about shitty academic implementations, but that's what I lived through.
the T(wo)LA of UC in UCSD/UCSC can't be entirely ignored. the p-system was very innovative, but ultimately got sidelined I think UC decided to self-host its teaching paradigm, well and good. If you'd gone to any other university without UC in its name you might not have had the p-System thrown at you so much. Obviously if you'd gone to UCB, things would have been radically different.
The interesting thing to me is that San Diego hosts the supercomputer centre and so there was a sense the engineers there really live in Fortan, did, and do.
(I was in the UK system at the same time as you, and my uni had Wirth on sabbatical for a year, during the ada/modula specification days. We all learned on Pascal on a Dec-10, unless you chose the other door and went LISP. I regret not going in the LISP door now, but hindsight is like that)
The interesting thing to me is that San Diego hosts the supercomputer centre and so there was a sense the engineers there really live in Fortan, did, and do.
(I was in the UK system at the same time as you, and my uni had Wirth on sabbatical for a year, during the ada/modula specification days. We all learned on Pascal on a Dec-10, unless you chose the other door and went LISP. I regret not going in the LISP door now, but hindsight is like that)
My friend told me that functional languages didn't like IO, and that they used recursion instead of loops. I thought "that is fucking nuts" and stuck with C. I basically had Dunning-Kruger in my youth.
Now I am a Scala programmer, often doing pure-FP with Cats...
Now I am a Scala programmer, often doing pure-FP with Cats...
Is it just me or does hearing "Zilog Corporation" not sound like it's straight out of the movie "Blade Runner"?
Lol, I added corporation because I assumed the youngsters didn't know about it. After googling, I see they called themselves Zilog, Inc.
I think you meant Modula-2, in many ways a successor to Pascal.
https://en.wikipedia.org/wiki/Modula-2
https://en.wikipedia.org/wiki/Modula-2
Yes, a typo. My friends referred to it as Modula-screw.
Modula-2 is a lot better than Pascal. Less verbose, many fewer BEGIN/END blocks.
Ada and Oberon are even better.
Ada and Oberon are even better.
I have fond memories of using Turbo Pascal. It was quite useful and pragmatic and it looks like Free Pascal inherited that.
I also remember having to use some other (standard?) Pascal at university and it was much more limited and had annoying strict limitations like you describe. It seemed far less useful for anything practical. If that was my only experience with Pascal I would probably not have very fond memories.
I also remember having to use some other (standard?) Pascal at university and it was much more limited and had annoying strict limitations like you describe. It seemed far less useful for anything practical. If that was my only experience with Pascal I would probably not have very fond memories.
I used Delphi in the 90's and early 00's, and really loved how simple it was to create desktop applications. I tried to get back into Pascal via Lazarus a few years ago, but was just very turned off by Pascal itself. The conventions just differ so much from other more popular languages that I use for work now, and there just isn't the same level of stack overflow questions/answers to make it easy to pick up. I guess with ChatGPT, it should be a lot easier to pick up now, so maybe I should give it another go.
“In the race”
What a terrible habit we have of speaking about our tools like they’re in competition with each other!
I don’t think I’ll ever meet a carpenter who talks about their hammer or even their manual crank drill being “still in yhe race”.
Tools have contexts where they might be used. Sometimes one tool will supersede another for all the day’s tasks, but tomorrow’s tasks will be different in unknown ways and whatever distinguishes one tool from another may be just the right thing there.
In programming languages, that might look like somebody setting aside a paradigm for a while because projects and architectures went a certain way, but then reviving that paradigm again when they go some other way.
Pascal has some cool stuff to it. We should be curious about that stuff and keep it in mind as new contexts emerge; but it’s never been in a race and we really don’t do ourselves much good in talking about it that way.
What a terrible habit we have of speaking about our tools like they’re in competition with each other!
I don’t think I’ll ever meet a carpenter who talks about their hammer or even their manual crank drill being “still in yhe race”.
Tools have contexts where they might be used. Sometimes one tool will supersede another for all the day’s tasks, but tomorrow’s tasks will be different in unknown ways and whatever distinguishes one tool from another may be just the right thing there.
In programming languages, that might look like somebody setting aside a paradigm for a while because projects and architectures went a certain way, but then reviving that paradigm again when they go some other way.
Pascal has some cool stuff to it. We should be curious about that stuff and keep it in mind as new contexts emerge; but it’s never been in a race and we really don’t do ourselves much good in talking about it that way.
programming languages (and some other categories of software used to create things) depend strongly on having an active user and developer base, because the range of things that people want to do with them keeps changing and growing. so in that sense there is a competition for mindshare, and languages that don't "keep up" get an increasingly large list of things that you can't use them for because no one has written the libraries, or the compiler backend, or the bindings, or whatever that you need to get your task done.
Sort of, but that’s less true than ever in an age of .net, java, and js/wasm runtimes that let you easily bridge between your project’s language and libraries written in other languages.
Standing up an established language in one of these runtimes is an upper division college level project. If you strongly felt that Algol was the clearest or most inspiring way to express your project, it’s not nearly so out of reach as it was a few decades ago.
That’s exactly why we’ve had this cambrian explosion of new and revived languages lately.
Standing up an established language in one of these runtimes is an upper division college level project. If you strongly felt that Algol was the clearest or most inspiring way to express your project, it’s not nearly so out of reach as it was a few decades ago.
That’s exactly why we’ve had this cambrian explosion of new and revived languages lately.
Only if you are in those respective ecosystems. I write embedded code so I don't get any of those options. Most of my code is in C++ because historically that is what we knew best (we have been updating to modern C++, so it is one of the better C++ code bases, but still it has the warts of C++). Integrating anything other than C++ into our code is hard. Many things are a class, most with virtual functions (London vs Detroit mocking is a different rant), and nothing except C++ really knows how to deal with it. Then there are templates - std::vector is the perfect type for so many things, but again nothing else can deal with it.
I keep trying to figure out how to use something else, but it is really hard to break in. Those who have tried before me gave up because of the friction.
I keep trying to figure out how to use something else, but it is really hard to break in. Those who have tried before me gave up because of the friction.
That's because it's a zero sum game and one of the reason why you see advocates for new languages fighting for market share attacking older languages because they know that only so much software gets written.
I programmed in Delphi since version 1 (before that of course Turbo Pascal) and I loved the system, a lot. The entire system is snappy, easy to use and beautifully designed. It was ways ahead of its time.
Recently, I came back to a pet project: genetic algorithms. I wrote a library for it with polymorphism, generics and some other (actually not so complicated) stuffs in FPC/Lazarus and then I must notice that my productivity suffered quite significantly compared to other languages like Python and F#. The thing is, on the first glance, everything is fine but going into the details, many small issues turnout to be big blockers.
For example, FPC introduced constref modifier for parameters. But if you declared as const instead, the compiler will still gives green light. But when running, the result is different in an inexplicable manner. Then there is a very subtle difference between a local procedure/function and a global one using as a comparer. Program compiled just fine without any hint or warning but the result is inexplicably wrong and causes a great deal of debugging effort. That was the case with generic objects list and sorting. Then there is obviously the problem with documentation and the excessive use of overloading and type alias in many libraries. For examples, TFixedPoint and TPoint in the Graphics32 library are totally different, but unfortunately assignment compatible. Thus without good documentation, one can mistakenly pass the parameters for one function for the other and the compiler can not detect it, ultimately defies the purpose of a strong static typing system. Not to mention the (not so small) quality issues with the tooling like the internal debugger crash or (sometimes) missing of declaration informations inside the editor.
All in all, I feel the Delphi/FP language is getting old and freight with many technical debts. Trying to introduce new concepts while keeping backward compatibility can make a programming language/system so bloat and hulking that maintain quality can hardly be achieved. It still serves the purpose but it requires IMO an urgent revamp.
Recently, I came back to a pet project: genetic algorithms. I wrote a library for it with polymorphism, generics and some other (actually not so complicated) stuffs in FPC/Lazarus and then I must notice that my productivity suffered quite significantly compared to other languages like Python and F#. The thing is, on the first glance, everything is fine but going into the details, many small issues turnout to be big blockers.
For example, FPC introduced constref modifier for parameters. But if you declared as const instead, the compiler will still gives green light. But when running, the result is different in an inexplicable manner. Then there is a very subtle difference between a local procedure/function and a global one using as a comparer. Program compiled just fine without any hint or warning but the result is inexplicably wrong and causes a great deal of debugging effort. That was the case with generic objects list and sorting. Then there is obviously the problem with documentation and the excessive use of overloading and type alias in many libraries. For examples, TFixedPoint and TPoint in the Graphics32 library are totally different, but unfortunately assignment compatible. Thus without good documentation, one can mistakenly pass the parameters for one function for the other and the compiler can not detect it, ultimately defies the purpose of a strong static typing system. Not to mention the (not so small) quality issues with the tooling like the internal debugger crash or (sometimes) missing of declaration informations inside the editor.
All in all, I feel the Delphi/FP language is getting old and freight with many technical debts. Trying to introduce new concepts while keeping backward compatibility can make a programming language/system so bloat and hulking that maintain quality can hardly be achieved. It still serves the purpose but it requires IMO an urgent revamp.
> freight with many technical debts
"Freight" is a noun, not a verb. I can't guess the word you meant.
"Freighted"? (Weighed down.) "Fraught"? (Troubled by.)
The sad thing is that Pascal continued to evolve, but TP codified and fossilised it and that seems to be becoming a problem now.
Pascal evolved into Modula, which fairly soon became Modula-2 which is still around and enjoyed a moment in the sun.
(Modula-3 was someone else.)
Modula-2 evolved into Oberon, which is also still around.
Oberon evolved into Oberon 2, then was rebooted with Oberon 07, but which also led on to Active Oberon and Zennon.
Oberon+ is an attempt to re-unify them.
https://oberon-lang.github.io/
"Freight" is a noun, not a verb. I can't guess the word you meant.
"Freighted"? (Weighed down.) "Fraught"? (Troubled by.)
The sad thing is that Pascal continued to evolve, but TP codified and fossilised it and that seems to be becoming a problem now.
Pascal evolved into Modula, which fairly soon became Modula-2 which is still around and enjoyed a moment in the sun.
(Modula-3 was someone else.)
Modula-2 evolved into Oberon, which is also still around.
Oberon evolved into Oberon 2, then was rebooted with Oberon 07, but which also led on to Active Oberon and Zennon.
Oberon+ is an attempt to re-unify them.
https://oberon-lang.github.io/
“Usually, at our age, we should be managers, not developers.”
There’s a lot of assumptions and bias in here.
There’s a lot of assumptions and bias in here.
I'd prefer to be a senior staff engineer, or whatever they call the technical leaders. The pay isn't quite as good as upper management, but it is equal to regular management and I get to do technical things. I just have to be careful not to direct others to make a big unmaintainable mess.
Yeah ageism wasn't always part of our profession. It was probably a side effect of rapid progress combined with the desire for wage suppression. It has let us move faster as old bad ideas lose their champions faster, but we then lose all the old good ideas too. Not every developer should turn into a manager. We don't need that many managers, and good managers are more rare than good developers in my experience. Having a stereotype that old developers that aren't rich yet must be bad developers comes and goes as the bubbles form and burst. If you develop in a domain where developers need lots of on the job expertise before being productive, or in embedded or game development where a big part of TC is job enjoyment, then that stereotype is already stale and career staff developers can regularly be geniuses.
On the other hand people smart enough to be engineers are smart enough to be in management so if that is your interest the world has a lot of people who for whatever reason can't won't do management. While managing other engineers is a way in, once you are in management you can do run a factory or a construction site and those often are places where workers cannot break into management.
There are a lot of different types of intelligence. I have met many brilliant developers that made horrible managers. And I have met many developers that we joked they moved to management to protect the codebase, that turned out to be great managers. That is a good point though, that many jobs don't have paths into managing those same jobs.
pascal was the 2nd language i learned after basic and it was the best time of my learning life. the fact that you could add inline assembler code and the early attempts of object oriented programming were amazing.
it was turbo pascal 6.0 btw.
Inline assembler was a killer feature: you could optimize bits of your code without having to understand how an assembler works and without having to deal with a linker as Pascal compiler did everything itself.
Great time indeed !
Great time indeed !
Not to mention you had a running program milliseconds after Ctrl-F9. I get modern apps require so much more stuff to run but I still miss that zippy experience.
+1 for the fast compile time. TurboPascal was not a marketing name, it was that fast, including my old 386 machine.
But TBH, nowaday's compilers do so much more, I'll happily trade compile time for that !
But TBH, nowaday's compilers do so much more, I'll happily trade compile time for that !
>> And... Pascal is still in the race for sure!
And what about.. umm... Modula 2/3 or Oberon? They don't gain as much industry attractions as Pascal does, eh?
And what about.. umm... Modula 2/3 or Oberon? They don't gain as much industry attractions as Pascal does, eh?
Wirth went too far with Modula, case sensitivity is a bug, not a feature. He became obsessed with purity, instead of usability.
Anders Hejlsberg was the author of the best Pascal implementation, greatly enhancing Pascal until he was seduced by Microsoft and helped start the evil that is .NET and C#.
Delphi was great until Borland decided to abandon most of their user base and pursue the corporate market.
Lazarus/Free pascal is really good, except for the abysmal documentation. The very lumpy approach to creating help actively prevents incremental improvements. There's no way to just fix one page of the help.
Anders Hejlsberg was the author of the best Pascal implementation, greatly enhancing Pascal until he was seduced by Microsoft and helped start the evil that is .NET and C#.
Delphi was great until Borland decided to abandon most of their user base and pursue the corporate market.
Lazarus/Free pascal is really good, except for the abysmal documentation. The very lumpy approach to creating help actively prevents incremental improvements. There's no way to just fix one page of the help.
> case sensitivity is a bug, not a feature.
Agree; that was the first thing I changed in https://oberon-lang.github.io/; besides the few academic oddities, original Oberon is a much better language than Pascal or Modula.
> He became obsessed with purity, instead of usability
There was definitely an academic bubble; for example, the claim that Oberon is a system language and can only be specified with 16 pages is demonstrably false, especially since there is a lot of code in the Oberon system that can only be implemented at all by means of (partially undocumented) backdoors to the language; unfortunately, these backdoors bypass the compiler's type checking.
> Lazarus/Free pascal is really good, except for the abysmal documentation
Unfortunately, the language is a huge, partly unspecified patchwork, where apparently all sorts of current fashionable constructs have been built in, partly even redundantly. The resulting complexity is hardly manageable with the present development approach.
Agree; that was the first thing I changed in https://oberon-lang.github.io/; besides the few academic oddities, original Oberon is a much better language than Pascal or Modula.
> He became obsessed with purity, instead of usability
There was definitely an academic bubble; for example, the claim that Oberon is a system language and can only be specified with 16 pages is demonstrably false, especially since there is a lot of code in the Oberon system that can only be implemented at all by means of (partially undocumented) backdoors to the language; unfortunately, these backdoors bypass the compiler's type checking.
> Lazarus/Free pascal is really good, except for the abysmal documentation
Unfortunately, the language is a huge, partly unspecified patchwork, where apparently all sorts of current fashionable constructs have been built in, partly even redundantly. The resulting complexity is hardly manageable with the present development approach.
Here are the mentioned sixteen pages if anyone is interested:
https://miasap.se/obnc/oberon-report.html
Oberon also has an interesting set of features to enable object-oriented programming without the syntactic sugar. Here is an article which describes basic abstractions in Oberon:
https://miasap.se/obnc/data-abstraction.html
https://miasap.se/obnc/oberon-report.html
Oberon also has an interesting set of features to enable object-oriented programming without the syntactic sugar. Here is an article which describes basic abstractions in Oberon:
https://miasap.se/obnc/data-abstraction.html
I referred to this one: https://people.inf.ethz.ch/wirth/Oberon/Oberon.Report.pdf.
I never thought of Pascal as a systems programming language. I always considered the inline assembler as the hack to get around that limitation. (Just as it is in C)
I am curious, what's the problem with redundancy? Having more than one way to do something doesn't seem particularly ominous to me. I'm sure you've got solid reasons.
I am curious, what's the problem with redundancy? Having more than one way to do something doesn't seem particularly ominous to me. I'm sure you've got solid reasons.
> I never thought of Pascal as a systems programming language
I referred to Oberon when stating that it isn't a system programming language, not Pascal; the latter is well suited for low-level system programming because you can take addresses and directly manipulate pointers, and there are facilities for multi-threading etc.
> what's the problem with redundancy?
FreePascal is at least three different languages in one; if you add compiler options the number of actual language versions even multiplies. There are e.g. different object systems which are even available at the same time in certain modes. This multiplies not only the learning effort, but also the development and documentation effort. It is apparent that FreePascal tries to follow C++ when looking at the feature set; C++ is a very complex language and so became FreePascal; the fact that not every feature could be freely designed but had to respect the existing feature set with all its interactions made FreePascal even more complex than C++ in some respects. And FreePascal has to carry on burdens from the past which were improved in Modula or Oberon, but which have to remain in the language for backward compatibility reasons.
I referred to Oberon when stating that it isn't a system programming language, not Pascal; the latter is well suited for low-level system programming because you can take addresses and directly manipulate pointers, and there are facilities for multi-threading etc.
> what's the problem with redundancy?
FreePascal is at least three different languages in one; if you add compiler options the number of actual language versions even multiplies. There are e.g. different object systems which are even available at the same time in certain modes. This multiplies not only the learning effort, but also the development and documentation effort. It is apparent that FreePascal tries to follow C++ when looking at the feature set; C++ is a very complex language and so became FreePascal; the fact that not every feature could be freely designed but had to respect the existing feature set with all its interactions made FreePascal even more complex than C++ in some respects. And FreePascal has to carry on burdens from the past which were improved in Modula or Oberon, but which have to remain in the language for backward compatibility reasons.
Object Pascal was invented by Apple in collaboration with Wirth for Mac OS, as evolution from clascal used in Lisa.
Until the C and C++ took over inside Apple R&D, Mac OS was mostly programmed in Assembly and Object Pascal, and then it was time for C++ to take over.
Even the stuff that looks like C, is actually extern "C" under the hood.
Also no one really used the initial Pascal implementation, just like with C, most compilers had plenty of extensions, like Apple's Object Pascal.
Some of those extensions were later standardizes as Extended Pascal, however by then Modula-2 and Object Pascal (Apple and Borland's followup) were more relevant, Ada was coming into the picture, and thus everyone ignored ISO Extended Pascal.
Until the C and C++ took over inside Apple R&D, Mac OS was mostly programmed in Assembly and Object Pascal, and then it was time for C++ to take over.
Even the stuff that looks like C, is actually extern "C" under the hood.
Also no one really used the initial Pascal implementation, just like with C, most compilers had plenty of extensions, like Apple's Object Pascal.
Some of those extensions were later standardizes as Extended Pascal, however by then Modula-2 and Object Pascal (Apple and Borland's followup) were more relevant, Ada was coming into the picture, and thus everyone ignored ISO Extended Pascal.
> Anders Hejlsberg was the author of the best Pascal implementation, greatly enhancing Pascal until he was seduced by Microsoft and helped start the evil that is .NET and C#.
Some historical correction needed.
Many of the improvements in Turbo Pascal 4.0 onwards came from UCSD Pascal and Apple's Object Pascal, initially, and then followed up on interoperability with C++ for Borland products.
He wasn't seduced by Microsoft, rather by former Borland employees working at Microsoft wanting to refer him (those referral bonus), which he continuous refused until himself got pissed off with Borland's management.
"Anders Hejlsberg: A craftsman of computer language" interview
https://behindthetech.libsynpro.com/001-anders-hejlsberg-a-c...
Some historical correction needed.
Many of the improvements in Turbo Pascal 4.0 onwards came from UCSD Pascal and Apple's Object Pascal, initially, and then followed up on interoperability with C++ for Borland products.
He wasn't seduced by Microsoft, rather by former Borland employees working at Microsoft wanting to refer him (those referral bonus), which he continuous refused until himself got pissed off with Borland's management.
"Anders Hejlsberg: A craftsman of computer language" interview
https://behindthetech.libsynpro.com/001-anders-hejlsberg-a-c...
I miss the ease with which you put some graphics on the screen via the Borland Graphics Interface library for Turbo Pascal. :)
I think that is what Free Pascal's backwards compatible graph unit is implementing? Sad to see it is deprecated, but maybe it still works? I could not use it for porting my ancient Turbo Pascal 2.0 game since it was relying on an older, CGA-only, graphics library that had a different API.
https://www.freepascal.org/docs-html/rtl/graph/index.html
https://www.freepascal.org/docs-html/rtl/graph/index.html
As an old Delphi user when it was strong back in the day I still like Pascal, although my dream is to see one day Lazarus swallow other more modern languages too, say Zig, Crystal or Nim.
What Free Pascal seems to do amazingly well is platform-support and backwards compatibility. I think it may be worth considering for some of my future hobby projects for that reason alone, assuming that there will remain some critical mass of developers around to keep the compiler working and that they do not start rolling out new incompatible versions all the time like what has become the norm for popular programming languages.
Official list of supported platforms from freepascal.org: "Intel x86 (16 and 32 bit), AMD64/x86-64, PowerPC, PowerPC64, SPARC, SPARC64, ARM, AArch64, MIPS, Motorola 68k, AVR, and the JVM. Supported operating systems include Windows (16/32/64 bit, CE, and native NT), Linux, Mac OS X/iOS/iPhoneSimulator/Darwin, FreeBSD and other BSD flavors, DOS (16 bit, or 32 bit DPMI), OS/2, AIX, Android, Haiku, Nintendo GBA/DS/Wii, AmigaOS, MorphOS, AROS, Atari TOS, and various embedded platforms. Additionally, support for RISC-V (32/64), Xtensa, and Z80 architectures, and for the LLVM compiler infrastructure is available in the development version. Additionally, the Free Pascal team maintains a transpiler for pascal to Javascript called pas2js."
Official list of supported platforms from freepascal.org: "Intel x86 (16 and 32 bit), AMD64/x86-64, PowerPC, PowerPC64, SPARC, SPARC64, ARM, AArch64, MIPS, Motorola 68k, AVR, and the JVM. Supported operating systems include Windows (16/32/64 bit, CE, and native NT), Linux, Mac OS X/iOS/iPhoneSimulator/Darwin, FreeBSD and other BSD flavors, DOS (16 bit, or 32 bit DPMI), OS/2, AIX, Android, Haiku, Nintendo GBA/DS/Wii, AmigaOS, MorphOS, AROS, Atari TOS, and various embedded platforms. Additionally, support for RISC-V (32/64), Xtensa, and Z80 architectures, and for the LLVM compiler infrastructure is available in the development version. Additionally, the Free Pascal team maintains a transpiler for pascal to Javascript called pas2js."
Having to write C/AL to make a living, which is based on Pascal, I can safely say it shouldnt be in the race anymore...
Interesting take. Pascal is definitely a niche language but most of the community around FPC and Lazarus seems very positive and welcoming.
Would you mind expanding on why you feel this way? What Pascal do you use? Do you use Delphi or FPC/Lazarus? What don’t you like about the language (or your particular vendor implementation)?
Would you mind expanding on why you feel this way? What Pascal do you use? Do you use Delphi or FPC/Lazarus? What don’t you like about the language (or your particular vendor implementation)?
I have to say I wrote this as more of a joke as I do have no actual experience with Pascal. Looking at the syntax I just assumed it to be extremely similar to the language I have to work with on a daily basis. And with that, just as limited.
C/AL is a product of Microsoft and is only used in their ERP Software Navision. It's a horrible experience to work with as you don't have a lot of modern languages features just for the sake of readability.
At some point in the article the author wrote that Rust code isn't readable for example. I'd argue code shouldn't have to be readable by non-programmers. And especially not if the language sacrifices features like creating objects or dynamic arrays...
But as I wrote, I don't have actual experience with Pascal so maybe it's actually better.
C/AL is a product of Microsoft and is only used in their ERP Software Navision. It's a horrible experience to work with as you don't have a lot of modern languages features just for the sake of readability.
At some point in the article the author wrote that Rust code isn't readable for example. I'd argue code shouldn't have to be readable by non-programmers. And especially not if the language sacrifices features like creating objects or dynamic arrays...
But as I wrote, I don't have actual experience with Pascal so maybe it's actually better.
Free Pascal is a lot more robust and featureful than whatever God-awful ERP language you have to work in. It's a spiritual descendant of Turbo Pascal and Delphi, which were used to develop diverse applications from line-of-business to games for decades. Dynamic memory allocation and objects are built-in. It is definitely NOT the Pascal of Kernighan's "Why Pascal Is Not My Favorite Programming Language".
What are the top 2 pain points you encountered?
As anecdote, my new older co-worker started his new embedded camera project also with Lazarus. A fast safe language, much easier and safer than C. Even SIMD tricks and OpenCV are possible for higher frame rates.
Lazarus is the IDE for FPC, the FreePascal Compiler, as I understand it. Lazarus itself isn't a language.
Every time I've tried to use Pascal (with Lazarus/FPC) I find myself incredibly confused as to the proper way to download and version packages. Separate project? Using Lazarus package manager? Git submodule?
PS4 emulator/compat layer in FP: https://github.com/red-prig/fpPS4
As someone who has never seen Pascal, I have to say, the code example is not very readable. But that is not because of the syntax, which is nice, but because of the terrible variable names.
If you have to loudly proclaim you're still important...
Pascal is an abandoned prototype for Modula-2 and Oberon.
Modula-2 and Oberon are abandoned dialects of Pascal. I just wish Concurrent Pascal would have survived. As the only properly safe system language.
My point is more that Pascal was abandoned by its author, which happened while it was still widely used. (Or that was the external perception. In the Oberon project, sure, they may have had a Pascal front end for all their own old code to work.)
Wirth made a mistake by fragmenting his language development over similar, but incompatible languages under different names.
When we look at C, the story is different. ANSI C was carefully designed to be backward compatible with K&R C. C99 didn't break too much in C90: test cases to demonstrate incompatibility have to be contrived. The name of the language didn't change.
Simply not changing the name is a powerful social tactic. People overlook differences when the name has not changed. (Look at how Lisp outsiders think that Lisp is all the same.)
Modern Fortran is very different from Fortran 66 or 77. Because the name is the same, the "Frankenfortran" is accepted in the same circles (e.g. scientific computing). Had the name changed, that would be unlikely.
I can't escape the suspicion that Wirth should have continued to use the Pascal name for that entire succession of languages.
Wirth made a mistake by fragmenting his language development over similar, but incompatible languages under different names.
When we look at C, the story is different. ANSI C was carefully designed to be backward compatible with K&R C. C99 didn't break too much in C90: test cases to demonstrate incompatibility have to be contrived. The name of the language didn't change.
Simply not changing the name is a powerful social tactic. People overlook differences when the name has not changed. (Look at how Lisp outsiders think that Lisp is all the same.)
Modern Fortran is very different from Fortran 66 or 77. Because the name is the same, the "Frankenfortran" is accepted in the same circles (e.g. scientific computing). Had the name changed, that would be unlikely.
I can't escape the suspicion that Wirth should have continued to use the Pascal name for that entire succession of languages.
GCC just integrated Modula-2 into their compilers in the box offering.
A bit of Oberon survives in Go, which is probably the only reason I somehow like the language, despite their design decisions, which I must admit are still less draconian than Oberon-07.
A bit of Oberon survives in Go, which is probably the only reason I somehow like the language, despite their design decisions, which I must admit are still less draconian than Oberon-07.
C# using config files? If you want (and use the default template). Otherwise (and minimal apis) the code looks closer to the go model.
Argh, I am to trigger happy.
Argh, I am to trigger happy.
It's really not, unless we define "in the race" as "still technically exists." It will be displacing absolutely nothing.
I hope this isn't hosted on Pascal. Got a 502.
Probably got a 502 for it not being hosted on Pascal.
But iirc, HN is Lisp?
But iirc, HN is Lisp?
Not quite, Arc, a LISP inspired language that is essentially a one-off.
http://www.paulgraham.com/hundred.html
http://www.paulgraham.com/hundred.html
But these days folks are mostly used to the C style syntax. And I'm not even arguing that it is a better language than C or others. But the whole industry has gone overall into believing that anything newly 'invented' is good and anything that's been around a while is passé. Ironically, at the same time as the core technologies we use are based on decades old tech like Unix, relational databases, TCP/IP, etc. And many others like Lisp and Smalltalk fell by the wayside at least partly due to performance issues that were made irrelevant by Moore's law long ago.
Oh humans... :)
Btw, Logo is another one that's under appreciated. Seymour Papert was brilliant in making programming more visual and intuitive for kids. And I didn't actually know until recently it's actually a Lisp based language with a lot of power. Who knew?
In some parallel universe, I'd love to see folks like those, along with many others from that era, as the ones we heap recognition on instead of our worship of current tech billionaires. Those guys generally understood the hardware, software, and core theory. Given the mess that is computing and the internet, it's a shame that we'll be losing them over the next few decades.