oddthink

> Although it turned out in the end that C++ developers actually wanted to use C++.

Oof, I don't think so. It's just ridiculous how many things Google uses C++ for where something like Go or Java would be a better fit, and everyone I talked to agreed. No one liked C++ for search-like things.

I think they just underestimated how powerful the network effects were. People wanted to use Go, but then it didn't have Flume support forever, so what can you actually do with it? And all the NLP libraries were in C++. And the vector-search library was C++, and graph clustering, and so on. One of the basic data formats was super-clunky for ages as well, but I forget if it was SSTable / RecordIO / Capacitor or what.

Or perhaps the Go creators were just writing very different code in very different domains from what I saw as the bread-and-butter C++/flume data-crunching pipelines of Search and Maps.

> E.g. If I ever see a monetary value stored in something else than integers I'm going to run away screaming (thank you Rust decimals represented as JSON floats). It's always integers unless you have a VERY good reason to do otherwise (though exported view can be in anything, even in weird bitcoded formats).

That really overstates the issue. Whole domains of finance run just fine on doubles.

If you're doing Monte Carlo options pricing over interest rate paths, and you're interested in the risk metrics, like durations, convexity, vega, and so on, no one cares what your rounding convention is. doubles are just fine, thank you. How are you going to force `exp(-rt)cashflow` to be an integer? Or the normal CDF?

Yes, there are domains where ints make sense. But it's certainly not universal, you just need to make the right engineering choice.

I've found differential forms to be more useful than GA, but that might just be that I was brought up in the MTW tradition and don't quite get GA.

Whenever I look at GA, I try to figure out where the metric comes in, and I just don't see it.

For context, way back when I did astro theory and wanted to do things like figure out things like the magnetic field structure in the curved spacetime near highly-magnetized rotating conducting spheres, and then do some basic plasma physics in that environment.

The differential geometry approach at least gives the structure to think about that, then you can go down to the index-style notation to actually get the differential equations you need to solve. The GA approach, I'm not even sure how to frame the problem.

VSCode binds a lot of basic commands to function keys, so I'm always doing Fn-F12. That seems like a weird choice, and if it really bothered me, I could remap it, but so far I haven't.

I loved that thing. I don't know how many hours I spent on that. I wish I could my kids interested in anything half as creative.

The current version is at https://github.com/jsoftware/jsource

I'm sorry, it's a really inefficient format. I don't want to sit and listen for two hours to what's most likely half an hour of content by reading. Just write down what you have to say already!

I guess you could do double-speed, but I find that somehow stressful.

Edit: I just read the paper. It took me 21 minutes. It's not long, only 11 pages.

Does the "standard office" even exist? I have never seen one in my working years. I don't even know what to imagine. The closest I got was a shared office in grad school in the late 90s, but after that it's been cubes at best, long slabs of desk in an open room at worst.

I tried fountain pens for a bit back in grad school, but they honestly weren't great. They were imprecise, blobby, scritchy on the paper. Subscripts and superscripts would smear out. The best experience, IMHO, was a 0.5 mm mechanical pencil, but those smeared, so I eventually switched to pilot v5 or muji pens.

But that sounds like math, not cursive, you say? Well, yes, but there are paragraphs of thinking and doodling and argument in there with the math. My point is that fountain pens seem optimized for some kinds of writing, but certainly don't have a monopoly on all sorts of putting pen on paper.

Yes. For like a simple naive Bayes, you can say we start at 0, a user vote is worth +3, a merchant vote is +5, we decay by 0.1 every month, publish if we hit +13 (95%), un-publish at +10 (90%), etc. etc.

It's the same math as logits, but the scale's a bit nicer.

I've been using decibels as a scale for log-odds for a while when reporting results. It works pretty well, since the relevant part of the scale is wide, unlike using nepers, which I had never heard of until I started noodling around with this.

It's internal. But it's basically hooking up SQL code generation to the docs and schema of most of the tables in the data warehouse. I don't know the details, but probably also some extra stuff in the prompt to give a bit of context. It started as a few-days hack that then got momentum.

There was a 1-5 Likert scale self-rating on "leveraging AI" and a free-text box. I rambled about using claude code to help summarize my daily notes, cursor for implementation, using the chatgpt ui for broad questions (what happened to internal project X, how do I configure airflow again, etc.), then experiments with the find-the-right-table-for-you SQL generator. That seemed like about the level folks were going for.

There are some people who are really into it. The sql-generator's great for PMs; ops are experimenting with moderation triage. I personally have mixed feelings, but I'll futz with it on company time (and api $) to see if I can get it to do something useful. It'll mess up tensor alignment, but I can fix that.

