The Daily WTF: Curious Perversions in Information Technology

2009-12-21 Reply Admin

I know of a very valid reason for declaring the arguments as variants: nulls. The only way to represent a nullable value without writing your own struct of sorts is to use a variant.

Further, it was possible to create classes in VB6 which obviously would have been the preferred solution. (Although the types of the properties would have to be variants to allow for nulls). That said, creating COM classes in VB6 was its own little slice of heaven.

Someone suggested building a class, but that seems kind of dumb to me, the constructor would be just as unwieldy and each attribute would have to be referenced individually, so surely there is a better solution to this, right?

In VB6, that isn't even possible and in languages where it is, it is not the preferred method. It would be better to simply have properties on the class and let the code that consumes the class determine if the property values needed to perform its operation have the proper values. That said, the big problem with altering your class definitions is that you can get COM issues.

2009-12-21 Reply Admin

Coyne:
Tzimisce:
Maybe the developers wanted to get "n-tier architecture" on their resumes.

Hey, can I get an n-tier architecture on my resume with this?
  static boolean equal(int a, int b)
  {
    //Annoying me 297 times to say: return a != b;
   }
"My tiers are deeper than your tiers!"

Yes; the trick in the technical interview will be ducking at the right time to avoid being stabbed in the head.

2009-12-21 Reply Admin

Gross, but it was the way it was ... back in the day.

It totally looks like Classic ASP.

You have to remember that the only way to remote objects was to use DCOM. You couldn't just declare objects and expect it to work all the way through all the layers. If you were really smart maybe you could get it to work, but DCOM was pretty buggy and a b*tch to get working, not to mention slow. When you add the best practice of a stateless service layer, you also need a very chunky API (as opposed to a chatty one).

The hungarian notation isn't even that much of a wtf when you are looking in the past. Annoying, but how else do you deal with a language where everything is a variant when communicating via COM.

So all things considered, the only wtf is the name of the function indicating the method will use some Xml somewhere (i.e. the caller doesn't care how the method calls the layer below, or at least shouldn't).

2009-12-21 Reply Admin

Mmmph:
Gross, but it was the way it was ... back in the day.
It totally looks like Classic ASP.

You have to remember that the only way to remote objects was to use DCOM. You couldn't just declare objects and expect it to work all the way through all the layers. If you were really smart maybe you could get it to work, but DCOM was pretty buggy and a b*tch to get working, not to mention slow. When you add the best practice of a stateless service layer, you also need a very chunky API (as opposed to a chatty one).

The hungarian notation isn't even that much of a wtf when you are looking in the past. Annoying, but how else do you deal with a language where everything is a variant when communicating via COM.

So all things considered, the only wtf is the name of the function indicating the method will use some Xml somewhere (i.e. the caller doesn't care how the method calls the layer below, or at least shouldn't).

Forgot also to mention that the web layer never communicates directly with the database, and many shops (rightly) dictate the database must use stored procedures (you gals have heard of sql injection attacks i gather)

2009-12-21 Reply Admin

I'm really not seeing the inherent WTF of functions that call other functions and, you know, reuse code. That would normally be a success story.

2009-12-21 Reply Admin

Duke of New York:
I'm really not seeing the inherent WTF of functions that call other functions and, you know, reuse code. That would normally be a success story.

Try reading the comments to the article if you need a hint.

hoodaticus · 2009-12-22 Reply Admin

Mmmph:
Gross, but it was the way it was ... back in the day.
It totally looks like Classic ASP.

You have to remember that the only way to remote objects was to use DCOM. You couldn't just declare objects and expect it to work all the way through all the layers

Dude, not only is this VB6, but its caller and its caller's caller are also VB6.

What part of the strongly-typed code indicated to you that this was classic ASP?

2009-12-22 Reply Admin

It is much too easy for stored procedures just to call other stored procedures. First with professional Databases like postgres you can write stored procedures in different languages. Off course C would be a natural choice, but it is best complemented with perl and python.

Second (and much more important): Those other languages could call other libraries, which in call could call other libs, which could call ..., which could call ... ... a stored procedure!

