Each programmer has its way to learn a new programming language, and the difficulty to master it depends on many factors, we can enumerate:
- The language itself.
- The programmer experience.
- The language community.
- The existing language resources ( websites, books,…).
Here are some pragmatic steps to learn a new programming language:
First, Install the environment:
Even if you use the resources from the web, books or you do a training to learn the programming language, the trivial step is to install the environment needed to develop, execute and debug your code.
Sometimes the environment could be just an IDE, and for other cases you have to install many other tools. Each language has many possible environements and you have to choose yours.
When you begin to learn a new language, it’s better to focus on the language itself rather than the environment, it’s better to use an environement which is very simple to install and use even if it’s not the most rich in features. You can after switch to another environement if you begin to master the language.
Explore and execute some samples
After installing the IDE, try to explore some samples, execute and debug them. The goal of this step is to familiarize yourself with the IDE capabilities.
Write and execute your first sample
Create a sample from scratch is very useful to have an idea of the program structure and how to deploy it. In many cases just a “hello world” could be sufficient.
Good habits from the beginning
If you are accustomed to develop using a specific style, it’s very hard to change your habits. If you begin a new programming language try to explore some known open source projects, no need to download and build the project, you can just discover the code from GitHub. This step will help you to have an idea of the style used by these mature projects.
The headache of choosing the frameworks and libraries.
When you begin a new programming language, sooner or later you have to choose some libraries and frameworks to use.
Choosing a software library is not always an easy task, specially if many concurrent libraries exist for a specific need. As a beginner it’s maybe the most complicated task.
Here are some factors to consider when choosing a library:
1- Licensing
The library license is the first thing to check, it’s very important to verify if the license is compatible with your project, before going further and discover the library capabilities.
http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses
2- Does the library satisfy your needs?
It’s a trivial factor, but how many devlopers realized a mini proof of concept to check that all their needs are satistified by the library. Sometimes we discover very early that the library is not good for some reasons.
3- The community is active
Many problems could occurs when using a library, if its community is active, it will be very easy to find quickly a solution.
4- What about the trend of using the library?
It’s interesting to know if the library grow on popularity or not? for that you can use google trends and discover the evolution of the library over years.
Here’s for example the trend of d3.js API:
5- Does the library has a break changes in the past?
Before adopting a library, take a few minutes and search in the web for “LibraryName breaking changes” to check if for a specific version a breaking changes was done.
It could help you for the following reasons:
– Avoid using library examples from older versions.
– it’s not good sign if a library has a big breaking change. It means the developers does not care about the library users, and it could happen again in next versions.
6- Constraints and limitations of using a library.
Sometimes a library is awesome for a specific needs, but has one killer limitation which could force you to not use it.
Let’s take as example the google chart api, it’s a versy useful chart library. However, it has one annoying limitation, the user must have an internet connection.
Before choosing a library, be sure that no limitation could affect its using, you have just to search in the web for “LibraryName limtations”.
7- Documentation
A well documented library will helps you considerably when you use it. specially if it contains many samples of using it.
8- Did you care about performence when using the library?
If you plan to use a library in a context where the performence is very important, don’t only trust the benchmarks found in the web. It’s preferable to make a POC with your specific constraints to have a better idea of how the library behaves in your specific context.
9- Does your application multiplatform?
If you application must works in many platform, don’t test mostly in one platform, after finishing the developement test for all the other platforms.
Always test from the begining on all the targeted plateforms, some libraries are very good implemented for an OS and very bad implemented for the others.
10- Is there any other serious alternative to the library chose, and you have a doubt?
In some cases you could find two awesome libraries for the same needs, and you have a doubt of using one of them. In this case never let your code highly coupled with the library. Prefer using wrappers and facade patterns to isolate it’s use.
Of course there are many other factors that could influence your choice. and to minimise the risk of using a bad library which we must change it after. It’s always a good practice to isolate its use in some few places in the code, by using wrappers and facades.
Try to evaluate the coupling of your application with all the libraries used, identify the libraries highly coupled with your code, and progressivly try as possible to decouple its use.