Hacker News Reader

Comment by gavinhoward | Hacker News Reader

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-i...

[2]: https://gavinhoward.com/2020/12/my-development-environment-a...

[3]: https://gavinhoward.com/2023/06/an-apology-to-the-gentoo-aut...

[4]: https://gavinhoward.com/2023/09/lessons-learned-as-a-user-3-...

View on HN

>, 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!

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.

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)

There was a time when Microsoft wrote extremely lean code, and BillG in particular. Best example: TRS-80 Model 100.

Yes, DONKEY.BAS was legendary... /s

C probably was bloated then. But today it’s the backbone of everything, whereas python will never be that, at least on hardware at the levels we can foreseeable build.

Languages like C brought a massive benefit to accessibility. Devolving “software is slow” to “yeah but C vs assembly” is such a ridiculous crutch argument. Assembly is not remotely approachable to the majority of programmers. C, rust, zig, c++, Java, C# are all approachable languages that are fast and have great fast libraries and frameworks to work with.

All I can see in the “I can finish the see sharp program faster” argument is that “python vs c++.jpeg” from the 2000’s where half the python was importing libraries, but they wrote the C++ from scratch, and everyone who knew nothing about C++ moved this image around like it was some hilarious joke of C++.

> 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.

Both perspectives are correct for their respective times. Compilers were much dumber in 80. These days your GUI desktop program written in assembly language would probably run slower than written in C and compiled with modern gcc O2.

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.

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.

The problem is it's trade-offs on top of trade-offs, all the way down.

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.

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.

I agree, except that engineering is"fit for purpose at the smallest cost."

For me personally, I am banking on having multiple business customers for my software. If I consider the cost amortized, I can spend a little more to engineer something better.

But yes, it still has to be fit for purpose. My customers will provide a document that explains what they want to do with my software and on what platforms. If I sign a contract, that means I am committing to supporting their purposes on those platforms.

The ethical considerations and professional obligations that go into creating a bridge aren't exactly translated into the act of creating software. If we mirrored those in a bridge building analogy the "cost my client afford" would mean the engineers would often find themselves greenlighting a bridge that would fail in sensible conditions in our current world.

No. A civil engineer's response would (should?) be immediately that the client cannot build the bridge for that cost, simply because it will kill someone as a first order effect. That's the ethical consideration. The downsides of janky rendering or poor memory management aren't quite the same unless you actually add up the power wastage and apply it as an impact on global warming. But, those are not a first order effect, and although they should be, they don't have the same influence on the solution.

There's plenty of software that can kill someone as a first-order effect. If you allow second-order, there's even more.

Avionics. Air traffic control. Industrial control. Automotive software. 911 dispatch. Medical instruments. Medical information. Military command and control. Mechanical engineering analysis software.

Lots of software can kill people.

That's not what I'm saying. If a web page takes 2s to render rather than a theoretical minimum of "immediately", for most software that most people write, no one will die, or be hurt, or even feel too bad as a first-order effect. Obviously, if one is writing flight control software, or somesuch, then the stakes are higher, and one ought to be aware of that. That's the practicality calculation. If you're going to kill/hurt/really upset someone, then what you're doing is not fit for purpose (unless that is the purpose :) )

FWIW, the embedded domain usually has a little more focus on efficiency and correctness compared to enterprise software.

I don't understand this position, sorry. A bridge that would fail under expected conditions is straightforwardly not strong enough for its purpose?

the assumption youre making is that strong enough for purpose is always true for any value of "cost my client can afford."

that's what i was trying to draw attention to.

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

Try supporting unicode

Heh, that is probably the exception that proves the rule!

> 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?

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.

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

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

Yep

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.

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?

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.

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.

> 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.

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

Heh...

  > ... I use a heavily-modified Gentoo ...

Need not say more :)

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.

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

I know exactly why: I haven't started marketing yet. :)

After I get to MVP and actually try marketing, we'll see what happens.

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?

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.

No revenue generally means the project eventually gets abandoned or relegated to spare time because people gotta eat. So yeah I'd say it's a bad thing.

I'm all for quality engineering. I'm just saying that if your whole plan for a new product is "quality engineering", then you have no plan at all. The horse needs to come before the cart.

Even couching the output as a "product" begs the question. It comes with a whole set of connotations around what's expected in and from such an effort.

What you're describing is a tragedy of the commons from the perspective of social and civilizational benefit. I agree that's what it is, but I think we should be more careful before justifying it.

That's fine for theoretical discussions. The poster I was replying to implies that their goal is to sell a product and make money, so I was speaking to that.

You are right on many levels, and I know it.

> But I would suggest to every engineer to consider Chesterton’s fence.

I agree.

In fact, I believe I have considered Chesterton's Fence; I have a plan.

I'd like your opinion on my plan.

> Making something people want enough to pay for is very difficult.

Yes, absolutely.

To fight this, I have spent years, 3.5 years, figuring out what people hate about build systems, and I have designed mine to address those.

While that doesn't guarantee success, I think it may improve my odds. Do you agree?

> That is: builders who prioritize marketing outcompete those who prioritize engineering quality.

Yes, and it sucks.

I hate marketers. I hate marketing. I hate the fact that I'm going to do it. But I have to.

So my marketing with be focused on giving people something for just paying attention.

> 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.

Thank you for your compliment! I hope so, and my plan is to emphasize this.

I'm going to post four articles on HN, each a week apart, and each will be designed to give readers something substantial, with a blurb about marketing at the end that will be clearly marked as marketing.

* The first will be new FOSS licenses designed to better protect contributors from legal liability.

* The second will be a post on language design and psychology.

* The third will be a deep dive into Turing-completeness and what it means.

* The fourth will be the source code as a Show HN, along with an offer for early adopters.

> 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?

It's awful, but you are right.

So this marketing push is all I will do for four weeks: preparing and posting, and responding to comments. This is when I will "prioritize winning in the market."

Does this have a chance of working?

"Does this have a chance of working?"

It's a start for sure. But personally I'd suggest changing your mindset a bit from the idea that you'll come out of the code cave for a month to grit your teeth and do marketing. Granted, this is much better than just staying in the cave. But really to run a successful business I think you need to accept at a deep level that marketing, making money, and growing the business is now your main job, and you will permanently need to spend at least as many thought cycles on that as you do on programming.

To wit, while posting those articles and a Show HN sounds like a good plan and you should definitely do that, what will you do if they all fall flat and get no traction? It's a distinct possibility, and I hope you won't just give up.

I'd think more about what you're going to do every week for the next year to get users rather than putting all your chips on an HN launch that may or may not pan out. Even if you do rock the HN launch, you're probably going to have the "trough of sorrow"[1] to contend with after, so I'd think more about how you can make marketing a repeatable part of your rhythm in the long run.

1 - https://andrewchen.com/after-the-techcrunch-bump-life-in-the...

Thank you so much for your answer!

> while posting those articles and a Show HN sounds like a good plan and you should definitely do that, what will you do if they all fall flat and get no traction?

You got me. I was planning on giving up. :P

I am in a place where the only cost to switching projects and trying again in three years is the opportunity cost, so because I'm bad at constant marketing, that's what I was going to do if I got zero traction.

If I got only some traction, I'd weigh my options.

I was only going to worry about long-term weekly marketing if the launch went well enough.

Because I'll be frank: I have no idea how to do constant marketing that doesn't bother people or waste their time. If I would waste their time, I'd rather just throw my own time away and switch projects.

> Even if you do rock the HN launch, you're probably going to have the "trough of sorrow"[1] to contend with after

Good blog post, and yes, I agree. I am expecting the trough as I build up the MVP.

The issue with your strategy imho is that failing to get traction with an HN launch is not that much of a negative signal. Getting to the front page is a bit of a crapshoot and not achieving it doesn't necessarily mean no one is interested in your product--it could mean you got unlucky or just need to iterate on your messaging.

If you haven't gotten it in many users' hands yet, it might be a good idea to try recruiting like 50-100 users first, either one-by-one through email reachouts or in smaller communities where it's less hit-or-miss, like niche subreddits. If some of these users like the product and stick with it, start giving you feature requests, etc., that tells you that you're on to something. Conversely, if you can't get even a small group of users to try it and stick with it using that approach, it's much more of a negative signal than a failed HN launch and probably indicates that something needs to change.

Whatever route you decide to take, I wish you the best with it!

Also:

"I have no idea how to do constant marketing that doesn't bother people or waste their time. If I would waste their time, I'd rather just throw my own time away and switch projects."

That's noble of you, but I would cut yourself some slack. Ideally you would market in a way where you don't bother people or waste their time, but getting users often requires trying things where you risk getting close to that line. Sometimes you might cross over it, but that's just something to learn from.

Trying to market a product while never bothering anyone the least little bit is a bit like trying to be a comedian without offending anyone or to find a romantic partner without enduring some awkward dates. I think it just goes with the territory.

As sad as it makes me, I believe you.

I'll think about what to do.

I think if you succeed, it will be because other developers are investing in you personally. Because they like what you write and how you think, and thus trust you to write good software.

I think patio11 is someone who has used a similar marketing strategy to great success. People hire him because of the quality of his writing demonstrating his understanding.

I think you are absolutely right.

I also think I can't replicate patio11's success! He's a much better marketer and writer than me.

> While that doesn't guarantee success, I think it may improve my odds. Do you agree?

Not your parent commenter but I wouldn't agree, no. Build systems are one of these things most companies want to setup once and want to never deal with them again, and only do so if they have zero choice.

`earthly.dev` had an article some weeks ago that addressed why one of their products never took off even though it's really good and addresses grievances in the space. The TL;DR was that existing customers of other CI/CD tools did not want to migrate to a new system, especially since it doesn't offer a migration from their existing solution.

Here it is, hope you find it insightful: https://earthly.dev/blog/shutting-down-earthly-ci/

> Why is all the winning software in every category slow and bloated and seemingly unconcerned with engineering excellence?

1. They are extremely aggressive about coming to market fast. That's a good thing, yes. 2. They then let the project ossify because they view development as a cost center. Which is a bad thing. 3. Their endgame after being successful enough and can afford enough lawyers, they start proactively buying or shutting down potential competitors.

The "marketing wins over quality (and slower) engineering" does apply, yes, but not throughout the entire lifecycle. It applies only in the very first phase.

I would find it very satisfying to do what he’s doing. I’m not sure it needs be judged against making money.

Ever tried HolyC?

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.

What usability features of Gnome do you find indispensable that prevent you from moving to a lighter-weight DE, like LXDE, XFCE or Cinnamon?

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

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.

Jobs also said native apps were unnecessary and we can all just use web apps. (Despite working on an app store at the time.) So even the prophet himself isn't such a great example.

Yes. Jobs was wrong in many things - we all err permanently.

Reply on news.ycombinator.com