That's just not how that works, how much consumers will pay is a binding constraint. Apple isn't subsiding their phone with developer fees and distributing their below marginal cost. Apple is almost certainly charging well above its marginal costs and is already charging the revenue maximising price, it's not willingly leaving money on the table.
Not entirely how you've made formed this connection but respectively it sounds like you've confused several things here.
They are obviously not charging the maximum price because they’ve raised the price significantly when the iPhone X came out and suffered no harm. Apple sets prices based on a 30% raw profit margin and ignores the market except as it constrains their raw material and manufacturing costs. They use that 30% to pay there other costs, such as iOS development and R&D and investing in manufacturing partners.
The iPhone X, like all models, is a different model than all the others; the maximum price for one model is not going to be the maximum price for another.
> Apple sets prices based on a 30% raw profit margin and ignores the market except as it constrains their raw material and manufacturing costs.
Literally impossible ahead of time, as some of their costs are fixed rather than marginal. If you spend, as they did last year, ~$34.5bn on R&D, and you make a thing that costs $1000 to make and then you price it at $1300, but the market looks at what it is and what it costs and says "nah" so only 1 million people buy it that year, then what you're actually making isn't a 30% profit, it is a loss >110x your revenue.
We don't know exactly how much R&D was spent on the AVP, nor the exact sales, but the market reaction to the price is something you should have in mind. No matter what its unit economics were, Apple probably made a loss overall.
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.
Even in the Era AI, GGPlot's API is still the best charting API. The name "Grammar of Graphics" isn't just marketing, they literally sought to write a god damn grammar to was capable of expressing all possible qualitative graphics.
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)
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.
Yeah Grammar of Graphics semantics are already very ideal for both humans and agents alike. Ggsql is a recent project that implements it as SQL user defined functions which is even more agent friendly
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)
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
not the parent, but one thing i find charming is that a lot of them have a really good feel for line weight and inking style, and vary it interestingly in various parts of the plot. computer generated charts tend to have a much more uniform line weight.
I think it's better to think of "Web components" as "Custom Elements" they really aren't components in the way you think of components in other frameworks (which on the web introduced them first), and I think most of the dissatisfaction with them comes from trying pretend they're an alternative as they just aren't. Components in almost every other framework are efficient (efficient rendering runtime) and expressive (the ability not to have a root element but instead a frag, or context APIs etc) in ways that web components never will be, which makes them unappealing.
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.
I think also the lack of framework support for things like defining a shadow root probably feeds into this idea it needs to be mutually exclusive.
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.
There's also the issue that web components are eager. Once it's in the DOM, and upgraded, it will cause an endless cascade of requests for every import inside.
I don't know if they fixed it, but when reddit rewrote their menu with web components, it required 100+ http requests to render.
I have a wrapper around fetch for static requests so that no matter how many requests for the same file are made at the same time, only one of them actually goes out over the wire.
There is no problem here, whether you have a page that requests a static file 1000 times in a nested DOM or a single time. The outcome is still only a single request.
> I have a wrapper around fetch for static requests
imports are not fetched by JS fetch. They are fetched by the browser. It happens before any JS in the component is even run.
That's why web components force request cascades: for every import the browser fetches the script, parses it, and starts fetching imports there, recursively.
Edit: it's also one of the reasons why bundling exists in most JS build tools. `import` was conceived when parallel fetching over http2 was right around the corner... and never materialized. So why make potentially hundreds of inneficient network calls (with browsers restricting them to something like 4 at a time), when you can just collocate code and dependencies?
Ah, I see what you mean. You were talking about using imports recursively.
I use fetch instead of imports for web components because I have a web component that does client-side includes, and it's literally easier to do client-side includes in a performance manner than anything else, including the recursive case.
Yes you can invent all kinds of workarounds for their core design. Re-implementing imports like you do. Or bundling, like everyone does and something that even lit recommends: https://lit.dev/docs/tools/production/
Except cache is not infinite, it is routinely expunged and re-fetched.
The "nothing burger" is so significant that even projects whose stance is "web components are the end all be all of web development" like lit recommend bundling.
I don't know I've encountered this same issue, but I've seen cases where the same stylesheet would be fetched multiple times which is quite annoying. I had to go out of my way to setup something to handle this.
There's a bit going here, and my terrible method names probably don't help, but `ctx.useRemoteStyleSheet` internally checks if the stylesheet has been fetched is the process of being fetched, returns an object which contains the load state allowing the component to handle its unloaded state. But this might avoid that specific issue of 100+ css requests, I still get quite a few just not that many.
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.
Support for anything web components-related is a death by a thousand cuts both for the browsers and for the framework authors.
For the browsers:
Shadow dom breaks almost literally everything. It's a parallel world that exists on its own and that needs dozens of additional web standards to patch holes introduced by it. And delays dozens of useful web standards that now have to be aware of it.
On top of that nothing in web components is ever created thinking even one step ahead, and break multiple pieces of basic functionality. It's a collection of barely fitting patches. E.g. at first they couldn't send data in forms. Enter FormData. Oops, still cannot be a custom form submit button. Here's a 7-year old still unresolved issue: https://github.com/WICG/webcomponents/issues/814
For frameworks:
Framework authors have to patch all thise holes on their own. Because unlike web components they actually do care about standards and browser functionality. If styles don't work, forms din't work, code doesn't work etc. because of web components, it's the framework that will be blamed.
100% agree, and for most heavy users it really doesn't really enable them to do build any kind of app they weren't already able to do before.
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.
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.
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.
I see all these people complaining about Elm limiting privileges to certain Github projects. A sensible complaint. But why hasn't anyone simply forked Elm, made the small tweak to make the check function return true or whatever, and offer that as a download/patch to the community?
I understand that defaults matter and that can have a large impact on the flow of libraries and code and stuff... my point is more, if you've got production code bases on this language, or at least, did 6 years ago, why so helpless? Nothing makes the point that an open source project can't dictate to its customers like the customers taking the "open source" part seriously.
I don't actually expect that to "work". What I expect to happen is that in the second-order effects that it would resolve this matter one way or the other once and for all. Either the core language realizes they need to accept the change, or the community works around the blocker, or the core language goes closed source and removes all doubt and people can move on, including their production services.
Is anyone else where familiar with MathML[1] and tried using it place of LaTeX?
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.
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.
> think the fact there is no uniform standards for acceptable floor plans, compliant layouts and construction codes across the different jurisdictions
FTA: “Conventional homebuilding is subject to different building code requirements in different jurisdictions, depending on what version of the code has been adopted. But manufactured homes are built to one set of national requirements, the federal HUD code.”
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.
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
I witnessed this process with a friend, a freshly-happily-divorced doctor who moved away with her two kids and wanted a fast solution. Damn, they were quick. It took a few months to produce the components (they have a backlog), then something like 4 days to put together.
Idk, but it seems like you could attempt to use this argument for absolutely anything that is manufactured.
Why do people buy manufactured cars instead of custom ones? Is it because they dont care or is it because a custom car would be 10x more expensive?
If they could actually manufacture a house that is 1/10th or less the cost but the tradeoff is its a little outdated or the layout isnt exactly what they want, i have a hard time beliving people wouldnt take that trade.
communist countries before 1989 did this en masse producing large concrete panels with each wall being basically one, they could erect apartment blocks very fast and build thousands of apartments, they also used unified prefab "core" for bathroom/toilet
but it's difficult to say how economical it would be in market economy since they did it in centrally planned economy
Paneláks work, in the sense that after the necessary fixes and improvements, plenty of people still live in them happily.
Some comments from the Commie era, though:
* quality of work used to be shoddy in a legal environment where firing a drunkard was illegal and there were no competing firms. In a competitive market, this can only work if the people doing the building are reliable and competent,
* some level of personalization, if only decorative, goes a long way. If all the buildings look identical, it wears down on people:
* you really, really have to think about how people will use the resulting architecture. Some such buildings had a lot of various empty corners and dead ends where people would piss and worse, thus developing an extremely disgusting smell.
I don't think quality of work actually improved that much, people like to bash these commie buildings, but when you look at new buildings it's not really much better. Now you have competitive market, but the result in race to the bottom (price) is the same, they jsut hire the cheapest Ukrainian and you will get the expected result.
I have good examples, we had vote in our building who will upgrade our roof, we had offers for like 1.2M CZK, 1.8M CZK and 4-5M CZK, while they all had space specs, same warranty, I was the only one who voted for cheapest option, the rest of the people used logic "won't vote for the cheapest" option and the result was exactly as I expected, instead of the cheapest Ukrainians we paid 50% extra for very same Ukrainians doing the job under different company with bigger margin. Of course the roof which didn't leak before "upgrade" started to leak in my apartment, so much for the quality of work. When we asked them to fix it, they claimed it's leaking because of my A/C on the roof (which didnt leak for years before their "upgrade"), but 3rd party inspection confirmed they glued insulation wrong and surprise surprise after fixing it stopped leaking while nothing was done about my A/C. There was not a single Czech speaking person working on the roof since I could hear them shouting until very late and had to climb to roof at one instance when they kept working still around 9PM, why would they care when they go to dormitory without families...
Building across the road was fixing the roof as well, done by usual non-local suspects as well and the quality? Immediately after they "finished" their job I could see objects slowly falling from under the roof, which is now going on for years, but most of the residentof the building seem to not care or are unaware of this since it's empty wall without windows, which my kitchen window faces.
So yes, quality of work on panelaks was very inconsistent (there was no 90 degree corner in my bathroom/toilet when I was remodeling, my panelak has even concrete walls in toilet/bathroom unlike the cheaper prefab core in most newer panelak buildings, prefab with 90 degree corners would be in this aspect improvement), but so is quality of the work on new buildings by my experiences and I could add more.
I want to say from thousands of miles and an ocean between us, the roofing market is the same. Most contractors bid the work by hiring the same groups of people that have either low/no skill or are displaced/not exactly legal immigrants.
I was able to hire a company that employed locals and you know what, the price was 25% higher, they took twice the time to finish, and the roof still leaked. I've had one fixed and now have another leak to get fixed. I won't let them back on my property.
Yeah these are definitely some of the more well known examples, these early communist countries tended to have a lot of state capacity so if there were such things like local planning controls and they got in the way of state priorities they were simply rewritten or appealed.
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.
Not only communist countries, Sweden had Miljonprogrammet[0] between 1965-1975, Wikipedia's page about it is a good read for more details:
> At the time, the intention to build one million new homes in a nation with a population of eight million made the Million Programme the most ambitious building programme in the world. In contrast to the social housing proposals of many other developed countries, which is targeted at those with low incomes, the Million Programme was a universal program intended to provide housing to Swedish people at a variety of income levels.
I currently live in a townhouse built during that period, the house is from 1974, around me in the same neighbourhood there are many houses of the exact same floorplan. Each row has 4-5 townhouses, 3-4 rows are built around a central playground where each row faces each other, this pattern repeats spreading across a 2km stretch between two lakes and a forest, there are around 200-300 of these townhouses in the neighbourhood. Closer to the metro station there are higher density buildings, the low-density ones (like mine) are built on the edges of the suburb, still a short 10-15 min walk to the station.
They are all based on pre-fabricated concrete structures, the finishing varying a bit (wooden panels, different colours). Also they were built in a way to make renovations and reconfigurations easy, accessing utilities is straightforward and it was easy to upgrade my house's electrical systems to have many more outlets in different rooms than it was originally planned for.
I wish similar programs would be discussed these days, it was an effective way to improve the housing stock in a short period of time.
> 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
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
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.
> 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.
Your first paragraph links having the colour in the type system as allowing you to write functions that take arguments of parametric colour; your last paragraph says you're unconvinced that you might also like to write functions that return results of parametric colour.
An example: a vector of things to a thing of a vector, for "thing" in (promise, option, result<E>, ...). Such a function should only really return a promise if it's given a vector of promises, and, with an interface that "thing" supports, can be written generically for all those things.
(In Rust, there are separate implementations of that for Option and for Future.)
Higher-kinded types are the (a?) design solution, but they _do_ come at a cost, and for some that cost is higher than the cost of colours.
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.
I think I was simply not very good at expressing what I was trying to convey, sorry, and it is a fault of mine to come across as gotcha-y even when trying not to. Thank you for responding with patience despite that.
The first point I interpret as "colourful arguments are avoidable and bad", with which I agree.
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".
A function's type is its full signature, including inputs and outputs. When you have first-class functions, you have values with function types, and those values are inputs to other functions. Necessarily, then, if you colour outputs you have also applied colour to inputs.
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'm in agreement with your closing paragraph's sentiment. That HKTs aren't a broadly adopted solution is something I accept, but I reserve the right to low-key begrudge it.
(And the more I write about this, the more I wish the original article had used "flavour" rather than "colour" as I try and probably fail to find phrasing that doesn't simply sound like portions of a racist rant.)
> 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.
Not entirely how you've made formed this connection but respectively it sounds like you've confused several things here.