Programming is 75-90% repetition of patterns. The remaining 10-15% are the difference between a simple translation of usual human language into a foreign language vs. developing algorithms and/or logic to solve a problem.
If we can get rid of the non-algorithm, non-logic part we'd be better off, and this is what i read into this sentence.
Look at this snippet of Java:
public static void main(String[] args)
To answer all of those questions, you need to go into method visibility, the difference between static and instance methods (itself easily requiring the teacher to introduce the concept of 'state' and what OO is at a basic level), types and the notion of a "void" type, and odd historical baggage which prompts the JVM to look for 'main' as a special, magical name. You haven't even gotten to "Hello, world!" and you have to unpack at least a lecture's worth of knowledge into the poor sap's head.
It's a lot easier to have a language where you type commands and the machine follows them. Even fundamentally bad languages, like GW-BASIC (my first language), have a hypnotic power over young programmers simply by virtue of that immediate response.
Programming today still means 85%-90% doing repetitive stuff. Tools could do away with this, freeing the developer/engineer to spend more time on solving actual problems.
If you oppose to this, please state the reason why, since I'm probably fogged.
To be more clear, I don't propose to make programming easier. I do propose to make so-called "programming" go away, to focus on the actual problem-solving part. "Programming" to me means mostly translating requirements into code (without having to deal with decomposing and recombining requirements, which is the real work).
But some languages have more than others, which is why they're bad teaching languages.
That's my point.
> To be more clear, I don't propose to make programming easier. I do propose to make so-called "programming" go away, to focus on the actual problem-solving part. "Programming" to me means mostly translating requirements into code (without having to deal with decomposing and recombining requirements, which is the real work).
Translating requirements into code is programming. Reducing boilerplate isn't making programming go away.
It's known as "shell". It's opposite to programming.
"Shell" is a kind of REPL for a kind of language, both being optimized to minimize typing required to execute commands and string them together in a pipe. It's good at its job, but it's poor general REPL. Proper programming REPLs are very powerful and very useful tools, to the point I'm pretty unhappy when I have to work in a language without one.