[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Is Elisp really that slow?
From: |
Drew Adams |
Subject: |
RE: Is Elisp really that slow? |
Date: |
Fri, 17 May 2019 08:02:44 -0700 (PDT) |
> I've been in this software business for 30+ years, and with the arrival
> of "commodity computing", I've observed a strong anti-pattern: designs
> tend to cater to the buyer and not to the user.
>
> I'll explain: If you decide which product to "buy", you haven't the
> time/resources to become proficient with that product: you decide on
> first impressions. But once you use that product for years, you'll
> "need" other features, which perhaps don't stick out at first sight.
>
> There are two mechanisms pushing that anti-pattern forward:
>
> 1. In bigger corporations those taking the decision which software
> to "buy" (usually in the monetary sense) won't be those
> paid (and thus more or less blackmailed) to use it. Management
> goes "oh, shiny" and workers go "oh, no!".
>
> 2. In general, when you personally "buy" a piece of software
> (in the monetary, or in the general sense), you often have
> no idea on what you need, so you go "oh shiny" again, and
> sink considerable effort into fine-tuning your interface to
> that software. Re-tuning is so expensive that you better not
> think of it (as a long-time vi user, I mostly moved to Emacs
> about ten years ago: it /was/ expensive.
>
> Cheers
>
> [1] "buy" in a very general sense: it might cost money or not,
> but it'll cost learning, dedication and commitment.
And in a later msg:
> I'm convinced that conventional software has promoted patterns
> which tend to keep users in dependency (much more so in the Web
> "application" space[1], because there it's strategic for your
> business), and that those patterns infiltrate our way of seeing
> things -- therefore they end up in free software too, for no reason.
+1000. Thank you for putting it so clearly.
user != chooser
Of course users may first choose. But they also must then use.
Design for choosers ("sales" in some sense) is not, in itself,
design for users and use.
OTOH, a bazaar does have this advantage over a cathedral:
masses of user/developers attracted (in whatever way initially
- click-bait/"oh-shiny" or not) do sometimes improve a thing
that might have started out rudimentary or poorly designed.
Do Photoshop developers spend a huge amount of their energy
worrying about dumbing it down to commodity-sell it to every
Joe & Jane? There may be some of that, but I doubt that it
is a strong/main consideration for the product design, in
particular for making the product as usable, useful, and
powerful as possible.
- Re: Is Elisp really that slow?, (continued)
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/30
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/28
- Re: Is Elisp really that slow?, tomas, 2019/05/17
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/28
- Re: Is Elisp really that slow?, Dmitry Gutov, 2019/05/17
- Re: Is Elisp really that slow?, Óscar Fuentes, 2019/05/17
- Re: Is Elisp really that slow?, Dmitry Gutov, 2019/05/17
- Re: Is Elisp really that slow?, Óscar Fuentes, 2019/05/17
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/30
- Re: Is Elisp really that slow?, tomas, 2019/05/17
- RE: Is Elisp really that slow?,
Drew Adams <=
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/31
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/27
- Re: Is Elisp really that slow?, Xavier Maillard, 2019/05/29
- Re: Is Elisp really that slow?, Eli Zaretskii, 2019/05/17
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/30
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/25
- Re: Is Elisp really that slow?, 조성빈, 2019/05/25
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/25
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/25
- Re: Is Elisp really that slow?, Eli Zaretskii, 2019/05/25