The Future of LtU

Recently the homepage is almost dead, and the discussions about important papers that are mentioned on the home page almost non-existent.

I am sad to say that if this continues LtU will fade away - something I am sure none of us wants.

This is a cry for help. If you are an editor, please try to post news you come across that might interest the LtU community. Take part in the discussions (you don't have to participate in all of them! participating in discussions on "static typing" is optional...) If you are an editor, are reading LtU, but haven't posted in a long time, don't feel you have become an outsider. You are still part of the team, and I for one am interested in what you might want to share. I know some long time editors got discouraged for various reasons -- I think now is a good time to return and reshape things to what they used to be.

If you are a regular reader and participate in the forum regularly, if you think you understand the spirit of LtU, how about signing up to become an editor? The process is simple (basically, you have to email me and that's it).

Many of you have personal blogs, and they are great resources. I still think the LtU community effort had an additional value it'd be a shame to lose. If you agree - post!

Finally, if you are a programming language scholar, and are reading and enjoying LtU - how about signing up to be a guest blogger?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

RSS

I, like I'm sure many others, read LtU through RSS. This unfortunately makes it (relatively) hard to carry on discussions as opposed to simply passively reading. This is mainly due to the fact that RSS and Atom were created by people who's definition of success is how many people read their blog.
I suspect this is part of a general decline in discussion on forums on the web caused by RSS and the like. It would be nice if someone were to create a protocol that extends RSS to include threading capability (allowing comment viewing) and has posting capability (perhaps authorised by OpenId). It could be called NNTP...

Declining spirits / rising spirits

A decline in the spirit of LtU may be conterbalanced by a rise in the spirit of Christmas. I wouldn't be surprised if things pick up in the new year.

Becoming an editor

I've been reading LtU for a long time, and I often find myself wanting to post some article about something I've read. However, I always feel that I'm not experienced enough, and that I would need some guidance to get the "article right". Is there some possibility to have a mentor editor who will help review articles before posting ?

BTW, I was unable to find your email, but I there is somebody to review my posts, I would be really happy to become an editor !

I must admit that the

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)?

Editing

I am not knowledgable enough to edit academic works, however if there is something positive I can do to help, I would be happy to spend a little less time on my own blog and more time helping Lambda the Ultimate.

Quality not quantity

I am bemused by the frequent worry about the supposed paucity of posts. I don’t find them infrequent and neither do I see how their infrequency would be a problem (probably because I too use RSS).

However, I agree with Zombywuf that RSS may be having a negative effect on the discussion of posts. I for example read posts soon after they have been posted and tend not to check back later for comments, as manual checking is no longer part of my routine (not that I comment anyway, but I hope you understand my point). Perhaps the solution is feeds for the discussion of each post. Although, this assumes that it would be worth it, which means high quality discussion and that it is very easy to subscribe and unsubscribe to feeds in the popular aggregators. Or perhaps the topic poster could elevate choice comments to the feed (which would give discussion more status). Anyway, it seems to me that the situation could be improved by an interface which induces better behaviour. Unfortunately the interface options are rather limited.

LtU

You might think LtU is on a decline, but I still find it an excellent resource. So the discussion might be a little lower than usual at the moment, but I still think it's a great site.

Agree

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.

ACM Library

Can we somehow persuade the ACM to open the contents of their Digital Library for free access to everybody? That would provide at least a decade worth of good "new" material. LtU would be the ideal vehicle of (re)disemmination.

Seriously, wouldn't that be a great thing for them to do?

I doubt ACM would be willing

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.

Natural ebb and flow, plus uncertainty

There is a natural ebb and flow to a lot of these things. Even Slashdot seems to have its ups and downs. And some of us silly academics have all these students to take care of that seriously interfere with LtU time!

Another issue is that I frequently encounter papers that should be of interest to LtU, but really don't know if they have been discussed before. Maybe if there was a master .bib file (or equivalent!) for papers that have been seriously discussed on LtU?

To make this note a bit more substantial: hop on over to CiteULike and leaf through various people's lists of papers. I certainly recommend dherman, rwtodd and JeffreyPalmer's list of links. I have a bunch of links too, but I imported the bibtex of all my papers onto CiteULike recently, and I don't want this particular post to be too self-serving.

LtU Meta Information

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

I keep an offsite Index of LtU Topics. My usual manner to determine whether a paper has been discussed before is that I just grep for the URL in my local copy of all the LtU posts and see what turns up. A link to the zip copy of all the LtU posts is at the bottom of the topic index page. I generally try to update the topics and files once or twice a month.

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).

Natural ebb and flow

I know I'm feeling a crunch at the end of a semester.

I signed up for an account now just so I could be counted. There are plenty more of us I'm sure who don't feel we yet have anything to contribute to this discussion, but are very interested in reading the articles and reading the comments.

