Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

This is not a coding horror, rather a horror from a coding textbook. An excerpt from my intro to OSes class textbook:

quote:

ASIDE: GREAT ENGINEERS ARE REALLY GREAT
Engineers like Jeff Bonwick (who not only wrote the slab allocator mentioned
herein but also was the lead of an amazing file system, ZFS) are
the heart of Silicon Valley. Behind almost any great product or technology
is a human (or small group of humans) who are way above average
in their talents, abilities, and dedication. As Mark Zuckerberg (of Facebook)
says: �Someone who is exceptional in their role is not just a little
better than someone who is pretty good. They are 100 times better.� This
is why, still today, one or two people can start a company that changes
the face of the world forever (think Google, Apple, or Facebook). Work
hard and you might become such a �100x� person as well. Failing that,
work with such a person; you�ll learn more in day than most learn in a
month. Failing that, feel sad.

Yes, feel sad if you don't happen to be one of the few people with the time, money, and safety net to spend all day and night programming poo poo for months on end on the off chance that what you produce can be sold for a profit. Yes, Mark Zuckerberg is definitely a once-in-a-lifetime genius and not just a rich rear end in a top hat who didn't have to risk anything to spend all day programming his product.

This textbook is written in the most insufferable, halting nerd-syntax and also has frequent footnotes just for the sake of making Star Wars references and putdowns on people who don't immediately understand the material. If you find yourself typing the word "thusly" as frequently as this book does, you need to hire a technical writer to clean your poo poo up.

# ? Feb 4, 2015 18:34

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 16:47

csammis: Aug 26, 2003; Mental Institution

LeftistMuslimObama posted:

This is not a coding horror, rather a horror from a coding textbook. An excerpt from my intro to OSes class textbook:
...
This textbook is written in the most insufferable, halting nerd-syntax and also has frequent footnotes just for the sake of making Star Wars references and putdowns on people who don't immediately understand the material. If you find yourself typing the word "thusly" as frequently as this book does, you need to hire a technical writer to clean your poo poo up.

What the hell book is this, "OSes for Dummies"?

# ? Feb 4, 2015 18:36

sarehu: Apr 20, 2007; (call/cc call/cc)

If only we had 12 fingers so that we could have 144x engineers.

# ? Feb 4, 2015 18:37

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

csammis posted:

What the hell book is this, "OSes for Dummies"?

Yeah, name and shame please.

# ? Feb 4, 2015 18:43

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

csammis posted:

What the hell book is this, "OSes for Dummies"?

http://pages.cs.wisc.edu/~remzi/OSTEP/

Edit: That's right, there's Socratic dialogues in this thing. And the characters all talk like they're in XKCD or something.

double edit: Professionally I am a technical writer, so I get really cranky whenever they put a diagram 3 pages away from the text it discusses, or an aside box in the middle of a sentence. They do it A LOT. I offered some feedback on it and was met with extreme hostility.

The MUMPSorceress fucked around with this message at 18:46 on Feb 4, 2015

# ? Feb 4, 2015 18:43

csammis: Aug 26, 2003; Mental Institution

Wow, my condolences. That sounds completely insufferable.

If you're interested in an OS textbook that isn't self-absorbed bullcrap, I liked Modern Operating Systems by Tanenbaum or Operating System Concepts (the dinosaur book)...but this was 10+ years ago and maybe the modern editions are also written for children by children

# ? Feb 4, 2015 18:51

FlapYoJacks: Feb 12, 2009

Skuto posted:

Meanwhile, in embedded (really, Android) land, we discovered a vendor has been shipping drivers that try to load firmware...using a relative path...while being loaded in the application context.

Took about a week of debugging to see why our software just wouldn't work on a peculiar set of devices.

Ahh vendor drivers. :allears:

I had to fix a vendor provided gps driver that wasn't even parsing nmea correctly, and had at least 2 (maybe 3, been a while) thread lock potentials due to not using mutexes anywhere in the driver.

# ? Feb 4, 2015 19:00

Deus Rex: Mar 5, 2005

LeftistMuslimObama posted:

This textbook is written in the most insufferable, halting nerd-syntax

Is Steve Klabnik one of the authors, by chance?

# ? Feb 4, 2015 22:18

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Bonwick is a badass, though.

# ? Feb 4, 2015 23:04

Deus Rex: Mar 5, 2005

LeftistMuslimObama posted:

http://pages.cs.wisc.edu/~remzi/OSTEP/

