As anecdote, my new older co-worker started his new embedded camera project also with Lazarus. A fast safe language, much easier and safer than C. Even SIMD tricks and OpenCV are possible for higher frame rates.
Lazarus is the IDE for FPC, the FreePascal Compiler, as I understand it. Lazarus itself isn't a language.
Modern Pascal is still in the race (2022)
151–160 of 160 posts
Re: Modern Pascal is still in the race (2022)
#152I 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…
I think you meant Modula-2, in many ways a successor to Pascal. https://en.wikipedia.org/wiki/Modula-2
Re: Modern Pascal is still in the race (2022)
#153I 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 th…
Now I am a Scala programmer, often doing pure-FP with Cats...
Re: Modern Pascal is still in the race (2022)
#154Earlier quoted context omitted.
You misremember. Pascal's grammar is "easy" because it is LL(1), not LR(1)! C is almost LR(1), if we allow prior declarations to decide how some tokens are classified, like whether an identifier is a variable or type name. Declarations like void (*signal(int, void (*fp)(int)))(int); are LR(1). LR(1) sentences are harder to read than LL(1) because you have to keep track of a long prefix of the input, looking for right…
> C is almost LR(1), Does that include the C preprocessor? Somehow, I recall someone here (maybe it was user walterbright) suggesting that implementing a C preprocessor was a lot of work - maybe months - so one might consider using Facebook's MIT licensed preprocessor: https://github.com/facebookresearch/CParser
[1] https://web.archive.org/web/20230714010215/http://conal.net/...
Re: Modern Pascal is still in the race (2022)
#155Earlier quoted context omitted.
Which is why the convention is usually to not permit multiple declarations in one line. If you value your codebase anyway.
Declaring X,Y and Z on separate lines for a graphics routine would just be silly, they're all the same type. Defensive programming that extreme reminds me of the behavior I learned to avoid pissing off my drunk dad.
Re: Modern Pascal is still in the race (2022)
#156Earlier quoted context omitted.
Lazarus is the IDE for FPC, the FreePascal Compiler, as I understand it. Lazarus itself isn't a language.
Lazarus only supports fpc and no other compilers, nor pascal dialects. Sure
As I understand it, it is mixing up a language with an IDE.
Re: Modern Pascal is still in the race (2022)
#157Earlier 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.
One thing that is better about the syntax that I really like is the removal of BEGIN and END everywhere except around code in MODULEs and PROCEDUREs. IF/THEN/ELSE/END, FOR/DO/END, REPEAT/UNTIL, WHILE/DO/END, CASE/ELSE/END, no longer have BEGIN/END, even if there are multiple statements in them. This makes the code less verbose than C and C++ and equally or more compact vertically than them, depending on whether you put your braces on separate lines.
Re: Modern Pascal is still in the race (2022)
#158Earlier quoted context omitted.
I think you meant Modula-2, in many ways a successor to Pascal. https://en.wikipedia.org/wiki/Modula-2
Yes, a typo. My friends referred to it as Modula-screw.
Ada and Oberon are even better.
Re: Modern Pascal is still in the race (2022)
#159Always loved pascal and always will. It was one of my first introductions to "Structured Programming"
How about Ada or Oberon, both much better than Pascal or Modula-2?
Re: Modern Pascal is still in the race (2022)
#160Earlier 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
In languages without this feature (most of them), you sometimes see long blocks get labeled at the end anyway. On the other hand, you could argue that if your block is long enough it doesn't fit on the screen, then it should be its own function anyway. Like this, except replace "..." with many lines of code. if (z.p == z.p.p.left) { ... } else { // z.p != z.p.p.left ... } // if
True. However, in Ada at least, if the block types don't match then it's a syntax error detected at compile time by the compiler. Comments like those listed above are often not checked at compile time, and thus aren't very useful for preventing errors.