[HN Gopher] Castle Engine - Free open-source cross-platform 3D/2...
___________________________________________________________________
Castle Engine - Free open-source cross-platform 3D/2D game engine
using Pascal
Author : MrBra
Score : 299 points
Date : 2024-02-19 06:03 UTC (16 hours ago)
(HTM) web link (castle-engine.io)
(TXT) w3m dump (castle-engine.io)
| Jean-Papoulos wrote:
| 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.
| nurettin wrote:
| I 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 wrote:
| Possibly 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 wrote:
| Words 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 wrote:
| I see no difference in learning symbols in order to read
| source code _and_ learning alphabet in order to read words
| /sentences.
| spookie wrote:
| Picking up a game engine without prior knowledge and making
| something on your free time, I assume that would be the
| aim.
| darkwater wrote:
| 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.
| mirpa wrote:
| 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 special set of eyes.
| andsoitis wrote:
| 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!');
| logicprog wrote:
| Well if we're doing that, then you wouldn't use the curly
| brackets in the C style syntax example either. If you
| just make one ideomatic without making the other
| ideomatic, the comparison ceases to be fair. Anyway,
| doing that to both of them would make the comparison
| pointless, because the point wasn't to compare
| _ideomatic_ code examples, but to compare the syntax in a
| general case, so writing them slightly unideomatically to
| show off the general-case syntax is fine, as long as both
| are written the same way to control for unrelated
| variables (like special-case syntactic sugar), which is
| precisely what the original comparison did: write both
| code samples in the most general way, and crucially _in
| the same way_ , so we could directly compare the
| scanability of syntax. And imo C won by a mile.
| FpUser wrote:
| you are also allowed: case input of
| 'A'..'C': writeln('blah blah blah'); 'N','n':
| writeln('blah blah'); 'Y','y': writeln('blah');
| else writeln('Input invalid!'); end;
| darkwater wrote:
| TBH? I see them basically the same. My brain probably
| scans equally faster "b...n" and "e..d" then the
| direction of the curly brace. And I haven't read or
| written Pascal since early high-school, ~30 years ago.
| FpUser wrote:
| Your example is not Pascal problem. It is inability of an
| author to come up with clean looking version. One can do
| bad style in any language.
| dennis2354 wrote:
| Great example. Your C-Code translated to Pascal would be
| 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;
|
| Now this does not look any different then your code.
| Except your code _does_ compile _but_ has several errors.
|
| 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!');
| lelanthran wrote:
| > 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 wrote:
| While 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.
| wizzwizz4 wrote:
| 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.
| lelanthran wrote:
| > *: 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. Long chains of `filter` and `map`.
| jameshart wrote:
| Long chains of filter and map are common in any language
| - they may have better chaining syntaxes, but since
| mapreduce can basically implement any collection
| operation you can imagine, filter and map chains are
| going to crop up.
|
| With its tuple, object, and destructuring syntaxes JS
| actually ends up with some of the most readable mapreduce
| code of mainstream C-derived languages (it's soooo much
| worse in Java).
| fzzzy wrote:
| Just always use !==. != will automatically cast and !==
| won't, therefore "1" != 1 is false and "1" !== 1 is true.
| hellcow wrote:
| Unless you're testing if something is null or undefined,
| in which case a single "x != null" handles it.
| fzzzy wrote:
| Sure. I usually just use !x for that.
| wizzwizz4 wrote:
| 1. `function` gives you a new `this`, whereas `=>` closes
| over the `this` from the parent scope. Which to use
| depends on what you want. (Full disclosure: I would've
| had to think for a bit whether the syntax was `->` or
| `=>` - though I'd probably guess `=>` because `->` means
| something in C.)
|
| 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.)
| rlawson wrote:
| Agree! I also find Pascal very soothing to write. Yes it's a
| little more verbose than C but it makes you think ahead and
| stay organized.
| zozbot234 wrote:
| Many people have the same experience writing Rust. And they
| have plenty of time to relax while the program compiles.
| badsectoracula wrote:
| > 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 wrote:
| 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 learning? Using for
| a new project rather than legacy code?
| andsoitis wrote:
| > AFAIK there is a lack of mobile support, so the use case
| for Free Pascal is strongest for cross platform desktop
| apps?
|
| Both iOS and Android are supported by FreePascal as well as
| Delphi.
| graemep wrote:
| Thanks. Good to know.
| pjmlp wrote:
| > Can you expand on Pascal vs Go? What is Go missing?
|
| On the context of classical 1970's Pascal, enumerations
| instead of the const/iota dance.
|
| On the context of Pascal dialects derived from UCSD Pascal
| and Object Pascal, by non specific order, exceptions,
| package naming that isn't tied to source control repos,
| binary distribution of packages, powerfull generics,
| metaclasses, GUI RAD tooling, more investments into
| optimizing compilers (gccgo seems stuck in pre-generics
| Go).
|
| Personally, I came to peace with Go, still hoping to
| const/iota dance to come to an end, some day.
| lelanthran wrote:
| > Can you expand on Pascal vs Go? What is Go missing?
|
| Proper type creation (create a new type for integers less
| than or equal to 12, and greater than or equal to 1, for
| example)
|
| Proper enum/ordinal types (Even C is more strongly typed
| than Go in this instance, because C enums are not _just_
| ints, and you can 't supply an invalid value to a function
| expecting a specific enum).
|
| Both these together demonstrate the much stronger typing in
| Pascal.
| badsectoracula wrote:
| > Can you expand on Pascal vs Go? What is Go missing?
|
| 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.
| sylware wrote:
| Well... at least there is not pascal++ and that's a win for
| sure..
| erfgh wrote:
| > 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 wrote:
| Words can be read as single hieroglyphs, basically, it is
| matter of experience.
| dadie wrote:
| As 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_ wrote:
| Is 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 wrote:
| Noticed 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.
| bitwize wrote:
| Oooh, Pascal. This'll tickle the fancy of some old-school demo
| and game coders. I bet we'll see some unique things emerge from
| this.
| spockz wrote:
| I learned to really program in Delphi, before that it was PHP.
| Pascal and derivatives still hold a special place in my heart.
| I never imagined nee development would be done with it!
| finnjohnsen2 wrote:
| Me too. Delphi 4 was THE BOMB! I loved it so much.
| bbor wrote:
| Ok I've got a hacker challenge for the more creatively-inclined:
| if I wanted to stretch "cross platform" to web (and thus webVR?),
| how might I wrap/integrate/emulate/polyfill/whatever this?
|
| EDIT: after a quick search the answer is a resounding "you can do
| it, but yikes." Multiple people reference _custom compilers_ ,
| which I'm guessing are beyond my reach...
|
| https://news.ycombinator.com/item?id=12029566
|
| EDIT 2: wow nvm it's on their roadmap! Their "why pascal" page
| says it's already supported, but i think thats more hopeful than
| contractual. Coming soon (roadmap):
| Oculus (VR) (we have the hardware to test) WebGL (FPC
| can compile to WebAssembly) XBox (we have the hardware
| to test).
|
| (Love the casual "we own at least one xbox" humble brag. If the
| authors are reading this, that's the only part that I find a tiny
| bit off putting -- a tinge of overeagerness to persuade me / sell
| me.)
|
| https://castle-engine.io/features#_cross_platform
|
| Highly recommend the "Why pascal" page in general, the most
| interesting part of the project to a passerby like me:
|
| https://castle-engine.io/why_pascal
| vintagedave wrote:
| > Love the casual "we own at least one xbox" humble brag.
|
| Maybe it's not a humblebrag, but showing they're taking cross-
| platform seriously. I don't own an Xbox for example, and if I
| worked on something like this, buying one would be for the
| specific reason of making sure the project worked. I'd
| communicate that.
| michaliskambi wrote:
| As for our mention of XBox on https://castle-engine.io/features
| : the point I wanted to say there was that we have
| "development" version of Xbox, as provided by Microsoft. Though
| it doesn't matter much nowadays, since retail Xbox versions can
| also be used for development, from what I read. I edited that
| statement to say this
|
| """ XBox (we have the hardware -- even devkit, though
| "developer mode" can also be activated on a retail version of
| Xbox). """
|
| As for web:
|
| - This is mentioned on https://castle-engine.io/why_pascal as
| supported nicely by FPC compiler. FPC can compile regular
| Pascal code to WebAssembly, there's also Pas2Js that can
| compile regular Pascal code to JS. See samples e.g. here:
| https://github.com/genericptr/Pas2JS-WebGL?tab=readme-ov-fil...
|
| - In the context of Castle Game Engine, web is part of "Coming
| Soon" of https://castle-engine.io/features . We want to utilize
| above to enable to recompile any Castle Game Engine application
| (as long as it uses cross-platform API) to the web. Details are
| on https://castle-engine.io/wp/2023/04/08/web-target-
| progress-a... .
| tommica wrote:
| How fancy, hopefully the project is successful - interesting
| language choice, always have put "Pascal" as an out-of-date
| language, but clearly I was wrong
| baq wrote:
| Turns out Go is mostly Pascal with curly braces and nobody is
| calling Go out of date ;)
| thibaut_barrere wrote:
| I often told people that Go reminded me so obviously of
| TurboPascal (which I dearly used in my childhood) that I felt
| something "warm" when coding with it :-)
|
| I enjoy using it, even though I didn't decide to use it as my
| main stack for various reasons.
| bitwize wrote:
| The engineers behind Go (and Plan 9) really loved Oberon,
| which influenced the UI of Plan 9 and Acme, and the developer
| ergonomics of Go.
| ramon156 wrote:
| Out of date is more than just syntax
| moffkalast wrote:
| As of this moment, I'll start calling Go out of date :D
|
| I mean it doesn't even have generics or exceptions, get with
| the times.
| LispSporks22 wrote:
| I have a feeling those pascal developers are getting stuff done
| super productively.
| bbor wrote:
| Object Pascal is a modern programming language. It supports
| classes, units, properties, generics, interfaces, reflection,
| closures... Everything you expect from a modern OOP language.
|
| :shrug:
| wolvesechoes wrote:
| This is what amazes me.
|
| If you go through the available Delphi/FPC libraries, you will
| find basically anything. From CAD drawing widgets to frameworks
| for building SCADA systems. Most are not present on GitHub, and
| if they are, don't have hundreds of stars.
|
| On the other hand I have an impression that in more popular
| languages like Rust - which I use for my projects, I admit -
| most projects fall into "grep for the 1000th time, but this
| time made right".
| timw4mail wrote:
| Except most of that stuff in Free Pascal doesn't really have
| documentation.
| CarRamrod wrote:
| I've never commited to going deep on a project in Pascal. Seems a
| bit too high-pressure for me.
| incanus77 wrote:
| The trick is to take it a millimeter at a time.
| fuzztester wrote:
| A millipascal at a time.
| d--b wrote:
| Sorry to explain the joke, but pretty sure he was refering
| to milimeters of mercury => another pressure unit.
| coderedart wrote:
| Ty. I could feel that there was a joke in there
| somewhere, but didn't remember the mercury pressure thing
| zem wrote:
| that should be no bar to using it
| DeathArrow wrote:
| After learning Basic at home, once I went to high school, Pascal
| was the first "serious" programming language I've learned.
|
| But since I discovered C a year or two later, I never looked back
| to Pascal. C felt more "pro", more flexible and seemed closer to
| metal. Pascal seemed more appropriate for developing GUI apps,
| while C seemed able to tackle anything, from the most intricate
| guts of the operating system, to drivers, games and GUI apps. Of
| course, that was silly, because Pascal was able to do everything
| that C did, but to my younger self it seemed less "serious" and
| "pro".
| SantiagoElf wrote:
| Similar experience.
|
| Around '96-97 I was playing with writing fire effects in Turbo
| Pascal, most of the tutorials used the asm with mode 13h, and
| all I had was Turbo Pascal 5.5, which didn't support the asm
| keyword. So, I dabbled a bit with it, and then in late 97, I
| found about C, and when I saw the for loop in C - I never
| touched Pascal again.
| vr46 wrote:
| At the very bottom of things I expected to see this week,
| amazing. Worth playing with on sheer chutzpah, hats off to
| everyone involved.
|
| I don't know a thing about Pascal, though, why would anyone still
| be using it? Is it good?
| tsukurimashou wrote:
| Hah pascal, the first language I learned to script some game
| named Soldat when I was a kid, fun times
| thesnide wrote:
| Soldat was actually the first shareware I bought, as I totally
| didn't have to, yet I sunk so many hours in it.
|
| Without doing much progress skill wise :-D
| tsukurimashou wrote:
| haha me too! I sent a bank cheque to MM when I was 12 because
| I wanted to support the guy (and I was so glad that this game
| existed because I had a toaster and couldn't play any of the
| "modern" 3D games at the time)
| thesnide wrote:
| MM even opensourced it https://github.com/soldat/soldat
| shoozza wrote:
| In the meantime the repository moved to:
| https://github.com/opensoldat/opensoldat After MM sold
| the game to someone else I felt like it would be better
| to make sure the name is different as the new owner had
| different plans and did not want to continue releasing
| the source code.
|
| Later someone unknown hijacked the original url and
| copied an outdated version of the repository (you can see
| the mention of OpenSoldat.)
| shoozza wrote:
| FYI Soldat used/uses PascalScript and had no classes in the
| beginning (they where added later to the ScriptCore.)
|
| It's still around. The FLOSS version is called OpenSoldat now
| (I plan to get it back on track eventually as it became
| unstable with Version 1.8).
|
| Really enjoyed the quick compile times :)
| dang wrote:
| Related:
|
| _Why use Pascal?_ -
| https://news.ycombinator.com/item?id=36646890 - July 2023 (307
| comments)
|
| _Modern Object Pascal Introduction for Programmers_ -
| https://news.ycombinator.com/item?id=36371434 - June 2023 (3
| comments)
|
| _Castle Game Engine Roadmap_ -
| https://news.ycombinator.com/item?id=36365420 - June 2023 (10
| comments)
|
| _Modern Object Pascal Introduction for Programmers_ -
| https://news.ycombinator.com/item?id=28079093 - Aug 2021 (3
| comments)
|
| _Castle Game Engine: Cross-platform 3D and 2D game engine_ -
| https://news.ycombinator.com/item?id=23741883 - July 2020 (20
| comments)
|
| _Castle Game Engine 6.4 released - physics, iOS services, shader
| pipeline upgrade_ - https://news.ycombinator.com/item?id=16207075
| - Jan 2018 (2 comments)
| masfoobar wrote:
| Cannot remember the last time I used a programming language in
| the Pascal family. Our programming course we had to use Delphi.
| This was college back in 2001. I purchased a copy of Delphi 5 (my
| college has version 4) so likely tried things for a year or two
| afterwards. I doubt I touched Delphi after 2005.
|
| In College we had to create a Stock Control program. It was an IT
| course so most people struggled as programming was not their
| direction. For me being a "prodigy programmer" had no issues
| jumping into Delphi.
|
| If anything, knew little about Delphi. Once I started coding and
| realised I was typing var, begin, end, or := (etc) -- I knew it
| was some kind of Pascal. Going back to my earlier days in high
| school, I had a copy of Turbo C and Turbo Pascal so thats why I
| had a little head start.
|
| I remember the difficult part was storing the stock data in a
| binary file, using binary search to find data, etc. My tutor was
| old-school so I wouldn't be suprised if Delphi had more 'out of
| the box' solutions which we take for granted in modern Go, C#,
| etc.
|
| Everyone struggled to get their code to build. Brings back fond
| memories.
|
| Today I place Pascal in the same Category as Basic. Seems like an
| interesting project but I just dont have interet using Pascal so
| would be a deal breaker for me.
|
| I would not be surprised, however, if there is still a pretty
| large base of Pascal defenders out there. More power to them if
| the case.
| optymizer wrote:
| We're probably in the same age group. I used to write simple
| games and graphics apps in Turbo Pascal in high school. Later
| on I used Delphi to write "business apps". To me, there isn't
| that much difference between Pascal and C in terms of language
| design.
|
| I used to translate my Pascal code to C by replacing begin/end
| with curly braces, moving interface declarations to header
| files, replacing well named functions to cryptic-sounding
| strtok calls, etc. It was all so unnecessarily ugly in
| comparison.
|
| C is my favorite language now, but the cleanliness of Pascal
| and the user friendliness of Delphi have stuck with me as
| reminders of how great a developer experience can be.
|
| I've been using Android Studio for 10 years now and the
| experience doesn't hold a candle to Borland Delphi Architect
| from 20 years ago. We might have more advanced features these
| days, but it's a disconnected mess in comparison.
| vfclists wrote:
| > Seems like an interesting project but I just dont have
| interet using Pascal so would be a deal breaker for me.
|
| What are the languages you would prefer to use now?
| dkersten wrote:
| 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 any Pascal. The engine looks cool though!
| vfclists wrote:
| 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.
| jlarocco wrote:
| Have to agree with the OP here.
|
| 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.
| thesnide wrote:
| I'll have to try it, if only to honor Wirth.
|
| And mostly to see if those fond memories of learning to code with
| Turbo Pascal survived the test of time...
| lelanthran wrote:
| Probably, IME.
|
| https://news.ycombinator.com/item?id=39427811
| omgmajk wrote:
| Most comments in this thread reminds me of the discussion we had
| under a discussion about Fortran recently, here's the comment
| thread regarding Pascal
| https://news.ycombinator.com/item?id=38966342
| malkia wrote:
| Pascal (Turbo/Borland) was the most most fun I had programming
| back then. The "Unit" of compiliation just worked (and yes it
| allowed only DAG-like dependency hierarchies). It was super fast
| to compile and use, but also to edit/debug.
|
| 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...
| alanlammiman wrote:
| castle is not a good choice of name though as castle dot xyz is
| somewhat of a game engine too
___________________________________________________________________
(page generated 2024-02-19 23:01 UTC)