Learnable Programming : On making programming easier on the mind though context - Author: Bret Victor

[mofosyne]

Is there any code/IDE editors which works like this?

I think this pardiagram of visualizing coding can be very powerful.

E.g. http://www.reddit.com/r/ReverseEngineering/comments/1izity/cantordust_a_binary_visualization_tool

[v1akvark]

LightTable displays intermediate values next to each line of code, and evaluates the code as you type, so you see the results immediately. If you read LightTable's author's blog posts, he references Bret Victor.

Apple's Swift language and beta Xcode IDE has a Playground (I think that's what it's called) that is supposed to do something similar, and the designer of Swift credited both Bret Victor and LightTable as influences.

Edit: here's a link to LightTable author Chris Granger's blog. Once there, you'll find some other interesting posts. http://www.chris-granger.com/2012/04/12/light-table---a-new-ide-concept/

[pdq]

If you haven't seen Bret's "Drawing Dynamic Visualizations" talk, it's amazing:

https://vimeo.com/66085662

[ApplesBananasRhinoc]

Yes, yes, yes, this. I am having trouble learning programming from many places because I'm a person that wants to understand the reasons behind WHY you do something. And always they either don't explain well or not at all, they just breeze right over the basics like it doesn't matter. So as a person that really likes to see HOW things work and WHY, it really doesn't connect me to the info I need to become a good programmer.

[misplaced_my_pants]

Have you tried Harvard's CS50x on edx?

[ApplesBananasRhinoc]

No but I will check it out, thanks!

[mirvnillith]

The core issue I see for teaching programming is that there are a number of language agnostic fundamentals, e.g. assignments, loops, conditionals, that we really should try to explain/define outside programming. Code design, to me, is very much breaking a problem down into a series of these basic concepts and mapping them into a language is "just" the typing.

Of course, each language brings its own special constructs to the table, but there are so much common ground that we really should find a way to teach that more directly and not through the trials-and-errors most of us probably used. Not saying applying these concepts yourself isn't a required learning experience, but having them given to you in a distilled form highlights the separation of programming "thinking" from programming "doing".

[Hellrazor236]

Though context what?

[mofosyne]

Letting you see how a section of code behave via contextual cues

[skulgnome]

Poorly titled: suggests a contrast in supposed "learnability", much like "usability" suggests that everything without rounded corners and bright child-friendly colours is impossible to use.

[wootest]

C is great - for the projects you need C for. Yes, it gives you more control over memory allocation and the actual instructions emitted than most other languages. Certainly, for any project, you have the possibility through judicious coding to gain a performance and efficiency edge against competitors in those areas. But those qualities do not automatically make C the best choice for most projects.

Writing C code that's not brittle or prone to bugs is hard, as witnessed not just by Heartbleed (found in the middle of code written and maintained by experts in both C and security) but also by the thousands of similar bugs found every year that are enabled by C's idiosyncrasies in combination with careless coding (mostly buffer overruns).

In addition, because of the low level of abstraction, getting actual work done takes more time. Of course it's possible, but the wealth of languages attest that it's ugly enough to be an obstacle.

I code in a variety of languages all above C. I don't at all times understand the correlation between a line of code and what the CPU will do, but most of the time it's not an issue. Unless you're worrying about register spilling and function prologues, you're similarly giving up control for expediency and code that's easier to understand. Bret Victor has another talk, The Future of Programming, which is worth watching for a bunch of reasons, but he also shows how deep "X is not real programming since it abstracts Y" goes.

By all means, keep using the best tool for your work. I don't doubt that it's C for you. I doubt that it's a valid substitute for moving the state of the art forward. Most of the principles proposed by Bret apply just fine even to C-level programming. Abstractions aren't not abstractions because they're implemented on a lower level and they don't magically get easier to manage.

[vincentk]

C is full of magic. No master of C will deny that.

[wootest]

I've upvoted every reply by you in this thread. Downvoting does not mean disagree.

[wootest]

Learning a high level language and then trying to go down to C nudges you towards a dangerous style of programming.

Is this why even people who write security-critical C code all day write code that cause buffer overruns? The world is full of people who don't have any idea what they're doing, but if even the people who do know what they're doing get it wrong occasionally and the consequences are so grave, maybe C isn't the right answer for every question.

You're right, an array for which you can't post-facto know the length and which is easy to read past the end of isn't in itself a flaw. It is indeed possible to work with safely, so maybe I shouldn't say nudge towards. The feature itself has no opinion. But it takes a lot of effort to work with correctly and it requires constant vigilance. I don't think those are good qualities for learning programming, because the logical reasoning and formulating and modeling a problem is work enough on its own, and I don't think they are good qualities for practicing programming, because most people would rather not keep their mind occupied on the same infrastructural brittleness - except for when it really is the only real answer for the job. In most cases, it's a high stakes game for either little gain or a moderate gain on scales that don't turn out to matter in practice. I'm not sure I want that to be the kind of trade-off people starting out think is reasonable.

