Re: Pointers to "why C behaves like that ?"

"Christian Bau" <christian.bau@freeserve.co.uk> wrote in message
> So a language that allows you to drop declarations lets you save five
> seconds because you don't have to type "long" or "int" or whatever in
> two places, and then it costs you three hours to find the bug.


A language that is strongly typed and has no explicit declaration
facility doesn't just let you save five seconds for not typing in
"long" vs. "int" declarations for simple variables (plus the 3 extra
hours for finding bugs because you either declared the wrong types, or
got so distracted from inessentials such as this that you mangled up
the task that counts: expressing the algorithm, itself); but also the
5 weeks of having to contrive entire files worth of class declarations
and modules to fit the method(s) you have in mind; or to work with the
various other facilities of the language whose only real function is
to compensate for the disadvantages of having the requirement for
explicit typing (namely: to compensate for the lack of true
polymorphism that arises from having no explicit typing in a strongly
typed language).


>+> It is much better if I can specify redundantly what the code is
>+> supposed to do; that makes it more self-documenting and it is more
>+> likely that the code doesn't compile if I make mistakes.


It's even better to just write the code and specifying what the indended
algorithm(s), synchronization(s), control(s) are BY the code. A
programming language is not 'code'. It's a notation for specifying
and defining processes. Using yet another language to specify
what the specification is specifying misses the point.


In a strongly typed language, the description of what a process does
always supersedes the description of what typing is consistent with what the
process does. So you never need to know what typing(s) are consistent
with it, because it's the process you're supposed to know in the first
place.


An array example was posed in another article. It the language has
sized arrays and you can't infer the size from the program, then the
language is not strongly typed. But it's already a given that you
always need explicit typing when the language is not strongly typed.
So, the example isn't saying anything.

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