6 ms·
https://castle-engine.io/why_pascal https://castle-engine.io/why_pascal I'm gonna have to put a damper on things, here. Most of the reasons listed are things a
by Jean-Papoulos 3y ago
https://castle-engine.io/why_pascal https://castle-engine.io/why_pascal
I'm gonna have to put a damper on things, here. Most of the reasons listed are things available in any other modern language (safety, cross-platformness, libraries...) but one of the things cited is readability.
I work on Pascal code 8 hours a day, and it is not more readable then conventional C syntax ; I'd argue it's much less. The fact that you need to use entire words to denote syntax makes it much harder for your brain to parse things : Instead of immediately seeing "this is code structure" and "this is actual code", you need to actually read the words to make that distinction. It is very counter-productive and a bad design solution, imo.
I feel like this page was written 20 years ago. The reasons would have made quite a lot more sense back then, notably about the type safety.
- deleted 3y ago[deleted]
- nurettin 3y agoI don't have a preference over whether C or pascal is more readable. One might seem more readable depending on my mood or time of day just like editor colors. But my main reason to use a pascal game engine for games would be to avoid garbage collection.
- dazzawazza 3y agoPossibly most of these arguments are arguments in opposition to Lua, the dominant scripting solution in video games, as opposed to pure positives for Pascal? In the 90s a spent many years programing in pascal in Think Pascal... not glamorous but it got the job done. It's not too bad but I program on C++ now so... yeah, maybe my brain has melted.
- vintagedave 3y agoWords can be helpful for people who don't like symbols? C is very terse, Pascal verbose. It's like C vs Python. Single-character symbols can be hard to parse for some people in the same way words are for you. A good IDE / code structure will make the structure and code easy to differentiate anyway.
- mirpa 3y agoI see no difference in learning symbols in order to read source code and learning alphabet in order to read words/sentences.
- tmcdos 3y agoThis is like comparing Latin alphabet with Egyptian pictograms or Chinese hieroglyphs. The time has proven multiple times that using words is easier for humans than using symbols.
- spookie 3y agoPicking up a game engine without prior knowledge and making something on your free time, I assume that would be the aim.
- darkwater 3y agoMost probably you already learnt the alphabet in the past, and there is 0 cognitive load for your brain to parse it. Unless you come from a language using another alphabet, but then unfortunately you need to bow to Latin alphabet rule over programming languages in any case.
- mirpa 3y agoOh, really? if ((input = 'y') or (input = 'Y')) then begin writeln ('blah blah'); end else if ((input = 'n') or (input = 'N')) then begin writeln ('blah'); end else begin writeln ('Input invalid!'); end; if input == 'y' || input = 'Y' { writeln ('blah blah'); } else if input = 'n' || input = 'N' { writeln ('blah'); } else { writeln ('Input invalid!'); } If you find Pascal easier to read, I would guess you have very special set of eyes.
- andsoitis 3y agoYour example isn't idiomatic. You would not write begin/end for single-line cases. Instead it would be: if ((input = 'y') or (input = 'Y')) then writeln ('blah blah') else if ((input = 'n') or (input = 'N')) then writeln ('blah') else writeln ('Input invalid!'); OR even better case uppercase(input) of 'Y': writeln('blah blah'); 'N': writeln('blah'); else writeln('Input invalid!');
- lelanthran 3y ago> The fact that you need to use entire words to denote syntax makes it much harder for your brain to parse things : Instead of immediately seeing "this is code structure" and "this is actual code", you need to actually read the words to make that distinction. It is very counter-productive and a bad design solution, imo. While I agree that it gets slightly tedious to read daily, I have to say that there is no language other than pascal that lets me come back to the language after 3 years and instantly be able to read it with no problems. I don't know if any other language where this is possible.
- tux3 3y agoWhile I'm not the world's #1 Golang fan, this is something that they have. They took a lot of complexity out of the language, so any code you look at will seem very simple & readable. There's not a lot of magic syntactic sugar, you just write things down the simple verbose way. The flip side of that coin is you have to reimplement a lot of things yourself, so any essential complexity that the language doesn't handle for you is pushed on you to re-implement in your codebase. Python's decent at this too. At least the simple Python people use in small scripts. It's almost pseudocode, as long as no one tries and overengineers it.
- archargelod 3y ago> Python's decent at this too. It's almost pseudocode. Nim has Python-like syntax. But, I find it even easier to read/parse at a glance than Python. Also, I hate that in languages with dynamic typing you have to read whole function to understand what type of arguments it takes and what is the return type. Nim is statically-typed, so all the types are properly declared.
- wizzwizz4 3y agoIn my experience, Python, C and JavaScript* all have this property; whereas I have to relearn Pascal, Haskell, sh and (to an extent) Rust every time I go away from them for a bit. I think this is more a property of you or I than of particular languages. *: excluding `for (… of …)` and `for (… in …)` – I can never remember which is which. `for (… of …)` is the one you can use with Arrays and other iterables.
- badsectoracula 3y ago> I work on Pascal code 8 hours a day, and it is not more readable then conventional C syntax ; I'd argue it's much less. I'd disagree with that. I've worked on several Free Pascal projects, C projects, C++ projects and some other stuff and i find it easier to follow Free Pascal code in big projects written by other people than C/C++/Java/etc. At least, i'd say that outside extreme cases (like esoteric languages - or trying to write OOP code in an XML-based language with only imperative functionality :-P), readability is up to the reader. Go is the only other language i found easy to follow, despite not really knowing much about the language itself, but Go is also a much simpler language, more limited in its feature set - Free Pascal on the other hand is a "kitchen sink" language where everything and anything goes and yet it still remains easy to read. That said, IMO the #1 reason to use Free Pascal isn't so much the language itself (most of the stuff mentioned are also available in, e.g., D - and i'd say that D does a much better job at doing compile-time stuff to the point where you can probably implement yourself any missing features from Free Pascal) but the Lazarus IDE and the FCL and LCL frameworks. Well, that and that it has a very fast compiler with a decent optimizer (and there is the new LLVM backend if you need more oomph, though with a big hit to compile time) and a large number of supported platforms. Also great backwards compatibility. That is very important, if my X years old code that used to work stops working without externally imposed reasons (e.g. uses OS-specific code and i switched to another OS or the universe replaced x86 with RISC-V) i don't care how clean, consistent, elegant or whatever else a language might be that give theoretical language designers warm feelings, i care that my code that worked doesn't work anymore.
- graemep 3y agoCan you expand on Pascal vs Go? What is Go missing? I do not know much about either language, but the first thing I thought when people compared Pascal to Go (another comment, not yours) was what about concurrency? Go does have strong concurrency story. AFAIK there is a lack of mobile support, so the use case for Free Pascal is strongest for cross platform desktop apps? Is it something you think is still worth learning? Using for a new project rather than legacy code?
- andsoitis 3y ago
- sylware 3y agoWell... at least there is not pascal++ and that's a win for sure..
- erfgh 3y ago> Instead of immediately seeing "this is code structure" and "this is actual code", you need to actually read the words to make that distinction. First of all, there is syntax highlighting. Furthermore, after the first few times you see a word you don't actually "read" it in the sense you mean here, you are just matching it, as an image, with other words in your vocabulary. So it's not any harder to "read" a word than to read a curly brace, assuming no other very similar words are used in the vocabulary of the language.
- thesz 3y agoWords can be read as single hieroglyphs, basically, it is matter of experience.
- dadie 3y agoAs someone who has been coding in Delphi for a living for the past 5 years I'd argue the syntax being verbose is only a small part of a larger problem, which is that (object) pascal is a very bad language for pattern recognition. The syntax highlighting in current IDEs like RAD Studio or Lazarus is very poor (though I'm not as familiar with the later). I mean I think aside from keywords, strings, numbers and comments everything has the same color. Even if the syntax was less verbose, we'd still be reading each word. It is basically the same as having no syntax highlighting at all. And even assuming the syntax highlighting would get better and/or the syntax would be less verbose, we'd still be reading each word because of the case-insensitive nature of the language. The compiler might not care about the case, but at least my eyes do. So unless I'm reading the word I could not really say whether MyMaGiCaLnAmE and mYmAgIcAlNaMe is the same name or not.
- Log_out_ 3y agoIs it though. The whole cross Plattform is a leaky abstraction almost anywhere. Just accept it's gonna be limited to windows and reduce the workload for main revenues market.
- musicale 3y agoNoticed this on the modern object pascal intro page: {$R+} // range checking on - nice for debugging I want this (perhaps as a compiler and/or runtime option) for clang/gcc as well.