Apple and Fortnite

Events in the Apple vs. Fortnite dispute are unfolding rapidly. In less than a week, Fortnite modified their web page to allow payments outside of Apple's payments API (which meant that Apple could not extract a 30% toll), Apple removed Fortnite's app from the Apple App Store (which meant that customers can no longer install it on Apple devices), and Fortnite ran an advertisement video that parodies Apple's "1984" ad for the original Macintosh computer. Fortnite has also filed a lawsuit against Apple.

A few thoughts on this dispute:

First, Apple will probably win the lawsuit. It seems to be a contract dispute, and I think Apple's terms and conditions are strong enough to defend its actions. (Although I am not a lawyer and I am not offering legal advice.)

Second, Apple is probably surprised at the tactics used by Fortnite. I'm sure Apple is frequently involved in lawsuits, ranging from patent disputes to wrongful termination by employees. Most of these are handled quietly. Fortnite is running a very public campaign, and wants to make as much noise as possible. I'm not sure that Apple is prepared for a public dispute.

Third, Fortnite is prepared for this fight. The parody of Apple's "1984" advertisement shows that -- such a parody was not assembled in an afternoon hack session.

Fourth, Apple is the larger of the companies, and is therefore "punching down" against the smaller Fortnite. Apple faces the risk of looking bad, and must tread carefully. Carelessly worded statements by Apple will be received poorly.

Fifth, it seems that Fortnite is ready to walk away from the Apple platform. A public spat such as this one leaves little room for reconciliation.

Sixth, Apple is most likely ready for Fortnite to walk away. Apple recognizes that the revenue from Fortnite is a small portion of its overall income. Apple probably assumes that it can get other companies to provide games for Apple devices.

Finally, while Fortnite will probably lose in a court of law, they may win in the court of public opinion. This may be damaging to Apple. Apple has fans and followers, but I don't know that Apple has many friends. The fans and followers will stay with Apple, but partners and suppliers may become more cautious in their dealings with Apple. Small developers may delay releases for Apple devices, or may defer them indefinitely. For Apple to win, it needs more than lawyers -- it needs a good public relations campaign.

Add Functional Programming to Object-oriented Programming, not the other way round

The programming world has multiple paradigms, or styles of programming. The reigning champion is Object-oriented Programming, embodied in C++, Java, and C# and oriented around, well, objects. The prior champion was Structured Programming (or Procedural Programming) represented by C and Pascal and oriented around control structures (and avoiding GOTOs). The challenger is Functional Programming oriented around functions, and in the languages Haskell and F#, among others. An older paradigm is Unstructured Programming (USP), which does use GOTOs and lacks the modern IF/THEN/ELSE and DO/WHILE constructs of Structured Programming.

SP and USP operate in the same space: small and medium-side programs. Since they operate in the same space, one often picks one of them, but does not use both. (One can use both, but it is not easy.)

Object-oriented programming (OOP) operates in "the large" and helps us organize large systems. Structured Programming (SP) and Functional Programming (FP) operate in "the small" and help us build short blocks of code that are reliable and readable. In this view, SP complements OOP and they work well together. SP and FP, on the other hand, compete in the same space. We can build large systems with OOP and SP, or with OOP and FP. (We can build small programs with SP alone, or with FP alone. OOP is not useful with small programs.)

Structured Programming is demonstrably better than Unstructured Programming. Functional programming is arguably better then the older Structured Programming. One would think that we would use the best paradigm, and that we would use Functional Programming. But we don't. It takes time to learn a programming paradigm, and most programmers know the Structured Programming paradigm. Structured Programming is what we have, buried inside many modern systems.

The mix of Object-oriented Programming and Structured Programming makes sense. To use a programming paradigm, or a mix of paradigms, one must have a language that supports the paradigms. C++, Java, and C# all support OOP and SP. Pascal supports only SP; Object Pascal and Delphi support both. Haskell supports FP.

The advocates of Functional Programming have noticed that their preferred languages have achieved modest acceptance, but none have become as popular as the most popular languages C++, Java, and C#, or even Python. That lack of acceptance makes some sense, as a Functional Programming language does not have the Object-oriented Programming concepts that help us organize large systems. (Conversations with practitioners have probably ended with project managers and OOP programmers saying something along the lines of "Functional Programming is nice, but we have a large code base in an Object-oriented Programming language, and we cannot give up that organization." 

I think these conversations have spurred the advocates of Functional Programming to merge OOP into FP languages, the hope that project managers and programmers will accept the new combination. The combination of object-oriented programming and functional programming is a nice trick, and it works.

