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 »

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Mustach posted:

That and "embedded programming" is just every coder's attempt at "manly" and irrefutable evidence for hating things. "GARBAGE COLLECTION? IF YOU WERE ON A 15-BITS OF RAM TINKERBELL NIGHT-LIGHT LIKE ME YOU'D KNOW THAT'S ALL BULLSHIT"

I've heard this complaint a bunch of times but never seen it. Are you sure you aren't projecting here?

# ? Sep 13, 2012 14:28

Adbot: ADBOT LOVES YOU

# ? Jun 4, 2024 07:46

Mustach: Mar 2, 2003; In this long line, there's been some real strange genes. You've got 'em all, with some extras thrown in.

Yes, aside from the hyperbole, I've seen it. This blessed oasis that is CoC is mercifully free of that kind of thing. (at least since teapot got permabanned)

# ? Sep 13, 2012 15:13

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

teapot and Unabomber were the two best posters in CoC (well SHSC I guess since CoC wasn't a thing for most of their tenure).

Honorable mention to AvengingDentist of course

# ? Sep 13, 2012 15:52

Zhentar: Sep 28, 2003; Brilliant Master Genius

shrughes posted:

(The hand-rolled code can be less susceptible to bugs if it's just a better written implementation, which you're not likely to see for Boost libs but you are likely to see for, well, a lot of libraries out there.)

It's not just the susceptibility to the bugs, too - there's also the matter of support. Being dependent on a third party with unresponsive support to identify and fix issues can really suck.

# ? Sep 13, 2012 15:55

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

Zhentar posted:

Being dependent on a third party with unresponsive support to identify and fix issues can really suck.

So can being dependent on 10 year old code written by people who have since left the company.

# ? Sep 13, 2012 16:12

Contero: Mar 28, 2004

That Turkey Story posted:

I find this to be the case with most languages. It seems like for every language that introduces something useful, they get rid of something else that is useful because it's "complicated" (who cares if it's useful and correct -- it's scary!).

I'm curious what your list of retained features would be to make a successful successor to C++.

My biggest issue is that the first thought when replacing C++ always seems to be "So this language is going to be like C++, except with garbage collection! Then we can get rid of those nasty, confusing destructors."

# ? Sep 13, 2012 19:15

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

Contero posted:

I'm curious what your list of retained features would be to make a successful successor to C++.

My biggest issue is that the first thought when replacing C++ always seems to be "So this language is going to be like C++, except with garbage collection! Then we can get rid of those nasty, confusing destructors."

Garbage collection isn't nice because destructors are hard, garbage collection is nice because keeping track of object lifetimes is cognitive overhead and if you can get rid of it then why the hell not?

# ? Sep 13, 2012 19:42

tractor fanatic: Sep 9, 2005; Pillbug

They really need to have designed templates for metaprogramming instead of discovering accidentally years down the line that the system you put in for creating generic containers happens to be turing-complete.

# ? Sep 13, 2012 19:58

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

tractor fanatic posted:

They really need to have designed templates for metaprogramming instead of discovering accidentally years down the line that the system you put in for creating generic containers happens to be turing-complete.

And so D has compile-time code :v:

# ? Sep 13, 2012 20:09

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

GrumpyDoctor posted:

Garbage collection isn't nice because destructors are hard, garbage collection is nice because keeping track of object lifetimes is cognitive overhead and if you can get rid of it then why the hell not?

I think the more substantive point here is that any successor to C++ would have to have GC that is optional at most. In 2012 any system that can meet its performance requirements with a GC is already implemented in a language with a GC, so there is no point to making a C++ replacement that forces one on you.

An optional GC would make a putative C++ successor attractive by making it easier to develop systems that don't have as stringent specific performance requirements (and I should state pre-emptively that 'speed' as in average framerate or whatever isn't the requirement that kills a GC for most things that can't stand a GC) without sacrificing suitability in the niche where C++ excels.

It should also be noted that the combination of pervasive value semantics and numerous deterministic semi-automatic memory management schemes can make memory management in C++ a non-issue (or at least rather tractable) in most cases, and that designing around the pathological cases of a GC that may well change in the next version of your language's VM is often a non-trivial consideration when you measure performance in something other than hundreds of requests per second.

# ? Sep 13, 2012 20:24

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

I generally agree with you, but I'd like to make the point that

Otto Skorzeny posted:

the combination of pervasive value semantics and numerous deterministic semi-automatic memory management schemes

isn't exactly how I'd describe a "non-issue."

# ? Sep 13, 2012 20:57

That Turkey Story: Mar 30, 2003

Contero posted:

I'm curious what your list of retained features would be to make a successful successor to C++.

Any list I try to quickly make here is bound to be incomplete, but of the things that many other modern, mainstream, statically-typed languages don't have, such a language would need something analogous to templates that allows for generic programming with the efficiency and genericity that templates provide. Note that "generics" are not it. Value semantics (in other words copy constructors, assignment operators, and preferably move operations, etc.). Destructors that are automatically called when a type leaves scope. Function overloading (and preferably operator overloading, though not strictly necessary). Some way to do compile-time metaprogramming. Something akin to either concept maps or ADL, but preferably just concept maps and ditching ADL. Both signed and unsigned integers for god's sake. I'm probably missing obvious stuff but these are ones that jump to mind as being really important and that some modern languages don't have.

Contero posted:

My biggest issue is that the first thought when replacing C++ always seems to be "So this language is going to be like C++, except with garbage collection! Then we can get rid of those nasty, confusing destructors."

Yes! I hate this and I see it all the time. That so many programmers don't understand the flaw in this is especially upsetting.

GrumpyDoctor posted:

Garbage collection isn't nice because destructors are hard, garbage collection is nice because keeping track of object lifetimes is cognitive overhead and if you can get rid of it then why the hell not?

There's nothing wrong with garbage collection, but its uses are far more limited than many programmers understand and it is frequently misused. The biggest issue comes from the fact that it's not a replacement for destructors, and since memory allocation and deallocation often involve types that need to manage some kind of resources other than memory, you still need to be explicit about disposal of resources when in the presence of garbage collection, otherwise you get non-deterministic disposal or no disposal at all (it's why languages have things like C#'s using statement, which is unfortunately not anywhere close to a replacement for destructors).

Realistically, garbage collection is fine in cases where 1) non-deterministic memory management is acceptable, 2) you actually want shared ownership of a given object (garbage collection is pointless for clearly scoped objects), and 3) where disposal of the type is trivial and predictably will be trivial in the future (i.e. in C++ terms, any C++ type with a trivial destructor or that only directly or indirectly dynamically allocates types that have trivial destructors).

