[sclug] The C Lang is not machine readable

Roland Turner SCLUG raz.fpyht.bet.hx at raz.cx
Sun Jun 26 08:18:10 UTC 2005


Graham wrote:


>	The C language is not machine readable.


Well, it's readable in the sense that anything is machine readable.


>	Compilers and bin/make process the files, but they dont
>       _UNDERSTAND_ them.


Agreed, but I'm not convinced that machines currently do anything remotely
akin to "understanding". Lots of clever algebra produces tools that mimic
understanding, to a limited extent, but that's about all.


>	Re-factoring IDE's do (to some extent), but there is a missing
>       popularity for tools that can read programs, and understand them
as they are.


Well, no tools can understand programs. Some tools are designed to use
internal models of programs that are closer to the mental models used by
programmers than to the internal models used by the languages'
specifications (and the general purpose tools that implement them). Such 
tools are capable of operations that the more general tools are not 
(tool-assisted refactoring is a good example), but neccessarily suffer 
from more limited applicability; a tool which models in terms of a typical
programmer's mindset is not going to cope well with the complete
generality of the language and, as a result, will always trip up when 
exposed to code written to different conventions. Consequently, it is 
desirable and sensible for the compilers themselves to operate with the
complete language, but for tools to exist within IDEs that can operate  on
subsets of the language that are (far) easier for programmers to work 
with.


>	If we had a culture of machine readability, C++ would be slightly
>       different, and _USED_ significantly differently.


(chuckle)


This has of course already happened, you are describing Java's heritage.


The decision to remove the pre-processor solves most of the problems  that
you describe by arranging for the compiler's internal model and the 
programmer's mental model to coincide far more closely (closely enough
that Java bytecode can be decompiled to source, losing only local symbol
names). This certainly  made some things difficult from the outset (plenty
of reformed C programmers, myself included, frequently find themselves
hankering for a pre-processor to solve one problem or another), but has
fueled the development of well integrated in-language features
(assertions, generics, auto-boxing,  ...) that are performed as
information-destroying text-processing in C++.


>	In a culture of machine readability, it would be common practice
>       to have a
>	pre-loaded image of all the header.h files, and you would have
>       fine grained
>	dependencies, on FIELDS of classes, not entire header files. Then
>       a minor
>	change ina header file, that didnt change ony OFFSETS of anu
>       fields, would not recimpile the world.


Again, solving this kind of problem (compiled-code fragility with  respect
to referred changes) was part of Java's initial remit and was achieved
successfully a decade ago.


- Raz





More information about the Sclug mailing list