Visual Basic makes Baby Jesus cry [Archive] - SoonerFans.com Message Boards

mdklatt

1/29/2007, 07:29 PM

Dear Microsoft Overlords,

What you call a "Date" in Excel is called a "time" by the rest of the computing world (based on decades of Unix tradition, I imagine) or even better yet a "timestamp" because it is not just a date. Thus, confusion reigns when you have a DateValue function that returns what you call a "Date" but what the rest of us call a "date", i.e. just a calendar date. If you're going to be contrarian about naming your date types, at least be consistent. Why I should have to use both DateValue (which returns just the calendar date portion of a Date) and TimeValue (which returns just the clock time portion of a Date) to construct a complete Date (by your definition) is completely ****ing beyond me. To sum up, your DateValue function returns a Date as just a date, not a Date. **** me running.

And furthermore, why are the VBA versions of both of these functions more braindead than the worksheet versions which I'm not allowed to use for some reason?

Penguin

1/29/2007, 07:39 PM

You lost me at "Overlords."

soonerboomer93

1/29/2007, 08:23 PM

M$wned

slickdawg

1/29/2007, 08:45 PM

And you wonder why I just use shell scripts??

GottaHavePride

1/29/2007, 09:28 PM

Dear cockmaster who's responsible for the VBA debugger,

It's customary to indicate where an error actually took place so as to not send the programmer off on a wild ****ing goose chase.

:mad: :mad:
I find it hilarious that cockmaster escaped the profanity filters while **** gets censored. :D

landrun

1/29/2007, 10:37 PM

Try

Catch

Finally

If you don't understand that, then it's time to upgrade from VB6 to .Net. :D

skycat

1/30/2007, 12:01 AM

mdklatt is mad because he can't get a date.

landrun

1/30/2007, 09:24 AM

mdklatt is mad because he can't get a date.

Such is the life of a computer nerd. ;)

mdklatt

1/30/2007, 09:32 AM

And you wonder why I just use shell scripts??

Can you turn one of those shell scripts into an Exel add-in? :cool:

Vaevictis

1/30/2007, 09:36 AM

Can you turn one of those shell scripts into an Exel add-in? :cool:

See, there's your problem right there. You're trying to interface with Excel ;)

GrapevineSooner

1/30/2007, 02:26 PM

I love PHP.

NormanPride

1/30/2007, 02:33 PM

Putting code in a variable makes me happy.

mdklatt

1/30/2007, 04:53 PM

I love PHP.

That's crazy talk. Although it's certainly better than...shudder...Perl, and possibly VB.

Vaevictis

1/30/2007, 05:02 PM

That's crazy talk. Although it's certainly better than...shudder...Perl, and possibly VB.

Hey man, perl is great, as long as your need is to whip something up in 5-10 minutes and never ever ever ever EVER look at it again. :D

landrun

1/30/2007, 08:38 PM