In terms of #1, most people are okay with it, and that's fine. I'm including this for completeness and because it isn't always acceptable. If you really are trying to make a general-purpose language, this is definitely important to understand. Optional garbage collection is one thing, but if you force it for all dynamically allocated objects then you're ruling out a whole class of users for no reason.

In terms of #2, you should already be striving for minimizing or eliminating shared ownership to begin with -- you use value semantics in C++. Take a look at all of the C++ standard libraries and all of the boost libraries, for example. Specifically, which of their components would be significantly, if at all, impacted by the presence of garbage collection and how would it make their implementation better, easier to understand, or even easier to write for that matter? Since they use value semantics, pretty much none of them (you could probably stretch and say something like shared_ptr could be metaprogrammed to have a different implementation in cases where types have trivial destructors).

Further, as for #3, even if you're not dealing with value semantics, if your types are nontrivially dispoable or if your code (especially generic code) is to contain anything that is potentially not trivially disposable, then you want or need deterministic disposal anyway, which garbage collection itself cannot provide. Because of this, you need some other way to keep track of when disposal can take place that is actually deterministic and timely -- if you have to keep track of when to dispose anyway, then the benefits of garbage collection in that scenario go out the window (if you know when to dispose of the object, you know when its memory is ready to be reclaimed).

Garbage collection is fine for dynamic memory allocation of trivial types, but it falls flat on its face with respect to deterministic resource management. In something like C++ with garbage collection, there's nothing detrimental about the facility being there and it's very welcome, but good practice will still always be to use value semantics unless you have a solid reason not to, use unique_ptr in places where you have simple lifetimes of dynamic objects, and use shared_ptr in places where you have dynamic objects with shared lifetimes (though again, that's something you should strive to avoid if possible anyway).

That Turkey Story fucked around with this message at 21:28 on Sep 13, 2012

# ? Sep 13, 2012 21:15

Optimus Prime Ribs: Jul 25, 2007

I've been tasked with fixing up our company's website, and this is a small snippet of one CSS file (out of four total):

CSS code:

/*
--------------------------------------------
SELECTED STATE
--------------------------------------------
*/

/* Event Webcasting*/
#eventWebcastingOverview #navEventWebcastingOverview a,
#liveEventWebcasting #navLiveEventWebcasting a,
#archiveEventWebcasting #navArchiveEventWebcasting a,
#selfServeWebcasting #navSelfServeWebcasting a,
#advancedFeatures #navAdvancedFeatures a,
#webcastingProcess #navWebcastingProcess a,
#webcastingSoftware #navWebcastingSoftware a,
#faq #navFaq a,
/* Professional Services */
#professionalServicesOverview #navProfessionalServicesOverview a,
#videoProduction #navVideoProduction a,
#eventManagement #navEventManagement a,
#speakerTraining #navSpeakerTraining a,
#customDevelopment #navCustomDevelopment a,
/* Hosting & Distribution */
#hostingDistributionOverview #navHostingDistributionOverview a,
#bandwidthCalculator #navBandwidthCalculator a,
#publishing #navPublishing a,
#selfServeWebcasting #navSelfServeWebcasting a,
#workback #navWorkback a,
/* SNVideo */
#snVideo #navSnVideo a,
#equipment #navEquipment a,
#network #navNetwork a,
#support #navSupport a,
#reservations #navReservations a,
#innovativeOfferings #navInnovativeOfferings a,
/* About SN */
#aboutOverview #navAboutOverview a,
#managementTeam #navManagementTeam a,
#awards #navAwards a,
#press #navPress a,
#history #navHistory a,
#contact #navContact a,
/* Resource Center*/
#resourceCenterOverview #navResourceCenterOverview a,
#videso #navVideos a,
#interactiveForms #navInteractiveForms a,
#pdfDownloads #navPdfDownloads a,
#bandwidthCalculator #navBandwidthCalculator a,
#roiCalculator #navRoiCalculator a,
#carbonCalculator #navCarbonCalculator a,
#workbackVideo #navWorkbackVideo a,
#workbackAudio #navWorkbackAudio a,
#eventConsult #navEventConsult a,
#workOrder #navWorkOrder a,
#bestPractices #navBestPractices a
{
	color:#333333;
	background-color:#FFFFFF;
	font-weight: normal;
	border-left-style: solid;
	border-left-color: #0083bc;
	border-left-width: 10px;
	border-right-style: none;
	border-right-width: 0px;
	border-right-color: #FFFFFF;
	padding-left: 10px;
}
/*
--------------------------------------------
secondary STATE
--------------------------------------------
*/


/* Event Webcasting*/
#eventWebcastingOverview #navEventWebcastingOverview a:hover,
#liveEventWebcasting #navLiveEventWebcasting a:hover,
#archiveEventWebcasting #navArchiveEventWebcasting a:hover,
#selfServeWebcasting #navSelfServeWebcasting a:hover,
#advancedFeatures #navAdvancedFeatures a:hover,
#webcastingProcess #navWebcastingProcess a:hover,
#webcastingSoftware #navWebcastingSoftware a:hover,
#faq #navFaq a:hover,
/* Professional Services */
#professionalServicesOverview #navProfessionalServicesOverview a:hover,
#videoProduction #navVideoProduction a:hover,
#eventManagement #navEventManagement a:hover,
#speakerTraining #navSpeakerTraining a:hover,
#customDevelopment #navCustomDevelopment a:hover,
/* Hosting & Distribution */
#hostingDistributionOverview #navHostingDistributionOverview a:hover,
#bandwidthCalculator #navBandwidthCalculator a:hover,
#publishing #navPublishing a:hover,
#selfServeWebcasting #navSelfServeWebcasting a:hover,
#workback #navWorkback a:hover,
/* SNVideo */
#snVideo #navSnVideo a:hover,
#equipment #navEquipment a:hover,
#network #navNetwork a:hover,
#support #navSupport a:hover,
#reservations #navReservations a:hover,
#innovativeOfferings #navInnovativeOfferings a:hover,
/* About SN */
#aboutOverview #navAboutOverview a:hover,
#managementTeam #navManagementTeam a:hover,
#awards #navAwards a:hover,
#press #navPress a:hover,
#history #navHistory a:hover,
#contact #navContact a:hover,
/* Resource Center*/
#resourceCenterOverview #navResourceCenterOverview a:hover,
#videso #navVideos a:hover,
#interactiveForms #navInteractiveForms a:hover,
#pdfDownloads #navPdfDownloads a:hover,
#bandwidthCalculator #navBandwidthCalculator a:hover,
#roiCalculator #navRoiCalculator a:hover,
#carbonCalculator #navCarbonCalculator a:hover,
#workbackVideo #navWorkbackVideo a:hover,
#workbackAudio #navWorkbackAudio a:hover,
#eventConsult #navEventConsult a:hover,
#workOrder #navWorkOrder a:hover,
#bestPractices #navBestPractices a:hover
{
	background-color:#4e4c4d;
	font-weight: bold;
	padding-left: 10px;
	color: #FFFFFF;
}

ugh....

# ? Sep 13, 2012 21:16

ToxicFrog: Apr 26, 2008

Optimus Prime Ribs posted:

I've been tasked with fixing up our company's website, and this is a small snippet of one CSS file (out of four total):

ugh....

Thanks the colourizing, it looks like something has vomited blood all over the thread.

Can't say that's inappropriate, either.

# ? Sep 13, 2012 21:29

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

FWIW my experience has been that I end up spending about the same amount of time thinking about resource management in C# and C++, and both are way simpler than Objective-C with automatic reference counting. The learning curve for C++ memory management is definitely steeper than for garbage collected languages, though that's a problem with the language in general.

# ? Sep 13, 2012 22:51

Zombywuf: Mar 29, 2008

That Turkey Story posted:

Any list I try to quickly make here is bound to be incomplete, but of the things that many other modern, mainstream, statically-typed languages don't have, such a language would need something analogous to templates that allows for generic programming with the efficiency and genericity that templates provide. Note that "generics" are not it.

Have you seen Clay. It's in early stages but it seems to be going in a nice direction.

# ? Sep 13, 2012 23:26

That Turkey Story: Mar 30, 2003

Zombywuf posted:

Have you seen Clay. It's in early stages but it seems to be going in a nice direction.

No, but from the listed features and design philosophy I'm already interested.

Edit: Skimming the language reference, I like how they handle a lot of things, often better than C++: overloading, discriminated unions (though I'm not entirely sure they should be a language feature as opposed to a library feature), and function return type deduction.

Edit2: In IRC someone is claiming that development on the language isn't really active anymore, even though it looks like it was updated relatively recently. :/

Edit3: I really like this language a lot.

That Turkey Story fucked around with this message at 01:55 on Sep 14, 2012

# ? Sep 13, 2012 23:35

shrughes: Oct 11, 2008; (call/cc call/cc)

That Turkey Story posted:

Realistically, garbage collection is fine in cases where 1) non-deterministic memory management is acceptable, 2) you actually want shared ownership of a given object (garbage collection is pointless for clearly scoped objects), and 3) where disposal of the type is trivial and predictably will be trivial in the future (i.e. in C++ terms, any C++ type with a trivial destructor or that only directly or indirectly dynamically allocates types that have trivial destructors).

