Earlier quoted context omitted.
i do not think you understand the concept of scope.
Perhaps you're being a little short here? Explaining what you mean would go a long way to fostering good will.
More of these replies on HN please!
Why use Pascal?
211–220 of 516 posts
Re: Why use Pascal?
#212Does Pascal still require all variables to be declared at the top? I did a quick search and that seems like the case, but I want confirmation from someone that knows the language. If so, that's a immediate "no" for me. We know by now that keeping variable declarations close to their usage is a big boost in readability, and at times even in performance (you only declare variables you actually use). I know Pascal has e…
One of my primary languages is C89 and don't find it an impediment. It's been over 2 decades since I last touched Pascal so I'm not sure how it works there, but in C you can always open a new inner scope with { and declare more variables there.
and at times even in performance (you only declare variables you actually use).
All but the stupidest compiler (which usually means no optimisation at all, not even precomputing constants) will not be affected by completely extraneous variables.
Re: Why use Pascal?
#213Earlier quoted context omitted.
I've found .Net deployments to be rock solid and easy. What problems do you hit?
A couple of months ago I started working at a company that (mainly) develops C# libraries. The pipeline to deploy is complicated. Using a tool like ILMerge to combine DLLs into a single DLL (to prevent DLL hell issues). Using Babel to obfuscate the code base. Using nuspecs to create a Nuget package from the DLLs and various metadata. Signing the DLLs with some certificate. Then, if native stuff is included, also ensu…
Well, a lot of those requirements are highly bespoke to your task and to your team.
My C# pipelines and C# apps are far easier to package and deploy than my Python apps for example. And, as you said, the pipeline is normally a one time cost.
Re: Why use Pascal?
#214Earlier quoted context omitted.
They are both used to define blocks. Eg Begin … End in for loops https://wiki.freepascal.org/For From what I recall, Pascal doesn’t support variables scoped within a specific block. But then neither do some languages with C-style curly braces too. So {} and Begin…End are pretty much the same thing. BASIC (and Visual Basic especially) often get a lot of criticism for their syntax but the End Thing style block terminat…
i do not think you understand the concept of scope.
I’ve written a few compilers in my time so I have some idea about scoping rules ;)
As I and other have already said, it depends on the specific language. Some languages scope local variables at the function level (irrespective of {} or Begin End), and other languages scope local variables inside the containing {} or Begin and End block.
In that regard {} and Begin End serve identical purposes of defining a local execution block and then it’s up to the language or dialect, or sometimes even the compiler authors, to decide upon the rules of variable scoping.
What you’re doing here is conflating syntax grammar with deeper rules about a languages compiler or specification.
To come back to your original point, Delphi does support variable scoping inside Begin End blocks. I don’t know if FreePascal also does but older dialects of Pascal didn’t because of the original intent of Pascal being a single pass compiler. Equally, not all languages that have C-like curly braces support variable scoping in the way you’re trying to describe. JavaScript originally didn’t and had to create a whole new keyword to add it (a little like what Delphi did, funny enough). My own shell scripting language very intentionally doesn’t support scoping despite having curly braces.
As for inlining other contexts like functions, classes, etc, it has been a while since I’ve written any Pascal so I can’t recall the nesting rules here. But like with our discussion about variables, it’s more a question of whether the specification and/or compiler has support rather than a quirk of the Begin End grammar that forbids it — just as is the case with {} too.
Re: Why use Pascal?
#215> Why use Pascal? Because you like Niklaus Wirth's languages, and only those ... but only up to Pascal. You don't think that the improvements in his subsequent Pascal-like languages are Wirth a damn. You believe that Wirth went soft in the 1970's and 1980's, and sold out Pascal. If that is you, you probably write code in Pascal, implement Pascal, write about Pascal ... (Everyone else should probably skip Pascal and t…
> (Everyone else should probably skip Pascal and take a look at Modula-2 and Oberon.) I did check out Oberon-07 because of its minimalism but i really couldn't get over the SHOUTY keywords :-P. (Wirth used uppercase for Pascal's keywords too but unlike Oberon, Pascal is not case sensitive - my pet theory is that Oberon is case sensitive as a reaction to Pascal programmers not using shouty capitalization :-P)
I think the main reason for keywords being uppercased in Oberon (which is case sensitive) is to free up the space for user-defined identifiers. As long as the programmer sticks to lowercase and mixed case identifiers, new keywords and predefined procedures can be introduced in the language without invalidating old programs.
Re: Why use Pascal?
#216I disagree with some of their reasons. Modern: Object Pascal isn't a modern language. It was modern in 1998, maybe, but it hasn't evolved much since then. Latest big change was the addition of generics, behind almost any other language. Fast: FPC doesn't generate particularly fast code, and the nature of OP objects doesn't help with locality. It's faster than scripting languages, but generally slower than AOT compile…
I also think the modern part is exaggerated here. Object Pascal was had cutting edge features and developer experience in the 1990s, but I think it's hard to see it this way nowadays.
There are two big features that one expects in a "modern" language that are missing in object pascal:
1. Some sort of automatic memory management that prevents memory leaks and dangling pointers. Modern languages usually have GC, automatic reference counting (like Swift or Python) or some form of static analysis (like the Rust borrow checker) - Zig is probably the only outlier here, but it does have better memory safety tooling (like defer). Object Pascal really feels like going back to C++ as it was during the 1990s and early 2000s, before smart pointers and later move semantics caught on. If I remember correctly, COM interfaces, but they carry the COM baggage and nobody is using interfaces for everything.
2. A package manager that is isolated (not impacted by the global environment), supports specifying dependency version in a configuration file and supports repeatable builds with lockfiles. fppkg doesn't seem to go that far.
There are other features that you could argue for I guess, like type inference, simplified expression syntax, asynchronous I/O and more, but they would be more controversial.
I don't think I can honestly call Object Pascal a modern language, and it's sad, since I still have a warm place in my heart for Pascal.
Re: Why use Pascal?
#217Earlier quoted context omitted.
A couple of months ago I started working at a company that (mainly) develops C# libraries. The pipeline to deploy is complicated. Using a tool like ILMerge to combine DLLs into a single DLL (to prevent DLL hell issues). Using Babel to obfuscate the code base. Using nuspecs to create a Nuget package from the DLLs and various metadata. Signing the DLLs with some certificate. Then, if native stuff is included, also ensu…
Well, a lot of those requirements are highly bespoke to your task and to your team. My C# pipelines and C# apps are far easier to package and deploy than my Python apps for example. And, as you said, the pipeline is normally a one time cost.
Comparing to Python is not exactly fair. I don't think there are any languages that have a worse deployment experience.
How does it compare to Go or Rust?
Re: Why use Pascal?
#218Why? Old languages must remain around for legacy support. However, it's hard to see the point of shoe-horning all those modern features into an old language. I write a lot of Java, and really, almost everything since Java 8 should not have been added. Lambdas, for example, are a kludge in Java. Want modern features? Use a modern language. If you want to stay in the Java ecosystem, for example, you could use Kotlin. I…
> Use a modern language. If you want to stay in the Java ecosystem, for example, you could use Kotlin. That's easier in Java given how easy it is to interop between languages (see also Clojure). What if I'm using C++? There's no easy upgrade path to anything else. There's still value to "shoe-horning all those modern features". I might not start a project with C++ today, instead choosing a modern language (e.g. Rust)…
> I might not start a project with C++ today, instead choosing a modern language (e.g. Rust) instead.
This would depend on what your constraints and needs are. Rust isn't a "modernized C++", it's a language/ecosystem with a different set of strengths and weaknesses. You may very well prefer C++ over Rust today.
Re: Why use Pascal?
#219Earlier quoted context omitted.
> Begin End vs { } doesn't really bother me. but they don't really mean the same thing - {} defines a local scope, begin...end doesn't.
They are both used to define blocks. Eg Begin … End in for loops https://wiki.freepascal.org/For From what I recall, Pascal doesn’t support variables scoped within a specific block. But then neither do some languages with C-style curly braces too. So {} and Begin…End are pretty much the same thing. BASIC (and Visual Basic especially) often get a lot of criticism for their syntax but the End Thing style block terminat…
The most C-style language is C and it does have variables scoped to a block, I believe. The same for C++.
Re: Why use Pascal?
#220Does Pascal still require all variables to be declared at the top? I did a quick search and that seems like the case, but I want confirmation from someone that knows the language. If so, that's a immediate "no" for me. We know by now that keeping variable declarations close to their usage is a big boost in readability, and at times even in performance (you only declare variables you actually use). I know Pascal has e…
One of my primary languages is C89 and don't find it an impediment. It's been over 2 decades since I last touched Pascal so I'm not sure how it works there, but in C you can always open a new inner scope with { and declare more variables there. and at times even in performance (you only declare variables you actually use). All but the stupidest compiler (which usually means no optimisation at all, not even precomputi…
> All but the stupidest compiler (which usually means no optimisation at all, not even precomputing constants) will not be affected by completely extraneous variables.
The statement is certainly false in this general form, even with full link-time optimizations. If the type has a constructor with side effects external to the program (e.g. it makes syscalls), the compiler cannot remove the variable.