> I think that the weakest part of that interview section is
> that neither of you mentioned real contracts (as in
> Eiffel). While I agree that the "contract enforcement"
> benefits of strong typing are generally overstated, the I
> suspect that the benefits of real Design by Contract
> support are substantially greater.

I actually asked Guido a lot about contracts, but in the "Contracts in Python" installment:

http://www.artima.com/intv/pycontract.html

> > So what is the argument against using a scripting
> language
> > to build a "system"?
>
> The weak-typer's view is that you can get as much
> robustness through testing, and that you get to start
> testing sooner.

This sound like a rather weak argument to me. It implies that robustness is achieved through the requirement for extra disipline by the programmer having to compensate for the weakness of the language. It also misses the fact that there is nothing stopping you putting an equal amount of testing into Java development as into Python development with the added benefit of not having to test types (so rigourously) in Java.

Vince.

This topic is almost two weeks old, but still...

So what is the argument against using a scripting language to build a "system"?

It might be instructional to take a look at the development of LPMuds here.

LPMuds are muds implemented in an interpreted C-dialect, called 'LPC'. LPC is runtime-typed and in the beginning contained no compiler type checks whatsoever.

However, as the muds, and especially the core game mechanics, grew in size (up to 300 concurrent users and hundreds MB of game code), LPC added more and more type checking to the language (it can be bypassed, though).

The reason for this, as I see it, is that with a large system you as a single programmer can't know any longer every aspect of the existing code. In a small system you can keep in mind that womble() calls frog() with is second argument which therefore must not be a float; but in large system the compiler is better suited to keep track of these details.

I find many programmers don't understand the relationship between their code and the systems their code rides. They overdo it, driving up costs and the time of delivery for the sake of bullet proofing.

The reality is the correct tool for the job not only encompasses the choice of language, but also the hardware and network environment the resultant application will reside. They must complement each other for the task at hand.

For example, lets say we have an internal application that at most 50 people will use in your organization. Response times are not critical (we are not building the space shuttle here). Now given that the worse case senario is 50 connections, and more likely an average of about 5 or 6 connections at any given point in time, what would be the correct solution? Many times this ends up being a java or C++ application running on a fully redundant mirrored environment (perhaps MC Service Guard environment on a high end HP). In reality, the application could be emplemented on a Sun Blade/Ultra single processor box with an automated backup routine using readily available Zope and Python. It would be implemented quicker, the users would be able to give more immediate feedback, changes would be trivial, and the developer would really serve the users what they need when they need it.

The problem is we think in terms of gold plating and bullet proofing our applications in various ways - at both ends of the spectrum. Not only do we use the most 'stable' and/or 'efficient' language implementation, we then further elimenate all possible exposure by over engineering the hardware solution. I think some of this stems from the overspecialization of programmers. I often question the motivations of anyone who refuses to learn new languages, and other aspects of system development outside of their area of expertise.

Every project is not the space shuttle - in fact, <i>most</i> are not. Outside of mission critical code (such as nuclear reactor code, or code that controls the space shuttle engines), imperfect working code in the hands of users now beats perfect code 14 months from now.

(To toot my own horn, I have built programs using the following languages: basic, fortran, C, C++, Java, Perl, Python, sed, awk, sh, csh, tcl/tk/expect, x86 assembler, sparc assembler, and lisp)

Quote from article:
"To me, attempting to use one language for every programming task is like attempting to use one tool for every carpentry task. You may really like screwdrivers, and your screwdriver may work great for a job like inserting screws into wood. But what if you're handed a nail? You could conceivably use the butt of the screwdriver's handle and pound that nail into the wood. The trouble is, a) you are likely to put an eye out, and b) you won't be as productive pounding in that nail with a screwdriver as you would with a hammer."

My reply :
I think ability to code plays a part in whether to use another language and or script instead of the language the developer is skilled with. Still learning another language can be of great value.

Here are some thoughts (abstact or not) towards this view and in practical terms. Please consider.

1): retention of language semantics and its usage.

An efficient programmer with one specific language should be able to do about anything whether strongly typed or not.

Why? There is an ease of use reference within the mind which the coder develops as the continue to use the language. Like lifting weights at first, your muscles find it difficult and you tire easily. Later ease of use and enhanced efficiency develop that you become more intense
with lifting heavier weights (if desired) and your speed in lifting improves as well. So why consider another language.?


2): Use a script language:

The coder could create his own simple script language for specific duties they might have in mind. If setting the languages real code to the text editor is difficult, I agree it may be at times especially when your at the top end of your performance threshold and it is the end of the day or the middle of the week. It is good to use another language as a distraction while the formulation of code references set up in the brain. Again , it may be just as well to create your own script.

3): Change attitude towards existing language the coder may be enriched by it.

How about applying a changed attitude towards the way you code when using the same language. Since the tasks your thinking about are less important and could be done with the language your using but at the time your language is too difficult to work with then enhance your skillset by starting to or create a library (if there is time) to objectify the specific tasks code.

Keep adding to your library of less importance. You then are creating a new level of expertise which will enrich the
flavour of your ability.

As well you may develop a more diversified perspective on how to code. Like a window refresh if you will of your own disposition. cleaner , crisper - leaner - meaner.

It is an intersting topic with many appropriate answers and I have wished to and have learned other languages too. I found in my specific instance (of being human) that selecting another language was because I was too tired to make the language I was seemingly skilled to work with work the way I wanted it too. It is interesting that I got over it.


Thanks for reading

David W. Stubbs