Hey yall, made a cool little terminal app the other day. Since most terminals can't display images or set pixels, my app converts images into special Unicode characters and ANSI colors to render an image roughly in the terminal.
I find this kind of handy to inspect images in the terminal without having to open another window to view them.
I wrote this in C which was kind of fun. I think it might have been easier in another language, but I chose C since it's likely to still work in 10 to 20 years with no app maintenance on my part.
Here's the github repo if you'd like to use it or give it try: https://github.com/wbf22/terminal_images
Here's an example image and the result of displaying that image with my app
Thoughts
I think one of my favorite things about C is its unchangingness. Lots of languages have constant updates which often means something you write now won't work in 5 years (at least if your trying to use the most recent language version). Some languages have a better way to lock the language version but it still often makes setup difficult.
Another thing I love about the C community is the emphasis on single header file libraries. These are really convenient as you can just copy them into your project. Then your app won't break when the dependency manager remote is shutdown or moved.
However this system also has drawbacks. Without dependency management, it's much harder to stay up to date with the latest versions of your dependency. This can be more critical for things that have to do with security.
Something I've found working in the industry the past few years is that there's a trade space with dependencies. Using them means faster development and not having to writing boilerplate code. It also means you can piggy-back on other people's expertise, especially when it comes to security. But it also means future tech debt as new versions come and old ones loose support. So it's basically a trade between ease and industry-standards, and longevity.
It's interesting that people used to say that 'hardware comes and goes, but software lives forever'. It kind of feels like now software only lives 5 years, especially when it's built on top of constantly changing dependencies.
In the end, it really depends on what kind of project or system you're making. Are you doing rapid development with constantly changing requirements? Or is this something you want to build and then have last forever? It's good to think about these things when choosing to use frameworks or dependencies.
Top comments (1)
Fun!