Hacker News Reader

Comment by brian-armstrong | Hacker News Reader

I've noticed a trend where Javascript people are unwilling to learn other languages, confining themselves to being in one small little niche forever. Hasn't it always been said that good programmers will make an effort to become familiar with multiple languages?

View on HN

In his case I think the decision was correct. Once you have at least a year of experience in one language as a fresh programmer, you understand the quirks, paradigms, design patterns etc. You have a mental model of what a programming language looks like so you can evaluate other languages from that standpoint.

Once that experience is there, then yes, I agree that its usually not difficult to learn a new language.

That may be true, but I languages can be taught and learned on the job, and frequently are. When giving an interview, you're generally more concerned with processes, how the person thinks and solves problems, how they learn on the fly, etc. In each interview we give, we generally set them up for JS and PHP (we are a PHP shop), depending on the question but also give them the option of switching to a language they are more comfortable with. We can teach you PHP relatively easy; I came in with no PHP experience and was able to start building in Silex in under a month. What we care about is understanding basic architecture, database interaction, OOP principles, some design patterns, etc.

So I think his choice to stick with what he knows and focus on learning algorithms was a good one. He could learn Java or Go or Ruby prior to the interview and then find out that he was placed on a project developing in Python, assuming he took the job. Languages are generally easy to learn and teach; best practices, algorithms, design patterns, etc. are what's hard.

How would you know how easy or hard it is to learn a different language if you haven't done it yet?

So the 2 programming languages I am comfortable at are Ruby and JavaScript (which most boot camps teach). I am familiar enough with Python and Java to understand and write code, but wouldn't feel comfortable taking them on for a Google interview. And as for Ruby, I don't see myself using it professionally in the future, so it made sense to double-down on JavaScript. It definitely positively impacted the JS code that I write for work.

I can't speak to the trend, but it's worth considering where these "Javascript people" came from. For example, I'm currently a Javascript dev. I learned rudimentary C, C++, Pascal, and a couple of Assembly languages in high school/college, but quickly got into Perl (and the Web) for my job. After several years of developing in Perl I learned Java to show the execs looking to do "enterprise" development that I was a team player. I hated Java, and when the chance came to switch, it was going to be either Python or Javascript, and Javascript was something I had picked up some experience with, so it was the first one to get me hired. I'd consider my experience to be fairly familiar to most full-stack or backend developers.

In contrast, I run into a lot of frontend developers that came from the opposite direction: HTML, then CSS, then Javascript. Their relationship to different languages and how it can be useful to their skillset is completely different from mine. If they are uninterested in learning any other language, it's likely because:

* They have no experience to say it will be useful to them, since they are planning to continue to develop in Javascript for the foreseeable future. * The other "languages" they know (HTML & CSS) are NOT helpful in their JS skillset. So by extension, they have experience teaching them that learning other "languages" isn't helpful.

I'd be skeptical too if someone that didn't code in my language of choice was saying that I should expend effort when my experience says otherwise: it sounds too much like an ivory tower someone speaking pompously.

Now, in my case, I DO know other languages and I know how they can benefit me. (Even language experiences I hated, such as my 5 years as a Java dev, were certainly instructional and useful in my current practices). But that's BECAUSE of my experiences, not DESPITE them. So I can see how someone with a different experience would respond differently. (Heck, I tend to look down on all strict-typing languages because of my Java experience, despite hearing from others that Java is not a great example to learn from).

I hope you can get past your aversion to nicer type systems. As someone who has watched things break in production too many times, the math is very clear to me that a little time spent pleasing the type system saves MUCH more time that would have been spent debugging something in production that a simple compilation pass would have caught.

I don't recall single a production bug in my code caused by a type issue (excluding null/undefined cases, where typing is rarely helpful), whereas I've lost countless hours to teaching a compiler what it should already know. (And I have plenty of bugs, they just tend to be logical rather than type based).

That said, I also try to use a lot of unit tests, so there HAVE been more than a few pre-prod issues having to do with types. I just view the time spent on these as still less than what a strictly-typed language would require. Fixing the 1 in a 100 situation that is quickly exposed in a test is less effort than being verbose 100 times.

I will admit that there are some test cases that typing would make much easier - but not enough to yet sway me. I'll also say that strong typing (ala Python) is far less painful to me than static typing (ala Java).

I'll try to keep an open mind, but until I start seeing production bugs that make it worth more development pain, it's unlikely to occur.

* I'll also note that I think my web experience makes me prefer coercion, because everything has to keep switch to/from strings. Though I'm sure the strict-typing crowd will see that as evidence that typing has all the more need to be enforced :)

Dealing with null and undefined cases is a significant practical advantage of a modern type-system. Compilers can catch most of them.

Also you can encode your logic in types - The Curry-Howard Correspondence (https://en.wikipedia.org/wiki/Curry–Howard_correspondence) says this is always possible in sufficiently advanced type-systems. While this goal hasn't been realized in mainstream programming languages, we have been moving towards it for a long time.

So when you say that you only have logical errors, not type errors and can't recall any type issues, do keep in mind that those are exactly the kind of things type-systems aim to solve.

But I can't blame you since Java and similar languages provide the only mainstream experience of static types.

Languages I don't know, but paradigm and domains is godsend for your brain after you're over the mental uphill. After going into FP and now reading about Prolog a lot, a huge lot of ideas are blending in few concepts, recursive space exploration, trimming, continuations, graph theory ...

I wonder if it's what is expected from college graduation (we saw all these topics there after all) or if I'm late to the game but it's quite a joy nonetheless.

True story.

But fact is: JavaScript the opposite of a small little niche.

Not because you can do everything with JS (which you probably can't) but because a few things you can do with it are considered rather valuable at this moment.

Switching to a different language isn't that big of a deal for a advanced programmer.

Reply on news.ycombinator.com