Actually, the reason why I found static typing annoying in the past (and why I felt more productive in Python) were the types are really low level (missing basic things like tuples) and lack of type inference. You have to repeat the type information, a lot. And also you have to declare lot of intermediate data structures.
In Python, this became easier and one could focus on the data transformations, thinking about the code a level higher.
But then I learned a bit of Haskell 5 years ago, and with type inference, this problem goes away. So it convinced me back to benefits of static typing. (Although I still feel the most productive in Python, their library APIs are IMHO unmatched in any language. But Haskell is catching up.)
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).
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.
> 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.
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".
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.
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.
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.
> 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.
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.
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.
> 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.
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.
I appreciate that you wrote that you "feel" more productive with python. I 100% agree with this feeling at most scales of code size, and the feeling matches reality at the small scale. However, I've found that this feeling of productivity doesn't match reality in the large. I use Haskell for programming in the large despite this feeling of unproductivity, because in fact, I am way more productive.
Just to clarify, I agree that Haskell can be more productive than Python, I was talking about productivity of Python (or, for that matter, Lisp) compared to C-like languages of the era. But with Haskell's type inference, the Python's advantage is lost (if we forget, for a moment, extremely well-designed Python's standard library with focus on convenience).
C++ cannot have non-local type inference due to, you know, object-oriented part of it.
This means that you cannot say something like this:
auto sepulka;
auto bubuka = zagizuka(sepulka);
Because if zagizuka's parameter is a structure or a class, you have a selection of parents. On a contrary, you have a selection of descendants of the result type of zagizuka() for bubuka, each having their own copy or assignment constructor.
[1] shows how hard it is to make right type system with inheritance. I believe these slides mention 25 years of collaborative effort. Compare that to [2] where it took 8 years to design intuitionistic type theory (1971-1979) by mostly single person.
C++ doesn't have type inference at all which I understand requires constraint solving.
It has a much simpler type deduction system where the type of an object is deduced from its initializing expression, i.e. deduction always flows in one direction.
It is nowhere as powerful, but it does cover a lot of use cases.
One advantage (in addition to the ease of implementation) is that, except for circular definitions, there are no undecidable cases and it is not necessary to restrict the type system to prevent them.
would infer the type of zagizuga as some object that implements two methods `doSomething()` and `doSomethingElse()`... i think that should be doable (and possibly extremely slow) right?
Yes, it is doable, but what if there several memory-layout incompatible classes which implement both methods?
E.g, A implements virtual doSomething() and B and C inherit from A, add some different fields and both implement doSomethingElse() which they should overload for their inheritance from class Z.
good question, i guess it depends on the language... multiple inheritance without namespacing would either result in either method getting chosen randomly, or a build error...
for example, in swift you cant even inherit from two protocols that have default implementations... and i think in c++ you also cant call the method without specifying namespace...
so, i suppose, if you wanted to go all the way, you could even do namespace inference
so zagizuga is infered to be some type that inherits from `Something` namespace and expects that namespace to defined `doSomething()` function, in addition to providing `doSomethingElse()`
though that seems getting a bit fragile irl maybe...
I have zero problems using type inference, tuples, etc in my code. Other developers I deal with and who do use C++ have no problems using those "novel" concepts either. So I am completely at loss about what type of culture you are talking about here. It looks like grasping at a straw type of argument to me.
I'm talking about all libraries and books written since it's development up until the early 10s; and of all those teams, libraries, and code which are legacy.
Haskell has never had a decades-long history of 'compiler-oriented programming', ie., excessive declarations, and so on.
The idea that C++ has a haskellish culture is patently absurd, even if the vanguard regard itself as presenting tending toward that direction.
I am in no way implying that "C++ has a haskellish culture". Neither I would consider it of any advantage. All I said is that modern C++ programmers have no problems using the concepts. There is plenty of those that are used in gobbles of libraries as well. Sure old libraries do not have it but so what?
Hmm, what do you mean? Haskell is generally considered nominally typed (or rather types introduced by its newtype and data declarations are ...). "Structural typing" typically refers to things like polymorphic row types and polymorphic variants.
It is complicated. Templates do allow some form of structural typing and the new-in-C++17 structured bindings do allow for decomposing and inspecting types (although this being C++ it is kind of awkward). Structured bindings are expected to evolve into full pattern matching in the future.
Nope you don't, that's what typedefs are for. They're underrated for sure though. People don't use them nearly as much as they should. They're incredibly valuable for avoiding precisely this problem.
I thought the complaint was about the logic duplication, not the extra keystrokes. If you want type inference you already have auto. If you want to minimize your keystrokes, you're using the wrong language to begin with, whether there's type inference or not. C++ is designed for writing software robustly, not quickly. (<-- This is not a trivial or obvious statement btw. It took me several years to grasp this. And I viewed C++ from an entirely different perspective when it finally sunk in for me that I would appreciate C++ much more if I decided to make minimizing keystrokes a non-goal.)
No, I'm saying even in that case you know it was intended to be a copy. If you wanted that to be a reference then you'd either (a) just do the obvious thing which is to just use the original variable name instead of creating a new variable out of the blue for no reason, (b) leave a comment explaining why you're not doing the aforementioned obvious thing, or (c) use a self-explanatory variable name to provide the explanation instead of a comment.
Is it really that painful to write "String" each time? You spend at least a fraction of a second anyway to verify that you're writing the right thing, to reconsider if you should use an object or constant or refactor the function to work with a Boolean instead of a naked string; why is writing out the type such a big deal everytime this topic comes up?
I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors.
> Is it really that painful to write "String" each time?
I find it more painful to read code that has too many type annotations. I also find it painful to read code that has too few, so I'd argue there's a bit of an art to it.
But languages that have type inference but allow type annotations at least allow you to try to hit that balance.
> I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors.
Type inference doesn't make these errors go away.
And about your other point, it's unfair to look at just a simple case of writing "string" or not as the only thing inference provides. Although I'd argue that leaving out types where possible helps readability-- it's really the more elaborate cases or intermediate steps during a longer transformation that inference helps with. Not to mention the fact that inference in closures is also really nice.
To me it's not the trivial cases like this that make type inference useful. It's when you get longer types like `Arc<Mutex<HashMap<String, String>>>`. Granted, that could be solved with a `type` declaration (or `typedef` in C++) but it's still convenient to be able to say: `let mut x = Arc::new(Mutex::new(HashMap::new()));` and let the compiler figure out the rest based on usage.
And it's my experience that that is only a benefit to the person who wrote the code, and only for a short time.
Generally, I prefer being able to read a line of code and understanding exactly what it does. If I need an IDE and have to repeatedly try to find the definition of something then, in my opinion, that's wasting my time.
C++'s 'auto' is really useful but it's over-used IMO. I think that there's a belief that if you're not using 'auto' everywhere then you're not writing 'modern' C++. Just becuase your code compiles doesn't necessarily mean it's correct.
I find that types can reduce readability as well as enhance it. They add noise and make it harder to concentrate on the variable names which are often much more important than the types which are often (but certainly not always) obvious from context.
I guess it partly depends on how varied your types are. In some domains you can find yourself working with 10 variables that are all strings, or all floats/integers. At that point the type isn't that helpful for distinguishing which variable is which.
Code that specifies types instead of using auto is, barring compiler bugs, usually less correct. The compiler knows better than you what the type really is.
Shifting topics a bit, typedefs don't allow me to write generic code. Templates do, but templates bring in their own problems, in addition to not being expressive in the right ways: I can have an array of T, but I can't specify that T is Numeric?
The fact C++ doesn't have Numeric but instead has int and long and unsigned and long long and float and double all off on their own is another problem: The compiler knows enough about them to have complex promotion rules but doesn't know enough to allow me to refer to all of them under one name in my code.
You're asking for the impossible. What you want is precisely what templates are, but you also want them to not be "templates" for... some bizarre reason.
> I can have an array of T, but I can't specify that T is Numeric?
Sure you can. If you have C++20 concepts:
template<class T>
concept Numeric = std::integral<T> || std::floating_point<T>;
template<Numeric T>
T twice(T x)
{ return x + x; }
Probably not a good idea since the caller won't know what the return type is at that point, and the return type would become dependent on the implementation, which breaks function abstraction.
And imagine what would happen when you get a few more 'auto' variables in the return expression. Suddenly your return type will depend on the implementation of your callees. And the code can then quickly become impossible to understand.
It might be common practice but it shouldn't be. There are lots of reasons this is a bad idea; here's just a sampling:
1. "My return type is whatever I happen to return" circumvents the ability of the type checker to ensure correctness.
2. More generally, the purpose of a specification (a function declaration in this case) is to declare what is required of a compliant implementation, and to provide a way to check the validity of that implementation. But when you make the types all become auto-deduced, you're basically reducing the specification to a ~ shoulder shrug "it does whatever it does" ~.
3. Moreover, as I alluded to in the comment, it quickly becomes near-impossible to meaningfully separate the definition from the declaration, whether that's because you want to hide it or because you want to compile it separately. Simply put, you lose modularity. It seems like a minor thing when (as in the example) the return value doesn't depend on types inferred from other callees' return values, but as soon as that ceases to be true, you suddenly tie together the implementations of multiple functions. At that point, your functions lose much of their power to abstract away anything, since as soon as you change the return expression for one function, it has the potential to break code (up to and including causing compilation errors) in the the entire chain of callers. (!)
4. Templates end up getting re-instantiated far more often than they need to be (which can slow down both the compilation and the runtime efficiency). You almost certainly don't want '0' and '(size_t)0' to result in duplicate instantiations when dealing with sizes, for instance.
5. Issue #4 can also result warnings/errors/bugs, since now you have a function that returns a different concrete type than you likely intended, which can result in everything from spurious warnings (signed/unsigned casts, for instance) to actual bugs (later truncation of other variables whose types were inferred incorrectly as a result).
6. The code becomes difficult for a human to read too. You now no longer have any idea what types some variables are supposed to be. Not only does this hamper your ability to cross-check the correctness of the implementation itself (just as with the declarations, in #1) but unless your function is trivial, this quickly makes it harder to even understand what the code is doing in the first place, never mind what it's supposed to do.
7. Proxy types become impossible to implement, since they won't undergo the intended conversions anymore.
All this just to reduce keystrokes might be a common trade-off, but a poor one.
I can come up with more reasons, but hopefully this gets the point across.
edit: I see dataflow beat me to it. I'll leave this here anyway.
> I can have an array of T, but I can't specify that T is Numeric?
This is what type-traits and 'concepts' are for, right?
> The compiler knows enough about them to have complex promotion rules but doesn't know enough to allow me to refer to all of them under one name in my code.
In Python, this became easier and one could focus on the data transformations, thinking about the code a level higher.
But then I learned a bit of Haskell 5 years ago, and with type inference, this problem goes away. So it convinced me back to benefits of static typing. (Although I still feel the most productive in Python, their library APIs are IMHO unmatched in any language. But Haskell is catching up.)