DEV Community

loading...

Exploring other programming languages

Lance Wicks
Judoka, Developer, Kiwi
Originally published at lancewicks.com on ・5 min read

Lately I have been doing some coding challenges and rather than just solving them and moving on I have been doing them in multiple languages for a couple of reasons.

Deliberate Practice

Those of you who have heard of the 10,000 hour rule will probably have heard of the deliverate practice idea. The idea here is that the act of “deliberate practice” is powerful; more so than just practice. This is the idea that just playing scales on the piano will not make you a concert pianist; no matter how many hours you do it. If however, you practice scales that get more and more complex and stretch your ability; then perhaps one day you will be onstage at the Albert Hall (Carnegie Hall for you Americans perhaps).

In developer context, just writing code is not perhaps deliberate practice. Even solving challenges may not be deliberate practice if it is challenging depending on where the challenge is and what you are trying to practice.

Systems thinking versus coding

When working on a coding problem you are often doing two things; one solving the problem and coding the solution. When thinking of deliberate practice are you praticing solving problems or coding a solution? Subtley different.

For me, I have been wanting to practicing coding, as opposed to wanting to practice solving problems.

So my solution has been to solve and code the problem once in a familiar language (Perl 5), then code up the solution in another language (javascript, perl6, go, dart, etc).

Tools and Practices

This approach means that after the initial solution I understand the problem and solution (often not completely) and have gained some practice at coding it in a mature language I know well (Perl 5).

Then I code up the same solution in another language, this means I know how to solve the problem (the algorithm) but I don’t know the language specific implementation or tooling. So I need to explore how to craftunit tests in that language, how to lint the code, how various operators vary between Perl5 and the next language.

My aim is to learn tools and practices; not learn how to solve puzzles.

Specifically I want to learn tools, which for me includes the language, the testing framework(s), the static analysis and linting tools. I also want to learn what makes that language different; so bouncing from one language to another helps me experience the differences first-hand.

Having solved a variety of different simple challenges across up to 5 languages has proven interesting. Perl 5 is always the easiest one to solve and code up. Why? Because it’s a mature, flexible language I know really well. Moving from Perl 5 to Japavascript for simple challenges is not very difficult; they are similar enough but the tooling is foreign and there is a lot of variety in tools (where Perl 5 has pretty much standardised on solid tools). Moving from Perl 5 to Perl 6 is relatively easy; they are sister languages; but Perl 6 has many more ways of doing things that you can use. The tooling however is lacking for linting and formatting as two cases to note. Perl 5 to Go is a real challenge at first; things are very different.

Sidenote: Going from Go to Perl 6 actually seemed easier than you would think. Perl 6 can be very similarly written to Go… especially if you have not got a Perl 5 mindset you will probably find it a relatively painless exercise.

Coding Practices

Whatever language I am working in, I am focussed heavily on how I code the solution more so than the solution itself. I am using as much TDD and BDD as I can.

I am trying to modularise and create all the solutions as reusable modules that might be found in a larger software codebase.

I am running tests continuously and pushing commits when I feel I have made the smallest change that makes sense.

I am trying to write intelligible, human-readable code (even when stealing challenges from https://code-golf-io?utm\_source=rss&utm\_medium=rss I try to write the verbose, written for person not compiler/interpreter code.

Trying different approaches

Now I have a corpus of challenges I have coded up in a few different languages I am at the stage where I can cycle around the challenges and decide if I try a new language or a new approach to the solution.

I.e. having solved a problem in one way; I may decide to solve it another way in the same language. Or solve it the same way with different tools and see what happens.

Again my goal is not to get good at solving puzzles; but to leanr to be a better developer of code. To get better at knowing how to code reliably across a variety of tools and languages so that I know the strengths and weaknesses of both the languages, tools and myself.

Summary

I am choosing to practice software development; I have specific goals in mind and that affects how I choose to practice and what I choose to focus on.

I can assure you all that the code I am writing is not super elegant, or super secure, super clever, super performant, super anything. It is however written, it is tested, it is tidy and it works.

I know I am good at some languages, not good at others. I know a lot about some tools in some languages and barely anything about others. I have improved in my skills at all the languages and tools and the methodlogies.

And that is the point; I wanted to improve and I have.

Lance

Want to give it a go?

I can heartily recommend giving this a try if you have any interest in coding and being better at it than you are today.

My suggestion is to start in a language you know and solve an easy problem (fizzbuzz for example). Ideally solving something where knowing if you have solved it is pretty well documented (test data/outputs are always a bonus). I have solved several “Holes” from https://code-golf.io?utm_source=rss&utm_medium=rss now as that site has good graduation of difficulty and also makes knowing what the correct answer is easy as you can even do it in the website if you want.

The https://cyber-dojo.org/?utm_source=rss&utm_medium=rss site is also great as it has tests built in, which can be a starting point that is invaluable if that is an area you don’t feel strong in.

Personally, I have tended to choose a puzzle from either of these sites or from one I get sent by email from https://www.dailycodingproblem.com?utm_source=rss&utm_medium=rss/ and work on it locally. I have yet to try challenges from https://perlweeklychallenge.org?utm_source=rss&utm_medium=rss/ but I here good things and learnt recently that some Python developers are using the site so it may be where I get my next challenge.

If you do give give it a try, please drop me an email and let me know how you get on.

Extra Credit

If all that seems a bit too easy… take it to the next level and do what I did recently; try and do it on a plane (or simply offline). Try coding up a solution in a new or unfamiliar language without google.

This is where you learn how good languages are and documentation. Perldoc and Godoc suddenly become wonderful assets and Javascript loses your enthusiasm when suddenly you can’t look things up.

.

.

.

Read this far? Good, then I offer this tip https://devdocs.io/?utm_source=rss&utm_medium=rss for offline documentation for a whole bunch of languages!

Discussion (0)