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 »

Zombywuf: Mar 29, 2008

Zhentar posted:

It's the foreach structure that gets a bit awkward, although it makes up for it by being very flexible.
code:
	f  s num=$o(^CoC(num)) q:num=""  d  

Yeah, you see that bit where that's completely incomprehensible, that's the bit that makes this bad. I have no idea in that statement what's a keyword, what's a variable, what's a collection or even what's a name and what's an operator. It is so ugly that I have no desire to find out.

# ? Apr 24, 2010 09:55

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 08:43

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Zombywuf posted:

Yeah, you see that bit where that's completely incomprehensible, that's the bit that makes this bad. I have no idea in that statement what's a keyword, what's a variable, what's a collection or even what's a name and what's an operator. It is so ugly that I have no desire to find out.

Oh you don't know the half of it. The whitespace is the most important part of that line.

# ? Apr 24, 2010 17:15

jonjonaug: Mar 26, 2010; by Lowtax

Zhentar posted:

I'm cool with the for loop structure.

It's the foreach structure that gets a bit awkward, although it makes up for it by being very flexible.
code:
	f  s num=$o(^CoC(num)) q:num=""  d  

I think you need professional help.

# ? Apr 24, 2010 17:39

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

The worst part is that I'm not sure if "CoC" is a reference to Cavern of Cobol, or just some other obscure MUMPS keyword or operator.

# ? Apr 24, 2010 17:57

pseudorandom name: May 6, 2007

Flobbster posted:

The worst part is that I'm not sure if "CoC" is a reference to Cavern of Cobol, or just some other obscure MUMPS keyword or operator.

It's a global function, but I have no idea what it does.

# ? Apr 24, 2010 18:03

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

If I'm reading it right, that would be equivalent to

code:

FOR  SET num=$ORDER(^CoC(num)) QUIT:num=""  DO

^CoC is a global/persistent variable named "CoC".

I'm still trying to figure out how $ORDER() works, exactly.

# ? Apr 24, 2010 18:07

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Have fun: http://71.174.62.16/Demo/AnnoStd?Frame=Main&Edition=1995&Page=a107100#Def_0003

Let's see if I remember this stuff.

code:

FOR  SET num=$ORDER(^CoC(num)) QUIT:num=""  DO

"FOR " is an infinite loop that executes all the crap on the rest of the line. SET num=$ORDER(^CoC(num)) essentially says "Get the value at the index num in the global variable ^CoC and then tell me the index of the next value and set num to that. So it's a bizarro iterator. QUIT:num="" says "break out of this loop, but only when num is the empty string. DO says "execute the block on the following lines".

So it translates roughly to:

code:

num = "";
while(true)
{
    num = ^CoC[num].next();
    if(num == "") break;

    // do stuff
}

# ? Apr 24, 2010 18:35

Dessert Rose: May 17, 2004; awoken in control of a lucid deep dream...

When it was all written out, I sort of had a vague idea of what was going on. I feel a little insane that I was able to figure any of it out.

# ? Apr 24, 2010 18:47

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

Avenging Dentist posted:

Job Security

Dear god.

# ? Apr 24, 2010 19:16

Zhentar: Sep 28, 2003; Brilliant Master Genius

Avenging Dentist posted:

QUIT:num="" says "break out of this loop, but only when num is the empty string.

Just to clarify, the empty string is not a legal subscript. When $ORDER returns "", that means you've reached the end of the array.

Internet Janitor posted:

<job security>

Not really. This stuff can be easily trained in under a week.

# ? Apr 24, 2010 19:33

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Zhentar posted:

Not really. This stuff can be easily trained in under a week.

Which is why the training period is (was?) three months for developers. And that's excluding application training and project-level training. All told, it was about 7 months before I committed a single thing.

# ? Apr 24, 2010 19:37

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

From the perspective of writing new software, MUMPS doesn't strike me as dramatically worse than most scripting languages, especially if you aren't taking advantage of some of the "features" that make it more cryptic.

Maintenance, on the other hand, looks like an absolute nightmare. Code is nearly meaningless out of context. Legacy codebases were encouraged to use cryptic variable names and no comments. It's like how PHP would look if it was invented in the early 70s.

# ? Apr 24, 2010 19:48

