Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern Pascal is still in the race (2022)

blog.synopse.info

Post reply on HN
Print view View original

61–70 of 160 posts

Re: Modern Pascal is still in the race (2022)

#61

Post by dwheeler »

zozbot234 wrote: post #38
PumpkinSpice wrote: post #25

Earlier quoted context omitted.

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

Historically, the point of writing 'begin' and 'end' instead of using curly braces was mostly support for non-ASCII character sets where the curly braces are not included. It's why C also has an alternate syntax using and COBOL goes as far as writing out arithmetical operators as English text, such as DIVIDE x INTO y GIVING z.

Ada, at least, uses begin...end in part because it prevents certain kinds of errors. In its syntax you have to specify what you are ending, reducing the risk of invalid matches and increasing the likelihood of the error report system guessing correctly what you intended. E.g.:

    if X > 0 then
      Y := 0;
    end if;
Curly braces are shorter, but a close curly brace will match any open curly brace. Such is the nature of trade-offs.

Re: Modern Pascal is still in the race (2022)

#63

Post by Sakos »

dwheeler wrote: post #61
zozbot234 wrote: post #38

Earlier quoted context omitted.

Historically, the point of writing 'begin' and 'end' instead of using curly braces was mostly support for non-ASCII character sets where the curly braces are not included. It's why C also has an alternate syntax using and COBOL goes as far as writing out arithmetical operators as English text, such as DIVIDE x INTO y GIVING z.

Ada, at least, uses begin...end in part because it prevents certain kinds of errors. In its syntax you have to specify what you are ending, reducing the risk of invalid matches and increasing the likelihood of the error report system guessing correctly what you intended . E.g.: if X > 0 then Y := 0; end if; Curly braces are shorter, but a close curly brace will match any open curly brace. Such is the nature of trade-…

Ngl, I think that's brilliant. Braces matching the wrong brace is like a daily occurrence. It's such a tedious small thing that constantly hounds me whenever I'm writing code

Re: Modern Pascal is still in the race (2022)

#64

Post by sinuhe69 »

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.

Re: Modern Pascal is still in the race (2022)

#66

Post by nine_k »

PumpkinSpice wrote: post #25
runlaszlorun wrote: post #20

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

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

One huge difference between C and Pascal grammars us that Pascal is LR(1), so it can be parsed easily, which helps one-pass translation. It also helps humans read it.

C, on the other hand, has needlessly complicated syntax; a function definition is hard to detect, and a pointer to a function is hard to interpret, because it's literally convoluted: https://c-faq.com/decl/spiral.anderson.html

Sadly, this is a general stylistic difference: where Pascal tries to go for clarity, C makes do with cleverness, which is more error-prone.

Re: Modern Pascal is still in the race (2022)

#67

Post by mike_hock »

jerf wrote: post #21
jchw wrote: post #8

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

"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, a…

> The story of software engineering in the 1990s was a story of overreactions and misdiagnoses.

This is a recurring theme, not one isolated to the 90s.

Re: Modern Pascal is still in the race (2022)

#68

Post by zozbot234 »

Sakos wrote: post #63
dwheeler wrote: post #61

Earlier quoted context omitted.

Ada, at least, uses begin...end in part because it prevents certain kinds of errors. In its syntax you have to specify what you are ending, reducing the risk of invalid matches and increasing the likelihood of the error report system guessing correctly what you intended . E.g.: if X > 0 then Y := 0; end if; Curly braces are shorter, but a close curly brace will match any open curly brace. Such is the nature of trade-…

Ngl, I think that's brilliant. Braces matching the wrong brace is like a daily occurrence. It's such a tedious small thing that constantly hounds me whenever I'm writing code

Most programming languages now support reformatters out of the box. Part of the point of those is to make mismatched closing braces more visible.

Re: Modern Pascal is still in the race (2022)

#69

Post by pavlov »

KerrAvon wrote: post #52
zozbot234 wrote: post #38

Earlier quoted context omitted.

Historically, the point of writing 'begin' and 'end' instead of using curly braces was mostly support for non-ASCII character sets where the curly braces are not included. It's why C also has an alternate syntax using and COBOL goes as far as writing out arithmetical operators as English text, such as DIVIDE x INTO y GIVING z.

I was under the impression that COBOL's English syntax was intended to be a more human-readable approach, not so much a workaround for character set limitations.

Maybe both? COBOL predates the first draft of ASCII by several years. Character sets were far from standardized in those days.

Re: Modern Pascal is still in the race (2022)

#70

Post by mikewarot »

Rochus wrote: post #58
mikewarot wrote: post #31

Earlier quoted context omitted.

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…

> case sensitivity is a bug, not a feature. Agree; that was the first thing I changed in https://oberon-lang.github.io/ ; besides the few academic oddities, original Oberon is a much better language than Pascal or Modula. > He became obsessed with purity, instead of usability There was definitely an academic bubble; for example, the claim that Oberon is a system language and can only be specified with 16 pages is dem…

I never thought of Pascal as a systems programming language. I always considered the inline assembler as the hack to get around that limitation. (Just as it is in C)

I am curious, what's the problem with redundancy? Having more than one way to do something doesn't seem particularly ominous to me. I'm sure you've got solid reasons.

Post reply on HN