4) You want memory safety and don't want every piece of broken code to be a security flaw.

# ? Sep 13, 2012 23:43

That Turkey Story: Mar 30, 2003

shrughes posted:

4) You want memory safety and don't want every piece of broken code to be a security flaw.

If by that you mean you don't want somebody to be able to accidentally write to something that's been deleted and/or destroyed, I agree, but unless you're disallowing holding references to non-dynamically-allocated objects, or you are always implicitly dynamically allocating and garbage collecting all objects, you're still going to have that potential problem anyway. That's a gigantic trade-off.

You could sort of have it both ways, though -- keep track of traceable memory references ala GC, and if other pieces of code are still holding onto them at the time delete is called or the object is destroyed, produce some kind of error (probably something like terminate without stack unwinding, allowing some kind of hook). The thing is, even if you avoid trampling over memory, your program is still in some erroneous, unaccounted for state by the programmer. Something still should be done other than silently continuing.

# ? Sep 14, 2012 01:03

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

That Turkey Story posted:

discriminated unions (though I'm not entirely sure they should be a language feature as opposed to a library feature)

It looks like it's how they do their OO:

the FAQ posted:

Unlike mainstream object-oriented languages such as Java, C++ and Python, Clay does not provide class definitions or inheritance. However Clay provides excellent support for polymorphism using an overloaded function dispatch system and variants (which are basically tagged unions). Rather than calling a method of an object as you would in a traditional OO language, in Clay you call a function and pass in arguments that determine which specific overload of the function will be called. The overload may be determined either at compile time or at run-time.

# ? Sep 14, 2012 02:05

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

Plorkyeran posted:

FWIW my experience has been that I end up spending about the same amount of time thinking about resource management in C# and C++, and both are way simpler than Objective-C with automatic reference counting. The learning curve for C++ memory management is definitely steeper than for garbage collected languages, though that's a problem with the language in general.

Are you saying that ARC is complex to think about? If you aren't working with CF classes, the only gotcha I can think of is making sure you don't have retain-cycles, which would be an issue in any language. And those are easily solved by using weak references where appropiate.

# ? Sep 14, 2012 02:13

That Turkey Story: Mar 30, 2003

GrumpyDoctor posted:

It looks like it's how they do their OO:

Right, well, it's more like the alternative to OOP. It's like a boost::variant only with direct language support instead of as a library feature (other languages have it as a language feature as well). I sort of see that they want language support for them so that they can be open, though I'm not convinced you always want them to be open. I exclusively use boost::variant for any runtime polymorphism in all my personal C++ code anyway (I don't use virtual functions), so this seems like it's exactly the type of thing I would want. Edit: Well, I use virtual functions for type erasure too, but really I'd like a more direct way to do type erasure without having to hack it through oop facilities.

