HackerTrans
TopNewTrendsCommentsPastAskShowJobs

mtrower

no profile record

comments

mtrower
·3 yıl önce·discuss
> Also don't allow people to remove the ads by paying - you need to show ads to people with enough money to buy the stuff you're advertising. Exclusively showings ads to poor people does not work. Just make sure your ads aren't annoying.

I would definitely not pay money to a site that wanted to show me ads, regardless of my preferences, as a subscription member. Full stop.
mtrower
·3 yıl önce·discuss
> He already lost 4 years of his life to this. Hopefully he wises up and pivots before he wastes another 4 years.

I think it's up to him to decide whether that time had value or not.
mtrower
·3 yıl önce·discuss
> * VCs to continue to pour hundreds of millions of dollars to run the site and never ask for an ROI

Do they? I sure don't. In fact VC involvement is just about the last thing I want out of anything I consider critical infrastructure...
mtrower
·3 yıl önce·discuss
> I don't like the idea that our goal is always to make the most efficient code possible. It's not, it's to deliver business solution as efficiently as we can with the resources available. Just like you wouldn't want to pay for a mechanic to spend a week making your car more fuel efficient if you took it in to get new engine mounts. His job is not to make your car work for you, not work the best it possibly could.

If he could get me a 1000x gain in fuel efficiency, like you often see when software when performance overhauls are done, I would sure as hell give him his week. But this is less about maintenance and more about how the car/software is built the first time around.

In that vein, I do expect that if gasoline prices drop to $0.20c/gallon in a decade (hah), that fuel economy on new cars does not drop to 3mpg to match. That's essentially what seems to have happened in software --- the hardware got really fast, so software got really slow.

> It's not, it's to deliver business solution as efficiently as we can with the resources available.

This is true; I guess what I take issue with is externalizing hidden costs to the customer. We keep paying for faster and faster hardware, and have to because that old hardware which is still working perfectly fine can't run the new software, which is much slower. And often, even on new hardware, the software is just this side of "tolerable". If you're writing your own in-house tool and nobody cares, do whatever suits.

> That said most of the time you do want to be writing efficient code.

Yes. That's all I want. Reasonably efficient. Not balls-to-the-wall speed demon witchery like we saw back in the demoscene heyday, just not to be sliding backwards all the time to erase all the gains our hardware got us.

---

EDIT: I get where you're coming from with the business incentives, I really do. But I'm saying I have a lot of issues with the end result --- as is often the case, maximal profit for the business is wreaking havoc elsewhere, in a sort of tragedy of the commons effect. And there are no realistic ways for me as a consumer to alter business incentives. A lot of software, especially the type that people get paid to write is closed source and closed protocol.

An excellent example is Discord --- it works well enough, when it works, but it's kind of a big heavy behemoth. It doesn't run well on older computers (I frequently see it burning a whole core just sitting in a voice channel). Right now, it's using nearly 1GB(!) of RAM, and frequently climbs to 2 or more if I leave it run long enough. This is a program whose core functionality was essentially available to me in 1999, and it struggles if I try to run it on a 4GHz machine from 2012. The search function sucks imo, and various other complaints. Screensharing with audio is broken (because electron), and probably always will be.

And I can't do a damn thing about it. I can't use a different platform, because the platform I use is determined by the people I want to talk to that are already using it. I can't improve or fork the program, because it's closed source. I can't (realistically) use a different client, or even write my own, because it's a closed protocol. So I'm just stuck with this pig of a program, and no amount of rage or frustration that I feel will alter the company's business incentives.

But it's just one program, right? Okay, I've got the cycles to spare, and the RAM, well, I overprovisioned this machine, so (in the case of this one, relatively modern machine), it's not the end of the world... right?

Now add Spotify. It's the same damn problem, so now the problem is 2x. Add a web browser (I mean, one who's job is actually to browse the web). I manage to draw the line there, mostly, but a lot of people are stuck with a lot more (VS Code, etc). It all adds up to a nightmare. And yet, all the time, I hear how "performance doesn't matter" (not exactly your words, but a prevalent developer sentiment).
mtrower
·3 yıl önce·discuss
Could it be an issue of experience perhaps? (As in, different experience bases, not overall quantity of experience).

Do you have much background in procedural or data-driven programming?
mtrower
·3 yıl önce·discuss
Also worth noting what his idea of a "small efficiency" was; he goes on to note that, say, 12% efficiency, easily gained, is not small at all!

He never says to throw all ideas of performance out the window when writing your initial run of code. It's just not worth it to dig down into the weeds and micro-optimize everything ahead of time, is all.

But people just take this quote as liberty to completely ignore all notion of performance in their code. Maddening, and a total disservice to Knuth.
mtrower
·3 yıl önce·discuss
> people that learned what “clean code” is from a blog post or a Tweet or (most likely of all) another YouTuber

Or, you know, college. Though I can only speak of my local tech college, not full blown university. I don't bear them any ill will --- there's a hell of a lot to try to teach in two years --- but a lot of the things that were taught in my degree, were very dogmatic.
mtrower
·3 yıl önce·discuss
If your area of expertise is putting out a general purpose shape area compute library, then maybe. If your purpose is elsewhere and this code is a tool to accomplish that --- not so much. Not everything needs to be fully general. Write the tool you need, whatever that ends up being.
mtrower
·3 yıl önce·discuss
> All he does fits in registers and maybe cache.

Well yes, that's.. actually the point. Indirectly, anyway anyway.

> I mean, Python is slow as an old dog, yet it gets most of the ML fun.

Python driving some UI and logic, with a ton of optimized Fortran and C driving everything hot.
mtrower
·3 yıl önce·discuss
> There is a time and a place for performant code but it's not the only metric we need to take into consideration.

Of course not. But then, nobody is really complaining about apps they think are fast enough. The problem is, when something is noticeably slow, you complain about it, file reports etc, and are met with stiff resistance.

What's important is not that you make the machine go as fast as it can possibly go at all times. What's important is to know how fast it can go, so that you're aware of just exactly how much you're leaving on the table. The actual amount in most cases, would, I expect, surprise most people...
mtrower
·3 yıl önce·discuss
> If they are a normal business admin they are very replaceable. So you don't have to make life easy for them unless they can justify the cost of doing so.

That is a mentality which is too horrifiying to find proper words to describe.

> If people avoid doing their job because they don't like their tools that is a disciplinary matter. Time to find an administrator that can do the job required.

It's human nature to avoid difficult things. Discipline only goes so far; it happens subconsciously.

And anyway, small inefficiencies add up to mountains, but it can be hard to see what's going on when everything is just pebbles everywhere.
mtrower
·3 yıl önce·discuss
Don't forget your electricity costs, A/C costs, hardware maintenance costs... these are often overlooked, but are not nothing. You've added permanent recurring expenses to avoid your one-time developer fee.

Yes, sometimes this might make sense --- if the dev fees are going to be exorbitant, or if you just can't afford to pull a dev off a project to work on it. Other times, it makes more sense to pay the dev...

You keep saying, CPU cycles are cheaper than developer hours, but this is nonsensical without quantities attached to each. How many CPU cycles, on what kind of machines? How many cycles do those machines have to spare? What's the performance per watt? How many developer hours at what kind of salary? There's way too much missing info to be making such a statement.
mtrower
·3 yıl önce·discuss
What defines a codebase as realistic, exactly? There are many, many programs out there doing various things in various ways.
mtrower
·3 yıl önce·discuss
You know, I started on some concrete examples for you, but I had to stop and back up. Really? You can't think of any examples yourself? The modern web is absolute hell to use if you aren't on modern hardware. Try it sometime; use a 10 year old phone, or an old computer that wasn't built top-of-the-line.

There's so much hardware out there that can run native applications just fine, that can play back HD video, that can run complex 3D real time video games, but crawl like molasses when loading your average webpage. Facebook and YouTube are terrible offenders, but so are your average blogs. Many banking websites are terrible (yet they don't have to be; my local credit union has a zippy website that looks attractive to boot, has modern design elements, etc.).

Maybe the hardware you're running is eye-wateringly fast, or maybe it's just barely fast enough and you don't need the cycles for anything else. But we're not talking milliseconds. We're talking order(s) of magnitude. I can't bring myself to believe you don't see at least some of it, if you just open your eyes and look around.
mtrower
·3 yıl önce·discuss
> the whole world is comprised of the 99% of cases where shaving off that millisecond buys you absolutely nothing

Who was talking about a single millisecond here?

I notice, broadly, two types of people who engage in these arguments.

1> OMG, computers are thousands of times faster than they were a decade ago, why is everything not lightning fast? Why are so many things slower than they were back then? Why is my chat program eating 2GB(!) of RAM?

2> Because we're busy writing six billion features on our Nth iteration of this problem space, we can't be bothered to shave a few millis bro!

And they just talk past each other.
mtrower
·3 yıl önce·discuss
Quite often the issue isn't 400ms vs 100ms, it's literally seconds vs single-digit ms.

> The problem is capitalism and/or human nature.

Fundamentally, yes.
mtrower
·3 yıl önce·discuss
> Also EAC is a lots more user friendly that some python software.

User friendly is a matter of opinion.
mtrower
·4 yıl önce·discuss
That's an interesting approach to consider, thanks!