4 ms·

I've joined several companies, and getting into a Python code base was the most difficult one, because of the lack of typed method parameters. It was easier wit

I've joined several companies, and getting into a Python code base was the most difficult one, because of the lack of typed method parameters. It was easier with Java and better still with Scala - same for Typescript vs. Javascript. I would be interested, is your Python experience green field or joining a large project? (just wanting to know, not implying anything on your part).

js8 6y ago
It was an experience on my personal projects, cca 20 years ago. That's when I started using Python and it really felt more powerful than C++ (and Java) back then. Then around 2008 I became interested in Common Lisp, and then later I made the choice to learn Haskell instead of Clojure. It took me a while before actually getting where is the improvement in Haskell and functional programming. This was all for my own personal projects, which are small programs. I would still recommend against using Python on a big project. Funny thing, I remember talking to my boss (a mainframe programmer) in 2010, when I solved something with a script in Python, that I wouldn't use it in production, but it's great for small things. Forward to 2020, plenty people use it in products. Maybe the Haskell will be the same, you also have many people today saying "well this is good for experiments but I wouldn't write a product in it".
jim-jim-jim 6y ago
I had the exact same experience: being a new employee at companies A and B, with large Python and Scala codebases respectively. At company B it was far easier to get on board and start writing code, and it has remained easy. Trying to make sense of Python was truly demoralizing, and a significant part of why I left company A.
gameswithgo 6y ago
there are controlled studies supporting this idea the function parameters not having types slows down productivity
- tome 6y ago
  It would be helpful if you linked them ...
mumblemumble 6y ago
I bounced off of Python a few times before finally taking to it (at a time when I had no choice). I honestly believe that this situation has improved since Python 3.5 or so, purely on the basis of improved standards of documentation, including many more libraries adding type hints to their public interfaces. I've recently been back to Clojure, and it's the same old aggravation again. It seems that, oftentimes, the only way to know what arguments a function is prepared to accept is to already know what arguments a function is prepared to accept. I don't want to come across as being too down on dynamic typing - I'm currently in the process of trying to get my company over to Python by any means necessary. What I really want to challenge is the idea, popular in many dynamic typing circles, that static types just get in the way. They can also serve to communicate essential information. If you aren't communicating that information through type annotations, then it's absolutely essential that you do it by some other means.
- ithrow 6y ago
  I don't want to come across as being too down on dynamic typing - I'm currently in the process of trying to get my company over to Python by any means necessary. Curious, from what and why? ML?
wassenaar10 6y ago
> getting into a Python code base was the most difficult one, because of the lack of typed method parameters Yup, this is probably my main issue with Python. I love writing it when I'm working on personal projects, having to read massive Python code bases at work feels unnecessarily tedious due to how much work you have to do sometimes just to find out the type of something.
neutronicus 6y ago
I worked on a large-ish C++/Python codebase and touching the Python parts was always extremely frustrating for me. The lack of .h files alone is a huge grievance for me - I had to scroll past definitions even to know names and arities of class methods, read constructors to know what's in class members. SciPy was nice enough for turning data into a picture, though.
- supergarfield 6y ago
  > The lack of .h files alone is a huge grievance for me That's an interesting point... Besides C and its derivatives, and OCaml, do other languages have separate definition files? It seems like newer languages, even statically typed, normally don't. I suspect the reason is that you have to duplicate all definitions, which seems like rote work. It also feels less necessary with IDE tooling: IDEs I know have a view for all definitions in a file.
  - mumblemumble 6y ago
    They don't, but, at least in object-oriented languages, much of overall experience is easy enough to replicate with formal interfaces and coding standards.
    - KingOfCoders 6y ago
      I thought the nice thing about Modula-2 was that you could browse through interface files to understand some code and then go into implementations.
      - mumblemumble 6y ago
        It's true, but there are so many ways to skin that cat. Smalltalk, for example, gives an even more fluid way to browse at a high level and then drill in, and it doesn't (necessarily) have source code files in the first place.
mattnewton 6y ago
For new python work that might grow, I highly recommend pytype annotations. It’s not perfect but it’s as close to the best of both worlds that I have ever seen in production.
dehrmann 6y ago
> getting into a Python code base was the most difficult one, because of the lack of typed method parameters One place I worked used to be a Python shop, but had migrated most of its services to Java. Chatting with one of the engineering leads for a large Python system that had a lot of business logic, he said where Python actually fails to scale is lines of code and developers because lack of types makes it harder to reason about and harder to make changes safely. This obviously changed now that type annotations are a thing.

