Writing new library and expecting people to actually use it without providing types is not realistic. You can write library in JS, but you will still need to provide types, since that's what ecosystem is right now.
I disagree it's hard per se, but I'd agree it's hard to do well. Especially if you have a bunch of JS functions that return (or expect) objects with very similar but slightly different properties. Figuring out the overlap and the semantic relationship between the types is often challenging, because the original authors never thought about the problem in terms of what types of objects they were dealing with.
The best definition i can think of for declarative UI frameworks is probably something closer to 'frameworks that optimize for your ability to make a pure function representing state'.
(After all `[[UIViewController alloc] init]` does indeed purely say 'you have view controller' — that's just not super granular!)
In this light, isn't SwiftUI just a setup more optimized in this direction
I spent a while trying to approach this post with an open mind. In the end I was disappointed.
rel/to title: yes. (just say scroll position. fine.) But also I think this is pretty well understood! (No?)
- In declarative UI / FRP / whatever, you model your basic UI state through a pure mapping from your business logic 'model'.
- But (as in procedural programming) the UI has its own state — that's not necessarily part of your initial business/domain/model.
If you want to model it, you'll have to understand it, read it, and add it to you model. That can be annoying—especially if the APIs for getting or setting the state are bad.
This doesn't really sound like a fundamental flaw conceptually to me. It's just an API with defaults you don't have to deal with unless you need to.
- don't care what your color is? fine. system default for you.
- don't care what tab a link opens in? fine. user default.
- don't care how scroll position is managed? fine. system default.
- want to handle any of them? cool. you can.
It sounds like progressive disclosure of API complexity to me. Great.
> It's totally out of place with the rest of the Swift programming language. They had to add new crap to the language to accommodate its declarative style, when Swift is (was) unapologetically imperative syntax-wise. It's an obvious bolt-on and leaves a really bad taste in my mouth.
Woah now, that's interesting! In my mind swift has had awesome support for functional programming paradigms since launch. I understand it to be leaning in about as far as it can given that it's built with first class support for Obj-c oriented frameworks.
What makes you feel like it's unapologetically imperative?
I'd love any pointers to precedent for how this plays out from here.
1. The acquisition was >1 year ago. (And there's some question of whether FB followed the correct process.)
2. The antitrust concern is in one major market with a ton of political and regulatory power — but still one of many. (Are there international trade agreements that inherently make this ruling impactful outside of the UK?)
3. The acquired company was very unlikely to find a better outcome, and would have been fairly likely to require costly restructuring for lack of this one.
I don't take this super seriously — because giphy feels replicable and, well, it's gifs. But curious if anyone else sees impactful competitive/strategic concerns, or if the matter at hand is really just political precedent setting.
Mostly I feel bad for giphy people. Hope they're nicely contractually protected.
In any acquisition an assessment of the regulatory risks has to be part of the process for the vendor. They took a risk in selling to FB and that risk hasn’t paid off. No one is entitled to the ‘best’ price if it involves something which falls foul of competition law.
And on competition - will anyone else be interested in GIFs if the dominant social network owns the market leader?
> “Companies are not required to seek CMA approval before they complete an acquisition but, if they decide to go ahead with a merger, we can stop the companies from integrating further if we think consumers might be affected and an investigation is needed.”
> He added: “We warned Facebook that its refusal to provide us with important information was a breach of the order but, even after losing its appeal in two separate courts, Facebook continued to disregard its legal obligations. This should serve as a warning to any company that thinks it is above the law.”
> I want this to be the start of a forced breakup of Facebook, WhatsApp and Instagram.
okay
> There’s zero benefit to consumers, and a lot of harm.
There's a ton of potential societal benefit in centralization and/or monopoly in theory. There's also a ton of potential downside. What in particular makes this fall in the latter bucket?
Where's the advantage of instagram, whatsapp and Facebook belonging to one company? The only advantage on any side I can see is combining user data and behavior data to improve ad revenue.
You could argue that features can make it easier across products, but each product would be big enough on their own to develop these features at little cost compared to their income. Apart from that there's no potential upside I can see for a user to have these products under one company.
The same applies to Giphy. Right now, messenger companies don't own Gif companies and it's still very easy to use them together. I don't see the benefit here for a user to have them owned by the same company.
> Where's the advantage of instagram, whatsapp and Facebook belonging to one company?
Common-ish arguments for monopolies, as applied to this situation:
* potentially the interoperability you indicate
* infrastructure investment leading to stability
* similarly: best in class client side software
* security / privacy guarantees (yes. I know, ironic, etc. but the fully distributed multi-company alternative is likely worse on these dimensions)
* single point of accountability for the state and law enforcement. (yes. not likely a HN concern. Still valuable to the state and potentially regular consumers.)
* general pro monopoly argument: fewer resources are wasted in competition, and so can be applied to product development and research. i.e. bell labs
IDK how I feel the scales tip in this case, but treating it as cut and dry feels a bit naive.
So turn it all into a state run company instead? Your points sound as if that would be a potential solution. But that would have its own issues with somewhat twisted incentive structures.
"* general pro monopoly argument: fewer resources are wasted in competition, and so can be applied to product development and research. i.e. bell labs"
You are arguing for Central Planning. You can't be pro-free market and pro monopoly.
At least government monopoly is theoretically accountable to the voters.
Transistors were originally invented during WW2. Reductio ad absurdum - we should have one big state monopoly controlling everything in the interests of permanent warfare.
The deliverables of any software project is obviously incremental in nature (EG, Initial boot with software graphics, 2D graphics, power saving features, 3D graphics etc), so the funding model makes sense
The point of spotify moving into podcasts is to make a netflix-like channel that 1) attracts user and so 2) attracts more publishers. In turn, Spotify can do dynamically targeted and unskippable advertising which attracts more advertisers, and so more publishers.
As users and publishers leave the open, rss based, podcast world will have significant downwards pressure.
Yes. That's the reason why I saved it. I don't know much about quantum mechanism, but I could feel a vague intuition developing after reading this essay.
If not, it sounds like one core issue is 'adding types to an existing untyped codebase is hard'. This checks out. :)