Lambda the Ultimate

I must admit that the slowness of the first page makes me sad from time to time, but the high quality keeps LtU one of my "main" sites at all times.

On the other hand, it is true that same high standard makes it less likely one would offer to contribute. For example, hitting an OSNews or Slashdot posted link such as More Haste, Less Speed The Complexity of Lazy Evaluation and posting it here in a comment - such as this - seems a bit like a sacrilege performed out of incompetence.

But perhaps a link-drop could be added, or a reddit-like feature for potential submission by and editor could be added? Or would that be too slashdotty (if that's a word)?

I find LTU an invaluable resource for keeping tabs on new developments in the field of programming languages. The level of discussion is not the sole measure of the usefulness of the site and I would suspect that there are many readers like me who don't feel qualified or don't have time to get involved in the discussions but who still find the site very valuable.

I doubt ACM would be willing to do that. Not even ACM members have access to the DL anymore, unless they pay extra $$.

But most recent papers are available on the webpages of the authors, so this should not be a big problem.

...but really don't know if they have been discussed before.

Ok, so maybe we have those that don't want to retrieve the huge base of html files. So I got to thinking, why not have an inverse LtU link page. That is, have a page that lists all the URLs that have been linked to in LtU and have a link back to the places where they were embedded within the LtU posts. What I came up with is a page that has LtU URL links mapped to LtU topics. This allows you to scan for a URL and find the places in LtU where they were linked to - a sort of inverted LtU index.

Warning Note: This index is rather large (3megs), so it may take a while to download. Also, I don't plan on keeping that index page up to date (this is probably a one time snapshot of URLs).

I wouldn't be surprised if a large portion of readers here were somehow tied into academia, either as professors/lecturers or as students. Near the end of the semester, there is a definite crunch for everyone involved, and I think that could significantly effect LtU traffic.

For those with access to server statistics, do you see any sort of "2 semesters and a summer break" pattern in hit rates and such?

I have many of the same feelings. I'm a career-switcher from outside computer science, so I have had a lot of catching up to do. LtU has been a great resource for learning, but I don't really have the right background to do more than ask the occasional question. But if there is something folks like myself can do, speak up -- I'd be glad to help.

... and therefore get to understand how and why functional programming languages are not adopted on a wider basis.

Let me quote from the policies document:

LtU is a weblog dedicated to the study of general properties of programming languages, with an emphasis on programming language research and theory.

The purpose of LtU is not to give a wider adoption of FP in the industry.

While on the subject - a number of reasons have been pointed out in the reports from Commercial Users of Functional Programming : 2004 and 2005.

Hardly surprising, there are quite a few non-technical issues pointed out that are not related to fp in itself, but rather the limited amount of commercial support for the tools, fear of license issues (GPL/LGPL), etc.

The purpose of LtU is not to give a wider adoption of FP in the industry.

How can this be true when:

a) everyone here insists that FP is the best approach for programming

b) imperative languages are continuously mocked (remember threads like 'why do they program in c++?)'

Hardly surprising, there are quite a few non-technical issues pointed out that are not related to fp in itself, but rather the limited amount of commercial support for the tools, fear of license issues (GPL/LGPL), etc.

My opinion is that none of those issues are the critical factors in the failures of FP languages to grab a significant market share. There are other reasons, more important, that have to do with FP itself.

I would analyse my view, but I do not think you are willing to listen, and since LtU is not the place for this kind of discussion (there is no other site where this discussion can be done though), I will not proceed.

there is no other site where this discussion can be done

What about comp.lang.functional? It has its frequent share of discussions about this. With the same frequency they also turn out to be rather fruitless, because everybody knows (or thinks he knows) about the various reasons.

Not all imperative languages're continuously mocked. I don't see anyone ripping into the ML family, for example, nor Smalltalk...

C++ gets it for a lot of reasons, above and beyond being imperative. While it may not be obvious for you, the changes you've suggested to turn it into a safe-but-powerful language require absolutely gutting it.

a) everyone here insists that FP is the best approach for programming

You must be reading a different blog than I am. There isn't ANYONE here I can think of who regularly expresses that thought (anymore anyway; in the old days maybe... ;-) )