Please keep doing what you're doing.

Thanks for the great blog.

School Related Ebb and Flow

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?

A lurker's apology

I'd like to second previous comments from richmassena and Zombywuf; I'm an an inactive 'participant', mostly because I would like to keep up the quality of discussion!

I'm with the other mostly-lurkers...

The intellectual level of discussion here is much higher than I am used to so I don't feel much ability to contribute outside the odd question here and there that probably make me look like an idiot. I do not have a heavy academic background nor the talent of being able to quickly comprehend papers thick with alien words.

LtU makes it hard for the layman to get involved.

And yet that is LtU's greatest strength. It is why I keep coming back for more - even if just as a reader. It is rare to find discussion sites which steadfastly refuse to cave to the lowest common denominator. That commitment to quality impresses me.

I'll be honest - at times it feels like there's a party going on here that everyone keeps talking about, yet no one will invite me to. That can be frustrating. Even so, it sounds like a party good enough to try to get in to - and so that motivates me to think and read and try to force myself to comprehend. I'm pretty sure I learn a little something new everyday thanks to LtU. The power of this site is not its breadth - but its depth.

I have many of the same

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.

Another lurker reporting in

I'm a student (undergraduate) and although I'm very interested in programming language theory, and I've done a fair amount of coursework on the subject, I don't have enough time right now to carefully read most of the papers that go by on LtU. I'd like to participate in the discussions, but I don't usually have anything to say...

In fact, I'm looking forward to graduating so that I'll have some time to start keeping up with PL research as well as going through my bookmarks and re-reading the most interesting papers I've seen here.

So in any case, I enjoy watching the site and skimming some of the papers, and I hope one day to be able to contribute regularly. I'd be quite sad if LtU went away before I had a chance to do so.

Programming is not only mathematics.

Ehud, you and others almost show no mercy for people that are not willing to contribute without quoting something with mathematics in it!

Programming and software engineering are not only mathematics...there are lots of aspects to it. If you don't encourage other styles of posts, then it is only natural that contributions will go down...progress in the sector or mathematics that deals with programming is really slow for a blog that wants to be updated on an almost daily basis.

My proposal stands; split LtU in two: a scientific only forum where people debate the mathematics of the programming languages, and a general forum for anything that concerns programming: discussions on programming languages, solutions, reviews of libraries, wild ideas and of course the social aspect of software engineering.

Even code snippets in the style of codeproject (with a rating system and such) would add something valuable to the site: you and other more informed members of the functional programming community will get a window on how most of us average programmers think, and therefore get to understand how and why functional programming languages are not adopted on a wider basis.

In other words, if you want discussion to thrive, let the people that are not mathematicians to come to the site and post.

And in the long run, more people will get to know functional programming, and that's could only be beneficial for the world...

Adoption of FP.

... 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

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.

Discussion forums

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

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.

21st Century Boy

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".

a) everyone here insists

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.

FP in PL theory

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 (+ off-topic)

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.

Advocacy

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.

:-)

*wince*

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

Which raises an important

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 :)

Conflict Resolution

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

Relativism

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.

A sincere comment on functional programming

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

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.

I mostly agree...

...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.

It should be a programming site as well, though.

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.

a toe in the tarpit

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

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

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

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.

Probably not-OT

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.

Example

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

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

Explanation

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.

A picture paints a 1000 words

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.

Maybe a mailing list or newsgroup?

I agree with others that rss (and in my opinion also web fora)
doesn't stimulate discussion.

Maybe the trafic of LtU could be *mirrored* in a mailing list (or
versa-vice), which people could also read in their news reader, thanks
to gmane.org.

Diversity

What LtU really needs is more people like Andris that are willing to share their journey through the PL landscape. That, and we need people that post stories from different perspectives.

Keeping a site like LtU ongoing faces several problems. On the one hand, there is the possibility that the quality of stories and discussions goes down with proliferation (LtU becomes populist). On the other hand, there is the possibility that they become so high quality that a certain intimidation factor creeps in (LtU becomes elitist). And on the final hand (being an economist by education, there is always more than two hands), there is the problem of overfamiliarity (we discussed this paper in the past, so why rehash what has already been discussed amongst us).

Anyhow, my vote goes for diversity as being the best path for LtU in the long run. Certainly it's great to have stories posted by the experts and teachers. But it's also refreshing to have stories posted by the learners and students (flawed posters are a necessary ingredient).

Yes, more from Andris please.

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

Yet another lurker

I don't have much to add to what the other lurkers have been saying... I'm also not a scholar, and I only have a cursory understanding of most of the articles posted here. That said, I do feel I learn a lot from them, but I don't feel I can really add to the discussion.

