8 ms·

I didn't say it in the post I wrote about C [1], but this is a big reason why I use C: I will have a hard time bloating my software. I can add features, yes, bu

I didn't say it in the post I wrote about C [1], but this is a big reason why I use C: I will have a hard time bloating my software. I can add features, yes, but adding a singular feature struggles to add even 100 kb to the executable. I don't work for anyone right now, but I do have a "work" machine. This machine is beefy. But I still run Neovim and tmux instead of an IDE. [2] I don't run a typical Linux distro; I use a heavily-modified Gentoo, and that includes using OpenRC over systemd. [3] I don't use a full desktop; I run a TWM called Qtile. [4] All of this is so my machine is not bloated. When my machine boots up, and I just barely log in, it is running only 40 processes (including the terminal and htop I use to check). As of right now, I'm engineering software. Truly engineering; I am spending the effort to effectively mitigate all of C's problems, while keeping the software lean and fast. I hope to someday build a business on that software. I guess I'll see if there even is a market for non-bloated, sleek software anymore. [1]: https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-in-memory-safety/ https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i... [2]: https://gavinhoward.com/2020/12/my-development-environment-and-how-i-got-there/ https://gavinhoward.com/2020/12/my-development-environment-a... [3]: https://gavinhoward.com/2023/06/an-apology-to-the-gentoo-authors/ https://gavinhoward.com/2023/06/an-apology-to-the-gentoo-aut... [4]: https://gavinhoward.com/2023/09/lessons-learned-as-a-user-3-prepare-for-the-future/ https://gavinhoward.com/2023/09/lessons-learned-as-a-user-3-...

usrnm 3y ago
> but adding a singular feature struggles to add even 100 kb to the executable Try supporting unicode
- gavinhoward 3y ago
  Heh, that is probably the exception that proves the rule!
vbtemp 3y ago
"I've turned down job offers because they were in C++" Yep
- nine_k 3y ago
  C++ is huge and highly interconnected. No matter whether you like it or dislike it, and how experienced you are with software development, you either invest years into becoming good at it, or stay away from C++ jobs.
- jrockway 3y ago
  If I was going to go back and time and offer younger myself career advice, I would probably say "just stick with C++". It was the most popular programming language when I started my career. It will be the most popular programming language when I end my career. Think about it. Is there any widely-deployed OS not written in C/C++? Any web browsers? Spreadsheets? CAD software? Text editor?
  - pdimitar 3y ago
    Having as much experience as you do and still conflating "widely used because it's super good" and "widely used because of network effects and inertia" is really puzzling. Surely you understand that your argument is disingenuous, right? Nobody wants to start over a new OS or a browser in another language due to the huge costs that no corporation nowadays is willing to shoulder (due to their own interests). Otherwise a lot of people would very definitely write OS-es and browsers in Rust, D, V even, Zig, Nim and a good amount of others. C/C++ were there first, that's all there is to it, it's that simple.
benkillin 3y ago
Heh... > ... I use a heavily-modified Gentoo ... Need not say more :)
- gavinhoward 3y ago
  Hey, it works for me. Besides, I struggled with sysadmin-type tasks until I bit the bullet and installed Linux from Scratch and then Gentoo. It was one of my best educational investments.
giraffe_lady 3y ago
I would say truly engineering would be contextualizing these decisions along a spectrum of tradeoffs and positioning your project on that spectrum according to the constraints of its creators and users. That may put you to one extreme of the continuum, but that doesn't mean people whose constraints land them elsewhere are not doing "true engineering." "I am going to build the strongest, lightest bridge in the world" is a marvel. "I am going to build a light-enough strong-enough bridge for a cost my client can afford" is engineering.
- gavinhoward 3y ago
  Sure, if they are considering tradeoffs. But a sign of considering tradeoffs is that every project seems to be just a little different because every circumstance is just a little different. When you have a software monoculture or monocultures, it's likely that tradeoffs are being ignored.
  - anjel 3y ago
    The problem is it's trade-offs on top of trade-offs, all the way down.
  - Nasrudith 3y ago
    Trade-offs also get a bit meta with "standardization" one way or another. Sure you could get peak performance if you made custom length and width screws but it boosts costs and makes it harder to maintain with the one-offs. Going with trade-offs is itself a tradeoff which means monoculture breeds a pattern of ignoring the tradeoffs.