But this approach is, in my view, the wrong approach.

When programmers and managers say that they want a programming language that supports OOP and FP, they don't really mean that they want an FP programming language that supports OOP.

What they want is a programming language that supports their current code base and allows them to add Functional Programming in small doses.

They want a compromise, much like C++ was a compromise for OOP. C++ offered classes to C programmers -- and was originally called "C with classes". It didn't mandate a pure OOP approach. Instead, it let programmers add OOP to an existing code base, and add OOP in a gradual manner.

The "FP plus OOP" approach fails because the existing code base is not OOP, but OOP with SP. A "FP plus OOP" language requires that all of the SP code blocks be re-written in FP. That can work for tiny programs and classroom exercises, but it doesn't work in the industry with large sets of code.

Yes, some companies have large, million-lines-of-code systems written in FP. But those systems were built in FP from the beginning.

Companies that have large, million-lines-of-code systems written in OOP (with procedural code too) don't want to stop everything and re-write that code. They want to add FP in small doses. They want the benefit of FP in a few key locations. Over time, they can expand FP to other parts of the system.

They don't want an FP language with OOP extensions. They want an "OOP and SP" language with FP extensions.

There is a language that may provide a path forward. Microsoft has its F# language, which is a Functional Programming language, but it also lives in .NET, which means one can combine F# modules with C# modules. If one has a system in C# and wants the advantages of Functional Programming, F# is worth investigating.

But beyond F#, I see no languages that offer a compromise between paradigms, and a way forward for managers and programmers. The current set of FP languages are too "pure" and don't allow the mixing of OOP, FP, and SP paradigms.

Perhaps we will see some new languages that bridge the worlds of Structured Programming, Object-oriented Programming, and Functional Programming.

Apple's risky game

Apple's recent spat with Hey has shown a possible problem with Apple's strategy.

If I may oversimplify events: Hey.com built an app for e-mail, and submitted it to Apple for distribution in the Apple App Store. Apple approved it. Hey then submitted an upgrade, which Apple rejected, claiming that the Hey.com e-mail app did not conform to Apple's rules. Hey.com charges users $99 per year for the e-mail service, and Apple wanted 30% of it. Hey fought back, saying that the terms for apps were 30% of in-app purchases, and people could buy a subscription on the hey.com web site. Apple said that such an arrangement was not satisfactory, and stood firm on its rejection of the upgraded app.

Hey's complaint is mostly one of fairness: the terms and conditions said "in-app purchases". Hey thought that they conformed to that clause. Apple then explained that an app must allow for in-app purchases when a subscription is required. (And apparently when a customer subscribes on the web site, Apple still wanted 30%.)

To further muddy the waters, Apple allows "read only" apps such as Netflix to avoid the 30% fee. 

One can see the advantage of Apple's strategy: by forcing an app maker to pay the 30% fee, it increases income (for Apple).

But a side effect of this strategy is that it converts a partner in one's ecosystem into a customer. Were hey.com to accept the proposed terms, they would be paying Apple. (Which, last time I checked, makes them a customer.)

So is hey.com a partner, a competitor, or a customer?

They are a partner in that they provide an app for the Apple App Store.

They are a competitor in that their app (an e-mail app) competes with Apple's built-in e-mail app.

They are a customer in that they pay money to Apple.

It is one thing to irritate your competitors; it is another to irritate your customers. Competitors expect that you will compete. Customers expect that you deliver value. And the folks at Hey consider the services provided by Apple in exchange for the 30% fee to be insufficient.

For Apple, this is probably a business decision, governed by finances and not by emotions. Even if they lose some app providers (customers), they make more money overall.

Further muddying occurred with a recent announcement (true or otherwise) that Amazon paid less than 30% for its app. This will not sit well with developers, especially after Tim Cook (CEO of Apple) claimed that all app developers have the same arrangement.

"Ah," think the small developers, "I see how this works. The big companies have a nice little club with discounts, but I have to pay full price."

Apple must tread carefully here. Apple has its market, and its walled garden, and its App Store. Partners or partners-turned-customers may grumble and pay the 30% "Apple tax" -- for now.

Apple runs the risk of becoming the next Microsoft -- or more specifically, the next big company that people love to hate. Developers may play by Apple's rules, grudgingly, as captives in the market. But when an alternative appears on the horizon, they will remember Apple's behavior and many will flock to that new opportunity. Apple may gain in the short term and lose in the long.

