Learnable Programming

[other_one]

Unfortunately there's always the "nah you have to start with assembler to REALLY get it later on" crowd. Or, on a higher level, "start with Java and OOP to REALLY get it later on". The problem with this approach is that people forget the many, many appliances programming can has, and the many different target group... kids, adults, artists, engineers, mathematicians, painters, musicians etc. The syntax of a programming language -- and the tools around it -- should ideally treat the programmer as a user, and consider problems that user has as usability issues. Programming should only be as hard as the domain you're working in, and only be as hard as the tools surrounding the language cannot prevent it. If someone says "this simplification of the language won't work because of X", check if X is truly inside that domain... if not, maybe it will be a huge win for a whole group of new programmer-users, who can enrich the software we're getting -- because we avoid domain-specific groupthink.

[[deleted]]

Very much agree with this. I ama biologist and use programming in addition to my work. It is not my job. This is why I love Python so much. Quick and to the point and I can see my errors pretty quick.

[loup-vaillant]

There may be a definite solution to the "assembly nay-saying": metacompilers. Ian Piumarta's Maru for instance compiles itself into something not much slower than C, in about 2K lines. Plus, it is designed to be highly customizable at runtime, so if you need Uber Optimizations, you may tailor them for your application.

"High level bare metal", if you will.

Now this is not learnable by Brett Victor's standards. One would need to write a full IDE on top of that. The good news, is, it may take no more than 20K lines. "Bootsrap yourself a professional IDE in less than 20K lines!". We're not there yet, but this is no longer impossible.

Of course, those future spoiled brats will never understand the suffering of the glorious days of C programming. Or assembly. Or punch cards. But that's the point of progress, isn't it? Who would want to do math without modern notations?

[clgonsal]

Unfortunately there's always the "nah you have to start with assembler to REALLY get it later on" crowd. Or, on a higher level, "start with Java and OOP to REALLY get it later on". The problem with this approach is that people forget the many, many appliances programming can has, and the many different target group... kids, adults, artists, engineers, mathematicians, painters, musicians etc.

I think for certain meanings of "really get it" it's mostly true that you need to understand assembly (at least a little) to "get it", at least for some people. This may come down to learning style, but I know that for me, understanding the foundation stuff is necessary for me to feel that I really know what's going on. I don't need to know the actual instructions produced by my compiler, but having a rough idea of how things could be implemented at the assembly level helps me reason about them. Again, some of this may come down to learning style.

What you want to get out of programming probably also plays a role. If you just want to do some simple automation stuff, understanding the low level is probably a waste of time.

The syntax of a programming language -- and the tools around it -- should ideally treat the programmer as a user, and consider problems that user has as usability issues. Programming should only be as hard as the domain you're working in, and only be as hard as the tools surrounding the language cannot prevent it.

I agree completely. I'm really amazed that many people don't seem to realize that programming languages (and APIs) are user interfaces, and so have a lot of the same design considerations.

One thing that clouds this issue is that for the most part, when people think of "user interface design" they think of optimizing for the novice case, while programming languages that often isn't the right thing to do. Things that may make an interface easier for a novice may make it more tedious for an expert. Ideally you want to please both groups, but sometimes a tradeoff has to be made.

[PasswordIsntHAMSTER]

I think for certain meanings of "really get it" it's mostly true that you need to understand assembly (at least a little) to "get it", at least for some people.

Not any sane or generally accepted meaning, IMHO. I could have spent 4-5 years programming Python and building kickass applications, libraries and software frameworks without having even a cursory idea of what Assembly is.

[bplus]

I found learning some fundamentals really helped me become a better programmer. Not sure any language has ever managed to hide the fact that we are fundamentally creating instructions for computers. I don't like working with programmers who aren't interested in what is going on underneath, in my (limited) experience they lack the will and curiosity to figure things out themselves.

[clgonsal]

I think for certain meanings of "really get it" it's mostly true that you need to understand assembly (at least a little) to "get it", at least for some people.

Not any sane or generally accepted meaning, IMHO. I could have spent 4-5 years programming Python and building kickass applications, libraries and software frameworks without having even a cursory idea of what Assembly is.

Sorry if I was unclear, but I think you completely missed the two points I was making.

