Why do 'developers' always insist on 'fixing' that which was

[weedeater64]

Code: Select all

jeff@hp-630:~$ soundinfo
soundinfo Ver. 2.3.10 (May 2008)  (c) 1996-2008  Jim Jackson
[soundinfo] No such file or directory : /dev/mixer
[soundinfo] No such file or directory : /dev/dsp

And breaking everything in the process?

[dasein]

Oooo! (furious hand-waving)... I know this one!!

Because they imagine that they are just so much smarter than everyone who came before them (*cough*systemd*cough*).

Yes, genuinely new requirements do some along every once in a while (e.g., digital video editing). But let's face it, we have existing code to fire LEM retrorockets, control robotic explorers on other planets, position telescope mirrors with exquisite precision, just to name a few. When it comes to code, the fact is that most wheels have already been invented.

But every generation decides that it has to "improve" things, even when we know from experience that such "improvements" mean lower-quality code, more bugs, more pointless features, etc.

I am reminded of a moment from back in my school days, when a classmate proposed to examine the question of "Why systems fail." I pointed out that that particular topic has already been researched to death, and I suggested that a more appropriate question was something like, "Given that we already know why systems fail, why do we keep building systems that fail??"

The subtlety was lost on him.

More's the pity.

[fireExit]

Code: Select all

jeff@hp-630:~$ soundinfo
soundinfo Ver. 2.3.10 (May 2008)  (c) 1996-2008  Jim Jackson
[soundinfo] No such file or directory : /dev/mixer
[soundinfo] No such file or directory : /dev/dsp

And breaking everything in the process?

in the meantime (jessie 64bit)

Code: Select all

fireexit@stars ~ $ soundinfo
soundinfo Ver. 2.3.10 (May 2008)  (c) 1996-2008  Jim Jackson
MIXER DETAILS ......................
           Mixer Id = HDA-Intel
               Name = Intel PantherPoint HDMI
           devmask  = 0x000021441
           recmask  = 0x000000000
           sources  = 0x000000000
        stereodevs  = 0x000001440
MIXER capabilities  = 0x000000000

MIXER (/dev/mixer) has following channels, set as :-
  [0x00000001]  0  Vol     100                         
  [0x00000040]  6  Line      0/  0                     
  [0x00000400] 10  Pcm2    100/100                     
  [0x00001000] 12  IGain   100/100                     
  [0x00020000] 17  Digital1    0                         

DSP details ................
     capabilities = 0x000003301
        formats = 0x00005B1F9
       blocksize = 1024

DSP Capability revision level 1
    Supports duplex operation (simultaneous read/write)
    Supports RealTime capability.
    Supports SETTRIGGER operation.

DSP Formats supported are :-
  Mu_Law    U8    S16_LE    S16_BE    S8    U16_LE    U16_BE

Fragment details    Output.. Input..
 total fragments         2        2
       available         2        0
   fragment size      1024     1024
 bytes available      2048        0



[dasein]

Supplemental answer, particularly applicable to re-writes: Because they are too damn intellectually lazy to do the "hard part" of code maintenance--diving deep into existing code to truly and fully understand everything it's doing.

It's commonplace to hear devs complain about how the existing code is too complex and too convoluted to maintain, and therefore simply must be rewritten from scratch.

But the actual fact is that virtually every patch, every kludge, every bugfix in the existing code is a living example of a failure by the original developers (and everyone who followed them) to fully and completely comprehend the requirements and the use-case of the software in question. But because reading code is way harder than writing it, the young Turks decide to scrap everything and start over.

Here's the problem: At the end of the day, the young Turks are no better than the original coders at understanding the "edge cases" that necessitated the need for all that "convoluted" code in the first place. By throwing away all the existing code, they are essentially giving themselves a lobotomy.

One example among many: When the KDE devs scrapped KDE 3.x in 2008, they lamented at great length about how the existing 3.x code base had become unmanageable and unmaintainable. Fast-forward six years, and the KDE devs justified a rewrite-from-scratch by lamenting at great length about how the existing 4.x code base had become unmanageable and unmaintainable. (Do we detect a pattern here?)

In my experience, the very best coders are so meticulous in their thinking and so comprehensive in their internal documentation that their code almost never needs to be rewritten, merely adapted ever-so-slightly to accommodate a new use-case. More to the point, their thinking so straightforward and so clearly articulated that their existing code can be reused and repurposed with virtually no effort at all.

But in coding, as in all things involving humans, mediocrity inevitably prevails, simply because mediocrity is far more commonplace than excellence.

(At least that's what they tell me.)

[weedeater64]

bla..bla..bla..bla...
[/code]

And how is that siggen working out for you?


Also, Debian loves to brag about how it has 20,000 packages, but how many of those 20,000 packages stopped working years ago?

Why do you leave them in the repos if you broke them?

It is very tiresome, searching for apps, installing them, only to find out they have not worked in years.

[fireExit]

And how is that siggen working out for you? Asshole.

Talking to the mirror, again?

[No_windows]

..... the young Turks

I don't understand this reference and I don't think you're referring to a rap group like Google seems to tell me.

[weedeater64]

..... the young Turks

I don't understand this reference and I don't think you're referring to a rap group like Google seems to tell me.

C'mon, let's see a screen cap of a working siggen.

[dasein]

..... the young Turks

I don't understand this reference and I don't think you're referring to a rap group like Google seems to tell me.

The magic search syntax is define, as in

Code: Select all

define young Turks

(Try it at Google or Startpage)

[dilberts_left_nut]

@weedeater64
Uncalled for and in violation of forum rules - take a break.

[NFT5]

Change for the sake of change? Probably.

Here's one perfect example:

In Debian 7 Synaptic has a quick search box on the toolbar. Quick and easy.


But, in Debian 8, the quick search box is gone, replaced by a button, doubling the effort to get to search.


Why?

[steve_v]

Damn you for pointing out this thing I hadn't noticed... Now it's going to annoy me forever.
There seems to be some weird push for "everything as a cryptic icon where once was a menu / text input" in UI design these days, I don't know where it's coming from, but it's utterly infuriating.
At least this one still says "search" on it.

[dasein]

But, in Debian 8, the quick search box is gone, replaced by a button, doubling the effort to get to search.

Reminds me of something Mandriva did circa 2008. They have their own equivalent of Synaptic, and some GNOME-headed numbnut convinced the devs to suppress library packages from the package list, claiming that it was "too confusing." As a result, displaying all packages available in the repo required an extra (and unnecessary) step of ticking a check box (which, of course, wasn't displayed on the main screen).

Of course, you know what happened. The frequency of folks asking "Where the farq is library X?" in the forums skyrocketed, leeching time and attention away from actual problems. But the devs (many of them GNOME-heads) were too damn stubborn to admit (and correct) the error.

(Wow, I sure am feeling chatty.)

[dilberts_left_nut]

(Wow, I sure am feeling chatty.)

Maybe because the thread topic is the equivalent of nerd-sniping for disaffected old geezers.

[dasein]

(Wow, I sure am feeling chatty.)

Maybe because the thread topic is the equivalent of nerd-sniping for disaffected old geezers.

Yeah, and I used to get paid for it, too.

(Man, that was one great gig.)