9 ms·

> there was no one left who could support an Erlang system. If you have $200k "python engineers" on the payroll who wouldn't jump at the opportunity to do some

> there was no one left who could support an Erlang system. If you have $200k "python engineers" on the payroll who wouldn't jump at the opportunity to do some additional Erlang, maybe it's time to reconsider your hiring practices and that is the real cautionary tale.

maxwindiff 6y ago
I want to downvote this comment so much.
- cosmotic 6y ago
  Why?
  - maxwindiff 6y ago
    This kind of sentiment come up every so often on HN and I'm just sick of it. Sure, programmers should strive to improve their craft, just like professionals in every industry. But there are plenty of ways to improve yourself and learning a new language is hardly the most effective choice (and in fact could be counterproductive).
    - scull7 6y ago
      How does learning a new way to think about a problem become counterproductive? Each language you learn gives you a new angle from which you can approach a problem. Is it counter productive to learn a second spoken language? I haven’t come across an argument against that, even learning a dead language like Latin or Ancient Greek has benefits.
      - maxwindiff 6y ago
        Perhaps counterproductive is too strong a word, but there could definitely be problems in the short term. Programmers love to apply things they learned in their work, and taking a concept or pattern from language A and applying them to language B is a natural reaction. The most common culprits are monads and actors. Ergonomics (readability, cognitive cost, debugging, IDE support, etc) became afterthoughts in the midst of excitement, and the long term health of the codebase (and teammates) suffers. I have made mistakes like that (introducing monads/future and making the team learn guava) and I still regret it. Its not to say futures are useless - there were a lot of async logic in the codebase and futures solve a real problem, but its not clear if the benefits outweigh the cost.
krn 6y ago
I completely agree. Software engineering is about being a master of problem solving, not just being a master of some tool or technique.
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
carapace 6y ago
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.
- craigsmansion 6y ago
  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.
  - sitkack 6y ago
    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.
- kbyatnal 6y ago
  Can you expand what you mean re: large projects in Python?
  - carapace 6y ago
    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.
dreamcompiler 6y ago
Completely agree. I worked at a company on a Common Lisp project where the Python crew refused to learn Common Lisp because they thought it would look bad on their resumes. This should be a litmus test for programmer quality: If they don't want to learn something because it's not "fashionable", they're probably lousy programmers who lack confidence in their own abilities. Do you really want these people working for you?
- deleted 6y ago
  [deleted]
- rraghur 6y ago
  I'll be the first to admit... I'm a little conflicted by this.. I've almost exclusively worked on the usual procedural /OO languages professionally (java /c#)..I like to experiment and I've picked up a bunch of languages along the way (perl, python, coffeescript, f#, nim etc).. And its usually because I want to see what's different and spend enough time to do something useful (but not large) with it. Also, it helps you become a better programmer IMO. otoh, if I'm hired for my skills but then have to work on js( don't actually like the js eco system) or haskell (I gave up after trying and I doubt I'd become very good at it anytime soon if I were forced into it) I'd be not happy either (and IMO, with valid cause that doesn't reflect on me or my abilities)
- enz 6y ago
  > Completely agree. I worked at a company on a Common Lisp project where the Python crew refused to learn Common Lisp because they thought it would look bad on their resumes. They can put only "Python" on their résumés, right?
  - dreamcompiler 6y ago
    One would think they could just avoid mentioning Lisp. I still don't understand their reasoning.
    - kazinator 6y ago
quickthrower2 6y ago
$200k !
as-j 6y ago
> If you have $200k "python engineers" on the payroll who wouldn't jump at the opportunity to do some additional Erlang Ah, sure they might be willing, but as a lead I'm not willing to invest in it. 1. I'm not sure I want someone who's got 4 weeks of experience in a language working on system critical infrastructure. Pick your time, does it take 6mo? 2. They have existing work, learning and working on an entire new language _AND_ new project is a huge task. Especially for non-trivial projects. We could, but in our case it was a better engineering decision was to retire the old system and move on.

maxwindiff 6y ago

I want to downvote this comment so much.

cosmotic 6y ago
Why?
- maxwindiff 6y ago
  This kind of sentiment come up every so often on HN and I'm just sick of it. Sure, programmers should strive to improve their craft, just like professionals in every industry. But there are plenty of ways to improve yourself and learning a new language is hardly the most effective choice (and in fact could be counterproductive).
  - scull7 6y ago
    How does learning a new way to think about a problem become counterproductive? Each language you learn gives you a new angle from which you can approach a problem. Is it counter productive to learn a second spoken language? I haven’t come across an argument against that, even learning a dead language like Latin or Ancient Greek has benefits.
    - maxwindiff 6y ago
      Perhaps counterproductive is too strong a word, but there could definitely be problems in the short term. Programmers love to apply things they learned in their work, and taking a concept or pattern from language A and applying them to language B is a natural reaction. The most common culprits are monads and actors. Ergonomics (readability, cognitive cost, debugging, IDE support, etc) became afterthoughts in the midst of excitement, and the long term health of the codebase (and teammates) suffers. I have made mistakes like that (introducing monads/future and making the team learn guava) and I still regret it. Its not to say futures are useless - there were a lot of async logic in the codebase and futures solve a real problem, but its not clear if the benefits outweigh the cost.

krn 6y ago

I completely agree. Software engineering is about being a master of problem solving, not just being a master of some tool or technique.

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

carapace 6y ago

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.

craigsmansion 6y ago
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.
- sitkack 6y ago
  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.
kbyatnal 6y ago
Can you expand what you mean re: large projects in Python?
- carapace 6y ago
  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.

dreamcompiler 6y ago

Completely agree. I worked at a company on a Common Lisp project where the Python crew refused to learn Common Lisp because they thought it would look bad on their resumes. This should be a litmus test for programmer quality: If they don't want to learn something because it's not "fashionable", they're probably lousy programmers who lack confidence in their own abilities. Do you really want these people working for you?

deleted 6y ago
[deleted]
rraghur 6y ago
I'll be the first to admit... I'm a little conflicted by this.. I've almost exclusively worked on the usual procedural /OO languages professionally (java /c#)..I like to experiment and I've picked up a bunch of languages along the way (perl, python, coffeescript, f#, nim etc).. And its usually because I want to see what's different and spend enough time to do something useful (but not large) with it. Also, it helps you become a better programmer IMO. otoh, if I'm hired for my skills but then have to work on js( don't actually like the js eco system) or haskell (I gave up after trying and I doubt I'd become very good at it anytime soon if I were forced into it) I'd be not happy either (and IMO, with valid cause that doesn't reflect on me or my abilities)
enz 6y ago
> Completely agree. I worked at a company on a Common Lisp project where the Python crew refused to learn Common Lisp because they thought it would look bad on their resumes. They can put only "Python" on their résumés, right?
- dreamcompiler 6y ago
  One would think they could just avoid mentioning Lisp. I still don't understand their reasoning.
  - kazinator 6y ago

quickthrower2 6y ago

$200k !

as-j 6y ago

> If you have $200k "python engineers" on the payroll who wouldn't jump at the opportunity to do some additional Erlang Ah, sure they might be willing, but as a lead I'm not willing to invest in it. 1. I'm not sure I want someone who's got 4 weeks of experience in a language working on system critical infrastructure. Pick your time, does it take 6mo? 2. They have existing work, learning and working on an entire new language _AND_ new project is a huge task. Especially for non-trivial projects. We could, but in our case it was a better engineering decision was to retire the old system and move on.