- kayo_20211030 3y ago
  Hear! Hear! Engineering is a practical discipline - and it is a discipline. It's building for purpose. I appreciate Tonsky's point, and agree with much of it, but engineering means turning out into the world things that are fit for purpose, however that's defined. Purpose is +100 and all the rest is something of less than 100. Mathematics is mathematics, science is science and engineering is engineering.
bheadmaster 3y ago
> As of right now, I'm engineering software. Truly engineering; I am spending the effort to effectively mitigate all of C's problems, while keeping the software lean and fast. Can you expand on that? Which exact problems of C's are you working on solving? Do you mean the language itself (writing a new dialect of C), or the ecosystem (e.g. impossibility of static linking with glibc)? Or something else entirely?
- gavinhoward 3y ago
  Unsafety. My blog post about C has a blurb about how I'm really writing in a partially memory-safe portable dialect. I have bounds checks, structured concurrency (to mitigate use-after-free and double-frees), and a bunch of other stuff.
  - trealira 3y ago
    Since you care about these things, why not try a language that has scoped threads and bounds checking built in, like Rust or Ada? Actually, I had written more about Rust and Ada, but then I read your blog, and it says you like C better anyway because you find it more fun, so nevermind. You might also like to use D in its "Better C" mode, which at least offers bounds-checked arrays and sliced, as well as some other features, while being very similar to C. https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html
deleted 3y ago
[deleted]
selfmodruntime 3y ago
All this work and you don't earn money with your style of engineering. Have you maybe stopped and wondered why you don't?
- gavinhoward 3y ago
  I know exactly why: I haven't started marketing yet. :) After I get to MVP and actually try marketing, we'll see what happens.
  - danenania 3y ago
    Not to pick on you—this is something I and most other engineers also struggle with—but I think this sums up the reason for most of the complaints in this thread. That is: builders who prioritize marketing outcompete those who prioritize engineering quality. Making something people want enough to pay for is very difficult; if you are trying to do that while also imposing a bunch of other constraints on yourself that have no clear marketing benefits, your odds of success go down a lot. Engineering excellence can sometimes be used successfully as a form of marketing in itself and you could well pull this off, as your content is super engaging and well-written. But I would suggest to every engineer to consider Chesterton’s fence. Why is all the winning software in every category slow and bloated and seemingly unconcerned with engineering excellence? Is it because everyone involved, the engineers that build it and the customers that buy it, are all technical philistine morons? Or is it because the products that win in the market prioritize… winning in the market, and all their competitors that don’t prioritize that for whatever reason fall by the wayside?
    - uoaei 3y ago
      Here is how the main factor incentivizing this sloppy engineering behavior is justified: everything is cast in terms of making money. Revenue is good -- fine. Therefore no revenue is bad -- doesn't follow and you need to justify that somehow.
      - danenania 3y ago
mortallywounded 3y ago
Ever tried HolyC?
jasode 3y ago
>, but this is a big reason why I use C: I will have a hard time bloating my software. Your perspective is interesting because I'm old enough to remember when the C Language was considered bloat compared to just writing it in assembly language. Examples of 1980s programs in assembly was WordPerfect, Lotus 123, MS-DOS 1.0. SubLogic Flight Simulator (before Microsoft bought it) was also in assembly. Back then, industry observers were saying that MS Word and MS Excel being written in "bloated" C was a reason that Microsoft was iterating on new features faster and porting to other architectures sooner than competitors WordPerfect and Lotus 123 because they stayed with assembly language too long. (They did eventually adopt C.) I see this "bloat-vs-lean" tradeoff in my own software I write for my private use. I often use higher-level and "bloated" C#/Python instead of the leaner C/C++ because I can finish a particular task a lot faster. In my case I'm more skilled in C++ than C# and prefer leaner C++ executables but those positives don't matter when C# accomplishes a desired task in less time. I'm part of the bloated software problem!
- gavinhoward 3y ago
  For your own private use, I see no problem with that. It's all tradeoffs; and finding the sweet spot for every particular insurance. I believe the article is complaining that people just blow past the sweet spot. In your case, C# is the sweet spot. In my case, I expect customers will want speed; I'm building an interpreter for a programming language.