So, yes, it was in the performance review. No, it wasn't a big deal. Yes, it seems to me like a reasonable nudge to get over the activation energy of learning to use the thing.

Yes, but the message from Shopify leadership is "it's part of your job to mess around with this stuff and see what works". Not "use AI at all costs".

The general feeling I'm getting is that using this AI stuff is important, but it's a learned skill, and we want as many people as possible to get familiar enough with it to have actual opinions.

I find that pretty unobjectionable.

I mean, I could walk down to a bar at 10pm, if I wanted to. I live in a city. But if I'm getting up at 6:30, I don't think I want a pint let alone three that late.

Plus, I'd still have two kids up, asking me to extend the wifi because they're not done with English yet or to help scan a page for math. I'm not going to just leave that to my partner.

Even the more traditional pint-after-work would leave me coming home tipsy at 7pm, having slacked off on all of dinner prep and child-wrangling. If I made a habit of that, it would get me my ass handed to me, and rightfully so.

I do wonder if the whole "pub-culture" thing was entirely predicated on the unpaid and unacknowledged work of women. And how much of that extended to other traditional extracurriculars like bowling leagues and clubs and such.

I don't really get where people with kids found these 6.5 hrs / wk to spend on friendships, or even the quoted current averages of 4 hrs / wk.

On a workday, there isn't much time. I roll out of bed at 6:30, get the kids up and fed breakfast and out the door. I finally get actually working at 8:30-9:30, depending on if I exercise or not. Stop work in the 5:30-6 range, switch into making dinner, getting kids to eat dinner, policing screen time and homework. Then bedtimes and such, following up on the zillion school emails, PTA newsletters, scheduling. If I have 45 min of downtime, typically in the 10-11pm range, if I'm lucky.

On weekends, there's all the deferred housework, like cleaning and laundry. Kids have swim and sports. Visits to grandparents, from grandparents. Every now and then we have someone over for a games afternoon, or someone is visiting from out of town, but I really doubt that adds up to 4 hr / wk.

It's probably just a notation/definition issue. I'm not sure if "grad f" is 100% consistently defined

I'm a simple-minded physicist. I just know if you apply the same coordinate transformation to the gradient and to the displacement vector, you get the wrong answer.

My usual reference is Schutz's Geometrical Methods of Mathematical Physics, and he defines the gradient as df, but other sources call that the "differential" and say the gradient is what you get if you use the metric to raise the indices of df.

But that raised-index gradient (i.e. g(df)), is weird and non-physical. It doesn't behave properly under coordinate transformations. So I'm not sure why folks use that definition.

You can see difference by looking at the differential in polar coordinates. If you have f=x+y, then df=dx+dy=(cos th + sin th)dr + r(cos th - sin th)d th. If you pretend this is instead a vector and transform it, you'd get "df"=(cos th + sin th)dr + (1/r)(cos th - sin th)d th, which just gives the wrong answer.

To be specific, if v=(1,1) in cartesian (ex,ey), then df(v)=2. But (1,1) in cartesian is (1,1/r) in polar (er, etheta). The "proper" df still gives 2, but the "weird metric one" gives 1+1/r^2, since you get the 1/r factor twice, instead of a 1/r and a balancing r.

I'd say a gradient is usually a covector / one-form. It's a map from vector directions to a scalar change. ie. df = f_x dx + f_y dy is what you can actually compute without a metric; it's in T*M, not TM. If you have a direction vector (e.g. 2 d/dx), you can get from there to a scalar.

There's just so much C++ at Google that really has no business being C++ and falls into the "networked server" category. At least large swaths of the Search and Maps codebase, large chunks of flume (beam) batch pipelines, etc., etc. It's only historical accident and network-effect stickiness that keep that from being written in Java.

I could easily imagine him thinking Go could make inroads there. But then it took a very long time to get a flume port, and even then it didn't have half of the nice affordances that the C++ version did.

People say they need the efficiencies of C++, but IMHO they really don't when so much of the actual code time is spent slurping data from one sstable and writing it to the next sstable.

Looks interesting, but it's not at all responsive. I can't view it without making my window larger than my screen and manually sliding it back and forth. Even basic TUIs know their output size. I know it's a UI demo, but that seems pretty basic.

How is this still so hard? Tk basically had this figured out 25 years ago.

It goes way too far, IMHO.

It ends up sounding like a smarmy Sunday-morning talk show conversation, with over-exaggerated affect and no content.

So far I've just fed it technical papers, which may be part of the problem, but what I got back was, "Gosh, imagine if a recommender system really understood us? Wow, that would be fantastic, wouldn't it?"

