ventana

Noticing how many comment threads here discuss that America is something, has become something, or is not something, I just wanted to remind everyone, especially those not living in the US, that the US combines several very difficult cultures which have different ideas of community, Christianity, civic duty, and everything. The first book I read on this topic was "American Nations" by Colin Woodard (highly recommended), and after visiting several states in different parts of the US, I try to be very cautious before making any statements about the US as a whole.

Not only for the conflicts, but mostly to encode the parameter types into the name for method overloading, because the linker has no idea about it.

I think maybe the idea of all these transpilers is to keep the generated code readable and as close to the original code as possible. Mangling names into unreadable garbage is not difficult, but that would also make the the transpiler act more like an obfuscator, which is probably what the authors want to avoid.

Protobuf has similar problem: whatever names you use for your proto messages should be translated to the target language as is, and with multiple target languages, chances are that you'll hit a keyword in one of them; each language plugin should figure out how to resolve this.

  $ cat test.proto
  syntax = "proto3";
  
  package test;
  
  message TestMessage {
    int32 register = 1;
    int32 foo = 2;
  }
  
  $ protoc --cpp_out=. test.proto
  
  $ grep 'register\|foo' test.pb.cc | head -n 2
        : register__{0},
          foo_{0},

A transpiler should translate all of the language's semantics, including resolving identifiers as symbols, and then choose legal names for them in the target language.

Yes, it should; but it also makes things much more difficult. This specific transpiler indeed builds an AST, but does not care about identifiers, just emitting them as is [1] (I hope I found the correct place in the code).

[1] https://github.com/solod-dev/solod/blob/8485bc867ae0f0269d75...

My goodness! This is the opposite of how I prefer working with my email. The three options presented in the demo are:

- swipe left to ignore;

- swipe right to keep (and also ignore);

- send an AI reply.

Poor, poor people who write a long email and expect a thoughtful response from a human.

Translating a language into a different language is a popular thing to do these days, but still not a very easy one. I feel it's like peeling an infinite onion of misery. First, you write a parser of your source language, figure out the translation of the instructions, and emit the code in the target language, and you're very happy when your translated Hello world compiles.

Then, a user (like me) tries writing something like

  package main
  
  func main() {
    register := 42
    println(register)
  }

  /tmp/solod_build3904763637/main.c: In function 'main':
  /tmp/solod_build3904763637/main.c:6:21: error: expected identifier or '(' before '=' token
      6 |     so_int register = 42;
        |                     ^
  /tmp/solod_build3904763637/main.c:7:29: error: expected expression before 'register'
      7 |     so_println("%" PRIdINT, register);
        |                             ^~~~~~~~ (exit status 1)

The next bad thing is when you step on your own toes and see that the new names you invented, like `so_int` or `so_println`, will inevitably pollute the global namespace. We'll either cross our fingers and hope that no one will create a variable named `so_int`, or we'll need to add all our new kind-of-reserved words to our already big list of exceptions.

I'm sure there are multiple levels of complexity beyond this.

Not trying to say that seeing a bunch of new translators from language A to language B is bad: not at all! It really seems that this is one of the popular usages of the agents, and a rewarding one. But doing it without hidden bugs is kinda hard.

I won't! But I can imagine a Windows developer (well, UTF-16, not UTF-32, but still NULs are everywhere) who might want to put something like that to the database without proper converting.

I would say it is both very pragmatic and very reasonable approach. Agents will probably not go anywhere, they are indeed useful tools, banning them seems pretty much unrealistic since people will use them anyway.

Then export PAGER= in your shell profile should help!

This is a common approach, CLI tools often use isatty [1] to check if the output fd is a TTY or not. Try running "git log" for example; if you have many commits, it will page through "less" or $PAGER only if it sees that you're on a real TTY; but if not, it will not. Try this:

  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

C-style strings being a thing at all really hurts.

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/

So, one fun consequence of this is that Unicode multi-byte strings (not UTF-8 but something like UTF-32) cannot be stored as strings in sqlite without a huge pain. Not that I ever planned to use multi-byte fixed length encodings, but good to know!

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

My reaction too, but then I found the button to try the previous days, and it was enough for me to figure out the game :)

I don't like the idea of making APIs effectively unusable for a human developer. We might not write a lot of code anymore, but getting rid of defaults and asking agents to pass all possible values explicitly makes it impossible to quickly debug the API call (e.g. with curl or something).

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.

I don't know! The author chose to use Golang, maybe it's for code reuse or just because they like Golang more. I did not question their choice, only commented on the implementation detail.

The author uses Flutter for UI, Golang binary for the app backend, and uses channels passing serialized protobuf messages between them. Since adding a new API call requires changes in multiple places, they ended up defining a "god message" which has a oneof with all possible options:

  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/

I never practiced Morse code, but I read enough about it to quickly realize that the nice sound a friend's cool new Nokia phone made on incoming SMS messages is actually ... -- ..., literally "SMS". The year was 2002 or so. I'm still amazed that someone in Nokia really thought about it back then.

