Thread did not disappoint.
This is what I was hoping someone would say. I feel like most visual programming I've seen is in the realm of toy / education. Things like scratch or lego mindstorms come to mind (as sol_hsa mentioned). I don't know anything about it,
I take a look then. But there nothing "toy"-like to my tool. It is editing the binary more or less directly, but in memory. Using a kind of virtualization of code and data, for the RTD to have control.
The reason for a graphical interface, is that it allows for much larger space of "syntax" selection. Also it allows for a large space of signaling the coder of what is actually happening to his code. De-coupling the syntax from the binary has many non-obvious benefits.
One that would be that I could read your code in my syntax. Another is compilerspeed, and yet another is complete typechecking, and even codechecking by the compiler nanoseconds after an instruction is written.
One of the most important features of a tool the way I see it, it to be able to get to everywhere in the code, from everywhere, as fast as possible. One of my goals is to try to make this efficient. Unless I think I succeeded, I will not publish anything.
but someone in the stream mentioned blueprints in the unreal engine which might hint at a more practical application. (There's actually quite a bit more examples of this than I realized).
Just a couple of month after I wrote my prototype I witnessed the demo of the unreal engine, and I immediately got excited seeing that they had been thinking a little bit along the same line, with the Blueprints. I even think, to my self, in private, I must have gotten some inspiration from them, somehow. Even though I was disconnected for 4 month, at the time I wrote my prototype. I am unable to express what that feels like, but I guess some will get it, and to others it will sound crazy.
I have always admired the Unreal team, since it was pretty obvious already in their first works they knew how to make games that was fun to play and performant. It's typical almost, how simple a program looks, is often felt like the illusion that it was easy to do, whereas it's always the other way around. When a program feels efficient and fluent, it means it took extremely much effort to get it that way. Or at the very least a lot of competance.
The demo was amazing. But 3D games are not for me, since I figure that the content creation is the most demanding task. Way over my competance and capacity, and what excite me the most is coding.
Plus there's only so much time in a year, and one has to figure out a niche to fit into. There's so many good coders out there, it seems, that even if the market screams for more(according to Casey), the true market is overflown by software.
I mean, even if you could launch a new facebook tomorrow you'd be wasting your time.
There now so many great games out there, that it's impossible to make time to play even a small selection. If you're not able to compete with the very best, you are likely to waste precious time and resources for nothing.
99% of games on googleplay, do not make a dime.
I think part of the problem with visual coding is twofold:
1. Code doesn't exist in a vacuum. It has to interact and integrate with existing code, most of which is already written in text.
This is true. But there's nothing preventing you from interacting with the same code, in the form of a binary library. Which my tool does already, calling to the windows library for having a window.
But the tendency among matured coders is to avoid libraries as much as humanly possible, since it in many cases is trivial to implement the few functions you would need, and that for libraries that have some serious scope, the applications already exist. So there no need to use them, since the solutions are already out there. When you want to create something new, there isn't a library to call to.
2. It's hard to match the effectiveness of keyboard input, even if the keyboard input is still entering every character by hand. Maybe it's unavoidable math: 10 fingers adds up to a whole lot more potential input than 1 mouse cursor.
This is very true. I completely agree. A keyboard is even more efficient than speaking. Not just a little more efficient, but the difference is so huge that I doubt that "talking to a computer" will ever gain popularity, just like talking to a dement never will be much fun. For creative people. FLOW FLOW FLOW is everything. During FLOW, you can in two month do the work equivalent of _SEVERAL YEARS_ of coding without it. And it requires that you can work at the speed of thought. No, even faster then the speed of thought. You need to go at the speed of your sub-consious thought. When Paul Graham speaks about good programmers, I tend to think along these lines. That this is those that have coded so much, they can connect directly with their subconscious while coding. They are no longer coding, but "dancing".
I think if an alternate interface is going to challenge traditional text input, it's going to have to have support a large baud rate (as it were) of information from human to computer.
I strongly agree with you here. This is the main issue to solve.