I always come back to Schutz's Geometrical Methods of Mathematical Physics as my reference for notation, but I agree. I came to this by way of General Relativity, so that colors my perceptions. The few treatments of GA that I've looked at (briefly) weren't very clear about the distinction between 1-forms and 1-vectors and seemed to assume Euclidean metric everywhere, so I left thinking that it seemed a little weird and not quite trusting it.

In any case, my experience is that the coordinate-free manipulations only go so far, but that you pretty quickly need to drop to some coordinates to actually get work done. d*F=J is nice and all, but it won't calculate your fields for you.

Elizabeth Bishop was there first: https://www.poetryfoundation.org/poems/47537/the-man-moth

I know at least one team is at work is using the Assistants API, and I'm talking with another team that is leaning pretty heavily towards using it over building a custom RAG solution themselves, or even over other in-house frameworks.

Interesting! Just over the past month, I've reduced my emacs usage a lot. I'd switched to VSCode for most coding a while ago, but I still kept my daily journal notes in org-mode, but I recently switched to Logseq for that.

I don't know if I'll stick with it, or if it'll get sluggish after a while, but right now the searching, rich-text, and pdf-annotation seems refreshing.

Thank you! The Lagrangian as projection of energy-momentum actually makes sense, unlike the "let's just subtract potential from kinetic. No reason, it just works" story. I'd been idly wondering that for a while (and this is as someone with a physics degree, though in astro, which is a good bit more applied).

Why would you? For most forward-looking calculations, the uncertainty of the future completely swamps any cent-rounding.

Even for plain-vanilla bond price calculations, floats are the right tool for the job. Say you have a bond that pays $5 every year for 10 years, then $100. What's that worth today?

Well, you have a forecast yield curve of interest rates. Say it's quoted as continuously compounded rates, so then you get something like price = sum_{t=1..10}($5*exp(-r(t)*t)) + $100*exp(-r(10)*10).

But wait, say you actually have 1000 different potential paths of interest rates, and you want to average over all of them.

Oh, and there's a 1% chance of default every year.

Oh, and actually these are mortgages, so there's a path-dependent chance of them refinancing every year, if the rates get low enough.

And then there's an overall economic forecast, so if you have a bunch of mortgages, there's a bigger chance they'll all default at the same time.

And so on. Rounding the cents isn't really worth the worry, once you're putting noisy forecasts through `exp` (or worse special functions).

This applies for vanilla bond valuation, any option, any future. More so if you want risk measures (what if rates go up 0.10%? volatility increases?), and so on.

Floats work just fine for this.

Is the selling point for this easier custom widgets than in other frameworks?

Maybe my standards are too low, but for quick internal tools, it's hard to beat 30-year-old Tcl+Tk.

This may be too late to this thread to matter, but I've been dabbling with GT for a few months, and I like it so far.

I'm using a few of the modalities mentioned in the article.

I use it as for "Pharo development" / Smalltalk IDE. I've tried a few times to learn Pharo and Smalltalk, but I've stuck with GT more than I ever had with raw Pharo. It feels nicer graphically, and, most importantly, it lets me write notes about what I'm doing and exploring and save them as part of the image. That means I can open GT and continue right from where I left off, even if it's been a month since I looked.

I use it for "Personal knowledge management", mostly. Little projects and analyses that occur to me. Nothing fancy, things like writing up why it's easier to get heads-tails in a sequence of coin flips than heads-heads, with a bit of simulation, a writeup of the Markov chain, derivation of expected times, etc. I've done that many times before, but it feels good to have it all together in an aesthetically-pleasing form. Bits on game odds, leetcode-ish algorithms exploration, general computational fiddling.

Once I figured it out, I like the git integration for both code and notebook pages. That goes a long way to reassuring me that the things I do won't be lost. I still don't quite get the Metacello / BaselineOfX dependency management, but I'll get there.

I did a little API browsing, mostly following the "Exploring the GitHub REST API in 7'" video by Oscar Nierstrasz (https://www.youtube.com/watch?v=-vFwfwy5WZA). That series is excellent and I think does a good job of illustrating the power of the system and how it's different.

But, in general, it feels like a good "tool for thought".

I fiddled with its python interop a bit. It's OK, but could use some expanding: it runs python code in a single venv that you'd need to populate with the packages you need. I couldn't find any support for switching venvs based on project directories, etc.

I could imagine using GT as a more hackable way to interact with code. You don't get the nice automatic features of a python IDE, but you could define graphical views for your objects, drill-down into sub-objects, and the like. But to do that, you'd also have to know some Smalltalk.