> The language for the 21st century should be business oriented, English-like and not dependent on native types.
It is shocking to me how often the problem of "programming is difficult and time consuming and unintuitive" is to be resolved by "making programming languages more like English". The language is there as a tool to make programming easier!
Do you know how many times I've taken someone's keyboard to type a tiny snippet and then explained it in English with the code as reference? Why do you think I don't just explain it in English first? Because English is verbose and ambiguous and not suited to describing logic. That's what programming languages are for.
It's the same thing whenever someone makes a scratch clone but meant for real work. If you limit your scope enough, and you benefit from the visual layout, I think it can be a productivity win. Otherwise, they just tend to make the trivial stuff into drag and drop, and the easy stuff difficult or tedious.
Unreal Engine's material and animation blueprints satisfy the above criteria, and are a pleasure to work with IMO. But they're both laser focused on doing one thing. With materials, seeing the output preview of each stage of the pipeline is a great help. And with animations, it's essentially a state machine, so seeing it graphed out in front of you is how you'd want to prepare to write the code anyway. Both clear wins for having a visual layout, but I want to stress that these are exceptions to the rule.
EDIT: Also should bring up Inform7[1] as another example of a focused tool that benefits from not being code. If your goal is to write a text adventure, it makes sense to use prose to create it. It also somewhat benefits the authors who are typically more writers than engineers, but don't even think that means you can just sit down and start writing it without a learning phase.
I'm going to take it one further. All of those are good but I think there are some "easier" and more fundamental things that are massive roadblocks for beginning programmers.
- Understanding the problem itself
- Determining how to actually solve that problem
- Expressing all the details of the solution you've chosen.
- Determining what has gone wrong and why
- Knowing when to step back and try another approach
> Do you know how many times I've taken someone's keyboard to type a tiny snippet and then explained it in English with the code as reference? Why do you think I don't just explain it in English first? Because English is verbose and ambiguous and not suited to describing logic. That's what programming languages are for.
Exactly this — and it is true about any human language. They were built for humans who are capable of interpreting things given the context. Try covering every single case in English and you have a lengthy legal document which no one wants to read — and it still has some ambiguity left.
If you want an example of what English would look like if used for programming, take a legal document and multiply it by 100.
It is shocking to me how often the problem of "programming is difficult and time consuming and unintuitive" is to be resolved by "making programming languages more like English". The language is there as a tool to make programming easier!
Do you know how many times I've taken someone's keyboard to type a tiny snippet and then explained it in English with the code as reference? Why do you think I don't just explain it in English first? Because English is verbose and ambiguous and not suited to describing logic. That's what programming languages are for.
It's the same thing whenever someone makes a scratch clone but meant for real work. If you limit your scope enough, and you benefit from the visual layout, I think it can be a productivity win. Otherwise, they just tend to make the trivial stuff into drag and drop, and the easy stuff difficult or tedious.
Unreal Engine's material and animation blueprints satisfy the above criteria, and are a pleasure to work with IMO. But they're both laser focused on doing one thing. With materials, seeing the output preview of each stage of the pipeline is a great help. And with animations, it's essentially a state machine, so seeing it graphed out in front of you is how you'd want to prepare to write the code anyway. Both clear wins for having a visual layout, but I want to stress that these are exceptions to the rule.
EDIT: Also should bring up Inform7[1] as another example of a focused tool that benefits from not being code. If your goal is to write a text adventure, it makes sense to use prose to create it. It also somewhat benefits the authors who are typically more writers than engineers, but don't even think that means you can just sit down and start writing it without a learning phase.
[0]: https://docs.unrealengine.com/en-US/Engine/Rendering/Materia...
[1]: http://inform7.com/