- dijit 3y ago
  is there not, a minor hint of irony here, that when I think of bloated software my mind goes almost immediately to everything Microsoft creates (except VSCode, which is somehow the most performant software they've created despite being written in a language that is theoretically slow)
  - BirAdam 3y ago
    There was a time when Microsoft wrote extremely lean code, and BillG in particular. Best example: TRS-80 Model 100.
ho_schi 3y ago
Using Arch with GNOME, VIM/NEOVIM. Happy value between usability and resource usage. The programmers on Linux usually care about efficiency. Christian Hegert is improving recently a lot in GNOME. This allows me to use a ThinkPad X220 which is running circles around some modern laptops with Windows. I understand that people prefer the small footprint of C. I like C. My personal preference is C++ (low- and high-level, more safety and flexibility). The problem is greed - i.e. capitalism. The blog mentions Electron and therefore Chrome and JavaScript. They are awful combination and allow companies to save on programmers. Programmers which handle C, C++, Rust or Python are a small group. Java, C# and JavaScript consume more resources, allow using a lot more stuff quicker (like a drug) and most importantly are forgiving mistakes. So the industry decides to waste the resources on our computers because they don’t need to buy and maintain them. The customer pays twice, for the software and the next computer with more soldered main-memory. The key point is - the software companies don’t pay for hardware or the environmental damage! I’m doing myself a little JavaScript and some Java. Efficiency? Nobody ask for that and I should not spend time on it. There is now law stating that managed languages need to waste resources but a side-effect. Remember Steve Jobs? I don’t appreciate what Apple does. But he banned Flash for a reason. Resources! Okay. Also bugs. And for the same reason they should ban Electron. Apple devices run faster with less resources because Apple saves on hardware. Why build devices with huge batteries, when you can achieve more runtime with less material and take the same money? The EU needs to enforce side-loading on the iPhone. But I also think Apple should be allowed to keep Blink (and therefore Electron) banned from AppStore. I don’t want see my battery dying because some corporate manager decided to drain it. But if you need Blink? Side load.
- Karellen 3y ago
  What usability features of Gnome do you find indispensable that prevent you from moving to a lighter-weight DE, like LXDE, XFCE or Cinnamon?
  - ho_schi 3y ago
    High keyboard focused usage with focus on the application-window. I specifically like to enter just “terminal” and the terminal open, either a new window or already open on. I also Alt+Tab but with many open applications finding is more convenient. Another thing is that it is also easy to use with the mouse and the overview makes that pleasant (good for novice users). They eliminated the unappropriate “desktop metaphor” from Windows 95 and the “system tray”. The negative side is that GNOME often removes options or hides them - which drives away experienced users (the people needed to pull in new users) and some developers to forks. The are right to not support every bewildering option but the needed ones must in place despite the UX people don’t use them itself. https://ometer.com/free-software-ui.html https://ometer.com/free-software-ui.html Some of this is right. Do stuff automatically right and don’t provide unneeded options to avoid complexity. Some not! Also provide required preferences e.g. “Do not suspend on LID close” because some people don’t want that! The GNOME people assumed it was needed as option because of problems with suspend (S3) in the past. Maybe people used it to bypass issues but that isn’t the use case of the preference. Another thing is “When you’ve five clock applets” I want to know what is missing from the first one which made all the others necessary. GNOME learned that people don’t need an “Emacs” as UI-Shell but somewhat went into the other extremes. PS: And GNOME just looks good by default. I don’t need themes because it is fine.
eternityforest 3y ago
I think there might be a market mostly with other engineers like you. Lots of people seem to really love this stuff, look at the forth crowd and how much they adore the language. For me... I don't notice any slowness or excessive battery drain in VS Code, so I just use that. Perhaps there's something deeply wrong with my psychology, but I'm just not very interested in simplicity for its own sake. It's cool, but not an approach I'd want to use every day in real life.
commandlinefan 3y ago
> I will have a hard time bloating my software I wonder how much of this is just because when a project manager comes along and says "as a system administrator, I want to be able to log all of the keystrokes of the users and reports who's slacking to the boss", you say, "ok, that feature will take about two weeks to implement" and they can't argue with you because it's C so they just go away and leave you alone.
- gavinhoward 3y ago
  The truth is that I don't have a project manager, another reason it's hard for me to bloat my software. :)

