10 ms·

This is my experience as well. Incidentally "this is a problem of people, not language" is one of my pet peeve statements (not that I'm mad at you, of course!)

This is my experience as well. Incidentally "this is a problem of people, not language" is one of my pet peeve statements (not that I'm mad at you, of course!) specifically because I've had it used against me enough to defend choosing, imo, bad tools. Everyone thinks they have developers that are good enough that they don't need the bumpers up when they bowl. But honestly, it's just almost never true (and if it is, it won't be for long as your company grows). One company I worked at had "we hire the best!" as its slogan, and they used it to justify so much bad practice. No code reviews (we just don't hire people who write bad code), no unit testing (same reason), python used for huge sprawling 10+ year old codebases that's on its third or fourth generation of maintainers, and no documentation anywhere. Everything is a spelunking expedition, and there's no type safety or anything to help you figure it out. There are more than a few thousand-plus line functions that make PyCharm chug every time your touch a character. On the flip side, the Java and C++ codebases were similarly abused (no tests, no docs, four generations of maintainers/oral tradition, no code reviews ever) but are at least two orders of magnitude easier to traverse because the type system keeps everyone honest across decades in a way that dynamic languages just do not.

iainctduncan 6y ago
I actually do due diligence on tech firms now for a job, and you're 100% right that the tradeoffs change dramatically when the company grows. Which doesn't mean that using the best thing possible for your expert coders at the beginning is wrong. At the beginning, you need every advantage you can get, and if you have expert programmers, give them the sharpest knife you can find! But yeah, once your company is hiring hundreds, or even dozens of devs, and is being sold every handful of years from one investment fund to another, the same set of tradeoffs no longer necessarily apply and .NET and the JVM look pretty good. I'm writing some Java at the moment for an Android app, and it's just killing me after doing Scheme and Python, but I have to admit, if that start-up had used Java or C#, they might have been better off in the long run. Hiring really good, disciplined people is super, super hard. My current thought is that if you don't have a super-star CTO who can attract and keep real A+ coders, don't use advanced languages. And if you do have that CTO, do it, but make sure you are architecting to make the rewrite in C# or whatever doable when you sell your company. If I were starting my own business now, I'd use Clojure or Scala or F#, and design things so that in 5 years new owners had a decent path to switch to C# or Java wherever they want.
- rantwasp 6y ago
  > I'm writing some Java at the moment for an Android app, and it's just killing me after doing Scheme and Python, but I have to admit, if that start-up had used Java or C#, they might have been better off in the long run. that’s a logical fallacy. chances are that if they used Java or C# they might be dead by now (ie it sucks but usually it’s a good problem to have)
  - iainctduncan 6y ago
    I know what you're getting at, and I agree with the sentiment very often, most of the time even. But in this particular case, I don't think so, and believe me, I spent a lot a of time thinking about that....
    - miku86 6y ago
      So what are your thoughts?
      - iainctduncan 6y ago
        Uh hard. First, maybe don't buy companies with bad technical debt, just start from scratch? And always prefer two experts to 10 juniors in the beginning even if you move more slowly at first. I don't know what would have worked well in that particular situation, but if I were to do it again and could influence the original team, I'd use Clojure. I believe the immutability and control of side effects would have been more of a benefit than types. That was where the real problems came from, dynamic ability to create out-of-sight side effects and alter data in unexpected ways all over the damn place. Clojure's immutability plus spec would have been way better.
- vips7L 6y ago
  > I'm writing some Java at the moment for an Android app, and it's just killing me after doing Scheme and Python Android isn't Java though. It's some frankenstein contraption made from a mutated version of Java from a decade ago. > I were starting my own business now, I'd use Clojure or Scala. I personally wouldn't ever choose Scala for anything. It's tooling is horrible (Sbt is a special hell, and scalac is as slow as a C++ compiler). I'm currently in a code base like you describe, scala core with a switch to Java. It's not fun. Were stuck with these legacy library and framework choices that don't fit into the Java ecosystem and it slows down development considerably.
denysvitali 6y ago
Exactly my feeling honestly. I was a fan of Javascript and Python a couple of years ago, and I strongly (and still do) hated Java for its verbosity. I really have to admit that, especially with large teams, a strongly typed language is definitely the way to go. I don't feel confident when I program in Python, nor in Javascript exactly for the lack of proper typing. One could argue that if you know exactly what you are doing, types can even be ignored, which is kind of true - but they're there to help the developer and his team. I don't see any good reason to use Python over Golang, for example, if we only consider the language itself and the confidence that you get from using a statically typed language.
crazypython 6y ago
> Everything is a spelunking expedition, and there's no type safety or anything to help you figure it out. For any significant Python codebase, I make sure to put extra effort into precise and strict type annotations so I can rely on type safety. Sometimes after fixing all the statically detected type problems, my program works on the first try. Python was strongly typed from the beginning, before it was statically typed. When you add a string to a number in Python, you get a type error. Python's static type system– which is formally part of the language and has multiple implementations– is an elegant and natural fit to the language. Unlike TypeScript, where the type system is artificial, and restricts what you can do with JavaScript. Language features that made it into ruby– like blocks and unless– were rejected from Python because they would have made it possible to create advanced DSLs, which is something the language maintainers aim to avoid– enabling the creation of arcane application-specific special languages. PEP-484 is the static type system's name: https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/ (implementations include mypy and Pyre)

iainctduncan 6y ago

I actually do due diligence on tech firms now for a job, and you're 100% right that the tradeoffs change dramatically when the company grows. Which doesn't mean that using the best thing possible for your expert coders at the beginning is wrong. At the beginning, you need every advantage you can get, and if you have expert programmers, give them the sharpest knife you can find! But yeah, once your company is hiring hundreds, or even dozens of devs, and is being sold every handful of years from one investment fund to another, the same set of tradeoffs no longer necessarily apply and .NET and the JVM look pretty good. I'm writing some Java at the moment for an Android app, and it's just killing me after doing Scheme and Python, but I have to admit, if that start-up had used Java or C#, they might have been better off in the long run. Hiring really good, disciplined people is super, super hard. My current thought is that if you don't have a super-star CTO who can attract and keep real A+ coders, don't use advanced languages. And if you do have that CTO, do it, but make sure you are architecting to make the rewrite in C# or whatever doable when you sell your company. If I were starting my own business now, I'd use Clojure or Scala or F#, and design things so that in 5 years new owners had a decent path to switch to C# or Java wherever they want.

rantwasp 6y ago
> I'm writing some Java at the moment for an Android app, and it's just killing me after doing Scheme and Python, but I have to admit, if that start-up had used Java or C#, they might have been better off in the long run. that’s a logical fallacy. chances are that if they used Java or C# they might be dead by now (ie it sucks but usually it’s a good problem to have)
- iainctduncan 6y ago
  I know what you're getting at, and I agree with the sentiment very often, most of the time even. But in this particular case, I don't think so, and believe me, I spent a lot a of time thinking about that....
  - miku86 6y ago
    So what are your thoughts?
    - iainctduncan 6y ago
      Uh hard. First, maybe don't buy companies with bad technical debt, just start from scratch? And always prefer two experts to 10 juniors in the beginning even if you move more slowly at first. I don't know what would have worked well in that particular situation, but if I were to do it again and could influence the original team, I'd use Clojure. I believe the immutability and control of side effects would have been more of a benefit than types. That was where the real problems came from, dynamic ability to create out-of-sight side effects and alter data in unexpected ways all over the damn place. Clojure's immutability plus spec would have been way better.
vips7L 6y ago
> I'm writing some Java at the moment for an Android app, and it's just killing me after doing Scheme and Python Android isn't Java though. It's some frankenstein contraption made from a mutated version of Java from a decade ago. > I were starting my own business now, I'd use Clojure or Scala. I personally wouldn't ever choose Scala for anything. It's tooling is horrible (Sbt is a special hell, and scalac is as slow as a C++ compiler). I'm currently in a code base like you describe, scala core with a switch to Java. It's not fun. Were stuck with these legacy library and framework choices that don't fit into the Java ecosystem and it slows down development considerably.

denysvitali 6y ago

Exactly my feeling honestly. I was a fan of Javascript and Python a couple of years ago, and I strongly (and still do) hated Java for its verbosity. I really have to admit that, especially with large teams, a strongly typed language is definitely the way to go. I don't feel confident when I program in Python, nor in Javascript exactly for the lack of proper typing. One could argue that if you know exactly what you are doing, types can even be ignored, which is kind of true - but they're there to help the developer and his team. I don't see any good reason to use Python over Golang, for example, if we only consider the language itself and the confidence that you get from using a statically typed language.

crazypython 6y ago

> Everything is a spelunking expedition, and there's no type safety or anything to help you figure it out. For any significant Python codebase, I make sure to put extra effort into precise and strict type annotations so I can rely on type safety. Sometimes after fixing all the statically detected type problems, my program works on the first try. Python was strongly typed from the beginning, before it was statically typed. When you add a string to a number in Python, you get a type error. Python's static type system– which is formally part of the language and has multiple implementations– is an elegant and natural fit to the language. Unlike TypeScript, where the type system is artificial, and restricts what you can do with JavaScript. Language features that made it into ruby– like blocks and unless– were rejected from Python because they would have made it possible to create advanced DSLs, which is something the language maintainers aim to avoid– enabling the creation of arcane application-specific special languages. PEP-484 is the static type system's name: https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/ (implementations include mypy and Pyre)