On Sat, 16 Jun 2007 09:43:00 -0500, Tom Ring
wrote:

Any open source version(s) you would recommend? I may have to have a
look again.

Hi Tom,

I would like to say Trilogy, which is also a declarative language, but
long gone by nearly 20 years.

On the active front, there is XPCE/Prolog (google this) out of
Amsterdam. It appears to be the product of a one-man show and to my
mind suffers from what he thinks the language should be (and not what
it was). I suppose my attitude would be better if I could have read
the users manual which, unfortunately, mimics all the poorly written
user manuals that have come down the pike since PL/M.

73's
Richard Clark, KB7QHC

On Sat, 16 Jun 2007 00:13:37 -0700, John Smith I
wrote:
Example:

#include iostream

void helloworldprocedure(void)
{
cout "hello world!" endl;
}

void main(void)
{
helloworldprocedure();
}

... takes no parameters, returns none ...

Horrid examples of language, these are like the proverbial turds in
the punch bowl at a party.

I think most C programmers prefer to program in assembly (but with
windows allowing NO direct access of devices, peripherals, memory or
disk--why bother, assembly can only be used as a wrapper to call windows
libs/dlls/activex/scripts/etc., or custom ones--linux can be made to
allow direct access),

Most C programmers are Neanderthals with their skills frozen in the
70s. There is at least one Windows Assembler out there, it's free and
has been available for years from Steve Gibson at:
http://www.grc.com/smgassembly.htm
His executables perform network connections in file sizes of barely
more than 5K up to a massive 22K.

however, C adds a productivity factor of
magnitudes over assembly.

Bull Looney. This kind of syrupy rationale was composed to sooth the
nerves of Dilbert's pointy haired boss. It merely reveals that many
coders need training wheels to allow them to ride faster when
designers could have walked there in half the time.

C is NOT a user language.

73's
Richard Clark, KB7QHC

Richard Clark wrote:

...
C is NOT a user language.

73's
Richard Clark, KB7QHC

Quite obviously, you are not a software engineer ... even is someone is
willing to pay you for such.

JS

On Sat, 16 Jun 2007 13:46:59 -0700, John Smith I
wrote:
C is NOT a user language.

Quite obviously, you are not a software engineer ... even is someone is
willing to pay you for such.

:-)

73's
Richard Clark, KB7QHC

Richard Clark wrote:
On Sat, 16 Jun 2007 13:46:59 -0700, John Smith I
wrote:
C is NOT a user language.
Quite obviously, you are not a software engineer ... even is someone is
willing to pay you for such.

:-)

73's
Richard Clark, KB7QHC

Richard:

Ahhh, to wise to take the bait, huh? grin

Well, you are right, anyone who programs deserves respect, no matter the
language--sure beats being to lazy to learn something new ... a
scripting language is best for what was first implied--I lied. :-(

We only need steer the app ... I am like y'all, I prefer the command
line to the gui.

Warm regards,
JS

John Smith I wrote:

[stuff]

.... err, just for today, to = too :-)

JS

Richard Clark wrote:
On Sat, 16 Jun 2007 00:13:37 -0700, John Smith I
wrote:
Example:

#include iostream

void helloworldprocedure(void)
{
cout "hello world!" endl;
}

void main(void)
{
helloworldprocedure();
}

... takes no parameters, returns none ...

Horrid examples of language, these are like the proverbial turds in
the punch bowl at a party.

I think most C programmers prefer to program in assembly (but with
windows allowing NO direct access of devices, peripherals, memory or
disk--why bother, assembly can only be used as a wrapper to call windows
libs/dlls/activex/scripts/etc., or custom ones--linux can be made to
allow direct access),

Most C programmers are Neanderthals with their skills frozen in the
70s. There is at least one Windows Assembler out there, it's free and
has been available for years from Steve Gibson at:
http://www.grc.com/smgassembly.htm
His executables perform network connections in file sizes of barely
more than 5K up to a massive 22K.

however, C adds a productivity factor of
magnitudes over assembly.

Bull Looney. This kind of syrupy rationale was composed to sooth the
nerves of Dilbert's pointy haired boss. It merely reveals that many
coders need training wheels to allow them to ride faster when
designers could have walked there in half the time.

C is NOT a user language.

73's
Richard Clark, KB7QHC

Richard

You may not like C programmers in general. However, some of us document
our code (my "code" is probably 80% comments) and don't declare
(assuming they declare at all) our functions as void. Unless they
really are. Sorry about the sentence structure there, I am very tired,
and also watching F1 qualifying at the same time. CPU idle time
nonexistent.

tom
K0TAR

Tom Ring wrote:

...
our code (my "code" is probably 80% comments) and don't declare
(assuming they declare at all) our functions as void. Unless they
...
tom
K0TAR

I certainly would not go about bragging in that style, dead sign of lack
of structure/logic in the code leading to obfuscation and requiring
extraordinary effort of documentation ...

The comments in source are only meant for other programmers, they
already know how to program, you don't have to teach 'em, nor attempt to
impress them with your brilliance--if such is present--they'll know.

With the proper use of significant names for variables, structs,
defines, etc. and programming for a "logical flow" of code, few comments
are needed (approx. 10-20% comments should be more than sufficient--if
the source is structured and non-obfuscated.)

Krist, they pay me to engineer software, not write books ... (if
management had their way--they'd screw that up ...)

SIMPLIFIED EXAMPLE:
// call at any point to debug/check variables
(void) debug_printout_of_variables_used(float whip_self-capacitance_pf,
float coil_self-capacitance_pf,
float coil_inductance_uh,
...)
{
cout "Whip self capacitance (pf): " whip_self-capacitance_pf
endl;
cout ...
...
}

JS

On Sat, 16 Jun 2007 21:19:57 -0500, Tom Ring
wrote:

You may not like C programmers in general. However, some of us document
our code (my "code" is probably 80% comments) and don't declare
(assuming they declare at all) our functions as void. Unless they
really are. Sorry about the sentence structure there, I am very tired,
and also watching F1 qualifying at the same time. CPU idle time
nonexistent.

Hi Tom,

Documenting code (any language, and even more so for "self
documenting" languages) is a necessary talent, and the first casualty
often abandoned to schedule.

This has nothing to do with "liking" C programmers in general;
however, C as a language is wholly inappropriate for a user's
interface to antenna design engines. The intersection of C
programmers and Antenna designers is so marginal that the focus on C
is six sigma to the left of the bell curve (and, of course, these
comments can be extended to assembler).

I've designed parsers and compilers - no easy chore certainly - and I
have enough experience in the matter to know that expressing the
user's need in BNF and pushing it through YACC would present something
vastly better than C; with the libraries stripped out, is nothing more
than simple conditionals and loops (and again, since the assembler set
for the 80x86, ASM could do that just as well). C programmers'
fluency through brute force attention does not elevate these opaque
libraries' troglodyte style.

With the advent of C++, things only got worse. I was doing that in
the late 80s and when Java came along, I jettisoned that baggage.

73's
Richard Clark, KB7QHC

Richard Clark wrote:

[stuff]

Richard Clark, KB7QHC

Richard,

Yes, a simplified script language to feed the logic in the app from the
commandline and a backup gui for those desiring it would be most
appreciated by those having to learn it and use the app ...

C programmers will participate by writing the app ... :-)

Regards,
JS