js8 6y ago

It was an experience on my personal projects, cca 20 years ago. That's when I started using Python and it really felt more powerful than C++ (and Java) back then. Then around 2008 I became interested in Common Lisp, and then later I made the choice to learn Haskell instead of Clojure. It took me a while before actually getting where is the improvement in Haskell and functional programming. This was all for my own personal projects, which are small programs. I would still recommend against using Python on a big project. Funny thing, I remember talking to my boss (a mainframe programmer) in 2010, when I solved something with a script in Python, that I wouldn't use it in production, but it's great for small things. Forward to 2020, plenty people use it in products. Maybe the Haskell will be the same, you also have many people today saying "well this is good for experiments but I wouldn't write a product in it".

jim-jim-jim 6y ago

I had the exact same experience: being a new employee at companies A and B, with large Python and Scala codebases respectively. At company B it was far easier to get on board and start writing code, and it has remained easy. Trying to make sense of Python was truly demoralizing, and a significant part of why I left company A.

gameswithgo 6y ago

there are controlled studies supporting this idea the function parameters not having types slows down productivity

tome 6y ago
It would be helpful if you linked them ...

mumblemumble 6y ago

I bounced off of Python a few times before finally taking to it (at a time when I had no choice). I honestly believe that this situation has improved since Python 3.5 or so, purely on the basis of improved standards of documentation, including many more libraries adding type hints to their public interfaces. I've recently been back to Clojure, and it's the same old aggravation again. It seems that, oftentimes, the only way to know what arguments a function is prepared to accept is to already know what arguments a function is prepared to accept. I don't want to come across as being too down on dynamic typing - I'm currently in the process of trying to get my company over to Python by any means necessary. What I really want to challenge is the idea, popular in many dynamic typing circles, that static types just get in the way. They can also serve to communicate essential information. If you aren't communicating that information through type annotations, then it's absolutely essential that you do it by some other means.

ithrow 6y ago
I don't want to come across as being too down on dynamic typing - I'm currently in the process of trying to get my company over to Python by any means necessary. Curious, from what and why? ML?

wassenaar10 6y ago

> getting into a Python code base was the most difficult one, because of the lack of typed method parameters Yup, this is probably my main issue with Python. I love writing it when I'm working on personal projects, having to read massive Python code bases at work feels unnecessarily tedious due to how much work you have to do sometimes just to find out the type of something.

neutronicus 6y ago

I worked on a large-ish C++/Python codebase and touching the Python parts was always extremely frustrating for me. The lack of .h files alone is a huge grievance for me - I had to scroll past definitions even to know names and arities of class methods, read constructors to know what's in class members. SciPy was nice enough for turning data into a picture, though.

supergarfield 6y ago
> The lack of .h files alone is a huge grievance for me That's an interesting point... Besides C and its derivatives, and OCaml, do other languages have separate definition files? It seems like newer languages, even statically typed, normally don't. I suspect the reason is that you have to duplicate all definitions, which seems like rote work. It also feels less necessary with IDE tooling: IDEs I know have a view for all definitions in a file.
- mumblemumble 6y ago
  They don't, but, at least in object-oriented languages, much of overall experience is easy enough to replicate with formal interfaces and coding standards.
  - KingOfCoders 6y ago
    I thought the nice thing about Modula-2 was that you could browse through interface files to understand some code and then go into implementations.
    - mumblemumble 6y ago
      It's true, but there are so many ways to skin that cat. Smalltalk, for example, gives an even more fluid way to browse at a high level and then drill in, and it doesn't (necessarily) have source code files in the first place.

mattnewton 6y ago

For new python work that might grow, I highly recommend pytype annotations. It’s not perfect but it’s as close to the best of both worlds that I have ever seen in production.

dehrmann 6y ago

> getting into a Python code base was the most difficult one, because of the lack of typed method parameters One place I worked used to be a Python shop, but had migrated most of its services to Java. Chatting with one of the engineering leads for a large Python system that had a lot of business logic, he said where Python actually fails to scale is lines of code and developers because lack of types makes it harder to reason about and harder to make changes safely. This obviously changed now that type annotations are a thing.