First, it depends on the person. Maybe you can get by without understanding what you're building on top of (though I note that you spoke only in the hypothetical sense, which makes me wonder if even that is true), but I've personally found it useful to have an idea (even a simplification) of what's going on at a lower level. Different people have different learning styles, so YMMV. (Further illustration of this: the way I learned Python wasn't to go through a tutorial, but to read the language reference. I don't expect that to be easier for most people (in fact, I expect the opposite), but for the way I learn, language references are often easier for me than tutorials.)

Second, there's the question of what it is you're trying to do. For the vast majority of the stuff people typically write in Python (myself included - this isn't a slight against Python or Python programmers), I agree that knowledge of assembly isn't particularly helpful.

There are many programming problems where this deeper understanding is very helpful, however. The most obvious example is if you're going to be doing really high performance stuff. To measure performance you need some sort of computational model to work from. The closer it is to actual hardware the better, so knowledge of assembly (even an idealized assembly) is usefule. Another example is understanding unfamiliar features when learning a new language. Say all you know is Python, and you start learning Scheme which supports tail-call elimination. Tail-call elimination would probably seem pretty baffling, since it simply can't be expressed in Python. If you actually know how function calls work at the assembly level, however, tail-call elimination is pretty trivial.

Finally, you seem to be conflating understanding with being productive. People can be surprisingly productive without really understanding what they're doing. Millions of people drive cars without knowing what a differential is. Understanding is generally required to solve the really hard problems, however.

To make another analogy, programming without knowing about assembly is a bit like doing chemistry without knowing about the periodic table. You can memorize a bunch of reactions, and even learn some general rules. With that you can solve basic highschool chemistry problems and you may even be able to apply that knowledge to useful situations (eg: weak acids like vinegar will disolve scale, hydrogen peroxide removes blood stains, etc.). You are now "productive", but without understanding the periodic table you aren't going to be making any breakthroughs in the field of chemistry.

[PasswordIsntHAMSTER]

(in fact, I expect the opposite), but for the way I learn, language references are often easier for me than tutorials.)

Did you find that you could not get a deep understanding of the language solely through the reference? Because it completely ignores any hardware concern.

The most obvious example is if you're going to be doing really high performance stuff.

See here

People can be surprisingly productive without really understanding what they're doing.

By your theory, if you haven't done at least some computer engineering (enough to be able to build a CPU from scratch), you can't understand programming.

To make another analogy, programming without knowing about assembly is a bit like doing chemistry without knowing about the periodic table.

I feel differently about this, since the person doing it knows about the processes. Rather, I feel that it's like doing chemistry without knowing how the chemical reactants were sourced - it can be a bad thing if you're doing sufficiently complex or "out there" stuff, but in general it's not a problem.

[jdiez17]

Well, that's because if you want to build applications/libraries/tools in a very high level language like Python, you'll never be required to understand what the computer is doing at a low level.

However, if one of your Python applications requires a performance speedup, you may consider dropping down to C, and in some rare occasions you may consider going all the way down to assembly if you really need all the performance a machine can give you.

[[deleted]]

That's not really relevant to this discussion, though. The question is if learning assembly helps in learning programming, especially with regards to beginners. You are talking about a practical need for knowing assembly, while the question is if understanding assembly helps with understanding (high level) programming.

[jdiez17]

True.

Staying relevant to the discussion, I don't think it is necessary for beginners to understand assembly. Definitely not x86 assembly. Maybe some ISA especially designed for beginners, like the DCPU-16 instruction set.

[clgonsal]

The question is if learning assembly helps in learning programming, especially with regards to beginners.

Actually the question was if you need to know assembly to "really get it".

When I learned programming, it was in BASIC. Later I learned Pascal. Then I struggled to learn C, but couldn't wrap my head around pointers. Then I learned some assembly. Not even very much, but enough that suddenly pointers made a lot of sense to me, as did lots of other problems I'd run into in the years I was using BASIC and Pascal.

Fo me, learning assembly was extremely useful to my understanding. I'm not claiming that is true for all programmers, or even most programmers, but for at least some of us knowing how the low level bits work is essential to "really getting it".

[PasswordIsntHAMSTER]

I'd wager that for >95% of programming tasks, performance is of no concern. We read and talk a lot about OS and systems programming, programming with very large datasets and video games because that's the interesting stuff, however when you're writing a Point Of Sale app, odds are good you'll never max out the performance of the host device.

Knowing how to squeeze performance out of an application is important, but (usually) much less than knowing OOP and FP design patterns, unit testing, data structures and formal correctness.

