[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Trying eev with a sexp (not for adults!)
From: |
Eduardo Ochs |
Subject: |
Re: Trying eev with a sexp (not for adults!) |
Date: |
Sun, 20 Oct 2024 22:15:09 -0300 |
Hey!!! Many thanks!!!
The book "The Mythical Man-Month" has a chapter called "Plan to Throw
One Away"... its first page is:
Chemical engineers learned long ago that a process that works in
the laboratory cannot be implemented in a factory in only one step.
An intermediate step called the pilot plant is necessary to give
experience in scaling quantities up and in operating in
nonprotective environments. For example, a laboratory process for
desalting water will be tested in a pilot plant of 10,000 gallon/day
capacity before being used for a 2,000,000 gallon/day community
water system.
Programming system builders have also been exposed to this lesson,
but it seems to have not yet been learned. Project after project
designs a set of algorithms and then plunges into construction of
customer-deliverable software on a schedule that demands delivery of
the first thing built.
In most projects, the first system built is barely usable. It may
be too slow, too big, awkward to use, or all three. There is no
alternative but to start again, smarting but smarter, and build a
redesigned version in which these problems are solved. The discard
and redesign may be done in one lump, or it may be done
piece-by-piece. But all large-system experience shows that it will
be done.2 Where a new system concept or new technology is used, one
has to build a system to throw away, for even the best planning is
not so omniscient as to get it right the first time.
The management question, therefore, is not whether to build a
pilot system and throw it away. You will do that. The only question
is whether to plan in advance to build a throwaway, or to promise to
deliver the throwaway to customers. Seen this way, the answer is
much clearer. Delivering that throwaway to customers buys time, but
it does so only at the cost of agony for the user, distraction for
the builders while they do the redesign, and a bad reputation for
the product that the best redesign will find hard to live down.
Hence plan to throw one away; you will, anyhow.
See:
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythical-man-month.pdf#page=130
Anyway. One thing that happens ALL THE TIME when I'm using Emacs is
that is that in one moment I'm doing something, then I think "hm, I
can automate this", and then in next moment I'm reading about how to
do that something, collecting links, and maybe writing some code...
and that code is ALWAYS throwaway code, that is allowed to be "barely
usable. It may be too slow, too big, awkward to use, or all three" -
and even unreadable, and broken.
In beginning I didn't allow myself to do that - I was always imagining
what other people would say if they looked at my code, and these
imaginary people were always criticizing my style, my names for
variables, my comments, EVERYTHING...
It took me ZILLIONS OF YEARS to realize that my colleagues and profs
would look at my code at most once or twice a year, and so I could
spend most of my time doing things that were "first systems", and that
could be full of experiments that no one else would understand... and
only my n-th rewrites needed to be readable.
By the way, I am working on this:
http://anggtwu.net/show-conses.html
https://lists.gnu.org/archive/html/emacs-devel/2024-10/msg00459.html
...and I am planning to submit it to ELPA, but I am waiting for
someone on emacs-devel to tell me that show-conses.el is ELPA-izable,
and no one has answered yet. Note this part of the e-mail:
These techniques are somewhat controversial: apparently Kids These
Days believe that all tests should be unit tests, or at least
automated tests - and some of these Kids These Days reacted very
angrily when I showed them my test blocks. But more on that later.
I've met lots of people who have this imaginary $EVILBOSS that is
always talking to them and always screaming things like "YOU CAN'T USE
THIS IN PRODUCTION CODE!!!" - and they believe that they need to
educate other people by screaming to them in caps lock too...
Cheers =),
Eduardo
On Thu, 17 Oct 2024 at 00:58, Bruno de Oliveira Macedo
<macedobruno@id.uff.br> wrote:
>
> Hi, I wanted to share these thoughts:
>
> I remember a while ago you introduced the distinction between "users" and
> "non-users".
> This differentiation made a significant impact on the approach I use to
> interacting with my system,
> as it effectively conveyed some philosophy inherent to eev.
>
> This idea of eev being for 5-year-olds feels like that.
> It not only captures the playful nature of engaging with a system with a
> 'child-like' mindset
> but also emphasizes the importance of not being overly concerned about
> appearing hyper-productive.
>
> The statement,
> "[...] if you start by learning how to configure Doom Emacs then you'll learn
> to see Lisp as a weird
> configuration language, and you'll be doomed..." is funny and resonates with
> me.
> Having used Doom Emacs for a period, I indeed perceived elisp as a
> configuration language during that time.
> However, my current mindset feels more liberated. But also really weird.
>
> Using eev and emacs as my main interface with the system, I've noticed that
> some things are really incomprehensible
> for other people. I feel that I could not convey the motivation for doing
> things this way
> However, concepts of user/non-user and adults/5-year-olds clarify my
> understanding of why this may be the case.
>
> "It turns out that 1) they were expecting that eev could solve some problems
> that they already knew that they had,"
> This observation is intriguing, as I have personally experienced this.
> I was unaware of the limitations in my system interaction.
> I used to worry excessively about being perceived as incompetent and sought
> the quickest way to project competence.
> Over time, I developed a preference for the eev approach, driven by a sense
> of truth and philosophy that draws me in,
> evoking a feeling of freedom.
>
> Anyway, I realize this is all abstract.
> The essence of an abstract idea underlying eev positively influences me.
> This is why I appreciate the simplicity and philosophy encapsulated in the
> notion of eev being tailored for a 5-year-old mindset
>
> Em seg., 14 de out. de 2024 às 06:43, Eduardo Ochs <eduardoochs@gmail.com>
> escreveu:
>>
>> Hi all!
>>
>> I just finished this,
>>
>> http://anggtwu.net/2024-find-tryit-links.html
>>
>> and this explanation on why eev is not for adults:
>>
>> http://anggtwu.net/2024-eev-for-5-year-olds.html
>>
>> Cheers =),
>> Eduardo Ochs
>>