Introduction

In 1981, the emergence of the government-industry project in Japan known as Fifth Generation Computer Systems (FGCS) was unexpected and dramatic.

The Ministry of International Trade and Industry (MITI) and some of its scientists at Electrotechnical Laboratory (ETL) planned a project of remarkable scope, projecting both technical daring and major impact upon the economy and society.

This project captured the imagination of the Japanese people (e.g. a book in Japanese by Junichiro Uemae recounting its birth was titled The Japanese Dream).

It also captured the attention of the governments and computer industries of the USA and Europe, who were already wary of Japanese takeovers of important industries.

A book by Feigenbaum and McCorduck, The Fifth Generation, was a widely-read manifestation of this concern.

The Japanese plan was grand but it was unrealistic, and was immediately seen to be so by the MITI planners and ETL scientists who took charge of the project.

A revised planning document was issued in May 1982 that set more realistic objectives for the Fifth Generation Project.

Previous Four Generations

• First generation: ENIAC, invented in 1946, and others that used vacuum tubes.

• Second generation: IBM 1401, introduced in 1959, and others that used transistors.

• Third generation: IBM S/360, introduced in 1964, and others that used integrated circuits.

• Fourth generation: IBM E Series, introduced in 1979, and others that used very large-scale integrated circuits, VLSI which have massively increased computational capacity but are still based on the Von Neumann architecture and require specific and precise commands to perform a task.

FGCS was conceived as a computer that can infer from an incomplete instruction, by making use of the knowledge it has accumulated in its database.

FGCS was based on an architecture distinct from that of the previous four generations of computers which had been invented by Von Neumann and commercially developed by IBM among others.

The Vision

1. Increased intelligence and ease of use so that they will be better able to assist man. Input and output using speech, voice, graphics, images and documents, using everyday language, store knowledge to practical use and to the ability to learn and reason.

2. To lessen the burden of software generation in order that a high level requirements specification is sufficient for automatic processing, so that program verification is possible thus increasing the reliability of software. Also the programming environment has to be improved while it should also be possible to use existing software assets.

3. To improve overall functions and performance to meet social needs. The construction of light, compact, high-speed, large capacity computers which are able to meet increased diversification and adaptability, which are highly reliable and offer sophisticated functions.

Objectives

The objective of this project is to realise new computer systems to meet the anticipated requirements of the 1990s.

Everybody will be using computers in daily life without thinking anything of it. For this objective, an environment will have to be created in which a man and a computer find it easy to communicate freely using multiple information media, such as speech, text, and graphs.

The functions of FGCSs may be roughly classified as follows:

1. Problem-solving and inference

2. Knowledge-base management

3. Intelligent interface

The intelligent interface function will have to be capable of handling man/machine communication in natural languages, speeches, graphs, and images so that information can be exchanged in a way natural to a man.

There will also be research into and development of dedicated hardware processors and high-performance interface equipment for efficiently executing processing of speech, graph, and image data.

Several basic application systems will be developed with the intention of demonstrating the usefulness of the FGCS and the system evaluation. These are machine translation systems, consultation systems, intelligent programming systems and an intelligent VLSI-CAD system.

The key technologies for the Fifth Generation Computer System seem to be:

• VLSI architecture

• Parallel processing such as data flow control

• Logic programming

• Knowledge base based on relational database

• Applied artificial intelligence and pattern processing

Project Requirements

1. Realisation of basic mechanisms for inference, association, and learning in hardware, making them the core functions of the Fifth Generation computers.

2. Preparation of basic artificial intelligence software in order to fully utllise the above functions.

3. Advantageous use of pattern recognition and artificial intelligence research achievements, in order to realise man/machine interfaces that are natural to man.

4. Realisation of support systems for resolving the 'software crisis' and enhancing software production.

It will be necessary to develop high performance inference machines capable of serving as core processors that use rules and assertions to process knowledge information.

Existing artificial intelligence technology has been developed to be based primarily on LISP. However, it seems more appropriate to employ a Prolog-like logic programming language as the interface between software and hardware due to the following considerations: the introduction of VLSI technology made possible the implementation of high level functions in hardware; in order to perform parallel processing, it will be necessary to adopt new languages suitable for parallel processing; such languages will have to have a strong affinity with relational data models.

Research and development will be conducted for a parallel processing hardware architecture intended for parallel processing of new knowledge bases, and which is based on a relational database machine that includes a high-performance hierarchical memory system, and a mechanism for parallel relational operations and knowledge operations.

The knowledge base system is expected to be implemented on a relational database machine which has some knowledge base facilities in the Fifth Generation Computer System, because the relational data model has a strong affinity with logic programming.

Relational calculus has a close relation with the first order predicate logic. Relational algebra has the same ability as relational calculus in the description of a query. These are reasons for considering a relational algebra machine as the prime candidate for a knowledge base machine.

Risks

There is no precedent for this innovative and large-scale research and development anywhere in the world. We will therefore be obliged to move toward the target systems through a lengthy process of trial and error, producing many original ideas along the way.

Timeline / Plan

Why not a Generation Evolution?

