Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)R

robinm

@ robinm @programming.dev

Posts
2
Comments
133
Joined
2 yr. ago

  • Fossil: A Git alternative with batteries included

    Jump

  • 2019, so 4-5 years ago so not that recent but not ancient either. But unfortunately tutorials have not been updated.

    I would say that the biggest benefit of git switch is that you can't switch to a detached state without using a flag (--detached or -d). If you do git co $tag or git co $sha-1 you may get at one point the error “you are in a detached state” which is ununderstable for begginers. To get the same error with git switch you must explicitely use git switch --detached $tag/$sha-1 which makes it much easier to understand and remember that you are going to do something unusual.

    More generally it's harder to misuse git switch/git restore. And it's easier to explain them since the only do one thing (unlike git checkout which is a mess !).

    So if it's only for you git checkout is fine, but I would still advice to use git switch and git restore so you will have an easier time to teach/help begginers.

  • Fossil: A Git alternative with batteries included

    Jump

  • If you try to learn git one command at a time on the fly, git is HARD. If you take the time to understand its internal data structure it's much, much easier to learn. Unfortunalely most people try to do the former because it works well (or better) for most tasks.

    I can't recommand enough the git parable.

  • Making it harder to do wrong | daniel.haxx.se

    Jump

  • That’s a very, very good read on how to make a very complex C project safer in practice. To sum-up: make it possible to introduce new module in a memory safe language (Rust in this case), make it harder to write bugs in C since the C part is not going to disappear overnight, and use as much tooling as you can to find any existing or newly introduced bugs (both memory bugs a logique error).

  • Fossil: A Git alternative with batteries included

    Jump

  • I am always doubtful when people say that accessing information inside git is hard. I totally agree that defaults in git can be improved (and they are, git restore and git switch are a much better alternative to git checkout that I no longer use). So let’s review the section “A Few Reasons Why SQLite Does Not Use Git”:

    “Git does not provide good situational awareness”

    git log --graph --oneline --author-date-order --since=1week

    Make it an alias if you use it often. Alias is what helps you create your own good default (until everyone uses the same alias and in that case it should be part of the base set of commands).

    “Git makes it difficult to find successors (descendants) of a check-in”

    git log --graph --oneline --all --ancestry-path ${commit}~..

    Likewise you could consider making it an alias if you use it often. Aliases can also be used as a post-it to help you remember what are the command that you find useful but you only use once in a blue moon!

    The mental model for Git is needlessly complex

    I may agree about that one. For reference, this is what the article says:

    A user of Git needs to keep all of the following in mind: The working directory The "index" or staging area The local head The local copy of the remote head The actual remote head

    If git fetch was run automatically every so often, as well as git push (of course in a personal branch), then this model could be simplified as

    • the working directory
    • the “index” or staging area (I actually think that being able to have more than one for drafting multiples commit at once, like a fix and a feature at the same time would be better than only having a single index)
    • your working copy of the shared branch
    • the shared branch

    And integrating your changes (merging/rebasing) should probably be exclusively done using a PR-like mechanism.

    Git does not track historical branch names

    I’m skeptical about the usefulness of this. But since git was my first real vcs (10 years ago), it may just be that I have not used a workflow that took advantaged of persistant branches. I assume that git annotate could be a solution here.

    Git requires more administrative support

    most developers use a third-party service such as GitHub or GitLab, and thus introduce additional dependencies.

    That’s absolutely true but I’m not sure it’s a real issue. Given how many strategies there are for CI/CD (and none is the definitive winner yet) I do think that being able to select the right option for you/your team/your org is probably a good idea.

    Git provides a poor user experience

    https://xkcd.com/1597/

    I highly disagree about that xkcd comics. Git is compatible will all workflows so you have to use a subset of all the commands. Of course you will have more commands that you never use if a software is usable for all the workflow that you don’t use. But you need about 15 commands to do stuff, 30 to be fluent, and some more to be able to help anyone. Compared to any other complex software that I use I really don’t think that it’s an unreasonably high count. That being said I totally agree that git from 10+ years ago was more complex and we should correctly teach what is needed to junior. HTML/css/js is a nightmare of complexity but it doesn’t stop 15 years old kid with no mentoring to build cool stuff because you don’t need to know everything to be able to do most of the things you may think of, just a good minimal set of tools. And people should definitively take the time to learn git, and stop using outdated guide. Anything that don’t use git switch, git restore and git rebase --interactive and presents you have to inspect the history in length (git log --graph or any graphical interface that show the history in a graph, git show, and more generally than you can filter the history in any way you want, being by author, date, folder, file type, …) is definitively not a good guide.

    To sum-up, I think that from this presentation fossil seems more opinionated than git which means that it will be simpler as long as your workflow exactly matches the expected workflow whereas using git requires to curate its list of commands to select only the one useful for yours.

  • Cargo cache cleaning | Rust Blog

    Jump

  • That's really a nice addition

  • Blind Developer Interviews Through Anonymized Remote Pairing - An Experiment

    Jump

  • That's an interesting idea, but as someone else pointed using a voice modulator would be much better. Technical skills are importants, but human behaviors too. I would not trade a nice average coworker for someone who is better technically but doesn't know how to communicate. And typing is complementary, not a replacement for voice communication since the amont of information you can share in a minute is 3-5 times higher by voice.

  • Rustlantis: Semantic fuzzing of the Rust compiler and interpreter [pdf]

    Jump

  • That's extremely interesting and clear at the same time. This thesis is definitively a gem!

  • Rust Programming - The State of Developer Ecosystem in 2023 Infographic

    Jump

  • I don't agree with the sentiment that debuggers are sub-optimal for Rust and that's why they are not used. In C++, I hop in gdb all the time, and I'm very fluent with it. But I never had the need for it in Rust. So they may be sub-optimals, IDK, I never had an issue in Rust where the best tool would have been a debugger.

    I would never do printf debugging in C++ because it's too complicated to do. In Rust with Display/Debug it's a breeze. And my best debugger for Rust is the compiler itself. But most importantly, most of my bugs are caught at compile time. The few remaining one are logic error and best analyzed with logging, aka printf debugging, and not a debugger that can pause the execution.

  • قلب | a non ascii programming language that uses arabic script

    Jump

  • What do you mean by that?

  • [Blog] Eyra does the impossible

    Jump

  • It seems extremely interesting.

  • Monaspace

    Jump

  • Something that I have never understood is why code ligature often try to combine two or more symbols into a single one. I like a lot what they did with “(” by fixing the vertical alignment of the “” while still keeping two separate symbols. I personally prefers when the number of symbols is preserved instead of merging them (like for “>=”).

  • Monaspace

    Jump

  • I find “texture healing” a fantastic idea. It does indeed increase the readability of monospace font, without making them non-monospace.

  • [advice] How do you learn with brain fog and bad memory?

    Jump

  • You seems to have a severe issue so I'm not sure what I'm going to say may help.

    Learning something and then forgeting it is absolutely normal. Repetition over and exponentially long time and sleep in between helps a lot. Some people use flashcards to helps with memorisation. The idea is simple, when you learn something you write question + answers on a piece on paper (usually bristol for easy manipulation) and put it in a box. This box has multiple compartment: every day, every second day, once a week, once every second week, once every second month for example. When you add a card you add it to the “every day” compartment. Then each day you open all the compartment of the current day and ask yourself all the questions. If you correctly remember the answer you put it in the next compartment, and if you don't you put it back to the “every day” one.

    Another way to helps you understand and rembembering things is to explain them to others. If you don't have someone to explain what you just learn you can create youtube video (even if noone will watch them but you do as if you had an audience). As bonus you now have a video that explains using your language something you just learn if you ever forget it!

  • Mozilla will move Firefox development from Mercurial to Microsoft’s GitHub

    Jump

  • Moving to git is nice but I don't understand why they don't self-host a gitlab instance.

  • Deleted

    Permanently Deleted

    Jump

  • step 1: learn to comment everything. This will helps code reviewer to catch errors because your code doesn’t match the comments

    step 2: write your code in a way that makes comments useless and stop writting them

    step 3: write your code just like you did in step 2, but documents all the things that you didn’t do, or why the code is more complicated than the naive approach. If your arguments are weak you are not in step 3, but in step 1.

  • Deleted

    Permanently Deleted

    Jump

  • It's especially true when you want to parse some json/xml/whatever. Just describe your datastuctures with regular struct and enum, add serde and done! It's like magic!

  • CSS is fun again

    Jump

  • Would encoding images in oklch before compressing them using jppeg or whatever is used for video compression helps to have much better dark while still keeping current compression ratio?

  • Which language you wish would really grow and reach mainstream adoption?

    Jump

  • Syntax has never really be an issue. The closest thing to plain english programming are legal documents and contracts. As you can see they are horrible to understand but that the only way to correctly specify exactly what you want. And code is much better at it. Another datapoint are visual languages like lego mindstorm or LabView. It's quite easy to do basic things, but it doesn't scale at all.

  • Rob Pike's 5 Rules of Programming

    Jump

  • I highly agree with point 5. Having good datastructure is so important and helps so much.