• 1 Post
  • 21 Comments
Joined 1 year ago
cake
Cake day: June 27th, 2023

help-circle

  • One problem with exceptions is composability.

    You have to rely on good and up-to-date documentation or you have to dig into the source code to figure out what exceptions are possible. For a lot of third party dependencies (which constitute a huge part of modern software), both can be missing.

    Error type is a mitigation, but you are free to e.g. panic in Rust if you think the error is unrecoverable.

    A third option is to have effect types like Koka, so that all possible exceptions (or effects) can be checked at type level. A similar approach can be observed in practical (read: non-academic) languages like Zig. It remains to be seen whether this style can be adopted by the mainstream.









  • If you execute a binary without specifying the path to it, it will be searched from the $PATH environment variable, which is a list of places to look for the binary. From left to right, the first found one is returned.

    You can use which cat to see what it resolves to and whereis cat to get all possible results.

    If you intentionally wants to use a different binary with the same name, you can either directly use its path, or prepend its path to $PATH.





  • The original “agile” is a reaction to the overly rigid planning and emphasizes worker self-management. It makes sense since the people who are closest to the work (the workers) know best how to plan and implement the work.

    It immediately breaks down when a specialized management tier emerges and tries to push their own agenda, i.e. to sell themselves rather than do something meaningful.

    At this point, whichever form is used doesn’t matter. The management, endowed with the power from above, will exploit the weakness of any agile-shmagile methodology to push their own agenda.



  • To be good at programming, a lot of knowledge is needed, but “accidental”. From practical ones like how to use git, to conceptual ones like cache performance mental model. It’s perfectly possible that git is designed with a different CLI, or the common cache line size being 512 bytes. Mathematicians usually don’t care about these things, since they are accidental. So they are bad at writing programs that’s far away from math.

    It’s a completely different story when they are writing programs about math. If the tool is good enough, i.e. allowing them to express math ideas in familiar terms, mathematicians are very good at writing math programs. As can be observed in Lean and mathlib.




  • Thank you for raising the question. I think it’s an important one to think about. I constantly hear about good things about the REPL experience of LISP family languages. You can set up a code fragment (the test in your example) to run constantly in the background as you edit. Then you can jump to the REPL anytime and interact with the state.

    I myself am more on the ML-family side of FP, where you’d encode the expected behavior with an expressive type system and work with the type checker (the smart compiler) to implement that behavior.

    One important thing to note is that the type checking process is also a fast feedback loop. The difference is that it’s often on the abstract level and you’re more concerned about the expected behavior instead of the actual behavior.

    It’s harder to write, but the advantage is that you’ll have more confidence once it type checks.

    Of course, the two styles are not mutual exclusive, just that the tooling ecosystem will often reflect the culture of that language family. And it’s easier to add a simple watch make task, but harder to go the other way around.