Re: OO BASIC or "B++"?

#41

murthi wrote:

Quote:

Well, I might classify myself as such at the risk of being immodest. But
mainly I resent the attitude that if you don't get with the latest, you're
obsolete/ineffectual/screwing your client/etc.

Blimey, I am not saying any of those negative things. I have worked in
the Pick world for 20-odd years and have found the community to be
mostly very capable, caring, folks.

Quote:

I would venture to guess that
most on this list know enough about "new" technologies, not to say being
able to use thin/thick client PCs for their UI, etc. as to be *not* "old
time" (or old dogs, either)

This is the bit I am worried about. My experience has been that very
few people in Pick really do have deep familiarity with things outside
of Pick.

For example, lots of folks on here say that they have been doing Object
Orientation in Basic for many years, and that it is not a question of
technology but one of design. That is, in my opinion, a bizzare
statement founded on a great confusion about the specifics of what OO
involves. The main purpose of OO is to be able to develop a direct
representation of the domain model your application is supporting, so
that you can then write your application in terms of those
abstractions.

For example, being able to say that an order has an associated list of
line items, and that the total value of those line items is limited by
the credit rating of the customer. There is no where in BASIC to
express such constaints other than by scattering them throughout the
code. In an OO language you could create a concept called order, which
contains concepts called line items which themselves enforce that total
value rule.

I have met many folks who have taken a cursory glance at approaches
other than Pick and dismiss them as aying "I have been in this business
for many decades and we never needed those new fangled things".

If this is what you do, then you are missing out. Not all alternatives
to Pick are Snake Oil. Many are very worthy of investigation.

Certainly, I still use Pick extensively, but I also spend considerable
time giving alternatives a very deep investigation. Many of them I
reject, but many of them I also embrace. Mostly I am focused on getting
the job done, and I find that other tools help me do that more than
Pick does.

Quote:

What I would also venture is that many (show of
hand, please, if this is substantially untrue I will stop p***ing in the
wind) are totally comfortable with mvBasic to do the bulk of the business
rule implementation. The rest is just window-dressing.To use the phrase I
detest, mvBasic is the right tool for the task.

This makes me cringe. Pick BASIC can do the job - just - but being able
to do the job isn't enough. The rest is not window-dressing - I think
you are doing yourself and others a misservice by misrepresenting other
approaches that could provide considerable benefit to their daily work.

Quote:

And no amount of computer science jargon can
obviate the fact that complex systems degrade with time like buildings, and
occasionally you *do* need an expert to prop 'em up rather than your buddy's
teen-age hacker son.

I have been trying hard not to use Jargon - I apologise if I have been
using words that are mumbo-jumbo. Again, you are right that complex
systems degrade over time (as mentioned earlier, I spend four years on
my PhD pursuing just that thought). At the same time, there are many
good tools and techniques out there that you are dismissing unfairly
simply because they are not Pick.

#42

Anthony Lauder wrote:

Quote:

my overall estimate
is that typically 70% of the code in a Pick BASIC application is
doing work not related to the business requirements. Example include:
managing multi-valued lists

True, Pick BASIC is weak in this area, but with QM now supporing
rudimentary objects, one can create some nice container classes.

Quote:

reading and writing file items; checking
for error conditions; iterating through loops.

All of these are certainly found in abundance throughout systems
written in other languages. While Pick BASIC doesn't have error
trapping built into the language (try/except/catch/finally/raise, etc),
such language features are easily misused and can lead to obscure bugs.

Quote:

At the same time, however, there are still many many things that are
VERY difficult to achieve in BASIC

Here are some examples:

(1) Imagine we had two simple multivalued lists: One contains a list
of employee ids, and the other contains a list of salaries for those
employees. How will you sort the list of employee ids in the
numerically increasing order of their corresponding salaries?

This really isn't difficult is it? Your salaries list must contain an
associated employee id or there would be no way to do it.

IDList = "100]200]300"
SalaryList = "25000]34000]57000"

No matter what language you use, there is no way to associate one with
the other.

Something like the following is trivial to sort as desired in Pick BASIC

EmpList<1> = "100]200]300
EmpList<2> = "34000]25000]57000"

I agree that it would require some code and encapsulating it in a
container class would be nice.

EmpList->Salaries->Sort("AR")

