Taligent's Guide to Designing Programs [pdf] (1994)
bitsavers.org
bitsavers.org
From http://ibgwww.colorado.edu/~lessem/psyc5112/usail/library/hu...
Taligent/Pink: You walk to the store with Ricardo Montalban, who tells you how wonderful it will be when he can fly you to the store in his Learjet.
Of course operating systems DO run our cars now. I would add
Modern cars: You pay your monthly subscription that allows you to unlock your car after it won't let you in. After entering your destination in the nav system you must sit through five minutes of store-related advertising on your dashboard before you can leave because you can't afford to upgrade to the ad-free tier. You are escorted to the store by a fleet of surveillance drones, several of which follow you around and scan everything you look at. Halfway home the car stops and makes you watch another five minutes of advertising about products related to your purchases.
In this case it's possible to recognise both that Taligent inadvertently subsidised production of a nicely packaged collection of "best practices" (taken individually, the TOC topics lgtm) and that shipping crap dominates designing (maybe even building?) according to best practices but never invoicing.
(I don't know if it's still true, but for a long time last century the "secret sauce" of Silicon Valley was that it was easy to find people who had just come off of one of these grand "new new thing" Потёмкин projects, and both (a) wanted to ship this time around, and (b) knew the best corners to cut to do so)
"Those who can do, do. Those who can't, teach."
It implies that teaching isn't a skill of its own. Some of the best football coaches were mediocre players (Alex Ferguson, Jose Mourinho) and some of the best players turned out to be very poor coaches (Steven Gerrard springs to mind at the moment). Can you only learn physics from someone who has made a world-changing discovery, or learn to write from a best-selling author? Or do you learn from someone who knows just enough to guide you in the right direction with enthusiasm and correct your mistakes in a way that doesn't make you feel like a failure?
What is correct is dogma in software development is a problem - software is too malleable and the world changes too fast to allow one set of ideas to dominate everything. That lesson hadn't even been thought about in the 90s though.
Expensive consulting services, training courses, books, videos, etc. It's not about whether any of that stuff actually works; it's about essentially creating a religion and extracting profit from the gullible.
Technology developed by Taligent landed in other projects, for instance, the Java JDK.
> in early 1996, IBM had assumed full ownership of Taligent, the joint venture started by IBM and Apple and later joined by HP. Taligent had been developing an object-oriented application framework and operating system called CommonPoint, which included extensive international support. When IBM took over, CommonPoint was mothballed, but much of the underlying technology was integrated into other IBM products.
Fairly quickly, the management of IBM and Taligent came to a realization: Java was missing international support. But Taligent had great international technology, talented engineers--including Dr. Mark Davis, president of the Unicode Consortium--and a location about 100 meters from Sun's JavaSoft division in Cupertino, California. Thus, a partnership was born: IBM arranged for Taligent's Text and International group to contribute international classes to Sun's Java Development Kit, making Java powerful enough for real-world business applications.
For JDK 1.1, Taligent provided the new java.text package, plus a number of new classes in java.util. This included Format and all its subclasses for formatting dates, times, numbers and messages; Collator, for language-sensitive string sorting; and BreakIterator , for determining line, word, and sentence boundaries in Unicode text. In java.util, Taligent contributed parts of ResourceBundle, as well as the Calendar and TimeZone classes (which provide flexible, international-friendly date and time support). In addition, IBM contributed a large collection of locale data from their National Language Technical Center in Toronto. This API and data provide a standard way to handle the requirements of different countries and languages, making this transparent to developers.
https://icu-project.org/docs/papers/history_of_java_internat...
I seem to recall a rumour that these were not given to experienced engineers to implement.
Waaay too much structure (and I like structure).
One of the things that struck me, was all the fairly basic stuff you couldn’t do, without getting a sign-off from an architect.
It must have been kind of miserable, to be an architect, there.
You aren't kidding. The table of contents alone has 20 pages.
All concrete advice, assertively stating "your code must look this way". The advice looks kinda sensible, but that lot of rules can't work as a group.
I’ve learned that it’s very important to “sneak” structure into the mix, so folks adopt it without thinking.
Designing good affordances, simple documentation, and sparse UX are important.
I feel that developer tools and documentation are often way more complicated than they could be, and that we often avoid applying the same kind of UX work, as we do, with regular end-user applications.
If it really was a cookie-cutter exercise, you wouldn't need developers. You'd just write the program to implement your rules.
Lack of self-awareness is the Achilles heel of people who write this kind of material.
But I distinctly recall the first time I saw a NeXT machine.
The Taligent/Copeland/OpenDoc debacle cost many small developers their livelihoods. Do you think $3T Apple would look back and cut some checks to the devs they "care deeplyed" with decisions like this? ["In 1981, Jobs refused to give founding stock to Apple employee number 12, Dan Kottke. Woz reportedly intervened, offering to match whatever options Jobs was willing to spare for Kottke. “OK,” Jobs replied, “I will give him zero.” --sort'a set the tone...]
Jack Grimes did a big presentation on Taligent to my employer, where I was working on next-gen OO dev tools. After seeing the Taligent demo, I immediately volunteered to be involved if we did anything with them.
I saw Taligent as an OO application framework/platform, which, if it was going to be big, maybe we could use as a target for higher-level application analysis and design tools we'd provide. And maybe we could also use it as an application framework for implementing our tools themselves.
Well-mannered OOP design (Taligent's Guide to Designing Programs) - https://news.ycombinator.com/item?id=32850209 - Sept 2022 (3 comments)
Taligent's Guide to Designing Programs - https://news.ycombinator.com/item?id=12148782 - July 2016 (2 comments)
This document doesn't convey what was unique about Taligent: it pushed one of the earliest open-doc application models, where a document could be composed of components unknown to the application because they came with all the code necessary to edit and manipulate it. It also pushed Apple's Copland team into a HAL that helped the transitions to PowerPC and Objective-C, fwiw.
Unfortunately, internet MIME types did a much better job of creating open standards, and by 1996 Java was promising to run code in browsers. NT was clearly going to survive any IBM alternatives, and MS was playing frenemy with Sun/JavaSoft to keep Solaris as a headache for IBM. It's not clear Taligent was ever intended by its funders as anything other than a bargaining chip, against MS and Copland tech leads.