8 ms·
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 basi
by js8 6y ago
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.)
- jcelerier 6y ago> the types are really low level (missing basic things like tuples) and lack of type inference how far ago was this in the past ? C++ had tuples and type inference for ten+ years officially now - gcc 4.4 had it in 2009
- mjburgess 6y agoThere's also the culture around the language to fold in. A culture of writing code assuming inference and structural typing is quite different than it merely being available.
- sfg 6y agoSo, OCaml or something? Or has Haskell added structural typing?
- mjburgess 6y agoHaskell is structurally typed...
- tome 6y agoHmm, 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.
- mjburgess 6y agoSure, my mistake. I meant something looser. Only that the types can be analysed structurally (ie., pattern matched). In C++, etc. there's a "radical nominalism" in which the type was very opaque, ie., encapsualated.
- gpderetta 6y agoIt 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.
- FpUser 6y agoI 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.
- mjburgess 6y agoI'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.
- FpUser 6y agoI 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?
- thesz 6y agoC++ 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] http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%20Simula%20User%20%28ECOOP%20Prize%29.pdf http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%... [2] https://en.wikipedia.org/wiki/Intuitionistic_type_theory#Martin-L%C3%B6f_type_theories https://en.wikipedia.org/wiki/Intuitionistic_type_theory#Mar... [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.
- gpderetta 6y agoC++ 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.
- andrekandre 6y agonot that im advocating it per se, but couldnt you deduct the tyope based on what `zagizuga()` does with `sepulka`? for example def sepulka(zagizuga) zagizuga.doSomething() zagizuga.doSomethingElse() 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? maybe i missed something...
- thesz 6y agoYes, 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.
- KingOfCoders 6y agoI'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 agoIt 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 agoI 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 agothere are controlled studies supporting this idea the function parameters not having types slows down productivity
- tome 6y agoIt would be helpful if you linked them ...
- mehrdadn 6y ago> You have to repeat the type information, a lot. 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.
- nicoburns 6y agoThat doesn't stop you having to type e.g. String foo = "bar"; String baz = foo; The `String`s can be completely avoided in languages with type inference because it's obvious that a string literal is a string.
- oblio 6y agoJava now has (limited) type inference, bar. As does C++, auto. They're limited but they remove a lot of tedium.
- mehrdadn 6y agoI 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.)
- secondcoming 6y ago> If you want type inference you already have auto or auto&&. Did you really intend to make a copy?
- mehrdadn 6y agoYou probably did intend it to be a copy if you're binding it to a variable and need it to be non-const (like in the example)!
- WraithM 6y agoI 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.
- js8 6y agoJust 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).
- bcrosby95 6y ago> in the large At what point do you feel like this line is crossed? "In the large" can mean different things to different people.
- WraithM 6y ago100k+ lines