Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

waderoush writes "Adam Wiggins, co-founder of Heroku, agrees with anthropologist Bonnie Nardi that programming isn't just for geeks. The problem, he says, is that today's tools for teaching programming are woefully inadequate. In a commentary, Wiggins argues that there are two major gaps preventing programming tools from being accessible to beginners: 1) they're too fussy, requiring extensive setup, and 2) they're focused on the technology rather than everyday tasks. A good tool for learning programming, Wiggins argues, would emulate an Excel or Google Docs spreadsheet – beginners would be able to fire it up instantly, and would be able to get useful things done right away. (He's dismissive, though, of visual programming tools that 'attempt to hide logic behind a point-and-click interface.') 'Broad programming literacy is crucial in a world increasingly made of computers,' Wiggins says. 'Despite common stereotypes, programming is not out of reach for the average person,' as long as the tools are easy to set up and specialized on the programmer's task."

People can't program the VCR clock. (For the young ones: Back in the old days we called the Tivo "VCR". Just like everything must have a camera today, back then everything had to had a clock, and it had to be set manually.) You can barely teach (most) people algorithms that aren't completely linear. If you think you can teach them to develop algorithms, you need to get back in the trenches and deal with normal people. Developing programs means to understand problems in depth and to correctly answer a lot of "what-if" questions about complex systems. Normal people actively try to avoid doing that kind of thinking.

This is because people are not interested into the problem, they are only interested by the solution.

And this is true for everybody: personally, I don't really care about how my car works, I just want that it works.When it does not work, I go to a garage to solve my problem.

Trying to simplify programming will only give a false sense of expertise, because REAL programming is tough: it's about solving abstract problems.

No matter the difficulty of the subject, there will always be people who are interested in understanding, and people who don't care (even if it's simple).So I would prefer that, instead of training people who don't care about programming, we train people who are interested into programming.

And the best tool to make people interested into programming is games, because a lot of programmers started programming because they wanted to write their own game.

Programming at a professional competancy might be out of reach. But programming badly isn't that hard. As in:

10 print "my sister is ugly" : goto 10

Back in the days of the TRS-80, Commodore Pet, Apple II and BBC personal computers (et.al.), millions of kids could turn on their personal computer and start typing in Basic right away, usually using stuff copied off of a magazine article... at first. But then they could modify their programs and crash them in a million different ways. That caused learning, a

`Hello World` in Java is one line, excluding stuff that the IDE does for me. While I do hate it when IDEs generate screeds of boilerplate code, I think Java keeps it to a minimum, and I like what Java makes explicit. I wouldn't say it was an ideal beginner's language though.

Hello World is one line in Groovy, Python, Ruby, Perl. Ruby and Python are languages I might recommend to an absolute beginner.

It is a far more demanding task that "geek" would qualify you. It requires talent, education and experience. Those that gripe about the tools do not get it or have never gotten beyond toy examples. Sure, a better tool helps. But when you create software (as opposed to slapping together some disaster waiting happen), the direct level of skill needed to use the tools is actually a minor concern. In fact, the language used is a minor concern, the problem is what matters. Insofar I even agree with the article. But refusing tools that are a bit complicated is the hallmark of somebody that does not get it.

Case in point: Pen and paper are exceedingly difficult to use for writing. Yet we spend years on every person to qualify them to use it. Yet compare the complexity of pen&paper on one side, and a computer on the other side. Anybody expecting the computer to be easier to use just has no clue at all.

All that "simple" to use tools for software creation do is cause even more really bad programs to be written, as suddenly everybody and their grandmother thinks they can do it. Like giving calligraphy pens to amateurs. Sure, they can produce some smears, but they cannot produce anything worthwhile.

Bullshit. Programming still is *piss-easy* compared to our actual mental abilities. Everyone of us does all the stuff you need for it in daily life anyway:

Everyone of us uses the concept of identifiers (think variables), when we say “he" instead of "Jim", or even "Jim" instead of shoving that person in front of your eyes.Everyone of us uses the concept of sequences of commands, when making a to-do list.Everyone of us uses has no problem with including tasks into that to-do list, that themselves are a set of steps one could write down somewhere else.Everyone of us is able to say "Do this 10 times.", "Do this for all people in the room.", or "Until you have at least $1000, keep on saving.".Everyone of us is able to make lists, use property lists (dating site profiles, etc), handle tree structures (company hierarchies, file systems), and even more complex ones.Everyone of us uses grouping (think modules) all the time in daily life. It's part of how our brain works, to group things into classes.Everyone of us can use and understand the concept of expressions, when we read and write recipes. (Which essentially are programs: dinner = [(simmerFor (10 min) (add [cream,whiteWine,(dried chickenBroth),nutmeg,(piecesOf broccoli),salt,pepper,garlic] (fried (chopped chickenBreast)))) + ((cookedIn saltWater (8 min)) tagiatelle), readyMadeGarlicyFriseeSalad ].)You do the next one.

