Language dependent design

I recently met this guy who insisted that programs must be designed with the language of implementation in mind, so that the design can fully utilise the benefits of each language.

I always design applications to be general enough so that it can be implemented using a variety of techniques ..

Whats your opinion ?

My two cents: probably a good strategy when possible, but it's not always possible or practical. For example, maybe you'd prefer an object-oriented design for your application, but the language you'll have to write it in just plain doesn't support OOP. You'd definitely want to know that before you designed the program.

Or, take functional vs. procedural programming. The two paradigms are different enough that your design would have to reflect it.

Ultimately, there's probably no harm in keeping the language in mind. It seems to me that taking into account the strengths and weakness of the language of implementation can only make your design more informed.
I think there are clear benefits to this (your design will probably be easier to understand and more intuitive if it is this general)...but at some point you have to choose your implementation.

I believe the choice of language can make a huge difference to the design choices you have available. For an extreme example, imagine trying to write the same application in an OO language such as Java, a functional language such as Lisp or Haskel, and logical language such as Prolog. The designs you would need for each language are radically different. Implementing a functional design in Java would be incredibly difficult, since the language has virtually zero support for it.

By trying to make a design general enough that it can be implemented in any language you are likely to end up designing for the lowest common denominator of language features, and missing out on elegant, simple solutions possible in specific languages.

Dave - The Developers' Coach

There are times when one is restricted in their choice of language-- the customer will only support and/or specifies one or two languages, for instance.

In these cases the programmer has no choice but to use what is available regardless of practicality, then it is a matter of usability and portability-- are you going to be able to accomplish what you want to do (and wht the customer wants to see) given the constraints in that language and is there a possiblity that the customer will want to shift this program over to another platform or language in the near future?

CHoice of language version can also present this constraint-- IEEE std 416 ATLAS has gone through some 32 iterations, each time changing the instruction set-- do you write the program based on the instruction set 416-1981 and run the risk that the code won't run on a 416-1976 machine or do you write it in the basic code common to both standards and ignore the added flexibility that the newer standard provides?

The customer generally knows better than the programmer does how the software is going to be used/misused/implemented, and the more you know what the customer rally wants the code to do for them, the better able you can meet their needs (and that's less time in development and maintenance of your code).

There was something my first boss always told me; Builders Get Blueprints, Programmers get crayon drawings.

I quote you on this one because of this: The customer generally knows (what they want, not how possible or feasible it is to developer). Often they have no idea how to implement it & have a fair idea on how it will be used, although that also adds to the abundant number of subsequent crayon drawings we get given.

As for designing a programme to a language, i don't think its important. Standardisation is about making a powerful idea which is platform-independant from its genesis. A strong, grounded & well thought out idea or concept can be adopted and developed in any language.

I agree, if no language is imposed on you, use a language that will run on any platform and is second nature to you. Personally, I use Raw C all the time anyway, unless Im told to use another language. Part of this comes down to me wanting ultra-performance applications, however.

Use what youre comfortable with so long as its x-platform.

I suppose it depends on the abstraction level on which your design language operates. Use UML and you're basically on the same level as the OO languages it supports. Historically in software engineering we have always aimed at increasing the level of abstraction on which we specify our solution. The most successful shifts were accompanied by the fact that the lower level language was automatically and fully generated from the higher level designs. This same success is pursued as well by Domain-Specific Modeling (DSM) languages. Have a look at the DSM Forum" for more information. In the case where the design language is on a truly higher abstraction level it is not dependent or constrained on the implementation language. Remarkable improvements in productivity can be achieved this way.

Martijn

This whole thread begs the question "What is the design?"

There is a common presupposition that a design must mean some sort of collection of diagrams that the code can be generated from, either manually or automatically.

An alternative view is that THE SOURCE CODE IS THE DESIGN - this has been eloquently argued in three articles by Jack Reeves. According to this view, the analogy with engineering/architectural design and construction is misplaced. In software it is all design, including the low-level coding. The construction part of the process is done automatically by the computer - often by clicking a button labelled 'Build' or typing 'make'. In this viewpoint, the source code is the equivalent to the detailed blueprints of engineers and architects. This does not preclude the use of higher level design artifacts just as architects and engineers may use various models, both real and virtual - but these are not the full design.

So according to this viewpoint the design must by definition be specific to the "implementation" language, since the design is written in that language.

Dave - The Developers' Coach

I understand. Still, how would you explain this statement when you look at a design in a 3GL language and its implementation in machine code? Is the design in 3GL specific to its implementation in machine code?

Martijn

Interesting question. I would say that in general the design is specific to the high level language, not the machine code. However there are times when optimising code that you need to be aware of the architecture you are running on, for example to minimise cache misses.

On the other hand you could make a case for the language itself being designed for the implementation on the machine. It is true that most languages can run on many different OSs and processors, but most machines these days are still based on the Von Neumann architecture, so are basically the same. The number of registers and the precise opcodes may change, but they all cover the same functionality. Changing to a new architecture, such as the parallel processing Transputer, gives rise a new type of language - Occam. If quantum computers ever become viable, they will probably be programmed in languages quite unlike any we have now.

It also goes the other way - there are machine architectures that are designed to run a specific language, such as the Lisp Machine.

Dave