PHP is a great language for its simplicity.
Perl, sucks. Just because of its lack of any decent debugging. (I know, then don't code any bugs! :D)
VB is nice.
But C# is even nicer.
ASP.Net has features that kick the crap out of PHP. Especially the postback feature.

SoonerInKCMO

1/30/2007, 10:22 PM

Perl, sucks. Just because of its lack of any decent debugging. (I know, then don't code any bugs! :D)

-w ain't good enough for ya? :texan:

mdklatt

1/31/2007, 04:10 PM

Dear Visual Basic Designers,

The redunant and retarded Java syntax for declaring objects is really not worthy of emulation. Nor is the idea of a type-nonspecific data structure. Java itself is unpleasant enough, but it's managed to crap all over other languages, too. Ugh.

Stoop Dawg

1/31/2007, 04:19 PM

It's possible to write solid code in any language.

It's possible to write **** code in any language.

The difference between good software and bad software is always the developer.

Always.

mdklatt

1/31/2007, 04:25 PM

It's possible to write solid code in any language.

VB sure makes it difficult.

This is just stupid:

Dim obj as Object
Set obj = New Object

Why the distinction between objects and "regular" variables?

Stoop Dawg

1/31/2007, 04:40 PM

Why the distinction between objects and "regular" variables?

I don't use VB, but there are definitely difference between objects and "regular" variables.

"Objects" are really just references (pointers) to structures in memory. "Regular" variables hold a value directly.

Variants (or untyped variables) are inefficient, but can be extremely useful (even necessary) in some circumstances.

I'm not backing VB - I've never used it (and never intend to). It's just my opinion that the quality of the programmer >> the quality of the language.

Vaevictis

1/31/2007, 04:43 PM

VB is nice.

I'm sorry, but this statement alone automatically invalidates any opinion you might have :D

mdklatt

1/31/2007, 04:59 PM

I don't use VB, but there are definitely difference between objects and "regular" variables.

"Objects" are really just references (pointers) to structures in memory. "Regular" variables hold a value directly.

If a "low level" language like C++ makes the difference transparent, why can't a scripting language like VB do it? I'm sure when OO was simply bolted on to VB a few years ago, they probably based the object model on the the "it" OO language at the time (Java). And thus, objects and "regular" variables must be treated differently by the programmer even for something as mundane as assignment.

landrun

1/31/2007, 05:55 PM

If a "low level" language like C++ makes the difference transparent, why can't a scripting language like VB do it? I'm sure when OO was simply bolted on to VB a few years ago, they probably based the object model on the the "it" OO language at the time (Java). And thus, objects and "regular" variables must be treated differently by the programmer even for something as mundane as assignment.

2 things...

1. I don't know how to use -w with Perl. :D

2. With .net an object is a reference type. Integers etc.. are simple datatypes.
Reference types are stored on the heap and the value types in the stack. Objects are reference types and are thus stored on the heap. You have to use the 'New' keyword for any object that is going to be stored on the heap. Which is where objects and classes go.

Vaevictis

1/31/2007, 06:00 PM

If a "low level" language like C++ makes the difference transparent, why can't a scripting language like VB do it?

Heh, it's only "transparent" if you ignore the subtle ways in which it will sometimes **** up if you forget that you're dealing with an object and not a data type. :D

EDIT:

For example:

int main()
{
TYPE a;
f(a);
}

If "TYPE" is a non-pointer data type, then you know from the code right there that you're passing by value; similarly, if "TYPE" is a pointer, you know you're passing by reference. If it's an object, you can't tell -- depending on how f() is declared, you could be passing by value or passing by reference.

Stoop Dawg

2/1/2007, 01:09 AM

If a "low level" language like C++ makes the difference transparent, why can't a scripting language like VB do it? I'm sure when OO was simply bolted on to VB a few years ago, they probably based the object model on the the "it" OO language at the time (Java). And thus, objects and "regular" variables must be treated differently by the programmer even for something as mundane as assignment.

I guess I'm not following you. What is it that you think should be the same? And what is transparent about C++ objects? Are you wondering why an object is not instantiated instantly when a reference to it is declared?

Dim cust as Customer

Are you thinking that statement should instantly create a Customer object?

Stoop Dawg

2/1/2007, 01:13 AM

For example:

int main()
{
TYPE a;
f(a);
}

Here's what I was talking about. Passing an uninitialized variable into a function named "f". It would be difficult to pack any more bad programming into 3 lines of code!

And yes, I realize it's an example. ;)

mdklatt

2/1/2007, 11:38 AM

I guess I'm not following you. What is it that you think should be the same? And what is transparent about C++ objects? Are you wondering why an object is not instantiated instantly when a reference to it is declared?

Why do all objects in VB (or Java or whatever else) have to be declared on the heap? And for what is supposedly a higher level language than C++, why should the programmer care about memory managment at all?

Dim cust as Customer

Are you thinking that statement should instantly create a Customer object?

It instantly creates an Integer, or a Double, or a String, so why not?

Stoop Dawg

2/1/2007, 12:13 PM

And for what is supposedly a higher level language than C++, why should the programmer care about memory managment at all?

... said the guys at Symatec.

Memory is still a scarce resource. Don't get me started on "garbage collection"! ;)

It instantly creates an Integer, or a Double, or a String, so why not?

Let's take a different example.

Dim iline as InvoiceLine

The InvoiceLine class probably contains an "Invoice" property. Following the proposed pattern of instantiating objects when they are declared, the Invoice object will be created when the InvoiceLine is created. The Invoice class probably contains a Customer property, so a Customer object will be created as well. The Customer may have Employer, Department, etc. properties. Since properties are just private variables all of these must be created when the object is created, which is when you declare a variable of that object type. You can see how inefficient this would be.

Additionally, consider this:

Dim line1 as InvoiceLine
Dim line2 as InvoiceLine

How do you make line1 and line2 reference the same Invoice object? The InvoiceLine class would have to carry a pointer to an Invoice object instead of an "object variable", otherwise every InvoiceLine object would reference it's own Invoice object.

There are probably techncal reasons as well, but the compiler and OS classes I took were 10+ years ago. If I learned anything relevant in them, it's outdated now.

You can, of course, use a struct instead of a class to get close to what you want. I think some languages are even allowing methods on structs these days - kind of a "lightweight" object, if you will.

mdklatt

2/1/2007, 02:02 PM

Don't get me started on "garbage collection"! ;)

That's exactly what I'm getting at. VB obviously uses a GC scheme inpsired by Java. When Java first came out, all the Java promoters said that C++ (their favorite target and biggest competetor) was yucky because it had...gasp...manual memory management. "Oh my God, you have manually deallocate memory? How barbaric!" Of course, in no time at all there was no shortage of advice in how to make the "automatic" deallocation in Java happen when you wanted it to happen. When you write a Java program you don't have to worry about deallocating memory--you just have to worry about cleaning up unused references so that JVM will deallocate the memory for you...when it feels like it.

This is some sample code I saw for using a VB Collection so that the "automatic" deallocation happens when you want it to happen:

Dim col as Collection
Set col = New Collection

(Why do I need a "Set" keyword here? The compiler knows 'col' is an object, so why do I have to tell it that? Silly.)

Dim obj as Object
obj = New Object
Call col.add(obj)
Set obj = Nothing

(Two things. Why do I need the Call keyword here? I don't need it to invoke methods on other objects? Secondly, I gather that setting obj to Nothing is so that the GC will know to clean it up. So much for "automatic" memory managment.)

I will say that this example code is suspect to me in terms of the author being any kind of "expert". I did this instead, which is seemingly a little cleaner:

Call col.add(New Object) ' no dangling references to worry about

Dim line1 as InvoiceLine
Dim line2 as InvoiceLine

How do you make line1 and line2 reference the same Invoice object? The InvoiceLine class would have to carry a pointer to an Invoice object instead of an "object variable", otherwise every InvoiceLine object would reference it's own Invoice object.

In C++ you can choose to use a reference or a pointer in that situation. You have no such choice in VB. Fortran is another good example of a language that doesn't burden the programmer with memory management at all, unless you explicitly ask for that burden.

Stoop Dawg

2/1/2007, 02:56 PM

When you write a Java program you don't have to worry about deallocating memory--you just have to worry about cleaning up unused references so that JVM will deallocate the memory for you

Exactly. The idea that a garbage collector eliminates the need for memory management is simply wrong. The programmer must always manage memory usage, either by explicitly allocating and deallocating memory (my preference) or by tracking all references throughout the app to be sure that memory can be deallocated when necessary (more difficult, IMO).

This is some sample code I saw for using a VB Collection so that the "automatic" deallocation happens when you want it to happen:

Dim col as Collection
Set col = New Collection

(Why do I need a "Set" keyword here? The compiler knows 'col' is an object, so why do I have to tell it that? Silly.)

Dim obj as Object
obj = New Object
Call col.add(obj)
Set obj = Nothing

(Two things. Why do I need the Call keyword here? I don't need it to invoke methods on other objects? Secondly, I gather that setting obj to Nothing is so that the GC will know to clean it up. So much for "automatic" memory managment.)

I'm not familiar with VB, so I don't have any idea what "call" is doing. However, I will say that the object created by that code will absolutely NOT be garbage collected. It's still referenced by the collection (unless "call" is doing some kind of weak-reference type thing).

I will also say that C# allows you to do this:

Collection col = new Collection();
col.Add(new Object());

I believe such shortened notation may be available in VB.Net. (e.g. Dim col as new Collection()). The only real difference between this and what I think you're looking for is the use of the "new" keyword.

In C++ you can choose to use a reference or a pointer in that situation. You have no such choice in VB. Fortran is another good example of a language that doesn't burden the programmer with memory management at all, unless you explicitly ask for that burden.

If you're doing "real" OOP, I would say that situation is the norm. If your classes are really just collections of related simple data types, then structs are probaby a better choice.

mdklatt

2/1/2007, 04:06 PM

However, I will say that the object created by that code will absolutely NOT be garbage collected. It's still referenced by the collection (unless "call" is doing some kind of weak-reference type thing).

You don't want the object to be GC'd while it's in the collection, obviously, but if you don't remove the temporary reference the object won't go away even if you remove it from the Collection.

I will also say that C# allows you to do this:

Collection col = new Collection();
col.Add(new Object());

That appears to work for the older version of VBA I'm using as well. I don't why the CodeGuru (my ***) example creates an extra Object.

I believe such shortened notation may be available in VB.Net. (e.g. Dim col as new Collection()). The only real difference between this and what I think you're looking for is the use of the "new" keyword.

Initializion during declaration would be an improvement, but I still think the New syntax is redunant. Every object has to be New'd, so why does there need to be a specific keyword for that? It's like the Set keyword. Every time I forget to use it, the compiler gives me an error. If the compiler already knows everywhere I need to use it, why do I need to use it??

If you're doing "real" OOP, I would say that situation is the norm.

If you're doing real OOP you can also have every object take care of it's own resource allocation with constructors and destructors so you don't have to worry about it. :)

Stoop Dawg

2/1/2007, 04:26 PM

You don't want the object to be GC'd while it's in the collection, obviously, but if you don't remove the temporary reference the object won't go away even if you remove it from the Collection.

Correct. However setting the temp reference to null (or Nothing) isn't necessary so long as that reference goes out of scope. I think we agree that GC sometimes makes memory management MORE difficult.

Initializion during declaration would be an improvement, but I still think the New syntax is redunant. Every object has to be New'd, so why does there need to be a specific keyword for that? It's like the Set keyword. Every time I forget to use it, the compiler gives me an error. If the compiler already knows everywhere I need to use it, why do I need to use it??

Re "new": I need to be able to declare references (pointers) without creating objects. Sure we could go back to the pointer syntax of C++, but by making all object references pointers they have eliminated much of the confusion surrounding use of pointers (IMO, of course). Also, if "new" weren't required, what would the following code do:

Dim cust1 as Customer
Dim cust2 as Customer
set cust1 = cust2

Re "set": The "set" keyword comes from the confusion surrounding assignment vs comparison in "C". The "=" operator has double meaning, so the "set" keyword is used to remove confusion. Other languages simply removed the double meaning of "=" (pascal uses ":=" for assignment and C# uses "==" for comparison).

If you're doing real OOP you can also have every object take care of it's own resource allocation with constructors and destructors so you don't have to worry about it. :)

And how, exactly, does an object take care of it's own resource allocation if the language is handling it for you? For example:

public class CustomerClass
{
public DepartmentClass Department;
}

The CustomerClass can't control memory allocation because you've changed the language to allocate memory for the Department as soon as a Customer is created. The only way around it would be to use pointers - which is what we've already got.

mdklatt

2/1/2007, 05:02 PM

Re "new": I need to be able to declare references (pointers) without creating objects. Sure we could go back to the pointer syntax of C++, but by making all object references pointers they have eliminated much of the confusion surrounding use of pointers (IMO, of course). Also, if "new" weren't required, what would the following code do:

Dim cust1 as Customer
Dim cust2 as Customer
set cust1 = cust2

If it was C, C++, or Fortran it would create a new object. If you want a pointer/reference you explictly delcare the variable that way.

Class c; // create a new instance of 'Class'
Class& ref(&c); // create a Class reference that points to c
Class* ptr(new Class); // create a pointer to a new Class instance

Re "set": The "set" keyword comes from the confusion surrounding assignment vs comparison in "C". The "=" operator has double meaning, so the "set" keyword is used to remove confusion. Other languages simply removed the double meaning of "=" (pascal uses ":=" for assignment and C# uses "==" for comparison).

C isn't the source of that confusion; the equality operator in C and C++ (and Java, too, IIRC) is "==". VB (going back to BASIC) uses the "=" for both equality and assignment. This is the formal syntax for assignment in VB (again, going back to its BASIC roots):

Let a = 3

However, the Let keyword is optional. The syntax for assignment of a pointer (i.e. object) replaces the Let keyword with the Set keyword (which is not optional):

Set obj = New Object

Why does there need to be a seperate syntax? The compiler already knows obj must be a reference and not a regular variable, so why do I have to tell it that? I want to assign this to that--you're the compiler, you figure out how to do it.

And how, exactly, does an object take care of it's own resource allocation if the language is handling it for you?

I was talking about C++. Using the constructor to allocate memory and the destructor to release it gives you truly automatic memory handling. The container classes in the C++ Standard Library do this, so you rarely have to mess with memory management at all.

Stoop Dawg

2/1/2007, 05:51 PM

Class c; // create a new instance of 'Class'
Class& ref(&c); // create a Class reference that points to c
Class* ptr(new Class); // create a pointer to a new Class instance

It appears that you can learn from this board after all! ;)

So VB and C# (and Object Pascal) all use the "reference model" and don't allow the "object variable" model. C++ allows both. To me, it's not a big deal to say "Class c = new Class()". A little more typing, to be sure, but I actually prefer a slightly more verbose language.

C isn't the source of that confusion;

You are, of course, correct.

I was talking about C++. Using the constructor to allocate memory and the destructor to release it gives you truly automatic memory handling. The container classes in the C++ Standard Library do this, so you rarely have to mess with memory management at all.

Hmmm. So in order to use object references in C++ you must use some crazy-assed pointer syntax all over the place? No wonder people are leaving it in droves. ;) ;)

How does C++ handle the construct below?

public class CustomerClass
{
public DepartmentClass Department;
}

Is the memory for "Department" allocated when the CustomerClass object is created? Or do you have to explicity create a Department object in the constructor of CustomerClass? If the later, how is this done given that the property is not declared using the aforementioned pointer syntax?

mdklatt

2/1/2007, 11:09 PM

I actually prefer a slightly more verbose language.

Give Fortran a try. ;)

Hmmm. So in order to use object references in C++ you must use some crazy-assed pointer syntax all over the place? No wonder people are leaving it in droves. ;) ;)

