Making GDScript a Standalone Programming Language

Now, for example, what does a database management framework with the help of Orm have to do with Godo?

It has to do with Godot if the user is using GDScript, because if they’re using GDScript, they’re using Godot. If they weren’t using Godot, they’d use something other than GDScript.

For Gdscript, it should be something like this, or a library compatible with the Android theme, for the general UI, the example will be similar.

I don’t understand what this means.

I feel that you are taking the issue in a completely different way, just because you are against this idea, the existence of a package manager for each language.

I want to be clear that I’m not against this idea for some personal or religious reason; it just doesn’t make sense to me because GDScript’s whole purpose is to serve Godot and software development using Godot. If you like the way the language is written, you can use Python for non-Godot development, and the vast majority of it will be the same. If you are using Godot, then you can use GDScript or one of many GDExtension-supported languages to benefit from their collection of libraries. GDScript’s reason for existing is to provide a language that’s tailor-made to Godot’s structure and allows quick iteration on Godot programs.

Does the Godot team expect us to use Python for even the simplest books needed for game and software design or to build it from scratch?

You’re probably encouraged to use GDExtension in these cases. Nothing’s stopping you from creating a GDScript library, though.

It’s really weird to need an external API for anything.

It’s not. Python uses external APIs for interfacing with most things. That’s what Python (and other language) packages are: code that has been written which allows that language and its environment to access other services and APIs.

I doubt [Python] could be as good as Gdscript

What specifically in GDScript do you think is superior to Python? Are you sure those are things in GDScript itself, and not in Godot as a whole?

I still feel that Gdscript needs an independent system for development, I mean direct access to it.

Here you go. This is direct access to GDScript’s source code.

In bash and management, Gdscript libraries are really necessary

You’re free to develop them as you see necessary. Again, nothing should be stopping you, unless there is some specific aspect of the OS that GDScript can’t access - in which case, you may want to open a proposal for that level of access to be granted to GDScript/Godot.

GDscript was a mistake, it is a major negative for Godot and you want to expand its footprint. If it helps the development of the godot engine, all good.

But nobody in their right mind would use GDscript unless they have to.

2 Likes

That is actually what I am looking for. A language like GDScript (I fool around with Wren, see https://wren.io), standalone, to embed into C/C++ and in my case into Dart programs. As a proof of concept it would probably be funny, to integrate it via the bean scripting framework into the JVM. But I guess that would be a little bit overkill.

No idea if “stanalone” helps the GDEngine, but as a nice language, I would prefer it over JavaScript any time!

Personally, I have a few ideas. Although I haven’t used GDScript extensively, I assume it’s a relatively simple language, which gives it some educational value—especially in terms of learning how to script for games. Another idea I’m exploring is hot-reloading. I think having an independent interpreter that can be integrated into my own tools would be incredibly helpful for development.

1 Like

It is a full fledged oo language with Python like syntax but (optional?) static typing and some interesting concepts like signals. Basically a high level language with build in Observer Design Pattern. Or call it “call back queues”?