> architecture is what happens when all those local pieces interact, and you can’t get good global behaviour by stitching together locally correct components
This is a great article. I’ve been trying to see how layered AI use can bridge this gap but the current models do seem to be lacking in the ambiguous design phase. They are amazing at the local execution phase.
Part of me thinks this is a reflection of software engineering as a whole. Most people are bad at design. Everyone usually gets better with repetition and experience. However, as there is never a right answer just a spectrum of tradeoffs, it seems difficult for the current models to replicate that part of the human process.
I’ve had a couple wins with AI in the design phase, where it helped me reach a conclusion that would’ve taken days of exploration, if I ever got there. Both were very long conversations explicitly about design with lots of back and forth, like whiteboarding. Both involved SQL in ClickHouse, which I’m ok but not amazing at — for example I often write queries with window functions, but my mental model of GROUP BY is still incomplete.
In one of the cases, I was searching for a way to extract a bunch of code that 5-6 queries had in common. Whatever this thing was, its parameters would have to include an array/tuple of IDs, and a parameter that would alter the table being selected from, neither of which is allowed in a clickhouse parameterized view. I could write a normal view for this, but performance would’ve been atrocious given ClickHouse’s ok-but-not-great query optimizer.
I asked AI for alternatives, and to discuss the pros and cons of each. I brought up specific scenarios and asked it how it thought the code would work. I asked it to bring what it knew about SQL’s relational algebra to find the an elegant solution.
It finally suggested a template (we’re using Go) to include another sql file, where the parameter is a _named relation_. It can be a CTE or a table, but it doesn’t matter as long as it has the right columns. Aside from poor tooling that doesn’t find things like typos, it’s been a huge win, much better than the duplication. And we have lots of tests that run against the real database to catch those typos.
Maybe this kind of thing exists out there already (if it does, tell me!) but I probably wouldn’t have found it.
I’ve found them to be pretty good if you tell them to be more critical and to operate as a sophisticated rubber duck. They are actually pretty decent at asking questions that I can answer to help move things forwards. But yeah by default they really like to tell me I’m a fucking genius. Such insight. Wow.
I agree with you very much, if what you are building actually benefits from that much client side interactivity. I think the counterpoint is that most products could be server rendered html templates with a tiny amount of plain js rather than complex frontend applications.
Facebook moved to mercurial because of specific problems related to the size of their monorepo. Moreover the git maintainers were unwilling to work with Facebook to improve git to solve some of these problems. Mercurial was a better fit and was open to the help. But all that said if you don’t have a truly enormous monorepo like Facebook or Google then git is arguably the better tool given the network effects. I don’t think Facebook wanted to promote Mecurial as some vastly superior solution outside because for most people it isn’t.
From the Facebook blog post, it seems like the key issue was Facebook's internal filesystem monitoring tool (Watchman) was easier to integrate with Mercurial than with Git:
So, neither Mercurial-out-of-the-box nor Git-out-of-the-box could handle huge monorepos. But Mercurial's willingness to make some modifications made it easier for Facebook to integrated their custom tooling to avoid the slow Big-O O(n) scans for changed files.
> From the Facebook blog post, it seems like the key issue was Facebook's internal filesystem monitoring tool (Watchman) was easier to integrate with Mercurial than with Git:
This is not true. I’ve seen x-rays of a child’s mouth with clearly no adult teeth visible below the gums. Later I’ve seen X-rays of the same mouth with one or two adult teeth below the gums where baby teeth are about to fall out. The adult teeth are there underneath once the baby teeth fall out but they are not there “from the start”. That isn’t even to mention the size problem.
I think with rowing in particular due to certain counter intuitive parts of the stroke you absolutely can get nothing out of years of self exploration.
I’m new to the language and thought these would be the same. But I just listened to some words with the two and the おお definitely has like a bigger o sound. That’s quite subtle.
You’ll hear it more easily with time. It’s hard to completely separate stuff like this from context (i.e. it’s far more rare to have a collision in sound that makes sense if you know the rest of the sentence), but it does matter for discriminating between words when you’re trying to look words up, for example.
I've never heard of the /o:/ of おう and おお being different. I've never seen a small child, or foreign speaker, being corrected in this matter; i.e that they are using the wrong /o:/ for the word and should make it sound like this instead.
This is literally not a thing that exists outside of some foreigners' imaginations. You will sooner hear a difference from $1000 speaker cables before you hear this, and it will only be if you are the one who paid.
You may be letting by pitch accent deceive you. In words that contain /o:/ it's possible for that to be a pitch boundary so that pitch rises during the /o:/ and that can contrast against another /o:/ word where that doesn't happen.
The 頬 word in Japanese is "kinda funny" in that it has a ほお variant and a ほほ variant. It has always stood out in my mind as peculiar. I'd swear I've heard an in-between "ほ・お" that sound somewhat reminiscent of "uh oh", with a bit of a volume dip or little stop that makes it sound like two /o/ vowels. It could be that the speaker intends ほほ, but the second /h/ sound is not articulated clearly. It may even be that the ほほ spelling was invented to try to represent this situation (which is a wild guess, based on zero research). In any case, the situation with that cheeky little word doesn't establish anything general about おお/こお/そお/とお...
I've been fooled by my imagination. For instance, many years ago I thought I would swear that I heard the object marker を sound like "WO" in some songs; i.e. exactly how it typed in romaji-based input methods, because it belongs to the わ group. Like "kimi-o" sounding like "kimi-wo". Today I'm convinced it is just a kind of 空耳 (soramimi). Or the artifact of /i/ followed by /o/ without interruption, becoming a dipthong that passes through /u/: it may be real, but unintentional. It's one of those things that if you convince yourself is real, you will tend to interpret what you are hearing in favor of that.
That's actually a good example because there are so many covers of that, you can see whether you hear the "whoopy wo" from differnt speakers.
There is a similar situation in the pronunication o 千円. There is a ghost "ye" that appears to the foreign ear. To the point that we have developed the exonym "yen" for the Japanese currency!!! The reality is more like that the /n/ is nasalized, similarly to what happens when it is followed by /g/. https://www.youtube.com/watch?v=5ONt6a1o-hg
OK, finally, let's crack open the a 1998 edition of the the NHK日本語撥音辞典. On pages 832-833, we have all the /ho:/ words, with their pronunications including pitch accents:
ホー with falling accent after ホ: 方、砲、鵬、朴
And, our cheeky word 頬 gets a separate entry here due to its pronunications ホー and ほほ。Both have a falling pitch after the leading ほ, like 方. No difference is noted.
ホー with pitch rising at the "o": 法、報
So of course if you compare someone saying 法律 vs 頬, there will be a difference. But a lot of longer ほお words have the same rising pitch like 法. 法律 (ほうりつ） vs 放り出す （ほおりだす）is the same.
Fairly intuitively, 頬張る（ほおばる）has rising pitch at the お、in spite of 頬 by itself exhibiting falling pitch.
> This is literally not a thing that exists outside of some foreigners' imaginations.
I think you're a little obsessed with this. It's not pitch accent and I'm not "being fooled", but if you want to insist that you know better...fine? You do you!
> OK, finally, let's crack open the a 1998 edition of the the NHK日本語撥音辞典. On pages 832-833, we have all the /ho:/ words, with their pronunications including pitch accents: ホー with falling accent after ホ: 方、砲、鵬、朴
I've already given you examples where you can often hear the difference if you try. These "ho-words" are completely unrelated, and non-responsive. You seem to be arguing about something else (or just trying to name-drop the NHK pronunciation guide).
Anyway, there are two distinct sounds in the kana table for う and お. They're individually pronounced differently, so why you're so resistant to the idea that combinations of the two might also have a difference in pronunciation, I don't really know. I've personally had native teachers tell me this, and I hear it all the time. Go ask a native to slowly sound out the individual mora for a word like 紅茶 vs. say, 大阪 -- that's how I first heard it.
Anyway, I'm not really interested in debating this further. It's a very, very minor point. Good luck with your study.
> there are two distinct sounds in the kana table for う and お.
Oh no, that totally escaped my feeble attention. Boy, do I feel sheepishly stupid now.
> Go ask a native to slowly sound out the individual mora
In fact, now that you point it out, even if I do that myself, it's obvious they are different: ko-u-cha, o-o-sa-ka!
Well, I've just been going about this all wrong, barking up the wrong tree.
In hindsight it now makes total sense that they wouldn't just use う as a marker to indicate that the previous お is long. Thats what ー is for; whereas う has a sound!
reply