For computers to be employed at numerous application levels in the 1990s, they must evolve from machines centered around numerical computations to machines that can assess the meaning of information and understand the problems to be solved.

Non-numeric data such as sentences, speeches, graphs, and images will be used in tremendous volume compared to numerical data.

Computers are expected to deal with non-numeric data mainly in future applications. However, present computers have much less capability in non-numeric data processing than in numeric data processing.

The key factors leading to the necessity for rethinking the conventional computer design philosophy just described include the following:

1. Device speeds are approaching the limit imposed by the speed of light.

2. The emergence of VLSI reduces hardware costs substantially, and an environment permitting the use of as much hardware as is required will shortly be feasible.

3. To take advantage of the effect of VLSI mass production, it will be necessary to pursue parallel processing.

4. Current computers have extremely poor performance in basic functions for processing speeches, texts, graphs, images and other nonnumerical data, and for artificial intelligence type processing such as inference, association, and learning.

The research and development targets of the FGCS are such core functions of knowledge information processing as problem-solving and inference systems and knowledge-base systems that cannot be handled within the framework of conventional computer systems.

Results

With the Fourth Conference on Fifth Generation Computer Systems, held June 1-5, 1992 in Tokyo, Japan, an era came to an end.

This section quotes different people analyzing the results, it won't be fully consistent

Since then ten years have passed in which ICOT grew to about 100 researchers and spent about 54 billion Yen, that is some 450 million US$. In these ten years a large variety of machines have been built ranging from the special purpose PSI machine, that is a personal sequential inference machine, to several constellations of processors and memory ranging from 16 to 512 processing elements together forming the PIM family, that is the Parallel Inference Machine.

Fun Trivia

The one commercial use we saw of the PSI machines was at Japan Air Lines, where the PSI-II machines were employed; ironically, they were remicrocoded as Lisp Machines.

Sources

• Overview to the Fifth Generation Computer System project (1983)

• The Japanese national Fifth Generation project: introduction, survey, and evaluation (1993)

• An overview and appraisal of the Fifth Generation Computer System project (1993)

• Research consortia as a vehicle for basic research: The case of a fifth generation computer project in Japan (1997)

Conclusion

This section has no quotes from sources, these are my observations:

I find that for every thing you can point as a reason for its "failure" there's an alternative universe where you could point to the same things as reasons for its success.

For example:

• Starting from scratch

• Thinking from first principles

• Radical changes to the status quo

• Single focus

• Vertical integration

• Risky bet on nascent technologies

• Specialized Hardware

The only reason that is clearly negative is that the demo applications were not developed with real use cases and involving real users, that may have made it harder to show the value of FGCS to end users and industrial partners.

It would be easy to mention Worse is Better but if it keeps coming up as a reason, maybe we should pay more attention to it?

My conclusion right now is that technically they achieved many of the things they planned, they succeeded at going where they thought the puck was going to be in the 90s but it ended up somewhere else.

What's your conclusion?

Related Posts

• Why OpenDoc failed, and then failed 3 more times?

• Past Futures of Programming: General Magic's Telescript

Introduction

Telescript was a programming language developed by General Magic in the nineties that allow the first generation of mobile devices to interact with services in a network.

This sounds similar to the way smartphones work today, but the paradigm that Telescript supported called "Remote Programming" instead of Remote Procedure Calling is really different to the way we build services and mobile applications today.

For this reason and because as far as I know there's not much knowledge about the language and the paradign online I decided to write a summary after reading all the content I could find. All resources are linked at the end of the article.

If you haven't heard of General Magic I highly recommend you to watch the documentary, here's the trailer:

In case you prefer content in video form, the following may give you an idea.

For an overview video and the earliest mention of the Cloud I can think of see:

An introduction by Andy Hertzfeld at 21:20 in this video:

Another (longer) talk by Andy at Standford two weeks after the one above, mostly focused on Magic Cap but mentions Telescript around 1:06:38:

From now on most of the text is quoted from the resources linked at the end, since my personal notes are just a few I will quote only my comments, they will look like this:

Hi, this is a comment from the author and not a quote from Telescript resources.

Since each resource attempts to be self contained there's a lot of content that is repeated with some variation.

I slightly edited the quoted text to avoid repetition. Emphasis is mine.

The Pitch

The convergence of computers and communication, and advances in graphical user interfaces are placing powerful new electronics products in the hands of consumers.

In principle, such products can put people in closer touch with one another -- for example, by means of electronic postcards; simplify their relationships by helping them make and keep appointments; provide them with useful information such as television schedules, traffic conditions, restaurant menus, and stock market results; and help them carry out financial transactions, from booking theater tickets, to ordering flowers, to buying and selling stock.

Unless public networks become platforms on which third-party developers can build communicating applications, the networks will respond much too slowly to new and varied requirements and so will languish. Unfortunately, today's networks are not platforms.

Telescript enables the creation of a new breed of network that supports the development of communicating applications by making the network a platform for developers. It provides the "rules of the road" for the information superhighway, which leads to the electronic marketplace.

The Electronic Marketplace

Telescript integrates an electronic world of computers and the networks that link them. This world is filled with Telescript places occupied by Telescript agents.