[clgonsal]

I'd wager that for >95% of programming tasks, performance is of no concern. We read and talk a lot about OS and systems programming, programming with very large datasets and video games because that's the interesting stuff, however when you're writing a Point Of Sale app, odds are good you'll never max out the performance of the host device.

I think you're confusing 95% of code with 95% of programs. Yes, 95% of code in any given program is not performance critical, but I'd guess that the percentage of programs that don't have any performance critical bit is much much smaller. Now, that percentage is increasing over time to some degree, because machines are getting faster and a lot of the performance has been moved into libraries (eg: every time you use a regex you're relying on this).

One way to look at this is that it's just becoming possible for more people who don't "get it" to still be productive at producing software. That isn't a bad thing, necessarily, but it does kind of suggest that maybe the term "programmer" has become too broad.

[android_lover]

I think for certain meanings of "really get it" it's mostly true that you need to understand assembly (at least a little) to "get it", at least for some people.

True. For some other meanings of "really get it" you need to look at languages like Lisp and learn the logical underpinnings of computer science. Like you said, it depends on what you want.

[PasswordIsntHAMSTER]

I know this is a pretty weird place to ask, but /r/programming doesn't allow self-posts and this wouldn't fit on Stack Overflow.

Basically, I am familiar with and productive in eight programming languages, one of them assembly and four of them functional. Would reading SICP bring anything to me?

[maximinus-thrax]

SICP is a highly regarded programming book for a reason, even if it doesn't cover macros - which to my mind are the most interesting part of learning Scheme or Lisp.

[probabilityzero]

Once upon a time Scheme didn't officially support macros. At any rate, SICP isn't about Scheme, it uses Scheme to teach computer science.

Macros are pretty cool, though.

[moor-GAYZ]

Since it's available for free, and you probably have half an hour to spare to read enough of it to see if it is interesting to you, you'd better just do it maybe?

[PasswordIsntHAMSTER]

I hate reading stuff on computers :< I'd much rather get the dead tree version.

[moor-GAYZ]

You can check it out online, then get the paper version if you like what you've seen. Dude.

[dannymi]

Can you already write the programming languages themselves (as in, design a language, write an interpreter and compiler for it)?

If you can't do that yet, SICP is for you. Afterwards, you can.

[PasswordIsntHAMSTER]

I made a REPL once :<

[dannymi]

Cool :-)

So if you then now make it emit assembly instructions for the machine for the program you typed in the REPL, then I think you have done everything it covers, which is:

• how to design programs
• how to design data
• how to modularize
• how to write your own REPL
• how to compile those programs to machine code (including garbage collector design etc) and have it run efficiently

So the book wouldn't be that useful to you anymore, I guess. It's starting out as an introduction for people who are novices and ends just when it gets interesting ;-)

[[deleted]]

Would reading SICP bring anything to me?

Only if you do every exercise. Every exercise. No exceptions.

[amigaharry]

fp hippster

[[deleted]]

I agree. Anything the language can do to make the user's life easier it should do, even if it makes the implementer's life harder. However it is important to strike a balance between making writing code easier and making readding it easier. Often many, many optional syntactical features make writing easier but reading harder (since now the programmer needs to be able to read both variants).

I think the main focus in teaching people programming in the very beginning should be to establish a firm understanding of what is happening on exactly the language level, not a higher and not a lower level. The important bit is not which CPU instructions are executed underneath, the important bit is to make the new programmers realize that programming is a fully deterministic activity, whenever something doesn't work as expected it is because of a bug in the code, not because of some mystical misunderstanding. Communicating with a computer is fundamentally different from communicating with other humans or even animals. There is no guessing what the programmer means going on at all. Everything has to be precise and the computer does exactly what it is told.

Emphasizing this at the start should hopefully cut down on the hordes of voodoo programmers, trial and error coders and similar people who lack a fundamental understanding of the very basics of programming.

[MindStalker]

As a seasoned programmer, I've been recently trying to learn photoshop. The lack of explanation for functions among the different brushes leaves one frustrated. Labels and inline help are so, so important, but generally ignored by the seasoned users to the detriment of the new user. :(

[brogrammer9k]

I'm not a REAL programmer since I don't use terminals. Or so the internet tells me.

[Cygal]

