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

41–50 of 160 posts

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

#41

Post by zozbot234 »

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…

Unfortunately, LOGO uses dynamic scope. It could easily be a viable language aside from that one misfeature.

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

#42

Post by kagakuninja »

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…

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 conditions. I think I had to declare something as volatile once or twice.

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

#43

Post by kagakuninja »

broken-kebab wrote: post #27
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…

I think it's better to avoid time-related adjectives like "archaic" when talking about PLs. For starters it doesn't really mean much in general: in software development fashions come, and go, and then reappear as "new" again. Secondly, Pascal syntax is of the same historical age as that of C, and the ML languages. Would you say that C# (or Haskell) is syntactically archaic?

OK, how about "cumbersome" or "unnecessarily verbose". I haven't used modern Pascal, but the ancient version I used was also very limited.

I am 60, have used many languages, and used to love C and C++. I consider C and C++ archaic and Java is border-line. I thought Java was cool 10-20 years ago, but I've moved on to Scala.

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

#44

Post by kagakuninja »

Simplicitas wrote: post #39
kagakuninja wrote: post #35

I have lingering distain for Pascal, unlike other people here... In 1980 I was a freshman at UCSC, and the professors did not like C. So most classes used UCSD Pascal. While it apparently pioneered some cool ideas, it was not at all ready for industry use. The free function was just a suggestion, it didn't deallocate anything. Arrays were fixed size, and an array of size 80 was a different type than size 255 (and 255…

Is it just me or does hearing "Zilog Corporation" not sound like it's straight out of the movie "Blade Runner"?

Lol, I added corporation because I assumed the youngsters didn't know about it. After googling, I see they called themselves Zilog, Inc.

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

#45

Post by brnt »

msla wrote: post #33
JAlexoid wrote: post #26

Earlier quoted context omitted.

> C with 2 plusses I read it as "C with two pulses"... Which is how I feel about C++ - unnecessarily complicated.

I don't understand the joke you're making. How does "pulse" equate to complicated?

C++ isn't really one language, but a language family with dozens if not more dialects. If you read some codebases from different places, you will sometimes, or even often, barely recognise what's going on (unless you are an advanced user).

In C++, people very much tend to pick a subset, so different pulses beat concurrently, if you will.

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

#46

Post by jchw »

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

Earlier quoted context omitted.

I'm not convinced: the term archaic implies that something is obsolete or subjectively old-fashioned, not just that it's necessarily old. C# isn't archaic in part because C never stopped being relevant this whole time and because C# syntax has evolved significantly in recent years.

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 from C is costly and requires justification. In some cases, I think Pascal's decisions just proved wrong; like the lack of short-circuiting in boolean expressions. I assume modern Pascal compilers have resolved this, but it's a good example of how I think things go: ideas that improve the status quo are worth bringing back, ideas that have a lot of switching costs are a hard sell.

I also understand that sometimes the difference may seem superficial, and that's because they are. Are Pascal units really vastly different from modern translation units/modules? Somewhat, but not that much. But it differs enough that someone not familiar with Pascal needs some time to adapt, whereas almost anyone with programming experience of any level can pick up Go, because it's stupidly simple. It does differ from C and other languages that are still contemporary, but when it does differ it's often good: the type syntax and declaration syntax is massively simpler than C, for example. (And yes, Pascal's type syntax is also better, at least by some measures.)

I'm happy to discuss these matters, but I will also be completely honest: I'm not particularly moved by this line of argument. It feels somewhere between semantics and an implicit desire to consider a future where Pascal syntax somehow becomes in vogue again as it was in the early 2000's. Maybe an evolved Pascal, but not the Pascal of today. And if I'm wrong, I'm wrong; I'm just calling it the way I see it.

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

#47

Post by jerf »

jchw wrote: post #28
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…

Yeah, I can relate to this. When coding in Go I routinely combine mutexes and channels. Channels are useful for signalling and some other things. I am a bit miffed though since it absolutely feels like CSP concurrency and message passing COULD be better, it's just not in Go. Maybe I'll try Erlang some day and be imbued with the curse of knowledge. Rust doesn't solve the problem of multiple mutexes being tricky, but i…

"Maybe I'll try Erlang some day and be imbued with the curse of knowledge."

For the purposes of this discussion [1], Erlang is just Go except you don't have mutexes as an option at all, so anything you want locked has to be in a separate Erlang process (analog of goroutine). So if all you want is a shared dictionary to be used as a cache or something, it has to have its own process/goroutine, you don't get an option of just locking access.

Since that's how it works in Erlang, it has a bit of syntax grease around it, but not enough to make it just right; you've still got to do things like handle communication errors because it could be on a different node in a cluster whereas in Go it's just a local shared resource.

I think the main problem is that as useful as actors are as a concept, they're not a great foundational abstraction, which is to say, the base that everything is built on and you can't go below. It works, but then it means you're paying the full actor price for everything. But you don't always want the full actor price for everything, and you don't need to pay it because in practice "lack of actor isolation" is rarely the root cause for any particular problem, because that's too big a thing to be the root cause.

[1]: If that's too glib for you: https://news.ycombinator.com/item?id=34564228

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

#48

Post by pkolaczk »

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 not a problem with mutexes but with resource management in some languages. In Rust mutexes use RAII and unlock automatically - you cannot accidentally forget to unlock.

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

#49

Post by veber-alex »

pkolaczk wrote: post #48
kagakuninja wrote: post #42

Earlier quoted context omitted.

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 not a problem with mutexes but with resource management in some languages. In Rust mutexes use RAII and unlock automatically - you cannot accidentally forget to unlock.

Yes but it is very easy to hold mutexes locked longer than needed because you usually don't think about when stuff is dropped in Rust, you just let it go out of scope.

I have gotten really annoying deadlocks because of this in the past.

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

#50

Post by broken-kebab »

kagakuninja wrote: post #43
broken-kebab wrote: post #27

Earlier quoted context omitted.

I think it's better to avoid time-related adjectives like "archaic" when talking about PLs. For starters it doesn't really mean much in general: in software development fashions come, and go, and then reappear as "new" again. Secondly, Pascal syntax is of the same historical age as that of C, and the ML languages. Would you say that C# (or Haskell) is syntactically archaic?

OK, how about "cumbersome" or "unnecessarily verbose". I haven't used modern Pascal, but the ancient version I used was also very limited. I am 60, have used many languages, and used to love C and C++. I consider C and C++ archaic and Java is border-line. I thought Java was cool 10-20 years ago, but I've moved on to Scala.

It's verbose for sure (though Pascal's overall amount of boileplate probably takes less space compared to Java code). Structurally it's almost the same beast (both inherited from Algol), with notable exceptions like for loop.

Scala feels more modern than C to me too, when talking about language concepts/features. Regarding syntax they are in the same basket.

Post reply on HN