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 »

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

i allow myself one swear per codebase, and decide very thoughtfully where to put it

# ? Jan 6, 2020 20:37

Adbot: ADBOT LOVES YOU

# ? Jun 6, 2024 17:56

redleader: Aug 18, 2005; Engage according to operational parameters

Suspicious Dish posted:

i allow myself one swear per codebase, and decide very thoughtfully where to put it

gently caress.csproj

# ? Jan 6, 2020 20:56

QuarkJets: Sep 8, 2008

Volguus posted:

It depends. Is there a method that implements CooperHarveyKennedy2002 algorithm? If yes, then computeDominanceFrontiersFollowingCooperHarveyKennedy2001() is totally appropriate, as well as computeDominanceFrontiersFollowingCooperHarveyKennedy2002() .

This is overly verbose. If Cooper, Harvey, and Kennedy published more than 1 paper together in 2001 then are you really going to add MLA citations to your method names, or would it make more sense to just use a shorter method name with a comment that contains a citation?

Like imagine if every standard library did things this way. Yikes

# ? Jan 6, 2020 21:16

taqueso: Mar 8, 2004

I put two sets of comments in each file, one pedantic and one terse. Plus a meta comment discussing the merits of each.

# ? Jan 6, 2020 21:24

boo_radley: Dec 30, 2005; Politeness costs nothing

redleader posted:

gently caress.csproj

piss.sh

# ? Jan 6, 2020 21:40

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

redleader posted:

gently caress.csproj

poo poo.sln :colbert:

# ? Jan 6, 2020 22:00

Volguus: Mar 3, 2009

QuarkJets posted:

This is overly verbose. If Cooper, Harvey, and Kennedy published more than 1 paper together in 2001 then are you really going to add MLA citations to your method names, or would it make more sense to just use a shorter method name with a comment that contains a citation?

Like imagine if every standard library did things this way. Yikes

Then give them (the algorithms) a more palatable name. They dont have to be named by the name of the paper. The idea is: differentiate them by the method name if you can. If it'll be overly verbose try to shorten it a bit. If you can't then that's fine. If you have to choose between a short and non-descriptive name and an overly verbose one, go with the verbose one.

The worst way to go would be computeDominanceFrontiers1(), computeDominanceFrontiers2(), computeDominanceFrontiers2Ex() to account for algorithm variations (assuming the variations cannot be just specified as a parameter to that function).

Volguus fucked around with this message at 22:17 on Jan 6, 2020

# ? Jan 6, 2020 22:14

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

Volguus posted:

Whatever name you choose should be relevant and obvious for whoever will be maintaining the code (you 6 months from now). Just like the interface names are important for other developers, implementation details are important for maintainers. There should not be a different naming standard for the 2 classes of developers.

Are you seriously claiming that the names you choose for the public interface you expose, should contain implementation details that are only relevant for the people that maintain the internals?

# ? Jan 6, 2020 22:46

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Jabor posted:

Are you seriously claiming that the names you choose for the public interface you expose, should contain implementation details that are only relevant for the people that maintain the internals?

I would seriously say that ArrayList and LinkedList are valuable, even if I only use ArrayList through List

# ? Jan 7, 2020 00:57

DaTroof: Nov 16, 2000; CC LIMERICK CONTEST GRAND CHAMPION
There once was a poster named Troof
Who was getting quite long in the toof

leper khan posted:

I would seriously say that ArrayList and LinkedList are valuable, even if I only use ArrayList through List

That's an instance where the implementation detail is relevant to the user.

# ? Jan 7, 2020 02:50

Linear Zoetrope: Nov 28, 2011; A hero must cook

While this is language dependent, I'd distinguish on type or module for a lot of this.

code:

trait DominanceFrontierAlgorithm  {
    fn compute(/* <params> */);
}

// ...

// No member struct, just a type wrapper for the algorithm.
pub struct CooperHarveryKennedy2002;

impl DominanceFrontierAlgorithm for CooperHarveryKennedy2002 {
    fn compute(/* <params */) {
        // ...
    }
}

code:

// Same functionality, different files/modules to namespace the function.

mod cooper_harvey_kennedy_2001 {
    fn dominance_frontiers () -> Whatever {

    }
}