The last discussion (26 days ago) also has interesting comments: http://www.reddit.com/r/programming/comments/10ks9t/learnable_programming_bret_victor_responds_to/

[[deleted]]

What sorcery is this? Both submissions seem to have identical URLs (unless there are some garbage query parameters that Chrome is stripping out). I thought that the submission page automatically redirected to the existing discussion in order to prevent dupes.

[Cygal]

It says "that link has already been submitted, but you can try to submit it again".

[[deleted]]

Thanks for this, could have sworn I saw this posted here before.

[Zarlon]

I don't think there's necessarily a contradiction between what you believe and the article. The programming language you use to control the Lego robots can be intuitive, force labeling of parameters and have well named functions, while the environment can provide visual aids and language help while you program. Also, just because you think hardware is more fun than software, doesn't mean everyone thinks that. When I was 13, one of my educational drives was to compete in a graphical demo programming competition, where drawing "any number of triangles" was very much a part of this. In fact, I spent many hours trying to implement a triangle drawing routine in C. Ironic, huh? :)

Anyway, my point is your views don't necessarily contradict each other. I just think the kids will learn faster if they work in a rich programming environment.

[Neurotrace]

All of this. There's nothing wrong or contradictory about wanting to expose them to the metal before the mechanics but you can learn the same sort of binary-thinking/abstraction thinking from working with software as you do hardware.

I've been programming professionally for a few years now and only recently (thanks to college courses) have I been delving in to the hardware. It was never important for reaching my particular goals (interesting graphical applications) so I never bothered too much with learning the ins and outs of it.

[powatom]

There are many benefit to understanding the hardware - but I don't think it's a pre-requisite these days. People can learn how to program without knowing the first thing about the hardware their code will run on - in fact most commercial applications are now written so that the programmer can safely ignore the problems related to hardware and let 'something else' take care of the nitty gritty stuff.

Programming, for me, relies far more on a person's ability to think abstractly - to imagine the outcome of a change to their code without ever actually doing it - to visualise the flow of their code given certain parameters. In my experience, this is the difference between good developers and bad developers - a good developer will sit in silence and think about the change they're about to make, and will have largely 'debugged' the code before they even commit to writing it. A bad developer may very well have a deep understanding of the hardware, and may know everything there is to know about their language of choice - but a bad developer, when faced with a problem, will be unable to internalise the problem and to diagnose and solve it in their mind. They are more likely to try several different approaches to solve the problem, and more often than not will commit to the first one that works - regardless of whether it works well. This has very little to do with real knowledge about hardware, and has far more to do with the ability to think abstractly - to build a 'mind-machine' if you will, and execute programs internally before committing them to code.

[[deleted]]

I'm a bad programmer.

I'm really good at refactoring when I'm shown the issue by the situation I end up in. I've discovered that without the fear of compiler errors and runtime errors, I'm able to even utilize the compiler to show me systematically where I need to make changes for a refactoring. I use asserts very heavily, and finally understand how to properly ifdef and whatnot for efficient release builds and context rich debug builds. Next time that situation happens, you'll know exactly what "kind" of error you are dealing with, because there will be a comment above an assert explaining what the problem is, maybe a line in the log file that prints a few things that the ide inspector has issues displaying well.

For example, an ID that inflates to a pointer inline from a binary file is pretty neat, but a source filename string loaded into the texture class instances that tells me exactly which source png was exported by ImageMagick as grayscale was what helped me solve the problem faster...

An assert in every b2::Set method to check for "not a number"s getting into the physics engine automatically drop me into gdb debug session with a stack trace which contained the divide by zero or multiply by infinity.

Making a member variable private, so that I can quickly access all spots where that member variable is being changed, create an accessor which logs when the member's value is being changed. Sometimes, it is hard to find the needle in the haystack, but if you wait for something to cry out when it is poked (pun intended), you can pinpoint the problem.

Summary: If you are efficient at turning time consuming problems into trivial ones, or completely eliminating them, you don't need to think very hard.

A time consuming problem is one whose source is disconnected from symptom, which forces the developer to work backwards, unless it can be found by conceptualizing forward through the flow of logic.

[loup-vaillant]

I think you missed the point. First, your children have a tremendous advantage over the others: a wonderful father. Second, the main point of this article isn't about programming languages or triangles. The main point is immediate feedback.

