Re: Help Constructing Fictional Cross-Religious Movement

Wilson Heydt wrote: 
In article <430FC09A.10502@xxxxxxxxxxxxxxxxxx>,
Brooks Moses  <bmoses-nospam@xxxxxxxxxxxxxxxxxx> wrote:
That's one of the first big Important Things about objects -- it's like a typedef in the sense that you can declare lots and lots of them, but it also can have private variables within all those objects that only certain functions can access. 

If it's such an important discHtinction, why is it that I can clearly see
how to do the exact same thing in non-OO langauges that I've worked with
for over 30 years?

I see three reasons: (a) You know how to do something in Fortran that I don't know how to do despite being pretty familiar with it, (b) COBOL can do this where Fortran 95 can't, or (c) one of us isn't understanding the other about what the "exact same thing" is.

Given that this is something that I'd really like to know how to do in Fortran -- and, while Fortran 2003 has objects, there are as yet no Fortran 2003 compilers -- would you mind explaining how you'd do the following in COBOL or Fortran or something similar?

Consider the following subroutine, which defines what amounts to a "point" object of sorts:

  subroutine point
    real, save :: x, y
    real :: xin, yin, xout, yout, d

    entry setpoint(xin,yin)
      x = xin
      y = yin
    return

    entry getpoints(xout,yout)
      xout = x
      yout = y
    return

    entry getdistance(d)
      d = sqrt(x*x + y*y)
    return
  end subroutine

Now suppose that I'd like to have multiple points that are like this one, which have independent x and y values but have identical functions. Specifically, I'd like to have an array of points, and some other points that aren't in that array, and I'd like to be able to pass them as arguments to other subroutines. How would you do that?

[...]
My analogy here is that insisting that there is some mystical difference between
an object and a function or subroutine is the same sort of roadblock that insisting
there is some mystical difference between a row and a record. Sure, there are things
that are a whole lot easier to do to or with a database row than with a flatfile record, but those differences aren't fundamental to what they are. I do understand
the utilitarian differences between objects on the one hand and subroutines or functions on the other. Rather, it is the insistence that the naming convetion carries something important in and of itself that matters coupled with mischaracterisizing what can be done under the previous "labels" that is the problem.

I only agree with that partway, which is a good part of why I've been debating this. I think that the naming convention _does_ carry something important -- namely, it carrys a way of thinking about the program, and that way of thinking leads to things being trivial that might not otherwise be.

Now, I definitely agree that mischaracterizing what can be done under the previous labels is a problem, and I also agree that descriptions of objects tend to claim a lot of things as differences that really aren't, and tend also to describe things in object-specific jargon in ways that amount to completely begging the question.

That's why I found the O'Reilly book's author so refreshing when he came out and admitted that an object is just a function by another name and went on from there.

Any problems I have with Java aren't because I don't know what an object is. The problems I have with the language are probably do to general ossification of the brain that have come with age. Just as there are "9 and 60 ways of constructing
tribal lays, and every single one of them is *right*", there are a myriad of ways of writing books on Java and I have yet to find to one that meshes smoothly with
me so that I "get" the language. I may never find such a book, or one may turn
up tomorrow. Who knows?

Certainly not I. In my experience with learning C++, what worked for me was finding a programming problem that seemed reasonably amenable to object-oriented programming, and that I wanted to write starting from a blank slate. Specifically, something that I already wanted to do, for reasons other than learning programming. Once I had that, mostly what I needed was a book that had a good index and layed out the basic programming syntax thoroughly and concisely.

- Brooks


--
The "bmoses-nospam" address is valid; no unmunging needed.
.

Relevant Pages

  • Re: Help Constructing Fictional Cross-Religious Movement
    ... You know how to do something in Fortran that I ... >don't know how to do despite being pretty familiar with it, COBOL ... > subroutine point ... >was finding a programming problem that seemed reasonably amenable to ...
    (rec.arts.sf.composition)
  • Re: f95 OOP question
    ... and I managed to bring the intel compiler to its knees. ... until you understand Fortran 95 a little better. ... The term module means the same thing in Fortran 95 that it does in every other computer programming language. ...
    (comp.lang.fortran)
  • Re: exit and reenter a subroutine
    ... programming). ... that indicates what you want the subroutine to do. ... first call will initialize something and later calls will process it. ... You might also look at ENTRY, but it probably isn't the best solution. ...
    (comp.lang.fortran)
  • Re: Learning FORTRAN
    ... GNU Fortran, http://gcc.gnu.org/wiki/GFortranBinaries#Windows ... of FORTRAN preferably giving the text of its own compiler. ... How well do you know other programming languages or put differently: ... SUBROUTINE, don't assume that the other function is known to the ...
    (comp.lang.fortran)
  • Re: A petition to J3 apropos FORTRANs future
    ... >> web programming, GUI development, and text analysis. ... >> may partially explain the small market share of Fortran. ... almost NO new code would be written in the language. ... time on the types of codes that scientists and engineers want and need to ...
    (comp.lang.fortran)