I like python, its a nice simple language that you can use to pump out a proof of concept real quick with little hassle, but for full on production I avoid it. But I think this is a larger trend in programming, in my opinion the majority of programmers are super lazy. Everyone is in a mad dash to get the cool new thing out so they just slap a bunch of dependencies on it and damn the consequences of developer debt down the road. More people would rather roll with an MVP as the final product than build something from scratch that's more robust, resilient, and efficient. Then after a while you have this huge mess of old broken code that can't be fixed anymore and just needs to be redone from scratch.
Sure you are going to need to redo code anyways from scratch eventually. But, programmers like I mentioned, which is surprisingly a huge chunk, make problems worse for themselves throughout the lifetime of the code by being short sighted and stamping their approval on code their too lazy to rewrite because their boss doesn't know any better.
Its more expensive trying to fix broken code and working around other work arounds that should not be in production. Slows you down, bloats your code, makes it harder for new employees to learn the system when they come on board, etc.
Is the quality of the dependencies you use really so bad that it'd take you more time to fix them than to write your own code and then fix that?
Like I can see where I'd make that tradeoff, but it'd have to be a small function in a really niche use case, which isn't really that common. (I work on the JVM though and don't know how good/bad Python libraries would be in general.)
Well it matters when you roll it out at scale. I suppose client side you don't have to worry too much. I think it's still a bit lazy but it doesn't have too much of an impact on small projects. But, as an example, the last company I worked at we made a neural network engine from scratch because we were just not happy about the available frameworks, their heavy dependency usage, and their very specific requirements of os and language versions. In our tests while I was there, we were able to get 3 times the speed up against the fastest framework of the ones we tested, which was Tensorflow. A lot of the speed up came from just taking good programming practices into account and knowing the system in and out and potential weak points. That's how much the dependencies were killing the speed. Since I've left, that's one of their main things now, just making high quality machine learning modules that get the best bang for their buck.
So yeah, I'd say the dependencies are pretty bad. It's a process outside of your control and you kind of just have to deal with whatever is under the hood. More importantly though, what's under the hood was likely meant to be general purpose and there is more than likely a better way to do it for your particular situation. And as she mentions a lot of the bugs are indefinitely there so you just have to have permanent workarounds, which is never good.
Oh definitely. I think though, for whatever reason, python has quite a bit more of it than most. I think that's probably partly because of how fast it has been adopted and rolled out.
Recently started using Go a little, and it does feel better but it just takes longer for me to write (probably because it's newer to me too). At work, people want things quickly. I'd love to be able to spend my time writing things properly in Go, but it's just not as quick and easy as Python is.
This is entirely anecdotal, but my experience has been that many people espouse the speed of Python development when in fact they put out sloppy, non-production ready code that needs a ton of extra review, effort, and sprints to get up to snuff. I often find myself producing higher quality, production ready Python code than those who cling to it like a safety blanket and complain non-stop about how "slow" languages like C#, Go, and TypeScript make them.
On top of that, I believe that I am able to produce production ready code in other languages even faster than Python! Particularly when it comes to doing refactors for exploratory architecture in early POC/MVP; love the tooling assists so I'm not drowning in "is not a functions" and other dumb stuff while I'm working on hammering out interfaces, abstractions, and other structure.
Granted, I have almost certainly not worked with the best Python programmers, or the best programmers that happen to only use Python to put it another way. But looking at Python itself, the languishing ecosystem and stdlib, and every large OSS Python project, what does that even look like?!
So, I would say that yes it has a lot to do with familiarity and comfort... I'm very suspicious of people who insist on using Python and have little familiarity with anything else.
You can have a messy MVP, I always start with some half baked MVP. But if you roll with that as your product you're shooting yourself in the foot a million times down the line. MVP should be the discovery phase and then after you know and understand the problem you should just build the thing from scratch. It saves you a bunch of pain down the road. If it took you 1 or 2 months to build the MVP it will take you half or less that time to recreate it from scratch. You understand the problem completely and most of it will be you just retyping from memory say in data oriented design rather than object oriented. So really there is not too much effort required after you have defined the problem and solution. So yeah, it has nothing to do with ego, it's just a reality of working on projects other people's companies will be relying on.
If a programmer is lazy, forcing him to use Java or C++ isn't going to fix it. And I've seen good developers ship plenty of quality code in Python or Ruby.
That's not what I'm saying, what I'm saying is that if there is a known bug in a python library, don't use it and code it from scratch. Especially if your job is to roll it out at a large scale. You could save your company tons of money just by taking the time to do it right. But yeah, you can ship python and ruby all you want. That's fine, but if you are using buggy or broken libraries because you don't want to code one up yourself, then that is in fact not quality and is indeed lazy.
Me personally, for my company I would not hire any contractor making code for me in python. Not because python is inherently bad or unoptimized in all cases, but because I know the general tendency is to use lots of dependencies. Pythons motto over all is easy over hard that has really spread in the community in a not so good way. Like I said though, I use it, I like it, it is awesome for banging out prototypes, but I avoid it for production. There is just to many potholes to the point I would rather just code something from scratch closer to the hardware, which I will admit I do not enjoy xD, but if its what needs to be done, then so be it. There are just a lot of things that I work on where even 5% efficiency could save you thousands.
This is a strange grab bag of ideas. You take Python’s strengths at prototyping and wide support and make them sound like weaknesses. Right tool for the job has been a saying for a while.
Sure you are going to need to redo code anyways from scratch eventually. But, programmers like I mentioned, which is surprisingly a huge chunk, make problems worse for themselves throughout the lifetime of the code by being short sighted and stamping their approval on code their too lazy to rewrite because their boss doesn't know any better.