What pretty much all long-time LtU regulars would agree, I believe, is that there are some lessons and approaches taken from FP that need to be understood and applied before one can claim to either understand or practice the state of the art in programming.

And that is quite a different thought than "FP is the best approach for programming".

Disclaimer: I am not in academia. I've got a job programming just like so many others here on LTU. Take what I have to say about programming language research with the appropriate grain of salt.

a) everyone here insists that FP is the best approach for programming

That's a pretty strong claim. A few people might make that claim, many merely claim that FP is a good approach for many problems and the best approach for some problems.

A reason that functional programming languages are so popular here is that there is a lot of interesting research being done in functional programming languages. (This is, as I understand it, mostly because type theory is typically formalized in typed lambda calculi, so implementing ideas is easiest in functional languages.) So functional programming languages have the same type of "foothold" on programming language research that imperative languages have in the business world.

b) imperative languages are continuously mocked (remember threads like 'why do they program in c++?)'

Bjarne Stroustrup claims that "C++ is a general purpose programming language with a bias towards systems programming..."[Stroustrup]. From this statement I come to the understanding that C++ is best used as a systems programming language. This forces a C++ programmer to be concerned with certain low-level details that are arguably inappropriate for an applications programmer to be concerned with. So the question "Why do they program in C++?" is mostly directed at the applications programmer. So, why do applications programmers program in C++ when there are safer, higher-level alternatives? Another reason people wonder about the use of C++ is that it has other "issues" that have nothing to do with being imperative.

A reason that functional programming languages are so popular here is that there is a lot of interesting research being done in functional programming languages. (This is, as I understand it, mostly because type theory is typically formalized in typed lambda calculi, so implementing ideas is easiest in functional languages.) So functional programming languages have the same type of "foothold" on programming language research that imperative languages have in the business world.

Absolutely. It goes beyond type theory, too. Lambda calculi are used in all sorts of ways in other areas of PL semantics and theory. For example, providing a denotational semantics for a language boils down to defining a translation from the source language to a kind of lambda calculus. Any language can be defined this way, including imperative languages, and "untyped" languages. You can also, of course, use functional languages instead of "raw" lambda calculus for such definitions.

Using a pure language as a metalanguage to define other languages has many benefits, but it has some drawbacks, too. One of them is that various kinds of state have to be threaded through the definitions, passed from function to function. This is true even for definitions of pure languages, where environments (variable bindings), at least, typically need to be threaded in this way. For definitions of imperative languages, it's typically necessary to thread both environments and a store, to model mutable data cells. And for realistic language definitions, various other kinds of values may also need to be threaded.

This threading of multiple values complicates the definitions, and makes them harder to manipulate and understand. So back in 1989, Moggi introduced a construct to help modularize and simplify the structure of denotational definitions, a way to handle the passing of state implicitly. This construct was called a monad.

Later, of course, Wadler pointed out that monads were useful for functional programming in general. But their original purpose, for which they're still useful today, is to simplify models of programming languages, particularly imperative languages! Following a monadic definition of an imperative language, or writing one (once you've learned enough FP to do it), can give a lot of insight into the meaning of imperative languages, and imperative code. Ironically, while monads are one of the very things that a typical programmer assumes is a prime example of the impracticality of FP, they're actually one of the better tools for building theories and models of mutable state. (Some operational semanticists or temporal logicians might dispute that, but their math is hardly less "functional".)

So that's a glimpse into one big reason why there's an FP focus on LtU. Of course, the effort that has gone into these metalanguages over the past fifty years (counting Lisp as the first metalanguage) means that they have a lot of advanced capabilities, with rigorous foundations, many of which would benefit mainstream languages. So sure, there's going to be advocacy.

But to look at the material and discussion on LtU and come to the conclusion that "everyone here insists that FP is the best approach for programming" is simply a misunderstanding, based on unfamiliarity with the context and purpose of some of the core subjects being discussed here.

Thanks for this post, Anton -- it greatly clarifies how things got the way they are. I knew that "ML" stands for "meta language", and that scheme is basically designed to be proto-linguistic goop to experiment with control flow, but hadn't made the full connection. It also gives some interesting perspective into the perceived FP advocacy. We all tend to advocate what we're familiar with. I even advocate Perl sometimes (insert mandatory LtU condescention), because I'm very familiar with it, and it saves me a lot of time doing the text-munging, data shuffling, and automation that are necessary parts of my work.

