Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: MOPT-01 - assumptions and spaces

by talexb (Canon)
on Dec 10, 2002 at 15:52 UTC ( #218810=note: print w/ replies, xml ) Need Help??


in reply to MOPT-01 - assumptions and spaces

    • Programming is the art of thinking clearly, and
    • A computer programmer is a human who's learned to think like a computer.

I would argue your points a little differently .. in order to become proficient at programming, one needs to be able to think clearly. And a computer programmer is a human who has learned to understand how computer software operates.

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.

And programmers don't have the monopoloy on clear thought. You need to be able to think clearly for lots of other jobs too. :) I would argue that creative thought helps during the software development process. For the same reason that ad agencies have a basketball court to blow off steam and trigger the creative process, Silicon Valley companies have foosball tables to achieve the same goal -- work through the creative process and come up with a great solution.

I'm reminded of a PHB from a few jobs back -- he'd get really miffed if he saw me staring out the window, obviously deep in thought. He couldn't understand that thinking works best away from the keyboard. For some reason, upper management had decided someone with a Tourism degree from a community college was a great choice to run a software development project.

Go figure.

--t. alex
but my friends call me T.


Comment on Re: MOPT-01 - assumptions and spaces
Re2: MOPT-01 - assumptions and spaces
by mstone (Deacon) on Dec 11, 2002 at 01:03 UTC

    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.

      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.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (3)
As of 2014-10-01 01:37 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (386 votes), past polls