Hacker News Reader

Comment by gyepi | Hacker News Reader

Many years ago, I was working with a Perl programmer and, making conversation over a lunch or coffee break, I asked him what other languages he knew. He replied, "only Perl." I was shocked and persisted in my questioning, even offering up other common languages in the hopes that he was being merely forgetful, but he was quite clear that he knew only a single programming language. This, I find very scary.

This is probably not far from the norm where a programmer "knows" multiple languages but are only expert in one. This is almost as scary to me.

At least for me, there's a refreshingly synergistic effect from knowing and understanding multiple languages well.

In fact, I would go so far as to claim that a good programmer should know and understand a variety of languages and, ideally, use them frequently.

View on HN

I would go so far as to claim that a good programmer should know and understand a variety of languages and, ideally, use them frequently.

How frequently? Can you describe the average week of this programmer?

Given that the circumstances differ, I don't think I could provide any specific guidelines.

I am not averse to using multiple languages in a project if each serves a need so, in the past two months, I have used gsl, TCL, Python, C, and Go for various components of an ongoing project. But not necessarily all at the same time. Most days, I focus on one and only deal with two simultaneously during integration or code generation.

I'm not really opposed to using different languages in a project.. but what you just described seems to mean a lot of unnecessary complexity for a given project. Given that you could use a subset of two of those to reasonably accomplish what you need, it seems to me like you are dramatically increasing maintenance costs in favor of toying around.

This line of reasoning is quite standard, and for many purposes, quite valid. However, in my particular case, it is not. Each language served a specific purpose that could have been accomplished by another, but with greater effort. Sometimes, it's better to use multiple languages in a system than to use just one throughout. Unfortunately, I can't go into more detailed reasons, but I assure you, it is not for "toying" around.

I didn't mean to offend... I honestly like toying around with different languages, and have never been afraid to add more. I mean a typical web project has data-persistance, server-side language, server-side platform, client-side language, common markup, and styling. Each of them could be using a different language or set of tools... let alone more backend connections/services.

I've been leaning towards full-stack JS as much as possible. If only that it makes some of the communication channels much easier to work across. There's still templating (html/jade/mustache/markdown) and styling (css/less/sass/stylus) to consider, and not mentioning interaction with other systems/services (mongodb/sql/salesforce). Bringing as much of that under one umbrella as possible is useful.

On the flip side, if you have well documented services, and workers/queues you can break your load up and use a lot of different platforms.

You didn't mention differing circumstances, just that the skills are necessary to be a good programmer.

Also, "platform spread" is a real concern.

Why should it be scary? If you need someone to write some scripts in Perl, it should be just fine to use someone who mainly just knows Perl. Anyway, they can learn other stuff as they need to, once they know one language well, but you haven't made a case that this is actually necessary.

It's scary because, knowing only one language means that he can only think about, and express solutions to, any problems in terms of that language. In this case, he was not expert at Perl either, so the net result was ... not good. I remember seeing Perl programs that would have been better written as very short shell scripts.

Note that "mainly just knows Perl" is quite different from "only knows Perl".

Since then, I have never met another programmer who knows only one language; I think they are pretty rare. As for proving the case, I don't think I can: there may well exist a good monolingual programmer out there. It's just not likely.

> I remember seeing Perl programs that would have been better written as very short shell scripts.

This is really common. Anyone who spends time with code should take the time to learn the *nix toolset. It's a shame to see so many people reinventing tools that have been around since the 70s.

Scary for the person perhaps. Language fads come and go. You don't want to be a person with only one language on your resume when nobody uses that language anymore. Perl is probably not one of those, though.

Which languages makes all the difference. It's more important to know at a language from a broad number of paradigms, rather than knowledge of a bunch of C-syntax-derived object oriented languages (I say this, but I'm just as guilty of it as many others, despite trying to rectify it).

Frequent usage is more difficult, though. I'd like to think I know C++, Java, C and Python all very well, SQL to a reasonable level. However, add the "dabbling" languages: Racket, Haskell, Scala, C#...where exactly would the time for using these frequently come from?

Arguably, languages are only important to an extent - libraries surrounding languages are the truly important part.

I think knowing a given language can help a lot... for example the addition of generics and lambdas to C# has dramatically changed how I may approach a given problem in C#.

I know there is often a cost to using, for example the linq extension methods, it will look cleaner a lot of the time than the loop syntax.

Beyond this, simply using a new framework in an existing language can shape your views... for example, the differences in using JS with say jQueryUI, NodeJS, or AMD modules.

Knowing a language, and some platforms/libraries/approaches can greatly shape how you use that language. I once saw a VB app written by a COBOL convert... well, it ran in VB, but definitely looked like a COBOL application.

Reply on news.ycombinator.com