The (eventual) rise of style-checkers

The IT world changes technology and changes practices. We have changed platforms from mainframes to personal computers, from desktop PCs to web servers, and now we're changing from web servers to cloud computing. We've changed programming languages from assembly to Cobol and Fortran, to Basic, to Pascal and C, to C++, to Java and C#. We're now changing to JavaScript and Python.

We change our coding styles, from "unstructured" to structured and from structured to object-oriented.

We also change our development processes. We started with separate tools (editors, compilers, debuggers) and then shifted to the 'IDE' - the integrated development environment. We added version control systems.

The addition of version control is an interesting study. We had the tools for some time, yet we (as an industry) did not use them immediately. I speculate that it was management that spurred the use of version control, and not individual programmers. Version control offers little benefit to the individual; it offers more to managers.

The use of version control systems allows for larger teams and larger projects. Without version control, team members must coordinate their changes very carefully. Files are kept in a common directory, and updates to those files must ensure a consistent set of source code. It is easy for two programmers to start working on different changes. Both begin by copying the common code to their private workspaces. They make changes, and the first one done copies his changes into the common workspace. When the second programmer finishes, he copies his changes to the common area, overwriting the changes from the first programmer. Thus, the work from the first programmer "disappears".

These problems can be avoided by carefully checking prior to copying to the common area. For a small team (less than fifteen) this requires effort and disciple, and is possible. For a larger team, the coordination effort is daunting.

An additional benefit of version control systems: the illusion of accountability. With controlled access and logged activity, project managers could see who made which changes.

Project managers, not individual developers, changed the process to use version control. That's as it should be: project managers are the people to define the process. (They can use input from developers, however.)

We have style checking programs for many languages. A quick search shows style checkers for C, C++, C#, Java, Perl, Python, Ruby, Ada, Cobol, and even Fortran. Some checkers are simple affairs, checking nothing more than indentation and line length. Others are comprehensive, identifying complex modules.Style checkers are not used in a typical development project. The question is: when will style-check programs become part of the normal tool set?

Which is another way of asking: when (if ever) will a majority of development teams use style-check programs as part of their process?

I think that the answer is: yes, eventually, but not soon.

The same logic for version control systems has to apply to style checkers. It won't be individuals who bring style checkers into the process; it will be project managers.

Which means that the project managers will have to perceive some benefit from style checkers. There is a cost to using them. It is a change to the process, and some (many) people are resistant to change. Style checkers enforce a certain style on the code, and some (many) developers prefer their own style. Style checkers require time to run, time to analyze the output, and time to change the code to conform, all of which take time away from the main task of writing code.

The benefits of style checkers are somewhat hazy, and less clear than version control systems. Version control systems fixed a clear, repeating problem ("hey, where did my changes go?"). Style checkers do no such thing. At best, they make code style consistent across the project, which means that the code is easier to read, changes are easier to make, and developers can move from one section of the code to another. Style checkers invest effort now for a payback in the future.

I suspect that the adoption of style checkers will be slow, and while lead by project managers, it will be encouraged by developers. Or some developers. I suspect that the better developers will be more comfortable with style checkers and will want to work on projects with style checkers. It may be that development teams will form two groups: one with style checkers and one without. The development teams that use style checkers will tend to hire other developers who use style checkers, and the development teams that don't use style checkers will tend to hire developers who don't use style checkers. Why? Because a developer in the "wrong" environment will be uncomfortable with the process - and the code. (The same thing happened with version control systems.)

For style checkers to be adopted, I see the following preconditions:

• The style checkers have to exist (at least for the team's platform and language)
• The style checkers have to be easy to use
• The recommendations from style checkers has to be "tuneable" - you can't be swamped with too many messages at once
• The team has to be willing to improve the code
• The project management has to be willing to invest time now for payment later

 We have the tools, and they are easy to use (well, some of them). I think teams are willing to improve the code. What we need now is a demonstration that well-maintained code is easier to use in the long term.

An imaginary Windows version of the Chromebook

Acer and HP have cloudbooks - laptop computers outfitted with Windows and a browser - but they are not really the equivalent of a Chromebook.

A Chromebook is a lightweight laptop computer (in both physical weight and computing power) equipped with a browser and just enough of an operating system to run the browser. (And some configuration screens. And the ssh program.) As such, they have minimal administrative overhead.

Cloudbooks - the Acer and HP versions - are lightweight laptops equipped with the full Windows operating system. Since they have the entire Windows operating system, they have the entire Windows administrative "load".

Chromebooks have been selling well (possibly due to their low prices). Cloudbooks have been selling... well, I don't know. There are only a few models from Acer and a few models from HP; much fewer than the plethora of Chromebooks from numerous manufacturers. My guess is that they are selling in only modest quantities.

Would a true "Windows Chromebook" sell? Possibly. Let's imagine one.

It would have to use a different configuration than the current cloudbooks. It would have to be a lightweight laptop with just enough of an operating system to run the browser. A Windows cloudbook would need a browser (let's pick the new Edge browser) and stripped-down version of Windows that is just enough to run it.

I suspect that the components of Windows are cross-dependent and one cannot easily build a stripped-down version. Creating such a version of Windows would require the re-engineering of Windows. But since this is an imaginary device, let's imagine a smaller, simpler version of Windows.

This Windows cloudbook would have to match the price of the Chromebooks. That should be possible for hardware; the licensing fees for Windows may push the price upwards.

Instead of locally-installed software, everything would run in the browser. To compete with Google Docs, our cloudbook would have Microsoft Office 365.

But then: Who would buy it?

I can see five possible markets: enterprises, individual professionals, home users, students, and developers.

Enterprises could purchase cloudbooks and issue them to employees. This would reduce the expenditures for PC equipment but might require different licenses for professional software. Typical office jobs that require Word and Excel could shift to the web-based versions of those products. Custom software may have to run in virtual desktops accessed through the company's intranet. Such a configuration may make it easier for a more mobile workforce, as applications would run from servers and data would be stored on servers, not local PCs.

Individual professionals might prefer a cloudbook to a full Windows laptop. Then again, they might not. (I suspect most independent professionals using Windows are using laptops and not desktops.) I'm not sure what value the professional receives by switching from laptop to cloudbook. (Except, maybe, a lighter and less expensive laptop.)

Home users with computers will probably keep using them, and purchase a cloudbook only when they need it. (Such as when their old computer dies.)

Students could use cloudbooks as easily as the use Chromebooks.

Developers might use cloudbooks, but for them they would need tools available in their browser. Microsoft has development tools that run in the browser, and so do other companies.

But for any of these users, I see them using a Chromebook just as easily as using a Windows cloudbook. Microsoft Office 365 runs in the Chrome and Firefox browsers on Mac OSX and on Linux. (There are apps for iOS and Android, although limited in capabilities.)

There is no advantage to using a Windows cloudbook  -- even our imaginary cloudbook -- over a Chromebook.

Perhaps Microsoft is working on such an advantage.

Their Windows RT operating system was an attempt at a reduced-complexity configuration suitable for running a tablet (the ill-fated Surface RT). But Microsoft departed from our imagined configuration in a number of ways. The Surface RT:

- was released before Office 365 was available
- used special versions of Word and Excel
- had a complex version of Windows, reduced in size but still requiring administration

People recognized the Surface RT for what it was: a low-powered device that could run Word and Excel and little else. It had a browser, and it had the ability to run apps from the Microsoft store, but the store was lacking. And while limited in use, it still required administration.

A revised cloudbook may get a warmer reception than the Surface RT. But it needs to focus on the browser, not locally-installed apps. It has to have a simpler version of Windows. And it has to have something special to appeal to at least one of the groups above -- probably the enterprise group.

If we see a Windows cloudbook, look for that special something. That extra feature will make cloudbooks successful.

Derivatives of programming languages

Programmers are, apparently, unhappy with their tools. Specifically, their programming languages.

Why do I say that? Because programmers frequently revise or reinvent programming languages.

If we start with symbolic assembly language as the first programming language, we can trace the development of other languages. FORTRAN, in its beginning, was a very powerful macro assembler (or something like it). Algol was a new vision of a programming language, in part influenced by FORTRAN. Pascal was developed as a simpler language, as compared to Algol.

Changes to languages come in two forms. One is an enhancement, a new version of the same language. For example, Visual Basic had multiple versions, yet it was essentially the same language. FORTRAN changed, from FORTRAN IV to FORTRAN 66 to Fortran 77 (and later versions).

The other form is a new, separate language. C# was based on Java, yet was clearly not Java. Modula and ADA were based on Pascal, yet quite different. C++ was a form of C that had object-oriented programming.

Programmers are just not happy with their languages. Over the half-century of programming, we have had hundreds of languages. Only a small fraction have gained popularity, yet we keep tuning them, adjusting them, and deriving them. And programmers are not unwilling to revamp an existing language to meet the needs of the day.

There are two languages that are significant exceptions: COBOL and SQL. Neither of these have been used (to my knowledge) to develop other languages. At least not popular ones. Each has had new versions (COBOL-61, COBOL-74, Cobol-85, SQL-86, SQL-89, SQL-92, and so on) but none have spawned new, different languages.

There have been many languages that have had a small following and never been used to create a new language. It's one thing for a small language to live and die in obscurity. But COBOL and SQL are anything but obscure. They drive most business transactions in the world. They are used in all organizations of any size. One cannot work in the IT world without being aware of them.

So why is it that they have not been used to create new languages?

I have a few ideas.

First, COBOL and SQL are popular, capable, and well-understood. Both have been developed for decades, they work, and they can handle the work. There is little need for a "better COBOL" or a "better SQL".

Second, COBOL and SQL have active development communities. When a new version of COBOL is needed, the COBOL community responds. When a new version of SQL is needed, the SQL community responds.

Third, the primary users of COBOL and SQL (businesses and governments) tend to be large and conservative. They want to avoid risk. They don't need to take a chance on a new idea for database access. They know that new versions of COBOL and SQL will be available, and they can wait for a new version.

Fourth, COBOL and SQL are domain-specific languages, not general-purpose. They are suited to financial transactions. Hobbyists and tinkerers have little need for COBOL or a COBOL-like language. When they experiment, they use languages like C or Python ... or maybe Forth.

The desire to create a new language (whether brand new or based on an existing language) is a creative one. Each person is driven by his own needs, and each new language probably has different root causes. Early languages like COBOL and FORTRAN were created to let people be more productive. The urge to help people be more productive may still be there, but I think there is a bit of fun involved. People create languages because it is fun.

Collaboration is an experiment

The latest wave in technology is collaboration. Microsoft, Google, and even Apple have announced products to let multiple people work on documents and spreadsheets at the same time. For them, collaboration is The Next Big Thing.

I think we should pause and think before rushing into collaboration. I don't say that it is bad. I don't say we should avoid it. But I will say that it is a different way to work, and we may want to move with caution.

Office work on PCs (composing and editing documents, creating spreadsheets, preparing presentations) has been, due to technology, solitary work. The first PCs had no networking capabilities, so work had to be individual. Even with the hardware and basic network support in operating systems, applications were designed for single users.

Yet it was not technology alone that made work solitary. The work was solitary prior to PCs, with secretaries typing at separate desks. Offices and assignments were designed for independent tasks, possibly out of a desire for efficiency (or efficiency as perceived by managers).

Collaboration (on-line, real-time, multiple-person collaboration as envisioned in this new wave of tools) is a different way of working. For starters, multiple people have to work on the same task at the same time. That implies that people agree on the order in which they perform their tasks, and the time they devote to them (or at least the order and time for some tasks).

Collaboration also means the sharing of information. Not just the sharing of documents and files, but the sharing of thoughts and ideas during the composition of documents.

We can learn about collaboration from our experiences with pair programming, in which two programmers sit at one computer and develop a program. The key lessons I have learned are:

• Two people can share information effectively; three or more are less effective
• Pair program for a portion of the day, not the entire day
• Programmers share with multiple techniques: by talking, pointing at the screen, and writing on whiteboards
• Some pairs of people are more effective than others
• People need time to transition from solitary-only to pair-programming

I think the same lessons will apply to most office workers.

Collaboration tools may be effective with two people, but more people working on a single task may be, in the end, less effective. Some people may be "drowned out" by "the crowd".

People will need ways to share their thoughts, beyond simply typing on the screen. Programmers working together can talk; people working in a shared word process will need some other communication channel such as a phone conversation or chat window.

Don't expect people to collaborate for the entire day. It may be that some individuals are better at working collaboratively than others, due to their psychological make-up. But those individuals will have been "selected out" of the workforce long ago, due to the solitary nature of office work.

Allow for transition time to the new technique of collaborative editing. Workers have honed their skills at solitary composition over the years. Changing to a new method requires time -- and may lead to a temporary loss of productivity. (Just as transitioning from typewriters to word processors had a temporary loss of productivity.)

Collaboration is a new way of working. There are many unknowns, including its eventual effect on productivity. Don't avoid it, but don't assume that your team can adopt it overnight. Approach it with open eyes and gradually, and learn as you go.

We program to the interface, thanks to Microsoft

Today's markets for PCs, for smart phones, and for tablets show a healthy choice of devices. PCs, phones, and tablets are all available from a variety of manufacturers, in a variety of configurations. And all run just about everything written for the platform (Android tablets run all Android applications, Windows PCs run all Windows applications, etc.).

We don't worry about compatibility.

It wasn't always this way.

When IBM delivered the first PC, it provided three levels of interfaces: hardware, BIOS, and DOS. Each level was capable of some operations, but the hardware level was the fastest (and some might argue the most versatile).

Early third-party applications for the IBM PC were programmed against the hardware level. This was an acceptable practice, as the IBM PC was considered the standard for computing, against which all other computers were measured. Computers from other vendors used different hardware and different configurations and were thus not compatible. The result was that the third-party applications would run on IBM PCs and IBM PCs only, not on systems from other vendors.

Those early applications encountered difficulties as IBM introduced new models. The IBM PC XT was very close to the original PC, and just about everything ran -- except for a few programs that made assumptions about the amount of memory in the PC. The IBM PC AT used a different keyboard and a different floppy disk drive, and some software (especially those that used copy-protection schemes) would not run or sometimes even install. The EGA graphics adapter was different from the original CGA graphics adapter, and some programs failed to work with it.

The common factor in the failures of these programs was their design: they all communicated directly with the hardware and made assumptions about it. When the hardware changed, their assumptions were no longer valid.

We (the IT industry) eventually learned to write to the API, the high-level interface, and not address hardware directly. This effort was due to Microsoft, not IBM.

It was Microsoft that introduced Windows and won the hearts of programmers and business managers. IBM, with its PS/2 line of computers and OS/2 operating system struggled to maintain control of the enterprise market, but failed. I tend to think that IBM's dual role in supplying hardware and software helped in that demise.

Microsoft supplied only software, and it sold almost no hardware. (It did provide things such as the Microsoft Mouse and the Microsoft Keyboard, but these saw modest popularity and never became standards.) With its focus on software, Microsoft made its operating system run on various hardware platforms (including processors such as DEC's Alpha and Intel's Itanium) and Microsoft focussed on drivers to provide functionality. Indeed, one of the advantages of Windows was that application programmers could avoid the effort of supporting multiple printers and multiple graphics cards. Programs would communicate with Windows and Windows would handle the low-level work of communicating with hardware. Application programmers could focus on the business problem.

The initial concept of Windows was the first step in moving from hardware to an API.

The second step was building a robust API, one that could perform the work necessary. Many applications on PCs and DOS did not use the DOS interface because it was limited, compared to the BIOS and hardware interfaces. Microsoft provided capable interfaces in Windows.

The third step was the evolution of Windows. Windows 3 evolved into Windows 3.1 (which included networking), Windows 95 (which included a new visual interface), and Windows 98 (which included support for USB devices). Microsoft also developed Windows NT (which provided pre-emptive multitasking) and later Windows 2000, and Windows XP.

With each generation of Windows, less and less of the hardware (and DOS) was available to the application program. Programs had to move to the Windows API (or a Microsoft-supplied framework such as MFC or .NET) to keep functioning.

Through all of these changes, Microsoft provided specifications to hardware vendors who used those specifications to build driver programs for their devices. This ensured a large market of hardware, ranging from computers to disk drives to printers and more.

We in the programming world (well, the Microsoft programming world) think nothing of "writing to the interface". We don't look to the hardware. When faced with a new device, our first reaction is to search for device drivers. This behavior works well for us. The early marketing materials for Windows were correct: application programmers are better suited to solving business problems than working with low-level hardware details. (We *can* deal with low-level hardware, mind you. It's not about ability. It's about efficiency.)

Years from now, historians of IT may recognize that it was Microsoft's efforts that lead programmers away from hardware and toward interfaces.

Apple and Microsoft do not compete

The tech press has been building the case that Apple is "going for the enterprise market" and that Microsoft is "responding". I'm not convinced of this argument.

The evidence is thin. Exhibit A for Apple is the new iPad Pro, which has a larger screen, a faster processor, and an optional keyboard. The thinking is that this new iPad Pro competes with Microsoft's Surface tablet -- which it does -- and therefore Apple is in direct competition with Microsoft.

Exhibit B is Microsoft's partnership with Dell to sell computers to enterprises. Here, the thinking is (apparently) that Microsoft would only make such an agreement if it felt threatened by Apple.

Such competition may make for good news, but it makes little sense. Apple and Microsoft are in two different markets. Apple sells hardware that happens to come with some software; Microsoft sells software that happens to run on hardware. Its true that Microsoft is moving from the single-sale model to a subscription model, but they are still selling software. (Primarily. Microsoft does sell the Surface tablets. They are a tiny portion of Microsoft's sales.)

Microsoft and Apple are building a synergistic system, one which sees Apple selling hardware and Microsoft selling software. Enterprises may wish to purchase iPads and iPhones for their employees and still use Microsoft apps on those devices. Enterprises have a long history with Microsoft and lots of documents and spreadsheets in Word and Excel. Apple may have Pages and Numbers (its competing word processor and spreadsheet), but they are not the same as Microsoft's Word and Excel. The future (for enterprises) may very well be Microsoft apps running on Apple hardware.

One might assume that Apple has the upper hand in such a hardware/software combination. I disagree. While apps run in the iOS ecosystem at Apple's whim -- Apple can revoke any app at any time -- such a move would not benefit Apple. Enterprises are bound to their data first, their software second, and their hardware last. Apple could "pull the plug" on Microsoft apps, hoping that enterprises would switch to Apple's products, but I think the reaction would be different. Enterprise managers would be angry, and the target of their anger would be Apple. They would view Apple as selfish and dangerous -- and purchases of Apple equipment would drop to near zero.

Such a situation does not mean that Microsoft can be a bully. They have improved their reputation by expanding Microsoft software offerings to the iOS and Android platforms and maintaining a long relationship with the Mac OSX platform. They cannot arbitrarily "pull the plug" on their iOS apps. Such a move would be frowned upon. (They could, however, discontinue their support of iOS in response to arbitrary moves by Apple, such as a change in iTunes charges.)

Apple and Microsoft are not in direct competition. (Despite competing hardware and software products.) They stand to gain much more by civilized behavior.

New programming languages

Sometimes we create programming languages to solve problems in programming. (For example, we created PASCAL to use structured programming techniques.) Sometimes we create programming languages to take advantage of new hardware or system platforms.

Consider BASIC. It was made possible (some might say necessary) by the invention of timesharing systems.

Prior to timesharing, computing had to be done local to the processor. Computers were the stereotypical large, centralized (expensive) box one sees in movies from the 1950s and 1960s. Programs and data were supplied on punch cards or magnetic tape, which had to be processed on large (also expensive) readers. You could run a program, but only with the assistance of the system operator who would actually schedule the program for execution and load your input cards or tapes. There was no such thing as a "personal" computer.

Timesharing brought computing to remote terminals, small (relatively inexpensive) printing devices that let one issue commands to the computer without the assistance of an operator. The existing languages at the time (COBOL and FORTRAN) were not suitable for such an environment because they assumed the existence of card readers and tape drives.

BASIC was inspired by FORTRAN but it allowed for self-contained programs which could be modified by the user. The programs are self-contained in that they can include the data; COBOL and FORTRAN (and other languages) require data from an external source. With a self-contained program, no system operator was needed! (Well, not after the system operator started the timesharing service.) Users could connect, enter their programs -- including the data -- , run them, and see the results. This set of capabilities, all in one language, required a new language.

BASIC is not alone in being constructed in response to a system platform. There are others.

SQL was created for databases. We had the databases, and we needed a common, powerful language to manipulate them. Prior to SQL, each database had its own API. Moving from one database to another was a major effort -- so large that often people stayed with their database rather than switch.

JavaScript was created for web browsers. We had web pages and web browsers, and we wanted a way to manipulate objects on the web page. JavaScript (later with HTML enhancements and CSS) gave us the power to build complex web pages.

These languages (BASIC, SQL, and JavaScript) all filled a vacuum in computing. They also have had long periods of popularity. BASIC's popularity began shortly after its creation, and it moved from timesharing to microcomputers such as the Radio Shack TRS-80 and the Commodore 64. It was part of the original IBM PC, baked into the ROM so your could run BASIC without DOS (or disks!). SQL has been popular since the 1980s. JavaScript is in all of the major web browsers.

BASIC was challenged by other languages on small systems (FORTRAN, APL, Pascal, PL/M, C, and even COBOL). We eventually shifted from BASIC to Visual Basic and C++ (and later, Java, Perl, Python) but only after PCs become large enough to support those languages -- a program that contained its own data and a language its own editor was no longer needed. SQL remains popular, and no other languages have challenged it as the interface to databases.

Perhaps their popularity was due to the fact that these languages were designed to meet the needs of the specific platform. Perhaps they were so well designed, such a good fit, that other languages could not dislodge them. Perhaps we can expect JavaScript to have a long, productive life too. It has been challenged by CoffeeScript and TypeScript, but neither have made a dent in the popularity of JavaScript.

The new division line is collaboration tools

Veterans of the Windows era (and veterans of the DOS era) know all too well that the dividing line between tribes was the file format. Today, it is not the file format that locks in customers, but the ability to collaborate.

In the PC age, application programs ran on individual PCs, stored files on PCs, and used proprietary file formats. Microsoft Word used its own format, WordPerfect used its own format, Wordstar used its own format... you get the idea. Spreadsheets used their own formats too.

One could have several word processors installed on a single PC. Even though these programs ran on the same PC and stored their files on that PC, it was difficult (if not impossible) to move files from one application to another, because of the proprietary formats.

The idea was that once a customer (either an individual or a corporation) had created a lot of documents in the proprietary format, they would resist change to another vendor and stay with the original. It was a way to lock in customers to a vendor's product.

Some vendors allowed for their product to read the files of other products -- Word could read WordPerfect files, for example. Generally, such "interoperability" was limited to reading the files. Reading was easier than writing an "alien" format. (It is easier to pick out the important bits than create a file with all of the right internal tables and structures that will be acceptable to the other program.)

Today we have standard file formats, so a vendor cannot rely on proprietary formats to lock in customers.

But customers can still get locked in to a vendor's product.

Our tools are changing from stand-alone programs that store data in local files to on-line systems that allow for collaboration and store information "in the cloud". More than just sharing documents, today's collaboration tools let multiple people work on the same document at the same time. Microsoft's Office 365 suite allows this, as does Google's Docs and Sheets offerings. Other vendors offer this too.

But each collaboration environment is its own isolated garden. People using Google Docs can work with other people using Google Docs. People using Microsoft Office 365 can collaborate with other people using Microsoft 365. But one cannot mix products; one cannot cross tribes. A person using Google Docs cannot work (online, concurrently) with a person using Microsoft Office 365.

I expect that individuals and organizations will settle on a a single standard for their collaboration. Large corporations with an existing base of Microsoft documents will standardize on Microsoft's tools (Office 365). Small organizations with little or no existing documents (say, start-ups) will standardize on Google Docs because of the lower cost. Individuals will pick the tool that comes with their PC, when they buy a PC. (Several laptops now offer a free year of Office 365.)

Developers and contractors who work with multiple clients may find that they use both, picking the tool that matches their clients' needs for each project.

The "age of proprietary formats" lasted decades, roughly from 1980 to 2010. The "age of proprietary collaboration" may last just as long. Yet in the future I expect that the proprietary collaboration tools will develop interoperability and will not be used to lock in customers. Of course, vendors will find new ways to lock in customers.