usrnm 3y ago

> but adding a singular feature struggles to add even 100 kb to the executable Try supporting unicode

gavinhoward 3y ago
Heh, that is probably the exception that proves the rule!

vbtemp 3y ago

"I've turned down job offers because they were in C++" Yep

nine_k 3y ago
C++ is huge and highly interconnected. No matter whether you like it or dislike it, and how experienced you are with software development, you either invest years into becoming good at it, or stay away from C++ jobs.
jrockway 3y ago
If I was going to go back and time and offer younger myself career advice, I would probably say "just stick with C++". It was the most popular programming language when I started my career. It will be the most popular programming language when I end my career. Think about it. Is there any widely-deployed OS not written in C/C++? Any web browsers? Spreadsheets? CAD software? Text editor?
- pdimitar 3y ago
  Having as much experience as you do and still conflating "widely used because it's super good" and "widely used because of network effects and inertia" is really puzzling. Surely you understand that your argument is disingenuous, right? Nobody wants to start over a new OS or a browser in another language due to the huge costs that no corporation nowadays is willing to shoulder (due to their own interests). Otherwise a lot of people would very definitely write OS-es and browsers in Rust, D, V even, Zig, Nim and a good amount of others. C/C++ were there first, that's all there is to it, it's that simple.

benkillin 3y ago

Heh... > ... I use a heavily-modified Gentoo ... Need not say more :)

gavinhoward 3y ago
Hey, it works for me. Besides, I struggled with sysadmin-type tasks until I bit the bullet and installed Linux from Scratch and then Gentoo. It was one of my best educational investments.

giraffe_lady 3y ago

I would say truly engineering would be contextualizing these decisions along a spectrum of tradeoffs and positioning your project on that spectrum according to the constraints of its creators and users. That may put you to one extreme of the continuum, but that doesn't mean people whose constraints land them elsewhere are not doing "true engineering." "I am going to build the strongest, lightest bridge in the world" is a marvel. "I am going to build a light-enough strong-enough bridge for a cost my client can afford" is engineering.

gavinhoward 3y ago
Sure, if they are considering tradeoffs. But a sign of considering tradeoffs is that every project seems to be just a little different because every circumstance is just a little different. When you have a software monoculture or monocultures, it's likely that tradeoffs are being ignored.
- anjel 3y ago
  The problem is it's trade-offs on top of trade-offs, all the way down.
- Nasrudith 3y ago
  Trade-offs also get a bit meta with "standardization" one way or another. Sure you could get peak performance if you made custom length and width screws but it boosts costs and makes it harder to maintain with the one-offs. Going with trade-offs is itself a tradeoff which means monoculture breeds a pattern of ignoring the tradeoffs.
kayo_20211030 3y ago
Hear! Hear! Engineering is a practical discipline - and it is a discipline. It's building for purpose. I appreciate Tonsky's point, and agree with much of it, but engineering means turning out into the world things that are fit for purpose, however that's defined. Purpose is +100 and all the rest is something of less than 100. Mathematics is mathematics, science is science and engineering is engineering.

bheadmaster 3y ago

