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

101–110 of 160 posts

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

#101

Post by badsectoracula »

misja111 wrote: post #14
astrodust wrote: post #12

Earlier quoted context omitted.

Delphi was really a "Concorde moment" in that it was actually rapid , both in terms of development speed, and performance, which was somehow forgotten as the web emerged. Forgotten to the point that people thought Visual Basic was a good idea.

Delphi was great but a major deal breaker was that is was not free to use.

Early versions of Delphi were cheap enough ($99) even a high schooler could pool the money to buy it (or, more realistically, ask their parents :-P). That lasted until Delphi 5 IIRC.

The real dumb move (though TBH i can only say that in hindsight) was that they made a free Linux version with Kylix, the license required any programs released to be under GPL but they didn't release Kylix itself as GPL.

This was in very early 2000s, when GPL wasn't the boogieman among developers that seems to be nowadays with all the permissive licenses, desktop software was still something people wanted, commercial software wouldn't touch GPL and yet a lot of new programmers were onboarding Linux. Having Delphi/Kylix full GPL with a CLA (like some other projects) would mean that a) Kylix would become part of various Linux distributions, especially during a time when distributions were the main source for tools for Linux users, b) anyone working on FLOSS would both use and improve the tool, c) mindshare among programmers would improve as anyone will be able to try it out for free (as long as they used Linux, but many programmers - especially younger programmers at the time - didn't mind that), d) companies, enterprises, etc that wanted to sell shareware or just didn't want the rules GPL imposed would still need to buy the full program

Sadly this seemed to be yet another case of when Borland started losing touch with programmers in the 90s.

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

#102

Post by ggm »

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…

the T(wo)LA of UC in UCSD/UCSC can't be entirely ignored. the p-system was very innovative, but ultimately got sidelined I think UC decided to self-host its teaching paradigm, well and good. If you'd gone to any other university without UC in its name you might not have had the p-System thrown at you so much. Obviously if you'd gone to UCB, things would have been radically different.

The interesting thing to me is that San Diego hosts the supercomputer centre and so there was a sense the engineers there really live in Fortan, did, and do.

(I was in the UK system at the same time as you, and my uni had Wirth on sabbatical for a year, during the ada/modula specification days. We all learned on Pascal on a Dec-10, unless you chose the other door and went LISP. I regret not going in the LISP door now, but hindsight is like that)

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

#103

Post by bombcar »

usrusr wrote: post #94
suby wrote: post #81

Earlier quoted context omitted.

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…

Code folding is phenomenal for understanding a codebase and I'm really surprised it wasn't utilized more.

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

#104

Post by galangalalgol »

bluGill wrote: post #77
supportengineer wrote: post #60

“Usually, at our age, we should be managers, not developers.” There’s a lot of assumptions and bias in here.

I'd prefer to be a senior staff engineer, or whatever they call the technical leaders. The pay isn't quite as good as upper management, but it is equal to regular management and I get to do technical things. I just have to be careful not to direct others to make a big unmaintainable mess.

Yeah ageism wasn't always part of our profession. It was probably a side effect of rapid progress combined with the desire for wage suppression. It has let us move faster as old bad ideas lose their champions faster, but we then lose all the old good ideas too. Not every developer should turn into a manager. We don't need that many managers, and good managers are more rare than good developers in my experience. Having a stereotype that old developers that aren't rich yet must be bad developers comes and goes as the bubbles form and burst. If you develop in a domain where developers need lots of on the job expertise before being productive, or in embedded or game development where a big part of TC is job enjoyment, then that stereotype is already stale and career staff developers can regularly be geniuses.

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

#105

Post by Espressosaurus »

eichin wrote: post #92
deergomoo wrote: post #87

Earlier quoted context omitted.

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…

Which is why the convention is usually to not permit multiple declarations in one line.

If you value your codebase anyway.

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

#108

Post by alurm »

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.

Here's how I understand it.

One important (and beautiful) thing to understand about C is that declarations and use in C mirror each other.

Consider the same type written in Go and C: array of ten pointers to functions from int to int.

Go: var funcs [10]*func(int) int

C: int (*funcs[10])(int)

Go's version reads left to right, clearly. C version is ugly.

But beautiful thing about C version is that it mirrors how funcs can be used:

(*funcs[0])(5)

See how it's just like the declaration.

Go's version doesn't have this property.

So, now about the *.

Usage of * doesn't require spaces.

If p is a pointer to int, you use it like this: *p

And not like this: * p

And since type declarations follow usage, therefore "int *p" makes more sense.

There is also a good argument about "int *p, i". In the end, these usages follow from how the C grammar works.

There are many more musings about that on the web, but here is one of my favourites: https://go.dev/blog/declaration-syntax.

Edit: HN formatting.

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

#110

Post by kazinator »

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 the syntax is:

    {, , ...} ;
The star is a type-deriving operator that is part of the , not part of the !

This declares two pointers to char:

  char *foo, *bar;
This declares foo as a pointer to char, and bar as a char:

  char* foo, bar;
We have created a trompe l'oeil by separating the * from the declarator to which it begins and attaching it to the specifier to which it doesn't.
Post reply on HN