In the electronic world, each place or agent represents an individual or organization in the physical world, its authority. A place's or agent's authority is revealed by its telename, which can't be falsified.

A place, but not an agent, has a teleaddress, which designates the place's location in this electronic world and reveals the authority of the individual or organization operating the computer in which the place is housed.

The typical place is permanently occupied by an agent of the place's authority and temporarily occupied –visited– by agents of other authorities.

The Plan

In July 1995, NTT, AT&T, and Sony announced a joint venture to deploy a Telescript-based service in Japan.

In October 1995, France Telecom (the operater of the Minitel electronic marketplace, which supports more than 26,000 merchants and accessed in 1994 by 18 million users) announced its licensing of Telescript for use in France.

The Language

Telescript is:

• Object-oriented: As in SmallTalk

• Complete: Any algorithm can be expressed in the language.

• Dynamic: A program can define or discover, and then use new classes during execution. While exploring the electronic marketplace, a Telescript agent may encounter an object whose class it has never seen. The agent can take the object home, where it continues to function.

• Persistent. The Telescript engine secures all its data transparently, even the program counter that marks its point of execution. Thus, a Telescript program persists even in the face of computer failures.

• Interpreted

• Portable and safe: A computer executes an agent's instructions through a Telescript engine, not directly. An agent can execute in any computer in which an engine is installed, yet it cannot access directly its processor, memory, file system, or peripheral devices.

• Communication-centric: Designed for carrying out complex networking tasks: navigation, transportation, authentication, access control, and so on.

Telescript supplements systems programming languages such as C and C++; it does not replace them. Only the parts of an application that require the ability to move from one place in a network to another –the agents– are written in Telescript.

Telescript is object-oriented. In fact, like the first object-oriented language, Smalltalk, Telescript is deeply object-oriented. That is, every piece of information, no matter how small, is an object. Thus, even a Boolean is an object.

Like many object-oriented programming languages, Telescript focuses on classes. A class is a "slice" of an object's interface, combined with a related "slice" of its implementation. An object is an instance of a class.

Standard OOP similar to Smalltalk/Java, check Telescript Object Model for details

Process objects provide Telescipt's multi-tasking functionality. Processes are pre-emptively multi-tasked, and scheduled according to priority.

Telescript implements the following principal concepts:

• Places

• Agents

• Travel

• Meetings

• Connections

• Authorities

• Permits

Telescript extends the concept of remote programming, the ability to upload and execute programs to a remote processor, with migrating processes. A Telescript mobile agent is a migrating process that is able to move autonomously during its execution to a different processor and continue executing there.

Mobile agents conceptually move the client to the server, where stationary processes, or places, service their requests. When it is done in a place, an agent might choose to move itself to a different processor, carry results back to where it originated, or simply terminate.

Clearly, security is a major concern in this scenario. The operator of a Telescript processor wants some assurance that nothing bad will come of its decision to admit an incoming agent. The host platform wants to know who is responsible for the agent. The agent, on the other hand, would like to trust that private information it is carrying will not be disclosed arbitrarily. It needs to trust the operator of the platform.

Telescript provides some useful Mix-in classes that associate security-relevant attributes with objects of those classes, where the associated functionality is enforced by the engine. These include:

• Unmoved. An agent cannot take such an object along with it when it does a go. Places, for example, are Unmoved.

• Uncopied. An attempt to make a copy of such an object returns a reference to the original object rather than creating a copy.

• Copyrighted. This class is provided as a language extension rather than part of the language. Nonetheless, it is built into engines. An attempt to instantiate such an object will fail during initialization if it is not properly authorized by a suitable Copyright Enforcer object.

• Protected. Such an object cannot be modified once created, and any reference to such an object is like having a protected reference, except that ownership can be transferred. Packages are Protected.

Unauthorized processes, or processes that are not running under the region's authority, cannot create instances of the following classes:

• File: A File object can create a handle to any file that the engine can access on the underlying operating system.

• External Handle: An External Handle object can open a TCP/IP port on the underlying operating system.

• Control Manager: A Control Manager object can be used to perform a number of management and control operations on an engine. For example, a Control Manager can be used to change attributes of processes, such as their authority, or to halt the engine.

The Engine

All Telescript engines provide:

• Runtime type checking with dynamic feature binding

• Automatic memory management

• Exception processing

• Authenticated, unforgeable identity for each process, in the form of an authority

• Protected references

• Protection by encapsulation of private properties and features. This forms the basis for object-enforced access controls

• quotas and process privileges using permits, including control over creation of new processes

• security-oriented mix-in classes (Copyrighted, Unmoved, Protected, Uncopied)

• mediated protocols for process rendezvous (for example, entering a place, and Meeting Agents)

With regard to installing bogus classes, the Telescript engine won't admit an agent carrying a class that has the same name as one that's already in the engine, unless it's the same class. In other words, within an engine, class names must be unique.

Concepts

Agents

A place is occupied by Telescript agents. Whereas places give the electronic marketplace its static structure, agents are responsible for its dynamic activity.

A Telescript agent is an independent process. The Telescript environment executes the programs of the various agents that occupy the marketplace in parallel with one another.

