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.
Make does what it does surprisingly well: It runs commands on files based on a description of dependencies. There is no shortage of would-be successors of make, but so far none of them has succeeded, which supports the hypothesis that "make" has hit a sweet spot.
There is one alternative to make which I think is worth mentioning, because of its simplicity, brilliance, and excellent support for correctness: it is redo, as in Apenwarrs redo:
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.
It is more complicated than that. Advertisers are customers too and advertising creates incentive to use Amazon and enter into larger deals with Amazon that ultimately lower prices for customers. Additionally, revenue from advertising can go directly into funding supply chain innovations that result in an even better customer experience. Amazon doesn’t typically do anything unless the total downstream impact is shown to be positive; while customers do get annoyed with ads, they appreciate the nice things ad presence provides for them to a greater extent on average.
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.
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.
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.
"OOP makes it central, and builds around it, while FP de-emphasizes it in preference to ADTs."
ADTs are not an intrinsic part of FP, as not all FP languages even have them.
I'd also question whether ubiquitous polymorphism is overall a good thing in a language, or whether it's misguided complexity. In most OOP languages, any public method can be polymorphic, but a polymorphic function is inherently less predictable than one dispatches off a single type.
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.
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