Zombywuf: Mar 29, 2008

Internet Janitor posted:

From the perspective of writing new software, MUMPS doesn't strike me as dramatically worse than most scripting languages, especially if you aren't taking advantage of some of the "features" that make it more cryptic.

Maintenance, on the other hand, looks like an absolute nightmare. Code is nearly meaningless out of context. Legacy codebases were encouraged to use cryptic variable names and no comments. It's like how PHP would look if it was invented in the early 70s.

It looks like an extension of DOS batch files. It's a long way from being like a modern (where bash is defined as modern) scripting language.

# ? Apr 24, 2010 19:57

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Internet Janitor posted:

Legacy codebases were encouraged to use cryptic variable names and no comments.

That's because comments did (and still do) impose a small runtime performance hit in MUMPS. (Yeah, go ahead and read that again.) Also global variables were infinitesimally faster than local variables, so in the absence of actual performance data, they relied on superstition to tune their code. Incidentally, this is still the case at Epic, or was when I was there; people who went through training at different times received vastly divergent advice about performance (and it wasn't due to compiler/interpreter changes).

# ? Apr 24, 2010 20:00

jonjonaug: Mar 26, 2010; by Lowtax

Avenging Dentist posted:

That's because comments did (and still do) impose a small runtime performance hit in MUMPS. (Yeah, go ahead and read that again.)

The more I hear about this language the more accurate "Stockholm Syndrome" becomes to describe Zhentar.

# ? Apr 24, 2010 20:06

pseudorandom name: May 6, 2007

My understanding is that the MUMPS interpreter parses the line every time it is executed, which is why abbreviating the keywords, using one letter variable names and avoiding comments actually makes it faster.

# ? Apr 24, 2010 20:15

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Yeah, I'm fairly sure that Intersystems Cache (the MUMPS interpreter/environment) doesn't compile to bytecode.

# ? Apr 24, 2010 20:31

ozymandOS: Jun 9, 2004

Avenging Dentist posted:

Yeah, I'm fairly sure that Intersystems Cache (the MUMPS interpreter/environment) doesn't compile to bytecode.

As of a recent version, Cach� is now compiled to byte code and comments no longer cause a performance hit. By recent, I mean in the last year or two.

# ? Apr 24, 2010 21:56

Zhentar: Sep 28, 2003; Brilliant Master Genius

Avenging Dentist posted:

Which is why the training period is (was?) three months for developers. And that's excluding application training and project-level training. All told, it was about 7 months before I committed a single thing.

Was. They've cut it down to about 2 1/2 months. But of that, only one week was MUMPs specific; the rest was VB, framework, and application training (so I don't know why you would think that was excluded...). By my 6 month mark, I'd completed a project to be delivered to a customer shortly, so I'm guessing your team was weird.

BP posted:

As of a recent version, Cach� is now compiled to byte code and comments no longer cause a performance hit. By recent, I mean in the last year or two.

Cach� has compiled to byte code for a long time. Comments at the end of lines were stripped, however lines that were pure comments were compiled as noops, to preserve line numbering for jumps to offsets. Recent improvements have allowed lines that are pure comments to be removed entirely.

# ? Apr 24, 2010 23:07

Zhentar: Sep 28, 2003; Brilliant Master Genius

Avenging Dentist posted:

so in the absence of actual performance data, they relied on superstition to tune their code. Incidentally, this is still the case at Epic, or was when I was there; people who went through training at different times received vastly divergent advice about performance (and it wasn't due to compiler/interpreter changes).

There are still plenty of people who attempt tune their code without gathering performance data, misunderstand recommendations, and disseminate incorrect information. Although this thread is proof that the problem is hardly unique to Epic or MUMPS.

There has been some substantial effort recently to improve the quality of performance training and documentation, which has helped.

Avenging Dentist posted:

Also global variables were infinitesimally faster than local variables

Local variables are much faster than globals for a relatively small number of subscripts. However, globals scale much better.

# ? Apr 24, 2010 23:24

Zombywuf: Mar 29, 2008

Zhentar posted:

Local variables are much faster than globals for a relatively small number of subscripts. However, globals scale much better.

There is not enough WTF in the world to describe what is wrong with this.

# ? Apr 25, 2010 00:32

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Zhentar posted:

Was. They've cut it down to about 2 1/2 months. But of that, only one week was MUMPs specific; the rest was VB, framework, and application training (so I don't know why you would think that was excluded...). By my 6 month mark, I'd completed a project to be delivered to a customer shortly, so I'm guessing your team was weird.