> As of right now, I'm engineering software. Truly engineering; I am spending the effort to effectively mitigate all of C's problems, while keeping the software lean and fast. Can you expand on that? Which exact problems of C's are you working on solving? Do you mean the language itself (writing a new dialect of C), or the ecosystem (e.g. impossibility of static linking with glibc)? Or something else entirely?

gavinhoward 3y ago
Unsafety. My blog post about C has a blurb about how I'm really writing in a partially memory-safe portable dialect. I have bounds checks, structured concurrency (to mitigate use-after-free and double-frees), and a bunch of other stuff.
- trealira 3y ago
  Since you care about these things, why not try a language that has scoped threads and bounds checking built in, like Rust or Ada? Actually, I had written more about Rust and Ada, but then I read your blog, and it says you like C better anyway because you find it more fun, so nevermind. You might also like to use D in its "Better C" mode, which at least offers bounds-checked arrays and sliced, as well as some other features, while being very similar to C. https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html

deleted 3y ago

[deleted]

selfmodruntime 3y ago

All this work and you don't earn money with your style of engineering. Have you maybe stopped and wondered why you don't?

gavinhoward 3y ago
I know exactly why: I haven't started marketing yet. :) After I get to MVP and actually try marketing, we'll see what happens.
- danenania 3y ago
  Not to pick on you—this is something I and most other engineers also struggle with—but I think this sums up the reason for most of the complaints in this thread. That is: builders who prioritize marketing outcompete those who prioritize engineering quality. Making something people want enough to pay for is very difficult; if you are trying to do that while also imposing a bunch of other constraints on yourself that have no clear marketing benefits, your odds of success go down a lot. Engineering excellence can sometimes be used successfully as a form of marketing in itself and you could well pull this off, as your content is super engaging and well-written. But I would suggest to every engineer to consider Chesterton’s fence. Why is all the winning software in every category slow and bloated and seemingly unconcerned with engineering excellence? Is it because everyone involved, the engineers that build it and the customers that buy it, are all technical philistine morons? Or is it because the products that win in the market prioritize… winning in the market, and all their competitors that don’t prioritize that for whatever reason fall by the wayside?
  - uoaei 3y ago
    Here is how the main factor incentivizing this sloppy engineering behavior is justified: everything is cast in terms of making money. Revenue is good -- fine. Therefore no revenue is bad -- doesn't follow and you need to justify that somehow.
    - danenania 3y ago

mortallywounded 3y ago

Ever tried HolyC?

jasode 3y ago

>, but this is a big reason why I use C: I will have a hard time bloating my software. Your perspective is interesting because I'm old enough to remember when the C Language was considered bloat compared to just writing it in assembly language. Examples of 1980s programs in assembly was WordPerfect, Lotus 123, MS-DOS 1.0. SubLogic Flight Simulator (before Microsoft bought it) was also in assembly. Back then, industry observers were saying that MS Word and MS Excel being written in "bloated" C was a reason that Microsoft was iterating on new features faster and porting to other architectures sooner than competitors WordPerfect and Lotus 123 because they stayed with assembly language too long. (They did eventually adopt C.) I see this "bloat-vs-lean" tradeoff in my own software I write for my private use. I often use higher-level and "bloated" C#/Python instead of the leaner C/C++ because I can finish a particular task a lot faster. In my case I'm more skilled in C++ than C# and prefer leaner C++ executables but those positives don't matter when C# accomplishes a desired task in less time. I'm part of the bloated software problem!

