|
From: | Marcus D. Leech |
Subject: | Re: Stop making unneeded improvements |
Date: | Thu, 07 Jan 2021 16:51:47 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
On 01/07/2021 03:32 PM, paul@dbnut.com
wrote:
Prompted to write by Glen Langston's post, I'm an old man resurrecting an old moan, and in a minority that (I believe) is just not catered for:It was NEVER a goal of GR to make it easy for those without skills in programming, radio, and DSP to be successful despite those handicaps. There has been a growing perception that GR is "just a radio with a lot of knobs". It isn't. It's a programming environment for a highly-specialized discipline, notably signal processing. GRC has had the unfortunate side-effect of making GR seem like "a radio with a lot of knobs", and certainly if that's your perception of what GR is, then GRC will fall fare short of that goal. If you expect to be brilliantly successful despite a lack of the requisite skills, and blame the *tools* for your lack of success, then you should perhaps take a breath and re-think your position. I liken this attitude to some rich fool buying an A320, taking himself and his closest friends up in it for a maiden flight, only to be disappointed that he and his friends are now all dead, because they couldn't be bothered to learn how to be a pilot, study theory-of-flight, avionics, navigation, etc, etc, etc. But that's clearly the tools fault, right? Let's you think I'm some young punk, I'll be 60 in a couple of years. That makes me, decidedly, an "old fart" in this game. You clearly mis-understood what you were seeing. GRC has this unfortunate side-effect. Could GRC be "better" (for whatever value of "better" you want to use)? Of course. But don't think for a moment that you'll ever get around the fact that you'll need to understand ' what you're doing, both in terms of DSP knowledge and programming knowledge and experience. That's not what GR is, and I'd challenge you to find ANY tool in a deeply technical field like signal processing that removes the need to understand what you're doing, and why. But if you're at the level of "why should I need to understand what roles filters play, what sample-rates imply, how demodulators work" then you should look elsewhere. You'll be looking for a very long time. Another proximate example. There are now lots of really awesome tools that neurosurgeons use to help them do their jobs. But not a single one of those neurosurgeons go into that operating room without any understanding of anatomy, neurology, neuro-pharmacology, and years and years of experience as an intern. They don't simply waltz in there, turn on the "Surgeons Assistant 5000" device, and push the "cure my patient" button. True, after 6 months I managed to fumble my way to a flowgraph that sort-of got the job done. But there were serious limitations, such as WX widget deficiencies including only mono audio stream for some sources/sinks (just how out-of-date can you be in the 21st century?).I'll point out that GR is, at its core, just a set of library functions, a buffer manager, and a thread scheduler. There is ABSOLUTELY NO REQUIREMENT to use the facilities of GRC, and no requirement to use its world-view of the GUI widgets. GQRX is one example out there, and I myself built a fairly-complex GR-based application using the XForms toolkit years and years ago. Add in inexplicable control gaps like decade "thumb-wheels" (for tuning) or command buttons (e.g. to increment a variable by a preset amount) and it's clear that Gnu Radio Companion fails to replicate anything like a basic RADIO front panel.Because GR isn't as I've pointed out, "just a big radio with a lot of knobs". BTW sliders can be used and configured for whatever increment and range you want--and, again, you are not constrained to use any particular GUI toolkit with GR. GRCs GUI toolkit was largely initially imagined as a way of having some debugging tooling lying around, and not necessarily to produce a "gorgeous radio front-panel". That it has *just* enough functionality to convince you that it is heading for the "gorgeous radio front-panel" direction, rather than the "help me debug my application" direction can certainly lead you to find it seriously wanting. But, again, nothing requires that you use GRC or its particular set of widgets. I won't even start moaning about changes to Python versions and libraries.On the other hand, do you expect GR to just remain static in the face of underlying *critical* dependencies like Python changing underneath? How would you propose to make that "easy" when GR finds itself on a platform that may no longer have Python2.7, for example? Or wildly-deprecated WX libraries? Modern software has dependencies on other software. That's just a fact of life. You can argue that the software (GR in this case) shouldn't have any dependencies, but then you'd find that GR offered very few features, and it would bring out new versions roughly every 10 years, because all of the "goo" that is currently based on third-party libraries is now in-skin, and desperately hard to maintain. GR is nowhere-near unique in having this problem. Every piece of Open Source feature-rich software has this problem--it can either rely on 3rd-party libraries underneath, and thus have to make difficult management decisions from time-to-time, or it can simply do *everything* "in skin", and suffer the even worse consequences. The dependency "hell" is made even worse by the fact that Linux has been wildly successful. So much so that if you're an application developer, you have almost no way of predicting how your software will be configured and installed on any given version of Linux, from which there are dozens to choose from--each with their own package-management systems, choices of system libraries, system-management functions, network stacks, etc, etc. When a user runs into a problem installing your software on Linux-variant-47, you, as a developer, may have little to no "magic bullets" to make that process easier, because that process is entirely out of your control. That can definitely exacerbate the negative "user experience", but a project like GR has very little control over that experience. If you don't like the way your particular Linux distro has packaged GR, then your first line of complaint should be to whoever maintains that distro. BTW under "cool stuff", I include the disgraceful self-promotion and waste of valuable time in the YouTube video https://www.youtube.com/watch?v=bHjITd2HR-g&ab_channel=GNURadio. The golden rules for development include doing the basics well, backwards compatibility, not breaking what already works, incremental improvement, giving priority to fixing bugs/defects, and testing, testing, testing. GRC has broken all of these big time over the years."Things breaking" is just a fact of life in software development. I worked in commercial software dev for nearly 40 years. Open source projects are sometimes a bit worse in this regard because: o They get ambitious o They rely on other open-source tool-kits, which can break o They may not get as much free QA bandwidth as free developer bandwidth o They nearly never get any free technical-writer bandwidth I suppose the real problem (for me) is that GRC is written by DSP experts for DSP students who get by with a little help from their friends, adding a bit of Python here and C++ there. In other words, GRC is *not* the general purpose learner's tool that comes across in the Balint intro.One could, I suppose, crack open a good book on DSP and programming techniques. When I first started programming in C in 1979, I was not at all aghast at the fact that the C compiler didn't, in fact, include a complete 4-year undergraduate course in computer science. When I made mistakes, when I actually had to apply myself to programming problems, I took responsibility for those problems, and became a not-entirely-unaccomplished software developer as a result. When I first started using a lathe 20 years ago, I didn't blame the machine for my lack of skill. There was no "clippy" who popped up and said "looks like you're trying to make a bronze bearing-- would you like me to do it for you?". As for the lack of support for Windows, how can you possibly ignore (more-or-less) the No. 1 operating system with its large pool of users hungry for GRC-type tools? If your fundamentalist fixation on *nix prohibits contact with the unclean, please have the honesty to label your product accordingly.90% of the volunteer contributors to GR are *nix developers. We cannot force those to become Windows developers. There's no paycheque-linked carrot dangling in front of them to do that. GR has *never* excluded anyone from contributing in its 16 year history. That there are very few Windows people contributing is not due to a conscious effort on the part of the many generations of GR project management. If people want to make the GR experience better on Windows, they are welcome to contribute. They always have been. People like Geof Nieboer have done much over the years to make GR easier to install on Windows. The project needs more like that, but cannot make them appear out of thin air.
|
[Prev in Thread] | Current Thread | [Next in Thread] |