More intuitive programming languages

I would like to find a programming language that makes programming easier. And I have seen dozens that claimed to have that effect. But it seems to me that at best they work like placebo -- they make programming appear easier, which encourages students to give it a try.

Seems to me that most of these projects are based on cheap analogies. Let me explain... Imagine that you are in a business of publishing scientific literature, and then someone tell you: "Why don't you publish a children's book? There is a big market out there." Problem is, you have never seen any children's book. You are aware that those books must be different from books for adults, so you make a research. You discover that successful children books use big letters and big colorful pictures. Great! So you take Wittgenstein's Tractatus Logico-Philosophicus, triple the font size, insert pictures of cute kittens, and the book is ready. However, despite having all signs of a successful children's book, children are not enjoying it.

Essentially, you can't remove programming from programming. You could give people a game editor and call it a programming language, and that would be a nice first step, but if you want to go further, editor is not enough. Or you can give them a package "editor + programming language", and they will use the editor part, and complain that the other part is too difficult.

I feel that there is something missing in programming education. Generally, if you want to teach a skill, you have to divide it into smaller skills and teach them separately. If that's not enough, break the subskills to even smaller subskills, and at some point it becomes easy. But we probably don't know how to break the programming skill correctly. There are some subskills -- probably so trivial to us experienced programmers that they seem invisible -- that we fail to teach them. Some people luckily get it anyway, and those become successful programmers, and some people don't get it and cannot move further. I am thinking about things like "expecting the same result when you do the same thing". Another prerequisite is algebra: if one does not understand that substituting "X" in "X^2" by "A+1" makes "(A+1)^2", how are they supposed to substitute parts of program with function calls? Etc.

It would be great to teach programming by tools like Light Bot. We would just need more of them, in a smooth sequence from simplest to more difficult.

Also I think that easy programming language cannot be a substitute for knowledge of programming. Of course we should prefer better tools to worse tools. But we should also accept that some amount of initial knowledge is required, and cannot be avoided by using a better tool. Analogy: If you don't understand anything about mathematics, then your problem cannot be solved by having a more user-friendly calculator. You should first learn some mathematics, and only then search for the most user-friendly calculator available.

I don't know whether this particular project will bear fruit.

There's a non-empty reference class of previous efforts to create visual programming languages, including e.g. Prograph, and the success rate so far is very low (Scratch is perhaps a notable exception, making inroads in the unfortunately small "teach kids to program" community.)

To be fair, Subtext looks superficially like it does have some novel ideas, and actually differs from its predecessors.

Be careful with the implied equation of "visual" with "intuitive". They don't necessarily have anything to do with each other.

ETA: I've tried downloading the current version to see if I could do something simple with it, such as a FizzBuzz implementation. No dice; the .exe won't start. Maybe the program has dependencies that are not fulfilled on my (virtual) Windows box and it fails silently, or something else is wrong. Updating on the experience, I wouldn't expect very much from this effort. It's literally a non-starter.

One big thing about plain text (and so conventional programming languages) is speed: for a proficient and practiced user, the keyboard is a really efficient method of entering data into a computer, and even more so when using an editor like Emacs or vim or a fully-featured IDE. As soon as you start using the mouse you slow down dramatically.

Another thing about normal text is the tooling has built up around it. Version control is the largest one: being able to narrow down to exactly when bug Y was introduced ("git bisect" is pretty cool) and see exactly what changed is really useful. Currently I don't think there is anything like this for visual programming languages, and this is a requirement.

I don't think these points are necessarily impossible to address: a visual programming language could still use the keyboard for manipulation and the structure of the code is build into the storage format so it would be feasible for version control to be more intelligent and useful than current ones.

Also, using visual connection can separate things too much, so the meaning isn't obvious at a glance, e.g. in this picture one has to follow the lines back to work out what's being used where, but in a textual language the variable names should tell you what's what. This places an additional burden on the programmer, having to remember too much about what connects where: the language isn't "local" enough so the programmer can't easily model the program in their head.

That said, I'm sure a good language that uses a visual representation of control flow can introduce non-programmers to some of the ideas and allow them to automate some tasks, which is always a good thing. But, I don't think they will be a success amongst "real" programmers (at least until brain-computer interfaces work fluently).

Case study: Some of the first programming I ever did was on the LEGO Mindstorms RCX, and normal method was via a version of LabVIEW, the programs look a little like this. It was really cool! It got me introduced to some of the ideas of programming, and for simple things it's easy to understand the program.

