Comment by pjmlp
1 day ago
As usual, lets revisit something that Pascal could do in 1976,
type
StatusCodes = (Success, Ongoing, Done)
Go in 2025,
type StatusCodes int
const (
Success StatusCodes = iota
Ongoing
Done
)
Where do you put the comments on the Pascal version?
Where you feel like it.
Where's Pascal today?
Ouch!! Pascal's lack of popularity certainly isn't due to the fact that it supports such nice enumerated types (or sets for that matter). I think he was just pointing out that such nice things have existed (and been known to exist) for a long time and that it's odd that a new language couldn't have borrowed the feature.
Just below Go with Perl in between. All above Fortran, all below Visual Basic.
https://www.tiobe.com/tiobe-index/
Being used by these folks, https://www.embarcadero.com/
If you prefer, I can provide the same example in C, C++, D, Java, C#, Scala, Kotlin, Swift, Rust, Nim, Zig, Odin.
Please do. Would be interesting to read.
It's alive and kicking, right? :) https://www.freepascal.org They even have a game engine that can compile to a WASM target: https://castle-engine.io/web
Pascal evolved into Modula-2, which Wirth then simplified into Oberon. His student Griesemer did his dissertation on extending Oberon for parallel programming on supercomputers. Concurrently, Pike found Modula-2 an inspiration for some languages he wrote in the 80s and 90s. He got together with Griesemer and Ken Thompson to rework one of those languages, Newsqueak, into Golang. So that's where Pascal is today.
If Pascal doesn't have required exhaustive pattern matching, it's no better than Go or C# in this regard.
Go is the one being discussed as ignoring history.
C# thankfully was designed by someone that appreciates type systems, maybe you should revisit it.
Not enough to add sum types or exhaustive pattern matching... now F# - that was appreciated by someone that appreciates type systems.
Does Pascal's break down like this Go does?
How often do you pass literals into your functions?
1 reply →
[flagged]
People want sum types because sum types solve a large set of design problems, while being a concept old enough to appear back in SML in 1980s. One of the best phrased complaints I've seen against Go's design is a claim that Go language team ignored 30+ years of programming language design, because the language really seems to introduce design issues and footguns that were solved decades before work on it even started
Rust did not exist in 1976.
ML did, however (1973), and had..... sum types!
1 reply →
Sum types are not the same as the trivial example above. Sum types are actually useful, for one thing.
No one is asking for sum types, what Pascal does would already be a huuuuge improvement.
But I guess Go devs love to type their beloved boilerplate, it gives fuzzy feelings.
1 reply →