A lot of the ideas look like they're directly influenced by Stepanov's Elements of Programming. The only thing is, it doesn't look as though it's yet at the stage where it has full concept and concept map support, or if they're necessarily planned in the sense that they are for C++.

That Turkey Story fucked around with this message at 02:44 on Sep 14, 2012

# ? Sep 14, 2012 02:17

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Carthag posted:

Are you saying that ARC is complex to think about? If you aren't working with CF classes, the only gotcha I can think of is making sure you don't have retain-cycles, which would be an issue in any language. And those are easily solved by using weak references where appropiate.

Retain cycles are only an issue with GC when there are things external to the GC which can retain objects (such as IE's longstanding issue where cycles involving an ActiveX object wouldn't be detected). I find myself having to use CF classes or C libraries fairly frequently.

# ? Sep 14, 2012 04:03

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

Optimus Prime Ribs posted:

I've been tasked with fixing up our company's website, and this is a small snippet of one CSS file (out of four total):
ugh....

CSS code:

a
{
	color:#333333;
	background-color:#FFFFFF;
	font-weight: normal;
	border-left-style: solid;
	border-left-color: #0083bc;
	border-left-width: 10px;
	border-right-style: none;
	border-right-width: 0px;
	border-right-color: #FFFFFF;
	padding-left: 10px;
}

