Hacker News Reader

Comment by DeathArrow | Hacker News Reader

> Having had to work in a large pascal codebase, I don't ever want to use this language again.

Maybe Pascal isn't good for large code bases, but the same is true for Python, too. And nobody hates Python.

I hate Python, and I've met others who feel the same.

It's a language which had a reason to exist 25 years ago, but has since been surpassed in every way by other faster, more robust, more compatible languages that don't have such quirky syntax. So a lot like Pascal actually. (To be fair to Pascal, its syntax wasn't anything as inconsistent and frustrating as Python's.)

Python has become the lowest common denominator. It's a practical "no-frills" language that can be picked quickly by a sysadmin, a web developer, a scientist doing number-crunching or a kid automating their homework.

The problem with the “no-frills” proposition is that it’s loaded with frills, complexities, and decades of tech debt. Just installing dependencies for a Python project can feel insurmountable.

IMO JavaScript should be the default for any Python use case. It has the same deceptive veneer of beginner-friendly dynamic behavior, same kinds of footguns; but at least JS has a single package manager, much faster optimized engines, and you’d have to learn it for front-end work anyway so it has long-term dividends.

One of things I really like about Python is the huge standard library. Contrary to JavaScript (which I think is a really weird recommendation), where you need to npm install half the world.

It wouldn’t matter if those dependencies where stable, but JS has a culture of abandon libraries or to make backward-breaking changes every week, so upgrading a project after just a few months is a major pain

That's what I learned when I had to do front-end development using Angular: never upgrade packages.

And you never know if package Y required by package X will break the security of your app.

Having used both Python and JS, the only real benefit the latter has it may be faster.

The language has way too many gotchas. I wish they could shed all the legacy aspects to it. My experience with Python, along with many other folks, is that if we don't know something (API, syntax, etc), we often just guess it and it turns out to be right. Fairly intuitive.

Agree with the other commenter: Using pip + venv tends to solve the majority of packaging problems. In my career I deal with a Python dependency headache once every few years.

> and you’d have to learn it for front-end work anyway so it has long-term dividends.

Except when you don't do front-end work ;-)

Poetry does a good job for package management

I've learned Javascript and a framework or two and I hate it with passion.

I patiently wait for the moment in which we can manipulate DOM from within Weabassembly. Meanwhile I shamelessly push for Blazor for front-end, wherever I can.

Python is absolutely not a "no-frills" language. It is loaded with features, I'd be willing to bet that 99% of python programmers don't know all language features (even relatively old and frequently used ones like metaclasses) and that virtually nobody knows the whole stdlib

Additionally if one cares about performance, knowing C or C++ is also a must.

When was the last decade someone cared about performance?

Apparently everyone that writes native libraries to be called from Python, while calling them Python libraries.

I don’t understand how programming languages can get so much hate. If you don’t like it, don’t use it…

Surely you can appreciate that the language you're using isn't always your choice.

Yes, I do understand that, having programmed in business environments with legacy code for over a decade.

I've hated the poor decisions my predecessors had to make, the corners that were cut. I've hated that it's not maintained or documented. I've hated that it doesn't have tests.

Never have I hated the language.

And that sometimes, you make the wrong choice, and grow to hate that language.

Not always, but the most languages I have used professionally were my choices.

That means x86, assembly, C, C++, C#, Python and half of Javascript. For Javascript I mean half because I enjoyed doing simple things in JS on front-end long time ago, but these days I kind of dislike JS frameworks and I've learned them because I had to after I signed some contracts. I could have stayed 100% with backend work, but now is too late to complain.

I managed to steer clear of Perl, Objective C, Cobol and other languages I don't enjoy. I managed to learn F# and some Ocaml which I would like to use but never got the chance (personal projects excluded).

Most professional programming is done in already existing code and new projects often have to respect existing standards. You rarely get to choose what language to use.

