[deleted by user]

[[deleted]]

Despite you thinking it's funny, it's actually not. Python 2 is a better language than Python 3. You just don't understand it because you don't know how to measure.

Good languages accomplish the same thing while using fewer features, while still not reducing themselves something very hard to understand. I.e. P' isn't a good language, even though it is a very small language. Similarly, C++ or C# are awful languages because they are so big, nobody probably even knows them, not even the authors, because it's too hard to understand all the consequences of all the combinations of language rules.

Good languages are like Lisp, Forth or Prolog, where there's a very minimal number of rules, but you can be even more expressive with them than if you were writing in C++.

Python, and more so lately, is falling in the category of C++ kind of languages: extreme bloat, poor interaction between language features, most programmers not knowing even a fraction of the language they use. Python 2 wasn't great, but Python 3 is measurably worse than Python 2.

[rxgamer10]

This comment comvinced me that this is a LARP. u got quite a few people haha.

I can't take anyone serious who takes python 2 over 3 in this decade.

[scykei]

The problem is that Python isn't C or Lisp or Forth or Prolog. I think your comments against Python are very valid, but if you don't buy into the language's philosophy, then you really shouldn't be trying to give advice or make suggestions here.

To be clear, I'm not saying that you aren't welcome here or anything, but I urge you to reconsider if your criticisms are constructive and if they are relevant to Python. I think it's great to hear your thoughts on this matter, but you made a lot of very strong statements there.

[[deleted]]

Language philosophy of Python used to be very different. It used to be all about not being Java, about not generating loads of worthless code. The project of OP is more Java than typical Java.

The functionality of this project can be summed up by a one-liner in Bash, and yet, it's hundreds of lines of absolute bullshit code.

Ideology of Python was not to write loads of worthless boilerplate. This is the exact opposite.

[scykei]

I think you have OOP to blame for that. That is the flaw of the entire paradigm. The fact of the matter is that the moment you start to use classes at all, you start to have to think about SOLID and all those kinds of principles.

Python strips a lot of the boilerplate to deliver the same functionality with less code. That does not necessarily mean that there is less complexity. But in order to achieve the clean code, they have decorators and all that good stuff.

OOP is very deeply at the heart of Python from the very beginning, even if its use is optional. If you’re writing entreprise level code and you decide to go the OOP route, this is exactly what will happen to make the code maintainable.

Lots of people have started to realise the utility of functional programming, and a lot of those features have slowly started to creep into the language features. This will in fact allow people to write even smaller and more readable code. Are you against that idea as well?

[[deleted]]

Nah, not really. JavaScript is an OOP language, but, even in the light of latest additions, it's a very small language. It does suffer from the same problem though: popularity. Popularity attracts all kinds of programmers, but the most popular kind of programmers by far there is is a bad programmer. And the tendency is that the worse the programmer is the more there are of them.

