A Change in Direction

I have been working on a new language for the past few weeks and although it had been going well, it seemed a little premature to work on something that is likely to consume a lot of time in the long-term. Most of the reasons behind writing a new language is based on the fact Twinspire is written in three different languages and each codebase multiplying the time it would take to cover all bases.

This is simply not going to happen, but the desire to maintain all three codebases still weighs deeply in my mind.

So, could we make something that allows us to maintain all three codebases without needing to write an entirely new language? Yes, of course we can. It's just a matter of determining what that is and how we design it.

The most obvious solution is to use something like JSON that defines all our structures, procedures, enumerations, types and instructions, and exports them to each language. This would include looping, conditions, switches and the likes, ensuring we cover most of the typical programming language features. This is the easy way, and it is perhaps for the best we stick with this approach and consider expanding this later. This could turn into its own language, yes, but writing a completely new language right now is simply unnecessary.

Another thing that is being considered is using the tool to build the Twinspire framework. Now, two minor issues arise:

• If you choose not to use the tool, you could be using an earlier version of the framework until it is released in all three programming languages. A minor inconvenience, but nothing that can't be handled properly.
• If you choose to use this tool, you may have the latest features, but you are restricted to the WYSIWYG interface with little choice in terms of actual programming.

Now, this could serve a benefit in the long-term. Instead of using the tool directly, you can use the framework as it was generated for the respective programming language you choose to use, be it C#, ODIN or Haxe. This also means that you only use the tool once for the purposes of generating the respective code and compatibility with newer versions need not be an issue. Why? Because by generating from the tool, all of the generated code is up-to-date at the time of generation, so the only compatibility issues would be the result of updating your version of Raylib or Kha (in Haxe), which Twinspire relies on.

For the purposes of building a user interface framework in Twinspire, we've come a long way from making a video series on YouTube to writing blog posts on using WinForms for building tools to help generate UI-specific code, and now using WinForms for building tools to help generate any code relating to Twinspire.

Although this feels like a major detour to get to where we are now and it seems like not much progress is being done, we must walk the walk and not fret or cast doubts upon ourselves in doing so. Now is the time to really get working and get what I feel needs to be done.

As a side note, personal circumstances is currently affecting my hours working on this project so my free-time is currently limited. However, as always, I will keep you up-to-date with the latest and this is for sure the last time I am making any more drastic decisions. This decision is now final and I will start showing screenshots and real progress sooner rather than later. I will also attempt to make more frequent posts.