There is absolutely nobody with a normal working brain who can't program. With the right interface and presentation, your grandma can program medium-sized software packages, no problem.

And most importantly: There's nothing wrong with small shitty scripts grown from one-off one-liners.a

But you must understand the concept of "identifiers". Before you are 9-10, the name of your mother is useually just "Mom"... but so is everyones mother is named "Mom"... So now it is "joeys mom"... which is not "my mom"... and neither is a correct identity.

Concept of a sequence of commands - not until you are told "No" long enough. The problem is not the concept of a sequence, but one of generating a sequence. And doing it properly is hard. It takes over twenty years for people to write a sequence of words

You fail to see the problem. What you describe is the "primitives" of a simple programming language. Understanding them does not help you write software of any meaningful complexity. Your argument akin to saying somebody that can carry around a brick and put it somewhere is able to build a house that is comfortable and durable. Not so, rather obviously.

Everyone of us is able to say "Do this 10 times.", "Do this for all people in the room.", or "Until you have at least $1000, keep on saving.".

Well you think that every one is able to understand that, but I know at least a person with a PhD in Law that is unable to understand the concept of "FOR" or a "WHILE", and we were 2 computer engineers and PhD in computer science trying to explain it...

Indeed. You have to get the view a program has of the world, i.e. the abstraction used. Unless you understand that, nothing can help you. And by now I am convinced from experience that this cannot actually be taught, most people are just not equipped mentally to understand it.

Perhaps, the problem lies that most of the abstractions are created by programmers, and let's face it programmers have a unique way of thinking that's a bit different than the rest of the population.

Coupled with the fact that these ad-hoc abstractions are usually developed incompletely, don't model the real world, and are frequently mired in tedious details it starts to become very clear why regular people are left out of programming.

I agree with you on Lisp. The core language is strikingly elegant. I did some smaller work with it way back and really enjoyed it. I think the problem that most programmers have with Lisp is that if you do not understand recursion, it is very hard to get anywhere. That said, I am all for teaching (core) Lisp in school. You cannot get much more pure and simple than that. And maybe it will motivate the few that have the talent to go into software afterwards.

I'll admit the library problem in Lisp still exists today, though probably not in the same way. There are so many abandoned libraries out there it's hard to tell what to use. Though just a little bit of experience with Lisp brings an understanding of the library problem. You see, it's just too easy to write your own solution. I've spent probably 3x the time looking up libraries than I spend writing exactly when I need after finding out it doesn't exist.

There are two hard concepts in programming, and your list doesn't cover either of them. These are recursion (induction, for the theoreticians) and pointers (indirection, for the theoreticians). The idea of a pointer as something that is a name for a name for a name for a thing, at arbitrary number of levels of indirection, and that you can work with these instead of with identifiers (which are a single, fixed layer of indirection) is something that a lot of people, even those enrolled on computer science

The most people do not recognise ambiguity. People say things and then look at you oddly when you point out that what they have said also has a completely different meaning. The meaning they intended is usually obvious from the context but they are so locked on the context that trying to explain the alternative meaning is usually a wasted cause.

That mindset just does not handle programming at all well. "It's obvious" is a usually a disaster when you start thinking about programming because it's on

Everyone of us uses the concept of identifiers (think variables), when we say “he" instead of "Jim", or even "Jim" instead of shoving that person in front of your eyes.

False friends. Pronouns (he, she) etc are a closed set (think "keywords", not "variables"). And pronouns, like names, are fuzzy, context-sensitive references. It is precisely these linguistic constructs that make variables hard. We're not used to the fixed, uncompromising nature of an instatiated variable, and we're not used to the idea of strict scoping and overwriting of variables. I can talk about three different Jims without ever once making an explicit assignment declaration to the label "Jim".

Everyone of us uses the concept of sequences of commands, when making a to-do list.

You could learn to do cryptic crosswords. Most clues are modelled around a handful of patterns; general knowledge is a barrier, but you can allow yourself Wikipedia.

Your grandma could learn to program; it might not be worth it, depending on her age and ambitions.

All of these skills are learnt, learning takes time, and it's an opportunity cost. If I'd spent less time learning to code, I might have spent it learning to draw, or practising guitar, and I'd be better at those things. That's not about mental ability; it's about choice of specialisation.

As I said, there is a mechanical component, namely interfacing the tools. It is a minor part of the whole. You can learn to play the guitar all you like, you will never be a good jazz-guitarist or guitar composer unless you have quite a bit of talent. Sure, you can plunk the strings and may even be able to play sheet-music with some degree of accuracy. But that is not worth a lot.

The architecture and design of software is not something you can learn this way. Algorithmic is not. And the real-world problem analysis skills required to have your software actually solve a problem are not either.

Millions of people derive great satisfaction from mediocre guitar skills (I know people who get a lot of pleasure from their guitars, who can hardly keep rhythm). There's a class of people who could get value from *very* basic programming skills.

