Saturday, December 27, 2014

Why You Should Learn Different Programming Languages

Up until I graduated college, I mostly used Microsoft languages like C# and VB. Other than the .NET switch from VB6, I pretty much wrote code the Microsoft way and whatever way that I knew how... which in hindsight looks like a mess.

When you start working in a team and need to try to understand other people's messy code and/or develop on large applications where you cannot remember everything you did several months back... but need to, Clean, simple, robust, unit-testable and sufficiently documented code will save you a lot of time and pain...

I can't actually say you will learn this... I know a lot of people that don't and they are always busy putting out fires in a production environment... which to me sounds boring and stressful. (I have a whole rant on this which I will leave for another day...)

So anyway... the thing about learning or dabbling in many languages is that it exposes you to many different paradigms and conventions which make up new concepts, and different approaches to programming (event-driven, MVC, functional, ...). When you go back to your core language, you tend to pick out the ones you really like and start actively looking to see how to implement them in the language, because concepts tend to be transferrable. Often times you will find that there is some existing or similar framework already but without stepping out of you comfort zone, you would've never come accross it.

In addition, you will be more comfortable with learning other languages and tools, you get use to rolling up your sleeves, figuring things out, and thinking about how to make things better, faster... automated.

And it all can culminate in many Aha! moments. I have had many problems where I could not come up with a permanent fix or solution immediately but after a few weeks or months and after learning some new things, revisiting the problem, I go... What if we do this...

So here are some things I've learnt from other languages and brought back to C#.

Anonymous Functions

Language: JavaScript, Java

In Java you can implement interfaces as an anonymous class, and in JavaScript you can pass functions as parameters.

At the time, I kind of knew about events, delegates and LINQ in C#, but never really used it. But more and more, I started seeing instances where it would be great to pass functions.

Without the exposure to the concept, I probably would have never touched these things in C#.

Interfaces, Dependency Injection, and Design Patterns

Language: JavaScript, Java

First time I used this was on the job on a small project, via Spring. Then when I started using JavaScript frameworks like jQuery and node.js which have very modular components and rely on configurations to instantiate concrete instances of interfaces.

To be honest, up until then, I didn't really understand interfaces and inheritance; never really used it.

But this kind of "opened the door" and one thing led to another:

Why do I want to use dependency injection (IOC)?
  • Easier to swap out
  • Flexible
  • Forces you to think about and remove hard coded dependencies
  • Components can be reused in different projects... less coding, less testing

How do I make components? 
Use interfaces and abstract classes; understand inheritance

How should I build these modules?
  • Use design patterns when possible
  • Keep them small and as independent as possible
  • Separation-of-concerns, software architecture
What are design patterns, software architecture?
...

Frameworks

Languages: PHP, JavaScript, Java, C#

First time I really thought about frameworks was when I first started working a web service running on ServiceStack. I had to port it to Java using Jersey. Had to learn all about how it worked, how to write code for it. 

Then, I did some personal web development in PHP which led me to Yii, an MVC framework... now I learned MVC.

Next, node.js was new and really popular a few years ago, and I tried to pick it up (but by that time, my interest in serious web development was fading..) But anyway I got a bit of that and led to learning event-driven programming and (that would lead to a whole bunch of things...)

But anyway, you start learning that frameworks are useful for reducing redundant boiler-plate code because they already do it for you; you don't need to start from scratch. 

So now when I start a new project, I usually think about what needs to be accomplished and if there are any frameworks I should use to do it faster or better.

Class Libraries

You learn after awhile that a lot of code is redundant and not to "reinvent the wheel" whenever possible. Energy and time are limited and should be spent on more interesting things (which is also something that a lot of people don't understand... see rant above).

And with class libraries, you also learn to write more generic and smaller functions which allows you to reuse the same code over-and-over again in your application. This has many other benefits like testing, not having to change the same thing 50 times, etc. The caveat is you better have very good, robust unit tests to ensure that changes don't impact existing functionality... hm... sounds like automated unit tests... (again, one thing leads to another...)

In fact, now I've been building a few of my own for reducing redundant code in my projects. It does have some problems though as all my projects are linking to the working copy but at the same time I don't want to have a static DLL reference for each... maybe I should but then it makes it harder to change things on -the-fly...


MVVM

Well this a C# thing to begin with but it's a culmination of several of these concepts, and the fact that Visual Studio 2013 now has a very good (read no bugs, extremely good code-hinting) WPF editor.

The other contributors were:
  • MVC, frameworks in general
  • Delegates and events which led to learning Func, Predicate, Action, which led to INotifyPropertyChanged (the foundation of MVVM and the whole WPF concept) and ICommand

Collection Initialization, Structs

Languages: JSON, JavaScript

A lot of times in JavaScript, configurations are passed in a JSON object. Up until then, I tended to initialize static collections that usually contain configurations or static values which a bunch of Add commands.

Now I tend to initialize them in-line and in my opinion it's more intuitive and readable.

You can do something similar with structs although it's a bit confusing: The whole value vs. reference thingy and immutability.. don't think I still have a complete understanding of it yet but I use them mostly to pass a set of configuration values or data that won't be changed. 

Lastly

Programming Methodology

You get exposure to different ways of thinking about programming and you know they exist so you can evaluate when to use one over the other.
  • Functional programming (Scala, Clojure)
  • Event-driven, asynchronous  programming (node.js)
  • Imperative programming

Spent more than an hour writing this so... got kind of tired near the end.

No comments:

Post a Comment