Re: Stop making unneeded improvements

[Marcus D. Leech]

On 01/08/2021 12:38 AM, paul@dbnut.com wrote:
> [Apologies for the lack of paragraph breaks in that last - taken by 
> surprise after using a crude editor]
>
> Thank you, Marcus, for taking so much trouble to respond so 
> comprehensively. And with such good grace!
>
> Your detailed section on dependencies is very sobering and helps me 
> understand much better how vulnerable GR is in that respect, plus how 
> essential it is to restructure from time to time and how painful that 
> is going to be. In some ways the timing was unfortunate for me - a few 
> years earlier or later your project might have been a little less 
> "dynamic".
Nearly-all modern software that is anything other than trivial has a 
"dependency iceberg".  For commercial software, a bit less so, and it's
  driven a lot by licensing terms--the company I worked for most 
recently (now semi-retired, thank Cthulu) did a lot of replication of
  underlying technologies, because the licensing of the "totally 
perfect" open-source stuff interfered with the companies business goals.

But for open-source software, there's a long and strong tradition of 
"standing on the shoulders of giants".  This does mean a bit of
  risk, but overall, it means you can deliver better stuff, faster.
> Also I can now understand your (and presumably the majority) 
> perspective on the Companion as more of a debugging tool, while for me 
> it served more like Visual Studio for a WinForms project (not a very 
> accurate comparison, but I think you'll see what I'm getting at). The 
> fact remains that GRC exists, it is apparently used quite widely by 
> people like me with lesser skills, and its GUI wrappers for on-tree 
> blocks enable a fantastic scope for some *highly* complex system 
> prototyping.
>
> You may not want to emphasise GRC's stand-alone talents but 
> flowgraphing is an increasingly capable and popular tool class, not 
> entirely unlike GUI visual designers.
>
> In contrast, my (prototype) flowgraph was so simple as to be almost 
> laughable (and I should have made that clear at the start). Yes, it 
> was a "radio": reading from an I-Q file, the essentials being several 
> stages of frequency translation, decimation, assorted filters, 
> Hilberts, Costas, finally audio to sound card. Just rather different 
> from the many examples on the web. As for GUI, a couple of spectrums 
> and waterfalls, a 'scope, assorted selectors, and tuning.
>
> Ah, tuning. I ended up with one slider for *each* decade digit from 1 
> MHz down to 0.01 Hz (don't ask). That's why I was looking for up/down 
> buttons to configure tuning step using a single slider. Now you'll 
> probably tell me I'm a moron because XYZ will deliver exactly that. Oh 
> well, I'm a hermit and don't ask questions but should have done.
I understand the "just a radio" user-interface widget you're going for 
with that--many of the popular SDR-for-casual-airwave-surfers
  applications include something like that.  I've never found it 
particularly useful for *myself*.   Part of the problem is that GR is 
"stuck" using
  whatever bits and pieces of UI that toolkits like Qt provide. 
Creating new UI componentry would be:

  (A) A distraction from the DSP core-purpose
  (B) Lead to complicated questions about whether those new GUI 
elements get "upstreamed" to Qt or held as "private" extensions


> That brings me with trepidation to DSP understanding/skills. My maths 
> degree is ancient with a thick coating of rust and, however deep you 
> dig, not a mention of difference equations. So I'm a baby in this new 
> world. But please give me credit for having read hundreds of pages on 
> DSP at various levels - not enough to use Matlab or write Python 
> routines, but enough to configure ready-made GRC filter blocks and be 
> aware when I'm over my head.
>
> The point is, I take the view that (broadly speaking) there are two 
> levels of understanding: creator and informed/educated user. You are 
> the first type, I'm somewhere near the other end of the scale. By 
> analogy, I can use a highly sophisticated communications receiver to 
> great effect with almost no expertise in electronics design.
Right, and it is the "I can use a sophisticated communications receiver" 
aspect where there's a cognitive disconnect, I think.   GR is NOT
  "just a sophisticated radio with a lot of buttons", but is rather a 
*toolkit* that would certainly allow you to *create* "a sophisticated radio
  with a lot of buttons".

Diving back into the analog/hardware world.  If I come upon a box full 
of parts and I want to build "the coolest radio ever", I would not
  be surprised to find that the box of parts in and of itself, is of no 
use in helping me achieve that goal without some considerable background
  knowledge.  Yet, if I insisted that said box *should* somehow provide 
me with instant ability and skill, I'd be, correctly, thought of as a bit
  of a kook.

Now, the analog with GR and GRC is imperfect, and I fully acknowledge that.

> And the bottom line on this one is [as always, from my perspective] 
> for a wide range of applications you *can* get by without anything 
> more than GRC (i.e. no coding). And where GRC does fall "short of that 
> goal", *maybe* GRC warrants a bit more effort to widen the goal mouth. 
> It just feels a bit harsh hearing "nothing requires that you use GRC" 
> if GRC is ostensibly up to the job while the skills gap to make do 
> without it is so daunting.
I "get" the whole "oh, but it's so very close to what I need".  But GR 
really is just a specialized programming environment, and GRC
  has the unfortunate (in some sense) side effect of making it seem 
like something else, sometimes tantalizingly so.

Part of the problem here is that GRC isn't particularly *tutorial* in 
nature, and there has historically, and continues to be, a problem with
  providing adequate documentation on a block-by-block basis.  This is 
fixable by the mere application of hundreds of hours of
  tech-writer time.  That time, in the 16 years that GR has existed, 
has yet to materialize.  Coders are notoriously poor documentation people,
  and very-few tech writers seem to be imbued with the same 
public-spiritedness as competent coders.  This is not a problem
  peculiar to GR...

Nobody in the GR "management" would be at all unhappy for folks to 
contribute to making it better-documented and with a
  "slicker" UI framework in GRC.   There's no conscious effort to block 
that.  But the pool of contributors are generally focussed
  on other things.  Just the nature of an open-source project.

My main interest in GR has always been in its applications to 
radio-based science, such as ionospheric research, and radio astronomy.
  If you think GR is "bad", you should sit down with any number of 
"professional" radio astronomy tools sometime.  Oy.



> Sorry to have laboured that point.
>
> As previously, I have learned a lot from your exposition, Marcus. And 
> I'm grateful for your time responding. It's not my intention to try 
> and have the last word, so I'll shut up now and go back to my cave.
I enjoy these longer, rambling posts.   I get to put on my vestments and 
speak from the pulpit :) :)
> [BTW good to read Geof Nieboer's 4 Jan update on Windows installer]
>
> Paul White