That said I increasingly have a very strong distaste of these AI generated articles. They are long and tedious to read and it really makes me doubt that what is written there is actually true at all. I much prefer a worse written but to the point article.

It’s not encouraging for the future of a project when the maintainer can’t even announce it without having AI do the work.

It would be great if this turns into a high effort, carefully maintained fork. At the moment I’m highly skeptical of new forks from maintainers who are keen on using a lot of AI.

I mean, I'm more worried about the AI writing itself than people calling it out.

The AI articles on HN are an absolute disease. Just write your own damn articles if you're asking the rest of us to read them.

In this case, a Chinese developer who's not a native English speaker - I feel is _adding_ to "interesting conversations" not detracting from them but using AI assistance to publish an article like this in readable/understandable English.

I know HN and Ycombinator is _hugely_ US focused and secondarily English-speaking focused. But there's more and more interest in non US based "intellectual curiosity" where the original source material is not in English. From YC's capitalism-driven focus, they largely don't care. From my personal hacker ethic curiosity, I'd hate to miss out on articles like this just because of a prejudice against non English speakers who use AI to provide me with understandable versions.

Having said that, AI hype in general certainly feels like a disease to me. I was noting recently how the percentage of homepage like/discussions I click has gone way down. I remember the days where I'd click and read 80 or 90% of the things that made it to the homepage. These days I eyeroll my way past probably 2/3rds of them because they look at first glance (and from recent experience>) to just be AI hype in one form or another. (I've actually considered building myself a tool that'd grab the first three or so pages and then filter out everything AI related - but the other option is just to visit less often...)

The important part is the human who will do more than just try to get the LLM to do the hard work for them, though. Once software matures the bugs and edge cases become more obscure and require more thoughtful input. AI is great at getting things to some high percentage of completeness, but it takes a skilled human to keep it all moving in the right direction.

I would cite this blog post as an example of lazy LLM use: It's over-dramatic, long, retains all of the poor LLM output styling that most human editors remove, and suggests that the maintainer isn't afraid to outsource everything to the LLM.

Indeed, the whole "Ironically, switching from Apache 2.0 to AGPL irrevocably makes the project forkable" section seems misguided. Apache 2.0-licensed software is just as forkable.

Normally, I'd agree with you 100%.

But there are some interesting mitigating circumstances here.

1) It's "just one guy" who's running a fairly complex open source project already, one which uses minio.

2) The stated intention is that the software is considered "finished" with no plans to add any features, so the maintenance burden is arguably way lower than typical open source projects (or forks)

3) they're quite open about using AI to maintain it - and like it or hate it, this "finding and helping fix bugs in complex codebases" seems to be an area where current AI is pretty good.

I'm sure a lot of people will be put off by the forker being Chinese, but honestly, from outside the US right now, it's unclear if Chinese or American software is a more existential risk.

I'll admit I'd never heard of their Pigsty project before, but a quick peek at their github shows a project that's been around for 5 years already, and has pull requests from over a dozen contributors. That's no guarantee this isn't just a better prepared Jia Tan zx utils supply chain attack, but at least it's clearly not just something that's all been created by one person over 2 or 12 months.

In any case I had one paragraph about the content and one side-note about the writing style. Every single reply except one focused on the side-note, including you.

But this is one of the few cases where it might be acceptable.

Author is not a native speaker; in an announcement that a known project is being forked for maintenance the occasional odd phrasing and possible errors in grammar could sound unprofessional.

I wonder if in such cases a better use of AI would be to try to write it yourself and just ask a LLM to revise instead? Maybe with some directive to "just point out errors in syntax and grammar, and factual mistakes. No suggestions on style"?

Outside of that, error codes are useful for debugging code that is running on other people's machines (i.e. in production) for and for reporting reasons.

The most important is that the team needs to actually use the task board (or whatever data source you use to get your inputs) to track their work actively. It cannot be an afterthought that gets looked at every now and then, it actually needs to be something the team uses.

