Time to delivery is important. Moving quickly withing a language and frameworks that prioritise speed over safety gets a product out the door is important when testing whether a business idea holds merit. Once you’re established with a better scope of the project you should be rewriting this in a static language.
Dynamically typed interpreted languages should never be used for long term support imo
Idunno, Ruby was my first language and the other day I was trying to write a one-file script to wrangle some CSV data and even that got irritating. What does this function need? What does it return? Who the fuck knows! Is it even a function? Run it and find out, loser
And I’ve got reasonably popular projects in ruby, I’m not a beginner.
Yeah I completely agree with you, but sometimes there are other things that jankier languages allow you to do. Say in python, you can do direct property assignment. This is gonna be annoying for someone later to figure out why their object has suddely changed, and without getters and setters, you’ll have a harder time picking apart what’s going on. The benefit though is that it’s very quick to just tack on a property onto some global object and then have that read elsewhere down the road.
It sucks, and you will curse yourself later, like you don’t even know what type it is, or maybe it’s just null, however it did allow you to ship a project. Maybe that bodge solution is indicative of needing a complete overhaul on how you structure your project, but until you get to that point where you’ve scoped out what the final idea looks like, it might not be time for static typing and good code design.
I also think that static typing and such makes you move a lot slower when making changes. I love rust to bits, but maintaining an old project is like wading through treacle. I only jump towards using it now once I’ve got a really great understanding of all the needs of the system, and have the time to really think about the problem in its entirety. Maybe you suddenly need a mutable self in somewhere that you didn’t before, perhaps that means going and refactoring a whole load of traits that were designed without mutability (for good reason).
Why make fun of it though? If you make typing and being checker-clean mandatory on a Python project, you get most of the benefits of static typing. The biggest hole is if the libraries you’re using aren’t properly type annotated. Perhaps I’d feel differently if the meat of my projects was the use of badly or un-typed packages, but thankfully it isn’t.
I would rather have a statically typed language with equivalent clarity, ease of use and extensive libraries, but the benefits of Python along with comprehensive, enforced type annotation are strong. Proper thread handling could be good, but since that forces you towards avoiding monolithic executables, and using asyncio (which is a delight to use), it’s almost a benefit.
Dynamically typed/interpreted language?
I’ve never understood why so many languages insist on a feature that causes such a obtuse and tedious programming experience.
Python is great, until you don’t remember a function call, and can’t guess using your LSP to tell you. :/
Time to delivery is important. Moving quickly withing a language and frameworks that prioritise speed over safety gets a product out the door is important when testing whether a business idea holds merit. Once you’re established with a better scope of the project you should be rewriting this in a static language.
Dynamically typed interpreted languages should never be used for long term support imo
Idunno, Ruby was my first language and the other day I was trying to write a one-file script to wrangle some CSV data and even that got irritating. What does this function need? What does it return? Who the fuck knows! Is it even a function? Run it and find out, loser
And I’ve got reasonably popular projects in ruby, I’m not a beginner.
Yeah I completely agree with you, but sometimes there are other things that jankier languages allow you to do. Say in python, you can do direct property assignment. This is gonna be annoying for someone later to figure out why their object has suddely changed, and without getters and setters, you’ll have a harder time picking apart what’s going on. The benefit though is that it’s very quick to just tack on a property onto some global object and then have that read elsewhere down the road.
It sucks, and you will curse yourself later, like you don’t even know what type it is, or maybe it’s just null, however it did allow you to ship a project. Maybe that bodge solution is indicative of needing a complete overhaul on how you structure your project, but until you get to that point where you’ve scoped out what the final idea looks like, it might not be time for static typing and good code design.
I also think that static typing and such makes you move a lot slower when making changes. I love rust to bits, but maintaining an old project is like wading through treacle. I only jump towards using it now once I’ve got a really great understanding of all the needs of the system, and have the time to really think about the problem in its entirety. Maybe you suddenly need a mutable self in somewhere that you didn’t before, perhaps that means going and refactoring a whole load of traits that were designed without mutability (for good reason).
Or bolt MyPy to it, right?
Edit: Wow. Somebody out there has no sense of humor about their bolt-on type solution.
Hey its better than nothing? Haha
If performance isn’t an issue, I’d take it over nothing for long term support
Yeah. I live to make fun of MyPy - or rather of Python for needing MyPy, but it’s “good enough” in many situations.
Why make fun of it though? If you make typing and being checker-clean mandatory on a Python project, you get most of the benefits of static typing. The biggest hole is if the libraries you’re using aren’t properly type annotated. Perhaps I’d feel differently if the meat of my projects was the use of badly or un-typed packages, but thankfully it isn’t.
I would rather have a statically typed language with equivalent clarity, ease of use and extensive libraries, but the benefits of Python along with comprehensive, enforced type annotation are strong. Proper thread handling could be good, but since that forces you towards avoiding monolithic executables, and using asyncio (which is a delight to use), it’s almost a benefit.
That’s a good point. I do love options.
I’ll still jest a little at Pythons expense until a type system is natively available.
Having the option of not using types is great.
Having to go discover how to do basic typing in a 3rd party library is not great.
I adore Python, though - Right down to it’s painful Logging modules.