pure pleasure!

Watson · 2009-12-22 Reply Admin

Joey5337:
It is much too easy for stored procedures just to call other stored procedures. First with professional Databases like postgres you can write stored procedures in different languages. Off course C would be a natural choice, but it is best complemented with perl and python.
Second (and much more important): Those other languages could call other libraries, which in call could call other libs, which could call ..., which could call ... ... a stored procedure!

pure pleasure!

You forgot PHP. Yes; Postgres stored procedures written in PHP. And deep down in the guts of that PHP stored procedure.... "$conn=pg_connect('dbname=foo');"

2009-12-22 Reply Admin

and then you have to write a structure / class that simply has a lot of properties or a large constructor that has the same problem and adds more operations and maintenance headaches unnecessarily.

objects simply to pass data from one object to another with no processing are a bad idea.

the only real problem with this is that it is not strongly typed. the point is that it points to the huge amount of spaghetti and type misuse that will follow.

2009-12-22 Reply Admin

Who wrote this obscenity is just a minion: the blood is on the hands who wrote VB in the first place. Such a curse they cast upon humanity. We all are doomed. Praise thy ruby and thou will be saved.

2009-12-22 Reply Admin

nostradamus:
Who wrote this obscenity is just a minion: the blood is on the hands who wrote VB in the first place. Such a curse they cast upon humanity. We all are doomed. Praise thy ruby and thou will be saved.

I'm slightly confused as to which Ruby to praise.

Ruby - the programming langage ?

Or Ruby - the codename for the project which begat Visual Basic ?

What a beautiful day for throwing a bucket of water over a soothsayer and pointing out he didn't predict that...

2009-12-22 Reply Admin

Bim Job:
frits:
Bim Job:
frits:
Zylon:
frits:
So replace "Long Parameter List" code smell with a variation of the "Large Class" smell. Why not just declare a bunch of global variables and refactor with the "accumulate and fire" anti-pattern ?
Awww cute, someone just read that refactoring book.

Awww cute, someone's sticking up for his pal.
Awww, cute, someone's decided to duck the issue via an ad hominem attack.

Does your brain work properly? Do you think calling something an "anti-pattern" is an endorsement?

Bad code is bad.
I'm sorry, I must have mistaken your comment (in bold) for some sort of offensive brain-damaged response to another poster.

FTFY.

2009-12-22 Reply Admin

hoodaticus:
Try reading the comments to the article if you need a hint.

Yeah, I read them.

I've worked on systems where rows were inserted by a stored procedure that had to do validation checks on the inserted data.

The same validation checks were also used by other public stored procedures so (guess what) the insert procedure called into subroutines, and other procedures also called those subroutines.

It's not a WTF.

2009-12-22 Reply Admin

Mmmph:
Mmmph:
Gross, but it was the way it was ... back in the day.
It totally looks like Classic ASP.

You have to remember that the only way to remote objects was to use DCOM. You couldn't just declare objects and expect it to work all the way through all the layers. If you were really smart maybe you could get it to work, but DCOM was pretty buggy and a b*tch to get working, not to mention slow. When you add the best practice of a stateless service layer, you also need a very chunky API (as opposed to a chatty one).

The hungarian notation isn't even that much of a wtf when you are looking in the past. Annoying, but how else do you deal with a language where everything is a variant when communicating via COM.

So all things considered, the only wtf is the name of the function indicating the method will use some Xml somewhere (i.e. the caller doesn't care how the method calls the layer below, or at least shouldn't).

Forgot also to mention that the web layer never communicates directly with the database, and many shops (rightly) dictate the database must use stored procedures (you gals have heard of sql injection attacks i gather)

Yes, you can simply declare objects and have them work all the way through the layers. DCOM was only needed to go across the network. Even then, it was easy. Just use the Component Services tool to build a proxy and install it on the next tier forward. Also, COM doesn't require everything to be a variant. Heck, COM was first implemented in C, not VB, so the whole idea of variant is not baked into COM. Finally, it's easy to build a stateless, single-trip API using DCOM and make it fast. VB even has a function (well, part of the MTS component) that tell Microsoft Transaction Server to dump the object state(SetComplete).

