PLs and SE

it's never a language designer's job to define what's a sound software engineering practice. (on the Why Are Type Systems Interesting thread)

Setting aside the discussion on static vs. dynamic type checking, I must say that I find this statement rather puzzling. Aren't PL designers suposed to make SE easier? Isn't the best way to do this to evaluate and consider SE parctices? Isn't that what happens in practice (e.g., mining patterns for language features, library building etc.)?

When I created the software engineering department on LtU I wanted it to focus on language features and language design that are directly concerned with software engineering issues. But my view is perhaps even stronger than that: I think most PL issues are ultimately about SE.

Natrually, one approach is for the language to support whatever SE practices each and every programmer or team chooses. But isn't that simply an example of one sttitude towards the best way to handle the complexity of SE?

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

Comment viewing options

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

Incredible

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

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

This reminds me of a couple of epigrams...

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

agreed

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.

Suspicious

Personally, I am suspicious of SE concepts that cannot be formally encoded as programming language features. It's pretty clear we are far from finding a good way to do SE, and I accept (with pleasure) the fact that one can choose from a variety of available programming languages. Graphical diagraming tools of the kind that made UML famous make me very nervous...

It should be noted that deciding to do late binding, and use testing in place of static type checking, is a SE decision, so it's bogus to blame ST-languages and their designers as if they are the only ones favouring a specific style of SE.

Research Style

It's worth keeping in ind that even though PL research is closely related to the goals of SE, the two fields are very different in their research styles and agendas.

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.

That's very interesting.

As some of my comments may have shown, I'm quite new to PL theory. Could you tell/give pointers to what these difference in style & agendas are?

Style & Agenda

Good PL research is usually more formal. PL theory is very much concerned with formal semantics, and this tends to imply that papers contain more "math" than SE papers that usually deal with less formal issues (e.g., "requirement elecitation" etc.)

A large subset of PL theory is done using non-mainstream programming languages, most often functional languages. Some of this research is applicable to other languages/paradigm but not always.

It's all my fault

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.

What about "tools".

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

Tools

The subtle interplay between IDE features and language features was discussed here many time in the past (I confess to having raised the subject quite a few times myself). You might want to check the software engineering department posts in the classic archive.