'imperative' is used as an opposition to 'declarative' (e.g PHP vs. XSL -- one could differentiate less formally / rigidly by calling it 'instructional' vs. 'implicative', although that, too has semantic issues).

Theo's explanation is of an axis describing the evolutionary and developmental hierarchy of computer languages over time - in essence as a measure of increasing abstraction from the hardware machine.

The first tier is machine code; the second tier contains languages such as assembly (essentially a textual abstraction of machine code); at the third tier (which contains C and COBOL), you start to see an abstraction from explicit machine instructions to the intended function of those instructions, so instead of saying {'put value 3 in register a'; 'put value 5 in register b'; 'send registers a and b to the ALU with an ADD instruction and put the returned result in register c'; 'copy register c to memory address #blah'} you tell it 'x = 3 + 5;'. 'Function' in this case refers to functionality not 'mathematical mapping operation' (although it essentially is that also). The third tier is generally referred to as the functional layer.

It does not mean functional in the lisp and Haskell sense, and it's only equivalent to 'procedural' in a much looser context (several higher-tier languages and indeed lower ones [e.g. assembly] are also procedural -- again, 'procedural' strictly belongs to another axis).

I assure you, though, that it is a valid nomenclature and is referred to in several CS textbooks; it just happens to be talking about something else. Hence, Theo is essentially correct: there is a large semantic confusion as to what is meant by a 'functional' language.

----
Done.
[ Parent ]

C is a procedural language; it's also an imperative language. According to the abstraction hierarchy thing mentioned above, it's also a 'functional' language. Note: I'm not claiming that 'functional language' doesn't now mean the mathematical-function-based languages as it's understood today. I'm just saying that there was once a time when it was also used in the context mentioned above, though this usage has lessened with the advent of 'functional programming'.

I'm wondering whether this is a UKie (possibly BCS-specific) thing. I'd also note that it's entirely possible not to come across it in the literature aimed at computer scientists and software developers generally -- it wasn't covered in our 'languages' course, for example, where functional programming was used as understood now. I only came across the usage Theo references during a more specialised final-year course on compiler development and language construction; i.e. it seems to have been used in discussions with developers of languages, and not developers using languages.

Anyway: I knew what Theo meant, even if its use that way is fairly archaic and rare now, and was just verifying that he wasn't completely off-his-bonce as the replies implied.

----
Done.
[ Parent ]

Look at his requirements. He wants deterministic timing. He wants complete control over all internal structures. To get that, you need either to program in a careful subset of C* or (and check your compiler output) or assembler AND run it on a seriously obsolete/designed for embedded processor. There is a reason that Linus won't accept C++ in the kernel (which really has more to do with memory, but this happens for identical reasons).

The author also whines about multi-threaded/multiprocessor CPUs (and presumably SMP boxen). The exact same issues with regard to timing happen once you add caches and MPUs, much less everything else needed to make a fast CPU. It's certainly harder to produce correct code on a multi-threaded program, but that doesn't mean that timing is ever going to be deterministic on a single threaded program. On a nec V20 I could tell you exactly how many processor cycles (baring metastability) it would take a certain program to execute, or to respond to an interrupt (and how many cycles the handler would take). Just try that with an athlonXP (or any other modern single core).

Finally, I'm not saying that the author wants to drop down to assembler. I'm saying he hasn't a clue what he's talking about and can't meet his own requirements. He's ranting the tradition troll about how everything in the world has to be custom designed for his wishes, wildly ignoring that he won't be bothered to use it if given to him.

Wumpus<CR> * note that this is C as a higher level assembler, not C as its own programming language. You have to be careful that you know the 1-to-1 relationship with the assembler to the C code. Those who want to use C as a programming language divorced from actual implementation (a mistake considering how C is defined) will find even C too high a level.

[ Parent ]

Is a very low language, practically assembly. No threading, etc., and yes, you can say for sure exactly how long things will take. It is also somewhat of a functional language, though not rigorously so as it was designed by pragmatic astronomers, not math theorists.
----
_{ウセーバラケダ}
[ Parent ]