mod cooper_harvey_kennedy_2002 {
    fn dominance_frontiers() -> Whatever {
    }
}

or whatever.

You can mix and match this with making it switch on enums or parameters instead of calling the whole function raw too, obviously. Personally I'd also shorten names that are too long to either one name, or an initialism of some sort. Cooper2002 or Chk2002 or CooperHk2002 or whatever.

I have done named functions with similar purposes, e.g. if you have a graph package, it's not out of the question to have a strongly_connected_component module with functions named "Tarjan" and "Kosaraju" (okay bad example, you basically always want Tarjan's). Or have "Dijkstra" in a package next to "DepthFirstSearch", but these are cases where the nature of the algorithm is disambiguated by the context it appears in. I'm struggling to think of a scenario where you'd need to have something structured in a way that you need several functions that accomplish the same/similar goal(s) where you need to put both the purpose of the algorithm and the name of the algorithm itself in the function name.

Linear Zoetrope fucked around with this message at 03:15 on Jan 7, 2020

# ? Jan 7, 2020 03:10

Qwertycoatl: Dec 31, 2008

code:

compute_dominance_frontiers_using_algorithm_from_http_colon_slash_slash_miskatonic_dot_edu_slash_tilde_cooper_slash_papers_slash_dominance_dot_pdf()

# ? Jan 7, 2020 09:53

QuarkJets: Sep 8, 2008

Volguus posted:

Then give them (the algorithms) a more palatable name. They dont have to be named by the name of the paper. The idea is: differentiate them by the method name if you can. If it'll be overly verbose try to shorten it a bit. If you can't then that's fine. If you have to choose between a short and non-descriptive name and an overly verbose one, go with the verbose one.

If you're writing code that implements multiple versions of similar algorithms then I agree that you should try to name them in a way that makes sense while also differentiating them in a way that's meaningful. I just don't think it's appropriate to write out a fairly long plain-English sentence as a method name, because that sucks to work with. computeDominanceFrontiersFollowingCooperHarveyKennedy2001 is a bad name in my opinion because it's simply too long.

# ? Jan 7, 2020 10:26

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

QuarkJets posted:

If you're writing code that implements multiple versions of similar algorithms then I agree that you should try to name them in a way that makes sense while also differentiating them in a way that's meaningful. I just don't think it's appropriate to write out a fairly long plain-English sentence as a method name, because that sucks to work with. computeDominanceFrontiersFollowingCooperHarveyKennedy2001 is a bad name in my opinion because it's simply too long.

Well of course, that's why you write it as

code:

cmptDomFrtrsCprHrvyKdy01(...)

as it fits more nicely in the line and generates job security since there's no loving comments whatsoever.

# ? Jan 7, 2020 14:23

Volguus: Mar 3, 2009

Jabor posted:

Are you seriously claiming that the names you choose for the public interface you expose, should contain implementation details that are only relevant for the people that maintain the internals?

I'm seriously claiming that you should name your methods in such a way that they make sense for your users. "Your users" can be you 6 months from now if it's a private method meant for private consumption and will only be seen by the maintainers of the code and not exposed to the general public.
I am seriously saying that while naming is hard in and of itself, people should not be dogmatic about the names they choose, try to follow some arbitrary set of rules that may or may not fit their purpose at the time. I am seriously saying that one should think before doing. The only hard rule to follow is "choose names that make sense for whoever will be using this method, be they outside users or maintainers of the code".

Are you seriously claiming otherwise? Are you seriously ready to defend such a position? Do you have a book ready that you haven't read to defend it with?

# ? Jan 7, 2020 14:46

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

That didn't clear up your position at all!

# ? Jan 7, 2020 14:48

Volguus: Mar 3, 2009

Jabor posted:

That didn't clear up your position at all!

What position? That you should use common sense when naming stuff?

# ? Jan 7, 2020 14:49

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

Volguus posted:

What position? That you should use common sense when naming stuff?

Given the points at which you choose to pick fights, this doesn't seem much like your position at all.

# ? Jan 7, 2020 14:54

Volguus: Mar 3, 2009

Jabor posted:

Given the points at which you choose to pick fights, this doesn't seem much like your position at all.

Haha. Are you really that obtuse or do you have a point here?

# ? Jan 7, 2020 14:57