We did at least a month of MUMPS programming in training. This is as of late 2006 though, so it's possible that their standards have changed. Unfortunately, my guess is that their training standards have lowered rather than their hiring standards have raised. Also, this was the same for every single developer that started when I did, since I saw all of them in developer classes for three months. Once you hit the three month mark, you did about a month and a half of app training and then I moved onto my team's training which was largely redundant with other training (except for "welcome to the wild world of HTML"). To be fair, part of the reason it took me six months was because I gave absolutely no gently caress about my training since I knew it was bullshit from day one (and getting yelled at for trying to program Scorched Earth in MUMPS didn't help). I think the motivated people took about 5 months though.

Zhentar posted:

Local variables are much faster than globals for a relatively small number of subscripts. However, globals scale much better.

I mean lexical globals, not MUMPS globals. It's been a while.

Avenging Dentist fucked around with this message at 04:24 on Apr 25, 2010

# ? Apr 25, 2010 04:16

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

Zombywuf posted:

There is not enough WTF in the world to describe what is wrong with this.

Given that it's an interpreted language (or was until recently), not really. Choosing a data structure for local variables which has a low fixed cost but has poor asymptotic scaling makes sense, as given sane programmers, most functions will have few local variables. On the other hand, a large program may accumulate a large number of global variables, so it may make sense to choose a data structure that scales well but has a relatively high constant cost.

Assuming the crossover point in speed is in the range of 100 and not 5, I don't see anything to WTF about.

# ? Apr 25, 2010 04:19

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Oh also:

Zhentar posted:

Although this thread is proof that the problem is hardly unique to Epic or MUMPS.

It's a bit of an egregious failing when the very same person (who's in charge of basically all the programmers) at one point asserts that in Visual Basic, using With statements is 10x faster than not using it, and then a couple years later says the difference is a wash. I mean, I suppose it's my fault for not automatically tuning everyone out the moment they utter the words "Visual Basic", but what can I say? I'm a glutton for punishment.

# ? Apr 25, 2010 04:30

Zhentar: Sep 28, 2003; Brilliant Master Genius

Avenging Dentist posted:

We did at least a month of MUMPS programming in training. This is as of late 2006 though, so it's possible that their standards have changed. Unfortunately, my guess is that their training standards have lowered rather than their hiring standards have raised. Also, this was the same for every single developer that started when I did, since I saw all of them in developer classes for three months. Once you hit the three month mark, you did about a month and a half of app training and then I moved onto my team's training which was largely redundant with other training (except for "welcome to the wild world of HTML").

I went through training in early 2007. We had a full month that involved MUMPS type things, but only one week of that was actual language training.

I think the main reduction in training is cutting out a lot of things that weren't worth the time. Some things have also been moved to e-learning that can be done as needed.

Avenging Dentist posted:

I mean lexical globals, not MUMPS globals. It's been a while.

Oooooh. I don't know whether or not that's still the case (nor do I care, since it's never come up).

Avenging Dentist posted:

It's a bit of an egregious failing when the very same person (who's in charge of basically all the programmers) at one point asserts that in Visual Basic, using With statements is 10x faster than not using it, and then a couple years later says the difference is a wash.

Yeah, I'll give you that one. With hasn't really mattered since native compiled code. I don't know why it took a decade for people to get up to speed.

# ? Apr 25, 2010 05:17

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Zhentar posted:

I went through training in early 2007. We had a full month that involved MUMPS type things, but only one week of that was actual language training.

I could teach C++ in "a week" to programmers who'd never used C, C++, or Java if I got to spend three more weeks after that cementing the ideas in with more examples. This doesn't mean I'd assert that C++ can be learned in a week. Granted, I remember the language training itself being longer than that, but I really honestly think that if they gave you (the rhetorical you) a week and then expected you to write anything substantial in MUMPS, you'd have a lot of problems and would constantly be consulting references.

