More Graphical Language!

[Brendan]

Hi,

For years I've had this growing sense that something is wrong with the way we program - a feeling that it's harder than it should be, a feeling that the tools we use have failed to make any usability improvements beyond "icing" (e.g. syntax highlighting and auto completion), and a feeling that the full potential of computers isn't being used to make better tools.

It's like having a craving for chocolate ice cream, but not knowing what "chocolate" or "ice cream" is. You try to imagine the thing you're missing, but you can't because you've never known anything like it so the growing sense that something is wrong continues to grow.

Last night, someone (dozniak) sent me a link. It wasn't just a normal link - it was a major piece of the "something" I've been missing. The enlightenment was profound.

Here's the link: http://worrydream.com/LearnableProgramming/

Everyone that is interested the act of programming (how humans interact with the tools) needs to read this article.


Thanks,

Brendan

[bewing]

I have a few quibbles with the arguments in this article -- some important, some not.

Overall, this seems like a nice tool for a programmer to code a GUI, provided
1) That the people who create all the libraries will actually provide a working interface for this magical IDE to generate all these lovely thumbnails of the action of each GUI, math, and system function.
2) That there is a good way to store the unbelievable amount of per-step state information that the IDE will require in order to make this work. It needs to store a copy of the entire window, and probably the value of every single memory location in the address space -- at every time step. How many time steps? Oh, a few million.

It seems pretty clear to me that it'll be far less helpful for programming anything involving a real system call. Or stuff that's completely asynch. Situations where the data isn't known until runtime. And there is some AI magic that is left unexplained when it comes to data visualization of random unknown data.

Basically, I'd like to use it. But I'd really really hate to be the guy trying to build this IDE in the first place.

[Brendan]

Hi,

I have a few quibbles with the arguments in this article -- some important, some not.

Overall, this seems like a nice tool for a programmer to code a GUI, provided
1) That the people who create all the libraries will actually provide a working interface for this magical IDE to generate all these lovely thumbnails of the action of each GUI, math, and system function.

The examples were mostly graphical shapes (triangle, square, etc), which is fine for a language designed for learners (where you can limit the scope to "drawing things on a canvas"). This would make it very easy, as you can just execute the function being called to generate the corresponding graphics.

For real world programming it's rare for things to be graphical; but this doesn't really matter much. What they're really doing is displaying the results of calling a function with specific parameters. There's 2 different types of results - the returned value (if any), and the changes caused by any side-effects (if any). If a function returns an integer then you'd display that integer. If a function returns a structure then you'd display a list of fields and their values for that structure. If a function has side effects then you could display a list of whatever was changed (and what it was changed to).

For an example; for this function:

Code: Select all

int foo(int x, int y) {
    some_structure.bar = x;
    return x+y;
}

When it's called as "foo(2, 3);" you might display:

Code: Select all

Returned: 5

Side effects:
    some_structure.bar set to 2

The basic idea is the same - make it possible for programmers to see what the code does to the data.

2) That there is a good way to store the unbelievable amount of per-step state information that the IDE will require in order to make this work. It needs to store a copy of the entire window, and probably the value of every single memory location in the address space -- at every time step. How many time steps? Oh, a few million.

You wouldn't have to store very much at all. Instead, you'd have to quickly generate any data that's needed for display purposes. For example, if you're drawing a graph of how a function's variables change over time, then you'd start by compiling a special version of the code with instrumentation so that you end up with native code that generates a graph. Of course for normal software there would be plenty of cases where this can't work.

It seems pretty clear to me that it'll be far less helpful for programming anything involving a real system call. Or stuff that's completely asynch.

Imagine a system of isolated "agents" that can only communicate via. asynchronous messaging. For unit testing, you'd have a fixed sequence of request messages, and for each request message you'd have a sequence of expected response messages (plus some extra data to indicate when the agent should spawn a new agent, if the agent should terminate itself, etc). For each request; if the agent doesn't behave as it should then it fails the unit test.

A programmer would write the code for an agent and the corresponding unit test; and make sure it works like it should. The IDE would only have to care about displaying the agent's data and showing how that data changes as the unit tests are being run. The IDE wouldn't need to worry about large/complex applications and wouldn't need to store or generate the state for large/complex applications.

Note: This approach assumes that if all agents are correct, then a large/complex system of cooperating agents (an application) will also be correct.


Cheers,

Brendan

[OSwhatever]

Despite the programming language are the same tools are becoming better which enables you to debug and inspect object on a very detailed level. We have good tools for GUI programming as well.

Programming is a way of thinking, not a rote skill.

I agree with this part.

People understand what they can see.

Programming is often very abstract. Try to create a GUI where you are supposed to point and click to create a program that calculates Fibonacci numbers. Programming languages are abstract for a reason, tools on the other hand can be how graphical you want them to be. Can I see or touch Fibonacci series? What I know about Fibonacci series is described by mathematical expressions.

