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 »

Doctor w-rw-rw-: Jun 24, 2008

sarehu posted:

E: lol, nice stealth helldump.

What does this mean?

sarehu posted:

It's not like technically interesting projects and friendly coworkers are mutually exclusive, anyway. As far as I can tell the correlation is in the other direction.

Ehhhhhh, not necessarily. I think that technically interesting stuff tends to draw extremes. The Paper team had a couple of the best and worst people I've ever known.

# ? Mar 22, 2015 04:46

Adbot: ADBOT LOVES YOU

# ? May 31, 2024 09:10

SupSuper: Apr 8, 2009; At the Heart of the city is an Alien horror, so vile and so powerful that not even death can claim it.

I'll take a boring rear end tech job with great environment and coworkers over something actually interesting wrapped in a lovely stuck-up place. I'd rather stifle my tech skills than my sanity. :smith:

# ? Mar 22, 2015 13:04

Soricidus: Oct 21, 2010; freedom-hating statist shill

There doubtless are jobs that have all three of interesting work, good pay, and a sane culture, but I sure haven't ever found one.

# ? Mar 22, 2015 13:11

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Doctor w-rw-rw- posted:

What does this mean?

The tweet you quoted was made by someone who posts here.

# ? Mar 22, 2015 14:47

tef: May 30, 2004; -> some l-system crap ->

Doctor w-rw-rw- posted:

I want to run away from people who think this way. Am I the horror?

So long as there's sufficient professionalism, a bad engineer / a bad problem to solve is way, way, way harder to deal with than an unfriendly or unpleasant coworker.

lol keep running chump

# ? Mar 22, 2015 18:56

tef: May 30, 2004; -> some l-system crap ->

Doctor w-rw-rw- posted:

So long as there's sufficient professionalism

A short play in two parts.

tef: Go and work with good people and don't worry about the tech

goon: BUT IF YOU *WORK* WITH GOOD PEOPLE THEN

FIN

# ? Mar 22, 2015 18:59

Doctor w-rw-rw-: Jun 24, 2008

Didn't realize it was you when posting.

It's been my experience that companies that reward manners or personal relationships over results are really stressful because they frown on / make it difficult to call people out for consistently poor performance and hold them responsible.

I would honestly rather work a job where I can focus on doing what I like - programming - rather than spending many hours per week context-switching to a bigger picture and figuring out which of my dependencies will fail and how I should plan to work around that to get my stuff done. I'm not paid to do that.

Basically, the tech doesn't sort itself out, It just stresses someone else out. That, or the company itself is betting itself on the hope that however bad shape it's in, it can survive. All other things being equal, would I take someone whose work is good over someone who I'd want to be friends with? Yes, unless they've got both qualities. It's a job, I would rather trust my coworkers results than forgiving them as friends for failing to produce them.

# ? Mar 22, 2015 19:17

Soricidus: Oct 21, 2010; freedom-hating statist shill

Doctor w-rw-rw- posted:

Didn't realize it was you when posting.

It's been my experience that companies that reward manners or personal relationships over results are really stressful because they frown on / make it difficult to call people out for consistently poor performance and hold them responsible.

I would honestly rather work a job where I can focus on doing what I like - programming - rather than spending many hours per week context-switching to a bigger picture and figuring out which of my dependencies will fail and how I should plan to work around that to get my stuff done. I'm not paid to do that.

Basically, the tech doesn't sort itself out, It just stresses someone else out. That, or the company itself is betting itself on the hope that however bad shape it's in, it can survive. All other things being equal, would I take someone whose work is good over someone who I'd want to be friends with? Yes, unless they've got both qualities. It's a job, I would rather trust my coworkers results than forgiving them as friends for failing to produce them.

i'm the opinions

# ? Mar 22, 2015 19:21

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

don't write tech to solve social or business issues. it won't work.

pick the best solution, whether it's super technical or just talking to people.

google is does this a lot where they invent a bunch of tech that doesn't solve any problems or could have been solved by talking to a single guy.

