randomdata

No? Imagine how ridiculous that would become if interviewers actually followed that logic. "Great gameplay out there, <insert professional sports star>, but nevermind the sport we are all watching, my research identified that you erroneously wrote 1+1=3 in Kindergarten. What was your thought process?"

The podcast in question is known as "People I (Mostly) Admire" from the Freakonomics podcast network. The name should tell you that it is going to be about the people, not diving deep into their work. Perhaps there is room for a Podcast that scrutinizes the work of scientists, but one that literally tells you right in its name that it is going to be about people is probably not it.

It not like there can only be one Podcast. If you see that the world is missing something, create it! Nobody else is going to do it. If they would, you already wouldn’t have found it lacking.

This does seem to be the repeated consensus – that suburbanites choose to live in suburban areas because they want the isolation. Which, I suppose, makes sense as it is not like you have to live there. People by and large live where they want to above all else. Obviously there can be exceptions (e.g. children needing to live where their parents do), but as far as what prevails goes.

> There's also other reasons to oppose current suburb development patterns. Suburban sprawl is highly inefficient in many ways. It takes dramatically more infrastructure to serve the same number of people that you could in a denser area.

Is denser the actual alternative, though? It seems that if you took suburbs away from these people, they'd most likely try to move into more rural areas, so then you just end up with the same there (without the practical reasons traditionally associated with subsidizing rural areas).

In fact, I'm seeing more and more spreading of the so-called "15-minute city" conspiracy, which has people believing that there is some kind of organized plot out there working towards forcing people into living in dense cities. While the conspiracy itself is not particularly important here, the sentiment of people fearing that they might be forced into the city conveyed alongside it seems quite real and indicative that denser is not the direction they are willing to head.

At which point it really makes no difference if you physically reside within city limits or live in a suburban/rural area as the time and effort to get to the places that cater to your particular niche approaches being about the same in all cases. In fact, in my experience, it is often easier to access the amenities of a large city when you don't live in it!

Based on several adjacent discussions it seems not that the suburbs cause isolation, but that those who prefer to live in isolation are more likely to choose to live in the suburbs – presumably because it offers the isolation they seek. Even if an individual in the suburbs does not wish for isolation, if everyone else there does that limits the social possibilities.

But what about the suburbs destroys that? Or, would it be more accurate to say that those who already don't have connections have a preference towards living in suburbs? Perhaps that is where they feel most at home?

It is interesting that you say it is becoming a problem. Why was it not a problem in a past?

> It's a smaller town

Towns are usually considered urban. I was imagining actual, by definition, rural. Living in a small town (~2,000 people) right now, I'd say it has less of a social community that the rural areas I've lived in previously. Still nothing that should leave you feeling isolated, but there is certainly less of a "automatically friends with everyone" vibe. Granted, my rural experience is strictly in agricultural areas where everyone are farmers, which gives common ground on which to "automatically" become friends. If nothing else, you can talk about farming.

Is that the problem with the suburbs? That the people there can't find common ground on which to build friendships?

What is it about suburbs in particular that causes social isolation?

That gets you halfway there, perhaps, but I'm not sure it explains how you would use it in an actual application. Are you back to writing hundreds of "SELECT * FROM recent_admin_users"-type queries in the application, once again exploding the development effort and maintenance surface – exactly what you're trying to avoid with these types of tools?

> ORMs, the original topic at hand, are an entirely different beast.

The original topic at hand is active record, not ORM. ORM is, as the name literally tells, about mapping between relations (or, in practice, tables) and objects. No sane person is going to bash ORM. They may dislike a particular toolkit that tries to help with ORM, but at very least they are going to do ORM by hand.

But that's not what we're talking about. The original comment that set the context for this particular discussion is about query building. It literally proposed using an LLM to generate queries instead. You can query build in the active record style: e.g. `User::all().admins().latest()`, but that's still query building, exactly like the earlier example except with a different API.

The T in CTE literally stands for table. Even if you're right about the others, how could someone not think of that one as being a table? Regardless, now they can! Isn't education a wonderful thing?

