Curious fantasy and hypothesis

Friendly conversations, and everything that doesn't fit into the other forums.
42 posts Page 3 of 5
Monkeychops
Posts: 27
Joined: Wed Feb 18, 2015 11:53 am
by Monkeychops » Mon Feb 25, 2019 2:00 am
I think a lot of people kind of miss the point about the scripting language... it's not so much that torquescript sucks, or that it's hard to learn. There's a number of much bigger issues:

* Tooling - Sure you can argue syntax hilighting isn't that hard to add to most IDEs, but tooling goes waaaay beyond that. The tooling support for C# for example has code completion, snippets, refactoring, code navigation, advanced debugging, profiling etc.

* Libraries - Say you're writing a game server and you want to store your data in some new-fangled cloud database or other. Or you want to integrate with a hot new game streaming service. There's going to be a C# library for that you can drop in and go. If you're using Torquescript you're probably going to have to write all that from scratch.. probably in c++ (yep, you're going to spend days/weeks in c++ hell worrying about closing connections and releasing resources, even if you only signed up for some high level game scripting). You shouldn't need to burn valuable game dev time implementing/porting stuff that already exists.

* Performance - Torquescript isn't too slow for game scripting, but most of its biggest fans would still normally recommend writing high performance bits in C++. With a fast modern .NET runtime the performance should be good enough that you don't need to leave managed code or mess around going between different programming languages to get the job done.

* Familiarity - Ok, you can learn Torquescript fairly easily. But if does have its quirks... and if you already know C# its one less thing you need to learn coming in to a new engine.

* Productivity - C# is a much more feature-rich language with much neater and more productive ways of doing things. It also has tons of official libraries for working with data, collections, system interactions etc.

* Maintainability - C# makes it very easy to structure and organise your code, and to find the bits you are interested in when needed. There are well documented and tried and tested best practices for code structure that make working with large projects much easier.

* Security - Ok, so .NET isn't the most secure language and can be decompiled, but decent obfuscators exist that do a reasonable job of preventing casual snooping. Torquescript projects pretty much just lay their scripts bare for anyone to fiddle with or copy - and if you want to obfuscate it, you're going to have to write your own obfuscator, because again, its a niche language.

Sure, other engines have their own quirky languages too... but as you also noted, most of those have died out now in favour of mainstream high-level languages. When a lot of older engines were made, being able to embed mainstream languages wasn't really a thing because the open source runtimes didn't exist. Now that they do, people want to use them.
Bloodknight
Posts: 226
Joined: Tue Feb 03, 2015 8:58 pm
by Bloodknight » Mon Feb 25, 2019 5:22 am
I think you are conflating C# the application development language with C# the scripting language, most of the benefits you list there aren't magically generated just because its C# they exist because devs put hours of integrating their specific API into the tooling, look at the massive unity plugins for Visual Studio if you have any doubts.

As for the library plugins for C# vs C++, dude don't start a fight you can't win C++ is the single most cross-platform ever used, it has libraries for things most people haven't even heard of and have been in constant development for the past 40 years, there are probably 10 libraries for everything you can find C# library to do, now in another decade or so this may well be the other way round, but we aren't there yet :p

I will send word of recommendation to the C# Zealots Grandmaster and let him know you've done a fantastic job promoting C#, but you missed the point by an agricultural distance.
Azaezel
Posts: 461
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Mon Feb 25, 2019 2:39 pm
I think a lot of people kind of miss the point about the scripting language... it's not so much that torquescript sucks, or that it's hard to learn. There's a number of much bigger issues:

* Tooling - Sure you can argue syntax hilighting isn't that hard to add to most IDEs, but tooling goes waaaay beyond that. The tooling support for C# for example has code completion, snippets, refactoring, code navigation, advanced debugging, profiling etc.

* Libraries - Say you're writing a game server and you want to store your data in some new-fangled cloud database or other. Or you want to integrate with a hot new game streaming service. There's going to be a C# library for that you can drop in and go. If you're using Torquescript you're probably going to have to write all that from scratch.. probably in c++ (yep, you're going to spend days/weeks in c++ hell worrying about closing connections and releasing resources, even if you only signed up for some high level game scripting). You shouldn't need to burn valuable game dev time implementing/porting stuff that already exists.

* Performance - Torquescript isn't too slow for game scripting, but most of its biggest fans would still normally recommend writing high performance bits in C++. With a fast modern .NET runtime the performance should be good enough that you don't need to leave managed code or mess around going between different programming languages to get the job done.

* Familiarity - Ok, you can learn Torquescript fairly easily. But if does have its quirks... and if you already know C# its one less thing you need to learn coming in to a new engine.

* Productivity - C# is a much more feature-rich language with much neater and more productive ways of doing things. It also has tons of official libraries for working with data, collections, system interactions etc.

* Maintainability - C# makes it very easy to structure and organise your code, and to find the bits you are interested in when needed. There are well documented and tried and tested best practices for code structure that make working with large projects much easier.

* Security - Ok, so .NET isn't the most secure language and can be decompiled, but decent obfuscators exist that do a reasonable job of preventing casual snooping. Torquescript projects pretty much just lay their scripts bare for anyone to fiddle with or copy - and if you want to obfuscate it, you're going to have to write your own obfuscator, because again, its a niche language.

Sure, other engines have their own quirky languages too... but as you also noted, most of those have died out now in favour of mainstream high-level languages. When a lot of older engines were made, being able to embed mainstream languages wasn't really a thing because the open source runtimes didn't exist. Now that they do, people want to use them.
@ LukasPJ would no doubt be highly interested in another pair of eyes to help ensure that what is checked into the development fork *right now* does indeed allow for side by side scripting. Just sayin.
LukasPJ
Site Admin
Posts: 414
Joined: Tue Feb 03, 2015 7:25 pm
 
