[cipherself]

One anecdote in the same vein, a couple of months ago, I wanted to parse systemd-networkd INI files in Python and the python built-in ConfigParser [0] and pytest's iniconfig parser [1] couldn't handle multiple sections with the same name so I ended up writing 2 parsers, one using a ParserCombinator library and one by hand and ended up using the latter given it was much simpler to understand and I didn't have to introduce an extra dependency.

Admittedly, INI is quite a simple format, hence I mention this as an anecdote.

[0] https://docs.python.org/3/library/configparser.html

[1] https://github.com/pytest-dev/iniconfig

[thechao]

As a project gets larger the cost of owning a dependency directly begins to outweigh the impedance mismatch between 3rd party software & software customized to your project.

I've got 10 full time senior engineers on a project heading in to its 15th year. We rewrite even extremely low level code like std::vector or malloc to make sure it matches our requirements.

UNIX was written by a couple of dudes.

[kccqzy]

That’s because Python is a bad language for writing parser combinators and parsers based on them. Try Haskell.

[cipherself]

I have written parsers using parser combinators in Haskell and Clojure. I find that ML-like (Haskell, OCaml, StandardML) languages generally are great at writing parsers, even hand-written ones in it is a superior experience.

In this case, this was a project at $EMPLOYER in an existing codebase with colleagues who have never seen Haskell code, using Haskell would've been a major error in judgement.

[eru]

I agree!

Haskell is a great language. It can even be a great language for beginners, especially if there's some senior help on hand.

But it's a terrible language to foist upon an unsuspecting and even unwilling victim.