[4.0] Encourage static typing now that it has a performance impact

[ynot01]

Your Godot version: 4.0 Beta 2

Issue description: Static typing is still listed as completely "optional feature of GDScript" despite it having performant effect in 4.0 and it is said to avoid using static typing entirely in docs to not confuse users.

URL to the documentation page (if already existing): https://docs.godotengine.org/en/latest/community/contributing/docs_writing_guidelines.html#dynamic-vs-static-typing

[Calinou]

I'll let @NathanLovato weigh in, but one of the reasons we don't use static typing in the docs and demo projects is indeed to avoid confusing beginners.

I'm not sure if this status quo has changed for 4.0. I'd say that we should add type hints (also to demo projects). More and more languages are adopting type hints, and statically typed languages are becoming popular again. In fact, fully dynamic languages with no type hinting options are on the decline if anything (Lua, vanilla JavaScript, …).

[NathanLovato]

I recommend using static types for teaching purposes.

The performance impact would be the last reason for my team to recommend using static types in the docs, although I think this would be one of the most effective arguments for the community to accept and embrace static types. Because people have ideas about performance, especially developers who aren't so experienced. They want to use the features that maximize it.

---

Our experience teaching absolute beginners at GDQuest taught us that strong typing helps beginners understand types. It's the opposite of what you'd naturally assume.

I would now argue that dynamic languages are best for people who studied code for at least a semester. That's because:

1. Dynamic code doesn't help you practice your understanding of the types behind your values. Yet every value has a type and this type allows and disallows certain things in your code.
2. You don't get feedback on what you've done wrong in your code as you type it. You get fewer errors, and you get them late. Errors are an essential feedback mechanism and learning tool.

But students need to be properly introduced to type hints. The assumption that type hints are confusing is correct... if you drop beginners in code that has type hints without prior introduction or explanations! This issue shows that beginners actually don't understand value types.

And that's been a major point underlying beginner support requests over the years: people try to use functions that aren't available on a type, add incompatible values, and often have no idea of what their code is doing.

I've done a couple of things over the years and taught dynamic only, then static only, and now what we do is we start with dynamic for the absolute basics (learning syntax and features like variables, functions, loops...) and introduce static types as soon as we can. This is done in the app learn GDScript, where the last two lessons are dedicated to types.

And it's worked very well for our students. We answer close to 10 support requests per day, and we've had few that involved type-related mistakes. A couple of chapters into our latest course, people are pretty comfortable with them.

That's what I can say about using static types for teaching purposes. The general arguments against that are valid:

1. Static types look more intimidating to beginners. I think explaining their benefits well and early addresses that, but people need to get to the explanation.
2. Dynamic feels simpler. That's a little less cognitive load getting started. That's why we start our GDScript course with dynamic code.
3. For more experienced users, it can be their comfort zone. Especially if they only used languages like Python or JavaScript.

An issue you'll face if you try to make the changes is that many people are used to languages like Python and JavaScript, and they can be very attached to the syntax they know. The main objection I'd expect from users will be something like the usual "it looks horrible" or "it's more typing."

Funnily, we don't get these objections with actual beginners. We've gotten these objections mostly from experienced users and developers.

Let me know if you have any more questions.

[Mickeon]

I personally agree wholeheartedly. Please open a Proposal to share with the community at large.

[ynot01]

I personally agree wholeheartedly. Please open a Proposal to share with the community at large.

I considered but it appeared that godot-proposals were specifically geared towards engine issues, so I opted to post here. If someone else wants to post this proposal in what they believe is the appropriate medium to gain the most traction, I have no quarrel with it, as long as someone posts it here to I get to watch :)

[Mickeon]

I find what @NathanLovato wrote to be almost a perfect fit for a proper set of Proposals. All it misses is points that tackle how to solve the issue it presents. Actual nicely written solutions, beyond "Document implicitly static typing more often in the documentation", "Optimise variants when they're not allowed to change type" "Add optional warnings when the type of a Variant changes"...

Of course, I am not one to decide what is and isn't supposed to be a Proposal, but at worst, if too vague, it will just be moved to the Discussions, which would have less "traction" than a Proposal, but it'd still be a shared sentiment, that may or may not be something worth developing on.