The same things keeps happening every time I find myself stuck in traffic on the interstate. Out of nowhere, a popup appears in Google Maps: a faster route is available! 4 minutes faster! Unless either the passenger or the driver are fast enough to hit "No thanks", the change auto-applies, and Google now wants me to exit the interstate at the nearest exit and drive some random road I had no idea about, to rejoin the interstate a few miles ahead. Of course, a bunch of other vehicles in the same traffic jam got the same notification, so that minor road now get a sizable fraction of the interstate traffic, all of which then struggles to merge back.

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

Took me about half a year to drop my baseline levels, so, of course, not instant and not within "a couple" CGMs, but "a couple" was enough for me to understand the trends.

I used Libre 3; you can get different ones without a prescription online. You can easily get a prescription (in the US) if you get diagnosed with Type 2 based on your A1C numbers, but ordering a CGM online without any prescription is not a problem at all. Wearing it for 2-4 weeks is usually enough to learn a lot about your relationship with sugar.

Luckily, we live in the reality where every human who is interested in how their own body, and not the one of some random mouse, deals with blood sugar, can order a relatively inexpensive (for the benefits it provides) device — a continuous glucose monitor — and gather all the data they need to see what helps controlling the sugar level, and what does not. Using a CGM was a truly life changing experience for me, and I recommend trying it for everyone interested.

One of the ways not to get LMGTFY / Ask Claude as a response is to provide more information and proof of work when asking a question.

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.

My mom struggled to understand the concept of copying and pasting when she got her first computer at home, with Windows. It was more than 20 years ago, but I think the idea that you need to copy in one place, then go to some other place and paste there, still sometimes confuses her in the context of files, even though she does not have any issues with that when copy-pasting texts.

Limited charging infrastructure and severe weather remain a significant challenge for EV drivers in Russia, but Yasinskaya said the amount of money she is saving means her family may swap their other car for a hybrid, since they can charge it easily at their home outside the city.

"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.

I agree that both approaches are equally fast, and I myself did use VS Code at work a lot before the agents became widespread, so I can imagine myself doing either options. The terminal version is still less keystrokes because of the tab completion or reverse-i-search, but that's nitpicking.

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.

At the first glance, the 100x difference is surprising. My first thought was that the Rust code [1] uses AVX instructions, which would've explained the difference if the regular wc was a naive C code counting characters in a loop; but from what I see, at least the regular coreutils wc [2] uses AVX too, so the reasons of the 100x difference are not immediately obvious to me. Have you got any good explanation why? I don't believe it's Rust vs C, it might be some optimization that does not exist in the coreutils C code?

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

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

Agreed about the difference between CLI and TUI; at the same time, I do indeed prefer TUI over the “normal” (window) GUI apps for the exact reason why I would prefer vim (or emacs for the other half) over a GUI editor: when you are already in the terminal, launching a TUI app is just faster than switching to a GUI window. So it's still about "terminal or not" for me, or even, what is your default starting point: is it a desktop with icons or menus, or a command line with a prompt? For me it's a terminal, so I prefer TUI apps.

...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.

I don't think anything has changed for me regarding my vim usage. Previously, I would use vim to make simple changes in the code or configuration files, making larger changes in VS Code. Now, with agents, I never need to make larger code changes manually so I completely ditched VS Code, but I keep using vim in the same way as I did before: for small changes which I want to make manually, for editing configs, or as a scratchpad.

As a long time terminal user, it does not surprise me much when people just don't get it. The discussion often goes like this:

— In a terminal, I can do so-and-so with a simple command

— Well, in my FrobnicatorStudio, there's a shortcut Ctrl+Alt+So for that

and this can go forever, going into pretty much useless comparisons like "in vim, I can delete 24 lines by pressing four keys" (no Sublime user ever needs that) vs "in Sublime I have multiple cursors" (no vim user ever needs that either).

The proper argument here, probably, is this one: the terminal, with its way of combining small CLI tools into pipelines, covers infinitely many use cases, but indeed has a learning curve, taking probably a year or so to become really comfortable. When you reach that point, you will be, on average, much more productive than an average GUI user, but it requires some dedication, pain, and suffering to reach that point, and people often do it involuntarily.

In my case, my first job required managing customers' servers over ssh, those servers had bare minimum installed (often vi, not vim), and I had no choice other than figuring out how to do things effectively in this setup. If not for that experience, I'm not sure I would've gone through the pain of starting doing things in the terminal.

Have you ever run in to issues sharing your interpretation?

Not really.

Of course, having an analog Apple Watch face does not mean that don't know the exact time for the cases when I need to know the minutes, e.g. for a train departure time or things like that. It's just a mental calculation that I don't normally perform when I quickly look at my watch.

I would agree that people who need to know the time up to a minute normally won't ask because they likely have their own device showing it; and if they don't, they most likely don't need to know it up to a minute. But if they indeed do, I don't have problems with converting the watch time to HH:MM.