I can’t understand programming without types - it’s just so weird…
Python is not without types, there are dynamic types.
Sorry to be specific I find it so weird to program without defining what I want in and out of a function
Tests aren’t enough: Case study after adding type hints to urllib3
61–70 of 205 posts
Re: Tests aren’t enough: Case study after adding type hints to urllib3
#62Earlier quoted context omitted.
The main argument for dynamic typing is speed in prototyping but I find that's opposite for me. I'm much more comfortable rapid prototyping and ripping stuff apart when I have a strongly static typed environment telling me what I just broke. Doing radical refactoring often involves just making those changes and then fixing all the IDE or compiler errors until it runs again.
I would argue that the really big benefit of dynamic typing is that it enables a really nice interactive interpreter shell experience. I think it's also important from a prototyping standpoint that Python's static typing model does a lot of inference -- you don't have to add an explicit type annotation on every single variable.
This is possible with statically typed languages with Haskell being one of the examples where it's encouraged to use the REPL to work towards a solution and/or qucikly test ideas without having to write unit tests or full program tests. Ocaml and friends fall within this category too and none require extensive type annotation due to type inference.
I feel that too much focus is on static languages like C/C++ where types become a chore and judging it on that rather than looking at the plenty of languages with type inference brought by ML-style languages.
Re: Tests aren’t enough: Case study after adding type hints to urllib3
#63Honestly will never go back to languages without type checking, it prevents so many bugs and is a huge help in understanding code you haven’t worked with previously.
I've been a types advocate for years, but it wasn't until working with Typescript that I started experiencing some of the downsides... To me, ideally, types are supposed to be a benefit not only in safety, but in understanding the intent of a piece of code more quickly. For an api or library interface, review the types to see what its intentions are. But there's something about the typescript type system, with all th…
> with all the picks and keyof and typeof...
Depends of course a lot on the codebase but all typescript codebases that I've seen so far and considered "well-maintained" didn't really use keyof and typeof all that much. The only way I can imagine how one ends up with lots of those keywords is when you start with a dynamic language approach, and then tell the compiler afterwards what that type might be, instead of defining the type beforehand - might that be the issue?
Re: Tests aren’t enough: Case study after adding type hints to urllib3
#64Earlier quoted context omitted.
I have to agree, I've done over 5 years of C# and then went to ruby and never looked back. Static type checking raises the floor on incompetence, but also lowers the ceiling on excellence. I have to admit I don't have experience with the extremes which would be Haskell and Clojure. The amount of cruft I had to type in C# just to get shit done... It's all implicit in ruby thank god for that. I never EVER have to check…
How in the world does type checking lower the ceiling on excellence?
Tbh I'm conflating multiple things, I've heard a lot of good things about Haskell.
But in C# for example, if the system was not designed with dependency injection and everything being an interface it's very hard to build a test harness since you can't mock anything. Which means everything has to be tested manually. (I haven't done any C# in a long time, maybe it's not the case anymore)
So you have to create an interface and classes for every implementations for every type in the system just so I can change its type dynamically. By the time you're done with all the cruft, you forgot what you were about to code.
I'm infinitely more productive in Ruby compared to C#. But I can understand dynamic languages not being welcoming to juniors, since they can code themselves into pitfalls that will bite them later.
Re: Tests aren’t enough: Case study after adding type hints to urllib3
#65Honestly will never go back to languages without type checking, it prevents so many bugs and is a huge help in understanding code you haven’t worked with previously.
> Honestly will never go back to languages without type checking, it prevents so many bugs and is a huge help in understanding code you haven’t worked with previously. I see static types as one of the most powerful communication tools around, as far as code goes. I can't relate at all to people complaining that they waste time. They must work very differently from how I do, is all I can figure. It's that, or they don…
Consider these 4 possible combinations for programming languages:
(1) Low-level, static types
(2) Low-level, dynamic types
(3) High-level, static types
(4) High-level, dynamic types
For whatever reason, historically #1 and #4 have been most popular. C, C++, Pascal, Ada, and Java are #1. Python, JavaScript, Perl, and BASIC are #4.
There haven't been a lot of #2 or #3 languages. Some #3 languages (TypeScript and Python with types) have come along, but relatively recently.
A person who experiences only #1 and #4 might notice that they can whip up programs faster in a #4 language than in a #1 language, then falsely attribute that difference to the static types. Whereas the real reason is working at a different level of abstraction.
Re: Tests aren’t enough: Case study after adding type hints to urllib3
#66I've only been in the industry for ~15 years, but it still feels like every year, some ecosystem discovers the value of something that another ecosystem has taken for granted for decades - type-checking, immutability, unidirectional data-flow, AOT-compilation, closures, pure functions, you name it. I'm glad we seem to be converging on a set of best practices as an industry, but sometimes I wish we were spending less…
I think the problem is to figure out what the best practices actually are. What we are observing here is „the market fixing it“. The process is messy and redundant, but effective.
[deleted]
Re: Tests aren’t enough: Case study after adding type hints to urllib3
#67Earlier quoted context omitted.
I’ve done everything from Haskell to Java and I still strongly prefer Clojure and Common Lisp-style dynamic types.
I have to agree, I've done over 5 years of C# and then went to ruby and never looked back. Static type checking raises the floor on incompetence, but also lowers the ceiling on excellence. I have to admit I don't have experience with the extremes which would be Haskell and Clojure. The amount of cruft I had to type in C# just to get shit done... It's all implicit in ruby thank god for that. I never EVER have to check…
>I always know its type just by looking at its name.
Do you ever feel the names are getting too verbose and it would be great to have tooling that would allow you to get that information on mouse-over instead of having it make your lines almost unreadable?
I mean, there's a reason mathematics have decided to keep variable names short instead of having the names contain all the context.
Re: Tests aren’t enough: Case study after adding type hints to urllib3
#68I love static typing/type hints if for only 1 thing - code maintenance. Even code I wrote six months ago. Not having to dig through 6 functions deep to try to figure out whether "person" is a string, or an object, and if it's an object what attributes it has on it etc. is huge. And not to mention that some clever people decide - hey, if you pass a string I'll look up the person object - so you can pass an object or a…
> I hate having to waste time figuring out the type of every variable and hold it in my head every single time I read a piece of code. If a codebase doesn't have static types, it damn well better be set up to be highly grep-able. Including dependencies and frameworks. This is why Rails pisses me off so much. No static types to help you out, and you can't grep (can barely google, even!) methods and properties that are…
> ... grepable ...
This is so important.
It is also the reason why I like global variables. They are accused of making a spaghetti mess but ... in my experience the opposite is true.
Fancy patterns are way worse to reverse engineer than simple flat long functions accessing globals. Easy to debug too!
Re: Tests aren’t enough: Case study after adding type hints to urllib3
#69Earlier quoted context omitted.
I’ve done everything from Haskell to Java and I still strongly prefer Clojure and Common Lisp-style dynamic types.
Is it possible to elaborate in a comment? Honestly I probably wouldn’t take the time to read a lengthy article, but if there’s some elevator pitch then I’m all ears.
What makes CL/Clojure really work is that your editor (emacs usually, but there’s other options now) connects to the live program and has access to the entire runtime environment. So, you can do a lot of the things other languages need static types for via introspection (e.g. autocomplete: CL just asks the running program what functions are available that matches the current pattern and returns a list).
Secondly, since I’ve learned statically typed languages, I already have a mental model for how they make you structure your code, except dynamically typed languages make patterns easy that would require something like dependent types to check (see how complicated Typescript is, because it has to be able to model JS idioms). My experience is that a lot of the value of static types isn’t in the checking but in the modeling aspect: if you follow the general patterns you’d use in Haskell (represent algorithms like “apply a function to each member of the list” as functions), you reduce the amount of thought it takes to see the program is correct by splitting it up. For example, if I have this pattern in my imperative codebase:
let result = []
for (let idx = 0; idx const inc = v => v+1
. . .
return list.map(inc)
Now, if this is true, why do I prefer dynamically typed languages? Well, it comes down to two things: I find the "live programming" model of CL/Clojure more productive and roughly equal to types when it comes to checking correctness (and I don't think it's just me, I've seen various papers, etc. that claim Haskell and Clojure have roughly equal defect rates); and, I find the patterns I like in CL/Clojure/Javascript require much more sophisticated type checkers to actually validate, and such type-checkers have a huge up-front learning cost and still add a lot of boilerplate that exists mainly to convince the type-checker that you know what you're doing.
Finally, in a language with macros, you can roll your own static guarantees: one project I worked on was doing a bunch of calculations inside a database. We hit an edge case where the DB's idea of a week didn't match our requirements. As a result, I wrote a code generator that generated Clojure functions and DB queries simultaneously. In this situation, if you assume the code generator is correct, you have a compile-time guarantee that the Clojure versions of the queries are equivalent to the calculations being done inside the DB.
[1]: This page surveys a bunch of studies on the question of dynamic v. static types and finds the evidence in favor of static types to be surprisingly small https://danluu.com/empirical-pl/
Re: Tests aren’t enough: Case study after adding type hints to urllib3
#70Earlier quoted context omitted.
I want type checking on pretty much anything that will ever exceed about two screenfuls of code. If I can't keep the whole thing in my head at once, I want the computer to do it for me. That's the point, right? Making computers do stuff for us so we don't have to?
I kindof think of them as a giant set of unit tests. The compiler/linter etc. can check every variable and every function call to check to make sure you didn't mix up your types, which _will_ blow up at runtime if you got them wrong. So rather than write them all by hand, just get your tools to do it.
I see them as documentation of what I think something means or is, which the computer can check for accuracy (more or less), both as I write and as the codebase changes.
That legibility to the computer is what makes them much better than documenting the same thing some other way. Are they out of date? Were they wrong to begin with? The computer will tell me, no action needed on my part. I need to look up something in the context of what I'm reading right now—oh, look, the computer just told me exactly what I needed.