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

It’s hard work printing nothing

tedunangst.com

Post reply on HN
Print view View original

61–70 of 79 posts

Re: It’s hard work printing nothing

#61

Post by masklinn »

prashnts wrote: post #22
dkarapetyan wrote: post #11

I always thought low-level programmers (C, C++, assembly, etc.) cared more about minimal abstractions and minimizing dependencies. But it turns out it's the same story no matter what level of the stack you are on. Currently working on a project with 200+ requirements in requirements.txt and growing. Before anyone says microservices just realize that you have taken the same programmers that made this mess and shoveled…

That `requirements.txt` was probably generated by `pip freeze > requirements.txt`, which would yield all the installed packages and _their_ dependencies. Though, if 200+ packages were used in the codebase explicitly, that requires some sort of wizardry!

> That `requirements.txt` was probably generated by `pip freeze > requirements.txt`, which would yield all the installed packages and _their_ dependencies.

And also various development or test packages installed in the venv at the time e.g. third-party debuggers, profilers, etc...

Re: It’s hard work printing nothing

#62

Post by cpach »

rhubarbquid wrote: post #40
bb88 wrote: post #14

Earlier quoted context omitted.

It's a deprecation strategy. The warnings are typically for things that will break in the future. GTK can't control yet alone offer patches for the 1 million + programs that depend upon it as a library.

Printing those warnings to every end user isn't particularly useful though...

To be fair, most X applications are not launched from a terminal.

Re: It’s hard work printing nothing

#63

Post by lmm »

lotharbot wrote: post #50
cperciva wrote: post #29

There’s an argument to be made that silly error messages are better than crashing browsers There's an argument, but it's a really lousy one. If you're passing NULL as a string to printf, your code is broken . A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong .

> "A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong." Not necessarily. Wrong is relative and can have either small or large costs, and crashing also has a cost to the user (and to the developers if they lose users.) As an example, I play a very old video game (Descent). One of the major problems with one of the modern sou…

If it were possible to gain an advantage in a competitive match by having your system deliberately drop a packet, the game would quickly become impossible to play competitively - that kind of cheating would be basically impossible to detect because there's no way to tell it apart from a genuine bad internet connection. If you've carefully thought through what the game should do when a packet is malformed that's one thing, but if you haven't thought about it then cleanly crashing is probably the best option.

Re: It’s hard work printing nothing

#64

Post by MagnumOpus »

userbinator wrote: post #45
cperciva wrote: post #29

There’s an argument to be made that silly error messages are better than crashing browsers There's an argument, but it's a really lousy one. If you're passing NULL as a string to printf, your code is broken . A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong .

I agree with this 100%. Crashes are a way of not-so-subtly reminding you that your code is still buggy, and exactly where it crashed is usually a good indicator of where to start debugging. Rule of Repair: Repair what you can — but when you must fail, fail noisily and as soon as possible. To take this example to the extreme, imagine if the default state of the runtime/OS were configured so that invalid memory accesse…

Rule of Real World Developmen: Repair what you can and keep it running with kludges, because if your program fails noisily and soon, it gets uninstalled, and you get fired.

Re: It’s hard work printing nothing

#65

Post by roberthensing »

hexane360 wrote: post #46
smilekzs wrote: post #37

Earlier quoted context omitted.

"In the embedded world" covers a huge area, including mission-critical avionics code, which likely has much higher safety standard than, say, Android.

Although from hearing about the Apollo Guidance Computer, it's just as much of a miracle they were able to get it to work without any debugging or compilers, with basically one shot to write the program to ROM.

Well they put in an effort of 1400 man years for just the software. They even built an interpreter, because (flight/trajectory) requirements were changing all the time.

Also: "The highest level of testing was performed with a high fidelity digital simulation of the computer, spacecraft hardware, and mission environment."

http://klabs.org/history/history_docs/mit_docs/1711.pdf

Re: It’s hard work printing nothing

#66

Post by MichaelBurge »

lmm wrote: post #63
lotharbot wrote: post #50

Earlier quoted context omitted.

> "A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong." Not necessarily. Wrong is relative and can have either small or large costs, and crashing also has a cost to the user (and to the developers if they lose users.) As an example, I play a very old video game (Descent). One of the major problems with one of the modern sou…

If it were possible to gain an advantage in a competitive match by having your system deliberately drop a packet, the game would quickly become impossible to play competitively - that kind of cheating would be basically impossible to detect because there's no way to tell it apart from a genuine bad internet connection. If you've carefully thought through what the game should do when a packet is malformed that's one t…

That isn't true at all: Often competitive players are required to use the tournament organizer's hardware anyways.

And often competitive players form groups to play in, so everybody knows each other even while practicing.

You'd probably want to be on a LAN to minimize the risk of this happening accidentally.

So in practice, I don't think it would matter too much even if money was on the line. You would just have to take appropriate precautions, and watch to disqualify people for cheating.

Re: It’s hard work printing nothing

#67

Post by strictfp »

cperciva wrote: post #29

There’s an argument to be made that silly error messages are better than crashing browsers There's an argument, but it's a really lousy one. If you're passing NULL as a string to printf, your code is broken . A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong .

Yup. Fail fast.

Re: It’s hard work printing nothing

#69

Post by swah »

smilekzs wrote: post #37
ensiferum wrote: post #28

Earlier quoted context omitted.

I think not a single actual application is completely well formed. They all work on luck. Especially in the embedded world. Btw, my android just rebooted.

"In the embedded world" covers a huge area, including mission-critical avionics code, which likely has much higher safety standard than, say, Android.

And the architecture of the whole system is commonly an infinite while loop.

Re: It’s hard work printing nothing

#70

Post by lotharbot »

lmm wrote: post #63
lotharbot wrote: post #50

Earlier quoted context omitted.

> "A crash which results in someone tracking down and fixing the bug is far better than quietly doing something which is 100% guaranteed to be wrong." Not necessarily. Wrong is relative and can have either small or large costs, and crashing also has a cost to the user (and to the developers if they lose users.) As an example, I play a very old video game (Descent). One of the major problems with one of the modern sou…

If it were possible to gain an advantage in a competitive match by having your system deliberately drop a packet, the game would quickly become impossible to play competitively - that kind of cheating would be basically impossible to detect because there's no way to tell it apart from a genuine bad internet connection. If you've carefully thought through what the game should do when a packet is malformed that's one t…

> "cleanly crashing is probably the best option"

Except that it's also possible to gain an advantage by causing a game crash.

Ultimately, "crash the game" is among the worst possible options. (Also ultimately, it's a very old open-source game in which it's relatively easy to compile your own client software, so "make the game crash as an anti-cheat method" only works on honest players anyway.)

Post reply on HN