4 ms·
Does 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
by maleldil 3y ago
Does 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 evolved a lot over time. If this is indeed still a requirement, it's hard to understand why, and a barrier to those used to scoping in "modern" languages (even C99 has this).
- badsectoracula 3y agoDelphi allows inline variable declaration but Free Pascal does not (the developers explicitly decided against implementing it). Note that in Pascal (FPC, Delphi, whatever) you can have nested functions so this isn't that much of a limitation as it sounds. For example if i have a procedure that is very long i often end up splitting it in multiple nested procedures and each one has its own variable section. Also from a more practical perspective Lazarus (the most common FPC IDE) has a shortcut key to automatically insert variable declarations so you don't have to move up and down in code even if you have a large function body. I'd expect Delphi to have something similar.
- zabzonk 3y ago> Delphi allows inline variable declaration it may do so now, but for the longest time it didn't, which made it compare poorly with C++ and even with C, which allows definitions in a scope. in fact the OP concept of scope is a bit crap - basically the whole function,
- pjmlp 3y agoYour concept of Object Pascal scope is also outdated, in relation to Delphi.
- gaze 3y agoSeems a bit shallow. JavaScript equals is an abomination, which to me seems like a larger issue, and people use it just fine.
- maleldil 3y agoI agree that triple equals is an abomination. It's one of the many things ensuring I use JavaScript as little as possible.
- cxr 3y agoYou can pretty much ignore mostly anyone most of the time who screeches at you to use triple equals (strict equality comparison) instead of regular ol' "==" (abstract equality comparison). It's one of modern programming's dumbest, least well-founded memes, resulting in such brilliant advice as insisting during code review that typeof(foo) == 'string' be changed to typeof(foo) === 'string' because the latter is "safer". Anyone saying—anyone—this is guaranteed not to know what the hell they're talking about—and shouldn't be in a position where they're pretending that they do. It's unjustifiable and pure cargo cultism.
- gaze 3y agoA well designed language should not have an equals that results in a cargo cult
- cxr 3y agoI have missed the part of the discussion that contains an imperative for folks to debate the resolution of whether JS is a "well designed language"—and not about JS's equality comparisons per se and whether it's still usable or not despite that. These: > JavaScript equals is an abomination, which to me seems like a larger issue, and people use it just fine. ... are your own words...
- drpixie 3y agoIf that's the worst thing you can find about Pascal (and it's just a style issue) then Pascal must be the best thing ever :)
- userbinator 3y agoOne 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.
- mike_hock 3y ago> 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.
- userbinator 3y agoIf they cause visible side-effects, they are by definition not extraneous.
- mike_hock 3y agoI'm not interested in playing this semantics game. The compiler can't know whether a syscall has side effects. And some side effects can be benign and irrelevant, and you definitely left the variable in by mistake, but they're still side effects.