Web Excursions 2021-04-24
🌟 [Post of The Day] Green Vs. Brown Programming Languages
A dreaded language is one you work with extensively in the current year but don’t want to continue to use.
A loved language you use extensively and wish to continue using
dreaded languages are likely to be used in existing brown-field projects.
Loved languages are more often used in new green-field projects
Developers are giving a halo to languages that are newer or were not used commonly in the past,
and they are giving horns to languages that have been around longer.
I think this is because nobody likes maintaining someone else’s code.
And also, because of Joel’s Law: reading real-world is code hard. Building something new is fun, and new languages are used for that more often.
They are not dreading a language because they heard it was complex, but because they have to work it and feel real pain.
The TOP 15 Dreaded Programming Languages: VBA, Objective-C, Perl, Assembly, C, PHP, Ruby, C++, Java, R, Haskell, Scala, HTML, Shell, and SQL.
The TOP 15 Loved Programming Languages: Rust, TypeScript, Python, Kotlin, Go, Julia, Dart, C#, Swift, JavaScript, SQL, Shell, HTML, Scala, and Haskell.
Measuring Brown vs. Green Languages
The TIOBE index
claims to measure “the number of skilled engineers, courses and jobs worldwide” for programming languages
as a proxy for a language having accumulated lots of code to maintain.
Out of 22 Languages in the combined dreaded/loved list, 63% are Brown
a programming language life cycle:
loved programming languages get used a lot,
which leads to code maintenance,
which causes people to dislike them,
which leads to people looking for greener pastures and trying out a newer language.
Rust, Kotlin, and the other green languages may still be in a honeymoon phase.
People’s love for working with them may have as much to do with not working in 20-year-old codebases as it does with the particular languages.
Apple's M1 Positioning Mocks the Entire x86 Business Model - ExtremeTech
No single x86 CPU is sold this way or positioned as a solution to such a broad range of use cases. There are three reasons why.
First, PC customers generally expect higher-end systems in the same product family to offer faster CPUs.
In the past, both Apple and x86 systems were sold in such fashion.
Second, Intel and AMD both benefit from a decades-old narrative that places the CPU at the center of the consumer’s device experience and enjoyment
and have designed and priced their products accordingly,
even if that argument is somewhat less true today than it was in earlier eras.
Third, no single x86 CPU appears to be capable of matching both the M1’s power consumption and its performance.
Apple’s willingness to position the M1 across so many markets challenges the narrative that such a vast array of x86 products is helpful or necessary.
It puts Intel and AMD in the position of justifying why, exactly, x86 customers are required to make so many tradeoffs between high performance and low power consumption.
Apple’s gamble, with the M1, is that its custom CPU performance is now so high, at such low power consumption, that the choice of chip inside the system has become irrelevant within a given product generation.
There’s no chance Apple can address the entirety of its market with a single SoC, but it might be able to do so with just 2-3 different core designs
HN
klelatti: One thing which I don't think has been commented on is the marketing effort behind the M1.
a consistent message that "M1 is great - get a new Mac and get an M1".
Intel's marketing was a bit confused - i7 stays the same over 10+ years with only the obscure (to the general public) suffix changing from generation to generation.
Get better at Googling | Hacker News
qyi: Use quotes to force an exact-match search — Almost never works these days.
What Google Search is trying to be is a thing you can ask questions and get an answer back.
tyingq: The "AROUND" proximity search is neat as well, especially for words with dual meaning.
Daring Fireball: Thoughts and Observations on This Week’s ‘Spring Loaded’ Apple Event
Apple seems to be adding paid subscriptions to Podcasts the right way:
it’s an entirely new thing that doesn’t disrupt any of Apple Podcasts’s established support for “regular” podcasts
by which I mean free and open podcasts published over the web using RSS.
You can even add paid episodes to a free podcast for a freemium model,
and while the paid episodes will only be available to listeners using Apple Podcasts (and paying via iTunes), the free episodes are just in the same RSS feed as before, accessible to any and all third-party podcast players.
Paid podcasts that don’t go through Apple — like my and Ben Thompson’s Dithering — will continue to work as before.
Michael Tsai - Blog - Apple Sued for Removing Purchased Content
David Andino is the lead plaintiff in this case. He alleges Apple reserves the right to terminate access to any movie you “purchase.” And that they do this on regular occasions. He wants them to stop telling people they have “bought” things when they really have not.
This week, U.S. District Court Judge John Mendez made clear he isn’t ready to buy into Apple’s view of consumer expectations in the digital marketplace.
“Apple contends that ‘[n]o reasonable consumer would believe’ that purchased content would remain on the iTunes platform indefinitely,” writes Mendez. “But in common usage, the term ‘buy’ means to acquire possession over something. It seems plausible, at least at the motion to dismiss stage, that reasonable consumers would expect their access couldn’t be revoked.”
In another case, Matthew Price, the plaintiff, reportedly spent nearly $25,000 on content attached to an Apple ID. When Apple terminated Price’s Apple ID for an alleged violation of its terms and conditions, Price lost access to all of that content.