Edit: That's right, there's Socratic dialogues in this thing. And the characters all talk like they're in XKCD or something.

I skimmed through the book's online version and the dialogue stuff is limited to the introduction for each major section. These "Dialogue" sections look pretty much optional to read, not like there's important information tucked away in there that you wouldn't find elsewhere. The rest of the book seems pretty normal and fine to me.

My best guess is the authors read something like "A Play on Regular Expressions" and thought they'd imitate it. At least their missteps are limited to clearly marked sections of the book you're free to skip.

# ? Feb 5, 2015 02:53

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

Subjunctive posted:

Bonwick is a badass, though.

No doubt, I just object to literally telling your students that some people are just full stop better than you and if you're not that great you should just give up and feel sad.

Deus Rex posted:

I skimmed through the book's online version and the dialogue stuff is limited to the introduction for each major section. These "Dialogue" sections look pretty much optional to read, not like there's important information tucked away in there that you wouldn't find elsewhere. The rest of the book seems pretty normal and fine to me.

My best guess is the authors read something like "A Play on Regular Expressions" and thought they'd imitate it. At least their missteps are limited to clearly marked sections of the book you're free to skip.

A skim can't really show you this book's problems. The authors have no idea how to construct a sentence, they're constantly putting "aside" boxes in the middle of sentences just for the sake of having them at the beginning or end of a page, they frequently put diagrams pages away from the related text, and there are literally footnotes all over the place that are just lame jokes. All of that is super disruptive and prevents you from absorbing the material because you're constantly being disrupted by bad writing or layout.

I'm probably hypersensitive to this stuff because I write technical documentation for a living (at least until I finish this class and jump ship to dev dreamland), but these are really basic things that any editor would point out to them, but it's pretty clear that they haven't had it edited at all and are pretty opposed to receiving feedback.

# ? Feb 5, 2015 06:13

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

LeftistMuslimObama posted:

No doubt, I just object to literally telling your students that some people are just full stop better than you and if you're not that great you should just give up and feel sad.

Yes, that is objectionable and the only moral thing to do is object. I could not agree more, I just think Bonwick is a great dude who doesn't get enough appreciation.

