Re: [dev] [sbase] Use of libutil

From: Marc Collin <marc.collin7_AT_gmail.com>
Date: Wed, 29 Apr 2015 17:52:53 -0300

> The symbol table does not matter too much in statically linked applications (and that's what's supposed to happen)

Oh $deity... :facepalm:

So you do all that work of extracting the function to avoid "duplicate
code"... just so the compiler can put it back the way it should've
been written in the first place!? WTF.

> I can understand the motivation to do that manually to optimize the code

It's about optimising for efficiency and readability. By extracting
that function you have required the reader to know what that function
does... when she finds out, it happens to be something inanely
trivial... and you're doing it in one of the most trivial of
utilities.

> premature optimizations

You're making premature pessimisations instead.

> broken and unmaintainable, chaotic code (look at ACU).

Using big words like "unmaintainable" and "chaotic" does not help your
argument. The ACU echo does not require anyone with familiarity with
the POSIX interface to read more than a single file to figure out what
it does.

> Where?

Figure it out yourself if you think you're so smart.

On Wed, Apr 29, 2015 at 12:48 PM, FRIGN <dev_AT_frign.de> wrote:
> On Wed, 29 Apr 2015 08:58:26 -0300
> Marc Collin <marc.collin7_AT_gmail.com> wrote:
>
> Hey Marc,
>
>> If anything the amount of extra space you're taking up in the symbol
>> table with an additional (imported) function call and the code of the
>> putword function, for example, absolutely trivially stupid function is
>> far more than just integrating the bloody thing into the source. It is
>> literally a compare with an existing variable and a conditional
>> function call, which you can't do if you decide to pull it out
>> separately so you have to make an extra fucking variable THAT IS ONLY
>> EVER USED ONCE! Instead you have to go through the motions of passing
>> parameters and register saving/restoring and all that stupid shit that
>> compilers do when they call functions.
>
> It is one thing when your ACU project is slammed on some message board
> on the Interwebs, it's another when you start "criticizing" another
> project on false grounds.
> I'll give you a small hint: The symbol table does not matter too much
> in statically linked applications (and that's what's supposed to happen)
> and libutil is not dynamically linked into the binaries.
> If the compiler detects a function to be "trivial", it will inline it
> automatically. I can understand the motivation to do that manually to
> optimize the code, but premature optimizations are the first step
> towards broken and unmaintainable, chaotic code (look at ACU).
>
> I'm glad to see you subscribed to the suckless ml, you still got a lot
> to learn.
>
>> Why don't you refactor all the for loops out into their own function
>> too? Or all the if statements? After all, they are "duplicated code".
>> This is near that level of retardedness.
>
> Check out GNU coreutils if you like that.
>
>> You've also not propagated errors correctly... so it is a FAIL!
>
> Where?
>
> Cheers
>
> FRIGN
>
> --
> FRIGN <dev_AT_frign.de>
>
Received on Wed Apr 29 2015 - 22:52:53 CEST