…is it truly that bad? npm is the reason I don’t even install software based on node on my machines… python doesn’t seem nearly as bad by comparison? (I run it, just don’t like to write it) Maybe it’s worse than I realize
I haven’t used npm. But pip is horrible. Some times I’ve used a well-known library that only works on linux, but there is no mention of it whatsoever, and it installs without problem. The error only happens at run-time (not even when importing!) and says nothing about platform-dependency. I only learned that it was a linux-only library because I happened to try running it on a Linux machine to see if it worked.
Many times you have to set up your environment a specific way (environment variables, PATH, install dependencies outside of pip) for it to work, and there’s no mention of it anywhere. Sometimes you install the library with pip, sometimes with apt, and there is no way to know which one. And sometimes the library is both in apt and pip, but the pip one does nothing.
Furthermore, good luck importing a library. You might have installed it with “pip install my-library” but to import it you have to do “import MyAwesomeLibrary3”. And pip won’t tell you about that.
Wow that sounds like a headache, even though I’ve avoided python for other reasons that sounds like an additional reason to do so. Also the reason I avoid npm isn’t for a technical reason like you’ve outlined here. It’s because even installing npm requires me to install an entire other Linux distros worth of packages. Why do I need to install like 100+ new packages just to use a freaking package manager???
Perl is the only language that looks just as incomprehensible before and after a rot13 transformation.
Python on the other hand is the only language that will cause your application to stop working because you mixed up tabs and spaces, even though it looks perfectly fine on your scr.
It is absolutely fine to mix tabs and spaces in Python, as long as you are consistent about it. It’s not recommended though, as it’s easy to mess up if you’re not paying attention. Most IDE’s will convert tabs to spaces anyway so it’s a bit of a non-issue.
In Lisp, however, both errors are much harder to make (not even considering GNU Emacs’s superb auto-indentation - which is what most Lispers use these days, as far as I know):
I’ve had very few issues with whitespace in my decade or so of using python, especially since git and IDEs do a lot to standardize it. I’m a Python simp, tho
Among all of them at least python is the choice generically people learn when they don’t want to learn programming, just want to program stuff as a helper tool to manage data. For those, python is just fine and the learning material around is tailored to for that.
That’s how you trick people into programming. You then see people making scripts that take days to run, but it’s fine, they’re only going to use it twice and are busy enough to be able to wait
Teach this to your manager: At the beginning of a task, uncertainty is highest. Under no circumstances should you give an estimate in ‘man-hours’. Even days is too precise. The first estimate should be in months or years (of course depending on the size of the project). Then, as your insight into the project grows, you refine that to months, then weeks, later days. A vague estimate with a lower and a higher bound is way more useful to your manager than a ridiculously ‘precise’ but highly speculative number.
This lesson was brought to you by either “Code Complete 2” or “Rapid Development” by Steve McConnel, and by my former manager who wanted projects estimated in minutes.
A typical project manager will get a range, take the lower bound and communicate it as the only relevant number to every other stakeholder. When that inevitably does not work out, all the blame will be passed on to you unfiltered.
Depending on where you work it may or may not be worth giving someone new the benefit of the doubt, but in general it is safer to only ever talk about the upper bound and add some padding.
I hear this criticism all the time, but I’ve never seen it happen in 5 companies I’ve worked for so far. Usually there’s an understanding that estimates are wild guessing, and things are planned using dependencies rather than timeliness.
My manager once accused me of overinflating my (granted, very conservative) estimates just to be able to pull off a Scotty and be early in 10% of the time.
I don’t know, that mindset is so foreign to me. If someone was overestimating how long it would take because they were simply trying to be conservative and not run into unexpected cost overruns, I would commend them. I’ve always considered it more prudent to expect something to take longer so you know the kind of budget you need up front instead of lying to yourself about it. It costs a lot more (in terms of lost time and productivity) to have to swing a new budget mid-project because it turns out you’ve burned through the planned budget and you’re only 2/3 the way done with the project.
So, screw your manager, you’re doing the right thing, in my eyes. I guess that’s why I’m not in charge of anything.
You know, maybe we shouldn’t be taking estimation advice from a 1980s science fiction movie that amounts to a systematic method of lying.
Yes, I’ve used it before. Yes, you can hopefully have everything average out in the end. Yes, project managers demand estimates. None of these are good reasons to back up how fundamentally flawed it is.
this is my number one thing I hate. So we are going to be converting over one system to another and you have no ideas what issues will pop up. give an estimation on the project. or like estimation onf fixing a bug or doing something you think the software can do but your not real sure till you look into it.
The known unknowns and especially the unknown unknowns never get factored into an estimate. People only ever think about the happy path, if everything goes right. But that rarely every happens so estimates are always widely off.
The book How Big Things Get Done describes a much better way to factor in everything without knowing all the unknowns though - Just look a previous similar projects and look how long they took, take the average and bounds then adjust up or down if you have good reason to do so. Your project will very likely take a similar amount of time if your samples are similar in nature to your current task. And the actual time already factors in all the issues and problems encountered and even if you don’t hit all the same issues your problems will likely take a similar amount of time. And the more previous examples you have the better these estimates get.
But instead of that we just pluck numbers out of the air and wonder why we never hit them.
yeah I have literally had something where I list off a bunch of problmatic stuff and how it could be some high side and then follow up or everything could go swimmingly which never happens and we could have this low side and they are like ok so the low side. no. no. that is not what im saying.
Some people think that because Python is the easiest language to learn, it’s going to be easy to learn programming with Python. But learning programming is still very hard, so many abstract concepts to grasp. Python just makes it a tiny less hard, almost insignificantly now that we can use an LLM to learn the syntax faster than than ever.
It’s also important to note that you might come out ahead in learning those abstract concepts using a harder language.
But my first language was Pascal. from a book stolen from my dad’s library. Then C++. I still wouldn’t call myself anything other than an amateur… I mean, my dad can do more with one line of C than most programmers can do in their entire career. (he really shouldn’t. but he does. Calls it “job security”.)
It’s also important to note that you might come out ahead in learning those abstract concepts using a harder language.
I agree that you will learn more abstract concepts with more low level languages, but they are often not necessary. See Scala, beautiful language, lot’s of fancy subtle computer science concepts, and a plummeting popularity since its main popularizer, Apache Spark, implemented a Python API.
Well. yes. it does strongly depend on what you intend to do with it.
Python is a great language that’s very broadly used; there’s a reason that Apache added the python API; after all. (and why Scala is plummeting.) I wouldn’t even say Pascal was all that useful, to me. I think I ‘learned it’ enough to get through the dumb book, and then went on to something else. C++ was more fun anyhow.
I was hacking scripts and web shit together in perl, python and php for many years before learning C, and just a couple months learning C/C++ made me understand so many more basic concepts than all previous years experiences combined.
Comparing python env management to Ruby or rust or even Java for fucks sake just goes to show that nobody actually cares about how easy a language is to use, they just care about what is popular or what they think is popular.
Ruby, of all the examples you could come up with? My Redmine is updated only every few years because I rarely have a whole day to deal with the mess that is Ruby deps managent.
Development environment is a mess, but given its popularity, it’s not difficult to find an up to date tutorial. Then it is the easiest I think, you will be able to try programming basics and get a minimum viable product (small web app, small analytics…) easlier than with any other language.
Nah, php over python any day. Equally easy to start, equally fucked up core, but the ecosystem around it is so much saner and easier. And I’d argue it’s even easier for beginners.
Unless you need something that only has python bindings, I’d never choose python.
That is because when you’re a beginner, you read everywhere that you should be using anaconda and jupyter notebooks. I know because I did so. Neither of them lasted more than a week on my computer though.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.