Zhentar posted:

Oooooh. I don't know whether or not that's still the case (nor do I care, since it's never come up).

It comes up indirectly if you ever have to look at any old code.

Zhentar posted:

Yeah, I'll give you that one. With hasn't really mattered since native compiled code. I don't know why it took a decade for people to get up to speed.

I will grant that it's possible that the person who relayed the "10x faster" statement is just stupid as gently caress, since it takes a pretty dumb person to be bad enough with money that he'd have problems paying rent on an apartment on Epic money.

Of course, if we start going into horrors committed by my actual coworkers, we'll be here all drat day. A choice example: one of my coworkers swore up and down that it is logically impossible for a programming language to support function pointers. I died a little that day.

# ? Apr 25, 2010 05:33

Zombywuf: Mar 29, 2008

Plorkyeran posted:

Given that it's an interpreted language (or was until recently), not really. Choosing a data structure for local variables which has a low fixed cost but has poor asymptotic scaling makes sense, as given sane programmers, most functions will have few local variables. On the other hand, a large program may accumulate a large number of global variables, so it may make sense to choose a data structure that scales well but has a relatively high constant cost.

But it is no longer an interpretted language so all variables can be stored in an array.

Also "for a relatively small number of subscripts," what does that even mean?

# ? Apr 25, 2010 13:32

poopiehead: Oct 6, 2004

One of my coworkers found this nugget the other day, trying to see why a cache isn't performing very well.

code:

public class CacheKey
{
  private final Object[] parts;

  public int hashCode()
  {
    return parts[0].hashCode() + parts[parts.length-1].hashCode();
  }
  ...
}

Clearly, only the first and last entries of an arbitrarily sized array could matter. At least it takes the attention away from the fact that the author thought that summing up a few hash codes would be sufficient.

# ? Apr 25, 2010 15:00

dancavallaro: Sep 10, 2006; My title sucks

I guess someone wasn't paying attention in class when they were learning about hash tables.

# ? Apr 25, 2010 16:57

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

Zombywuf posted:

Also "for a relatively small number of subscripts," what does that even mean?

IIRC every variable in mumps is an array, initially of length 1, with elements 2..n being auto-vivified when element n is accessed.

Somehow everything is a row in a database, too.

# ? Apr 25, 2010 19:26

GROVER CURES HOUSE: Aug 26, 2007; Go on...

Otto Skorzeny posted:

IIRC every variable in mumps is an array, initially of length 1, with elements 2..n being auto-vivified when element n is accessed.

Somehow everything is a row in a database, too.

Is MUMPS an elaborate practical joke?

# ? Apr 25, 2010 19:54

1337JiveTurkey: Feb 17, 2005

Broken Knees Club posted:

Is MUMPS an elaborate practical joke?

Most modern dynamically typed scripting languages share the use of an associative array as their primary/only data structure. In that sense, the language is somewhat ahead of the curve and it got there because medical records keeping really needs that sort of functionality. People come down with new problems that require new types of tests and treatments. The relational model doesn't fit very well to it, whereas associative arrays are just what the doctor ordered. :v:

Everything somehow being a row in a database is another way of describing single level storage, which is quite popular outside of OS derivatives of CP/M and UNIX. In Multics, the primary method for accessing files was effectively mmap and there wasn't a need for some dedicated API for writing to disks since a file was just another segment in your process memory space. The UNIX model of files being streams of bytes took off due to the lack of hardware support for that in minicomputers, microcomputers and personal computers. These days everything has virtual memory support, though and the only excuse for multi level storage is that it's what everyone's used to.

# ? Apr 25, 2010 23:09

Zhentar: Sep 28, 2003; Brilliant Master Genius

Otto Skorzeny posted:

IIRC every variable in mumps is an array, initially of length 1, with elements 2..n being auto-vivified when element n is accessed.

Not really.

In MUMPS, there is only one data structure. It's really an associative tree rather than an associative array; with each node of the tree identified by a string, and optionally containing a value. "Subscripts" are the identifiers for the nodes, so when I refer to the number subscripts I'm actually referring to the number of nodes, usually at one level of the tree. I think the M standard allows for up to 128 levels.

"Local" variables usually refers not to the scope of variables, but to variables which exist within the stack for the process. This stack is usually pretty small (our current recommended configuration limits the stack for each process to 3MB). Global variables are prefixed with "^" (such as ^CoC), are persistent variables backed by the disk; which effectively makes them the database and their contents rows.

# ? Apr 25, 2010 23:43

Crazy RRRussian: Mar 5, 2010; by Fistgrrl

From codebase of project I am collaborating on with other grad students:

code:

//convert all characters in a word to upper_case
string WordDistribution::toUppercase( string check )
{
        for( int i = 0; i < static_cast<int> ( check.length() ); i++ )
        {
                switch( check[i] )
                {
                        case 'a':
                                check[i] = 'A';
                                break;
                        case 'c':
                                check[i] = 'C';
                                break;
                        case 'g':
                                check[i] = 'G';
                                break;
                        case 't':
                                check[i] = 'T';
                                break;
                        case 'n':
                                check[i] = 'N';
                                break;
                        case 'A':
                                break;
                        case 'C':
                                check[i] = 'C';
                                break;
                        case 'G':
                                check[i] = 'G';
                                break;
                        case 'T':
                                check[i] = 'T';
                                break;
                        case 'N':
                                check[i] = 'N';
                                break;
                        default:
                                check[i] = 'N';
                                break;
                }
        }
        return check;
}

# ? Apr 26, 2010 00:00

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

LockeNess Monster posted:

From codebase of project I am collaborating on with other grad students:

Please tell me it involves genetics in some way

# ? Apr 26, 2010 00:28

Crazy RRRussian: Mar 5, 2010; by Fistgrrl

Janin posted:

Please tell me it involves genetics in some way

Yup. I was hired as RA for this project to implement some additional features, but now I am trying to rebel and convince them that most of the codebase has to be cleaned up and re-factored.

I mean most of the code in the rest of the project is on the level of what you see here.

# ? Apr 26, 2010 00:29

Shumagorath: Jun 6, 2001

1337JiveTurkey posted:

These days everything has virtual memory support, though and the only excuse for multi level storage is that it's what everyone's used to.

I'm not sure what virtual memory has to do with that, but hasn't Microsoft been trying to bring this back for WinFS for a decade now and they just keep getting held up?

# ? Apr 26, 2010 00:35

Bozart: Oct 28, 2006; Give me the finger.

LockeNess Monster posted:

Yup. I was hired as RA for this project to implement some additional features, but now I am trying to rebel and convince them that most of the codebase has to be cleaned up and re-factored.

I mean most of the code in the rest of the project is on the level of what you see here.

Gotta love the "oh, you gave us a genetic code which doesn't exist? Here have N"

# ? Apr 26, 2010 00:36

Crazy RRRussian: Mar 5, 2010; by Fistgrrl

Bozart posted:

Gotta love the "oh, you gave us a genetic code which doesn't exist? Here have N"

Well in FASTA format N is supposed to mean that sequencer wasn't sure what nucleotide it was, so N is actually legit in input data. However also notice passing string by value, not consting it as well as method not being const and returning a brand new string.

Let's just say its not hard to optimize this thing and then show results and be all smug "oh hey, i made this poo poo run faster".

EDIT: Also I am not 100% sure but I think that this += operator on string is also probably going to be a cause of unnecessary slow as gently caress slow down

# ? Apr 26, 2010 00:38

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 08:43

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

LockeNess Monster posted:

Yup. I was hired as RA for this project to implement some additional features, but now I am trying to rebel and convince them that most of the codebase has to be cleaned up and re-factored.

I mean most of the code in the rest of the project is on the level of what you see here.

In fairness, I'm not sure there exists a pretty way to write that one in C++.

code:

string WordDistribution::toUppercase( string check )
{
        for( size_t ii = 0; ii < check.length(); ii++ )
        {
                switch( check[ii] )
                {
                        case 'A':
                        case 'C':
                        case 'G':
                        case 'T':
                        case 'N':
                                break;
                        case 'a':
                        case 'c':
                        case 'g':
                        case 't':
                                check[ii] -= 0x20;
                                break;
                        default:
                                check[ii] = 'N';
                                break;
                }
        }
        return check;
}

# ? Apr 26, 2010 00:39

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 »