[NathanLovato]

I could make a complete proposal if enough people want that. But I wouldn't want to fight over it.

I've seen a bunch of proposals lately where people come with strong positions and stand by them without asking questions or even trying to understand the OP's perspective. I would expect this one to trigger these kinds of responses. People can use rhetorics a little too much, techniques that help close the discussion without it being too apparent.

In the past years, people have been relatively against the idea of using type hints in official learning resources. The main arguments, as far as I know, were that dynamic code looks more accessible and that GDScript has primarily been a dynamic language.

As for how to add type hints and help people understand them, that's not a problem: there are already lots of types in the docs (every mention of Vector2 or a node is mentioning a type). Besides adding the type hints to code listings, you just need to add a couple of extra sentences when people are likely to get confused by the types. Especially in beginner-level material like the getting started series.

[cbscribe]

A couple of thoughts:

• Does it really have a performance impact? Is "Dodge the Creeps" running slow without type hints? GDScript performance is a red herring - if you're actually encountering performance issues because you're running some O(n^2) nested loops, static typing isn't going to save you. Whatever the arguments for or against static typing, I don't think performance is one that matters.

• The examples in the docs are there to demonstrate a minimum working example of the code required to accomplish the given task. If you're looking at those and you prefer type hints, you probably have enabled "Add Type Hints" and the -> void is going to be added for you anyway, regardless of whether it was in the docs.

• The editor currently defaults "Add Type Hints" to false. If we change the default for the docs, it feels like that would have to change as well for consistency.

• Yes, I'm one of those who think it looks ugly.

Ultimately, my main objection to this is my continuing desire to keep GDScript from losing what makes it GDScript. The language is one of the major selling points of the engine, and the fact that so many use it over C# (even though so many predicted C# was going to dominate) shows how effective and productive it is to use. What I fear is that we are setting foot on the slippery slope of well-intentioned "improvements" that leave us with something that no longer resembles the thing that we loved in the first place. Dynamic languages have a place - they don't all need to be changed just because they become popular, even though that seems to be the trend we see again and again.

This is one of those times that I sure wish we had some kind of telemetry, but I'll go ahead and add my anecdotal observations to the pot: I spend a lot of time with the community on Discord and Q&A and I can definitely state that I see significantly more dynamic GDScript than static.

/

[NathanLovato]

Just a note: this issue is about encouraging the use of static type hints. We haven't talked about changing absolutely everything. Last time I did serious work on the docs (late 2021), the docs didn't even explain typing well, the pros and cons, or showed examples of it.

My understanding is that this discussion isn't about changing everything. As I've mentioned above, I'm in favor of using them for teaching purposes. There's part of the docs that people use to learn programming. I'm personally thinking of this part, not necessarily having types everywhere.

We have types everywhere at GDQuest, and we have our reasons, but I'm not necessarily for making GDScript or all learning resources strongly typed. And it's not about taste either: I don't love dynamic or typed languages. I see clear benefits in strong typing and the ideal feature set for me is when the language assists me as much as possible with types (inference by default, excellent linting nearly in real-time... the looks of dynamic code whenever possible, but I can peek at the types and get all the info I need with my IDE).

Anyway, before going further in for/against the thing, we should probably define precisely what the suggested changes are about.

My proposal would be to use them for teaching the basics, and if it impacts the UX too negatively, having dynamic by default and a code tab with typed examples. Just like the editor lets you optionally use type hints, so could the docs. That would help raise awareness about the fact that GDScript supports strong typing too.

Note: if you check our app Learn GDScript, it's first 26 lessons with dynamic code, and only the last two introduce types and type hints. We've now taught a good number of programming neophytes with and without types, and I find that teaching types early really helped improve their understanding of their code.

I see significantly more dynamic GDScript than static.

It's completely normal to see more dynamic than static when the vast majority of learning resources teach that. Aside from GDQuest, I don't know too many persons who ever show type hints. Our students tend to use type hints more than the rest of the community as we teach them that.

It's important to note how much we shape what users do as teachers and, in part, influencers (in the sense that we influence Godot users through our content).