I'm guessing (someone please correct me) that even within the language theory community there is a level of advocacy between type theory people, who prefer ML, Haskell and friends, and control/object/other-behavior-stuff people, who prefer Scheme/Lisp. The argument is probably much more civilized, or at least better theoretically-clothed, but I'd guess it's still there.

This isn't relativism -- I'm not saying these positions have no merits, or that it isn't possible for there to be a "right answer" in any of these language disputes. I'm just saying that the justification of a position often come after one has adopted it.

I'm guessing (someone please correct me) that even within the language theory community there is a level of advocacy between type theory people, who prefer ML, Haskell and friends, and control/object/other-behavior-stuff people, who prefer Scheme/Lisp.

You bet. Just search for "static vs dynamic typing" on LtU to get an idea.

The argument is probably much more civilized, or at least better theoretically-clothed

Not necessarily. Just search for "static vs dynamic typing" on LtU to get an idea.

:-)

Which raises an important question: how does an author delete one of their, um, less-than-constructive posts?

Which raises an important question: how does an author delete one of their, um, less-than-constructive posts?

Conversations should not be wikis, though as you know LtU does let you edit your own posts, so nothing prevents you from erasing history. Obviously LtU isn't as functional as Achilleas thinks :)

According to my sources, the theorists have much more effective means of resolving their disputes. :-)

It also gives some interesting perspective into the perceived FP advocacy. We all tend to advocate what we're familiar with.

Exactly.

This isn't relativism -- I'm not saying these positions have no merits, or that it isn't possible for there to be a "right answer" in any of these language disputes. I'm just saying that the justification of a position often come after one has adopted it.

To an extent, relativism is the right answer, in that there are no perfect positions, except possibly in some very specific contexts. If you've picked a language reasonably rationally, because its particular strengths match your requirements or even just your preferences, it's hard to argue with that choice. One of the only arguments that someone who disagrees with your choice can then make is that you've erroneously assessed your own requirements, e.g. by giving the wrong weights to features that your language does or doesn't have.

This is why the claims in these disputes so often attempt to elevate the importance of particular features, like static vs. dynamic typing, or purity vs. mutability, or macros, or tail recursion, to the point of claiming that the feature in question is so important, or so dangerous, that programming in its absence or presence, respectively, is a mistake. (BTW, absence of tail recursion is a mistake! ;)

There's a PL version of Godwin's Law in here somewhere. E.g. the question "Would you fly in a plane controlled by software written in language X, or with/without feature Y?" introduces a context designed to elevate the importance of some requirements, while ignoring the enormous class of other contexts in which those presumed critical requirements are less important.

I found your sincere comment on functional programming. I think you should read the original post again.

I wrote a long and detailed response, but cannot find a working email address for you.
If you'd like to read my response, send me a mail.

This is not a programming site, nor a functional programming site. It's a programming language theory site, and the language of theory is mathematics. Which isn't to say that everything must involve formulae - but theory is useless if we're not willing to involve some rigour, and in practice the mathematical notation is not far behind.

I think you'll find an unwillingness to display rigour more frequently (even if it's just that of making your ideas concrete by putting them into code - why do you think people rave about FPLs for specification?) has a lot more to do with your frustration than the maths. Insisting that your opinion is just as valid despite the pile of research in front of you just doesn't cut it, and nor do overgeneralisations or strong but subtly incorrect statements written as facts. We're not studying (just) an artform here, and solid facts that can be relied on are vitally important to our getting anything done at all - which means that it's in everyone's interest to avoid mistaken statements of fact being propagated.

I've learnt a lot in my time here, including a lot of maths - it's not the background that matters, at least not in terms of information, it's the attitude and the approach. If you were less aggressive in defending yourself I imagine more people would be willing to explain or show how your ideas fit into the existing landscape, and where the known flaws are. There's a reason most of the dependantly-typed programming languages look like constructive mathematics in drag, for example, and that's something that can be explained by comparing to some of your proposals.

...though I think that PLs also have a communication element involved, which lets some of the more subjective elements in the door.

[Edit Note]

I guess I should also add that the main focus from Ehud doesn't seem to be the quality or content of the stories/discussions but rather the dearth.