# ? Mar 22, 2015 19:41

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

Suspicious Dish posted:

don't write tech to solve social or business issues. it won't work.

One out of three marriages start from online dating and they're happier marriages.

# ? Mar 22, 2015 21:07

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Doctor w-rw-rw- posted:

Basically, the tech doesn't sort itself out, It just stresses someone else out. That, or the company itself is betting itself on the hope that however bad shape it's in, it can survive. All other things being equal, would I take someone whose work is good over someone who I'd want to be friends with? Yes, unless they've got both qualities. It's a job, I would rather trust my coworkers results than forgiving them as friends for failing to produce them.

I dunno about this assertion. Good people I see as the kind of people who will acknowledge a need for consistency, and will do work with empathy for their coworkers. That empathy makes it possible to shelve contrary opinions when it doesn't matter to the end goal.

Good people doesn't mean a conflict free environment, it means conflicts are settled like self-aware, empathetic adults. Just having people willing to fight for ideas has never been a guarantee for good ideas to come to the top.

# ? Mar 22, 2015 21:22

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

Having good manners doesn't preclude raising concerns about people's behavior or performance; if anything it raises the odds of those conversations being effective. It does require that someone put as much thought into how to do that constructively as they would into naming class members or doing a large code review. Good interpersonal behavior isn't genetic, which is why we send kids to kindergarten. It's something that can be improved through development of technique, practice, and feedback, just like programming.

# ? Mar 22, 2015 21:42

karms: Jan 22, 2006; by Nyc_Tattoo; Yam Slacker

sarehu posted:

One out of three marriages start from online dating and they're happier marriages.

I did not know you married so many times you had collected statistically significant data on this.

# ? Mar 22, 2015 22:05

Evil_Greven: Feb 20, 2007; Whadda I got to,
whadda I got to do
to wake ya up?

To shake ya up,
to break the structure up!?

Looking at implementations and apparent understanding of it recently and reflecting on past thoughts, I've been thinking that maybe OOP is a horror in and of itself. I apologize, but this is going to be a little lengthy, so skip it if you don't have a few minutes to read on.

Back in school a few years ago, we had to do research papers for each class (in part to justify keeping the journal access to the university) and one I came across this article: Implications of Perspective in Teaching Objects First and Object Design. It is more aligned with teaching, but some of the ideas from this 5-page article have stuck with me ever since.

It starts with a pretty simple premise - the critique of students by instructors that their design is not object-oriented. However, it then examines the dreaded question: what is object-oriented design? So, the author went and looked into a bunch of objects-first books, and came up with a few different answers. Or rather... perspectives - three to be exact: language centric, model centric, and responsibility centric.