Two agents must meet before they can interact. One agent initiates the meeting using meet, an instruction in the Telescript instruction set. The second agent, if present, accepts or declines the meeting.

As a consequence of meet, the agents receive references to one another. The references let them interact as peers.

While in the same place, two agents interact by meeting. While in different places, they interact by communicating.

An agent can travel to several places in succession. It might link trips in this way to obtain several services or to select one from among them. Booking theater tickets, for example, might be only the first task on our user agent's to-do list. The second might be to travel to the florist place and there arrange for a dozen roses to be delivered the day of the theater event.

Places

Telescript places lend structure and consistency to the electronic marketplace.

Each place represents, in the electronic world, an individual or organization -- the place's authority -- in the physical world. Several places may have the same authority. A place's authority is revealed by its telename.

Travel

Agents travel using Telescript's go instruction.

The agent need merely present a ticket that identifies its destination. An agent executes go to get from one place to another. After an agent executes go, the next instruction in the agent's program is executed at the agent's destination, not at its source. Thus, Telescript reduces networking to a single program instruction.

If the trip cannot be made (for example, because the means of travel cannot be provided or the trip takes too long), the go instruction fails and the agent handles the exception as it sees fit. However, if the trip succeeds, the agent finds that its next instruction is executed at its destination.

An agent can move from place to place throughout the performance of its procedure because the procedure is written in a language designed to permit this movement.

Protocols

Telescript protocols operate at two levels. The higher level encompasses the encoding (and decoding) of agents, the lower level their transport.

The Telescript encoding rules explain how an agent -- its program, data, and execution state -- are encoded for transport, and how parts of the agent sometimes are omitted as a performance optimization.

The protocol suite can operate over a wide variety of transport networks, including those based on the TCP/IP protocols of the Internet, the X.25 interface of the telephone companies, or even electronic mail.

Example Use Cases

CatalogEntry: class = (
  public
     see initialize
     see adjustPrice
     product: String;
     price: Integer; // cents
  property
     lock: Resource;
);

initialize: op (product: String; price: Integer) = {
  ^();
  lock = Resource()
};

adjustPrice: op (percentage: Integer) throws ReferenceProtected = {
  use lock   {
    price = price + (price*percentage).quotient(100)
  }
};

Warehouse: class (Place, EventProcess) = (
  public
    see initialize
    see live
    see getCatalog
  property
    catalog: Dictionary[String, CatalogEntry];
);

initialize: op (catalog: owned Dictionary[String, CatalogEntry]) = {
  ^()
};

