return to table of content

Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal

Jean-Papoulos
43 replies
6d11h

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.

lelanthran
14 replies
6d8h

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.

wizzwizz4
8 replies
6d7h

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
7 replies
6d6h

*: 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`.

fzzzy
3 replies
6d5h

Just always use !==. != will automatically cast and !== won't, therefore "1" != 1 is false and "1" !== 1 is true.

hellcow
2 replies
6d4h

Unless you’re testing if something is null or undefined, in which case a single “x != null” handles it.

fzzzy
1 replies
6d2h

Sure. I usually just use !x for that.

SamBam
0 replies
5d2h

That doesn't test if it's null or undefined, that just tests if it's not falsy.

x = 0; !x → true

y = ""; !y → true

z = null; !z → true

wizzwizz4
0 replies
5d23h

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.)

jameshart
0 replies
6d5h

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).

Jean-Papoulos
0 replies
5d3h

I just tried make a ".any" generic function for arrays, and by god :

Most languages : myArray.any((e) => true);

Delphi : AClass.any<Type>(myArray, function (e) : Boolean begin Exit(True); end);

The readability is through the roof, lol.

rlawson
2 replies
6d5h

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
1 replies
6d4h

Many people have the same experience writing Rust. And they have plenty of time to relax while the program compiles.

tux3
1 replies
6d8h

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.

archargelod
0 replies
5d16h

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.

vintagedave
12 replies
6d9h

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
11 replies
6d8h

I see no difference in learning symbols in order to read source code and learning alphabet in order to read words/sentences.

darkwater
8 replies
6d7h

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
7 replies
6d5h

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
2 replies
6d5h

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
0 replies
6d3h

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
0 replies
6d2h

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;

vrruiz
0 replies
5d14h

Well, other simpler options are:

  if (input in ['Y', 'y']) then
    WriteLn('blah blah')
  else if (input in ['N', 'n']) then
    WriteLn('blah')
  else
    WriteLn('Input invalid');
And:

  if (LowerCase(input) = 'y') then
    WriteLn('blah blah')
  else if (LowerCase(input) = 'n') then
    WriteLn('blah')
  else
    WriteLn('Input invalid');

dennis2354
0 replies
6d1h

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!');

darkwater
0 replies
6d2h

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
0 replies
6d2h

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.

tmcdos
0 replies
5d5h

This 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
0 replies
6d7h

Picking up a game engine without prior knowledge and making something on your free time, I assume that would be the aim.

badsectoracula
6 replies
6d7h

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
5 replies
6d5h

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
1 replies
6d4h

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
0 replies
6d2h

Thanks. Good to know.

pjmlp
0 replies
6d4h

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
0 replies
6d4h

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
0 replies
6d

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.

thesz
0 replies
6d4h

Words can be read as single hieroglyphs, basically, it is matter of experience.

sylware
0 replies
6d6h

Well... at least there is not pascal++ and that's a win for sure..

nurettin
0 replies
6d9h

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.

musicale
0 replies
5d20h

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.

erfgh
0 replies
6d5h

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.

dazzawazza
0 replies
6d9h

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.

dadie
0 replies
6d2h

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_
0 replies
6d

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.

tsukurimashou
6 replies
6d9h

Hah pascal, the first language I learned to script some game named Soldat when I was a kid, fun times

thesnide
4 replies
6d8h

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
3 replies
6d5h

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)

shoozza
1 replies
5d20h

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.)

thesnide
0 replies
1d20h

Thx i didnt know that. Was actually wondering about why 2.

shoozza
0 replies
5d20h

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 :)

CarRamrod
6 replies
6d10h

I've never commited to going deep on a project in Pascal. Seems a bit too high-pressure for me.

incanus77
3 replies
6d10h

The trick is to take it a millimeter at a time.

fuzztester
2 replies
6d9h

A millipascal at a time.

d--b
1 replies
6d9h

Sorry to explain the joke, but pretty sure he was refering to milimeters of mercury => another pressure unit.

coderedart
0 replies
6d9h

Ty. I could feel that there was a joke in there somewhere, but didn't remember the mercury pressure thing

zem
1 replies
6d8h

that should be no bar to using it

fuzztester
0 replies
5d18h

You're giving me high blood pressure.

A pascal walked into a bar.

tommica
5 replies
6d10h

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
4 replies
6d10h

Turns out Go is mostly Pascal with curly braces and nobody is calling Go out of date ;)

thibaut_barrere
0 replies
6d10h

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.

ramon156
0 replies
6d9h

Out of date is more than just syntax

moffkalast
0 replies
6d5h

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.

bitwize
0 replies
6d10h

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.

dkersten
5 replies
6d8h

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
4 replies
6d8h

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
2 replies
6d

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.

vfclists
1 replies
5d17h

And what happens when these castle_xx files have to be combined with files from other libraries?

This goes a long way into avoid namespace conflicts.

dkersten
0 replies
3d9h

Do they need that? If not you’re using a hypothetical situation that likely will never occur to excuse a bad decision (see YAGNI). In my 24 years of programming, I’ve never needed to do this in any way where this naming would have helped me (a very occasional single prefixed file sure, but an entire project, never).

dkersten
0 replies
3d9h

But if you open the source directory, “every” file is a castle file.

I already know which files are castle files because they’re in the castle directory. It’s redundant information and it makes it hard to browse the files, eg I now need to scroll my file browser in my IDE to the right (so can no longer see directory names), Dane for tab labels snd file path breadcrumbs (on GitHub and in IDE), and on GitHub at least on mobile which is how I viewed it, it cuts the filename off after a certain length.

So I disagree that it’s a meaningless nitpick, it directly affects how easily I can navigate and read the file names. Just because yacc does it too doesn’t make it good (but at least in yacc’s case it’s not redundant information to know they are generated files, unless you put them in a yacc directory)

masfoobar
4 replies
6d8h

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.

vfclists
1 replies
6d4h

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?

masfoobar
0 replies
5d7h

Hi.

As mentioned, I have not touched Pascal/Delphi for around 20 years now. I dont have interest (re)learning this to use a 3D engine.

My reasoning is mostly due to popularity or, more specifically, job security.

Newer languages preferably, or keeping it C (atleast)

As mentioned in another reply above - I am learning Odin at the moment.

These are just my views. Like any view, can be scrutinised by anyone. We all have our preferences. I mean no ill towards Pascal in general.

optymizer
1 replies
6d4h

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.

masfoobar
0 replies
5d7h

I find "modern" development to be bloat. By modern I refer to web development as smart device (ie Android, IOS, etc)

I will always have a soft spot for C but try to find the right replacemenet.

Looking at Odin at the moment which I do like. It is taking inspiration from a number of languages, include C and Pascal.

bbor
4 replies
6d11h

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
1 replies
6d9h

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.

bbor
0 replies
5d15h

I guess my observation was more along the lines of “they’re game devs, they almost definitely have at least a few Xboxes between them”. But of course a matter of rhetorical taste, and I think you’re in the majority

michaliskambi
1 replies
6d5h

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... .

bbor
0 replies
5d15h

Thanks for the detailed response! That sounds amazing. I’ll try to keep track of this to eventually try it out, I’ve been chafing at the bounds of Three.js and I think the whole web game ecosystem could use a method/tool infusion from mainstream game development.

And gotcha on the Xboxes, sorry if that was rude - clearly HN thought it was! I had no idea that there were special developer Xboxes. And in general was expecting a much less organized operation lol, you seem very on top of your game

LispSporks22
3 replies
6d10h

I have a feeling those pascal developers are getting stuff done super productively.

wolvesechoes
1 replies
6d8h

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
0 replies
5d19h

Except most of that stuff in Free Pascal doesn't really have documentation.

bbor
0 replies
6d10h

  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:

bitwize
2 replies
6d11h

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
1 replies
6d10h

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
0 replies
6d8h

Me too. Delphi 4 was THE BOMB! I loved it so much.

thesnide
1 replies
6d8h

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...

DeathArrow
1 replies
6d9h

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
0 replies
6d8h

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.

zoom6628
0 replies
5d17h

I like pascal - learnt it in second year if tertiary and used off and on for a while. In my opinion as a bad developer and less-bad product manager FPC is the embodiment of duct-tape programming [1] is only that and c# in which I have seen that ethos in developers.

[1] https://www.joelonsoftware.com/2009/09/23/the-duct-tape-prog...

vr46
0 replies
6d9h

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?

sylware
0 replies
5d18h

And it is a proof than grotesquely complex c++ oo is more than useless for a 3D engine. Namespaces using the preprocessor should be enough, if you need more, you are the problem.

omgmajk
0 replies
6d4h

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
0 replies
5d23h

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...

dang
0 replies
6d8h

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)

alanlammiman
0 replies
5d22h

castle is not a good choice of name though as castle dot xyz is somewhat of a game engine too

Fischgericht
0 replies
5d16h

It's really a pity how badly the Delphi product was managed by Borland/Embarcadero.

Object Pascal is a great language. These days it produces native code for pretty much all platforms out there. The binaries created are tiny, and the speed is high - close to what C will give you - meaning that typically the code will run between 100 to 10000 times faster than comparable Python code.

When it comes to Castle Engine, it's a gigantic project, making it extremely easy to create games and 3D applications in a RAD kind of way. And unlike other huge Pascal frameworks, it's not a legacy product, but very actively developed. I have HUGE respect for the developers.

A comparable gigantic impressive project is Mormot, and ORM/SOA/MVC framework which is based on extremely optimized code.

Building a Server application with Object Pascal and Mormot is easy to do, and where using NodeJS might be able to handle 500 requests per second, with pascal code you will be in the areas of 10000+.

And this means that while with other languages you might need to run dozens of servers to handle the load, your Object Pascal based server code instead would easily run on a single server. So, using that language can give you massive cost savings.

A lot of people only remember Object Pascal as a teaching language. But the language has evolved, and still has features other languages are lacking, most importantly RTTI (aka reflection). There is only one area where the language isn't up to date, and that is having Multithreading/coroutines integrated into the language itself like it's done in Go.

And finally: I can still compile and run code I have written 40 (!) years ago. Within those 40 years tons of languages have come and gone out of fashion. Pascal is still here.

Back to Castle Engine: Even if you are not familiar with the Object Pascal language, I can highly recommend to try out their visual editor. It's just amazing.