dougdrums: Feb 25, 2005; CLIENT REQUESTED ELECTRONIC FUNDING RECEIPT (FUNDS NOW)

I try to be as clear and necessarily verbose as I can when coming up with function identifiers, generally using something that could be read as plain English. The length of an identifier should be inversely proportional to the amount of times it appears, as a loose rule of thumb. I.e. single letter variable identifiers are ok in lambdas, variable identifiers in the scope of a function block are one or two words at most, class properties can be longer if needed.

Multiple functions with related behavior can be dispatched by type/parameters, and should be given a shorter identifier with a more general meaning.

In the rare instance where the identifier length would be unwieldy relative to the amount of times it might show up, I'd abbreviate it and leave a comment with what I'd otherwise want to name it.

E: I err on the side of longer identifiers for publicly facing stuff since I personally would rather deal with something that has a long rear end name but is obvious, rather than having to look it up.

dougdrums fucked around with this message at 15:06 on Jan 7, 2020

# ? Jan 7, 2020 14:59

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

Volguus posted:

Haha. Are you really that obtuse or do you have a point here?

Gee, I wonder what started this whole exchange?

Bongo Bill posted:

The goal is to make it so that a colleague looking at the code will understand it. If it needs comments other than variable and method names, you've made it too weird and should be rewritten.

Soricidus posted:

I have doubts about this assertion.

For example, are you really suggesting that it’s better to have a method called computeDominanceFrontiersFollowingCooperHarveyKennedy2001(), rather than calling the method computeDominanceFrontiers() and having a comment that points readers to the paper that explains in detail the algorithm used and it’s tradeoffs relative to other algorithms? Even though the code is not “weird” and the algorithm is pretty straightforward, it is appropriate to comment this.

It’s not like people are any more likely to update method and variable names than they are to update comments when the implementation changes. A method name is just a comment that gets repeated at every call site.

Volguus posted:

Well ackshully, sometimes it's right to call a method computeDominanceFrontiersFollowingCooperHarveyKennedy2001()

# ? Jan 7, 2020 15:05

Volguus: Mar 3, 2009

Jabor posted:

Gee, I wonder what started this whole exchange?

Yes, there can be times when calling a method that name is appropriate. Are you really implying there is never such a time? Are you seriously saying that? Never ever? Really? :allears:

# ? Jan 7, 2020 15:13

Volte: Oct 4, 2004; woosh woosh

I ran into this issue like four days ago with polygon triangulation and I definitely want libraries that implement that to let me know which algorithms are being used and preferably allow me to choose among multiple ones. I've found that the specific algorithm being used being an implementation detail is only really true when you're talking about implementations of abstract data structures where the outcome is the only important thing and how you get there is irrelevant. On the other hand, geometric algorithms generally have unique characteristics and algorithm choice is something that the user is pretty much always going to care about. If I'm subdividing a mesh, go ahead and name the method SubdivideMeshCatmullClark, because if you just name it SubdivideMesh then it's not very helpful.

# ? Jan 7, 2020 15:15

dougdrums: Feb 25, 2005; CLIENT REQUESTED ELECTRONIC FUNDING RECEIPT (FUNDS NOW)

Ya I mean for the dominance frontiers case you probably could give a poo poo less or safely assume what algorithm going to be used, so computeDominanceFrontiers is cool and good, and if I really did care I could just look at the documentation.

In language where it's ok, the algorithm you want ought to be selected by passing an enum to the function, and setting the parameter to some sane or common default; or extending the base implementation; but I'd prefer the former, even if it means passing an enum to a constructor and selecting a private method based on what is passed to the generic public one.

Otherwise ya just put it in the identifier if it might be relevant.

# ? Jan 7, 2020 15:34

Volguus: Mar 3, 2009

Volte posted:

I ran into this issue like four days ago with polygon triangulation and I definitely want libraries that implement that to let me know which algorithms are being used and preferably allow me to choose among multiple ones. I've found that the specific algorithm being used being an implementation detail is only really true when you're talking about implementations of abstract data structures where the outcome is the only important thing and how you get there is irrelevant. On the other hand, geometric algorithms generally have unique characteristics and algorithm choice is something that the user is pretty much always going to care about. If I'm subdividing a mesh, go ahead and name the method SubdivideMeshCatmullClark, because if you just name it SubdivideMesh then it's not very helpful.

