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.
Given Taligent’s utter failure, not just as a business but also at delivering anything approaching useful software, only useful as a source of anti-patterns and what not to do. Anti-Pattern No. 1: process is a means to an end, not an end in itself.
Just because Taligent failed does not mean everything from Taligent is bad. Just because Google and Facebook were successful does not mean everything they did is worth emulating... such as open floorplans, continuous deployment, everyone-does-everything and other such crap.
My grandmother's advice to me on tractors, etc. was to never buy retail: get them at the auctions for the fellows who thought they could both pay dealer retail and be profitable.
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)
> Taligent’s utter failure, not just as a business but also at delivering anything approaching useful software
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.
Internationalization was certainly an important aspect of the Java language but unfortunately the first iteration of Java date and time management was a complete mess - namely while Java strings were immutual, Java date and time objects were not, making them considerably more error prone.
Totally off-topic but I really dislike the phrase "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.
The implication I have in mind is that many of those who teach are doing it because they can earn $$$ better that way than by actually practicing what they preach.
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.
I’m comfortable with lots of structure (I worked for a “classic” Japanese corporation, for many years), but I have come to understand that I’m very much in the minority.
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.
When scrum becomes all about the process and shipping things is secondary then scrum sucks. The sad part is you can add/remove most parts of scrum that you do not care about. Yet everyone seems to add everything in then never does the checkback to see if it actually did any good or just wasted everyone's time. The worst ones are the big corps that foist the whole process on groups with the hundreds of hours of 'training' and 150 page slide decks to go with it with no real reasoning as to why they are doing it.
Was it Taligent where Steve Jobs was talking about being at a trade show or demo and they wrote all this code for a half hour and didn't even have a window on the screen so he just left?
Put this in a paper bag and slam it against the wall behind a door that's usually propped open until it is dead.
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...]
I don't know about their methodology, but they had a good demo around then.
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.
This particular document is mainly about how to use C++ carefully, and much of the advice is surprisingly pertinent and still in use today.
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.
This was a wild time to be working in IT, not for what got shipped (spoiler, none of it did) but for the outlandish claims and bullshit that got tossed around trying to get other companies to stop investing in existing tech. Taligent. pink blah blah. Like they weaponised the Osborne effect against competitors.
This is accurate. NeXT was sitting right there but Taligent, Pink, and Cairo sucked all the oxygen. It’s kind of funny how NeXT won in the long run by acquiring Apple for a negative 430 million and re-skinning as macOS.
While NeXT wasn't a big commercial success, they were wise to innovate on a boring foundation (Mach/BSD, PostScript, Objective-C) while architecture astronauts working on Taligent, Cairo, and Copland were off reinventing the wheel.
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.