Difficult problems are difficult to solve, and require talent, experience and insight.Easy problems are easy to solve, and don't require as much talent, experience or insight.

Example: an artist using Photoshop decides he needs 20 layers in progression of shades. Creating each layer takes 8 mouse clicks, including a fiddly colour dialogue. Or, he could write a for() loop in some scripting language or other, and create the layers in a few seconds -- and add the tiny script to their arsenal for reuse.

Nobody is talking about Don Knuth. What we are talking about here is the equivalent of a musician that can entertain the crown in a restaurant in the medium price range.

I would also say that the very basic scripting skills you describe (no, that does not qualify as "programming"), are something people can either pick up easily by themselves, or have no chance mastering. Teaching something like this is entirely a waste of time. Talent is everything on this very basic level, and most people do not have the ta

Do what's actually happened here is that you've set a higher bar for your definition of "programming" than TFA's author.

TFA *is* talking about the very basic scripting skills I describe. Every advanced programmer started with that level of simplicity. Even if you never advance beyond that level of simplicity, scripting is useful. At the moment, lots of people who *could* benefit from scripting, do not, because the applications they use are not scriptable, or because the scriptability is not clearly signpost

Don't confuse programming with software engineering. The latter does require a good deal of talent, education and experience. But programming? I agree with the author that many people can learn, given the opportunity and the right tools.

Case in point: my high school taught a (somewhat unusual) computer class; this was in the mid-80s in what you might call a good high school (the Dutch high school system is divided in levels, the highest being "pre-university education" which was the level of my high school). The class consisted of some basic computer science (what is a computer, CPU, I/O bus, etc) as well as hands on programming in BASIC. This was a mandatory class which meant that we had a mix of geeks and non-geeks sitting in, but pretty much everyone was able to grasp the basic concepts of computing, logic, and programming, to the point were students were able to translate simple problems into working programs. Does this produce useful programmers? No, but it helps getting more people interested in the field, and in my current line of work I can see a clear difference between people who have had such a basic education in computing, and those who haven't. For people in IT who aren't actual software engineers, it's still useful to know a little bit about computers and programming.

To achieve this, having the right tools is important. Complex tools may be necessary when writing complex software, and a software engineer refusing to master complex tools because they are complex is silly, but for a beginner, complexity distracts them from what they are actually learning: writing a program. That's why BASIC is still a good tool for teaching laymen about computers; it might not be a very elegant language with stuff like GOTO, but beginners can have a working program up and running in minutes, doing simple input and output. Contrast that with something like C, which requires you to set up and master a compiler first, which is no easy task for someone just starting to program.

Your example of writing is a good one. Like programming, this too is something worthwhile to teach to the masses, and many are able to gain a basic proficiency in it. But you woudln't give a calligraphy pen (or a complex programming tool) to an amateur, you give them a BIC pen (or something like BASIC) so they can master the basics of the art without having to learn advanced tools as well.

Think about ALL the people in the world. There are billions of people who've learned to write, but how many of those can _really_ write a letter if they have to? I'll accept even people who write with bad grammar and spelling mistakes. All I want is people who can write an actual letter that is sufficiently intelligible to serve a simple purpose.

Well? I expect less than half of those who have learned to write are actually able to do so. And if they can't even write a letter after having been taught the alphabet, neither can they write a program if they would be taught BASIC..

I'm thinking of the other half, the billions who have learned to write and are now able to write something useful. And how many of those billions got inspired to write something great? Likewise, I think it is worthwhile to expose more people to computer science and programming. It gets more people interested in the subject, and a sizable portion of students should be able to learn something useful from a beginners course, even if they never actually do any serious programming later. Programming teaches

While I agree that it is worthwhile to _expose_ as many people as possible to programming, I think you are being overenthusiastic about the expected success rate.

Programming teaches logic,
expression of thought, and troubleshooting: all useful skills in many other
fields.

Yes, except... writing teaches logic and expression of thought too, in a much more freeform and forgiving way. It doesn't even need a computer, just a pen and paper. The fact is that as a civilisation, we aren't doing that well on the

Thank you, just my point. And if the letter suddenly needs to communicate a complex situation and how exactly to deal with it, and also includes reactions to uncertainties, then we are beginning to approach what software is. The arguments of all those here is alike to saying "Those that can write cannot only write any letter for any purpose, the can also program, as programs are written in text."

All I want is people who can write an actual letter that is sufficiently intelligible to serve a simple purpose.

Dear mom,
We're out of milk.

for(x=0; x!=100; x++)
if(cell(x,1) == 5)
cell(x,2).value = "good";

What? Do you think programming or writing are some sort of high art that the plebs can't comprehend? Doesn't my letter serve a simple purpose? Doesn't it convey a thought? Doesn't the for loop perform a function?
No, most people will never be professional programmers, or write "moderately complex" software. Because they don't have to.