Actually, except for the declaration, reference syntax is no different than "regular" syntax. Hower, just like pointers, references are more efficient to pass around and give you polymorphism. The main functional difference between a reference and a pointer is that a reference can't be null.

void f(Class c) // local variable
{
c.do_something(); // local copy, no polymorphism
}

void f(const Class& c) // reference
{
c.do_something(); // polymorphic, no copying
}

void f(const Class* c) // pointer
{
c->do_something(); // polymorphic, different syntax
}

How does C++ handle the construct below?

public class CustomerClass
{
public DepartmentClass Department;
}

Is the memory for "Department" allocated when the CustomerClass object is created? Or do you have to explicity create a Department object in the constructor of CustomerClass? If the later, how is this done given that the property is not declared using the aforementioned pointer syntax?

As written, that will create an instance of DepartmentClass with the same scope as the CustomerClass variable. If you want to explicitly control the lifetime of of DepartmentClass you need to use a pointer.

class Customer
{
public :
Department* m_dept;
Customer() : m_dept(0)
{
// constructor
m_dept = new Department;
}

~Customer()
{
// destructor
delete m_dept;
}
}

This will give m_dept the same lifetime as it's parent object. This is a trivial example, of course, because declaring m_dept as a local variable instead of a pointer has the same effect.

Norm In Norman

2/1/2007, 11:32 PM

You guys are cracking me up.

I love people who think their language is better than all the others. The fact of the matter is, every language has similarities and differences and every language was created for a specific purpose. For instance, way back when it might take weeks to create a GUI windows app in MS's C++ while it would only take hours to write the same app in VB. The VB app would be slower and use more memory, but you don't use it to do really complex stuff so it doesn't matter. Likewise, try loading a 1million record sequential file into java, do some business logic, then write a report. You can do this a TON easier in COBOL and it would run in so much less time you'd have time to learn another language while you were waiting. You probably aren't going to stick that report into a pdf using COBOL though.

Oh, and I'm pretty sure VB came out before java and .net was MS's answer to java not vb6. They actually want you to use c# and not vb.net.