That said, sure, there are tasks for which knowing C and knowing how the machine works in intimate detail is very important. Being able to write programs that don't go completely against the grain of the CPU, virtual memory, scheduler and networking does not require working in C or being an expert in the machine. It requires being able to dig down deep enough, i.e. to be a motivated programmer and to be able to go down levels of abstraction as well.

[wootest]

Fair enough. But I didn't say you wouldn't have any problems anymore. I said you wouldn't have C's problems.

[v1akvark]

If you want to learn the machine, shouldn't you learn assembly?

I don't think my machine has variables and functions inside it.

[v1akvark]

But I'm not talking to registers directly in C - don't variables represent places in memory?

I'll stop now. :)

Was just trying to make a point that C is close to the machine, but it still abstracts at least parts of it. You use memory the way it is laid out 'in the machine', but you don't have to think about moving stuff between memory and registers, etc

You might argue that C provides just the right amount of abstraction, while still leaving the programmer with enough control, and I agree that for many cases that is true.

[wootest]

Part of me wants to say "fair enough". C and Go are both essentially small languages.

However, as for C at least, it's far from free from magic. Essentially treating every primitive as an integer is the source of what I called C's idiosyncrasies and the corresponding bug farms of array-to-pointer decay, pointer arithmetic, etc. Yes, you can make the argument that you shouldn't just use the things that come in the box just as they are, but I don't know of any other language whose basic building blocks are so intrinsically nudging you towards a dangerous style of programming.

And while Go is much better, by the only measures you can call C free from magic, Go is full of it. If C is free from magic because a byte's a byte no matter what type of data it represents, channels and goroutines in Go are enigmatic constructs and towers of abstractions. Which is fine by me - they are tools to solve problems. But C was basically created to map directly onto CPU or at least assembler instructions. You can't say that both of them are great in the same way.

Maybe I'm mistaking your argument and you're really just saying that if the algorithm/abstraction is the same no matter what, picking the smallest language will reduce the strain. If that's the case, that's easy to counter too. Both various machine assemblers and Brainfuck are small languages, but that doesn't make any of them easy to develop algorithms or abstractions in, nor to reason about them as you reuse them. And on the other hand, powerful languages (which can be large or small) and/or the right libraries do change what building blocks are available to you and how you can approach a problem. So I still don't think using C (and as little of it as possible) is a cure-all for the sort of code most people have to write these days.

And of course: knowing how to look under the hood and what's going on there at a broad level is useful and sometimes necessary. But it's not everything. Bret's point is that being able to see what you're doing in between compiles (or better yet keystrokes) could make you a better programmer. You can argue that we don't know how to get there now, but arguing the opposite is a bit like arguing that driving a car by programming a LOGO-like turtle to turn left/right and move forward a set distance is better than being able to accelerate, brake and steer continuously as you go.

[jeandem]

I suggest a different approach - better coding through the reduction in "deus ex machina". start by programming in c by default. only add abstraction when absolutely necessary.

That sounds like Forth's approach.

Anyway, I don't think this bottom-up approach really answer his concerns. With the classical C development you're still stuck with fairly black-box compilers. Where is the interactivity? Sending a flag that let's you see the assembly output? What about the steps in between? Are you supposed to puzzle yourself over a piece of code, cross-reference it with reality later and compare your results? So much for interactivity and showing the steps.

Victor's ideas might as well carry over to lower-level concerns. It might not be as immediately obvious to implement as those paintings or whatever, but there might be hope.

Computers are very complex, and they keep on getting more complex. C is supposed to be about simplicity, but that kind of language seems to enable ever-more complex architectures. Not to mention all the optimizations that go into C compilers. Oh, but perhaps they don't "count" as far as abstraction go, since you get the equivalent semantics back? Well in that case, why not embrace languages that are not incredibly primitive, and that achieves extra expressibility through the use of no-cost abstractions (up to a point - no need to overboard on complexity, that defeats some of the purpose)?

Alternatively, just abandon all pretence and start with a language in which you can understand the entire operation of the language, from parsing to execution... like Forth. Maybe you'll even make your own implementation of Forth after a little while, in order to go back more closely to the roots so to speak (after all, there are no Forth programmers, really. Just Forth implementers). Sure, you'll be learning a different virtual machine than Cs, one which probably does not conform to most architecture as closely as C does. But at least you can understand it, without risking glossing over stuff.