IBM and Apple innovate in different ways

Two of the most influential companies in the PC universe are IBM and Apple. There are others, including Microsoft. But I want to compare just IBM and Apple. These two companies have similarities, and differences.

IBM and Apple are both hardware companies. Apple is still a hardware company, although its main business is phones and not computers. IBM is more of a services company; it was a hardware company in 1981 when it introduced the IBM PC.

Both companies innovated and both companies created designs that influence the market today.

IBM introduced the detached keyboard (other systems were all-in-one designs or keyboard-and-CPU with a separate display). IBM also introduced the internal hard drive, the original 8-inch floppy disk, the 3.5-inch floppy disk, the ThinkPad TrackPoint (the "pointing stick"), and the VGA display and video card.

Apple introduced the mouse for personal computers (the original mouse was two decades earlier and for a system much larger than a PC), the PowerBook laptop (a year before the first ThinkPad), AppleTalk, touchscreen for iPhones, and (notably) iTunes which gave consumers a reliable, legal way to load music onto their devices.

Apple stands out in that it innovates not just by adding features, but by removing them. Apple was first in delivering a computer without a floppy drive, and then a computer without a CD drive. Apple famously removed the headphone jack from its phones. It also omitted the Home, End, PgUp, and PgDn keys on its laptops, going back as far as the first PowerBook. (As the PowerBook was not compatible with the IBM PC, it had no need of those keys.)

Apple, more than IBM or any other hardware supplier, has innovated by removing things. The makers of Windows PCs and laptops had typically followed Apple's lead. They have, over time, removed floppy drives, CD drives, and most laptops now require specific multi-key presses for Home, End, PgUp, and PgDn.

IBM innovated by adding features. Apple innovates by trimming away features. That's quite a difference.

Of course, one can remove only so much. Apple has trimmed the phone to a simple slab with a single port for charging and data transfer. It has trimmed the Macbook to a thin wedge that opens to a screen, keyboard, and trackpad. There is very little left to remove, which means that Apple has little room to innovate along its traditional methods.

But notice that Apple's innovation-by-reduction has been in hardware. Its operating systems are not the equivalent of a slim wedge. To the contrary, Apple's mac OS and iOS are somewhat bulky, which is something Apple shares with Windows and Linux.

Of the major operating systems, mac OS probably has the best chance of slimming. Apple has the "remove things to make it better" mindset, which helps to remove features. Apple also has close integration between operating system and hardware, and drops support for older hardware, which lets it remove drivers for older devices. Windows and Linux, in contrast, want to support as much hardware as they can, which means adding drivers and allowing for older devices.

Let's see if Apple's "less is more" approach works it way into mac OS and into Swift, Apple's favored language for development.

Low code and no code still require thinking

One of the latest fads in tech is the "low code" (sometimes called "no code") approach to application development. This approach lets one construct an application without programming. The implication is that anyone can do it, and that one does not need to study programming or hire a programmer.

In a sense, all of this is true. And yet, it is not quite true.

Nor is it new.

Let's look at the "low code is really old" idea.

We have seen "low code" development for decades. It comes and goes, a cycle almost in sync with cicadas (which emerge from the ground every seventeen years).

It has been called different things in the past: "Report Program Generator", "Powerbase", "Fourth Generation Languages", and possibly even "COBOL" (which was hawked as a way for managers and non-programmers to read -- although not write -- code).

Each incarnation of low-code solutions uses contemporary technology, and always uses mid-grade, generally available hardware. The idea is to make these solutions available to everyone, or at least a large portion of the population, and not require expensive or specialized equipment. The 2020 version of "low code development" includes cloud-based, web-based, multiuser applications that run on servers and are accessed by a web browser.

There are multiple vendors offering different solutions. Some solutions are little more than multi-user spreadsheets with templates for data entry and charts. Others are more sophisticated. But all share a common trait, one that has been in all low-code solutions over time: they build what they build, with little room for expansion or customization. Low-code solutions offer a room with walls, and you can move anywhere in that room -- until you reach a wall.

(Tech-savvy folks will observe that *all* programming solutions, including the high-end hardware and sophisticated programming languages, are "rooms with constraining walls". Computers are not infinite, nor are compilers, processors, and databases. You can do only so much, and then you must stop. All programming methods, high-code and low-code, have limits. But the low-code methods have more restrictive limits.)

My complaint is not about the limits, though. My complaint is about the unstated assumption that anyone can quickly build an application.