My current team kind of doesn't like task boards because people tend to work in small groups on projects where they can keep that stuff in their own heads. This requires some more communication but that happens naturally anyway. They are still productive, but this kind of forecasting doesn't work then.

Jira is excel for task management. OOTB setup works absolutely great, and then someone comes along who wants a custom field on tasks to support <something that they read about elsewhere> and now you have to fill in that custom field. they leave, and someone else comes in and adds a new one. 5 years later you have 11 new fields that partially overlap, some are needed for some views, some are needed for other, but you can't use default boards because person Y decided that they wanted to call Epics Feat's, and made a custom issue type.

And in the end, the people who actualy use those boards just export a filter to excel and work there...

People. The problem is people.

I also don't feel less productive or lacking in anything compared to the newer developers I know (including some LLM users) so I don't think I am obsolete either.

Yes I know, Lisp could do this the whole time. Feel free to offer me a Lisp job drive-by Lisp person.

Agile has completely changed things, for better or for worse.

Being a SWE today is nothing like 30 years ago, for me. I much preferred the earlier days as well, as it felt far more engineered and considered as opposed to much of the MVP 'productivity' of today.

In normal markets there are competitors who force each other to keep reasonable profit margins and to improve their product as opposed to milking other people's hard work at the expense of the consumer.

Collective action by the creators would help.

All they have to do is dual-host (a fairly trivial matter, compared to organised collective action). What would make things even better is if they dual host on a competing platform and specify in their content that the competing platform charges lower fees. If even 10% of the creators did this:

1. Many of the consumers would switch. 2. Many of the creators not on the competing platform would also offer dual-hosting.

The problem is not "As a creator you have no choice but to accept whatever fees Apple, Google, Steam etc set". The problem is the mindset that their content is not their own.

I say it's their mindset, because they certainly don't act as if they own the content - when your content is available only via a single channel, you don't own your content, you are simply a supplier for that channel.

Apple will ban you for this.

How? I thought it was a Patreon thing - the "competing platform" would be competing with the Patreon app.

I'm not familiar with Patreon, but I thought the way it worked was that you could tip content creators via the Patreon app. I'm pretty certain that Apple cannot tell Patreon (a third party) that they are only allowed to offer exclusive content.

To me this is the thing that should be outlawed. Let people pay the Apple tax if they want, but don’t prevent people from making other arrangements. Most people are lazy and will pay the tax, if it isn’t excessive.

"No one needs app" is not the same as "No one has biological mandatory need to have an app"

Or even, post-Greenland, to force the Dutch to give Trump the Dutch Caribbean islands off the Venezuelan coast as well (Aruba, Bonaire, Curaçao).

If I were a Dutch member of parliament, I would be insisting this particular vulnerability to extortion be addressed as soon as possible. Of course, the US can still threaten to, at worst, nuke us all to smithereens but let's hope they're not willing to go that far.

