• 7 Posts
  • 144 Comments
Joined 2 years ago
cake
Cake day: September 7th, 2023

help-circle
  • I wrote a program that scanned object files (compiled from a large C++ project) to see how they were interdependent. It was pretty useful for detecting cycles in the shared libraries that we were compiling from them, but the biggest benefit was it enabled me to very easily rewrite the build system from scratch.

    It was surprisingly simple - most ELF parsers can read a file and dump the symbol tables in them. (In this context, a symbol means a defined function, so if a C/C++ source file has int main() in it, the corresponding .o file will have a main symbol in it.) They also include information about which symbols are defined in the .o file, as well as which symbols it depends on which are undefined. This allows you to figure out a dependency graph, which you can easily visualize using graphviz or use to autogenerate build files for CMake or any other build system you may wish to use.

    In my case, I wrote this kind of program twice in two separate jobs. Both of them had a very janky build system using custom Makefiles. I used this program to rewrite the build systems in CMake. The graphviz dependency graphs are also just generally helpful to have as project documentation. CMake can do this natively, by the way - here’s the documentation for it: https://cmake.org/cmake/help/latest/manual/cmake.1.html#cmdoption-cmake-graphviz


  • I don’t even know where to start to make vim or neovim do all that. If it can’t do that seamlessly and just as well, vimlike editors will never be a replacement for a proper IDE. It’s fast, capable single file and small scope editor for me.

    If you’re interested in learning how to do it, I found this guide extremely helpful for getting started. it’s in both blog and video format, and it shows how to install Lazy (a package manager for vim), and which plugins to install to get LSP working (which is what would provide all the hotkeys that you were mentioning above).

    It’s definitely not a task for the faint of heart, but I found it very rewarding once I figured out how to work with the plugin systems because it’s so powerful and easy to customize. I found it helpful to just watch the video a few times to see everything working, then slowly started building up my own configuration (which was a bit more minimal than the linked guide I provided - I only installed about 30-40% of the plugins he listed on that page).

    Another alternative is Lazyvim, which provides an out-of-the-box configuration experience for you. It installs a lot of plugins and most things should work out of the box with very little configuration. It is a massive beast though, but still pretty good for a first start.


  • The funny thing is, before Google existed, people had no idea if their marketing attempts were working. Maybe they had some ways of knowing or guessing, but there was no way to know how accurate their metrics were. Internet-based advertising, and tracking-based advertising in particular was supposed to change that.

    And now that we sit here with a duopoly of advertising giants, we’re back to the stage where marketers just have to trust that their provider is giving them good helpful information. And how are they supposed to know whether they really can believe it or not? They can’t of course! So we’ve come right back to where we’ve started.

    But considering they still spent tons of money before Google and Facebook gave them these “analytics”, it looks like they probably don’t even care that much.



  • One principle I try to apply (when possible) comes from when I learned Haskell. Try to keep the low-level logical computations of your program pure, stateless functions. If their inputs are the same, they should always yield the same result. Then pass the results up to the higher level and perform your stateful transformations there.

    An example would be: do I/O at the high level (file, network, database I/O), and only do very simple data transformations at these levels (avoid it altogether if possible). Then do the majority of the computational logic in lower level, modular components that have no external side effects. Also, pass all the data around using read-only records (example: Python dataclasses with frozen=True) so you know that nothing is being mutated between these modules.

    This boundary generally makes it easier to test computational logic separately from stateful logic. It doesn’t work all the time, but it’s very helpful in making it easier to understand programs when you can structure programs this way.







  • Python’s type system is dramatically better than Javascript’s though. Try doing things like '' + True and Javascript will do incredibly stupid things. Python will just give you a type error. Also, look at things like == vs === in Javascript as well. That’s the biggest reason why Typescript replaced it overnight. Python has found a better balance between productivity and error safety.

    In my opinion, the biggest shortcoming of Python’s dynamic typing system is that you need to have very thorough test coverage to be sure that your code doesn’t have semantic errors (a lot more than, say, Java). It has gotten better with the introduction of type hints, those I don’t have much experience with them, so I can’t say how much.



  • Distribution usually isn’t considered a strong point for Python, though.

    It depends. If it’s a simple script with no external dependencies, then it’s very easy to distribute. But if your application has external dependencies and you are trying to install it on your host (and you aren’t using docker or similar technologies), then yes, it’s harder than just shipping an executable or .jar file. The fact that Python’s standard library is so comprehensive helps a lot in this regard, but it only works up to a certain point.





  • Pathlib is very nice indeed, but I can understand why a lot of languages don’t do similar things. There are major challenges implementing something like that. Cross-platform functionality is a big one, for example. File permissions between Unix systems and Windows do not map perfectly from one system to another which can be a maintenance burden.

    But I do agree. As a user, it feels great to have. And yes, also in general, the things Python does with its standard library are definitely the way things should be done, from a user’s point of view at least.


  • With regards to work arrangements, I’m open to considering all options at this point (both in terms of time and location). My original line of thought is to start with some contracting work on the side, and then slowly growing into a more full-time commitment if/when I find contracts that I like.

    UK-based advice would be perfectly fine for me! I’ve worked in both the EU and North America, and I have one friend who lives in the USA while working for companies in the EU, so crossing that time difference doesn’t seem to create too much of an issue. The hard part for me at the moment is just finding a source of contracts. I have been reaching out to a lot of acquaintances in my network but so far haven’t really manage to find anyone that’s willing to provide a contract just yet, so that’s mostly what I’m interested in knowing at the moment.



  • It’s a large and very complicated piece of software with a single implementation. It’s practically impossible to fork, so users are forced to adopt whatever changes the maintainers decide to implement. This could include things like forced dependencies (incompatible with mulb libc for example), or other poor design choices (like binary logging, which is very controversial). And it forces its adoption in places that do not want it (as in cases like the one we’re discussing here, where it’s becoming harder and harder for Gnome to be used without it).

    I’m not going to argue about whether systemd is good software or not. But the biggest problem with it is that it’s basically a way for Red Hat to exert control over the entire Linux ecosystem.

    Think of it like Chrome/Chromium. Everybody naïvely thought we were never be where we are today when it was announced, but look at where we are today. While it’s technically open source and an excellent browser, above all, it’s a tool for Google to exert its control over the WWW, such as disabling adblockers, implementing DRM, deciding which CSS/Javascript APIs should (or should not) be adopted, etc. systemd could very well be Red Hat’s vehicle for imposing similar requirements on desktop Linux.