5 ms·

Steve Yegge had a series of essays where he discussed two flavours of programmers. "liberal", which e.g. likes lower-friction dynamic languages, prefers magic t

Steve Yegge had a series of essays where he discussed two flavours of programmers. "liberal", which e.g. likes lower-friction dynamic languages, prefers magic to boilerplate; and "conservative", which e.g. would prefer to have bugs known at compile time, prefers boilerplate to magic. https://gist.github.com/mrnugget/49ad3ee4043c746e42187e2820ddc2f6 https://gist.github.com/mrnugget/49ad3ee4043c746e42187e2820d... Autoloading sounds like a feature which reduces the friction while iterating on the program (when the mental model of the program is fresh), but adds a lot of friction if you need to maintain the program and are unfamiliar with the codebase. It feels like the points cited in the article in favour of autoloading are "liberal" ("nicer DX to just have all the classes available everywhere"), and the counterpoints are all "conservative" ("code should be readable/maintainable").

cturner 5y ago
Putting it in liberal/conservative terms moves it to a simple matter of opinion. But most code spends most of its life maintenance. Would anyone argue against the importance of maintenance?
- rgoulter 5y ago
  I think it inevitably comes down to trade-offs. If you can write highly maintainable code without paying the cost of slower speed, surely that's a winning strategy. But I suspect an increase in maintainability means "more friction to change". (e.g. I'd expect adding documentation and unit tests is to take more time in the short term than just writing the code without documentation and unit tests).
  - jatone 5y ago
    this problem is precisely what tooling is for. golang for example solves the explicit import problem quite nicely with almost no friction outside of ambiguous cases, which you'd need to handle explicitly anyways.
    - rgoulter 5y ago
      I think golang makes for an interesting example: Your program won't compile if you have unused imports, or even unused variables. Which is low-friction for maintenance. You're not going to have to worry if deleting something is unsafe. But this strong-arm implementation of a lint means that iterating on code meets high friction. It slows down developer iterations as you have to comment/uncomment in order to compile. -- "But if you use some tool it's not so bad" is advice I've been given, which strikes me as the same as "automatic loading isn't so bad if you're using an IDE".
that_guy_iain 5y ago
Having used autoloading in PHP it feels very similar to working with Java/Kotlin. With PHP there are community standards that are follow almost everywhere, you know your dependency code is in the vendor dir and then you know that code will follow a naming convention so the code is really easy to find. As the author of the post said Jetbrains have solved this problem and you can jump to the definition of any class really easily. Their issue is they know there is a tool that does the job but refuse to use it. This seems to me like complaining that using a screwdriver to hammer in nails is a bad idea.
EdwardDiego 5y ago
I used to love Python's dynamic typing, and magic, until I started working on build process critical Python written by other people - and it wasn't even a large codebase, it was about 1500 lines across five files. My least favourite part - dicts of dicts of dicts parsed from JSON, so good luck knowing what conf["foo"]["bla"]["bob"] was without a lot of code reading, good luck figuring out what other properties conf["foo"]["bla"] had, and good luck figuring out if those properties always existed. In the end I introduced Pydantic to give the JSON objects a known structure with validation, and that dramatically eased the maintenance friction in one foul swoop (and bringing in Pydantic exposed properties that everyone was setting religiously but never using) - instead of a dict of dicts, it was a now a dict of app name to BuildConfig. Bringing in mypy and gradually introducing type annotations took more effort, but once it was done, the codebase was far easier to read and understand, large sections of dead code were easily identified, and runtime bugs became far less common. In other words, I removed all the dynamic bits of Python. That said, when I'm working with Python libs that do terrible things (like deciding if they're running in a multiprocessing context by checking for an ENV var when the module is imported(!)) I do appreciate how Python's magic lets me reach in and monkey patch terrible things away - although I feel a bit icky doing so.
- gary_0 5y ago
  I spend a lot of time in crufty old C++, and I love how clean Python syntax looks. But then I wonder if it's trying to be too clean, with all those pesky explicit types scrubbed away. Which is odd, because the first time I read "explicit is better than implicit" was in "The Zen of Python", and I always very much agreed.
  - EdwardDiego 5y ago
    Python these days is sprouting type annotations all over the show, the benefits are too good to ignore. And if a given library doesn't use type annotations, people will often create type stubs for it that mypy can consume. https://github.com/python/typeshed/tree/master/stubs https://github.com/python/typeshed/tree/master/stubs TBH, Python generics are rather clunky, although I think they're probably still going to have cleaner type signatures than C++