gavinhoward 3y ago
For your own private use, I see no problem with that. It's all tradeoffs; and finding the sweet spot for every particular insurance. I believe the article is complaining that people just blow past the sweet spot. In your case, C# is the sweet spot. In my case, I expect customers will want speed; I'm building an interpreter for a programming language.
dijit 3y ago
is there not, a minor hint of irony here, that when I think of bloated software my mind goes almost immediately to everything Microsoft creates (except VSCode, which is somehow the most performant software they've created despite being written in a language that is theoretically slow)
- BirAdam 3y ago
  There was a time when Microsoft wrote extremely lean code, and BillG in particular. Best example: TRS-80 Model 100.

ho_schi 3y ago

Using Arch with GNOME, VIM/NEOVIM. Happy value between usability and resource usage. The programmers on Linux usually care about efficiency. Christian Hegert is improving recently a lot in GNOME. This allows me to use a ThinkPad X220 which is running circles around some modern laptops with Windows. I understand that people prefer the small footprint of C. I like C. My personal preference is C++ (low- and high-level, more safety and flexibility). The problem is greed - i.e. capitalism. The blog mentions Electron and therefore Chrome and JavaScript. They are awful combination and allow companies to save on programmers. Programmers which handle C, C++, Rust or Python are a small group. Java, C# and JavaScript consume more resources, allow using a lot more stuff quicker (like a drug) and most importantly are forgiving mistakes. So the industry decides to waste the resources on our computers because they don’t need to buy and maintain them. The customer pays twice, for the software and the next computer with more soldered main-memory. The key point is - the software companies don’t pay for hardware or the environmental damage! I’m doing myself a little JavaScript and some Java. Efficiency? Nobody ask for that and I should not spend time on it. There is now law stating that managed languages need to waste resources but a side-effect. Remember Steve Jobs? I don’t appreciate what Apple does. But he banned Flash for a reason. Resources! Okay. Also bugs. And for the same reason they should ban Electron. Apple devices run faster with less resources because Apple saves on hardware. Why build devices with huge batteries, when you can achieve more runtime with less material and take the same money? The EU needs to enforce side-loading on the iPhone. But I also think Apple should be allowed to keep Blink (and therefore Electron) banned from AppStore. I don’t want see my battery dying because some corporate manager decided to drain it. But if you need Blink? Side load.

Karellen 3y ago
What usability features of Gnome do you find indispensable that prevent you from moving to a lighter-weight DE, like LXDE, XFCE or Cinnamon?
- ho_schi 3y ago
  High keyboard focused usage with focus on the application-window. I specifically like to enter just “terminal” and the terminal open, either a new window or already open on. I also Alt+Tab but with many open applications finding is more convenient. Another thing is that it is also easy to use with the mouse and the overview makes that pleasant (good for novice users). They eliminated the unappropriate “desktop metaphor” from Windows 95 and the “system tray”. The negative side is that GNOME often removes options or hides them - which drives away experienced users (the people needed to pull in new users) and some developers to forks. The are right to not support every bewildering option but the needed ones must in place despite the UX people don’t use them itself. https://ometer.com/free-software-ui.html https://ometer.com/free-software-ui.html Some of this is right. Do stuff automatically right and don’t provide unneeded options to avoid complexity. Some not! Also provide required preferences e.g. “Do not suspend on LID close” because some people don’t want that! The GNOME people assumed it was needed as option because of problems with suspend (S3) in the past. Maybe people used it to bypass issues but that isn’t the use case of the preference. Another thing is “When you’ve five clock applets” I want to know what is missing from the first one which made all the others necessary. GNOME learned that people don’t need an “Emacs” as UI-Shell but somewhat went into the other extremes. PS: And GNOME just looks good by default. I don’t need themes because it is fine.

eternityforest 3y ago

I think there might be a market mostly with other engineers like you. Lots of people seem to really love this stuff, look at the forth crowd and how much they adore the language. For me... I don't notice any slowness or excessive battery drain in VS Code, so I just use that. Perhaps there's something deeply wrong with my psychology, but I'm just not very interested in simplicity for its own sake. It's cool, but not an approach I'd want to use every day in real life.

commandlinefan 3y ago

> I will have a hard time bloating my software I wonder how much of this is just because when a project manager comes along and says "as a system administrator, I want to be able to log all of the keystrokes of the users and reports who's slacking to the boss", you say, "ok, that feature will take about two weeks to implement" and they can't argue with you because it's C so they just go away and leave you alone.

gavinhoward 3y ago
The truth is that I don't have a project manager, another reason it's hard for me to bloat my software. :)