G'day, "Ken Roberts" & all;
"Ken Roberts" <forums@[EMAIL PROTECTED]
> wrote in message
news:1187821910.419985.74520@[EMAIL PROTECTED]
> In most cases, I think it's a waste of time to find the perfect
> language for an application. There are usually a handful of good
> choices. Once you learned a few languages, you start to pull common
> approaches out. In your case, you want to program your SBC. You'll
Yep. Well said.
> only have a few choices once you've picked the platform. I suggest
Only too true!
....
>> C & C++ are high-level languages that provide many conceptual elements
>> that
>> can be of enormous advantage. They can also obfuscate the underlying
>> nature
>> of the target processor. In "the old days", that was a real drag. But
>> with
>> today's fast processors and large memory availability, it's not nearly
>> such
>> a big deal anymore.
>
> Not exactly. C is a low-level language, specifically it resides at
> level 1, where most modern languages are at 3 or 4.
Okay, true enough. Considering that I cut my teeth programming at the
front-panel of your basic Data General Nova (Jumbo--17 slot) and then
moved
on "up" to assembly...I call C 'high-level'. But you're right...it's not
by
today's standards. Cricky! Ya get outta programming for a few years and
right away all of the rules change...(:-o)!
> Part of the difficulties people have with C is that there is very weak
> typing, which means you can have part of your program write a number
> and another part read it as text, or as absolutely anything else you
> might imagine. Some of those non-conversions are safe because the
> programmer may know it's happening. Others might be disastrous.
Well said.
....
> C was designed around Unix, and it is used to define most Unix-like
> operating systems. It's a very good language for creating an
> operating system, but not necessarily a good one for creating an end-
> user application.
That would depend a bit on the "end-user application", I would think.
> It would make a very good SBC language, but you may
> not want to deal with it because of the difficulties in learning it.
Yep. It can. But that becomes a function of the quality of the
implementation by the compiler vendor on the target chip. Having sold a
few
of them, I've found that to be true across the board. But, as you'd
pointed
out earlier...times are a-changin'. There are, however, some 'C'
compilers
that do a damn fine job of working with small processors. The made a few
extensions to the language and it wrote code as good as or better than
what
I could do by hand. While a good compiler--on a good day--could make code
that was equal to mine in size and speed, what it really excelled at was
doing it fast! I coded a traffic light application in C in about
7-hours...replacing the code that someone had written in assembly that
took
nearly 6-weeks. I guess they call that progress...
> C++ was designed by Bjarne Stroustrup for use by Bjarne Stroustrup.
Yeah. Heard that. But I learned my "C" at the knee of a fellow named
Stephen Johnson, who (as I understood his recollections) wrote "YACC" in
response to Brian Kernighan & Dennis Ritchie's progress in developing the
language later called 'C'; so you'll need to write slow so that us old
guys
can keep up...(:-o)! In any event, as programming methodologies and
languages matured, C++ somehow got selected to become the more object
oriented extension of "plain" old 'C'. I always thought it was a rather
poor outcome, and only sup****ted it cuz so many of my customers insisted
on
it...
....
> C++ is not a difficult language to learn, if that's what you start
> with. A modern IDE will take care of a lot of the underlying
> plumbing. The problem with C++ is making absolutely sure that what
> you're typing is a reflection of what you're thinking.
So very true!
Okay, so much for that. My experience is with missiles, spacecraft, and
aircraft instrumentation (troubleshooting, fixing, & maintaining; and
later
in Cat II flight testing at Eddy's airplane patch in the Mojave); as well
as
writing and peddling a variety of software applications and development
tool
set for a variety of embedded devices ranging from torpedoes through
modems,
medical devices, power & energy monitors, precision measurements of all
kinds, to interplanetary rovers. As a pilot I've used many different
kinds
of instrumentation. The idea that Dan brought out for a compact, ****table
MFD is excellent and triggers just about all of my buttons. I can build
this thing! But without an idea of what is:
1) Necessary (read: critical)
2) Nice to Have (read: not critical)
3) Fluff that adds little to the pilots reference frame (read: fun
gadgets
& gimme's)
....this will be a tough order to fill. My experience in hovering isn't
nearly on par with any of you reading here (but I'm in the process of
changing that...(:-o)!). So, would someone like to take the lead in
starting a list of features you'd like to see in such a device? I'll be
happy to volunteer myself to be the caretaker of that list...unless
someone
else wants to do that.
With the entire sound to explore out here (PNW), I plan on "going places"
in
relative comfort with mine, I'll start with:
Compass rose
Course and deviation bar
Heading bug
Speed
Map overlay
Radar overlay
Wind (apparent) speed and heading
Tach
Temps
Oil Press
Torque
EGT
MAP
Electrical
If I've left something out, please add it. If I've included something
stupid, delete it...
L8r all,
Dusty -- Everett, Wa.
|