This is not a programming site, nor a functional programming site.

But computers are tools that solve problems, and theory has to be put in practice in order to see if the solution is practical.

It would be only beneficial if LtU was a programming site where programming theories can be put to test.

It's a programming language theory site, and the language of theory is mathematics.

I would say it is a pure functional programming language theory site, not programming theory in general. The focus is on pure functional programming, above anything else.

but theory is useless if we're not willing to involve some rigour, and in practice the mathematical notation is not far behind

I disagree. In order to grasp a good idea, first you have to write it down with words, describe its essence, give examples, and then formulate a theory.

I think you'll find an unwillingness to display rigour more frequently (even if it's just that of making your ideas concrete by putting them into code - why do you think people rave about FPLs for specification?) has a lot more to do with your frustration than the maths.

If you think that I do not understand the math, you're mistaken. But my philosophy is that in order to understand something, you have to grasp its meaning, initially without math.

It's the attitude and the approach.

Personally I respect differences of other people and I do not expect all the others to think and express themselves like me...I would never mock or insult anyone, even if they are less informed than me.

But computers are tools that solve problems, and theory has to be put in practice in order to see if the solution is practical. It would be only beneficial if LtU was a programming site where programming theories can be put to test.

Similarly: "But algebra is a tool that solves problems... beneficial if LtU were an Abstract Algebra site where..."

And again: "But quantum physics is a tool that describes electrons' motions... beneficial if Planck the Ultimate were a site were CPUs were discussed, like Tom's Hardware."

Specialization is okay. Some people even like it. There are different sites to cater to different areas.

The focus is on pure functional programming, above anything else.

It is not unusual to see discussions about O'Caml here according to my experience, and that is not very pure. Leroy's work on certified compilers has been discussed as well.

.. grasp a good idea, first you have to write it down with words, describe its essence, give examples..

It is not unusual that prose is incomplete, or leaving out important details. Taking a more formal approach will expose those holes (and force you to take a stand on them) and in general make the presentation more clear to your readers. Having a clear presentation is also a sign of respect for your readers.

More examples are needed out there, The Monad.Reader is one very good attempt.

This is not a programming site, nor a functional programming site.

But computers are tools that solve problems, and theory has to be put in practice in order to see if the solution is practical.

It would be only beneficial if LtU was a programming site where programming theories can be put to test.

On the contrary, it would generate large amounts of noise - not least people arguing about the meaning of the tests without having understood the theory in the first place. But certainly people have posted evidence resulting from tests of various scales here before.

Your suggestion that this is a pure functional programming language theory site has been tackled elsewhere, so I'll skip that - but second there being a reason that most theory involves pure functional languages somewhere.

but theory is useless if we're not willing to involve some rigour, and in practice the mathematical notation is not far behind

I disagree. In order to grasp a good idea, first you have to write it down with words, describe its essence, give examples, and then formulate a theory.

I don't see the disagreement here. In fact, Simon Peyton-Jones' excellent "How to write a great research paper" points out that one of the most important things for a paper to do is communicate the intuitions behind the maths - something I agree with thoroughly, and see happening here regularly.

If you think that I do not understand the math, you're mistaken. But my philosophy is that in order to understand something, you have to grasp its meaning, initially without math.

If you truly understand all the maths you're better at it than I! But past a certain level of abstraction, there can't be an "initially without the math" - only motivations, no structure, because if you gave the structure you'd be doing the maths again. This likely has a lot to do with some of the mistakes I've seen you make - for example, insisting monads are entirely about state (because you were given motivation and an informal demonstration of using them for it) despite examples like non-determinism or parsing monads.

Personally I respect differences of other people and I do not expect all the others to think and express themselves like me...

Me either. Thing is, I don't express myself "like me" on LtU. Readers who know me from elsewhere will realise I don't pun anywhere near as much on here - nor do I expect you to write articles drawing analogies between your code and your sex life! And while the mockery you've received here hasn't been entirely appropriate for LtU either, it's a far cry from what you would've received in many places that might be considered less "elitist" than here.

If you truly understand all the maths you're better at it than I! But past a certain level of abstraction, there can't be an "initially without the math" - only motivations, no structure, because if you gave the structure you'd be doing the maths again.