But it was so slow. So intensely slow. Clicking around to find the right block to place, dragging it to the appropriate spot, connecting up the wires, place any auxiliary inputs for that block and connect them up, move all blocks around a bit so wires don't cross and blocks don't overlap, repeat. Takes 10 or 20 seconds at best to do the equivalent of "MotorA.run(5)", and much more to do something like "if TouchSensor.is_pressed()".

Furthermore, moderately complicated programs ended up as a mess of wires and blocks: it is very difficult to make modifications to a block of code (inserting stuff means either leaving it hanging off to the side, or manually rearranging the whole thing) and expressing some concepts/structures is pretty awkward. As an example: this piece of code.

A few years later, I started learning proper languages, and found out that I could actually run real code on the RCX, which allowed me to do vastly more complicated tasks, because, for instance, I could have variables without having to have wires running across the whole page, and it was easy to encapsulate repeated bits of code into separate functions (and they could take input parameters!).

(Obviously, that's just one example of one visual programming language, but it illustrates a few of my points.)

I don't know about subtext specifically, but I've grown a bit more skeptical about the possibilities of visual programming languages over the years.

As a game developer, I sometimes had to find ways to give non-programmers control of a system - allowing a level designer to control where and when new enemies spawn, a game designer to design the attack patterns of a specific boss, a sound designer to make his music match in-game events, an FX artist to trigger specific FX at certain times ... it's not easy to do right. We programmers sometimes make things that seem obvious and simple with little graphs with arrows and dependencies, but it turns out to be a headache for someone else to wrap his head around. What seems to work best is not making a fully programmable system (even if it's nice and visual), but rather defining a narrow set of operations that make sense for the behavior needed, and give a way of simply editing those; making something like a narrow minilanguage. And for that, simple linear text-based edition can work fine, without any graphical frills.

(Working with a visual tool works fine too, but it shouldn't become a full-blown programming language; give a level designer a powerful turing-complete node-based scripting system, and he'll make horribly complicated undebuggable rube goldberg machines, that could have been replaced by a few lines of code if he had explained to the right person what he needed)

Anyway, if you want to get better at programming, I don't think you should expect much from fancy new visual languages; it may be more efficient to get someone to teach you a bit.

[A] program written as lines of codes is uni-dimensional, and even the best of us may find it difficult to sort out [...] how distant parts of the code interact together.

That would only be a problem if you could only refer to things by line number. When I call doTheWatoosi(), it doesn't matter much if it's the next function down or something defined in another program completely. It's the symbol names that tell us about the interaction, not the locations of stuff in the file.

And, the space of possible names has many many dimensions, which actually gives it quite a leg up over visual languages which have 3 at best, and probably actually only 2 if they want to have a decent user interface.

Which of course doesn't address the very real issue you raise: that text is much more opaque to beginners than visuals. But I am very skeptical of the notion that a visual programming language would be of much help to programmers who are already strong.

If you're serious about learning, I suggest you take an online course from Udacity. Their 101 course is a very gentle introduction.

Registration is already open. They start tomorrow. It's free.

I am a programmer, and have been for about 20 years or so. My impressions here...

Diagrams and visual models of programs have typically been disappointing. Diagrams based on basic examples always look neat, tidy, intuitive and useful. When scaling up to a real example, the diagram often looks like the inside of a box of wires - lines going in all directions. Where the simple diagram showed simple lines drawing boxes together, the complex one has the same problem as the wiring box - you have 40 different 'ends' of the lines, and it's a tedious job to pair them all up and figure out what goes where.

Text actually ends up winning when you scale up to real problems. I tend to find diagrams useful for describing various subsets of the problem at hand, but for describing algorithms, particularly, text wins.

The problem of programming is always that you need to model the state of the computer in your head, at various levels. You need to be able to 'run' parts of the program in your head to see what's going on and correct it. This is the essential aspect of programming as it currently is, and it's no use hoping some language will take this job away - it won't, and can't. The most a language can do is communicate the algorithm to you in an organised way. The job you mentioned - of modelling the flow of instructions in your head, and figuring out the interactions of distant pieces of code - that is the job of the programmer, and different presentation of the data won't take that job away - not until the day AI takes the whole job away. Good presentation can make the job easier - but until you understand the flow of the code and the relationships between the parts, you won't be able to solve programming problems.

On the other hand - I feel that the state of computer programming today is still almost primitivist. Almost any program today will show you several different views of the data structure you're working on, to enable you to adjust it. The exception, by and large, is writing computer programs - particularly within a single function. There you're stuck with the single view in which you both read and write. I'm sure there is something more that can be done in this area.