If the community would like, I could drum up some white papers on debugging embedded systems. It might feel a bit commercial, since they'd almost certainly be from the company I work for (Green Hills Software).

Anyway, if you're interested in real-world (non academic) debugging solutions using embedded trace, I can post something.

Keep up the great work!

I'd certainly be interested.

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...

Would need a PL angle

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.

Step out of debugging

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.

Read and Discuss versus Download and Learn

Just three examples should be enough - Epigram, Scala, Alloy.

Once I've read the first couple of papers, and become interested enough to download the software, really learning what I can do with these things could absorb months of my time - there's nothing left for discussion.

Learning is a discussion for me.

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.

really 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.)

Blog Proposal

If anyone is interested I'd be happy to blog about my experiences with programming language theory from my beginner's perspective (beginner at least when it comes to type theory, I have been programming computers for twenty years).

I am currently researching kind systems, SK calculus, row polymorphism, and first class polymorphism as I work on a formalization of the Cat type system. I'd very much like to write about what I am learning, what I am reading, my observations, and my obstacles, but these topics are too advanced or specialized for the bulk of my readership in my current blog at Artima.com. On the other hand my naivete to some of the cornerstone topics in programming language theory might not be appropriate for the more scholarly members of LtU.

If we were to clearly label the posts for what they were, perhaps it would make it easy for the more advanced readers to filter them. Perhaps some kind of "beginner's corner" section of Lambda-the-ultimate.org also would be a good compromise?

Just some thoughts. I'd email my proposal to Ehud, but I can't find his email.

Sounds good

Ehud's email address is on the Feedback page.

Learning the Ultimate

I don't have a formal computer science background, but am a programmer by profession and am deeply interested in language and computing organization issues. Having played with Haskell, Scheme, Erlang, and just about any language that comes up, these days I'm focusing my language passions on my own scheme dialect to building DSLs.

I've found LtU a great resource to learn about aspects of programming languages and computation. It won't die :)

Theory of programming languages

That may run against the "Spirit of LtU", but I find this site to be a useful resource in learning about existing languages and language tools. I find misleading to say that LtU is exclusively about theory.

First of all, a great deal of theory is there to address practical problems that a programmer or even a computer user may meet. Discussing and identifying them helps language theory like publishing papers does.

Secondly I have a couple of suggestions to make LtU more of a community effort. Make a Suggested Postings forum. Another quality site I visit has one. Legitimate publishers can promote posts in that forum to site news. Posters need not worry if the subject is new to LtU or was already beaten to death.

Also invite the authors to the discussion. Create an account for them in advance if necessary. I am sure the LtU standards will make a few of them feel at home and contribute significantly to the discussion, raising the standards further.

Here, I look forward to your opinion, specially on whether discussing non-theorical issues of existing languages should be encouraged.

Theory as systematization

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.

to discuss PLs informed by theory

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?

Human Factors

The main beef I have with LTU is that it rarely discusses human factors of programming languages. As a human I have a limited memory and limited attention span. Ruby isn't great because it has some new feature, it is great because Matz spent years polishing the standard library to make it human. I would like to see more articles studying how we can simplify language constructs to reduce their human memory load or human search time when programming. Analysis of the grammar shape, number or tokens, useful abstractions for common data types and algorithms, ability to do distributed memory computations, tools for pointing out ways to improve our code, optimizing compiler issues, ...

Human Factors Blues

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.

Human factors vs. Intuition

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).

More detail

"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

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

Thanks for the tip

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.

The Challenge

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

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.

A small suggestion

The natural state of LtU, given the constraints is going to be a declining volume of comments. Here's why:

1) LtU encourages very knowledgeable people to write almost exclusively. By in large weaker posters (that is people with even more esoteric expertise, less knowledge and less experience) are encouraged to post less often. This results in an excellent signal to noise ratio but means the bar for new members is always slowly rising as the background knowledge increases.

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.

(1) is on balance a good thing, and arguably (3) is what LtU itself exists to change. So the only low hanging fruit is (2). Here is what I would suggest:

a) Discussions are able to delink themselves from articles. That way if a discussion wants to continue for weeks or months with a half dozen people it can (i.e. something like what Usenet discussions were like 81-95). Right now a discussion that is just about to become interesting will often die as the article moves to a lower position.

b) Articles refer back to "classic" discussions on related topics. That way people can read and comment on how the article effected the older topics and bring back readers. Again delinking helps here.

c) People receive email notification when someone responds to one of their comments. This encourages the thread to continue. It also encourages people to respond to articles on obscure topics if they would like to discuss them at some point in the future (i.e. they are sort of leaving a message behind for someone to come along and create a thread).

d) Have a community written LtU FAQ. Nothing encourages group conversation better then writing an FAQ. Further the FAQs are remarkably useful once written because of the amount of collaborative intelligence.

