471–480 of 581 posts
This also works for humans, but many python programmers who learned python before type hints can't be bothered. :sad_panda:
Earlier quoted context omitted.
There are downsides. But the upsides outweigh the downsides. I'm not a consumer of APIs. I've done game programming, robotics, embedded system development (with C++ and rust), (web development frontend with react/without react, with jquery, with angurar, with typescript, with js, zod) (web development backend with golang, haskell, nodejs typescript, and lots and lots of python with many of the most popular frameworks…
You are wrong. I learned programming mostly in C++ in the late 90's, and programmed in C, C++ and Java in professional settings for a decade or so, and still do from time to time.
I'm founding a company that is building an AOT compiler for Python (Python -> C++ -> object code) and it works by propagating type information through a Python function. That type propagation process is seeded by type hints on the function that gets compiled: https://blog.codingconfessions.com/i/174257095/lowering-to-c...
Earlier quoted context omitted.
> The extra typing clarification in python makes the code harder to read. It depends what you mean by "read". If you literally mean you're doing a weird Python poetry night then sure they're sort of "extra stuff" that gets in the way of your reading of `fib`. But most people think of "reading code" and reading and understanding code, and in that case they definitely make it easier.
As someone who has read code as easily as English for decades (which is apparently rare, if my co-workers are any indication), too many type annotations clutter it up and make it a lot harder to read. And this is after having used Typescript a lot in the past year and liking that system - it works well because so much can be inferred.
Earlier quoted context omitted.
> Not bolt on a sort of type system which actively fights against the way I use the language on a day to day basis. Can you help me out with an example of a Python usage pattern against which the type system seems to be fighting?
Ok, so this is just one of many examples but the most immediate one is where I don't care about the immutable sanctity of the variable I have just declared. I often use Python for data munging and I'll frequently write code that goes foo = initial_value ... foo = paritally_cleaned_up_value ... if check: foo = fianllylikethis else: foo = orlikethis Where the type of the value being assigned to foo is different each ti…
Earlier quoted context omitted.
Would you? Why? Python has a great experience for a bunch of tasks and with typing you get the developer experience and reliability as well.
No you don't. You get the illusion of static types without the actual upsides. For any even medium sized project or anything where you work with other developers a statically typed language is always going to be better. We slapped a bunch of crap on Python to make it tolerable, but nothing more.
Earlier quoted context omitted.
> C as it’s written by middling teams is a soup of macros, three-star variables, and questionable data structure implementations, where everybody fiddles with everybody else’s data. I’ll take good C over bad Python, but good C is rare. Ironically, the worst production C written in 2025 is almost guaranteed to be better than the average production Python, Javascript, etc. The only people really choosing C in 2025 are…
> The only people really choosing C in 2025 are those with a ton of experience under their belt, who are comfortable with the language and its footguns due to decades of experience. Experienced users of C can't be the only people who use it if the language is going to thrive. It's very bad for a language when the only ones who speak it are those who speak it well. The only way you get good C programmers is by cultiva…
I don't think it's going to thrive. It's going to die. Slowly, via attrition, but there you go.
Earlier quoted context omitted.
Well, we do coalesce on certain things... some static type languages are dropping type requirements (Java and `var` in certain places) :D
var does absolutely nothing to make Java a less strictly typed language. There is absolutely no dropping of the requirement that each variable has a type which is known at compile time. Automatic type inference and dynamic typing are totally different things.
dynamic x = "Forces of Darkness, grant me power";
Console.WriteLine(x.Length); // Dark forces flow through the CLR
x = 5;
Console.WriteLine(x.Length); // Runtime error: CLR consumed by darkness.
C# also has the statically typed 'object' type which all types inherit from, but that is not technically a true instance of dynamic typing.
Earlier quoted context omitted.
> I didn't. I've been mainly a Python, PHP and JavaScript programmer for ~25 years Maybe its time you expanded your horizons, then. Try a few statically typed languages. Even plain C gives you a level of confidence in deployed code that you will not get in Python, PHP or Javascript.
I find automated tests give me plenty of confidence in the Python code I deploy. I'd rather deploy a codebase with comprehensive tests and no types over one with types and no tests. I've been dabbling with Go for a few projects and found the type system for that to be pleasant and non-frustrating.
With Python, PHP and Javascript, you only option is "comprehensive tests and no types".
With statically typed languages, you have options other than "types with no tests". For example, static typing with tests.
Don't get me wrong; I like dynamically typed languages. I like Lisp in particular. But, TBH, in statically typed languages I find myself producing tests that test the business logic, while in Python I find myself producing tests that ensure all callers in a runtime call-chain have the correct type.
BTW: You did well to choose Go for dipping your toes into statically typed languages - the testing comes builtin with the tooling.