When MV is not an option

#51

Hi Dawn
I do not mind what language a person write in so long as it is appropriate
to the job. I am pleased to see that Jim Idle agrees with my assessment of
C as unsuitable for day to day commercial coding whilst being excellent for
transportable deep system coding.
By free form I mean unplanned. If the total method of display, input
control, file control etc is not planned first and rigidly adhered to it is
bad code.
I have discovered over the years that people such as process control
engineers simply start coding their thoughts from line 1 and hope that it
works at the end.
In fact Mark's 6P statement is the ideal description.
My earlier remark which came from an NCR NEAT3 instructor - Write the user
instructions first - is still the most valid approach to programming I can
think of.
Well designed code doesn't need much maintenance.
Regards
Peter
"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote

Quote:

Peter McMurray wrote:
Hi
That is why one does not use free form code.

I'm not sure what that means, but from the next couple of paragraphs it
sounds like you mean that you should never write in a general purpose
programming language. By a general purpose language, I mean that it
can be used to program the computer to do whatever the computer can do
(or at least very close). Is that your position?

In my situation the command is only used within the context of the 4gl
in an
area that is not available for general use. Just as something like
JBASE
which uses C to jump around so the program above can safely use the
code, a
well written 4GL uses commands with care when they are needed.

If you go to lower level code you will find that things like IF
statements
are converted to GOTO statements.

In my opinion anyone not using standardised coding procedures when
producing
theirown packages is coding badly. Unfortunately when thrown in to
extend
existing unplanned code one has to be circumspect in ones use of
valuable
statements. In fact on a recent contract the first thing I did was
write a
standardised input routine. It was fascinating watching the testers
trying
to knock it over - all in good humour - simply because they had not met
reliable code before.

Good deal. I am definitely in favor of using well-written, well-tested
libraries.

A screw is not useless because some idiot drives it with a hammer.

I like it. There are a lot of people, including me, learning
JavaScript. JavaScript has a similar feature to DataBASIC -- you get
enough rope to hang yourself (as H. Eggers says). I once did a talk
where I used the phrase "the music is not in the piano."

In spite of all of the abstraction of code and the higher level
languages, given the distributed nature of software applications today
it seems that it is even more the case that we need professional
software developers writing code. JavaScript is about to have what
PICK had many years ago -- lots of non-software developers writing
code, driving in screws with hammers. In the case of PICK, subject
matter experts could write software where with JavaScript web
developers are learning to code. There are benefits to this, but you
also end up with some awful code.

One philosophy I have held that I am beginning to change is related to
mitigating the risk of changing poorly-written code. My previous
approach was to try to change a minimal amount of code, isolating
changes to a single subroutine (or function or class) when possible and
adding to software around the edges rather than delving in and
"refactoring."

Agile methodologies such as eXtreme Programming (XP) suggest writing
only what is required to fulfill the requirements for the current
iteration of software and then refactoring the software to incorporate
the next features, rather than planning for them in advance. While I
disagree to some extent and do think it is important to think past the
end of our noses when designing, we need to take more somewhat more
short-term risk when we maintain software in order to have maintainable
software for the long haul. If we refactor the code when we make a
change, rather than simply figuring out where we could stick some lines
of code into the current application, we will require more and better
testing but end up with better software that can be maintained
indefinitely.

--dawn

#52

"dawn" wrote:

Quote:

There are a lot of people, including me, learning
JavaScript. JavaScript has a similar feature to DataBASIC -- you get
enough rope to hang yourself (as H. Eggers says).

Dawn, have I missed some big industry news? It doesn't seem to me
that JavaScript is gaining or losing popularity at a rate any
different than over the last several years.

FWIW, and not that anyone here said otherwise, I'm just adding info:
JavaScript is not exclusively used for website development. It
happens that the DOM of web browsers is made accessible to this ECMA
standard language. It's up to the various browser developers to
properly expose their object model. They do this by extending the
language with new objects, methods, and properties. As we've seen
some browsers have different implementation than others, but that
doesn't mean JavaScript is different - I know for a fact that many
people think there are different JavaScript dialects or that one is
better than another, when in reality people confuse the API into given
products with the language itself. Some other products have similarly
chosen to expose their model in a manner that's accessible by VBScript
or similar BASIC variants - take AccuTerm's integration with SAX as an
example. Products other than browsers also expose their DOM via
JavaScript. These include Macromedia Dreamweaver, Adobe Atmosphere,
and technologies like VRML.

Coming back to my original question - this usage of JavaScript has
been around for quite a long time and I don't see any big industry
shifts lately as indicated throughout this thread. Did I miss
something? I think the only shift going on is that a lot of Pick
people are just now catching up with a 10 year old buzzword - wouldn't
be the first time that's happened.

Quote:

JavaScript is about to have what
PICK had many years ago -- lots of non-software developers writing
code, driving in screws with hammers.

