I think this is entirely cart before horse. What actually happened was the web made programming relevant to a much broader audience and JavaScript is the language you use to program for the web, so everyone learnt that.
I think this is entirely cart before horse. What actually happened was the web made programming relevant to a much broader audience and JavaScript is the language you use to program for the web, so everyone learnt that.
Also anybody could right-click and "view source". (Imagine being able to do that in any Swing app in their peak, for contrast.)
When pages were just a few hundred lines any page could be recreated with a web browser, ambition, and enough time. Those days are long gone, now, with huge transitive node dependencies, minification, and feature-combinatorial-explosion. Like a sandboxed document-centric qbasic.
I’d save whole websites and play with their code (back then that meant html2/3 and early css and Javascript, but still). It was enticing after playing with terminal views for years before that. Kids like colourful things, what can I say.
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)
You have to put that exactly in every Java program. Why? What does it mean? Why can't I omit it?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.