Also, stored procedures are neither necessary nor sufficient to protect against SQL injection. If you use stored procedures, but build the call with string concatenation, you will be just as naked against injection as someone who uses bare string concatenation. It's string concatenation you need to avoid.

2009-12-23 Reply Admin

jsmith:

Also, COM doesn't require everything to be a variant. Heck, COM was first implemented in C, not VB, so the whole idea of variant is not baked into COM.

A Varient is basically an XLOPER, so I guess it was sort of first implemented in assembler, not C, but the variant appeared when COM automation was built in Excel Basic.

http://www.vergentsoftware.com/blogs/ckinsman/HowToBeAProgramManagerByJoelSpolsky.aspx

Basic had to get some kind of dynamic types, but I wasn't smart enough to figure out how to do that. Didn't matter. Tom Corbett, a programmer on the Visual Basic team, figured out how. And thus Variants and IDispatch were born, and Basic became a dynamic language

2009-12-23 Reply Admin

hoodaticus:
What the OP's WTFer did - storing the raw data on the stack as a huge number of arguments to a function - is a WTF. The whole thing comes crashing down if you run out of stack space. And what happens if he has to add new data to insert/update? Oh well, re-write the function! Using a few classes would let the system be much more flexible than this trainwreck. If the OP's WTFer was using OOP all along, then he never would have amassed 17 arguments in a function... his solution would have tended towards much more elegance.

O Gosh no, not that hoary old myth "more efficient to just use a pointer". I write embedded code where I count the size of the stack, and quess what: when you create the local object to pass to the remote function, it gets created on the local stack.

And WTF, when you need to add new data to the insert/update, you have to re-write the class. That is, add new data members. Well, that was a huge saving of labour, wasn't it?

Look, I'm just as much in favour of the One True Style as the next man, but let's remember: in the end what the workers got from the Marxist dielectic was jam tommorow

hoodaticus · 2009-12-23 Reply Admin

Martha:
hoodaticus:
What the OP's WTFer did - storing the raw data on the stack as a huge number of arguments to a function - is a WTF. The whole thing comes crashing down if you run out of stack space. And what happens if he has to add new data to insert/update? Oh well, re-write the function! Using a few classes would let the system be much more flexible than this trainwreck. If the OP's WTFer was using OOP all along, then he never would have amassed 17 arguments in a function... his solution would have tended towards much more elegance.

O Gosh no, not that hoary old myth "more efficient to just use a pointer". I write embedded code where I count the size of the stack, and quess what: when you create the local object to pass to the remote function, it gets created on the local stack.

And WTF, when you need to add new data to the insert/update, you have to re-write the class. That is, add new data members. Well, that was a huge saving of labour, wasn't it?

Look, I'm just as much in favour of the One True Style as the next man, but let's remember: in the end what the workers got from the Marxist dielectic was jam tommorow

You're right, my bad, code should be b.f. ugly.

Addendum (2009-12-23 12:52): BTW - You would not necessarily have to re-write the class simply because the schema changed or something. It depends on what kind of schema-type information is being provided to/ discerned by the object in the first place.

I've written more than one object model that updates a data store and does not need to have the class re-written just because the schema changes and new types of information are being stored. Incidentally, you can't do that if each field is being passed as a separate argument in some fugly function.

2009-12-23 Reply Admin

Katana:
Shriike:
Someone suggested building a class, but that seems kind of dumb to me, the constructor would be just as unwieldy and each attribute would have to be referenced individually, so surely there is a better solution to this, right?

Yes, but in VB you could make it very clear as in dim x as new XMLShipment() WITH x .Property1="whatever" .SomeOtherBit = "dude" .FileNotFound = IsBooleanTrue(false) END WITH

and it would be very clear to someone who later had to read the code what you were stuffing all those values into, as opposed to just having 40 lines of code setting values that have no obvious relationship to one another.