> postgresql documentation uses

In fairness, Postgres originally implemented QUEL, which is relational. It didn't move to SQL until quite late in its life. It often takes longer to update documentation than to write code, especially in open source projects where the contributors tend to much prefer writing code over updating documentation.

> and have a method chaining syntax.

And this is often how composition is implemented. Not strictly so, but a common way to do it. Consider:

    users = select("*").from("users")
    admin_users = users.where("role = 'admin'")
    recent_admin_users = admin_users.where("created > LAST_WEEK()")

Of course, you could do the obvious and write out 100 completely separate almost identical SQL queries, but that's not exactly maintainable and it's not the 1940s anymore. You are going to quickly hate everything about your existence as soon as those queries need to change. This is the reason people turn to query builders. If you only had to ever write one or two queries there'd be no point, but that never happens within the domain where these tools are used.

But perhaps there is a better way. This is where you would give us example code to show how you would replace that query builder code with a pure SQL solution.

Duplicate rows, NULLs, ordering, etc. But there is no distinction to be made here, just calling attention to your grievous error so you don't make it again. We don't want to look like a fool again next time. Viva la education!

> I'm also not sure how to answer your question.

You put a lot of effort into a rather detailed response not once, but twice. You obviously know how to answer the question at a technical level, but perhaps you don't understand the nuance of my question? What I mean is: Show us some example code that demonstrates query builder composition and the pure SQL that you would use to replace it.

2. I may be misinterpreting you, but you seem to be talking about composition of data, while the rest of us are talking about the composition of the language.

But, hopefully I've misinterpreted you. Perhaps you could demonstrate how query builder composition is best replaced in pure SQL?

ORM has nothing to do with queries. It is about the data. You will still want to map your database structures to your application structures (and vice-versa), else you'll end up with a weird and ugly chain of dependencies that will forever ruin your codebase.

Further, the project is focused on implementing the active record pattern, so it would be more appropriately called an async active record than an "async ORM".

Indeed i does.

From the article: "We also have a dome of free Wi-Fi coverage over part of our downtown [Chochrane]. Do you have that in Toronto?"

I don't expect anyone in Zimbabwe knows who he is, just as I cannot name a single person in Zimbabwe despite being sure they too have household names. His capital enablements, while significant, haven't become world changing.

Seems like it would be difficult to use for what they are trying to achieve. Lua would be a better fit, however it is noted that they tried it first, but ran into some kind of issue with it. So now Limbo is among the "off the shelf" options.

Yes, but this is conceptually exactly the same as the aforementioned shell scenario. This is not something different.

Just as I suspected, there is only one definition, and one that has proven to actually be well defined to boot as you managed to reiterate the only definition I have ever known to perfection.

Yes, you can generate your test data in the host language. That dramatically reduces upfront complexity.

But that doesn't come free. Now it is not easily transferrable to other languages. If you recall rsc's somewhat recent talk on testing, they benefited greatly by being able to use similar DSLs from other projects in tests to ensure feature parity. It can be a huge boon to have your test data scripts in an "agnostic" language for 30 years down the line when you are no longer working in the same environment.

Tradeoffs, as always.

> I was expecting more than a few real world use cases

Maybe that's the only use-case they know of? The project was clearly built for a specific purpose.

That's not to say that it cannot be found useful elsewhere, but that doesn't mean they have found it to be. If someone else finds it useful in other applications, I'm sure they'll write their own document about it. That's what the web is for, after all.

1. Given that their stated use-case for this tool is generation of data for testing purposes, why would input configuration be relevant?

2. It doesn't have any CSV-associated features to begin with. If for some reason you wanted to use this for that, you would interact with your own bound Go functions to facilitate working with CSV, just as demonstrated in the article. Within those functions, you can setup any configuration your heart desires.

Which stands to reason. People only think about you if you do something for them. Newton and Einstein enabled the creation of capital that changed the world, so they are remembered. The guy who discovered something amazing beside them, but that which we still haven't figured out how to use, remains unknown.