Re: [dev] Re: Linux distros that don't suck too too much

From: hiro <23hiro_AT_gmail.com>
Date: Fri, 13 May 2016 09:54:50 +0200

you're making up words there. nobody cares about your aesthetic problem

if your code only adds complexity to people's lifes you shouldn't
code. my code makes other people's lifes easier.

finding the right abstractions is a process.

this does not apply only to code btw.

On 5/13/16, Ben Woolley <tautolog_AT_gmail.com> wrote:
>
>> On May 12, 2016, at 10:36 PM, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
>>
>>> On 13 May 2016 at 01:31, Jason Young <doomcup_AT_gmail.com> wrote:
>>> suckless is about *simplicity*. Simplicity != easy to use. Simplicity
>>> means, basically, there's fewer parts to break, and there *being* fewer
>>> parts, it's easier to see *where* it breaks. Unfortunately, the more
>>> "easy to use" you make a piece of software, the bigger it gets and the
>>> more dependencies it accrues, and you're right back at suck software.
>>
>> This is a delusion. "easy to use" does not imply complexity.
>>
>> A rule of thumb for UI design is this: if a UI offers multiple ways to
>> achieve the same result, it sucks and becomes less "easy to use". It
>> confuses the user. And such an UI costs the extra price of additional
>> complexity.
>>
>> Instead "easy to use" interfaces should just reflect the solution
>> underneath and will only be simple if the solution underneath is
>> simple.
>>
>> Also note the quotes Louis replied, they explain it much more crisp.
>>
>> -Anselm
>
> I agree that simpler implementations can have greater "power of expression".
> However, optimizing the base case can be an added complexity that makes the
> aesthetic complexity less.
>
> I make a distinction between structural complexity and aesthetic complexity.
> Aesthetic complexity is the complexity of the path through the structure,
> from end to end. Adding structural shortcuts can often simplify the path.
>
> I like to start with a good "power of expression", and then solve the
> aesthetic problems. This certainly leads to "multiple ways to achieve the
> same result", but is a valuable enhancement. For example, ports that build
> from source, and then binary packages that build from those ports. Surely,
> having both options is better, and having one based on the other is a smart
> enhancement.
>
> However, sometimes I like to create a simple optimized solution that is
> designed for a single case. That can seem like a less complex thing, but in
> practice this leads to multiple solutions for a variety of cases. For
> example, there are usually dozens of window managers available. If you look
> at it system-wide, each was developed to not suck in some way, but now it is
> a bit of a struggle to get all of the apps to play nice with all of the
> different management styles.
>
> Basically, if you are writing code, you are adding complexity. How useful
> that code is, is very important to the "problem of complexity".
>
> In the end, I say this: if you are going to build something, build it to
> slay something else. That way you actually reduce someone else's suck
> system-wide. Like the way nginx overtook Apache. There can be misses, but
> let those be shots across the bow.
>
> Ben
>
Received on Fri May 13 2016 - 09:54:50 CEST