Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

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.


Comment on Re2: MOPT-01 - assumptions and spaces
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.

    Jenda

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

        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://218973]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (9)
As of 2014-08-29 19:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (287 votes), past polls