Any programming solution, high-code or low-code, requires more than programming. It requires an understanding of the data, and that data is used within the organization. It requires that the person building the application know the range of data values, the properties of individual data elements, and the ways in which those elements can be combined.

In other words, you still have to know what you want to do, you have to understand your data, and you have to think. Even for a low-code solution. Building a solution without the proper analysis and thought can lead to the wrong solution.

Low-code solutions are good for simple tasks, when those tasks are well-defined, have few (or no) exceptions, and do not have high performance requirements.

The high-code solutions require more planning and more coding (of course!), but offer greater expansion capabilities and more customization. You can detect specific conditions and add special processing for unusual cases. High-code languages also offer support for performance analysis such as profiling. 

Another unstated assumption is that once you have built your solution (low-code or otherwise), you are done. Experienced programmers know that programs and systems are not static, that they grow over time as people think of new uses for them. Low-code solutions tend to have little headroom, little upward potential. (They do what they do, and no more.) High-code solutions can be built in ways that let them expand easily, but such expansion is not guaranteed. I have seen any number of custom, high-code solutions that could not expand to meet the growing demands of the business.

Low-code generating systems have a place in the world. One can argue that spreadsheets are the extreme in low-code solutions (if we omit the macros written in VBA). Yet even spreadsheets require us to understand the data.

Selecting a low-code solution over a high-code solution is about trade-offs: ease-of-use (for the low-code solutions) against expansion and tuning (in the high-code solution). Which is better for you will depend on the task at hand, the people you have and their skills, and the future uses of the data and the developed system.

I favor simplicity, and consider solutions in terms of their complexity. I try to use the simplest technology for the solution,

First, consider using a spreadsheet. If a spreadsheet will handle the data and do what you need, use it.

Second, consider a low-code solution. If a low-code app will handle the data and do what you need, use it.

Finally, consider a high-code solution. If the simpler solutions don't do what you need, use the high-code solution.

But think about what you need, about your data, and about the limits on different solutions.

Then decide.

Remote work was a perk, now it may be the norm

Before the 2020 COVID-19 pandemic, remote work was unusual, and office work was the norm. After the pandemic, which will be the perk and which the norm?

During the pandemic, for many companies -- especially those which develop software -- remote work has become the norm. But that is during the pandemic. I am thinking about the period after the pandemic.

I am quite certain that companies that have switched from the pre-pandemic configuration of a large office building full of analysts, programmers, testers, and system administrators to the pandemic configuration of a large empty office building with analysts, programmers, testers, and system administrators working at home have noticed that their large office building is ... empty. I am also certain that someone in those companies has "done the math" and calculated the savings in keeping those employees working from home and moving the necessary employees to a much smaller office building.

(I am also certain that most office buildings are leased, and the owners of said buildings have looked at the possibility that their clients will want to move to smaller quarters. But back to the client companies.)

It is clear that after the pandemic, at least some companies will switch to a permanent "work from home" strategy. Twitter and a few other notable companies have made such announcements. But will all companies do so?

The 2020 COVID-19 pandemic may bring about a change to corporate culture. The pre-pandemic mode of thought (employees work in the office except for a few favored individuals) could switch to a new mode of thought, namely "employees work from home except for a few favored individuals".

It is possible, although unlikely, that all companies will change to this new mindset of remote work as the norm. It is more likely that some companies will change and some companies will stay with the original idea of remote work as a perk.

And it is quite possible that some of the former will adopt a second mindset of "office work as a perk". That is, the mirror reflection of what we had prior to the pandemic. Instead of remote work considered a perk, granted to a few individuals, some companies may consider office work the perk, granted to a few individuals.

What's more, the job market may be fractured between companies that want remote workers and companies that want in-office workers. This may lead to additional details in job postings ("remote only", "remote but in same time zone", and "in-office only", or "in-office at least three days per week"). The one standard arrangement of working in an office five days a week may no longer apply.

In the long run, I think the "remote as norm" strategy will dominate. The advantages of "work in the office" seem to be informal conversations and better communication through body language, neither of which can be expressed in dollars. The advantages of remote work can, in contrast, be calculated in dollars (the cost of not leasing the office building with its desks and chairs, minus the cost of securing communications to remote office workers).

Looking at past performance, hard factors (dollars) win over soft factors (non-dollars). We can look to past labor movements and labor laws. Child labor was prevalent -- until outlawed. Work was 10-hour days and six days per week, until the forty-hour work-week was enforced (or at least strongly encouraged) by labor law. Discrimination by age, gender, and race were the practice, until outlawed.