In VB you could make it very clear: InsertXMLShipment( _ GMImportId_fk := 1000, _ nShpId := 2007, _ nShpConConsigneeId := 3, _ nShpConShipperId := 7, _

Using a simple function call, you can test the call from an Excel spreadsheet: but it's the thin end of the wedge if you let users do user requirement testing.

2009-12-23 Reply Admin

Cumquat:
jsmith:

Also, COM doesn't require everything to be a variant. Heck, COM was first implemented in C, not VB, so the whole idea of variant is not baked into COM.

A Varient is basically an XLOPER, so I guess it was sort of first implemented in assembler, not C, but the variant appeared when COM automation was built in Excel Basic.

http://www.vergentsoftware.com/blogs/ckinsman/HowToBeAProgramManagerByJoelSpolsky.aspx

Basic had to get some kind of dynamic types, but I wasn't smart enough to figure out how to do that. Didn't matter. Tom Corbett, a programmer on the Visual Basic team, figured out how. And thus Variants and IDispatch were born, and Basic became a dynamic language

So, VB got variant from COM, not the other way around. VB needed variant to bind to a COM interface that wasn't known at compile time. None of this suggests that COM is inherently late bound.

2009-12-23 Reply Admin

code like this often reflects thinking like this.... and an environment where management is incurably random, you have to codeify a process that's almost impossible to explain or understand, hence you end up with code that is almost impossible to explain or understand.... Alot of this was probably added at the last minute....

rosko · 2009-12-24 Reply Admin

dsckeld:
Well, to me it just looks as if the dll in question were called by some VBScript from an ASP page. What's wrong with that?
It might look a little unwieldy, but would you rather make 1 insert call and a lot of update calls or maybe pass an array of unchecked values down to the database level?

(I am fairly sure that objects (like real Objects) were out of the question at the time.)

(second attempt)

No, you could certainly have either public members or properties on your VB6 classes and set them from ASP. And how is a huge list of unchecked (assumption!) variants any better or worse than an array of variants?

Oh, and the article specifies that this was VB6 <==> VB6 <==> VB6; ASP may have made the original call to the VB6 (COM+?) service, but everything else is VB6.

KattMan:
The only problem with the "representative line" is the fact that they are all variants, strongly type them.

Except that to pass in a Null, you would need a type that can be set to Null -- which in VB6 means Variant.

matthewr81:
If I remember right, ASP (VB6 style) all variables are variants, so any VB6 interfaces have to define variable as variants.

True, but the VB6 (or other COM) methods the ASP calls can certainly use any of the standard COM types, including strings and integers and doubles. But see above regarding Nulls and variants, and again... it's being called by VB6, not ASP.

2009-12-27 Reply Admin

This looks to me like Pitney Bowes' SendSuite.

That software is nothing but a huge monstrosity of a WTF.

2010-01-02 Reply Admin

Gee, and people say Cobol is verbose!

2010-01-07 Reply Admin

Mmmph:
Mmmph:
Gross, but it was the way it was ... back in the day.
It totally looks like Classic ASP.

You have to remember that the only way to remote objects was to use DCOM. You couldn't just declare objects and expect it to work all the way through all the layers. If you were really smart maybe you could get it to work, but DCOM was pretty buggy and a b*tch to get working, not to mention slow. When you add the best practice of a stateless service layer, you also need a very chunky API (as opposed to a chatty one).

The hungarian notation isn't even that much of a wtf when you are looking in the past. Annoying, but how else do you deal with a language where everything is a variant when communicating via COM.

So all things considered, the only wtf is the name of the function indicating the method will use some Xml somewhere (i.e. the caller doesn't care how the method calls the layer below, or at least shouldn't).

Forgot also to mention that the web layer never communicates directly with the database, and many shops (rightly) dictate the database must use stored procedures (you gals have heard of sql injection attacks i gather)

Obvious troll is obvious. And retarded.

HTMLCoder.exe · 2010-12-26 Reply Admin

Cue obligatory Yo Dawg joke.

The Matryoshka Method

Leave a comment on “The Matryoshka Method”