All kinds of mathematical libraries out there let you know (and choose) what algorithm you're using for a particular operation. User facing API even, not internal maintainer stuff. Jabor here is just being confrontational for the sake of it. Hell, I could have said that the sky is red sometimes and he would have come out yelling that it is usually blue and "how dare you!!!".

Here's a piece of advice Jabor: Relax, grab a KitKat. The year has just started, there's plenty of time to dissect and correct my posts. I post stupid poo poo all the time, so I'm sure you won't have to wait too long.

# ? Jan 7, 2020 16:12

Adhemar: Jan 21, 2004; Kellner, da ist ein scheussliches Biest in meiner Suppe.

dougdrums posted:

Ya I mean for the dominance frontiers case you probably could give a poo poo less or safely assume what algorithm going to be used, so computeDominanceFrontiers is cool and good, and if I really did care I could just look at the documentation.

In language where it's ok, the algorithm you want ought to be selected by passing an enum to the function, and setting the parameter to some sane or common default; or extending the base implementation; but I'd prefer the former, even if it means passing an enum to a constructor and selecting a private method based on what is passed to the generic public one.

Otherwise ya just put it in the identifier if it might be relevant.

If the language supports polymorphism, please use that for something like this.

# ? Jan 7, 2020 17:19

JawnV6: Jul 4, 2004; So hot ...

I'm losing my poo poo that this edited quote has been posted, multiple times by multiple posters, without the next line:

Bongo Bill posted:

The goal is to make it so that a colleague looking at the code will understand it. If it needs comments other than variable and method names, you've made it too weird and should be rewritten.

Everyone's taking this point and launching into their lil diatribe without looking at the next sentence, wherein our forums poster Bongo Bill admits that comments are necessary for the 'weird' contexts we're talking about :

Bongo Bill posted:

Conversely, if you can't rewrite it to be less weird, then it needs comments.

It was not a blanket condemnation of All Comments. Because I went and quoted the post, here's the rest of the nuance, where a specific phrase is included in the COMMENTS THAT DEFINITELY WERE WRITTEN AND EXIST:

Bongo Bill posted:

Keep the confusing part brief and the comment descriptive. I like to stick an "I apologize for the confusion" at the end when some exceptional situation defeats me.

Commit messages should be used to explain why a particular section of code was written at all, but not why it was written the way it was.

It was a description about tradeoffs between comments and commit messages, y'all just take whatever fragment makes you object first and rush to post.

And Volguus, this is a confusing hash of a comma spliced run-on sentence followed by pithy vacuousness:

Volguus posted:

I am seriously saying that while naming is hard in and of itself, people should not be dogmatic about the names they choose, try to follow some arbitrary set of rules that may or may not fit their purpose at the time. I am seriously saying that one should think before doing.

I agree that this did not clarify your position. Like... does the 'should not' cover the 'arbitrary set' clause? When you're going on blast for folks not recognizing your singular genius, maybe take a look back at the word salad you've provided and check if some editing is in order.

# ? Jan 7, 2020 17:25

DaTroof: Nov 16, 2000; CC LIMERICK CONTEST GRAND CHAMPION
There once was a poster named Troof
Who was getting quite long in the toof

Volguus posted:

All kinds of mathematical libraries out there let you know (and choose) what algorithm you're using for a particular operation. User facing API even, not internal maintainer stuff. Jabor here is just being confrontational for the sake of it. Hell, I could have said that the sky is red sometimes and he would have come out yelling that it is usually blue and "how dare you!!!".

Here's a piece of advice Jabor: Relax, grab a KitKat. The year has just started, there's plenty of time to dissect and correct my posts. I post stupid poo poo all the time, so I'm sure you won't have to wait too long.

I think this discussion went off the rails because you're reducing each other's arguments to strawman absolutes. For example...

Jabor posted:

Are you seriously claiming that the names you choose for the public interface you expose, should contain implementation details that are only relevant for the people that maintain the internals?

Emphasis mine. So...

Volguus posted:

Yes, there can be times when calling a method that name is appropriate. Are you really implying there is never such a time? Are you seriously saying that? Never ever? Really?

No, he doesn't seem to be saying that.