by LukasPJ » Mon Feb 25, 2019 10:19 pm
Eh, I tried to stay out of this one, because the thread is so toxic 😁

The stuff that is being checked in right now, doesn't really do anything.
All it does is, fix some api-export code and patching some stuff together to export a C-Interface, which was originally developed for JavaScript (in-browser games) when that was all the rage.

So it doesn't add anything new, it just fixes some stuff that already existed and, rather crudely, ties some knots together to activate some functionality which was never finished.

The C# aspect is completely separate from these changes, and you can put any layer on top of it if you want, that's what's nice about a C-Interface. It's a clean, standardized way of exposing managed code.

Why did I pick C#? Because the language has native interop built right in, Java for example requires a bunch of C code to be written and compiled. Doesn't matter too much, but it was very quick to get started with and do some PoCs.
Furthermore, it is statically typed. Which is an absolute must for me, I like to put a lot of functionality into scripts, so I don't want to deal with shitty dynamic typed shittyness.
It's fairly extensible, allowing for some DSL-esque features and cool transparent packaging of the native objects.
You can do unsafe code, which allows for micro optimization in the interop layer.


Honestly, I don't know if I would recommend C# as the all-in choice. It can be kept as a separate project because there is no overlap in code, and TorqueScript has that OotB run everywhere feature, that we can get with C# as well, but it's a lot more maintenance/up front development compared to just using three scripting language we have.

Before we look into making any language official, I think it should prove itself as a stable and broadly popular choice in a standalone packaging before we begin making it official.
Atm, the C# implementation should just be seen as a "proposal" or PoC solution.
suncaller
Posts: 21
Joined: Mon Apr 09, 2018 1:03 am
by suncaller » Tue Feb 26, 2019 2:07 am
I dislike TorqueScript as much as the next guy, but if we're going to all in with anything, that should be our choice, I think. Its strengths outweigh its negatives for its intended use cases. I've gotten started on a t3d-tools extension for vs code which for now adds code completion, snippets, refactoring, and code navigation. Debugging and profiling is on the TODO list, but it's not as straightforward.

The rest of your points... I'm not really sure I'm convinced about C#. I'd love if Lukas would be able to finish getting that popped in there, because who doesn't want more options, but the advantages TorqueScript provides for development are superior in every way, even if the language itself isn't. Real-time, live scripting in the editor, anyone?

Preview of t3d-tools (click the image to see it in action):
Image
Phantom_Limbs
Posts: 4
Joined: Thu Jan 31, 2019 12:14 am
by Phantom_Limbs » Tue Feb 26, 2019 2:27 am
Maybe a good angle would be to have an article or two talking about why Torquescript is great and what separates it from other choices such as LUA, C#, etc? In my (admittedly limited) experience, people tend to be way more amenable to learning a new language, tool, etc if there is good justification and clear advantages for doing so.
Did Godot's scripting language put people off? Not at all. Godot got c# and python scripting well after it boomed in popularity.
From my time keeping an eye on Godot, there was initially a lot of hostility about GDScript - a lot of newcomers were puzzled as to why a modern engine focused on lightweight and mobile would support a funky interpreted language with high overhead, especially one for which they had to learn new syntax. But, as it turns out, there's not just comprehensive documentation on Godot's site, but GDScript's introductory page (here: https://docs.godotengine.org/en/3.0/get ... asics.html ) lays out why they chose to implement it, as well as key advantages it offers. I wouldn't discount how important having that sort of thing is in getting people on board with using Torquescript.
Azaezel
Posts: 461
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Tue Feb 26, 2019 2:33 am
Furthermore, it is statically typed. Which is an absolute must for me, I like to put a lot of functionality into scripts, so I don't want to deal with shitty dynamic typed shittyness.

Before we look into making any language official, I think it should prove itself as a stable and broadly popular choice in a standalone packaging before we begin making it official.
Atm, the C# implementation should just be seen as a "proposal" or PoC solution.
Python and TS lived side by side as a resource for years. Rolling in those augmentations to let folks make that happen with whatever language they wish is laudable.

Simply to state the counter-perception, to my mind at least (and again, personal opinion) it's never made a great deal of sense to use a precision source and precision script pairing. While the tooling is surely more plentiful for them, if you've access to both i far prefer the status quo of precision source side and shall we say.. 'fuzzy' design script side for prototypical iteration, simple and one off class-modding. So I would urge that we maintain the 'why not both' approach.

Edit, Ironically, that godot link under history lists several of the bulletpoints we leverage too, such as syntax sugar for %foo="1 2 3"; %foo.y==2; and oneliner macros for leveraging class elements and methods as a couple quick readthrough examples.
suncaller
Posts: 21
Joined: Mon Apr 09, 2018 1:03 am
by suncaller » Tue Feb 26, 2019 2:53 am
You're not wrong, Phantom_Limbs. In fact, the point I was making was that people disliked gdscript, and yet the engine still became popular before the other languages were implemented. The proposal you made is one I've been contemplating, as well, and inspired by, it seems, the same Godot article.

It may be unnecessary for me to say I agree with Azaezel's points, but I'll do it anyway.
Steve_Yorkshire
Posts: 328
Joined: Tue Feb 03, 2015 10:30 pm
 
by Steve_Yorkshire » Tue Feb 26, 2019 3:00 am
Image
Image
Image
Image
Image
Image
LoLJester
Posts: 109
Joined: Thu Aug 13, 2015 5:58 pm
 
by LoLJester » Tue Feb 26, 2019 4:36 am
"It is an older script, but it checks out" - couldn't agree more. :mrgreen:
42 posts Page 3 of 5

Who is online

Users browsing this forum: No registered users and 10 guests