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

91–100 of 160 posts

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

#91

Post by BaculumMeumEst »

deergomoo wrote: post #87
nine_k wrote: post #66

Earlier quoted context omitted.

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

I'm very much not a C programmer, but I've never understood why it seems far more common to write `float *foo` instead of `float* foo`. The "pointerness" is part of the type and to me the latter expresses that far more clearly.

The * binds the name, not the type.

https://godbolt.org/z/GsoxrWdrG

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

#92

Post by eichin »

deergomoo wrote: post #87
nine_k wrote: post #66

Earlier quoted context omitted.

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

I'm very much not a C programmer, but I've never understood why it seems far more common to write `float *foo` instead of `float* foo`. The "pointerness" is part of the type and to me the latter expresses that far more clearly.

Because it isn't - `float* foo, bar;` foo is a pointer, bar is not.

(There were suggestions back in the 90s that to make C easier to parse for humans (and not-coincidentally simplify the compiler grammar) this should be `foo, bar: float*;` and your model of pointerness could actually be true. Never got much more traction than some "huh, that would be better, too bad we've been using this for 10 years already and will never change it" comments :-) (with an occasional side of "maybe use typedefs instead")

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

#93

Post by andomizczzz662 »

noizejoy wrote: post #90
pavlov wrote: post #69

Earlier quoted context omitted.

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

Lots (most?) of classic COBOL used EBCDIC[0] [0] https://en.wikipedia.org/wiki/EBCDIC

[dead]

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

#94

Post by usrusr »

suby wrote: post #81
zozbot234 wrote: post #68

Earlier quoted context omitted.

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

Rainbow brackets, so the brackets themselves are color coded to match with their corresponding partner, are also a godsend.

I'm surprised that code folding has never really become good/popular enough to make all these things non-issues.

Often it's only for named blocks like functions, and not for the really unhelpful bits like that conditional branch that is long, simple and deep, but really does not deserve spamming a namespace with an unhelpful identifier. And I've yet to see a deliberately short-lived folding to lessen the out of sight, out of mind tax that code folding of associated with. If there was deliberately short-lived folding, perhaps auto-reexpanding whenever the section has scrolled out of view, I'd use folding all the time, to navigate the nesting. The quasi-permanent until explicitly re-expanded cold folding? Yeah, I hardly ever use it, to many bad experiences with forgetting to re-expand.

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

#95

Post by Sakos »

zozbot234 wrote: post #68
Sakos wrote: post #63

Earlier quoted context omitted.

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.

Even with all these helpers, there's too much cognitive overhead and not enough that IDEs or plugins can do to take that away. Rainbow braces are nice and all, but it's not enough when the underlying concept is broken.

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

#96

Post by optymizer »

deergomoo wrote: post #87
nine_k wrote: post #66

Earlier quoted context omitted.

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

I'm very much not a C programmer, but I've never understood why it seems far more common to write `float *foo` instead of `float* foo`. The "pointerness" is part of the type and to me the latter expresses that far more clearly.

I swear if I see one more "int* x, y" example I will flip a keyboard. This isn't the 90s anymore. Everyone and their mother knows about this one pitfall, repeated for decades by people who have yet to read the memo that we now declare one variable per line, so it is never an issue. Even if you make this mistake, it's the least of your worries when coding in C because the compiler will typically warn you when you try to use the integer as a pointer.

Get with the program: types on the left, names on the right, one declaration per line.

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

#97

Post by badsectoracula »

deergomoo wrote: post #87
nine_k wrote: post #66

Earlier quoted context omitted.

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

I'm very much not a C programmer, but I've never understood why it seems far more common to write `float *foo` instead of `float* foo`. The "pointerness" is part of the type and to me the latter expresses that far more clearly.

I think it is a manner of preference, both "float* foo" and "float *foo" are widely used.

Personally i used "float *foo" for years until at some point i found "float* foo" more natural (as the pointer is conceptually part of the type) so i switched to that, which i've also been using for years. I've worked on a bunch of codebases which used both though (both in C and C++) - in some cases even mixed because that's what you get with a codebase where a ton of programmers worked over many years :-P.

I do tend to put pointer variable declarations on their own lines though regardless of asterisk placement.

(and of course there is always "float foo[42]" to annoy you with the whole "part of the type" aspect :-P)*

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

#98

Post by badsectoracula »

jchw wrote: post #46
broken-kebab wrote: post #40

Earlier quoted context omitted.

It's not something to differentiate between them: neither is obsolete as long as somebody uses it to earn, and Pascal dialects has been evolving as well as C#, while neither deviated significantly from their roots. TypeScript (which is rather new PL) uses Pascal-style for types. Haskell, and Ocaml are niche too, and the syntax is 98% from 70s, but it still feels like a new for someone who sees them for the first time…

Sorry, I am not convinced. To me, Pascal's syntax and source code organization is archaic. Even more archaic would be COBOL and BCPL. On a somewhat similar level to Pascal, perhaps Erlang as well. People's opinions do change over time, but I do not think it's likely that there is a renaissance awaiting Pascal's overall design decisions, specifically the ways in which Pascal differs from C. That's because differing fr…

> like the lack of short-circuiting in boolean expressions. I assume modern Pascal compilers have resolved this

I think your ideas on Pascal are a little outdated if you assume short circuit boolean expression are a modern Pascal compiler change. Turbo Pascal, one of the by far most common dialects, had that since the 80s, meaning this change has been around for four decades (assuming Turbo Pascal didn't take it from some other popular at the time dialect like USCD Pascal).

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

#99

Post by mananaysiempre »

deergomoo wrote: post #87
nine_k wrote: post #66

Earlier quoted context omitted.

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

I'm very much not a C programmer, but I've never understood why it seems far more common to write `float *foo` instead of `float* foo`. The "pointerness" is part of the type and to me the latter expresses that far more clearly.

For the same reason you don’t write x+y * z: because then the spacing contradicts the way the priorities work in the language.

We might wish for the C declaration syntax to be [, ...], but it’s not: it’s [ ...] [, ...], where int, long, unsigned, struct stat, union { uint64_t u; double d; }, and even typedef are all specifiers, and foo, (foo), (((foo))), *bar, baz[10], (*spam)(int), and even (*eggs)[STRIDE] are all declarators (the wisdom of using the last one is debatable, but it is genuinely useful if you can count on the future maintainer to know what it means).

Everybody is free to not like the syntax, but actively misleading the reader about its workings seems counterproductive.

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

#100

Post by girvo »

kagakuninja wrote: post #42
jerf wrote: post #21

Earlier quoted context omitted.

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

Mutexes aren't OK even if you only use one. They are error prone, you can forget to unlock. And of course, there is a temptation to avoid using it for efficiency reasons, because you "know" this part of the code is safe. These days I develop servers on the JVM. We almost never think about mutexes or related things, libraries take care of that. I use Scala, and our entire data model is immutable, eliminating most race…

> They are error prone, you can forget to unlock

That's a language issue though, rather than a mutex one. It's reasonably straightforward to fix that, as some languages (like Nim) do.

Post reply on HN