akst

A question about prefab construction came up at a talk this year in Sydney with Lucy Turnbull (Former Sydney Mayor) and Alain Bertaud (planner and author order without design), Lucy mentioned someone tried this in Sydney and went under and they never heard from them again despite promising the world. Alain mentioned that tastes (think in terms of from finishes to floor plans) change often enough where prefabricating an entire house doesn't really make sense. Not to mention construction codes can change as well (I know in the US it can vary on a county level), they mentioned they saw more success with prefabricating components like windows or fireplaces or whatever.

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.

> I think I was simply not very good at expressing what I was trying to convey, sorry

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.

I think you're confused, I was talking to two different points, while I'm sure I could have communicated with more precision, either missed it, it was unclear or you don't understand, either way I don't really get the gotcha tone when you could ask for a clarification:

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.

> The problem with function color exists when you can't abstract over it

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.

I get what you're saying here but I do think an actual dreams are at least a bit more interesting then AI output.

But I do think such a comparison (to emphasis how unhelpful sharing tailored AI text with others is) would be useful.

Don't take this the wrong way but to anyone who has read the book "The High Price of Free Parking" this contribution to this thread reads like someone who came late to a meeting and missed half of the discussion and keeps asking questions that would have been answered had they joined earlier.

I can see why you might ask this, but the book very much focused on the idea that a piece of land much preserve space for a parking space. It might sound innocuous but it is the source of many issues within cities, a contributor to housing inaffordability, why so many buildings in the US are surrounded by miles of parking, why some of the lots in your city are derelict, etc.

The book very much addresses why mandated parking minimums even in suburban residential lots are also bad (specially the mandated minimum less so the carpark itself), I highly recommend the book mentioned above.

Here's the preface of the book http://shoup.bol.ucla.edu/PrefaceHighCostFreeParking.pdf

There's also a good audiobook.

Very cool! I don't entirely understand some of the operations, but for what I do understand its pretty neat.

I wish in classes we were introduced to a notion of arithmetic on intervals as it comes up. Like in basic statistics with confidence intervals there's ±, as well as in the quadratic equation. It found some what dissatisfying we couldn't chain the resulting a series of operations and instead repeat the operations for the 2 seperate values of the ±. I get a teacher would rather not get hung up on this because they want to bring it back to the application generally, like solving a more complicated equation or hypothesis testing in basic stats. I just wish they hinted at the idea we can do arithmetic on these kinds of things more generally.

I realise what you've got here is well beyond this, but seeing this was some level of validation that treating the interval as a piece of data with its own behaviour of certain operations does make some sense.

This reply was unexpected but a nice surprise :)

I remember your site! I really like the consistent visual language, even if you didn't make the pixel art, at the very least they go well with your site. I entered my email on your other site, feel free to reach out or whatever, also this is my site https://akst.io

Hope you're doing well as well!

As someone else has said it is publicly funded, it's the same with Australia's ABC news [1]. When you watch it on TV, I guess there are ads for its own shows but other than that they are not allowed run ads. Funnily there are ads shown on its stories on apple news, I always wondered if that was in some violation of the Australia Broadcasting Corporation Act [2].

[1]: https://www.abc.net.au [2]: https://www.legislation.gov.au/C2004A02723/2022-02-18/2022-0...

I opened the book, it looks kind of like an essay. But it says this at the start

> This book was created through an extended collaboration between the author, Claude (Anthropic), and ChatGPT (OpenAI). The structure, pedagogical framework, and frustrations catalog emerged from the author’s two decades of teaching creative coding.

I think it would have been better to make a series of blog posts and held off on writing the book until they felt comfortable doing it without AI and understood how to express this ideas without AI.

Before I saw the AI comment, I felt like giving that to someone looking to learn about this might be overwhelming tbh. Now I feel it would be incredibly harmful like telling the blind to follow the blind. A beginner would be better off just to being told to give whatever they want to do a go and use claude as needed or something if they don't understand it. I did wonder why there was no code, I figure maybe they want to keep it general and keep this more philosophical.

tbh I dig the aesthetic of the book, but idk seeing that in the intro just makes it feel like it isn't worth my time.

There’s something called menu pricing, in order to keep its existing customer base buying their more expensive higher end models there need to be an unjustifiable drop in quality to switch.

The gap in spec is no mistake, if it was appealing enough for existing air-book users to downgrade it would cannibalise their bottomline.