I was recently asked to recommend a language for a new team. My boss (who won't be writing or even reading any of the code) suggested Python. His reasoning: it's what the kids are learning in college these days.

So here I am as the team Senior, looking at current and future team members and deciding on whether to be selfish and choose what's good for me, or trying to figure out what makes something good for the team. Is it better to pick something with a large hiring pool? Is it better to pick something with fewer footguns? Is it better to pick something with higher performance? Is C# really ok if we need Mac support? Is Swift ok for one-off glue apps that run on Linux? Is Zig too young? If a team of five has a Java geek, a Rust zealot, a C# fan, and somebody who only knows Python, can we just agree to all learn and use Go? If I know my replacement will undo whatever I choose, does it really matter?

The safe bet is C#, followed by Go. Swift, Rust, Zig, Python have their problems.

I love Zig and Nim but constantly pick C# or Go.

If time, money, support and performance are not an issue, you can pick anything but I guess someone of the above will always be an issue.

Unless you rewrite it in Rust and link an article on HN.

I think this sentiment underestimates the amount of work people do on existing codebases.

The most reviled languages are often previously loved languages that made writing code easier at the cost of reading and understanding it.

Team 1 secretes reams of instant legacy code, but get money and promotions for shipping it. Team 42 gets handed a steaming pile of manure that is beyond understanding. They then pick up the pitchforks because it is obviously the language's fault.

So, yeah, it isn't the language so much as the average incentives and behaviors around development.

> The most reviled languages are often previously loved languages that made writing code easier at the cost of reading and understanding it.

You claim someone actually loved Objective C or Perl? Or even Scala?

Hahah. I like Objective-C with ARC (in spite of its complexity and limitations), but Swift is more compact and I'm probably never going back (except maybe for hobby projects like writing something for GNUstep.)

I also like how Objective-C++ can mix in C++ code bases. It's an amazing chimera of a language.

That's funny because to me, Perl, is the epitome of a fun write-only language!

> You claim someone actually loved Objective C

The problem with Objective C is that it requires skill. The average developer really is better off using a more remedial language like Swift.

I'm sure at least their "parents" did.

$tongue in @cheek

> but has since been surpassed in every way by other faster, more robust, more compatible languages that don't have such quirky syntax

Pray tell, which ones are those?

Excelscript

> It's a language which had a reason to exist 25 years ago, but has since been surpassed in every way by other faster, more robust, more compatible languages that don't have such quirky syntax.

The same could be said about C++, but yet, here we are. Stroustrop's quip comes to mind: "There are languages people complain about, and languages no one uses". Just look at how much people complain about JS.

I don't know how old people here are, but from the early 2000's till probably the mid 2010's, Python really was the great language, with few alternatives - at least when you consider the libraries available for it.

It's not an accident that people began using it heavily for numerical computing. The only viable alternative at the time was MATLAB.

ISO Pascal isn't, but Object Pascal and Modula-2 definitly are.

Unfortunely most complaints about Pascal keep being reduced to that 1970 version of the language.

Totally agree. Various people seem to be out of touch with modern developments, misinformed, or are being disingenuous (as really advocates for a competing language). A lot of the discussions surrounding Pascal are as if Object Pascal (and its dialects), Delphi, Lazarus, or Oxygene (RemObjects) don't exist or never happened.

Or the seemingly lost successor, Oberon. An entire graphical OS and compiler was written in, and completely documented, in a book: "Project Oberon: The Design of an Operating System and Compiler" [0]

[0] https://people.inf.ethz.ch/wirth/ProjectOberon/PO.System.pdf

Do you consider Modula-2 to be a Pascal?

But yes, modern stuff should not be judged by the 1970 edition. I got soured on Pascal by having to use an ISO standard compiler on an embedded system; it was painful in several areas. But I shouldn't judge modern C by pre-ANSI C, or modern C++ by cfront. So, while I still say that ISO Pascal was deeply flawed, I shouldn't hold that against all Pascal versions.

Nicklaus Wirth considers Modula-2 as Pascal evolution, so there is that.

https://dl.acm.org/doi/10.1145/1238844.1238847

Except for anyone who has worked in a large Python code base.

I would take almost any other language, including Pascal, over Python for anything beyond a page of code.

Python is the Settlers of Catan of programming languages. Most people have a different favorite game they would rather play, but enough people don't hate it that you end up playing it anyways.

I don't hate it, but it's just mediocre. Python is fine for short scripting as long as you don't need dependencies (which still remains rocket science in Python world), at that point it's better to look elsewhere.

Dependencies in Python have been sorted for years. Pip works great for install and pip-tools compile works great for locking. Please stop spreading this untruth.

The existence of poetry, hatch, pdm, etc. (and lately rye) is proof that "just use pip-tools" isn't consensus.

It is a current truth that there are modern apps of interest to me written in Python that I can't install because I need some special dependency manager or environment manager or something and it looks like I will do serious harm to my system environment if I follow the installation instructions.

I'm not sure I understand you. If the project uses something "special" like poetry, hatch, pdm, etc., you only need to install those for development. If you simply want to use the project, they all should be installable directly with pip, as they all have pep517-compatible backends.

Even then, how can installing those tools harm your system? You can always use pipx and have each tool be installed in its own virtual environment.

My biggest problem with pip-compile is that it's really slow. Pip-compile runs can take upwards of 20 minutes, depending on how many dependencies your project has.

We use it because we don't have any alternative. I'd really love to have a faster tool though.

Nobody hates python?

The more I use julia, the more I hate python. Which is a lot by now.

Yeah, nobody hates Python

Reply on news.ycombinator.com