Before anti-discrimination laws, one may have argued that it made sense to hire the person with the best qualifications regardless of race or gender, but companies somehow hired mostly white males for the better jobs. Practices that just "make sense" weren't -- and aren't -- necessarily adopted.

Work in the office may "make sense" for some things, but the economics are clear. I expect companies to take advantage of the economics, and switch workers to remote work. I also expect that remote work will be assigned by a person's position in the corporate hierarchy, with executives and managers working in offices and "worker bee" employees working from home.

Some companies may even offer work in the office as a perk for certain positions.

Rough seas ahead for Intel

Apple's announced that it is switching processors from Intel to ARM. (For the MacBook. Apple has used ARM for iPhone and iPad for years.) This announcement indicates problems for Intel.

But first, some thoughts on "market leaders".

We like to think that markets have leaders, and those leaders set the direction and pace for the market, much as a squad leader in the military sets the direction and pace for the squad. Let's call this the "true leader".

There is another type of leader, one that instead of setting the direction and pace, looks at the crowd and runs out in front, and then claims leadership. Let's call this the "opportunistic leader".

So is Intel a true leader or an opportunistic leader? I think it is the latter.

One could argue that Intel lost its ability to lead the market in the mid-1980s, with the specific culprit being the IBM PC. Prior to the IBM PC, the market for personal computers was fractured, with different manufacturers using different processors. Apple and Commodore used the 6502, Tandy used the Zilog Z-80 in the TRS-80, and lots of others used Intel's 8080. Intel had the 8088 and 8086 processors, but very few manufacturers used them.

In the 1980s, Intel had a plan for the future of microprocessors - the iAPX line. It was a plan that built on the 16-bit 8086 but expanded to different architectures as the processors became more powerful. There were several specifications for processors, culminating with the iAPX 432 a 32-bit processor. (At the time, this was impressive.) The more powerful processors were not compatible with the 8-bit 8080, or (notably) the 16-bit 8086. It was a nice plan.

The IBM PC and the market for the IBM PC invalidated that plan. People wanted the IBM PC, which meant the Intel 8088. Later, it meant the IBM PC AT with the Intel 80286, which was not an iAPX processor.

This shows that Intel was not leading the market in the "true leader" sense.

Want another example? Let's look at "itanium", Intel's attempt at 64-bit architecture. (Also known as "IA-64".) It was a processor that was not compatible with the existing 32-bit software. Worse, it has a design that pushed work to the compiler, and some of that work was not determinable at compile time. AMD countered with x86_64, a design compatible with existing 32-bit code, and customers wanted that instead of Intel's offering. They wanted it so much that Intel eventually adopted the x86_64 design and abandoned IA-64.

I think these two examples show that Intel is more of the opportunistic leader than the true leader. Intel can design processors, and can design and manufacture the chips and build the support circuitry, but it's business strategy is to run out in front of the market.

Which brings us to Apple and ARM processors.

Apple has announced that it will switch from Intel processors to ARM processors for its Macbook laptops.

Is Apple a true market leader? Or are they opportunistic, running out in front of the crowd?

It doesn't matter.

It may be that Apple's decision will "move the market". It may be that Apple's "spidey sense" has detected a desire to shift to ARM processors, and Apple is first in the market to make the change. Whichever reason, Apple is doing it.

I think that not only Apple will shift from Intel to ARM, but the rest of the market will, too. For two reasons: cost and efficiency.

People will want computers with ARM processors because they (the computers) will have a lower price. 

People will want computers with ARM processors because they (the computers) will be more energy-efficient. (Which means a longer battery life.)

People who buy computers generally don't care about the processor. They care about running applications, and ARM can deliver that.

Windows is ready to move to ARM. Linux is ready to move to ARM. Apple is not only ready to move to ARM but is in fact moving to ARM.

What will happen to Intel?

Intel has a definite problem. They have lost the low-end market for processors. They are losing the mid-range market for processors.

One might think that Intel may find haven in high-end processors, running servers and other high-power computers. And there may be some space for them, but there is a problem: IBM.

IBM has staked out the top end of the market, with System/z processors (the successor to IBM's System/360, System/370, and System/390 processors) running the big servers that host virtual machines. IBM has a competent business there, one that will not be easily displaced by Intel's x86 processors.

Intel has a market that it being eaten by ARM at the bottom end and limited by IBM at the top end. Not an enviable position.

And certainly not a market leader, in any sense.