This prompted me to try OnlyOffice, and man is that nice. I do like LibreOffice, but 2 things bug me: It just looks old. And second, I have, since the dawn of time (and the Sun's Star Office) had issues just telling the software: "This is a Dutch doc, apply Dutch spelling and Grammar Checks". It has never worked well, even Firefox text fields work better. But with OnlyOffice it seems to work well so far, and also, it will be much much more recognizable by ex-MS Office users. It hear the interop with MS formats is also better.

[0] https://www.techspot.com/news/110095-international-criminal-...

They can also order MS and Amazon and Google and Apple to switch off services on which most of the economy relies, and which most devices require to function.

Not sure they can transfer while the US practice the death penalty or penal slavery.

I am not sure (of course), but I think Atwood simply thought standardizing this format was so obviously valuable that he didn't consider Gruber might not want to work with him. In retrospect it's kind of nice that it didn't happen, it really keeps everyone incentivized to keep the format simple.

In this case a few minor edge cases is really not a big deal compared to that (in my opinion).

https://blog.codinghorror.com/standard-markdown-is-now-commo...

And an interesting discussion on hn about it: https://news.ycombinator.com/item?id=4700383

I don't know how that book ever got as big as it did, all you have to do is try it to know that it's very annoying and does not help readability at all.

https://github.com/johnousterhout/aposd-vs-clean-code

_A Philosophy of Software Design_ is an amazing and under-rated book:

https://www.goodreads.com/en/book/show/39996759-a-philosophy...

and one which I highly recommend and which markedly improved my code --- the other book made me question my boss's competence when it showed up on his desk, but then it was placed under a monitor as a riser which reflected his opinion of it....

At the very least, you convinced me to add John's book to my ever-growing reading list.

I have had so many discussions about that style where I tried to argue it wasn't actually simpler and the other side just pointed at the book.

IMX, people mainly defend goto in C because of memory management and other forms of resource-acquisition/cleanup problems. But really it comes across to me that they just don't want to pay more function-call overhead (risk the compiler not inlining things). Otherwise you can easily have patterns like:

  int get_resources_and_do_thing() {
      RESOURCE_A* a = acquire_a();
      int result = a ? get_other_resource_and_do_thing(a) : -1;
      cleanup_a(a);
      return result;
  }

  int get_other_resource_and_do_thing(RESOURCE_A* a) {
      RESOURCE_B* b = acquire_b();
      int result = b ? do_thing_with(a, b) : -2;
      cleanup_b(b);
      return result;
  }

Maybe sometimes you'd inline the two acquisitions; since all the business logic is elsewhere (in `do_thing_with`), the cleanup stuff is simple enough that you don't really benefit from using `goto` to express it.

In the really interesting cases, `do_thing_with` could be a passed-in function pointer:

  int get_resources_and_do(int(*thing_to_do)(RESOURCE_A*, RESOURCE_B*)) {
      RESOURCE_A* a;
      RESOURCE_B* b;
      int result;
      a = acquire_a();
      if (!a) return -1;
      b = acquire_b();
      if (!b) { cleanup_a(a); return -2; }
      result = thing_to_do(a, b);
      cleanup_b(b); cleanup_a(a);
      return result;
  }

Of course, this is a contrived example, but the common uses I've seen do seem to be fairly similar. Yeah, people sometimes don't like this kind of pattern because `cleanup_a` appears twice — so don't go crazy with it. But I really think that `result = 2; goto a_cleanup;` (and introducing that label) is not better than `cleanup_a(a); return 2;`. Only at three or four steps of resource acquisition does that really save any effort, and that's a code smell anyway.

(And, of course, in C++ you get all the nice RAII idioms instead.)

this rings alarm bells for me reading that a cleanup_c(c) has maybe been forgotten somewhere, since the happy and unhappy paths clean up different amounts of things.

i imagine your python code escapes the giant tree by using exceptions though? that skips it by renaming and restructuring the goto, rather than leaving out the ability to jump to a common error handling spot

The exact point of taking the main work to a separate function is so that you can see all the paths right there. Of course there is no `c` to worry about; the wrapper is so short that it doesn't have room for that to have happened.

The Python code doesn't have to deal with stuff like this because it has higher-level constructs like context managers, and because there's garbage collection.

    def get_resources_and_do(action):
        with get_a() as a, get_b() as b:
            action(a, b)

Jumping out of the loop with a goto is also more readable than what Python has to offer. Refactoring things into functions just because you need to control the flow of the program is an anti pattern. Those functions add indirection and might never be reused. Why would you do that even if it was free performance wise?

This is why new low level languages offer alternatives to goto (defer, labelled break/continue, labelled switch/case) that cover most of the use cases.

Imo it's debatable if those are better and more readable than goto. Defer might be. Labelled break probably isn't although it doesn't matter that much.

Python meanwhile offers you adding more indirection, exceptions (wtf?) or flags (inefficient unrolling and additional noise instead of just goto ITEM_FOUND or something).

Then replaced a pretty simple one with an anonymous immediately invoked function that contained a switch statement with a return for each case.

Um, can I have a linter rule against that?

Basically it's a shame that Typescript doesn't have a switch-style construct that is an expression.

And that nowadays you can't make nested ternaries look obvious with formatting because automated formatters (that are great) undo it.

One of the most infuriating categories of engineers to work with is the one who's always citing books in code review. It's effectively effort amplification as a defense mechanism, now instead of having a discussion with you I have to go read a book first. No thanks.

I do not give a shit that this practice is in a book written by some well respected whoever, if you can't explain why you think it applies here then I'm not going to approve your PR.

Alas, there's a lot of Go people who enjoy that kind of thing (flashback to when I was looking at an interface calling an interface calling an interface calling an interface through 8 files ... which ended up in basically "set this cipher key" and y'know, it could just have been at the top.)

