views:

183

answers:

3

What features could be added to a new programming language to make it more "intuitive"? When it comes to websites and desktops, we favor high usability, almost intuitive usability. It is becoming increasingly expected that your application should "just work". For a certain class of applications the idea that one has to RTFM, is a mark against the effectiveness of the application. People tend to expect the application to just work the way they "think" it should work. One could argue that this is a worthy standard that designers should strive for.

Can the same usability rigor apply to programming languages and developer environments? I realize there are tools like IntelliSense that provide hints, and a good IDE provides a lot of assist. But what about the core language itself? What could be added (or removed) that makes certain programming techniques or algorithms more obvious to implement? How does one make regular expressions or recursion more intiutive? Or is this just folly?

Take a more concrete example: liquid layouts in HTML, CSS, or Flex and MXML. In HTML and CSS, the box model is anything but intuitive given the different implementations of Internet Explorer and the other browsers. And unless someone reads the documentation or studies the concept of the box model it would be difficult to "just get it" when designing a layout on one's first stab at CSS. I would argue this is why tables thrived in the early days. The box model was implicit in the concept of a table cell. With the help of tools like Dreamweaver one could get their mind around percentage widths and layout within the constraints of table cells. Then CSS came into maturity and a whole set of valid reasons emerged for why tables are not for layout. But to achieve the same effects designers had to really study the CSS implementations and the box model, and inject a new layer of abstraction into their thinking.

In another example, I find when programming lots of things in ActionScript and MXML, the whole concept of fluid layouts and percentage based widths of elements not very obvious and doesn't always follow intuition. I understand the basic problem in that the Adobe Flash player and the layout need to understand things in absolute pixel terms. When it comes to the potential width of a component, I understand why percentages are not immediately obvious to implement at the core level of the code. Theoretically speaking the Flash Player needs to know (or calculate) the exact width of a component so that it can provide the proper geometry to the video card when doing a draw on the screen. But when you introduce some concept of percentages then you introduce the theoretical possibility of an infinite width. And to find "infinity - 1" pixels is not something a computer can directly do without some layer of abstraction and calculation. The viewport must be referenced. The program must know its boundaries. So absolute widths are the norm, although humans might prefer to design in terms of percentages.

When it comes to programming languages can there be expressions and features that assist intuition when thinking about a programming task. Or are we better off "thinking like a computer" and just RTFM'ing the manual when we need to understand how to implement some feature or layout in code?

If you could change the syntax or semantics of your programming language of choice what would you add, change, or remove to improve the "intuitiveness" of it?

Addendum, the reason for asking this question is inspired by seeing example of what "novices" were able to achieve in Smalltalk in Alan Kay's lecture: Doing with Images Makes Symbols.

+3  A: 

One step folks are taking that has as much to do with base class library as it does the language itself -- although to be honest, the two are often synonymous -- is the concept of a Fluent API. The basic idea is to make code "read like a sentence", the idea being that this makes the code more flexible and maintainable.

Randolpho
@Randolpho, thanks for the reference to Fluent API. Interesting stuff. This is why I ask somewhat broad questions because I get interesting answers like yours that help me learn. Thanks for the response.
Gordon Potter
+6  A: 

"If you could change the syntax or semantics of your programming language of choice what would you add, change, or remove to improve the "intuitiveness" of it? "

Programming is hard. Really hard. Syntax changes don't matter much. IDE's are irrelevant to the fundamental challenge of programming.

The thing that is often baffling is the semantics of the language.

I don't know what "intuitive" means with respect to a thing as abstract as a programming language. Indeed, "intuition" is probably a bad thing. Coming to a programming language with intuition means preconceived notions, biases and intellectual junk will take over.

I would never expect to "just get it" for anything on any level anywhere. Programming requires clear thinking -- not "intuition" -- not "expectation".

The only thing we can ever do is read the manual and understand the unique, distinct, novel semantics of the new thing we're confronted with.

I do know this: elegant simplicity is essential. Orthogonality of features. Clarity. Precision. Absence of exceptions or special cases. Above all, simplicity.

Layering on language features is fundamentally bad.

Covering language problems by layering in a complex IDE is worse.


See http://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD854.html

"when faced with something new and unfamiliar we try to relate it to what we are familiar with. In the course of the process we invent the analogies that enable us to do so.

It is clear that the above way of trying to understand does not work too well when we are faced with something so radically new, so without precedent, that all analogies we can come up with are too weak and too shallow to be of great help. A radically new technology can create such circumstances and the wide-spread misunderstanding about programming strongly suggests that this has happened with the advent of the automatic computer. "

In short, "intuition" and "intellectual baggage" is the problem of the programmer. The best way to understand a technology is to approach it as something fresh, new and otherwise unknown.


Bottom Line.

The complexity is inherent.

You have two choices.

  1. Develop intellectual tools (i.e., abstraction, summarization, etc.) to cope with it.

  2. Get a job in another field.

Asking for the inherently complicated world of computing to morph into something any one person finds "intuitive" can't happen. Computing is too complicated to be "intuitive".

S.Lott
I think I agree. That is why I also, asked what could be "removed" as well as added.And you are right in that intuition is too fuzzy of a concept for the world of binary logic and programming. But how is this simplicity best achieved? Surely we don't expect everyone to be assembly programmers. Although there is probably value in understanding assembly to understand higher level implementation. How does one make it so that the programming clears one's mind of the baggage and assumption that make it difficult?
Gordon Potter
Assembler isn't "simple". Indeed, it's often too complex because of weird hardware special-cases and non-orthogonalities. Some languages (e.g. Python) are pretty simple and easy to get a grip on. Programming has no baggage -- it simply is. If your mind has baggage, that's your problem to leave the baggage behind. Indeed, that's your *obligation*: to come at a technology with a fresh, empty mind, free of preconceptions.
S.Lott
Interesting point. In a related note I feel like one aspect that has made me a better programmer is being more naive. Basically I call it my "think like a computer" mode. I know nothing about nothing until I am told explicitly. I find this helps in debugging. But it can be tedious, but ultimately effective strategy.
Gordon Potter
I agree with all of your points, S.Lott, but I must disagree with your conclusion. :) As someone who [attempts to be a] teacher to younger students in Computer Science, the only time I've ever made progress was with good analogies. Furthermore, having studied education (in a very limited, but still formal, sense), I have learned that many believe analogy is really the only way people can digest new ideas. Ultimately those ideas stand on their own, of course, but the analogy is a "key bridge". Such was my impression, at least. I certainly agree that it is unfortunate we cannot discard baggage.
Agor
+4  A: 

Another field I've seen that addresses the complexity of the "syntax" of a programming languages is that of Visual Programming Languages. The basic idea behind VPLs is to take the constructs of programming languages (decisions, subroutines, functions, etc.) and represent them graphically, typically as a data-flow diagram. One such language that's gaining popularity recently is the Microsoft Visual Programming Language. I have not used it, and cannot make claims as to its power, but I have used LabView to great effect and I can say that you can do pretty much anything you can think of even in LabView -- but you do have to think of it in a very different way.

That said, I find I have a personal preference for code rather than VPLs.

Randolpho
I figured I'd add an answer rather than edit my previous, as it's a different topic.
Randolpho