views:

139

answers:

7

Hi!

I have often read that some programming languages are clear than others and I asked myself several times if there is an objective way to measure the clarity of a language in order to design, given an abstract syntax, a concrete syntax as clear and human friendly as possible. Perhaps exist some kind of designs patterns for that purpose?

In short: How can be achieved the maximum clarity of a syntax? Know any way to quantify the "clarity" or "expressiveness" of a language?

Makes sense to try to measure these aspects?

Thanks.

+2  A: 

I don't think there is. Clarity is subjective, and design patterns are not a good measure for clarity of a language (indeed, design pattern are usually born to circumvent the limitation of a language).

Some people likes a language with rich and concise semantic (e.g. perl) and doesn't really mind the use of symbols, while other prefers a syntax that resembles natural language, such that you appear to speak to the computer (e.g. Hypercard) and doesn't really mind the verbosity or the ambiguousness.

Lie Ryan
Good point, but maybe there is some kind of "Language Ergonomics" criteria?
amorales
I am not sure you can say that clarity is subjective, at least not entirely. For example variable names today typically are not restricted in length, so I can create variables such as ClientSocketConnection, whereas when I started programming you were restricted to six or maybe eight characters, which meant you were forced to abbreviate, yet any abbreviation would possibly create different associations for different people as there is no standardized abbreviation for any of the english words in the sample variable name
Steve Ellinger
imgx64
imgx64, I truly doubt that Kernighan and Pike were advocating a return to 6 to 8 character variable names in all cases, are you so advocating?
Steve Ellinger
@Steve Ellinger: I personally never liked the variablesWithVeryLongNames fetish of many Java programmers. Most of my variable names are 3-8 letters, 2 words is max; too long variable names is unreadable. I certainly wouldn't like to put artificial limits on the length of variable names, though I think there is benefit in having short and brief names, and that's what Brian Kernighan and Rob Pike is advocating.
Lie Ryan
@Steve, click on the link I provided, it links to the exact page of the book on Google Books, you can see the context there. In short: they say variable names should be proportional to their scope. Short lived local variables get short 1-5 letter names, global variables get meaningful unambiguous names, etc.
imgx64
+2  A: 

A question like this usually results in a pedantic answer.

Languages are like tools.

They are built to suit certain purposes. Logic programming language solve certain problems in a more elegant way than an object oriented program would. Similarly, many main stream solution are easily done by a typical object oriented or procedural language.

Temperament and other factors of the tool user, in this case a programmer also matters. Some folks have achieved nifty solutions in Perl but it has always looked like black magic to me. I prefer Python's structural simplicity. For some, it's use of white space has been abominable.

It would be at best a very subjective evaluation, if there can be an evaluation of a language clarity and expressivity.

How ever, a clear indication is wealth of code production in that language. Some language like brainfuck has not been adopted while Python, Ruby etc have gained popularity. Although, these and many factor can be an indicator only. Some language, despite good constructs may not find much takers.

Network effect also affect the language adoption.

pyfunc
Ok perfect. Now suppose you're in charge of building that tool which is a Domain Specific Language? Will you build several to see which one works best? Probably a survey will be the best way to measure a subjective result.
amorales
@amorales : If I were building alone, then my likes and dislikes will have quite an impact along with requirements for that Domain Specific Language. I would rather place more faith in a few developers to flesh out the details. This way, it is guaranteed to maintain some integrity or personality. Survey, usually comes out with a mixture of requirements that put together may not look like the best solution. At best, it can be used as input.
pyfunc
+3  A: 

I have heard this phrase too many times carelessly thrown at different languages, and different people will choose different languages based on different criteria.

