Programming choice

For someone who has a significant background in electrical engineering (as you do), the best language is probably C or C++.

That which drives programmers to to other languages has more to personal predisposition than relative merit of the languages. For example, there is nothing wrong with using Laplace transforms to analyze linear circuits, but there are some people whou would swear that Laplace transforms are busted, and hunt in vain for something simpler that lets them get all the benefits of Laplace transforms without performing any complex manipulation or polynomial factoring. This difference in perspective has been raging non-stop since Java was born about a decade after C++ in the mid-1990s, so if someone tries to convince you that Java is better, you should pay more attention to their personal predisposition than the content of what they are saying

- without insight that can only be gained after years of using multiple languages, the former will reveal truth more quickly than the latter.

Between C and C++, I would use C++, as it is a superset of C, but herein lies another problem. Within the C++ community, there are many different styles of programming, so you have be weary of libraries that you download off the net. Some of them are good. Some of them are bad. In general, most people think what they make is good (i'd say

99%). Software engineers (the professional one's) are far more sloppy in their thinking/design than EE's, IMO. If they make a board that overheats in one region because layout was just bad, their first instinct, often, is to go hunting for an active cooling component to slap on hot spot than to redo the layout. The space of creativity in this area is HUGELY WIDE OPEN, despite claims of "best practice." To anyone who knows just how much waste and bad design goes on in software development and get away with it, it should come as no suprise that richest man in the world made his billions in software.

Currently, the Textronix CSA7404B of Integrated development Environments is Microsoft Visual Studio 2005. The Professional version of this software is not cheap (few hundred bucks), so they have a free, downloadable Express version which is *more than enough* to develop sinficant applications, though you will have to get the non-free package if you want the IDE to assist you in doing things like making icons and helping do buttons and such. You can still do these things by hand (without help of IDE), but it will be tedious.

MFC is Microsoft's first, public, significant "forward" (cough) migration from C to C++. It is an abomination as far as good C++ design goes. I would say many expert C++ MFC users have agreed to this, but they use it anyway. If you want to protect your "how I think" , stay away from it, at least initially. My own preference has been to continue using the C interface they provide to Windows, as the MFC is so ugly, I'd rather have raw-and-ugly than fat-but-still-ugly.

Stay away from C#. It is the latest in a serious of Microsoft lies to try to accomplish several things at once that would hugely benefity their market dominance:

  1. Kill Java, or disable it.
  2. Get programmers to stop writing code that is too portable for comfort (in C++)
  3. Provide a platform that will lock in programmers so that when Microsoft decides to make heavy pushes to Linux/Unix, they still control the software budgets of the customers who made transition, as all the software will require engine sold by Microsoft.
  4. Alleviate the problem of supplying multiple libraries in multiple spoken languages and multiple written languages even though the matrix of libraries do the same thing (put list box on screen for example). With the .NET crap, and C#, this dream of their's is closer to reality. The only drawback is that it comes with a giant diaper to garbage collect all the crap that is made by programmers who were lead into thinking that they no longer have to think about memory management. This is why C# is so popular, To get my to my Laplace transform example

- memory management is the one area where many, many programers bitten in their trek through the programming land, so they want to believe that there is a silver bullet to let them not think about it. But in fact, there is none, yet the need to believe there is so strong, everytime a language comes out and purports "with us, you don't have to think about memory management!!!' you get probably 5-10% of the eyeballs automatically.

To summarize, C or C++, Microsoft Visual Studio Express, no C# or .NET.

formatting link

Note that you *have* to download the Platform SDK and you will have to tweak the IDE to get it work for writing Windows apps (they explain this after you install theh IDE).

-Le Chaud Lapin-

Reply to
Le Chaud Lapin
Loading thread data ...

I did a couple of TCP/IP apps using PowerBasic's Console Compiler. It was amazing... stuff like

LINE INPUT "enter IP address : "; IP$

TCP OPEN PORT 2000 AT IP$ AS # 1 TIMEOUT 500

and

TCP PRINT #1, "Hello"

and it compiles into a single, clean .EXE file. Windows only, though.

John

Reply to
John Larkin

received

cross

Pick the one you're the most comfortable with. This is the kind of thing that could be done in perl, for heaven's sakes. Accumulate some data?

The only hard part will be the editing, unless it's textual data, in which case it's trivial - most of the GUI development systems I've used have a "text box" widget; you could still use one of those even if you're editing hex data, by editing it in ASCII and reconglomerating it.

Bottom line, it doesn't make any difference.

If you've never been a programmer before, then, probably, I'd recommend BASIC.

Good Luck! Rich

Reply to
Rich Grise

At some point I have to write a recording and editing package for data received across TCP/IP (or UDP). The idea is that I get the data via TCP/IP, record it, edit it and then play it back out again. There will be significant graphics involved.

The editing computer is likely to be a PC, although I would like it to be cross platform.

The only realistic options seem to be Windows programming or using Java. If the former, what programming tools are best? C++/MFC, C# Visual C++ etc? If the latter, any recommendations?

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org
Reply to
Dirk Bruere at Neopax

You could consider some of the open-source stuff that is currently around, rather than re-invent the wheel. Check out libpcap, ethereal, tcpreplay for example.

(I use ethereal & tcpreplay to capture & replay packets, though I don't edit)

TCM

Reply to
The Cheese Machine

received

cross

You are asking in the wrong place.

IMO java makes more sense if you want cross-platform compatibility, although there is also gtk and wxWindows.

For java you can use the eclipse development environment, and if you want, you can even use SWT (part of eclipse) instead of Sun's AWT or SWING. But that is a religious issue, so be careful soliciting opinions. ;-)

Nowadays it is also possible to compile java to native code for various platforms.

--Mac

Reply to
Mac

received

cross

I know. Problem is that this decision is going to have major ramifications for years to come (assuming the company survives that long). So I have to get it as right as possible.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org
Reply to
Dirk Bruere at Neopax

Thanks. I've previously done a detailed graphical interface so I'm familiar with MFC and Studio. I've also done some Java programming a few years ago. However, I have no idea how necessary a cross platform solution really is. Doing a rewrite for Linux and the Mac would be a nightmare.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org
Reply to
Dirk Bruere at Neopax

wxWidgets?

--

John Devereux
Reply to
John Devereux

Haven't heard of that, but it looks interesting...

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org
Reply to
Dirk Bruere at Neopax

Dirk, if you're not yet comfortable with the tools of your choices on either system, forget about it, it takes far to long to become comfortable with something new. Get someone else to do this job for you.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
Reply to
Rene Tschaggelar

received

it,

graphics

Yes .... aaand .....????

Lots of things can grab/record/edit/dispaly "data" - someone might even have written some of the components already. For example RRDTool is a database for time-series data, that *might* be useful, depending on many things.

What kind of data?

Does it need to be processed, not just stored, in real time?

Does it need to be displayed in real time?

How much time do you have?

cross

Like Linux PC v.s. Windows PC? EBCDIC ;-)

Bletch!! Combining a broken platform and a lame language loved only by computer scientists ;-). Python, OTOH, works wery well even on windows (see later).

