[lobsterthief]

To be fair, when you do that you would approach coding the application differently, which adds to development time. Also, it can change the whole mentality of developing it. Probably why more people don’t do that, though I agree it would be nice.

[quickthrower2]

You can ossify it (ha!) after you have done all the work and it is mostly complete.

    git remote add origin …
    git push

[fuzztester]

Time to coin a new word - enossification - like enshittification - which I came across here recently, but without the negative connotation of the latter.

[bberenberg]

Can you elaborate on what you would need to do different in terms of dev? The only thing I would do differently in this scenario would be to ensure no secrets or anything gets into the code which is a minor lift but also probably for the best.

[rthomas6]

In python I do horrible things like the following when nobody else is going to see it:

  [[[foo(x) for x in y] for y in bar_vec if baz(y)] for bar_vec in bar_mat if bar_vec != []]

[Cyphase]

Side note, you don't need `if bar_vec != []`. Trying to loop over an empty iterable (e.g. a list) just doesn't loop, since there's nothing there.

Also, another way to write this (which results in a flattened list) is:

  [foo(x) for bar_vec in bar_mat for y in bar_vec if baz(y) for x in y]

[__MatrixMan__]

I have my secret perversions as well, so I've got no judgement for you, but I do have to wonder how our editing styles differ if you find that easier to navigate than the equivalent nested for loop.

[rthomas6]

  for bar_vec in bar_mat:
      if bar_vec != []:
          for y in bar_vec:
              if baz(y):
                  for x in y:
                      foo(x)

Seeing it written out here, the example looks nice. In real code with more complexity, it takes longer for me to write it, and it usually takes up a lot more space than this. It bugs me how much space it takes up for something that is one idea in my head (Foo all the baz things in bar_vec).

But if there is anyone coming after me, I would write it in this style for their sake, because this style is easier to change.

[__MatrixMan__]

At least in my code, these nested loop thingies are rarely unique. If I have to do it once I probably have to do it many times. If I'm being mindful, I stop repeating myself and just write a generator so that I can invoke it like:

  [foo(x) for x in nonempty(bar_mat)]

Mostly this is because I live in fear of ruff's complexity warning, C901.

[Arelius]

I dunno, that seems to be just shame instilled by the toxicity of certain programmer culture.

I mean, it's not the clearest thing to read but labeling it horrible seems to be a judgement call that's unwarranted. And as software developers, we should create an environment that's less hostile to people who write things in ways we wouldn't.

And honestly, that set of list comprehensions has a bit of a lispy functional vibe, which could quite frankly be applauded in certain contexts.

[arolihas]

Maybe I'm telling on myself but this doesn't seem that bad at all.

[nicbou]

This is fine. I make all of my stuff open source, but I'll be honest with people about being the only user that matters to my development work.

[eternityforest]

I assume the issue is you self-censor more and have to do things exactly by the book.

I've never been particularly interested in "software for one person" but I've shared lots of working but not great code(years old from before type annotations that hasn't been touched much since, written a hurry, etc), and faced some embarrassment.

If I was actually attached to specific details of the style, like "Yeah it crashes on some JSON input, but I don't care, it's only meant to handle stuff from this other thing I made" I might not really like sharing it as much.