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!

«‹›2 »

blorpy: Jan 5, 2005

But maybe after the program pops off the stack and returns to the other function it'll get bored or something and come back to it and evaluate the rest of the statement!!!

# ¿ Apr 3, 2008 18:26

Adbot: ADBOT LOVES YOU

# ¿ Apr 26, 2024 05:43

blorpy: Jan 5, 2005

The javascript embedded in http://www.rockband.com resizes your browser. I thought we got past this years ago

# ¿ Jun 3, 2008 00:45

blorpy: Jan 5, 2005

I wonder how many NULLs are in that table. That is probably one of the most sparse tables ever created.

# ¿ Jun 6, 2008 22:24

blorpy: Jan 5, 2005

Ok, I was right, that table is incredibly sparse.

It's kind of funny that an hour's worth of reading about database theory would have eliminated this problem.

# ¿ Jun 6, 2008 22:54

blorpy: Jan 5, 2005

Ryouga Inverse posted:

I can't even figure out what he's thinking. Two minutes of asking a question would have solved his problem.

I remember when I was first trying to figure out how to make a web-based game, having only done one in mIRC script (christ, that's a coding horror all its own) and coming to the conclusion that I was probably going to have to make a separate table for each player.

I had to ask someone how I'd pull that off and she was like "wtf??? NO" and that pretty much fixed me.

For "easy" languages like web programming, I've always learned just by reading others' code and doing some basic playing with the code, and then delving into books. It removes all those reinventing the wheel obstacles.

# ¿ Jun 6, 2008 23:26

blorpy: Jan 5, 2005

duz posted:

I think he's thinking he has to put each visitor into their own row and add a column for each time they click. I'm not sure how one would ever come to that `solution`.

It would look like this I guess

code:


..........  Click000      Click001       Click002 ...
Visitor000  index.php     NULL           NULL
Visitor001  index.php     contact.php    products.php
Visitor002  products.php  index.php      NULL
.
.
.

substitute real links for the above

:barf:

# ¿ Jun 6, 2008 23:37

blorpy: Jan 5, 2005

Is this going to become another fizzbuzz? As with that, anyone who posts a solution is probably not fit to do so.

# ¿ Jul 12, 2008 06:25

blorpy: Jan 5, 2005

crazypenguin posted:

I forget who's blog it was, but man it must have sucked to be that guy. "Gee, a pile of morons make up my readership. "

Here's a hint.

quote:

Coding horrors: post the code that makes you laugh (or cry)

# ¿ Jul 12, 2008 07:41

blorpy: Jan 5, 2005

mr_jim posted:

A friend just told me about a guy he works with who prefaces every function name with his user name, as in:
code:
userName_funcName();

maybe he just saw all those examples using myFunc and decided to personalize it a bit further :haw:

# ¿ Apr 2, 2009 23:17

blorpy: Jan 5, 2005

Otto Skorzeny posted:

C'mon guys, plenty of people make lovely first posts, our job is to educate them so they don't end up like Victor or Chain Chomp

gently caress you

# ¿ Jul 25, 2009 06:35

blorpy: Jan 5, 2005

Ryouga Inverse posted:

From what he's said in the QuestHelper thread, that would seem to be the case (he talks about how it tends to get "stuck" on somewhat-good solutions when a large change would be better, which is exactly the issue a GA would face, for example)

GAs are still magic to me. I want to make a game with GA AIs.

Check out an existing GA lib like NEAT (or its modified cousin rtNEAT)

# ¿ Jul 31, 2009 05:31

blorpy: Jan 5, 2005

PraxxisParadoX posted:

PHP

# ¿ Sep 9, 2009 06:49

blorpy: Jan 5, 2005

Oh chocojosh, never stop posting. :shobon:

# ¿ Oct 6, 2009 22:54

blorpy: Jan 5, 2005

Janin posted:

Please post more details about insane Japanese software, because this post right here is incredible.

Ruby.

# ¿ Nov 9, 2009 21:29

blorpy: Jan 5, 2005

Vanadium posted:

Tell me more.

Well you see, Ruby was written by a chinaman, and they have a poor ability to write code.

# ¿ Nov 10, 2009 07:07

blorpy: Jan 5, 2005

ColdPie posted:

pre:
if(0)
  //what
  printf("hi");
prints "hi". your if-statement is useless.

holy moley coldpie

it's you. you're the coding horror itt.

# ¿ Mar 26, 2010 23:24

blorpy: Jan 5, 2005

Lexical Unit posted:

code:

char* data = blarg ();

star on the left? thats teh real coding horror

# ¿ Mar 30, 2010 20:22

blorpy: Jan 5, 2005

jonjonaug posted:

Better yet:

code:

//convert all characters in a word to upper_case
string WordDistribution::toUppercase( string check )
{
        for( size_t ii = 0; check[ii] != '\0'; ii++ )
        {
                check[ii] &= ~0x20;    // Convert the character to uppercase
        }
        return check;
}

Or if you don't trust your compiler to optimize it out:

code:

//convert all characters in a word to upper_case
string WordDistribution::toUppercase( string check )
{
        size_t temp=check.length();
        for( size_t ii = 0; ii < temp; ii++ )
        {
                check[ii] &= ~0x20;    // Convert the character to uppercase
        }
        return check;
}

You guys are missing the obvious optimizations your video card could be doing. This sort of parallel work is perfect for GPGPU/CUDA/etc. Just think how much faster this could run in such an environment!

# ¿ Apr 27, 2010 21:26

blorpy: Jan 5, 2005

Student code is disallowed in this thread, right? My group code-an-OS project has been the source of many horrors.

# ¿ Apr 27, 2010 22:01

blorpy: Jan 5, 2005

Ok, this stuff is from two of my teammates in my OS project. It's student code so you'd expect some level of shittiness but then again, it is a junior-level course. Also, if you don't know C you have no business calling yourself a computer engineer. :colbert:

On with the lovely code.

Guess what this is doing (variable names changed slightly and extraneous code removed to highlight the horror)

code:

int32_t syscall_open(const uint8_t *filename)
{
    ...
    for(int i = 0; i < 63; i++)
    {
        if(thing[i].file_name == (char)filename)
        {
            ...
        }
    }
}

(thing[i].file_name is a char array)
String comparison! Because that's totally how string compare in C works.

The next horror isn't about code itself. I had a continue; in my code somewhere and these two brilliant guys asked me where this "continue function" was declared. Think about that for a second. They thought that I was calling a function named continue, despite not having any parens and despire continue being highlighted by their text editors in the same color as every other reserved word.

Finally, l'horreur finale with a little bit of code I can demonstrate.

During a rush to get one our checkpoints done I wrote some somewhat hackish code. The same two teammates as before decided to "refactor" afterwards in an attempt to scrub off the hackishness. In particular, there was an issue where the assignment sheet happened to mention storing an inode_t * inside a file descriptor struct. I stored the inode_t itself because we have no memory allocation and there's no actual points based on storing a inode_t * instead of the inode_t itself. I figured that would be the last I'd ever hear of it but then I take a look at the code and see that they've gone through and changed all the inode_ts to inode_t *s without actually allocating any space! Worse yet, they changed

code:

inode_t node;
get_inode_by_name(name, &node);

code:

inode_t *node;
get_inode_by_name(name, node);

which clearly does not even initialize the pointer! asjhaosjaoijs ffffffffffffffff

The worst thing is that because we're in kernel mode this "works" most of the time for small tests.

When I pointed this out, I saw the following change shortly afterwards.

code:

inode_t *node = NULL;
get_inode_by_name(name, node);

tl;dr: 2 of my teammates manage to do negative work on this project. sadly i feel they're probably going to graduate with the same degree as me.

# ¿ Apr 28, 2010 03:04

blorpy: Jan 5, 2005

theg sprank posted:

Really that's all your fault though. You should have picked better partners.

From what I can tell these guys are roughly on average skill level for the course.

# ¿ Apr 28, 2010 06:22

blorpy: Jan 5, 2005

wwb posted:

Except that the homo who wrote MySql decided to try and get the EU to stop the deal because his database is a special snowflake that deserves to live.

We should loving nuke sweden.

The real horror here is that none of you called this guy on his homophobic bigotry. Shame on all of you.

# ¿ Jul 3, 2010 20:41

blorpy: Jan 5, 2005

Shumagorath posted:

____________/

Cool, an old gimmick and you didn't even get the nbsp right. Congratulations.

# ¿ Jul 3, 2010 21:20

blorpy: Jan 5, 2005

shrughes posted:

\____________

# ¿ Jul 3, 2010 21:31

blorpy: Jan 5, 2005

Come on guys, Lerdorf is Danish! Know your Scandinavian countries.

# ¿ Jul 4, 2010 06:43

blorpy: Jan 5, 2005

So it turns out that Cake Poker, a fairly major poker site, was using XOR encryption on everything and was found to have a couple of possible unaccounted for superusers on its site. When pressured about this issue, they advised players to make sure to only use wireless networks with WEP. :psyduck:

# ¿ Aug 12, 2010 02:14

blorpy: Jan 5, 2005

here's a cool thing, it's the run loop for erlang
https://github.com/erlang/otp/blob/dev/erts/emulator/beam/beam_emu.c

im not going to quote it because it's 6500 lines and i don't feel like i could do it justice, but just click and have a look

# ¿ Aug 19, 2011 08:04

blorpy: Jan 5, 2005

tef posted:

it has a bunch of op codes and a dispatch mechanism

vm code is never going to win beauty contests

fair enough, you're right. it's not a horror, but i don't envy the people who have to maintain it

# ¿ Aug 19, 2011 08:33

blorpy: Jan 5, 2005

pokeyman posted:

I've seen it argued that its C-like syntax helped it (or was necessary, even, to) get adopted everywhere, and it turns out it's not at all a bad language. I would've said the same thing as you a year ago, but I've changed my mind.

javascript is a terrible language and youre only giving it the benfit of a doubt because it becomes ok once you bolt 3 frameworks on top of it

# ¿ Sep 14, 2011 09:50

blorpy: Jan 5, 2005

pokeyman posted:

Which three frameworks did you have in mind?

It's a decent language if you change the syntax a bit. I'll happily concede that it's too easy to do stupid things in straight JavaScript.

Sorry, I was just using a bit of hyperbole, there's no specific 3. But, IMO, JS ranks up there with PHP in terms of "lets you do stupid things".

# ¿ Sep 14, 2011 20:31

blorpy: Jan 5, 2005

It's 2011, please stop writing raw SQL, everybody. If you would, look up an ORM for whatever framework you're using. There's literally no reason to be operating with your DB directly (unless you're the author a DB adapter for an ORM, in which case go nuts)