Do you see obvious flaws in such an approach?

I'm not sure. I think being able to model the computer's actions in your head is something of a requirement to be a good programmer. If people who use (a hypothetical completed) subtext learn to do that more rapidly, then great. If instead they learn to just barely cobble something together without really understanding what is going on, I think that would be a net negative (I don't want those people writing my bank's software). I'm not sure which is the likely outcome.

Or maybe I'm conflicted because I am a computer programmer, and subconsciously either don't want more competition or feel that anyone learning programming should have to put as much effort into it as I did.

But actually, if you managed to write a crappy life simulator, you can probably be a programmer. It takes practice to be good, like anything else. But if you don't enjoy the process of practicing at programming (it sounds like you don't), then you probably wouldn't enjoy being a programmer, either.

// 3 instructions
blah; blah
blah

// 2 instructions
blah blah
blah

// 1 instruction (indentation is significant!)
blah blah
  blah

// This one is tricky. Id' say syntax error, or a warning
blah; blah
  blah

// This looks better, more obvious to me: 2 instructions
blah; blah
        blah

// Alternatively, this one may also count for 2 instructions
blah; blah
      blah

// begin of a new block
appropriate_keyword blah blah
  blah

// end of a block (one instruction in the inner block,
                 one instruction in the outer block).
  blah
blah

// 2 instructions (but frankly, I'd provide a warning for the superfluous ";")
blah;
blah;

I recently did the biggest bit of useful programming I've ever done - automating large chunks of sysadmin work - in ant. ant is basically makefiles for Java. But it's Turing-complete!

What it feels like: using an esoteric programming language whose conceit is that all code must be correctly-formed XML. Most of the work was the mathematical puzzle of how to implement some really simple thing in ant. (Every domain specific language that is allowed to become Turing-complete will evolve into brainfuck.)

My point is not that ant is a horrible, horrible language to use for anything outside its narrow domain (though it is) - but that even when I'm coding in proper programming languages, the process feels much the same - it takes me half a day to work out how to implement the simple thing in my head, and coding feels like building a house one matchstick at a time. This leads me to suspect it's me, not the languages. So it's not just you.

In the Subtext FAQ there's a question that is now my favorite question to ask of any new programming tool:

How will this scale to programs larger than the screen?

Disconcertingly, the answer for Subtext is

Unknown.

This article suggests that something like 30% to 60% of people cannot learn to code. I think that's interesting. EDIT: This also might be wrong; see child comment.

The three hurdles the article describes are variable assignment, recursion, and concurrency. I don't think you can program at all without those three elements.

Programming is interesting in that the difference between good programmers and bad programmers seems to be far more pronounced than the difference between people who are good and bad at other tasks-- I recently observed about ten smart friends of mine trying to learn Haskell for a introduction to algorithms course. Some of them got it immediately and intuitively, and some just didn't.

Also. I suspect that some people will find learning to program a bit easier with functional programming languages like Haskell. When learning Haskell, I wrote lots of simple functions, and acheived more complex results by stringing together lots of simple functions. In imperative languages, it's a bit harder to test all the individual pieces as you're going.

As others pointed out, different ways of "programming" are best for different problem domains, and there is virtually no chance that a one-size-fits-all language can be useful to do or teach programming in every domain.

Moreover, regardless of the language, you have to develop the ability to think like a computer, which means that there is no magical DWIM (do what I mean) button/keyword available to you. Some people have a harder time developing this essential ability than others; they should probably consider a different career path, no matter what languages are available out there.

Recently I've been exposed to the idea of a visual programming language named subtext

I'm glad you like subtext. Me too.

I just had a big "update". EDIT: I'm a little less sure now. See the end.

I found something to teach programming on an immediate level to non-programmers without knowing they are programming, without any cruft. I always wished this was possible, but now I think we're really close.

If you want to get programming, and are a visual thinker, but never could get over some sort of inhibition, I think you should try this. You won't even know you're programming. It may not be "quite" programming, but it's closer than anything else I've seen at this level of simplicity. And anyway it's fun and pretty.

The important thing about this "programming" environment is that it is completely concrete. There are no formal "abstractions," and yet it's all about concrete representation of the idea formerly known as abstractions.

Enough words. Take a look: http://recursivedrawing.com/

[I was excited because to me this seems awfully close to the untyped lambda-calculus, made magically concrete. The "normal forms" are the "fixed points" are the fractals. It's all too much and requires more thought. It only makes pictures, though, for now. However, I can't see anything in it like "application" so... the issue of how close it is seems actually quite subtle. Somehow application's being bypassed in a static way. Curious. I'm sure there's a better way to see it I just haven't gotten yet.]