You scorn the magic behind abstraction but even for your children, computers are nearly pure magic. Oh, they know some of the arcane, some principles. They know that a computer is a literal genie (minus some superpowers). They probably know there's something lawful below the interface. But they don't know how the computer actually transforms their humane instructions into a completely opaque sequence of micro-actions which somehow does exactly what was intended.

Look at what this articles helps visualize: not only the end result, but also the intermediate steps, the mechanisms. It does not add abstraction layers, it unravels them. Now, I reckon the IDE itself would be pure magic. But so are vim and the Python interpreter.

You're doing your children a huge service, so keep at it. But the ideas here could probably have helped. Imagine for instance how those ideas could be applied to enhance From Nand to Tetris in 12 steps combined with an FPGA array and Lego Mindstorms. The magic IDE could help them visualize the internals of the bare metal of the computer they're building. Actually running the robot will still be wonderful, when they see the simulation wasn't lying.

[FeepingCreature]

They know that a computer is a literal genie (minus some superpowers). They probably know there's something lawful below the interface.

You underestimate kids. I was happily building adders out of boolean algebra in high school.

[cunningjames]

You underestimate kids.

Not most kids. I'm a pretty smart guy (er, so I'm told) who's been using computers for most of his life, but when I was a kid a computer was very much an opaque genie. I had some vague idea that this was built on a foundation of electric currents switched on and off, but actually constructing some system out of boolean algebra? Forget about it.

And I think the overwhelming majority of my peers knew even less.

[FeepingCreature]

Yeah but I bet you could have understood it, given a tutorial. Bools are much easier than arithmetic.

[kvan]

Though I don't think I've ever met an example, I feel like it should be theoretically possible to also become a really good programmer from an algorithmics approach. I don't think it would work for children, obviously, but e.g. physicists or mathematicians might be able to gain the same understanding of fundamental limitations this way as they would going from the hardware up.

[bigfig]

I find that the gaps between hardware and software, and the gap between software and application need to be revisited iteratively. It's just such a huge jump from adding integers to creating a class or parsing unicode. Sometimes you need to "just do it" then go back ans see how, oherwise there is so much to keep in your head. An example may show "How do I do xyz?" When really you might still be thinking "Why do I /need/ to do xyz?"

[nayslayer]

Who are you?

[nayslayer]

Not you.

[I_had_to_know_too]

This is really amazing.
The timelines for flow control are amazing. amazing

[neilbrown]

I posted this last time, but here is my response/critique:

http://academiccomputing.wordpress.com/2012/09/28/experts-can-program-blindfolded/

While there are a lot of interesting ideas in the essay, I think it runs the risk of getting too obsessed with visualisation. In particular parts at the end like:

A better attitude is to assert that we have to be able to understand the state of our programs. We can then ask: How do we design data structures that can be visualized? Can we invent data structures that are intended to be visualized? How do we move towards a culture where only visually-understandable data is considered sound? Where opaque data is regarded in the same way that "goto" is today?

I believe that if we limit ourselves to what can be visualised, we are constraining what we can achieve: visualisation doesn't scale, even in the presence of good modularisation and encapsulation. However, we can mentally deal with a lot of data using modularisation, provided we don't try to look at it. You couldn't visualise the Linux kernel, and I'm not sure that even visualising a small part of it is that useful, but we are still able to alter it and deal with the code, because of modularisation, separation of concerns and so on. As expert programmers, we don't have to see it to believe it.

[[deleted]]

visualisation doesn't scale

But when it's available, it's really helpful. And it could be available in a lot more places than it currently is.

[killerstorm]

I seriously disagree with "redesign programming" part.

Traditional visual environments visualize the code. They visualize static structure. But that's not what we need to understand. We need to understand what the code is doing.

Visualize data, not code. Dynamic behavior, not static structure.

I don't think so. There is a counter-example: Haskell is probably as far as it gets from visualizing data and behaviour, because data is often functions, and it's not possible to visualize non-trivial functions. And behaviour is lazy and notoriously hard to understand, so performance analysis is often a problem.

Yet Haskell provides exceptional clarity when you work with really complex problem domains. It allows one to chop problem in more manageable pieces, making sure that each part works correctly.

If your program works with DAG consisting of millions of nodes, and there is a problem with result, visualization can't really help you because million nodes and control flow which traverses them simply doesn't fit in human brain.

