Ever since I came across types in C#, as in “strongly typed”, I have been hooked to them!

The idea of “type safety” so intrigued me that the intrigue actually helped me in understanding generics as implemented in C# (which, for me, has the best implemented generics among all the modern, strongly-typed languages) better and then, I discovered generics in Typescript, a scripting language, that made it even more exciting and extended my fascination for template types more!

The excitement opened some newer avenues in my understanding of generics in the form of, for example — How solid is SOLID
and Generic type constraints

The latter, ie. the latter article on Typescript Generics, serves my purpose in writing this article more specifically. It is about type inference that happens in compile time on template parameters.

Bjarne Stroustrup calls “lousy interfaces” as “Duck typing” in his “Concepts: The Future of Generic Programming” whitepaper but then, all interfaces, as in OO languages, are bound to be duck-typed because there is no way (ignoring the “psst, Java can”) that a Predicate can be set on an interface.

The purpose of the links to my blog and to Stroustrup’s whitepaper is not to educate the reader on templates and generics or on duck typing but to highlight a core aspect in modern (modern as in post-modern!) software programming, which is testability.

“Post-modern” because, before the advent of the test driven development (TDD) paradigm, developing a functionality was more important than how the functionality would get developed! Meaning that getting the feature/software delivered to market (production) faster was more important than how the feature/software would get developed/maintained or scaled (or rather, would be, if scaled)!

It is only with the wide acceptance of Agile and Lean practices, in that specific order, did the importance of testability of code that is written began to gain importance. I mention this with such firmness because I want to highlight the emphasis that Stroustrup brings to the word “predicate” in his whitepaper.

Before getting into how Stroustrup uses predicate to describe his predicament with templates, it is important that I deviate a little and highlight the role of testing across the modern, post-modern and the Agile onto the digital world of seamless platform and device integration needs.

Earlier, before TDD ie., the compiler acted as a tester — a tester of syntax, semantics and the likes.

As software development began to address more complex needs, the complexity in implemented programming logic, too, grew, resulting in some parts of the code that could not be asserted well enough by the compiler because the complex logic could result in run-time failures or exceptions! So, the need for full-fledged, specialized test tools and testers grew.

The complexity in programming logic was caused due to a system interacting with other systems and so the run-time references needed to be tested thoroughly before allowing them to run in production. That is, functionalities that would get known to the executing code only at run-time.

So, strictly in the context of template types as in generics programming, and using the example that I used in the Typescript generics post,

interface DiscreteLinearOrder<T> {
next:()=>T;
lessThan(y:T):Boolean;
}
export class DLOnumber implements DiscreteLinearOrder<number> {

let me explain.

Although the class implements the T as a number (or, will specialize the T at run-time), it still leaves one ambiguity, you can never be sure if it is iterable to execute the next() interface function successfully at run-time (using it for brevity sake. The valid argument would be that if the class implements IEnumerable and derives the enumerable properties from that interface then there is no issue but how to enable a characteristic for an object is not the context)!

This is why I provided the reference to Stroustrup’s whitepaper because it has an example that inspired me to write this post.

The old favorite of mine, the Shape class!

I used to do many a training on generics in and around 2005 on this fabulous OO object because it seems to forever have something new for me so much so, that someone actually quipped as to why I obsessed over C# generics when we are all working on C++! But don’t let me mislead you, keep your focus on Stroustrup’s whitepaper.

In the whitepaper, Stroustrup talks about a Cowboy and a draw() function.

Typically, the draw() method in a Shape class would get a hint (as in a parameter) on what it is to draw and since the Cowboy, too, can draw (a gun, that is), the ambiguity would be, you can imagine it too, in the confusion for the Cowboy — whether to draw the gun ie. draw the shape of a gun or to draw the gun from the holster!

To extend the ludicrousness in the example, without it becoming too comedic, the cowboy could probably draw a square or a rectangle saddled in the horse, with the help of the horse’s hoofs but, practically speaking, the Cowboy would be expecting to be given the power to draw a gun from his or her hip holster and fire the gun than resort to something that could happen only in a computer graphics game created by a person who did not know what a Cowboy actually does!

So, to get back from the aside, I would say that even a predicate, as in concepts — Stroustrup’s concepts, if you have read that whitepaper by now — would not help because even the “drawable” capability would not suffice because the Cowboy’s need to draw() is different from a Shape’s need to draw()!

Now, this is the point on which I wanted to draw (quite a play of words, this article has become!) a parallel with testing ie. testability.

For me, the thumb rule that defines Agile, for what it stands for, is this — if a functionality or a feature is not testable then it is not worth developing and this stands good in terms of business, too!

If you cannot test whether a tweet can be tweeted from Space then it should not be developed unless, of course, if you are Elon Musk.

But, to get back to the subject of asserting the ability of an object, the ability to assert whether two different entities in two different domains can have the same functions is possibly rare in real-world (or rather, in real software terms) because all those abstractions have already happened as software development evolved over the last decade but Artificial Intelligence (AI), and Robotic Programming (RP) to some extent, definitely pose this problem — AI more than RP because with AI everything is in a double represented form due to the virtual environment of the domain itself!

So,

test(this test)

actually depends on whether this test is testable in the first place!

Now, this is not a play of words because, in the digital world of AI (or Machine Learning, if you will), the doability is extremely representative because everything happens in a “virtual” sphere of execution and the executing code does not have any means to differentiate itself in terms of domains!

That is, AI could easily make a Cowboy draw(square) and make a Shape draw(Colt) because, for all practical purposes, a predicate could possibly never get established in the tests!

Or maybe, it might all sound better if instead of “duck typing”, “lame duck typing” were used to describe it!

I am an Agile software professional/architect/consultant/coach. I like listening to music, watching English movies/plays, playing chess & reading.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store