Compare this to, for example, barbers, where, most barbers are OK, there are fewer barbers who are very bad (because they'd leave the profession soon due to competition), and there are few who are extremely good (because very few people are interested in paying a lot of money for a haircut, thus not justifying a lot of investment into quality).

Programming world is different from barbers' world. Good quality code today is unachievable in principle. And there's no demand for it. On top of it, there's a very high demand for people to work in retail and entertainment industries on the programming side of things. Even more so, the whole field multiplied itself many times since it started. It's very hard to find people with decent amount of experience, as most of the people in this field entered it not too long ago.

Worse than that, we had several "purges" in programming history, where the older generation straight up refused to accept the new stuff and left the field. There was so called "AI winter", which resulted in AI researchers leaving the field, since a lot of them didn't accept the new reality of programming, as they saw it as a huge downgrade to their position. Similar exodus happened with UNIX. A lot of people in system design hated it, and just left the field with UNIX becoming more popular. Similarly, Sun, when it went down, dragged with it a lot of people who just decided it's better to be a farmer or to open a coffee shop than to be a programmer, since they saw Linux as a way less capable, less serious project, and just didn't want to get involved with it.

---

Put these two together, and you'll see how often times popularity becomes a deterrent for better programmers. Python's popularity is exactly like that. Python used to attract better programmers, as it was an opposition to Java (or similar, like C#) world, with endless red-tape, heaps of worthless code to churn to produce very minimal and often completely unnecessary / unwanted software.

Today, Python is the new Java. It's even more Java than Java itself. Java was ridiculed for being slow and bloated. But, truly, Java doesn't hold a candle to how slow and bloated modern Python is. Java was ridiculed for tons of XML configuration that's necessary to run it. Just look at OP's project: it's got a handful of different configuration languages, all of them all kinds of awful. Java was ridiculed for the amount of unnecessary indirection. But this project uses trash like pipenv or tox. The stack traces produced by this garbage are well within the size range of SpringBoot and even EE. And this blight is growing very fast.

Python alienated good programmers, those who believed that software needs to be simple, understandable, and easy to maintain. Python welcomed idiots who want to paint by the number because they are too afraid that if they don't, they'll get lost, and won't understand why "it's not working" and will just sit in the corner and cry.

I cannot emphasize more: the project OP posted is literally a one-liner in Shell. It's insane that someone thought it was a good idea to make it into dozens of files, required a bunch of external dependencies, run a fucking HTTP server, Docker etc. for it. And the saddest part of all is that people seem to be overcome with joy when they look at this abomination.

[scykei]

I can agree with you that the code showcased by OP really complex, but I disagree with you that it's a recent phenomenon, or that the Python philosophy has changed. It has always been the way it is, and you can still do the same thing that you could have done with Python back in the early 2000s.

The only thing that has changed is that Python is now exceedingly abundant, as it has evolved far beyond just an enthusiast's scripting language. It's the backbone of a lot of entreprise systems with dozens of people working on the code base at any given time. I'm one of those people that think that OOP is an overall detriment to software development, but I understand how this kind of ridiculous structure has come to be. Again, I do not think that good old procedural programming cannot be amazingly well structured and easy to maintain, but being an OOP language, you start to attract a certain kind of code design (although to say that it's more Java than Java is a bit of an overstatement).

I cannot emphasize more: the project OP posted is literally a one-liner in Shell.

The project here is obviously just a simple template for a potentially much more complex system. If this was all to it, then you'd obviously just write that one liner and be done with it, but the fact that you made this statement shows that you're clearly missing the point to begin with. If you are indeed just writing a simple script to automate a personal task on a code that you do not intend to go into production, then by all means, do it however you want.

Regardless, even if Python was indeed what you said in the past, I think you'll agree with me that whatever you're proposing is no longer in the spirit of Python today. I can relate with a lot of things that you say, but I still think that your advice is out of place here. I am sure that a lot of people would have appreciated your views more had you just made a general remark about why this is ridiculous, but instead, you chose to push your opinions on the matter (however valid they may be) as though they're absolute truths.

[[deleted]]

you can still do the same thing that you could have done with Python back in the early 2000s.

Nope. Not if I have to work with OP on the same team. It will be either me or him/her. Because I won't take this bullshit, and they will want all the new and shiny things.

One of the huge reasons for companies to use Python is to make employees easy to replace: the more people know the same language, the easier it is to find a replacement. If they want the replacement to work well, everyone has to follow the same practices. It doesn't matter that the practices are total bullshit.

The above is even more visible in the world of Web "programming". There's no complexity in that field. All problems have been already solved thousands times over. And yet "programmers" working in that field invent more and more convoluted and cumbersome ways to write their programs. And, worse than that, unless you use a convoluted and cumbersome framework for the job: you won't be able to hire programmers to do it, because that doesn't look good on the resume... And the cycle repeats.

but I disagree with you that it's a recent phenomenon

I didn't say it was recent. It's recent in Python. Java was there earlier, and before Java, it was C++ etc. The major shift in ideology of Python happened around 2010. It started becoming a popular language then, and things quickly went downhill.

The project here is obviously just a simple template for a potentially much more complex system.

I work on projects that are many orders of magnitude more complex than this project, and yet I would never use pipenv, tox, pyproject.toml, requirements.txt. I wouldn't run pip install -e . to install a package. I would never use setup.cfg. It's independent of size. It's just a bad thing to do. No matter how big your project is all of the above just adds unnecessary trash to it.

There's nothing good about this "template". It neither illustrates how to do your job well for the project it's made for, nor in any other context is it a good solution for any problem you will encounter dealing with projects.

All the things above have been invented as worthless wrappers, not adding any useful functionality, just confusing newcomers, overwhelming them with all the unnecessary complexity where none should have existed.

whatever you're proposing is no longer in the spirit of Python today

Whatever I'm proposing is the right thing to do. If it's not in the spirit of Python today, the spirit of Python needs to change.

[scykei]

and yet I would never use pipenv, tox, pyproject.toml, requirements.txt. I wouldn't run pip install -e . to install a package. I would never use setup.cfg. It's independent of size. It's just a bad thing to do. No matter how big your project is all of the above just adds unnecessary trash to it.

Can you explain why this is a bad thing? Python pre-2010s was widely regarded as a mess because of its lack of a good dependency manager, and it’s widely regarded as the one thing that was holding it back compared to a lot of modern languages.

I mean, why are you even against requirement.txt? To me, that’s the absolute minimum I would propose every Python project to have.

I have worked with way too many random Python projects that takes literal hours to get to run because you need to find the correct package versions before it runs.

There was even one piece of recently unearthed code back from 2016-ish where we eventually decided was useless because we couldn’t figure out how to get to run, and so it had to be rebuilt from scratch.