git log                     # PAGER undefined; uses less
  PAGER=/usr/bin/head git log # pages through head, you get 10 lines
  PAGER= git log              # PAGER is empty; does not page
  git log | cat               # output is not a TTY; does not page

I don't think I was ever bothered by the automatic paging through "less".

[1]: https://man7.org/linux/man-pages/man3/isatty.3.html

Well, C strings exist and are probably here to stay.

I believe Pascal strings, where the length is stored in the 0th character, were much worse (also, obligatory reference to Joel Spolsky's “Back to Basics” and “fucked strings” [1]).

Looks like we only got enough memory to spare to allow arbitrary length strings with arbitrary characters – that is, being able to use 2 or 4 bytes for the length of every string – in 1990s or so, when C++ strings and similar types became popular.

[1]: https://www.joelonsoftware.com/2001/12/11/back-to-basics/

A good moment to appreciate the elegance of UTF-8 which allowed to encode multi-byte characters preserving the semantics of C strings.

It's similar to HTTP/1: there are a lot of headers in the protocol, but you can still use nc or openssl s_client and type the request manually; you probably only need Host: and Content-Type:, maybe Content-Length:, and it will work. I don't normally write HTTP requests in the terminal, but I know I can do it if I need. It's better to keep it this way, I think.

Same with APIs.

  message CarrotAPI {
    oneof api {
      Function1API function1 = 10;
      Function2API function2 = 11;
    }
  }
  
  message Function1API {
        message Request {}
        message Response {}
        
        Request request = 1;
        Response response = 2;
  }

This is... not really a good API design. I wonder if the problem of "multiple places to be edited" can be solved in an easier way by making a custom protoc plugin [1] which will take care of generating all the boilerplate for both Dart and Golang. This is how support for new languages and use cases is normally added to protoc.

[1]: https://protobuf.dev/reference/other/

Seeing this again and again. We call it a "Google detour" in the family, and rarely agree to the change of the route.

Compare:

— What's the best way of doing X?

— Ask Claude.

vs:

— I thought about this and found there are options A, B, and C of doing X, I like A more but C is the fastest; what do you think?

I believe a normal senior engineer won't suggest to talk to Claude in this case.

> "Yay for electric cars for everyone," she said, driving past another line of waiting motorists. "Those unfortunate, sad, unlucky people are just sitting there."

The majority of people in Russian cities live in apartments with no EV charging infrastructure. This person is lucky enough that she lives in her own home outside the city where she likely has a garage and can charge her car, but it's surely not a solution for everyone, at least not for the near future.

> people's workflows are really personal so I'd never tell someone to switch their's

I regularly, especially when working with younger colleagues at work, find myself struggling to look at how slow they are in the terminal, like when they hit the up arrow 20 times to find the specific command in the history. If I have a close enough relationship with a person to make sure my advice won't be considered rude, I'd probably say “Ctrl+R and then type”, or even “let me show you how I would do it faster”, but doing this too often is borderline rude, so sometimes I just watch and feel bad for them.

[1]: https://github.com/CallMeAlphabet/fastwc/blob/main/src/main....

[2]: https://github.com/coreutils/coreutils/blob/master/src/wc.c

...but not Midnight Commander: it's an outlier in your list, a tool that actively prevents you from learning the way how things work in terminal. Same for all attempts to invent a UI for git.