Also, your whole premise is just wrong. There's been a ton of research showing that the hard thing about programming is not syntax, or tooling, but thinking in abstract terms (I'd link, but I don't have access to most academic publications these days :( ). You're not the first person to think "Hey, if only we could make this whole programming thing more accessible to everyone, everyone would do it!" And yet nobody has succeeded, or even gone close. The best we've managed is to make it easier for an interested amateur to learn to program normally. We've got good documentation available on the Web. Every PC can easily install a wide range of language development environments, for free. Large numbers of frameworks are available to allow you to avoid having to do the heavy lifting for areas where you don't have the time / brainpower to become a subject matter expert. These are all positive developments, but the fact is that 99% of the population still can't even explain in plain English (or Spanish, or Chinese or whatever it is they speak) to a developer what it is they want a system to do.

When was the last time you saw a spec written by a non-programmer trying to explain a business process? Did they even try to explain what happens in error cases? If they did you were a lucky sort, because I've seen dozens of these types of documents, and none contained information on how to handle error conditions. They'll tell you to pull an employee out of the database based on the name, without stopping to think that several employees might have the same name, so you need to have some unique identifier. They'll tell you that an action needs to be done on the first of the month, but they'll forget to tell you what to do when the first of the month is actually a public holiday. These are the problems that we, as programmers, are trained to deal with, and which most people just don't seem capable of doing. And "easy" tools aren't going to help them, because the problem isn't the tools, it's the abstract thinking.

Despite the vitriol you've received, I think I understand what you're trying to say here. I think you want a higher level programming language. And not merely a successor to the latest zeitgeist, but essentially what C was to punch tape. That is, binary might be fundamental to computation, but it isn't fundamental to the ergonomics of programming. So the question is, is it possible to somehow abstract programming to an higher level?

pg wrote that all other language have evolved towards lisp. I think the trend is a special case of a trend towards functional programming. So imho, whatever comes next (given there is a next) will have to (for lack of a better word, ) supersede lambda calculus.

Automator is not coding.

That's overly general: a lot of programmers may be socially inept, but it's neither necessary nor sufficient. Both the examples from above are pretty anti-social, but they also don't happen to have these skills. Likewise, I know some very good programmers who are also good at requirements gathering and collecting domain knowledge, which entails learning from experts and listening to them.

> The tools we've created for computing are heavily dependent on symbolic logic.

The whole notion of computers, for better or worse, depends on symbolic logic. You'll have a hell of a time building a microprocessor whose instruction set is paintings or dance moves. The best case is that we build an interface from symbolic logic to this new, more approachable paradigm.

> They make amazing interactive art pieces.

How much logic can you put in an interactive art project? Can it model anything in the real world? The biggest problem with other paradigms is density: if you want to program via something other than symbolic logic, get ready for incredible fatigue as you try to turn a 10K LOC program into a 500MP painting. Or an 18 hour long dance.

I guess I should clarify: I don't think non-programmers are lesser beings, or that they can't model anything in their heads. But for the sake of programming, the only thing that matters is if you can model a computer. If you have other types of intelligence, that's fine, just know you're going to have a tough go of it when it comes to understanding the code you write.

> What worries me is that we've created a negative feedback loop.

<pedantry> Wouldn't that be a positive feedback loop? </pedantry>

Try as I might, I am having a difficult time figuring out how to express the previous sentiment through pictures alone. Especially if I want to ensure that others interpret the intent of my expression correctly. Pictionary is a great example of that difficulty. And consider that the concepts expressed in Pictionary are calibrated for a visual medium.

Symbols are precise and concise. Which are two good traits for expressing logic. The later trait is desired, while the former is required.

Don't get me wrong, there are geometric proofs that are much simpler than their symbolic competition. However, that simplicity is on a case-by-case basis in my experience. Where the majority of cases favour symbolic. Although I admit potential bias on this point.

When I think of documentation, pictures are a good way of giving an introduction to a code base. But when it comes down to expressing individual functions and interfaces, pictures can't beat code comments. And even code comments lose against simple enough functions.

If you can figure out a good way to express general purpose programming visually, more power to you. There is probably a good consumer market. But professionally, I believe it would be difficult to compete with symbolic programming. And not just because of inertia, but for the reasons stated above.

Finally, I don't think it is a matter of listening. I understand what it is like not to be able to express myself in a given way. But I also understand that I, like all people, have limitations. And I endeavour to work with people who complement, not just echo, my skill set.

It does make you wonder how many people would have made great programmers but gave up because they could not get past the step of learning how to code.

That's pretty much the opposite of my point: programmers want everyone to think like programmers (per your definition). In my opinion, this kind of "critical" thinking is not necessarily a positive: there are other ways to think critically that don't map well to programming. This seems like the typical HN view that everyone should think like I do. Some people don't get math, or symbolic logic, and that's not stopping them being a value to society.

Looking at your profile, it seems like you have a horse in this race. Personally, Visual looks very slick, but I don't think visual representations are really appropriate for programming beyond toys (or maybe data modelling, but not procedural programming). It gets very hard to lay out a large program in 2D space, and the toolbox required to enumerate all the built-ins and libraries seems like a bit of a handicap compared to just typing them.

Most CS comes down to logical operations and the scientific method.

Problem -> Research -> Hypothesis -> Experiment -> Analyze -> Results -> Reapeat until problem is solved.

You can program if you can reason well enough.

Each time I open an article on HN describing the virtues of the latest programming language, I always see the word "powerful". Whether a language is Assembly or Python, the author can guarantee it's "powerful". I think it's devolved into a buzzword because programmers use it to mean opposite things. It's like how Orwell said two critics can describe the same painting as possessing both "a living quality" and "a peculiar deadliness" [1].

Like I said in another comment, programmers were able to abstract binary away from the tangibility of punch tape. But I think we can only abstract so much before we begin to hit a wall, beyond of which we begin to lose absolutely essential features. So once we reach such a point, I think complexity becomes conserved.

So if we want to simplify one thing, the best we can often do is move the complexity elsewhere. Like a what a refrigerator does with heat. When programmers say a low level language like C is simple and powerful, they mean that the implementation is simple, but the interface is complex [2]. But when programmers say that a high level language like Python is simple and powerful, they mean that the implementation is complex, but the interface is simple.

So I think the real question is, "Where is the complexity hiding?"

[1] https://www.mtholyoke.edu/acad/intrel/orwell46.htm

[2] http://www.jwz.org/doc/worse-is-better.html

They don't have the skills needed to do it themselves, aren't interested in acquiring the skills, but appreciate your end product and want to use it.

I think this is just fine. I don't really want to put in the incredible effort required to learn to play the piano well, so I'm glad other people have put in that effort and I'll listen to them play instead. Would I learn if someone made it a lot easier? Probably. But would that make me a musician? Could I make inspired changes and extensions to existing works? Or wholly original works? No way!

Lets not ignore differences in humans and say programming is easy because it isn't to a large number of people.

http://arstechnica.com/information-technology/2012/09/is-it-...

People just think it "makes sense" to work directly with various fonts and sizes when writing on a page, but that's actually pretty unnatural. No one ever worked that way before - you'd bang out a draft on a typewriter and hand it to a typesetter who would take care of that part.

It took at least a decade for people to really accept it in earnest.