There's one thing missing in this. The "virtual computer" I'll make in my head for C, Pascal and even Perl will be totaly different than the one for Lisp, Scheme, ML or Haskel and that one will again be totaly different that the one for Prolog. And SQL basicaly adds another one.
Each type of programming languages is based on a different computational model so your simulation has to be different as well. And what we need to do when programming is not to simulate what does the "actual" computer do, but what does our computation model do.
What remains is the "thinking clearly", no matter what you use you have to consider all options, you have to know your border cases, you have to know exactly what /needs to happen|will be the result|must hold true/ in any circumstance.
Jenda
| [reply] |
Each type of programming languages is based on a different computational model so your simulation has to be different as well.
I understand what you're saying, but I disagree with your point.. rather strongly, in fact.
One of the key assumptions in programming theory is Church's Thesis, which basically says that any two systems that can solve the same problem are structurally identical. Turing machines are identical to Mu-recursive grammars, are identical to Post systems, are identical to Lambda calculus, is identical to C, is identical to Perl, is identical to Lisp, etc, etc, etc.
The real difference between our positions is one of level. You're looking at languages from a high-level perspective, where C, Perl, and Lisp look very different. I'm looking at languages from a low-level perspective, where an addressable block of storage is an addressable block of storage, whether I call it x[1], $x[1], car(cdr(x)), or x_values(1).
Yes, different languages 'Huffmann code' operations differently. What's easy in Perl may be laborious in C, and vice versa. But if you really know how your low-level virtual computer works, you can, to quote merlyn, "speak Perl with a Lisp."
Technically, different programming languages are nothing more than dialects of the same low-level language. Procedural programming, Functional programming, and Object-Oriented programming all share a common heritage, and in future meditations I'll show just how much alike they all are.
| [reply] |
I don't think the Church's Thesis says they are "structuraly identical". Even basicaly. It says they are identical in power. That's a totaly different thing!
Only the procedural computation model is based on "adressable blocks of storage", on mutable variables. In the functional model you do NOT assign values to variables only to change them later, there's actually no notion of "later" in that model. You define "variables" in the mathematical sense, you define the functions as relations between the parameters and the result, but there's NO MEMORY to address.
The reason why it's possible to "speak Perl with Lisp" is that Lisp is not purely functional. It allows you to leave the functional computation model! And then you can program the procedural way.
I am NOT speaking about the difference between individual languages. I'm talking about the difference between computation models! And even though Perl does have some functional features it's basicaly procedural. And therefore in the lower levels equivalent to C or Pascal.
Object Orientation doesn't actually fit into this discussion, it's just a syntactic sugar that alows you to tie the behaviour to the data more tightly, as far as the underlying model is concerned it's still procedural. Still based on "addressable memory blocks that are being modified by a sentence of statements".
Jenda
P.S.: I've been taught CS in Czech so if some of the terms look strange it's probably incorrect translation. Plus I did not have time to keep in touch with theoretical CS as I'd like to.
| [reply] |
