Re: A new paradigm
- From: "Bill H" <you@xxxxxxxxxxxxx>
- Date: Wed, 26 Jul 2006 08:39:42 -0700
Tony:
As I've said before, it seems the communication difficulties here are about
OOP being described in OOP language instead of in English (pun). :-)
Many of us in the MV environment are business people who know what we are
doing (businesswise) and use Pick to computerize that which we know in order
to improve/maintain profitability. We are business people!
To this end, many applications that have been written by people like me have
deficiencies to one degree or another. Reading the MV coding critiques in
CDP over the years has done much to improve our understanding, and use, of
IT concepts and improved the code we use and maintain on a daily basis.
When you speak about OOP, and use business examples we all understand, like
you have in previous entries in this thread (remember the Order
header/detail, Customer, Products, Terms example) the first thing you
usually get is: "you can do the same thing in Pick if you do .....". This
is not, IMHO of course, an impolite response but one grounded in a common
human language. Pick is very good in translating its concepts back and
forth into our human language of business and English (in my case). OOP is
not, as you can tell!
I've noticed that, as with any relational debate, when the debate gets a
little heated the description of OOP always reverts to the language of OOP;
interitance, encapsulation, objects (everything is), etc. :-) It is
generally difficult to describe concepts we're all familiar with in a
language that doesn't use the logical constructs of our experience. We all
know what an order is. We all know what it takes to generate an order and
what that order needs to update. What is difficult is to understand,
sometimes, is what OOP gives us that creates a better way to generate and
update an order than what has already been created. Being business people
we're always looking at the "bottom line" and can't quite figure this out,
so, hopefully, my ignorance will be forgiven. :-)
From my perspective, as an MV toolset user, there are a number of things I'dlike to see improved in the MV environment by either the MV vendors or
others. Believe it or not, I think what you've been saying and what Chandru
has been saying is very similar to me in the sense that you both would like
to see improvements within the "core" MV environment and would like easier
access to external IT resources.
I'm mostly interested in a more "logical" mapping of IT concepts and
structures to the business environment so "I" can build solutions. For me,
that's what MV has been all about. Moving to "n-tier" architecture using
OOP languages and 3rd party implementations of this, that, and a lot more,
requiring me to hire dbms administrators, UI developers, network
administrators, etc, just to get an application developed and running, is
not the direction I'm interested in. You've noted this and so have a number
of others. Those items most interesting to me, but certainly not to others,
has been the leveraging of the MV structure, dictionaries and BASIC, to more
easily accomplish some of the concepts of OOP (or "good practices"
generally) by someone like me, who knows the business I'm trying to run.
As I work with .NET, I notice it's very difficult to accomplish simple
tasks, as many business process are simple tasks. Basic things like I'd
like to keep a variable in scope are mind-boggling complex within the OOP
structure (the layers and layers of abstraction seem more designed for
obfuscation than for clarity). So, for me anyway, keeping most of the
business rules on the dbms server, within the dbms, is the simplest. Using
external routines like encryption and email available on the server, rather
than rewriting in BASIC, seems the simplest. Using the UI, and its
attendant toolsets, to interface with users seems the simplest. Using some
kind of "core" MV connectivity, to tie the UI with the business tier, seems
the simplest.
This thread has been facinating and I wouldn't classify it as tilting at
windmills nor as a bunch of MV people disagreeing. I'm included to view it
as healthy debate. :-)
Bill
"Tony Gravagno" <g6q3x9lu53001@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:ekmdc2lc5upcvfphot93f3o1md6k239cnb@xxxxxxxxxx
"murthi" wrote:
Mixed replies to several posts:
Oh, stop with your typical condescension!
I'm quite happy reinventing the wheel so it fits my use.
Condescention wasn't intended but I do think it's a shame that one
would be so adamant on creating something from scratch that already
exists.
"Eating with these damned chopsticks is so hard, I think I'll put a
scoop at the end of one of them."
"Err, that's a spoon, want one?"
"I don't care about your newfangled gizmos. Hand me some paper and
string." ...
I had hoped this would be a discussion about what OO could do for mv.
It is. I've proposed a couple ways it can be done using existing
tools, and suggested that there is no need to build something into MV
that doesn't belong in there in the first place.
<diplomatic mode temporarily switched off>
<maybe I need more (less?) coffee>
Let's get realistic. The only DBMS where this can happen is with
OpenQM and the project is already underway and being discussed
elsewhere. This rhetoric here in CDP is just idle chatter. Don't we
have more important things to do or areas of this market where we CAN
influence change, rather than wasting time on this topic as though it
will be of any benefit to a general MV community? An obvious response
to that is that I don't need to read a thread if I'm not interested.
I value comments by our colleagues, so I read them - people do me the
same courtesy. I just get frustrated when time is wasted in these
explorations into the impossible. We might as well be discussing
embedded MV in mobile devices or in-dash automobile computers.
<//>
Simon said (I resisted "says") more clearly: "I still believe that whilst
languages such as vb.net, c#, java etc can be used to develop in MV (and
perhaps should be used these days) that Data-Basic is the in-built
language
of the database and should be developed independently"-- I concur. If we
all
go
off and use non-mv tools, why bother with mv itself?
That wasn't suggested. I said (more or less) we should be using
existing tools in conjunction with the environment rather than
creating new tools with the only goal that they eventually equal what
already exists.
I'm sure non-mv tools
would be better suited to a non-mv environment,
I know you're not advocating building everything into MV, or that
external tools shouldn't be used with MV, but that's sure what it
looks like here. I think I understand your argument but these
comments just push it over the edge.
regardless of how many
mv-like features are inadvertently present.
I had suggested using mv.NET which is exists expressly for the purpose
of facilitating .NET/OO development for people who come from a
DataBASIC background - and to facilitate the introduction of DataBASIC
to people coming from the OO world. There's nothing "inadvertent"
about that.
otoh, I see Simon is wavering (in his latest post). Tony's got to you?
His comments are consistent - OO is generally good but an effort to
hardcode it into the MV model itself doesn't seem to be the best way
to derive the benefits. Do I need to "get" to someone for that sort
of statement to seem reasonable?
BTW Simon, u want yer 5 quid via mail or direct deposit? ;)
More fundamentally, nothing I said could be construed as being "this is
the
only OO types for mvBasic", or that OO objects are only synonymous with
files. It was just a start.
Understood - wasn't sure where you were going with it... Most
discussions tend to start _and_ stop with file definitions. For as
long as I can remember people talk about the idea of using dict items
in code, though dict items don't represent business objects. The
"FILE" statement in D3 allows for Custome<Name> Syntax but also
includes no concept of business objects. Forge, the Update Processor,
and other screen generation utilities all did/do the same.
If you don't like the objectification of files, no doubt
there's another way. However, since I suspect most of us here are quite
comfortable with "the confines of how data is physically stored on disk
(Simon)", it seems a natural extension.
To restate my point: I am not interested in the *general* definitions,
syntax, properties or behavior of Objects except insofar as they help me
and
others define and write programs in mv. And it seems that dealing with
files
and values is the fundamental action in mv applications.
This thread began with little more than the assertion that MV object
orientation would result in syntax like:
CUSTMER = NEW CUSTOMER()
CUSTOMER.READ etc
That's not enough to justify adding OO to MV. It's certainly not
enough to get OO developers to feel comfortable with MV as though
they're working in a familiar environment.
We can already do this:
EQU CUSTNAME to 1
CUSTOMER<CUSTNAME> = "Bob"
I don't see this syntax as being superior:
CUSTOMER.CUSTNAME = "Bob"
And we can already do this:
COMMON CUSTOMER
CALL CUSTOMER.UPDATE
So why do we need this syntax:
CUSTOMER.UPDATE
Or:
APP.UPDATE(CUSTOMER)
etc... ?
"Objectification" of a language is more than changing syntax to do
common functions. Let's assume that part is already done. The real
meat is in creating multiple instance/objects of a given class type,
execution of constructors to prefabricate common objects, allowing a
class definition to encapsulate rules so that we can take common rules
out of application code ... and there are SO many other things to
object orientation outside of syntax.
What I'm saying is that if you are going to take it that far, why not
use what already works well rather than theorize about the concepts
(and only some of them at that) as though this is the first time this
has been thought out?
As others have pointed out, mv is unique among databases by providing a
data
manipulation language and other utilities which work "inside the system".
Rather than ignoring or bemoaning this, I look upon it as one of its core
strengths. We have often mentioned the productivity advantage of mv. Part
of
its advantage lies in the tools (including the ability to edit data) which
enormously simplify development. Just because I would not want my users to
used ED does not mean that I should not use it. The simplicity of the data
structure and the intimate link to physical storage is again a plus. I can
use Search, Compare, Ed on data as well as programs while developing, and
it
makes life so much easier. Before Tony claims that every other environment
has the same features, better implemented, and more mainstream, I will
acknowledge I don't know if they do. But it does not matter if thet do,
and
does not invalidate what I said.
We're all here because we agree that the model is useful. Over time
the model has changed to make use of tools outside that
augment/supplement the code package. That doesn't mean we're giving
anything up, just admitting that there are other ways to accomplish
things. To wit:
- Pick used to be an operating system handling its own disk operations
and memory management. It's not a DBMS over existing OS platforms,
leaving the ultimate hardware interface to these other layers.
- While Coyote is a nice idea as a native web server it was never a
major success. Apache and IIS specialize in the tasks required of web
servers and developers tend to use these rather than Coyote.
- Most MV developers acknowledge at some level that they can send
e-mail directly from their MV envirnment, but prefer to shell out to
other common tools like sendmail and blat.
- For file transfer among environments we could write socket
interfaces for the various MV platforms, but the most commonly
accepted tools are outside of the box: FTP, Samba, AccuTerm FT, etc.
- People can use ED/AE/UP/vi and other tools for editing Pick items,
but a good number prefer to use external tools like wED which has a
Multiple Document Interface, colored syntax, etc.
- While some people have asked about encryption in MV, it's commonly
agreed that this should NOT be done in MV itself, but that we should
shell out to OpenSSH or other tools to use proper MD5 or other
standards.
This discussion of OO within MV is no different. I never advocate
replacement or giving up on MV, only errr, using the RT4tJ... figure
it out. :)
Simon further said "I would prefer to extend the dictionary to add to the
existing definition as well as compiling it to more easily processed
metadata" -- just so.Of course the Dict has to be extended; if it has
business rules incorporated, so much the better. If I see the one
advantage
of these OO extensions to mvBASIC, it's in the codification of data
management, not in the supposed magical improvement of the world of
programming. I like to think in small and manageable increments
It still sounds like you're talking exclusively about OO only in terms
of data management with Dict items and File IO. Relational databases
have referential integrity imposed by stored procedures and file time
triggers. That's what we get by putting code into Dict-like
constructs. This is completely unrelated to object orientation of the
language we use to manage our code logic - not just the data
management but logic flow in general.
I apologize if I've missed your point.
(Off the wall comment) This all sounds so argumentative and while it
seems like that's all I'm doing here I assure you I don't enjoy it
when it gets like that. Sometimes I think we fail to maintain
civility because people commonly mis-interpret lack of understanding
as violent disagreement...
About Simon's "At the moment, there isn't a great deal to differentiate
Chandru's advocation of using subroutines with the new QM OO because in
both
you need to *know* the names of the methods and properties by utilising
existing documentation. The Objects in OpenQM are not (asaik) self
descripting or usable in this way." --I'm not advocating subroutines per
se,
I just used that as an example of extending functionality (and also it
seemed to be the way to extend methods in QM OO). Besides, not sure I see
the point -- don't you need to "know" the names of the methods in order to
code them?
This is another advantage of using modern tools which assist with your
development by providing syntactical cues and even feature summaries
as you're typing your code. We could get this code completion for MV
and I believe there is some product that does this - outside of the
environment of course. As it's being discussed I see no difference
between MVOO development in ED and JavaScript development in Notepad.
This has nothing to do with the merits of OO itself, I think Simon was
just commenting that as long as we were using OO we might as well be
using an IDE for writing code that other OO developers use like :
Eclipse, Visual Studio, and a hundred others. Any OO developer who
tried to use ED for OO development would immediately feel like he
stepped back in time.
Higher level Business classes could then use these databinding and
datatype classes to expose higher level methods and objects.
And that's exactly the way it's done now. A method like Order.Write
would ask the higher level Order object to file it's data, the Order
object itself encapsulating a Customer, OrderHeader, OrderDetail, etc,
which in turn handle their part of the task.
What's the point in this?
Sorry but this is the way OO works.
Who sets up the 'write' method in a non-mv language?
You, the programmer.
Huh? I didn't say do the write in a non-mv language. I'm saying if
you're going to use MVOO then you should invoke MVOO class functions
on MVOO objects and not manually write objects to files. Objects are
generally responsible for their own behavior. If you don't code it
like that then you're writing procedural code around objects being
used simply as "thick" variables. In OO this is just another data
type, often referred to as a Struct which includes properties only and
no behaviors.
*I* certainly don't want to do it myself, I
want the language to have defined this (that's what a Pick Dict should
be).
If you have business rules attached to the write, then that's the only
thing
you'd have to add. This point is consistently ignored when touting non-mv
languages,.
What? We are SO disconnected here and once again I think this has to
do with your lack of understanding of the concepts being discussed.
Logic has nothing to do with the language being employed. The
language and its capabilities helps to determine where logic is
placed. If you're using procedural code then you branch to the logic
you need. If you're using object orientation then the logic is in the
class/object itself and you just tell the object to do whatever it is
that it needs to do. That's call encapsulation and that's the whole
point. When I'm writing application code I don't want to know how an
order is being written I just want to delegate the responsibility to
the component responsible and I expect the job to be done.
Coincidentally I might have written that code myself and I might be
intimately familiar with exactly what an order write operation does,
but at the moment I'm dealing a specific business function I don't
need to understand the mechanics of filing an order and related
records. This doesn't just apply to file write operations, it applies
to everything that one can do with or to an order. And this is at the
core of object oriented languages - it's not "consistently ignored".
Since you're advocating the use of object orientation it would help
for you to become familiar with these concepts. I happen to agree
object orientation is a good idea in general, and if applied properly,
for MV coding. My beef is with the linear thinking that's being
applied to this discussion of MVOO. It's like I don't object to the
idea of automobiles either, but 1) cars don't eat hay, and 2) get that
damned saddle off of there. LOL
For example, the notion of using Dict items as a base for class
objects is at the core of mv.NET and PDP.NET:
This is the sort of syntax for example that's already in place:
Customer = CustomerFile.Read("123")
Customer["FirstName"] = "Bob"
Customer.Write
or ... CustomerFile.Write(Customer,"123")
So what? Just because the *syntax* is in place means mv can use it
*easily*?
I guess I don't believe that a language created with no knowledge of mv
can
mesh so easily with it.
It took a lot of time for people to write the libraries for products
like PDP.NET, mv.NET, D3 Class Library, InterCall, and
UniObjects/UO.NET. Do you really believe this was done with no
knowledge of MV? Have you ever looked at the documentation for a
single one of these libraries? Do you have any idea what you're
arguing for or against here?
ATTENTION: Whomever it is who stole Chandru Murthi's PC and is
pretending to be him... When you are found you will be tortured as you
are now torturing us. Give Chandru his PC back and leave us alone.
I really don't give a rats arse about the language or topology but I
know some idiot is going to jump on the mention of .NET. >
I'll take on that role.
And I'm sure you don't know why you're arguing against .NET except
that it sounds like a politically correct thing to do... Chandru, I
know my limitations and I would be completely unarmed in a battle of
wits with you on the virtual assembler or the internals of this fine
system we love so dearly. Likewise, I'm getting a little tired of
arguing details of OOP with someone who has never used it. JavaScript
only provides a hint of object orientation. Find out what it is that
you're arguing about and we can try again sometime.
What we don't see too much of is recognition that fundamental coding
principles need to change when one starts objectifying ones code.
... No, each object is given just as much info as required and
the responsibility is delegated for them to accomplish their task.
I'm SO tired of this type of desperate example. If you're implying that a
single module does all of the above, yes, let's send the programmers to
hell. Don't you think anyone good would have modularized this?? And if so,
where's the change in the "fundamental coding principles"? Tony, * it's
agreed * that you can code badly in mvBasic. If you think one can *
automatically code better * in some OO language, fine, but let's move on.
We agree that poor coding habits are independent of language and not
related to use or lack thereof of object orientation. I was referring
to your original post to this thread which didn't say anything new but
re-iterated the use of Customer.Read and Customer.CUST_NAME syntax.
This is why I said we see a lot of this sort of thing but very little
about the deeper non-syntactical aspects of OO. Syntactical parsers
are easy and can change quickly, let's get beyond that. For anyone
who is really interested in object orientation in MV, we need to
discuss "the rest of it". Without good answers for the other OO
concepts this is just a lot of wasted keystrokes.
I guess I owe you dessert now for the aggravation...
T
.
- References:
- A new paradigm
- From: murthi
- Re: A new paradigm
- From: murthi
- A new paradigm
- Prev by Date: Re: Just getting Started
- Next by Date: Re: How to do a Pick/DataBASIC http server service?
- Previous by thread: Re: A new paradigm
- Next by thread: Re: A new paradigm
- Index(es):
Relevant Pages
|
Loading
