Comment by hgs3 | Hacker News Reader

Comment by hgs3 | Hacker News Reader

The authors main bullet points are:

> The learning curve is minimal since you already know the corners of the language.

Learning a new language shouldn't be difficult. Programmers are expected to familiarize themselves with new tech.

> Internal language APIs can be leveraged, which drastically changes the mental model to write the script (for the better).

This is true. I myself have encountered situations where I needed to call into my C API's from a higher-level language, but since most languages can interface with C this hasn't been an issue for me. For example I've interop'd Go+C, Python+C, and Lua+C.

> Scripts feel more natural and eventually maintainability increases. Team members are familiarized with the language!

This sounds like a subjective rehash of the first point.

> Development machines compatibility increases. Windows users can finally run all scripts.

This is true if you're talking about shell scripting, but if you're scripting with a general purpose programming language then it shouldn't be an issue. What language (besides shell) isn't portable these days? And even then, you can install a *nix environment on Windows.

> Learning a new language shouldn't be difficult. Programmers are expected to familiarize themselves with new tech.

I wish any large company agreed with this. I've worked for a company that on boarded every single new engineer to a very niche language (F#) in a few days. Also, everybody I worked with there was amazing. Probably because of that kind of mindset.

Meanwhile google tiptoes around teams adopting kotlin because "oh no, what if other teams touching the code might not be able to read it". Google is supposed to be hiring the brightest but internally is worried the brightest can't review slightly-different-java.

It's shocking how everybody acts like senior engineers might need months to learn a new language. Sure, maybe for some esoteric edge cases, but 5 mins on https://learnxinyminutes.com/ should get you 80% of the way there, and an afternoon looking at big projects or guidelines/examples should you another 18% of the way.

> It's shocking how everybody acts like senior engineers might need months to learn a new language.

I've seen instances where people were worried it would take someone a month longer to fully onboard. Completely ignoring the fact that *fully* onboarding in any complex environment is going to take several months anyway.

I'd also argue that in the case of setting up your scripts, it matters even less. Automation scripts shouldn't be so complex that you fully need to know the ins and outs of the language they are written in. If they are, then maybe it is time to re-evaluate your building/deployment process.

Furthermore, I'd say that historically, both bash and python should be languages any semi competent developer at some point learns to work with to some degree. I say historically, because it always has been difficult to not encounter it when doing software development in the past... 20 years or so. But with modern environments and deployments it is more feasible as much more is abstracted away in pipeline yaml syntax.

> Meanwhile google tiptoes around teams adopting kotlin because "oh no, what if other teams touching the code might not be able to read it".

That is highly ironic, seeing how often Google tries randomly shoving Dart down people's throats.

>It's shocking how everybody acts like senior engineers might need months to learn a new language.

It's true for some languages, like C++, some might wrongly extrapolate from that. I agree with your general point though. If your senior engs can't learn Python/Ruby/F# etc in a few days to a level where they can contribute, you might want to ask yourself what senior means in your org.

> Sure, maybe for some esoteric edge cases, but 5 mins on https://learnxinyminutes.com/ should get you 80% of the way there, and an afternoon looking at big projects or guidelines/examples should you another 18% of the way.

Not for C++, and even for other languages, it's not the language that's hard, it's the idioms.

Python written by experts can be well-nigh incomprehensible (you can save typing out exactly one line if you use list-comprehensions everywhere!).

Someone who knows Javascript well still needs to know all the nooks and crannies of the popular frameworks.

Java with the most popular frameworks (Spring/Boot/etc) can be impossible for a non-Java programmer to reason about (where's all this fucking magic coming from? Where is it documented? What are the other magic words I can put into comments?)

C# is turning into a C++ wannabe as far as comprehension complexity goes.

Right now, the quickest onboarding I've seen by far are Go codebases.

The knowledge tree required to contribute to a codebase can exists on a Deep axis and a Wide axis. C++ goes Deep and Wide. Go and C are the only projects I've seen that goes neither deep nor wide.

The hard part about learning C++ is the same stuff that’s hard about C, the rest is just stuff you can google TBH

Ridiculous. You must be talking about learning only the syntax of a new language. Truly internalizing how to wield a new language will take months to years.

A dev that switched from language X to Y "in a few days" will just write X using Y syntax. Here's a good example of going from Java to Python: https://youtu.be/wf-BqAjZb8M?t=1327.

>> The learning curve is minimal since you already know the corners of the language.

> Learning a new language shouldn't be difficult. Programmers are expected to familiarize themselves with new tech.

But in practice, it is. Maybe you're on a team of elite 10x programmers that can quickly become experts in anything, but that's rare. A lot of programmers don't want to bother coming up to speed with the quirky choice of some past developer. And a lot of places have programmers that aren't even that good with the "project main language," and just lack lack the ability become productive in that quirky choice in a reasonable amount of time.

Defensive coding against organizational problems is not a bad thing.

> But in practice, it is.

Indeed. There's also 'learning' and learning: really knowing all the nooks and crannies of a language, learning the standard library and learning popular third party libraries all takes time and makes a big difference to code quality.

Depends on the language. I am competent in half a dozen languages, and write a lot of functional code.

I have written a few projects in Haskell, but I freely admit theat when I read any of Simon Peyton-Jones papers (eg the one on build systems referenced on HN recently) I am in awe of the way he can map concepts into Haskell code.

> But in practice, it is. Maybe you're on a team of elite 10x programmers that can quickly become experts in anything, but that's rare.

Pray that you aren't, because that is a recipe for misery.

> Learning a new language shouldn't be difficult. Programmers are expected to familiarize themselves with new tech.

Learning it is fine, but will you still know it 2 years from now when you need to modify the script? Me, definitely not.

Could you re-learn it then if you need again?

Yep, but it all adds a lot of pointless work.

I'm so much happier since I started using JS for scripts, rather than the monstrosity that is Bash.

I think Crystal is a popular one which doesn't yet support windows fully, at least last time I checked

> Learning a new language shouldn't be difficult. Programmers are expected to familiarize themselves with new tech.

I think that expectation is a problem.

I mean, sure, you can't use one single technology for any non-trivial project. But, on the other hand, is it really faster to read the spec and short comings of 20k different `left-pad` type "tech"?

I think there's a line to be drawn: each new $TECH added as a dependency is a liability. The expectation should not be "throw every single tech we can think of into there, because programmers are expected to learn new tech".

The calculus really should be "Each new $TECH we add increases our hiring burden, our ramp-up times, our diagnostic burden for when things go pear-shaped, our cognitive load when actually adding features, our tests, and eats into our training-time budget."

Those are a lot of downsides, so before padding their CV the responsible developer should be balancing the trade-offs.

Unfortunately that is rarely how it actually works.

Reply on news.ycombinator.com