# ? Jan 7, 2020 18:10

Steve French: Sep 8, 2003

Volguus posted:

I'm seriously claiming that you should name your methods in such a way that they make sense for your users. "Your users" can be you 6 months from now if it's a private method meant for private consumption and will only be seen by the maintainers of the code and not exposed to the general public.
I am seriously saying that while naming is hard in and of itself, people should not be dogmatic about the names they choose, try to follow some arbitrary set of rules that may or may not fit their purpose at the time. I am seriously saying that one should think before doing. The only hard rule to follow is "choose names that make sense for whoever will be using this method, be they outside users or maintainers of the code".

Are you seriously claiming otherwise? Are you seriously ready to defend such a position? Do you have a book ready that you haven't read to defend it with?

Volguus posted:

Yes, there can be times when calling a method that name is appropriate. Are you really implying there is never such a time? Are you seriously saying that? Never ever? Really?

Let me recap the conversation a bit and how I understood it, at least parts I was participating in, and perhaps you can then point out to me where exactly I've lost your thread because I sure have.

You posted this:

Volguus posted:

It depends. Is there a method that implements CooperHarveyKennedy2002 algorithm? If yes, then computeDominanceFrontiersFollowingCooperHarveyKennedy2001() is totally appropriate, as well as computeDominanceFrontiersFollowingCooperHarveyKennedy2002() . The comment alone would not do. If there's only one computeDominanceFrontiers algorithm in the entire application, then sure, only comment the flavour used.
You can start with the shorter name and refactor to the longer name when the new version comes along. Don't have to start with the longer version in the hopes that it'll become clear in the future on why.

Which I (perhaps wrongly on a second read through) read as arguing against comments and in favor of conveying details in naming. Perhaps you simply meant that it is often appropriate to put those details in names while also putting necessary relevant additional details in comments.

Much of the original discussion was focused on

My take on this, that I was getting at with this comment:

Steve French posted:

Ok, now if the algorithm used is an implementation detail and not part of the interface?

Is that not only is it not always inappropriate to have comments in code explaining things, but that it is also not always appropriate to use naming to convey those details. Specific examples include:
- the comment is for a pure implementation detail that should be hidden from the caller
- the comment is in a method that is part of an interface that the class is implementing, and the author doesn't actually have any choice in the naming of the method (in addition to the first point, presumably)
- the comment contains detail that can't reasonably be conveyed in a method name: e.g. not just the name of the algorithm used, but also the rationale for using that particular algorithm, parameters, etc and a link to additional background information.

And your response is where I think we lost each other:

Volguus posted:

Whatever name you choose should be relevant and obvious for whoever will be maintaining the code (you 6 months from now). Just like the interface names are important for other developers, implementation details are important for maintainers. There should not be a different naming standard for the 2 classes of developers.

I'm not and wasn't arguing against intelligent naming without dogmatic application of rules. My take that I was trying to convey is that there are plenty of situations where comments explaining things are not only good, but not even an indication of weirdness or excessive complexity that can't be overcome: the example being discussed is a great example. Documenting succinctly which algorithm is used and why is not a code smell, IMO.

I also don't follow your last comment about there being different naming standards for 2 classes of developers; simply that methods that are part of the public interface should probably not (and sometimes cannot) generally be named based on implementation details that are not relevant to the consumer of that interface. Would it be easier for the maintainer if they did? Perhaps, though if the clarity for maintainer vs user are at odds with each other, I'll make it easier for the user.

So with that, were we just talking past one another? Are there specific things above that you do disagree with? Or any of it where I'm misunderstanding your argument?

# ? Jan 7, 2020 18:17

Volguus: Mar 3, 2009

Steve French posted:

Is that not only is it not always inappropriate to have comments in code explaining things, but that it is also not always appropriate to use naming to convey those details. Specific examples include:
- the comment is for a pure implementation detail that should be hidden from the caller
- the comment is in a method that is part of an interface that the class is implementing, and the author doesn't actually have any choice in the naming of the method (in addition to the first point, presumably)
- the comment contains detail that can't reasonably be conveyed in a method name: e.g. not just the name of the algorithm used, but also the rationale for using that particular algorithm, parameters, etc and a link to additional background information.

And your response is where I think we lost each other:

