361 karma · joined December 20, 2012
It does sound like youtube will be requiring experiments to pass some sort of similarity test before they can be run as an experiment.
I think it'll be interesting to see how it goes.
Like claiming townhouses not facing out into the street somehow produces X $ in mental health costs due to "lack of inclusion" and the footnote links to a study where non-english speaking communities in Australia were having real health costs due to lack of access to translation services. Which is something that passes for "evidence based" planning. Doing experiments in social sciences is a lot harder tho.
Maybe it's too easy to do experiments in Software and like you said
> Sometimes it feels a bit like we're sitting around so focused on measuring whether guests prefer one dish or the other and arguing over which experiment is best, that we don't notice a forest fire is blazing outside
I do think they're a useful tool but I see what you're saying.
Part of me feel some of that is risk aversion, but also maybe some of its process dependence when you have a number that provides strong certainty on a number of things, and because there's that feedback loop they get drawn to the things that cause the number go up. Similar to how people become dependent on LLMs to get stuff done or affirm if they did the right thing, and when they're in a space that's harder to measure they don't know to judge if they've done a good job or not.
I'm spending less time working on software, as I decided to get an econ degree, specifically econometrics, so I do spent a lot of time trying to think how to better measure stuff specifically in public policy, so I might be bias lol
But I do get what you're saying, hope things are well for you
> In my experience working in software, empiricism is the only thing valued anymore. Intuition and thoughtfulness is out the window because it's not scientific enough.
With things like A/B testing, its not entirely an objective as you need to make assumptions which can be difficult to measure (although typically randomisation solves a lot of them), but you can only measure what you've decide to measure (which isn't random), so you don't know when you're in a local max. So IMO intuition and thoughtfulness is necessary. Sometimes product managers don't listen to data scientists when they say you can't measure Y with X, or the research design violates the required assumptions to make a causal claims (like reverse causality or controlling on a post treatment effect, e.g. employment as control when measuring income after hospitalisation (the treatment)). I think the worse offences I've seen have been from marketing teams.
But proper research design does require intuition and thoughtfulness, because statistical models require thought, like other forms of supervised learning.
I've seen both
- PMs use questionable experiments to justify shipping something.
- PMs dismiss experiments when it was a null result and shipped anyways.
In either case I don't think the methodology is the cause of problems here, although I think shipping with a null result is justifiable if it's a larger unit of work (provided its not a regression).
Sometimes things that have heterogenous effects get measured as a homogenous effect, Like say:
- Your primary user base is X1 and X2 is a larger consumer base but makes up a small portion of your user base.
- Your experiment does poorly with X1, but say there was an increase in user base X2.
- However because X1 dominates the user base and your signups (because say you target ads to X1 over X2), no one drills into the effects on these different user bases, the result gets discarded as it seems to be a bad outcome.
There's valuable information in the experiment outcome but without thought and attention you can miss it.
> Google recently started doing all of these on anonymous searches with a modal overlay and a big bright blue "Continue" primary button that takes you to a login screen, while a "don't sign in" button appears as far less noticeable text above it.
I mean that sucks, but IMO with their market share, the way Google chrome is inclined to develop their product is very different to firms in more competitive spaces.
Perhaps A/B Tests, allows google to optimise the things they are incentivised to pursue, but in the hands of smaller firms with different incentives are willing to tweak things to be more appealing to users when they have far less market power, which I think is probably more the issue in the case of Google.
I just don't think this is a universal problem with the methodology
Look I get it feels weird but in practice most A/B tests are stuff like “does this copy change if ppl use this feature”.
The reasons they don’t is the same reason RCTs for new drugs don’t tell patients either. You end up with selection bias.
> If you don't have enough confidence in your changes to make them carte blanche, then don't make them at all
This is a bit hyperbolic, empirics is something that should be used more by decision makers not just for their own sake but for people who don’t understand why they are making them, especially in government (although It’s harder because finding cases where it’s appropriate is hard).
An A/B test isn’t just about what’s better, it’s about understanding all other things being equal how does one change to X affect Y. Which is information that can be used to inform the design of yet to be build features.
A lot of ppl have bad takes on what makes a product better, and they would otherwise have a greater say in the product design. Some product managers are just really stupid and are there due to nepotism so it’s an external equaliser and allowing the thoughtful ones to have more of a say.
> Users don't want their shit changing all the time.
Yep that’s why you don’t ask them.
I get if you have a specific flow that your use to. It would annoying for me too if that changed (as I’m pretty stubborn don’t like ppl making changes on my behalf), but that doesn’t mean it’s an objective better experience for all users or users who have yet to be familiar with the apps process.
When these products operate in competitive markets and not some winner takes all market these are often about improving users experience.
If this was something more high stakes like a medial trial I’d get it, but for stuff like filling out a document or watching a piece of media. The stakes for most SASS app are really low.
If almost everything is different, it’s hard to learn for next time what exactly what led to a change in which ever dependent variable your observating.
Many areas where people want to live and where homes should be built, can sometimes have a large portion of home owners like Mosman, Bondi, Croydon or Woollahra in Sydney. A tax on the unimproved value of land just doesn't get home building started here if no one is a renter (I recall increases in rent were tied to LVT in Progress and Poverty). And if its based on valuations the valuations will again be distorted by planning controls.
If you upzone these areas for towers, the moment the first person takes the gazillion dollar offer from a developer suddenly homes get built, and suddenly everyone else want to exit. And besides if you have LV Tax their land value will got up because their land will have fewer development limitations, higher demand, etc, etc.
Georgism is cool, land tax is cool, but it's not a silver bullet.
If your goal is to make homes more affordable, reforms like the ones they did in Auckland (loosening planning controls) is the way to go. https://onefinaleffort.com/auckland
Similar thing is taking place in Austin Texas right now as well. https://www.pew.org/en/research-and-analysis/articles/2026/0...
If your goal is to redistribute wealth Georgism is not a bad option, but again planning controls (zoning, Floor space, height limits, heritage controls, parking minimums, upper setbacks, excessive lower setbacks) can suppress the true size of the tax base.
Zoning and planning distorts land values so georgism alone won't solve land use problems. E.g. Demand for land with fewer property rights (such as single family zoning, or a heritage restriction) will be lower than the site next to it that allowed building a 200 floor residential tower. In turn its land value will be lower.
It might still yield a high rent tho, but maybe not more than a new well maintained apartment.
Not a fan of the paternalistic/nanny state attitude of the current government or that ministers track record, but isn't this two separate things which they intend to do?
Not entirely how you've made formed this connection but respectively it sounds like you've confused several things here.
One thing I've begun to notice is that LLMs list of a bunch of interesting stuff and raise all these thing you consider but often sometimes you just want a more focused response, so these scatter responses kind of lead you to being overwhelmed and losing focus on what you really wanted to do. At least I've started noticing this.
Like I'd ask about some statical approach taken in a paper and suddenly i'm being bombard with all these potential pivots and things I really need to consider, I kind of just want to consider 1 thing at a time and come to things once I fixed the immediate issue. Sure I have no doubt these other pieces of information are useful but it's just not the most useful information I need right now.
This is less of a problem with coding agents more so putting learning related questions to an LLM, like is the method covered in this paper, yes no? instead I get an exhaustive but overwhelming and indirect response that contains part of the answer. I just wanted to know if it was worth my time going through the paper but now I'm being bombarded told all this tangential information, which is unclear to me if I need to consider right at this moment, it's really distracting.
Maybe this is something others adapted to but i've resorted speaking past it saying, "this is the question please stay on topic" or literally "one thing at a time please" and then it narrows in, but they really stretch your attention thin if you're not more aggressive with keeping them on topic. The smarter models are better, and if you use max compute it does a better job.
I think they can definitely be helpful for learning, but you got play an active role, you can't just consume what it says like content.
I wish I could edit my original comment to add this correction.
https://x.com/Angus_KST/status/2057757395196293262/video/1?s...
It’s incomplete but it show cases some of what I mean. There’s just a lot more charm in these earlier graphics. I’m fairly certain they had to consider how the different colours of ink bleed on one another.
Like take 1978 for example, this might be some kind of highlighter ink, and when the colours over lap the grid they interact in ways most overlapping geometry don’t in charting libraries (but in CSS you can get a similar effect with mix-blend-mode: multiply)
https://www.rba.gov.au/publications/annual-reports/rba/1978/...
If you go to page 159 of the most recent RBA report, you’ll see otherwise clean clear charts that do a good job of communicating the relevant information (perhaps that’s all there should do from such an institution), but it’s admittedly soulless compared to the charts from previous decades
https://www.rba.gov.au/publications/annual-reports/rba/2025/...
The web platform has been shit long enough that frameworks and build tools ended up getting around to working around many shortcomings that shadow dom and web component APIs seek to address (such as scoping css with css modules then css in JS, now whatever else the cool kids are using), and the end result has less runtime overhead.
So say React adds support for shadow dom, as a user building a SASS app why adopt these APIs when your build system already does these? The framework authors know this, and so it's unclear what they gain from directing resources into making these parts of the frameworks API.
The only reason I tried it in my toy render DSL, is it sounded fun and unlike react I don't have to worry about breaking 10s of thousands of apps if I do it wrong.
Like I found it useful because I was trying to avoid using a build system and local styles allowed me to clean up my styles without resorting to build steps. But I'm largely building tools for myself and I don't really care about load times, and this likely isn't a representative use case.
Basically in my own render DSL like, I do this:
import { customElement, define, shadow } from '...';
export const ExampleInput = define((props, ctx) => {
const sheet = ctx.useRemoteStyleSheet(styleSheetUrl);
const onInput = ctx.useHandler(...);
const onKeyDown = ctx.useHandler(...);
// ...
const field = input
.css({ opacity: sheet.loaded ? '1' : '0' })
.on(onInput, onKeyDown)
.void({ type: 'text', value: text, disabled, className });
return customElement('akst-input-number')
.shadow(shadow.css(sheet).c(field))
.void({ className: hostClassName });
});
Before that I had a more manual process where fetches had to go through a style sheet loading "service" (or a light stateful wrapper over one). This was before I effectively made the above react like clone. Now that just happens behind the scenes, instead of all the nasty wiring I had with the web component class.
They even wrote a book about how they went about it (not that it speaks to the quality of the API) https://link.springer.com/book/10.1007/0-387-28695-0
I actually stumbled upon this book when I was trying to look up how draftsmen (with pens and pencils on paper) did qualitative graphics as I found they had a lot of charm as opposed to modern charting libraries. It's something I noticed when looking through a bunch of historical RBA (Reserve bank of Australia) annual reports, the 1960-1980 charts had a lot of character, but then you go into the early 2000s and its a stale chart from excel.
Anyways ggplot doesn't really recapture the magic of those older charts, but it seems use quite a few of those as a baseline for how to communicate information. Like in figure 20.1 they talk about efforts to replicate older inforgraphics that showed Napoleon’s March on Russia, this graphic here (I think the example in the book is a bit nicer than the one in this blogpost IMO)
https://www.andrewheiss.com/blog/2017/08/10/exploring-minard...
On top of the charts just look nicer than anything you could produce with pyplot (and any API built on top of it) as pyplot seems to be have some really limited raster based rendering or something and the text handling is incredibly limited, I've never had this issue in ggplot.
I feel like most software engineers aren't exposed to because it exists in the R ecosystem which is more so data scientist, econometricians, statisticians and other quantitative data professions, but it definitely one of the nicer APIs and I wish more people in the node and python ecosystem copied their homework. I see vega's full name is something to do with grammars, but idk it's for the same reason.
Elements in shadow root elements can be updated more or less the same way as elements in light doms with incremental patches and updates.
The main beneficiary of supporting shadow root and local stylesheets would likely be hobbyist projects looking to minimise their build step, as local stylesheets give you much of the benefits of many of the tools that handle localising a stylesheet to a component at build time.
Unfortunately, I haven't really seen numbers on this but I can't help but I feel the way styles are bundled by most modern bundlers (with global styles and minified classNames) will likely outperform a bunch of disparate components with their own individual local stylesheet with its own request (even with http2 or whatever). So again I can see why the framework maintainers may struggle justify spending time and energy on this.
But when you think of them as a suite of APIs to define custom elements, that can coexist with your framework components, this delimma goes away.
I do think it's a-shame that modern frameworks don't better support shadow dom and local styles, and local events. Understandably I also get why they also don't see that as a good use of their time either, it adds complexity to the runtimes, they need to observe events at multiple root nodes.
Besides the cost of implementation and commitment to additional complexity, assuming that was a nonissue, with the exception of those otherwise legitimate reasons, there's no technical limitation that prevents React from supporting shadow roots for arbitrary custom element. I made a proof of concept of this myself seems to work quite nicely with a stylesheet loader hook (which ensured it was loaded once and there was a shared sheet between all instances of the same element), but I had to start observing events in each elements shadow root.
But then you see stuff like this https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/
The author is very charitable in their description of the Elm Core teams actions in these interactions, but you read it and they come off entirely unaccountable and dismissive. If they want to make a purely functional language locked down, you really should be upfront that they don't have time to make sure basic parts of the web ecosystem are arbitrarily locked off like i18n until they decide users of their langauge are permitted to use it after ruling out any suggestion it doesn't undermine the purity they were going for.
https://discourse.elm-lang.org/t/bindings-for-intl/1264
Gonna be honest, really got the impression the maintainer here couldn't be stuffed looking to it, and wasn't personally impacted and largely didn't give a shit. Proceeds to run off some bullshit to dismiss the issue entirely about it being too risky (he had better things to do, and anyone he can delegate this too does too), the poster offers to do the work write a report, etc, etc. Then he's ghosted and for some reason the thread is shut after 10 days lol??? I guess giving him the dignity of a reply is out of the core teams hands because of how they arbitrarily configured their discourse.
Don't blame that dude for leaving Elm, glad I never made the mistake of wasting my time being dependent on its infantilizating runtime.
Look if you want to avoid being too coupled to the runtime your language exists in, sounds like a cool experiment, but maybe don't drag everyone along with you until you figure out the basic issues.
All that is 6 years ago hopefully they're more self aware.
Obviously not a replacement for all usecase of the above package (like rendering existing documents), but I use mostly for rendering math here and there in my own notes, I prefer it as I can render math without any dependencies, some examples here [2].
That said I'm my own user and mostly view it the same browser, but I've heard there are inconsistencies in rendering in different browsers.
[1] https://developer.mozilla.org/en-US/docs/Web/MathML
[2] https://akst.io/notes/?app=unsw.3202.07#uc-widget-0-title-13
The USA, and Australia actually use to have far greater state capacity.
Besides political will, the structure of institutions and distribution of authority in both Australia and USA act against the federal governments of either country enacting this.
> The comment from here onwards is about Sydney specifically, so if you're not interested this is your chance to get off.
Unfortunately in Sydney Australia this is almost certainly also regulated https://www.planning.nsw.gov.au/policy-and-legislation/housi...
It seems if you want you're allowed to set it up on your own property, which is surprising reasonable for Sydney standards. Just no more than 6 months after which you need to make a permit, possibly make a development application or something as it may be viewed as a permanent increase in floor space which tends to be tied infrastructure levies and maybe rates (think property tax). You can't set it up in the middle of the outback without some kind of planning proposal to rezone it to permit it.
At least with NSW (the state Sydney is in) the criteria are likely consistent across the state)
In Sydney Trailers likely aren't subject to Development control plans (DCPs) but other kinds of prefab/manufactured homes definitely are. Here's an example of a DCP, here is an example one from Randwick (one of 20-30 councils sydney is compromised of): https://hdp-au-prod-app-rcc-yoursay-files.s3.ap-southeast-2....
It regulates room size relative to floor ceiling distance, solar and privacy impacts on adjacent sites, minimum privacy and solar inside the dwelling (such as the amount of sunlight during the least sunny hour of the least sunniest day of the year), setbacks, etc, etc. If its next a heritage item it can't mimic it, it also can't take attention from it, has to confirm with some abstraction notion of sympathy to the heritage item
> For many sectors of construction, difficulty in achieving economies of scale could be attributed to the fact that only a small number of buildings of a particular type get built in the US each year. There were, for instance, only 10 skyscrapers taller than 200 meters built in the US in 2025
But so on production productivity generally, relating to that
In New Zealand Auckland they did a board upzoning in 2016, it was the largest metro governed under the same planning regieme, they allowed many dwelling types by right, and increased planning controls. Economist Matt Maltman did some research on construction productivity during this period
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5386023
His research (which showed productivity did increased) this is consistent with the idea the point above being productivity gains comes from the ability to repeat the same process over and over which was possible Auckland after they uniformly upzoned the city, after which most lots had higher zoned capacity than its existing built capacity (almost certainly with homogeneous allowed heights and floor space), allowing for this process of repeatedly building the same type of unit over and over. Matt has written more about construction productivity here in
https://inflectionpoints.work/articles/best-practice-for-sup...
Anyways if you'll note that the number of firms providing homes also increased, meaning the process of repeating construction over and over isn't isolated to a few firms. While the size of the industry almost certainly grew, the same number of builders likely were working more and more of similar buildings, and they are repeating similar processes over and over consuming similar inputs over and over.
- Those different housing projects due to some level of homogeneity will encounter similar hurdles where which creates a sufficiently large incentive and market for someone to sell solutions tailored to those problems which likely improves productivity (compliance is likely a big one).
- There was likely a greater rate of interaction of different people in these industries interacting with one another allowing for a greater distribution of construction related ideas, some more efficient than others. Think when you have a new coworker who introduces a new tool and suddenly every starts using, this process is able to happen more frequently.
- Likewise some of those inputs likely had an opportunity to efficient. Inputs from industries with fewer players would have been greater incentivised to sell as many units as possible and find ways to reduce their costs. If they performed price 2nd/3rd discrimination previously due to that market being insufficiently large relative others, they have an incentive to act otherwise.
Even with that still leaves planning controls, which dictates a lot constraint’s on development. In some jurisdictions you can effectively have planning controls that ban some floor plans. Admittedly I’ve just heard of federal HUD maybe this is some unprecedented case where it overalls local government planning and state laws, though I think that’s unlikely, I do know there’s plenty of fragmentation of planning regimes.
Point being, you may be able to construct something and it to tick the construction code boxes, whether the building you can make with it is permitted under planning is a different matter. Which can implicit ban those buildings
For example the zoning code could limits the type of dwelling to something and that thing has a pedantic definition which unique to that jurisdiction, or there’s a combination of max floor space controls and height controls that makes off the shelf prefab components ineffective at making the most of the allowed building envelope. Or a jurisdictions could require design contests for buildings at certain sites or a certain area so it may not be a given you can even use available prefab.
Something like a factory requires an intensive upfront captial investment, if tastes change often enough the process would need to be amendable to adapt to changing tastes.
Combined with that, I think the fact there is no uniform standards for acceptable floor plans, compliant layouts and construction codes across the different jurisdictions really makes it hard for there to be economies of scale.
> note I don’t think construction codes are strictly a problem within the US, there’s apparently a manufactured housing code. However planning controls are a seperate thing and possibly still an issue.
An example from Sydney (which likely relates to other jurisdictions) Outsides construction code, in Sydney there is a quasi instrument called the apartment design guide which issues requirements on floor plans, floorspace, how far a bedroom wall can be from a window in a bedroom, ceiling heights a lot of things that act as constraints on the possible layouts of a home, and I have no doubt some form of this exists in other jurisdictions as well. I imagine when there is so much variation in different legislative constraints in different jurisdictions there isn't really economies of scales as there are actually several different non homogenous market segments with incompatible set of constraints, and where there's overlap it may not be a high demand end product.
I don't think this as much of a problem but I imagine there are cases where some unionised construction industries may refuse to use work on site using prefab components. I haven't really heard of such cases so I'm not convinced this is a real blocker.
No its, and I appreciate you taking the time to read my reply and consider my perspective here.
> The second point I interpret as "colourful returns are unavoidable but good", with which I disagree - even if that interpretation is too strong and is more "... are unavoidable"
Thats fair, but yeah I wouldn't go so far to say its good or imply we should celebrate it in anyways, more so it as a unavoidable constraint that warrants engaging with.
For sure HKT would generalise many stray ends, and there are definately more complicated usecases where you can write much nicer types with HKT, although my experience has been theres been more pain in writing them without HKT than using them without HKT so the pain is a fixed cost of building the library and not an on going problem of using it. Although I am sure there are cases where it's also the case that usage of the library is more painful without HKT.
IDK, I haven't written a ton of Haskell in a while maybe I've forgotten some of its magic and internalised some of the suboptimal aspects of the absense of working without HKT.
But I do from time to time find problems that would be nicer to solve with HKT, I think generally quite a few of them are DSLs or some form of meta programming. I guess in typescript conditional types you can get away with a lot cooked things.
> Transposing a vector of things to a thing of vectors is an example of where colourful output forces colourful input. If you cannot abstract over abstractions, you must write and re-write the sequence function for each abstraction
I've unfortunately also had similar issues from the lack of HKTs with some linear algebra APIs so I don't find this too surprising.
Anyways, the two points:
- The first point was, "not having a common way to generalise over both sync, async or blue, green, brown functions, seems avoidable and bad". This is when the type system struggling to common up with a common classification for function invocation independently of colour.
- The second point was that, was "so what if there are different return / wrapping / container / monad types", which focuses on a more common interpretation of this article but a different one.
In Haskell a type in a result, State, Config, Parsec, Maybe is in it for a reason, and thankfully we can generalise over that. Higher kind types (abstracting over abstractions) is a whole other basket, as an ex haskeller I would love to see them more mainstream but admittedly I don't think language authors are convinced and there isn't much we can do about it, so we should learn to make do with what we have outside of haskell.
Hopefully it's safe read this as there's no common static type between function and async function meaning APIs (that take functions as arguments) have to provide seperate methods (or overloading) for these different colours.
Like in typescript you can write `<T>(f: () => T) => T` because an async function statically is just the return type wrapped in a Promise, not something like `async () => T` you can still pass in an async function as an argument.
I think that's a reasonable thing to take issue with, and its _possibly_ an avoidable design problem. That said I can see it being less avoidable if the async function requires some special kind of invocation (like being associated with some kind of async runtime and its a compiled language).
When I see people bring the issue of function colouring, the focus tends to be on the fact that a function is no longer interchangeable with a sync function and now you have to handle a promise, which I personally find unconvincing if the return type really should be a promise then it shouldn't be interchangeable with a sync function.