Re: simple vs complex languages

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




Lex

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