As John Carmack said: "if a lot of operations are supposed to happen in a sequential fashion, their code should follow sequentially" (https://cbarrete.com/carmack.html).

A single method with a few lines is easy to read, like the processor reading a single cache line, while having to jump around between methods is distracting and slow, like the processor having to read various RAM locations.

Depending on the language you can also have very good reasons to have many lines, for example in Java a method can't return multiple primitive values, so if you want to stick to primitives for performances you inline it and use curly braces to limit the scope of its internals.

But of course understandeable code with comments simply has much more bandwidth of expression so it will get the best of both worlds.

I see writing commentless code like practicing playing piano only with your left hand, it's a showoff and you can get fascinatingly close to the original piece (See Godowsky's Chopin adaptations for the left hand), but of course when you are done showing off, you will play with both hands.

I said this at a company I worked and got made fun of because "it's so much more organized". My take away is that the average person has zero ability to think critically.

But I definitely don't go about it the same way. Mr. Martin honestly just doesn't seem very good at implementing his ideas and getting the benefits that he anticipates from them. I think the core of this is that he doesn't appreciate how complex it is to create a class, at all, in the first place. (Especially when it doesn't model anything coherent or intuitive. But as Jeffries' Sudoku experience shows, also when it mistakenly models an object from the problem domain that is not especially relevant to the solution domain.)

The bit about parameters is also nonsense; pulling state from an implicit this-object is clearly worse than having it explicitly passed in, and is only pretending to have reduced dependencies. Similarly, in terms of cleanliness, mutating the this-object's state is worse than mutating a parameter, which of course is worse than returning a value. It's the sort of thing that you do as a concession to optimization, in languages (like, not Haskell family) where you pay a steep cost for repeatedly creating similar objects that have a lot of state information in common but can't actually share it.

As for single-line functions, I've found that usually it's better to inline them on a separate line, and name the result. The name for that value is about as... valuable as a function name would be. But there are always exceptions, I feel.

It was useful for me and many others, though I never took such (any?) advice literally (even if the author meant it)

Based on other books, discussions, advice and experience, I choose to remember (tell colleagues) it as “long(e.g. multipage) functions are bad”.

I assume CS graduates know better now, because it became common knowledge in the field.

Things were pretty dire until Sandi Metz introduced Ruby developers to the rest of the programming world with "Practical Object-Oriented Design". I think that helped start a movement away from "clever", "artisanal", and "elegant" and towards more practicality that favors the future programmer.

Does anyone remember debugging Ruby code where lines in stack traces don't exist because the code was dynamically generated at run time to reduce boilerplate? Pepperidge Farm remembers.

Haskell (and OCaml I suppose two) are outliers though as one is supposed to have a small functions for single case. It's also super easy to find them and haskell-language-server can even suggest which functions you want based on signatures you have.

But in other languages I agree - it's abomination and actually hurt developers with lower working memory (e.g. neuroatypical ones).

  > Even a switch statement with only two cases is larger than I'd like a single block or function to be.

In his own words, ( page 34 ):

> [functions] should be small. They should be smaller than that. That is not an assertion I can justify.

He then advocates for functions to be 2-3 lines each.

That's both true, but long way away from "every line should have it's own method", but I guess parent exaggerated for effect and I misunderstood them, I took it literally when I shouldn't.

There's a literal link to a literal Uncle Bob post by the literal Uncle Bob from which the code has been taken verbatim.