search

LordOfDragons / dragengine

Drag[en]gine Game Engine
MIT License
70 stars 6 forks source link

Builtin IDE for script languages #7

Open Deadlytoad opened 4 years ago

Deadlytoad commented 4 years ago

Hi, I am requesting a built in IDE for the the dragengine, believe this would help keeping all the workflow in one software. I know visual studio or other IDES exist but its nice to have a established IDE for the main scripting language for the game which is dragonscript(but you can use any language if you use a IDE). Curious on what you guys think on this?

Thanks

LordOfDragons commented 4 years ago

The Drag[en]gine does not have a "main scripting language" by concept. Such a Code Editor would have to support all kinds of scripting languages including those coming in the future. This would require the ability to define languages, highlighting, semantic handling and more. It would be basically redoing KDevelop or VisualCode inside the IGDE as an editor. This kind of editor I do not consider useful.

As you mentioned the editor could just focus on DragonScript as a language. This would narrow down the work load but would be still a lot of work to be done.

Iiridayn commented 2 years ago

Not a fan in general of IDEs.

I prefer to use a dedicated text editor and more generally the "Unix philosophy" - tools which specialize in one thing, but that can talk to each other via a universal interface (namely, text over stdin). The advantage I find is that I end up with an amazing text editor which I can use anywhere, on any language, and can then use whatever compiler/build tool that I need for a given project (though I prefer those to obey the unix philosophy, etc).

Another nice side effect is that it simplifies development (don't build a networking stack into the app when you can pass in curl), and allows the app to focus on doing just one thing very well, as opposed to many things poorly (the networking stack won't handle networking issues nearly as well as curl, and developers won't have time to spend on features if they're fixing the networking stack). To a certain extent it's a generalization of the idea of software libraries to interoperating applications - with some of the same downsides (ie, curl might not do exactly what you need, or be a bother to invoke, or can't be expected to be installed on the target system, etc).

Anyway - IDEs reverse this modularization into "let's build a text editor and a compiler and a workflow manager and a 3d designer and a ..." - YAGNI, and lots of reinventing wheels.