Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Niklaus Wirth was right and that is a problem

bowero.nl

Post reply on HN
Print view View original

181–190 of 198 posts

Re: Niklaus Wirth was right and that is a problem

#181

Post by justin66 »

cmrdporcupine wrote: post #177
shash wrote: post #103

Earlier quoted context omitted.

Here’s his reasoning: https://superuser.com/a/419167 “ The bad performance on the Sony is due to poor software engineering. Some TV features, like motion interpolation, require buffering at least one frame, and may benefit from more. Other features, like floating menus, format conversions, content protection, and so on, could be implemented in a streaming manner, but the easy way out is to just buffer between each su…

Well, yes, I suspected it was something like this. I'm well aware of this kind of bloating (guess I should have said something in my comment to avoid the downvotes...) but it still doesn't support the OP's comment. Network latency is not only high, but there's literally nothing that can be done of it -- because of the speed of light! (I am somewhat lucky to work on something where we can optimize away much of the cra…

The person you initially negatively responded to said "networking is not the bottleneck," and if it's possible to have a meaningful negative reaction to that, it might involve asking "the bottleneck in what system?" I think he's right, but it's a blanket statement and it's fair to ask for more context.

More context: typical network latency is good enough that video games rendered on a remote server are becoming practical, or at least salable. "Network latency is high" is a vague enough statement that it could mean anything, but if being able to render video games remotely and stream the output to the client doesn't make you reconsider, I question what you would ever consider network latency that's not too high.

The kicker with these games, that perhaps speaks to the original, crazy post by horsawlarway, is that it's normal for a TV set and set of controls to introduce a lot more latency than the network connection itself: the network is not the bottleneck. There's a good excuse for the latency in involved in networking, rooted in physics, but this is not true for the hardware and the software stack.

Re: Niklaus Wirth was right and that is a problem

#182

Post by chrisandchris »

cable2600 wrote: post #125
badsectoracula wrote: post #38

Earlier quoted context omitted.

In my experience what the switch to SSDs resulted into was Windows 10 becoming practically unusable on a mechanical HDD. Comparing how long the OS needs to start up, launch applications, etc on my laptop with Win10 vs a much older laptop with Win8 (the first and last time Microsoft bothered to optimize Windows the last decade) is night and day and that older laptop originally came with Vista! When i first installed W…

At Microcenter you can buy a house brand SSD hard drive with 128G on it for $58 and boot from that and store all your other files on a D:\ regular hard drive. That is how I set up my son's Windows 10 gaming rig.

There are countries where you will live with that $58 dollar for 2 weeks (or more). Maybe not everyone has the money to buy a SSD.

Re: Niklaus Wirth was right and that is a problem

#183

Post by cmrdporcupine »

justin66 wrote: post #181
cmrdporcupine wrote: post #177

Earlier quoted context omitted.

Well, yes, I suspected it was something like this. I'm well aware of this kind of bloating (guess I should have said something in my comment to avoid the downvotes...) but it still doesn't support the OP's comment. Network latency is not only high, but there's literally nothing that can be done of it -- because of the speed of light! (I am somewhat lucky to work on something where we can optimize away much of the cra…

The person you initially negatively responded to said "networking is not the bottleneck," and if it's possible to have a meaningful negative reaction to that, it might involve asking "the bottleneck in what system?" I think he's right, but it's a blanket statement and it's fair to ask for more context. More context: typical network latency is good enough that video games rendered on a remote server are becoming pract…

Well, yes, I recently worked on the video receiver component for Stadia on Chromecast. So I know a little about these things.

Re: Niklaus Wirth was right and that is a problem

#184

Post by justin66 »

cmrdporcupine wrote: post #183
justin66 wrote: post #181

Earlier quoted context omitted.

The person you initially negatively responded to said "networking is not the bottleneck," and if it's possible to have a meaningful negative reaction to that, it might involve asking "the bottleneck in what system?" I think he's right, but it's a blanket statement and it's fair to ask for more context. More context: typical network latency is good enough that video games rendered on a remote server are becoming pract…

Well, yes, I recently worked on the video receiver component for Stadia on Chromecast. So I know a little about these things.

Perhaps you can see why that makes your comments all the more baffling? It's understandable that you might view the network as a UI bottleneck since you were working on an application that relies maximally on low-latency networking, but you must realize how unusual that is, and how fast typical networking actually is in order to make your work possible at all. (and to the original point, how lame an excuse network latency is for those who can't manage to cobble together a fast implementation of a much, much simpler application)

Re: Niklaus Wirth was right and that is a problem

#185

Post by echlebek »

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…

I wish slack seemed fast for me. It's like typing into molasses.

Re: Niklaus Wirth was right and that is a problem

#186

Post by cmrdporcupine »

justin66 wrote: post #184
cmrdporcupine wrote: post #183

Earlier quoted context omitted.

Well, yes, I recently worked on the video receiver component for Stadia on Chromecast. So I know a little about these things.

Perhaps you can see why that makes your comments all the more baffling? It's understandable that you might view the network as a UI bottleneck since you were working on an application that relies maximally on low-latency networking, but you must realize how unusual that is, and how fast typical networking actually is in order to make your work possible at all. (and to the original point, how lame an excuse network la…

It's just round trip to Europe from North America (esp western north america) is actually ... an eternity, could easily drift into 100ms -- and not one I can optimize to get rid of. Whereas I can work my way down the software stack and find bottlenecks and deal with them.

Yes I can't control what TV manufacturers do, that is a wild card. But the quote taken out of context is more than a little inflammatory -- the network has a hard physical limit that the local device does not.

FWIW I'm just as dissatisfied with software bloat as the next person. Retro computing is one of my hobbies, and the latency measurements there are something to be envious of.

ChromeOS generally does better in latency measurements than other platforms; much effort was made there, much of it by people I know.

Re: Niklaus Wirth was right and that is a problem

#187

Post by wglb »

bfuclusion wrote: post #141
wglb wrote: post #109

Earlier quoted context omitted.

I’ve been programming since 1965, read Dijkstra, Niklaus Wirth. And these days I break software at people’s request. There is in fact much less concern and emphasis on quality these days. It is also interesting to note that Knuth also does not do libraries

I'd say it's probably more a factor of the _requirements_ of the software getting harder. Pre 1995 most developers were writing apps running on a desktop that wasn't even multitasking. Post 1995 you have preemptive multitasking, TCP/IP / GUIs / multi platform / search indexes, etc. Most don't have the brain power to be experts in all those fields, hence you have to pick where you can excel in quality.

Sorry, I don't buy that. In 1970, I was writing multi-tasking assembler language code to real-time data collection of medical EKG data, feeding what we today would call an expert system or even AI to generate an English language cardiology report and sending it back to the hospital, first via paper tape carried over to ASR 33s, laater by dialout (where each character generated an interrupt). We gave ten minute turnaround.

I cringe today when programmers struggle with async processes in C or other languages, or async/await. We (Michael Whinihan and I) developed a dead-simple pattern using co-routines that vastly simplified interrupt driven programming. It is as if folks these days haven't read https://www.amazon.com/Operating-Principles-Prentice-Hall-Au...

I did a significant fraction of the work to build this, I wasn't the smartest guy in the outfit either. (Probably the most smart-aleck.) Check out one of the team members: https://en.wikipedia.org/wiki/Fibonacci_nim.

None of us were experts when we started this. We figured all the parts out and made it work, reliably. We had on the order of a small integer numbers of hours of outages per year. This was before Tandem Computers was born.

Now serving the medical community puts some pretty stringent requirements on what you build and how you operate it.

Re: Niklaus Wirth was right and that is a problem

#188

Post by wglb »

OnlyOneCannolo wrote: post #122
wglb wrote: post #109

Earlier quoted context omitted.

I’ve been programming since 1965, read Dijkstra, Niklaus Wirth. And these days I break software at people’s request. There is in fact much less concern and emphasis on quality these days. It is also interesting to note that Knuth also does not do libraries

Can you elaborate on the Knuth thing?

Reading his TAoCP you can see it in action.

The wonderful NY times article https://www.nytimes.com/2018/12/17/science/donald-knuth-comp... talks about this, with a quite from Norvig:

In those early days, he worked close to the machine, writing “in the raw,” tinkering with the zeros and ones.

“Knuth made it clear that the system could actually be understood all the way down to the machine code level,” said Dr. Norvig. Nowadays, of course, with algorithms masterminding (and undermining) our very existence, the average programmer no longer has time to manipulate the binary muck, and works instead with hierarchies of abstraction, layers upon layers of code — and often with chains of code borrowed from code libraries. But an elite class of engineers occasionally still does the deep dive.

“Here at Google, sometimes we just throw stuff together,” Dr. Norvig said, during a meeting of the Google Trips team, in Mountain View, Calif. “But other times, if you’re serving billions of users, it’s important to do that efficiently. A 10-per-cent improvement in efficiency can work out to billions of dollars, and in order to get that last level of efficiency, you have to understand what’s going on all the way down.”

Re: Niklaus Wirth was right and that is a problem

#189

Post by markbnj »

wglb wrote: post #109
markbnj wrote: post #106

> 1995 was the year in which programmers stopped thinking about the quality of their programs. Oh, please. There are some good points in the article but that hyperbole was unnecessary. I was programming in 1995, and nobody stopped thinking about the quality of their software.

I’ve been programming since 1965, read Dijkstra, Niklaus Wirth. And these days I break software at people’s request. There is in fact much less concern and emphasis on quality these days. It is also interesting to note that Knuth also does not do libraries

> I’ve been programming since 1965, read Dijkstra, Niklaus Wirth.

Well sir, you have me by ten years, and believe me I respect that extra decade. That said, I think you're falling into the trap many of us greybeards tumble into as we get older: the things we cared about and focused on become, in our minds, the right and true perspective that has been lost or disregarded by younger practitioners. It's really not very different from "When I was your age I walked to school every day, uphill, both ways!" Or maybe it's just me.

Yes, there are far fewer programmers hand optimizing assembly code, and yes every programmer now cobbles together applications by reusing code written by other programmers, some of which is very good, and some of which is not. But if programmers were still spending their time optimizing low level loops and eschewing any code that they did not personally write and verify the beauty of, the world we have today would not exist. Instead of zooming with my family in the middle of a pandemic we'd be exchanging emails, or posting on a BBS to say "Hi!" There's obviously still a need and role for people who like to work at that level, and that kind of engineering remains fascinating (one of the reasons I love to read the linux kernel mailing list), but I don't bemoan the rise of high level languages, libraries, package management ecosystems, frameworks and the like. That stuff has given us the world we have today, and a few warts notwithstanding I still like it much better than the one we had.

Re: Niklaus Wirth was right and that is a problem

#190

Post by akkartik »

IncRnd wrote: post #85
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…

That's just not true. 1. Networking isn't the number one source of complexity, since local apps can be bloated, slow, buggy, and complex. 2. Security is not a consequence of networking. A non-networked system can be insecure, and a networked system can be secure. Security is more normally viewed in the context of confidentiallity, integrity, and availibility along with the concepts of authentication, authorization, a…

It still seems useful to consider how security and compatibility add complexity to our software stacks, even if the causal chain of networking -> security -> compatibility isn't right.
Post reply on HN