but how many of those can _really_ write a letter if they have to?

No true scotsman fallacy. Get off your high horse.

I expect less than half of those who have learned to write are actually able to do so.

That's because you have an EXTREMELY jaded and cynical outlook on humanity. Go talk to some people.

if(milk.quantity == 0) { pick up purse
put on coat
put purse in coat pocket
open front door
go out of front door
close front door
take purse out of coat pocket
take key out of purse
lock front door
put key in purse
put purse in coat pocket
walk to car
take purse out of coat pocket
take key out of purse
unlock car door
open car door...
put milk in fridge
close fridge door}

An ad hominem argument, the hallmark of a mind that fails to come up with any good argument and knows it.

And no, you cannot teach everybody how to read and write. Not even in the western world. Oh, you can teach letters and words, but there is something called "functional illiteracy" and it is not rare. Wikipedia puts it at 14% of all adults even in the US. And programing is far harder than reading and writing.

I also have to say I am not at all scared about "the masses" finding out how easy it is to program

I am scared about all the damage they will do when trying to. And it has already started, e.g. with businessmen automatizing things using spreadsheets that bypass any organizational requirements for documentation, software quality, maintainability and even backup. These are disasters waiting to happen.

This is no worse than what 'professional' programmers are already doing to those same end users through zero-day exploits and bugs that confound easy use of their computing systems.

Why not build automation tools instead that not only allow end users to handle some of their own automation without shooting themselves in the foot - but also ties those solutions into the enterprise systems as well? Geez guys - this is not rocket science. For that matter, we could also create tools that limit what application

I am not confusing them. A reasonable programmer needs at least some software engineering skills. Otherwise you get people that write unreadable code, use the wrong algorithms that break systems because they just do not understand what goes in and the characteristics are, etc. Sure, once you have a detailed flow-diagram, putting that into code is just a mechanical exercise. But who do you think fills in the details here? A software engineer? Unlikely, far too expensive and then they could fire the programme

You're talking about professional programmers, in which case I agree that you don't become one by using a few simple tools and doing a few courses.

A programmer is someone who writes computer programs; any stricter definition is just elitism. If you can come up with (not just copy) 10 print "hello world"20 goto 10, you're a programmer, even though you're just a beginner. So is the guy with the smarts to write a few VBA snippets to tart up his Excel spreadsheet. These are just hobbyists or guys writin

Show me an artist and I will show you someone who wasn't afraid to make a few smears.

I don't see how any of this negates the argument that making the learning curve for getting started a little more shallow for those who need that could help more people learn to program. Its a useful skill, and frankly, I think a good one to learn. Teaches strong logical reasoning skills, is that not a good thing?

What's wrong with more "really bad" software being written? What's wrong with "everybody and their grandmother" thinking they can make software?

I *want* more people to have simple to use tools. I *want* more people to believe that they can write software. Why?

It exposes more people to software development (and maybe more people get passionate about it and become good). Most people I've run across who are REALLY good at this whole software development thing got their start fucking around with simple, accessi

There are two primary contributing factors to problems with respect to badly written software. One is that it's generally difficult to look at the software externally and determine its quality. I'm not an automotive engineer, but I can look at a 1980 Chevette, take it for a test drive, and determine that it was built from duct tape, bubblegum, and staples, and was not a well made vehicle. The same is less possible with software, which often doesn't offer those externally visible clues; and it's even more of a problem for non-developers to see its quality (or the lack thereof.)

The other half of the problem is that providing solutions of any kind (not just software) enable further external dependencies upon those solutions. The fact that it's a software solution may make some people believe that it's reliable in ways that it is not.

For example, a beginner programmer might write up some home automation code that turns on a light when the garage door opens. They might then extend it to make it dial a phone and play a recording when a button is pushed. And that's absolutely a great thing, because the kid is starting to learn.

The problem starts when Uncle Joe, who is not a software engineer, says "that's really neat, now give that button to Grandma so that if she falls she can push it and we'll go help her out." But the beginner's software might have a hidden fault that causes it to only execute when the garage door is open, which it was throughout its limited testing. What has been created is a program that externally looks good, and so it gets reused, but has had insufficient testing and is in no way well-engineered or ready for production use. And nobody involved in the project understands that until it's too late.

Not recognizing that the software is bad, someone then created an external dependency on that bad software. Grandma might fall when the garage door is closed, she pushes the button instead of dialing the cell phone because she believes the button will work, and instead goes unrescued for too long.

This is of course a contrived example, but it's amazing how much bad code is woven into so many different places in the real world, with so many dependencies on it. And once you add those dependencies, it's often very hard to change them. Believe it or not, I've heard the management equivalent of "We can't take the button away from Grandma now, what if she falls again? It makes her feel better."

This is not saying its bad for people to create software. What is bad is that people don't understand that what they've created is of low quality.

