There are two major concepts in confusion: binding and loading. It is conflated by the concept of DataBinding, which is somewhere in the middle often doing both. After considering it, I am going to add one more concept, to complete the trifecta, dispatch.

Types

Late Binding: type is unknown until the variable is exercised during run-time; usually through assignment but there are other means to coerce a type; dynamically typed languages call this an underlying feature, but many statically typed languages have some method of achieving late binding

Implemented often using [special] dynamic types, introspection/reflection, flags and compiler options, or through virtual methods by borrowing and extending dynamic dispatch

Early Binding: type is known before the variable is exercised during run-time, usually through a static, declarative means

Implemented often using standard primitive types

Functions

Static Dispatch: known, specific function or subroutine at compile time; it is unambiguous and matched by the signature

Implemented as static functions; no method can have the same signature

Dynamic Dispatch: not a specific function or subroutine at compile time; determined by the context during execution. There are two different approaches to “dynamic dispatch,” distinguished by what contextual information is used to select the appropriate function implementation.

In single [dynamic] dispatch, only the type of the instance is used to determine the appropriate function implementation. In statically-typed languages, what this means in practice is that the instance type decides which method implementation is used irrespective of the reference type indicated when the variable is declared/assigned. Because only a single type — the type of the object instance — is used to infer the appropriate implementation, this approach is called “single dispatch”.

There is also multiple [dynamic] dispatch, where input parameter types also help determine which function implementation to call. Because multiple types — both the type of the instance and the type(s) of the parameter(s) — influence which method implementation is selected, this approach is dubbed “multiple dispatch”.

Implemented as virtual or abstract functions; other clues include overridden, hidden, or shadowed methods.

NB: Whether or not method overloading involves dynamic dispatch is language-specific. For example, in Java, overloaded methods are statically dispatched.

Values

Lazy Loading: object initialization strategy that defers value assignment until needed; allows an object to be in an essentially valid but knowingly incomplete state and waiting until the data is needed before loading it; often found particularly useful for loading large datasets or waiting on external resources

Implemented often by purposefully not loading a collection or list into a composite object during the constructor or initialization calls until some downstream caller asks to see the contents of that collection (eg. get_value_at, get_all_as, etc). Variations include loading meta information about the collection (like size or keys), but omitting the actual data; also provides a mechanism to some runtimes to provide developers with a fairly safe and efficient singleton implementation scheme

Eager Loading: object initialization strategy that immediately performs all value assignments in order to have all the data needed to be complete before considering itself to be in a valid state.

Implemented often by providing a composite objects with all their known data as soon as possible, like during a constructor call or initialization

Data Binding: often involves creating an active link or map between two compatible information streams so that changes to one are reflected back into the other and vice versa; in order to be compatible they often have to have a common base type, or interface

Implemented often as an attempt to provide cleaner, consistent synchronization between different application aspects (eg view-model to view, model to controller, etc.) and talks about concepts like source and target, endpoints, bind/unbind, update, and events like on_bind, on_property_change, on_explicit, on_out_of_scope

EDIT NOTE: Last major edit to provide description of examples of how these often occur. Particular code examples depend entirely on the implementation/runtime/platform

Anything that is decided by compiler while compiling can be refer to EARLY/COMPILE TIME Binding and anything that is to be decided at RUNTIME is called LATE/RUNTIME binding.

For Example,

Method Overloading and Method Overriding.

1) In Method Overloading your method calls to the methods are decided by the compiler in the sense that which function is going to be called is decided by your compiler at compile time. Hence being EARLY BINDING.

2) In method Overriding, it is decided at RUNTIME which method is going to be called. So it is reffered as LATE BINDING.

Tried to keep it simple and easy to get. Hope this helps.

Late binding is when behavior is evaluated at runtime. It’s necessary when you indeed want to determine how to act based on information you only have when the program is running. The clearest example in my opinion is the virtual function mechanism, specifically in C++.

class A
{
public:
    void f() {}
    virtual void g() {}
};

class B : public A
{
    void f() {}
    virtual void g() {}
};

int main()
{
    A* a = new B;
    a->f();
    a->g();
}

In this example,a->f() will actually call void A::f(), because it’s early (or statically) bound, and so the program at runtime thinks it’s just a pointer to an A type variable, whereas a->g() will actually call void B::g(), because the compiler, seeing g() is virtual, injects code to look up the address of the correct function to call at runtime.

if you are familiar with function pointers this would be an example.
Functions defined can be said to be Early binding .
whereas if you use Function pointers its late Binding.

  int add(int x,int y)
  {
    return x+y;
  }
  int sub(int x,int y)
  {
      return x-y;
  }


    int main()
    {
     //get user choice
     int(*fp)(int,int);
     //if add
      fp=add;
     //else if sub
     fp=sub;
     cout<<fp(2,2);
    }

here functions add and sub are functions (its address are binded at compile time-linker)

but the function pointer is late binding the fp can call either add or sub depending on user choice [at runtime].

Early and late binding only make sense in the context of types and not the way you are describing it. Pretty much all modern languages are typed in the sense that all values have fixed types. The difference comes in when we look at dynamically vs statically typed languages. In dynamically typed languages variables don’t have types so they can refer to values of any type and this means that when you call a method on an object referred to by some variable the only way to determine whether that call is valid or not is to look up the class for the object and see if that method actually exists. This allows for some cool things like adding new methods to classes at run time because the actual method lookup is deferred up until the very last moment. Most people call this state of affairs late binding.

In a statically typed language variables have types and once declared can not refer to any value that is not of the same type. This isn’t strictly true but lets assume it for now. Now if you know that the variable will only ever refer to values of a specific type then there is no reason to figure out if a method call is valid or not at run time because you can determine the validity before the code is ever run. This is referred to as early binding.

An example to demonstrate late binding in ruby:

a = 1 # a is an integer at this point
a.succ # asking for its successor is valid

class A
  def method_a
    # some code
  end
end

a = A.new
a.method_a # this is also valid
a.succ # this is not valid


class A # we can re-open the class and add a method
  def succ
    # some more code
  end
end
a.succ # now this is valid

The above sequence of actions is not possible in a language like Java where all types are fixed at run time.

Instead of giving you an academic definition I will try to show you some of the differences using a real world example using VBA:

Early binding:

Dim x As FileSystemObject
Set x = New FileSystemObject
Debug.Print x.GetSpecialFolder(0)

This requires a reference to be set to the “Microsoft Scripting Runtime” component at design time. It has the advantage that you get an error message already at compile time when you have a typo in FileSystemObject or method names like GetSpecialFolder.

Late binding

Dim x As Object
Set x = CreateObject("Scripting.FileSystemObject")
Debug.Print x.GetSpecialFolder(0)

This does not require a reference to be set beforehand, the instance creation and type determination will just happen at run-time. The compiler won’t complain at compile-time when you try to call a non-existent method of x, this will lead to a run-time error only when the specific line is executed.

So, the disadvantage of late binding is that you don’t have any strong type checking here. But that is also the advantage – let’s say you have a component where several versions exist, and each newer version provides some additional functions. (A real-world example are the MS Office components, like the Excel COM interface) Late binding allows you write code which works together with all of that versions – you can first determine the specific component version, and if you find out that you have only an older version available, avoid to execute functions calls which don’t work with that version.

Perhaps the most common example of late binding is resolving Internet URLs. It supports dynamic systems and large systems without trying to link and bind every site in the world before you can reach any, but on the other hand it does incur some overhead (DNS lookup, much less IP routing) at runtime.

By that light, most varieties of binding in language environments is more or less early, at compile time or link time.

Each kind has costs and benefits.