Lambda the Ultimate

Why do we pursue language designs and the issues that are coupled with the design?

Myself, I look at languages as tools for dealing with problems. Ultimately I care not about the workings of the tool(s) as long it does what I want it to do with a certain amount of ease. I guess that is often why I tend to lean more towards the quick and dirty languages like Lisp, Python, Javascript, and Perl (well not as much Perl because I usually can't read what I wrote afterwards, which is the same reason I print instead write in cursive).

I guess I find it hard to see programming languages from a research point of view. My mindset when looking at research goes something like 'do I need an operator for this', 'is this character intuitively representing its use', or 'how many keystrokes, and how far do my fingers have to move in order to accomplish X'? If I was to place blame, I would have to say that Donald Norman's "The Design of Everyday Things" did this to me. I can't look at anything with a blissfully ignorant eye, not wondering if design X of the product Y is the best for me.

With my reasons expressed (though short and potentially ambiguous), I would like to know the intentions others. I would like to know what I may be potentially missing from the field.

Thanks guys. =)

I think we should distinguish bbetween research questions and language learning in general.

I simply like languages, and enjoy exploring them. It is interesting to see different approaches to similar concerns, play with interesting language constructs (e.g., continuations) etc.

When it comes to research you must focus your attention if you want to get anywhere. I try to find problems that seem widespread, and whose solutions might improve the state of the art (in my cases, I try to think about software engineering issues). The next step, which is at least as important, is to sift through your list of problems and try to focus on problems that you think can be attacked with tools and techniques we have, or at least problems that are "close enough". If you have a good nose you may find fundamental questions that can improve the basic scientific tools we have. These questons go back into the list, for another round of evaluation...

For what it's worth, my interest stems from a belief that our current programming languages are inadequate to the what is needed.

Hardware is evolving away from a single CPU core clocking at ever increasing frequencies towards multiple cores clocked for a better power/performance ratio. Although I've said this for years, both Sun and Intel have recently started putting out press releases saying the same. (Incidentally, I don't claim any great foresight, I think it has been blindingly obvious for a long time, just look at Backus' ACM Turing Award speech and his comments on the "Von Neumann bottleneck").

But our existing languages have not been designed with this in mind.

Another issue is that of abstraction - we need more of it. I don't want to have to tediously describe to a compiler how to perform a loop. After the first time it was a waste of effort.

I want high-level languages that will allow efficient, reliable, distributed processing.

Because we don't know how many processors we are going to have in a distributed computing net we should not be having to annotate our code with "par" and "seq" constructs. The best suggestion I currently know of is the "dataflow parallelism" used in Oz, pH (parallel Haskell), and their ancestors (and any cousins?). That doesn't mean there are better alternatives that I haven't yet heard of.

Reliability is important. You don't want the program controlling your car to crash in case you do as well. Static Typing helps here, and most (non-FP) languages have appalling, buggy Type systems (if any). But even here there are competing ideas. On the one hand Design By Contract (Eiffel), and on the other Erlang's fast crash recovery.

And efficient because despite all the above, the programming community will not move to such languages if the performance penalty is too great.

I'm unlikely to get everything I want. But a sizeable subset would be nice...

This of course relates to David said about type systems. Though I have never been fond of them, mainly because I broke my crystal a long time ago and now I cannot see into my source's future, I can see their use in reference to productivity (which of course references SE).

On the side of abstraction, I couldn't agree more. Early Java implementations of concurrency is a very good example of poor abstractions. Though I must say that primitive (ie, lower level) languages have their place. As I stated earlier, I don't have a lot of care for the underlying mechanism of a language implementation as long as it does what its told, and provides a means of informing me that I am using it incorrectly.

David also brings up an excellent point about distributed processing. I, myself, have never had more than a one processor machine, but my interests lie within the web and therefore ultimately deal with distributed resources.

I am making this is a special focus in Color. I am completely awe-strickened by zeroconfig systems like Apple's Rendevous, and VSTa's network transparency, and think that these technologies provides some interesting insights into the new world we program in.