It's also natural that people use GDScript more when it's the language that gets the vast majority of learning resources and has much better integration and stability than C#.

If there are really even just 20% of Godot users using C# right now (I don't think polls are accurate at all), it's already crazy to me. It seems that a substantial number of people chose to use C# despite all the cons in Godot.

I would say that maybe if we had tight integration of Python or JavaScript, people would flock to that, even if the languages were less productive and adapted than something fine-tuned to Godot like GDScript.

I agree that having analytics would be great in any case, and also doing more UX. We try to do that qualitatively, but we lack data to make more educated decisions. We're often shooting in the dark.

The above is still important because analytics don't tell you how people would behave if the situation was different.

keep GDScript from losing what makes it GDScript

It's a gradual language. At least in Godot 4, it's not just a dynamic language anymore, and that's great because, from a pure programming standpoint, there are clear tradeoffs between dynamic and static. And in Godot, you can get the best of both worlds.

I think that it is now part of the language's identity. In Godot 4, GDScript is getting perhaps a little more complex and feature-full, just like the engine.

Yes, I'm one of those who think it looks ugly.

I would really like the conversation not to be too tainted by that. I think it's going to be the main actual objection, how attached people are to certain aesthetics.

The thing is, when you teach actual neophytes, they really don't care. At GDQuest, we do everything with static hints. This hasn't hindered our growth or sales that I know of.

Actually, our students don't complain about the hints. And we ask our students lots of things directly as we have to sell to keep going, I'm paying a team, marketing is very important, and we have to think carefully about looks, individual preferences, and all the objections that our students might have.

The people telling it's ugly or they hate type hints tend to be persons who don't understand types and related tradeoffs (they just see it as unnecessary, and rightly so, because generally, nobody showed them it can make a difference and it's not just for fun) or professionals who work with dynamic languages.

Now, I really hope we can focus the discussion on user experience and learning and leave love and taste aside because this just taints arguments and it's going to prevent consensus.

Importantly, introducing type hints doesn't have to be all or nothing.

Again, I would suggest either making them optional to raise awareness about the feature (fairly big scope, but perhaps we could help some), or using them in some part of the getting started course to help beginners who learn to code with Godot better understand what the code does and how it works.

I don't mind if people don't want more than a couple of guides appended at the end and leaving everything else untouched, but I still think it'd be beneficial for users learning to code with Godot, based on our exp. teaching code beginners without and with types.

[ElectricGrizzly]

Seems like this issue hasn't had much action in a while, apologies for raising this from the dead.

I personally really enjoy utilizing the static typing features of GDScript for a couple main reasons.

1. It helps catch certain issues early during development.
2. Personally, I find static typing generally offloads some of the brain space required during debugging. I can simply look at an objects type in the code and be sure it is for sure the specified type -- especially when the line has been marked type-safe, and not have to read the code thinking "x is of this type, which down here gets cast to y of x"... for example.

However, I think the inclusion of static typing within the Godot documentation is inherently a stylistic choice, and opinions and reasons behind those opinions will vary wildly.

This is why I have a suggestion... maybe a proposal?

Similar to how within much of the code documentation there are GDScript and C# tabs, I think it would be worth it to add a GDScript (Typed) or similar tab -- exact name to be decided. This would give a reader the ability to choose whatever option they see fit.

This solution would provide a perfect middle ground. It's leaves the choice of which to view up to the reader, and defaults to the tried and true dynamically typed GDScript. New users of Godot can choose to start their Godot journey supported by whatever language -- or language feature, that they wish. For experienced Godot developers -- perhaps experienced developers in general, this change would have virtually no impact. In my experience, more seasoned developers are able to look at code examples in just about any language and map that to the language they are using at the time.

Would love to hear thoughts on this!

[tetrapod00]

I'm not opposed to the idea of having both typed and untyped examples in the docs per se, but I don't think we have enough contributors to support it. It's one more thing to keep updated across all the examples in the docs.

For context, there has been occasional discussion of migrating all examples to use typed code. I suppose it is the same amount of work to either translate all the existing untyped examples, or add equivalent typed examples to all existing examples. However, I'm wary of making a choice that adds extra maintenance to all future updates to all future code examples.