In Beautiful Code, Yukihiro Matsumoto (Ruby's designer) makes an argument about how much simpler it is to write a Hello World program in Ruby than in Java. Although I don't think this example is meant to scale, the author's point is that the amount of cruft you have to add on to your code reflects the deficulty in understanding a program written in a that language. That is, the less distraction you get, the more "readable" the program is.

Now, in my experience, good programmers write clear code in all languages they program in, though even more clearly in languages they are more familiar with. The author's talent as well as the breadth of his experience in that lenguage end up dwarfing the language itself's clarity or expressiveness.

Another point to consider is the amount of available libraries and the quality of the APIs. If you have to write less "support code" to get the job done, then it's likely the resulting program is clearer because it appears more straight to the point.

André Caron
+1  A: 

I find LOLCODE to be the most understandable language of them all:

HAI
CAN HAS STDIO?
I HAS A VAR
IM IN YR LOOP
    UP VAR!!1
    VISIBLE VAR
    IZ VAR BIGGER THAN 10? KTHXBYE
IM OUTTA YR LOOP
KTHXBYE
Aillyn
+1  A: 

There have been some studies in what is called "natural programming" which may be of interest to you:

http://www.cs.cmu.edu/~NatProg/index.html

They attempt to design languages to meet human expectations instead of trying to conform people to what's simplest for a computer. And they're basing it on experiments. For instance studying how many people bring back a pear from a box of fruit when you instruct them to "bring back something is not an apple or a pear". (I haven't kept up with their results, but it sounded like a promising project.)

Still, "clarity" and "expressiveness" are nebulous things to gauge. There are of course studies which do quantitative measure of languages against one another, like the Computer Language Benchmarks Game. Some people have taken data from solutions offered in that game and graphed trends like "code size vs. performance":

http://blog.gmarceau.qc.ca/2009/05/speed-size-and-dependability-of.html

You might be able to make some shaky metrics-based propositions about a general-purpose-language based on trends in code size it takes to perform a given task efficiently. But then you're pinning down fairly subjective notions of what "clarity" and "expressiveness" are. (I'm biased to believe shorter programs that do the same work faster are often clearer, but there are many counterexamples.)

So I'd say that in the absence of a defined target audience with which you can do usability studies with test subjects, you won't do much better than these kinds of metrics for making generalizations about languages.

(Note: I like Rebol and I think it has the power to be incredibly clear and expressive...but only if you use it a certain way which involves developing DSL dialects as you go, which is not the way a lot of people think when they program. Yet!)

Hostile Fork
Again?! Every few years, some researchers "discover" that if you create a programming language similar to human languages, everyone will program, programming will be as easy as talking, programming careers will become worthless, and AIDS will be cured... Now we have Cobol, SQL, HyperTalk, AppleScript, Apple Automator(not a programming language per se, but I think it fits here), Lingo(in Macromedia Director, which I have been unfortunate enough to program a real project in it), and a myriad of other languages. These languages have done nothing but torture programmers everywhere.
imgx64
The raw data of doing experiments is useful at least in understanding the kinds of cognitive gaps that happen between computers and humans...and why they happen. (As opposed to someone making up a language off the cuff that they *think* will be good based on some personal gut-instinct...which seems to be what people usually do with "humanish" language design.)
Hostile Fork
@Hostile: I'm still not sure what do they *want to achieve*. Do they want non-programmers to program? They can't, no matter how easy the language is. Read [this excellent article](http://www.codinghorror.com/blog/2006/07/separating-programming-sheep-from-non-programming-goats.html) by Jeff Atwood for an explanation.
imgx64
It reminds me of studies of two random people in different rooms, who are to pick a positive integer that the other person picks. To me 1 seems the obvious choice, as the boundaries are [1..+inf] and +inf is not an option. But the average person picks 7. I'll predict human programmers won't match AI programmers--so I like setting an example by being inclusive and understanding, instead of invoking Biblically-inspired posturing over "sheep" and "goat" separation. (Blind people won't paint as well as people who can see, unless we think outside the box in adapting to them and their situation.)
Hostile Fork
Don't get me wrong: I do think the test Jeff cites is a useful one for doing placement tests. I just don't consider it the basis of a philosophy that certain people should be discouraged from programming despite being really passionate about it, just because they failed that test. After all... at some point in your life you were a baby... but adults took care of you and adapted the world to you instead of letting you starve and die. I dunno about COBOL or AppleScript, but some people I know got their start programming in HyperCard. It set off a lightbulb and they went on to bigger things.
Hostile Fork
@Hostile: An excellent example. Now imagine a person who can see **having to use** blind-friendly tools to paint, and he has a career in painting.
imgx64
Above you said: *"Do they want non-programmers to program? They can't, no matter how easy the language is."* That's different from *"Do they want experienced programmers to use dumbed-down languages which are unsuited to their purposes?"* I do not believe the latter is the purpose of the work done by Dr. Myers et. al. - rather, I think it can be more seen as "PSL" (programming-as-a-second-language) style thinking. A test like the one Jeff cites is probably a good guide for whether someone is better served by classical programming. Again, this question provoked subjectivisim on "clarity"...
Hostile Fork
>> quantitative measure of languages against one another, like the computer benchmarks game << Please correct the text or the URL - that is NOT the computer language benchmarks game. (There is no suggestion on the computer language benchmarks game website of a quantitative measure of "language understandability".)
igouy
@iguoy: Not sure what you didn't understand about what I wrote, but I changed it to try and be more "understandable". My point was that what the OP was proposing would be hard to measure, but other things about languages *have* been measured (which he might not be aware of). The results *may* be correlated with "clarity" and "expressiveness", for some definition of those terms. I linked directly to the computer benchmarks game itself, *despite* it being the topic of (and the first hyperlink) in the article I felt was relevant to my point: http://stackoverflow.com/posts/3792366/revisions
Hostile Fork
A: 

Measuring the understandability of a language is not as important as measuring the understandability of a programmer.

mattjames
A: 

You can also look at the book "Concepts of Programming Languages" by Latest Edition, BY R. W. Sebesta. There is chapter in this book (chapter 1 or 2 I don't remember exactly) discuss criteria to evaluate a programming language.

chepukha