Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I never learnt anything about VB6 (and I dont want to) but I wanted to search for bad things in computer software, so my first though was VB6.

So for example, VB6 was strongly typed with late binding.

Makes some sense to have a language with that combination? (I dont think so).

I want to know reasons of why VB6 was like this! or why is good idea for a lenguage to be like this. Bad things that happend with a lengugage like this? good things?

share|improve this question
3  
After years of being forced to use vb6 I came to the conclusion that Variants cause more bugs than they prevent and omitting option explicit should be considered a capital crime. *8') –  Mark Booth Jun 21 '11 at 10:35
    
If you are searching for bad examples, use contemporary ones, not old ones. PHP comes to mind. That said, if weak typing is necessarily bad then isn’t C the prime example of it? –  Konrad Rudolph Jun 21 '11 at 11:18
    
Konrad I was asking also the examples you give me. I say VB6 as an example. I like to get an answer about strongly typed with late binding –  llazzaro Jun 21 '11 at 23:25
    
As an aside, you might want to make your question more neutral. Your first two sentences immediately classify strong typing with late binding as a bad thing. You're likely to get better answers if you don't presume this right off the bat. –  Greg Jackson Jun 22 '11 at 7:08
    
My favorite language, Common Lisp, is strongly typed with late binding. –  David Thornley Jun 22 '11 at 14:52
add comment

4 Answers

up vote 4 down vote accepted

Like the three primary .NET languages (C#, F#, and VB), VB6 was strongly typed with the option for early or late binding. Microsoft recommended using early binding, but late binding was offered for things similar to modern .NET reflection. Maybe a strongly typed language that's always late bound doesn't make a lot of sense to you, but throughout .NET, there are very good reasons why it's supported and used along with early binding.

share|improve this answer
2  
I like your answer. But could you explain more about the "very good reasons", thats the core of my question –  llazzaro Jun 21 '11 at 23:26
    
As I mentioned, reflection is the primary reason to use late binding. If you want to, for example, dynamically load an assembly that's defined in other code, a language needs late binding to support it. Without late binding, the compiler needs to have access to this external library to compile the code. This makes things like dynamically loading DLLs or graceful degradation impossible (I can't load this library, so use a less efficient or less accurate method, or display an error message instead of entirely blowing up). If you search for late binding, you can find tons of specific examples. –  Greg Jackson Jun 22 '11 at 6:59
    
Thanks Greg for add more info. I choose you answer. –  llazzaro Jun 25 '11 at 18:39
add comment

It made sense for vb6 because of the problem late binding solved: interfacing with unknown binary com objects at runtime. In that context, it makes sense.

share|improve this answer
add comment

VB6 supports compile time data types, early binding. However it also supports a Variant datatype which is essentially a type that is not known until runtime.

share|improve this answer
    
Even a runtime-enforced type system still qualifies as strong typing though. –  Konrad Rudolph Jun 21 '11 at 11:20
    
Jeff, you answer my question partially. What about lenguages strongly typed with late binding? –  llazzaro Jun 21 '11 at 23:29
    
To clarify, "compile time data types" describes early binding, not strong typing. These are two different attributes that often tend to be found together, but are quite different -- strong typing refers to what restrictions the compiler puts on intermixing datatypes (e.g. using an integer as a string, or vice versa). Early typing simply means that it knows what these types are at compile time. –  Greg Jackson Jun 22 '11 at 7:05
add comment

My opinion...unless you have a very strong necessity that requires late binding, which you can articulate, you should always use early (compile-time) binding. Also, I hate languages that are not strongly typed. Something just feels "wrong" about it. That is bias speaking, I am not prepared to make an academic argument for one side or the other.

share|improve this answer
    
I love late binding!!, polymorphism seems natural. I said that the combination is what I dont like! –  llazzaro Jun 22 '11 at 4:50
    
Maybe my understanding of the term "late binding" is incomplete. I guess what I was really thinking of was run-time type checking versus compile-time type checking. I agree polymorphism does seem natural. If you have a reference to an object or an interface that is a subset of a particular type I don't see anything wrong with that...I just hate how, like in javascript for example, you can declare a "var" and assign integer data OR string data to it, perform operations or makes calls against it that are invalid for some types, etc., and you don't get any complaints until execution. –  John Connelly Jun 23 '11 at 15:43
    
After some research, I don't believe that "early binding" excludes polymorphism, as your comment seems to indicate. –  John Connelly Jun 23 '11 at 15:46
    
check duck typing, this is what I trying to say that seems more natural. early binding dont excludes polymorphism –  llazzaro Jul 2 '11 at 5:07
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.