QUACK LIKE A DUCK

TYPING PART II

Cbachellam

Atlanta, GA

April  14, 2016

Introduction

Today’s blog post comes with bells, whistles and an announcement that, the underlying theme of all the posts in this blog is: “there is always a chasm between theory and practice, but a well essayed technical work can bridge this gap, and seamlessly connect the two disparate world, though the latter is a precursor”. Now let us get back to science, we are in the continuum of the second part, in the chain of posts about TYPING. (checkout my previous post about TYPING PART I). We left with the need for typing and definition of typing in the previous post. In this post, we plunge into nominal and structural typing.

Nominal-Typing Vs Structural-Typing Alias Duck-Typing

Predominantly all high level compiled languages are baked with the typing feature called as Nominal Typing, which means that -

“a fully qualified unique name/identifier of the class and its contract / interface (which specifies the behavioral features or methods the class ought to implement) are matched/compatible by the name against the instantiated objects”. - cc

This idea or notion of tying down the object instances against the names of class / interface is called Nominal Typing (Object Oriented languages like C#/JAVA/C++). To paraphrase the above definition: Having class names as part of the meaning of objects is called nominality [1]. Also according to Benjamin Pierce [2], “The fact that recursive types come essentially for free in nominal systems is a decided benefit [of nominally-typed OO languages]”. 

On the contrary if the objects are matched against the structural equivalence of the entities in comparison (there by avoiding the fully qualified name / nominal information), then it is called as Structural Typing. Also Structural Typing is commonly called as Duck Typing. 

“If it walks like a duck and quacks like a duck, it must be a duck.” - unknown

- what it means is an object need not be tied down to its class merely by name of its class / interface, rather than, a perfect or close to perfect harmony with its class’s fields / properties and methods is deemed as passable.

TYPESCRIPT Code Snippet for Structural / Duck Typing example

interface IVector2D {

    x: number;

    y: number;

}

interface IVector3D {

    x: number;

    y: number;

    z: number;

}

var vector: IVector2D = { x: 0, y: 10, }

var vector3D: IVector3D = { x: 0, y: 10, z: 20 }

function iTakePoint2D(vector: IVector2D) { /* do something */ }

iTakeIVector2D(vector2D); // exact match okay

iTakeIVector2D(vector3D); // extra information okay

iTakeIVector2D({ x: 0 }); // Error: missing information `y`

References:

1. Moez A. AbdelGawad.  An Overview of Nominal-Typing versus Structural-Typing in Object-Oriented Programming. 
2. Benjamin C. Pierce. Types and Programming Languages. MIT Press, 2002.

C# Sugary Syntax Rush

 Cbachellam

Tuesday, March 8, 2016

Atlanta, GA.

Setting the stage: 

Today we are satisfying our craving towards sugary syntax for complex structures in asynchrony in C#. Though we have dealt with asynchrony in JavaScript in previous blogpost, this blogpost ignites questions like, why do we need async / await keywords in C#, the genesis or under the hood internals of asynchrony, what are its marked strengths and advantages, also dispel the myth and fallacious thinking etc. These are questions which have been nagging me from the moment I was exposed to asynchrony in C# and hopefully will alleviate pain.

Asynchrony in C#:

Asynchrony has been there from get go(gecko). There is nothing unique about it expect syntactical sugars. In C# any long running activity like reading a large file I/O operation or waiting for high latency network I/O operation can lead to blocking the UI thread and the GUI hangs for the response. This lead to genesis of asynchronous processing; non UI blocking activity, which is the prime driver behind all this invention. We previously had asynchronous operations in Silverlight API’s, like in a real world instance, where the user interacted with the autocomplete suggestion text box which hung up for every alphabet the user typed in, trying to serially process the input and waiting for the response. To get around this, class: HTTPWebRequest’s special asynchronous method BeginGetResponse takes in a callback as a parameter. The callback is fired on successful completion of receiving the response. In other words, the UI thread continues to perform other activity and tangentially fires off the long running network I/O operation and on completion, calls the callback which updates the UI with the response data. This way the non-blocking UI thread is achieved. Please note that I would like to dispel the myth- this doesn’t improve the performance but on the other hand improves the responsive nature of the GUI without blocking the user interaction.

Now how can we connect the dots with async/await keywords in modern C#. Let’s say if we have a chain of asynchronous instructions which gets fired on completion of one after another. The code gets unwieldy, complex and convoluted. Imagine jumping from callbacks to callbacks, which is unreadable and soon becomes a coding nightmare. To get around this, C# came up with a sugary syntax, that kind of eliminated the chafe and logic callback hops that one has to go through in understanding and reading async code. 

Does async / await spawn a thread?

As described in the above discussion, any activity that doesn’t stop or block the main UI thread and fired off tangentially can be boldly claimed as asynchronous. But the question is does this tangential firing, spawn a thread. No it doesn’t. Async code doesn’t create a thread. But on the other hand it uses Thread Pool. 

vis-à-vis JavaScript

This I see a major difference between JavaScript and C# asynchrony. JavaScript is more along the lines of a single thread getting chopped for multiple asynchronous operations. On the other hand, C# async is reusing the threads from thread pool. Both are ultimately syntactic sugars and improve the responsiveness of the UI.

Digest on TYPE in Programming Languages- Part I

With intrinsic focus on Typescript
CbaChellam - January 24, 2016

Atlanta,Georgia.

Introduction

Today's blog post takes an aim and breaks down meticulously the TYPE in programming languages. As part of my curious research activities, i delved into a new open source language called as TYPESCRIPT. The more i dwell, i am starting to realize that there is more depth and dimension to it than just as a Transpiler. Please note that though the article talks about TYPE in programming languages in generic, it is also guided by the foundation of typescript.

What is Type in Programming Languages(PL)?

According to computer science, Type in languages means, a metadata that describes the kind of data stored in the designated memory location. This metadata can be of predefined primitive datatypes such as integer/float/string or an object (instance of a class). 

Why do we go for Typing?(Strongly Vs Weakly and Static Vs Dynamic Typed)

Strong typing doesn't allow mixing operations between mismatched data types. This allows to eliminate the runtime errors during static time or compile time. C# and JAVA are languages that support strong typing and hence static type checked. And Javascript is a weakly typed language and hence dynamically type checked. In languages like C#/JAVA a expression like this [1+”1”] yields a static error, pointing out that an explicit casting should fix the expression, like [1+(int)”1”=2]. On the other hand, weakly typed languages like Javascript, expression like [1+”1”] results in implicit casting of the right hand operand to int as 1, and yields a result as 2(integer). Though there are programming languages which have been allowing Gradual Typing, which means, parts of the program allow dynamically typed and other parts allow statically typed to coexist in the same language side by side.Typescript is one such language. Conversely, C# started as a statically typed language, but as of version 4.0 is gradually typed, allowing variables to be explicitly marked as dynamic by using the dynamic type.

Conclusion

Typescript is a superset of Javascript in the sense that the lacuna and frailty of javascript are amended in the super language. Javascript was never intended to be enterprise or industry ready, thats were features like gradual typing can bridge the gap and make it powerful. In the next coming series, we will take a look at Sub Type, Duck Type and Nominal Vs Structural Typing, again in the background of Typescript.

Through coding, we imitate god, which makes us not powerful but humble!