I submit that spending some quality time with vanilla Python can cure most of one's curly brace addiction 😃

Btw I didn't know the Apollo code was done in all assembly. I was hoping at least for some Algol for easier code management. On the second thought, they probably wanted to squeeze maximum performance out of the platform.

    xyz they probably wanted to squeeze maximum performance out of the platform.

    I worked on embedded systems in the 80's/90's. Even then, I had to use assembly language for code that had to run very fast, for example, processing radar data in real time.

    The more time I spend in Python, the more glad I am that Ruby exists. 🙂

    It's been a while since I've done any assembly. Maybe I should pick up a new one, perhaps ATmega328 assembly for Arduinos. That could be interesting.

    I touched python once, but I stuck with bash.
    It's 4 decade old nightmare of outdated, "historically friendly" syntax, but it reminds me of this really old 24 year old cat i met once.
    Even though it's so old it can barely stand, and you're pretty sure if you touch it wrong, it'll snap like a glowstick, you love it anyway.

    I like Python. It's really nice and was the basis for GDScript (though it probably would have been better if they just used Python itself).

    I didn't like Python at first. But it grew on me considerably. Python is hard to beat when it comes to general purpose scripting. I mean the whole package; clean intuitive syntax, powerful idioms, design philosophy at a sweetspot between object oriented and procedural, abundance of libraries ("batteries included"), easily expandable via c for performance critical tasks, excellent c api for integrating into native applications as a scripting language... the list goes on.

    GDScript is basically Python-lite. I'm not sure why they didn't use full-on Python. That'd be awesome. I guess they figured it too heavyweight for the purpose. Someone knows if it was developed from scratch or is it a Python fork?

    @DaveTheCoder I've had some experience with assembly in my formative years. Mostly hobby projects on 8 bit home machines. Programming them in machine code was in fact quite similar to working with embedded systems, as all hardware was accessible directly via address space... I was lucky to have been taught 6502 as a kid by an electronics engineer, then picked Z80 and later 68000 on my own. It was in fact the second computer language I learned after basic, even before delving into C. I think every coder should learn basics of the machine code on the CPU of their choice. Knowing how it all works at the low level will demystify computers for you to a great extent. This fundamental knowledge helps when learning almost any other computer related concept... It aslo makes one immune to digital bullshit and hype in the vein of "agi will kill us all in 5 years" or "level 5 autonomy this time next year" 🙂

      Yeah, I just finished my Computer Science degree last month. Good stuff I learned. There was some x86 assembly code. We even had to compute like 10 steps of a Turing Machine in our head for a test (no writing anything down). Plus a whole class on operating systems, how memory management and cache works (on the CPU mostly and in the OS for page files). It gave me a whole other understanding of computers. Definitely feel like it helped with what I'm doing.

      This is the official reason for making a new language, but I feel like it might just be NIH...
      https://docs.godotengine.org/en/stable/about/faq.html#what-were-the-motivations-behind-creating-gdscript

      xyz and later 68000 on my own

      I had one of the early Macs. There was no assembler for it initially. Using a 68000 programming manual, I used pencil and paper to write assembly code and translate it into hex machine instructions, and patched the instructions into RAM. That had the side effect of making me really familiar with the instruction set, which came in useful at a later job.

      • xyz replied to this.

        I kind of like Julia for its speed, easy C DLL foreign function interface and some interesting language features, but it has something I dislike even more than indent flow control: its arrays start at 1. 🙁
        Oh, and it's white space rules are a bit excessive (not indenting like Python, just where you can/can't put spaces in expressions).

        When I was at college (I mean as a student in the 90's, not my current job of lecturer) one of my subjects was designing a working 4bit cpu from logic gates in a simulator. That was quite fun. We also had a subject where we had to build custom ISA expansion cards for a PC and write the drivers for it.

        xyz GDScript is basically Python-lite. I'm not sure why they didn't use full-on Python.

        There's probably more reasons, but making it multi threadable would probably cause a split in implementation anyways. Defacto forking it.

        xyz Someone knows if it was developed from scratch or is it a Python fork?

        From scratch. Both Python and Lua were considered but found lacking and not ideal. Leading to development of a custom language. Better question is why didn't they consider angelscript or if they did why/how it failed their criteria. I'm guessing because it's compiled and not interpreted or JIT.

        DaveTheCoder I had one of the early Macs. There was no assembler for it initially. Using a 68000 programming manual, I used pencil and paper to write assembly code and translate it into hex, and patched the instructions into RAM. That had the side effect of making me really familiar with the instruction set, which came in useful at a later job.

        Now that's hardcore. Urban legend has it that von Neumann could program in hexadecimal machine code directly off the top of his head. When suggested to build an assembler to make the job easier, he dismissed it as a waste of time. See, fellow kids, you nowadays complain about not having a brace or two. Back in the day we didn't even have assemblers 🥳

        Joking aside...

        Yeah, multithreading is one of Python's weaknesses... or strengths, depending on how you look at it. But for a game engine it's definitely a problem. Other reasons from the official "why custom language" list are also not without merit. When you think about it, a "new" language for a new engine should be made as accessible and easy to pick up as possible. So your best bet is to employ a popular syntax that lots of people are already familiar with. There are really only 2 options: C-like or Python-like. Since C# already is a good C-like readymade option, Python-like is the only reasonable thing left. Using otherwise pure Python syntax with curly braces shoehorned in would just be confusing (and frankly - irritating) for people with previous coding experience. And it can be argued that this is the majority of active and potential users.

        Overall, I think Godot masterminds did the right thing with GDScript, in both - desicision to use a custom language and to make it look like Python . As with most other things in Godot, the solution is well thought out and aptly implemented. So kudos. I still didn't check the new GDScript features and improvements in v4 though.

          xyz Python syntax with curly braces shoehorned in would just be confusing (and frankly - irritating) for people with previous coding experience.

          TBF the curly braces could be implemented as purely optional fluff. OTOH down the line a special purpose for them could be found and then it might be a problem. So if it's just purely fluff it's probably not worth implementing I'd guess.

            Megalomaniak
            Fluff is indeed lethal to a giant project when its still actively developed.
            I'd know : (