I'm not and wasn't arguing against intelligent naming without dogmatic application of rules. My take that I was trying to convey is that there are plenty of situations where comments explaining things are not only good, but not even an indication of weirdness or excessive complexity that can't be overcome: the example being discussed is a great example. Documenting succinctly which algorithm is used and why is not a code smell, IMO.

I also don't follow your last comment about there being different naming standards for 2 classes of developers; simply that methods that are part of the public interface should probably not (and sometimes cannot) generally be named based on implementation details that are not relevant to the consumer of that interface. Would it be easier for the maintainer if they did? Perhaps, though if the clarity for maintainer vs user are at odds with each other, I'll make it easier for the user.

So with that, were we just talking past one another? Are there specific things above that you do disagree with? Or any of it where I'm misunderstanding your argument?

No, I don't think we're disagreeing here. The only wrong thing to do is to dogmatically apply rules, whatever those rules may be, however sane. Personally I prefer to convey the important information for the user of the method in the method name: what am I doing. That "what" can be implementation details if it is really that important and if it is appropriate for the user to know.

With that being said: yea, the thread got off the rails at times and I was to blame for it. I apologize.

# ? Jan 7, 2020 20:43

dougdrums: Feb 25, 2005; CLIENT REQUESTED ELECTRONIC FUNDING RECEIPT (FUNDS NOW)

Adhemar posted:

If the language supports polymorphism, please use that for something like this.

, like the rust example above is alright. The past three years of C and Python have rotted my brain. This would be trivial in any functional language I can think of. I'd think doing it with generics in C# or Java would get complex to the point of not being worth it unless you really value the safety and speed, vs setting a delegate from an enum passed to the constructor. But like I said I now suffer from Python brains so ...

# ? Jan 7, 2020 21:28

Linear Zoetrope: Nov 28, 2011; A hero must cook

dougdrums posted:

Ya , like the rust example above is alright. The past three years of C and Python have rotted my brain. This would be trivial in any functional language I can think of. I'd think doing it with generics in C# or Java would get complex to the point of not being worth it unless you really value the safety and speed, vs setting a delegate from an enum passed to the constructor. But like I said I now suffer from Python brains so ...

Oh, Python? That's easy, if numpy and scipy have taught me anything it's that the correct way to handle this is having a function that takes in a half-documented string badly acting as an enum to select the algorithm.

# ? Jan 8, 2020 02:24

xtal: Jan 9, 2011; by Fluffdaddy

QuarkJets posted:

If you're writing code that implements multiple versions of similar algorithms then I agree that you should try to name them in a way that makes sense while also differentiating them in a way that's meaningful. I just don't think it's appropriate to write out a fairly long plain-English sentence as a method name, because that sucks to work with. computeDominanceFrontiersFollowingCooperHarveyKennedy2001 is a bad name in my opinion because it's simply too long.

The length of the name is an implementation detail to the name itself. If length is stopping you from using good names then set up autocomplete. And I say this as an 80-cols purist where long names drastically change the shape of the code.

In Ruby I like to have a public method `do_some_thing` that branches to private methods `do_some_thing_for_butts` and `do_some_thing_for_farts`. These names can get super long, which reflects how precise their duty is.

# ? Jan 8, 2020 02:29

Absurd Alhazred: Mar 27, 2010; by Athanatos

https://twitter.com/Jonathan_Blow/status/1214675595629432832
https://twitter.com/Jonathan_Blow/status/1214683830117748736

Is this as dumb as I think it is?

# ? Jan 8, 2020 06:05

Zopotantor: Feb 24, 2013; ...und ist er drin dann lassen wir ihn niemals wieder raus...

ratbert90 posted:

PUT RELEVANT INFORMATION IN THE GODDAMN loving TICKET ASSHOLES.

DON'T TELL ME THAT YOU DIDN�T <do thing we specifically told you causes problems> BECAUSE I CAN SEE IN THE LOG FILES YOU ATTACHED TO THE TICKET THAT YOU DID <thing> ON <date>, <date> AND <another loving date>.

# ? Jan 8, 2020 06:22

taqueso: Mar 8, 2004

Absurd Alhazred posted:

Is this as dumb as I think it is?

Every time I see a JBlow tweet its because he said something dumb

# ? Jan 8, 2020 06:28

