
Why Pascal Is Not My Favorite Programming Language (1981) - dsego
https://www.lysator.liu.se/c/bwk-on-pascal.html
======
clouddrover
This article pops up every now and again. Most of the criticisms are no longer
valid. Pascal has moved on in the last 38 years.

If you don't know modern Pascal then check out Free Pascal, Lazarus, and
Delphi:

[https://www.freepascal.org/](https://www.freepascal.org/)

[https://www.lazarus-ide.org/](https://www.lazarus-ide.org/)

[https://www.embarcadero.com/products/delphi](https://www.embarcadero.com/products/delphi)

(And Delphi documentation at
[http://docwiki.embarcadero.com/](http://docwiki.embarcadero.com/) )

~~~
acqq
Specifically, just two years after the title text was written, in 1983, there
was already Turbo Pascal which was much more useful than the language as
defined for the introductory university classes:

[http://edn.embarcadero.com/article/20693](http://edn.embarcadero.com/article/20693)

It was the fastest compiler and environment of the time, but additionally,
even before 1983, the "minimal" form of the language, suitable for teaching,
was almost never used in production. What was used in production did have the
necessary extensions which allowed having some very good software, with
provably less bugs than C, because the basis was good and safer.

See also MacPaint, developed also around 1983 ("finished in October 1983"), in
Apple Pascal:

[https://www.computerhistory.org/atchm/macpaint-and-
quickdraw...](https://www.computerhistory.org/atchm/macpaint-and-quickdraw-
source-code/)

Even Go language took its influences from Pascal, "rediscovering" some aspects
that were obviously better (for the humans writing programs) than C.

~~~
rob74
Actually the influence of the Pascal family and that of the C family are about
equally significant, if you go by the chart from the "Go Programming Language"
book (available in the free preview, page xiii
[https://www.amazon.com/Programming-Language-Addison-
Wesley-P...](https://www.amazon.com/Programming-Language-Addison-Wesley-
Professional-Computing/dp/0134190440/)). Most significant is probably the
module system, which, in good Turbo Pascal tradition, allows Go to run loops
around other C-family languages (looking at you Rust ;) ), and of course the
declaration syntax ("i int" instead of "int i").

Since I first came across Go I've been thinking that a Go-based Delphi clone
would be really amazing. Maybe someone could breathe some new life into the
Lazarus IDE by adding support for Go? Hmmm, actually there already is
something: [https://github.com/ying32/govcl](https://github.com/ying32/govcl)
\- probably worth keeping an eye on...

------
ckok
Amazing, our Oxygene compiler, Delphi and FPC has solved all of these issues
ages ago, perhaps it's time to let this article go after all this time.

\- 2.0 Types and scopes: Apple = type Integer; makes it a distinct type

\- 2.1 Array size: dynamic arrays

\- 2.2 Admittedly, not exactly solved, but classes are how we hide variable
these days.

\- 2.3 Oxygene doesn't care about order of things

\- 2.4: Long solved

\- 2.5: While allowed; something can be said for using an alias here to make
the intent obvious; the in set is also solved in Oxygene since c in ['a'..z']
compiles to c >='a' and c <='z'.

\- 3: boolean shortcircuitry has long been part of Pascal

\- 4: With streams apis this is no longer a thing

\- 5: xor/or has lng been part of the languages, the semicolon issue seems a
style issue to me, not a big deal

(edit: had to insert enters to make it readable)

~~~
jstimpfle
I've used Delphi in the last year and, while I hated it overall, there were a
few things I liked about it. It's really nice that it compiles so quickly. And
it feels very principled, at least the Pascal baseline.

The main problem I remember is that you cannot simply use pointer types, or
other complex types, as function parameters. You always have to declare a
typedef first, such that the type that is used in the function signature is a
single word (named reference to the typedef).

Working on a compiler myself, I understand from an implementation perspective
why Wirth did this, but this is really lazy. From a developer's perspective,
to me that's next to unusable. It's really stressful to predeclare pointer
types before using them, and using names like TypeP, TypePP and so on is much
less readable than simple ^Type, ^^Type, etc.

Another thing that's driving me crazy is case insensitivity. I would never
willfully choose a language with case insensitive identifiers. It's driving me
nuts.

> 2.2 Admittedly, not exactly solved, but classes are how we hide variable
> these days.

global initialized variables are really important to me to avoid unnecessary
boilerplate and indirection (which is just as painful as not having
initialized globals). What I did was initialize them in the initilization
section. But it was another major inconvenience.

~~~
kbp
> Another thing that's driving me crazy is case insensitivity. I would never
> willfully choose a language with case insensitive identifiers. It's driving
> me nuts.

What about it annoys you? Do you often define a lot of variables whose names
differ only by case, in languages that let you? Common Lisp normally behaves
as though it were case insensitive, and I've never found that to be a pain
point.

~~~
jstimpfle
In fact I often use the "Thing thing" approach to variable declaration and I
think I like it. It's an easy way for me to avoid thinking about taxonomy. But
it's not that important. If it wasn't possible I could invent different names.

What really irks me is that in case-insensitive languages, codebases naturally
start to use all kinds of variations of casing, to refer to the same variable.
It really trips me up when reading code. It's also difficult when writing code
since I tend to remember variable names in a very visual way. (Same reason why
I dislike the case-insensitive Windows filesystems).

There simply isn't any good reason not to always use the same case for any
variable throughout a project.

Beyond that it's also aesthetically not pleasing, from an engineering
viewpoint. Case-insensitive comparison is much more complicated than simply
comparing strings as arrays of bytes.

Historically, I think the reason why case-insensitive languages exist is
simply that at the time they were invented (at least in the case of Pascal),
many systems couldn't input lowercase characters.

~~~
kbp
> In fact I often use the "Thing thing" approach to variable declaration and I
> think I like it. It's an easy way for me to avoid thinking about taxonomy.
> But it's not that important. If it wasn't possible I could invent different
> names.

There's no reason that types and variables need to live in the same namespace.
The language can know what it's expecting at a certain point. Putting them in
different namespaces, like Lisp does, lets you re-use the same name for types
and variables even with matching case, and is more waterproof with regards to
clashes than a case convention.

> There simply isn't any good reason not to always use the same case for any
> variable throughout a project.

I agree, but I also feel that there isn't any good reason to have multiple
distinct objects in the same namespace whose names differ only by case. It
just seems like a recipe for confusion.

When I'm quickly iterating on something, it's nice being able to be lazy and
inconsistent with capitalisation. Standardising that in a codebase is
important, but it's more of a job for a linter, I think.

~~~
jstimpfle
Yes, C has that too. It has different namespaces for struct, union, and enum.
And I like the clarity of the explicit namespace prefixes at each place of
reference. But I tend to not rely on that distinction, since C++ has only a
single namespace.

And as soon as we go to more dynamic languages, where types can also be
variables, it all breaks down.

~~~
kbp
I was just saying that there's no good reason to have different variables with
names that only differ by case; the example you gave where you do like that
has a better solution in multiple namespaces.

------
romwell
Good thing that we aren't using languages the way they were in 1981 anymore.

As for Pascal, TurboPascal has been revolutionary, and it came out in 1983,
two years after this article came out. TP, the lightning-speed IDE, debugger
and compiler in one small executable pushed Pascal to its peak popularity;
Delphi was another revolution.

These days, Lazarus would be the go-to modern Pascal successor. (Delphi is
still here, but is very much non-free; Lazarus is FOSS).

~~~
tokyodude
Someone told me TurboPascal was actually Modula-2 just named "Pascal" for
marketing. Where they wrong?

~~~
mannschott
Yes.

Most obviously Modula-2 is is case-sensitive, while (Turbo)Pascal is not. Also
Modula-2 addresses the danging-else problem in Pascal, while TurboPascal does
not.

It wouldn't surprise me if TurboPascal addressed some of the same deficiencies
in Pascal that Wirth also addressed in Modula-2, but they probably do so
differently.

------
analognoise
My usual shoutout to Lazarus/FreePascal go here: They're really wonderful,
modern, well-maintained and ready for professional work.

If you've experienced 100MB Electron garbage and are tired of it, or you think
C++ is a tangled mess and want no part in it, and you need something LGPL that
has a wonderful community, check it out.

------
dvfjsdhgfv
It's an interesting read and at the same time a relief to realize that many if
not most of the problems have been addressed years ago. E.g. sorting an array
in FreePascal is a very simple task (not to mention that dynamic arrays and
generics are also supported).

~~~
nine_k
It's funny that generics are supported in Pascal, but not in its spiritual
successor, Go.

(Of course, Go's succession goes not directly from Pascal, but through
Modula-2 and Oberon.)

~~~
magicalhippo
Delphi has compile-time generics, which is kind of a "worst of both worlds"
approach. It has all the constraints of templates, but none of the benefits of
run-time instantiated generics like .Net has.

For example you can't make a generic function that uses the + operator to add
two parameterized elements together, because there's no way to constrain the
types to only those which has the + operator defined. But unlike templates in
C++, the compiler doesn't just try and see if it works but rather emits an
error.

------
stesch
I was indoctrinated by this text. A fan of C and C style languages.

And I feel this was so wrong and that the world could be a better place if we
would have turned into another direction.

~~~
dvfjsdhgfv
It happened to me, too. This and several other cases demonstrate the value of
independent thinking, investigating the matter yourself rather than following
the crowd. This is happening also these days: two years ago it was Big data,
last year it was microservices and "serverless" and so on.

~~~
WalterGR
_and so on._

Back until the dawn of computing. And the dawn of technology before that. And
the dawn of humankind before that. And so on.

------
jonathanstrange
I used to be a language snob until I realized that the choice of language is
pretty much irrelevant. What counts is the tooling, the available libraries
and framework, and sometimes also how fast the compiler and the executables
are.

------
sysrpl
If anyone cares for an overview of Lazarus and Free Pascal, here are a few
resources:

[https://www.getlazarus.org/new/](https://www.getlazarus.org/new/)

[https://www.getlazarus.org/learn/language/lexical/](https://www.getlazarus.org/learn/language/lexical/)

... and the searchable online reference:

[http://docs.getlazarus.org/#rtl+system+tobject#](http://docs.getlazarus.org/#rtl+system+tobject#)

------
augustk
For those interested, Oberon is the current Pascal. It is also designed by
Niklaus Wirth. I use the OBNC compiler
([https://www.miasap.se/obnc](https://www.miasap.se/obnc)).

~~~
nurettin
Perhaps in a way, OBNC is the successor to Pascal considering Pascal's history
with Niklaus Wirth, but then, Delphi appears to be a better candidate for
being the "current pascal" considering Anders Hejlsberg's commercial success
in creating widely-adopted languages.

~~~
augustk
OBNC is just a compiler. Whereas other languages evolve by adding more and
more features, Oberon seem to converge to a set of features which are tried,
tested, orthogonal and (most important) essential. Wirth has been very careful
not to introduce any misfeatures.

------
stevefan1999
I really miss Pascal and Delphi. They're beautiful.

~~~
chadcmulligan
You don't have to - they're still around