I’ve produced music through much of 2010-2020, I wasn’t there in the 1980-2010s but it wasn’t uncommon see discussion online about different samples or things like this. Never really seen any mention something like this unquantified “je ne sais quoi” or at least don’t really recall

My take is, it was the first of its kind to widely circulate exhibiting desirable quantities for sampling, a combination of good enough and path dependency. After a certain level of saturation/entrenchment it carried an aesthetic compared to readily available samples (maybe this is what you meant).

Whenever I couldn’t find a breakbeat sample (or wanted some starting point at least) I’d default to it. When I did music production it was very easy to get your hands on a loop but obviously that’s much later.

The fact you’re talking someone with this frustration shows maybe there are people with use cases other than yours?

When IDEs do resolve this it tends to be because they built some index to look up these identifiers, which is likely taking up a portion of your memory. A language that statically tells you with an identifier comes from will take out less resources, and your IDE can collapse the import anyways.

So not sure why you feel so strongly about a language design whose ambiguity necessitates consuming additional resources to show you your little drop-down menu.

> If Amazon finds your product on another website for lower than its own website, it'll just hide your listing from the search -- this is meant to be pro-consumer (when you go to Amazon you'll get the lowest price).

It’s not pro-consumer, take two seconds to consider second order effects here. If a producer can sell for lower elsewhere they can’t compete on price with Amazon unless they want to lose amazon sales.

The whole obnoxious dogmatic evangelicalism thing is definitely a wider human phenomenon outside software and junior devs picking up new languages.

Definitely isn’t one of those things that can be solved, but it’s helpful to be aware of and process on that basis. I think some personalities are likely disproportionately vulnerable to this behaviour, but I think it largely has a positive core of enthusiasm. It’s probably more a matter of those individuals growing in self awareness.

Perhaps we saw a big wave of that with rust because it meant a lot of things to a lot of different people, some more equip to express their enthusiasm with some self control than others.

Have you got a link to this blog post?

As someone who spent the last year messing around with web components, I think there’s some cool stuff there but I have a new level of appreciation for actual components APIs from actual frameworks.

It’s more a custom element API than a component API, I mean that line in the sand is pretty subjective, but I just can’t see this API being a part of any major web framework, I can see that with shadow dom, I can’t see that with the whole customElement.register and garbage you have to do in the constructor.

Also the goals of this API are just not aligned with the purpose of a framework/component system. I do encourage people to play around with them but it’s really annoying to hear how they’re being promoted they’re are a lot less exciting than the platform advocates are willing to admit but that doesn’t mean they are useless but we need up stop pretending they’re the future of web applications.

Frameworks are often designed with the goal of managing application complexity without being overwhelmed by the shortcomings of the platforms. Web Components have done little to reduce the need for such a thing.

I would love the option for pay for usage for many products I am forced into paying a subscription for.

I think one legitimate difficulty with micropayments for a news site (that has a few options to solve) is the reservation price of most readers for a single article might be lower than the cost of handling the transaction. The best option I can think of is the user needs to add credit their account or a credit card or something, which isn’t uncommon but I think some people might see it as a grift where they pay for more than they’re initially getting.

I think one benefit of it or shortcomings is it’ll probably kill off portions with smaller readership, but if that’s not you -you’re no longer paying for something you weren’t reading.

I do sympathise as someone who has to scrape content from time to time, but that doesn't sound like a problem for the author of the content or something that impacts their intended user.

Auto video playback in Twitter/X isn’t much better especially on the mobile app. I realised this can be remedied by switching to the webapp. It’s a subpar user experience due to constraints of mobile web (and lack of investment by X) but it’s also likely why auto video playback rarely works, so it evens out.

Is frustrating I have no control over it s as a paying user, same with hiding the blue checkmark

They’ve been rolling out a bunch of stuff like this in Australia and the UK. As an Australian I’m fairly certain I was made to do some sort of facial recognition some time ago.

I kind of hate it, but honestly it’s had minimal impact on me and my usage of these services if I’m being real.

I think you might be making an entirely different point.

In macroeconomic, you have an aggregate production functions that represents output for a country or something. In many of these function you'll have a parameter for technology, it acts as a multiplier over inputs, so the greater the measure of technology the greater the output. Quite a few of these also exhibt a characteristic where output drops if technology increases too fast. To illustrate this, imagine a scenario in real life that kind of looks like a rapid evolution of some kind of technology of home phones, to cell phones, to smart phones at a rate faster than people know how to make use of them, while also spending money adoption making the intermediary adoptions quite wasteful.

