[alanctgardner2]

People seem to think the difficulty in coding is the mechanical act of writing code. "If only you could draw code!", they cry, linking together a series of blocks to represent program flow. The thing is, even if you make a language where it's impossible to fail (every program does something, it's visually intuitive when a program isn't valid), it still doesn't necessarily do the right thing.

The difficulty in programming isn't the mechanical act of writing code; we have copy-paste for that. The problem is having a mental model of the program execution, and mapping it to the real-world problem. This is the difference between good and bad programmers, and it applies to the population at large.

Case in point: I'm working with some soon-to-be grads from a CS program. In Java, one of them instantiated a class, and set an attribute of that instance. Elsewhere they instantiated a new instance, and tried to read the value back. And they couldn't understand why the value wasn't set, Portal-style, in their new instance. This guy, who has been in school for 4 years for CS, also couldn't figure out why it made sense to make specific shapes (circle, square, triangle) children of an abstract Shape class. He could, very easily, add a Search bar to an Android app because he had seen a tutorial on how to do it - but making the bar do anything was a tremendous feat, because it wasn't just the mechanical repetition of some pattern.

Even with experienced (>5 years) programmers, I've seen some really terrible debugging where it was clear the person didn't have a mental model of the code. They never really got any benefit from GDB, because when they looked at the internal state of the program they just shrugged and said "Yeah, looks right". And they owned the codebase. This was their code, and they couldn't reason about it.

After all that ranting, my point is: you can make it easier to write some program, but you can't make it (appreciably) easier to write the program that you need.

[williamcotton]

> And they couldn't understand why the value wasn't set, Portal-style, in their new instance.

Is it possible that these students might have other types of intelligence?

I've got friends who are very strong visually and they thrive in visual environments such as MaxMSP and Quartz Composer. They make amazing interactive art pieces. Yet, they seem completely baffled by general purpose programming and symbolic logic. The thing is, you can talk to them and they can absolutely reason about things. They're not incapable of logic, rather a certain expression of logic.

What worries me is that we've created a negative feedback loop. The tools we've created for computing are heavily dependent on symbolic logic. This attracts people who are gifted with symbolic logic. They in turn create more tools that work best for people excel at symbolic logic. And so on and so forth.

I don't think this is an issue with people being incapable of creating mental models. A gymnast has an amazing mental model of their body and it's relation to space and the things in that space. However, we have yet to create computing tools for interactive design that build on top of that mental model. Why is that? Because we engineers have some of the WORST mental models of how our bodies flow through space.

I think this is all mainly an issue with listening, understanding and compassion, traits that seem to be stunted in the software industry. Engineers seem to have a certain predilection to talk over people. We seem to always be waiting for the other person to stop talking.

And I'll take the poetic license one step further and say that our entire industry is incapable of listening. It is always "hey, lets set up coding camps"! What about, "hey, let's set up a symposium where us engineers listen to other people about how they live their lives and what they think!"?

[alanctgardner2]

> Engineers seem to have a certain predilection to talk over people

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.

[Double_Cast]

I mostly agree with what you said. But your proposed solution sounds to me like a reboot of COBOL, which was a failure. I feel like I'm misinterpreting something. Am I?

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

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

[scj]

An extension of your argument might be that linguists have also failed these people, as modern languages are represented in symbols (expressed visually and orally).

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.

[ericHosick]

> Is it possible that these students might have other types of intelligence?

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.

[ericHosick]

> The difficulty in programming isn't the mechanical act of writing code;

I look at coding and programming as different things.

Programming is the critical thinking aspects of developing software and a skill that everyone should master: starting with children.

The act of writing code, and more specifically using frameworks designed with the intent of being coded against, is unnecessarily difficult.

I've always spent more time fighting with bad frameworks than I do implementing desired behavior.

Once I figure out the peculiarities of a compiler, I'm good to go. I can code fast. But, getting to that point takes a long time. It is especially difficult for people learning to program when they have to learn to code (edit: at the same time).

Software development is fundamentally broken and it frustrates me to no end.

[alanctgardner2]

