> 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.
It can be really frustrating viewing threads like this sometimes. I've not once seen an interest rate swap priced in anything other than float/double, and that's relatively simple even compared to some of the crazy instruments out there.
Like, sure, probably don't use floats for everything, but what are the odds that your greeks are gonna be nicely expressable as simple rationals?
Quick browse over Stripe API (i.e. not a simplistic payment provider) will show exactly otherwise.
Metrics/durations/convexity/vega aren't monetary value, these are calculation values and I'm fine with them being whatever. If you're calculating averages to make decisions based on this I don't care if you're counting dolars or tomatoes.
Monetary value is $4.50 and it's representation of actual money passed through system. In practice this value is almost never undergoing any operations except for addition and subtraction. Any multiplication/divison etc. is left to specialized systems that return results wrapped in 800 pages of standarization documents, regulations and so on; systems where term "bit flip" is not a joke, but a risk.
As I wrote fintech != fintech, and I know many organizations aren't at that level of scrutiny, but a huge domain of people dealing with others' people money know that charging someone 1 cent too much is a tens of thousands of problems coming their way.
What's your preferred solution to dealing with FX conversions?
My issue with using integers everywhere is that FX conversions (or other rates) always come into play, and at that point I'm forced to use something else anyway (e.g. arbitrary precision decimals).
I never had to deal with that. At one place it was so complicated that specialized system took reconciliation over (it got baggage full of context data including exchange agreement details, with boundaries and time-regions plan).
In not-a-fintech we just went with doubles and rounded up (worst case - we get a cent more of a customer).
Though if I had to design today for that, I'd look for non-string serializable decimal, so not "10.123 == (10, 123)" but more like (10123, 3) and serialize in JSON as a value and precision separately.
Yet that's only cause I saw Decimal(10,123) sent in JSON as "10.123" which JSON reader red as 10.122 float and inserted to "1012" to database.
I worked on a trading system dealing with transaction limits expressed in USD but trading in many currencies.
FX rates and prices were expressed in fixed point because it was more efficient to handle in FPGA. A lot of thought went in to making the system accurate enough based on real FX rates while falling on the right side of the limit
I suggest reading the comment I was replying to since it contextualises the answer quite well. Hard to find absolutes in real life outside of thermodynamics.
> 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.
Doubles are not just fine, but required there. If you compute risk, as you allude to, by finite differences, then you need the precision of floats rather than rounding to integer cents prematurely.
It doesn't matter for quant finance to use floats because approximate is perfectly fine. Tracking the exact amount to accounting standards is the job of the brokerage team not the quant devs. Floats are fine for modeling as long as the numerical drift is accounted for.
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.
There is a relatively recent episode of the ArrayCast array language podcast with Henry Rich who is the primary maintainer and developer of J, talking about new features: https://www.arraycast.com/episodes/episode104-j96
Click on the show notes and there are links to previous episodes with him, talking about the J engine implementation, updates in J 9.03, threading and faster bignum calculations in J 9.04, updates in J 9.5, his views on tacit programming, etc.
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.
For me, podcasts are useful for learning while I drive. They are also useful for refreshing my recollection.
Finally the are useful for synthesis…a podcast can talk about tenuously related topics that would not usually be appropriate for an academic paper; use analogies, metaphors, and similes; and simply go off topic and discuss other interesting ideas that turn out to be more applicable than the formal subject.
I don't particularly like the podcast format either, but it's not inherently less efficient. You can potentially do other tasks while listening to one which would be difficult while reading. I personally find it difficult to concentrate on the content of the podcast when I do this (I don't take in information well from auditory sources), but others don't (and some actually find it hard to remember things they read).
Same for me. I only can listen to podcasts when I'm folding laundry, and my laundry folding needs are limited so it takes ages to get through a single episode.
I listen to podcasts while walking our dogs. Might not be enough for some of these really long episodes, but generally enough to know whether I'm going to finish it or not.
I sympathize, but just happened to listen to this episode over several days. The discussion actually adds a lot to the paper, and they seem very qualified to critique it. One of the guests(?) has written several esolangs. There must be a way to generate a transcript.
Slight spoiler: they have lots of criticisms of the paper.
That's Lu, one of the regular hosts now. All very bright and interesting people, different from each other. I think only Jimmy has a formal CS education, but he'll talk as much about philosophy sometimes.
Also, show notes link to the paper that they talk about that they do like much better.
I really enjoy listening to people talk about things. I get the same enjoyment out of talk radio and any news radio that is editorialized. I enjoy lots of shows on the various NPR member stations.
This format isn't inefficient, you're just judging it based having a different goal than it does.
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.
In my very first job as a software developer, in 1989 at the tender age of 19, I had my own office, with a door, which I could and would close when I needed to concentrate. It was beautiful. I had a side chair, and other devs would drop in and discuss designs and code. I also had an office at my next job, in 1993. It wasn't until I took a contract job in 1994 that I experienced cubicle life, but the walls were high and I could do some midnight construction to add a bit of privacy. I even had an office at a Seattle startup in 2001. It was afterward that things started to slide toward the open-office morass. Fortunately, I've worked only out of my home office since 2022, and it's been beautiful.
I still miss the old days: We had offices, we actually did design before we started implementing, we didn't do stand-ups but everyone still knew what was going on. I think I'll go yell at a cloud now.
I had what seemed to me a standard office, door but no window, in 2008 at my first job out of school at IBM in Austin. Some folks in that same hallway were doubled up but I was lucky to have one to myself while there.
A few jobs later in 2011 I also had one with a door, wall was a half-frosted window onto the hallway, was doubled up with another new hire eventually, this in SoCal, Ventura County.
Then in grad school from 2012 in NYC, also had a closet-scale office I shared with one of a rotating cast of officemates, that had an exterior window, nice view of 1 WTC as it was going up.
Since then (2016 on) it's been open offices, but at least with individual (if joined) desks, then WFH.
At a former job, for quite some time, there were separated offices with about 3 devs per room. It wasn't quite "one room per dev", but much, much better than the regular open office setups.
10'x10' office with a door and window out to the hall, and a light switch.
There's probably about 30 other offices like mine, a cube area with another 8-10 cubes, and a few conference rooms, but most of the building is a shop floor.
But I don't work near a major city, and I'm not a software engineer, just a regular one.
I've seen them, but they were rare already by late 1990s when I started work. I recall my dad having on in the 1970s, and I remember when I started they were tearing some out to put in cubes. Back then they told me offices were cheaper than cube (cube walls need to be stronger than regular walls because they cannot tie into the ceiling for support thus increasing costs), but they believed in the cube plan and so were willing to pay that price.
Cube walls are one off expense, while office square footage is a monthly expense, so if you can fit more people in the same size office by putting up some cubes it makes sense (so long as you ignore the lost productivity).
An office or a cube takes up similar amounts of floor space - you have a lot of options for both. My current building is an open office plan which gives everybody more square footage than any cube or office walls plan I've seen. Building walls are a one-off expense just like installing cubes.
One place I worked, till 1992 at least, had offices with doors for all the engineers. I loved it but, if I kept my door closed for too long, I often felt others thought I was hiding or goofing off.
If I kept my door open, I would still get distracted by people walking by. Even if they didn't say anything, they'd look in which would catch my eye.
Visiting my dad's work in the 1980's, what I distinctly remember is not only office doors, but that everyone had a busy light outside that they could toggle from a switch on their desk. Presumably so they could close the door but still let others know they were fine with interruptions. The lights probably did not ONLY exist for visiting kids to have something to play with.
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.
Technical pens (staedtler) are great for math writing and quite precise (I studied engineering and used these a lot for notes with lots of formulas, diagrams, math notation etc), but the ink does take a bit to dry so it can be smeary particularly for left-handed use. They’re also a bit unforgiving with writing angles (likely not optimized for writing, for sure but they do work)
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.
Like, how many decibels of evidence does this observation provide for this hypothesis? That seems potentially pretty workable, as long as you can ensure conditional independence.
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.
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.