Skip to main content

Concept is more important than Programming language constructs

    Programming languages are evolving faster in the Information Age. The rapid growth in the language features and new Programming languages being introduced in the market is overwhelming. It is difficult to keep up with this pace. Moreover organisations like Oracle which adopted 6 months release cycle using Agile process has given us very little time to learn new things and establish our stronghold. When I went through few of these Programming languages I found the usual pattern that conceptually they are very similar only the Programming construct is different. Hence I believe the concept is more important than Programming language construct.

    Let's take an example of Groovy and Java 8. Both of these languages have the concept of lambda but the programming construct is different. In Groovy Programming language they call it Closure and in Java 8 they called it Lambda. The concept is same to pass code as an argument. The concept of code as an argument is to extract the reusable code or extracting change from the constant.

Groovy Closure vs Java 8 Lambda Constructs

     Above image shows how the way we could write the code is Groovy vs Java. In case of Groovy the curly braces are wrapping the entire code in case of Java parameters are outside the curly braces. Now we can argue that the differences are not limited to these but each Programming language will provide different options and restrictions. The implementation they follow may be different. But if we learn the very basic concept then we can write better code. We get engrossed in learning the programming constructs and then hardly find time to understand the concept. Hence start understanding the concept first then you can go to the language construct. When you are learning a new Programming language, even if you may not know the construct but the concept being similar all you need to do is learn the construct.

    How the closure or lambda is useful ? The official documentation emphasises on the anonymous inner class and the concise code. In true sense its beneficial is separating the change from the constant. Consider below scenario


   In this case we are looping through the list of contacts and based on the type of contact whether Email, Instant Message ID and Mobile Number we are sending appropriate Notifications to destination. Here notification type varies with Destination.  The constant in this case is to LOOP through some list and based on the the CONDITION ( Predicate ) we are performing certain ACTION which varies based on the condition. We have now created a generic code which will follow same pattern

LOOP -> CONDITION -> ACTION

    Noticeable feature here is that the generic code can invoke a code ( i.e Condition and Action ) which is passed as an Argument.

    With this thought process it does not matter if you know many Programming languages or not but learning any new Programming language will be easier for you.




References :


Comments

Popular posts from this blog

Container detached from docker network

Introduction One fine day you find out that one of your docker containers is running but is not currently attached to the container network that you created using docker network command. Ideally a container should be detached from the network when there is some error in it. However, if you set the restart: on-failure in the docker-compose.yml  in that case the container should restart and still be attached to the network. In such a weird situation follow the steps documented in this blog. Possible reasons Listed below are the possible reasons for this issue Storage space issue Memory issue ( We will cover this in next blog ) Storage space issue We need to check the space utilisation at the server level first then drill down to the docker engine. Server level utilisation In most cases the server is ubuntu system hence check the disk usage using the disk free command (i.e. df -h ). It will show you the current storage space utilisation of the server. df -h Docker engine space utilis...

Secure login to MySQL for bash scripts

Introduction In this blog we will connect to a mysql via CLI from a bash script for generating a db dump. A cleaner approach for the same is using mysql config editor. In this blog we are taking an example of a mysql container running inside docker and we have a script for taking a db backup using  mysqldump . We will not use a password as a parameter to  mysqldump  command instead we will use something called as login path. MySQL config editor It is a utility to store authentication credentials in a obfuscated login path file named as  .mylogin.cnf . How to do it ? View existing configurations To view existing configurations if there are any use below command. The command will output existing configurations if there are otherwise it won't print anything. mysql_config_editor print --all Sample output In the output below you can see that the password is obfuscated and is not readable directly. It is handled by the mysql utilities to use this password as per the flags ...

TOP down or bottom UP approach to Learning

      All of us have unique learning ability. Learning new thing has two of many approaches ( i.e TOP-DOWN or BOTTOM-UP ). TOP down approach is from Generalisation to Specialisation approach and BOTTOM up is inverse. Which approach to follow depends on the individuals choice and level of experience. In both the cases you can start small then broaden your learning and then narrow it down for easier storage and retrieval. Let's do a comparative analysis today of these approaches and understand which approach is better.     Learning something new requires lot of efforts and if you do it wrong then you tend to confuse yourself and lose confidence. Let's take an example of the BOTTOM up approach, if you are learning a new programming language and you start with the datatypes, reserved keywords, access specifiers, etc. then you will need more efforts to first store all what you learnt then club them together to create a logical whole. Most of us will argue s...