Lambda the Ultimate

I agree wholeheartedly, in the strong literal sense of "incredible" -> "not credible."

...that I have heard.

First, is the conventional attitude around here, which was first expressed by Tony Hoare: the job of the language designer is usually consolidation rather than innovation. Figure out what people do that works, and then find a way to re-express it in the simplest and cleanest way you can. This is unarguably a good idea.

But there's a counterpoint to this view. John Reynolds told me that he once described a correctness proof for XORing together pointers in a doubly-linked list to someone. This person asked why he would ever want to prove such a disgustingly nasty hack correct, to which he replied that it was no longer a disgusting hack, because he had a clean proof of correctness for it.

I think they are very closely related. A lot of language design is inspired and driven by SE insights. Yes, there is thereby the danger that you restrict the programmer to what you think is good SE, and what is good SE is extremely subjective. One reason why people like C++ I guess, it has endless options to fill in your own kind of SE... much like people enjoy configuring their window manager etc :)

My own SE insights of the last few years have been of a kind that is not expressible as a programming language feature, with as a direct result that I have had less of an urge to design new programming language features.

This should be obvious to LtU regulars who are subject to PL theory papers on a dialy basis, but from my experience this fact is often overlooked by many academics and practitioners.

I find it incredible that some would argue that PL designers should be agnostics when it comes to SE.

I argued that, and I'll argue it some more if you insist.

Here are several reasons why PL design and SE shouldn't be mixed:

• Software engineering is not nearly as formalized as programming language theory. A SE-supporting feature introduced in a programming language can still be formalized in the context of the language, but the reasons for having it can't.
• SE fashion is changing much faster than the PL theory or the PL technology. A language filled with SE-supporting features will soon be obsolete.
• Even worse than adding support for SE features into a language is restricting the language to be unable to support SE techniques that went out of favour. The most famous example is probably the goto statement. While goto certainly can be harmful in hands of a bad programmer, and does much harm when it's the only control structure, there are situations when it's the best alternative.
• Every language can be viewed as a mathematical theory, a logic to be exact. An actual formal mapping between a language and the corresponding logic is a very complex and not very rewarding task; but whether the language designer is aware of it or not, he will apply in his design the same kind of rules a mathematician would use. You've heard of "beautiful theories". A language can be beautiful too. The aesthetic criteria include simplicity, self-consistency, and something I can't find a word for, but means that the reason for every part of the theory has to be evident from the theory itself. For example, the cosmological constant is often considered the "ugly part" or "bolt-on" in the General Theory of relativity because the theory itself doesn't actually require it (it's a simplification, I know). A SE consideration added to a language ruins all of the three criteria. And aesthetic does matter even in practice.
• PL design is a complex affair, but it is simpler than SE the same way mathematics is simpler than sociology. It's easy to make a mistake in the language design. It's much easier to do it when you're trying to help users by adding usability features. You don't know your users. You don't know what they'll use the language for, and you don't know how. All you really know is the language itself.
• And finally, if your language is good (and Turing-complete), it can support any SE technique. All it takes is a little discipline.

A disclaimer: I won't bother to list all reasons why SE matters, but that doesn't mean I'm not aware of any. The list above is one side of the argument. It's all true, but it's not the only truth.

I wholeheartedly agree that programming languages and software engineering *should* be more strongly connected, but one of the things I have been increasingly seeing is the need for better tools.

For better or worse, I write a decent amount of code in C on Windows, and I have experimented with several open source IDE's(with GCC being the compiler at the heart of these IDE's) and Microsoft Visual C. I have found that many of the free/open source IDE's seem to be lacking in the area of help, documentation of the language(I don't have all of the standard library memorized...), and even the quality of the error messages generated by the compiler.

I have often wondered what kinds of improvements programming language designers could make to their languages if they considered the development environment(I suppose Smalltalk would be the poster child here). After all, a very slick IDE for C could make it a much more enjoyable experience to program in, and while Lisp style macros are one example of the ability to change a language, how much of this power could be "simulated" by an IDE(and would it really count as being "faked"?).

I realize IDE's are a very base kind of CASE tool(traditionally the domain of SE), but why _can't_ the IDE and other aspects be part of a programming language design? I mean is a plain ASCII text file the culmination of how to _express_ a program?

How many examples of CASE tools are really an exercise in language design or extension of an existing language?

Of course, I'm just a lowly graduate student(in math no less...) :)