guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: timestamp


From: adriano
Subject: Re: timestamp
Date: Sat, 12 Feb 2022 14:30:16 +0100

Hi Ricardo,

thank you for chiming in :-)

Il giorno sab, 12/02/2022 alle 12.49 +0100, Ricardo Wurmus ha scritto:
> 
> Hi adriano,
> 
> I’ve got no good answers as to “why” things are the way they are, but
> the manual explains the range of these values:

You're right, the manual does explain the range of these values, so the
experience can be less punishng than I perceive it to be

I had just overlooked those bits, I was't readng hard enough, actually

I think there's a reason for that but I need to digress a bit

My main gripe with the Manual is its "reference" nature

I'd love it to consider the experience of wanting to cover a use case
as the starting point of exposition

Instead it considers features as starting points and it leaves to work
to stitch together a solution for their use case to the reader

It's a matter of cognitive styles, there's no universal solution

A manual centered on use cases would baffle _some_ people

The argument of lack of examples in the Guile/Guix documentation has
been made several times now, or at least, I've seen it being made
several times

Although there's no solution in sight, this reaasures me to some extent

Because it means that the community is not completely blind in respect
to this issue

As for me, I like to mention that I had individuated this talk at the
Fosdem 2017

https://archive.fosdem.org/2017/schedule/event/legacy_docs/

and I proposed an excerpt from that talk in my videos about how to read
a file in Guile (a basic use case and its solution)

But today I'd like to also mention something else

It's a project called "bropages"

It's meant to be used like the "man pages" tool but it's made only by
example

Quick dry examples

Do you see a pattern here ? :-)

http://bropages.org/

Admittedly the name of this project is a bit unfortunate, but that's a
different argument ;-)

ok, I digressed enough

The reason why I overlooked those bits is that I get frustrated when I
land in manual pages that repost long lists of procedure I'm not sure
what to do with, unless I think of that a bit

So I skim, I jump around in the page, trying to minimize frustration

This morning I'm playing with a use case of mine

These days I'm training in a gym and I have an agreement with a
personal trainer

I shoot myself while training, I send them the footages on whatsapp
(sigh) and they send me back some more footages in which they
comment/correct my execution

So I have a folder with a bunch of files named like this

VID-20220129-WA0021
VID-20220202-WA0019
VID-20220207-WA0025
...

I'm mumbling of a script that can group these files by day

meaning putting in a subfolder all the files having the same date in
their name

maybe such subfolder could have an expressive name

so I would have a collection of days/subfolders 

The bunch of files I have now is quite hard to parse

I hope I was clear

So today i read about the stat* procedures, I moved from "stat:perms"
to "access?"

So, ok, now I know how to check a file

I also read about datetimes and converting from/to epochs

So now, if I can find the way to access the _name_ of a file, I could
isolate the substring expressing the date and parse it to get an epoch

Then I could start to think about how to group files by date

(in Clojure there's a library procedure that groups dictionaries by key
but that's an argument for a different thread)

So, in laying the logical stones in my script/wall, I have to go
through the manual over and over again to fish for useful bits and
stitch together my subpatterns made of small stones 

Ten I'll have to assemble my subpatterns...

This kind of process is frustrating to me

Rather than stitching together features to build solutions to use
cases, I'd prefer so much to sew together new use cases starting form
preexisting one (as the bropages dudes seem to like)

Again, this is a subjective preference, there's no obvious solution

I'd refrain from arguing that the Guile manual authors were not smart
enough because their documentation is pointlessly selective, I
understand that this was done in good faith

I'd rather contend that people with this specific cognitive style are
smart and people with a different style are less smart but again this
is another argument

I'd love if people would refrain from arguing that having a hard time
with Guile documentation means you're not tryng hard enough or that
you're not smart enough

Again, I understand that this argument isn't necessarily made
maliciously

But between Guile curse of knowledge and this kind of arguments, I
believe this explain quite a bit the difference in success between
Guile and Python or Javascript



reply via email to

[Prev in Thread] Current Thread [Next in Thread]