(FWIW, I think Bonwick and Zuck would both object, though I don't know Bonwick as well.)

Subjunctive fucked around with this message at 06:39 on Feb 5, 2015

# ? Feb 5, 2015 06:36

Athas: Aug 6, 2007; fuck that joker

csammis posted:

Operating System Concepts (the dinosaur book)

This book is pretty crap. It's the typical American textbook; totally stuffed with irrelevant material and written in a very bloated style, and containing many obsolete and pointless algorithms. I have actually heard good things about the book LeftistMuslimObama is slamming, although mostly from the point of view of technical information and basic didactic structure (viewing an OS as a set of abstractions). I can easily believe the editing is poor, as it seems self-published.

There are not many textbooks describing modern operating systems design. The best way is probably just to write some kernel code and see for yourse.f.

# ? Feb 5, 2015 07:23

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

quote:

TIP : GETTING IT RIGHT (LAMPSON�S LAW)
As Lampson states in his well-regarded �Hints for Computer Systems Design� [L83], �Get it right. Neither abstraction nor simplicity is a substitute for getting it right.� Sometimes, you just have to do the right thing, and when you do, it is way better than the alternatives. There are lots of ways to design APIs for process creation; however, the combination of fork() and exec() are simple and immensely powerful. Here, the UNIX designers simply got it right. And because Lampson so often �got it right�, we name the law in his honor.

loving laffo. Any OS engineer could be able to tell you why fork() and exec() are bonkers insane.

# ? Feb 5, 2015 08:51

Workaday Wizard: Oct 23, 2009; by Pragmatica

Suspicious Dish posted:

loving laffo. Any OS engineer could be able to tell you why fork() and exec() are bonkers insane.

I would like to know more.

# ? Feb 5, 2015 09:15

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Well, first of all, COW means that the kernel needs to overcommit memory on fork();. By default, the kernel makes a good assumption that the fork(); will eventually exec();, and assumes that very little of the memory of your original process will actually be copied, so it does a compromise and allows other processes on the system to use more memory than it actually has. This leads to the OOM killer and killing random processes when the system has actually run out of memory.

It's also fundamentally the wrong abstraction and has been since the day the concept of multithreading appeared. fork(); will only fork the current thread, so if you have resources (like a mutex) that were managed by a separate thread, your child could hang waiting for a mutex that never gets unlocked, since the other thread holding it doesn't exist anymore. So you're not allowed to call malloc(); (it takes a mutex internally), you're not allowed to basically call anything but setenv, dup, and exec();.

I would prefer a system where fork(); took a function pointer, the child process inherited all the VM maps from the parent process but were set readonly, not COW, and the stack page starts empty and fresh. That would allow us to set up the child environment (set envvars, dup fd's) without the giant pitfall that the rest of fork(); has.

fork(); is so broken that the original authors ripped it out and replaced it with rfork(); in Plan 9, Linux has clone();, and POSIX specified the mind-blowingly-useless vfork();.

But nope, it was a clear example of "getting it right".

# ? Feb 5, 2015 09:29

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

The idea of just running code to set up the environment of whatever child process isn't a bad one (and there's certainly an argument that it's better than the CreateProcess method of finding some way to specify every possible configuration option you might ever need as parameters), the problem is really everything else involved with fork() (like the fact that it's technically possible to do things other than call exec immediately after configuring the child process).

Perhaps a better option would be to just create a process paused, and then manipulate that process object a whole bunch before you actually set it running. Almost like the builder pattern in more enterprisey programming languages.

# ? Feb 5, 2015 13:11

dwazegek: Feb 11, 2005; WE CAN USE THIS

I'm not familiar enough with C to determine if this is a horror, but I think it is.

I was browsing the wikipedia page on checkdigits, and under the section for ISBN 10 it says the following:

quote:

The sum can be computed without any multiplications by initializing two variables, t and sum, to 0 and repeatedly performing t = t + digit; sum = sum + t; (which can be expressed in C as sum += t += digit;)

code:

sum += t += digit;

Isn't that undefined behavior in C?

# ? Feb 5, 2015 14:44

nielsm: Jun 1, 2009

I believe that parenthesizes as:
sum += (t += digit)

The value of an assignment expression is the new value of the assigned-to variable.

So:
t += digit
reads t, adds digit to it, writes back to t, is an expression with the new value of t

And then
sum += expression
does the same thing, except that here the expression is also an assignment.

What might be undefined was if you do something like
sum += sum += digit
since that assigns to sum twice in one sequence element, meaning the order of the assignments would be undefined.

(Sequence element? Is there a proper name for that?)

# ? Feb 5, 2015 14:51

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Sequence point.

# ? Feb 5, 2015 15:11

dwazegek: Feb 11, 2005; WE CAN USE THIS

nielsm posted:

What might be undefined was if you do something like
sum += sum += digit
since that assigns to sum twice in one sequence element, meaning the order of the assignments would be undefined.

Yeah you're right, this was what I was thinking of. Guess I'm the horror :v:

# ? Feb 5, 2015 15:43

csammis: Aug 26, 2003; Mental Institution

Suspicious Dish posted:

It's also fundamentally the wrong abstraction and has been since the day the concept of multithreading appeared. fork(); will only fork the current thread, so if you have resources (like a mutex) that were managed by a separate thread, your child could hang waiting for a mutex that never gets unlocked, since the other thread holding it doesn't exist anymore. So you're not allowed to call malloc(); (it takes a mutex internally), you're not allowed to basically call anything but setenv, dup, and exec();.

One of the bigger horrors I've experienced at work (that wasn't code I wrote) was a third party library we use for fulltext indexing. When indexing a certain file type the indexer would hang and two of the processes would show up in the process list. Sure enough, we finally figured out that the library was fork()ing forty goddamn frames deep in the call stack. It seems that the library designers assumed it would only ever be used by a single-threaded parent process and when we changed our process framework to use per-thread mutexes instead of global mutexes then *poof*

Naturally the company that created this library hasn't existed for some time and the IP is currently owned by one of our biggest competitors :sigh:

# ? Feb 5, 2015 17:37

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Naive: how do per-thread mutexes work? If only one thread can access them, how do they help coordinate multiple threads?

# ? Feb 5, 2015 18:00

Hiowf: Jun 28, 2013; We don't do .DOC in my cave.

I'm assuming he's talking about separate feeding datastructures per thread with a lock per datastructure rather than a single global lock for "all potentially shared data" or something like that.

# ? Feb 5, 2015 19:14

csammis: Aug 26, 2003; Mental Institution

Skuto posted:

I'm assuming he's talking about separate feeding datastructures per thread with a lock per datastructure rather than a single global lock for "all potentially shared data" or something like that.