Back to that programming is a way of thinking. I think this is the core issue here. I think that imperative languages have their limits for modern systems. Take an FFT for example, you have a kernel computation and then you loop it. How can you make it more concurrent? Not really obvious is it? You can expand and draw diagrams of the FFT and see how calculations depend on each other and then get an idea how to do it. My point is that imperative languages encourage us to think series of statements that are then executed in that order but many times the order doesn't matter and you do many things at the same time. Like going from your favorite imperative language and the switch over to your makefile in order to do some changes and your brain gets stuck because it is so fundamentally different.

Maybe VHDL is closer to what I want. Take the FFT example, then VHDL compiler will try to expand my expressions into netlists and it is therefore optimized naturally. On a CPU, the netlist is already there so how do we map my netlist that I want to the CPU that already exist and is fixed?

[cxzuk]

Hi,

Here's the link: http://worrydream.com/LearnableProgramming/

What great food for thought, thank you Brendan.

Basically, I'd like to use it. But I'd really really hate to be the guy trying to build this IDE in the first place.

I second that, And think its an even bigger job than just the IDE. The impression I get from the article, is a start again, ground up rethink of everything.

[Jezze]

From an educational point I can see the benefits of this but in practice I don't think this would ever work for something outside of the domain shown in those examples. Having a visual representation for everything would not be feasible in many cases. However, I think the ideas are nice and I think there are some aspects of this that could be applied in a more generic way.

To be able to step through a set of functions containing a bunch of nested loops and at the same time be able to keep track of return values and side-effects could be useful especially if you are chasing some sort of nasty bug. It can also help you understand what the edge conditions are, possible integer overflows and whatever one type of input would make your program break which might not be apparent at first glance.

[trinopoty]

First the article always says "she", that means the author did not expect any male to read it.
The features explained in the article may be good for a learner but is almost useless for a pro programmer. Imagine using the feature when thousands or even millions of lines of code are involved. The programmer is better off keeping track of functions and their parameters manually.
The IDE will assume that the program will be compiled for the host platform, which is not true in many cases.
Programmers are expected to understand abstract concepts better than other people.
Also, the programmer using the features will waste most of his time working with graphics software than actually programming.
Lastly, most of the features explained have been implemented in software like Visual Studio, Eclipse, etc; although the name of the feature might be different.

There is a fundamental design flaw in the features illustrated in the article.

The above is only my personal thought, yours may vary.

[cxzuk]

...
The programmer is better off keeping track of functions and their parameters manually.
...
Programmers are expected to understand abstract concepts better than other people.

The authors argument is that this is should not be the case. It should not be a requirement to be able to mentally understand the computers behavior (keep track of state and understand abstract concepts etc), but to provide feedback to programmers of whats going on.

[piranha]

First the article always says "she", that means the author did not expect any male to read it.

Wrong. If the article had always said "he" would that mean that the author didn't expect any women to read it? No. The pronoun is irrelevant.

The features explained in the article may be good for a learner but is almost useless for a pro programmer. Imagine using the feature when thousands or even millions of lines of code are involved. The programmer is better off keeping track of functions and their parameters manually.
The IDE will assume that the program will be compiled for the host platform, which is not true in many cases.

The whole idea was a system designed for learning. So, yes, it is better for learning, and that is the point. As for compiling for the host platform, a beginner programmer shouldn't need to worry about that.

It was quite an interesting article, and I wish that my friends who had to learn Processing last semester had used such a system. They were non programmers, but had to learn Processing for some class, and they had a very hard time doing it. They were able to do the assignments, but they didn't actually learn any actual programming skills in the class. I guess thats why you should never learn programming from a class offered by the digital media department...

-JL

[Brendan]

Hi,

Even though this is intended for learners; a lot of the ideas (and reasons behind them) are applicable for experienced programmers.

Here's a brief summary of the main points from the article:

a) The IDE should show labels when the mouse hovers over various parts of the code; so that a programmer can read brief explanations of keywords, functions, function parameters, etc. This would make it a lot easier for beginners to learn. It would also help experienced programmers understand other people's code. For an example, here's a line of code:

Code: Select all

HTML_rootThread = HTML_THREAD_create(&SCAN_mainThreadOutput, NULL, NULL, "index.txt", THREAD_TYPE_association);

Who can tell me what each of those parameters are? I wrote that line of code yesterday; and by next week I won't remember what those parameters are myself.

Note: A lot of programmers already do write descriptions of parameters, etc. It's just that most languages make it hard/impossible for the IDE to associate the description with the parameter.


