Hacker News Reader

Comment by carapace | Hacker News Reader

This, twice.

Back in the day people would balk at hiring Python programmers saying, "there are so many more Java programmers", and I used to say, "Why would you hire a Java programmer who was unwilling or unable to learn Python?"

Same logic applies here: Why would you hire a Python programmer who was unwilling or unable to learn Erlang? (Especially if you're going to pay them to do it!)

If you can't switch languages you're a kind of technician not a programmer.

FWIW, having done it professionally for ~15 years I'll never write another large project in Python again. Erlang's runtime is so much better than Python's it's just ridiculous. I feel stupid for not realizing this sooner.

View on HN

If I had a Python job (a language I enjoy) and I was forced to work in a language I don't (say, Perl), I'd start complaining about it and looking for something else to do. I personally wouldn't mind working with Erlang, but that isn't the point. Many developers "can" do these things but it doesn't mean they want to.

It's pretty much how we treat our Python projects. All of us hate it, but data science is done in Python so we still need some percentage of the engineering team fluent enough in it to sustain operations with it (on-call, maintenance, bugs, eventual decommissioning).

The moment we can get rid of it, you bet we will. But it's much easier tearing it down when you understand it enough to discern designs driven by the limitations of the tech vs requirements for the product. Black box ground up replacements are hard and expensive compared to ports. Also, thankfully it's Python and nothing something more difficult/complex.

At the end of the day, it's a job, and there's an expectation of professionalism to do what's necessary. A lot of people on HN like treating tech jobs like a paid hobby which I think is detrimental to career development.

Regrettably, also back in the day and probably around the same time, companies who wanted to hire "outside of the box" asked for Python. Not because they were python shops, but because they figured that people who had an interest in a new but not-quite-commercially viable language must have some sort of intrinsic interest in programming, and would likely make for better programmers.

This is because those shops read the PG essays, and think that the the shibboleth is Python, it is not. The marker is that that someone is at the fringe and not in the middle of the flock.

I have met lots of engineers who are smack dab in the middle of the flock when it comes to tech stacks, or even _behind_, but they were more than capable. Hire for what you need. But what you think you need and what you actually need is probably not know to you.

Depends on the reason for switching. If I'm asked to switch because the new stack is going to have measurable improvements plus the language is going to stay and grow (just as examples may be Go or Rust right now), then sure. On the other hand, if the reason is because the company fucked up by relying on one idiot with an elitist mindset about programming languages, then that request going to have to come wrapped with very good incentives. If I'm a great java developer with tons of jobs to choose from, you are going to have to give me a very good reason to narrow my opportunities down for you. Otherwise, I'd say no and move on and you can go hunting for devs for a niche language and pray to Gods that the hiring situation will improve for you.

Your example of Java to Python doesn't represent the gravity of switching from Java to say Erlang or Haskell. You assume someone says no because they are unwilling or unable. We are unwilling, sometimes, because of the opportunity cost we have to pay for your fuck up.

> If I'm a great java developer with tons of jobs to choose from, you are going to have to give me a very good reason to narrow my opportunities down for you.

Why would learning a new tool narrow rather than widen your opportunities?

It's not like you forgot all you know about Java.

Learning an obscure tool that eventually dies is a waste of time. Think learning a language only you and a few of your friends speak. This in itself is good enough reason to be cautious about what you invest your time in learning.

Languages and specially the tool chain and the way of doing things around them evolve. If you spend like 5 years doing something else and come back to it, you'll find things have changed a lot. You may argue that it's easy to relearn this. But from a job perspective, the guy who has been using the exact same tech stack in the recent years will often be a better bet than a guy who wrote Java in version 1. This is very true for C#. Syntax, design principles, tools, method of deployments all have changed rapidly. Professionally, you want to be as up to date as possible in the area you worked in or you get rusty. You can learn new things on your time for their own utility. Flushing down 40-60 hours a week on a useless piece of knowledge is bad all round to me.

> Flushing down 40-60 hours a week on a useless piece of knowledge

That is only if it's actually useless. I haven't programmed in haskell for many years, yet I am very glad I did. It was hard at first, but it made me think about code, data and transformation from a different perspective, expanding the repertoire of paradigms, regardless of which language I code in.

YMMV, but personally, I'd much rather hire or work with someone with 3y java + 1y erlang experience, than just 5y java experience. In general a polyglot rather than monoglot, especially if it's a different coding paradigm. Nevertheless, I may not actually want them coding random bits of work in erlang or whatever random language.

Well, a Java developer isn't going to want to give up the JVM, their type safety, and great tooling, for a start.

I get being interested in Erlang if you're doing Python. But interested in doing Python as a Java dev? Probably not.

Seriously, why doesn't python have a maven equivalent yet?

And no fat-binaries. Nor self executing binaries. It's just as old and having em basically just boils down to enforcing conventions. But nope, nothing. There have been attempts by some such as shiv, but really... None are even remotely as usable as maven is.

You could containerize your python. That's like having a fat binary.

yes, you can do that. I've been doing that for around 8 years now.

And no, it's not the same. Not even remotely. The only thing that helps with are quick and easy deployments.

The thing which makes maven special is the ease of producing artefacts for deployments, not the final step of starting it up on the server.

Python doesn't require creating artifacts. It requires dependency resolvement which Docker is perfect for.

Have you tried Nuitka? https://github.com/Nuitka/Nuitka

In the same vein there's also PyInstaller and PyOxidizer, not to mention platform-specific binaries generators (Py2app, ...)

PyInstaller Nuitka PyOxidizer To name a few.

Can you expand what you mean re: large projects in Python?

Yeah, thanks for asking.

I've been a happy Python programmer for over fifteen years, so this comes from a place of love and respect.

Beyond roughly 150k LoC you start to run into difficulties keeping everything straight over time, especially if you use a lot of indirection or other magic. The aspects of the language that help you go fast when you're prototyping (is "RAD" still a thing? Rapid Application Development) start to trip you up when the codebase matures. There are a lot of fancy footguns in Python that catch you if you stop dancing.

Tooling is getting a little better (MyPy, et. al.) but at the same time the overhead of adding explicit type information erodes the advantages Python has over, say, Java or Haskell.

from personal experience with mypy, the great thing about gradual typing in a dynamic language is that, well, it's gradual! when I want to do something extremely dynamic, there's no horrible reflection API in my way. but most of the time I can live happily inside the walled garden mypy provides.

I have adopted this attitude for personal projects & small companies, and it was mostly great.

There was at least 1 really large error that slipped into production because we were mocking an untyped service incorrectly (a mistyped property name), and the test passed, but prod exploded. It was embarrassing, and I certainly would have caught it with more mypy discipline, but overall the pros outweighed the cons.

At big companies that use mypy, however, this is problematic. If teams only define types for the straightforward parts of the system, then the types become less useful, especially as the company scales. From what I’ve seen, individual teams use an all-or-nothing approach with MyPy, so it’s unusual for an individual dev to sparsely type anything.

agreed - I am thinking more in terms of the common distinction between infrastructure/libraries and application code - I can write dynamic, well-tested libraries that are used by heavily annotated, checked application code. The types are generally more meaningful at that layer, and it tends to evolve more quickly anyway.

This is true of all dynamic languages. Rails codebases become a nightmare beyond a certain LOC. It’s taken a long time but now that we have languages with strong static typing but good type inference like Kotlin, Swift, Typescript etc the old fully dynamic languages are obsolete technology and will eventually be replaced.

I'm not touching COBOL anymore for $200K

Reply on news.ycombinator.com