Re: simple vs complex languages

Lex Spoon <>
5 Jun 2003 23:22:34 -0400

          From comp.compilers

Related articles
[35 earlier articles]
Re: simple vs complex languages (Jan C.=?iso-8859-1?Q?Vorbr=FCggen?=) (2003-06-05)
Re: simple vs complex languages (2003-06-05)
Re: simple vs complex languages (2003-06-05)
Re: simple vs complex languages (David Chase) (2003-06-05)
Re: simple vs complex languages (Yiorgos Adamopoulos) (2003-06-05)
Re: simple vs complex languages (Dave Thompson) (2003-06-05)
Re: simple vs complex languages (Lex Spoon) (2003-06-05)
Re: simple vs complex languages (2003-06-08)
Re: simple vs complex languages (2003-06-08)
Re: simple vs complex languages (Lex Spoon) (2003-06-20)
| List of all articles for this month |

From: Lex Spoon <>
Newsgroups: comp.compilers
Date: 5 Jun 2003 23:22:34 -0400
Organization: Georgia Institute of Technology
References: 03-05-198 03-06-006
Keywords: design, debug
Posted-Date: 05 Jun 2003 23:22:34 EDT

>>There are a fair number of languages around where a function doesn't
>>have to exist even when it is called, and a missing function will be
>>automatically converted into some other construction (e.g. a call to
>>an external program). This can be useful, as any shell programmer can
>>witness :-)
> And the user has to pray each time before running such a program,
> because nobody can tell him what it /will/ do. Such code can only give
> hints on what the program /should/ do... ;-)

The praying is an overstatement in general, even though it's surely
true for some tools. When you transition into more serious
development, you start testing, and any decent test will at least
execute every function call once. Thus, passing the test suite
guarantees that the functions exist as a matter of course.

I'm sorry if this sounds nitpicky, but I run into a lot of language
designers who say "X is not useful for production development" without
considering that production development involves testing.

To put it another way, you have to "pray" that your code is correct in
general, not just that all of the function calls are spelled right.
Not many programs have proofs of correctness, after all. You must have
some mechanism to check for hard things like off-by-one errors, and
that mechanism will easily nail function-doesn't-exist errors along
the way.

In principle, RAD tools and production development tools might be
different. However, given the current state of the practice, I see no
problem making a single language and toolset that is great for both.
The details matter, of course; some RAD tools really do tend to
produce unpredictable and untestable messes. That doesn't mean RAD
tools in general *have* to be bad for production. For example,
Smalltalk seems to strike a good balance. The particular case of
relaxing declaration-before-use causes no trouble for production


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.