Space Gopher: Jul 31, 2006; BLITHERING IDIOT AND HARDCORE DURIAN APOLOGIST. LET ME TELL YOU WHY THIS SHIT DON'T STINK EVEN THOUGH WE ALL KNOW IT DOES BECAUSE I'M SUPER CULTURED.

Absurd Alhazred posted:

https://twitter.com/Jonathan_Blow/status/1214675595629432832
https://twitter.com/Jonathan_Blow/status/1214683830117748736

Is this as dumb as I think it is?

Yes, it's very dumb.

The problem he's trying to solve is that, when you're working with shared state in a preemptive multitasking environment, you have to be highly defensive about other threads modifying what you're working with. If you aren't defensive, and the scheduler stops you in the middle of the wrong non-atomic operation, then some other thread could come in and mess up what you're working on. Reasoning about how to be defensive is difficult, especially when performance is important. Like, if you come up with a cool algorithm for processing things in parallel that doesn't start with "first lock everybody else out of this section of code until I'm done with my thing", then you can probably get a doctorate or a publication in a decent journal out of it.

Cooperative multitasking on a single-processor system can solve this by explicitly making huge atomic operations that only yield control back to the scheduler at safe points, at the cost of allowing malicious or poorly written programs to take down the entire system. Nobody does this any more, because "just don't have malicious or buggy programs" isn't a workable constraint for a computer system.

But, let's say we bring it back, since losing one core out of many isn't as big a deal as losing the entire system. If you're working on a system with a bunch of cores, guess what? Other threads might still come in and modify things out from under you, even if everything is fully cooperative, because there might be an operation running on another core that modifies your shared state. You still have to be defensive - locking resources for your exclusive use (creating contention problems) or coming up with exotic solutions that can't be wrong even if they're interrupted. You gain nothing, and allow for the possibility of those same bad programs to eat up a full core. So, yeah, it's pretty dumb.

# ? Jan 8, 2020 06:32

CLAM DOWN: Feb 13, 2007

Yo, everyone please be respectful and stop being obnoxious nerds. That's my job. Thank you and have a nice day.

# ? Jan 8, 2020 07:14

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Space Gopher posted:

Yes, it's very dumb.

The problem he's trying to solve is that, when you're working with shared state in a preemptive multitasking environment, you have to be highly defensive about other threads modifying what you're working with. If you aren't defensive, and the scheduler stops you in the middle of the wrong non-atomic operation, then some other thread could come in and mess up what you're working on. Reasoning about how to be defensive is difficult, especially when performance is important. Like, if you come up with a cool algorithm for processing things in parallel that doesn't start with "first lock everybody else out of this section of code until I'm done with my thing", then you can probably get a doctorate or a publication in a decent journal out of it.

Cooperative multitasking on a single-processor system can solve this by explicitly making huge atomic operations that only yield control back to the scheduler at safe points, at the cost of allowing malicious or poorly written programs to take down the entire system. Nobody does this any more, because "just don't have malicious or buggy programs" isn't a workable constraint for a computer system.

But, let's say we bring it back, since losing one core out of many isn't as big a deal as losing the entire system. If you're working on a system with a bunch of cores, guess what? Other threads might still come in and modify things out from under you, even if everything is fully cooperative, because there might be an operation running on another core that modifies your shared state. You still have to be defensive - locking resources for your exclusive use (creating contention problems) or coming up with exotic solutions that can't be wrong even if they're interrupted. You gain nothing, and allow for the possibility of those same bad programs to eat up a full core. So, yeah, it's pretty dumb.

For a practical example of this, dual cpu macs running OS 9.1 were still unstable as gently caress - we had cooperative multitasking with multiple cpus with that os, and it sucked poo poo.

# ? Jan 8, 2020 07:17

Adbot: ADBOT LOVES YOU

# ? Jun 6, 2024 17:56

Kilson: Jan 16, 2003; I EAT LITTLE CHILDREN FOR BREAKFAST !!11!!1!!!!111!

Space Gopher posted:

Yes, it's very dumb.

You gain nothing, and allow for the possibility of those same bad programs to eat up a full core. So, yeah, it's pretty dumb.

Can't a malicious program just take all the cores anyway?

# ? Jan 8, 2020 10:34

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 »