I think it is simply that make is too crufty to extend. It has perma-broken behavior around space handling, which nobody dares touch [1]. But you can't replace it because it is entrenched, so Makefiles must be wrapped, by configure or CMake or whatever. And these in turn have their own cruft, so must be wrapped, by autoconf and...well someone please wrap CMake!
The C and C++ ecosystem is crying out for a new build system, but there is no mechanism to converge on one. It's bad.
Amazon ads are contrary to the company's mission statement of being the "most customer centric company." They could improve the customer experience at one stroke by eliminating pay-for-placement.
What a sad vision. Per the article, the most important thing about software is that it is safe. The role of an OS is to protect against abuse. The web is inherently safe; therefore we should use web apps instead of native apps. This is profound technological pessimism.
A different vision: computers empower people. An OS provides APIs and UI conventions, and apps can use them to build upon each other, so that users can bring their knowledge from one app to another. Users invest in learning advanced techniques because it's worth it, because all our software participates (think keyboard shortcuts or Unix pipes).
The web has none of this. Websites are not cultivating a new UI vocabulary. Most websites don't support even basic interactions beyond click and tap. They may even actively parasitize the old: Google Docs supports cmd-Z but not Edit->Undo; we are being taught to distrust our UI, the OS itself is being eroded.
> users who cannot perceive or experience the web delivering great experiences
Then build those great experiences and Apple will change its tune. Seriously.
> The web was a lifeboat away from native apps for Windows XP users. That lifeboat won't come for iPhone owners because Apple won't allow it.
iPhone owners are happy and Apple knows it. On the iPhone, web apps are not a lifeboat; instead the web is displacing high-quality native apps with alien-feeling lowest-common-denominator stuff. No thanks.
It does not. -XOverloadedStrings unlocks `fromString :: String -> a.` That is not a polymorphic string interface; it's just syntax sugar for making something else from a string literal.
Right. But OOP makes it central, and builds around it, while FP de-emphasizes it in preference to ADTs.
Strings are a good illustration. Instead of an abstract polymorphic String type, Haskell provided a concrete String type as an ADT. This proved too inflexible, which is why we have Text, lazy Text, ShortText, etc. Compare to NSString which also has multiple representations but hides them behind a single polymorphic interface.
I agree with that. If you create accessors as a matter of course, then you are mostly adding dead weight. But accessors can add a useful layer of abstraction at the interface layer, as you say.
OOP (as Alan Kay conceived it) was explicitly inspired by biology. Objects are cells and communicate through exchanging messages. State is local and hidden, and data itself disappears, which means that the program as written may be ignorant of how operations are performed.
"Safety" and "performance" are not always the most important considerations. For example, Apple uses OOP so that its frameworks can evolve without breaking client apps. NSDictionary is a dynamic object because it permits the implementation to be changed or replaced, and this comes at a cost of performance.
The behavior is disabled in private browsing. That suggests some acknowledgement of a privacy risk.
What is creepy here is that a random website which I closed ten minutes ago get to know when I unplug my ethernet cable. I am happy to tell a website when I close it - that is its purview. But when I close a website I want it to be closed. Now I know it lingers.
> These should be compilable to a single asm routine, as long as there is an homogeneous way to copy them
That's a massive asterisk. In practice, copying values to the heap is complicated. Integer values may be memcpyed. Pointer values may require read and/or write barriers, or perhaps reference counting. Compound types may require some combination. Maybe you have copy-constructors and you need arbitrary callouts! These implementation details can't be hand-waved away.
> The difference between this case and the polymorphic case is that here the underlying structure (eg "compare" or "insert") isn't done in a homogeneous way (single routine) for every type: the polymorphism is ad-hoc and not parametric. The vtable solution is a form of boxing and that impacts runtime
Kindly, I think you have some confused terminology. Parametric vs ad-hoc polymorphism is a difference in the type system, and occurs long before the optimizer kicks in. Parametric polymorphism is a single function implementation parametrized by types. Ad-hoc polymorphism is multiple implementations, and the compiler chooses one based on types (e.g. C++ overloading or template specialization).
If the optimizer chooses to emit a specialization, that does NOT make it ad-hoc polymorphism. That's just a detail of the optimizer. And it is a distinct optimization from inlining, for good reasons, like not wanting to be tied to the inlining cost model.
> for efficient compilation of languages with generics you need to have an efficient compilation of parametrically polymorphic functions (by type erasure)
C++ and Rust both have efficient generics without using type erasure. Boxed generics are not necessary at all, as long as you accept static linking.
Swift has tried to address this by making specialization an optimization. When it compiles a generic function, it emits a single boxed implementation, like Java. But the optimizer may also choose to specialize it for concrete types, like C++ or Rust does.
It sounds nice, but there's a huge performance difference between boxed and specialized. When you make a function generic, the compiler boxes values, conservatively emit retain/release, others.
The difference is so large, it justifies giving the programmer levers to control specialization. Swift team has added "@_specialize" as a hint. I think they should go further.
What I don't know is how specialized generics can participate in library evolution. If a dynamic library provides a sort routine, and you specialize it, what happens when the library changes? This is where a JIT or the .NET model (compile at install time) can pay off. Apple has laid some groundwork for this (bitcode, Rosetta 2) so they can certainly get there if they choose to.
Anyways I think the real dilemma is whether generics are meant to be a performance optimization (C++, Rust) or just for typechecking (Java, C#). The cost of saying yes to performance is library evolution.
I don't understand why Apple is holding anyone back. Just build an app that doesn't work on iOS. There's lots of apps exclusive to iOS and Mac - why not exclusive Android?
If the app really is a game changer, if it's that compelling, Apple will absolutely change its tune.
The C and C++ ecosystem is crying out for a new build system, but there is no mechanism to converge on one. It's bad.
1: http://savannah.gnu.org/bugs/?712