[wonton53]

Great! I am so glad more people see types as a useful tool. Personally I see it as essential, so I struggle to understand the mind set of people who do not want to use them. I understand that people think it feels like a lot of work, but that is like nothing compared to the 90% of time people who dont use types spend on reading logs and fixng the same issues every day. I assume people have some sort of amnesia and thinking «oh the value was undefined, I have never seen THAT error before», but that is probably just me being bitter. So I was wondering, since you seem like a super-fresh converted;did you have any specific reservations originally, and whas there any specific type of solution to a issue that finally changed your mind?

[cuddlybacon]

> I struggle to understand the mind set of people who do not want to use them.

I've posted a few reasons before. I think I've refined the list slightly since last time:

* People's first exposure to programming often came from using C++ or Java. An old version with really crappy type errors. Schools are often conservative about updating their tech stacks.

* Types are most useful when reading or changing code. New learners are mostly writing new code.

* Writing `Person person = new Person()` seems highly redundant. In the kinds of small programs you are writing as a newbie, you are likely to write a lot of this.

The reasons so far make types seem like overhead: you are having to do more work and getting little in return for doing so. The next two get a bit deeper.

* In the small codebases you'll have as a newbie[0] at disproportionate amount of the codebase is interacting with the outside world. The outside world is untyped. In both typed or dynamic languages, you have to shuttle this untyped data into your language's type system. But when there is a type error in this process, I find it is generally easier to debug in a dynamic language. That makes sense to me: they need to have good workflows for dealing with runtime type errors.

* Classes tend not to teach technique[1]. Students are expected to invent it on their own as they learn programming. As professionals, we often don't teach technique to each other either. If you invent techniques that leverage the strengths of types, then the appeal of types will seem pretty obvious. If you don't you may go years without before you are exposed to these techniques. If you invent techniques where static types get in the way, then you may find static types to be a severe hindrance to getting things done.

[0] I think this also applies a lot of the time when starting a new project.

[1] By technique I mean the steps you do to produce working code. This doesn't just include generating new code, but understanding existing code and debugging code.

[wonton53]

That makes a lot of sense. And I think the lack of teaching technique has to do with the broad variety of programming tasks. Techiques are way too specific to the domain and we won’t see more of it in school until «computer science» is split into more and more fine grained studies or get a bigger part of existing studies like math is now. e.g now I feel embedded, backend and frontend are distinct «directions». In the future I expect it to be further branched into for example finance, healthcare, chemical processing, public infrastructure. This is gradually happening all the time though and «true» computer engineering will always exist, but I think it will be more and more niche just like embedded and OS level programming is more niche now but was the only option before. Anyway I think types are key to making programming safe enough to bring it to this kind of broader workforce (in some distant future, with good IDE support).

[yuy910616]

Glad to share but I'm not sure if I'm representational - I'm a data analyst who is learning more about backend engineering.

I think if you're a SWE or has a CS education or worked with a compiled language before, you know exactly what kind of problem typing is solving. For me, I have to first discover the problem, slowly learn that there is a solution out there, and finally realizing that my problem can be solved by this solution.

The formalization of problem space + the discovery of solutions + the final realization of matching solutions to problems are non-trivial. I'm a bit embarrassed that it took so long and a bit sad. But it is what it is.

[wonton53]

That makes perfect sense actually, thank you for taking the time to answer. And I’m indeed a SW eng with a degree, so spot on. I do something similar to data analysis «for fun»/non professinally but my day job is payment/banking systems. Live payment systems and settlement systems are both very different from analysis tasks. They have all the focus on «correctness» and integration interfaces with other organizations (which are ALWAYS wrong because «they» don’t understand types/strict interfaces). While analysis in my experience is dealing with tons of dirty data sources not in real time or the code will even just run once (not millions of times). I always go to cleaning the input and validating the data, but I suspect that is because of my day job and i feel it is less valuable to put in this effort than it is for my day job. So I have myself also skipped using types many times to learn whatever library I need or to iterate quicly (minutes compared to days). For example, it is very comfortable to just let pandas give you 0 for NaN when you just want a plot. So I understand it takes more time because the value of types is probably much lower to you in absolute terms.

[TheGuyWhoCodes]

> I struggle to understand the mind set of people who do not want to use them

It usually comes from people who never had experience with statically typed languages, don't work on projects with a large dev team, cross teams projects or work with a lot of 3rd party libraries. They don't realize the maintenance nightmare that types can easy.

Sure you write one off script, or something that is rarely run don't use types, but when you have a 50k lines codebase that is actively developed and maintained it's another story.

