Hacker News new | ask | show | jobs
by bragr 1054 days ago
I wish people could be honest and say they don't care for some language or framework or OS for personal or aesthetic reasons, rather than having to round it up to being objectively bad, but then I suppose nobody probably would click on "I don't like Python and have got some nits to pick".

Oh and he just says what is supposed to be quiet part at the end:

>And, not to put too fine a point on it, but if you can code Python but not Go (or another decent programming language), you probably have no business writing software for a living. I know it sounds harsh and I apologize for that, but writing software is a profession and hence you should have the knowledge, skill, and experience to use professional tools.

Hear that all data scientists, flask devs, systems engineers, and ML folks? Python is bad so you should quit. ;)

5 comments

I see this sort of person as an extremely rigid, unbending, dime a dozen type person even if they’re very intelligent. I’m in this business to succeed and build and create things, there is very much an “energetic” aspect and his energy is dead as fuck. It’s a very simple fact that some see it, and some don’t. He’s one who doesn’t, and all those that see it can see it so clearly. He’s most definitely not someone I would want on my team.

The amount of idiotic … implications of his statement is so excruciating it’s physically painful to me. But I encounter this unadaptive unawareness all the time with working with programmers from other teams, etc so I’m used to it.

He published an article in June titled "It is not cool to be unkind!".

Interesting contradiction.

I know someone like that, very energetic, full of ideas, but so stubborn I'm sure it holds him back.

Lol bragr did not offer any ideas, only cranky complaints. Who cares?
Aha, you pointed out the disease.

This is the biggest problem in software and it's kind of intractable.

The ideal world has tools that empower everyone to do what they need to do, which to some extent must include an activity like programming.

But, and this may be unconscious, "people who program for a living" have a strong incentive to gatekeep.

What's amazing is people who program for a living, who people would normally think of as being "experts", have so little knowledge of all the different types of programming that is done by, well, people who program for a living, and the tools they use to do that programming.

Not only then is it gatekeeping, it's also a sign of an inexperienced programmer.

I'll give one thing to Python programmers, they tend to work directly with their end users and build solutions that matter to them. Anyone that's done that kind of work knows it's difficult, regardless of programming language being used.

And arguably, is the more "important" work, or at least the stuff requiring the most attention?

I know that's a tough thing to say -- but yeah, the irony is that a really really good "low-level programmer" is destined for obscurity, because things just work and once they're working people forget about it. Shouts to Linus Torvalds.

You're saying that specialization is bad and that specialists can't be experts.
No. I'm saying people that make these ignorant statements aren't experts.
I see, thanks.
Clearly a Go enthusiast who never mastered Python. And, really, Go? If your were pushing Rust mayyyybe I could give you the benefit of the doubt.
> I wish people could be honest and say they don’t care for some language or framework or OS for personal or aesthetic reasons, rather than having to round it up to being objectively bad, but then I suppose nobody probably would click on “I don’t like Python and have got some nits to pick”.

Yeah, this kind of hyperbolic headline article repeating mostly dead-horse arguments is just low-effort click farming, not a serious contribution to the discussion of anything. All it adds to what is a well-trodden debate is…factual errors, like the claim that Python prominently features “lazy evaluation” (while, as in any language, you can arrange laziness in Python, it is very much eager normally.)

I really think that Python is not a good language for ML, it just got "there" first.

The ecosystem is the real plus, of course. But the language is a headache for this. I agree with the "false economy" angle. I would happily trade the "agility" of dynamic "gluing" with some kind of real type safety, human-readable error messages and performance[0].

[0] - hiding C in Python's clothes doesn't count :)

Python is the de facto glue language with one of the biggest ecosystems out there, that makes it possible to use any kind of over-the-top library that does 1093 things after a single `import antigravity`. Also, ML absolutely makes sense for python, it’s not like most PLs have actual support for video cards — ML is very specifically about manipulating data (a fundamentally dynamic task) and calling out to specific libraries for training, a very glue-task. Give me any language better than python for that.

Quoting Brooks (butchered): “the only significant productivity improvement comes from relying on code that is already written”. Your fancy “better” language has not even 1/10th of what python has, it won’t replace it.

> Python is the de facto glue language with one of the biggest ecosystems out there

I never contested that.

> ML is very specifically about manipulating data (a fundamentally dynamic task)

I disagree strongly with using dynamic languages for data. Data has dimensions, units, types. You need to know that you're not adding coats to horses or USD to EUR. You need to know that you didn't silently sliced by the wrong axis. You may want formal verifications. You may to transform data without worrying about silent errors.

All the "metadata" and wrapper classes ML in Python are just trying to give you what the language can't.

> a very glue-task. Give me any language better than python for that

That's my point exactly. ML has evolved beyond glueing a few C libraries. It needs complex, big programs, which is an area where Python is terrible. Also the different nature of the "glued" components (each with its own data formats, protocols and calling conventions) makes the glue a mish-mash of untyped mixed magic idioms.

Training and using ML is different. It has been relatively common to bundle the trained weights with a different programming language system - but training can be a more exploratory phase, so python is not a bad fit for that.