Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re2: MOPT-01 - assumptions and spaces

by mstone (Deacon)
on Dec 11, 2002 at 01:03 UTC ( #218973=note: print w/replies, xml ) Need Help??

in reply to Re: MOPT-01 - assumptions and spaces
in thread MOPT-01 - assumptions and spaces

As you already stated, a computer does not think -- therefore (being pedantic), a computer programmer can't think like a computer. What a programmer can do is understand how a computer will most likely do a task, and fit the solution to that process.

A couple of people have called me on this one. I chose 'think like a computer' because it sounds better than 'has learned to simulate a computing machine mentally.'

There's no "most likely" about it, though. A human can work out exactly what a computer will do for a given sequence of input, and should do so frequently. Maybe it would be better to say, a programmer is a human who can build (and run) a virtual computer in their mind.

And I don't deny the need for creative human activities in programming at all.. mentally simulating a virtual computer is hard work. Imagine the physical effort of trying to move a welding torch in exactly the same path a robot would use.. no bumps, no jiggles, no wavering speeds. After half an hour of that, any human would want to go out and shoot hoops for a while.

Replies are listed 'Best First'.
Re: Re2: MOPT-01 - assumptions and spaces
by Jenda (Abbot) on Dec 12, 2002 at 13:43 UTC

    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.


      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.

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


        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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://218973]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (9)
As of 2018-06-25 09:01 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.