I just started experimenting Pure Data [puredata.info], and it is an example of an environment that does this quite well. Although it can be very complex when you dig down into it, it's very easy to get started with and create useful objects without the "fuss" that TFA talks about.

This is the problem with trying to simplify ("abstract") anything; you make the simple things easier and the slightly-less-than-simple things nearly impossible.

Something Microsoft also excels at in their products. As soon as you leave the narrow area of what they expected you to do, configuring Windows gets more cryptic than Linux kernel programming. You should always make things as simple as possible, but not more than that. This is one example of where the limit was crossed. With that, people are tricked into thinking they understand the problem, when in reality they do not. This prevents learning, realistic self-assessment and will produce any amount of fundamentally broken software.

It seems to me that a great deal of people have this idea in their heads that any and everyone is able to do any and everything. This is bollocks.Furthermore, blaming the inability to get interested in something or to cross a certain difficulty barrier on the tools is just laughable.

If one can't take the first step in programming and get acquainted to the tools, he won't be able to make the later steps either. It takes commitment and interest. Reducing the first barrier won't bring a lot better programmers, it will bring in a lot more bad programmers that get stuck half way through and don't really help anyone.

bullshit. some don't admit it but there's a hurdle to start programming, knowing where to start.

it can be as simple as sitting down with someone for 30 minutes, showing them how to write a bash script, save it, make it executable and run it. 10 more minutes for the idea of looping and a few more giving them a list of good sites to read when they're trying to figure something out.

6 months later I get an email from the guy asking esoteric questions about specific frameworks and has become his offices translator for when the needed to ask for software.

You are everything that's shitty about the industry. I'm glad I don't have to work with anyone as toxic as you.

It doesn't really take knowing where to start. I didn't know either when I began, I just picked a book that I found interesting and started reading it, following the examples in the book, etc.

Sadly I've made the opposite experience. I've tried to get a couple of people into programming, but it just didn't work out, even giving them a very simple start wasn't helping their interest. Sure, there's definitely people around there that are just waiting to be shown something until they can flourish, but I'm quite

Which is a little wierd when you think about it. If statisticians know so much about stats why'd they focus on a stats package that can give you incorrect results? Even the inventor says it was a mistake, but he couldn't grok Lisp at the time, so came up with R.

Most people understand the difference between learning fire safety for a day and being a fireman. They understand that learning CPR doesn't make them emergency room doctor. A few basic tools isn't supposed to teach them what professional programmers do except in a vague sense.

I don't think he means more professional programmers, but more people who understand programming. Just like it's great that every person nowadays learns to read. They don't all become linguists, but having that skill is an advantage regardless. I just don't think that people have a chance to understand programming without understanding the mindset of math first, so in my opinion if you want to teach people to code you should first teach them logical thinking.But while all people could benefit from learning

It seems to me that a great deal of people have this idea in their heads that any and everyone is able to do any and everything.

The term "literacy" suggests that it's about developing a basic understanding, as opposed to expertise. Using written language as the example, we've got a 98% literacy rate, but fewer than 1% are qualified to be professional writers.

Well said. The more I know and the more skills I acquire, the more things I find that I know I do not have the required talent to do. Not the drive, motivation, time, but the raw basic foundation. One of the most important things in your own intellectual development is identifying your limits and most often they do not come in the form of scale, but of area. For example, even highly intelligent people cannot understand all areas of Mathematics. Even mathematicians on PhD level cannot. And it is not a matter

If one can't take the first step in programming and get acquainted to the tools, he won't be able to make the later steps either.

I completely disagree. It doesn't make any sense to require that you start using the tools which the professionals use.

If you wanted to become even an amateur race car driver, you don't learn to drive in an Ariel Atom. A second hand Honda Civic is probably a good start. You don't even need to start with a manual car, since the important things when starting off are learning th

Along the lines of Siri but self contained. It would understand stuff like controlling the TV and the home security system. My mother could really use something like that and it doesn't have to be dumb either. You should be able to give it complex instructions in English and yeah it would be helpful if it could read lips.

He's saying programming is not as simple as Excel because programming doesn't have an equivalent of the SUM() function that does almost all the work for you when you are new to it.

Yet, excel never tells you that you have to use the SUM function, or that A:A means the whole A column, or that $1$3 means it shouldn't change the row/column when spreading the formulas. But he wants the development environment to somhow not require knowledge of how a loop works, or what an array is?

The problem isn't that programming is harder than Excel, at least not if you use a full-featured IDE with a decent language, like Visual Studio with C# 4.0. You can learn to drag a few controls to a new window, double-click on a button, and write something like "MesageBox.Show(textBox1.Text);" in seconds. No knowledge of arrays or functions necessary.

Programming is NOT harder than excel, and there ARE tools that make it as easy as possible. Anything else requires "visual programming" which he states he doesn't want, either. But of course, excel doesn't "hide the logic" from you, right?

The fact is, you need some basic knowledge to do any job. Excel requires knowing the syntax and function names, so does general-purpose programming, just like you need to know the parts of a car, and their use, if you ever want to build one from scratch.