Yep that's right

# ? Feb 5, 2015 19:33

Karate Bastard: Jul 31, 2007; Soiled Meat

nielsm posted:

What might be undefined was if you do something like
sum += sum += digit
since that assigns to sum twice in one sequence element, meaning the order of the assignments would be undefined.

I don't do this poo poo and am blessed to work with people who know not to do this poo poo, but that poo poo ain't precisely undefined, is it? Someone else might correct me, but sum += sum does not produce an lvalue for += to act upon, so sum += digit needs to be evaluated first, so you'll end up with sum = sum * 2 + digit, right?

e: oh no that's right, the right += should affect the left sum as well, producing sum = (sum + digit) * 2. Or something involving void*. Don't mind me, I'm confused.

Karate Bastard fucked around with this message at 20:11 on Feb 5, 2015

# ? Feb 5, 2015 20:04

nielsm: Jun 1, 2009

Karate Bastard posted:

I don't do this poo poo and am blessed to work with people who know not to do this poo poo, but that poo poo ain't precisely undefined, is it? Someone else might correct me, but sum += sum does not produce an lvalue for += to act upon, so sum += digit needs to be evaluated first, so you'll end up with sum = sum * 2 + digit, right?

Either of these could be a valid rewriting of that expression:
sum += digit; sum += sum;
or
temp = sum; sum += digit; sum = temp + sum;

What makes a valid lvalue or not doesn't come into play, the associativity the operators doesn't magically change depending on what would or would not make valid expressions. The assignment operators are always right-associative because that's what makes most sense in the general case.
However there isn't any definition of what order the operands of an expression are evaluated in. Two different compilers could generate the operands in different ways.

code:

mov eax, [sum]   ; operand 1
mov ebx, [sum]   ; operand 2
mov ecx, [digit] ; operand 3
add ebx, ecx     ; right-hand subexpression addition
mov [sum], ebx   ; store right-hand subexpression back
add eax, ebx     ; outer subexpression addition
mov [sum], eax   ; store final result back

; is just as valid as

mov eax, [sum]   ; operand 2
mov ebx, [digit] ; operand 3
add eax, ebx     ; right-hand subexpression addition
mov [sum], eax   ; store right-hand subexpression back
mov eax, [sum]   ; operand 1
mov ebx, [sum]   ; right-hand subexpression
add eax, ebx     ; outer subexpression addition
mov [sum], eax   ; store final result back

# ? Feb 5, 2015 20:24

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Suspicious Dish posted:

Well, first of all, COW means that the kernel needs to overcommit memory on fork();. By default, the kernel makes a good assumption that the fork(); will eventually exec();, and assumes that very little of the memory of your original process will actually be copied, so it does a compromise and allows other processes on the system to use more memory than it actually has. This leads to the OOM killer and killing random processes when the system has actually run out of memory.

It's also fundamentally the wrong abstraction and has been since the day the concept of multithreading appeared. fork(); will only fork the current thread, so if you have resources (like a mutex) that were managed by a separate thread, your child could hang waiting for a mutex that never gets unlocked, since the other thread holding it doesn't exist anymore. So you're not allowed to call malloc(); (it takes a mutex internally), you're not allowed to basically call anything but setenv, dup, and exec();.