b) The IDE should try to explain things in context. Ok, this isn't easy for normal code and only really works for a language/environment designed for learners. That's fine (it's only one thing of many).


c) Fine grained flow control should be tangible. The idea here is fairly simple (making it easy to see the order things are actually executed). This is for everyone that's ever messed up an "if" condition, or forgotten a "break" in a switch statement, or accidentally written an infinite loop. Most IDEs with built in debuggers do this already (e.g. "single step"). The main difference is how well integrated it is into the IDE (e.g. in most cases the debugger is separate thing glued onto the IDE as an afterthought) and the ability to move backward as well as forward.

In general, I don't see any problem in allowing "backward step" where possible (and simply not providing the option if it's not possible); even if "backward step" is limited to the last "n" steps (where "n" depends on how much RAM you've got). For this case, you only have to keep track of the order that lines are executed - e.g. one line number per step. Note: It's only talking about the control flow within one function, not within the entire program, so it shouldn't be some "millions of lines of code" nightmare.


d) Coarse grained flow control should also be tangible. In this case, you'd only really need to show when functions are being called. For example, you could have a diagram showing which functions call which other functions, and then just highlight the "currently executing" function. The hard part is generating the diagram (but that doesn't sound impossible and there are existing tools that do this already). It'd be easy to allow "backwards" here too (you'd only have to keep track of the order that functions are executed - e.g. one "function identifier" per step). For something massive (e.g. OpenOffice) this would be a nightmare because the diagram would be huge, but I only care about small "agents" (that are about as complex as a class in OOP) and I have no reason to care about huge programs.


e) Data should be shown. This makes perfect sense - we all use educated guesses, and sometimes we get it wrong, and then we use a debugger to actually "see" what we should've been able to see to begin with. Of course when you're writing code you don't want to see all of the data for an entire process all of the time. You'd only really want the data from one function (e.g. input parameters and local variables) when that function is being executed once. Obtaining the data isn't that hard, and recording the last "n" steps of data (where "n" depends on how much memory you can spare) is easy. Displaying the data would also be easy - just display the variable names (and/or structure fields) and their contents (which is either just a boring old integer or a boring old floating point number, or a slightly less trivial address/pointer). The tricky part would be figuring out a nice way to display large arrays (maybe just don't display arrays until/unless the user clicks on it, and then display the array as a grid/table in a separate dialogue box).


f) How data changes over time should be shown. This is the same as above (limited to the data of one function's parameters and local variables, when that function is being executed once); except you'd draw a bar chart or something instead of the current value. You wouldn't even need to show all graphs for all the variables at the same time (maybe when the user hovers their mouse over a variable's current value you'd pop up the "value over time" graph). You also wouldn't necessarily need to display all of a variable's data - you'd display what you can at the time, and (if the function is still running in the background) you'd add more values to it as more data becomes available.


g) Eliminate hidden state. I personally don't agree with this part. The reasoning sounds logical (especially for learners), but it's the opposite of "separation of concerns". Any state that is outside of a class/object/agent should be hidden, and any state outside a method/function's scope should probably be hidden too.


h) Get something the user can react to as soon as possible. This is mostly just auto-completion, except that functions are given default values (e.g. so that you can type 3 letters of a function's name and end up with code that works, rather than a function with missing parameters). I don't think the "default parameters" part is possible in all cases; but I also don't see any reason not to do this for all of the cases where it is possible. The problem here is that existing languages make it hard for programmers to specific default values.


i) Allow the programmer to see all the things they could use. This is what I was planning to do anyway - e.g. a list of keywords, functions, etc. that the user can click on (or drag and drop or something) to add the keyword/function/whatever to their source code. Their demo (where they click on the function name) looks much faster/better than drag and drop. I don't think the demo goes far enough though - I want an "almost typo proof" IDE, where it's impossible to mistype a variable or function name.


j) Start constant, then vary, then add loops. In general writing functions this way makes sense, because it's easier to write code with constants (and see it work), and then add things like variables and loops afterwards. With the assistance of an environment designed for it (default function parameters, buttons to do things like convert constants into variables or surround selected lines with a loop, etc) it looks like it'd be very fast and very easy to use. Again, I don't think the demo goes far enough here either - I want an "almost syntax error proof" IDE, where it's impossible to (for e.g.) forget a curly brace at the end of a loop or end up with the wrong number of brackets in a complex condition; and get a screen full of useless error messages when it's compiled.


Each of these things on their own wouldn't really be that special, and (even with all of these things) for a normal/existing language like C it wouldn't work very well. What I'm thinking of is an IDE that combines all these things with my "agents that communicate via. asynchronous messages" system and a language that is designed for both the IDE and the "agents" system.

Please note that the combination of i) and j) make it easy for the IDE to work in tokens rather than text. For example, you might select 4 lines of source code and click the "while" icon, and the IDE would insert the tokens for "while" and "end_while" into your source code and display them according to user preferences (e.g. "terwijl () { }" for Dutch programmers, "wahrend() {}" for German, "alors que () { ... }" for French, "mentre () { ... }" for Italian, and maybe an animation of a mouse on a treadmill for children).

