[AccessD] Interfaces

> I bring up Lisp and Smalltalk because they, in their day, were supposed
> to revolutionize the world with their dynamic flexibility -- but they
> didn't.
Yes, Ken,

And before that(?) it was Artificial Intelligence (AI), which was expected 
to solve all the problems...

What happens AFAIU is a natural evolution and as I was teached here on 
Marxists-Leninist Dialectics  (:)) lectures while in high school - 
evolution is based on "the unity and the struggle of the 
contrasts/differences". And evolution evolves as a spiral and from time to 
time the "law of denying the denying" (sorry for my English) rejects almost 
all the principles, which were the foundation of an "old school" theory and 
practice and returns the "good old" principles and makes them the foundation 
of the "new" theory and practice but on higher level of evolution spiral....

This is what happens in programming now IMO - SmallTalk and LISP were great 
but a way ahead their time to be effectively used for practical real life 
programming  - these days the nowadays practical challenges and the high 
level of the modern technology allow to "recall them from shadows" and 
effectively use and even go on higher level as Ruby (I'm not Ruby expert, 
even not a beginner - I only read about some of its principles and what it 
allows to do dynamically on run-time)...

> But, if you are prepared to shed preconceptions, the old wave can probably 
> do
> 95% of what the new wave can do.
Ken, IMO it can't solve the issues, which can be effectively solved only by 
Test Driven Development and Unit Testing - the latter is the "new school" 
and in general the new school programming languages can exist without almost 
any compile time binding.

Well, the pure "old school" can still do a lot but based on BDUF(Big Design 
UpFront) and intensive and expensive "old school" testing methods.

As I noted already - all depends on context - and I do agree that good old 
C++(its latest standard with STL etc.) together with TDD and Unit Testing 
can solve 95% of the modern challenges...

Shamil

----- Original Message ----- 
From: "Ken Ismert" <KIsmert at TexasSystems.com>
To: "Access Developers discussion and problem solving" 
<accessd at databaseadvisors.com>
Sent: Wednesday, March 29, 2006 11:29 PM
Subject: Re: [AccessD] Interfaces


>
> Shamil,
>
>>>I'd note all that below are "old school"
>>>definitions (beginning of 90ies)
>
> Yes, I admit that.
>
>>> ... COM and VB6/VBA, good but too inflexible ...
>>> ... late bound interfaces/run-time binding
>>> are in the same or even bigger favor ...
>
> Surprisingly, VB6/VBA is not fundamentally inflexible -- but the
> orthodoxy of how to use it is. Remove Option Explicit from your module
> header, and you can write code like:
>
> Public Sub Test()
>    a = "ABC"
>    b = 1234
>    Set c = CurrentDb()
>    Debug.Print a, VarType(a)
>    Debug.Print b, VarType(b)
>    Debug.Print c.Name, TypeName(c)
> End Sub
>
> Looking kind of dynamic, no? But how many times have the VB gods told
> you that this style of code was wrong? And VB has always had late bound
> interfaces/run-time binding using the Object type. In fact, it may be
> possible to do a decent implementation of run-time introspection and
> partial binding to foreign interfaces -- using VBA only, with no custom
> support DLLs/ActiveX required.
>
> My point is not to bash the new stuff -- it has its obvious merits. But,
> if you are prepared to shed preconceptions, the old wave can probably do
> 95% of what the new wave can do.
>
>>> ... Test driven development means that you tested
>>> all the interfaces by running unit tests ...
>
> That is the big problem with dynamic languages: verifiability. Thus, the
> emphasis on test-driven development in the dynamic Ruby and Python
> platforms. It is the latest attempt to bridge the chasm between
> static/inflexible/verifiable languages (C, C++, Java, ...) and
> dynamic/flexible/hard-to-verify (Lisp, Smalltalk, Python, Ruby).
>
> I bring up Lisp and Smalltalk because they, in their day, were supposed
> to revolutionize the world with their dynamic flexibility -- but they
> didn't.
>
>>> Ruby is the next challenge to MS C# and VB.NET...
>
> In terms of purity of concept, Ruby is it. For the time being, I'm going
> with Python, not because it is the 'ideal' language, but for purely
> practical reasons that I am not going to outline in this post.
>
> -Ken
>
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com