e) Have fun threads ("Worst type system ever invented", "Unlambda as a first language?", etc.. ) where people can learn LtU concepts in an online discussion without the expectation that their comments are being taken seriously. These could (perhaps should) be on a different subpage.

1) LtU encourages very

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

There's all sorts of places where the knowledgeable and not so knowledgeable can discuss things in isolation. Perhaps it's just because I belong to the latter group, but I've always thought the goal was to have LtU as a neutral ground for the two sides to meet. Those that are experts are asked to have the patience to teach, encourage and inspire. In turn, those of us that are non-knowledgeable are asked to be inquisitive but respectful.
2) Never ending discussions are discouraged by the format of the board.
I rate this as a good thing as never ending discussions usually drift way too far from the origin (Godwin comes to mind). I'm biased but I think the maximum depth of the discussions is somewhat optimal, encouraging fresh starts. I don't think the problem is that there is an upper limit on the number of posts per story, but rather that we have come well short of that limit of late.
3) The size of the population capable of discussing these topics at these levels is limited.
Although I'd agree that there is an optimal population size for the LtU community, I still think there's room for growth. An influx of new people is always nice so that the discussions remain fresh. A point to remember here is that it is usually the front page stories that attract new people. The number of readers that regularly scan the front page is much larger than those that scan the forums. However, if the items on the front page just becomes a place to post links with no discussion, then LtU becomes little more than a bookmark page.

Branching out?

I think having a site dedicated to programming language design (PLD) is great and I do not know of any alternative to Lambda the Ultimate! How about branching out the LtU franchise? I would suggest three sections, for which I'll also mention role models:

  1. Meta-blog: people are both vain and lazy, with the vanity sometimes countering the laziness. So, one has to learn to use their vanity productively. I would love to have a new part of LtU that merges some of the dispersed blogs (and news) out there and consolidates their information in one place.
    Role models: Planet RDF and Eric's Link Blog.

  2. Forums (plural!) with email alerts: It's difficult to participate in a forum if you have to check manually if there has been progress. openrdf.org uses mvnForum which works really well. Currently, I see one forum at LtU; why not have several ones, dedicated to different topics? I don't know what would be adequate here, maybe something along the lines of "experience reports", "language design", "exciting papers" etc.
  3. A section with high-quality blog entries on PLD. This section would have lower traffic and its entries would be fed into the meta-blog mentioned above. And guess what: The role model here is the current LtU main page.

I think having a site

I think having a site dedicated to programming language design (PLD) is great and I do not know of any alternative to Lambda the Ultimate!

Each site that comes up with an alternative project is also an alternative to LtU. Focussing on the practical side of language design and offering current or future language designers technical expertise and news ports is an interesting idea for sure. But it has to be realized by someone and stand on its own. I suspect the academic focus on LtU would become burried. Another objection is the wording. Lambda the Ultimate is a great title for a page for discussing CS papers but I would hardly unify PLD under Church of Lambda.

Quick Note

I just want to briefly say that I'm still here, still excited about programming languages and language design, but have largely been quiet over the past few weeks due to a combination of not having come across much that I felt was of sufficient interest, time taken for the holidays and, most recently, because I've had Lasik surgery. That last bit is great news for a guy whose uncorrected vision was on the order of 20:200+, but when the correction is so aggressive as to result in something approaching 20:30 vision, it takes a bit longer to recover. :-) My surgery was on Friday, and it's really only today, for example, that I can actually read LtU without feeling like I'm straining, and my eyes still look like I just got in a bad bar fight—presumably over static vs. dynamic typing. ;-)

So let me just add that there's a natural ebb and flow to these discussions, it's the holidays, and while it's always great to see some new editorial blood (welcome aboard, cdiggins!) some of us old(er) guard are still here and will be back in force as interesting new items, schedules, and eyes allow.

I never for a moment

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

Incidentally

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...

LtU must not die

I agree with many who said that there's a natural ebb and flow to these discussions, since I started reading LtU (2003 IIRC) there have been a couple of times it was moving slower than usual. I even dare to say that interesting research isn't so frequent these last couple of months as some times in the past. Also many of us are still trying to fully digest old papers/discussions (I know I am) and don't get too involved with current discussions and revisits to already discussed topics (e.g. I didn't have much interest in seeing the STM video, since I read almost everything about it via LtU).

LtU is the best (IMHO) resource for PLT discussion, even if it moves slower than a lazy snail ;)

Please don't

Please don't consider ceasing ltu activities. While more content would be greatly appreciated, the current level of content is more than sufficient to warrant ltu's survival.

Please, please, please
do not go-ooooo-ohoh

For my part I've had so much

For my part I've had so much hacking to do these past couple of years that when I've found spare moments I get as far away from computers as possible. :-) Lately my curiosity is awakening again.