> Programming is the critical thinking aspects of developing software and a skill that everyone should master: starting with children.

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.

[ericHosick]

My sentence was poorly written. I wanted to say "Programming is the critical thinking aspects of developing software and critical thinking is a skill that everyone should master: starting with children."

I don't want everyone to think like programmers. I want programmers to think like everyone else and hope some day that everyone can be programmers.

> It seems like you have a horse in this race.

Ya. We do. We've been working on a new development methodology and from that a visual object language and framework. Initially we coded against the framework but have found that you can visually represent usage of the framework equally well.

> really appropriate for programming beyond toys (or maybe data modeling, but not procedural programming)

Funny you say that. I also agree if you are using traditional approaches to software development (aka procedure programming). However, our framework does not use procedural programming per-se in that it has no paramaterized procedures/methods/functions/sub-routines.

[scott_s]

I think you should keep in mind that the distinction you make between "programming" and "coding" is not shared by most programmers. I acknowledge that the things you're describing exist, and are distinct, but those are not the words I use for them. To me, "programming" and "coding" are synonymous. I point this out because you may run into confusion if you discuss these concepts with others, and rely on using your own words.

[ericHosick]

> rely on using your own words

People used to say they would "program their VCR".

Also, I didn't in any way mean to imply that they were definitely different. I did say "I look at coding and programming as different things" as opposed to "Coding and programming are different things".

[Double_Cast]

A few months ago, a redditor introduced me to the notion of "the trivium". It was mentioned in the context of reforming the U.S. education system. I think it was a neat idea, and it was the lens through which I interpreted this comment.

The trivium consists of grammar, dialectic, and rhetoric [1]. Grammar signifies knowing the language/jargon. E.g. knowing the parts of a car. Dialectic signifies logic and critical thinking. E.g. realizing that adding more oil won't fix the alternator. Rhetoric signifies application and expression. E.g. designing a safe, high-performance, cost-effective, and aesthetically-appealing vehicle.

Regarding your anecdote about not understanding abstraction of shapes. It sounds to me like your friend is comfortable with grammar, but not dialectic.

According to this redditor, a major flaw in the education system is that it teaches "subjects" (grammar) while critical thinking (dialectic) is shafted (mostly limited to math class) [2]. But I repeatedly read stories about people who can program without anything more than a basic understanding. I find this surprising because computer science is mostly math, which falls under dialectic. Why is this? Disclaimer: I'm new to programming.

[1] http://en.wikipedia.org/wiki/Trivium

[2] http://www.scribd.com/doc/36325362/The-Lost-Tools-of-Learnin...

[nathas]

Computer science is mostly "math" only at the lower levels - things like language design, how the bits work in the actual circuits, etc. Exceptions are things like 3d graphics and crypto, but most "normal" programmers don't need to understand the underlying math there.

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.

[scott_s]

My own essay on the relationship of computer science and math: http://www.scott-a-s.com/cs-is-not-math

[Double_Cast]

Thanks. I liked the physicist reference.

[CodeMage]

People seem to think the difficulty in coding is the mechanical act of writing code

A lot of people make the mistake you mentioned, but the author makes a different, common mistake that is, in my opinion, even worse:

Programming is easy, after all: all you need to understand is conditions and repetition

Programming can be boiled down to conditions and repetition as much as playing chess can be boiled down to moving the pieces around. That's why there's a difference between playing chess with your mates and being the world champion.

Or, for a different analogy, try boiling down the act of driving a car to pressing pedals and wiggling the steering wheel. Yes, driving your personal car might be almost as simple as that, but driving a bus full of people or a race car goes quite a bit beyond that.

What I'm trying to say is that there are different problem classes that require different skill levels. While it's perfectly okay to want to make it easier for people with lower skill levels to solve problem classes that can be solved -- I hope you will forgive me if I call that the low-hanging fruit -- the author's stated belief is an oversimplification that has repeatedly been proven incorrect.

[scott_s]

Perhaps a more general way to state your point: Don't confuse the mechanical actions required to perform a task with the mental reasoning that drive them.