My personal definition of the terms are that programming/developing are akin to seeing a problem and writing an application to solve that problem. Coding is taking a problem description and solution specification developed by someone else, and translating that specification into a computer program.The "coding" option only requires familiarity with the language and the coding tool being used, and seems to be closer to the process I think Adam and Bonnie are aiming for.However, the "programming/developing" op

For any of you professionals out there who has to deal with legacy code, you find that back in the 80's and 90's there were a lot of non-programmers who became programmers and most of them cut their teeth on Database Centered Languages. Like Fox Pro, Delphi, Access...For many of these non-developers the software they wrote got rather advanced, and often the business reason to replace these legacy systems isn't as much from a limitation of their coding (while looking at the code could make you cringe) but mo

I have to agree. I've always said that 50% of modern programming is having the right tools, and the right tools configured correctly.

Introduce someone to C. Now explain that even though C is standardised, there's no "standard" way to compile a C program, to port a Makefile, to have a program compile the same everywhere without manual work ensuring so, or even to start debugging. And then show then a Visual C++ project file and tell them they have to manage it and make sure it works even if their primary platform isn't Visual C++.

It can get horrendous. Sure, most Linux installs come with gcc set up and you can compile a basic C file and get a basic executable (called a.out with NO OUTPUT to tell you that, for stupid historical reasons, which still blows my mind), but anything beyond that and you're learning the tools more than the language.

I personally have a deep-set hatred of Makefiles. I honestly can't stand them as a programmer and avoid them like the plague. I get the C preprocessor inside-out and can fancy macro tricks that amaze even me, but I can't be bothered with Makefiles and their separate, unrelated, horrendous syntax. But as a user, they are great when I just want to make a simple change and then recompile without fussing about where my compiler path is, etc. All their alternatives? I have the same problem, but at least plain Makefiles work the same everywhere if they are well-written.

Even IDE's only mask those same details and thus cause more problems. Standard debugging of a problem for a beginner is to google the error messages from the compiler / linker because it really is that atrocious to try to understand what they actually mean.

I have a large C project on the go at the moment. It's several dozen code and header files and the same again in associated resources, etc. It took me an hour to work out how to stop it uploading the resource files to the SVN repository and even now I can break it when I add a new resource file without meaning to. It's a nightmare that only compiles because the IDE generates a hidden makefile, runs it through MinGW's make tools and then runs MinGW's gcc to get it to compile / link. I gave up about the five-object-file mark of trying to compile it myself but in other projects with other people's code, I've literally deleted the Makefile and wrote a bash script to do the job instead, they were that horrendous to understand.

Debugging is also a major bugbear. I know how to load a file into gdb, set a breakpoint, execute it and inspect variable values. Manually. And that's it. I don't even know what half the commands on the menus are supposed to be used for or the correct syntax to make them work and it's not like I haven't tried. Debugging is best done through an IDE that does it for you (still using gdb) and even then the tool doesn't get everything right (I often get out-of-sync line numbers when single-stepping through a program in Eclipse).

I have taught beginners programming since I was a teenager, and it's only got harder. If I was to write a book on, say, C now, I would feel obliged to supply a disk and include a chapter on how to find the compiler setup program, how to install it, etc. so that I could be consistent throughout the book knowing they were using the same tools and the same versions so I could show them how to debug, etc. Just saying "compile this hello world" can be a book in itself, depending on their background, experience, and computer setup.

