Niklaus Wirth was right and that is a problem • Hacker News Board

Re: Niklaus Wirth was right and that is a problem

#91

Post by regularfry » Sat, Aug 01, 2020, 1:39 AM UTC

bbreier wrote: post #66

ThrowawayR2 wrote: post #61

Earlier quoted context omitted.

> " It seems there are two distinct branches of computing emerging - one where performance matters, and one where it doesn't. " The unfortunate corollary being that the prevalence of developers who treat it as if it doesn't makes it darned hard to find one who treats as if it does when you need one. > " Applications made for "consumers" tend to be made like a cheap car " Not really a great analogy. The Prius has a re…

> Luxury cars often have high maintenance requirements and poor reliability since cost is not a concern to their owners. This is absolutely a nit and does not disqualify your overarching statement at all, but generally these attributes are due to the constraints of technology-- for example, fitting large, high performance engines necessarily increases the frequency of maintenance intervals as well as the difficulty (…

This tends not to be why luxury models are unreliable in practice.

Luxury models are used by the manufacturer as a proving ground for the tech they're going to filter down to the mass market models next. Luxury model customers are relatively price-insensitive but want to be able to show off shiny features, so they get the exclusive new tech that's not been tried at scale yet. Thus the unreliability. It's not the technical constraints, it's the maturity of the technology.

Re: Niklaus Wirth was right and that is a problem

#92

Post by mabbo » Sat, Aug 01, 2020, 1:41 AM UTC

Software speed is a usability feature, and usability is a subset of economic value.

It turns out, people are perfectly happy to put up with slightly slower software for all of the other benefits we get from modern software: rapid development, rapid deployability, ease of code comprehension, and more.

When users complain about slow software enough to buy a different product (in whatever variation of 'buy' that may be) then it becomes a high priority thing to fix. Software today is precisely as fast as it needs to be- and no more, typically.

To me, this article is just the software engineer's version of Grandpa complaining that things were better in the old days- he's ignoring the reasons why things changed.

Re: Niklaus Wirth was right and that is a problem

#93

Post by IncRnd » Sat, Aug 01, 2020, 1:41 AM UTC

mikl wrote: post #88

All that “bloat” enables us to do (much) more with less developer hours. The balance is the same as ever, developer time vs. compute power. As compute power gets ever cheaper, and developer time still costs the same, we put bigger burdens on the machine to save developer time. In other words, simple economics.

I don't think that developer time is the only metric here.

Yes, every project can get to market or to the next release with a startup company's speed, but you trade-off and generally get "startup quality" that way. That is the actual point.

This industry is so fast-moving that the costs associated with that level of quality is often paid later by other people. There are plenty of examples of this.

Re: Niklaus Wirth was right and that is a problem

#94

Post by greggman3 » Sat, Aug 01, 2020, 1:42 AM UTC

arexxbifs wrote: post #77

> About 25 years ago, an interactive text editor could be designed with as little as 8,000 bytes of storage. That would be in 1970, but my guess is that "ed" would be a hard sell today. There is plenty of bloat to go around these days and I think we could do a lot more to address that. But we've all got too much skin in the web game to own up to the embarrassing fact that a chat program that's basically IRC with pict…

That text editor quote really bugs me. Sure my Atari 800 had a word processor that came on a 8k cartridge. I couldn't type Chinese, Japanese, Korean, Russian, Arabic into. I could only type ASCII. Just the ability to do that alone would likely entail many many megabytes of code.

For one, there is no text based system like those old machines that handles all that so I have to switch to graphics. Just the font alone for all of those languages will be multi-mega bytes and I'll need multi-megabytes more for space to rasterize some portion of those fonts. Rasterising just 4 or 5 glyphs is more work than that entire 8k word processor had to do on its 40x24 text screen.

Then for each language I'll need multi-megabytes for handling the input methods. The input methods are complex and will likely need a windowing system to display their various options and UX so add more code for that.

The point being that we need the complexity. That 8k editor wasn't useful in the same sense as our stuff today. I don't know a good analogy. It's like complaining that people use CNC machines today and at one point got by with a hammer and chisel. I'm not going back.

Re: Niklaus Wirth was right and that is a problem

#95

Post by davidgu » Sat, Aug 01, 2020, 1:45 AM UTC

rabidrat wrote: post #83

arexxbifs wrote: post #77

> About 25 years ago, an interactive text editor could be designed with as little as 8,000 bytes of storage. That would be in 1970, but my guess is that "ed" would be a hard sell today. There is plenty of bloat to go around these days and I think we could do a lot more to address that. But we've all got too much skin in the web game to own up to the embarrassing fact that a chat program that's basically IRC with pict…

> more than I like saving a few fractions of a percent of my hard drive space. Hard disk space is seldom the actual issue. Instead, it's bandwidth used (too expensive to download over a mobile connection, or maybe not even feasible to download over a low-quality connection), or memory requirements (can't reliably use slack + spreadsheet + photoshop at the same time), or power consumption (laptop out of battery in 1 h…

I am very seldom in a situation where I must download my IDE while traveling in a rural area, run it with Photoshop simultaneously, or use it for the entirety of a 3-hour plane ride.

While multi-hundred-megabyte text editors consuming double digit CPU to render some text are definitely a sign of inefficiencies _somewhere_, I value any marginal productivity benefits from these additional features over (possibly significant!) usability in very resource constrained situations.

Re: Niklaus Wirth was right and that is a problem

#96

Post by elihu » Sat, Aug 01, 2020, 1:55 AM UTC

horsawlarway wrote: post #23

This article is the problem. It's the same freaking fallacy I see again and again on here - It's simple, easy to understand, and dead fucking wrong. The vast majority of the complexity you're dealing with in modern computing comes from three sources. In the order of impact 1. Networking. It turns out there are real and hard limits on how fast we can pass data around over copper wires. Fiber is better, but you just li…

Regarding 3, I think part of the problem of ecosystem fragmentation has to do with large tech companies finding their favorite niche and being reluctant to compete with each other.

I have a theory that this has something to do with incentives: competition can be good for the company that is able to grab another's territory, but on average it's usually a loss. That's especially true from the perspective of shareholders, most of whom don't just hold one stock but many. Some competition is necessary, but too much is inefficient. If you own stock in both Apple and Google, you're happy with them each having their own group of loyal phone buyers. Spending more money than necessary to try to attract the other company's customers to switch is almost a pure loss from the point of view of the shareholder. Companies might not explicitly collude to divide markets (which would be against anti-trust law), but they're still subject to the disapproval of their shareholders if they rock the boat too much. Sometimes I think it makes more sense to think of all publicly-traded companies as being a sort of loosely-structured single corporation rather than truly separate competing entities.

So we have all these different software ecosystems that all these different businesses have built their respective walled gardens around, but software developers suffer because they can't just write to one platform and have their application be portable. Instead, they need a totally different application if they want to be accessible to desktop PC users, Android, iPhone, the web, tablets, servers, enterprise customers, HPC, cloud, game consoles and so on. Sure those users all have different needs, but surely they could have quite a bit more cross-platform consistency and common tools and standards than what we have now.

Re: Niklaus Wirth was right and that is a problem

#97

Post by thisisnico » Sat, Aug 01, 2020, 1:57 AM UTC

LeftHandPath wrote: post #48

ummonk wrote: post #32

The referenced AppSignal post about 13,000 dependencies for a todo list is conflating dependencies required for the build tooling with dependencies that are actually bundled in to the web app. It's also hilarious that right after referencing the dependency problem in the JS ecosystem the OP then goes and advocates splitting up your library into a bunch of mini libraries. That's exactly how we got into this mess in th…

I agree with the core point of the article, but I agree with your points as well. The conclusion of the article is definitely wrong. I recently buddied up with someone who has a CS degree to try and make a desktop app, as a side project. I asked if he is familiar with MariaDB and whether or not he's used C++ ODBC. Our discussion quickly turned into choosing libraries / existing code. He uses Spring and Hibernate and…

Dual Core and Quad core were also massive improvements in performance.

Re: Niklaus Wirth was right and that is a problem

#98

Post by justin66 » Sat, Aug 01, 2020, 1:58 AM UTC

cmrdporcupine wrote: post #89

Negitivefrags wrote: post #80

Earlier quoted context omitted.

Networking isn't the bottleneck. As John Carmack quipped, "I can send an IP packet to Europe faster than I can send a pixel to the screen. How f’d up is that?" Usually if there is latency caused by networking in an application it's usually unneeded roundtrips caused by inefficient programmers or inefficient layers in the software stack. It's insane how much overhead there is.

I am completely baffled by this quip. At speed of light in a vacuum, from New York to London is 19ms. That's the physical limit of what a network could ever hope to accomplish, but in reality in fiber it's apparently about 28ms. At 60fps we need to present a new set of pixels to the screen every 16ms. So in the time that a packet goes in one direction to Europe we could have presented almost two full frames of pixels…

You haven't even tried to take the shocking amount of latency introduced by the hardware and the software stack into consideration, and it's what prompted Carmack to make his comment.

Re: Niklaus Wirth was right and that is a problem

#99

Post by arexxbifs » Sat, Aug 01, 2020, 2:00 AM UTC

greggman3 wrote: post #94

arexxbifs wrote: post #77

> About 25 years ago, an interactive text editor could be designed with as little as 8,000 bytes of storage. That would be in 1970, but my guess is that "ed" would be a hard sell today. There is plenty of bloat to go around these days and I think we could do a lot more to address that. But we've all got too much skin in the web game to own up to the embarrassing fact that a chat program that's basically IRC with pict…

That text editor quote really bugs me. Sure my Atari 800 had a word processor that came on a 8k cartridge. I couldn't type Chinese, Japanese, Korean, Russian, Arabic into. I could only type ASCII. Just the ability to do that alone would likely entail many many megabytes of code. For one, there is no text based system like those old machines that handles all that so I have to switch to graphics. Just the font alone fo…

I think actual bloat is better measured by comparing the size and speed of a program with a few of its previous versions and look at the number of new features. Outlook strikes me as a suitable candidate: I can't think of anyone using it any differently today than say 10 years ago.

I even think comparing with something that is 20 years old today is more interesting than comparing a 1995 IDE to a line editor written for teletypes.

Re: Niklaus Wirth was right and that is a problem

#100

Post by vvanders » Sat, Aug 01, 2020, 2:02 AM UTC

abraxas wrote: post #24

agumonkey wrote: post #14

Earlier quoted context omitted.

Herb Sutter had a wonderful talk on constant factor plague. As much as I like clojure and similar convenience and algorithmic beauty.. I can appreciate the devil-is-in-the-details much more since this video (forgot the title sorry)

Could you please dig it up? I'm not sure hot to find it based on what you posted and would love to watch it.

Was it this one(30 minutes in)?

https://channel9.msdn.com/Events/Build/2014/2-661

Probably one of my all time favorite performance talks.