Math is tricky in that it is tower of increasing abstraction, each layer built upon, and abstracting from, the previous one. If you want to understand some of the higher layers you have a couple of options:

(1) Learn the axioms and definitions and push the symbols.
(2) Have worked with the previous level of abstraction enough that you have a good intuitive feel for manipulating and dealing with the constructions of that level, and can thus understand the abstraction from those constructions.

The advantage of (1) is that it gets you there quickly, with the disadvantage that you really don't have a feel or intuition for what you're doing and are at the mercy of symbol pushing to do anything. It's practical for working with stuff, but it doesn't impart much understanding - not until you've spent a long time pushing symbols. The advantage of (2) is that you step in with some degree of understanding. The downside is that it takes a lot of time to get to grips with the previous level - either you've got an intuitive understanding of the level before that, or you've been symbol pushing at that level for quite some time.

The problems tend to come when people take option (3) which is where you take the intuitive descriptions of someone who took option (2) and skip the symbol pushing part of option (1). Without the actual understanding of the previous level from option (2) you don't actually have any good intuitions about what's going on, and worse, because you don't even have the symbol pushing at your disposal you are inclined to just go with your intuitions which are more than likely wrong (at the higher levels of math anyway - math is surprisingly counterintuitive most of the time). Basically you're trying to understand something without the context - the intuitive descriptions given are great to give a vague idea, but ultimately they're only meaningful if you have sufficient context via options (1) or (2).

This is all rather off topic - except perhaps it is not. I think ithis is partly what makes discussion a little harder on LtU: given the level and breadth of material up for discussion here there is a fairly limited number of people who actually have sufficient background to comment well on any given item, and anyone else is left uttering vague intuitions that are often quite wrong. I have a string background in mathematics, but most of the high powered material here is sufficiently outside my particular field of mathematical expertise (with its rather more CS than pure math orientation) that I can rarely say anything sensible on the matter. I'm not sure what the cure is for this.

I just wanted to say that I liked this answer. I think it does apply to programming languages. I try to write programs (similar to pushing symbols) in languages that I don't really like just to combat my frequently wrong intuition.

The problems tend to come when people take option (3)

See this paper for a vivid example of prominent people taking this approach.

Care to explain, or are you just here to snipe?

Sorry, I was kind of cheap, but I couldn't resist bringing this one up, because when I stumbled over that paper recently I was astounded how it mistakes formalism for random use of symbols and formulas. It claims to formalise (parts of) the type system of C++, but the rules exhibit an amount of incoherence, incompleteness, hand-waving and general confusion that I have never seen in a paper.

I disagree. In order to grasp a good idea, first you have to write it down with words, describe its essence, give examples, and then formulate a theory.

If you think that I do not understand the math, you're mistaken. But my philosophy is that in order to understand something, you have to grasp its meaning, initially without math.

For low level and applied mathematics courses like Algebra, Trigonometry, Calculus, and Differential Equations, I have found that students have much more difficulty deciphering word problems than manipulating mathematical expressions. Drawing a picture usually helps to translate the obfuscated (natural language) into clear, precise, and unambiguous mathematical statements. I find that ideas are easier to communicate to students with pictures and the language of mathematics than with natural language.

But, even for something like Quanitative Business Analysis, there are linear programming problems with 5 or more variables. You cannot draw pictures then. So, how do communicate ideas in that area without mathematics?

Just my opinion.

I agree, I'd like to keep up with Andris' explorations. I don't always understand them, but they're always worth reading.

I'd certainly be interested. If nothing else, I imagine I'm far from the only person here who's not quite as familiar with the constraints of embedded systems as they'd like - and debugging capabilities sure interact with what's desirable in static tools. Hmm, and now I'm thinking a bunch of thoughts about debugging lazy languages...

Debugging is an interesting and useful subject, though there'd have to be some tangential tie-in with programming languages. What in PLs makes debugging easier/harder - lazy evaluation adds an extra layer or two of indirection.

Programmer: debugging is a persistent problem in my daily practice. I would like to know more about theoretical approaches to debugging techniques.

Language theorist: debugging is a solved problem. Just use a language with a reasonable evolved type system, then you don't have to debug your programs at all.

