Connect with us

Programming choice

Discussion in 'Electronic Design' started by Dirk Bruere at Neopax, Dec 4, 2005.

Scroll to continue with content
  1. 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

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

    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?


    The Consensus:-
    The political party for the new millenium
  2. 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

  3. 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.

    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-
  4. John  Larkin

    John Larkin Guest

    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


    TCP PRINT #1, "Hello"

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

  5. 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


    The Consensus:-
    The political party for the new millenium
  6. 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.


    The Consensus:-
    The political party for the new millenium
  7. wxWidgets?
  8. Haven't heard of that, but it looks interesting...


    The Consensus:-
    The political party for the new millenium
  9. Rich Grise

    Rich Grise Guest

    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

    Good Luck!
  10. Mac

    Mac Guest

    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

  11. 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.

  12. 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?
    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

    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.

    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 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.
  13. Series of positions for actuators.
    Think animatronics.
    No. Offline editing.
    Linux, Mac, Windows.

    The + is that I know it well.
    I'll check it out.

    The Consensus:-
    The political party for the new millenium
  14. Actually, think multiple channels.
    I need to record one channel while playing others back.
    Then do an edit.


    The Consensus:-
    The political party for the new millenium
  15. 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


  16. 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:

    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

    Maybe "Audacity" is even closer to what you want.
    RRDTool at least have a query format. SQL of course does.
    There is never enough ;-)
    Should be Ok these days.
    That is a distinct advantage ;-)
    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.
  17. Ted Edwards

    Ted Edwards Guest

    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.

  18. David Brown

    David Brown Guest

    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
  19. Pat Ford

    Pat Ford Guest

    Also look at QT from trolltech
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day