I'm surprised they didn't mention that Python now has types. Sure, it's not checked at compile time, but your IDE can perform the checks, and you get almost all the benefits you'd get with Go types. I agree that one of the main advantages is the ability to navigate and receive help from the IDE, which is fully covered if you use type hints in Python. The argument about compile-time checks versus mypy/pylance type checking is a separate discussion altogether
Год назад+6
Rust and Go dev here. I never tried Python but worked time ago in Ruby. So I can imagine all the tradeoffs and challenges in big codebases for Python. I'm in favor of compiled static-typed languages for a variety of reasons. However, I also believe that scripting languages are important in several use cases such as scientific computing or embedding just to name a few. For example, I see scripting languages as perfect for prototyping and fast iteration. Great for getting ideas running as quickly as possible and as felxible as possible too.
I like Julia for scientific computing and I think it would be a good fit for other ELT uses too. Dynamic typing with optional type hints and multiple dispatch make for a very flexible system. Efficiencies in the JIT compiler make it pretty fast too, I think somewhere around Go levels.
I think another advantage of static languages, particularly as I've found with Rust, is that those strict constraints that Dr. Green complained about "limiting expressivity" actually challenge your preconceptions and force you to reconsider the path you're taking to your goal. I've often stumbled upon much better ways to design my code by listening to the Rust compiler instead of naively following the path of least resistance as I would in Python. This means you end up spending a lot more time thinking about how to implement something, which can be great if design and quality is a concern. But if you really just need to get _something_ out fast I can see that wouldn't really fly
The dynamic typing discussion was very confused. Your interviewee apparently doesn't know the difference between nominal typing and structural typing, e.g. he doesn't seem to be aware that you can have static typing and duck typing at the same time (e.g. C++ templates). He also states that python will not perform any type checking, but it will -- it's just a structural type check (does the thing I need exist) which happens at the time of use. Also no, you'll never get the same assurances as static typing from unit testing, not unless you have unit tests for every value representable in a given type (which may be an infinite set so good luck). Also, I thought the whole idea was to be more productive, but you're telling me I have to do the compiler's job and write tests to give me guarantees other languages give me for free? Not exactly a sterling value proposition.
I don't think that most people consider the act of the Python interpreter executing like a `PyObject_TypeCheck` at runtime being akin to the typesafety you get in languages like TS and Go, at least in the same manner that we're having this conversation around static vs dynamic typing. You are correct in that this *technically* fits the definition of a structural type check, but caveating this level of semantics here IMO would unnecessarily muddy the water around the actual conversation we were trying to have, which was comparing the dynamicism of Python to a more static language like Go.
@@mgdotdev From the wiki: "Python uses duck typing and has typed objects but untyped variable names. Type constraints are not checked at compile time; rather, operations on an object may fail, signifying that it is not of a suitable type. Despite being dynamically typed, *Python is strongly typed,* forbidding operations that are not well-defined (for example, adding a number to a string) rather than silently attempting to make sense of them." (emphasis mine) This is not some idiosyncratic point of view either; the phrase "python strongly typed" returns 260 million hits, including from the official python wiki. "which was comparing the dynamicism of Python to a more static language like Go." Or to a loosey-goosey language like javascript, which surely is relevant, no? A zen koan: if python lacked type checking, why does the TypeError exception exist?
Unit tests make sense when the unit has domain values and should be tested there for correctness and expectation. Object type assertions come from writing unit tests for these objects is just doing the type-checker's job. I didn't listen to the guest carefully, but I thought it was about something like monkey patching (so not writing static metaprogramming, but just lying to the type checker), which is valid that static types won't play nicely. I have my opinions on monkey patching, but that's a separate topic. At the end of the day, the guest probably thinks that naming is hard - why name a class when I can just write object assertions on terms? Though by the mid of the conversation, I was lost - I thought it was supposedly a conversation between static patching and monkey patching - it seemed like they still talk about proof via tests...
@@mgdotdev You can use Pythons typing.Protocol and a type checker (mypy/pyright etc.) to get the statically checked structural typing that Go interfaces provides.
You just develop with that in mind, it's not any harder than trying to debug a statically typed program. I'm sure you wouldn't be super happy jumping blind into Chromium and debugging that either. It's not much different.
I had to give up half way through. Some of the arguments showed a lack of experience using statically typed systems that take advantage of the benefits while being designed for flexible and anticipatory usage through things like generics. The thought of relying on people to come up with viable tests for things you get literally for free with static typing borders on insanity to me. Sounds like a nightmare.
IMO you will love dynamically typed languages when you start developing but grow tired of them overtime. I don’t think this is wisdom or maturity, I just think statically typed languages give you more pre-runtime feedback that you can fix the afternoon you write up the feature rather than in the middle of the night when prod falls over because some attribute doesn’t exist on an object.
If you don't write tests in dynamically typed or untyped languages, then you'll definitely get those issues. You'll just need to test more, really. Not much more, but there are more tests to be done.
@@master74200 so would you agree that this means with a dynamic language you accumulate technical debt faster that you have to cover with tests, which in turn make it harder to change the design in future as you would need to also update the tests?
@@joshring8563 Not really. There's more tests, but unless you're making a massive monolithic spaghetti monster, you'd just write a couple more tests than usual. Maybe even not more tests than usual either, if you just test what you need to test. Types are useful for the compiler to tell you where your syntax is wrong. Tests are useful for you to tell you where your LOGIC is wrong. Types can make your tests easier to write, but unless you're doing OCaml-level types, you probably don't have THAT big a dependency on them for your business logic itself. I hope.
@@master74200 " Types are useful for the compiler to tell you where your syntax is wrong. Tests are useful for you to tell you where your LOGIC is wrong." Ehh... no. You can encode nontrivial logic in the type system so that it helps ensure that your logic is correct, too. The vast majority of the time when I change something in C++, if it compiles, it works. That's not remotely the experience in something like python.
the idea of a static language being not expressive enough is not a great argument IMO. I guarentee you that he can do every ETL pipeline thing he wants in Go, just with less varied "expression". Rust is more "expressive" than python in my experience and I'm not entirely sure that is an advantage. Rust's macro system is the definition of infinite expressiveness, which will be awesome in 10 yearsfor example when we have the best HTML templating engine stabilized, but for allowing medium tier companies to build their own DSL is probably a bad idea.
His argument for struct vs python object/class is not a statically typed vs dynamically typed comparison makes no sense. it is an argument for OOP vs Procedural programming. People shouldn't compare Go with Python. Python is OOP and the way to write Python is not even close to how you think in Go. Please compare Python with C++ or Java if you wish to compare static typed vs dynamic typed languages from OOP perspective. Please have proper understanding of languages before you compare stucts with classes. They are inherently different. Its like comparing cheetahs with crocodiles and telling that crocos can't run at 100kmph so they are inferior.
I'm surprised they didn't mention that Python now has types. Sure, it's not checked at compile time, but your IDE can perform the checks, and you get almost all the benefits you'd get with Go types. I agree that one of the main advantages is the ability to navigate and receive help from the IDE, which is fully covered if you use type hints in Python. The argument about compile-time checks versus mypy/pylance type checking is a separate discussion altogether
Rust and Go dev here.
I never tried Python but worked time ago in Ruby. So I can imagine all the tradeoffs and challenges in big codebases for Python.
I'm in favor of compiled static-typed languages for a variety of reasons.
However, I also believe that scripting languages are important in several use cases such as scientific computing or embedding just to name a few.
For example, I see scripting languages as perfect for prototyping and fast iteration. Great for getting ideas running as quickly as possible and as felxible as possible too.
I like Julia for scientific computing and I think it would be a good fit for other ELT uses too. Dynamic typing with optional type hints and multiple dispatch make for a very flexible system. Efficiencies in the JIT compiler make it pretty fast too, I think somewhere around Go levels.
I think another advantage of static languages, particularly as I've found with Rust, is that those strict constraints that Dr. Green complained about "limiting expressivity" actually challenge your preconceptions and force you to reconsider the path you're taking to your goal. I've often stumbled upon much better ways to design my code by listening to the Rust compiler instead of naively following the path of least resistance as I would in Python.
This means you end up spending a lot more time thinking about how to implement something, which can be great if design and quality is a concern. But if you really just need to get _something_ out fast I can see that wouldn't really fly
Love this vid! Im a pharmacist trying to use CS tools to improve my field so cool to see his perspective
The dynamic typing discussion was very confused. Your interviewee apparently doesn't know the difference between nominal typing and structural typing, e.g. he doesn't seem to be aware that you can have static typing and duck typing at the same time (e.g. C++ templates). He also states that python will not perform any type checking, but it will -- it's just a structural type check (does the thing I need exist) which happens at the time of use.
Also no, you'll never get the same assurances as static typing from unit testing, not unless you have unit tests for every value representable in a given type (which may be an infinite set so good luck). Also, I thought the whole idea was to be more productive, but you're telling me I have to do the compiler's job and write tests to give me guarantees other languages give me for free? Not exactly a sterling value proposition.
I don't think that most people consider the act of the Python interpreter executing like a `PyObject_TypeCheck` at runtime being akin to the typesafety you get in languages like TS and Go, at least in the same manner that we're having this conversation around static vs dynamic typing. You are correct in that this *technically* fits the definition of a structural type check, but caveating this level of semantics here IMO would unnecessarily muddy the water around the actual conversation we were trying to have, which was comparing the dynamicism of Python to a more static language like Go.
@@mgdotdev From the wiki:
"Python uses duck typing and has typed objects but untyped variable names. Type constraints are not checked at compile time; rather, operations on an object may fail, signifying that it is not of a suitable type. Despite being dynamically typed, *Python is strongly typed,* forbidding operations that are not well-defined (for example, adding a number to a string) rather than silently attempting to make sense of them."
(emphasis mine)
This is not some idiosyncratic point of view either; the phrase "python strongly typed" returns 260 million hits, including from the official python wiki.
"which was comparing the dynamicism of Python to a more static language like Go."
Or to a loosey-goosey language like javascript, which surely is relevant, no?
A zen koan: if python lacked type checking, why does the TypeError exception exist?
Unit tests make sense when the unit has domain values and should be tested there for correctness and expectation.
Object type assertions come from writing unit tests for these objects is just doing the type-checker's job.
I didn't listen to the guest carefully, but I thought it was about something like monkey patching (so not writing static metaprogramming, but just lying to the type checker), which is valid that static types won't play nicely. I have my opinions on monkey patching, but that's a separate topic.
At the end of the day, the guest probably thinks that naming is hard - why name a class when I can just write object assertions on terms? Though by the mid of the conversation, I was lost - I thought it was supposedly a conversation between static patching and monkey patching - it seemed like they still talk about proof via tests...
@@jimhrelb2135 Yeah it was all a little discombobulated imo
@@mgdotdev You can use Pythons typing.Protocol and a type checker (mypy/pyright etc.) to get the statically checked structural typing that Go interfaces provides.
Thanks for this episode and these interesting discussions @you two! 🤘
JDSL?? Does Tom work there???
Tom is a genius
Gotta love Tom he’s a genius.
Python is cool if you code alone. But, in a team trying to debug Python code that you didn't wrote... Damn
You just develop with that in mind, it's not any harder than trying to debug a statically typed program. I'm sure you wouldn't be super happy jumping blind into Chromium and debugging that either. It's not much different.
I had to give up half way through. Some of the arguments showed a lack of experience using statically typed systems that take advantage of the benefits while being designed for flexible and anticipatory usage through things like generics. The thought of relying on people to come up with viable tests for things you get literally for free with static typing borders on insanity to me. Sounds like a nightmare.
IMO you will love dynamically typed languages when you start developing but grow tired of them overtime. I don’t think this is wisdom or maturity, I just think statically typed languages give you more pre-runtime feedback that you can fix the afternoon you write up the feature rather than in the middle of the night when prod falls over because some attribute doesn’t exist on an object.
If you don't write tests in dynamically typed or untyped languages, then you'll definitely get those issues. You'll just need to test more, really. Not much more, but there are more tests to be done.
@@master74200 so would you agree that this means with a dynamic language you accumulate technical debt faster that you have to cover with tests, which in turn make it harder to change the design in future as you would need to also update the tests?
@@joshring8563 Not really. There's more tests, but unless you're making a massive monolithic spaghetti monster, you'd just write a couple more tests than usual. Maybe even not more tests than usual either, if you just test what you need to test. Types are useful for the compiler to tell you where your syntax is wrong. Tests are useful for you to tell you where your LOGIC is wrong. Types can make your tests easier to write, but unless you're doing OCaml-level types, you probably don't have THAT big a dependency on them for your business logic itself. I hope.
@@master74200 " Types are useful for the compiler to tell you where your syntax is wrong. Tests are useful for you to tell you where your LOGIC is wrong."
Ehh... no. You can encode nontrivial logic in the type system so that it helps ensure that your logic is correct, too. The vast majority of the time when I change something in C++, if it compiles, it works. That's not remotely the experience in something like python.
The typing discussion is interesting. That's why you can use type hints and mypy with python.
the idea of a static language being not expressive enough is not a great argument IMO. I guarentee you that he can do every ETL pipeline thing he wants in Go, just with less varied "expression". Rust is more "expressive" than python in my experience and I'm not entirely sure that is an advantage. Rust's macro system is the definition of infinite expressiveness, which will be awesome in 10 yearsfor example when we have the best HTML templating engine stabilized, but for allowing medium tier companies to build their own DSL is probably a bad idea.
His argument for struct vs python object/class is not a statically typed vs dynamically typed comparison makes no sense. it is an argument for OOP vs Procedural programming. People shouldn't compare Go with Python. Python is OOP and the way to write Python is not even close to how you think in Go. Please compare Python with C++ or Java if you wish to compare static typed vs dynamic typed languages from OOP perspective.
Please have proper understanding of languages before you compare stucts with classes. They are inherently different. Its like comparing cheetahs with crocodiles and telling that crocos can't run at 100kmph so they are inferior.