I would prefer a system where fork(); took a function pointer, the child process inherited all the VM maps from the parent process but were set readonly, not COW, and the stack page starts empty and fresh. That would allow us to set up the child environment (set envvars, dup fd's) without the giant pitfall that the rest of fork(); has.

fork(); is so broken that the original authors ripped it out and replaced it with rfork(); in Plan 9, Linux has clone();, and POSIX specified the mind-blowingly-useless vfork();.

But nope, it was a clear example of "getting it right".

why are you putting semicolons after function names

like i get using parens to clarify that it is a function instead of an english word, that is a useful convention that i often use myself, but semicolons have grammatical value in english

# ? Feb 5, 2015 21:13

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

rjmccall posted:

why are you putting semicolons after function names

like i get using parens to clarify that it is a function instead of an english word, that is a useful convention that i often use myself, but semicolons have grammatical value in english

if you're going to put the parens throw in the man page section as well

# ? Feb 5, 2015 21:19

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

rjmccall posted:

why are you putting semicolons after function names

like i get using parens to clarify that it is a function instead of an english word, that is a useful convention that i often use myself, but semicolons have grammatical value in english

No particular reason other than force of habit and not expecting people to get mad at it I guess.

# ? Feb 5, 2015 22:27

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

Suspicious Dish posted:

and not expecting people to get mad at it I guess.

Classic mistake!

# ? Feb 5, 2015 23:20

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

Yeah, the whole time they were explaining fork and how elegant it was in the lecture, I kinda kept wondering to myself "am I the only person in here who thinks this is really stupid?". Glad to know I'm not alone.

I especially loved the part about how great it is that the child and parent are totally sharing the same memory until they aren't.

# ? Feb 5, 2015 23:24

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Suspicious Dish posted:

No particular reason other than force of habit and not expecting people to get mad at it I guess.

It did actually make your post somewhat harder to read; there were several garden paths where the semicolon made sense for a second and then, after the new "sentence" inevitably became nonsense, I had to go back to reread it without the semicolon.

I am honestly curious about it; I'm not sure I have ever seen it before. Like I said, parens make sense and are pretty common, but semicolons are new to me.

# ? Feb 5, 2015 23:24

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

LeftistMuslimObama posted:

Yeah, the whole time they were explaining fork and how elegant it was in the lecture, I kinda kept wondering to myself "am I the only person in here who thinks this is really stupid?". Glad to know I'm not alone.

I especially loved the part about how great it is that the child and parent are totally sharing the same memory until they aren't.

It's elegant if you're writing a toy kernel.

# ? Feb 5, 2015 23:47

b0lt: Apr 29, 2005

LeftistMuslimObama posted:

Yeah, the whole time they were explaining fork and how elegant it was in the lecture, I kinda kept wondering to myself "am I the only person in here who thinks this is really stupid?". Glad to know I'm not alone.

I especially loved the part about how great it is that the child and parent are totally sharing the same memory until they aren't.

i am writing something right now that uses the linux clone syscall to make a thread that shares memory but not file descriptors :getin:

# ? Feb 6, 2015 00:01

qntm: Jun 17, 2009

Ah, "Get It Right", what a useful, pointless, insulting, tautological piece of advice

# ? Feb 6, 2015 01:50

ExcessBLarg!: Sep 1, 2001

LeftistMuslimObama posted:

Yeah, the whole time they were explaining fork and how elegant it was in the lecture,

Are you actually taking Remzi's/Andrea's class, or at least attending Wisconsin-Madison? Professors like to pretend their poo poo doesn't stink, but if this is actually being used at another respectable institution that's insane.

# ? Feb 6, 2015 02:08

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

ExcessBLarg! posted:

Are you actually taking Remzi's/Andrea's class, or at least attending Wisconsin-Madison? Professors like to pretend their poo poo doesn't stink, but if this is actually being used at another respectable institution that's insane.

I am at UW, but they are currently exploiting the hell out of grad student lecturers in the CS department. The only class I've taken with an actual faculty member is data structures.

# ? Feb 6, 2015 03:50

ExcessBLarg!: Sep 1, 2001

LeftistMuslimObama posted:

I am at UW, but they are currently exploiting the hell out of grad student lecturers in the CS department.

Sounds like an inbreeding problem.

# ? Feb 6, 2015 04:41

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 16:47

ExcessBLarg!: Sep 1, 2001

Suspicious Dish posted:

Any OS engineer could be able to tell you why fork() and exec() are bonkers insane.

I disagree. Conceptually fork is a very convenient, and relatively-straight forward (at a high level) approach to spawning processes that affords userspace a lot of flexibility in terms of setting up child processes and establishing communications back with the parent. Obviously the details are a bit hairy, but no less so than alternative mechanisms that are sufficiently flexible. Now, it's true conformant fork(2) has too inflexible semantics in modern kernels, which is why Linux's clone(2) came about. Conceptually though, clone is still based on the idea of, and implements, process forking.

Suspicious Dish posted:

Well, first of all, COW means that the kernel needs to overcommit memory on fork()

It does not, you can run the kernel in "don't overcommit" mode in which case Linux will return ENOMEM if there's insufficient memory for all the read-write pages. Conversely processes can create memory overcommitments through brk and mmap without having to fork either. The reality is that Linux allows memory overcommitment by default as it's useful when memory use is inefficient, which can be for a number of reasons other than COW fork rw pages (e.g., wasted space in thread stacks).

ExcessBLarg! fucked around with this message at 05:17 on Feb 6, 2015

# ? Feb 6, 2015 04:58

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »