Live data from Hacker News

Did we lose our way in making efficient software?

rufatmammadli.medium.com

281–290 of 515 posts

Re: Did we lose our way in making efficient software?

#281

Earlier quoted context omitted.

An actual customer won’t like it when you tell them they have to turn off or bypass a security feature to run your software. Not when other software doesn’t need it.

Once I get a project to "actual customers" I don't mind paying and signing my binaries.

How about "actual users" rather than "actual customers?" We should not normalize this because it eats away at free software. It is totally unreasonable to have to pay the operating system's manufacturer in order for person A to simply distribute software to person B, outside of manufacturer's infrastructure. The manufacturer has nothing to do with that distribution, and has no business "warning" the user about this software.

Re: Did we lose our way in making efficient software?

#282
post #6

I want to make native apps but Apple and Microsoft seem to be trying really hard to stop me. I have to buy developer accounts, buy certificates for signing binaries, share 30% of my revenue with them for barely any reason and so on. Not to mention the mess they've introduced in their APIs - especially Microsoft. So of course we choose the much simpler, much cheaper way of the web.

Ok Set up CC processing on the web: How much are you going to pay stripe? 2.9% + 30¢ ... that means you have to charge 10 bucks to get down to a 6% transaction fee. Quite the price floor and an interesting cap on your pricing model! What does managing chargebacks cost you? The moment your taking money your going to hire in customer service, or spend time dealing with CS. What happens when you get a chargeback, or do…

The cheapest in my country is 7 cent per transaction, the most popular is 25 cents. We also don't do claw-backs.

Re: Did we lose our way in making efficient software?

#283
post #6

I want to make native apps but Apple and Microsoft seem to be trying really hard to stop me. I have to buy developer accounts, buy certificates for signing binaries, share 30% of my revenue with them for barely any reason and so on. Not to mention the mess they've introduced in their APIs - especially Microsoft. So of course we choose the much simpler, much cheaper way of the web.

Devil's advocate: you now get a lot of tooling for 'free', which used to cost hundreds or thousands of dollars.

Yeah that doesn't quite work. I agree that the cost of tooling has gone to nearly zero in most cases, but not giving it away will limit the people willing to even try to develop code for your platform.

Re: Did we lose our way in making efficient software?

#284

Earlier quoted context omitted.

One off few hundred or few thousands is nothing in comparison to 30% tax. That said, I don't know about Mac, but you can build apps using free tools - maybe in not as convenient way, but certainly you can. I remember, because I was someone who couldn't afford Visual Studio licence and had to make do with GNU tools. The greed of these companies put me off from developing anything.

It's 15% for almost all developers, not 30%.

A distinction without a difference

Re: Did we lose our way in making efficient software?

#285

Earlier quoted context omitted.

The article is an ad: "*** provides uptime monitoring and flow-based monitoring for APIs." This is an important subject, thus it's one for which clickbait is generated. Size is a problem. I look at my Rust compiles scroll by, and wonder "why is that in there?". I managed to get tokio out, which took some effort. The whole "zbus" system was pulled in because the program asks if the user is in "dark mode". That brought…

I'd check your .bashrc because that shouldn't be happening without your say so.

.bashrc hasn't change since 2021. But Ubuntu pushed a new /usr/bin/bash in mid-March.

Re: Did we lose our way in making efficient software?

#286
post #59

Earlier quoted context omitted.

The native world also refuses to create a standard UI API, making everyone use either Qt or Electron because sorry writing it over again for each platform is a hard “no.” Not even big companies do that anymore.

Why would platform maintainers want to encourage the lowest common denominator apps that such an API would undoubtedly result in (as a standardized UI API by definition cannot leverage platform strengths)? Apps like that get made anyway but as it stands at least there’s a healthy crop of smaller/indie native alternatives which often best the behemoths in UI/UX. That would likely disappear with the addition of a stand…

Platform maintainers (Apple, Microsoft, etc) already do this by being on web standards panels. ;P

Re: Did we lose our way in making efficient software?

#287
post #59
post #6

I want to make native apps but Apple and Microsoft seem to be trying really hard to stop me. I have to buy developer accounts, buy certificates for signing binaries, share 30% of my revenue with them for barely any reason and so on. Not to mention the mess they've introduced in their APIs - especially Microsoft. So of course we choose the much simpler, much cheaper way of the web.

The native world also refuses to create a standard UI API, making everyone use either Qt or Electron because sorry writing it over again for each platform is a hard “no.” Not even big companies do that anymore.

Yes. Not only are they refusing (and have been for decades) to create a standard UI API, they are 1. actively making their own UI APIs as different as possible from one another, even down to requiring different programming languages to use them, and 2. killing things that they once supported, which ease cross-platform code (both major platforms walking away from OpenGL in favor of their incompatible native APIs).

Re: Did we lose our way in making efficient software?

#289

My opinion about this is that yes, we lost our way, and the reason is very simple, it is because we could. It was the path of least resistance, so we took it. Software has been freeriding on hardware improvements for a few decades, especially on web and desktop apps. Moore's law has been a blessing and a curse. The software you use today was written by people who learned their craft while this free-ride was still ful…

I disagree. It’s all the frameworks and security features like telemetry of the operating systems and those framework libraries. There are programs written in Lazarus (free pascal) that run blazing fast on windows, even the modern ones like Windows 11. Keeping the software written for a specific purpose for the desktop is the best bet for quickness and stability.

Every modernization (hardware and framework) in software is a tax on the underlying software in its functional entirety

Re: Did we lose our way in making efficient software?

#290
post #236

Earlier quoted context omitted.

Yep. The most successful startup I worked at had a SPA that downloaded 5MB bundle and preloaded a bunch of data. Took nearly 10 seconds to startup. Nobody complained about that. In fact, few people complained about a few portions of the app that had abysmal performance. It often wasn’t until 60 second load times that customers started complaining. They still raved and raved about that software because it solved an ex…

"They still raved and raved about that software because it solved an extremely valuable problem for them. A job that took literally a week could now be done in minutes." This is a big point isn't it. We seem to think that customers are choosing "slow" over "fast", when a lot of times they are really choosing between "slow" vs "manual" (i.e. very very slow)

You’d always take a bike instead of walking if you can’t get a car. No one is looking to waste time when they need to get something done. If a tool is the only thing in town, they’ll praise it. Until your competitor came with something better in the way that matter.
Post reply on HN