I'm so glad Typescript changed that mindset of frontend developers and is supported by a lot of prominent open source projects

[caturopath]

That might be where it usually comes from, but that hasn't been my experience. My Python subcommunity groupthink was against type annotations for years, despite the groupthink also saying that statically typed are better all things equal and most of the loudest folks having worked for some FAANG company.

Thinking that typing is good and buying that a pasted-on-after-the-fact typing system is good are different matters.

[yuy910616]

In my experience, it was quite jarring to see a python function with a bunch of : -> Union[int,str], Optional, Any, etc.

Change is always hard.

[takeda]

I actually don't understand Optional in that mix. "Optional" basically means the value can be "None". You typically use it like this "Optional[str]" which means the value is a string or "None".

[wonton53]

Very true, but there is a gradient there. I have an example of the opposite extreme. A few years ago I worked with a person who would rather continue working in php 5.3 than start using Scala, which was hot at the time. He literally copy-pasted an old project instead of starting a new one in Scala (or ANY other language, this was a payment system and php does not even have strong enough crypto support in old versions). And I can tell you for sure he had at least 1 year exposure to Scala and doing at least 1 full project. His reasoning for copy-pasting old php: He was «just too stupid to understand Scala». It is an extreme example, but most people I met who dont like strong typing fall into that category (lazy? Certainly not stupid) and I just dont know what to say to them or what to think myself to accept them or even how to use whatever hidden powers these people have other than creating circular dependencies for the company by making obvoius mistakes they themselves spend most of their time fixing. Im not actually bitter, just frustrated that so many seem to just not care.

[acdha]

A lot of it depends on the work you do, and what other kinds of tools you use. If you’re working with simpler code and use something like flake8 or have a reasonably fast test cycle, you can be pretty productive either way. If you work with harder-to-type data structures (e.g. nested JSON or XML), you’ll see less wins from typing then validation (this is why Django apps tend to have fewer issues this way because the database validation reduces the amount of data motion before something validates it).

That’s not to say that typing isn’t useful - I use it daily, especially since VSC has made it a lot faster than mypy - but I do think the Python community is wide enough that you can find people legitimately saying it is or isn’t a big deal for them as a function of where they work. You also have a certain amount of PTSD from languages like Java which make typing far more labor intensive and through some combination of limited expressiveness, dynamic logic, and culture end up making the benefits less than anticipated.

[wonton53]

I can absolutely see that there are many cases where the code is not run many times or the dataset is dirty and that types actually get in the way. As a example, I cannot stand using stuff like VSCode with lsp because it is unbearably slow for both linting and code completion. I feel pycharm is faster (actual typing is slow, but code completion makes me rarely type more than 3 characters before completing which makes it feel faster). I’m mentioning this because I would never dream of typing out a data structure, which is probably because my work is so different from an analysis job. For me code for data structures should be either generated or be simple enough to type out in a few minutes and there should be as few as possible of them. In sharp contrast to data engineering type of work where data just is dirty because it is so much of it from everywhere. Anyway, in both cases I dont want to type a full variable name without some completion, ever, much less 100 times which it seems some people are completely fine with. I’m showing my inexperience with python here, but I would love if there existed something like the F# type providers so I do not have to type so damn much:D

[Mehdi2277]

One of the pycon type talks was about type checking json. TypedDict or pydantic can both be used to deal with that fairly well now. For a complex json sure the type might be long but write it once and used the typeddict name after that. It feels similar to needing to write protobut def/thrift def. Some of the json I even work with is given a spec with protobuf and loaded that way which gives you type support. protobuf can generate python type stubs with mypy-protobuf. One practical annoyance is many libraries that use protobuf generated code don't currently include type stubs with them. I currently just make the stubs myself, but that is something most people would probably get stuck on and just needs more libraries to update the build scripts to include them in wheels.

XML could have a similar approach although I'm not sure if anyone has done it already.

Second talk (30 minute mark) of this video, https://www.youtube.com/watch?v=ld9rwCvGdhc

[acdha]

Yes, I use pydantic for that and it’s quite helpful - one of my favorite libraries in recent years. I do think your last point is key: this seems to be a community maturity point because a fair fraction of people will bounce off of a bad first experience and say it’s not worth the cost.

[jpalomaki]

If you don’t have really flexible type system, strong typing makes certain things complicated.

Think for example a library like Pandas. Building something like that with a not-very-flexible type system would result in much more cumbersome user experience. In many cases you would likely feel the types just getting on your way while working interactively.

Microsoft has done great things with C# on this frontier, but it has also taken many years and probably a lot of brainpower.