Or perhaps there are professional carpenters out there who, never
having seen this particular screw before, make the informed decision
that it's OK to bash it with a hammer until they learn how to use a
screwdriver with it. Many car mechanics have a way of approaching
every vehicle like it's their old 4 cylinder Ford. I think
programmers have a tendency to do the same with new languages, as in
"I've been doing this for 30 years, there aint any new gizmo language
that I can't code in". Anyway, this is NOT about anyone here, I'm
just saying screw banging isn't exclusively the domain of novices.
Again I'm wondering what the "JavaScript is about to have" part means.

Quote:

Agile methodologies such as eXtreme Programming (XP) suggest writing
only what is required to fulfill the requirements for the current
iteration of software and then refactoring the software to incorporate
the next features, rather than planning for them in advance.

In line with this, note that Unit Testing is very big these days,
where the tests for the code are written before the code itself. Make
a change to the code and the tests should still pass. Does it take
more time and money? Sure, but as we've all seen, how much time and
money does it take to find bugs later? RD has some tests like this
for D3, but D3 is constantly breaking because there aren't enough of
them - tests are written to verify that a bug has been fixed, but not
to verify core functionality. That's an issue that management has
known about for years but the decision was made to not invest in this
type of QA.

Quote:

While I
disagree to some extent and do think it is important to think past the
end of our noses when designing, we need to take more somewhat more
short-term risk when we maintain software in order to have maintainable
software for the long haul. If we refactor the code when we make a
change, rather than simply figuring out where we could stick some lines
of code into the current application, we will require more and better
testing but end up with better software that can be maintained
indefinitely.

--dawn

And with the Unit Testing tools that are available today, it's much
easier to build refactoring tools because you know that the end result
is logic that's functionally equivalent to the original. In fact
Dawn, your point is validated by the fact that there are tools in
popular use and new ones being developed which themselves refactor
code. This concept of refactoring to avoid bugs might be new for some
Pickies, but witness the mainstream industry has already shifted to
incorporate it into standard development methodologies and is building
tools to facilitate the practice.

T

#53

Tony Gravagno wrote:

Quote:

"dawn" wrote:
There are a lot of people, including me, learning
JavaScript. JavaScript has a similar feature to DataBASIC -- you get
enough rope to hang yourself (as H. Eggers says).

Dawn, have I missed some big industry news? It doesn't seem to me
that JavaScript is gaining or losing popularity at a rate any
different than over the last several years.

Then, yes, you have missed a memo. Google for "AJAX JavaScript" to see
how many hits you get. AJAX was named in Feb 2005. JavaScript use has
gone up drastically since that time, enticing even hold-outs like me to
join the fray.

Quote:

FWIW, and not that anyone here said otherwise, I'm just adding info:
JavaScript is not exclusively used for website development. It
happens that the DOM of web browsers is made accessible to this ECMA
standard language. It's up to the various browser developers to
properly expose their object model. They do this by extending the
language with new objects, methods, and properties. As we've seen
some browsers have different implementation than others, but that
doesn't mean JavaScript is different - I know for a fact that many
people think there are different JavaScript dialects or that one is
better than another, when in reality people confuse the API into given
products with the language itself. Some other products have similarly
chosen to expose their model in a manner that's accessible by VBScript
or similar BASIC variants - take AccuTerm's integration with SAX as an
example. Products other than browsers also expose their DOM via
JavaScript. These include Macromedia Dreamweaver, Adobe Atmosphere,
and technologies like VRML.

Coming back to my original question - this usage of JavaScript has
been around for quite a long time and I don't see any big industry
shifts lately as indicated throughout this thread. Did I miss
something?

It sounds to me like you did. It is not a different usage, but more
use. The combination of various technologies and trends (and
indications of old browsers going out of use enough to ignore them)
with a marketing buzzword plus the use of this approach by Google, has
launched JavaScript into the spotlight. It was an also-ran,
use-when-you-have-to product until AJAX (or sometime last year when
Google and others picked up more steam with it).

Quote:

I think the only shift going on is that a lot of Pick
people are just now catching up with a 10 year old buzzword - wouldn't
be the first time that's happened.

Nope. That isn't it (this time).

Quote:

JavaScript is about to have what
PICK had many years ago -- lots of non-software developers writing
code, driving in screws with hammers.

Or perhaps there are professional carpenters out there who, never
having seen this particular screw before, make the informed decision
that it's OK to bash it with a hammer until they learn how to use a
screwdriver with it.

Stop looking over my shoulder, Tony ;-)

Quote:

Many car mechanics have a way of approaching
every vehicle like it's their old 4 cylinder Ford. I think
programmers have a tendency to do the same with new languages, as in
"I've been doing this for 30 years, there aint any new gizmo language
that I can't code in". Anyway, this is NOT about anyone here, I'm
just saying screw banging isn't exclusively the domain of novices.

Who would have thought such a sentence would arise from this
conversation?

Quote:

Again I'm wondering what the "JavaScript is about to have" part means.

Agile methodologies such as eXtreme Programming (XP) suggest writing
only what is required to fulfill the requirements for the current
iteration of software and then refactoring the software to incorporate
the next features, rather than planning for them in advance.

In line with this, note that Unit Testing is very big these days,
where the tests for the code are written before the code itself.