a:hover
{
	background-color:#4e4c4d;
	font-weight: bold;
	padding-left: 10px;
	color: #FFFFFF;
}

Ok, done.

They did just list every instance of their a tags using unnecessarily specific selectors, right?

# ? Sep 14, 2012 12:02

bobthecheese: Jun 7, 2006; Although I've never met Martha Stewart, I'll probably never birth her child.

code:

<script type="text/javascript" src="resources/js/extjs4/ext-all-debug.js" ></script>
<script type="text/javascript" src="resources/js/phpjs/php.full.min.js" ></script>
<script type="text/javascript" src="resources/js/jquery-1.7.1.min.js" ></script>
<script type="text/javascript" src="resources/js/jquery-ui-1.8.16.custom.min.js" ></script>

"Well I'm using one javascript library, but I know PHP, so I'll include a library that lets me use those functions in javascript, too. Also, the jquery library has some nice features. And wouldn't it be nice if there were some widgets I could use... because I don't know the ones in the original library that I'm using"

...gently caress...

At least I'm getting paid well for this.

# ? Sep 14, 2012 13:03

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Wheany posted:

CSS code:

a
{
	color:#333333;
	background-color:#FFFFFF;
	font-weight: normal;
	border-left-style: solid;
	border-left-color: #0083bc;
	border-left-width: 10px;
	border-right-style: none;
	border-right-width: 0px;
	border-right-color: #FFFFFF;
	padding-left: 10px;
}

a:hover
{
	background-color:#4e4c4d;
	font-weight: bold;
	padding-left: 10px;
	color: #FFFFFF;
}

Ok, done.

They did just list every instance of their a tags using unnecessarily specific selectors, right?

You fool! Now the one DIV where they didn't want those colors is all wrong!! Put them back!

