[aprssig] Rant - Cross platform portability
Jim Lux
jimlux at earthlink.net
Sun Sep 17 17:31:22 EDT 2006
Gregg makes some comments about the availability of software for a
variety of environments, and that triggers some comments about
software development, not necessarily directed at Gregg personally,
but at a general misunderstanding of how and why software gets developed.
The primary thing to remember is that software development is not
free. The developer has to get paid somehow, either in psychic
satisfaction or in cold hard cash. (love or money, as the saying
goes) If it's the latter, it's easy.. he who pays the piper calls the
tune. The piper payers have varying motivations, which will drive
what tune they call, be it platform independence, or Windows for all.
It's the former form of payment, psychic satisfaction, that's a bit
more problematic. The satisfaction often derives from "scratching an
itch", and that itch might not include learning a new toolchain or
providing platform independence. The challenge, if you're funding it
from altruism, is in finding someone for who "the itch" is,
simultaneously, the desire for platform independence AND whatever
function you want to perform. Except for the most trivial of needs,
this is a tough hurdle to surmount.
Remember, if it were easy to do, it would have already been done, so
the going in assumption is that the functions you want are
non-trivial and will require some non-trivial amount of work to get them done.
About which more, later.
Gregg Wonderly wrote, in response to some posts about Airmail, a
Winlink interface program:
I've argued with them about making the choice to write windows only software.
In this day and age, there is absolutely no reason to do that. There are many
different common GUI libraries for the C language that make multi OS
programming
possible. There is also Java, which makes it extremely trivial to write "runs
everywhere" software, with zero porting work. I created a project at
http://openlink.dev.java.net where I started by recreating the
airmail UI. It's
still pretty bare, because I just have too many other things going on. But,
anyone who can do the work of filling in the actions, can take the
GUI that I've
created and go at it.
It should be possible to create a very viable PSK implementation in Java.
However, right now, all the DSP work seems to be focused on windows
or C/x86-asm
environments. That is such a shame to see all that work not supporting the
whole amatuer radio service.
---
While the sentiments expressed by Gregg are wonderful, there's a
fairly big gap in the ability to do "write once, run everywhere"
software, except for the most trivial of applications. Web browsers
are about the closest thing that you see, and you'll note that there
are numerous incompatibilities, even with fairly simple HTML. There
are also "market realities" to consider, some of which I touched on initially.
But to take in specifics:
"I've argued with them about making the choice to write windows only software.
In this day and age, there is absolutely no reason to do that."
-- Sure there is..some very good reasons, especially if your
developers are doing it for free. Windows development tools (Visual
Studio) make it very easy and quick to generate Windows applications
that run perfectly well on Windows platforms, especially if you need
tight integration to some Windows specific functionality (e.g.
Windows Media Player). There are very, very few people who get *paid*
to develop amateur radio software, so the population of programmers
doing such work is likely to get paid to develop to meet some other
needs (i.e. cranking out mods to that payroll system at work, etc.),
and, because of the dominance of Windows, the odds are that
programmer is programming for windows. If I spend my 10 hours a day
toiling at work in the Windows development environment, when I turn
to my unpaid amateur radio efforts, I might naturally select to work
in the environment within which life is easiest. If you're paying the
developers, then you'd pick whatever gives you the most bang for the
buck, and that's "Windows everywhere".
Yes, there are cross platform tools, but they are *different* than
the Windows tools I'm familiar with. So now, to generate that
wonderful amateur radio software, I have to not only invest the time
in the actual programming, but I have to learn a new toolchain and
all of it's peculiarities. This is nontrivial, especially since many
of the alternate toolchains come from the Free/Open Source Software
environment, many adherents of which equate the use of MSWin in any
form with a sin on a par with burning a orphanage to the
ground. Many of the alternate toolchains seem to go out of their way
to either implement interfaces and conceptual models that are
"different than Windoze, because we all *know* windoze sux" or,
alternately, "Make Windows look like Linux". This is fine if you are
a Linux developer who wants to get something working in the Windows
environment, but is truly a pain if you are a Windows
developer. Oddly, the Linux crowd has not come up with packages to
"make Linux look like Windows", probably because it would be reviled
as "giving aid and comfort to the enemy". Since the programmer
population follows the installed base, guess which conceptual model
your would-be amateur radio programmer is more familiar with?
----
"There are many different common GUI libraries for the C language
that make multi OS programming
possible."
>> Possible, but not easy. Use that common library and you might
give up some really useful features of the Windows GDI. Sure, if you
want to work in text mode, almost anything works, but most users
demand more flash than that. Likewise, if you're willing to take the
performance hit to work in X-Windows or OpenGL, you can use
that. Many of these libraries also have a different user interaction
model than Windows (because, perhaps, they come from a different
environment: Unix, Mac, etc.). Then, you have a problem that the
users (who ultimately will determine the success of your product)
tend to be Windows users (based on statistics of what OS is running
on most computers), and the X, Y, or Z model of user interaction is
different than the Windows model, so you've basically pushed the
learning curve problem from the few software developers to the many
users. On purely economic terms, this is bound to fail.
---
"There is also Java, which makes it extremely trivial to write "runs
everywhere" software, with zero porting work. I created a project at
http://openlink.dev.java.net where I started by recreating the
airmail UI. It's
still pretty bare, because I just have too many other things going on. But,
anyone who can do the work of filling in the actions, can take the
GUI that I've
created and go at it."
Java makes portability trivial only for trivial applications. "Zero
porting work" is a pipe dream for most applications. There are
several JREs out there, and they're not all compatible with each
other, as much as Sun would wish it were not so. Java does make it
easier, but at some non-zero cost for processing resources. Java
also requires learning a new language which is very different from
traditional C. As you yourself say, "I started by recreating...
pretty bare, because I have too many other things going on"... The
same is true for everyone else. Getting the initial framework in and
working IS trivial. Getting all the grotty little details is
not. It's a lot of time consuming work. People write amateur radio
software as a labor of love, and that love tends to fizzle when it's
tedious and boring.
Your best bet for a Java implementation would be to find someone who
develops Java stuff for a living (therefore they are facile in that
environment) and who is also motivated to take on a large development
task for the benefit of Amateur Radio.
---
"It should be possible to create a very viable PSK implementation in Java.
However, right now, all the DSP work seems to be focused on windows
or C/x86-asm
environments. That is such a shame to see all that work not supporting the
whole amatuer radio service."
Java is not known for high performance computing applications. Sure,
there are Java compilers out there, but they don't generate code with
the performance of straight C, FORTRAN, or ASM code. DSP developers
are always trying to eke out the last percent of performance
(because, in their day job, they're cursed with trying to get 10
pounds of processing into a 5 pound CPU speed sack), so, at least for
production purposes, they tend to gravitate towards languages which
get them "close to the hardware" with a minimum of abstraction. Many
DSP applications are latency sensitive, and things like asynchronous
garbage collection just cause fits and starts for a developer. Sure,
with modern computers, you can just "overpower" the problem by making
sure there's plenty of spare CPU cycles, so you don't care what else
is going on. However, the folks developing your DSP algorithms most
likely come from an environment where this is not the case, and
again, you're in the situation where the people with the domain
specific knowledge prefer to work in an environment that is not, for
instance, Java.
As a practical matter, there's a fair amount of DSP code being
written these days in tools like Matlab/Simulink, which can then
generate C, which can then be compiled for your target. I don't know
how many different targets are available, and how compatible they are
among platforms. Probably not very.
---
And, contrary to Gregg's assertion, all that work (albeit for C/x86
asm) DOES support the whole Amateur Service... Much of the software
developed for amateur uses is Open Source.. yes, the design
documentation may be a bit sketchy, and the code not commented as
well as one might want. However, it's there to look at, and if an
ambitious amateur wishes to implement the function in a different
target environment, they've got a big leg-up on doing it from scratch.
It all comes down to development resources. Software development
isn't free. The developer has to get paid, either in psychic
satisfaction or in cold hard cash. If you have a pile of cash, you
can have the developer develop for whatever environment you wish, be
it some proprietary closed one (Windows) or some cross platform
portable nirvana. If you don't have cash, you can rely on persuasion
and appeals to altruism, although, as has oft been pointed out:
persuasion doesn't pay the rent. With sufficient resources, one can
even overcome the inevitable limitations imposed by the increased
abstraction inherent in cross platform portable solutions.
Consider this question: "How much would *you* be willing to pay for
cross platform compatibility?"
Gregg said he'd like it, but isn't willing to pay very much: "because
I just have too many other things going on". Clearly, he's not
willing to spend a lot of money or time to get there. He's willing
to express an opinion, and cast out a hope that through the kindness
of strangers, he can get what he'd like. That's great, because it's
what amateur radio is based on. Many hams have contributed mightily
to the fund of common knowledge, to the betterment of all of us (the
fact that it's also part of why you get to play with that valuable RF
spectrum for free, and relatively unfettered by regulatory oversight,
is also in there too). But, wishes won't get the job done.
Let's say that it would take a programmer, skilled in Java, about
2000 hours (one work year) to build a workable PSK31 application,
including learning the DSP stuff. (or alternately, to get a DSP
person to learn Java and figure out how to do it in a somewhat DSP
peculiar environment) That's only about $250K, if you bought their
time retail. You could probably find someone willing to do it for
half that, on the side, if you're willing to wait a couple years for
it (hey, they have their full time day job to pay the rent).
How many of you would be willing to fork out a proportionate share of
that $120K, for something that will be delivered in 2 years, that
might not actually do what YOU want it to do. Think there's a 1000
people willing to send in a check, tomorrow, for $120? Nope.. don't think so.
But that's essentially what Gregg (and many others like him) are
really asking... "Please, spend lots of YOUR time, so *I* can get
what *I* think would be a boon to society". I, like Gregg, think
cross platform interoperability would be wonderful. However, I'm
not willing to invest ANY time in achieving it. I've got enough
development problems for ham radio applications in the environments I
know to occupy ALL of my spare time (and then some). I'm willing to
design my own stuff so that it's, at least, not "cross platform
hostile", but, when push comes to shove, and I need to use some sort
of funky Windows specific feature to get what *I* want to get done,
done, I'm going to do it, because my "itch" isn't universal
acceptance, but getting my problem solved.
Now, if someone has a bunch o'spare cash lying around (it happens...
Paul Allen has enough cash lying around to build a arrayed radio
telescope costing 10s of million dollars, without a heck of a lot of
financial return to be expected, just out of curiosity.), they're
free to fund someone (or someone(s)) to develop all sorts of cool ham
radio oriented software that's platform independent and high
performance, etc. And, we'll all benefit from that person's altruism.
Cynically,
Jim, W6RMK
More information about the aprssig
mailing list