# ¿ Dec 10, 2011 01:51

blorpy: Jan 5, 2005

jonjonaug posted:

Are we just talking about web design or in general because I can think of a lot of applications for interacting with a database.

In general, and I agree, there are plenty of cases where you should interact with a database -- through an ORM.

# ¿ Dec 10, 2011 02:00

blorpy: Jan 5, 2005

baquerd posted:

There is no good reason to add the added complexity of an ORM for many simple tasks. It may be "nicer" in a way, but it adds another layer of failure and checks that need to be done.

Suppose we want to read a table and display it to the page. Why ORM?

The rule of thumb is to prefer more abstraction, not less, unless you have a very particular reason for doing so.

# ¿ Dec 10, 2011 02:28

blorpy: Jan 5, 2005

wwb posted:

I can think of lots of neat set-based operations that are horribly ugly or expensive in an ORM. I can think of lots of lightweight apps that do just fine without the ceremony of an ORM. I can think of lots of apps I made worse by adding an ORM. Choose the right tool for the job -- and sometimes the right tool is raw sql.

See above. This is C versus assembly all over again. Having more abstraction makes everyone's lives better. Also, for what it's worth, some ORMs do actually include the ability the make nearly full use of what you can do with raw SQL. If yours doesn't, why not just patch it?

By the way "thinking of" apps that shouldnt have an ORM sounds suspiciously like premature optimization to me. This is pretty much always the case when you start talking about sacrificing portability and maintainability for "performance"