Also, I do want integrated unit tests - I want people to write the code for an "agent" and the unit test for it (and not just the code itself). This means that for c), d), e) and f) the IDE can use test data (from the unit test) and can show the flow of execution while performing the unit test. Because these "agents" are isolated things, it also means that the IDE could compile an agent and its unit test as a stand-alone program, and instrument that stand-alone program so that it sends any data needed for c), d), e) and f) back to the IDE when executed. Basically, the IDE doesn't need to care about extracting data from an agent that is running in a full program consisting of many cooperating agents.


Cheers,

Brendan

[gerryg400]

First the article always says "she", that means the author did not expect any male to read it.

Wrong. If the article had always said "he" would that mean that the author didn't expect any women to read it? No. The pronoun is irrelevant.

The features explained in the article may be good for a learner but is almost useless for a pro programmer. Imagine using the feature when thousands or even millions of lines of code are involved. The programmer is better off keeping track of functions and their parameters manually.
The IDE will assume that the program will be compiled for the host platform, which is not true in many cases.

The whole idea was a system designed for learning. So, yes, it is better for learning, and that is the point. As for compiling for the host platform, a beginner programmer shouldn't need to worry about that.

It was quite an interesting article, and I wish that my friends who had to learn Processing last semester had used such a system. They were non programmers, but had to learn Processing for some class, and they had a very hard time doing it. They were able to do the assignments, but they didn't actually learn any actual programming skills in the class. I guess thats why you should never learn programming from a class offered by the digital media department...

-JL

Actually 'she' is just plain wrong. 'He' is perhaps grammatically correct although 'singular they' is gaining popularity as a gender neutral pronoun.

[bewing]

First, @trinopoty, regarding "she": traditionally, in English, you are supposed to use "he" when describing an unknown individual. Women in our society have decided that this is a prejudiced bias towards being male, and there are some social movements to stop using the word "he" at all. Some people are experimenting with using the word "she" in all cases, to turn the tables and see how annoying men find it to be.

Second, @everyone: don't bother trying to correct people from other nations who have no experience of your social trends. Keep in mind that the internet is international.

When it comes to learning, the author fails to understand that there are 3 entirely separate concepts involved, and mushes them together in foolish ways. The first concept is learning to think. The second concept is learning to program. The third concept is developing code for a particular API.

The author complains about the Khan Academy "not teaching programming in a smart way". That is not what they are trying to do in the first place. They try to teach kids to THINK. The fact that they use a programming project as a riddle to get kids to do creative problem solving is irrelevant.

Beyond that, there are many computer languages out there. To learn how to program, you need to basically learn how to work with all of them. If you create an artificial situation that makes programming trivially simple -- then your victims will still have completely failed to learn how to program, because they won't have a clue how to use any other language. To learn how to do a task, that task needs to be at least a little difficult. Otherwise you won't pay attention, and you won't learn anything.

But, of course, I am not interested in any of those learning aspects. What I am interested in is something like the WIn64 API. Or GTK, or Qt, or SkyOS, or any other extremely complex API out there. I do NOT want to learn all these APIs. But I DO want an IDE that makes it so trivially easy to write code for each of them that I don't HAVE to learn ANY of them, and I can still efficiently build working code for them.

I would really love to have the IDE show me all the possible Set* functions in the WIn32 API, and let me pick the one I want. I would love to have it tell me what each parameter was, in a tooltip, so I don't have to go look them all up all over again for the 3 millionth time. Except that the tooltips need to have cut and paste capability.

Beyond that, I am happy with being able to singlestep through my sourcecode, with the current value of any variable available to me, and being able to doubleclick to set and clear breakpoints. Going back in time a couple steps in time would be nice, but it's probably not worth my effort to code it into my own IDE.

[trinopoty]

Exactly, that is my point.
Programming is a way of thinking not a way of writing code. The language will not matter if one knows how to solve a particular problem. However, the bit about displaying a description about the function and its arguments is really helpful.
Eclipse and Visual Studio implements this on Windows. As far as I know, the only IDE that implements it on Linux is Eclipse.
There should be an open-source project for such an IDE.

[bluemoon]

Programming is about choosing the right way to write the code - but programming itself is a critical part of software engineering - itself is a part of "doing something useful".

I'd put the "thinking" part as part of software engineering process, and this thinking part has always been not limited to coding.

[Griwes]

Exactly, that is my point.
Programming is a way of thinking not a way of writing code. The language will not matter if one knows how to solve a particular problem. However, the bit about displaying a description about the function and its arguments is really helpful.
Eclipse and Visual Studio implements this on Windows. As far as I know, the only IDE that implements it on Linux is Eclipse.
There should be an open-source project for such an IDE.

Why do people always forget about Kdevelop?