Quote:

(2) How do you enforce a rule that you should not be able to delete a
customer record from the system if there are any outstanding orders
for that customer?

This is about referential integrity (RI) and not Pick BASIC. RI is not
well supported at the database level in any MV database. However, some
vendors support triggers, which can help in this area.

Regardless, RI is in the hands of the developer and not a DB
administrator that designs the schema. I agree that native RI in MV
systems, such as foreign key constraints and cascading actions would be
nice to have.

Quote:

(3) How do you say that a child's date of birth must be later than the
date of birth of its mother - and enforce that throughout the whole of
your application?

Again, this is a RI constraint issue, not a language issue.

Quote:

Instead, I am pushing back against all the folks on
here who claim that Pick is the greatest thing in the world, and that
everybody else needs to wake up and see how great Pick is.

I think that pushing back is good. I agree there have been
developments in other languages and databases that multivalue systems
could benefit from. I think the biggest of these would be RI at the
database level.

Not only would it eliminate a lot of hand coding, and improve the
quality of the data in a given system, but it would help to legitimize
multivalue systems amoung those who see this as a serious shortcoming.

--
Kevin Powick

#43

concrete examples to talk about rather than abstractions!.. embedded
comments..Chandru Murthi

"Anthony Lauder" <anthony.lauder (AT) gmail (DOT) com> wrote

Quote:

Lucian wrote:

I've programmed in FORTRAN, COBOL, a couple of assembly languages, C
and finally PICK BASIC.
For me, the most intelligible, easy to maintain and better language is
PICK BASIC.

The main advantage that Pick BASIC has over those other languages you
mention is that is is low on ceremony. It does not require you to focus
much on technical preamble, and allows you to mostly focus on the
business area your system will support.

However, there are many areas where Pick BASIC IS high on ceremony. One
glaring example is the fact that is have very simplisitc support for
collections of data. The technical intricacies of manipulating
multivalued (and subvalued) lists within BASIC lead to very convoluted
code.

Indeed, over the past 8 years I have been pretty much full time dealing
with numerous Pick legacy systems - and my overall estimate is that
typically 70% of the code in a Pick BASIC application is doing work not
related to the business requirements. Example include: managing
multi-valued lists; reading and writing file items; checking for error
conditions; iterating through loops.

You CAN do somethings about this, with very careful programming in
BASIC, and I have worked with many of my clients to tame their wild
code.

At the same time, however, there are still many many things that are
VERY difficult to achieve in BASIC since the underlying tools
themselves do not support many fundamental features.

Here are some examples:

(1) Imagine we had two simple multivalued lists: One contains a list of
employee ids, and the other contains a list of salaries for those
employees. How will you sort the list of employee ids in the
numerically increasing order of their corresponding salaries?

I suppose you mean that in an OO based language, you'd construct a
collection (pardon my imprecision) of the related multivalued fields, and
then use something like: EmpSalaryPlusOtherfields.sort(Empid), thereby
sorting all the related fields. Does this imply that the .sort method is
inherent in the language or that you have to "program" it yourself?

This is a very common scenario, and I'd typically write one subroutine that
does the sorting:
CALL SORTMVS(Record,ListOfAttributes,SortOnThisAttr)

Obviously not as elegant (or is it?) but in my mind, clearer. For one thing
you don't have to check the constructor for the fields to see what's
happening. For another, constructing the constructor itself is subject to
error. The CALL does have the disadvantage of having to feed it the list of
related mvs, which in itself would cause some to blanch since it's the
actual physical location instead of an abstraction. One could use Dict
words, I suppose.

However, in the web tool we use, the abstraction *is* there. On the (valid)
assumption that the form data contains all the related multivalued fields
(this is enforced via the Dictionary definitions), the Call would be
simplified :
CALL SORTMVS(SortOnThisField)

which works because in server side code, the form and its data are in
Common, and the field name in SortOnThisField can be found and its related
mv-ed fields resolved without further specification. If the Dict defs change
(say adding a mv field), the form is automatically updated and there need be
no changes to the server code.

Obviously, this a) requires more *developer* work up front (but it's a
one-time burden, and, of course,. in mvBasic, it's actually about 10 lines
of code) and b) requires the programmer to not futz off and do some
error-prone code herself.

Quote:

(2) How do you enforce a rule that you should not be able to delete a
customer record from the system if there are any outstanding orders for
that customer?

Triggers can enforce this on many mv systems. Isn't this RI? In an OO
language (going from your other post) the rule is embedded in the class? (I
understand that you can have such constraints in non-mv databases, but I
assume we're talking about an enhanced mv). I thought that violated some
other rule, but I guess I'm wrong.

Otoh, we try to enforce a rule in our tool that all file i/o must go through
a common subroutine:
CALL FILEIO(Filename, Record, Action, ReturnedError) something like that.
It is conceivable (and, now that you mention it, fairly easy) for this
routine to enforce integrity constraints. A homemade trigger if you will.

Quote:

(3) How do you say that a child's date of birth must be later than the
date of birth of its mother - and enforce that throughout the whole of
your application?

How about hiring non-brain-dead programmers?
More seriously, this seems to be a data entry validation issue (or RI on
other databases). If the validation is specified once and the application
building tool (everyone uses a tool, don't they?) uses a Dictionary, it is,
indeed, enforced throughout the app.
If, however, you want to protect against every discrete piece of code that
may add a few decades to the child's birthday, I have no answer except as to
2).

Quote:

These types of thing are very easy to express in English, but are very
hard to implement in BASIC. When you DO manage to implement them, they
require astonishing levels of discipline from the programmer - since it
is VERY easy to circumvent them.

What you consider "astonishing levels of discipline from the programmer" I
would consider "good intelligent programming".

Quote:

As I keep saying, I do like the simplicity of Pick and the "get on with
it" methodology that Pick folks tend to adopt. I am not advocating
high-ceremony solutions (like, say, C++ and Oracle in every case).
Instead, I am pushing back against all the folks on here who claim that
Pick is the greatest thing in the world, and that everybody else needs
to wake up and see how great Pick is.

I have said, and will continue to say, how great Pick is. However, I usually
qualify it with why I think it's great. There are many things that could be
improved. The sad thing about discussions like these is that there will most
probably never be a sea change in Pick/mvBasic/ etc to incorporate *some*
(we can disagree as to which *some*) new features. Perhaps QMBasic is a good
compromise?

It's often hard to explain what good design/programming *is*. But as someone
else mentioned in response to one your posts, it's good to see monikers to
hang principles on. I go on about computer scientists because they cannot
conceive of a world where you can train programmers/developers to write good
code and working, maintainable, applications without following their
guidelines. Designing and programming business apps is still a craft, not
quite a science ('course if you're programming a lunar landing there's a
slightly different skill set involved), and you need a lot of training to do
it well.

Quote:

Overall, the simplicity of Pick means you can learn it easily, and bash
out an application quickly. However, there really are other technical
solutions to some of the problems from which Pick suffers. I am not
advocating other technologies for the sake of their newness - but
rather because they will remove much of the intellectual burden that is
force on the programmer by the tools you are currently using.

I am telling you that you CAN have things that are as simple as Pick -
yet are far more expressive in terms of providing direct support for
the underlying business domain model.

#44

Each of these is very easy and just done once by the system
architect/senior programmer. All systems i work on, the developer never
directly reads and writes to a file, it is all done through standard
handlers (classes), developed by myself. any such validations, auditing
etc are placed in the central file handler so the programer just does
his file.open/read.write/delete/select and either catches an error or
gets a succes which he than has to handle. Again i think most pickes
these days approach things in a much more organised style like this, it
only takes a little imagination and a familiarity of oo techniques.

Anthony Lauder wrote:

Quote:

Here are some examples:

(1) Imagine we had two simple multivalued lists: One contains a list of
employee ids, and the other contains a list of salaries for those
employees. How will you sort the list of employee ids in the
numerically increasing order of their corresponding salaries?

(2) How do you enforce a rule that you should not be able to delete a
customer record from the system if there are any outstanding orders for
that customer?

(3) How do you say that a child's date of birth must be later than the
date of birth of its mother - and enforce that throughout the whole of
your application?

#45

Kevin Powick wrote:

Quote:

(3) How do you say that a child's date of birth must be later than
the date of birth of its mother - and enforce that throughout the
whole of your application?

Again, this is a RI constraint issue, not a language issue.

Bad form replying to my own post, but my response wasn't really
correct. It's not really a database level RI issue.

To enforce that type of constraint in Pick BASIC would require some
type of filing routine, where such rules could be validated. Of
course, one would have to use such a routine, but then again, in an
object-based language, one would have to use the object to ensure the
constraint was checked. It could still easily be bypassed by an
application developer.

Nothing is foolproof.

--
Kevin Powick

#46

Symeon wrote:

Quote:

Each of these is very easy and just done once by the system
architect/senior programmer. All systems i work on, the developer never
directly reads and writes to a file, it is all done through standard
handlers (classes), developed by myself. any such validations, auditing
etc are placed in the central file handler so the programer just does
his file.open/read.write/delete/select and either catches an error or
gets a succes which he than has to handle. Again i think most pickes
these days approach things in a much more organised style like this, it
only takes a little imagination and a familiarity of oo techniques.

This is wonderful. You sound like a very disciplined developer. Some
things still confuse me. Let's look at a simple example:

We are writing a booking system for a hotel. A new customer must either
give a credit card number or a pre-approved billing address or pay in
cash when checking in. A repeat customer may say "same payment method
as usual" or may on an ad-hoc basis pay with cash or credit card.

There is a lot going on in this simple example: the user interface
needs to reflect the need for various prompts and so on to be present,
and apply some validation rules to them; the persistence mechanism
needs to reflect lots of rules too and maintain relationships between
things; and finally there is probably some bit inbetween that does some
business-oriented calculations.

In technical terms, all the rules and relationships are grounded in
something called the Domain Model, which is a reflection of the
real-world area being supported. Writing subroutines for, say,
persistence is an implict and scattered reflection of this Domain
Model.

A lot of non-Pick folks focus on developing a central Domain Model off
which everything else hangs. So, there is a core part of the system
saying everything necessary about the business domain, including the
relationships between the concepts (customer, billing address, credit
card number, booking history, and so on), their constraints (validation
rules) and the impacts of various events on them (e.g. if I pay in
cash, no bill is sent to my billing address).

If we scatter this knowledge into lots of disparate subroutines (some
for the UI, some for persistence, some for "processing" and so on, then
we have (1) No good way of enforcing the constraints, etc, other than
pure programmer discipline, and (2) it becomes much more difficult to
build an explicit mental model of what only has an implicit
implementation.

One of the big shifts in non-Pick that I have seen is a much greater
emphasis on an explicit Domain Model - and this is very hard to achieve
with deliberate technological support.

So, I applaud you on the discipline you employ, and point out that you
could take things even further with better tool support by having a
core Domain Model shared by very thing UI, Processing, and Persistence
layers around it.

#47

Quote:

Tony Gravagno wrote:
Even I'm beyond words. The fact that you believe what you're saying
is a testimony to why this market is the way it is.

"SteveB" wrote:
Hiya. Who/what were you replying to?

TG wrote:
Chandru wrote the following snippets. Way too much to comment on.
Don't get me wrong, I like and respect Chandru, but it's this very
mindset that has caused the Pick model to fade into obscurity among
the people toward whom he thumbs his nose.
T
================================

I'm absolute baffled, Tony. Comments & questions for you below.

Quote:

No wonder I don't like, don't fully understand and don't need OO!
In the time it would take me to decipher the above paragraph, I
could have created a new application...
One wonders--perhaps simplicity IS a virtue? Perhaps all this
gobblygook about OO, is the conventional wisdom that has to be paid
obeisance to? Perhaps the Emperor's clothes lie therein?

Have you read any of the OO threads over in cdt?
Do you think OO is the answer? Or the problem?

Quote:

They used to say "don't argue with success". Pick, by any standards was a
howling success when un-computer-science-schooled programmers did not know
any better than to develop applications. It's current state of decline is,
as most of us would concur, just a marketing phenomenon, and is
exacerbated
by our community's general inability to refute these overblown claims of
weakness. We just don't speak the language.

Do you agree that Pick was successful circa 30 years ago?
Do you agree that it is in decline now?
Do you agree that this turnaround was mainly marketing related, not
technical?

Quote:

If you read the academic journals on many disciplines, you will note that
they get steadily narrower, more jargon-filled, and more concerned with
esoterica. Geography comes to mind. You thought Geography was concerned
with
physical boundaries and features? No more. I feel the same way whenever I
read anything touted as the latest computer science technology. Acronyms
out
the gazoo, jargon that obscures the issues, claims of superiority that
cannot be verified in the real world, dismissal of anything that does not
conform to the received wisdom, etc..

Have you noticed that IT has become the jargon center of the world?

Quote:

I can see why I'm not super rich. Obviously I
should've been using all these nifty tools so that I could take 10 times
longer and charge my clients accordingly. Now there's a business model
worth
an advanced degree!

Do you know satire when you see it? =`;^>

I would be amazed to hear anybody who has been in the Pick world for any
length of time dispute any of Chandru's assertions. And when I hear you
say "The fact that you believe what you're saying..." it appears to me
that you do not believe them. Maybe I misconstrue your comments? Maybe
you agree with his premises, but use them to reach a different conclusion?

--
frosty

#48

"Anthony Lauder" <anthony.lauder (AT) gmail (DOT) com> wrote

Quote:

The main purpose of OO is to be able to develop a direct
representation of the domain model your application is supporting, so
that you can then write your application in terms of those
abstractions.

For example, being able to say that an order has an associated list of
line items, and that the total value of those line items is limited by
the credit rating of the customer. There is no where in BASIC to
express such constaints other than by scattering them throughout the
code. In an OO language you could create a concept called order, which
contains concepts called line items which themselves enforce that total
value rule.

Could you post the actual syntax of this with the enforcement?

Chandru

Quote:

What I would also venture is that many (show of
hand, please, if this is substantially untrue I will stop p***ing in the
wind) are totally comfortable with mvBasic to do the bulk of the business
rule implementation. The rest is just window-dressing.To use the phrase I
detest, mvBasic is the right tool for the task.

This makes me cringe. Pick BASIC can do the job - just - but being able
to do the job isn't enough. The rest is not window-dressing - I think
you are doing yourself and others a misservice by misrepresenting other
approaches that could provide considerable benefit to their daily work.

But just as a simplistic example, if, like me, you believe typing variables
is unnecessary (let's not argue about that, it's just an example), just
having to declare variables is "window dressing" --- *to me*. I'm not doing
a disservice to the dedicated folk who believe in typed variables, it's just
my opinion. One of the reasons I like javascript is that you can declare
variables locally or globally in a simple way, but you don't have to. Best
of both worlds.

#49

"murthi" <c_xyz_murthi (AT) seeing_xyz_green (DOT) net> wrote

Quote:

"Anthony Lauder" <anthony.lauder (AT) gmail (DOT) com> wrote in message
news:1151676988.785519.207910 (AT) p79g2000cwp (DOT) googlegroups.com...

The main purpose of OO is to be able to develop a direct
representation of the domain model your application is supporting, so
that you can then write your application in terms of those
abstractions.

For example, being able to say that an order has an associated list of
line items, and that the total value of those line items is limited by
the credit rating of the customer. There is no where in BASIC to
express such constaints other than by scattering them throughout the
code. In an OO language you could create a concept called order, which
contains concepts called line items which themselves enforce that total
value rule.

Funny! I have been doing that for 30 years without having the rules

scattered throughout the code. I actually have standards that I use for
Pricing, Orders, Invoicing etc. As I believe any competent developer has.
It is possible to have a 1000 programs in a suite with one universal pricing
routine that is called by everything needing a price just as we have a
universal edit routine. I think you are tied up in syntax rather than
object design I suggest that you have a look at Grigory's response. Now here
is a man with full knowledge of every side of the argument.
Peter McMurray

#50

Of course. It's called splitting the UI from the middle tier from the
business rules. Wait! This is the latest management technique for new
technology. :-)

Bill

"SteveB" <steve.bush (AT) neosys (DOT) com> wrote

Quote:

Bill H wrote:
Quality control is much more difficult too because we, who know what the
software is supposed to do, can't test the software to do it and the
programmers, who know how the software is put together, can't test what
it
is supposed to do.

This is no nirvana, but a much more difficult, and convoluted, way to
exist.

Sounds like a nightmare of mismanagement allowing such a split to
arise, not an argument against using industry standard tools as such.
Shipping in different expertise without ensuring it gells with the
current brains is asking for trouble.

Cheers,
Steve