quote:

If I was to make any brash-assed blanket statement about data access in 2012, it would be that your default answer for data storage should not be relational. Document databases make so much more sense for most apps and generally dodge the whole issue of needing or not needing an ORM in the first place.

Completely irrelevant because I wasn't talking about data access, I was talking about SQL.

# ¿ Dec 10, 2011 02:33

blorpy: Jan 5, 2005

Kim Jong III posted:

ORMs are classic examples of what Joel Spolsky means when he says all non-trivial abstractions leak.

That's not to say that ORMs aren't, in very many cases, the best thing since sliced bread. Especially if you are doing CRUD webapps. Oh god, ORM's are great at CRUD. But when the ORM is generating nasty, slow, or completely broken SQL you're going to spend time peeling back abstractions, and that takes time.

Hell, for Django's ORM, consider:
code:
# Don't do this to see if something exists...
if some_queryset:
    pass

# ... do this...
if some_queryset.exists():
    pass

#... BUT not every time; sometimes, do this:
if some_queryset:
    #why?
    for x in some_queryset:
        print x.foo
And that's just something to worry about with the CRUD apps

I didn't say you wouldn't have to know any SQL or not understand how an ORM maps to SQL. It's still useful to understand how it works. It's just way better to use the ORM in actual code, though (and small bits of sql where the ORM won't let you do something)

# ¿ Dec 10, 2011 02:43

blorpy: Jan 5, 2005

Cubiks posted:

I'd say it would be better to use a simpler solution, not just add more abstraction. Unless you really enjoy enterprise java with its endless nested ThingFactoryFactoryImplementationFactories. Can't get much more abstraction!

Strawman. I can easily counter that with "well then why aren't you writing all your programs in raw assembly?". Yawn.

quote:

I'll admit, use ORM when it makes sense: when you have very clear Object to Table mappings and no possibility of strange queries now or in the future. But as wwb says, trying to do any useful, optimized SQL (i.e. one of the reasons you use a relational db in the first place) is really painful in most ORMs I've seen.

Just one example. Please, that's all I'm asking.

Also, nothing forbids you from using both.

# ¿ Dec 10, 2011 02:45

blorpy: Jan 5, 2005

npe posted:

If we're just tossing out blanket statements for all applications out of our rear end, then I'll use this opportunity to say your application shouldn't be concocting *any* queries on the fly ever - not even via an ORM. Use stored procedures and marshal your complex types. Keep the SQL in the db!

(If this is not appealing to you then you should be using a document store and not a relational database anyhow.)

*Note: I don't actually believe this. As it turns out, many application domains are completely different from each other and there are very different considerations for each!

Actually, as it turns out, an ORM is basically always the right choice unless you have enough experience to know different, and in that case you're not someone who's asking questions about SQL on the internet.

# ¿ Dec 10, 2011 02:50

blorpy: Jan 5, 2005

shrughes posted:

The rule of thumb of a fresh college graduate.

Are you officially stalking me now

# ¿ Dec 10, 2011 03:15

blorpy: Jan 5, 2005

tef posted:

a quick recap for those who haven't been reading the thread

Pushing the limits. No-one said it had to be fast explicitly, but the implication was that orms have limitations and sometimes you must use sql. speed is one of those mitigating factors in choosing to use sql over an orm.

Your 'it can be done in an orm ' was a facile statement beside the point. orms can model a large chunk of things. we know this. however it turns out there are tradeoffs, like performance,e that are not made in your favour.

If you're going to contribute with your deadly wit and canny ripostes, it would help if we didn't have to explain all the words in the post you're replying to.

also, 'ruby is written in c so it's fast'

Are you daft, tef? Any decent ORM would turn that given example into exactly the same SQL that a human would write (although not if you tried to write it the way notshadowstar did). And with a good JIT the differences would disappear outright. Maybe you ought to step out of the world of turtles and into the modern era.

# ¿ Dec 11, 2011 09:33

Adbot: ADBOT LOVES YOU

# ¿ Apr 26, 2024 05:43

blorpy: Jan 5, 2005

For reference, here's a code snippet from one ORM^{^[1]} which makes quick work out of that example

code:

class Avg(Aggregate):
    is_computed = True
    sql_function = 'AVG'

class Count(Aggregate):
    is_ordinal = True
    sql_function = 'COUNT'
    sql_template = '%(function)s(%(distinct)s%(field)s)'

    def __init__(self, col, distinct=False, **extra):
        super(Count, self).__init__(col, distinct=distinct and 'DISTINCT ' or '', **extra)

class Max(Aggregate):
    sql_function = 'MAX'

class Min(Aggregate):
    sql_function = 'MIN'

class StdDev(Aggregate):
    is_computed = True

    def __init__(self, col, sample=False, **extra):
        super(StdDev, self).__init__(col, **extra)
        self.sql_function = sample and 'STDDEV_SAMP' or 'STDDEV_POP'

class Sum(Aggregate):
    sql_function = 'SUM'

class Variance(Aggregate):
    is_computed = True

    def __init__(self, col, sample=False, **extra):
        super(Variance, self).__init__(col, **extra)
        self.sql_function = sample and 'VAR_SAMP' or 'VAR_POP'

______________________________________________
[1] Django Project, The. https://github.com/django/django/blob/master/django/db/models/sql/aggregates.py .

# ¿ Dec 11, 2011 09:46

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!

«‹›2 »