My guess is that whoever wrote than has no clue what a .class is.

# ? Sep 14, 2012 13:47

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

Lumpy posted:

You fool! Now the one DIV where they didn't want those colors is all wrong!! Put them back!

My guess is that whoever wrote than has no clue what a .class is.

I wanted to believe it was generated from a WYSIWYG, but the comments indicate otherwise.

# ? Sep 14, 2012 13:55

Vanadium: Jan 8, 2005

Clay looks like it shares some DNA with Haskell, so I'm all for it :v:

# ? Sep 14, 2012 14:23

Optimus Prime Ribs: Jul 25, 2007

Wheany posted:

They did just list every instance of their a tags using unnecessarily specific selectors, right?

Nope. There are plenty of anchor elements in the HTML that are not being referenced by that verbose CSS.
For example there's this (modified to prevent table breakage):

HTML code:

<ul id="menu">
  <li>
    <a href="event_webcasting/index.html">
      <img 
        src="images/menu_1.jpg" 
        alt="Event Webcasting" 
        name="event" 
        width="125" 
        height="60" 
        id="event" 
        onmouseover="MM_swapImage('event','','images/menu_over_1.jpg',1)" onmouseout="MM_swapImgRestore()" 
      />
    </a>
  </li>
  
  <li>
    <a href="professional_services/index.html">
      <img 
        src="images/menu_2.jpg" 
        alt="Professional Services" 
        name="professional" 
        width="151" 
        height="60" 
        id="professional" 
        onmouseover="MM_swapImage('professional','','images/menu_over_2.jpg',1)" onmouseout="MM_swapImgRestore()" 
      />
    </a>
  </li>

  <li>
    <a href="hosting_distribution/index.html">
      <img 
        src="images/menu_3.jpg" 
        alt="Hosting &amp; Distribution" 
        name="hosting" 
        width="145"
        height="60" 
        id="hosting" 
        onmouseover="MM_swapImage('hosting','','images/menu_over_3.jpg',1)" onmouseout="MM_swapImgRestore()" 
      />
    </a>
  </li>
  
  <li>
    <a href="about/index.html">
      <img 
        src="images/menu_5.jpg" 
        alt="Contact Us" 
        name="about" 
        width="74"
        height="60"
        id="about" 
        onmouseover="MM_swapImage('about','','images/menu_over_5.jpg',1)" onmouseout="MM_swapImgRestore()" 
      />
    </a>
  </li>
 </ul>

This would have been so much simpler if the goober who wrote this had just used CSS to swap the images.

Lumpy posted:

My guess is that whoever wrote than has no clue what a .class is.

Pretty much exactly what I thought when I first saw it.

# ? Sep 14, 2012 14:50

Geisladisk: Sep 15, 2007

Probably been posted before, but...

"Tough times on the road to Starcraft posted:

History tells us that programmers feel compelled to try every feature of their new language during the first project, and so it was with class inheritance in StarCraft. Experienced programmers will shudder when seeing the inheritance chain that was designed for the game�s units:

CUnit < CDoodad < CFlingy < CThingy

CThingy objects were sprites that could appear anywhere on the game map, but didn�t move or have behaviors, while CFlingys were used for creating particles; when an explosion occurred several of them would spin off in random directions. CDoodad � after 14 years I think this is the class name � was an uninstantiated class that nevertheless had important behaviors required for proper functioning of derived classes. And CUnit was layered on top of that. The behavior of units was scattered all throughout these various modules, and it required an understanding of each class to be able to accomplish anything.

Who in their right mind would make something as integral as a unit in a RTS game inherit from three seemingly totally unrelated classes? :psyduck:

# ? Sep 14, 2012 15:06

senrath: Nov 4, 2009; Look Professor, a destruct switch!

Guys with absolutely no experience at all using a new language.

# ? Sep 14, 2012 15:12

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

Optimus Prime Ribs posted:

Nope. There are plenty of anchor elements in the HTML that are not being referenced by that verbose CSS.
For example there's this (modified to prevent table breakage):
code:
        onmouseover="MM_swapImage('event','','images/menu_over_1.jpg',1)" onmouseout="MM_swapImgRestore()" 

Oh, that is adorable :3:

# ? Sep 14, 2012 15:20

Optimus Prime Ribs: Jul 25, 2007

Wheany posted:

Oh, that is adorable

It only gets better! Check out the code for those functions:

JavaScript code:

function MM_swapImgRestore() { //v3.0
  var i,x,a=document.MM_sr; for(i=0;a&&i<a.length&&(x=a[i])&&x.oSrc;i++) x.src=x.oSrc;
}

function MM_findObj(n, d) { //v4.01
  var p,i,x;  if(!d) d=document;

  if((p=n.indexOf("?"))>0&&parent.frames.length) {
    d=parent.frames[n.substring(p+1)].document; n=n.substring(0,p);
  }
  
  if(!(x=d[n])&&d.all) x=d.all[n]; for (i=0;!x&&i<d.forms.length;i++) x=d.forms[i][n];
  for(i=0;!x&&d.layers&&i<d.layers.length;i++) x=MM_findObj(n,d.layers[i].document);
  if(!x && d.getElementById) x=d.getElementById(n); return x;
}

function MM_swapImage() { //v3.0
  var i,j=0,x,a=MM_swapImage.arguments; document.MM_sr=new Array; for(i=0;i<(a.length-2);i+=3)
  if ((x=MM_findObj(a[i]))!=null){document.MM_sr[j++]=x; if(!x.oSrc) x.oSrc=x.src; x.src=a[i+2];}
}

I'm wondering what "version 1" of those functions looked like.

# ? Sep 14, 2012 15:31

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Just saw this in a codebase I'm working on. It made me chuckle.

C# code:

var message = GetMessage() ?? GetMessage();

I guess someone wanted to double check.

# ? Sep 14, 2012 15:36

PrBacterio: Jul 19, 2000

Optimus Prime Ribs posted:

I'm wondering what "version 1" of those functions looked like.

I wanted to say "what can't you just look that up in your version control system" but then it dawned on me what the answer to that suggestion might be... :gonk:

# ? Sep 14, 2012 15:46

Xenogenesis: Nov 8, 2005

Optimus Prime Ribs posted:

It only gets better! Check out the code for those functions:

Well the MM_swapImageBullshit were functions generated by old-school Dreamweaver, so it's likely the CSS (complete with nested ID selectors?? really???) was autogenerated too :\

# ? Sep 14, 2012 15:48

Optimus Prime Ribs: Jul 25, 2007

PrBacterio posted:

I wanted to say "what can't you just look that up in your version control system" but then it dawned on me what the answer to that suggestion might be...

No version control of any kind. :downs:

I can't wait to leave this place.

Xenogenesis posted:

Well the MM_swapImageBullshit were functions generated by old-school Dreamweaver

Well at least it wasn't all hand written then.
I still don't know why the hell someone thought using that was a good idea though.

# ? Sep 14, 2012 15:57

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

Ithaqua posted:

Just saw this in a codebase I'm working on. It made me chuckle.
C# code:
var message = GetMessage() ?? GetMessage();
I guess someone wanted to double check.

We do stuff like that here (only with try/catch blocks) because some of our services talk to a Microsoft CRM server (in the background) that's so slow that the first call is overwhelmingly likely to fail with a timeout. Of course, we can't get rid of CRM because it lets idiots make pretty drag-and-drop UIs to enter and display their data.

# ? Sep 14, 2012 16:15

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Munkeymon posted:

We do stuff like that here (only with try/catch blocks) because some of our services talk to a Microsoft CRM server (in the background) that's so slow that the first call is overwhelmingly likely to fail with a timeout. Of course, we can't get rid of CRM because it lets idiots make pretty drag-and-drop UIs to enter and display their data.

It seems like a better approach would be to handle the timeout within the methods requesting the data. The calling code shouldn't have to worry about it. I'd classify doing Method() ?? Method(); as a horror in pretty much any circumstance.

# ? Sep 14, 2012 16:32

Adbot: ADBOT LOVES YOU

# ? Jun 4, 2024 07:46

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

Ithaqua posted:

It seems like a better approach would be to handle the timeout within the methods requesting the data. The calling code shouldn't have to worry about it. I'd classify doing Method() ?? Method(); as a horror in pretty much any circumstance.

I'd have to check, but I think the exceptions get thrown by framework internals when the other service just doesn't respond because it's waiting for CRM*, so there might not be a better way around it. I just try to avoid those parts - it's dark in there :ohdear:

* we go through some third party (purchased) library that's not actively developed anymore, so we can't even be sure what's actually going on there

# ? Sep 14, 2012 17:11

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 »