Each of these perspectives have fairly well-defined boundaries (I'll shorten it to L, M, and R respectively):
L - classes and objects are self-contained static building blocks/entities for software, with an emphasis on fields and methods.
M - objects are parts of a larger software context - simulated systems, which leads to a static relationship focus (association/generalization/composition/etc).
R - objects fulfill a role/have a responsibility within the software; this is not like L, where things are fairly concrete, but instead more abstract - the author likens it to an obligation to carry out a request.

The general design I was taught in CS - and what the author mentions - is pretty straightforward: identify objects and their relationships(Vehicle has a model attribute/Car inherits from Vehicle), then define their behavior (one can repaint() a Vehicle). This pretty much follows L - a static, structured distribution of behaviors amongst various objects. The M view is in some respects similar, but it aims to simulate a system in the real world; this is a bit more abstract than L, as the objects in it might not physically exist or they might be of different scale (for example, the engine in a car). For both perspectives, you determine who is a part of the system, then what it does.

But... what is a system supposed to do? That is the behavior - and it's already there. We wouldn't start building a system unless we had a general idea of what it's supposed to do! Where does this fit in with the above way of object-oriented programming? R is markedly different: identify responsibilities, group these responsibilities into roles, define patterns for the collaboration of these roles, then determine the objects that fulfill these roles. In essence, it is the reverse of the other perspectives: figure out what you need done, then determine who does it.

If you think about it, that's kind of how the real world works. People don't get a job and then responsibilities - a role is needed with responsibilities, then someone can get a job in that role. Those roles might have changing responsibilities, or the person might change roles entirely. A military shouldn't design a vehicle and then figure out what it's supposed to do, otherwise they end up with the Bradley - or the F-35.

Worse, the usual object-oriented design has issues with some things - take the author's example case study: Backgammon. A simple board game seems ideal for the M perspective, right? You may perhaps formulate (like the author) a design consisting of Backgammon, Player, Die, Board, Point, Bar, and Checker objects - along with a whole lot of issues, if you want to validate moves. Two die are rolled, and only one may be used per checker. However, to even move a checker on the board, you must have your bar clear of any checkers - those must be put into play first. Further, if one player has two checkers on a point, the other player cannot move a checker to that point. Now, to validate a move... you'll have to access state data from every one of those objects.

As you can see, there are some severe problems from this perspective on design. What about the R approach? First, you identify what something needs to do: handle the board, handle turns, validate moves, and roll dice. This is a bit radical: each object has a distinct responsibility that it needs to fulfill - it conflicts with keeping the data and behavior confined together. There are still similarities from the M approach - there should still be an overall manager object Backgammon and a Board object, along with its components Point and Checker. However, there are also many changes.

For example, as MoveValidator is now its own object, Board surrenders any responsibility it had in doing move validation. You might argue that - as the Board is what tracks positions, it should do the validation - consider the possibility of variations in the rules, that is to say, backgammon variants. The board does not change, but the rules do. Suddenly, it makes a whole lot more sense to design objects in this manner. Patterns become readily visible as well - structuring the objects in this manner lets you use the strategy pattern on much of it.

Using R, Board would still be responsible for telling locations to whichever concrete MoveValidator is being used, but it no longer handles a dozen different rule sets internally. Hell, you could even do partial validation (for general, but not always, rules like blocking) as long as it's decoupled from the move itself - different concrete MoveValidator objects could simply not call those methods from Board.

Still, the author makes the point - and I agree - that this isn't some new paradigm: this perspective approach is just another facet of OOP. This responsibility approach is likely worse in a variety of instances than the other approaches; all have their limitations. His contention in the discussion is that the model perspective may be more useful for applications, while the responsibility perspective could be better for frameworks.

tl;dr - OOP: the responsibility perspective (1) determine responsibilities for a system (2) create objects to fulfill those obligations.

# ? Mar 22, 2015 22:16

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

KARMA! posted:

I did not know you married so many times you had collected statistically significant data on this.

I didn't. Other people did.

# ? Mar 22, 2015 22:16

Karate Bastard: Jul 31, 2007; Soiled Meat

Evil_Greven posted:

tl;dr - OOP: the responsibility perspective (1) determine responsibilities for a system (2) create objects to fulfill those obligations.

On the other hand object oriented programming is an expensive disaster which must end. _{Did I get that link from here btw?}

# ? Mar 22, 2015 22:43

ulmont: Sep 15, 2010; IF I EVER MISS VOTING IN AN ELECTION (EVEN AMERICAN IDOL) ,OR HAVE UNPAID PARKING TICKETS, PLEASE TAKE AWAY MY FRANCHISE

Karate Bastard posted:

On the other hand object oriented programming is an expensive disaster which must end. _{Did I get that link from here btw?}

Probably - I've seen that link in this thread before.

# ? Mar 22, 2015 23:39

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Speaking of OO, I had a (Javascript) function that shows a bunch of map markers, it was basically

JavaScript code:

this.get('markers1').then(function (marker) {
	marker.set('visible', true);
});
this.get('markers2').then(function (marker) {
	marker.set('visible', true);
});

I made similar callbacks in several places, so I just made a "show" function in our "utils" module, imported it and changed the above code to

JavaScript code:

import {show} from '../utils/util';

this.get('markers1').then(show);
this.get('markers2').then(show);

Our junior developer then moved the code to the marker module (good, I should have done that, actually), but instead he made the show function a member of the mixin:

JavaScript code:

export default Ember.Mixin.create({
	show: function() {
		this.set('visible', true);
	}
});

And replaced my code with

JavaScript code:

this.get('markers1').then(function (marker) {
	marker.show();
});
this.get('markers2').then(function (marker) {
	marker.show();
});

Because "it's more OO"

# ? Mar 22, 2015 23:59

The Laplace Demon: Jul 23, 2009; "Oh dear! Oh dear! Heisenberg is a douche!"

Karate Bastard posted:

On the other hand object oriented programming is an expensive disaster which must end. _{Did I get that link from here btw?}

While we're at it, the two object-first perspectives (language especially, and model too) remind me of Execution in the Kingdom of Nouns. The responsibility perspective just sounds like sensible program design, nothing about that is object-oriented. It's the problem boiled down to a few basic data structures and some functions to manipulate them.

e: Actually, the responsibility perspective sounds like it too. MoveValidator indeed.

The Laplace Demon fucked around with this message at 00:42 on Mar 23, 2015

# ? Mar 23, 2015 00:27

seiken: Feb 7, 2005; hah ha ha

Karate Bastard posted:

On the other hand object oriented programming is an expensive disaster which must end. _{Did I get that link from here btw?}

Yeah, I posted it here a while ago and mostly people made fun of select paragraphs whole ignoring the main thrust of the rant. Fair enough though, it's pretty long.

(Actually I don't think OOP is completely without merit but I do agree with a lot of the ranting in the article)

# ? Mar 23, 2015 01:16

Deus Rex: Mar 5, 2005

Suspicious Dish posted:

don't write tech to solve social or business issues. it won't work.

What? Every programmer employed by a company to write code is being paid to "solve a business issue".

# ? Mar 23, 2015 02:48

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

perhaps "issues that would be better solved by raw business or social solutions" is a better phrase

# ? Mar 23, 2015 04:29

Doctor w-rw-rw-: Jun 24, 2008

Subjunctive posted:

Having good manners doesn't preclude raising concerns about people's behavior or performance; if anything it raises the odds of those conversations being effective.

Never said that it did. But letting reluctance to be harsh get in the way of honest feedback when someone's performing poorly makes everyone's job harder.

# ? Mar 23, 2015 06:09

1337JiveTurkey: Feb 17, 2005

Evil_Greven posted:

tl;dr - OOP: the responsibility perspective (1) determine responsibilities for a system (2) create objects to fulfill those obligations.

I've always viewed the language perspective a bit differently. A good object oriented design from a language perspective tracks how we'd describe the behavior of the program. Unless I'd describe how a game of backgammon works in terms of different PositionManagers each with their own PositionStrategy, I wouldn't use those in a design. I'd say a Board has several Points, each of which has potentially several Checkers.

If some class seems impossible to give a good name (using design patterns in the name is a pretty solid indicator) then it's because it's unclear what the class is. Method names like run(), doIt() and the like are signs that it's not clear what they're supposed to do. A class or method with a good name can still have design problems, but one with a bad name is always going to suck because it reflects muddled thinking about the design.

The problem with the language and model perspectives is they don't give any idea of how to make a good design, just how to tell if a design is bad. CRC (Class-Responsibility-Collaborators) cards are a responsibility-based design method that uses the spec to create a design.

It starts by going through the nouns in the spec/use case/story for candidate classes. Not every noun will end up being a class, but they offer a good first approximation of what should be a class. So if the backgammon spec doesn't mention variant rules, there's no need for such a class. If it does, VariantRules works better than MoveValidator because it directly relates to the spec. Whenever you need a new class, write the name on top of an index card with a vertical line down the middle.

The responsibilities are parts of the spec that say how the program is to behave. For each responsibility, pick a noun that fits the responsibility and write it on the left hand side of the card. Next ask what additionally needs to happen to meet the responsibility. If something already handles that responsibility, write that class name on the right hand side as a collaborator. If nothing does, add the responsibility to a new or existing class and list that as a collaborator. If it makes sense for the class to handle that responsibility, then write it as a second responsibility.

If the responsibilities or collaborators on a card no longer fit, then try to describe the responsibilities at a higher level. If that doesn't work, then split the class into two or more classes. VariantRules may need ValidMoves, InitialState, EndState, ScoringRules and so on but if they all comfortably fit on a single index card, the class shouldn't be too complicated. If a card's almost empty, some responsibilities can be shifted to it or its responsibilities can be moved to a different class and the class eliminated.

The process is complete when every responsibility has been farmed out to a card. No cards should have duplicate responsibilities and all of the responsibilities should be necessary for the program to meet the spec.

The Laplace Demon posted:

While we're at it, the two object-first perspectives (language especially, and model too) remind me of Execution in the Kingdom of Nouns. The responsibility perspective just sounds like sensible program design, nothing about that is object-oriented. It's the problem boiled down to a few basic data structures and some functions to manipulate them.

e: Actually, the responsibility perspective sounds like it too. MoveValidator indeed.

That blog post takes an extremely rigid view of how verbs can map to objects. Getting the garbage bag from under the sink is something that can be defined in terms of the garbage bag or in terms of the sink. Sink.retrieveGarbage() might make sense if Sink is mutable and tracks what's under it or if there's no global pointers to the Garbage objects. Meanwhile Garbage.retrieve(Location) would work if Garbage tracks where it is while Sink is immutable and there are global pointers to the Garbage objects.

# ? Mar 23, 2015 07:37

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

seiken posted:

Yeah, I posted it here a while ago and mostly people made fun of select paragraphs whole ignoring the main thrust of the rant. Fair enough though, it's pretty long.

(Actually I don't think OOP is completely without merit but I do agree with a lot of the ranting in the article)

I really should have been reading tvtropes instead of this right now because I can't fall asleep. I only am just a fraction into it, but I would like to explore the idea of functional languages handling OOP principles better than imperative languages. Is there a good resource for this that demonstrates this in detail without assuming the reader is already versed in functional programming?

My problem with functional programming is that I only did some Scheme over a decade ago in school, and it was very synthetic stuff. So I am liable to dismiss it out of ignorance, just as a procedural programmer may dismiss OOP as "just some animal-cat-dog-meow() bullshit."

# ? Mar 23, 2015 09:33

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

I'm not sure I'd say that functional languages handle OOP better, because it's really hard to do "true" OOP in those languages. In that if you got a book on OOP design patterns, you'd probably be scratching your head on how to implement some of them. I think the main argument is more that algebraic, dependent, and associated types tend to solve the sorts of issues OOP tries to solve better. Those concepts are not necessarily limited to functional languages, but are the most common in them.

# ? Mar 23, 2015 09:38

raminasi: Jan 25, 2005; a last drink with no ice

While that anti-OOP rant is fun, it should be noted that it's really not difficult to write an equivalent version for functional programming, complete with a litany of complaints about "No True Scotsman" defenses.

All programming is terrible.

# ? Mar 23, 2015 14:40

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

1337JiveTurkey posted:

I've always viewed the language perspective a bit differently. A good object oriented design from a language perspective tracks how we'd describe the behavior of the program. Unless I'd describe how a game of backgammon works in terms of different PositionManagers each with their own PositionStrategy, I wouldn't use those in a design. I'd say a Board has several Points, each of which has potentially several Checkers.

If some class seems impossible to give a good name (using design patterns in the name is a pretty solid indicator) then it's because it's unclear what the class is. Method names like run(), doIt() and the like are signs that it's not clear what they're supposed to do. A class or method with a good name can still have design problems, but one with a bad name is always going to suck because it reflects muddled thinking about the design.

The problem with the language and model perspectives is they don't give any idea of how to make a good design, just how to tell if a design is bad. CRC (Class-Responsibility-Collaborators) cards are a responsibility-based design method that uses the spec to create a design.

It starts by going through the nouns in the spec/use case/story for candidate classes. Not every noun will end up being a class, but they offer a good first approximation of what should be a class. So if the backgammon spec doesn't mention variant rules, there's no need for such a class. If it does, VariantRules works better than MoveValidator because it directly relates to the spec. Whenever you need a new class, write the name on top of an index card with a vertical line down the middle.

The responsibilities are parts of the spec that say how the program is to behave. For each responsibility, pick a noun that fits the responsibility and write it on the left hand side of the card. Next ask what additionally needs to happen to meet the responsibility. If something already handles that responsibility, write that class name on the right hand side as a collaborator. If nothing does, add the responsibility to a new or existing class and list that as a collaborator. If it makes sense for the class to handle that responsibility, then write it as a second responsibility.

If the responsibilities or collaborators on a card no longer fit, then try to describe the responsibilities at a higher level. If that doesn't work, then split the class into two or more classes. VariantRules may need ValidMoves, InitialState, EndState, ScoringRules and so on but if they all comfortably fit on a single index card, the class shouldn't be too complicated. If a card's almost empty, some responsibilities can be shifted to it or its responsibilities can be moved to a different class and the class eliminated.

The process is complete when every responsibility has been farmed out to a card. No cards should have duplicate responsibilities and all of the responsibilities should be necessary for the program to meet the spec.

That blog post takes an extremely rigid view of how verbs can map to objects. Getting the garbage bag from under the sink is something that can be defined in terms of the garbage bag or in terms of the sink. Sink.retrieveGarbage() might make sense if Sink is mutable and tracks what's under it or if there's no global pointers to the Garbage objects. Meanwhile Garbage.retrieve(Location) would work if Garbage tracks where it is while Sink is immutable and there are global pointers to the Garbage objects.

Is this a parody of that 'how to read poetry' scene in dead poets society?

# ? Mar 23, 2015 14:50

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

GrumpyDoctor posted:

While that anti-OOP rant is fun, it should be noted that it's really not difficult to write an equivalent version for functional programming, complete with a litany of complaints about "No True Scotsman" defenses.

But you see, Lisp is the One True Language and sprang forth from John McCarthy's head fully-formed, innovating and popularizing all modern programming concepts including but not limited to functional programming. As you can read in my numerous blog posts and their associated Hacker News threads on the subject, object oriented programming is diametrically opposed to functional programming and inferior in all contexts and realizations. Furthermore,

# ? Mar 23, 2015 15:21

itskage: Aug 26, 2003

fleshweasel posted:

No, if your software experiences some problem from missing the library it needs that requires poring over the source to diagnose, you need to require that library. It's a waste of everyone's time to have it just limp along without it.

Yeah I was just being facetious due to what was being discussed about working with nice people.

# ? Mar 23, 2015 17:42

brap: Aug 23, 2004; Grimey Drawer

Oh poo poo sorry about that then.

# ? Mar 23, 2015 17:49

seiken: Feb 7, 2005; hah ha ha

GrumpyDoctor posted:

While that anti-OOP rant is fun, it should be noted that it's really not difficult to write an equivalent version for functional programming, complete with a litany of complaints about "No True Scotsman" defenses.

All programming is terrible.

Yes. Specifically, I don't agree at all with the argument "OOP is terrible, therefore Lisp is the best language", but I think many of the complaints about OOP are certainly valid in themselves.

Especially the stuff about how if you get to the point where you need all this dependency injection framework crap to initialize your objects, you're doing something very wrong.

It certainly isn't perfect by any means, but I think something like the C++ standard library is an interesting example of something that uses objects when useful, particularly for stuff like RAII, but isn't really OOP in any dogmatic sense (lots of non-member functions, some functional-inspired stuff, and so on).

# ? Mar 23, 2015 18:22

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

GrumpyDoctor posted:

While that anti-OOP rant is fun, it should be noted that it's really not difficult to write an equivalent version for functional programming, complete with a litany of complaints about "No True Scotsman" defenses.

All programming is terrible.

I find this "everything is terrible" attitude that's so common among programmers really irritating. Its basically just a thought terminating cliche at this point. There are actually significant differences between OOP and FP that are worth talking about, and you can't just handwave that whole essay away with "eh, I could write a similar one about FP".

# ? Mar 23, 2015 18:52

Karate Bastard: Jul 31, 2007; Soiled Meat

I've definitely overbought the oop propaganda in the past, to the point where I sometimes got stuck in the design phase because I couldn't figure out the best way to translate the problem into objects and class structures, while all the time knowing full well it translates just fine into a few small functions and a few simple separate data structures, and still not allowing myself to go that route because it ain't 1337 oop enough.

# ? Mar 23, 2015 18:59

Dr. Poz: Sep 8, 2003; Dr. Poz just diagnosed you with a serious case of being a pussy. Now get back out there and hit them till you can't remember your kid's name.; Pillbug

Not really code, but if you've ever hit up the Git Man pages for help, you should get a laugh (or cry) out of this: http://git-man-page-generator.lokaltog.net/

Sorry if this is a repost.

# ? Mar 23, 2015 19:02

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

HappyHippo posted:

I find this "everything is terrible" attitude that's so common among programmers really irritating. Its basically just a thought terminating cliche at this point. There are actually significant differences between OOP and FP that are worth talking about, and you can't just handwave that whole essay away with "eh, I could write a similar one about FP".

Everything is terrible, but it's all terrible in different ways and those differences are important to understand.

I often find a lot of these arguments about some paradigm being bad being of the form:

"Hammers are bad because you can dig a ditch with them instead of using a shovel."

Rather than the more reasonable and helpful argument:

"Hammers are bad at digging ditches, use a shovel to dig a ditch, use a hammer to drive a nail."

# ? Mar 23, 2015 19:15

Karate Bastard: Jul 31, 2007; Soiled Meat

Dr. Poz posted:

Not really code, but if you've ever hit up the Git Man pages for help, you should get a laugh (or cry) out of this: http://git-man-page-generator.lokaltog.net/

Sorry if this is a repost.

Coder horror: my colleague didn't find that funny in the least, and couldn't even spot that that's a parody, and said it's indistinguishable from the real deal, and that git is impossible to understand anyway, and added as evidence that git once destroyed all their code when they were trying to get remotes to work.

How do you manage to destroy all your code using something that literally only exists to save diffs of your work?

# ? Mar 23, 2015 19:19

ToxicFrog: Apr 26, 2008

Karate Bastard posted:

Coder horror: my colleague didn't find that funny in the least, and couldn't even spot that that's a parody, and said it's indistinguishable from the real deal, and that git is impossible to understand anyway, and added as evidence that git once destroyed all their code when they were trying to get remotes to work.

How do you manage to destroy all your code using something that literally only exists to save diffs of your work?

The "while trying to get remotes to work" leads me to suspect something involving a conflicted merge/rebase where they badly hosed up conflict resolution and don't realize that you can just rewind to the point before the merge/rebase and try again.

# ? Mar 23, 2015 19:40

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Dr. Poz posted:

Not really code, but if you've ever hit up the Git Man pages for help, you should get a laugh (or cry) out of this: http://git-man-page-generator.lokaltog.net/

Sorry if this is a repost.

I feel stupid for asking, but what does the command purport to do? It sounds like it garbles up a bunch of current work and then pees on the repository with a pollution of tags or something.

# ? Mar 23, 2015 20:00

Adbot: ADBOT LOVES YOU

# ? May 31, 2024 09:10

astr0man: Feb 21, 2007; hollyeo deuroga

Rocko Bonaparte posted:

I feel stupid for asking, but what does the command purport to do? It sounds like it garbles up a bunch of current work and then pees on the repository with a pollution of tags or something.

that site is a parody and none of the commands are real (essentially it's just a markov generator using the text from actual git man pages)

# ? Mar 23, 2015 20:04

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 »