The inspiration on GameMaker is clear and very much appreciated.
Can the IDE run on other OSes besides Windows? You seem to be using WinForms.I tried building it and running through Wine, but it didn't work.
Congrats on the project, making an IDE is no easy task. I believe there's room for a game engine to offer what GameMaker 8.1 used to (near instant runs, extremely fast iteration time for 2D games).
Thanks. As you said, the IDE is built on winforms, so it's windows only. maybe it was a mistake to not to use a cross platform framework like avalonia, but i really like the winforms designer, and winforms is the only UI framework i ever used, except for MAUI which is not a good idea to build an IDE on.
Windows.Forms is becoming less of a problem with projects like LibreWinForms [0] progressing quickly. I just tried to build your project and there are only a few classes that are not implemented when it comes to the GUI.
Every other UI framework I worked before and after always left me with the impression that something was lacking, in speed of development, fast iteration, but also in the quality of the abstractions.
Plenty of reasons to continue using WinForms for quick and dirty utils.
WinForms has had a major cleanup over the last few years. Issues with DPI, multiple windows are mostly gone.
You no longer need VS2. vscode on its own is excellent, and you can if you need to, still use VS2 for debugging
(Same applies to AvaloniaUI for cross platform.)
Codex, Claude need guidance if you want something maintainable, otherwise they generate a mess structure wise or reinventing functionality already available in standard controls 'out of the box'.
I completely agree with you. It definitely felt like function over form. It was utilitarian, but WinForms was probably the closest thing since Visual Basic (and Delphi) in terms of rapid prototyping of a GUI.
I'm a happy user and I think they are doing a lot of things different in a good way. A lot of their blog posts are highly technical and informative.
But, I agree, this is mostly a puff piece. Nothing necessarily wrong with that but not what I would have expected given the other blog posts that have shown up here on HN.
> new programming language development is basically dead at this point
I think it's the opposite. For the projects that warrant it (usually games), it has never been easier to create a custom embeddable scripting language. It was always somewhat common to have custom languages, specially if the game is open to mods and/or allows users to create custom maps, but now that's easier than ever to do.
I'm pretty sure the issue is not "higher order abstractions".
It is using multiple single letter references with no real grounding or relationship that the reader has to track.
For example, looping over a map with "k" and "v" vars is not that bad because the reader understands k=key and v=value, and that makes since for a map.
If you do this same thing with different single letter vars, e.g. "a" and "b", it instantly becomes more difficult to read.
When writing a generic function and using these single character type references it can make sense, especially because the function/method doesn't care what those references are, however to someone trying to understand what's going on it can be extremely difficult simply because of the names.
Sure, if all you are going to do is call that method or function those type references go away and the call site may be relatively clean, but you still have to read the thing to understand what it is and how to use it.
It's showing you it's blending the `Box[T]` with a function that takes a function that applies over `T` to get a new type `Box[U]`. It's a bit convoluted, and it's also unnecessary. I think it's more readable like this:
reply