The problem with Windows is that there is no real support for scripting. That sort of stops you from "gluing" a prototype up from a bunch of already-made/almost-there command-line applications and forces you to hack up the entire thing.

etc?

IMO C++ has all the diseases of C wrapped in additional layers of C++ cruftiness and complexity. Not good.

The only time *I* use C++ is in "Rose Realtime" - where C++ is the intermediate format of a project, generated during the build ;-). C# is Microsoft Only, thus not worth learning because any Microsoft technology will go away as soon as the revenue stream derived from it declines. Unless one is a virus vriter, of course.

Python will be *way* cleaner and easier than any of those!! Python + wxWindows delivers the portability today that Java keep talking about. (see

formatting link
SciPy has loads of numeric functions e.t.c.

Python developers tend to be a pragmatic bunch: Meaning that most of the Python libraries that are available for Linux/Unix have real Windows ports with proper Windows install packages. So the code can spread more.

Reply to
Frithiof Andreas Jensen

...

Then, duh. Just pick a language you like. If you have access to a Linux platform, then it's even easier - this is the sort of thing you could write in a shell script, for pity's sakes! ;-)

Contact closures and position feedback stuff, I'd probably go for "C", just the plain vanilla kind, at least for the guts - there are all kinds of GUI development things on Linux. To go to C++, you'd have to define what your objects are, its properties and what it can do, and all that stuff, but I'm really not a programmer tutor, except that one time that hot babe asked me to tutor her in COBOL, but it turned out she just wanted to get into my knickers.

She did. ;-P

Cheers! Rich

Reply to
Rich Grise, but drunk

Series of positions for actuators. Think animatronics.

No. Offline editing.

Lots.

Linux, Mac, Windows.

The + is that I know it well.

OK

I'll check it out.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org
Reply to
Dirk Bruere at Neopax

Actually, think multiple channels. I need to record one channel while playing others back. Then do an edit.

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org
Reply to
Dirk Bruere at Neopax

I am already thinking: "Text file", XML-format probably for info on graph such as channel number, scaling and stuff + a Parser to convert track into scheduler commands right around here. I am almost thinking "$make Movement" on a set of files for ultimate crudeness ;-)

A text format and parsing engine will be an "easy" "core" to work with I.M.O. Once *that* works, the Scheduler, Sampler, Editor, and the Grapher can be glued on.

The trick to software I.M.O is to get something working very quickly - even if it is crude, stupid, vile and "inefficient" - and then keep learning from using it and refining it until one runs out of time or it is good enough.

For longer sequence times and more fancy graphs, maybe RRDTool could handle the data storage part:

formatting link

The thing I like about RRDTool, apart from the ease of storing time-series data, is that there are many different API'sw for it so that one is not bound to one particular programming language. Graphing of data are "for free" too.

The disadvantage is that samples must be regularily spaced. I do not know how fast RRDTool is - it should be much faster than SQL - but ... maybe not fast enough to do without buffering + "rescheduling" in which case SQL (for better queries) or even text files can work too (to get something up quickly).

Maybe "Audacity" is even closer to what you want.

formatting link

RRDTool at least have a query format. SQL of course does.

There is never enough ;-)

be

Should be Ok these days.

That is a distinct advantage ;-)

(see

Another useful thing is XML-RPC;

It makes it easier to split applications in an "Engine part" and a Display Part. So the Engine might be C++ because you know that already and the GUI can be something entirely different. Because of the clean split, test drivers can be written for both components.

Reply to
Frithiof Andreas Jensen

Have you considered REXX? One package I've seen advertised claims:

BRexx is the fastest Rexx interpreter. It has a tiny footprint and runs on Windows CE, as well as Windows, Unix, Linux, Mac OS X, DOS, AmigaOS, ...

I use eCS-OS/2 and both REXX and Object REXX are available. I would appear that it is possibly about as cross platform as you can get.

Ted

Reply to
Ted Edwards

If you've used MFC, consider wxWindows and C++. Apparently it bears a lot of similarities with MFC, at least in the way it is built up, but it is fully cross-platform and free. Personally, I'd go for python and wxPython.

Reply to
David Brown

Reply to
Pat Ford

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.