PS: Blue! Blue! Blue! (**)

** This is a joke that will only make sense if you've read The Name of the Wind: Rothfuss. If you prefer to spoil yourself, here, but buy the book afterward if you like it.

cross-posted here

Visual programming is great where the visual constructs map well to the problem domain. Where it does not apply well it becomes a burden to the programmer. The same can be said about text based programming. The same can be said about programming paradigms. For example object oriented programming is great... when it maps well to the problem being solved, but for other problems it simply sucks and perhaps functional programming is a better model.

In general, programming is easy when the implementation domain (the programming language, abstract model, development environment, other tools) maps well to the problem domain. When the mapping becomes complex and obscure, programming becomes hard.

You will not find a single approach to programming that is easy for all problems, instead you will find that each approach has its limits.

My current project is to catalyze a new perspective on programming. I believe that we should be programming using an ecosystem of domain specific languages. Each language will be arbitrarily simple (easy to learn) and well targeted to representing solutions within in its targeted problem domain. Although none of the languages are individually Turing-complete, Turing-completeness is available within the ecosystem by combining programs written in different languages together using other languages.

When I use the term language I mean it in its most general sense, along the lines of this definition "a systematic means of communicating ideas or feelings by the use of conventionalized signs, sounds, gestures, or marks having understood meanings". Perhaps a better word than language would be interface.

Programming from this perspective becomes the generation of new interfaces by composing, transforming, and specializing existing interfaces, using existing interfaces.

This perspective on programming is related to language-oriented programming, intentional programming, aspect-oriented programming, and model-driven engineering.

MaxMSP is a music technology program that works like this - you can visually track the flow of information. It might be relevant - I'll write about it more tomorrow, i'm on a mobile phone at the moment.

I'm not a programmer. I wish I were. I've tried to learn it several times, different languages, but never went very far. The most complex piece of software I ever wrote was a bulky, inefficient game of life.

For how long? I've been able to solve the first 5 Project Euler problems after 2 days of Python, and I'd probably be able to solve more, but that isn't programming.

I doubt you can become anything that would deserve the label "programmer" in under 3 years, as long as you are not a genius.

It seems that there are some who are incapable of learning programming. That said, when you are programming, you are virtually always working with a Von Neumann Architecture, so many languages have common ground.

Code is in general presented as composable units. Working in Symbolic Graphs of plaintext names or in actual graphs in 2d makes little difference.

If you really want to learn programming, but think that regular Java(script) or Python is trite and annoying, try Haskell. Haskell requires you to know math to actually make sense of anything, and it is very powerful in very different ways compared to Algol descendants.

Related point - I remember that programming in hyperscript (for hypercard) was a lot like explaining something to someone who had no domain knowledge.

Get the text of field 'address'.

Put it after field 'label'.

Stuff like that.

I lost interest in programming after I realized how much effort it would take me to do anything cool.

For those people here who consider themselves reasonably skilled at programming: how long would it take you to implement a clone of Tetris? I've got a computer engineering degree, and "cin" was the only user input method they taught me in programming classes...

Edit: You're not allowed to use ASCII graphics, and it has to run at the same speed on different processors, but other than that, requirements are flexible.

There is good reason that several programmers have referred to GUIs as "point-and-grunt" interfaces. And actually programming requires even more flexibility. An intuitive and functional "intuitive" programming system is going to be based around natural language, not pretty pictures. That isn't to say images won't be used, most likely in structuring the sub-components of the overall program, but LabView already shows the strengths and weaknesses of that if the programmer doesn't have sufficient linguistic control at a lower level.

ADDED:

Point and Grunt

Better known as "see and point," the point and grunt principle is simply the principle that users interact with on-screen objects with the pointer. I have a low opinion of this principle because I blame it for lowering the cognitive functioning of users. It reduces users to the same level as children who have not yet learned to speak. While simple, it lacks expressiveness.

CS345 / Graphical User Interfaces: Principles of Graphical User Interface Design

Fantastic thread! Are there any statistical programming, or programming languages of any kind that are, well, 'obvious'. Something I can type 'survival analysis with lalalala' instead of 'stset 34.3 alpha 334' or something like that?

model the flow of instructions in your mind, how distant parts of the code interact together

Unless you're hacking you usually don't need to do this. You just need to understand what state the program is in before and after each operation. You never need to understand the whole thing at once, just understand one part at a time.