71–80 of 103 posts
Earlier quoted context omitted.
Just always use !==. != will automatically cast and !== won't, therefore "1" != 1 is false and "1" !== 1 is true.
Unless you’re testing if something is null or undefined, in which case a single “x != null” handles it.
Earlier quoted context omitted.
Oh, 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 s…
Your 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!');
case input of
'A'..'C': writeln('blah blah blah');
'N','n': writeln('blah blah');
'Y','y': writeln('blah');
else
writeln('Input invalid!');
end;Earlier quoted context omitted.
Most 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.
Oh, 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 s…
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;
And why should be the double pipe be any better to read than an "or" statement?
Btw: as you won't need the begin and ends it would look like
if (input = 'y') or (input = 'Y') then
writeln ('blah blah')
else
if (input = 'n') or (input = 'N') then
writeln ('blah')
else
writeln ('Input invalid!');I took a look at the code, since I was curious far a large Pascal codebase looked like. I haven’t seen a substantial amount of Pascal code since about 2001. One thing I noticed was the file names, I can’t say I’m a fan of prefixing every single source file with “castle”, it makes it much harder to see what the file is about and makes them all look the same. I can’t comment on the actual code, since I’ve never written…
This is no different from yacc files being prefix by "yy". It makes it easier to spot which files are castle files and avoids collisions with files/units from other libraries. Meaningless nitpick.
There may be a handful of yacc files in a large project, so prefixing them with "yy" is convenient to locate them quickly - though I'd still prefer a dedicated subdirectory.
Every file in this project is a "castle file", so preceding every name with "castle" is pretty useless and hinders readability and navigation. If it's not part of castle, it shouldn't be checked into the repo.
Earlier quoted context omitted.
> 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…
Can 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 learni…
Pjmlp mentioned a few, though i wouldn't say so much they are things "Go is missing" but more "Go does not provide them" - at least in my mind it is more of a FPC has "more stuff you could use" than Go lacking stuff.
> what about concurrency?
It is pretty much the same as you'd find in most other languages: done via threads with some language support for thread level storage. There are some helpers in the library and Lazarus also comes with a package that allows you to run stuff in parallel like a "parallel for", but nothing higher level than that.
> Is it something you think is still worth learning? Using for a new project rather than legacy code?
I think if you want to make a desktop application that runs in multiple desktop OSes, it is worth to learn it so you can use Lazarus. For other stuff, i dont think it provides that much of a benefit compared to other languages. I think the weakest aspect might be server-side apps - there is some support (even out of the box and Lazarus even has some RAD support for it so you can do things like routing URLs to different parts visually) and a framework or two, but i get the impression that most effort is in desktop stuff.
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…
Then something got lost with Delphi, it's not that it was a bad product, but people started looking elsewhere...
I still cherish the day, as Pascal gave me the headstart to C/C++ from Apple Basic, but also allowed me to start using bit of inline assembly and learn it along the way...
Earlier quoted context omitted.
In 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.
> *: excluding `for (… of …)` and `for (… in …)` There's more that will trip you up in JS if you leave it for too long. Off the top of my head: 1. Which function definition (`function` or `=>`) do I need to use in order to make the `this` keyword point at the correct object in an event handler/anonymous function/foreach parameter? 2. I see code with both `!==` and `!=` - what is the significance of using both? 3. Lon…
2. `!==` is strict comparison, and `!=` tries to do incomprehensible magick to munge incomparable types together. I still know some of the rules (array to string sticks in my mind), but I doubt many people know all of them. There's almost never a good reason to use `!=`, outside `elem.value != my_integer`. (Though `NaN !== NaN`, so you need to watch out for that: since equality is defined recursively on objects I'm pretty sure this is infectious.)
3. The length of the chain is easy (though, iirc there are performance implications since it's not lazy). The hard part is the fact that map callbacks can take one, two or three arguments, so stuff like `["123", "456", "10", "1234"].map(parseInt)` will behave unexpectedly. (Something like `[123, undefined, 2, 5]`, though I might be thinking of PHP.) Not sure whether `Array.prototype.filter` has similar gotchas.
That's off the top of my head. I haven't seriously used JavaScript since the ES5 times, but JavaScript's a very… memorable… language. (I can't even remember hello world in Pascal.)
Earlier quoted context omitted.
> *: excluding `for (… of …)` and `for (… in …)` There's more that will trip you up in JS if you leave it for too long. Off the top of my head: 1. Which function definition (`function` or `=>`) do I need to use in order to make the `this` keyword point at the correct object in an event handler/anonymous function/foreach parameter? 2. I see code with both `!==` and `!=` - what is the significance of using both? 3. Lon…
Just always use !==. != will automatically cast and !== won't, therefore "1" != 1 is false and "1" !== 1 is true.