Re: Re: [tsc-devel] Rewrite: Programming language

Marvin Gülker | Fri, 06 Oct 2017 18:47:09 UTC

Hi everyone,

my apologies for the late reply. I had a surprisingly busy week.

Am 25. September 2017 um 15:15 Uhr -0500 schrieb Ryan Gonzalez <…9@g…>:
> Well, I just didn't want to write my next Go rant if that wasn't
> actually under consideration. ;)

Input is always appreciated, as long as it's useful. Your post does not
look like you want to start a flamewar.

> Things like the error handling are never problems with small programs,
> but as they start to grow it becomes an incredibly major hassle.

Go is no different than other languages without exceptions here, but I
guess this point is then meant in general against such languages. Fair
enough.

> If we're really doing this from scratch, that would mean building a
> game engine. Lack of operator overloading bites here: instead of
> things like SFML's nice vector operations (e.g. obj.getPosition() +
> otherVector), you have to use long function calls like
> obj.getPosition().addVec(otherVector) or similar.

You have a point. The inability to overload operators is unsatisfying.

> Of course, the only true solution would be to write a programming
> language and use that to implement a compiler framework which would
> then be used to implement a compiler which would then be used to
> implement a programming language which would then be used to implement
> a 2D graphics engine which would then be used to implement a game
> engine which would then be used to implement a game.

Don't forget you have to write the operating system from scratch.

Seriously, the idea is to cut down on TSC's dependencies and pick up
some OpenGL experience on the way. Even more important, the entire thing
should be fun to work on, ideally for all of us.

> In all seriousness, though: if we're looking at other languages, I'd
> highly recommend Nim: https://nim-lang.org/

I will take a closer look in the next days, but a language that compiles
down to another language before it is compiled to machine code
introduces a layer of abstraction that I'd rather not want to deal
with. One more layer of abstraction means there's one more possible
source for problems. I have made bad experiences with CoffeeScript in
this regard. Then, the same approach was used for Vala, which was boldly
announced by the GNOME people some years ago and has now fallen out of
use[1]. This is exactly the kind of short durability that I want to
avoid. Look, TSC's current code base is more than 10 years old, and it
would be nice if the new code base could make for another 10 years and
then still finding developers for it.

I find C++'s complexity disturbing, but the one thing it can hardly be
beaten on is durability. I have no worries that the language and people
actively using it are still around in 10 yers. The same with C. With Go,
I have the hope that this will be the case. With languages that I have
never heard of until they are either suggested here or have made it as
hip to HackerNews only recently, I have problems to imagine.

Marvin

[1]: https://www.bassi.io/articles/2017/02/13/on-vala/ (who is a GNOME dev)

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F