Live data from Hacker News

Heteroglot: Project Euler problem #16 in Pascal, #17 in Inform 7

eev.ee

11–16 of 16 posts

Re: Heteroglot: Project Euler problem #16 in Pascal, #17 in Inform 7

#11

Earlier quoted context omitted.

Bear in mind that this was written in 1981, at the beginning of a decade that saw enormous progress for Pascal, rendering most of "some guy"'s objections invalid. ANSI C only happened towards the end of that decade. I think when an essay from 20 (or 35) years ago claiming "X sucks" is referenced, it's kinda foolish not to draw attention to the history that followed.

Well, I was using Pascal professionally from 1986 to 1988, and many of those objections were still valid. (Granted, on an embedded system rather than a PC, so the improvements in Pascal were slower in coming to us.)

I was using pascal in the early 90s, and the compilers to which I had access most certainly still had "Strongly typed, but arrays of different lengths are different types", which was incredibly annoying. (And for fun, consider the arguments against pascal's length-typed arrays and against go's lack of generics)

Re: Heteroglot: Project Euler problem #16 in Pascal, #17 in Inform 7

#12

> 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 teachi…

I don't know which Pascal you're referring to, but with the modern Object Pascal (that's been around since the mid-90's), I've written two SQL database engines and a web development IDE/compiler.

AFAIK, this was also written in Object Pascal:

https://www.image-line.com/flstudio/

These products are hardly "toys".

Re: Heteroglot: Project Euler problem #16 in Pascal, #17 in Inform 7

#13
post #3

"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 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.

Those arguments are very old. Modern Object Pascal, (around since the mid 90's) has dynamic arrays that are used now instead of the old static arrays with hard-coded bounds. The only time that you use static arrays now is if you truly need a bounded array, such as when calling into an API call that has MAX_PATH or something similar as the bounds and you need a character buffer for a return argument. This also applies to strings, which are now also dynamic and reference-counted, and not some fixed buffer that is 255 bytes in length. You can still use most of the old stuff because the language is very backwards-compatible, but most people don't.

Re: Heteroglot: Project Euler problem #16 in Pascal, #17 in Inform 7

#14
post #3

"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 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.

Those arguments are very old. Modern Object Pascal, (around since the mid 90's) has dynamic arrays that are used now instead of the old static arrays with hard-coded bounds. The only time that you use static arrays now is if you truly need a bounded array, such as when calling into an API call that has MAX_PATH or something similar as the bounds and you need a character buffer for a return argument. This also applies…

Pascal had already failed to take off by the mid 90s, as I recall, so the damage had been done.

Re: Heteroglot: Project Euler problem #16 in Pascal, #17 in Inform 7

#15
post #14

Earlier quoted context omitted.

Those arguments are very old. Modern Object Pascal, (around since the mid 90's) has dynamic arrays that are used now instead of the old static arrays with hard-coded bounds. The only time that you use static arrays now is if you truly need a bounded array, such as when calling into an API call that has MAX_PATH or something similar as the bounds and you need a character buffer for a return argument. This also applies…

Pascal had already failed to take off by the mid 90s, as I recall, so the damage had been done.

No, Turbo Pascal was very successful, and its successor, Delphi, was wildly successful on Windows (Delphi was first released in 1996). It only started to falter in 2003-04 when Borland decided it wanted to be an enterprise Java company (???) and Anders Hejlsberg, the chief Delphi architect, left to go to Microsoft, where he was the chief architect for C# for .Net, and now works on TypeScript.

Re: Heteroglot: Project Euler problem #16 in Pascal, #17 in Inform 7

#16
post #4

Earlier quoted context omitted.

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-…

> 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…

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.

Post reply on HN