NOTE: The material on Swift and Modula-2 R10 was edited at a later date to reflect some late design decisions that affected the comparisons, to emphasize the totality of functionality including libraries, and to correct a few small typos. It is up-to-date as of 2015 03 30.

Day 2 Observations

One thing that has become abundantly clear at WWDC is that Apple is returning to its grassroots--the developer community that makes its ecosystem work. In the heady days of the late seventies, thousands of people discovered that they could make these fantastic new computing machines do what they wanted.

What if their tools were primitive by today's standards, and what if the space one had for code and data combined was under 12K bytes? What if to do the really good stuff you needed to learn 6502 assembler and what hooks in Applesoft BASIC and DOS could be co-opted to avoid re-inventing the wheel? Programming was no longer the preserve of white-coated high priests secure behind a glass window and insulated from the student rabble by a receptionist whose task it was to hand your eighty-column coding sheet to the key punch operatior. It had become something that anyone willing to do a little work could try, and in droves they turned the "Visicalc machine" into a general-purpose tool platform.

Business applications, educational software, file utilities, code analyzers, and a dozen other categories appeared overnight where none had existed before. The Apple ][ and its descendants became a programmers' kindergarden, a playground for a whole new art form. Some of this became professionalized, institutionalized, and made more difficult with the advent of the PC and its IBM-promoted role as a business machine, but the geek community was in no mood for limitations and tore the sober blue-pinstripes off the business box to reveal its gaming heart. The Mac by contrast started off as an archetypal Steve Jobs closed box--easy to use, but on his terms. When programming was opened up, the leap to an event-driven GUI was difficult and it was said of the badly-written programming manuals that to understand any one chapter, one had to know all the others first.

Over time, Apple gradually made things easier for programmers, publishing more and more APIs, offering tutorial materials, sample code, and, twenty-five years ago starting WWDC a a gathering place and intellectual seedbed for promoting the vision of a developer community. The cycle repeated with the iDevices--closed boxes at first, but latterly a wide-open platform. But more often than not, the big stage at WWDC was used to make hardware announcements--some, like the PowerPC, and then the switch to Intel of great importance and interest to developers, but not necessarily to their craft.

As the first WWDC not to have any Jobsian influence in its creation, the 2014 is utterly unlike that. All hardware announcements, significant or mere bumps, have been put off to other venues. This show is all about empowering an even more vibrant developer community to build the apps that will make Macintosh and iOS devices sufficiently insanely great that the cheap imitators will be forced to either change their ways or fold their tents. Much of this is already happening. The Blackberry developer is nearly an extinct species, Windows mavens are threatened, and the Android community is fractured and uncertain, not knowing what direction to go.

Apple by contrast has laid out a clear, cogent, and get-your-teeth-into-it roadmap for the future, independent of where they take their two OS or their hardware. The four thousand new APIs, a newly energized XCode, the new Swift language and in particular the new tools for developing integrated health and home automation apps, cross platform handoffs, the automatic generation of appropriately parameterized user interface elements for platform variations, the tight integration with existing tools, and the application interopabilty facilitation all open up not merely new ideas and coding possibilities, but whole new directions.

The collected geeks are lapping this stuff up. Yes, journalists may pan Apple for not making product announcements here, and the company stock might suffer from disappointment over iTV and iWatch failing to appear, but what has happened here is more important in the long run. These are not merely new toys to occupy geeks' time, they lay the foundation for ensuring the loyalty of an ever-expanding community of dedicated designers and programmers whose jobs have just been made more interesting, easier, and more productive. True, their apps will be cooler, but they will be faster, more fully-featured and better, tightly integrated into the two Apple OS by being able to inter-operate with each other by program and device. Going forward, they won't want to jump ship for something inferior, and Apple will reap the benefits in both immediate mindshare and longer term marketshare.

If this is a war of operating systems, Apple has rediscovered the heavy artillery--the grassroots programmer. The heady 1970s are about to be repeated, but at a higher level and on an orders-of-magnitude larger scale.

Day 3 Observations

As WWDC progresses it becomes increasingly clear from session content and the people running the labs that Apple has hung its corporate development hat on Swift, its new programming language. The push to have the 6000 of us, and a million other developers do the same is very strong. As previously noted here, this is quintessentially a developer's conference.

Swift can be used from a command line interface or from within XCode. It is of course an object oriented language, and because the company wants the transition to be seamless, Swift has complete access to existing Cocoa and Cocoa Touch libraries. Code written in Swift can be integrated into existing Objective-C projects, and vice-versa. No header files need be manually generated, and the existing ones will be automatically translated in order to get the documentation for the classes, their methods, and properties. Likewise, building Swift libraries will generate a complete set of Objective-C headers to expose the code to that language.

In talking to the language designers, compiler and library writers, the Spy quickly learned that the Apple team identified much the same issues and adopted much the same principles for addressing them as did he and his partner with Modula-2 R10--modernization, security, simplicity, small core, and a blurring of the differences between built-in and user-defined ADTs. However, the practice of theory seldom resembles the theory of practice, and nurture (environment) is at least as important as genetics. Resources are also an issue. Thus the Apple team's responses to the identified issues
(a) bear little sufface resemblance to those we settled on for R10
(b) are focused entirely on the Apple ecosystem,
(c) are, despite the emphasis on safety, more about utility and ese of use,
(d) are accompanied by a rich set of supporting interfaces, and
(e) followed an implicit philosophy at times instead of our explicit one.
(f) at times added functionality by elaborating language features
(g) already are OO, whereas we have left that to a second phase of R10.

For instance, Modula-2 R10 implements generics using a refinement-of-template model, similar in principle, though not in syntax, to that in the ISO version. Each refinement for a different data type or other variant produces a new and specialized interface and code set. Swift takes the opposite tack. Generic code is by default compiled only once. When it is to be called by program code, say to use a particular type (think a generic quicksort of an initially unspecified type being called with type float for instance), all the necessary information for that type (how to compare or swop for instance) is attached to the generic code as a hidden parmeter at compile time, obviating any necessity for explicit refinement and the consequent duplication. (Implicit trumping explicit.)

Likewise, although in both languages if the programmer creates a data type that conforms to the numeric protocol, it automatically gets access to I/O routines, thus blurring the lines between supplied ADTs and user defined ones. When an R10 ADT type library defines its bindings to I/O in a protocol-conformant manner, the blurring is achieved with macro translations at compile time. In Swift, even supplied types are do not have all their functionality built-in to the language but are themselves in libraries, so this blurring is not so much making the library ADT appear to function by translating a built-in to a supplied procedure, as it is that all types are the same kind of citizen from the start. You read that right. A Swift int, for instance comes from a library; it is not in the core language.

In R10, only the I/O functionality of the built-in types is in libraries, not, say, their arithmetic, which is built in.

Both languages permit mutable or immutable named values, though Swift combines declaration and initialization. R10 implements type safety explicitly, tightening the requirements for compatibility by type name in almost all situations, not structure or implicit subtype. Swift does so implicitly wherever possible, making type declarations optional in any cases where the inference engine can determine it. If a variable is initialized with an obvious int value such as 659, that's its type. Where it is necessary to specify type explicitly, this can be done. Both languages provide a variety of numeric types, including specific bit width whole number type.

Such numeric types are incompatible in both languages and require explicit type transfer and/or a supplied initializer that can do a conversion. Both languages address type transfer safety in the same explicit fashion, though the syntax differs--R10 uses its infix type transfer operator :: bound to either runtime or user-defined library conversion routines and Swift uses the type name as though it were a function in prefix fashion, somewhat like older Modula-2 dialects. Same problems, different half solution, same other half.

Both languages have value and variable parmameters (though in Swift the latter are distinguished from inout parameters, and the actual parameters passed to an inout formal parameter require the ampersand prefix.). Both have variadic parameters, only the syntax differs.

Given that Swift comes from a C-family background, subroutines are functions by default, the opposite of Modula-2. However if the Swift function return value is left out, the return value is void by default, and this need not be mentioned in the header, bringing the two models much closer. Alternately, the return value can be made optional, with the default return being nil. However, Swift elaborates on return values by allowing more than one--an implicit tuple. R10 keeps things simpler, allowing only one return value from a function procedure.

Both languages use FOR IN with either explicit or implicit indexing. Both allow iteration to be defined for a new data type and bound to FOR. R10 permits descending binding to be bound, where that makes sense.

Swift, as Modula-2 always has in its CASE statement uses a true select, that is in a switch, cases do not by default follow through, but terminate. Thus, unlike older C-like notations, the unnecessary break statement has been eliminated.

This discussion to be continued below (non-liner presentation here), with more focus on differences.

Keep in mind here that Apple is not in the business of offering tools that will be of general purpose utility outside their own ecosystem. Objective-C was scarcely used apart from Apple development, and the same will be true of Swift. After all, Apple has no interest in introducing Android or Windows developers to the quality tools, techniques, and libraries their developers are being enabled to use. Why would they enable developers for the competition to write better code? XCode, Swift, and the Metal Graphics API aren't mainstream. Or, more aptly, they are, and all other streams are being reduced to trickles in their respective drainage ditch. Even now, not many fish swim there.

Much of Swift programming can employ autocompletion. Start to type the name of a function call and an attached dialogue box offers possible completions, with documentation also accesible. Of course, this is all Apple-specific and related to the programming environment, not the language. Any IDE could be set up to do such completions for any given language. Even were Apple to license the language, many person-years woud be required to adapt it to a different environment sufficiently to achieve the same effects.

A Swift playground is a new type of XCode document that shows code on the left and results on the right--live, with code change consequences immediately displayed. A timeline can display values of a variable over time. Their first use is for learning, and the Swift Tour tutorial IS a playground. They can also be used to teach beginners programming or to experiment with code before using it in a program. Drawing is particularly compatible with this model as the results are immediately visible. In all cases, there is no more typing a few lines, compiling, executing and scrutinizing the output and error logs just to see what the changes did. This is JIT compilation of course, not interpretation. Individual lines can be clicked to determine the value of a variable at that point in execution via a popup. The file inspector allows the program to be executed against iOS or MacOS.

The XCP interface (XC Playground) offers a number of utilities to facilitate this workflow. This can, for instance allow one to animate a heap sort, so determining visually whether the code is correctly heapifying. Animated results are also great for prototyping, especially for graphics. Of course, the playground cannot be used for performance testing, as its own performance dominates that of the program. REPL is separate command line inTerface to Swift that provides a terminal experience.

Metal is a graphics API that gives more direct access (on the bare metal) to the GPU. Previously, this was handled by OpenGL, a graphics interface available for numerous platforms. It generality requires two layers--a universal set of calling protocols, and a specific back end for each supported GPU. Apple only cares about its own GPUs, and can flatten this considerably, producing dramatic speedups. Metal, however, is more a language in its own right than a mere UI. At this writing, the interface has a decidedly C++ flavour to it in order to take advantage of existing code, but the Spy expects that could change in time.

Day 4 Observations

As WWDC progresses, more and more attendees are leaving Moscone for lunch. Not surprising. The Spy fully understands the logistical difficulties involved in making a tasty meal for 6000+ people, but recommends Apple engage a different supplier next time. The fruit snacks are fresh, and the soda, juice, and water plentiful, but the meals in plastic containers seem dry and somewhat unappetizing. The Spy repudiates the stereotype that programmers are too busy thinking and coding to notice what they eat and can therefore be fed just anything.

It's also clear that the majority of said multitude are prioritizing the Apple menu itself in much the same way as the Spy. At most times, a given session has one to two thousand attendees. But anything connected with Swift attracts up to two-thirds the developers present. See the remarks on queues above.

Let's continue the discussion of the differing solutions to the language needs identified by the Apple team and the Modula-2 R10 team.

In Modula-2 the built-in array sizes are static, but in Swift they are dynamic, so can be appended to. This means an array can start out empty, and be filled later. In particular a formal parameter can be an empty array, and filled by the actual parameter, the same functionality as a Modula-2 open array. Both use a count/COUNT to determine the number of active elements, though the semantics differ. However, an empty Swift array may also be a formal return type of a func (there can be more than one), and be filled at return time, a very flexible facility that provides one kind of genericity. Both index these in the local scope commencing at 0, with the last index dynamic and procedures (functions) in both have types and are assignable to variables of types with the same type signature.

Note however, that the same dynamic array facilities (and ones, for instance, for associative arrays, counted sets, and other collection types) are very much available in R10 because the library facility has been leveraged in such a manner that once, say, a dynamic or associative array has been refined from the library blueprint or a new type of method from a generic template, their use in a program is no different than that of a built-in (e.g. infix notation for operations, binding of FOR to library-defined iteration, and use of other bindable language entities.) IOW, from a syntax use point of view, the only privilege the built-in types have is that their arithmetic is known to the compiler before it looks at the libraries. The distinction between built-ins and programmer-defined types is now essentially erased by a very robust re-visioning of the library as a dynamic programming resource, not merely a collection of static code.

Swift structs (including types, which are structs) can be extended. In particular, functions, including operators, can be overloaded for them, and various symbols can be combined to create new operators for such a type. R10 has extensible records, but uses type modules for operator binding, limits user-defined binding to a smaller set of symbols, and does not allow new symbol combinations for new operators. The designers of R10 felt that the language ought to impose some discipline in such matters.

Swift objects are automatically reference counted. Memory allocation for an object is implicit. When the last reference to an object goes away the object is released. Also, like Objective-C there are weak references (mutable optional values) that can prevent one reference from keeping another alive. Swift has strong, weak, and unowned references. R10 has such facilities as well, but uses RETAIN and RELEASE for fine grained control of references.

In both, all variables are required to be initialized before they are used. The compiler analyzes for this by considering all branches of the code. There is no default except for optionals that default to nil. However, Swift has struct and class initializers that can define default values.

Major differences: Swift has closures, captures, variant enumerations, and optional chaining to a desired value or a nil (employing short circuited booleans) which are implemented as enumerations with two cases (use to safely work with possibly missing values). Modula-2 lacks all these, but makes much more use of modules and has sets, as well as a variety of collection blueprints and generic templates to guide the refinement of types for program use. A structured constant can be constructed in an assignment in Modula-2 for sets, records, or arrays, whereas in Swift this is true only of arrays. Although both make use of protocols, Swift claims to be a protocol-based language. Swift introduces varient enumerations and extensible structs, but R10 replaces variant records with indeterminate records, while making both them and enumerations extensible.

Swift is very much a part of a programming system, in which it now stars instead of Objective-C. XCode has been re-tooled to take this into consideration, and extensive debugging tools are available in the system to inspect code, track down faults, determine the values of variables at any point in the program run, try out new code in the REPL (command line interface) in a program's context (rather than in the overhead-heavy playground), and harness the power of the existing Objective-C, Cocoa, Cocoa Touch, and Swift libraries to a program. Indeed, what is here should be taken as a high-level overview of some of the functionality of Swift, not fully expository of either it or of Modula-2 R10, for which purposes the Spy refers his reader to the defining documents.

The Spy has not previously been a fan of C-family languages In particular, the design of C++ is bloated, non-orthogonal, and presents an almost impossibly steep learning curve to the beginner. Java was a good design, but has been poorly implemented and managed by Sun, and should be now considered a dead language. Objective-C, to the Spy's mind, is Smalltalk philosophy dressed up in C-like syntax--a fairly good design, but obviously not for everyone. It has served Apple well, though it never had much traction to become a general purpose language.

On the Pascal side of the Algol fence, Pascal itself lives on only in Embarcadero's (formerly Borland's) Delphi. Objective Pascal never had much of a life outside Apple. Ada was a horse designed by a committee, boycotted by many because of its DoD origins, and never used extensively because of it's very heavy compiler requirements. It had some nice features, though. Modula-2 had a brief rise to glory, but fell due to the number of years the ISO committee took to standardize it. Had Wirth been more definite about what it was, specifically in the libraries, and called it Pascal-2, it could have ruled. It lives on in a single current product (p1 for the Mac) and in the update undertaken in the R10 project. Oberon suffered from excessive fracking--it was different at every university, and never any one thing.

