
Heteroglot: Project Euler problem #16 in Pascal, #17 in Inform 7 - hoverbear
http://eev.ee/blog/2016/01/12/heteroglot-number-16-in-pascal-number-17-in-inform7/
======
to3m
"How on earth did C win out over this?" \- here's some guy's take on, if not
exactly this question, matters that may be related:
[https://www.lysator.liu.se/c/bwk-on-
pascal.html](https://www.lysator.liu.se/c/bwk-on-pascal.html)

My own memory is similar - Pascal was just generally annoying to use, in
various little ways, that added up over time. On the face of it, it seems like
it should be a lot better than C, but in practice... it just wasn't.

~~~
vessenes
That's such an interesting essay -- some of the complaints seem so egregious,
it's no wonder Pascal didn't take off. All of the complaints seem (to my eyes)
very reasonable. The high points:

No closures, so global vars everywhere

No breaks in flow control, it's goto (deprecated) or nothing

Strongly typed, but arrays of different lengths are different types.

Casting types is not possible

A number of annoying order-of-code requirements

"and" and "or" have no guaranteed precedence or order of operation..(!)

Those are enough to make me want to hurl the compiler against a wall.

~~~
munificent

        > No breaks in flow control, it's goto (deprecated) or nothing
        > Strongly typed, but arrays of different lengths are different types.
        > Casting types is not possible
    

Those are real frustrations, but, at the same time, they help avoid many of
the security and safety issues that have plagued C for decades.

It's not clear if there's a language somewhere between Pascal that's less
annoying but more safe while still being simple. But I think it is pretty
clear that there is a real trade-off in either direction.

C doesn't get in your way when you know you're doing like Pascal does. But it
also doesn't get in the way when you _don 't_ know what you're doing.

~~~
vessenes
I think Go has a reasonably good story about each of those three items
actually; you can create an array of specific length as a type (and name it if
you like), or you can create a slice, which does not have length requirements.

Flow control is significantly better, and supports goto style semantics when
you need them.

Casting is liberally warned against (unsafe.*), but available when needed.

------
asQuirreL
> Cool. I’m glad to see Pascal has adopted Rust’s approach of putting the type
> last, so you can actually see at a glance what the variable names are.

I'm guessing (hoping) this is irony...

------
AnimalMuppet
> I have a hard time even thinking of it as a systems language, since systems
> languages tend to be full of punctuation, whereas Pascal makes pretty heavy
> use of keywords.

Judging whether it's a systems language by keywords vs punctuations?
Seriously?

> does this seriously predate C and share the same problem space?

Some people thought it could share the same problem space, but it was
primarily intended to be a teaching language. It turned out that it wasn't as
suited for real work as some people thought.

> Granted, I don’t know enough about Pascal from one toy program to fairly
> compare it to C. Kind of curious what the story is, though.

The story is, when you quit having toy problems, Pascal's limitations got in
your way much more than C's limitations did.

~~~
nickpsecurity
So Jurg and Wirth designed Modula-2 as a replacement, then built a computer,
then wrote an OS, wrote some apps, and lived happily ever after. Until their
urge to build new languages was overpowering. Rinse, repeat.

Yet, Modula-2 had a nice combo of readability, safety, compiler efficiency,
and runtime-efficiency. Proven in OS development. Such safe, systems languages
helped once I got past toy problems C could handle without crashing my stuff.
;)