I think we see an aspect of this here, a lot of things we took for granted are changing, shared assumptions are being challenged and it's a period we're all relearning new things. To some extent spending too much time diving on the current iteration of AI tooling might be for nothing if gets invalidated by another sudden jump.

With all these new tools people are building, I can't help but feel they are building foundations on moving soil.

The argument here is founded on motivated reasoning.

Copyright was founded on similar principles to property rights, it encourages desirable economic by ensuring investment in RnD doesn’t have a free-rider disincentive. Whether it’s the right tool for the job and how enforcement carries out its a another matter. While these laws for property and IP aren’t without issues they do address actual problems.

Personally I would be more open to the idea of open AI flouting copy rights if they weren’t planning on taking a portion of the claim of other peoples creations used via the product while failing to properly compensate the sources of its training data.

I take it because copyright was used to hurt independent and smaller harmless creators, they’re dislike of AI is entirely consistent with that given smaller creatives are being harmed in a sense with their work mimicked and work deprived of them.

Personally I think creatives have an edge as I personally don’t think AI is great at exercising discretion in creativity or design. Which you can see in coding agents their discretion in design is often arbitrary and poor. So I think at least for now that’s still where humans tend to out perform AI

That’s also another thing. Sometimes the output is just junk, like there wasn’t really any intention behind the test to prevent a certain likely scenario arising

Sometimes it just add tests that lock in specific quirks of the code that weren’t necessarily intentional

Yeah, there’s something convenient about a dedicated device when you’re using a notebook and pen and your only other screen is your phone. It’s also nice not having to dedicate screen space to a calculator too.

If I have something more complicated with more moving pieces and data points I will just write a python script.

I like the CASIO fx-CG50, is good but there are more feature rich calculators out there, it’s just less finicky than my more powerful TI-nspire CX II one. I also just kind of dig the aesthetic of the UI reminds me of my old Nintendo DS.

My TI one is good for verifying algebraic substitutions as it’s a proper CAS one.

ATM I feel like LLM writing tests can be a bit dangerous at times, there are cases where it's fine there are cases where it's not. I don't really think I could articulate a systemised basis for identifying either case, but I know it when I see it I guess.

Like the the other day, I gave it a bunch of use cases to write tests for, the use cases were correct the code was not, it saw one of the tests broken so it sought to rewrite the test. You risking suboptimal results when an agent is dictating its own success criteria.

At one point I did try and use seperate Claude instances to write tests, then I'd get the other instance to write the implementation unaware of the tests. But it's a bit to much setup.

You know you CAN actually quantify how bad or good these things are in what respect and their second order effects. The trades off are pretty well understood. Increasing returns to scale are a thing, as are natural monopolies where consolidation is more efficient even with the headaches that comes with regulating a monopoly.

Car makers, entertainment companies, news organisations are very different kinds of industries to the ones we’re talking about here. They aren’t natural monopolies and don’t feature increasing to scale (at all output levels). In media, the reasons we’re seeing consolidation is due to entry barriers primarily with how IPs protections work. This is entirely unrelated.

Also you’re talking about this entirely from a consumers point of view. From economy wide point of view, duplication of a product will pull resources away from other industries that might be more profitable for a country. Which is bad for the same reason tariffs are bad. These are real costs that will affect quality of life and crowd out desirable economic activity.

Just circling back to this original article. This is arguably not one of those cases.

But redundancy and duplication purely on principle is dogmatic and shortsighted, and yes wasteful. We don’t have infinite resources in the world.

If you’re assessing things entirely on a strategic basis makes total sense. It’s understandable why they are doing it but I wouldn’t go so far as to say it’s underrated or suggest there are no drawbacks.

Duplicating things without reason is wasteful. With a hobby project sure that’s your own time and is likely more an act of consumption and personal fulfilment. But these are national economic resources being redirected away from other things.

In software in a large codebase where there are coordination costs with reuse due to the organisation structure, there’s a strategic reason not to reuse, but it might highlight a limitation of the organisation structure, but that’s not something someone making the call to reuse code or not can do much about.

Likewise France really can’t do much about the state of the US and dependency is understandably seen as a risk.