cybereality No, I don't like the more verbose-y parts like Public, Private etc, The indents look good when you have small amounts of code but not if you have a lot and have mental pressure from debugging.
Let's compare:

public partial class CharacterBody2D : Godot.CharacterBody2D
{
	public const float Speed = 300.0f;
	public const float JumpVelocity = -400.0f;

	// Get the gravity from the project settings to be synced with RigidBody nodes.
	public float gravity = ProjectSettings.GetSetting("physics/2d/default_gravity").AsSingle();

	public override void _PhysicsProcess(double delta)
	{
		Vector2 velocity = Velocity;

		// Add the gravity.
		if (!IsOnFloor())
			velocity.Y += gravity * (float)delta;

		// Handle Jump.
		if (Input.IsActionJustPressed("ui_accept") && IsOnFloor())
			velocity.Y = JumpVelocity;

		// Get the input direction and handle the movement/deceleration.
		// As good practice, you should replace UI actions with custom gameplay actions.
		Vector2 direction = Input.GetVector("ui_left", "ui_right", "ui_up", "ui_down");
		if (direction != Vector2.Zero)
		{
			velocity.X = direction.X * Speed;
		}
		else
		{
			velocity.X = Mathf.MoveToward(Velocity.X, 0, Speed);
		}

		Velocity = velocity;
		MoveAndSlide();
	}
}
extends CharacterBody2D


const SPEED = 300.0
const JUMP_VELOCITY = -400.0

# Get the gravity from the project settings to be synced with RigidBody nodes.
var gravity = ProjectSettings.get_setting("physics/2d/default_gravity")


func _physics_process(delta):
	# Add the gravity.
	if not is_on_floor():
		velocity.y += gravity * delta

	# Handle Jump.
	if Input.is_action_just_pressed("ui_accept") and is_on_floor():
		velocity.y = JUMP_VELOCITY

	# Get the input direction and handle the movement/deceleration.
	# As good practice, you should replace UI actions with custom gameplay actions.
	var direction = Input.get_axis("ui_left", "ui_right")
	if direction:
		velocity.x = direction * SPEED
	else:
		velocity.x = move_toward(velocity.x, 0, SPEED)

	move_and_slide()
extends CharacterBody2D


const SPEED = 300.0
const JUMP_VELOCITY = -400.0

# Get the gravity from the project settings to be synced with RigidBody nodes.
var gravity = ProjectSettings.get_setting("physics/2d/default_gravity")


func _physics_process(delta) {
	# Add the gravity.
	if not is_on_floor() {
		velocity.y += gravity * delta
	}
	
	# Handle Jump.
	if Input.is_action_just_pressed("ui_accept") and is_on_floor() {
		velocity.y = JUMP_VELOCITY
	}

	# Get the input direction and handle the movement/deceleration.
	# As good practice, you should replace UI actions with custom gameplay actions.
	var direction = Input.get_axis("ui_left", "ui_right")
	if direction {
		velocity.x = direction * SPEED
	}
	else {
		velocity.x = move_toward(velocity.x, 0, SPEED)
	}

	move_and_slide()
}

Focus in the middle of the code and at the top then. In GDScript you get lost. In C# and my version (last) you don't, If you look at the above with all the variables, you get lost in the public mess for C# but not in GD and mine. I want JavaScript style code. I have had no problems with that in readability.

GDScript looks 100% better and easier to read to me. I don't know, you might just have to get used to it.

If you want to pursue this, there are two ways:

  1. Submit a proposal:
    https://github.com/godotengine/godot-proposals

  2. Implement it yourself, and submit a PR (pull request):
    https://github.com/godotengine/godot/pulls

Personally, I don't think the idea will get far. Most of my programming experience is with languages that use braces (e.g. Pascal, C, C++, C#, Perl, PHP) and I have no objection to that approach, but GDScript is different and most users like that.

5 days later

I've got an alternative solution.
Learn some BASH scripting and regular expressions.
I can't say I have ever complained about syntax ever since I realized even this isn't verbose enough for a lot of cases when all you want is to parse an email address in a little bash script.

"^[A-Za-z0-9](([a-zA-Z0-9,=\.!\-#|\$%\^&\*\+/\?_`\{\}~]+)*)@(?:[0-9a-zA-Z-]+\.)+[a-zA-Z]{2,9}$"

For real though, brackets look cool. I'd be down to see it as an option.

    packrat I've got an alternative solution.
    Learn some BASH scripting and regular expressions.
    I can't say I have ever complained about syntax ever since I realized even this isn't verbose enough for a lot of cases when all you want is to parse an email address in a little bash script.

    That actually reminds me, someone ages ago did make a tutorial for creating your own scripting language for godot 2.x.

    Didn't find the one I was thinking of with a quick search but did come across one for godot 3.x:

    Audio quality is a bit lacking tho.

      Megalomaniak You know I've been thinking of doing something like that for a while, but I haven't had time (or energy) to do that kind of thing. The classic education time hog has claimed me too, and it's a really a crying shame.

      Since we're just about to enter the twilight zone here 🙂 I'm trying to imagine how might it work the other way around - a c++ or java variant that uses strictly whitespace for code blocks. Now that would be... something! X-)

        xyz I nearly stickied my keyboard with a mocha.
        I've never touched java in my life, but I have touched C++. I have also touched the Bible. I'm not an expert on either, but I'm pretty sure somewhere in there was something along the lines of "thou shalt not whitespace C and two fold plus".

        The thing is, if you want to be a successful programmer, you have to be flexible. Meaning, learning new APIs, new languages, new IDEs and software, etc.

        I have probably programmed in 20 languages at least, and I can pick up a new language in like 2 days. It's important to learn the tools and not assume everything will be the same or what you are used to.

        The language daScript supports both styles (although you can't mix them within a function).

        White space based flow control has always turned me off of languages. I'm fine with brace based (like C++) or keyword based (like Lua) blocks.

          Kojack White space based flow control has always turned me off of languages.

          I think it forces people to avoid the "I wrote a whole operating system in 1 line of code!!!!!!!!!!!".

          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.