OT: Programming Language .... Ping Reg
Gary
programming language you are using to create the DOS programs ? I've
programmed in basic years ago and also Pascal and assembler. I'd like
to do some programming for some simple projects of my own but don't
need or want anything like a 400 page book(s) for Visual C++ etc.
Thanks in Advance.
73 Gary K8IQ
W9DMK
wrote:
Boy, are you in luck?
Pascal is the magic word!
Bob, W9DMK, Dahlgren, VA
Replace "nobody" with my callsign for e-mail
http://www.qsl.net/w9dmk
http://zaffora/f2o.org/W9DMK/W9dmk.html
K7MEM
If you want to use a language that is portable to any computer,
gives you GUI capability, and requires a minimum of tools, learn
HTML, CSS and Javascript. If you can program in basic and pascal,
then Javascript should be no problem. There are a million tutorials
on the internet that tell you how to use them together. You can design
your own graphic front end in HTML and talk to it with Javascript.
The most basic of tools required is a web browser and a text editor.
That's how I write all my web pages. If you want something better,
there are lots of free development tools and page templates. If you
only want your programs to be local, that's OK. There is no requirement
to put it on the net, but if you do want to put it on the net, it's ready.
--
Martin E. Meserve - K7MEM
http://www.k7mem.com
(remove _nospam_ from my email to reply)
Reg Edwards
Hello Gary,
All my programs are written in Pascal. I use Borland's Turbo Pascal-6
compiler but I think all versions of Pascal, for practical purposes,
are interchangeable.
I like Pascal because it is disciplined. It obliges the programmer to
produce logical, straightforward, understandable programs. For example
there are no GOTO statements as in Basic. There are few clever but
ambiguous code-constructs which allow alternative ways of performing
the same operations. It is difficult to misuse or pervert the language
to take advantage of fortuitous circumstances in program structure.
The programmer is not tempted to break the rules.
The DOS/Pascal/Windows combination allows programs to be produced as
short, single, self-contained, executable binary files. They are also
machine independent. All of which is convenient for both programmer
and user.
There are disadvantages. It would be nice to have graphics and to be
able to dump the screen to a printer with one hit of a function key.
But I think such facilities would make programs machine dependent
through their screen and printer driver software. I could be wrong.
----
Reg, G4FGQ.
John Smith
You guys are in luck, there is an EXCELLENT FREE pascal compiler/IDE--it
mimics borland (most powerful pascal developed)--only is up-to-date and
runs on XP and server 2003...
http://www.freepascal.org/down-i386-win32-usa.html
It compiles all borland code with very few changes to the original
source code (mostly compiler directives is all which needs to be
changed), standard pascal it should have no problem with...
Warmest regards,
John
"Gary" <grynwbry@@@@Yahoo.com> wrote in message
news:1hrl91lh6f251i79u...@4ax.com...
John Smith
Since we seem to be picking up a pascal programmer or two-I might as
well toss this out and see if anyone is interested:
R. Nelson-WB0IKN, apparently, contributed/wrote an article back in
January 1985 issue of "Ham Radio."
Anyway, I ended up with some source code of his to compute a gamma match
for a monopole/dipole-it is written in basic, and runs in "GWBasic" (you
can get a copy of GWBasic off the net if you wish to run his original
source-or use a method of your own.) I have the source at:
http://blake.prohosting.com/mailguy2/gammabasic.txt
I did a bit of work in translating his source to pascal, and it is in
two files there:
http://blake.prohosting.com/mailguy2/gg.txt {a pascal .tpu unit to be
used by the main program }
and:
http://blake.prohosting.com/mailguy2/gamma.txt {the main program}
. this source is mainly a debugging shell to get his
formulas/calculations converted to pascal's method of handling math.
. the source compiles and runs. and seems to end up with the same
values as his source. the code is FAR from finished and is a starting
point. but can be used quite effectively to test the concept.
. there is an error if "driven element diameter = gamma rod diameter =
gamma rod spacing".. It is a divde by zero error. since a square root of
a variable is attempted and of course NOT allow and generates the error.
his original code does NOT suffer this error-because of a "buggy error"
in gwbasic-it allows the square root of zero, apparently!!!! (he
started working with imaginary numbers it seems!)
. anyway, those interested can take a look at the source and see if it
is of any interest to them-be great if someone would get it into good
working shape and have Reg put it up to share with all interested.. I
just have about a dozen other things on my plate right now and can't get
to it immediately-and would rather translate to "C" anyway.
. it would be interesting if anyone has any good info on design of gamma
matches and could share that with me-I'd like to study the formulas and
hear descriptions of the calculations-as here I have only translated
them-if anyone has such, please let me know. R. Nelson, or course,
should be given credit for having provoked these manipulations of his
original code.
. my debug code only considers the monopole, the dipole option would
need to be added, but is a simple calculation or two which can be seen
in his original basic code.
. if I can help with any others efforts, in any way, just let me know.
Warmest regards,
John
"Gary" <grynwbry@@@@Yahoo.com> wrote in message
news:1hrl91lh6f251i79u...@4ax.com...
John Smith
There ARE goto statements in borland pascal (don't kill the messenger of
bad news--as is done here so often)... you can, just, not "goto"
outside of a procedure or function or outside the main code (your goto
must remain local to the code block it is instituted in)... I can supply
you with a quick piece of example code if you wish me to....
Warmest regards,
John
"Reg Edwards" <g4fgq...@ZZZbtinternet.com> wrote in message
news:d7fbc4$kmt$1...@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...
Cecil Moore
> I like Pascal because it is disciplined.
It apparently doesn't allow the English system of units. :-)
--
73, Cecil http://www.qsl.net/w5dxp
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
Hal Rosser
"John Smith" <assembl...@gmail.com> wrote in message
news:pqIme.49$mj3.2...@news.sisna.com...
interesting.
what's the diff if
source was in Pascal, C, C++, VB, GWBasic or whatever.
A miniscule difference in execution time at best.
Today's computers are fast. - (faster than most slide-rules).
Some of us script-kiddies would translate it for the fun of it.
John Smith
I don't even know where to start with that question--however, since
GWBasic worked as a "basic interpreter"--the speed difference between
that code and pascal could be compared to a baby crawling and the speed
of light!
However, here that is almost a moot point--speed is not important and
the code is simplistic... and not demanding of processor cycles of
execution...
The reason to translate it to pascal or "C" is so it could be included
into a larger antenna program--an example, not "C" of course, but
fortran for example--would allow it to be included into a program such
as EZNEC....
My gawd man, the possibilities are as limited as ones mind!!! ... well,
in some cases---that is rather limited, isn't it? Course, none of those
guys here... <grin>
Warmest regards,
John
"Hal Rosser" <hmro...@bellsouth.net> wrote in message
news:OmMme.46762$J25....@bignews6.bellsouth.net...
Reg Edwards
>
> There ARE goto statements in borland pascal (don't kill the
messenger of
> bad news--as is done here so often)... you can, just, not "goto"
> outside of a procedure or function or outside the main code (your
goto
> must remain local to the code block it is instituted in)... I can
supply
> you with a quick piece of example code if you wish me to....
>
Yes, I'm sure you could descecrate the language for no useful purpose
if you wished.
The fact is there is no GOTO statement in Pascal. It is not needed.
Only somebody with suicidal tendencies would deliberately convert a
straightforward, logical, easily maintained, understandable program
into a bowl of spaghetti. Every artificially concocted GOTO
statement, another complicated part procedure, is a self-inflicted
wound. Furthermore, it selfishly inflicts wounds on future maintenance
operations. It is a symptom of lazyness and lack of intelligence on
the part of the so-called programmer. One who is unfit to collect his
wages.
If you want to be useful, write an internal, self-contained procedure
in Pascal which will dump the screen to the printer on a single hit of
a function key. Just like it is in DOS. No prizes offered.
----
Regards, Reg, G4FGQ
John Smith
I am just pissed they sell booze in fifth's here (liters would be little
better), fifth of a gallon is a silly thing--don't ya think--just round
it off to a whole gallon and call it square is my idea of it...
<drunken-grin>
Warmest regards,
John
"Cecil Moore" <w5...@hotmail.com> wrote in message
news:429b81b5$1...@spool9-west.superfeed.net...
Joe
is Cobol available for XP Pro, and if so where can I get it at?
Thanks
"Cecil Moore" <w5...@hotmail.com> wrote in message
news:429b81b5$1...@spool9-west.superfeed.net...
John Smith
<sound-of-running-footsteps-down-a-long-hall>
Warmest regards,
John
"Joe" <j...@telnet.com> wrote in message
news:cANme.21616$g66.12512@attbi_s71...
John Smith
Well, darn man, you are NOT even going to ask for an example--so that I
may attempt to pollute the minds of organized pascal programmers with
the goto statement--but, I, at last, cannot resist, so powerful is my
addiction to the DREADED goto, that I must have my fix--I am no better
with the goto than an addict with heroine!!! <grin>
{ CODE FOLLOWS }
program a;
uses crt;
LABEL here;
BEGIN
here:
writeln('goto....');
delay(500);
goto here;
end.
Warmest regards,
John
"Reg Edwards" <g4fgq...@ZZZbtinternet.com> wrote in message
news:d7g88t$qn0$1...@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com...
John Smith
That nice looking, immaculate code you write, which flows with elegant
logic, purpose and beauty... when the compiler gets it, changes it and
spit a "whole bunch" of "gotos" in it... in assembly (which is what the
compiler finally deals with) there are gobs of "direct jumps" using the
assembly "JMP $????" instruction which transfers program execution
DIRECTLY and IMMEDIATELY to code beginning at the address given ($????)
(THIS is the DREADED goto--but really, it doesn't bite if ya know how to
use it <grin>)....
... moot point however, as on the level of high level language a
programmer can hide from this... HOWEVER, pascal, in the end, ends up
just like 'em all, a binary program with gotos!... <frown>
Indeed, you could not execute code with out the binary goto--the first
happens when any program executes... as a direct jump must be made to
the binary program code which has been loaded into memory, and now must
be JUMPED to, to execute....
But even worse, it is as I claimed Reg, look on the net using the search
terms "goto statement" and pascal (use the double quotes too)... it IS
part of the pascal language and can be used as I stated above...
However, let us move on friend, this is a silly argument at best, and
credulous to spend any time at all debating--however, a programmer
should know about it...
...and I support the NON-USE of goto in programs... <grin> goto is a
sticky thing, later on you can trace bugs in code for days... and
resolve that bug down to a goto!
You advise well, when you advise to avoid the DREADED GOTO!!!!
<nod-and-a-wink>
Very warmest regards,
John
"Reg Edwards" <g4fgq...@ZZZbtinternet.com> wrote in message
news:d7g88t$qn0$1...@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com...
Fred W4JLE
"Joe" <j...@telnet.com> wrote in message
news:cANme.21616$g66.12512@attbi_s71...
Gary
Thanks Reg, I had forgotten about Borland's Turbo Pascal. That's what
I used in a Pascal class back in the mid 80's. You're right about it
being pretty well structured, I remember the days of trying to
decipher some TRS-80 Model 1 basic and maybe the second or third line
would read goto 10000 <grin>
Thanks again.
73 Gary K8IQ
Gary
Thanks for the links and all the information John. Maybe I should try
a registry cleaner for my first project and have my fellow hamsters
here inform me of any problems <big grin> ;^)
Thanks again !
73 Gary K8IQ
John Smith
the type a registry cleaner would be needed to protect against... it is
strange, I hear your words sounding as threatening as a script kiddie!
<grin>
Problems are to be expected--indeed, it is the challenge some live
for... you live--you learn--BRING IT ON!
<maniacal-egotistical-competitive-evil-smile>
Warmest regards,
John
"Gary" <grynwbry@@@@Yahoo.com> wrote in message
news:6cmn91tinfg75dveb...@4ax.com...
John Smith
much over 200 pages)... sometimes even they are not enough...
Warmest regards,
John
"Gary" <grynwbry@@@@Yahoo.com> wrote in message
news:1hrl91lh6f251i79u...@4ax.com...
Gary
Well I've found that even with the 400 page manuals there's always a
question I have that's not covered. :( .... My favorite programming
experience was assembler on a 8 bit 6502. That was about as easy as
programming in basic. I can't imagine what programming a modern
processor in assembler would be like. I suspect for the most part
assembler on a P4 etc is a dead language.
73 Gary K8IQ
Richard Fry
> There are disadvantages. It would be nice to have graphics and to be
> able to dump the screen to a printer with one hit of a function key.
> But I think such facilities would make programs machine dependent
> through their screen and printer driver software. I could be wrong.
If you can tolerate TWO hits of a Fn key/mouse, Printkey 2000
will enable such, and works with Windows 9x/Me/2000/XP. The
screen clip also can be saved as a gif, jpg etc and pasted into
other windows programs, or attached to an email. The program
is free.
Here is one download link:
http://www.webtree.ca/newlife/printkey_info.htm
RF
clvrmnky
> Since we are talking about programming languages, does anyone know if there
> is Cobol available for XP Pro, and if so where can I get it at?
> Thanks
>
Visual Age for COBOL compiler for testing at work. It is very mainframe
oriented, and even has an interface that allows you to appear to code in
a Win32 IDE and it does the compile on a mainframe for you. IBM is also
committed to Java/services integration with legacy apps and languages.
The famous one is MicroFocus, which has a lot of Win32 support, right
down to all the Win32 APIs and .NET (don't laugh; COBOL was one of the
first 15 languages that Microsoft supported in the .NET framework.)
There are others: just let your Googles do the walking.
If you meant "free-as-in-beer-and-speech" COBOL, then you are somewhat
limited. The most useful is OpenCOBOL, but it fails many basic tests
for COBOL-85, at least on the two machines I compiled it on.
TinyCOBOL is pretty stagnant, and there is a lot of other vapourware
that seems to be infinitely stalled.
You can also download a free-as-in-beer learning edition of Fujitsu
COBOL which is slightly crippled. It should work on XP.
clvrmnky
> I don't even know where to start with that question--however, since
> GWBasic worked as a "basic interpreter"--the speed difference between
> that code and pascal could be compared to a baby crawling and the speed
> of light!
> However, here that is almost a moot point--speed is not important and
> the code is simplistic... and not demanding of processor cycles of
> execution...
>
Many "modern" BASIC implementations are compiled, at least to byte-code.
This makes it more equivalent to something like Java. With a clever
virtual machine design and today's fast systems it's hard to tell the
difference between a traditional compiled-to-object-and-linked
application and one that is compiled to byte-code and run in a VM or
interpreter of some sort.
> The reason to translate it to pascal or "C" is so it could be included
> into a larger antenna program--an example, not "C" of course, but
> fortran for example--would allow it to be included into a program such
> as EZNEC....
>
There is at least one BASIC system that will generate executables for
Windows, Mac OS X and Palm OS from the same source, and on the same machine.
John Smith
are still used, but out of main stream.
All professional implementation of C allow "inline assembly", you simply
drop an "asm" directive where you would like to switch to assembly and
begin keying in assembly code. When done, end your assembly block and
drop right back to C. Even turbo pascal allows this.... the compiler
and linker will just eat this up with no problem...
In the Linux world, one compiler and linker is able to virtually take
any language syntax and use it to compile and link binary code--it
doesn't give a rat's bum what syntax you are limited to write in--what
prevents that from happening out here in the real world is the need for
profit and to keep things proprietary--silly and very hampering... and,
made me have to learn a dozen syntax's over the years... I am not hung
up on syntax--and although I consider BASIC difficult in the fact it
obfuscates what is "really happening", cobol is worse... both are still
used, and microsoft would like to see everyone using "visual basic
scripting"...
I just don't fight the good fight anymore--will program in the language
which someone stands beside and is willing to defend with their life...
if the pay is good, the language is even better...
If someone suddenly "develops" a "new" and "revolutionary" language--I
guess I will grab a book and pick it up too... fact is, we have enough
syntax's need someone to come up with "real" ideas...
Warmest regards,
John
"Gary" <grynwbry@@@@Yahoo.com> wrote in message
news:jh3o91t8gksg37gce...@4ax.com...
J. Mc Laughlin
taught in computer engineering whether using assembler level languages or
higher level languages. In programming, spaghetti is bad.
Of course, at machine code level, a conditional branch includes what
looks like a goto. Only a Californian troll would not understand that does
not violate the idea of structured programming.
Well done Reg!
Mac N8TT
--
J. Mc Laughlin; Michigan U.S.A.
Home: J...@Power-Net.Net
"Reg Edwards" <g4fgq...@ZZZbtinternet.com>
<snip>
John Smith
... religious wars over "structured programming", OOP, syntax, etc...
always becomes the question, "Just how many fairies can I dance upon the
head of this pin."
My coding directly relates to the VERY specific sliver of the industry I
work in--encryption/decryption, in real time, of video, audio and text
and other signals relative to purpose--and is both for security and size
of data (data compaction) reasons and have transmissions/communications
occurring at a high rate of speed....
If you attempt to do that in real time, with very highly structured high
level languages only, and only written with regards to structure in
mind--you will ALWAYS fail--there is no processor fast enough, there is
no affordable way to build a product platform to execute the code on....
In college you learn the rules and how to "do it right"--but this is
only so in "real industry" you can effectively break these rules and end
up making a profit--the fairies dance the pin...
Take a look at just the testing shell I began to translate the code
given here to pascal--you will find it is indeed structured--that is
because speed is of no real importance and I am only concerned about
making it readable to others...
Warmest regards,
John
"J. Mc Laughlin" <j...@power-net.net> wrote in message
news:119p5uq...@corp.supernews.com...
John Smith
Just in case there is a danger that some may wish or attempt to bend my
quite real agreement with you (although mixed with my silly and
un-appreciated humor)--into a seeming disagreement--look at the testing
shell code...
NOT only have I agreed with you in my speech (text), I have agreed with
you in my code! There is no better "AYE!" which can be given...
Warmest regards,
John
"Reg Edwards" <g4fgq...@ZZZbtinternet.com> wrote in message
news:d7g88t$qn0$1...@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com...
John Smith
You can drop "mathix" from the uses statement--it is a 3rd party math
lib I thought I needed, but wrote the code internal to the code
itself--now it is not needed... but will generate a linker error, since
it will not be on your system...
Warmest regards,
John
"John Smith" <assembl...@gmail.com> wrote in message
news:pqIme.49$mj3.2...@news.sisna.com...
John Smith
In thinking about your question, it would surprise me if most any
compiler and linker which will run on windows 2000 will not also run on
windows xp--however, I am aware of no such COBOL compiler linker...
However, since the name of the language itself COBOL stands for "COmmon
Business Orientated Language" it might be better to ask in a
business-programming orientated newsgroup, rather than technical
groups--just an idea...
Warmest regards,
John
"Joe" <j...@telnet.com> wrote in message
news:cANme.21616$g66.12512@attbi_s71...
Richard Clark
<assembl...@gmail.com> wrote:
>... religious wars over "structured programming", OOP, syntax, etc...
>always becomes the question, "Just how many fairies can I dance upon the
>head of this pin."
Hi Brett,
This is simply sheer and uninformed baloney.
>My coding directly relates to the VERY specific sliver of the industry I
Which means you lack the scope and depth to be making such absurd
generalizations you offer here.
>If you attempt to do that in real time, with very highly structured high
>level languages only, and only written with regards to structure in
>mind--you will ALWAYS fail
More unvarnished blarney. You already reveal that you have very
little production experience to the matter, and what you write,
following, reveals you had very little academic backing in formalisms
to boot.
>there is no processor fast enough, there is
>no affordable way to build a product platform to execute the code on....
There is a vast industry in "fast enough" processors that work quite
capably with structured code. They are called DSP chips and run at
the highest efficiencies on the most rigorous of structured code
derived from the academics of Fourier Analysis.
There are hundreds of millions of OTHER processors that are in the
market right now that operate nothing other than structured designs -
the manufacturers couldn't afford otherwise without being run out of
business from cut-throat competition. You wouldn't last a cache hit
in the Gaming market.
From the profound to the prosaic - I've built JAVA designed network
servers that processed the entire TCP/IP protocol stack that inhabited
the 8-bit realm of an 8051. All serving up the usual web pages with
illustrations galore in less than 1MB memory space on a circuit board
as large as your thumb. All for only $50 too. Any Cassandra calls
that fast processors are necessary are throwing instruction cycles
against the wall to see what argument will stick. The wall of
structure design is Teflon coated.
>In college you learn the rules and how to "do it right"--but this is
>only so in "real industry" you can effectively break these rules and end
>up making a profit--the fairies dance the pin...
Brett, you are barely a decade out of that shoe-box you call college
and it sounds like they gypped you of an education.
>Take a look at just the testing shell I began to translate the code
>given here to pascal--you will find it is indeed structured--that is
>because speed is of no real importance and I am only concerned about
>making it readable to others...
This is, in fact, a self incriminating testimony to the lack of your
testing in this regard, not proof of the slowness of structured
design. You offer no metrics whatever, and yet you are ready to
jettison proven techniques on the basis of speculation. This is
probably driven by indictments from other sources in the trade press
trying to drape themselves with the mantle of authority. Their Power
Point slide shows generally prove they don't know how to engineer
measurements they purport to offer. I've sat through to much of this
kind of hand waving from scads of one night wonders in engineering
management (back when the bubble was filling with clowns who could get
a job by simply nodding at other clowns with full wallets). It was
embarrassing to sit next to a customer who really knew better.
I've stood toe-to-toe with other development groups that practiced
your mantra and they proved to be bloated, inefficient and under
productive as they struggled to offer 1/3 the product my groups
churned out by practicing the hallmarks of good design.
We could pass on to the favorite whipping boy of "documentation."
This topic is one of those steps that is jettisoned first by these
managers-in-a-bubble as being frosting that comes last; and as long as
it has plenty of sugar, then no one will notice how little food value
there is in it. I've seen their mal nourished groups grind into the
late night, thrashing in confusion, missing deadlines, budgets going
bust, and projects being canceled. The favorite excuse is it was
someone else's fault, or if they are so egalitarian, it was out of
their control.
All such failure was easily foreseen in the loss of structure, one
bit misplaced has no resilience as would be tolerated in an analog
design; hence the denial of structure is a call for assisted suicide.
73's
Richard Clark, KB7QHC
John Smith
I would like to explain just how ridiculous that appraisement in--I am
unable--I am a loss of words--and given up religious wars...
disassembly some code and have a look... that will either stand as proof
enough, or not... disassemblers are widely available... and syntax
translators clog the net...
Warmest regards,
John
"Richard Clark" <kb7...@comcast.net> wrote in message
news:2lmp91ptp6t415lvf...@4ax.com...
John Smith
and methods to be an effective, logical, and "politically correct"
programmer--industry teaches you how to effectively break these rules
for a profit...
... to be both teacher and effective in industry--you must know both...
Warmest regards,
John
"John Smith" <assembl...@gmail.com> wrote in message
news:cH5ne.209$at3.7...@news.sisna.com...
Richard Clark
<assembl...@gmail.com> wrote:
>You see one side of a two sided coin... college teaches you laws, rules
>and methods to be an effective, logical, and "politically correct"
>programmer--industry teaches you how to effectively break these rules
>for a profit...
Sheer hogwash. You don't have enough experience in the matter.
>... to be both teacher and effective in industry--you must know both...
Brett,
Having been both, and having had my feet held to the fire to PROVE
accomplishment (not merely declare that those students who fell by the
way were unwashed or otherwise tainted); then your test between us is
one that you have failed to graduate from.
Your improvisation into the weak defense of metaphor is quickly
dismissed by fillip: "You only have experience with the edge of the
two sides of a coin."
I was an instructor in Electronics in the Navy. The Navy had a very
rigorous (read structured) system whereby the students proved the
merit of the instructor in the quality of their grades. All testing
was done through question banks that had a track record of thousands
of students having answered them and producing a grading curve. No
test was offered that did not offer the prospects of 90% of the class
achieving at least a grade of 80%. If that mark were missed anywhere,
then it was back to sea duty for the instructor. This was because to
his point of instruction, those students had pulled their weight and
proven their proficiency in a heavily formalized system geared to
produce America's best Electronics Technicians.
I've had more than 100,000 student-classroom hours of teaching
experience and my students advanced to higher realms of study
un-impeded by any lack of my skill. I worked from a syllabus that
mandated that I attend very specific and structured "learning goals"
by any method I thought fit. It took some very imaginative skill to
do that as my classes were populated by a variety of ethnicities and
foreign populations (Greeks, Brits, Turks, Iranians, Vietnamese,
Korean, to offer a few). Some students had only 6 weeks of English
language training. Yet, and all, they managed to pull their share of
the 80% grade expected of ME. Any grade higher was the merit of their
own accomplishments.
My commercial Engineering experience (more than triple your own
spanning many schools of thought on software design) encountered much
the same in the spread of ethnicity and population groups within my
teams (more Japanese, Chinese, and Indians these days). These groups
EXPECT structure, and any straying from that expectation is a flaccid
sign of weakness that they hold in contempt (which they have the grace
to not expose).
John Smith
As you will have it... apparently the corp you work for has different
methods...
Warmest regards,
Brett Smith <grin>
"Richard Clark" <kb7...@comcast.net> wrote in message
news:naqp91t1tv6i8vp5s...@4ax.com...
John Smith
they are getting all the education they need at mit or berkeley--you are
mistaken, we internship them to "turn them to the dark side", we feed
'em goto-burgers and spaghetti-code (well, something like that)...
<evil-heheheheheeeeeeee!>
Warmest regards,
Osama Bin Laden -
AKA John Smith -
AKA Brett Smith <grin>
"Richard Clark" <kb7...@comcast.net> wrote in message
news:naqp91t1tv6i8vp5s...@4ax.com...
J. Mc Laughlin
Amen. You understand. Without structured and documented programming
one has trash (I know a few other descriptive words that would be
applicable). One of my students and I once built an automated EMC measuring
system that was under computer control. With the use of documented and
structured programming, changing instruments or the DUT was straight
forward. Furthermore, since each module was "rung-out" the reliability did
not suffer when things were changed. (Just to bring a bit of EMC related
subject matter into the discussion.) I am sure that many reading this site
know the pain of working on software that is not structured.
Thank you for your effort and skill in making the critical points clear.
73 Mac N8TT
Richard Clark
<assembl...@gmail.com> wrote:
>I will try one more time,
Hi Brett,
Trying "one" more time is not the same as being cogent to the matter,
nor compelling. However, this weak attempt underscores the basic
problem.
In short, what you are doing is a spaghetti excuse, and it aptly
proves the poverty of that method.
Gary
Thanks for the info John. I'm really surprised that assembler is still
used. Like I mentioned my experience was limited to an 8 bit 6502
processor and I suspected assembler was probably a goner by now.
73 Gary
On Tue, 31 May 2005 09:01:25 -0700, "John Smith"
Gary
<j...@power-net.net> wrote:
>I applaud Reg for his defense of structured programming. That is what is
>taught in computer engineering whether using assembler level languages or
>higher level languages. In programming, spaghetti is bad.
>
> Of course, at machine code level, a conditional branch includes what
>looks like a goto. Only a Californian troll would not understand that does
>not violate the idea of structured programming.
>
> Well done Reg!
> Mac N8TT
I'll never forget the days of trying to decipher some TRS-80 Model 1
Basic. You might read the first line or two and then have to a "goto
10000" statement for some subroutine. Spaghetti it was !
73 Mac ... Gary K8IQ
John Smith
Warmest regards,
John
"J. Mc Laughlin" <j...@power-net.net> wrote in message
news:119q2do...@corp.supernews.com...
John Smith
real bureaucratic MBA... every friday, no later than monday morning a
complete printout of our project had to be on this @$%@#$%'s desk--it
was COBOL!!!
I am sure he packed it home, showed it to his neighbors, impressed his
wife, children and friends with it--possibly even laid in on the bar
while knocking back a few, and the bar patrons were appropriately
impressed...
... anyway, he NEVER did figure out, the code was always the same,
always years old and from another project... but being about 4 inches
thick, it must surely have intimidated him to look...
... another thing he may NEVER have noticed, my boss would put little
rhymes and stories in the comments (and constantly change these)--he was
a pretty good writer and jokester, and many were funny--perhaps he only
asked for the printout so he could read those... <grin>
Warmest regards,
John
"John Smith" <assembl...@gmail.com> wrote in message
news:ic8ne.248$fV.87...@news.sisna.com...
Hal Rosser
> Dead languages are languages like cobol, pascal, fortran and basic--they
> are still used, but out of main stream.
I've heard it said that there's more lines of Cobol in use than all the
lines of all the other languages combined.
That's not too surprising though, considering the wordiness of the language.
IBM mainframes and the AS400 both still use COBOL - (and another one you
didn't mention - RPG).
John Smith
compiler and linker--it all looks the same--an assembly language
programmer has no problem reading it either way... the only people I
have ever found hung up on syntax--are non-coders... <frown>
Warmest regards,
John
"Hal Rosser" <hmro...@bellsouth.net> wrote in message
news:dY8ne.39281$6k7....@bignews4.bellsouth.net...
John Smith
Ahhh, just having a bit of fun--point being, I answer to a boss (used to
a wife), sometimes my kids... and that is about it... I no longer have
to champion my cause(s) and prove what is obvious to me... as I said,
you may have it any way you like... you attempt to divert and sidetrack
me to purpose of your own--my attention span has not become quite that
short yet... <grin>
Warmest regards,
Jim Jones (free Kool-Aid is being passed out in the yard!)
AKA Brett
"Richard Clark" <kb7...@comcast.net> wrote in message
news:a32q91peciut9390m...@4ax.com...
Richard Clark
<assembl...@gmail.com> wrote:
>point being, I answer to a boss
Hi Brett,
It isn't your boss writing this guff we read. Save it, I read enough
of this kind of explanation from Capitol Hill.
John Smith
Don't get so upset OM...
... of course, I can't toss as much BS as you are accustomed to...
wasn't it a 15 year old boy in the Netherlands, somewhere, which cracked
the encryption on DVD movies? After some super team of "structured
programmers" and "goto-less coders" sold the movie industry the idea it
was safe to release their product in digital form? Un-breakable
encryption they claimed--wasn't it?
Hey, aren't you from that industry--or did I get that wrong? <grin>
Well, probably just a fluke--it'll probably work next time...
Warmest regards,
Brett AKA "Big Bad John"
"Richard Clark" <kb7...@comcast.net> wrote in message
news:e5hq91dabupnpb96h...@4ax.com...
Richard Clark
<assembl...@gmail.com> wrote:
>... of course, I can't toss as much BS as you are accustomed to...
No, you don't do a very good job of it.
>wasn't it a 15 year old boy in the Netherlands, somewhere, which cracked
>the encryption on DVD movies?
Hi Brett,
You are talking about deCSS which proved irrevocably that NOT
following structured routes leads to ruin.
>After some super team of "structured
>programmers" and "goto-less coders" sold the movie industry the idea it
>was safe to release their product in digital form? Un-breakable
>encryption they claimed--wasn't it?
Once again, you supply a pale argument that literally exposes the
opposite of your bias. Those who "sold" this idea were NOT code
designers. You might carry more weight if you researched your
material before littering it here.
As Bruce Schneier offers in "Applied Cryptography," rolling your own
security is the easiest form of protection to crack. Clearly this
group who spun together CSS never got past his chapter 2 "Protocol
Building Blocks" and, if you haven't gotten the message yet, is
clearly the highest statement of structured programming around. Did
your college offer this subject as a weekend reading assignment during
Chico homecoming?
>Hey, aren't you from that industry--or did I get that wrong? <grin>
I doubt you could name an industry I haven't worked in. I also dug
ditches with the SeaBees and ran with many Diesel Boat Sailors. They
would unanimously qualify your BS as rather lame. I suppose most of
this has become tediously boring for others, why don't you try your
hand at antennas where foolish statements have at least an even field
for others to meet you on?
John Smith
Ahhh, simple problem then, out thinking is simply 180 degrees out of
phase, no problem, I like mine, you can change yours if harmony is the
goal--not the goal here...
Have a nice day...
Warmest regards,
John
"Richard Clark" <kb7...@comcast.net> wrote in message
news:gojq91ti1n6h2et1h...@4ax.com...
Richard Clark
<assembl...@gmail.com> wrote:
>Ahhh, simple problem then, out thinking is simply 180 degrees out of
>phase, no problem, I like mine, you can change yours if harmony is the
>goal--not the goal here...
The ethic of Savonarola with the Bonfire of the Vanities, harmony was
achieved when they tested his combustion temperature a year later.
Brett, this is a game you are ill suited for.
Reg Edwards
poetry.
Can I respectfully suggest you restrict your language to plain
American-English and avoid Old English Shakespeare as beautiful and
amusing as it may be.
Richard would also do better at communicating his ideas if he
continued along the same lines. I'm sure there's lots of sense
embedded in what you both have to say. But I am unable to dig it out.
Now please carry on with what you were saying.
Incidentally, I've now switched to South African red wine. And I'm not
on speaking terms with my doctor. By chance he is a radio amateur who
uses a G5RV. His nurses have more common sense.
----
Reg.
John Smith
You play a game, I go on with life... I am quite sure that is why none
of it appears to make sense to you...
Warmest regards,
John
"Richard Clark" <kb7...@comcast.net> wrote in message
news:gppr91plkfbp7bueo...@4ax.com...
John Smith
Don't much care for wine here Reg... but a good shot of American
whiskey always makes the day brighter... <grin>
Warmest regards,
John AKA Brett
"Reg Edwards" <g4fgq...@ZZZbtinternet.com> wrote in message
news:d7kpp6$9sm$1...@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com...
Richard Clark
<assembl...@gmail.com> wrote:
>You play a game, I go on with life... I am quite sure that is why none
>of it appears to make sense to you...
Hi Brett,
None of it makes sense simply because you speak of life like an old
man waiting to die. If you wish to characterize my mode as "playing a
game," you should note that your indictment describes me as having
more vitality than your circular and repetitive excuses for embracing
a morbid ethic.
(Sorry Reg if too much of this English is derived from the Normans -
is this something Americans can cope with that Brits still fume over
after a thousand years? You know, you write very little authentic
Anglo Saxon in the first place to protest. Even more, those Mead
drinkers would sneer at your continental foppery over wine.)
So, we are all well acquainted that you will not yield a point without
deflections of tepid japery - give us your best rebound.
clvrmnky
> Dead languages are languages like cobol, pascal, fortran and basic--they
> are still used, but out of main stream.
>
a few feathers to throw COBOL into the same basket as Pascal. Your
local bank manager or technical advisor may disagree violently on this
subject.
That is, even if we ignore the fact that Pascal was primarily created to
be a teaching language and Fortran was always a niche language (where it
did quite well, and still does), there's quite a bit of life in COBOL yet.
This is my understanding since being pulled kicking and screaming into
mainframe development because our customers demanded support of iSeries
and z/OS environments. I can say with all honesty that it is possible
to learn enough COBOL to make a small TCP/IP app that works quite well
in busy mainframe environment. So far the bugs I'm finding are in Java
on Win32 :)
In the process of doing so I also learned that not only is there more
COBOL code being actively maintained than any other language, out of all
new enterprise "mission critical" software development projects last
year COBOL was the language of choice for over 50% Of all new
application starts, COBOL represents 15% See
<http://www.csis.ul.ie/cobol/Course/COBOLIntro.htm> (I have no
affiliation with this site, nor have I independently verified these
numbers which appear to originate from the Gartner Group.)
I'd expect the former, given how many legacy apps written for hardened
banking, medical and insurance systems are written in COBOL. I mean,
Gartner reports that there are 240 billion lines of maintained COBOL out
there. All other languages represent 60 billion. That's a lot of COBOL
code.
The last was a surprise to me. I imagine numbers like this can be
sliced any way you like, but in my short experience there is a lot of
active COBOL development going on out there.
A lot of this has to do with the fact that the ANSI/ISO standard for
COBOL has been constantly updated, while allowing 40-year old apps to
still compile and run.
COBOL is easy to make fun of, but it still casts a deep shadow; I
suspect it will continue to do so for years.
[...]
> I just don't fight the good fight anymore--will program in the language
> which someone stands beside and is willing to defend with their life...
> if the pay is good, the language is even better...
>
Quite true, in my experience. I quite enjoy being forced to learn new
tools and techniques.
> If someone suddenly "develops" a "new" and "revolutionary" language--I
> guess I will grab a book and pick it up too... fact is, we have enough
> syntax's need someone to come up with "real" ideas...
>
This happens regularly. There are all kinds of neat languages to look
at. One of the tenets of "Pragmatic Programming" is to learn a new
language a year if you are a working coder.
My favourite new (to me) languages lately are Ruby and Haskell. The
former is a pure Smalltalk-like OO interpretive language. Great
prototyping language. The latter is a very pure functional language.
For those of us who cut our teeth on functional languages, it's quite a
fresh look.
John Smith
One thing you may be overlooking, many cobol programmers are only in
their 50's and early 60's and have not retired yet... they have become
senior in positions and their mindset still has much influence... in the
next decade--this begins to crumble...
Warmest regards,
John
"clvrmnky" <clvrmnk...@coldmail.com.invalid> wrote in message
news:QDnne.8414$5u4....@nnrp1.uunet.ca...
John Smith
Here we must separate paths, you are now focused on personal attacks on
my intelligence, thinking, actions, words, opinions, beliefs and
goals--and, if I read your words correctly--plan on denying me... you
may continue upon your course--and I upon mine...
Have a nice day...
Warmest regards,
John
"Richard Clark" <kb7...@comcast.net> wrote in message
news:t5ur91pf22uv28pcs...@4ax.com...
John Smith
The "180 phase-shift" in our thinking, I referred to, relates to this:
You mental-model knowledge as a well of water, if too many men drink and
use--it may run dry.
My model is upon a virtual well, one of the mind, the more men (and
women) who drink strengthen the source which feeds this well--and the
"water of knowledge" springs forth in abundance. Indeed, it should only
dry up if men obfuscate even the location of this well with quotes from
Shakespeare! (Or worse, movies!)
Another example:
You model newsgroups as a few experts imparting their wisdom to the
ignorant masses....
I model the newsgroups as a place where ignorant men overcome their
limitations by group effort...
And, another:
You model antenna hobbyists as SUPERSTARS, each going to make enormous
contributions on a solely individual basis...
I view us as a more socialistic model--where no man is of any
significance and the results of the whole is what matters...
... and that appraisal/opinion of mine is what prompted me to state what
I have and prompted me to the "180 phase-shift conclusion"...
Warmest regards,
Brett AKA John
"Richard Clark" <kb7...@comcast.net> wrote in message
news:gppr91plkfbp7bueo...@4ax.com...
clvrmnky
> clvrmnky:
>
> One thing you may be overlooking, many cobol programmers are only in
> their 50's and early 60's and have not retired yet... they have become
> senior in positions and their mindset still has much influence... in the
> next decade--this begins to crumble...
>
It may be a truism that COBOL coders are older than other coders (I'm in
my 30s) and that these people /may/ be driving the decisions to continue
to use it. I don't agree this is the primary driving factor for how
COBOL gets used in the real world.
That fact is that a good number of huge corporations (often referred to
as the "Global 1000") continue to use COBOL regardless of the age of
their project managers. COBOL has outlived the first wave of original
users of the language. Apparently the mean age for a working mainframe
developer is in the 35-45 demographic. These guys were just babies
(like me!) in 1968. Someone mentioned that last year's SHARE conference
had a younger crowd than ever before. There is talk about a
"third-wave" of mainframe developers (a demographic I'm not in a hurry
to join.)
Like I said, we have over 40 years of very, very mission critical
systems to maintain. These corps are very, very conservative about
changing these systems. It is naive, at best, to think that there is
one single factor that would drive these corporations to switch to
something else the day they retire the last old-timer.
I'm personally glad that banks, insurance underwriters and telcos use
big iron running truly time-tested technology to keep their uptimes
measured in years.
I not suggesting that COBOL will never be replaced. I'm suggesting that
things will not "crumble" but will be slowly migrated in a *highly*
controlled manner to other systems. Generally, this means that legacy
systems continue to work just as they always did, with features and
add-ons coming in the form of frameworks like MQSeries from IBM.
At any rate, I'm not sure we can trust anyone's crystal ball. All we
know is that traditionally the shops that use COBOL do not like risk of
any sort, and love to manage risk as much as possible. Any move away
from COBOL will be steady and controlled, and will likely keep people
employed for years to come.
For this reason alone, COBOL belongs in another pile altogether from
Pascal or even FORTRAN.
In fact, this very reasoning supports some of the decisions that the
embedded world makes. There are less and less reasons to make
hand-coded assembler or use speciality languages like real-time C or
Forth. Not unless one happens to be in the embedded systems world,
whereupon it suddenly makes a whole lot of sense. When you are making
1000 widgets that will be deployed for decades and then promptly
forgotten about, it makes sense to consider "alternatives" to the status
quo.
Is there a reason for anyone who doesn't work on z/OS or iSeries to
learn COBOL? No. Does the fact that small application shops, shops
that target home and office PCs and hobbyists don't use a language make
that language obsolete? Absolutely not.
The thing I've learned about this business is that one never know as
much as one thinks they do!
John Smith
As I have already stated, I have given up religious wars over syntax...
all that is left for me is to wonder why anyone would go on developing
in it (COBOL--I understand maintaining old code for economic reasons)
All which stands clear to me is that "C++" can do all of what the others
might achieve, combined (barring assembly, which is the root of all)...
... if MBA's dream of reading source and understanding it--not even
COBOL will grant them their dream... though they might pretend, more or
less successfully...
If you do not trust your programmers, you will limit them with their
language--I guess I am luckily I still have a position where all which
matters is our results and the department head is a strong programmer
with acceptable backbone... the coding dept here is looked upon as a
blackbox, you hand us specs, we give you working code... if all goes
well, no complaints... no one second guess you...
I know COBOL programmers argue syntax as if their very lives depended on
it (other languages too, to at least a degree), why has always been a
complete mystery to me, in the end I just chalked it up to fear of
"C"...
To try to give you a perspective of how this looks to me, the guy with
cobol looks like he is standing there with a sliderule in hand--the "C"
programmer as having a graphing scientific calculator in hand... both
can get the job done--I just expect to obtain better results from one...
Warmest regards,
John
"clvrmnky" <clvrmnk...@coldmail.com.invalid> wrote in message
news:iWpne.8433$5u4....@nnrp1.uunet.ca...
Russ
<assembl...@gmail.com> wrote:
>Richard:
>
>Don't get so upset OM...
>... of course, I can't toss as much BS as you are accustomed to...
>wasn't it a 15 year old boy in the Netherlands, somewhere, which cracked
>the encryption on DVD movies? After some super team of "structured
>programmers" and "goto-less coders" sold the movie industry the idea it
>was safe to release their product in digital form? Un-breakable
>encryption they claimed--wasn't it?
>
>Hey, aren't you from that industry--or did I get that wrong? <grin>
>
>Well, probably just a fluke--it'll probably work next time...
>
>Warmest regards,
>Brett AKA "Big Bad John"
>
>"Richard Clark" <kb7...@comcast.net> wrote in message
>news:e5hq91dabupnpb96h...@4ax.com...
>> On Tue, 31 May 2005 18:27:58 -0700, "John Smith"
>> <assembl...@gmail.com> wrote:
>>
>>>point being, I answer to a boss
>>
>> Hi Brett,
>>
>> It isn't your boss writing this guff we read. Save it, I read enough
>> of this kind of explanation from Capitol Hill.
>>
>> 73's
>> Richard Clark, KB7QHC
>
A poor algorithm and bad math can be implemented anyway you like,
strutured or kludge and it will be broken. Of course, it will be
easier to see what went wrong with the structured code. A good crypto
system can be done by hand and be un-crackable or DES can be done as
elegantly as is humanly possible and we all know what became of DES.
Russ, who has probably written as much code as anyone out there
Richard Clark
>A good crypto system can be done by hand and be un-crackable
Hi Russ,
Schneier holds that only ONE cryptographic system is un-crackable: a
one time pad - provided you (you meaning the pair in communication)
have the only key and then destroy it immediately after ONE use.
Every thing else succumbs to brute force if the secret's lifetime (its
value over time) is long enough.
Basically it boils down to cycles/cent, and the CSS lobby made their
algorithm the cheapest crack on the market. Roll your own security
and that's the consequences. Ultimately, security is no better than
the last bozo to touch the code.
Dan Brown's "The Digital Fortress" is a page-turner that moves on
these very precepts. The classic by Clifford Stoll, "The Cuckoo's
Egg" is an excellent detective story illustrating the perils in real
(1980s era) life.
John Smith
A good disassembler on a fast computer can rip through structured binary
code at hundreds, maybe thousands of lines a minute in a best case
scenario... generating readable assembly instructions which can easily
be converted into any syntax you would like... (course you gotta start
figuring out what "varible1" and "variable2" represent in the real
world--teenagers seem gifted to this)
... get Intel's "Big Book" on the processor and learn to use the tricks
to break this within the source code and disassembly ends up a mess...
a really good in-house optimizing compiler can be used to obfuscate code
a bit too... (production compilers which been "cracked" can actually be
used to aid in the disassembly, telling exactly how they built the code)
...in the end, the more structured the better the disassembler can
"guess" the code and spit out source a 15 year old teenager can eat
up... sometimes there is little need to worry about such, and sometimes
you just don't have a choice...
... then there are those who have never even heard of such things, one
real user of all these tricks and more is M$ itself... IBM has been
another... and if you really want to make your head spin, take a look
at the compiler Intel sells--those boys know all the tricks... the
compiler ain't cheap, and its code has NEVER been cracked (not fully
understood in its operations)... been around for years, scarce due to
the fact it holds the hackers at bay (they don't have a bunch of cracked
copies they can use)... now Intel knows how to obfuscate!
... now is the time the pin head fairy dancers come out to play...
Warmest regards,
John
"Russ" <carl...@hotmail.com> wrote in message
news:v7ns91h70caggmjpo...@4ax.com...
Cecil Moore
> ... have the only key and then destroy it immediately after ONE use.
Years ago, experiments were carried out with chaotic keys.
Wonder what happened to that notion?
--
73, Cecil http://www.qsl.net/w5dxp
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
John Smith
10^100000000 bit encryption, I can see it on the horizon now... <grin>
How are they ever going to allow those wonderfully encrypted DVD's to be
played--without having to include a decryption algorithm in each player?
And, how are they ever going to be able to stop a blackhat hacker from
downloading the code from the hardware and cracking it?
Perhaps a system where if you open the player there is a little suicide
bomber in there--and he throws the switch?
Warmest regards,
John
"Cecil Moore" <w5...@hotmail.com> wrote in message
news:429e879e$1...@spool9-west.superfeed.net...
Russ
wrote:
Yep, the Vernam cipher is the one and only. Good crypto depends on
good key discipline and good message discipline (padding, no
stereotypical messages, etc)
Digital Fortress and Brown's other books are so full of bullshit that
I only read them to see how full of it he could get. Just like that
other "great" author, Steven King. King seems to get paid by the word
and his prose show it.
Russ - kf4wxd
clvrmnky
> clvrmnky:
>
> all that is left for me is to wonder why anyone would go on developing
> in it (COBOL--I understand maintaining old code for economic reasons)
>
contrast syntactical structures of various languages forever, I'm not
sure I agree at all that this is what I've been discussing.
The notion that syntax is the only difference between languages,
especially in the context I've been giving, is not accurate at all. I
certainly was not arguing syntax can be used to measure worthiness or
success of a language.
My comments should be taken as musings on the nature of working coders,
and the tools they need to succeed in different environments. Syntax is
almost a non-issue when one takes this view.
I mean, COBOL has a pretty "interesting" syntax which has not stopped it
from becoming a highly important part of most of our lives. Your bank,
insurance company, investment company and telephone company all depend
on COBOL, and will continue to do so for years to come. There will be
no sudden change, especially not to Java or any C-like language.
The reasons for this have nothing to do with syntax, and everything to
do with long-term stability and scalability in the mainframe environment.
> All which stands clear to me is that "C++" can do all of what the others
> might achieve, combined (barring assembly, which is the root of all)...
>
Any relatively complete language can do what any other language can do.
However, the language is just one small part of the process. The
environment in which the code is built, test, run and maintained is much
more important that the language itself.
Be careful of using terms like "assembler" because this is often just
another language, depending on the platform. The word "macro" in "macro
assembler" means something! A CPU does not understand the text "JMP
$A000" anymore than most humans.
Hand-crafted machine code via some kind of loader is pretty bare metal,
but very few people do this kind of thing anymore. Even that requires a
linker/loader on most modern CPUs.
> If you do not trust your programmers, you will limit them with their
> language--I guess I am luckily I still have a position where all which
> matters is our results and the department head is a strong programmer
> with acceptable backbone... the coding dept here is looked upon as a
> blackbox, you hand us specs, we give you working code... if all goes
> well, no complaints... no one second guess you...
>
Well, if your intention is to say that using COBOL somehow restricts
imagination and innovation, I have to respectfully disagree. A language
is just a tool, and the differences between the languages amount to no
more than flavours, in my experience.
That is, I don't see much of a gulf between coding in C, Java,
Objective-C or COBOL, other than language structure. One's approach to
solving problems changes, to be sure, but the notion is that one chooses
to solve problems using the most appropriate tools at their disposal.
Honestly, in the mainframe world even right now, the best tool for
solving the problems of mainframe environment is ReXX, JCL, PL/1 and
COBOL. z/OS shops support a fair amount of 390 assembler, but COBOL is
king for many reasons.
C is used on mainframes, but more as a "high-level" assembler for
drivers and services.
> I know COBOL programmers argue syntax as if their very lives depended on
> it (other languages too, to at least a degree), why has always been a
> complete mystery to me, in the end I just chalked it up to fear of
> "C"...
>
Do they? I hadn't noticed. There are "shop standards" and there are
finer points of where to place that final full-stop. However, the
stickler for syntax is the compiler itself. Most maintenance coders I
know have a healthy disrespect for all languages and often make wry
jokes (i.e., "gallows humour") at their own expense. Given that C is
available on mainframe I don't think anyone is really afraid of it.
Not unless you are concerned with buffer overruns, memory leaks and
stack-smashing in your mission critical application. Then you are right
to be very, very afraid of C or C++.
When you maintain a large body of code for many years, it is important
to pay attention to the details. If you check in changes around my shop
without paying attention to whitespace and bracing style, your changes
get rejected. This is generally considered a good thing.
> To try to give you a perspective of how this looks to me, the guy with
> cobol looks like he is standing there with a sliderule in hand--the "C"
> programmer as having a graphing scientific calculator in hand... both
> can get the job done--I just expect to obtain better results from one...
>
Yikes. This is sort of a naive way of looking at things, isn't it?
Expecting better results from a coder simply on the language choice is,
in my experience, the road to hell pave with all kinds of good intentions.
The difference between something like COBOL and C is not at all how you
describe it. COBOL is not some kind of stone-age tech that has fallen
behind. If anything, C has been pushed deeper into it's original niche
of a tool to generate object code for operating systems (specifically,
Unix-like operating systems.)
This is not a bad thing because this is one of the things C does best,
but it does make C a bit like the slide-rule language of yore. I think
of it as a compact and arcane tool that the original east-coast geeks
invented as a "high-level assembler" on early time-sharing systems they
were inventing at the same time.
Similarly, COBOL is an arcane and much larger toolset that, along with a
whole spectrum of tools, was invented to solve another problem
altogether. It just happens that this particular "niche" is much, much
bigger than any of the other niches.
Certainly COBOL standards have been updated more recently than C; I
suspect we may never see another ANSI/ISO standard for C again. Some
might argue that this implies the language is "perfect"; that the C
specification has reached a point where it represents the pinnacle of
achievement for the language.
I think this horse is dead.
-- cm
John Smith
Real processor instructions are numbers, binary, they can be visualized
in one and zeros, but much easier on the hex, 16 base, system.... of
course assembly language has a syntax... but with its syntax, for the
most part, one single instruction translates down to one or two
processor instruction(s) (number(s))(and there are even exceptions to
this--macro processors for example)--in a high level language one
instruction can translate to hundreds if not thousands of instructions
on the processor level.
Well, arguing cobol when technical uses are intended is moot. You would
need an assembly language programmer to even begin--the language simply
does not have the constructs to be used effectively and would need to be
created.
Except for my first entry into the field, I have always avoided business
related programming (cobol/basic--so I am not well voiced to argue bank
coding) like the plague (my avoidance is NOT always successful even
today.) Writing the interfaces to hardware (drivers) has always
interested me the most--but I do diverse projects and always there is
the boring maintenance and adjustments for cracked code which hackers
have caught on to (this can get interesting.) However, where I
presently find employment, ALL programs are in "C". From our
in-house--marketing, sales, business end--right down to the drivers.
Back in 1995 there was a battle here to drop cobol and standardize all
our stuff around "C", the older cobol'ers won out--then in 2000 a lot of
our business code was contracted out and we ended up with no in-house
cobol ONLY programmers (right to the bitter end when they lost their
jobs, they argued for cobol!!!--they should have popped back to a few
classes and picked up "C":)... luckily, shortly after this time, we were
able to argue we should center all our code on "C" and not allow outside
programmers to be aware of the functioning of our code (just then, as
luck would have it, virus's, trojans, etc helped make our point for us),
this allowed us, in-house, to translate the cobol to "C" and we now
maintain all our code in-house again--kinda luckily for guys like me
which still need a job.... (the department head here is as crafty as a
wizened old fox)
I would hate for a guy over in India or China to be doing my work right
now... and I keep my fingers crossed--it could easily just happen...
Warmest regards,
John
"clvrmnky" <clvrmnk...@coldmail.com.invalid> wrote in message
news:uVEne.8547$5u4....@nnrp1.uunet.ca...
Richard Clark
>King seems to get paid by the word
>and his prose show it.
Hi Russ,
I would take a tenth penny on the dollar he made, and live a rich man.
clvrmnky
> clvrmnky:
> in one and zeros, but much easier on the hex, 16 base, system.... of
> course assembly language has a syntax... but with its syntax, for the
> most part, one single instruction translates down to one or two
> processor instruction(s) (number(s))(and there are even exceptions to
> this--macro processors for example)--in a high level language one
> instruction can translate to hundreds if not thousands of instructions
> on the processor level.
>
fields of electrons doing little controlled dances across the gates of
semiconductors. We aren't really talking about binary values anymore
because even this is an abstraction. It's not like anyone uses a keypad
and/or mechanical switches to load values into a register anymore.
However, assemblers were, and still or to some extent, seen as
high-level abstractions to facilitate code maintenance and readability.
This, of course, is why we have such a thing as computer languages.
Most of the time we don't care if the macros we see in a text file
correspond directly with a particular instruction.
Heck, for application programmers the further one gets away from
thinking about "instructions", the better!
> Well, arguing cobol when technical uses are intended is moot. You would
> need an assembly language programmer to even begin--the language simply
> does not have the constructs to be used effectively and would need to be
> created.
I'm not sure what you mean. While it may be handy to think of
machine-coders as the "starting point" for all things, this is not
really how it works. Most high-level languages are written in other
high-level languages.
Of course, many people take issue with the whole high vs. low level
approach anyway. Languages like C and Forth are certainly low-level if
you look at them the right way. This is one of their strengths.
However, being closer to the metal is not always better. The whole
notion of computer languages is to find a way to describe a solution to
a problem space. There are some spaces
> Except for my first entry into the field, I have always avoided business
> related programming (cobol/basic--so I am not well voiced to argue bank
> coding) like the plague (my avoidance is NOT always successful even
> today.) Writing the interfaces to hardware (drivers) has always
> interested me the most--but I do diverse projects and always there is
> the boring maintenance and adjustments for cracked code which hackers
> have caught on to (this can get interesting.) However, where I
> presently find employment, ALL programs are in "C". From our
> in-house--marketing, sales, business end--right down to the drivers.
>
This makes sense. C was designed as an object-code generator for things
like operating system librarys and (now) drivers. C can often be
thought of as a portable assembler.
The age of writing applications in C (ANSI-C, anyway) is probably long
over. We have much better tools to solve that problem. Hey, I like C,
but I recognize it's weaknesses. If COBOL is wordy and has a strange
idea of when a "statement" is (or is not) over, then C is too dangerous
in the enterprise, and requires coders with a fair amount of experience
who know how to use a debugger and enjoy assertions!
But it pays my bills, as does COBOL and Java. My Pascal work lives on
in the form of Delphi. I suspect that in the future dependence on a
specific language will diminish in favour of deployment platforms like
.NET and such. Who knows, maybe the next time we talk Google will be a
complete internet development platform?
At any rate, this whole thread was prompted by the earlier comment that
somehow COBOL is obsolete and that nobody uses it. My introduction to
the language (not my choice, either) has enlightened me somewhat to the
fact that this is just not the case. In fact, the exact opposite is
true right now, and is unlikely to change until someone can come up with
a tool for the same problem space that offers the same necessary qualities.
It is not just that old-timers are reluctant to see the light and move
to Java or C (or rewrite all those thousands of lines in
machine-specific assembler.) The space that COBOL is in cannot be
replaced (not without a lot of pain and significant risk) by anything
else right now. The "right" kind of Java environment is a likely
candidate in the long term.
Anything else I've mentioned is secondary to this point.
I've said it before, but it still bears repeating: I'm glad my bank
depends on mainframes and COBOL. Uptime measured in years and
performance in thousands of transactions per second (with rollback) is a
Good Thing!
Dave Platt
Cecil Moore <w5...@hotmail.com> wrote:
>Years ago, experiments were carried out with chaotic keys.
>Wonder what happened to that notion?
Depends how you use 'em.
As far as I know, the "one time pad" system is still used for certain
communications which require extremely high security. The key is as
long as the message itself, is generated via extremely-random
processes (e.g. monitoring radioactive decay, listening to RF white
noise from deep-space sources, etc.), is used only once (it's
exclusive-or'ed with the message), and is then destroyed. Since
there's no regularity in the key, and no re-use of any portion of the
key, there's no way to analyze the cipherstream - any possible
plaintext is equally probable.
The biggest limitation to this system is that it's very clumsy to use.
You have to generate a *lot* of truly-random key, and then manage to
distribute it via a physically-secure channel (e.g. CD-R discs
hand-carried by an armed courier) and keep it secure (tamper-evident
seals on the packages, etc.). I believe this system is used for
certain military and intelligence data, but I'd be sorta surprised to
see it being used in commercial applications.
For less-secure cryptosystems, the problems seem to break down into
several categories: the strength of the algorithm itself (e.g. are
there any cryptanalytic attacks which are significant more efficient
than brute-force enumeration of all possible keys), distribution and
sharing and use of the keys, and the integrity of the coding (e.g. did
the algorithm or the implementation code contain a "subliminal
channel" which "leaks" information about the message or key?).
--
Dave Platt <dpl...@radagast.org> AE6EO
Hosting the Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
John Smith
The only time I ever used a keypad and programmed directly in hex was
college... it was a beginning class where you had to develop your own
simplistic compiler and linker to run on a motorola processor, to gain
understanding at the workings of a processor...
My C compiler/linker will go "Dennis Ritchie"/ansi/OOP/etc... there are
compiler directives to allow or bar any encountered standards--I always
run "wide open", if it is assembly to complex OOP macros the compiler
never complains (except at real logic/language/syntax errors and missing
libraries)... however, we call the winapi directly when in windows, the
UNIX kernel directly when in UNIX/Linux... or assembly to deal with an
LCD screen and ports if on the microcode of motorola cell phone, etc...
We have developed in-house source/binary libraries, both static and
dynamic and seldom go to a 3rd party vendors (M$ SDK/DDK is used for
windows NT, sometimes, mostly kernel device drivers)...
Frankly--I live a coders dream (well, something like that)... <grin>
Warmest regards,
John
"clvrmnky" <clvrmnk...@coldmail.com.invalid> wrote in message
news:VNHne.8603$5u4....@nnrp1.uunet.ca...
John Smith
Currently I am following his "Wolves of Calla" series... I don't mind
kicking him a few pennies myself....
Warmest regards,
John
"Richard Clark" <kb7...@comcast.net> wrote in message
news:g8eu91hsmo0tjqdsu...@4ax.com...
Bill Ogden
Intel to zSeries. (The most fun was the 7090 series; the least fun was
Intel.) The concept of assembly programming to obtain the last ounce of
performance is becoming questionable, at least on mainframes. Best
performance, when considering superscalar operation, pipelining, cache
boundaries, and virtual memory translation boundaries (TLBs on mainframes)
no longer involves straightforward instruction streams, but needs to
interleave all these other consderations that are definitely not intuitive
to an assembly programmer. Well-written compilers can usually do a better
job. Of course, the compiler (or optimizer that follows the compiler) must
be very well adjusted to the hardware that will execute the program.
I am not a COBOL programmer. However, I do appreciate a few attributes of
COBOL. For example,
- It allows creation of in-program "subroutines" with full access to the
program's symbol table. (I.e., use the PERFORM verb.) Very few other
languages (other than assembler, of course) allow this.
- It deals with strings as primitive elements, something the C does not
do. When running on hardware (such as mainframes) that also deals with
strings as basic elements, this allows for much more straightforward use of
the instruction set. (The requirement for C programs to frequently chase
the end of character arrays to deal with strings, and the common need to
reserve a character (x'00') to mark the end of a string, has always seemed
rather primitive to me. Of course, it was needed on the hardware used for
early C---it is unfortunate that the language never progressed past this
hardware design limitation.)
-The average COBOL program is almost certainly easier to maintain (years
later, by another programmer) than the average C program. Of course, one
can write obscure code in any language or wonderfully clear code in any
language, but I am speaking of existing, average code. (The extreme example
in this category was APL. Even the original programmer could often not
understand his own code after being away from it for a few months. It was a
wonderful, powerful language, but the average program was utterly
unmaintainable in typical production environments (in my opinion).)
I have noticed that major applications written in C (or C++) appear to
consume considerably more processor power and considerably more memory than
applications written in COBOL (or assembler, or PLI, or Fortran). A 1MB
application in COBOL is "large" while a 1MB application in C is almost
"trivial". I know a lot of this is due to the inclusion Windows libraries
(DLLs), etc, etc, and the different nature of the applications.
There is seldom a winner in religious "discussions" and I suspect this
thread is about to die.
Bill
W2WO
John Smith
I actually do not stand at complete odds with you...
However, "C" can be viewed as a "superset" of assembly...
Or, assembly can be viewed as a subset of "C"...
I am aware of no "C" compiler which refuses to accept assembly language
instructions--as standard... I am aware you might have to set compiler
directives to allow or disallow this as you see fit...
For one who declared, right from the start, that religious wars on
syntax are exactly what I wish to avoid... I seem drawn like a moth to a
flame (or something like that)...
However, since we have gotten here, to this point, let me go further, if
I would choose to write in COBOL syntax--I would still keep my "C"
compiler and linker---and, would use the #define and statement, and
macros in "C" to remap all of the COBOL syntax I would use, to "C"....
I could then go about my merry business and write in "COBOL", when the
"C" compiler seen the source, it would translate on the fly and produce
"C" object code...
if I was not aware of what had been done--I could honestly be left
thinking I was truly using a legit COBOL compiler/linker, I could do
the same with pascal--even basic should I choose... attempt to do the
reverse with those languages and you will see failure...
... in my humble, personal opinion, you can develop a million more
syntax's, I am just left to sit and wonder why...
Warmest regards,
John
"Bill Ogden" <wog...@attglobal.net> wrote in message
news:EG_ne.39164$NZ1....@fe09.lga...
John Smith
nothing fancy, just for personal use--it contains both computations for
monopole and dipole... as the original basic code implemented it (very
similar)...
http://blake.prohosting.com/mailguy2/gamma_cpp.txt
Warmest regards,
John
"John Smith" <assembl...@gmail.com> wrote in message
news:pqIme.49$mj3.2...@news.sisna.com...
> To all:
>
> Since we seem to be picking up a pascal programmer or two-I might as
> well toss this out and see if anyone is interested:
>
> R. Nelson-WB0IKN, apparently, contributed/wrote an article back in
> January 1985 issue of "Ham Radio."
> Anyway, I ended up with some source code of his to compute a gamma
> match for a monopole/dipole-it is written in basic, and runs in
> "GWBasic" (you can get a copy of GWBasic off the net if you wish to
> run his original source-or use a method of your own.) I have the
> source at:
> http://blake.prohosting.com/mailguy2/gammabasic.txt
>
> I did a bit of work in translating his source to pascal, and it is in
> two files there:
> http://blake.prohosting.com/mailguy2/gg.txt {a pascal .tpu unit to
> be used by the main program }
>
> and:
> http://blake.prohosting.com/mailguy2/gamma.txt {the main program}
>
> . this source is mainly a debugging shell to get his
> formulas/calculations converted to pascal's method of handling math.
> . the source compiles and runs. and seems to end up with the same
> values as his source. the code is FAR from finished and is a starting
> point. but can be used quite effectively to test the concept.
>
> . there is an error if "driven element diameter = gamma rod diameter =
> gamma rod spacing".. It is a divde by zero error. since a square root
> of a variable is attempted and of course NOT allow and generates the
> error. his original code does NOT suffer this error-because of a
> "buggy error" in gwbasic-it allows the square root of zero,
> apparently!!!! (he started working with imaginary numbers it seems!)
>
> . anyway, those interested can take a look at the source and see if it
> is of any interest to them-be great if someone would get it into good
> working shape and have Reg put it up to share with all interested.. I
> just have about a dozen other things on my plate right now and can't
> get to it immediately-and would rather translate to "C" anyway.
>
> . it would be interesting if anyone has any good info on design of
> gamma matches and could share that with me-I'd like to study the
> formulas and hear descriptions of the calculations-as here I have only
> translated them-if anyone has such, please let me know. R. Nelson, or
> course, should be given credit for having provoked these manipulations
> of his original code.
>
> . my debug code only considers the monopole, the dipole option would
> need to be added, but is a simple calculation or two which can be seen
> in his original basic code.
>
> . if I can help with any others efforts, in any way, just let me know.
>
> Warmest regards,
> John
>
> "Gary" <grynwbry@@@@Yahoo.com> wrote in message
> news:1hrl91lh6f251i79u...@4ax.com...
>> Thanks for all the helpful programs Reg. I'm just curious what
>> programming language you are using to create the DOS programs ? I've
>> programmed in basic years ago and also Pascal and assembler. I'd like
>> to do some programming for some simple projects of my own but don't
>> need or want anything like a 400 page book(s) for Visual C++ etc.
>>
>> Thanks in Advance.
>>
>> 73 Gary K8IQ
>
>
ka...@sonic.net
<clvrmnk...@coldmail.com.invalid> wrote:
>On 31/05/2005 12:01 PM, John Smith wrote:
>> Dead languages are languages like cobol, pascal, fortran and basic--they
>> are still used, but out of main stream.
>>
>Indeed, these are certainly legacy languages. It might, however, ruffle
>a few feathers to throw COBOL into the same basket as Pascal. Your
>local bank manager or technical advisor may disagree violently on this
>subject.
Especially your bank's loan officer. I know for certain that
the code to determine your credit rating is still written in COBOL.
ka...@sonic.net
<clvrmnk...@coldmail.com.invalid> wrote:
>On 01/06/2005 6:03 PM, John Smith wrote:
>>
>> If you do not trust your programmers, you will limit them with their
>> language--I guess I am luckily I still have a position where all which
>> matters is our results and the department head is a strong programmer
>> with acceptable backbone... the coding dept here is looked upon as a
>> blackbox, you hand us specs, we give you working code... if all goes
>> well, no complaints... no one second guess you...
And no one to competently review your code to verify that it
does exactly what the specs say and not a whit more. God willing, your
shop never gets within shooting distance of my checking account or
life support system.
Say, you guys wouldn't be behind the famous control code for
the equipment which allowed radiation therapy patients to receive tens
or hundreds of times the prescribed radiation dosage, would it? "All
wen well" until patients started dying.
>> I know COBOL programmers argue syntax as if their very lives depended on
>> it (other languages too, to at least a degree), why has always been a
>> complete mystery to me, in the end I just chalked it up to fear of
>> "C"...
It's common for those whose ideas aren't accepted to "chalk it
up to fear" on the part of others. It's easier by far than proving
your case.
John Smith
"bibles", I really never look for these institutions to be
"progressive." Frankly, if you offered up that bank code employed a lot
of Hebrew and Greek, I'd investigate first before claiming naught...
... heck, as far as bankers go--I'd not even be surprised if they were
the direct decedents of the original "money lenders in the temple."
Warmest regards,
John
<ka...@sonic.net> wrote in message
news:k217a1lpvrck4bh5t...@4ax.com...
John Smith
And, "... how can we ever release this code, there still might be one
error in the 30,000 pages of well documented source... ?"
... questions to which there are many answers...
Warmest regards,
John
<ka...@sonic.net> wrote in message
news:f527a1p12989usuu0...@4ax.com...
Bill Ogden
and these help define the boundaries of the languages. No amount of
#defines will allow a C compiler to provide subroutines with full access to
the main program symbol table. (Making all variables external (in the C
program) could accomplish this, but would be unreasonable for many other
reasons.) There really are differences in languages beyond the obvious
syntax differences.
I tend to measure languages (and programmers) by their maintainability,
measured in decades. Possibly one my most important business actions was
helping kill application development in APL.
Of course, IMHO, anything worth writing is done is assembly language --- but
that is a different debate.
Bill
W2WO
"John Smith" <assembl...@gmail.com> wrote in message
news:Wf%ne.35$Uz.9...@news.sisna.com...
John Smith
Too be perfectly frank with you, all who I have ever seen argue syntax
simply can't program--that doesn't mean they don't think they can...
If you find a programmer who is having difficulty maintaining C, I think
you will find he/she has difficulty maintaining any syntax...
C can simply do all of the other languages combined--at its first
creation by dennis ritchie it was "all powerful." Since that time many
have posed arguments of why it should be limited--they even go to the
extreme of attempting to hide these attacks on the language in
"standards", so far all these attempts have failed--thank gawd...
Warmest regards,
John
"Bill Ogden" <wog...@attglobal.net> wrote in message
news:BFYoe.41969$NZ1....@fe09.lga...
clvrmnky
this thread]
<ka...@sonic.net> wrote in message
> news:f527a1p12989usuu0...@4ax.com...
[...]
>>>>>On 01/06/2005 6:03 PM, John Smith wrote:
>>>>>>> If you do not trust your programmers, you will limit them with their
>>>>>>> language--I guess I am luckily I still have a position where all
>>>>>>> which
>>>>>>> matters is our results and the department head is a strong
>>>>>>> programmer
>>>>>>> with acceptable backbone... the coding dept here is looked upon as
>>>>>>> a
>>>>>>> blackbox, you hand us specs, we give you working code... if all
>>>>>>> goes
>>>>>>> well, no complaints... no one second guess you...
>>> And no one to competently review your code to verify that it
>>> does exactly what the specs say and not a whit more. God willing, your
>>> shop never gets within shooting distance of my checking account or
>>> life support system.
[...]
On 05/06/2005 8:29 PM, John Smith wrote:
> Ahhh, "...who watches the watchers....?"
> And, "... how can we ever release this code, there still might be one
> error in the 30,000 pages of well documented source... ?"
> ... questions to which there are many answers...
>
Code reviews are not absolutes. The notion is to have many eyes staring
at something so that, as a group, they can spot problems and pitfalls.
Sometimes we aren't even talking about errors. It's important in a
large product to organize components and interfaces and such in a
sensible manner, and sometimes someone will point out where you can
refactor or where you are "reaching around" to a software component you
shouldn't be accessing directly. Code reviews can take many forms, as
well. Most of the time it is just water-cooler talk when working on a
problem, and then a reviewer or two before changes are committed.
Bigger projects almost require a weekly sit-down with dead-tree version
of the code in front of you.
There will always be errors in software. The idea is to use the tools
and protocols appropriate for the task and application to help minimize
the errors and to control the effect of the errors over time.
The enterprise software business depends to some extent on something
called "SCM" (Source Code Management) or "ALM" (Application Lifecycle
Management) to manage change to critical business systems over time.
The "black box" method you talk about is fine, but only as long as there
are internal processes guiding decisions about how code is changed for
any reason.
Failure to do so will result, eventually, in tears and recrimination.
I've seen it and I've lived it.
Generally, any company that makes software knows that that software is
it's greatest and most important asset. Managing that asset is what
what I've been driving at, and what (I think) "kashe" was hinting at, as
well.
Really, for any large software project there is one simple rule: Every
time a developer makes significant changes without some sort of code
review, God kills a kitten.
-- cm
Reg Edwards
The concept of MTBF, Mean Time Between Failures, can be applied to
software.
Does anyone disagree?
John Smith
Warmest regards,
John
"Reg Edwards" <g4fgq...@ZZZbtinternet.com> wrote in message
news:d81o4f$6gt$1...@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
John Smith
million professional computer users can use the application and never
discover the error in code--let one computer illiterate dummy have the
keyboard and an immediate crash occurs...
You keep large data files of previous errors which are known and
simulate real world entry of such "garbage" to the application, in
debugging you literally toss everything but the kitchen sink (well,
maybe that too) at the development project from tons of "error
generating data files"... you exercise its dynamically created buffers
and constructs with endless streams of junk, a lot randomized... you
attempt everyway possible to break the running of the application--as
time goes by you get better at this testing... if it passes all this on
multiple high speed machines testing for endless hours/days--you then
release it for beta testing--if you have done the testing well, there
will be few reports of errors from beta testers... then the computer
illiterates get their turn...
Warmest regards,
John
"clvrmnky" <clvrmnk...@coldmail.com.invalid> wrote in message
news:YgZoe.9072$5u4....@nnrp1.uunet.ca...
Fred W4JLE
"Reg Edwards" <g4fgq...@ZZZbtinternet.com> wrote in message
news:d81o4f$6gt$1...@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
Richard Clark
<g4fgq...@ZZZbtinternet.com> wrote:
>The concept of MTBF, Mean Time Between Failures, can be applied to
>software.
>
>Does anyone disagree?
Hi Reg,
Of course. MTBF is more apropos to linear systems. For digital
hardware, failure is dominated by either infant mortality, or old age.
Very rarely is there a problem in between.
As for software, any notion of time is utterly ridiculous. Any
operation that successfully performed once will ALWAYS perform
identically every time again. There is no such thing as a time
between failures such that the software will be reliable in between.
That would be spooky beyond superstition.
The best that you can expect from software is that if it is simple
enough, you can trust it to do the same thing again - a Brit by the
name of Alan Turing proved this some 60 years ago. Turing also
offered there is no way to guarantee a program will work, unless you
are willing to watch it for as long as it was running. For a quick
reference, google Turing and Enigma machine.
Roy Lewallen
I do. It's a much too simplistic concept. "Failure" can be a bug which
requires a second mouse click when only one should be needed, one which
causes a critical output value to be wrong by an amount that's serious
but not obvious, one which causes a plane to crash or a bridge to fall,
or anywhere in a continuum between them. It's shortsighted and can be
badly misleading to lump these vastly different flaws together into a
single quantity "failure".
Even if you did adopt this terribly simplified model of failure, the
mean time (presumably in user-hours for typical desktop computer
software) between "failures" depends very heavily on the user and how he
uses the sofware.
While it might be a useful concept for some small class of programs
which perform a small set of tasks, I'd consider any stated number for
MTBF for most typical desktop programs as simply a fabrication of the
marketing department. It could be made to be pretty much whatever they
choose it to be.
Roy Lewallen, W7EL
clvrmnky
> A million programmers can look at source and miss a very simple error, a
> million professional computer users can use the application and never
> discover the error in code--let one computer illiterate dummy have the
> keyboard and an immediate crash occurs...
>
and bugs we don't. Since QA is typically the most expensive part (in
terms of man-hours) we might want to minimize bugs as much as possible
in the unit-testing phase.
However, this does not address the issues of component scope or design,
or refactoring, both of which are critical to maintaining a large
project over any serious length of time.
Bugs are the easy part, and they are not strictly why one should have
code reviews of some nature.
> You keep large data files of previous errors which are known and
> simulate real world entry of such "garbage" to the application, in
> debugging you literally toss everything but the kitchen sink (well,
> maybe that too) at the development project from tons of "error
> generating data files"... you exercise its dynamically created buffers
> and constructs with endless streams of junk, a lot randomized... you
> attempt everyway possible to break the running of the application--as
> time goes by you get better at this testing... if it passes all this on
> multiple high speed machines testing for endless hours/days--you then
> release it for beta testing--if you have done the testing well, there
> will be few reports of errors from beta testers... then the computer
> illiterates get their turn...
>
Again, test cases are important, as they allow us to test for things we
already know about, and help keep changes from introducing regressions.
This is, however, only a tiny part of what good software management
practices help achieve.
Doing a modest amount of testing from the three classic QA contexts is
important:
1. 12-yr old hacker, who wants to break your app for a laugh.
2. Timid 80-yr old grandmother who may not comprehend your UI in any
typical manner, nor understand the underlying system enough to figure
out how to make your app work.
3. A monkey, who throws garbage and feces at your UI, occasionally
powering off the machine in a fit of anger.
At some point all the QA you want is not enough. There will always be
bugs that escape QA detection, and code reviews will likely not catch
those either.
Bob Spooner
Time To Failure (MTTF) rather than MTBF. The difference is because the bug
that causes the failure is already there waiting for the right conditions to
show itself rather than being caused by something breaking after having been
placed into service. Toward the end of it's operational life the MTTF for
IBM's OS360 operating system was on the order of 3000 years. That means that
if there were 3000 computer systems using it and they were in operation 24
hours a day seven days a week, a new bug was being detected only once a
year.
I don't think software reliability is valued very much these days. For those
selling software, time to market seems to be much more important than
reliability. For those buying it, price seems to be more important. That's
why we have to buy additional antivirus and spy detecting software to
protect our computers. A whole new software industry has grown up because we
don't require reliability in the software we use.
73,
Bob AD3K
"Reg Edwards" <g4fgq...@ZZZbtinternet.com> wrote in message
news:d81o4f$6gt$1...@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
John Smith
possible a "driver model" must be adopted, core code should always be
able to remain static and functioning independently in regards to these
hardware changes--in a perfect world...
With PC's movement between operating systems can be a bit more
difficult--movement to linux will generally be expensive in a windows
dominated world (most remaining mainframes have well developed
transitional models and is cheaply implemented), however since the
client obtained the OS for low cost (or no cost) they should be more
than able to shoulder the related expenses...
While microsoft has indeed adopted the 80 year old grandmother model you
have mentioned in your post--I always recommend ignoring her, some of us
prefer to always plan for the 15 year old hacker who gets lucky, and the
gorilla...
... your final protection always rests in insurance against claims made
by those who have been harmed in using your
code/application/utility/etc--and the contract/disclaimer for
such--which, as everyone knows, if you make it long enough will never
get read, so by all means, make them responsible for everything in its
text--personally, I am always tempted to make them responsible for acts
of God which may occur while they are using the software--guess that is
why they don't let me write them... <grin>
Warmest regards,
John
"clvrmnky" <clvrmnk...@coldmail.com.invalid> wrote in message
news:%m1pe.9115$5u4....@nnrp1.uunet.ca...
Richard Clark
wrote:
>A whole new software industry has grown up because we
>don't require reliability in the software we use.
Hi Bob,
That brings to mind a case that should be drawing to conclusion today,
or at least sometime this week here in Washington state.
It bears on the last election where the Republicans were content to
win with the will of the people when the ballot count showed they were
200 votes, or so, ahead. Out of 2 Million, that was a thin margin of
1% of 1%.
This close count provoked a law mandated, recount which swung the win
to the other column. We have a law that changes the method of
counting to hand, if a certain margin exists, and the losing side is
willing to pay the burden. The Republicans were no longer content
with the will of the people, they expressed they would be more content
with the will of a judge. Hence, the fellow I was working with
(literally) collecting ballots pressed a suit against the election as
being fraudulent. Time will tell if the Republicans will go fishing
for some other entity before whom they will pray for succor.
I won't go into how much they would have lost by if the ballots they
wanted cast out came to pass - they want to win in court, not by
ballot count.
Anyway, this response is directed towards software reliability and
voting machines. We had testimony (from the Industry at a panel
presentation at the League of Women Voters) that software was not 100%
reliable, and we could never hope for it to be 100% reliable. Another
Industry representative, this time credentialed and not selling a
voting system, offered that Bank software counts paper everyday to
exceedingly high precision and accuracy. Much better than current
voting systems.
The salesman hemmed and hawed, threw a hissy fit, and fumed back that
hand counting was not nearly as good as machine counting. By and
large this is true (never mind his software didn't hit the mark of
being even close). Hand counting error rates average about 3 - 5%.
Machine counting error rates average about 2 - 3%.
The election results and the first recount showed less than 1% error
and in fact both this and the last hand (second re-) count agreed
within 1% of 1%. 1% of 1% was not good enough, but no one is
suggesting we do this by hand next time when 2 - 3 % machines do it
better. Yeah, a contradiction on the face of it, but they only have
to convince 1 judge 51% instead of 48% (allowing for the boon of
machine error) of 2 Million people.
As some Republican wag on the floor of the House offered across the
aisle last November:
"No matter how hard you whip a dead horse, you are not going to
win the race."
It's remarkable to see them flogging the road through the flesh
stripped ribs of a carcass. I hope they can push it across the finish
line so I can see what they call a victory lap.
73's from the Soviet Republic of Washington
Richard Clark, KB7QHC
Roy Lewallen
> . . .
> Hand counting error rates average about 3 - 5%.
> Machine counting error rates average about 2 - 3%.
Surely I'm not the only one who wonders what counting method was used to
arrive at those numbers. It's tempting to imagine that the hand counting
results were checked by machine counting and vice-versa, then the
results thrown into some wonderful statistical equation to arrive at
those authoritative sounding numbers. . . or is there a hyperaccurate
Third Method that The Conspiracy is keeping secret from us?
Roy Lewallen, W7EL
Richard Clark
wrote:
>Richard Clark wrote:
>> . . .
>> Hand counting error rates average about 3 - 5%.
>> Machine counting error rates average about 2 - 3%.
>> . . .
>
>Surely I'm not the only one who wonders what counting method was used to
>arrive at those numbers.
Rather more mundane and prosaic methods, certainly. The Web is not
shy of content to satisfy your enquiry though.
> It's tempting to imagine that the hand counting
>results were checked by machine counting and vice-versa,
That is one way, and certainly this time was no exception - perhaps
versa-vice.
>then the
>results thrown into some wonderful statistical equation to arrive at
>those authoritative sounding numbers. . .
Authorities have agreed on the results, yes. Most wonderful,
statistical equations are as simple as SUM/NUMBER. Few, I imagine,
rarely pen "wonderful" to their work or methods. Myself, I would shy
from offering what you should accept as authoritative - especially
when the leading defendant in this case has praised my contributions
(as inconsequential as I might think that effort was in proportion).
>or is there a hyperaccurate
>Third Method that The Conspiracy is keeping secret from us?
Hi Roy,
Sorry, when the population daily suffers so much admitted fraud, I
hesitate to offer conspiracy theories that could scavenge up the
crumbs of neglected booty. Perhaps you may be thinking of the
Association for Computing Machinery (ACM). They only host about 8000
pages relative to voting machines. Among them you might find some
amplification of methods, personalities, and challenges to the numbers
I offer.
Dialogue and corrections are always accepted.
73's from a political hack
Richard Clark, KB7QHC
Reg Edwards
degree of accuracy just by repeating the counting process a number of
times.
It is reasonably assumed errors occur at random.
A comparison with a Hyperaccurate Third Method counting machine is not
required. It could not be trusted anyway.
----
Reg
==========================================
"Roy Lewallen" wrote
John Smith
" It could not be trusted anyway."
Sounds one of my "public servants" here--I have been highly suspicious
of george lately....
Warmest regards,
John
"Reg Edwards" <g4fgq...@ZZZbtinternet.com> wrote in message
news:d82lkn$av2$1...@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com...
John Smith
And then they want to go to electronic voting--makes you wonder who is
running the show? Might just end up being one guy with access to the
database... <grin>
Warmest regards,
John
"Cecil Moore" <w5...@hotmail.com> wrote in message
news:42a5b901$1...@spool9-west.superfeed.net...
> Bob Spooner wrote:
>> That's assuming that those doing (or controlling) the counting are
>> honest.
>> But unfortunately, honesty doesn't seem to be valued very highly
>> either.
>> There was an inner city Philadelphia precinct that had a 100% voter
>> turnout
>> during a recent presidential election...
>
> During the Lyndon B. Johnson senatorial election, some voters
> in Jim Wells County arose from their cemetery graves and
> voted for Johnson. Others registered to vote in alphabetical
> order. When Gov. Price Daniels showed up with the Texas
> Rangers, the court house had mysteriously burned down along
> with all the voting records and the rest is history.
> --
> 73, Cecil http://www.qsl.net/w5dxp
>
>
> ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet
> News==----
> http://www.newsfeeds.com The #1 Newsgroup Service in the World!
> >100,000 Newsgroups
> ---= East/West-Coast Server Farms - Total Privacy via Encryption =---