Well it's not the language choice, it's all the helper programs that are
version locked that annoy me most. Python is in a weird state of limbo
right now with the version 3 switchover. Many systems are defaulting to
python 3 and we should probably do the same. Python would work great if I
was just putting together an FM radio by connecting blocks, but for any
more computational advanced program I would want to switch to C++. GNUradio
is almost catered to Pyhton, this should not be the case, it should be
modular so I can call it from any scripting language or GRC. For just
connecting blocks Python has way too much overhead, a simpler scripting
environment would suffice. Then for more advance programs you almost have
to switch to C++. Take usrp_spectrum_sence for example, this program has
it's own block ( bin_statistics ) that has no use other than basically
being the heart of usrp_spectrum_sence, it just shows python isn't up to
the task of real DSP work beyond just connecting real C++ code. Whats
needed is a common block connecting API that can be run directly from GRC
without using python as an intermediary. Without the need for python/swig
we eliminate a great deal of version locking and system incompatibility.
On Fri, Dec 30, 2011 at 3:45 PM, Marcus D. Leech <mle...@ripnet.com> wrote:
> Very true, all of it, GNUradio is quite the hodgepodge of different APIs,
>> Languages, and Ideas.
>> And that's not always a bad thing, it can allow great flexibility, but
>> sadly it is currently doing the opposite. With required versions of SWIG,
>> Python 2.x/3.x and other helper programs it ONLY compiles reliably on
>> ubuntu and fedora, and only Ubuntu, not kubuntu or Xubuntu as the small
>> differences in GTK versions break most of wxgui. I am also a die-hard
>> FreeBSD user forced into Ubuntu as no other operating system can compile
>> GNUradio since 3.2. OK sorry for the rant.
>>
> See my earlier rant about "shoulders of giants".
>
> I think that what happens for *some* people is that Gnu Radio isn't
> written using their programming language/paradigm of choice.
> To *them* it's "obvious it should have been written in
> {C,C++,Ruby,Java,Fortran,**Pascal,Erlang,Cobol} and I can't understand why
> these Gnu Radio idiots picked Python/C++". I admit that back in 2005,
> when I first started using Gnu Radio, I was resentful of
> the choice of Python/C++. Two languages that I was ill-prepared for. I
> spend most of my professional life coding in C, with
> occasional excursions into C++. Gnu Radio forced me to learn enough
> Python to get by. Now, I love it. I find that I'm much more
> likely to write a "throw away" program in Python than C these days, and
> I've been a C programmer since 1979! I taught my son
> Python when he was 8. He still loves it at nearly-14, and even taught
> Python to his class-mates when he was at a private school.
>
> With the advent of GRC, you don't even have to know Python or C++ to
> accomplish a great deal of stuff. If the "plugging lego together"
> paradigm isn't "natural" or is too restricting, you can always program in
> a soup of Python and C++. It's all doable.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> ______________________________**_________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