Programmer: hey, what kind of language does this magic for me?

Language theorist: oh, there are some very important typed lambda calculi and sugarizations. All of them are deeply intimate with Curry-Howard who stated a corresponce between types and proofs. If you will I send you a list of very interesting papers that explain them in detail.

Programmer: hmmm... typed lambda calculi... I'm more the practical, engineering guy and would like to play with an implementation. Can you recommend any?

Language theorist: well, there is some prototype implementation from 2002, which is implemented in Arrow-Haskell, a dialect of Haskell. I don't know in which shape it is but it is written by Luis Picardello, a well known type theorist who has also written sophisticated papers about weak n-categories and their use in cryptographic protocols.

Programmer: ... and tools?

Language theorist: as you know, industry is driven mostly by hype, marketing and stupid persons. So there isn't much money spent for good tools, for good languages and well educated programmers.

Learning is a discussion for me. I write notes, ideas, and reactions in the margins of books I own, in notes files on my computer.

For example, Epigram is a good place to apply everything that Types and Programming Languages teaches, and the syntax is even related.

For Alloy, I'd love to see a short intro that includes screenshots.

For Scala, I'd like to see some of its code snippets compared to imperative and purely functional languages.

I think that if you document your learning and your questions as you go along, it will invoke much discussion and learning.

I'm unsure how to respond to that - I thought "really learning what I can do with these things" was clear enough, I guess I was wrong.

I don't think you can learn much about Scala without writing programs in Scala. There's nothing novel in the idea that "book learning" is a poor substitute for doing. There's a euphemistic phrase I overheard as a child, which meant nothing to me as a child - women gossiping about some man - all mouth [sic talk] and no trousers.

(And instead of looking for a short Alloy intro that includes screenshots, I suggest you start with the tutorial on the Alloy website.)

Ehud's email address is on the Feedback page.

I find misleading to say that LtU is exclusively about theory.

Some finer distinctions need to be made, I think.

LtU may not be exclusively about theory, it is one of the few places of its kind to discuss PLs informed by theory.

There are umpteen places on the web for people who just want to discuss PLs in general. I think LtU serves its constituency best if it focuses on PL issues through the filter of theoretical understanding, even when not discussing narrowly theoretical topics.

Remember that the word "theory" in this sense need not mean "otherworldly", "impractical" or "mathematical"; it simply means a framework resulting from careful thought that organizes the topic in some internally coherent way. There are a number of different approaches that fill this bill.

LtU has not always succeeded in sticking to this principle of a "theoretical filter" on the topic, but I think it remains the ideal that most long-time members strive for.

LtU may not be exclusively about theory, it is one of the few places of its kind to discuss PLs informed by theory.

Well said.
I am happy Marc says LtU is not only about discussing programming languages theory, rather discuss based on PL theory. It makes me feel I am at the right place. How do you feel?

The main beef I have with LTU is that it rarely discusses human factors of programming languages.

I'll respond to this, since for a long time I was "Mr. Human Factors" here on LtU, and I still think these issues are important, but with some caveats.

The first is that, as with any design criterion, "making things easy for users" is dependent on what you want to make easy and who you see your user as. What Matz thinks is intuitive is what a native Japanese-speaker who admires Perl thinks is intuitive. A native English-speaker who reads a lot of math might think Haskell is more intuitive.

It is very hard to have a sensible conversation about these issues unless you identify all the hidden assumptions that go into your notion of "easier", and these are very slippery and very hard to discuss in a forum such as LtU, though on occasion we have managed not too badly.

The second caveat is the realization that I made a long time ago, but which has deepened over time, that "human factors" are actually built into any good theory.

A theory is usually considered good if it has "elegance", a human factor par excellence, that amounts to decomposing its ideas into their pithy, fundamental elements. A deep theoretical understanding makes it easier to understand the complexities of design and programming. A theory which doesn't make it easier for people to understand these things is unlikely to have many adherents.

While the technical language that the theory is couched in can require some initiation, this is one of the strengths of a community like LtU: you can get some human context in ordinary language to help support your own investigations into the terser domain of theory.

I object to the specific term "intuitive", but I would greatly enjoy seeing some cognitive science research about programming.