live: sponsored op (cause: Exception|Nil) = {
  loop {
    // await the first day of the month
    time: = Time();
    calendarTime: = time.asCalendarTime();
    calendarTime.month = calendarTime.month + 1;
    calendarTime.day = 1;
    *.wait(calendarTime.asTime().interval(time));

    // reduce all prices by 5%
    for product: String in catalog {
      try { catalog[product].adjustPrice(-5) }
      catch KeyInvalid { }
    };

  // make known the price reductions
  *.signalEvent(PriceReduction(), 'occupants)
  }
};

Resources

• The Foundation for the Electronic Marketplace

• Scenes from the Electronic Marketplace

• An Introduction to the Language

• Mobile Agents

• An Introduction to Safety and Security in Telescript

• Telescript Language Reference

• Telescript Programming Guide

Related Posts

• Japan's Fifth Generation Computer Systems: Success or Failure?

• Why OpenDoc failed, and then failed 3 more times?

✍️ Notation as a Tool of Thought

• The importance of nomenclature, notation, and language as tools of thought has long been recognized. In chemistry and in botany the establishment of systems of nomenclature did much to stimulate and to channel later investigation

• Mathematical notation provides perhaps the best-known and best-developed example of language used consciously as a tool of thought

• In addition to the executability and universality emphasized in the introduction, a good notation should embody characteristics familiar to any user of mathematical notation:

• Ease of Expressing Constructs Arising in Problems:

  If it is to be effective as a tool of thought, a notation must allow convenient expression not only of notions arising directly from a problem, but also of those arising in subsequent analysis, generalization, and specialization.

• Suggestivity:

  A notation will be said to be suggestive if the forms of the expressions arising in one set of problems suggest related expressions which find application in other problems.

• Subordination of Detail:

  As Babbage remarked in the passage cited by Cajori, brevity facilitates reasoning. Brevity is achieved by subordinating detail

• Economy:

  The utility of a language as a tool of thought increases with the range of topics it can treat, but decreases with the amount of vocabulary and the complexity of grammatical rules which the user must keep in mind. Economy of notation is therefore important.

  Economy requires that a large number of ideas be expressible in terms of a relatively small vocabulary. A fundamental scheme for achieving this is the introduction of grammatical rules by which meaningful phrases and sentences can be constructed by combining elements of the vocabulary.

💭 How can we develop transformative tools for thought?

• Retrospectively it’s difficult not to be disappointed, to feel that computers have not yet been nearly as transformative as far older tools for thought, such as language and writing. Today, it’s common in technology circles to pay lip service to the pioneering dreams of the past. But nostalgia aside there is little determined effort to pursue the vision of transformative new tools for thought

• Why is it that the technology industry has made comparatively little effort developing this vision of transformative tools for thought?

• Online there is much well-deserved veneration for these people. But such veneration can veer into an unhealthy reverence for the good old days, a belief that giants once roamed the earth, and today’s work is lesser

• What creative steps would be needed to invent Hindu-Arabic numerals, starting from the Roman numerals? Is there a creative practice in which such steps would be likely to occur?

• The most powerful tools for thought express deep insights into the underlying subject matter

• Conventional tech industry product practice will not produce deep enough subject matter insights to create transformative tools for thought

• The aspiration is for any team serious about making transformative tools for thought. It’s to create a culture that combines the best parts of modern product practice with the best parts of the (very different) modern research culture. Diagram: 'insight' and 'making', pointing to each other in a loop You need the insight-through-making loop to operate, whereby deep, original insights about the subject feed back to change and improve the system, and changes to the system result in deep, original insights about the subject.

  People with expertise on one side of the loop often have trouble perceiving (much less understanding and participating in) the nature of the work that goes on on the other side of the loop. You have researchers, brilliant in their domain, who think of making as something essentially trivial, “just a matter of implementation”. And you have makers who don’t understand research at all, who see it as merely a rather slow and dysfunctional (and unprofitable) making process

• Why isn’t there more work on tools for thought today?

• It is, for instance, common to hear technologists allude to Steve Jobs’s metaphor of computers as “bicycles for the mind”. But in practice it’s rarely more than lip service. Many pioneers of computing have been deeply disappointed in the limited use of computers as tools to improve human cognition

  Our experience is that many of today’s technology leaders genuinely venerate Engelbart, Kay, and their colleagues. Many even feel that computers have huge potential as tools for improving human thinking. But they don’t see how to build good businesses around developing new tools for thought. And without such business opportunities, work languishes.

• What makes it difficult to build companies that develop tools for thought?

• Many tools for thought are public goods. They often cost a lot to develop initially, but it’s easy for others to duplicate and improve on them, free riding on the initial investment. While such duplication and improvement is good for our society as a whole, it’s bad for the companies that make that initial investment

• Pioneers such as Alan Turing and Alonzo Church were exploring extremely basic and fundamental (and seemingly esoteric) questions about logic, mathematics, and the nature of what is provable. Out of those explorations the idea of a computer emerged, after many years; it was a discovered concept, not a goal. Fundamental, open-ended questions seem to be at least as good a source of breakthroughs as goals, no matter how ambitious

• There’s a lot of work on tools for thought that takes the form of toys, or “educational” environments. Tools for writing that aren’t used by actual writers. Tools for mathematics that aren’t used by actual mathematicians. Even though the creators of such tools have good intentions, it’s difficult not to be suspicious of this pattern. It’s very easy to slip into a cargo cult mode, doing work that seems (say) mathematical, but which actually avoids engagement with the heart of the subject

• Good tools for thought arise mostly as a byproduct of doing original work on serious problems

👩‍🎨 Designerly Ways of Knowing: Design Discipline Versus Design Science

• A desire to “scientise” design can be traced back to ideas in the twentieth century modern movement of design

• We see a desire to produce works of art and design based on objectivity and rationality, that is, on the values of science

• The 1960s was heralded as the “ design science decade” by the radical technologist Buckminster Fuller, who called for a “ design science revolution” based on science, technology, and rationalism to overcome the human and environmental problems that he believed could not be solved by politics and economics

• We must avoid swamping our design research with different cultures imported either from the sciences or the arts. This does not mean that we should completely ignore these other cultures. On the contrary, they have much stronger histories of inquiry, scholarship, and research than we have in design. We need to draw upon those histories and traditions where appropriate, while building our own intellectual culture, acceptable and defensible in the world on its own terms. We have to be able to demonstrate that standards of rigor in our intellectual culture at least match those of the others

OpenDoc

To start, here's a brief description of what OpenDoc was:

The OpenDoc concept was that developers could just write the one piece they were best at, then let end-users mix and match all of the little pieces of functionality together as they wished.

Let's find out the reasons:

ActiveX

ActiveX lived longer and was used in multiple places, so why was it deprecated?

ActiveX on Wikipedia

Complexity:

Even after simplification, users still required controls to implement about six core interfaces. In response to this complexity, Microsoft produced wizards, ATL base classes, macros and C++ language extensions to make it simpler to write controls.

Unified model, platform fragmentation:

Such controls, in practice, ran only on Windows, and separate controls were required for each supported platform

Security and lack of portability:

Critics of ActiveX were quick to point out security issues and lack of portability

...

The ActiveX security model relied almost entirely on identifying trusted component developers using a code signing technology

...

Identified code would then run inside the web browser with full permissions, meaning that any bug in the code was a potential security issue; this contrasts with the sandboxing already used in Java at the time.

A break from the past, part 2: Saying goodbye to ActiveX, VBScript, attachEvent…

HTML 5 replaces most use cases:

The need for ActiveX controls has been significantly reduced by HTML5-era capabilities, which also produces interoperable code across browsers.

The Open Source Alternatives: KParts & Bonobo

If the problem was the business model but the technology was really powerful then it should not be a problem for up-and-coming open source desktop environments with a user base consisting mostly on power users and developers that would benefit from code reuse.

The major desktop environments, Gnome and KDE, had/have something similar to OpenDoc.

An interesting fact is that Gnome used to be an acronym: GNU Network Object Model Environment, the Object Model idea was in the name itself.

I didn't notice until now that the name KParts seems to come from OpenDoc's Parts concept.

Usenix: KDE Application Integration Technologies:

A KPart is a dynamically loadable module which provides an embeddable document or control view including associated menu and toolbar actions. A broker returns KPart objects for certain data or service types to the requesting application. KParts are for example used for embedding an image viewer into the web browser or for embedding a spread sheet object into the word processor.

KParts on Wikipedia:

Example uses of KParts:

• Konqueror uses the Okular part to display documents

• Konqueror uses the Dragon Player part to play multimedia

• Kontact embeds kdepim applications

• Kate and other editors use the katepart editor component

• Several applications use the Konsole KPart to embed a terminal

How will CORBA be used in GNOME, or, what is Bonobo?

Bonobo is a set of interfaces for providing application embedding and in-place activation which are being defined. The Bonobo interfaces and interactions are modeled after the OLE2 and OpenDoc interfaces.

...

Reusable controls: Another set of Bonobo interfaces deal with reusable controls. This is similar to Sun's JavaBeans and Microsoft Active-X.

Bonobo on Wikipedia:

Available components are:

• Gnumeric spreadsheet

• ggv PostScript viewer

• Xpdf PDF viewer

• gill SVG viewer

History of Gnome: Episode 1.3: Land of the bonobos:

Nautilus used Bonobo to componentise functionality outside the file management view, like the web rendering, or the audio playback and music album view.

...

This was the heyday of the component era of GNOME, and while its promises of shiny new functionality were attractive to both platform and application developers, the end result was by and large one of untapped potential. Componentisation requires a large initial effort in designing the architecture of an application, and it’s really hard to introduce after the fact without laying waste to working code.

...

As an initial roadblock it poorly fits with the “scratch your own itch” approach of free and open source software. Additionally it requires not just a higher level of discipline in the component design and engineering, it also depends on comprehensive and extensive documentation, something that has always been the Achille’s Heel of many an open source project.

History of Gnome: Episode 1.5: End of the road

Sun’s usability engineer Calum Benson presented the results of the first round of user testing on GNOME 1.4, and while the results were encouraging in some areas, they laid bare the limits of the current design approach of a mish-mash of components. If GNOME wanted to be usable by professionals, not curating the offering of the desktop was not a sustainable option any more.

...

The consistency, or lack thereof, of the environment was one of the issues that the testing immediately identified: identical functionality was labelled differently depending on the component; settings like the fonts to be used by the desktop were split across various places; duplication of functionality, mostly for the sake of duplication, was rampant. Case in point: the GNOME panel shipped with not one, not two, but five different clock applets—including, of course, the binary clock

...

Additionally, all those clocks, like all the panel applets, could be added and removed by sheer accident, clicking around on the desktop. The panel itself could simply go away, and there was no way to revert to a working state without nuking the settings for the user.

KParts seems to still be around, you can see a list of actively developed KParts on KDE's GitHub account, Bonobo was replaced by DBus which is a Message-oriented abstraction not related to OpenDoc concepts as far as I know.

What about Web Components?

From MDN: Web Components:

Web Components is a suite of different technologies allowing you to create reusable custom elements — with their functionality encapsulated away from the rest of your code — and utilize them in your web apps.

Web Components have been around for a while and developers seem to be split in two camps regarding how useful it is.

We will see with time if it becomes the main way to do web applications and a new attempt at OpenDoc, this time on the web.

Conclusion

Still not sure which were the main reasons, but many of them aren't shared by later attempts:

• More RAM was available during the ActiveX days and is available today for KParts

• KParts and Bonobo don't require a business model and benefit from reuse

  • Unlike OpenDoc/ActiveX there's no competition between Apple/Microsoft and developers

• Execution on ActiveX/KParts didn't seem to be a problem

• Lived long enough and learned from OpenDoc failure

• Weren't developed by a consortium

• Were well integrated into the underlying environment

• Had use cases from day one

• No vendor lock-in

• Some had good distribution channels (Package Managers)

• At least KParts and WebComponents seem to have a good developer experience

The conclusion is that there's no conclusion, the case is still open, what do you think?

Related Posts

• Japan's Fifth Generation Computer Systems: Success or Failure?

• Past Futures of Programming: General Magic's Telescript

💾 Computers and Creativity

I will be arguing that to foster optimal human innovation, digital creative tools need to be interoperable, moldable, efficient, and community-driven.

...

Acknowledging that computers themselves are not inherently creative should not come as a surprise. Instead, this truth identifies an opportunity for computers to more fully assume the role of co-creator — not idea-generator, but actualizer.

...

Intelligence Augmentation (IA), is all about empowering humans with tools that make them more capable and more intelligent, while Artificial Intelligence (AI) has been about removing humans fully from the loop

...

The lack of interoperability between creative tools means that all work created within a tool is confined to the limitations of that tool itself, posing a hindrance to collaboration and limiting creative possibility

...

Moving beyond building on top of existing software, we can begin to imagine what a piece of software could look like if it itself was moldable, or built to be modified by the user

🧠 Thought as a Technology

At first these elements seem strange. But as they become familiar, you internalize the elements of this world. Eventually, you become fluent, discovering powerful and surprising idioms, emergent patterns hidden within the interface. You begin to think with the interface, learning patterns of thought that would formerly have seemed strange, but which become second nature. The interface begins to disappear, becoming part of your consciousness

...

What makes an interface transformational is when it introduces new elements of cognition that enable new modes of thought. More concretely, such an interface makes it easy to have insights or make discoveries that were formerly difficult or impossible

...

Mathematicians often don't think about mathematical objects using the conventional representations found in books. Rather, they rely heavily on what we might call hidden representations

...

This contrasts with the approach in most computer reasoning systems. For instance, much work on doing mathematics by computer has focused on automating symbolic computation (e.g., Mathematica), or on finding rigorous mathematical proofs (e.g., Coq). In both cases, the focus is on correct mathematical reasoning. Yet in creative work the supply of rigorously correct proofs is merely the last (and often least interesting) stage of the process. The majority of the creative process is instead concerned with rapid exploration relying more on heuristics and rules of thumb than on rigorous proof. We may call this the logic of heuristic discovery. Developing such a logic is essential to building exploratory interfaces.

🌱 Personal Digital Habitats

A Personal Digital Habitat is a federated multi-device information environment within which a person routinely dwells. It is associated with a personal identity and encompasses all the digital artifacts (information, data, applications, etc.) that the person owns or routinely accesses. A PDH overlays all of a person’s devices1 and they will generally think about their digital artifacts in terms of common abstractions supported by the PDH rather than device- or silo-specific abstractions. But presentation and interaction techniques may vary to accommodate the physical characteristics of individual devices.

...

Personal Digital Habitat is an aspirational metaphor. Such metaphors have had an important role in the evolution of our computing systems. In the 1980s and 90s it was the metaphor of a virtual desktop with direct manipulation of icons corresponding to metaphorical digital artifacts that made personal computers usable by a majority of humanity.

🏛️ DynamicLand Narrative

The mission of the Dynamicland Foundation is to enable universal literacy in a humane computational medium.

...

Instead of isolating and disembodying, it must bring communities together in the same physical space, to teach and discuss ideas face-to-face, to build and explore ideas with their hands, to solve problems collectively and democratically. For universal literacy, and for a humane medium, these are requirements.

...

Dynamicland researchers are inventing a new form of computing which takes place in physical space, using ordinary physical materials such as paper, pens, cardboard, and clay. There are no screens and no apps. Instead, people craft computational activities together with their hands

...

Unlike isolated apps, these projects all exist in the same space, can all be interconnected with one another, and can all be used by many people together

...

Dynamicland is particularly interested in its potential for public spaces in which people seek to understand and communicate — libraries, museums, classrooms, arts spaces, town halls, courtrooms.

...

The Dynamicland researchers are not developing a product. The computers that the researchers build are models: not for distribution, but for studying and evaluating

...

This community space is an early model for a new kind of civic institution — a public library for 21st-century literacy. Dynamicland envisions a future where every town has a “dynamic library” with computational literature on every subject, where people gather to collectively author and explore this literature, using the medium to represent and debate their ideas using computational models. People will hold presentations and town-hall discussions on issues of importance to the community, using the medium to see facts, explore consequences of proposals, and make data-driven decisions collectively. The public benefit of transforming collective learning and civic engagement is potentially immeasurable.

🧑‍💼 Office, messaging and verbs

The way forward for productivity is probably not to take software applications and document models that were conceived and built in a non-networked age and put them into the cloud

...

It takes time, but sooner or later we stop replicating the old methods with the new tools and find new methods to fit the new tools

...

What kills that task is not better or cheaper (or worse and free) spreadsheet or presentation software, but a completely different way to address the same underlying need - a different mechanism

...

But it should be replaced by a SaaS dashboard with realtime data, alerts for unexpected changes and a chat channel or Slack integration. PowerPoint gets killed by things that aren't presentations at all

...

You don't actually send email or make a spreadsheet - you analyze, delegate, report, confer, decide, track and so on. Or, perhaps, 'what's going on, what are we doing and what should we be doing?

🧑‍🎨 Software designers, not engineers An interview from alternative universe

In my universe, we treat the creation of software as a design activity, putting it as a third item on the same level as science and art.

...

when we start a software project, we think of it in more general terms. A typical form of what you call specification in our world is a bit more like a design brief. A much more space is dedicated to the context in which the work is happening, the problem that you are trying to solve and constraints that you are facing, but design briefs say very little about any specific potential software solution to the problem.

...

When you're solving a problem, even as you get to a more technical level, you always keep in mind why you are solving it.

...

The problem really only becomes apparent as you try to solve it. So, the key thing is to quickly iterate. You come up with a new framing for the problem, sketch a solution based on your framing and see what it looks like. If it looks good to you, you show it to the customer, or you sketch a range of different prototypes.

...

Software sketches are very ambiguous. When you are sketching, you are omitting a lot of details and so the sketching tool will give you something that can behave in unexpected ways in certain situations.

This is actually quite valuable, because this ambiguity allows your ideas to evolve. You can often learn quite a lot about the problem from the things that are underspecified in your sketches.

...

Very often, the right problem framing makes it possible to see a problem in a new way

⭕ Our Brain Typically Overlooks This Brilliant Problem-Solving Strategy

People often limit their creativity by continually adding new features to a design rather than removing existing ones

🛠️ The state of internal tools in 2021

Developers spend more than 30% of their time building internal applications.

That number jumps to 45% for companies with 5000+ employees.

...

More than 57% of companies reported at least one full-time employee dedicated to internal tools.

...

77% of companies with 500+ employees have dedicated teams for building and maintaining internal apps

...

2 out of 3 developers default to building from scratch, as opposed to using a spreadsheet or a SaaS tool.

🕹️ Serious Play

Games remain the most underrated and underexplored medium of art ever conceived by humans

...

Video games are right now shaping the patterns that will define the next generation of Design. Many of the hot topics in tech today like artificial intelligence, augmented reality, and remote collaboration have been brewing in video games for decades

♾️ Systems design explains the world

What is systems design? It's the thing that will eventually kill your project if you do it wrong, but probably not right away. It's macroeconomics instead of microeconomics.

...

Most of all, systems design is invisible to people who don't know how to look for it

...

With systems design, the key insight might be a one-sentence explanation given at the right time to the right person, that affects the next 5 years of work

...

What makes the Innovator's Dilemma so beautiful, from a systems design point of view, is the "dilemma" part. The dilemma comes from the fact that all large companies are heavily optimized to discard ideas that aren't as profitable as their existing core business

Colors

• Change color of things

• Nice default color palette

• Use my preferred color palette

• Use this color from here

• Import/export color themes

• Some words or identifiers should always have a specific color

• The same thing should have the same color everywhere

• Good contrast

• Automatic contrast of text if I pick a dark/light background

• Automatically generate color for large number of items

  • All the colors should belong to the same palette

  • Don't generate colors that are hard to tell apart

  • Don't place similar colors close to each other

  • Don't use the background color on things

Formatting

• Apply basic formatting to text

• Align text

• Use the fonts I use in Office

• WYSIWYG editor that behaves like Word

• Number alignment

• Number/date formatting to the right locale

• Decimal formatting to the right/fixed number of decimal places

• No weird .0000004 formatting anywhere

• No .00 for integers

• Emoji support

Themes

• Dark theme

• My Theme

• Company Branding

• Put the logo in places

• My logo on the Login Page

Integrations

• Integrate with system accounts

• Use accounts/permissions from Active Directory

• Import from Excel/CSV

• Import from email/email attachment

• Export to Excel

• Export to PDF/Image

• Record a short video

  • As a GIF

• Send as email

  • Send as email periodically

  • Send as PDF attachment on an email

• Import/attach images

  • Crop before upload

  • Compress

  • Change Format

• Use image as background but stretch the right way

• Notifications on the app

  • On apps on my phone

  • By SMS

  • On our systems

  • On my mail

UX

• Good error handling

• Good error descriptions

  • Translated error messages

• Tell me what to do to solve an error

• Tell me what this does before I click on it

• Support touch gestures and mouse

• Keyboard shortcuts

  • Customizable

• Undo everywhere

• Multiple undo

• Recover deleted things

• Ask before deleting

• Copy and paste

• Templates

• Detailed and up to date guides in text with screenshots at each step and highlights

  • And in Video

  • Screenshots that stay up to date as the product evolves

  • That are in sync with the version I'm using

  • That adapt to my custom setup

• Up to date and detailed documentation

• Translated to my language

• Sorting everywhere

  • Natural sort

  • Sort by multiple criteria

• Filter everywhere

  • Fuzzy filtering

  • Case sensitive/insensitive filtering

  • Filter by multiple/complex criteria

• Track what is used where and warn me when deleting

• Optional cascade deletion

• Native and simple date picker on every platform

• Sorted lists/selects (by the label!)

  • Natural Sorting

• Dropdowns with filtering but that behave like the native controls

• Preview things

• Consistent button ordering/labels

• Consistent capitalization

• Progress bars for slow/async operations

• Responsive UI during slow operations

• Disabling buttons during slow operations

• Handling double clicks on things that should be clicked once

• Clear indication of what can be clicked

Compatibility

• Deploy on exotic configurations/platforms

• Deploy on old/unsupported versions

• Deploy on what we have

• Deploy/Run without internet connection

• Handle Excel, CSV, JSON, XML

  • Handle malformed versions of all of the above

• Handle (guess) dates with no timezone

• Handle ambiguous/changing date formats

• Integrate with obscure/outdated software/format

• It should work on my old android phone browser/IE 11

• Unicode

  • Handle inputs with unknown and variable encodings

Operations

• Easy to install

• Easy to update

• Easy to backup

• Easy to recover

• Works with the database and version we use

• Can be mounted on a path that is not the root of the domain