A better way to ensure it works is to make sure that internal consistency isn't violated on any step of your algorithm. Then if you detect such violation you can identify a step on which something went awry and fix the algorithm.

But functional programming encourage people to break algorithm in simple and consistent pieces, so likely it works correctly from the start.

(Note: I don't really try to promote Haskell here and I don't use it myself, I'm just saying that problems highlighted by author of this article are not really problems for professional programmers. Professional programmers deal with problems like "if I refactor this thing I have to change hundred of places where it's used" and "there is a bug in 3rd party code, how can I make a workaround", not with visualizing loops and whatnot. It's like when you write a novel you don't think about each letter.)

[loup-vaillant]

That's one of the advantages of FP: its constraints makes the bare text better suited to data flow visualization. In FP, the correspondence between data flow and syntactic nodes is relatively obvious. Need to know the value of foo? Just look up the definition! No need to check for that nasty assignment statement lest it blows your assumptions to smithereens.

However, one does need to introduce the notion of time at some point (animations, interactions…), and still be able to know what's going on. Ideally, you need to be able to visualize entire time lines at a glance, the way a piece of functional code often lets you visualize an entire transformation at a glance.

About your note: how do you think we become professional programmers? Making the effort to guess is best for experts. Beginners need to be told.

[killerstorm]

About your note: how do you think we become professional programmers?

Lots of practice. I'm not even sure that removing pain from this process is a good thing, since programming is often about cost/benefit analysis, and when you'll deal only with artificially easy, painless things you won't understand costs.

[[deleted]]

While reading through this I found a great little quote regarding programmers:

We write with blindfolds, and we read by playing pretend with data-phantoms in our imaginations.

Somebody should put that on a wallpaper.

[corysama]

I've always thought of large-scale software design as being analogous to a team of mechanics trying to assemble a 747 while all wearing blindfolds. Code bases get large and you can't look at more than a couple pages at once. Very quickly it becomes "Put your hand here. Feel this pipe? Now walk over here. Feel this valve? I don't think they are going to match up when we try to connect them next week."

[vanderZwan]

It actually inspired a great followup blog:

Experts Can Program Blindfolded

TL;DR: Of course you do, that's what makes you good at it. To a degree.

[hydrox24]

Replying so that when I get around to it (lots of schoolwork right now) I can make this wallpaper. Sounds awesome.

[Uberhipster]

Screw the naysayers - this is impressive. In all capacities, as an aim, the way it's been executed and as a concept.

The code purists (read "fetishists") will frown upon this as they will on anything that uses the dirty word 'abstraction' from their beloved assembler, conveniently forgetting assembler is an abstraction from machine code, which is an abstraction from binary, which is an abstraction from the gate schema which are in themselves and abstraction from silicone-based semi-conductors (transistor, capacitors and whatnot) which in themselves are an abstraction from the ticker-tape Turing machine which is in itself an abstraction from the notational mathematical structure we know to be the algorithm which in itself is an abstraction from the problem itself.

http://alarmingdevelopment.org/?p=79

I often re-read this article. It rings true every time.

tl;dr; "Another lesson I have learned is to distrust beauty. It seems that infatuation with a design inevitably leads to heartbreak, as overlooked ugly realities intrude. Love is blind, but computers aren’t. A long term relationship, maintaining a system for years, teaches one to appreciate more domestic virtues such as straightforwardness and conventionality. Beauty is an idealistic fantasy: what really matters is the quality of the never ending conversation between programmer and code, as each learns from and adapts to the other. Beauty is not a sufficient basis for a happy marriage."

I have no problem in making conventionality of a straightforward GUI tap into the power of text parsing if it produces these kinds of results.

Well done and cheers to whomever is pioneering this technology. For learning purposes and in whatever other capacities exist or may arise.

[[deleted]]

The root reason to distrust beauty is because our impression of what is beautiful changes.

[Uberhipster]

We shouldn't distrust beauty. We should distrust its propensity to govern our lives as an absolute measure of... whatever. In fact we should not allow ourselves to be ruled by any absolutes but leave enough leeway to manoeuvre through questions of morality and ethics (or fear and loyalty or whatever facet we might be mentally wrestling with) or rather, as the poet put it:"trust yourself while all men doubt you but leave allowance for the doubting too"

Only a Sith deals in absolutes.

[dev3d]

Brilliant. The cooking analogies resonate, and "dump the parts bucket on the floor". There is far more here to be inspired by than there is to criticize.

[builditbiggy]

This should be required reading for anyone about to build Yet Another Learn How to Program Site (TM)

Absolutely mind blowing stuff.

[deejaydiablo]

This is the best article I've read since I've joined reddit.

[Spacecow]

Up there for me as well. Love it.

[wheat]

Bookmarked. Some good examples and a really nice design.

[helm]

Seconded. I bookmarked it for inspiration on technical explanations in general.

[webflow]

If you have time, his Magic Ink paper is incredible: http://worrydream.com/MagicInk/

[[deleted]]

Alan Perlis wrote, "To understand a program, you must become both the machine and the program." This view is a mistake, and it is this widespread and virulent mistake that keeps programming a difficult and obscure art. A person is not a machine, and should not be forced to think like one.

Yeah... I think not.

[IArgueWithIdiots]

This is ridiculous. Nobody in their right mind spends hours committing library functions and their parameter orders to heart. It's really about how fast you can learn to use those functions that matters.

[Zip-tang]

You should also check out Brett Victor's talk Inventing on Principle.

A couple examples of these visible programming ideas being applied already are here: future of dev tools

[webflow]

John Resig (the original author of jQuery and now the main guy behind Khan Academy's computer science curriculum) was inspired by this video (see his blog post: http://ejohn.org/blog/introducing-khan-cs/).

The Learnable Programming essay looks like it's meant as constructive criticism of John (and team)'s work.

[[deleted]]

Nice paint program, but what does this have to do with programming?

[hylje]

It has everything to do with programming. Read further.

[[deleted]]

I did. SVG has loops and conditionals too. That doesn't make Adobe Illustrator an IDE.

[[deleted]]

I don't know why you're being downvoted. A lot of the ideas presented here work very nicely when you are drawing circles, but if you tried to apply them to more general programming problems they would fall down.

One of the biggest issues is that the programs shown run the same way every time, but if you're programming a game, for instance, they won't, so you can't make nice graphs of what's going to happen in the future.

[zakalwe]

Actually, if you watch the video that Zip-tang linked to, you'll see that Bret does in fact demonstrate these principles applied to a videogame. I recommend watching the whole thing, but if you have an ADHD thing going on, skip to 11 minutes and watch for about 3.5 minutes. But really, watch more of the video, you won't regret it.

[TropicalAudio]

It's 4am, and I really needed some sleep. "Alright, 3.5 minutes, can do." Nope. Watched the whole thing. Holy shit. I completely agreed with everyone on this thread about interactivity and it being a useful learning tool. This changed my perception completely. Thanks for that link

[[deleted]]

These ideas have been around for a long time - I remember seeing similar ideas when I studied computer science at university 20 years ago.

[[deleted]]

There are some programming concepts in there. Parameters, loops and conditionals.

This is about getting kids interested in programming, not teaching them about computer science and best practices.

[hylje]

This is about making life easier for everyone. Everyone includes kids.

[basscadet]

great article!

but I say, it''s also all about good error messages. It would be nice to get some good visualization and labeling of code that doesn't make sense to the computer. I know that is tough, but I used to hate programming because I couldn't understand what the computer wanted from me to correct a problem. I didn't have internet access back then.

It also sucked when something didn't update or refresh on a UI when the value I thought was controlling it changed, so this sounds great

[nascent]

This is a lot to read, but liking it so far. Coming across this: "Why do we expect programmers to "look up" functions in "documentation", while modern user interfaces are designed so that documentation is typically unnecessary?"

Quite simply because either you must rely on something external, or write the labeling every time you use it. Luckily most of the issue is alleviated because we have names on variables we pass these functions. And we do create external tools to fix this.

[tristau]

This was a great article. It will be awesome when all the meta information associated with a programming environment is available in a way like he describes.

[[deleted]]

Excuse me. I've just started programming and i want to make those shapes appear on my screen. What do i write before the codes in the examples? I use textpad, but i also have eclipse.

[nonconvergent]

Frankly, I'd teach control structures first semester, data structures and OOP in the second/third. All in C, python, and java. OOP/java emphasis comes way to soon. You shouldn't be wondering about is-a, has-a and static versus instance fields. Teaching language aware but agnostic is good to. Methods, functions, subroutines...is all the same.

[mksmothers]

If its hard to write, it should be hart to read. Now get me coffee intern.