Yes, I tried to teach Java that way to a beginning group and backed
out, deciding it was too hard to teach intro programming that way. I
do like the approach, in theory, but I don't use it in practice. Maybe
someday.

Quote:

Make
a change to the code and the tests should still pass. Does it take
more time and money? Sure, but as we've all seen, how much time and
money does it take to find bugs later?

I do like having test harnesses, and it might be good to write the
tests in advance, but I haven't bought it that completely yet. I have
no doubt it is good, but I don't think it is essential for developing
quality software.

Quote:

RD has some tests like this
for D3, but D3 is constantly breaking because there aren't enough of
them - tests are written to verify that a bug has been fixed, but not
to verify core functionality. That's an issue that management has
known about for years but the decision was made to not invest in this
type of QA.

While I
disagree to some extent and do think it is important to think past the
end of our noses when designing, we need to take more somewhat more
short-term risk when we maintain software in order to have maintainable
software for the long haul. If we refactor the code when we make a
change, rather than simply figuring out where we could stick some lines
of code into the current application, we will require more and better
testing but end up with better software that can be maintained
indefinitely.

--dawn

And with the Unit Testing tools that are available today, it's much
easier to build refactoring tools because you know that the end result
is logic that's functionally equivalent to the original. In fact
Dawn, your point is validated by the fact that there are tools in
popular use and new ones being developed which themselves refactor
code. This concept of refactoring to avoid bugs might be new for some
Pickies, but witness the mainstream industry has already shifted to
incorporate it into standard development methodologies and is building
tools to facilitate the practice.

I had difficulty embracing this at first, but I have seen first hand
that this is worthwhile. If you keep your code clean with each change
(or make it cleaner), you are always making your changes and
enhancements to understandable code (in theory). The downside is that
you do end up injecting bugs where none existed before in code that
would not have had to change if you did it another way, so testing is
essential. I still have to make the business case in my head for it,
however. If you can just stick a little if statement here instead of
rewriting these three components, it seems like the smaller, less risky
but uglier change might sometimes be better but it is that kind of
thinking that makes spaghetti over time.

Cheers! --dawn

Quote:

T

#54

"dawn" wrote:

Quote:

I'm just saying screw banging isn't exclusively the
domain of novices.

Who would have thought such a sentence would arise from this
conversation?

ROFL, yeah, I guess that does look a little weird out of context.

Quote:

... If you keep your code clean with each change
(or make it cleaner), you are always making your changes and
enhancements to understandable code (in theory). The downside is that
you do end up injecting bugs where none existed before in code that
would not have had to change if you did it another way, so testing is
essential. I still have to make the business case in my head for it,
however. If you can just stick a little if statement here instead of
rewriting these three components, it seems like the smaller, less risky
but uglier change might sometimes be better but it is that kind of
thinking that makes spaghetti over time.

For reference, I've only had a couple clients pay me to re-write (now
buzzed as "refactor") some of their code as an investment toward fewer
bugs and faster fixes in the future. I recommended these changes and
am happy that I did so, but as a matter of principle I think we're on
the same page - if it works, don't uh, start banging that screw. LOL

The question I guess we need to ask ourselves is how many other
programmers came before us who decided to go for the one-liner rather
than re-working the code to a cleaner base-line. If there has been a
long line of other people fixing some piece of code, no wonder it's
spaghetti, maybe it's time to make an investment. This means we can't
stand on some principle, but once again, just try to make the right
decision for each specific situation.

T

"screw banging" - v.t. : the act of using an incorrect or unusual
choice of tools to accomplish a task. See also, "to MacGyver".

#55

Tony Gravagno wrote:

[snip]

Quote:

Unit Testing is very big these days,
where the tests for the code are written before the code itself. Make
a change to the code and the tests should still pass. Does it take
more time and money? Sure, but as we've all seen, how much time and
money does it take to find bugs later? RD has some tests like this
for D3, but D3 is constantly breaking because there aren't enough of
them - tests are written to verify that a bug has been fixed, but not
to verify core functionality. That's an issue that management has
known about for years but the decision was made to not invest in this
type of QA.

At the risk of sounding like a broken record... When I was at HHH one
of the guys in Technical Infrastructure (Steve Payton) had an excellent
test rig for running upgrades and patches to D3 through. He was often
able to pick up on little things the RD engineers hadn't and pass
things back rather than go live with them. I have no idea what happened
to all the old HHH software and data, and am no longer in contact with
Steve, but if you're reading this Steve - you might consider making RD
aware of your knowledge and expertise in this area. They will probably
remember how you were able to pick up on things - even if they just
recognised HHH and not you specifically.

Cheers
Mike.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

When MV is not an option

comp.databases.pick comp.databases.pick

Re: When MV is not an option - 11-29-2005 , 04:10 AM

Re: When MV is not an option - 11-29-2005 , 04:44 PM

Re: When MV is not an option - 11-29-2005 , 06:45 PM

Re: When MV is not an option - 11-30-2005 , 05:56 AM

Re: When MV is not an option - 11-30-2005 , 03:35 PM