I def have a soft spot for Pascal. And I think Niklaus Wirth deserves more recognition in broader circles for his foundational work with pcode, compilers, Oberon, etc. I learned Pascal like many of us growing up in the early PC era and never could look at BASIC the same way again (or respect Gates for his love of it, lol). I think having such a highly structured language at a young age did wonders.
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.
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.
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.
> 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.
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.
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.
"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.)
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?
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.
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.
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.
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.
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)
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 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.
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.
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.
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.
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.
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.
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.
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."
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)?
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.
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?
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.
runlaszlorun|2 years ago
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.
PumpkinSpice|2 years ago
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.
switchbak|2 years ago
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.
sixthDot|2 years ago
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.
wolfi1|2 years ago
djha-skin|2 years ago
Mostly, but I'm told the new Austral[1] language has syntax very similar to that of Pascal's.
1: https://austral-lang.org/
zozbot234|2 years ago
darigo|2 years ago
Clubber|2 years ago
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.
jchw|2 years ago
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.
jerf|2 years ago
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.)
broken-kebab|2 years ago
astrodust|2 years ago
Forgotten to the point that people thought Visual Basic was a good idea.
rob74|2 years ago
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.
Svip|2 years ago
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
kagakuninja|2 years ago
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.
ggm|2 years ago
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)
Simplicitas|2 years ago
jacquesm|2 years ago
https://en.wikipedia.org/wiki/Modula-2
livrem|2 years ago
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.
dbsmith83|2 years ago
swatcoder|2 years ago
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.
zem|2 years ago
jacquesm|2 years ago
sinuhe69|2 years ago
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.
lproven|2 years ago
"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/
supportengineer|2 years ago
There’s a lot of assumptions and bias in here.
bluGill|2 years ago
soliton4|2 years ago
wiz21c|2 years ago
Great time indeed !
anta40|2 years ago
And what about.. umm... Modula 2/3 or Oberon? They don't gain as much industry attractions as Pascal does, eh?
mikewarot|2 years ago
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.
ibobev|2 years ago
livrem|2 years ago
https://www.freepascal.org/docs-html/rtl/graph/index.html
squarefoot|2 years ago
livrem|2 years ago
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."
zwnow|2 years ago
elteto|2 years ago
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)?
tabtab|2 years ago
rurban|2 years ago
lproven|2 years ago
ursuscamp|2 years ago
falker|2 years ago
zubairq|2 years ago
timbit42|2 years ago
How about Ada or Oberon, both much better than Pascal or Modula-2?
nilslindemann|2 years ago
davidw|2 years ago
kazinator|2 years ago
rurban|2 years ago
oaiey|2 years ago
Argh, I am to trigger happy.
Tommstein|2 years ago
cdelsolar|2 years ago
lproven|2 years ago
b800h|2 years ago
doublerabbit|2 years ago
But iirc, HN is Lisp?