The Spy has believed for years that there was room for a brand-new programming language that would remove some of the unnecessary freight of the old ones, incorporate modern ideas in its design, and re-focus language design on the discipline of software engineering by providing more robust tools for security, safety, and reliability. His students in the programming languages course came up with roughly the same set of features every time he turned them loose on design practice. Needless to say, most of these ideas have found their way into Modula-2 R10. Some have also, though in a different manner, ended up in Swift. Safety, extensibility, orthogonality, simplicity, the ability to use existing libraries even in other languages, a syntax cleanup, blurring the lines between supplied and user-created ADTs, consideration for implementability, robust generics, and more attention to mutability and dynamic issues are all things both detected as priorities. Good to see that Apple thinks so too. The major difference in philosophy: explicit vs implicit and the techniques for extensibility (though the latter are partly dictated by heritage). This last point is most marked in the approach to generics, where R10 took a very lightweight road, and Swift a very robust one indeed.

Swift gives the initial appearance of being the best C-like design thus far attempted (though in the Spy's HO, that alone does not say much). Its simplicity and power, and that of the available programming tools in its environment have the potential to capture many more developers for Apple and harness their skills to produce a vast collection of new and potent software. That it is firmly fixed in, and unlikely to escape from said Apple ecosystem is thus more of a strength for that community than it is a weakness. True, its programs will be non-portable to other OSs. OTOH, it isn't likely than many people in that community will want them ported. Nor is their much profit in doing so. Other platforms may have many boxes, but their users seem prepared to live with a paucity of low-cost and limited apps. The bar has been raised--a lot.

By contrast, R10 was designed with safety, simplicity security, generality, and good software engineering practice as central issues, and these qualities do set it apart from Swift in many respects. Its template and blueprints, and the rules for creating these, guide the programmer in good practice, provide a measure of safety, and trigger the complier to point out when a necessary binding has been omitted from the refinement. As in all Modula-2 dialects, R10 requires unsafe practices be flagged with an explicit IMPORT from the pseudo-module system SYSTEM. All design decisions, including those to omit older features of limited utility in practice, were subjected to rigorous scrutiny and questioning, sometimes on several occasions, especially when new, potentially impinging decisions were taken. In contrast with the ISO dialect of Modula-2, R10 returns to a simpler, lighter-weight approach to programming, particularly for I/O.

R10 is also unlimited in scope and applicability. It could be used on any platform, and it would not be difficult to use an automated tool produce a set of FOREIGN DEFINITION modules to allow access to the Apple eco-system (or any other's). Whether Apple would, as we believe they should, allow programmers a choice between their proprietary language and one that is arguably more robustly designed for safe and reliable SE practices, and has greater potential to be universal, is doubtful. That they might adopt some R10 ideas to improve Swift is, we hope, as probable as it is necessary.

R10 is at the time of this revision a complete design, requiring only the production of a reference compiler ( and likely a GNU version) to prove its concepts. At a later stage, the designers will ass multi-programming and OO facilities, but these are not critical at this time. Besides, a robust generic system obviates some common but unnecessary solutions done in OO that are more suited for and simpler in generics (parameterized data types and methods, for instance).

Day 5 Conclusions re WWDC itself

The Spy couldn't attend every session or lab. There were others on frameworks for cloudKit, WebKit, iBooks, the store, Photos, games, accessibility, interactive programming, iTunes, power and performance, Cocoa Touch, and improving the user experience. Conversations around him saw Apple engineers helping developers to debug their apps, people from many countries getting to know each other, swopping contact information, forming tentative new alliances, and generally enjoying each others' company.

Being neither a bash or party person, the only evening session the Spy took in was "Stump The Experts. It was hard to tell amid all the institutionalized chaos that Stump always represents who won, but the Spy thinks the event anded with an 11-11 tie.

In other news, he installed Yosemite--which turned out to be a little hairy, as settings for a few programs were lost, and VPN ceased working--it connects but passes no active traffic, and reTurns no diagnostics to explain why not. Otherwise the experience is much as expected--the flatter, cleaner design is visually appealing, the notification centre has become the place to put widgets that access the calendar, a calculator, weather, and stock quotes. Some features, such as handoff do nothing for the Spy as yet, because they require a handoff-enabled iDevice, and his is far too old to run iOS7 let alone iOS8. This includes using the Mac to take calls--essentially a handoff function that requires the mobile device to be nearby.

On the automation side of things JavaScript has been added as a scripting language for OS X. This is in addition to the automation enhancements made for Mavericks (notifications, code signings, use statements, script libraries, speakable workflows). In Yosemite code signing is integrated with workflows, script libraries are enhanced, there are script progress indicators, and dictation commands to enhance speakable workflows.

This extension to the JavaScript language that enables it to be used in this automation. There is a script editor application for writing these scripts. This has a top pane for code and a bottom pane to display live logging of event results. A popup controls the language--AppleScript or JavaScript. Note that JavaScript for Automation is not just JavaScript Core. In this context, Apple has provided a bridge to scriptable applications which, when called produces Apple events. Lots of possibilities here with clickable JavaScript on the desktop and access to foundation classes of the system API. Thus you can now create a Cocoa application in JavaScript.

There's been lots to think about this week. Apple is moving it's developer community forward with many new tools. New hardware will undoubtedly follow, with UI kits added to XCode. Imagination? Creativity? Apple still has it. No stereotypes here. Stay tuned. And now, it's time to drive home, vacationing up the California and Oregon coasts before returning to the old igloo in the frozen north.

--The Northern Spy

Opinions expressed here are entirely the author's own, and no endorsement is implied by any community or organization to which he may be attached. Rick Sutcliffe, (a.k.a. The Northern Spy) is professor of Computing Science and Mathematics at Canada's Trinity Western University. He has been involved as a member or consultant with the boards of several community and organizations, and participated in developing industry standards at the national and international level. He is a co-author of the Modula-2 programming language R10 dialect. He is a long time technology author and has written two textbooks and nine novels, one named best ePublished SF novel for 2003. His columns have appeared in numerous magazines and newspapers (paper and online), and he's a regular speaker at churches, schools, academic meetings, and conferences. He and his wife Joyce have lived in the Aldergrove/Bradner area of BC since 1972.

Want to discuss this and other Northern Spy columns? Surf on over to ArjayBB.com. Participate and you could win free web hosting from the WebNameHost.net subsidiary of Arjay Web Services. Rick Sutcliffe's fiction can be purchased in various eBook formats from Fictionwise, and in dead tree form from Amazon's Booksurge.

URLs for Rick Sutcliffe's Arjay Enterprises:

The Northern Spy Home Page: http://www.TheNorthernSpy.com

opundo : http://opundo.com

Sheaves Christian Resources : http://sheaves.org

WebNameHost : http://www.WebNameHost.net

WebNameSource : http://www.WebNameSource.net

nameman : http://nameman.net

General URLs for Rick Sutcliffe's Books:

Author Site: http://www.arjay.ca

Publisher's Site: http://www.writers-exchange.com/Richard-Sutcliffe.html

The Fourth Civilization--Ethics, Society, and Technology (4th 2003 ed.): http://www.arjay.bc.ca/EthTech/Text/index.html

URLs for items mentioned in this column

WWDC: https://developer.apple.com/wwdc/

Modula-2 R10--see the link at: http://www.modula-2.com/

p1 Modula-2: http://modula2.awiedemann.de/