friedman23 5y ago
Liberal and conservative is a terrible analogy, it's about being explicit or implicit. And in programming explicit is always better.
- jaredcwhite 5y ago
  Nope.
thinkindie 5y ago
with PHP autoloading you can still detect issues at compile/build time
mike_hock 5y ago
I don't know 'bout y'all, but to me, one of those "flavors" is clearly "right" and the other is clearly "wrong."

cturner 5y ago

Putting it in liberal/conservative terms moves it to a simple matter of opinion. But most code spends most of its life maintenance. Would anyone argue against the importance of maintenance?

rgoulter 5y ago
I think it inevitably comes down to trade-offs. If you can write highly maintainable code without paying the cost of slower speed, surely that's a winning strategy. But I suspect an increase in maintainability means "more friction to change". (e.g. I'd expect adding documentation and unit tests is to take more time in the short term than just writing the code without documentation and unit tests).
- jatone 5y ago
  this problem is precisely what tooling is for. golang for example solves the explicit import problem quite nicely with almost no friction outside of ambiguous cases, which you'd need to handle explicitly anyways.
  - rgoulter 5y ago
    I think golang makes for an interesting example: Your program won't compile if you have unused imports, or even unused variables. Which is low-friction for maintenance. You're not going to have to worry if deleting something is unsafe. But this strong-arm implementation of a lint means that iterating on code meets high friction. It slows down developer iterations as you have to comment/uncomment in order to compile. -- "But if you use some tool it's not so bad" is advice I've been given, which strikes me as the same as "automatic loading isn't so bad if you're using an IDE".

that_guy_iain 5y ago

Having used autoloading in PHP it feels very similar to working with Java/Kotlin. With PHP there are community standards that are follow almost everywhere, you know your dependency code is in the vendor dir and then you know that code will follow a naming convention so the code is really easy to find. As the author of the post said Jetbrains have solved this problem and you can jump to the definition of any class really easily. Their issue is they know there is a tool that does the job but refuse to use it. This seems to me like complaining that using a screwdriver to hammer in nails is a bad idea.

EdwardDiego 5y ago

I used to love Python's dynamic typing, and magic, until I started working on build process critical Python written by other people - and it wasn't even a large codebase, it was about 1500 lines across five files. My least favourite part - dicts of dicts of dicts parsed from JSON, so good luck knowing what conf["foo"]["bla"]["bob"] was without a lot of code reading, good luck figuring out what other properties conf["foo"]["bla"] had, and good luck figuring out if those properties always existed. In the end I introduced Pydantic to give the JSON objects a known structure with validation, and that dramatically eased the maintenance friction in one foul swoop (and bringing in Pydantic exposed properties that everyone was setting religiously but never using) - instead of a dict of dicts, it was a now a dict of app name to BuildConfig. Bringing in mypy and gradually introducing type annotations took more effort, but once it was done, the codebase was far easier to read and understand, large sections of dead code were easily identified, and runtime bugs became far less common. In other words, I removed all the dynamic bits of Python. That said, when I'm working with Python libs that do terrible things (like deciding if they're running in a multiprocessing context by checking for an ENV var when the module is imported(!)) I do appreciate how Python's magic lets me reach in and monkey patch terrible things away - although I feel a bit icky doing so.

gary_0 5y ago
I spend a lot of time in crufty old C++, and I love how clean Python syntax looks. But then I wonder if it's trying to be too clean, with all those pesky explicit types scrubbed away. Which is odd, because the first time I read "explicit is better than implicit" was in "The Zen of Python", and I always very much agreed.
- EdwardDiego 5y ago
  Python these days is sprouting type annotations all over the show, the benefits are too good to ignore. And if a given library doesn't use type annotations, people will often create type stubs for it that mypy can consume. https://github.com/python/typeshed/tree/master/stubs https://github.com/python/typeshed/tree/master/stubs TBH, Python generics are rather clunky, although I think they're probably still going to have cleaner type signatures than C++

friedman23 5y ago

Liberal and conservative is a terrible analogy, it's about being explicit or implicit. And in programming explicit is always better.

jaredcwhite 5y ago
Nope.

thinkindie 5y ago

with PHP autoloading you can still detect issues at compile/build time

mike_hock 5y ago

I don't know 'bout y'all, but to me, one of those "flavors" is clearly "right" and the other is clearly "wrong."