robinm

@robinm@programming.dev

• ⁨Comment⁩ on ⁨[deleted]⁩ ⁨⁨9⁩ ⁨months⁩ ago⁩:

  If you have references explain why and how that it’s easier to port C to a new architecture by creating a new compiler from scratch than to either create a backend for llvm (and soon gcc) or to create a minimal wasm executor (like what zig is doing) to this new architecture I’m interested. And of course I talking about new architectures because it’s much easier to recreate something that as already be done before.

• ⁨Comment⁩ on ⁨[deleted]⁩ ⁨⁨9⁩ ⁨months⁩ ago⁩:

  I’m not familiar with C tooling, but I have done multiple projects in C++ (in a professionnel environnement) and AFAIK the tooling is the same. Tooling to C++ is a nightmare, and that’s and understatement. Most of the difficulty is self inflicted like not using cmake/meson but a custom build system, relying on system library instead of using Conan or vcpkg, not using smart-pointers,… but adding basically anything (LSP, code coverage, a new dependency, clang-format, clang-tidy, …) is horrible in those environments. And if you compare the quality of those tools to the one of other language, they are not even close. For exemple the lint given by clang-tidy to the one of Rust clippy.

  If it took no more than an hour to add any of those tools to a legacy C project, then yes it would be disingenuous to not compare C + tooling with Rust, but unfortunately it’s not.

• ⁨Comment⁩ on ⁨Unison | A friendly, statically-typed, functional programming language from the future · Unison programming language⁩ ⁨⁨11⁩ ⁨months⁩ ago⁩:

  I would even have said that both throwing and catching should be pure, just like returning an error value/handling should be pure, but the reason for the throw/returning error itself is impure. Like if you throw and ioerror it’s only after doing the impure io call, and the rest of the error reporting/handling itself can be pure.

• ⁨Comment⁩ on ⁨Unison | A friendly, statically-typed, functional programming language from the future · Unison programming language⁩ ⁨⁨11⁩ ⁨months⁩ ago⁩:

  I’m surprised about this statement, I would have said that exceptions are the consequence of an impure operation (that may or may not fail differently every time you call it).

• ⁨Comment⁩ on ⁨Unison | A friendly, statically-typed, functional programming language from the future · Unison programming language⁩ ⁨⁨11⁩ ⁨months⁩ ago⁩:

  There take on what they call capabitilites is very interesting. Basically anything that would make a function non-pure seems to be declared explicitely.

  A computational effect or an “effectful” computation is one which relies on or changes elements that are outside of its immediate environment. Some examples of effectful actions that a function might take are:

  writing to a database throwing an exception making a network call getting a random number altering a global variable

• ⁨Comment⁩ on ⁨Fossil: A Git alternative with batteries included⁩ ⁨⁨11⁩ ⁨months⁩ ago⁩:

  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.

• ⁨Comment⁩ on ⁨Fossil: A Git alternative with batteries included⁩ ⁨⁨11⁩ ⁨months⁩ ago⁩:

  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.

• ⁨Comment⁩ on ⁨Fossil: A Git alternative with batteries included⁩ ⁨⁨11⁩ ⁨months⁩ ago⁩:

  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

  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.

• ⁨Comment⁩ on ⁨Blind Developer Interviews Through Anonymized Remote Pairing - An Experiment⁩ ⁨⁨11⁩ ⁨months⁩ ago⁩:

  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.

• ⁨Comment⁩ on ⁨Mozilla will move Firefox development from Mercurial to Microsoft’s GitHub⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

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

• ⁨Comment⁩ on ⁨[deleted]⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  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.

• ⁨Comment⁩ on ⁨Which language you wish would really grow and reach mainstream adoption?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  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.

• ⁨Comment⁩ on ⁨The Absolute Minimum Every Software Developer Must Know About Unicode in 2023 (Still No Excuses!)⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  I do understant why old unicode version re-used “i” and “I” for turkish lowercase dotted i and turkish uppercase dotless I, but I don’t understand why more recent version have not introduce two new characteres that looks exactly the same but who don’t require locale-dependant knowlege to do something as basic as “to lowercase”.

• ⁨Comment⁩ on ⁨Linux Terminal Emulators Have The Potential Of Being Much Faster⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Just toebe sure, what’s the name of this new terminal emulator? termkit?

• ⁨Comment⁩ on ⁨When a Programmer Holds the Code Hostage: The costs of a policy of appeasement⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  That’s true. But at least you will have evidence that Martin doesn’t conform to the team rules.

• ⁨Comment⁩ on ⁨Linear code is more readable⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  One way to make it obvious which function can be called at which state is to use different type. Like UnbackedPizzà and CookedPizzà, and the bake function takes the former and returns the later.

• ⁨Comment⁩ on ⁨When a Programmer Holds the Code Hostage: The costs of a policy of appeasement⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  If your hierarchy is trying to destroy the product you create, just leave. You are not the main stackholder, and do not get benefits from the well-being of your product. The only things that should be importants as and an employee are “is my job interesting” and “are the work conditions great”. If you have to fight your management, they have already lost you because they just broke your trust, as well as the second point.

• ⁨Comment⁩ on ⁨I wonder how many fires have been started because people have left the pizza box in the oven while trying to keep it warm⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Cardboards are actually quite good at heat insulation. If you have an electric oven (no flame) and put the temperature below 200°C (ignition is at a slighly higher temperature but oven aren’t precise), there is no risk. So you can totally reheat pizza at 180°C on its cardboard.

• ⁨Comment⁩ on ⁨When a Programmer Holds the Code Hostage: The costs of a policy of appeasement⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  That’s well written. I think that requiered 2+ code review could also help because with time more people will gain knowledge of the dark parts of the codebase, just by reviewing the PR of “Martin” when he work on them.

• ⁨Comment⁩ on ⁨What benefits do you get for being on-call? - programming.dev⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Same in France

• ⁨Comment⁩ on ⁨What would it take for you to move away from Github?⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Lol. I read “Other oysters gaining more popularity”, and found it very appropriate !

• ⁨Comment⁩ on ⁨Why Linux is better for (most) developers!⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  And cgb is kind of the same but with better controls and syntax coloration.

• ⁨Comment⁩ on ⁨Opinions on how to deal with duplicate code.⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  There are 2 metrics that need to be considered:

  • easy to read
  • easy to modify

  The first point is by far the most important. Usually DRY win because less code means less to read so less to put in your head. But if the abstraction is too complicated (for example because there are two many parameteres) then it’s worth considering drying.

  And don’t forget the second point, but do not overthing and YAGNI. Sometime a simple comment “don’t forget to update method foobar()” is enough. Don’t forget either that you can always rewrite the abstraction when you need to modify something (if the original did not fit your new requirements), but for this to be an easy task, the understanding of the original abstraction must be crystal clear. That’s why the first point is so important.

• ⁨Comment⁩ on ⁨4 year old got her first linux kernel patch accepted⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  And you should not forget that Emacs is way harder when you are 4 because your hands are smaller!

• ⁨Comment⁩ on ⁨4 year old got her first linux kernel patch accepted⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  So cute!