Threads for Cykelero

  1. 8

    Looks cool, my quick feedback is that your 02-12-06 time format is confusing.

    1. 6

      Agreed, please use the ISO 8601 (YYYY-MM-DD) date format. 🤓

      1. 4

        Agreed, what is this horror

        Got 212,432 snapshots, from 96-10-23 18:55:02 to 21-05-30 14:37:26.

        1. 1

          Oh, that didn’t cross my mind. I’ll probably add back those two digits, then!

        1. 65

          This is one of those things where I simply don’t understand why people insist that empirical science gives a definitive answer, or why people even care what the science says. I switch freely between light and dark schemes, and I do so based on the evidence of… my eyes. If it’s bright in my office I find dark screens harder and more tiring to read. If it’s dark, I find light screens harder to read. I prefer dark, overall, so I keep my office as dark as possible, usually.

          The question of which is “proven” to be superior, in lab conditions not using my eyes, is irrelevant. Having statistics doesn’t make it true.

          1. 12

            …or why people even care what the science says.

            Exactly, especially when it is debatable whether the science is even answering the question we find interesting.

            1. 12

              To some, science is religion, so invoking capital-S science justifies their subjective opinions, as if that’s what it’s for. To the rest of us, it looks quite silly and we can see right through it.

              I blame Solarized for even putting forth the notion that color schemes are anything other than preference.

              1. 10

                It seems like most people need permission from science to have any beliefs at all these days. I think articles like this shake people out of it a bit, but people carry that need with them to everything that’s not obviously subjective.

                I don’t think there’s anything wrong with bringing science into colorschemes or anything, I think most people should try doing a bit more of it because I think programming experience and aesthetic pleasure, while connected, aren’t the same thing. Try using acme colors or otherwise minimal, or turn highlighting off entirely every once in a while. Maybe try rainbowy semantic highlighting if you’re a minimalist already.

                1. 2

                  It seems like most people need permission from science to have any beliefs at all these days.

                  I think it’s the opposite, no? Many people hold beliefs despite the science, heck, some chunk of them believe that if something rhymes it has to be true.

                  The article is trying to answer what is better for some narrow definition of better, that matches author’s beliefs. If it were written in e-simple, it would have had a different message. But, as you and many say, color schemes are highly subjective areas — better is what we claim is better.

                  1. 1

                    some chunk of them believe that if something rhymes it has to be true.

                    Maybe we’re getting off-topic here, but I’ve never known anyone like that. Even the most religious people I know of would warn you that the devil has catchy songs, maybe even more catchy songs than God does.

                    1. 1

                      I don’t know anyone who claims it at the face value, but there are always subtle psychological effects:

              2. 1

                This is something I’ve been wondering about, because I’m one of these people who feels the urge to tell others about how light themes are actually better than they think. What’s the impulse?

                I think it comes down to culture. Dark editor themes seem to be the norm nowadays, and using a light theme actually draws attention. New colleagues will often make surprised comments when they see my editor—in the same way they’d comment about someone not being able to touch type. They don’t outwardly criticize, but it’s transparent it’s not something they expect from an experienced developer.

                So, as a result, it gets me thinking a lot about why I’m using a light theme despite it being a bit looked down upon. It’s very possible this is a common motivation for speaking out about the light/dark science!

              1. 3

                I like the thoughtful documentation, congrats on that! (As a minor nitpick, the link to the API Reference was a bit hard to find on the first skim).

                I generally use Node for my scripting needs because JS is the language I’m most comfortable with, so I can quickly whip up whatever I need, and I think this project is up to something. I like that it provides straightforward helpers for the cli, fs, and http parts — I usually make do with commander.js, fs-exta + fast-glob and got, respectively, but they still need some boilerplate.

                I’m curious about the rationale behind some aspects in the project, which to me seem to make the scripts less portable:

                1. injecting the API in the script’s global namespace vs. explicit require() / a single lemon scope
                2. the npm loading mechanism; did you consider allowing the normal require syntax and monkey-patching the internals?

                P.S. Thanks for putting your ideas out there! :-)

                1. 3

                  Oh, my, thank you for the kind words. I really needed these.

                  I’m glad you like the idea :)

                  You’re definitely right about the link to the reference being buried; the care that went into the docs is big part of what makes Tasklemon good, so I should make them way more prominent.

                  I wonder what you mean exactly by “portable”? TL was really thought up as a complete thing, so I might have had some blind spots in the design when it comes to integrating with other things. Despite this, since it’s built on top of Node.js, you can still do Node things: require() will work as expected, for instance, so you can still make use of neighboring JS files.

                  Of note, initially TL was never intended to be used as an API, as an imported package in a bigger project, and was designed accordingly; I’m starting to think it might be possible, after all.

                  1. 1

                    I wonder what you mean exactly by “portable”?

                    I guess I meant code that looks like normal JS as much as possible, and could potentially work without TL. I might have projected my own desire to have a way to quickly play around with npm modules in a way similar to Runkit (or that Mac app that I can’t can’t remember the name of right now) and so usage as an API somehow made more sense to me.

                    1. 1

                      Well, that might come eventually! For now though, it’s only the full-on approach.

                  2. 2

                    And some feedback from a toy script:

                    cli.accept({ color: '-c' });
                    let { formatter, lab, rgb } = npm.culori;
                    1. Is there a way to accept/read positional arguments from the cli?
                    2. It would be cool to auto-generate a --help out of argument descriptions
                    3. The package resolution seems to fail (lemon@0.2)
                    1. 1
                      1. Indeed: you can specify a position (say, '#0' for the first positional argument) instead of, or in addition to, a named argument.
                        You could very write something like this: cli.accept({ color: '#0 -c --color' }) which would mean the script accepts the color argument in these three different ways.
                      2. I agree! I’d like to work on that at some point. If you look at the cli.accept() documentation, I actually mention you can add descriptive text for arguments, even though it’s not used yet.
                      3. The script seems to work for me, although it doesn’t output anything; I can see it correctly parses the color if I add a cli.tell call. What arguments are you passing to the script when running it?
                      1. 1

                        Weird… I’ve added an issue on your GitHub repo with some details.

                        1. 1

                          Perfect, thanks! I’ll try to increase the logging of the installation process; right now it outputs messages, but doesn’t persist them.

                  1. 1

                    I use node for scripting on occasion (usually when I’m doing something like manipulating json). I’m not quite sure what this project gives me over plain node or bash.

                    If you think bash gets unreadable (and I don’t disagree), the straight node file API is fine and familiar. If I’m going to learn a new API, IMO I’d prefer to put that time into learning (more) bash.

                    1. 1

                      You’re making me realize I really need to add a comparison with Node APIs right in the readme. If you actually see how TL and Node look like next to each other, it becomes insane to suggest Node.js comes even closes in terms of usability.

                      I just threw this comparison together; to match just three lines of Tasklemon, Node suddenly needs three imports, path parsing, path concatenation (!), and everything is laid out with cryptic names. It’s an unreadable mess which drowns intent in barely safe implementation details. Node.js APIs are just fine, but not for the purpose of scripting!

                      If anyone needs to read and understand a script in a language/library they don’t know, JS/TL easily beats out JS/Node, or Bash/Shell. And with the meticulously detailed documentation, I think it might have a shot at being more pleasant to learn, too :)

                      1. 1

                        But in bash, it’s just rm ~/*.tmp

                        For short scripts, bash will be more concise and more powerful. For longer scripts, although the node file API in particular is messy, at least if anyone else has to read it there’s a decent chance that it will be familiar.

                    1. 6

                      The README explains fairly well what this does, but what is the motivation? Like, when is this better than shell scripting?

                      I’m probably missing something, but to me as an onlooker - it feels like a lot more work to do the same things here, and why use NodeJS if you remove it’s only strong benefit (asynchronous from the ground up) in how your service works? Seems like Ruby or Perl do this better out of the box, there are strong libraries do this in Python, and the difference in overhead of using this library vs writing it in Go or similar seems small.

                      1. 2

                        I find that shell code very quickly becomes hard to read as the script’s complexity increases; the syntax just isn’t as clear and explicit as that of something like Ruby or JavaScript. As to why you’d choose one over the other, I hear people have pretty strong preferences when it comes to languages :)

                        1. 6

                          I think that bash gets a bad rep in this way. However, I think it’s not because the language is bad but because everyone treats every script in it as a quick-and-dity hack. You do that in any language and you’ll get the same problem.

                        2. 2

                          We use node for a lot of the glue scripts in our project - it’s easier than bash, works cross-platform, and because our project is already javascript we all both know the language and have the runtime installed.

                          1. 1

                            Ruby does indeed have anything you might need out of the box, and shelling out is just a matter of writing the command in backquotes. The only pain point is that when you need to both read the output of a command and get its status code you have to use popen3 which I always found to have a clunky API.

                            1. 3

                              Sure, but any clunkier than we’ve got using node now?

                          1. 7

                            So that example is essentially just rm dir/*.ext? Or find dir -name '*.ext' -delete (not clear to me if your version is recursive or not)? I’m not so convinced your JS version is that much better to be honest.

                            1. 3

                              Yep, that’s exactly what it does! For simple examples like this, you’ll often find the shell version to be more straightforward, but as soon as what you’re trying to achieve is more tortuous (with branching, user input, etc) I think Tasklemon allows the whole logic to be laid out in a much more readable way.

                              1. 3

                                Right; it may be worthwhile to think of an example that better illustrates the strengths of your library. I don’t disagree that larger shell scripts can become unwieldy (I even wrote an entire article about it a while ago), but that doesn’t automatically mean that any alternative is better.