Ping John Larkin

Interesting. Clearly C and its derivatives are approaching obsolence. They were designed for solving relatively small problems, on resource-limited machines, authored by geniuses who hack maximally cryptic code and don't look back.

He argues for more OOP languages, where modules pass messages autonomously and presumably asynchronously.

How about this:

Completely the opposite, namely expressing programs not as procedures to be executed all over the place, but as point state machines.

I love state-machines, in programs or in hardware. They are forced to account for every possible system state, and, coded sensibly, have absolutely known, finite resource needs and can't crash. Modern C programming mostly reminds me of 1960's vintage async logic design, a tangled heap of gates, flipflops, one-shots, 555's, rc's, and delay lines, with no global clock in sight. The real screwups in modern logic design happen when signals cross clock domains.

Cool link. Thanks.

John

Just curious: Do you guys use VBA for instrument control?

"As long as you have clever agents, and can keep disagreeing with each other violently enough and slagging each other off in the popular press, you can keep yourselves on the gravy train for life. How does that sound?" [Deep Thought in "The Restaurant at the End of the Universe" by Douglas Adams]

Rule of thumb: any field with 'science' in the name isn't one. Computer science is driven by fashion and faction.

I like to use two kinds of languages: C++ when I have to do something big or fast, or need to talk to hardware, and some scripting language (preferably REXX) for everything else. I can program REXX about 20 times faster than C++, but it runs at least that much slower. That makes for useful tradeoffs. My big-iron clusterized electromagnetic simulator is written like that, with a parallellized simulation engine and a compiled postprocessor glued together by a script that also does the user interaction, file parsing, optimization, and so forth.

Cheers,

Phil Hobbs

You're Welcome.

But I'm not sure he "argues for more OOP languages". What I get is he shows that OOP means so many different things to so many different people. With the unstated Corollary "Does it mean anything at all?"

That last example he showed seemed to be another viewpoint like all the others.

Robert

I suppose not, since I don't know what VBA is. OK, what *is* VBA?

We program our test stands in PowerBasic, and run them under DOS. Our customers access our VME stuff at register level, with whatever software they like, and we don't supply applications or drivers.

We are considering doing a bunch of Ethernet and PoE instruments, so I suppose we'll have to use Windows or Linux at some point. The Windows versions of PowerBasic actually do TCP/IP and UDP sort of stuff very easily.

John

Visual Basic for Applications. It comes with MS-Office but most people don't know it's there, and until recently that included myself. It allows you to plop down control and display elements pretty quickly with a few mouse clicks. Most of the time it seems to be done in Excel. IOW Excel then becomes the user interface but with enough control surfaces placed on the screen you might not realize that at first glance. The pre-cooked control elements have the typical appearance of those in most Windows programs but you can alter them, including pics, logos etc.

Right-clicking onto one of those control surfaces brings up the basic editor. Now you can program the details, what you want it to do or display, when, and so on. Seems pretty slick for distributing a user interface with the equipment because the customer wouldn't have to load any executables, just load your Excel file and allow macros to run.

Intuilink from Agilent is an example of such an Excel user interface:

Don't know how VBA would fare there. RS232 is IMHO certainly not its strength. Been wrestling with it for a while but now a couple of customers called in more urgent stuff. So I'll get back to it later.

I like your thinking, Phil. If you ever get bored with REXX, Python is a somewhat more modern alternative you might enjoy.

Some of the very first programs I was ever paid to write were in REXX (at IBM, not surprisingly)... I'm always a little more hesitant to admit that most of the others back then were in Turbo Pascal. :-)

As with many somewhat more abstract techniques, OOP is one of those solutions that doesn't necessarily have a whole lot of appeal until you've solved the problems it tries to address in a non-OO fashion. I think this is the reason so many people who put "C++" on their resumes aren't *really* proper C++ programmers at all -- they've not yet been asked to solve any problem that benefitted *that much* from OOP.

You don't need much programming experience to see the value of, e.g., operator overloading, but stuff like inheritance/virtual functions is much better appreciated by programmers who have written, e.g., "command shell" type applications where they end up indexing an array of function pointers... at which point they remember, "Hey... vtable!" -- and the light goes on.

But you need a bit more experience to see the danger (reduced clarity). Too many programmers use overloading simply because they can; particularly those whose experience is mostly with code which they wrote themselves from scratch.

At least overloading normal operators isn't a bad as copy constructors or type converters, where you need to be paying very close attention to even notice that the function will be called.

I got a copy of VB about 12 years ago with my first W95 box. It's pretty spiffy. I haven't gotten into VBA, primarily because I don't know how to get started, and how the stuff in the program relates to the app.

But I do know that it will communicate with other programs, so, if it doesn't have a TCP socket built-in, then probably a little wrapper or daemon could take care of the comm; then your VBA could open it like a file or I/O device.

Cheers! Rich

Agreed; for beginners I think the advice to remove the default copy and conversion constructors is a good idea.

On a "regular PC" usually beginners ignoring that advice just suffer a little performance degradation that isn't noticeable. On an embedded system, it can be a much bigger problem due to the much more limited memory and CPU speed, of course.

If you must use VB, then may I suggest the free 'Express' version from Microsoft. Thats right, its 100% free and is also royalty free.

I wrote an excel spreadsheet for calculating results of a microwave ham radio contest I participate in every year. One of the things involved in the scoring is computing the distance between two points on the earth. If you want to do that pretty accurately it takes a bit of number crunching. I had that algorithm in C programs I wrote (adapted from others more knowledgeable.) Maybe there was a way to port that into excel without using VBA, but VBA certainly looked like the best way as I saw it.

Here's an example of one of the functions I added in VBA to my excel spreadsheet...

Wow.

Is that the charter for SED, or does it just sound like it should be?

If we can figure out how to make the 'gravy train' thing really happen, it would make a great charter. Any ideas?

Cheers,

Phil "wage slave" Hobbs

Nobody snipped-for-privacy@nowhere.com posted to sci.electronics.design:

I must admit that much of "programmer education" is writing trivial programs and espousing theoretical ideology with out practical context.

We do the dos/PB thing because it's very fast and almost realtime. Windows seems to steal fraction-of-a-second time slices whenever it feels like. PB is, unlike VB, a true compiler, so we can run useful 30 MHz FOR loops, or generate 100 usec pulses, or do serial i/o without timeouts. We can also directly address VME or PCI registers and i/o ports, and make PCI-bus BIOS calls. If you turn off the 18 Hz clock interrupt, or synchronize with it, you absolutely own the CPU. It does inline assembly, too. Pretty bare metal.

John

Then we are in the same boat. I can easily get my hands around new HW stuff. Had to dive really deep into lasers and optics for a recent assignment and it's working nicely now. But with programming I am having a very hard time. VBA has lots of potential but to make things actually work is tough for me. Got the virtual RS232 (via USB) working but it quits out of the blue, with all kinds of cryptic errors, most of them I don't have the foggiest what they mean. One day the new scope answers correctly, other days it doesn't. This includes a few hard freezes, meaning CTRL-ALT-DEL didn't do the trick. Had to push that big reset.

RS232 is weird. MS offers a mscomm32.ocx routine but it comes with severe licensing restrictions, meaning it cannot be used with all VBA versions that came with Office. Probably because Bill doesn't want us to. So I am using the API now, with mixed success. But heck, if it was too easy there would be no learning experience.

Interesting. Have to look for it. Is it better than the one in MS-Office?