I frequent a C programming board and most of the problems I see are people using obsolete tools (e.g. Turbo C presumably because it's "free" and their instructors were trained on it), or no tools at all (i.e. no capability to debug, manually typing in compile-lines, etc.).

The next most common set of problems is not understanding how to use those tools or interpret their errors ("_main is undefined", etc.). The next set is not understanding how to write something that doesn't give a compile warning/error (usually because they've star

To answer both above questions, I'm using C as an example. Almost all modern languages (including anything in.NET, even the more modern Visual Basics, Java, etc.) suffer from the same problems.

Python would also be included on my list. Hell, the programs I see written in python often bundle their own runtime copy of the entire Python interpreter when distributed because there's no way to guarantee what the end-user has and your program just might not work unless they have the right version. It's not as e

This has been tried so many times before. The simple fact is that most people can't program.

Simpler tools, or better tools, can ease the incidental burden of having to work with a program.

What they can't ease is the cognitive load of having to remember patterns, and abstract objects, and nested function calls. Most people can't deal with this.

Mr Wiggins has probably forgotten, as I have, the difficulties one faced and overcame when one first learned to program, and so he's forgiven for thinking that if we just made the environment simpler anyone could do it.

I'd argue that python at the shell is pretty simple, but most people can't or aren't motivated to do even that.

This thinking is like saying "a full piano is too difficult, so if we give people a little toy piano they'll be able to learn to play".

This has been tried so many times before. The simple fact is that most people can't program.

Only because they never learned how, not because they're incapable of writing computer programs!

Most people don't see any benefit to learning how to program, and so they don't bother to learn. The absurd, unnecessary, barriers that aspiring learning face today is enough to hold back all but the most dedicated. How many people's lives have been made more difficult because we've locked-out the home user with unnecessarily complex tools?

We're a long way from the old days, where all you needed to get started

This thinking is like saying "a full piano is too difficult, so if we give people a little toy piano they'll be able to learn to play".

When I was young I had a little Casio keyboard with auto-accompaniment. It allowed me to experiment with chord progressions using major, minor, major 7th and minor 7th chords, before learning to play those chords manually. It's not a bad thing. 30 years later, I'm able to transcribe chord progressions almost without thinking - something a number of my musical friends find astonishing.

Perhaps I'd have developed that skill without the dumbed down learning tool - but it definitely lowered the barriers to entry.

This is gtoing to happen, it only a question of when and that includes the if an when you get to do so in your lifetime.

It tooj 300 years for the Hindu-Arabic Decimal system to overcome the Roman Numeral system of mathematics...why? Politics o0f thoise who didn't want to lose their position inj society. But Abstraction Physics isn't about some subset of abstract, such as mathematics, but all abstraction,

Well, duh. Everyday tasks have already been programmed. The only way to teach people to solve new problems is to present the technology with some (over-simplified for clarity) examples.

I still remember one of my first book about Lisp. One of the very first examples was how to analytically differentiate an expression. Now that is a good example. It shows that, even with very basic Lisp, you can do things that are unheard of in other programming languages. Only such examples teach you the mindset of a languag

I never understood the obsession with introducing people to programming using a programming language. You basically cannot do anything "out of the box" without first covering a wide amount of topics(including storage, ie variables, types etc). This is enough to turn a large # of people off, so why not start with tools that allow you to write "programs" without having to worry about types, variables etc. we already have such tools, they are called sed and awk(and others) most of what your average Joe is g

Computer literacy is decreasing though because as a society we aren't focusing on it. Computer literacy courses in school should teach basic programming. Having at least coded in Logo would make a huge difference in people's ability to understand computers.

HyperCard, from Apple back in the day, was a pretty good environment for knocking out simple little programs that almost looked professional. And it was free. It really was what you're describing, though the language was pretty limited. VB stole a lot of ideas from Hypercard and made it a bit more complex and platform limited and you had to pay for it. JavaScript could step in if the DOM wasn't so confusing. It's probably not ever gonna happen. Programming environments that aren't hard to use always ge

I'm forced to agree with an underlying point: poor tools discourage students from striving further. Modern carpenters don't have to cut their own boards from trees in order to get planks, nor do they have to mine their own ore and make their own nails to learn carpentry. But in modern technology, too often we have to do just that sort of assembly of a complex toolchain to get our tols working. The result is a lengthy and often burdensome apprenticeship learning mechanical skills. Masterpieces are much easie

Recently trying to deal with an open source project. all the C code is a mess of structs within structs. Defining a struct for frisking A and B throwaway variables is insane. readability of code has turned into a nightmare with all this misuse of the languages. yet it's the current "trend".

how about tools on how to teach programmers that being "clever" or what your professors taught you is not always right?

Putting programming within the reach of every-day people is to harm [further] things in two ways:

1. Adds to the complexity of knowledge of users and thus creates additional potential for things not working.2. Reduces further the power and flexibility of most programming which results from the need to reduce the risks of #1.

The kind of high-level programming we are doing today is more "black box" dependant than ever before. When I learned to code, it was BASIC first but then quickly into assembly language for some popular motorola processors. In that realm, I learned to write pretty much everything about how to get input to how to send output. Admittedly there were stll black boxes, but the black boxes were essentially "interacting with the OS" which is one black box we need.

But when the very language we write in is a black box I begin to worry more and more about the mentality of programmers who don't understand the underlying details of what really goes on. I recall someone saying "why do checks this way? use REGEX!" I was like "uhm... what do you think regex routines are doing???" Once again, black box dependency obscures people's understanding of what computers are actually doing.

I'll get off my soap box now, but I will close with this: The problems with today's software is programmers who don't understand computers. This division of "hardware guys and software guys" is ridiculous... every bit as ridiculous as the idea of separating the head from the body (mental and physical) in the practice of medicine.

Despite common stereotypes, programming is not out of reach for the average person

Hahaha, no.

Shit like this is the reason I need to get my ass back to college already and change careers away from computers, as fucking far away from them as I can get.

Everybody I work with who has not tried thinks that programming is just so fucking simple.

Guess what?

It's not that fucking simple.

You have to be willing to ask "what if?" You have to be willing to admit you've made a mistake when you find a contradiction in your algorithm. You have to be able to admit you've made a mistake when y

I recently decided to try my hand at some mobile app development after 15+ years of programming experience with mostly other non-related tools. The setup was just painful, it took me an entire weekend of tinkering around trying to figure out (ie google search) why various things weren't working/not compiling etc. Once I figured out the methods of getting things setup that works, its fine now and I have been working away with few issues and could start over again in no time. The problem though is that unt

One claim is that 199 out of 200 people applying for a coding job cannot code at all. The examples given are hilarious (or deeply depressing) and there is every reason to believe the observations described. Some of the links are also eminently worthwhile.

I know, that sounds like a contradiction in terms, but one of my college profs made a good case for the concept.

The value of learning programming for non-programmers is not "I have to get that *@$% computer to do what I want". It's "I have to learn how to break down a large problem into simpler smaller problems, until I know how to solve it." and "I have to recognize the adjustments and adaptations that humans naturally make when solving problems." And as a side effect, it also teaches the important lesson that some problems cannot be solved by convincing people around you to believe in nonsense.

Not sure really, understanding an article written by an anthropologist on programming seems harder than kernel development to me. But you're probably on the right track though. Other requirements from what I gather are a one-click install and a Microsoft Bob equivalent to ask what you want to achieve.

I'm not sure he knows what he's asking for, but I think I know what might address his concerns, and it's basically more embedded languages in apps that people use.

Lots of people learned simple procedural programming with Word/Excel macros. Record a macro, look at the code generated, amend it. Now some people do it with VBA, but I'd say that VBA is more hidden than the old macro language was.

He says people respond "OK, that's cool but what could I use it for?" - and the answer is anything repetitive or mundane that you find yourself doing at a computer. If you find yourself repeatedly going through the same sequence of clicks, a coder thinks "I want to automate this loop". A non-coder just accepts the drudgery.

The Raspberry Pi version of Minecraft can be automated with Python. Anyone who's laboriously built something brick-by-brick, click-by-click in Minecraft out to be impressed by a few lines of Python doing the same job in the blink of an eye. We need more apps that work like that. We need to get to the point where people demand it.

Why not hire someone to fill the place within the organization? I interact with a lot of people on a day to day basis who are very smart and knowledgeable within their fields, but when it comes to automating some mundane task or sharing information in a structured way it's outside of their area of expertise.

There are three possible approaches in that scenario:

They learn how to script / code themselves (most of them won't have the time/stamina, and even if they did they wouldn't be able to share the results so you get duplicated effort)

They hire an external company to write the software for them (but the overhead of dealing with another company that doesn't know your business and needs formal requirements can be huge, and you can still get the duplicated effort / lack of sharing)

You have an in-house team (3 people for 1500+ employees does the job for us), that manages custom software for specific purposes. They can direct people's requirements to either being 3rd party, having too high cost / reward, or requiring in-house software. With access to all the existing databases, with intimate knowledge of the business, with ties to various departments within the business, they have not only the skills but also the business knowledge, the access, and the relationships, to ensure that necessary software can be developed quickly, efficiently, and then propagated to any other staff / projects which need the same thing.

You can't have an in-house team that tries to reinvent the wheel and write software where it's unnecessary, that's pure waste, but for a large organization having a small team that can take care of things that really do need to be done in-house can give a big competitive advantage.

Considering that a basic devkit like Eclipse (sufficient to write a lot of Java code) can be set up by downloading, unzipping and double clicking on the file with the colorful picture, I can only concur.

Considering that a basic devkit like Eclipse (sufficient to write a lot of Java code) can be set up by downloading, unzipping and double clicking on the file with the colorful picture, I can only concur.

You are missing a few steps, like installing the JDK and possibly installing the JRE, figuring out what the heck this workspace thing is. The Hello, World example you copied from the Internet also doesn't work because the package doesn't match. Congratulations, Hello, World compiles in Eclipse, but you want to see it as a standalone program. You click on your.java or.class file, 'Windows can't open this file'. After googling the problem, you find out that you need to run it from the command prompt by typing "java hello.class" so you become comfortable with cd.. until you get to your workspace and find the 'bin' folder. You try it, 'java can not be found or recognized'. Now you have to add the jdk to the path.

Nonsense. People do it all the time. At the office, it's more than just the development staff, everyone with a job that requires more than answering a phone, from the executives to the maintenance staff, employ "algorithmic thinking" to identify and correct problems as diverse as developing policies and procedures to why the furnace kicks out.

The backyard mechanic, the hobbyist baker, and the new homeowner tackling their first DIY projects all employ the same set of thinking skills that the computer progr

Problem is most are a PITA to set up for the more interesting things. Compiler for a boring PC? easy. but writing code for embedded processors like a Microchip or TI MSP430 are 90X more fun and satisfying than writing yet another twitter client. Setting up those compiling environments are a royal huge PITA. In fact last night I blew 4 hours getting it all set up for the MSP430 on ubuntu, the only distro that has most of what I needed in a repo so I can just apt-get it all. and learned that Ubuntu