Does anyone know of research like e.g. a
study of people programming in fMRI machines, a characterization of programming performance as a function of API in the style of experiments on working memory size or long-term memory formation, etc?

About "intuition", I like Jef Raskin's article Intuitive Equals Familiar. According to my vague recollections, all the claims I've seen that Ruby is intuitive seem to run much like Tim Bray's, saying something about "guessing at a syntax or a method or a usage and getting it right the first time", which sounds very much like familiarity (supported by things like syntax borrowed from other languages, and multiple synonyms for library functions, to copy several other languages).

"It is very hard to have a sensible conversation about these issues unless you identify all the hidden assumptions that go into your notion of "easier", and these are very slippery and very hard to discuss in a forum such as LtU, though on occasion we have managed not too badly."

I agree. Hence I would rather see them discussed on LTU rather than an HCI site. Ignoring factors you pointed out such as local spoken language preferences, I would like to see more rigorous human complexity measures we can apply to programming languages and libraries.

Toy example printing in "C" vs "C++" (ignoring formatting parameters):

cout << "2*3=" << 6;
printf("2*3=%d",6);

What complexity measures can we come up with for these?

Lets look at their grammar:

C++:
START: "cout" EXP PRINT_PAIR ";";
PRINT_PAIR: NULL| "<<" EXP | "<<" EXP PRINT_PAIR;
EXP: (a valid C++ expression)

C:
Um. I think you need a stack or two to match all the "%d, %f, %s" statements with their counterpart arguments at the end of the function.

If our complixity measure is what level of the Chomskey heirarchy does the human have to preform at then "cout" would beat "printf".

If our complexity measure is number of symbols then "cout" wins because it doesn't have the laundry list of "%d,%f,%s,...".

That was just a toy example, but I think it illustrates that we can use rigor in defining how complex it is to use a programming language or library construct.

//edit: 2*3=6 not 3 :-), cleaned a redundant sentence

Human factors were discussed many times on LtU, from a vareity of different perspectives. I suggest searching the archives.

Thanks for the tip. I have only browsed the archives by hand so I did a quick google of the LTU domain with "human". Found a lot of stuff I had missed.
Google query(human site:lambda-the-ultimate.org)

That is a good reading list for the weekend.

That was just a toy example, but I think it illustrates that we can use rigor in defining how complex it is to use a language construct.

You've chosen for your example a fairly clear case where the syntax and semantic design choices of the particular construct map nicely onto each other when considered in isolation.

But the challenge is to find principles that scale to the whole system and to the general case, and this is quite difficult.

The best approach I've found so far is to first understand the semantic model of a language (theory again ;-)) and then examine the mapping between syntax and semantics for ambiguity. (The design of Oz is one I would recommend as a paragon in this regard.)

Working from this basis, the C++ example doesn't necessarily fare so well, since it creates expectations for the streaming syntax elsewhere in the language that maybe aren't so easily parsed.

The bottom line is that any human interface can only be evaluated if you have a good model of the domain it is intended to represent and manipulate, and how that domain interacts with the entire language system.

This discussion about the "human interface" within the Ruby community turns out to be an insane version of New Age stalinism. Dividing languages or language constructs into human and inhuman is bogus and leads to a false sense of the naturality of artifacts. The level of self reflection among programmers tends not to be very high in general but some enlighted Rubists who start programming language flame wars with the opener "I as a human being..." deserve to be in the category of the retarded programmer. I do not think that LtU or any other serious medium shall care about this a lot. HCI is a complex issue that depends on many factors including ones own experiences with other media and an inner design logic ( "monotonicity" according to Jeff Raskin ), not sectarian propaganda. The key term "intuition" shall be reserved for Kung Fu movies but not design studies.

1) LtU encourages very knowledgeable people to write almost exclusively.

2) Never ending discussions are discouraged by the format of the board.

3) The size of the population capable of discussing these topics at these levels is limited.

I never for a moment iamgined that you left us! Get well soon!

I'm still here/back. Right now I'm catching up with about four months of LtU. I might actually decide to request to become a contributing editor in a month or so. I, unfortunately, haven't been reading too many (um... any) papers etc. recently, but there is some content that I'd like to make that should be of interest to LtU, and anyways, I will sooner or later (sooner) get into some crazy PLT topic and post about it in my indirect fashion. In fact...