Comment Re:Balance taxes? (Score 1) 299
And there are much better ways to teach programming. For a very long time there has been a movement to bring programming to the masses, as if, somehow, everyone would be able to write beautiful, intricate code to solve their most complex problems.
You probably already know how to program, and I think that's why you seem to miss the point entirely.
That niche is mostly served nowadays with apps for phones and tablets, which the end user can discover and use on their own from the app store to solve most common needs; but the developer is not totally removed from the equation yet, as even for really simple needs, the user is restricted to the subset of interactions that developers have created in advance, and the user can't build their own on top of them.
Writing programs requires clear, linear thought. It requires thinking in terms of structures and systems.
That's true of most current programming environments, but it's not an inherent property of what we call "programming" if understood in a general sense (that of creating new automated behaviours), specially when we restrict it to the basic tasks I'm talking about. Programming by example, case-based reasoning, procedural inference, constraint-based layouts... or even dexlarative markup languages are tools that allow creating some kinds of automations without using a procedural language nor learning an exact syntax.
The field of End-user Development studies those tools in a scientific context, and has some achievements in their history. Many of these tools are limited in scope (they apply to special situations) and are not general-purpose tools; but some of these, like the spreadsheet and Hypercard, are Turing machines at their core and can ultimately be used for any programming task.
The essence of EUD tools is not defined in terms of linear thought but in terms of semantics and inference of meaning - i.e. being able to make sense of the system as presented and use it to solve your current problems. All humans are good at sense-making, provided the tools are tailored to cover their needs and knowledge background. I've learned some research on semiotics applied to Human-computer interaction, and it shows how to study and build such tools. That is not the approach that is taught in common comp-sci curricula, though.
There are plenty of graphical programming languages that reduce the need for precise syntax, but they only REDUCE it, not eliminate it, and they still require procedural thinking which, ultimately, presents an insurmountable difficulty for many people.
True again, but again not an insurmountable problem. Information workers have managed to use Excel as a shared database with abstract datatypes and Outlook as a workflow management and collaborative creation tool, and as structured personal storage, all without learning how to create a single function definition. That's a Good Thing, though it would be better if they could use similar tools created specifically for those purposes.
Sure, everyone should be given basic skills in writing, and perhaps in drawing or painting as a child, and so perhaps everyone should be given basic skills in programming, but beyond that, why?
Who says there needs to be anything beyond that? The main problem for end users is that their essential needs are still not covered with current programing platforms, as basic programming skills are not enough to build even the most basic automation. The knowledge required to build anything practical like a simple app or Web page is still too much; the learning curve is just too steep. That's where a tool like Hypercard, with its hands-on approach and simple conceptual model, would help.