Jobs Hires Naroff to Rebuild Objective-C as Stepstone Tools Falter

Oral History of Steve Naroff Part 1, Session 1 — Computer History Museum

Computer History Museum

Stepstone's commercial component business collapsed because pre-packaged software libraries cannot succeed without being proven across multiple production applications, forcing NeXT to bring compiler and runtime development in-house.

AI-assisted summary of Oral History of Steve Naroff Part 1, Session 1 — original source. Check the original for full context.

Source published:

Key ideas

  • Steve Naroff transitioned from developing electronic CAD tools to systems software after seeing that languages like MAINSAIL and Objective-C solved modularity problems where traditional C fell short. (38:30)
  • At Stepstone, Naroff redesigned Objective-C from a fragile script translator with inline expansion into an integrated compiler front-end backed by a dynamic runtime and explicit interface declarations. (84:14)
  • Steve Jobs directly confronted Stepstone leadership over lagging compiler and runtime support, prompting NeXT to recruit Naroff in 1988 to lead its Objective-C and developer tool efforts. (126:22)
  • Naroff integrated Objective-C into the GNU C Compiler (GCC) and developed 'categories' to replace runtime class posing for NeXT's Interface Builder. (142:29)

Detailed notes

## Background Published by the Computer History Museum on YouTube on April 19, 2019, this video documents session one of an oral history interview with software engineer Steve Naroff conducted by Hansen Hsu on October 8, 2018. The program covers Naroff's life and engineering career, tracing his musical upbringing, his work on MAINSAIL at Cericor, his foundational overhaul of Objective-C at Stepstone, and his eventual recruitment to NeXT.

## TL;DR Steve Naroff recounts his formative years as a disciplined jazz musician and his early computing education on mainframe punch cards at SUNY Oswego before transitioning into Unix and C systems at HHB-Softron. Drawn to dynamic object-oriented programming after discovering Smalltalk, he led graphical EDA tooling in MAINSAIL at Cericor and subsequently joined Stepstone to rebuild the fragile Objective-C translator and dynamic runtime. He discusses Stepstone's flawed software component business model, Steve Jobs's confrontation with Stepstone leadership, and his own intense hiring interview with Jobs. The session culminates in Naroff joining NeXT's operating system group in 1988, where he integrated Objective-C into GCC, optimized Mach-O runtime loading, and designed language categories to power Interface Builder.

## Atmosphere & style The interview has an articulate, reflective, and candid archival tone, driven by Hansen Hsu's structured inquiries and Naroff's vivid storytelling. Naroff balances deep technical design trade-offs with unvarnished personal recollections, ranging from the intimidating pressure of a Steve Jobs interview and legal threats from Stepstone to the emotional weight of personal family loss during NeXT's launch sprint. Watching it feels like sitting down with an experienced systems craftsman who views programming as an expressive art, offering an authentic insider post-mortem on the birth of modern object-oriented computing.

## Bulletin - [38:30](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=2310s) Steve Naroff transitioned from developing electronic CAD tools to systems software after seeing that languages like MAINSAIL and Objective-C solved modularity problems where traditional C fell short. - [01:24:14](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5054s) At Stepstone, Naroff redesigned Objective-C from a fragile script translator with inline expansion into an integrated compiler front-end backed by a dynamic runtime and explicit interface declarations. - [02:06:22](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=7582s) Steve Jobs directly confronted Stepstone leadership over lagging compiler and runtime support, prompting NeXT to recruit Naroff in 1988 to lead its Objective-C and developer tool efforts. - [02:22:29](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8549s) Naroff integrated Objective-C into the GNU C Compiler (GCC) and developed 'categories' to replace runtime class posing for NeXT's Interface Builder.

## Key takeaways - [03:28](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=208s) Early musical training under his father instilling deep discipline and pattern recognition that carried directly into Naroff's perspective on programming as an art form. - [23:56](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=1436s) Undergraduate coursework at SUNY Oswego relied on batch processing punch cards with severe daily run constraints, enforcing careful desk-checking and architectural planning. - [38:30](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=2310s) Naroff's exposure to Alan Kay's 1977 Scientific American article on Smalltalk prompted his pivot toward dynamic object-oriented systems. - [52:16](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=3136s) Cericor utilized MAINSAIL for its electronic CAD software, capitalizing on its dynamic module loading, garbage collection, and metadata before Hewlett-Packard's C++ rewrite failed. - [01:08:31](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=4111s) Bell Labs rejected Naroff because Bjarne Stroustrup's C++ team only hired PhDs, leading him to accept an offer at Brad Cox and Tom Love's startup PPI. - [01:24:09](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5049s) The original Objective-C implementation was merely a fragile script-based translator without explicit interface declarations, leading to link-time and runtime failures. - [01:47:42](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=6462s) Stepstone suffered from 'elite institution cognitive disorder,' prioritizing research requests from titan clients like HP over the urgent, production-level needs of NeXT. - [01:50:02](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=6602s) Naroff formulated the 'two-application rule,' asserting that reusable object frameworks or IC-Paks cannot be designed in an ivory tower without validating them against at least two distinct production apps. - [02:06:22](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=7582s) During an on-site demonstration at NeXT's Deer Creek offices, Steve Jobs aggressively confronted Stepstone co-founder Tom Love for failing to prioritize runtime stability and developer tooling. - [02:11:24](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=7884s) Steve Jobs put Naroff through an intense, combative interview to test his stamina, bonding over the shared belief that programming is an art form comparable to music. - [02:16:08](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8168s) When Stepstone threatened Naroff with a lawsuit and a lien on his condominium upon resigning, NeXT general counsel Gary Moore intervened and quickly neutralized the dispute. - [02:22:29](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8549s) Arriving during NeXT's pre-launch 'bomb run' in 1988, Naroff integrated Objective-C directly into GCC 1.0 and worked with Kevin Enderby to optimize Mach-O linker metadata for memory-constrained hardware. - [02:26:46](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8806s) Naroff engineered Objective-C categories to eliminate brittle runtime 'poseAs:' hacks, creating a robust, language-level extension mechanism for Interface Builder.

## Detailed walkthrough ### [00:09](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=9s) Family Roots and Early Childhood

On October 8, 2018, interviewer Hansen Hsu sat down with Steve Naroff at the Center for Software History at the Computer History Museum in Mountain View, California. Naroff was born in March 1961 in Poughkeepsie, New York, where his parents were living temporarily. Soon after his birth, the family relocated to the Bronx, where Naroff spent the first six or seven years of his childhood living in an apartment located right next to the subway line—so close that the entire apartment would shake whenever a train rattled by.

Naroff's family background is Ashkenazi Jewish. On his father's side, his grandfather immigrated to the United States from Odessa, Russia (present-day Ukraine). His maternal ancestors came from the Austro-Hungarian Empire (Hungary and Austria). His mother worked primarily as a homemaker while taking on occasional administrative jobs for local companies. Naroff's father was a career jazz musician and educator who had toured with the United States Navy Band for four years during the Korean War before earning a master's degree from the Manhattan School of Music. An accomplished tenor saxophonist, conductor, and author of a widely used 1980s collegiate textbook on jazz improvisation, his father grew up under harsh circumstances on East 150th Street in Harlem. For him, music was not merely a passion: “music was a way out of the tough projects and also a way to get respect from all the people there because it was a really rough, rough place.” Even at the age of 85, he continued playing in ensembles in Florida.

- Father's background: Grew up in Harlem, Korean War Navy Band veteran, Manhattan School of Music master's degree, professional tenor saxophonist, music educator, author. - Mother's background: Homemaker and administrative assistant. - Cultural/religious upbringing: Culturally Ashkenazi Jewish; celebrated major holidays without being strictly observant. Naroff was bar mitzvahed at age thirteen at a Reform temple largely to please his more traditional grandparents. - Sibling: Sister Debbie, who later attended SUNY Oswego alongside Naroff (both met their future spouses there) and settled in Ramsey, New Jersey.

---

[03:28](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=208s) Moving to Spring Valley and Musical Discipline

Seeking better schools and a safer, more supportive working environment as an educator than the rough New York City school system could offer, Naroff's father moved the family roughly thirty miles outside New York City to the suburb of Spring Valley in Rockland County, New York. In stark contrast to the cramped Bronx apartment, the Spring Valley home sat on a spacious one-acre lot with a large swimming pool. Naroff frequently helped his father maintain the property.

Music dominated the Naroff household. His father taught public school music during the day and gave private lessons to neighborhood students at home in the evenings. Naroff's own musical education began early under his father's strict tutelage:

> “Because a clarinet was put in my mouth at the age of six, and my father was, you know, somewhat of a disciplinarian when it came to music and education, most of it centered around music.”

Naroff focused intensively on classical clarinet, undergoing annual adjudicated evaluations through the New York State School Music Association (NYSSMA). By the ninth grade, he had mastered the Mozart Clarinet Concerto, one of the most demanding solo works in the clarinet repertoire. However, between ninth and tenth grade, Naroff realized that the rigid constraints of the classical world did not suit his temperament: “classical music wasn't really my calling. It was very highly structured, and it didn't provide that much freedom that I was looking for.” He switched over to the tenor saxophone, gravitating toward jazz improvisation, which became his primary musical outlet through his college years.

- Childhood pastimes: Music was central, though he also played baseball as a pitcher. - Reading habits: Read primarily school-assigned texts, humor magazines (*Mad Magazine*, *National Lampoon*), and visual sci-fi television (*Star Trek*, *The Twilight Zone*) rather than novels.

---

[10:04](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=604s) High School Years and the Teacher's Son Dynamic

Naroff attended junior high and high school in Spring Valley, where the public school system was well-funded, highly rated, and ethnically diverse, with a notable African American student population. He described himself as a conscientious, meticulous student and note-taker—a trait that stayed with him into his college compiler courses—though he was never aggressively competitive about grades or standardized tests. Although he performed well in mathematics, the subject was taught in an abstract manner that initially failed to inspire him, leaving him unable to see its practical applications. Nevertheless, he suspected that the underlying patterns of his deep musical training helped him instinctively grasp mathematical concepts.

Attending the school where his father served as music teacher, orchestra conductor, and band director created a complicated social dynamic. His father was an uncompromising disciplinarian on the podium who demanded strict order from the students:

> “Kids didn't understand discipline as much—I mean, some kids did. So I always felt like kids, you know, if they got yelled at in orchestra, after orchestra they'd look at me like, ‘Man, your dad's, you know, grumpy.’”

His father's presence also meant that any minor misstep on Naroff's part was promptly reported by fellow teachers, leading to unpleasant post-school confrontations at home. Despite the occasional awkwardness, Naroff was a straightforward, well-behaved student who largely avoided trouble, laying a focused foundation for his eventual transition to university.

[13:46](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=826s) Early Influences: Jazz Heroes and Intellectual Mentors

When asked about early teachers, heroes, or mentors, Steve Naroff explains that his primary figures of reverence were not academics, but professional jazz musicians whom he watched perform live in Greenwich Village clubs. He singles out saxophonists like Sonny Rollins and Michael Brecker as figures he deeply admired, largely because seeing them up close illuminated the immense gulf between raw talent and true mastery. Naroff saw himself as musical and naturally gifted, but he recognized that he lacked the grueling discipline that propelled those artists to stardom.

> “I was a talented musician, but I didn't have the dexterity or the work ethic that some of these other people that attained stardom do, you know, most of them work five, six hours a day on their instrument and I had natural talent and I might play one or two hours a day and I understood the difficulty in getting to the to where they were and making it look as easy as they made it look, so I had a lot of respect for musicians.”

On the academic and computing side, Naroff graduated from high school in 1979, an era when personal computers were barely emerging and the industry luminaries of later decades were not yet cultural icons. In that pre-PC period, computers mostly meant mainframes, and Steve Jobs had not yet become a household name to revere. Later, while in college, Naroff found remote intellectual mentors through the literature; he points specifically to Alan Kay, noting:

> “In college, I felt Alan Kay was a mentor just from reading what he was writing.”

[15:47](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=947s) Deciding on College: SUNY Oswego and the Rarity of Undergraduate CS

Naroff’s first real exposure to computing came upon entering college. Finishing high school, his initial impulse was to pursue music full-time as a career. His father, an experienced touring musician who understood the hardships of making a living in the performing arts, intervened with practical advice. He supported Steve's music but counseled him to keep it as a minor while choosing a pragmatic major. The two discussed computer science, which was an unusual choice at the time because dedicated undergraduate curricula were exceedingly rare across the country.

Naroff discovered through his own historical research that SUNY Oswego’s computer science program was established early, in 1970, after Danish mathematician Ooblaer Van Dijk drafted a proposal in 1968. Within the approximately 60 campuses of the State University of New York system, only Oswego and SUNY Potsdam offered Bachelor of Arts degrees in computer science at that time, while major flagship centers like Stony Brook, Albany, and Binghamton did not yet have undergraduate programs. By comparison, Stanford University did not establish an undergraduate CS curriculum until 1986, relying solely on graduate programs until then.

Family finances and conservative financial values led Naroff to narrow his search strictly to in-state public universities within the SUNY system: - SUNY Oswego tuition and fees at the time ran roughly $6,000 per year, compared to roughly $27,000 in modern costs when factoring in mandatory room and board. - Naroff graduated with only a modest $3,000 student loan, which he was able to repay quickly. - Unlike SUNY Potsdam, which balked at students dividing their attention with a demanding arts minor, Oswego actively welcomed Naroff to major in computer science while playing clarinet and saxophone in both the college orchestra and jazz band. - Oswego’s campus sat right along the shore of Lake Ontario, which offered scenic views in the summer, though winters brought lake-effect winds so ferocious that students under a certain weight were cautioned against walking near the water for fear of being blown in.

[21:08](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=1268s) Mentors at Oswego: Craig Graci and Doug Lea

At Oswego, Naroff’s academic trajectory was shaped by two influential faculty members: Craig Graci and Doug Lea. Graci held a master's degree in mathematics and had transitioned to teaching computer science in 1978, just one year before Naroff enrolled. Because Graci was actively mastering compilers and operating systems alongside his students, his teaching carried an infectious enthusiasm. Graci shared Naroff’s love for music, forming an immediate personal kinship and providing the individual encouragement Naroff needed to tackle the rigorous coursework.

Around 1980, Doug Lea joined the Oswego faculty. Lea would go on to become a widely known author and authority on C++ and Java concurrency. Both Graci and Lea were devoted scholars who dedicated their lives to university teaching and felt no pull to enter the commercial software industry. Later, after entering the corporate world, Naroff called Graci to pitch the exciting opportunities available in industry and ask if he wanted to leave academia, but Graci declined without hesitation. Graci later became the director of cognitive studies at Oswego. Naroff preserved his college compiler project as an enduring point of personal pride:

> “I brought, when I left Oswego, even though we did all our work and punch cards, I printed my compiler and still have it to this day and it's it's something I'm really proud of, it was done in Pascal.”

[23:56](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=1436s) The Punch Card Era: Compilers, Batch Processing, and Structured Thinking

Naroff’s early coursework was completed under strict batch-processing constraints on mainframe hardware. Programming required punching code onto cards, assembling card decks, and waiting for batch runs with minimal machine access.

```mermaid flowchart LR accTitle: Mainframe Batch Submission Workflow accDescr: The step-by-step developer cycle from manual flowcharting to running punch cards on the IBM 1130 and Burroughs mainframes.

subgraph Design ["Program Design"] A["Flowcharting & Manual Analysis"] B["Card Punching (Decks)"] end

subgraph Execution ["Mainframe Batch Run"] C["IBM 1130 / Burroughs 5600"] D["Limited Runs (3 Per Day)"] end

A --> B B --> C C --> D D -->|"Syntax or Logic Error"| A ```

Naroff’s curriculum progressed through a series of mainframe environments and languages: - **First Course (IBM 1130):** Naroff wrote his earliest programs in Fortran, running on an IBM 1130 mainframe doing elementary operations like basic sort algorithms. - **Simulation Course:** In his second year, he programmed in GPSS (General Purpose Simulation System), studying statistical queueing theory through classic simulations such as modeling wait times in a barbershop. - **Core Systems Courses (Pascal):** Most upper-level classes, including his compiler and assembler work, were written in Pascal. Programs often spanned multiple thick card decks containing thousands of lines of code. - **Time-Sharing:** Oswego later added a Burroughs 5600 system, introducing Naroff to time-sharing alongside traditional punch card workflows.

Because students were restricted to only three batch runs a day, careless trial-and-error debugging was impossible. Students were forced to draft thorough flowcharts and analyze logic errors exhaustively on paper before submitting jobs. Naroff reflects on the difference between that era and modern software development:

> “Even though interactive development environments like the ones we ended up developing and Apple and NeXT and so on are wonderful, there's also something wonderful about thinking about your problem that much and having that level of respect for the computer, right, and it it took a lot of discipline to get a compiler, a big piece of code thousands of lines, to work, you know, under that constraint.”

When asked whether he encountered object-oriented programming during college, Naroff clarifies that he did not. The closest brush occurred when he asked Graci whether Oswego would offer a course covering Simula. Graci responded, “No, not yet,” although the department held respect for the Simula research emerging from Europe. Computer science education in that era focused almost entirely on structured programming, eliminating `goto` statements, and exploring modularity in procedural code rather than object-oriented paradigms.

[27:36](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=1656s) Programming as Art and Crafting Order

Steve Naroff reflects on the discipline required when writing software in an era preceding object-oriented adoption. Objects were not yet part of mainstream industry methodology, leaving developers to rely strictly on structured and modular programming. Naroff treated the programs he wrote as works of art, obsessing over details as specific as indentation. While code was rarely viewed on-screen due to the batch-submission model of computing, physical printouts had to be read, making visual clarity essential for navigating complex codebases.

Careful indentation and avoiding unwieldy routines served a pragmatic purpose: without strict complexity management, it was impossible to write a large program that could successfully run within an allotment of only three executions per day. Naroff argues that his aesthetic focus was not merely decorative, noting: “I can't sit here and actually say the art that I was doing the art for art's sake it was more side effective how do you really make something this a puzzle that's this complex work under these constraints.” That intense rigor, he believes, is absent from modern software engineering, fostering habits of sloppy work and loose programming.

[29:08](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=1748s) The IBM Franklin Lakes Internship

Prior to his junior year of college, Naroff worked odd jobs, including cooking at Nathan’s Famous hot dog restaurant in New York. Around 1982, his junior year, he applied for and secured an internship at IBM in Franklin Lakes, New Jersey, working as a computer operator. The position primarily consisted of babysitting massive, high-speed laser printers, keeping them continuously stocked with paper and data. Naroff describes watching the paper move through these machines at speeds where individual sheets were impossible to see.

The facility in Franklin Lakes happened to be directly across the street from the company where he would later accept his first post-graduate job. Naroff recalls being paid roughly $14 an hour—a generous rate for a student in the early 1980s. While he admits he did not learn a great deal about software engineering from the position, the internship offered firsthand exposure to the sheer scale of early corporate computing infrastructure.

[31:17](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=1877s) Entering the Job Market and General Dynamics

After graduating in 1983, Naroff faced the pre-internet job market without platforms like LinkedIn. He followed two distinct leads. The first came unexpectedly from General Dynamics, who reached out to invite him for an interview in Pomona, California. Having never flown on an airplane before, the trip alone was a stressful and novel experience.

Upon arriving at the facility, Naroff was handed promotional brochures detailing the projects he would be assigned to: writing FORTRAN code for missile guidance systems. The realization brought immediate culture shock. Having no desire to build weapons of war, Naroff disengaged mentally, though he completed the interview for the sake of the experience.

[33:10](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=1990s) First Job at Henckels, Haas & Brown (HHB-Softron)

The opportunity that led to Naroff’s first professional software job arose through personal networking. His mother mentioned that a friend from their neighborhood, Rosalie, worked at a local firm called Henckels, Haas & Brown (later renamed HHB-Softron), situated only ten miles from where he grew up and within two or three miles of the IBM site. Founded by three MIT graduates—Lutz Henckels, René Haas, and Kenneth Brown—the company was a pioneer in circuit simulation and digital test software, marketing a suite known as CADAT (Computer-Aided Design and Test).

To maintain and extend their software base, the founders recruited an entry-level cohort of five to ten recent graduates from institutions such as MIT, Columbia, and Carnegie Mellon. Operating in a mixed UNIX and VAX/VMS environment, Naroff’s first major responsibility centered on CADAT's binary circuit description files, which compiled from a proprietary text language into binary structures that lacked adequate inspection and analysis tooling. Later, when Berkeley sockets emerged in UNIX, Naroff built software to distribute simulation passes across networked machines—an innovative technique at the time for accelerating compute-heavy test runs.

```mermaid flowchart LR accTitle: Distributed Circuit Simulation in CADAT accDescr: Diagram showing how a circuit description text file compiles to a binary format, then distributes across networked UNIX machines via Berkeley sockets. subgraph Compilation["Compilation Stage"] A["Circuit Description Text File"] --> B["CADAT Compiler"] B --> C["Binary Circuit File"] end subgraph Distribution["Distributed Simulation"] C --> D["Analysis & Dispatcher Tool"] D -->|"Berkeley Sockets"| E["Remote UNIX Node 1"] D -->|"Berkeley Sockets"| F["Remote UNIX Node 2"] end ```

- **Founders:** Lutz Henckels, René Haas, Kenneth Brown (MIT graduates). - **Core Product:** CADAT (Computer-Aided Design and Test), addressing circuit and test simulation. - **Operating Environments:** UNIX and DEC VAX/VMS. - **Key Contributions:** Binary circuit analysis utilities and network-distributed simulation passes using newly introduced BSD sockets.

[36:18](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=2178s) Transitioning from Pascal to UNIX and C

HHB-Softron served as Naroff’s formal baptism into UNIX and the C programming language. Coming from an academic background rooted in Pascal, which strictly enforced type safety and bounds checking, Naroff found C to be terse and error-prone. The bootstrapping process demanded mastering a broad surface area of command-line tools, including Make and the C shell (`csh`), which took three to six months before he felt comfortable.

While Naroff appreciated the power of the platform, he began questioning whether C was the appropriate foundation for building large-scale application software. Because C had been created specifically to implement the UNIX operating system, it lacked high-level safety mechanisms and made reasoning about large, modular simulation problems unnecessarily brittle. Naroff realized: “fundamentally it was developed to aid operating system development in this case UNIX they were sort of developed side by side and for what we were doing building large simulation tools it wasn't a real natural fit.”

[38:30](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=2310s) Discovering Smalltalk and the Move to Cericor

During his two-year tenure at HHB-Softron, Naroff encountered Alan Kay’s 1977 *Scientific American* article, “Microelectronics and the Personal Computer.” The paper presented the concepts of Smalltalk, object-oriented dynamic systems, and the Dynabook tablet concept. The vision transformed Naroff’s perspective on software architecture, driving him to advocate for object-oriented methodologies within HHB.

The management at HHB-Softron was candid with Naroff: while they acknowledged the value of modern language abstractions, re-architecting an established commercial codebase was a financial and operational impossibility for their business. Understanding his desire to pursue dynamic, higher-level architectures, they gave him their blessing to seek employment elsewhere.

Through an industry headhunter, Naroff connected with Cericor, an emerging CAD startup based in Salt Lake City, Utah. Cericor stood apart from competitors like HHB: instead of defining electronic circuits through batch-compiled, textual netlists, Cericor allowed engineers to visually compose circuits on graphical workstation displays. Founded by researchers rooted in the Evans & Sutherland and University of Utah graphics ecosystems, Cericor presented Naroff with an environment directly aligned with modern object-oriented and graphical paradigms.

[41:25](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=2485s) Moving to Salt Lake City and Meeting Nancy Allen

Leaving New York for Salt Lake City was a genuine culture shock for Steve Naroff, as Utah was about the furthest thing imaginable from where he envisioned living. Before making the leap, he talked to his future wife, Nancy Allen, proposing that they get married first and then relocate together to Utah for Cericor.

Naroff had met Nancy at SUNY Oswego, where she was a violinist in the college orchestra and he performed his "greatest hit," a solo on the Mozart Clarinet Concerto. They grew close through the orchestra and a shared music theory class. Nancy graduated two years ahead of him and took a job at CBS Records in New York City, working out of the "Black Rock" headquarters. In her role interfacing between the legal department and classical recording artists, she brought home stacks of free albums and obtained tickets to major concerts, including Earth, Wind & Fire at Madison Square Garden. Naroff recalls crossing paths with young up-and-coming talents like Harry Connick Jr. and violinist Cho-Liang Lin (whom they ran into again years later when Naroff's own son was performing).

While Nancy supported the initial move to Salt Lake City, she experienced serious reservations once they arrived. Coming from an exciting professional life in Manhattan, she struggled with the local climate:

> “I think once we got there she had more reservations because at that point in time in that heavily Mormon culture females were very much second-class citizens and we were still young and she had a hard time going from a great gig in New York to finding a great gig in Salt Lake.”

The environment was sharply distinct from their New York roots, where women had far more professional parity and independence.

---

[44:40](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=2680s) Background, Politics, and Discovering Alan Kay

Naroff describes his personal and family background as deeply liberal, working-class, and Democratic. His paternal grandfather had been a New York cab driver who also started the city's first dog-walking business before dying young from smoking. Growing up around people who had very little instilled in him a lifelong empathy for the less fortunate and a belief in paying taxes to support public safety nets:

> “I know that I'm standing on the shoulders of great people and we'll talk about some of those later but I also know that the time that I was born and the time I entered the computer science business was opportune you know.”

When asked by Hansen Hsu how he first encountered Alan Kay's work—specifically Kay's seminal September 1977 *Scientific American* article, “Microelectronics and the Personal Computer”—Naroff noted that in the pre-internet era, discoveries happened organically through workplace discussions and technical print media. Colleagues at HHB-Softron frequently traded clippings and debated industry trends. He likely followed up on articles and names cited in publications like *Byte* magazine's famous August 1981 Smalltalk issue, tracking down other writings by the pioneers of personal computing. Naroff also noted that, as he was reminded when preparing for the interview, Alan Kay was an alumnus of the University of Utah, cementing the school's historical weight in computer science and interactive graphics.

---

[48:26](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=2906s) The Culture at Cericor and Becoming a Team Lead

Naroff's interview at Cericor in Salt Lake City went well, though it featured a culturally unusual pitch from the manager to whom he would report. The manager, an open member of the LDS Church, explained that Cericor was drawn not only to Naroff's programming talent and enthusiasm for the MAINSAIL language, but specifically to his background:

> “He said something very unusual he said you know one of the reasons were we're interested in you is your leadership skills that are not only sort of something we believe you have but sort of a cultural thing it's like you're from New York you know there's something about being a Jew from New York that they were attracted to there's this whole weird Zionist thing that goes on in the Mormon thing...”

The hiring manager told Naroff outright that many of the local Mormon engineers were content to be steady "worker bees" and actively wanted someone who would take charge. Leading this team turned out to be the smoothest managerial experience of Naroff's entire career. Unlike Silicon Valley workplaces where managing engineers felt like "herding cats" because everyone wanted to set direction, the Cericor team was receptive, collaborative, and maintained high morale. Naroff functioned as a team lead: coordinating design, managing schedules, delegating tasks, and writing substantial amounts of code himself.

Although he later misremembered his time at Cericor as lasting two or three years, historical records revealed he was only there for about a year and a half. Just five to six months after he arrived, Hewlett-Packard stepped in and acquired Cericor, after which Naroff agreed to stay for another year under HP management.

---

[52:16](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=3136s) Technical Innovations of MAINSAIL

Cericor's CAD software was written in MAINSAIL (Machine Independent Stanford Artificial Intelligence Language), a programming environment that left a lasting impression on Naroff. MAINSAIL had evolved out of the SAIL language created at the Stanford Artificial Intelligence Laboratory (SAIL) and had received initial backing from the Stanford University Department of Genetics/Biology, which required a high-level system for developing large, complex software without wrestling with C. That investment directly benefited the computer-aided engineering and CAD/CAM industries, which were floundering under the limitations of standard C in an era before C++ had matured.

MAINSAIL was not purely object-oriented in the Smalltalk sense; rather, it was modular and object-based, drawing architectural lineage from Simula, Modula, and ALGOL. Its defining strength lay in solving the logistical headaches of large-scale software engineering:

```mermaid flowchart TD accTitle: MAINSAIL Architecture and Module System accDescr: Diagram illustrating how MAINSAIL bypassed traditional static link steps using dynamic module loading, metadata, and memory safety tracking.

subgraph Compiler ["Compilation & Introspection"] M["MAINSAIL Source Module"] Meta["Embedded Metadata"] Tag{"Safety Tag"} M --> Meta M --> Tag end

subgraph Runtime ["Dynamic Runtime Environment"] DL["Dynamic Module Loader\n(No Static Link Step)"] GC["Garbage Collector\n(Inspects Self-Describing Metadata)"] Safe["Safe Execution / High-Level Logic"] Unsafe["Unsafe Execution / Direct Memory Pointers"] end

M --> DL DL -->|"Loads on Demand"| Runtime Meta --> GC Tag -->|"Safe Module"| Safe Tag -->|"Unsafe Module"| Unsafe ```

- **Dynamic Module Loading:** MAINSAIL eliminated the traditional static compile-and-link cycle common to C. Instead, the runtime loaded modules dynamically as execution required them. - **Self-Describing Metadata:** Every compiled module retained metadata describing its internal structures, which powered automated runtime facilities such as built-in garbage collection. - **Pragmatic Memory Safety:** Unlike rigid garbage-collected languages, MAINSAIL permitted low-level bit twiddling and raw memory pointers when required. The compiler categorized each module as either "safe" or "unsafe," encouraging developers to isolate low-level operations from core business logic. - **First-Class Concurrency:** The language featured a native co-routine mechanism conceptually similar to blocks and closures in modern programming languages.

[54:49](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=3289s) Stanford, Xidak, and the Genesis of MAINSAIL

Tracing the lineage of MAINSAIL, Steve Naroff explains how the language arose out of the Stanford Artificial Intelligence Laboratory (SAIL) and Stanford's biology department. The biology department hired the principals at Xidak, a spin-off company founded to build a machine-independent version of SAIL. In the early 1980s, the computing landscape was fractured by an explosion of diverse workstation platforms. Apollo Computer, a major player based in the Boston area with its proprietary Aegis operating system, dominated early on alongside emerging players like Sun Microsystems. As Unix gained unstoppable momentum, even proprietary platforms like Aegis were forced to provide Unix emulation layers. Software developers desperately needed abstraction layers so they could write a single codebase and run it anywhere across competing hardware architectures. Naroff marvels at the historical geography, noting that Xidak was located on Deer Creek Road in Palo Alto, almost next door to where NeXT would later set up its campus.

```mermaid flowchart TD accTitle: Evolution and Motivation of MAINSAIL accDescr: Diagram tracing the development of MAINSAIL from Stanford SAIL to portable commercial CAD applications. subgraph Stanford["Stanford Origins"] SAIL["Stanford AI Lab (SAIL)"] Bio["Biology Department Funding"] end subgraph XidakCo["Xidak Commercialization"] Xidak["Xidak (Deer Creek, Palo Alto)"] Mainsail["MAINSAIL Language\n- Machine-independent\n- Dynamic runtime & GC\n- Portable across Apollo Aegis, Sun Unix"] end subgraph Industry["CAD Adopters"] Cericor["Cericor\n(Schematic capture & simulation)"] end

SAIL --> Bio Bio --> Xidak Xidak --> Mainsail Mainsail --> Cericor ```

MAINSAIL fulfilled its stated mission of facilitating large, highly portable systems with remarkable effectiveness, even though it never captured mainstream adoption. For a young computer-aided design (CAD) startup like Cericor, the decision came down to a stark binary: write the system in plain C or embrace MAINSAIL. At the time, Smalltalk and other dynamic, garbage-collected languages were confined largely to research labs and deemed impractical for commercial software products. Meanwhile, C++ was still in its infancy in the early 1980s, existing merely as a C preprocessor (Cfront) without native compilers or production-ready runtime stability. Xidak offered Cericor personal engineering attention and a pragmatic runtime environment, leading Cericor to build its entire suite on top of MAINSAIL.

- SAIL was originally machine-dependent; the Stanford biology department funded Xidak to create a machine-independent, portable successor. - Apollo Computer initially led the workstation market with Aegis before Unix homogenization forced Aegis to adopt Unix emulation. - Cericor chose MAINSAIL over C and early C++ because MAINSAIL offered dynamic runtime features and automatic memory management in a production-oriented tool.

---

[58:21](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=3501s) Hewlett-Packard's C++ Port and the Pitfalls of Language Startups

After Hewlett-Packard acquired Cericor, HP management grew deeply uneasy about depending on a proprietary programming language controlled by a tiny vendor like Xidak. Rather than purchasing and funding Xidak directly, HP executives mandated a complete rewrite to migrate Cericor's vast MAINSAIL codebase to C++. Naroff saw this as an engineering catastrophe in the making. Migrating an application designed from its inception around automatic garbage collection to a language lacking garbage collection was an outright showstopper, compounded by C++'s inability to dynamically link and load modules on the fly. As Naroff bitterly reflects on the outcome:

> “And they started this five year long effort to convert the MAINSAIL code to C++, and I knew from the very beginning that this was not looking like a smart thing for them to do, and five years later they canned it.”

Naroff laments the five years of squandered engineering talent, describing it as a classic case of top-down corporate mismanagement where executives ignored warnings from engineers on the ground. Reflecting on the fate of language companies, Naroff notes that Xidak eventually folded despite having brilliant compiler, runtime, and linker architects. Rivals like Mentor Graphics, the established titan in electronic design automation, deeply respected what Cericor had achieved with MAINSAIL, recognizing how daring the architecture was. However, Mentor had built its systems in standard C, making their eventual shift to C++ straightforward. Xidak succumbed to the harsh commercial realities of developer tools, a structural trap echoed in Brad Cox's experiences with Stepstone: developing brilliant compiler technology is rarely sufficient to build a sustainable, standalone business.

- HP spent five years attempting to rewrite Cericor’s MAINSAIL codebase into C++ before canceling the project entirely. - Key technical roadblocks in moving to C++ included the loss of automatic garbage collection and dynamic runtime module loading. - Mentor Graphics acknowledged Cericor’s technical bravery with MAINSAIL while choosing the safer, incremental path of evolving from C to C++.

---

[01:01:46](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=3706s) Inside Cericor's EDA Tools: Simulation, Journaling, and Metadata

Naroff describes Cericor's flagship software as an advanced graphical schematic capture and logic simulation environment. Users placed logic gates—such as NAND gates—onto a graphical canvas, wired them together, and organized them into hierarchical modular components. The system allowed designers to run interactive digital circuit simulations, displaying logic levels as animated streams of zeros and ones traveling visibly through the drawn wires on the screen. While visually impressive and cutting-edge for mid-1980s workstations, it remained an open question whether the tool could scale to the astronomical gate counts required by semiconductor giants like Intel, who relied heavily on proprietary, in-house verification toolchains.

```mermaid flowchart LR accTitle: Cericor Software Architecture and Naroff's Infrastructure accDescr: Block diagram illustrating the user-facing EDA tool and Naroff's underlying software infrastructure layers. subgraph Application["Cericor Schematic Capture & Simulator"] Canvas["Interactive GUI Canvas\n(NAND gates, wiring, 0/1 signal flow)"] Sim["Logic Simulator"] end subgraph Infrastructure["Naroff's Infrastructure Layer"] Journaling["Input Journaling Engine\n(Capture/playback of mouse & menu events)"] CDL["Cericor Development Language (CDL)\n(Object-oriented metadata UI framework)"] end subgraph Runtime["Base Platform"] MS["MAINSAIL Language & Dynamic Runtime"] end

Application --> Infrastructure Infrastructure --> Runtime ```

Within Cericor, Naroff led the infrastructure engineering team and spearheaded several critical internal systems. Because manual regression testing for interactive graphical applications was notoriously difficult, Naroff developed an automated input-capture subsystem called "journaling," which recorded exact mouse movements and menu actions to reproduce user sessions deterministically during regression test suites. Furthermore, because base MAINSAIL had limited object-oriented mechanisms, Naroff helped design and evolve the Cericor Development Language (CDL)—a proprietary, metadata-driven object framework that allowed engineers to define complex user interfaces declaratively instead of writing raw, low-level MAINSAIL code. Naroff served as the technical steward and educator for this internal architecture, ensuring structural integrity across the growing engineering organization as HP brought in more developers.

- The Cericor CAD tool provided real-time visual feedback, animating binary 0 and 1 logic states flowing across schematic connections. - Naroff implemented "journaling" to capture and replay user mouse and menu interactions for automated regression testing. - CDL (Cericor Development Language) provided an internal object-oriented metadata layer to build UI components without hard-coding raw MAINSAIL.

---

[01:06:25](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=3985s) Leaving CAD Behind: The Road to the First OOPSLA

Although HP sought to promote Naroff into formal management, he recognized that the post-acquisition environment was fundamentally misguided. Within six months of the takeover, he traveled to Oregon to interview with Mentor Graphics, the undisputed market heavyweight in electronic design automation. Mentor made him a lucrative job offer, but Naroff paused to reassess his career trajectory. He concluded that he no longer wanted to spend his life developing software tools for hardware engineers; instead, he wanted to dedicate his career to crafting software tools for software engineers. Describing this pivot in career focus, Naroff recalls:

> “At that time I actually made the decision that I wanted to get out of the software tools for hardware people and into software tools for software people, because I was a software person.”

Naroff declined Mentor's offer and chose to remain at Cericor for another year, helping his colleagues navigate the HP transition while continuing to master dynamic runtimes and systems architecture. That patient decision bore fruit in the autumn of 1986, when the very first ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA '86) took place in Portland, Oregon. Attending the inaugural conference, Naroff found himself at the epicenter of the emerging object-oriented computing movement. Prepared by his hands-on experience with dynamic runtimes and metadata systems, he crossed paths with Brad Cox and Tom Love of Productivity Products International (PPI)—a meeting that would draw him straight into the development of Objective-C.

- Mentor Graphics made Naroff an offer six months after the HP buyout, but he chose to stay patient rather than immediately jump to another CAD firm. - The experience solidified Naroff's core vocational desire: moving away from EDA tools to focus exclusively on programming languages and developer tools. - At the inaugural OOPSLA conference in Portland in 1986, Naroff met Brad Cox and Tom Love, setting the stage for his move to PPI/Stepstone.

[01:08:31](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=4111s) Rejection from Bell Labs and Joining PPI in Sandy Hook

After meeting Brad Cox and Tom Love at the first OOPSLA conference, Steve Naroff arranged an interview in Sandy Hook, Connecticut, with their startup, PPI (Productivity Products International). Prior to committing to PPI and Objective-C, however, Naroff had set his sights on AT&T Bell Labs. Bjarne Stroustrup’s research group was doing compelling work on C++ in New Jersey, near Princeton, which appealed strongly to Naroff because it was close to where he had grown up. That ambition ended abruptly when either a headhunter or Bell Labs directly informed him that they only considered candidates with doctorates. It was Naroff's first real career rejection after a string of early successes, and while it stung at the time, he later considered it providential: “If I would have—if they would have accepted me, life would have been a lot different, I'm convinced.”

Naroff interviewed with PPI, received an offer, and relocated to Connecticut. Sandy Hook provided a scenic, rural setting, brought him back within easy driving distance of his parents, and offered relief from the culture shock he and his wife had experienced in Salt Lake City. His wife found employment locally at a physics laboratory, and the couple purchased their first home—a condominium—during an era when mortgage interest rates hovered at an astronomical 14 percent. The move formally marked Naroff’s transition into building developer tools designed specifically for software engineers.

- **AT&T Bell Labs rejection**: Disqualified immediately for lacking a Ph.D. (“Bell Labs: only Ph.D.s need apply”). - **Location benefits**: Sandy Hook, Connecticut offered a beautiful physical setting and proximity to family on the East Coast. - **Economic conditions**: Bought their first condominium when prevailing interest rates were around 14 percent.

---

[01:12:16](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=4336s) First Impressions of Brad Cox and Tom Love

Naroff’s initial impression of Brad Cox was formed watching him speak on an OOPSLA panel, where Cox appeared poised, articulate, and thoroughly professional. Rather than drilling into the technical minutiae of the Objective-C language, Cox focused on evangelizing an object-oriented revolution, a perspective detailed in his influential book, *Object-Oriented Programming: An Evolutionary Approach*. While Naroff respected Cox’s ability to sell the vision using metaphors of the Industrial Revolution and modular integrated circuits, he found the book slanted more toward marketing than rigorous engineering. Tom Love, by contrast, served as the charismatic business counterpart who pitched executives and corporate partners. Naroff and Love ended up living in the same condominium complex, developing a close personal bond that led Naroff to view Love as an important mentor.

Both founders combined grand ambitions with what appeared to be pragmatic execution. Having watched MAINSAIL’s radical, proprietary runtime approach fail commercially during his tenure at Cericor and Hewlett-Packard, Naroff believed an evolutionary step forward for the ubiquitous C language was the only viable path to mainstream adoption. He wanted an agile, practical environment over academic research: “I really wanted to work for a company that wasn't too ivory tower, but wanted to work for a company that was lean and mean and trying to do stuff for real people and real projects.” Despite those expectations, the internal reality of working at PPI would prove far more complicated than the impression he had gathered from the outside.

```mermaid flowchart TD accTitle: PPI Founders and Steve Naroff Dynamic accDescr: Diagram showing the roles of Brad Cox, Tom Love, and Steve Naroff at PPI. subgraph Leadership["PPI / Stepstone Leadership"] BC["Brad Cox<br/>(Visionary, ICpaks, Blocks)"] TL["Tom Love<br/>(Outbound Deals & Mentorship)"] end subgraph Engineering["Language Development"] SN["Steve Naroff<br/>(Objective-C Evolution & Runtime)"] end TL -.->|"Mentor & neighbor"| SN BC -->|"Delegated Objective-C language"| SN ```

- **Brad Cox**: Focused on conceptual messaging, the software components revolution, and writing *Object-Oriented Programming: An Evolutionary Approach*. - **Tom Love**: Charismatic dealmaker who secured key enterprise accounts, including HP Labs. - **Strategic appeal**: Evolutionary extension of C rather than a disruptive, clean-slate language like MAINSAIL.

---

[01:16:19](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=4579s) Venture Capital, Leadership Voids, and the Reality of Stepstone

PPI was later rechristened Stepstone, a rebranding that coincided with the arrival of venture capital investors. That institutional funding triggered internal turmoil, culminating in the departure of Tom Love. Naroff perceived Love as having been pushed out by the venture capitalists—whether through direct termination or by placing him in an untenable operational position—an outcome that deeply affected Naroff because Love had been his primary mentor at the firm. Even prior to his exit, Love spent minimal time in the Sandy Hook office because he was constantly on the road closing partnership deals.

With Love traveling and Cox retreating to explore standalone initiatives such as ICpaks and early iterations of blocks, a severe management vacuum emerged inside Stepstone’s small software group of roughly 8 to 12 developers. Engineering management changed hands early on when the manager who had signed Naroff’s offer letter departed, replaced by Ken Hammer-Hodges, a former ITT colleague of the founders who did not actively guide the product’s technical roadmap. Instead of a unified team, individual engineers pursued fragmented projects—one developer handled the interpreter, several worked on ICpaks, and Naroff found himself working largely on his own to shepherd the core Objective-C language compiler and runtime: “It was probably the least managed company of the three companies I had worked with to date.”

- **Venture capital entry**: Precipitated the company's name change from PPI to Stepstone and the eventual exit of co-founder Tom Love. - **Team size**: The engineering team comprised approximately 8 to 12 developers, supplemented occasionally by temporary contractors. - **Engineering leadership**: Ken Hammer-Hodges, an ITT alumnus, was brought in to oversee software, but provided little day-to-day technical direction. - **Fragmented efforts**: Brad Cox handed off language maintenance to Naroff while shifting his attention to ICpaks libraries and experimental language constructs like blocks.

[01:21:54](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=4914s) The Disconnect at Stepstone and the "Sweeping the Floors" Porting Effort

At PPI (later Stepstone), Brad Cox was working on adding blocks as a library component without direct language support, but that effort was completely uncoordinated with the actual development team. Naroff recalls that Cox operated behind closed doors: “It was really distinct: it’s almost like he was the research wing, him alone, and everyone else was development.” While having a dedicated researcher is not inherently bad, it created an organizational void where engineers normally looked to the visionary founder for product direction. Instead, the first and second prototype iterations of Objective-C were riddled with defects, giving Naroff more than enough problems to tackle on his own. He decided to simply put his head down and get to work.

During his first six months, Naroff was assigned to port the software to a multitude of hardware and operating system architectures. He quickly discovered that there was no documentation whatsoever explaining how the system was designed. To create a baseline for future engineering decisions, Naroff wrote comprehensive architectural and implementation documentation. In doing so, he realized that fundamental parts of the existing implementation were severely flawed. After having led sophisticated object-oriented architecture work in MAINSAIL at Cericor, spending his days porting an unpolished preprocessor to obscure platforms felt distinctly unglamorous: “It did feel a little bit like sweeping the floors, like I wasn't moving in a totally upward direction, but it didn't really matter to me because I believed that there was so much opportunity.”

[01:24:09](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5049s) The Prototype Translator and the Lack of Interface Declarations

When Hansen Hsu asks about the state of the language and whether it could even be considered a real compiler when Naroff arrived, Naroff clarifies that calling it a compiler was generous at best. It was essentially a loose collection of scripts designed to identify Objective-C syntax, expand those constructs in-line into C code, and pass the surrounding C code through completely untouched. The resulting output was then handed off to a host platform's standard C compiler.

```mermaid flowchart LR accTitle: Early Objective-C Translation Pipeline accDescr: Diagram showing the naive script translation of Objective-C constructs to C source before hitting the native C compiler. subgraph Frontend["Naive Preprocessor Phase"] A["Source Code (.m)"] --> B["Script Translator"] B -->|"Leaves raw C code untouched"| C["Intermediate C Code"] B -->|"Expands Obj-C message sends inline"| C end subgraph Backend["Native Toolchain Phase"] C --> D["Host Platform C Compiler"] D --> E["Machine Object Files (.o)"] E --> F["Unix Linker (ld)"] end ```

Because it was only a naive translator rather than a full semantic parser, it could not catch even routine programming mistakes: - The language lacked any syntax or construct for explicit interface declarations (`@interface`). - If an engineer mistyped a method or selector name inside a message expression, the translator simply presumed that the typo was the intended method name. - Errors could not be caught until link time or runtime, which was excruciating given how painfully slow the compile-link-debug cycle was on 1980s hardware.

[01:26:34](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5194s) The Unix Toolchain Dilemma and the Proposal with Alan Watt

Naroff recognized that Objective-C needed to evolve, not into an idealized, academic language, but into a practical, resilient tool. From its inception, Objective-C had made a fundamental trade-off: “I mean, as soon as you say you're embracing C, you're compromising from a purity standpoint.” Stepstone also chose not to write a proprietary build system, intending to fit into standard Unix utilities like `make`. However, because the translator generated intermediate files that `make` could not track reliably, incremental builds often failed to trigger necessary recompilations. A developer would build an executable only to have it mysteriously crash at launch because stale object modules had been linked into the final binary.

To address these flaws, Naroff teamed up with Alan Watt, a colleague who had also worked at ITT, to author a comprehensive engineering proposal. The proposal aimed to stabilize the toolchain while balancing conflicting stakeholder demands: - **Research vs. Production Requirements:** Corporate research customers such as HP were asking Stepstone to integrate experimental technology like an HP-developed garbage collector, whereas production clients like NeXT—who were relying on the language to build an entire operating system and GUI desktop—urgently needed basic reliability, predictable builds, and robust error detection. - **Compiler Overhaul:** The language needed explicit interface declarations so the compiler could validate message signatures, and the front-end needed to be rewritten from scratch to parse the language in its entirety rather than via surface-level script substitutions. - **Robust Intermediate Handling:** Generated artifacts needed to integrate cleanly with standard Unix build pipelines so that stale dependencies would not corrupt executables.

[01:29:48](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5388s) VC Skepticism and the Breakthrough NeXT Visit

Despite the critical necessity of these fixes, Naroff faced fierce resistance internally from Stepstone’s venture capitalists. The investors evaluated the project strictly through financial metrics and could not comprehend paying engineers to refactor existing code just to flag compiler errors: “To them, error handling—they're money people—this notion of, ‘Well, we can't flag an error,’ to them that's like, ‘Well, so what? They're not programmers.’” Ken, the manager running software at Stepstone, lacked the technical depth to advocate for the engineering team, forcing Naroff to wage the political battle on his own.

A pivotal turning point arrived when NeXT sent two engineers out to Stepstone’s Sandy Hook, Connecticut offices: Steve Stone, an OS engineer, and Trey Matteson, a sharp young programmer recently graduated from Brown University. When they read Naroff and Watt’s proposal, they were thrilled: “They both came to visit us in Sandy Hook and read my proposal and were just jazzed, totally just—they’re like, ‘Oh my god, this is exactly what we’re bumping into; this solves our problems.’” Naroff bonded closely with Steve Stone over their shared musical interests—Stone was an accomplished bass player, and the two spent an evening exploring Greenwich Village discovering obscure music. Capitalizing on their enthusiasm, Naroff coached them on the corporate politics: “I said, ‘Guys, when you go back to Palo Alto, I need you to write a letter that identifies what we talked about and why you were supportive of this so I can basically do the political dance at Stepstone.’”

[01:32:14](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5534s) Fixing the Selector Pool and Fighting for a Dynamic Runtime

Stone and Matteson wrote the formal letter upon returning to Palo Alto. Backed by their customer mandate from NeXT, Stepstone management had no choice but to let Naroff overhaul the compiler and runtime. Naroff immediately focused on eliminating the fragile mechanism used to register method names. Previously, a global selector pool was populated directly by tables embedded within individual object files, which the linker would coalesce. If an object module fell out of date due to a missed dependency in `make`, its obsolete selector table was merged anyway, silently corrupting the global selector pool and causing the program to crash. Naroff reflected: “Simply put, it was a good prototype; it was a toy in the early days. My job was to try and build it into a tool that had more wins than drawbacks.”

Naroff rebuilt the compiler from the ground up, added interface declarations, and shifted selector registration toward a truly dynamic runtime model. Both company management and fellow engineers initially pushed back, worrying that dynamic table relocation at program launch would ruin performance on typical workstations of the era, which often had only four megabytes of RAM. Naroff steadfastly rejected building static compromises: “It's a dynamic language, it has to be implemented dynamically—you don't implement a dynamic language statically, you just don't.” While class descriptors laid out by the compiler could still be coalesced by the linker, moving the selector resolution and binding mechanisms into a dynamic runtime gave Objective-C the stability and foundation required to support NeXT's ambitious software architecture.

[01:35:04](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5704s) Runtime Design, Rich Metadata, and Cross-Platform Porting

Naroff elaborates on the delicate architectural tension between the compiler, the linker, and the runtime. In a truly dynamic environment, a program could parse a text file specifying object attributes and instantiate the corresponding data structures on the fly. Because of his background working with MAINSAIL's rich runtime environment, Naroff understood this balance deeply—not as an academic compiler writer, but as a language user who needed runtime reflection. The original metadata in Stepstone's Objective-C translator was incomplete, prompting him to advocate for a far more robust system to describe classes, instances, method signatures, and structures dynamically.

```mermaid flowchart TD accTitle: Trade-offs in Objective-C Message Dispatch accDescr: Diagram illustrating the two different implementations of message dispatch in early Objective-C.

subgraph SingleCall["Fast Assembly Dispatch (One Call)"] A1["msgSend Invocation"] -->|"Shared stack frame"| B1["Assembly Trampoline"] B1 -->|"Direct jump leaving args intact"| C1["Target Method"] end

subgraph TwoCall["Portable Dispatch (Two Calls)"] A2["Lookup Routine"] -->|"Lookup method pointer"| B2["Return Function Pointer"] B2 -->|"Second call with args"| C2["Target Method"] end ```

When interviewer Hansen Hsu asks about the target platforms Stepstone cared about, Naroff recalls working on HP-UX, Apollo, and an exceptionally bizarre minicomputer: the Gould, an IBM-clone architecture. The Gould port proved memorable because its assembler accepted VAX mnemonics and converted them into IBM-style machine instructions—a bizarre hack by whoever originally adapted the assembler. Porting also forced Naroff to wrestle with message dispatch trade-offs: - One implementation used pure C to perform a lookup routine that returned a function pointer to the target method, requiring two distinct function calls. This approach was highly portable across machines but slow. - The faster alternative combined the dispatch lookup and the user arguments onto the same stack frame, using a small snippet of hand-crafted assembly language to jump directly to the target method in a single function call. - For proprietary operating systems like NeXTSTEP or macOS, speed trumped portability: “You just do whatever's the absolute fastest on your processor and an operating system.” - At Stepstone, which did not control its own hardware or OS, Naroff advocated getting ports running via the slower, portable double-call mechanism first, reserving assembly hacks until sales volume warranted the investment.

[01:39:10](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5950s) Stepstone's Customers, Software ICs, and NeXT's Arrival

Stepstone attracted customers largely through print advertisements in *Byte* magazine, which enjoyed massive circulation among technical professionals. However, as a small, cash-strapped startup, Stepstone struggled with customer allocation; a desperate company would burn engineering hours tailoring a port for a single one-off sale on an exotic architecture like the Gould, rather than waiting for critical mass. Engineering staff were heavily sheltered from customers, and Naroff rarely interacted with buyers directly. While researchers at places like HP Labs casually purchased developer tools to experiment with adding Smalltalk concepts to existing C codebases, selling Brad Cox's pre-packaged libraries—the "Software-ICs"—introduced thorny commercial friction over source code access.

NeXT’s adoption of Objective-C began through William Parkhurst, the original AppKit developer, who was looking for developer tools and became captivated by the language. Inside NeXT, engineers debated several paths: - They evaluated Pascal and Object Pascal alongside Objective-C. - Bud Tribble, who was leading software at NeXT after managing the original Macintosh project at Apple, worried that the overhead of Objective-C messaging would degrade system performance, leading to discussions about programming against Display PostScript directly. - After six to nine months of building substantial software with Stepstone's Objective-C translator, NeXT engineers ran straight into severe compile-time bottlenecks and runtime limitations.

Faced with mounting delays, NeXT contacted Stepstone to deliver an ultimatum: “They basically came or contacted Stepstone to read him the riot act and say, you know, ‘We've made a big decision to go with your language and we need it to be pushed in this direction or else we might reconsider.’”

[01:44:39](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=6279s) Silicon Valley Urgency vs. East Coast Skepticism

The frustration inside NeXT was bottom-up and engineer-driven. Developers working under crushing pressure were reportedly complaining, “William, you know, what'd you do to us, right?” Because the Mach kernel and Unix foundations were written in C, sticking with a C-compatible object-oriented layer was the only viable path forward; they simply had to make Objective-C performant. When Naroff was brought in as a consultant by Stepstone to assist NeXT, the engineers' pain was unmistakable: “I knew they were in pain; they were in pain.”

A sharp cultural rift emerged between Stepstone's East Coast venture capitalists and the reality of the West Coast workstation market: - The venture capitalists treated NeXT as just another unproven startup, questioning why Stepstone should prioritize Steve Jobs's nascent company over an established corporate heavyweight like HP Labs. - Naroff found this view completely misguided: “To me it was like so obvious... How could you even question that? HP Labs is piddling around with the language and NeXT is building an operating system; this is like our chance.” - The VCs remained indifferent to Jobs's pedigree, reasoning that while he had founded Apple, a new computer startup was a gamble compared to selling tools to Fortune 500 research divisions. - Having cut his teeth on mainframes, minicomputers, and CAD workstations, Naroff viewed early personal computers and Macs as mere toys; what electrified him about NeXT was the bold vision of building an elegant, professional-grade Unix workstation that ordinary users could actually operate.

[01:47:42](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=6462s) Elite Institution Cognitive Disorder and Stepstone's Misjudgments

Naroff connects Stepstone's institutional mindset to a concept he encountered in a twenty-minute Google presentation by author Malcolm Gladwell on what Gladwell terms "elite institution cognitive disorder." In that lecture, Gladwell explores how individuals become completely smitten by big-name academic institutions, mortgaging their houses and going to extraordinary lengths to attend places like Yale or Harvard, particularly in STEM disciplines. Once there, despite being remarkably smart, many end up in the bottom third of their class—an experience they have never faced before—which leads them to become convinced they are failures. Gladwell backs this up with data, while jokingly admitting that he himself was so flattered by the prestige of being invited by Google that he agreed to give the talk for free.

Applying that psychological trap to his former employer, Naroff argues that Stepstone suffered from the exact same disorder:

> “And I think Stepstone had elite institution cognitive disorder. I think from their perspective HP was an elite institution, and it was HP back then was, you know, they were so respected—things have changed, you know. And, but, but yeah, to them NeXT was just a startup company just like us: we're a startup, they're a startup.”

Because Stepstone reified established industry titans like Hewlett-Packard while dismissing Steve Jobs's NeXT as merely another run-of-the-mill startup, they systematically mismanaged their commercial focus and engineering priorities.

---

[01:50:02](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=6602s) Venture Capitalists, Half-Baked IC-Paks, and the Failure of Ivory-Tower Architecture

When venture capitalists arrived at Stepstone, the company's already precarious culture deteriorated further. Unlike Naroff’s previous employers, Stepstone lacked true leadership and was divorced from a hungry, entrepreneurial spirit; Brad Cox was off doing isolated research, and the operational management brought in from ITT lacked product focus. When outside investors stepped in believing they understood software better than the engineering staff, they pushed to maximize output blindly, assuming that churning out more IC-Paks was the solution. They failed to realize that the libraries they had already built were fundamentally half-baked.

```mermaid flowchart TD accTitle: The Two-Application Rule for Software Kits accDescr: Diagram illustrating that a reusable framework or IC-Pak must be proven against at least two wildly different real-world applications before its architecture can be finalized.

subgraph Design["Framework Formulation"] K["Domain-Specific Kit / IC-Pak"] end

subgraph Validation["Application Validation"] A1["Application 1 (e.g., Spreadsheet)"] A2["Application 2 (e.g., Schematic Capture)"] end

K -->|"Services"| A1 A1 -.->|"Validates basic utility"| K K -->|"Stress tests abstractions"| A2 A2 ==>|"Exposes missing requirements & drives redesign"| K ```

Reflecting on lessons he later formalized at NeXT, Naroff explains that creating reusable, domain-specific object libraries without simultaneously building production applications to validate them is guaranteed to fail:

> “Something I learned—I didn't know this at the time, but now looking back, and I learned it soon after Stepstone, actually at NeXT, and I've never gone back—is: you cannot develop a domain-specific IC-Pak or kit, whatever you want to call it... without doing an app to prove it, and I would argue two apps at least.”

Naroff highlights the pitfall: building a framework around a single program, such as a spreadsheet, only proves it works for that specific domain. Validating whether its graphics and object models can handle a radically different problem, such as schematic capture, requires testing it against a second distinct application.

Professional software houses such as NeXT, Adobe, and Lotus were never going to wager their commercial futures on closed-source, unproven object libraries delivered by an outfit with no real-world production apps. While Brad Cox retrospectively rationalized the demise of IC-Paks as being simply "ahead of their time" or suffering from an unready software marketplace business model, Naroff disagrees with that diagnosis:

> “Well, you could blame the business model you want; the technology just wasn't good enough.”

Naroff recalls coming across an online lecture titled *Object-Oriented Programming is Bad*. While disagreeing with the speaker’s complete rejection of encapsulation, Naroff deeply resonated with one analogy: designing an object hierarchy without knowing its ultimate use case is like drawing up blueprints and erecting interior walls for a house before knowing what the building is actually for. Stepstone—and later initiatives like Taligent—fell into this trap by attempting to hardwire rigid abstractions from an ivory tower without close feedback from end-user applications.

- Stepstone's investors fixated on producing more IC-Paks, rejecting Naroff's proposals to build interactive development environments (IDEs), code browsers, and better compilers modeled after Smalltalk. - Concrete engineering details require empirical refinement: when Naroff and Bertrand Serlet later crafted the Objective-C runtime's method lookup caching, they experimented with complex schemes before discovering that the simplest possible mechanism—linear probing with a hash code derived directly from selectors—performed the best. - Stepstone lacked the iterative, collaborative feedback loop that modern open-source software relies on; when HP lobbied to insert their garbage collector into the Objective-C runtime, they expected it to be adopted wholesale without running it across diverse customer environments, which would have compromised performance for clients like NeXT. - In summary, Naroff views Stepstone as an operationally dysfunctional environment where leadership failed to execute on both the business and technical fronts: “It's not about the concepts; they had the right concepts. They didn't execute the business, they didn't execute on the technology, and that was their problem.”

[01:59:51](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=7191s) Brad Cox's Vision of "Objectware" and the Realities of Software Components

Hansen Hsu opens the segment by revisiting Brad Cox’s concept of "objectware" and software components, asking Steve Naroff whether that overarching philosophy of modular Software-ICs sold on an open commercial market was what initially drew him to Stepstone. Naroff reflects that while Cox’s conceptual pitch held some initial appeal, he was inherently skeptical and never had the luxury to dwell on grand market abstractions. At Stepstone, Naroff was consumed entirely by the immediate crisis of rescuing the Objective-C compiler and the language implementation itself. Stepstone had bifurcated its efforts: while Naroff fought compiler fires, the company treated its IC-Pak product lines as a completely segregated thread. This siloing was reinforced by a corporate culture that actively discouraged engineers working on different initiatives from collaborating or communicating.

Naroff experienced this fragmentation firsthand when he formulated design ideas for an Objective-C interpreter. Despite the fact that his compiler language changes directly influenced any interactive language runtime, he was never invited to participate in the interpreter's design. The interpreter remained a half-baked effort, partly inherited from an outside partner, leaving Stepstone with an incoherent patchwork of technologies. Turning to the broader economics of software components, Naroff points out a fatal flaw in Cox's commercial model: commercial clients refuse to stake their core products on non-trivial, black-box binaries without having access to and control over the underlying source code.

“I also think—I think I said this before—with components, shipping software becomes pretty important, because ultimately, if there are non-trivial components, companies don't want to put their future in another company's hands without control of the source code, which is true for other stuff too, but it's particularly true for components,” Naroff explains regarding the commercial resistance to black-box software components.

```mermaid flowchart TD accTitle: Stepstone Strategy vs NeXT Requirements accDescr: Contrast between Stepstone's commercial focus on black-box IC-Paks and NeXT's technical requirement for solid language infrastructure.

subgraph Stepstone["Stepstone Priorities"] direction TB A["VC Leadership"] --> B["Focus on Commercial IC-Paks"] B --> C["Black-Box Binaries without Source Code"] A -.->|"Siloed / Neglected"| D["Compiler & Language Infrastructure"] end

subgraph NeXT["NeXT Priorities"] direction TB E["NextStep OS & Frameworks"] --> F["Small Dynamic Runtime on 68030"] F --> G["Solid Compiler Diagnostics & Code Gen"] end

D -.->|"Naroff delivers improvements"| G C -.->|"Rejected by clients"| E ```

[02:04:12](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=7452s) Functional Culture versus Venture-Backed Silos

Naroff argues that Stepstone’s belief in selling black-box objects without source code stemmed from pure naivety and a lack of real-world application development experience. Had the company engaged in shipping major end-user applications, its leadership would have run into the hard realities of debugging and maintaining foreign binaries. Instead, Stepstone operated without open introspection. Naroff recalls that the company never held an all-hands meeting to candidly dissect why the business was failing; the engineers were treated like pawns executing isolated tasks while executive leadership struggled fruitlessly to find a viable business model.

This environment stood in stark contrast to the engineering culture Naroff later encountered at NeXT. At NeXT, Steve Jobs fostered an open, confrontational dynamic where company leaders and engineers gathered in a room, laid all their cards on the table, and hashed out technical and organizational roadblocks directly. Naroff notes that when outside investors take control of a small startup without understanding its technical core, the company culture inevitably deteriorates.

“That's how a functional company works: they put the cards on the table and figure out what's working and what isn't working, and that exercise never, to my knowledge, at least if it happened, it didn't include me or Brad, apparently,” Naroff observes regarding the difference between Stepstone and Steve Jobs's operational style.

- Stepstone's management kept developers siloed on separate projects, preventing cross-pollination between the compiler team and runtime/interpreter efforts. - Outside venture capitalists took control of Stepstone and directed resources away from the base language and towards commercial IC-Paks. - Naroff's parting lesson on startup governance: when outside financiers arrive writing checks and dictating direction without technical understanding, engineers should beware.

[02:06:22](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=7582s) Steve Jobs Confronts Tom Love at Deer Creek

Turning to how Objective-C entered NeXT, Naroff explains that NeXT was attracted to Objective-C because C was their foundational systems language, dynamic message-passing provided Smalltalk-like flexibility, and the Smalltalk lineage fit naturally with the Xerox PARC heritage prevalent among NeXT's early team. NeXT needed an ultra-compact dynamic runtime capable of running smoothly within the tight memory constraints of a four-megabyte Motorola 68030 machine. However, NeXT was initially sold a bill of goods by Stepstone, unaware of the serious technical flaws and compiler deficiencies buried beneath the surface.

Before NeXT hired him, Naroff traveled to California as a Stepstone consultant to demonstrate an improved version of the Objective-C translator featuring better error handling and superior C code generation. NeXT was operating in intense secrecy, so Naroff was confined to the business offices on Deer Creek Road, completely isolated from the secure engineering cubicles. While Naroff was demonstrating his compiler improvements on a standalone Sun workstation running the Sun C compiler, Steve Jobs suddenly walked into the entryway accompanied by Bud Tribble, Steve Stone (Naroff’s engineering liaison), and Stepstone co-founder Tom Love. Jobs immediately lit into Love, reading him the riot act for failing to support NeXT's engineering commitments. Jobs argued like an engineer, rattling off precise demands for better error messages, compiler stability, and runtime infrastructure, while demanding that Stepstone stop wasting energy on IC-Paks. Watching Jobs advocate fiercely for basic compiler fundamentals convinced Naroff that NeXT was led by an executive who understood engineering reality.

“Steve had pretty much read Tom the riot act in terms of, you know, we made a bet on you guys and you're not delivering, and you know, Steve is doing great stuff, but we need your whole company to be engaged and support Steve because we care about the language, we care about the infrastructure, we care about the runtime, the error messages, and he like went through, he sounded like an engineer—it was amazing,” Naroff recounts regarding Jobs's dressing-down of Tom Love.

- Jobs explicitly told Tom Love to redirect Stepstone's resources away from IC-Paks and directly into the core language and runtime tooling. - Bud Tribble remained characteristic of his calm, quiet persona during the confrontation, while Naroff watched with quiet satisfaction. - The confrontation showed Naroff that Jobs understood fundamental engineering dependencies—namely, that a rock-solid compiler and language foundation must precede higher-level application frameworks.

[02:11:24](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=7884s) The NeXT Interview and Confrontation with Steve Jobs

Following the Deer Creek confrontation, Jobs decided that rather than acquiring Stepstone or continually battling its management, NeXT should simply hire Naroff directly through targeted recruitment. Naroff flew out to California for a grueling slate of interviews. The schedule began with morning interviews alongside engineers William Parkhurst, Kevin Enderby, and Joe Capriati, followed by a dedicated 45-minute one-on-one session with Steve Jobs, lunch with the operating system group, and afternoon panel interviews with Avie Tevanian, Peter King, Mike DeMoney, and Bud Tribble.

When Jobs entered the interview room, Kevin Enderby—NeXT's compiler and linker engineer—was still inside chatting with Naroff. Enderby politely offered to leave, but Jobs insisted he stay. What followed was a memorable, high-tension interrogation: Jobs scrutinized Naroff’s resume with unconcealed disdain, aggressively challenging his career trajectory, choices, and credentials. Enderby sat through the encounter in awkward discomfort, a moment he and Naroff would reminisce about for years afterward. Naroff refused to back down, vigorously defending his career, his architectural achievements, and the compiler work he had delivered.

“Steve basically looked at my resume with some disdain, questioning my career, what I had done, and it was interesting—I proceeded to defend my life and, you know, talk about the work I had done,” Naroff recalls about his intense initial grilling by Jobs.

[02:13:36](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8016s) The Interview with Steve Jobs and the Connection Through Music

Recounting his interview with Steve Jobs, Steve Naroff explained the history of the two startups he had been part of and how he ended up at Stepstone—a company Jobs openly did not respect. Once Naroff laid out his trajectory, he noticed Jobs immediately begin to relax. Although Naroff admitted he was not savvy enough at that exact moment to realize what was unfolding, the dynamic became clear shortly afterward: Jobs was already convinced before entering the room that Naroff should be at NeXT, but he deliberately made it an intense trial. As Naroff put it, “Steve was convinced I should be at the company before he entered the room, yet he made it a tough interview, and he did it because he knew I had leadership potential at the company and he wanted to see whether I would shrivel up and die under his questioning.” Jobs needed to know whether this prospective hire had the backbone to defend his technical ideas. Drawing on his New York upbringing and his background playing in numerous bands with all kinds of personalities, Naroff was unfazed and enjoyed walking through his work.

The decisive turning point came when Naroff articulated his personal philosophy that software development was fundamentally an art form, drawing explicit parallels between programming and music. Jobs had a deep affinity for music and passionately shared the view that programming was artistic expression. That mutual understanding forged an immediate kinship. Kevin stayed for roughly fifteen minutes before stepping out, while Jobs and Naroff continued talking one-on-one. Later that day, Naroff joined the operating system team for a memorable lunch interview at Little Garden, a legendary Palo Alto Chinese restaurant that served as a bustling crossroads for Silicon Valley talent, packed with engineers from NeXT and the rising Sun Microsystems.

- **Interview dynamic**: Jobs tested Naroff's resilience under aggressive questioning to see if he possessed technical leadership stamina. - **Philosophical alignment**: Naroff's view linking code architecture to musical composition immediately resonated with Jobs' own perspective on software craftsmanship. - **The scene at Little Garden**: The restaurant functioned as an intimate Silicon Valley hub where competing engineering teams crossed paths and eavesdropped on neighboring tables.

---

[02:16:08](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8168s) The Stepstone Lawsuit Threat and NeXT’s Legal Shield

After the interview, NeXT extended an offer, but when Naroff gave notice at Stepstone, management erupted in hostility and threatened to sue him to prevent him from joining Steve Jobs. Naroff was twenty-seven years old, had never faced legal action, and felt profoundly vulnerable: “I’d never been threatened with a lawsuit, and I didn’t have the means to defend myself, and the whole notion of them taking a lien on my modest condo that I bought with a 14 percent mortgage was intimidating.” Naroff reached out directly to Jobs, explaining that unless NeXT could resolve the legal intimidation, he would be unable to make the move. Jobs promptly handed the matter to NeXT's general counsel, Gary Moore, who neutralized the dispute within days.

The threat lacked legal substance because NeXT had already negotiated and purchased a full source code license for Objective-C from Stepstone. Naroff was not taking any proprietary ICpak libraries, nor was he bringing over proprietary code; NeXT planned to engineer its own runtime library from scratch rather than rely on Stepstone’s. Naroff reflected that companies do not own their employees' knowledge, and an astute management team led by Dennis Sisco would have realized that letting NeXT invest heavily in advancing the core language freed Stepstone to focus its own resources entirely on its ICpak component strategy. Instead, Stepstone leadership reacted out of panic because the startup was struggling. Naroff noted the sharp contrast between Sisco's status-driven hierarchy and Jobs’ pure meritocracy: Jobs never evaluated people based on age or net worth, caring strictly about the caliber of their ideas.

```mermaid flowchart TD accTitle: Resolution of Stepstone Legal Threat accDescr: Diagram illustrating how NeXT's legal and licensing rights cleared Steve Naroff's transition from Stepstone.

subgraph StepstoneConflict["Stepstone's Opposition"] A["Stepstone threatens lawsuit"] --> B["Threatens lien on Naroff's condo"] B --> C["Naroff informs Steve Jobs"] end

subgraph NeXTDefense["NeXT Legal Intervention"] C --> D["Jobs assigns Gary Moore (NeXT Legal)"] D --> E{"Legal Fact Review"} E --> F["Full source license already held by NeXT"] E --> G["No ICpak proprietary code taken"] E --> H["NeXT building independent custom runtime"] end

subgraph Outcome["Transition Cleared"] F & G & H --> I["Dispute resolved within days"] I --> J["Naroff relocates to NeXT"] end ```

---

[02:19:37](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8377s) Personal Tragedy and Entering the NeXT "Bomb Run"

Just as Naroff and his wife were preparing for the cross-country relocation from the East Coast to Sunnyvale, personal tragedy struck. Naroff's wife was pregnant, and right before they were scheduled to depart, a doctor discovered an irregularity on a sonogram; the pregnancy was failing, and they lost the baby. Navigating the grief of a lost pregnancy amidst the disruption of a cross-country move and a career change proved immensely painful, but they endured the crisis and moved westward.

Naroff arrived at NeXT around August 1988, stepping straight into an intense corporate sprint. The public unveiling of the NeXT Computer (the NeXT Cube) was scheduled for October 12, 1988, leaving only weeks to stabilize the software stack. Within the company, this frantic final push toward release was referred to as being in the “bomb run”—a phrase coined by Bud Tribble. Entering the company with incomplete hardware and software components strewn across the floor was exhilarating yet chaotic, particularly against the backdrop of intense public and industry fascination with Steve Jobs' new venture. Naroff also noted the poignant timing of the oral history interview itself, conducted on October 8, 2018, sitting squarely between the anniversary of Steve Jobs’ death on October 5, 2011, and the October 12 anniversary of the NeXT Cube launch.

---

[02:22:29](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8549s) Joining the OS Group, GCC 1.0, and Open Salaries

Naroff officially joined NeXT as an engineer reporting to Mike DeMoney, the manager of the Operating System group. At that time, NeXT lacked a dedicated developer tools group, and Naroff was seated directly alongside the OS engineers in an expansive open office. Avie Tevanian, the pioneer of the Mach kernel, had joined only a few months earlier and was an individual contributor deep in OS development. Prior to Naroff's arrival, compiler maintenance had fallen on Steve Stone, an OS systems programmer who had been hacking the compiler purely out of necessity. Stone and his colleagues were desperate to hand off compiler duties so that persistent bugs throughout NeXT software could finally be addressed systematically.

Naroff's initial task was fixing outstanding bugs in the Stepstone translator and stabilizing its integration with the GNU C Compiler (GCC). This was Naroff's very first encounter with Richard Stallman's Free Software Foundation codebase; GCC version 1.0 had only been released in 1987, making the year-old compiler fragile and error-prone. For his first three to four weeks, Naroff immersed himself in resolving bugs across both the Stepstone translator and early GCC. His rapid fixes transformed daily development for the software team:

> “I went from an environment where I was begrudgingly let loose or to do anything interesting to an environment where just fixing bugs made people giddy.”

The impact was immediate. Chris Franklin, who was developing the Workspace Manager (NeXT's graphical file browser, akin to the Mac Finder), sent an email copied to the broader software team celebrating Naroff's fixes for dramatically unlocking their productivity. Because NeXT operated under an open salary and equity policy where compensation levels were visible across the organization, several of Naroff's colleagues inspected his compensation, decided he was underpaid relative to the value he had delivered, and successfully lobbied management to award him an immediate salary raise and equity increase.

[02:26:50](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8810s) The Culture at NeXT and Plans for an Independent Runtime

Reflecting on the reception of his work at NeXT, Steve Naroff remembers being overwhelmed by the positive corporate culture and recognition he received, which was completely unlike anything he had encountered earlier in his career. Finding an environment that was genuinely nurturing and appreciative motivated him to pour himself into the work. As Naroff puts it: “It was honestly the best environment and culture I had ever experienced, you know, so this just led to me being even that more devoted to doing crazy great things.”

With the compiler front end settled, the next major imperative was drawing up plans to eliminate NeXT’s dependency on Stepstone's proprietary runtime library. Naroff set out to build a clean-sheet replacement runtime specifically tailored for the Mach operating system and its memory architecture. At the time, the compiler efforts at NeXT rested on just two engineers: Naroff handled the front end, middle end, and integration with the GNU C Compiler (GCC), while Kevin Enderby handled the back-end tools—the assemblers, loaders, and linkers.

[02:28:13](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8893s) Mach-O Optimizations and Linker-Driven Performance

Working in tandem with Kevin Enderby, Naroff realized that controlling the linker provided a massive architectural advantage for Objective-C. The Mach-O object file format possessed sophisticated capabilities for structuring sections and metadata. Because NeXT computers were running on relatively modest hardware with limited physical memory, Naroff and Enderby engineered system-specific techniques to organize and lay out class metadata so that virtual memory paging was kept to an absolute minimum.

Naroff stresses that having direct control over the linker is critical when building a dynamic language runtime for production systems. Although dynamic languages often default to deferring resolution and setup to execution time, NeXT could not afford runtime bloat. Instead, they devised creative strategies to distribute the workload upstream, pushing as much metadata layout and resolution into the compiler and linker as possible while deferring as little as necessary to execution. During this initial phase, the team was not actively altering the language syntax or semantics; their entire focus centered on evolving and tuning the underlying implementation.

```mermaid flowchart TD accTitle: Distribution of Objective-C Workload at NeXT accDescr: Diagram illustrating how the compiler and linker optimize metadata to minimize runtime paging under Mach.

subgraph BuildPhase ["Build & Link Pipeline"] A["Compiler Front End (GCC / Naroff)"] -->|"Generates AST & Mach-O Sections"| B["Linker & Mach-O Tools (Enderby)"] B -->|"Organizes & Pre-packs Metadata"| C["Optimized Mach-O Executable"] end

subgraph RuntimePhase ["Execution Environment"] C -->|"Direct Mapped, Minimized Paging"| D["Custom NeXT Mach Runtime"] D -->|"Low-overhead Execution"| E["Constrained Hardware Memory"] end ```

- **Two-man tools team**: Steve Naroff focused on the front end, intermediate representation, and GCC integration; Kevin Enderby focused on assemblers, loaders, and linkers. - **Mach-O metadata tuning**: Compiler and linker laid out metadata specifically to prevent paging faults when classes and selectors were loaded. - **Workload redistribution**: Maximizing compile-time and link-time preparation minimized runtime initialization costs on memory-constrained hardware.

[02:29:41](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8981s) Origin of Categories and Supporting Interface Builder

The one major exception to the policy of keeping the language stable occurred very early on, driven by the needs of Interface Builder. Jean-Marie Hullot, working elsewhere in the software organization, came to Naroff to explain the internal mechanisms he was relying on to make Interface Builder function. Hullot was using a runtime feature called class posing (`poseAs:`), a low-level runtime intervention that spliced a subclass directly ahead of an existing class in the metadata hierarchy so the runtime could be tricked into executing custom design-time code.

Naroff recognized that while posing was an impressive and clever hack, building the company’s most important tool on runtime trickery was untenable. He felt strongly that the system needed explicit language-level constructs to support these dynamic UI behaviors reliably: “Interface Builder was really the crown jewel, and making sure it didn't depend on hacks, but depended on language features explicitly, is sort of important.” To replace runtime posing with clean, first-class language mechanics, Naroff implemented Objective-C categories, allowing developers to extend existing classes with new methods without subclassing or tampering with runtime metadata pointers.

## Notable quotes > [01:26:34](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5194s) As soon as you say you're embracing C, you're compromising from a purity standpoint. — Steve Naroff

> [01:32:14](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5534s) It's a dynamic language, it has to be implemented dynamically—you don't implement a dynamic language statically, you just don't. — Steve Naroff

> [01:59:51](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=7191s) Ultimately, if there are non-trivial components, companies don't want to put their future in another company's hands without control of the source code — Steve Naroff

## Mentioned Steve Naroff, Hansen Hsu, Sonny Rollins, Michael Brecker, Alan Kay, Ooblaer Van Dijk, Craig Graci, Doug Lea, Lutz Henckels, René Haas, Kenneth Brown, Nancy Allen, Brad Cox, Tom Love, Ken Hammer-Hodges, Alan Watt, Steve Stone, Trey Matteson, William Parkhurst, Bud Tribble, Steve Jobs, Kevin Enderby, Joe Capriati, Mike DeMoney, Peter King, Avie Tevanian, Gary Moore, Dennis Sisco, Chris Franklin, Jean-Marie Hullot, Bertrand Serlet, Malcolm Gladwell, Richard Stallman, Bjarne Stroustrup, SUNY Oswego, SUNY Potsdam, Stanford University, IBM, General Dynamics, Henckels, Haas & Brown (HHB-Softron), Cericor, Hewlett-Packard, HP Labs, Evans & Sutherland, University of Utah, CBS Records, Mentor Graphics, Xidak, Apollo Computer, Productivity Products International (PPI), Stepstone, AT&T Bell Labs, NeXT, Apple, Sun Microsystems, Lotus, Adobe, Free Software Foundation, CADAT, MAINSAIL, SAIL, Smalltalk, Simula, Pascal, Fortran, GPSS, UNIX, DEC VAX/VMS, C, C++, Objective-C, Mach, Mach-O, GNU C Compiler (GCC), Interface Builder, Workspace Manager, NeXT Computer (NeXT Cube), Motorola 68030, IC-Paks (Software-ICs), CDL (Cericor Development Language), Display PostScript

## Video description Interviewed by Hansen Hsu on 2018-10-08 in Mountain View, CA X8800.2019 © Computer History Museum

Steve Naroff was born in Poughkeepsie NY, 1961, of Ashkenazi Jewish parentage. His father was a jazz musician, conductor, and educator. Naroff’s childhood was spent in the Bronx, and later in the Spring Valley suburbs of New York where his father taught high school music. Naroff began playing classical clarinet at the age of six, and later jazz saxophone. Naroff received his degree in Computer Science from SUNY Oswego in 1983, with a minor in Music. His first job out of college was at Henckels, Haas & Brown (later HHB-Softron), working on Computer Aided Design and Test systems, where he had his first exposure to Unix and C.

After reading about Smalltalk in Alan Kay’s 1977 Scientific American article “Microelectronics and the Personal Computer,” Naroff decided to move to Cericor in Salt Lake City, where he lead the design of graphical circuit design systems, using the language MAINSAIL, which used a dynamic runtime like Smalltalk. Naroff stayed on for a year after HP’s acquisition of Cericor, but eventually left after disagreeing with HP’s decision to port the MAILSAIL-based product to C++, which lacked the dynamic runtime. After meeting Brad Cox and Tom Love at an OOPSLA conference, Naroff joined their startup PPI in 1986, which was later renamed Stepstone. Naroff’s first task was to port the Objective-C translator to various platforms including HP-UX and Apollo, and documenting the design and implementation. After NeXT became a user of Objective-C, Naroff became the main engineer fixing Objective-C for NeXT’s needs, which he felt was not given sufficient attention at Stepstone.

By 1988, Naroff had decided to join NeXT outright. At NeXT, Naroff integrated Objective-C into the GNU C Compiler, integrated C++ with Objective-C in GCC to support Lotus’ Improv spreadsheet, and added the “categories” feature to help support the graphical Interface Builder development tool. Naroff became the manager of NeXT’s Development Tools team, leading the development of an Objective-C parsing framework called DevKit, and collaborating with Bertrand Serlet and Blaine Garst on adding the “protocols” feature to Objective-C. Naroff took a break from NeXT in 1994, working at IBM evaluating various object-oriented platform plays.

Naroff returned to NeXT in 1995 to create its Objective-C to Java bridge. After NeXT’s acquisition by Apple, Naroff became Apple’s Director of Java technologies and developer tools, driving Apple’s Java strategy through its transition from Mac OS 9 to OS X, merging NeXT and Apple’s developer tools teams, and managing Apple’s relationship with Metrowerks, a key third party tools developer. Naroff stepped down from management in 2002 to develop Xcode, Apple’s Integrated Development Environment (IDE), led development of Objective-C 2.0 from 2005-2007, and led the development of the LLVM/Clang C compiler front-end from 2007-2010.

* Note: Transcripts represent what was said in the interview. However, to enhance meaning or add clarification, interviewees have the opportunity to modify this text afterward. This may result in discrepancies between the transcript and the video. Please refer to the transcript for further information - http://www.computerhistory.org/collections/catalog/102717385

Visit computerhistory.org/collections/oralhistories/ for more information about the Computer History Museum's Oral History Collection.

Catalog Number: 102717386 Lot Number: X8800.2019

[Source](https://www.youtube.com/watch?v=ljx0Zh7eidE)

中文简报

因Stepstone工具表现不佳,乔布斯聘请纳罗夫重构Objective-C Stepstone的商业组件业务之所以崩溃,是因为预封装软件库如果未经多个生产级应用的检验就无法成功,这迫使NeXT将编译器和运行时开发转为内部自研。 史蒂夫·纳罗夫回顾了他早年作为自律爵士乐手的成长经历,以及在纽约州立大学奥斯威戈分校接触大型机打孔卡的早期计算机教育,随后他在HHB-Softron转向Unix与C语言系统。在接触Smalltalk并被动态面向对象编程吸引后,他在Cericor用MAINSAIL主导了图形化EDA工具的开发,随后加入Stepstone重构了脆弱的Objective-C转换器与动态运行时。他探讨了Stepstone存在缺陷的软件组件商业模式、史蒂夫·乔布斯与Stepstone领导层的交锋,以及他自己与乔布斯之间那场激烈的入职面试。本次访谈的高潮在于纳罗夫于1988年加入NeXT操作系统团队,在那里他将Objective-C整合进GCC,优化了Mach-O运行时的加载,并设计了语言的“分类”(category)机制以赋能Interface Builder。 在发现MAINSAIL和Objective-C等语言解决了传统C语言无法应对的模块化难题后,史蒂夫·纳罗夫从电子CAD工具开发转向了系统软件领域。 (38:30) 在Stepstone期间,纳罗夫对Objective-C进行了重新设计,将其从一个带内联展开的脆弱脚本转换器,重构为由动态运行时和显式接口声明支持的集成编译器前端。 (84:14) 史蒂夫·乔布斯曾因编译器和运行时支持滞后直接质问Stepstone领导层,促使NeXT于1988年招募纳罗夫来主导其Objective-C和开发者工具研发。 (126:22) 纳罗夫将Objective-C整合进GNU C编译器(GCC),并开发了“分类”(category)功能,以取代NeXT的Interface Builder原本使用的运行时类伪装(class posing)。 (142:29)

Reading summary

Steve Naroff's early career illustrates how dynamic systems concepts transformed Objective-C from a fragile source translator into an industrial operating platform. Drawing on his musical discipline and experience with dynamic runtimes, Naroff rebuilt the language's compiler and runtime architecture to meet the strict performance demands of NeXT. Musical Discipline and Programming as Art (27:36) Naroff's engineering approach originated in rigorous classical clarinet training under his father, an exacting jazz musician and educator. While Naroff stepped back from performance after observing that he lacked the grueling five-to-six-hour daily practice regimen of jazz figures like Sonny Rollins, his musical background informed his perspective on software design. Studying under Craig Graci and Doug Lea at SUNY Oswego, Naroff adopted a craftsman-like approach to compilers and simulations on batch-processing punch-card systems. Constrained to three batch executions per day on IBM 1130 and Burroughs mainframes, Naroff treated source code as an aesthetic puzzle, obsessing over indentation and complexity control to verify programs visually from paper printouts. Naroff argues that this structural rigor was a necessary adaptation to technical constraints, contrasting it with modern software development practices that he believes often tolerate undisciplined, loose programming. Dynamic Runtimes versus Corporate Static Rewrites (52:16) After transitioning from academic Pascal to C and UNIX at HHB-Softron, Naroff concluded that C was ill-suited for large-scale modular simulation tools because it lacked high-level safety mechanisms. Inspired by Alan Kay's 1977 Scientific American paper on Smalltalk, Naroff moved to Cericor in Salt Lake City, leading a team building graphical electronic design automation software in MAINSAIL. Developed out of Stanford, MAINSAIL eliminated static linking through dynamic module loading, garbage collection, and introspection, facilitating portability across competing Apollo and Sun workstations. Following Hewlett-Packard's acquisition of Cericor, HP executives mandated a complete rewrite of the MAINSAIL codebase into C++. Naroff viewed the migration as a fundamental architectural error due to C++'s lack of dynamic loading and automated memory management, a skepticism validated when HP canceled the initiative after five years. The episode convinced Naroff to leave hardware CAD development behind and pivot toward building tools for software engineers, leading him to attend the inaugural OOPSLA conference in 1986. Fragile Compilers and Siloed Venture Strategy (84:09) Joining PPI (later Stepstone) after AT&T Bell Labs rejected him for lacking a doctorate, Naroff found that early Objective-C was not a true compiler but an unpolished preprocessor script that passed raw C through untouched. It lacked explicit interface declarations (@interface) and failed to flag mismatched method selectors. Furthermore, stale compilation dependencies in make routinely corrupted global selector pools, triggering mysterious runtime crashes. Despite these flaws, Stepstone's venture capital backers dismissed compiler error detection as unimportant, prioritizing the sale of pre-packaged Software-ICs (ICpaks). Naroff observes that Stepstone suffered from deep internal fragmentation. Co-founder Brad Cox conducted isolated research on language blocks without coordinating with compiler engineers, while commercial ICpaks remained half-baked because they were never stress-tested against multiple real-world applications. Drawing on Malcolm Gladwell's concept of 'elite institution cognitive disorder,' Naroff contends that Stepstone misjudged the market by deferring to corporate research clients like HP while overlooking NeXT, which urgently needed a reliable production compiler to build its operating system. Tailoring Objective-C for the Mach Platform (148:13) After Steve Jobs confronted Stepstone leadership over unfulfilled engineering commitments, NeXT recruited Naroff to take over Objective-C. When Stepstone threatened a lawsuit, NeXT general counsel Gary Moore neutralized the dispute by pointing to NeXT's full source code license. Joining NeXT's operating system team in 1988, Naroff stabilized the translator against early versions of the GNU C Compiler (GCC 1.0) and initiated a clean-sheet rewrite of the runtime to eliminate Stepstone dependencies and support the Mach operating system. To run dynamic software on NeXT's four-megabyte Motorola 68030 workstations, Naroff collaborated with linker engineer Kevin Enderby. By exploiting the Mach-O format, they pre-structured class metadata in the compiler and linker, minimizing runtime virtual memory paging. When Interface Builder creator Jean-Marie Hullot relied on runtime class posing (poseAs:) to splice design-time behavior into classes, Naroff introduced Objective-C categories as a native language feature, providing a robust mechanism to extend classes without runtime metadata trickery. Naroff's account underscores how commercial viability in software infrastructure depends on aligning language mechanics with operating systems and developer workflows, leaving open whether Objective-C could have achieved mainstream viability had NeXT not intervened to overhaul Stepstone's failing implementation.

精炼阅读摘要

计算机历史博物馆对史蒂夫·纳罗夫(Steve Naroff)的口述历史访谈记录了他从早期音乐与批处理计算训练,走向系统级面向对象工具开发的历程。纳罗夫指出,早期的Objective-C仅是一个缺乏语义检查的脆弱原型,正是他在Stepstone与NeXT期间围绕动态运行时、编译器重构及Mach-O链接优化展开的工程实践,才将其塑造成可支撑现代商业操作系统的工程级语言。 早期训练与受限环境中的软件美学 (27:36) 纳罗夫早年在古典单簧管与爵士乐演奏中接受了严苛的结构化训练,这段背景使他形成了对规律与复杂模式的敏锐直觉,并将编程视作一种讲究秩序与美感的技艺。1979年进入大学后,他在IBM 1130等大型机上使用打孔卡和Pascal语言开发编译器。当时系统每天仅允许运行三次批处理任务,极其严苛的硬件与时间约束迫使他格外注重代码缩进、模块化设计以及复杂度控制。纳罗夫认为,这种强约束下的极客严谨性是现代软件工程所缺失的。 EDA系统探索与转向开发者工具 (38:30) 大学毕业后,纳罗夫进入HHB-Softron从事数字测试工具CADAT的开发,在此期间接触到UNIX与C语言。但他逐渐意识到,为操作系统编写而生的C语言缺乏高级安全保障,难以优雅支撑庞大复杂的仿真工具。受到艾伦·凯(Alan Kay)关于Smalltalk动态对象架构文章的启发,他加入犹他州的Cericor,使用基于斯坦福SAIL的MAINSAIL语言构建图形化原理图捕获工具。MAINSAIL所具备的动态模块加载与元数据机制,加深了他对动态运行时的理解。在经历惠普收购Cericor并强行将其底层向缺乏垃圾回收机制的C++移植所带来的工程灾难后,纳罗夫下定决心离开硬件CAD行业,将职业方向转向为软件工程师打造底层开发工具。 重构Stepstone的Objective-C缺陷原型 (84:09) 1986年参加首届OOPSLA大会后,纳罗夫加入布拉德·考克斯(Brad Cox)与汤姆·洛夫(Tom Love)创立的PPI(后更名为Stepstone)。他发现当时的Objective-C远非成熟的编译器,本质上只是一组将消息传递内联展开为C代码的粗糙脚本翻译器。该系统不仅没有显式接口声明(@interface),更缺乏语义报错能力,全局选择器(selector)池还会因make增量编译遗漏而静默损坏。面对风险投资人对“重构代码仅为报错提示”的短视质疑,纳罗夫联合阿兰·瓦特(Alan Watt)撰写技术方案,并在NeXT来访工程师的支持下倒逼管理层放权。纳罗夫随后从底层重构了编译器并引入动态选择器注册模型,坚决抵制在仅有4MB内存的工作站上向静态机制妥协。 组件商业化困局与NeXT的文化共振 (107:42) 纳罗夫分析指出,Stepstone因患有盲目崇拜老牌企业的“名校认知失调症”(elite institution cognitive disorder),过度重视惠普而轻视初创期的NeXT,同时其兜售黑盒二进制“软件IC”(IC-Paks)的构想完全脱离了实际应用开发与源码调试的客观现实。当乔布斯因技术支持不力在Deer Creek办公室对Stepstone联合创始人严厉问责后,NeXT决定直接将纳罗夫招募麾下。在充满挑战的入职面试中,纳罗夫顶住乔布斯对其履历的苛刻盘问,并凭借“编程与音乐同属艺术”的底层共鸣赢得信任。当Stepstone试图以诉讼威胁阻止其离职时,NeXT法务部门迅速介入予以化解。 落地NeXT:Mach-O系统优化与Category诞生 进入NeXT操作系统部门后,纳罗夫迅速修复了Stepstone翻译器与GCC 1.0集成时的多项缺陷,并着手开发摆脱Stepstone依赖的自主运行时。他与负责汇编及链接工具的凯文·恩德比(Kevin Enderby)紧密协作,充分利用Mach-O目标文件格式的高级元数据布局能力,将大量符号解析和布局工作前置到编译与链接阶段,从而将Mach虚拟内存分页开销降至最低。此外,针对让-玛丽·于洛(Jean-Marie Hullot)在构建Interface Builder时依赖低层运行时“类型伪装”(poseAs:)的脆弱设计,纳罗夫在语言层正式引入了类别(Category)特性,为现代动态UI开发提供了坚实的语法规范。 本篇口述历史清晰呈现了Objective-C从Stepstone时期的脆弱概念原型,演变为支撑NeXTSTEP与现代苹果系统核心基石的工程细节。然而访谈主要立足于纳罗夫个人的技术视角,Stepstone管理层及外部投资人在商业化决策与知识产权争议中的具体考量,仍有待更多维度的历史档案印证。

Detailed notes — zh

## Background 本内容由计算机历史博物馆(Computer History Museum)于 2019 年 4 月 19 日在 YouTube 上发布,采访由 Hansen Hsu 于 2018 年 10 月 8 日主持进行。页面描述概述了 Steve Naroff 从早年音乐背景、大学接触计算机科学,到先后任职于 HHB、Cericor、Stepstone(PPI)并最终加入 NeXT 负责 Objective-C 编译器和开发工具的技术生涯。 ## TL;DR 访谈回顾了 Steve Naroff 从学习单簧管和爵士萨克斯到转入计算机科学领域的早期成长经历,重点讲述了他在 HHB 接触 Unix 与 C 语言、在 Cericor 运用具有动态运行时的 MAINSAIL 语言开发图形化 EDA 系统的工程经验。随后,Naroff 详述了在 PPI/Stepstone 期间面对原始且脆弱的 Objective-C 转换器所开展的重构斗争,以及风投资本介入后 Stepstone 脱离实际的商业盲区。最终,在乔布斯对 Stepstone 问责并展开极具对抗性却深具艺术共鸣的高压面试后,Naroff 加入 NeXT 攻坚 GCC 与全新的动态运行时,并为核心工具 Interface Builder 开创了原生的 Categories 语言特性。 ## Atmosphere & style 整场口述史访谈沉稳、详实且极具工匠特质,Naroff 将深厚的音乐底蕴与系统底层工程的严谨性交织叙述,语言坦率而富有洞察力。在回忆早年穿孔卡片编程、遭遇风投资本认知失调以及只身对抗乔布斯挑衅式面试的经历时,语调既生动风趣又充满张力,鲜活还原了 20 世纪 80 年代个人计算与动态语言萌芽期独特的工程师理想主义与行业现实碰撞。 ## Bulletin - [38:34](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=2314s) Steve Naroff 在 1980 年代受 Alan Kay 论文启发投身面向对象编程,先后在 Cericor 接触 MAINSAIL 动态运行时,随后加入 Stepstone 主导 Objective-C 语言架构重构。 - [02:05:55](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=7555s) 因 Stepstone 资方与管理层忽视底层编译器稳定性并盲目推行无源码的“软件集成电路”(IC-Paks),NeXT 遭遇严重技术瓶颈,乔布斯直接向 Stepstone 高层问责并促成 Naroff 跳槽 NeXT。 - [02:22:29](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8549s) Naroff 加入 NeXT 后迅速修复编译工具链,将 Objective-C 原生集成至 GCC 并深度整合 Mach-O 格式,摆脱了对 Stepstone 运行时的依赖。 - [02:29:29](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8969s) 针对 Jean-Marie Hullot 开发 Interface Builder 时依赖类伪装(Posing)底层 Hack 的痛点,Naroff 在 Objective-C 中设计并引入了 Categories(分类)特性。 ## Key takeaways - [06:03](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=363s) 深厚的古典单簧管与爵士萨克斯演奏训练,塑造了 Naroff 严谨细致的笔记习惯和对程序代码结构的抽象理解力。 - [21:11](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=1271s) 在 SUNY Oswego 本科求学期间,受 Craig Gracie 和 Doug Lea 等导师影响,在穿孔卡片与每日仅 3 次上机的严苛约束下建立了极高的编程规范意识。 - [36:18](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=2178s) 在 HHB 从事 Unix 与 C 语言分布式电路仿真开发时,Naroff 体会到 C 语言在大型复杂系统抽象表达上的局限性。 - [38:34](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=2314s) Alan Kay 于 1977 年在《科学美国人》发表的论文彻底改变了 Naroff 的技术视野,促使他加入开发图形化电路设计的 Cericor。 - [52:16](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=3136s) Cericor 所采用的 MAINSAIL 语言凭借动态模块加载、元数据支持及内存安全隔离机制,极大地启发了 Naroff 对动态运行时的工程理解。 - [58:21](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=3501s) 惠普收购 Cericor 后强行耗费 5 年将具备垃圾回收的 MAINSAIL 系统重写为 C++ 导致项目流产,印证了脱离动态运行时生搬硬套静态语言的系统性风险。 - [01:08:31](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=4111s) 因贝尔实验室坚持非博士不招的硬性门槛,Naroff 在 1986 年首届 OOPSLA 后选择加入 Brad Cox 与 Tom Love 创办的 PPI(后更名为 Stepstone)。 - [01:24:09](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5049s) 早期的 Objective-C 仅是朴素的宏替换转换器,缺乏显式接口声明(@interface)与错误校验能力,配合 make 构建时极易崩溃。 - [01:31:00](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5460s) NeXT 工程师 Steve Stone 和 Trey Matteson 专程访问 Stepstone 并撰写支持信,协助 Naroff 在内部博弈中赢得全面重构 Objective-C 编译器的授权。 - [01:59:51](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=7191s) Stepstone 资方盲目推行不开放源码的黑盒“软件集成电路”(IC-Paks),忽视底层语言稳定性与实际 App 场景检验,导致商业与技术双重溃败。 - [02:05:55](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=7555s) 乔布斯在 NeXT 鹿溪办公室因编译器缺陷当面斥责 Stepstone 高层,并在随后的高压面试中通过对“编程即艺术”的共鸣敲定录用 Naroff。 - [02:16:05](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8165s) 面对 Stepstone 的诉讼威胁,NeXT 凭借已购得的 Objective-C 完整源码授权迅速化解法律纠纷,保障 Naroff 顺利入职。 - [02:22:29](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8549s) 在 NeXT Cube 发布的“投弹航线”高压冲刺阶段,Naroff 迅速攻克 GCC 与转译器 Bug,成为操作系统团队的关键技术支柱并获同事主动游说加薪。 - [02:26:50](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8810s) Naroff 协同 Kevin Enderby 深度利用 Mach-O 二进制段重排优化元数据,极大降低了有限内存条件下的虚拟内存换页开销。 - [02:29:29](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8969s) 为消除图形界面工具 Interface Builder 对运行时类伪装(Posing)黑魔法的依赖,Naroff 为 Objective-C 正式引入了原生的 Categories(分类)特性。 ## Detailed walkthrough ### [00:09](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=9s) 出身背景与家庭渊源 采访于 2018 年 10 月 8 日在计算机历史博物馆(Computer History Museum)由 Hansen Hsu 主持展开。Steve Naroff 回忆自己出生于 1961 年 3 月的纽约州波基普西(Poughkeepsie),但父母在那里仅停留了很短一段时间;出生不久后,全家就搬到了纽约布朗克斯区(Bronx),他在那里度过了人生最初的六七年。从族裔根基来看,Naroff 属于阿什肯纳兹犹太人(Ashkenazi Jews):其父亲一方的祖父是从俄罗斯敖德萨(Odessa)移民而来的,母亲一方则拥有匈牙利和奥地利血统。 Naroff 的父亲是一名职业音乐家和音乐教育家,朝鲜战争期间曾在海军军乐团(Navy Band)服役巡演四年,退伍后在曼哈顿音乐学院(Manhattan School of Music)取得了硕士学位。父亲以演奏次中音萨克斯(tenor sax)为主,是爵士乐领域的泰斗级人物,同时也是极具水准的乐队指挥,在 20 世纪 80 年代还撰写过一本被多所大学广泛采用的爵士即兴演奏教材;直到 85 岁高龄时,父亲仍在佛罗里达与当地乐队同台演奏。母亲则是一名全职家庭主妇,偶尔会在附近公司承接一些行政杂务,但全家主要的经济支柱依然是父亲。父亲白天下校教书,晚上则在家里招揽大批学生进行私人授课。 家庭的宗教氛围并不浓厚。Naroff 的祖父母和曾祖父母作为较早的移民一代极为虔诚,因此他 13 岁时按照传统接受了犹太成年礼(Bar Mitzvah),但他直言那基本上只是为了哄祖父母高兴,学习希伯来语的过程也让他倍感压力。全家虽然会庆祝一些节日并维系文化传统,但整体并不算信教。Naroff 提到,他们后来定居的小镇 Spring Valley(位于纽约市外约 30 英里的宜人郊区),如今已经聚居了大量往返于纽约市工作的哈西德派(Hasidic)极端正统犹太人。 - 出生时间与地点:1961 年 3 月,纽约州波基普西(Poughkeepsie) - 幼年住所:纽约市布朗克斯区(生活了六至七年) - 族裔背景:阿什肯纳兹犹太人(父系源自俄罗斯敖德萨,母系源自匈牙利与奥地利) - 父亲背景:海军军乐团退伍、曼哈顿音乐学院硕士、次中音萨克斯爵士乐手、指挥家及音乐教育家 - 母亲背景:家庭主妇,兼做区域性行政工作 --- ### [03:56](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=236s) 从布朗克斯到春谷镇的成长环境 布朗克斯与后来迁入的春谷镇(Spring Valley)形成了极强烈的反差。Naroff 回忆,在布朗克斯他们住在一栋紧挨着地铁线的高层公寓里,每当地铁呼啸驶过,整间公寓都会剧烈震动。后来全家搬入春谷镇,生活彻底变为了安逸宁静的郊区模式:家里拥有在加利福尼亚标准下不可想象的广阔地块(约一英亩土地),院子里带有一个大泳池,他经常和父亲一起在院子里干农活打理草坪。 举家迁离市区迁入郊区是那个年代中产家庭的普遍选择,其中最主要的原因是郊区拥有极佳的公立学校系统。对 Naroff 的父亲来说,这不仅是想给儿女提供更好的教育,更因为他自己作为一名教育工作者,迫切需要一个更体面、更安全的执教环境。Naroff 补充道,父亲童年是在纽约市极为混乱险恶的哈莱姆区东 150 街(East 150th in Harlem)长大的:“Music aside from him being drawn to it and loving it, music was a way out of the tough projects and also a way to get respect from all the people there.”(音乐除了吸引他、让他热爱之外,也是走出险恶公营廉租房的一条出路,同时还是在那个地方赢得所有人尊重的一种方式。)正因环境严苛,音乐才成了父亲人生的避风港与通向外面世界的阶梯。 家庭成员方面,Naroff 有一个妹妹 Debbie,目前定居在新泽西州拉姆齐(Ramsey),离他们儿时成长的地方不远。兄妹俩的人生轨迹有许多重合之处:妹妹和 Naroff 读了同一所大学(纽约州立大学奥斯威戈分校,SUNY Oswego),而且兄妹两人都是在大学里邂逅了各自未来的伴侣。 --- ### [06:03](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=363s) 音乐熏陶:从古典单簧管到爵士萨克斯 从六岁起,父亲就把单簧管塞进了 Naroff 的嘴里。由于父亲在音乐和学业上都奉行严格的管教理念,Naroff 的整个童年几乎都围绕着音乐运转。虽然他也打棒球、担任过投手,但核心精力始终在古典音乐上。他展现出了非凡的乐器天赋,每年都要接受纽约州学校音乐协会(NYSSMA)的评级审核并听取严苛的专业乐评;到初三(九年级)时,他已经能够独奏莫扎特的《A大调单簧管协奏曲》(Mozart Clarinet Concerto)——这被公认为单簧管曲目中难度极高的巅峰之作。 然而,在九年级向十年级过渡的阶段,Naroff 意识到古典音乐并不是自己的真正志趣所在:“It was very highly structured and it didn't provide that much freedom that I was looking for, so I switched over to tenor sax and gravitated much more to jazz.”(它结构太严谨了,无法提供我所追寻的那种自由,所以我转向了次中音萨克斯,并且越来越被爵士乐所吸引。)单簧管的学习为萨克斯打下了坚实的技术基础,进入高中乃至大学后,他彻底放下了单簧管,专攻次中音萨克斯与爵士即兴演奏,并从中找到了真正的乐趣。 在平时的阅读与课外娱乐方面,Naroff 表示由于童年大部分时间都在读谱和听乐,学校要求的必读书籍之外,他很少去碰严肃的严肃文学名著,休闲时更偏向于读《疯狂杂志》(Mad Magazine)或《国家讽刺》(National Lampoon)这类诙谐读物。与他后来酷爱阅读的大女儿形成鲜明对照的是——他的女儿幼年就能啃完《指环王》(Lord of the Rings),甚至去书店主动要求买《默克诊疗手册》(Merck Manual)——Naroff 自己更偏向于视觉化接收。在电视娱乐上,他是经典科幻片《星际迷航》(Star Trek)和《阴阳魔界》(The Twilight Zone)的狂热影迷。直到后来步入大学、彻底迷上计算机,他才变成了一个如饥似渴的专业技术书读者;在那个没有亚马逊网购的时代,为了淘到生僻的计算机专著,他不得不频繁往返于纽约市区去寻觅那些偏僻隐蔽的书店。 ```mermaid flowchart LR accTitle: 音乐与专业发展阶段 accDescr: 展示 Steve Naroff 从六岁接触古典单簧管到转向爵士萨克斯再到大学迷上计算机的学习轨迹演变。 subgraph Classical ["古典音乐启蒙"] A["6 岁:学习古典单簧管"] --> B["9 年级:演奏莫扎特单簧管协奏曲"] end subgraph Jazz ["转向自由爵士"] B --> C["9-10 年级:转攻次中音萨克斯"] C --> D["大学时期:专注于爵士即兴演奏"] end subgraph Computing ["跨入计算机领域"] D --> E["大学阶段:痴迷计算机科学<br/>赴纽约市淘阅冷门技术专著"] end ``` --- ### [10:04](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=604s) 基础教育与父子师生关系 回顾从小学到高中的学业历程,Naroff 自评是一名优秀且极具条理的学生。他从不属于在考场上拼得你死我活的极端竞争型人格,对 SAT 这种标准化考试机制也持保留态度,但应付学校课业向来游刃有余。他擅长做笔记,记录习惯极其严密细致,这一条理分明的习惯从中学一直延续到大学的编译器课程中。高中阶段他的数学成绩优异,但当时的教学方法过分拘泥于公式解题,未能展现数学的实际应用潜力,以至于他并没有与数学产生强烈的情感共鸣;不过,他深信音乐与数学之间存在着内在的结构共通性,深厚的音乐训练让他能够极其自然地透彻理解(grok)高阶数学逻辑。 当时的春谷高中(Spring Valley High School)教学质量极高,社区资源投入充分,而且学生背景呈现出非常健康的多元化。那里的多元并非指亚裔或印裔群体的聚集,而是拥有庞大的非裔美国人学生群体,涵盖了各阶层家庭,而非单纯的白人富家子弟学校。Naroff 对这种公立学校的多元化生态推崇备至,认为这是学习人际交往的最佳环境,日后他也尽可能让自己的子女留在公立高中体系中就读。 高中时期最特别的经历在于,他的父亲恰好在他就读的初中与高中任教,并且直接担任学校管弦乐队的指挥和音乐总监。这种“父子兼师生”的身份给 Naroff 带来了不小的心理包袱:父亲在乐队排练中是个雷厉风行的铁腕管理者,对纪律要求极高,排练中如果有同学因为纪律问题被父亲当众训斥,排练结束后往往会对着 Naroff 抱怨“你老爸脾气真臭”。与此同时,由于父亲在校任教,教职员办公室之间互通声气,Naroff 一旦在其他科目上有丝毫懈怠或出格行为,父亲放学后就会立刻知晓并施加严厉管教。好在 Naroff 本身性格踏实稳重,并不是离经叛道的叛逆青年,父子在校共处的日子虽有尴尬,但也波澜不惊地平稳度过。 - 学习风格:笔记极其工整详尽,更看重知识的实际应用而非标准化应试成绩 - 数学与音乐联结:借由深厚的乐理与视奏背景,无缝理解高阶数学逻辑 - 学校生态:春谷高中教学质量极佳,生源阶层与种族背景极具包容性与多元性 - 父子同校体验:父亲兼任学校乐队总监,铁腕治乐导致 Naroff 常承受同学的人际压力,但在校行为也受到严密监督 ### [13:46](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=826s) 少年时期的偶像与导师:从格林威治村爵士乐手到 Alan Kay Steve Naroff 谈及成长过程中敬佩的人物时表示,自己当年的偶像与敬仰的对象主要是他在纽约格林威治村(Greenwich Village)爵士俱乐部里亲眼见到的专业音乐家,比如当时的萨克斯风演奏大师 Sonny Rollins 和 Michael Brecker。Naroff 坦言,自己虽然有音乐天赋,但深知自己没有那些登顶巨星的惊人指法技巧或极其刻苦的敬业态度。那些大师每天在乐器上投入五六个小时的苦练,而他每天只练一两个小时;正因如此,他深知能达到那个高度并把高难度的演奏表现得游刃有余是多么困难,因而对专业音乐家抱有极深的敬畏。 在学术与计算机领域,由于 Naroff 在 1979 年高中毕业,当时计算机整体尚处于雏形阶段,以大型机为主,像 Steve Jobs 这样的人物在那时还没有成为公众崇拜的偶像。不过,Naroff 提到自己在大学期间读到了 Alan Kay 的著作,虽未谋面,但从精神上早已将他视为导师。正如 Naroff 所言: > “Even if I didn't know them, you know, in college I felt Alan Kay was a mentor just from reading what he was writing.” --- ### [15:47](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=947s) 择校与专业抉择:SUNY Oswego 与本科计算机科学课程的早期历史 高中毕业面临前途选择时,Naroff 曾一度打算全职投身音乐事业,成为一名职业音乐家。然而,走遍世界巡演、深知音乐从业艰难的父亲坐下来劝导他回归现实。父亲虽然全力支持他的音乐追求,但建议他将音乐作为辅修,去选一个其他专业作为主修。父子俩商量后决定选择计算机科学。Naroff 指出,当时大学本科设立计算机科学课程非常少见。为了准备这次访谈,他特意查证了历史:纽约州立大学奥斯威戈分校(SUNY Oswego)的计算机科学课程由丹麦数学家 Ubblr Van Dyke 于 1968 年撰写提案、1970 年正式设立;当时整个纽约州立大学(SUNY)系统中,除了 Oswego,仅有 SUNY Potsdam 考虑开设计算机科学学士(BA)学位,而像 Stony Brook、Albany、Binghamton 等名气更大的 60 所分校当时均未设立本科计算机专业。甚至斯坦福大学也是直到 1986 年才开设本科计算机科学课程,此前只有研究生项目。 选择就读 SUNY Oswego 出于多重现实考量。Naroff 的父亲是一名教师,家庭作风相对保守,不希望背负巨额学生贷款,因此决定将择校范围锁定在教学质量优异且学费亲民的 SUNY 系统内。在具备计算机课程的 Potsdam 和 Oswego 之间,Oswego 非常开明地支持他辅修音乐,并热烈欢迎他加入校管弦乐团和爵士乐队,而 Potsdam 则担心高强度的音乐辅修会分散学生精力。此外,Oswego 坐落于安大略湖(Lake Ontario)畔,风景极美,唯一的缺点就是冬季气候异常寒冷、狂风呼啸,以至于如果体重较轻的人在湖边行走,甚至会有被大风吹入湖中的危险。 - **学费对比**:当时 Oswego 包含食宿的费用约为每年 6,000 美元,Naroff 仅申请了 3,000 美元的学生贷款,毕业后很快还清;而如今该校包含食宿的费用已达约 27,000 美元。 - **环境变迁**:由于冬季极度酷寒多风,现在的某些校区甚至修建了地下通道供师生穿行,但在夏季这里风光秀丽。 --- ### [21:11](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=1271s) Oswego 的良师益友:Craig Gracie 与 Doug Lea 在 SUNY Oswego,Naroff 遇到了对他计算机生涯影响深远的导师 Craig Gracie。Gracie 拥有数学硕士学位,在 Naroff 入学的前一年(1978 年)才开始教授计算机科学。Gracie 极为出色,当时他自己也在与学生们同步学习编译器(compiler)和操作系统(operating system)等核心领域,这种与学生一同探索未知的状态让他的教学格外引人入胜。Gracie 本人也酷爱音乐,两人因此结下了深厚的师生情谊。Naroff 自认在高中时并非拼命拔尖的学霸,只是靠着天赋轻松取得不错成绩;到了大学面对硬核的编译器和操作系统挑战,学业变得极为艰巨,正是 Gracie 给予的悉心关怀与指导改变了他的人生轨迹。 大约在 1980 年(Naroff 入学两年后),Doug Lea 也来到了 Oswego 任教,成为 Naroff 的另一位导师。Doug Lea 后来成为了 C++ 和 Java 社区举足轻重的领军人物(luminary),撰写了大量关于 Java 并发编程(Java concurrency)和 C++ 的权威著作。Naroff 提到,Gracie 和 Doug Lea 两人都纯粹出于对教学的热爱而终生留在学术界。后来 Naroff 进入工业界时曾打电话力邀 Gracie 投身工业界发展,但 Gracie 毫无兴趣,目前担任 Oswego 认知研究(Cognitive Studies)的主任。至今,Naroff 依然珍藏着当年在大学里用 Pascal 语言编写、打印在纸上的编译器源代码,并以此为荣。 ```mermaid flowchart TD accTitle: Academic and Mentorship Influences at SUNY Oswego accDescr: Diagram showing the mentors Craig Gracie and Doug Lea guiding Steve Naroff in computer science, along with his music minor. subgraph Faculty["SUNY Oswego 导师"] CG["Craig Gracie<br/>(数学硕士 / 1978年开设计算机课 / 音乐爱好者)"] DL["Doug Lea<br/>(1980年加入 / Java并发与C++权威学者)"] end subgraph Student["Steve Naroff 的双线学习"] CS["计算机科学主修<br/>(Pascal编译器、操作系统、大型机)"] Music["音乐辅修<br/>(管弦乐团、爵士乐队)"] end CG -->|"悉心指导 / 亦师亦友"| CS DL -->|"学术启发 / 编程理论"| CS CG -.->|"共同话题"| Music ``` --- ### [23:56](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=1436s) 穿孔卡片、大型机与严苛的编程纪律 谈及人生中写下的第一个程序,Naroff 回忆那是在大学课程中完成的。虽然具体题目已经模糊,大约是打印“Hello World”或基础排序算法,但他清晰记得第一门课程使用的是 IBM 1130 大型机上的 Fortran 语言。大二时,他修读了一门使用 GPSS(General Purpose Simulation System,通用系统仿真语言)的课程,主要用于排队论、统计学以及模拟类似“乔的理发店”(Joe's barbershop)这类的业务场景问题。在那之后,他的绝大部分专业课程都转到了 Pascal 语言上。 当时的编程环境全靠大型机与打孔卡片(punch cards)。学生们在 IBM 1130 和后来的 Burroughs 5600 分时大型机上编写汇编器与编译器,往往需要抱着用橡皮筋扎起的厚厚几摞卡片盒,里面包含数千行代码。系统每天仅提供三次上机运行(batch run)的机会来检验程序正确性。Naroff 感慨,这种极端的物理限制强迫程序员在提交卡片给计算机之前,必须用流程图详尽梳理逻辑、深入严谨地思考问题,形成了高度自律的思维习惯。Naroff 阐述了这种古老工作方式给软件工程带来的沉淀: > “There's also something wonderful about thinking about your problem that much and having that level of respect for the computer, right? And it took a lot of discipline to get a compiler, a big piece of code thousands of lines, to work you know under that constraint.” 当被问及大学期间是否接触过面向对象编程(OOP)时,Naroff 表示当时完全没有。大学里唯一接近的讨论是他曾向 Craig Gracie 询问是否会开设欧洲发展起来的 Simula 语言课程,Gracie 回复暂时不会。当时计算机科学教学的核心集中在结构化/模块化编程、避免滥用 `goto` 语句等软件规范上,面向对象编程所倡导的“大规模编程”(programming in the large)优势在当时的本科教育中还不是重点。 - **上机约束**:每天仅有 3 次批处理运行机会,迫使学生必须在动手前完成详尽的流程图设计并反复推敲代码逻辑。 - **硬件环境**:前期完全基于配备打孔卡片的 IBM 1130,后期引入了支持分时系统(time sharing)的 Burroughs 5600 大型机。 ### [27:36](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=1656s) 结构化编程、代码严谨性与早期的打工实习 在进入第一份全职工作之前,面向对象编程(OOP)甚至都还未进入软件开发的主流方法论中,这项概念花了相当长一段时间才真正流行起来。Steve Naroff 回忆,他在大学和早期的编程实践中一直严格遵循结构化编程与模块化编程。当时由于每天最多只能在穿孔打卡机上跑两到三次程序,代码排版与模块切分就成了生死攸关的技能。他把编写代码视为一门精雕细琢的艺术,甚至对代码缩进(indentation)有着极高的执念。虽然平时在打孔卡上根本看不出缩进,但一旦将代码打印到纸质清单上审查时,清晰的缩进结构便一览无遗,能够有效避免编写出庞大而难以驾驭的例程(routines)。 然而,Naroff 澄清这种对美感的追求并非纯粹的“为艺术而艺术”,而是在极端资源限制下管理复杂度的必要手段。面对这种复杂的谜题,唯有极度自律才能让程序在极少的运行次数中成功执行。Naroff 对此感慨,这种在严苛约束下磨炼出来的严谨与工匠精神在如今的代码世界中已经严重流失,他直言: > “It's that part of the rigor and art is missing today and encourages a lot of sloppy sloppy work, sloppy programming.” > (正是这种严谨与艺术感在今天消失了,导致助长了大量粗制滥造、马虎敷衍的编程工作。) 谈及大学期间的打工与实习,Naroff 在大三之前曾做过各种零工,比如在纽约著名的热狗连锁店 Nathan’s 掌勺。到了大三(大约 1982 年),他在位于新泽西州富兰克林湖(Franklin Lakes)的 IBM 申请到了一份计算机操作员(computer operator)的暑期实习。这份工作的实质就是看护极为昂贵的高速激光打印机,源源不断地给它们加纸并喂入数据。这些工业级激光打印机速度惊人,打印时纸张在眼前飞速闪过,肉眼几乎无法辨识。尽管时薪高达 14 美元(按现今购买力折算相当于每小时 30 至 40 美元),但他坦言在那里没学到太多高深的软件知识,更多是见识到了那些用于大批量输出纸质文档的庞然大物。巧合的是,富兰克林湖这个当时算不上技术中心的小镇,日后竟成了他大学毕业后第一份正式工作隔街相望的邻居。 - **编程与代码美学**:极度重视缩进与子例程拆分,核心动机在于通过结构化手段降低系统复杂度,以适应打孔机时代一天仅能跑两到三次任务的严苛环境。 - **IBM 实习经历(1982 年)**:在新泽西州富兰克林湖担任计算机操作员,主要职责是维护并操作高速激光打印机;时薪约 14 美元。 --- ### [31:17](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=1877s) 毕业求职与通用动力(General Dynamics)的文化震撼 1983 年,Naroff 从纽约州立大学奥斯威戈分校毕业。在那个没有 LinkedIn 等求职网站的年代,他接受了两次面试。其中一次充满意外:位于加州波莫纳(Pomona)的通用动力公司(General Dynamics)不知通过何种途径联系上了他,邀请他飞往加州面试。 这是 Naroff 人生中第一次乘坐飞机。对于从未出过远门且独自飞行的年轻人来说,这趟旅程本身就伴随着不小的紧张感。抵达波莫纳后,他坐在接待室等待面试,工作人员递给他几本宣传册,介绍他未来将要参与的产品项目。当他翻开手册时,赫然发现自己即将编写的竟然是计算机辅助导弹系统(computer-aided missile program)的 Fortran 代码。面对屏幕上冷冰冰的战争武器,Naroff 感受到剧烈的“文化震撼”: > “I really didn't want to work on, you know, war instruments.” > (我真的不想去从事战争武器方面的工作。) 尽管他硬着头皮完成了面试流程,但内心早已将这份工作全盘排除,甚至后来对具体的技术面试环节失去了所有记忆。即便如此,这次跨越大半个美国的初次飞行与面试经历,依然成了他步入职场前的一次难得锻炼。 --- ### [33:10](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=1990s) 加入 HHB:初涉 Unix、C 语言与分布式电路仿真 回到东海岸后,Naroff 的母亲得知邻居罗莎莉(Rosalie)在一家名为 Henckels, Haas & Brown(HHB,后更名为 HHB-Softron)的初创小公司工作,便引荐了刚毕业的 Naroff。HHB 距离 Naroff 长大的地方只有大约 10 英里,距离他此前实习的 IBM 也不过两三英里。Naroff 参加了面试并立刻爱上了那里的技术氛围。 HHB 由三位 MIT 毕业生(Lutz Henckels、Ken Brown 和 René Haas)联合创办,是当时电路仿真和测试仿真领域的先驱企业。他们自主研发了一套名为 CADAT(Computer-Aided Design and Test,计算机辅助设计与测试)的核心软件。随着业务拓展,创始团队需要对现有系统进行重构与扩充,因此招揽了一批年轻的应届毕业生。Naroff 与其他五到十名来自哥伦比亚大学、卡耐基梅隆大学(CMU)和麻省理工学院(MIT)等顶尖名校的毕业生同时入职。虽然 Naroff 自嘲毕业院校名气不及同侪,但他很快融入团队并与大家建立了深厚友谊。 在 HHB 的技术栈主要是基于 Unix 和 VAX/VMS 系统。Naroff 在那里主要攻坚了两大任务: 1. **电路二进制文件分析工具**:HHB 原本有一套专门的硬件描述语言,用于定义电路元器件之间的拓扑连接关系,该语言会被编译为紧凑的二进制电路文件。但当时团队缺乏能够深入解析、检查和调试这些二进制文件的底层工具,Naroff 负责为此构建配套的分析程序。 2. **基于网络套接字(Sockets)的分布式仿真加速**:随着 Unix 系统正式引入 Berkeley 套接字(Sockets)支持网络通信,Naroff 参与开发了前沿的分布式电路仿真技术。他利用套接字将复杂电路仿真流水线中的不同处理流程分发到局域网内的不同计算机节点上协同运算,大幅缩减了耗时极长的仿真过程。在当时,利用局域网集群进行分布式计算属于极具前瞻性的前沿探索。 ```mermaid flowchart TD accTitle: HHB Circuit Simulation Architecture accDescr: CADAT textual language compiles to binary, then gets analyzed and distributed across Unix machines via Berkeley Sockets. subgraph Design["设计输入阶段"] A["文本电路网表描述语言"] -->|"编译"| B["二进制电路文件"] end subgraph Tooling["分析与分布式加速"] B --> C["二进制文件解析与检查工具 (Naroff 开发)"] B --> D["CADAT 仿真调度引擎"] D -->|"Berkeley Sockets 网络通信"| E["机器节点 1: 仿真 Pass A"] D -->|"Berkeley Sockets 网络通信"| F["机器节点 2: 仿真 Pass B"] end ``` --- ### [36:18](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=2178s) Unix/C 学习曲线与对语言表达力的反思 HHB 的经历是 Naroff 首次真正踏入 Unix 和 C 语言的世界。初期的工作极具挑战性,因为工程师必须熟练掌握一整套复杂的工具链,包括 C Shell、Make 构建脚本以及各类系统调用。他大约花费了三到六个月的时间跨越学习曲线,才真正感到游刃有余。 习惯了强调类型安全与严谨防错的 Pascal 之后,C 语言的设计哲学给 Naroff 带来了不小的心理落差。C 语言语法高度精炼且底层,对安全检查几乎持中立态度,甚至在某种程度上容易纵容错误操作。Naroff 很快意识到: > “Like it's C school, but fundamentally it was developed to aid operating system development, in this case Unix... and for what we were doing, building large simulation tools, it wasn't a real natural fit.” > (C 语言是很酷,但从根本上说,它是为了辅助开发操作系统——也就是 Unix——而诞生的;而对于我们要构建的大型仿真工具来说,它并不是一个非常自然契合的工具。) 在开发极其庞大而精密的电路仿真系统时,缺乏高阶抽象的 C 语言使得代码极难维护且极易出错。这种对 C 语言局限性的强烈感受,促使 Naroff 开始主动探寻更优秀的编程范式与更具表现力的语言工具。 --- ### [38:34](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=2314s) 读到 Alan Kay 论文的震撼与出走 Cericor 在对 C 语言的冗长繁琐日渐失去耐心之际,Naroff 偶然读到了计算机先驱 Alan Kay 于 1977 年在《科学美国人》(Scientific American)发表的著名文章《微电子学与个人计算机》(Microelectronics and the Personal Computer)。这篇文章向他展示了一个全新的计算宇宙: * **Smalltalk 语言**:展现了基于消息传递和动态运行时的纯面向对象范式。 * **Dynabook 构想**:早在 70 年代末就描绘出了类似现代 iPad 的便携式个人计算设备蓝图。 这篇论文对 Naroff 产生了深远而具颠覆性的影响,彻底拓宽了他的技术视野。他开始在公司内部积极宣讲面向对象编程、现代工具链和高级语言的巨大潜力。然而,HHB-Softron 的管理层虽然认可面向对象概念的前瞻性,但基于商业运营现实做出了务实判断:他们无法承受停下手头业务去全面重写软件的巨大成本与风险。管理层诚恳地表示,公司很希望他留下,但如果他执意追求这些新技术,也会尊重并支持他的离开。 明确自身志向的 Naroff 通过猎头公司物色契合方向的下家,最终锁定了位于犹他州盐湖城的 Cericor 公司。当时大多数电子设计自动化(EDA)软件(如 HHB 的系统)仍依赖编写枯燥的纯文本文件来连接电路元器件,而 Cericor 却走在时代最前沿——他们率先在图形化屏幕上通过直接拖拽和交互来设计电路。Naroff 将 Cericor 视作 CAD 领域的苹果公司(Apple),它正将传统繁琐的工程制图带入革命性的图形视窗时代。此外,Cericor 的技术骨干多来自图形学圣殿埃文斯-萨瑟兰(Evans & Sutherland)以及犹他大学,这让渴望在先进工具与面向对象世界一展身手的 Naroff 毫不犹豫地做出了西行的抉择。 - **Alan Kay 1977 年论文**:发表于《科学美国人》,系统阐述了 Smalltalk 面向对象思想及 Dynabook 概念,成为启发 Naroff 投身面向对象技术的思想源泉。 - **HHB-Softron 态度**:认可 OOP 价值,但由于既有软件资产沉重与商业交付压力,无力进行系统级推倒重构。 - **Cericor 的技术亮点**:颠覆传统的纯文本网络表定义模式,率先基于图形化窗口界面进行交互式电路设计,背后拥有犹他大学与 Evans & Sutherland 的图形学学术与工业血统。 ### [41:25](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=2485s) 迁往盐湖城与和 Nancy 的婚姻 对于在纽约长大的 Steve Naroff 来说,犹他州盐湖城本是他“最不可能想要去的地方”,两地之间存在着极大的文化冲击(Culture shock)。当时他与女友 Nancy Allen 正打算结婚,Naroff 便提议:“不如我们先结婚,然后一起搬到盐湖城去吧?”于是两人成婚并启程西迁。Naroff 后来发现 Cericor 是一个极佳的工作场所。 谈及妻子 Nancy Allen,Naroff 回忆两人相识于纽约州立大学奥斯威戈分校(SUNY Oswego)。当时 Nancy 是管弦乐队的小提琴手,而 Naroff 正在乐队担任莫扎特单簧管协奏曲的独奏——那是他在音乐上的“代表作”。通过乐队合作以及共同的音乐理论课,两人相识相爱。Nancy 比 Naroff 高两届,毕业后进入纽约市 CBS 唱片公司的法律部门(位于著名的“Black Rock”大楼),担任法务与古典音乐家之间的对接人。 得益于 Nancy 在 CBS 唱片的工作,两人经常拿到顶级演出的门票。例如他们曾结识尚未大红大紫的年轻爵士歌手 Harry Connick Jr.;在麦迪逊广场花园观看 Earth, Wind & Fire 的演唱会;著名小提琴家林昭亮(Cho-Liang Lin)当时也与 Nancy 熟识,多年后还在 Naroff 儿子的演出场所相逢叙旧。Nancy 还经常免费带成叠的黑胶唱片回家。尽管搬家前 Nancy 非常支持 Naroff,但到达盐湖城后却感到了落差。在当时的摩门教(耶稣基督后期圣徒教会)主流文化中,女性地位基本等同于“二等公民”。Nancy 在纽约拥有一份光鲜的工作,在盐湖城却很难找到相当的职位,所受到的待遇也与纽约相去甚远。 - 夫妻初识背景:SUNY Oswego 管弦乐队(Nancy 奏小提琴,Naroff 独奏莫扎特单簧管协奏曲)及乐理课堂。 - CBS Records 经历:Nancy 在纽约 CBS 唱片总部法务部工作,积累了丰富的音乐圈人脉并享有海量现场演出福利。 ### [44:40](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=2680s) 政治立场与早年背景 Naroff 谈及自己的家庭出身是非常自由派(Liberal)、蓝领工人阶级并且坚定支持民主党的。尽管如今美国的党派政治极度部落化(Tribal),让人随着年龄增长感到厌倦与烦躁,但早年的他并不太关心宏观政治。他的理念单纯源于人道主义关怀:社会应当帮助弱者,纳税也是理所应当的,只要税金能用于救济底层困苦的人群。 Naroff 提到自己的父亲成长环境极其贫困,祖父是纽约的一名出租车司机,还曾开创了纽约最早的职业遛狗生意,但因吸烟过早离世。由于深知贫困的滋味,Naroff 对弱势群体始终怀有同情心。回看自己的人生道路,他谦逊地表示:“我知道自己是站在巨人的肩膀上,但我也知道自己出生的年代和进入计算机科学行业的时间节点非常幸运。” ### [46:47](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=2807s) 接触 Alan Kay 与面向对象理念的契机 当被问及当年是如何读到 Alan Kay 1977 年发表在《科学美国人》(Scientific American)上的经典文章《微电子学与个人计算机》(Microelectronics and the Personal Computer)时,Naroff 表示当年既没有社交媒体,也不能直接 Google 搜索,完全依靠人际传播。在 HHB-Softron 工作时,优秀的同事们经常聚在一起讨论计算机行业的前沿动态并互相分享文章。 此外,Naroff 提到 20 世纪 70 至 80 年代极具影响力的《Byte》杂志,特别是探讨 Smalltalk 的特辑。通过阅读这些技术杂志上的人物名字,他进一步检索并研读了相关学者撰写的论著。Naroff 还在为本次访谈做案头功课时想起,Alan Kay 本人正是犹他大学(University of Utah)的毕业生,犹他大学在计算机图形学与计算科学史上具有举足轻重的地位。 ### [48:26](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=2906s) Cericor 的面试与独特的摩门团队管理体验 去 Cericor 现场面试时,Naroff 的直属主管是一名摩门教徒。对方不仅坦率地介绍了当地文化,还给出了录用 Naroff 的一个非常奇特的理由。主管表示,除了技术经验、编程热情以及对 MAINSAIL 语言的兴趣之外,他们看中 Naroff 的领导潜力,并且认为这与他的地域文化背景密不可分: > “我们对你感兴趣的原因之一是你的领导能力,这不仅是我们相信你拥有的特质,也是一种文化层面的东西——比如你来自纽约,在摩门教观念里对纽约犹太人有一种特殊的亲近感。” 主管坦承,公司里许多摩门教员工习惯于做服从安排的“工蜂”(Worker bees),并且安于这种状态,因此他们希望 Naroff 能够挑起大梁带领团队,而组员们也渴望这样的领导。这与日后硅谷那种“宛如放牧猫群(Herding cats)”、人人都争当领导者的工作氛围大相径庭。Naroff 在 Cericor 担任团队主管(Team Lead),负责任务分配、系统架构设计、项目管理以及大量的底层编码。虽然他当时并不是正式编制的人事经理,也不负责撰写绩效评估,但他带领的团队士气极高,那是他职业生涯中“带过最轻松、最顺畅的团队”。 Naroff 查阅资料后惊讶地发现,自己原本以为在 Cericor 呆了两三年,实际上只有一年半。入职仅仅五到六个月,公司就被惠普(Hewlett-Packard, HP)收购,他在 HP 旗下继续留任了一年。 ### [52:16](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=3136s) MAINSAIL 语言的技术架构与实用主义哲学 MAINSAIL 对 Naroff 的技术思维产生了极其深远的影响。该语言由斯坦福大学人工智能实验室(SAIL)的系统演变而来(SAIL 即 Stanford Artificial Intelligence Laboratory),最初由斯坦福大学生物系资助开发,目的是为了构建需要处理庞大复杂数据的大规模系统。当时 C 语言在大型系统构建上捉襟见肘,C++ 尚未问世,MAINSAIL 带来的突破极大反哺了正在艰难摸索的计算机辅助工程/设计(CAE/CAD)行业。 Naroff 强调,MAINSAIL 不仅仅是一门编程语言,更是一整套运行时(Runtime)环境。它本质上是基于模块(Module-oriented)的语言,血统更接近于 Simula、Modula 和 ALGOL,而非纯粹的面向对象语言。虽然面向对象的原教旨主义者可能会贬低它,但 MAINSAIL 凭借极其实用主义(Pragmatic)的工程设计脱颖而出。它彻底抛弃了类似 C 语言的静态链接步骤,完全通过运行时动态加载模块,并且所有模块都是自描述的(Self-describing),携带了丰富的运行时元数据(Metadata)。这些元数据被用于语言内置的垃圾回收机制(Garbage Collection)。 与此同时,MAINSAIL 保持了底层操控的灵活性,允许开发者直接获取内存指针。编译器会在编译时为每个模块打上“安全(Safe)”或“不安全(Unsafe)”的标签。在大型项目中,大部分模块属于安全模块,但在必要时开发者依然可以编写不安全模块去进行底层的位操作(Bit-twiddling)。此外,MAINSAIL 还内置了协程(Co-routine)机制,其运作形态类似于后世主流编程语言中的闭包/代码块(Blocks)。 ```mermaid flowchart TD accTitle: MAINSAIL 核心运行时架构与模块交互 accDescr: 展示 MAINSAIL 语言的动态加载、元数据支持及模块安全性隔离机制 subgraph RuntimeEnvironment ["MAINSAIL 动态运行时环境"] DynamicLoader["动态加载器 (无静态链接环节)"] GC["内置垃圾回收系统"] CoroutineEngine["协程机制 (Co-routines / Blocks)"] end subgraph ModuleSystem ["自描述模块系统 (带元数据)"] SafeModule["安全模块 (Safe Module)<br/>受类型系统与垃圾回收全权托管"] UnsafeModule["不安全模块 (Unsafe Module)<br/>允许直接指针操作与底层位运算"] end DynamicLoader -->|"按需动态载入"| SafeModule DynamicLoader -->|"按需动态载入"| UnsafeModule SafeModule -.->|"提供元数据 (Metadata)"| GC UnsafeModule -.->|"提供元数据 (Metadata)"| GC ``` - 渊源与背景:衍生自斯坦福 AI 实验室的 SAIL,由斯坦福生物系出资扶持,专为突破 C 语言在大型系统开发中的瓶颈而设计。 - 动态机制:去除传统 Link 步骤,依赖模块自描述元数据进行动态装载与垃圾回收。 - 兼顾底层控制:通过 Safe/Unsafe 模块机制,既保证整体系统的内存健壮性,又保留了底层直接操作硬件内存和位操作的能力。 ### [54:49](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=3289s) MAINSAIL 的起源与跨平台愿景 Naroff 讲述了 MAINSAIL 语言的背景。斯坦福大学人工智能实验室(AI Lab)开发了 SAIL 语言,随后斯坦福大学生物系聘请了从斯坦福拆分出来的 Xidak 公司的主要成员,致力于开发一种机器无关(machine-independent)的 SAIL 版本,这便诞生了 MAINSAIL。在 1980 年代初期,市面上面临着极度碎片化的工作站生态,从 Apollo(及其 Aegis 操作系统,后来被迫提供 Unix 仿真)到 Sun Microsystems,硬件与操作系统各不相同。软件公司迫切需要一种抽象层,实现“一次编写,到处运行”的跨平台移植能力。斯坦福生物系资助了 MAINSAIL 的早期研发,之后 Xidak 作为一家独立公司拆分出来,其总部巧合地设在帕洛阿尔托(Palo Alto)的 Deer Creek,几乎就在日后 NeXT 公司的隔壁。 Naroff 指出,尽管 MAINSAIL 具备开发大型可移植程序的卓越设计,但它从未在业界取得广泛的普及。然而,像 Cericor 这样的计算机辅助设计(CAD)公司却看中了它。在当时的 Cericor 看来,技术选型基本是在 C 语言与 MAINSAIL 之间做抉择。绝大多数像 Smalltalk 那样具备垃圾回收(Garbage Collection)特性的语言都诞生于学术研究环境,并不适合构建实际的商业产品;而当时的 C++ 尚处于起步阶段,仅是一个预处理器(cfront)而非原生编译器,远未成熟。Cericor 认为自己可以同 Xidak 紧密合作并获得个性化的技术支持,从而借助其动态运行时开发出先进的 CAD 工具。 - **主要工作站厂商竞争**:波士顿的 Apollo(Aegis OS)最初在工作站市场占据主导,随后 Sun Microsystems 凭借 Unix 强势崛起。 - **MAINSAIL 的核心诉求**:提供真正独立于硬件平台的抽象,满足开发大型、复杂、可移植系统的需求。 - **C++ 在 1980 年代初的局限**:缺乏成熟的原生编译器实现,语言规范仍在快速变化,业界对其商用信心不足。 ### [58:21](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=3501s) 惠普收购后的技术歧路与 Xidak 的困境 在惠普(HP)收购 Cericor 之后,这种技术路线遭遇了巨大阻力。惠普管理层对依赖一家小公司(Xidak)及其专有的 MAINSAIL 语言感到极度恐慌。虽然惠普有财力直接收购并注资 Xidak,但他们却选择了一项极其漫长且注定失败的工程:耗费五年时间试图将全部 MAINSAIL 代码重写为 C++。Naroff 对此批评道:“taking an application which was developed with garbage collection from the get-go and going to a system that isn't garbage collected just that alone is a showstopper... but then if you consider other showstoppers like no link dynamic dynamically loaded on the fly C++ wasn't very good at that and yeah oh it's just such a such a bonehead decision man.” 最终惠普在折腾了五年后彻底放弃了这个重写项目。 Naroff 借此反思了语言工具类创业公司的艰难处境。Xidak 拥有一流的编译器和运行时专家,其技术实力甚至让 Mentor Graphics 这样强大的行业巨头深感钦佩。但正如许多技术驱动型初创企业一样,Xidak 缺乏清晰可行的商业模式,最终走向倒闭。Naroff 提到,正如 Brad Cox 后来在访谈中所总结的那样,做软件工具本身就是一个艰苦的行业,而做编程语言工具更是难上加难。 ```mermaid flowchart TD accTitle: Cericor to HP Language Migration Attempt accDescr: Diagram showing HP's failed 5-year migration of Cericor CAD software from MAINSAIL to C++ due to architectural incompatibilities. subgraph S1["MAINSAIL 架构 (Cericor)"] M1["垃圾回收 (GC)"] M2["动态模块加载 (Dynamic Loading)"] M3["高级元数据与抽象"] end subgraph S2["惠普强制技术迁移"] C1["C++ 方案 (1980年代中期)"] C2["手动内存管理 (无 GC)"] C3["静态链接 / 缺乏成熟动态特性"] end S1 -->|"耗时 5 年重写"| S2 S2 -->|"架构冲突与无法调和的缺陷"| F["项目最终取消 (Canned)"] ``` ### [01:01:46](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=3706s) Cericor 的图形化电路设计软件与架构工作 Naroff 详细回顾了他在 Cericor 负责的具体技术工作。Cericor 的核心产品是一款交互式原理图捕获与仿真软件(Schematic Capture & Simulation)。用户可以在图形界面上放置 NAND 门等逻辑门元件,通过虚拟导线连接,并将设计打包成组件。最惊艳的特性在于实时电路仿真:屏幕上虚拟导线中流动的“0”和“1”逻辑电平会实时动态展示出来。Naroff 形容这一产品“非常性感、非常酷”,尽管它在面对像英特尔(Intel)这类顶级半导体大厂的超大规模需求时,扩展性与稳健性仍有待验证。 为了保证这种交互式 GUI 工具的可靠性,Naroff 开发了一套日志回放测试系统(Journaling System),能够完整记录用户的鼠标轨迹与菜单点击输入,从而在系统迭代演化时自动化重放回归测试。此外,由于 MAINSAIL 本身面向对象的能力有限,Naroff 参与并领导了基于 MAINSAIL 之上的面向对象架构建设。团队内部开发了一套名为“Cericor Development Language”(CDL)的专用 UI 声明语言,避免工程师使用原生 MAINSAIL 编写底层界面代码。Naroff 担任了底层基础架构(Infrastructure)团队的负责人,负责设计元数据机制、规范架构一致性并培训不断加入团队的惠普工程师。 - **交互式原理图仿真**:直观展示二进制逻辑信号在虚拟电路连线中的流动状态。 - **日志录制与回放(Journaling)**:捕获所有 GUI 交互事件,解决图形界面难以编写自动化回归测试的难题。 - **CDL 界面描述语言**:早于 NeXT Interface Builder 的早期尝试,通过领域特定语言抽象界面构建。 ### [01:06:25](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=3985s) 职业方向的转向与首届 OOPSLA 惠普完成收购后,Naroff 很快预见到项目在技术路线上的死局。收购后仅六个月,行业霸主 Mentor Graphics 便在俄勒冈州总部向他抛出橄榄枝并开出工作邀请。Naroff 在深思熟虑后拒绝了这份工作。他意识到自己不想再做“为硬件工程师构建软件工具”(software tools for hardware people),而是渴望做“为软件工程师构建软件工具”(software tools for software people)。他认识到自己本质上是一个软件人,而 Mentor 已经十分庞大稳固,并不真正需要他去改变什么。 Naroff 选择在惠普再留守一年,一边学习技术一边等待时机。恰逢 1986 年首届面向对象编程大会(OOPSLA)在波特兰召开,Naroff 代表公司参会。用他的话说,“机会就是运气遇到充分的准备”(opportunity is where luck meets preparation)。正是在这届里程碑式的学术与工业会议上,Naroff 结识了 PPI(后更名为 Stepstone)的创始人 Brad Cox 与 Tom Love,为他后续全面投身 Objective-C 乃至加入 NeXT 奠定了契机。 ### [01:08:31](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=4111s) 求职贝尔实验室受挫与加入 PPI 在首届 OOPSLA 会议上与 Brad Cox 和 Tom Love 进行简短接触后不久,Steve Naroff 便前往康涅狄格州的桑迪胡克(Sandy Hook)参加 PPI(Productivity Products International)的面试。但在与 PPI 建立联系之前,Naroff 最初心仪的去处其实是 AT&T 贝尔实验室,希望加入 Bjarne Stroustrup 的团队从事 C++ 的开发。贝尔实验室的大部分前沿研究位于新泽西州普林斯顿附近,那里风景优美,且离 Naroff 幼年长大的地方很近,能让他重返东海岸。 然而,当他尝试申请时,贝尔实验室几乎第一时间就回绝了他——因为他没有博士学位。“It was Bell Labs. Only PhDs need apply,” Naroff 描述道,当时贝尔实验室有着非博士不招的硬性门槛。在以往职业生涯中一直顺风顺水、处处被争抢的 Naroff 第一次尝到了被拒绝的滋味。虽然当时很受打击,但他并未因此冲动地跑去读博;事后回想,他反而庆幸这次拒绝:“Fortunately they rejected me, and yeah, I went to PPI. I had a pretty good interview and they made me an offer.”如果当时去了贝尔实验室,整个人生轨迹将完全不同。加入 PPI 让他得以回到东海岸陪伴父母,摆脱在盐湖城经历的文化冲击。夫妻俩在康涅狄格州买了第一套公寓住宅,当时的房贷利率高达令人咋舌的 14%。 - 贝尔实验室对软件工具研发团队有严格的学历偏好,非 PhD 学历者直接被拒之门外。 - PPI 坐落在康涅狄格州桑迪胡克,Naroff 对那里的优美自然风光留下了极深印象。 - 迁居桑迪胡克标志着 Naroff 正式从开发电路 CAD 应用转向专门为软件开发者打造底层基础设施工具。 --- ### [01:12:16](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=4336s) 初识 Brad Cox 与 Tom Love:愿景与实用主义的碰撞 Naroff 回忆了在 OOPSLA 上对 PPI 两位创始人的第一印象。Brad Cox 在研讨会(Panel)上表现得极其从容沉稳,言谈举止极具专业素养。但 Cox 当时宣传的重点并非 Objective-C 语言本身的语法特性,而是面向对象编程将引发的技术革命。Cox 当时出版了名作《面向对象编程:一种演化式方法》(Object-Oriented Programming: An Evolutionary Approach)。Naroff 坦言自己读完并没有被彻底倾倒,觉得书中的营销成分多于纯技术剖析,但这恰恰是 Cox 的过人之处:“It was clear that he had a knack for selling the vision. And he talked about the Industrial Revolution, and he talked about, you know, soldering ICs together, and there was something compelling about what he was saying at the time.” 相比之下,Tom Love 更多退居幕后负责商业运作。Love 同样是一位极富魅力的演说家,但他主要对接商业客户。巧合的是,搬到康涅狄格州后,Naroff 和 Love 住在同一个公寓园区,两人私交甚笃,Naroff 视其为良师益友。Naroff 当初选择 PPI,正是看中了他们既有高远的宏大愿景,又兼具面向现实的工程实用主义。在经历过 Cericor 与惠普因 MAINSAIL 过于激进导致的挫折后,Naroff 极度渴望一种渐进演化的技术路径:“The whole idea of making or evolving the C community to an object-oriented programming language was so desirable to me, because I had seen MAINSAIL take a more radical approach and I saw it fail.”他希望为真实世界的工程师打造脚踏实地的工业级产品,而非象牙塔里的学术玩具。 --- ### [01:16:19](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=4579s) 资本介入、Tom Love 离职与混乱的内部管理 Naroff 于 1985 年底正式入职 PPI。不久后风险投资机构注资,公司更名为 Stepstone。伴随着 VC 的进驻,联合创始人 Tom Love 被迫离开了公司。尽管 Love 本人后来谈及时并不完全认同自己是“被清洗出局”,但公司内部普遍认为这是风投施压的结果。Naroff 类比了 Steve Jobs 被驱逐出苹果的公案:管理层往往会将创始人架空到一个令其难以忍受的虚职上,迫使其自行离开,“so the result is the same.” ```mermaid flowchart TD accTitle: PPI Management Transition accDescr: Diagram showing the leadership transition and organizational fragmentation at PPI/Stepstone. subgraph Founders["Founding Leadership"] TL["Tom Love<br/>(Business / Outbound)"] BC["Brad Cox<br/>(Vision / ICpacks)"] end subgraph Shifts["VC Influx & Departures"] VC["Venture Capitalists Enter<br/>(Rebranded to Stepstone)"] TL -->|"Pushed out / Left"| Dep["Love Leaves Company"] VC --> Ken["Ken Hammer-Hodges<br/>(Ex-ITT Software Manager)"] end subgraph Engineering["Fragmented Dev Team (8-12 Engineers)"] SN["Steve Naroff<br/>(Objective-C Language Lead)"] Int["Interpreter Team"] IC["ICpacks Library Team"] end Ken -.->|"Lacked technical drive"| SN Ken -.->|"Hands-off"| Int Ken -.->|"Hands-off"| IC ``` 失去 Tom Love 对公司是一个巨大的打击。Love 极具外向开拓精神,曾凭一己之力促成了惠普实验室(HP Labs)等重要客户的订单。他离职后,软件研发团队陷入了严重的管理真空。当时 PPI 的软件开发人员大约只有 8 到 12 人。最初给 Naroff 签发录取信的软件经理离职后,公司从前 ITT 体系挖来了 Ken Hammer-Hodges 接管软件团队。但 Ken 缺乏推动底层软件研发的技术魄力;与此同时,Brad Cox 实际上已经将 Objective-C 语言的后续发展全盘移交给了 Naroff,自己转向了其他方向:“Brad pretty much handed the language off to me and decided that he was going to go work on other stuff.”整个研发团队各自为政:Naroff 独自操舵语言演进,有人在做解释器,还有几个人在维护 ICpacks 类库。Naroff 直言,与他之前经历过的两家井井有条的公司相比,当时的 Stepstone 几乎处于无人掌舵的混乱失序状态。 ### [01:21:54](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=4914s) Brad Cox 的研究孤岛与 Stepstone 初期的技术文档空白 在 Stepstone(原 PPI)内部,Brad Cox 正在尝试将代码块(blocks)作为纯库组件来实现,而完全没有提供语言层面的语法支持。这项研究工作并没有与具体的开发团队进行任何实质性的统筹与协调。在 Steve Naroff 的记忆中,Brad Cox 的办公室门平时总是紧闭的,“他就像是独立一人的研究所,而其余所有人都在搞开发工程”。虽然创始人钻研前瞻性方向无可厚非,但整个公司因此缺失了来自愿景型创始人的清晰技术指引。 面对 Objective-C 第一代和第二代原型实现中暴露出来的堆积如山的技术缺陷,Steve Naroff 选择埋头苦干。他在 Stepstone 的头六个月全耗在将代码移植到各种系统架构上。当时公司甚至没有一份关于该系统的架构设计或实现细节的正式文档,Naroff 不得不亲手把整套架构与实现逻辑文档化,以便团队能在有据可依的基础上做技术决策。在梳理过程中,他逐渐认清现有系统在设计上的千疮百孔。这与他在 Cericor 围绕 MAINSAIL 搞前沿面向对象架构设计的经历形成了强烈反差,让他一度觉得自己像是在“扫地打杂”,但他坚信这项技术背后潜藏着巨大的机会。 ### [01:24:09](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5049s) 早期 Objective-C 预处理器的原始状态与语言缺陷 当时的 Objective-C 根本算不上真正意义上的编译器,本质上只是一套初级的转换器(translator)或者带有特定触发规则的脚本。它并不会对 C 语言本身的语法进行深度解析,只是搜寻方括号等 Objective-C 消息语法片段,将其就地展开并替换成相应的 C 代码,保留其他原生 C 语言部分不加干涉,最后将混编后的 C 代码直接喂给底层的普通 C 编译器。 这种极为初级的转换机制导致它根本无法捕获最基础的编程错误。即便是最普通的方法拼写错误,它也无能为力。造成这一缺陷的核心原因不仅在于工具技术本身的不成熟,更在于当时 Objective-C 语言规范本身的缺失——系统完全没有显式接口声明(explicit interface declaration)的概念。如果开发者在消息表达式中不小心把方法名拼错了,转换器也只会盲目认定这就是该方法的真实名字并直接放行。在当时原本就极其缓慢的“编译—链接—调试”工作流中,这种静默失败给开发排错带来了极大的痛苦。 ```mermaid flowchart LR accTitle: 早期 Objective-C 原始代码转换流程 accDescr: 展示代码经过早期脆弱脚本转换,在结合 make 工具时因缓存失步而导致链接崩溃的过程。 subgraph Src["源码阶段"] A["Objective-C 混编源码<br/>(无接口显式声明)"] end subgraph Trans["朴素转换阶段"] B["文本级匹配脚本/转换器"] C["直接展开消息表达式<br/>(拼写错误直接放行)"] end subgraph Build["编译链接阶段"] D["中间 C 语言临时文件"] E["底层标准 C 编译器"] F["UNIX make 构建工具<br/>(文件依赖失步)"] G["生成损坏可执行文件<br/>(链接/运行时崩溃)"] end A --> B B --> C C --> D D --> E D -.->|"依赖感知失效"| F E --> G F --> G ``` ### [01:26:34](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5194s) 脆弱的构建链、风险投资者的冷遇与重写提议 除了无法检测语法错误,早期 Objective-C 转换器生成的代码在配合 UNIX 传统工具链(如 make 工具)时极其脆弱。Objective-C 从一开始选择兼容 C 语言,就意味着放弃了纯粹性,而为了融入 UNIX 生态使用 make,又引入了严重的工程妥协。当转换器生成中间文件时,make 经常无法正确识别哪些中间文件需要重新生成;结果经常是开发者链接并运行程序时瞬间崩溃,追查下去才发现是编译工具生成的中间文件管理失步。 针对这一系列乱象,Steve Naroff 与曾任职于 ITT 的工程师 Alan Watt 联名撰写了一份架构重构提案。他们提出了满足工业级软件开发所需的底线改进: - 引入基础的显式接口声明,让编译器能捕获最基本的拼写与类型错误; - 重写一个能够完整处理该语言语法的大前端编译器,彻底告别朴素的文本宏替换; - 确保生成的代码和中间文件具备高鲁棒性,与 make 等构建工具有序协同。 然而,这份从底层解决可靠性问题的提案却在 Stepstone 内部遭遇了阻力。公司的投资人完全从纯财务回报出发,难以理解“编译器为什么非要花钱去报错”,觉得无法报错只是小事一桩;而软件部门主管 Ken 又缺乏足够的技术声望与底气在管理层为工程师据理力争。 - “只要你声称自己拥抱 C 语言,你从纯粹性的角度来看就已经妥协了。”(Steve Naroff 谈及语言设计的妥协) - “在我看来,要不要修复基础问题,其显而易见的程度就像‘把 MAINSAIL 程序强行用 C++ 重写是开历史倒车’一样确定无疑。”(Steve Naroff 回忆与资方的分歧) ### [01:31:00](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5460s) NeXT 工程师来访与破局的关键信函 就在改革提议陷入僵局之际,NeXT 派出了两位核心工程师前往康涅狄格州 Sandy Hook 的 Stepstone 办公室:一位是操作系统专家 Steve Stone,另一位是刚从布朗大学毕业的青年才俊 Trey Matteson。NeXT 当时正在全力打造 NeXTSTEP 操作系统和开发工具,正是被转换器这一堆底层 Bug 折磨得最深的大客户。当他们读到 Steve Naroff 的提议时拍案叫绝,直呼这正是他们在 Palo Alto 开发系统时撞上的所有痛点。 Steve Stone 本身也是一名贝斯手,与音乐背景深厚的 Naroff 一拍即合。他们相约去纽约格林威治村畅聊音乐与小众乐队,私交甚笃。抓住这个破局良机,Naroff 在会后对他们说:“哥们,你们回到 Palo Alto 后,必须写一封正式信函,列出我们讨论的痛点以及为什么你们全力支持这份方案,好让我在 Stepstone 内部打赢这场政治仗。”两人回到加州后果真写下了这封极具分量的支持信,资方被迫让步,终于正式批准 Naroff 着手重构 Objective-C。 ### [01:32:56](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5576s) 静态陷阱与动态 Runtime 的核心分歧 获得全权授权后,Steve Naroff 开始彻底重构 Objective-C 编译器,并在此期间正式为语言引入了接口声明机制(`@interface`),同时着手根治运行时(Runtime)设计的致命漏洞。在此之前的旧架构中,Objective-C 使用一个全局选择器(Selector)池来管理所有方法名,各个目标模块(object modules)各自维护一张选择器表,并在链接时合并到全局池中。一旦某一个编译模块未能被及时重新编译,其旧表中错误的偏移和符号就会被链接器直接拷进全局池,导致整个符号表损毁,程序一运行就崩溃。Naroff 直言:“说白了,它早期就是一个原型玩具,而我的任务就是把它打造成一个利大于弊的真正生产级工具。” 在推动更具动态性的 Runtime 和启动期动态重定位时,Naroff 不仅面对资方的疑虑,还遭到了内部部分保守工程师的技术质疑,他们质疑在当时内存普遍只有 4MB 的硬件条件下,系统能否承担得起大规模符号数据表的动态重定位开销。Naroff 对此予以了坚决回绝,坚持动态语言绝不能用静态思维去生搬硬套: > “它是一门动态语言,就必须以动态的方式去实现。你绝不能用静态的方式去实现一门动态语言,绝对不行。” ### [01:35:04](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5704s) 运行时平衡、元数据与跨平台移植挑战 Steve Naroff 谈到了系统在动态性方面的取舍:通过读取包含各类属性的文本文件,系统能够在运行时动态生成数据结构。这构成了编译器、链接器与运行时环境之间极其微妙的平衡。“因为我曾在 MAINSAIL 这样拥有丰富运行时环境的语言中工作过,他们总是在试图理清那种微妙的平衡,所以我拥有一些相关的经验,不是作为编译器作者,而是作为语言用户。”这种经验同样涵盖了元数据(metadata)的构建。Objective-C 最初的元数据并不完整,Naroff 提议让描述类、实例和方法的元数据变得更加健壮,这一机制随着时间推移不断演进。 当 Hansen Hsu 问及移植语言时哪些平台较为重要,Naroff 列举了 HP-UX 和 Apollo 等主流工作站,但他移植过最晦涩古怪的机器是一台 Gould(一种类似 IBM 大型机克隆的小型机)。Naroff 回忆说,这台机器的汇编器极其诡异,它接收 VAX 助记符,却将其翻译为类似 IBM 的机器指令。这是因为当年的汇编器编写者图省事,直接从别处借用代码拼凑而成。 移植工作中真正的技术难点在于消息分发(message dispatch)的实现机制。分发调用通常有两种方式: 1. **基于汇编的单次跳转(速度优先)**:调用形如 `objc_msgSend` 的函数时,由于调用本身带有必须传递给目标对象的实参,这些参数必须留在当前的调用栈帧上。将消息分发参数与用户参数放在同一个栈帧中,必须借助一小段特定处理器的汇编语言来实现直接跳转。 2. **两阶段函数调用(可移植性优先)**:先让消息分发或查找例程返回目标函数的指针,然后再进行第二次常规函数调用。 ```mermaid flowchart TD accTitle: Objective-C 消息分发实现的两种路径 accDescr: 对比速度优先的汇编单跳转分发与可移植性优先的双重调用分发 subgraph FastPath["高效汇编方式(NeXT / Apple 采用)"] A1["调用 objc_msgSend"] --> A2["保留实参在同一栈帧"] A2 --> A3["汇编级 Jump 直接跳转目标方法"] A3 --> A4["单次调用开销,执行速度极快"] end subgraph PortablePath["纯 C 可移植方式(Stepstone 早期移植策略)"] B1["调用消息查找例程"] --> B2["返回目标函数指针 IMP"] B2 --> B3["发起第二次常规 C 函数调用"] B3 --> B4["两次函数调用开销,无需底层汇编"] end ``` Naroff 总结道,Stepstone 自身不拥有操作系统也不生产处理器,因此他常倡导的策略是:先用慢速且可移植的双重调用机制把系统跑通;如果某款机器卖得好,再写汇编进行深度优化。而在 NeXT 和苹果,由于掌控了完整的硬件与操作系统,自然会毫不犹豫地选择速度极致的单栈帧汇编方案。 --- ### [01:38:59](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5939s) Stepstone 的客户生态与小公司的生存困境 当被问及 Stepstone 如何获取 HP 和 NeXT 之外的客户时,Naroff 指出,当时的联合创始人 Tom Love 主要依靠在《Byte》杂志上刊登广告。“《Byte》杂志在当时受众非常广泛,所以我认为很多人都是主动找上门的。” 这也暴露了早期小型软件公司的典型困境:一旦有客户打来电话要求针对某种罕见处理器进行移植,哪怕订单只有一笔,资金匮乏的小公司也会被迫投入核心工程资源去开发移植版本。Naroff 感叹,他很难想象当年为了那一笔订单为 Gould 小型机做移植能卖出多少份。 在 Stepstone 内部,软件工程师受到相当程度的保护与隔离,管理层通常不希望开发者直接接触客户或了解商务谈判细节。Naroff 与 NeXT 的接触,很大程度上是因为他主动争取、突破这种限制才得以建立起来的。 - **获客渠道**:主要依赖《Byte》等主流计算机杂志的技术广告吸引技术人员主动接洽。 - **资源浪费陷阱**:初创团队容易为了单笔小订单,将稀缺工程师资源消耗在类似 Gould 小型机这种毫无规模效应的边缘平台上。 - **组织屏障**:Stepstone 管理层严格限制一线工程师与商业客户直接交流,技术人员通常被蒙在鼓里。 --- ### [01:41:03](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=6063s) NeXT 的技术阵痛与东西海岸的风投偏见 惠普(HP)最早接触 Objective-C 是在 HP Labs(惠普实验室)。研究人员在继承了庞大的 C 语言代码库后,看到广告希望尝试将 Smalltalk 的面向对象特性与 C 结合,因此采购属于轻量、随意的学术探索。然而,当 Stepstone 试图推销其“IC Packs”(软件集成电路包)构件库时,企业客户对无法获取源代码变得极其敏感和焦虑,销售难度陡增。 NeXT 引入 Objective-C 的契机,源于 NeXT 早期负责开发 AppKit 的核心工程师 William Parkhurst。他在寻找开发工具时(可能在 OOPSLA 会议上)被 Objective-C 所吸引,并推动团队采纳。在此之前,NeXT 曾考虑过使用 Pascal 或 Object Pascal,主管软件工程的 Bud Tribble 还曾顾虑 Objective-C 带来的运行时开销过大,讨论过是否直接基于 Display PostScript 编程。 然而,在重度使用 Objective-C 约六到九个月后,NeXT 工程师撞上了严重的语言缺陷与漫长的编译时间瓶颈,研发陷入巨大痛苦。“他们基本上直接联系了 Stepstone,对他们大发雷霆,并表示:‘我们做出了采用你们语言的重大决策,我们需要它朝这个方向推进,否则我们可能会重新考虑。’”Naroff 回忆说,当时 NeXT 工程师们群情激愤,甚至在公司里追问 William Parkhurst:“威廉,你到底把我们推进了什么坑里?” ```mermaid flowchart LR accTitle: NeXT 早期语言选型评估路径 accDescr: NeXT 在技术选型过程中从 Display PostScript 和 Object Pascal 最终收敛至 Objective-C subgraph Alternatives["早期评估备选方案"] D1["Display PostScript 直接开发<br>(Bud Tribble 担心运行时开销)"] D2["Pascal / Object Pascal"] end subgraph ChosenPath["最终选型路线"] O1["William Parkhurst 引入 Objective-C"] O2["深植于 Mach 内核与 C 生态"] O3["6-9 个月后撞上性能与编译瓶颈"] O4["逼迫 Stepstone 改造或自研接管"] end Alternatives -.->|"否决"| O1 O1 --> O2 --> O3 --> O4 ``` 当时 NeXT 的底层核心是 Mach 操作系统微内核,C 语言是整个系统的基石,放弃 Objective-C 回退是不可能的,唯一出路就是彻底修复并重塑这门语言。然而,Stepstone 背后的东海岸风险投资人完全无法理解 NeXT 的战略价值。风投们认为 HP Labs 才是响当当的大企业客户,而把 Steve Jobs 的 NeXT 仅看作一家不知前途如何的小初创公司:“HP Labs 只是拿这门语言随便玩玩,而 NeXT 是在用它构建一整套操作系统!这是我们千载难逢的机会,但他们完全没开窍。” Naroff 本人并非苹果电脑的信徒,早年一直使用大型机、小型机与工程工作站,一直视个人 PC 和 Mac 为“玩具”。但 NeXT 要打造一台“普通凡人也能使用的专业工作站”的愿景,深深吸引了他,促使他最终投身 NeXT 阵营。 ### [01:47:42](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=6462s) 精英机构认知失调与 Stepstone 对 NeXT 的轻视 Steve Naroff 引用了 Malcolm Gladwell 在 Google 举办的一场时长约 20 分钟的著名演讲,该演讲探讨了所谓的“精英机构认知失调”(elite institution cognitive disorder)。Naroff 认为 Stepstone 内部就严重患有这种认知失调症:在他们眼中,HP 是一家声名显赫、受人尊重的顶级精英大企业,而当时的 NeXT 不过是一家籍籍无名的初创公司。“在他们看来,HP 是一家精英机构,而当年的 HP 确实备受尊崇;至于 NeXT,不过是和我们一样的初创小公司罢了。” Naroff 进一步阐述了 Gladwell 的核心论点:许多学生沉迷于顶尖名校的光环,不惜抵押房产也要挤进名校攻读 STEM(科学、技术、工程、数学)或计算机专业,但最终却以失败告终。这种失败并非因为他们不够聪明,而是因为进入哈佛或耶鲁后,他们头一次跌落到班级后三分之一的梯队,心理上彻底被摧垮,误以为自己是个彻头彻尾的失败者。Gladwell 本人未曾就读名校,甚至自嘲愿意免费为 Google 做这场通常收费昂贵的演讲,正是因为自己潜意识里也被 Google 这种“精英光环”所吸引。Naroff 借此指出,Stepstone 的管理层正是因为盲目迷信 HP 这种老牌巨头的权威,才反过来彻底看轻了真正拥有革命性潜力的年轻客户 NeXT。 ### [01:50:02](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=6602s) 风投资本介入与脱离实际的“软件 IC”狂热 当 Hansen Hsu 问及风投资本(VC)进驻后 Stepstone 的演变时,Naroff 直言公司的内部文化本就不容乐观:缺乏清晰有力的领导,Brad Cox 长期埋头于自己的学术性研究,而空降的管理层则来自 ITT 这种官僚式传统巨头,完全没有 Naroff 此前经历过的两家初创公司那种饥饿感与拼搏进取的创业精神。当自以为比工程师更懂行的金融资本家接管话语权后,公司陷入了盲目扩张的泥潭。工程师和真实客户本应共同驱动技术迭代,风投却笃信“越多越好”的粗放逻辑,一味强推更多的“软件集成电路”(IC packs),完全无视现存的 IC packs 根本只是半成品。 Naroff 指出,自己后来在 NeXT 学到了一个至关重要的工程铁律:任何特定领域的 IC pack、Kit 或对象库,在没有至少两款真实应用程序的实战检验下,是绝对无法凭空设计成功的。如果只做了一款电子表格应用,只能证明该框架勉强契合电子表格,但一旦换成原理图捕捉(schematic capture)这类图形软件,现有的架构模型就可能彻底崩溃。Naroff 反驳了 Brad Cox 后来在受访时将失败归咎于“时代太超前”或“商业模式不成熟”的说法:“你可以随心所欲地去怪罪商业模式,但事实是技术本身根本不够过硬。”像 NeXT、Adobe 或 Lotus 这样开发专业级应用的严肃软件厂商,绝不可能在没有看到成熟 App 验证、且拿不到源代码的前提下,把公司的身家性命押在 Stepstone 闭门造车弄出来的对象库上。 ```mermaid flowchart TD accTitle: Stepstone 与 NeXT 架构设计方法对比 accDescr: 对比 Stepstone 缺乏实战检验的顶层设计模式与 NeXT 依赖真实应用程序闭环驱动框架迭代的模式。 subgraph StepstoneApproach ["Stepstone 的脱节开发模式"] direction TB VC["风投资本与管理层<br/>盲目追求组件数量"] --> Spec["凭空定义庞大的<br/>IC Pack 领域架构"] Spec --> Shelf["缺乏真实 App 验证<br/>且不开放源码"] Shelf -.-> Fail["专业客户(NeXT/Adobe)拒绝采用"] end subgraph NeXTApproach ["NeXT 的实战驱动开发模式"] direction TB App1["应用 1<br/>(如 Lotus Improv)"] & App2["应用 2<br/>(如 Interface Builder)"] --> Probe["极限实战场景检验"] Probe --> Craft["极致打磨基础框架<br/>(简单哈希、线性探测缓存)"] Craft --> DynamicKit["高可用 AppKit / Foundation"] end ``` ### [01:54:42](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=6882s) 闭门造车的面向对象架构与 NeXT 的极简工艺 Naroff 联想到网络上一场名为《面向对象编程很糟糕》(Object-Oriented Programming is Bad)的热门演讲。尽管他不赞同演讲者全盘否定封装性的极端观点,但演讲中一个形象的比喻让他深有共鸣:“用对象编程就像是在还没搞清楚这栋建筑到底是拿来干什么之前,就先在房子里砌满了隔墙。”Stepstone 以及后来的 Taligent 正是犯了这种致命错误:在完全不清楚上层应用具体需求的情况下,过早将庞杂抽象的底层架构固化。 在底层系统设计上,理论构想往往敌不过反复测量的工程实证。Naroff 举例说明: - **消息派发缓存机制**:甚至连最简单的对象查找与消息发送哈希表(message dispatch cache),都不能脱离具体场景纸上谈兵。Naroff 与 Bertrand Serlet 等人在 NeXT 早期尝试过五花八门的高级算法,但最终在 Objective-C 中胜出的,反而是世界上最简单的方案——利用方法选择器(selector)计算特定哈希值,并配合纯粹的线性探测(linear probing)。这种看似反直觉的最佳方案,必须经过大量构建、测量与匠心打磨才能得出。 - **孤立的单向协作**:Stepstone 缺乏开源社区那种高频反馈的迭代生态。例如 HP 曾试图游说 Stepstone 采纳其自研的垃圾回收器(garbage collector),HP 的态度只是傲慢地直接丢过来一套代码,完全不打算与其他客户共同验证适配。Naroff 笃定地指出,哪怕这套东西能讨好 HP,也绝对无法适配 NeXT 或其他实际生产环境。 - **公司溃败的根源**:Naroff 坦言自己尊重 Tom Love 与 Brad Cox,但 Stepstone 内部机能失调到了极点:“他们失败并不让我感到意外。核心概念没有错,但他们在商业执行上一败涂地,在技术执行上也一败涂地,这才是他们的致命死穴。”在只有寥寥数人的初创团队里,创始人若脱离业务现实,注定无法带领公司突围。 ### [01:59:51](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=7191s) 评 Brad Cox 的“软件集成电路”(IC-Pak)构想与 Stepstone 的执行溃败 Hansen Hsu 与 Steve Naroff 谈及 Stepstone 联合创始人 Brad Cox 著名的“Objectware”与“软件集成电路”(Software IC / IC-Paks)愿景——即把软件组件做成像硬件集成电路一样、在公开市场上流通买卖的黑盒零件。Naroff 承认,自己最初加入公司时确实在某种程度上被这个销售口号所吸引,但也抱有怀疑态度;然而在实际工作中,他根本无暇去深入思考其宏大意义,因为光是拯救摇摇欲坠的编译器和语言本身,就已经耗尽了他所有的精力。 Naroff 指出,Stepstone 的企业文化存在严重割裂,公司甚至变相鼓励不同技术线之间互不沟通。例如 Naroff 对 Objective-C 解释器有许多改进构想,并且他正在推动的语言级改动必然会影响到解释器,但管理层从未鼓励他参与解释器的规划;而那个解释器本身也是一个半生不熟、东拼西凑的产物。在组件销售模式上,Stepstone 坚持完全黑盒化、不提供源代码的策略,这在现实工业界中显得极为天真。企业绝不可能把自身的前途寄托在另一家没有源代码掌控权的公司手中。如果 Stepstone 真正深入从事过严肃的应用程序开发,就会在实战中尽早撞上这些壁垒。 ```mermaid flowchart TD accTitle: Stepstone 软件组件愿景与实际脱节分析 accDescr: 展现 Brad Cox 的软件 IC 理论假设与商业/工程落地现实之间的矛盾。 subgraph Theory ["Brad Cox 的宏大愿景"] V1["软件 IC (IC-Paks) 理论"] V2["公开市场销售黑盒组件"] V3["无需源代码即可像硬件芯片般组装"] end subgraph Reality ["工程与商业现实"] R1["底层编译器与语言极不稳定"] R2["客户拒绝将核心命运交给无源码黑盒"] R3["公司内部缺乏实际 App 开发实战经验"] end subgraph Outcome ["最终结果"] O1["内部研发各自为政、沟通割裂"] O2["投资人接管,商业模式无法闭环"] end V1 --> V2 --> V3 V3 -.->|"脱离实际"| R2 R1 --> O1 R2 --> O2 R3 --> O2 ``` - Brad Cox 的构想将软件组件比作五金或电子芯片,试图在不交付源代码的前提下出售二进制黑盒对象。 - Naroff 直言:“With components shipping software becomes pretty important because ultimately if there are non-trivial components companies don't want to put their future in another company's hands without control of the source code which is true for other stuff too but it's particularly true for components.” - 在 Stepstone 内部,工程师如同被蒙在鼓里的棋子,管理层与资方从未组织过任何开诚布公的全员会议来复盘公司为何无法盈利;而 Naroff 强调,真正健康运转的公司(如后来的 NeXT)在遇到瓶颈时,会把所有底牌摊在桌面上彻底清算。 --- ### [02:05:55](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=7555s) 乔布斯大闹鹿溪办公室:对 Tom Love 当面问责 随后话题转入 NeXT 为何选用 Objective-C 以及 Naroff 决定转投 NeXT 的导火索。NeXT 早期选择 Objective-C,是因为系统以 C 语言为基础,而在 C 之上构建一套类似于 Smalltalk 的动态消息传递机制极具吸引力;这与施乐帕洛阿尔托研究中心(Xerox PARC)的技术血脉不谋而合,且微小的运行时环境非常适合跑在配备 4MB 内存的 68030 芯片上。然而,NeXT 在初期同样有些天真,被 Stepstone 的宣传所打动,却不知道底层隐藏着巨大的技术缺陷。 在 Naroff 正式加入 NeXT 之前,他曾以顾问身份前往 NeXT 位于鹿溪(Deer Creek)的商务办公区,交付一套能够改善错误提示并生成更优代码的高级版 Objective-C 翻译器。当时 NeXT 处于极度保密状态,Naroff 被隔离在工程办公区之外,只在角落配了一台 Sun 工作站进行演示。当他向 NeXT 工程师展示成果时,Steve Jobs 突然走进了办公室门厅,与 Bud Tribble、NeXT 负责对接的技术接口 Steve Stone、Stepstone CEO Tom Love 以及 Naroff 站在一起。Jobs 当场对 Tom Love 严厉训斥,把 Stepstone 痛骂了一通。 - Jobs 对 Tom Love 态度极其强硬,当面发难表示 NeXT 在 Stepstone 身上押了重注,但对方根本无法交付合格的基础工具。 - Jobs 展现了惊人的技术切入能力,他把手下工程师反馈的编译器问题、运行时架构和报错机制逐一数落出来,听起来就像一名一线工程师在发号施令。 - Jobs 斩钉截铁地要求 Tom Love 必须全力支持 Steve Naroff 的工作,把资源集中投入到 Objective-C 语言基础设施与编译器上,而不是继续浪费在所谓的 IC-Paks 组件上。 - 在场目睹这一切的 Naroff 心生震撼,并深感折服:“Here's a CEO which has a clue my goodness what a difference from the venture capitalist now running StepStone this is a guy I could see working for.” - 相比于风险投资人治下空洞无物的 Stepstone,Jobs 清楚地意识到在没有打牢语言地基之前大谈上层建筑纯属空谈;不久后 Jobs 便越过 Stepstone 管理层,直接指示团队安排 Naroff 的入职面试。 --- ### [02:11:24](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=7884s) 独面乔布斯:一场充满挑衅与质问的高压面试 Naroff 接受邀请飞赴加州参加正式面试。面试日程排得极其密集,包括由负责编译器与链接器的 Kevin Enderby、William Parkhurst、Joe Capriati 组成的小组面试,随后是与 Steve Jobs 单独进行的 45 分钟面谈,接着与操作系统团队(OS Group)共进午餐,下午则接受 Avie Tevanian、Peter King、Mike DeMoney 以及 Bud Tribble 等一众骨干核心长达数小时的车轮面试。 在预定与 Jobs 单独面谈的时间段,Kevin Enderby 刚结束上一场面试,正与 Naroff 讨论技术细节。Jobs 走进会议室时,Enderby 本想识趣退场,但 Jobs 却出人意料地示意 Enderby 留下来旁听。随后,Jobs 拿过 Naroff 的个人简历,露出一脸不屑与鄙夷的神情,开始用极其严苛、极具对抗性的语气逐项质问 Naroff 过去的职业生涯选择与技术资历。 - Jobs 的风格不是按常规套路提问,而是直接向求职者发起正面交锋,质疑其过往经历的含金量,借此测试对方在心理高压下的应变能力与对自身技术的底气。 - 坐在旁边的 Kevin Enderby 感到如坐针毡;多年后每次与 Naroff 重逢,Enderby 都会津津乐道那场令人窒息的面谈:“Oh man, that was tough sitting through that.” - 面对 Jobs 的挑衅与轻蔑,Naroff 没有退缩妥协,而是据理力争地全面为自己的履历和工程成就辩护,坦然阐述自己在编译器与动态运行时领域解决的实际难题。 ### [02:13:36](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8016s) 乔布斯的严苛面试与编程即艺术的共鸣 面试深入到 Steve Naroff 之前参与的两家初创公司,以及他是如何流落到 StepStone 这样一家乔布斯打心眼里看不起的公司。叙述完这些经历后,Naroff 察觉到乔布斯整个人立刻放松了下来。Naroff 坦言自己当时或许不够成熟,没能立刻看透乔布斯的意图,但事后很快就想明白了:乔布斯在走进会议室之前,心里其实就已经确信 Naroff 应该加入 NeXT。之所以还要摆出极其严苛的架势进行考问,是因为乔布斯看出了他的领导潜质,“他想看看我是否会在他的质问下缩成一团死掉,他想看看这家伙能不能捍卫自己、捍卫自己的想法,还是会直接退缩萎靡”。 得益于在纽约的生活经历,加上长期在多支乐队演奏、习惯了同各色各样的人打交道,Naroff 并没有被吓倒,反而兴致勃勃地向乔布斯大谈自己做过的各种项目。当 Naroff 聊到自己如何看待“编程是一门艺术”、编程与音乐的内在关联,以及这一切是如何将他引向当下的 NeXT 时,乔布斯被彻底打动了。乔布斯内心深处对热爱音乐的人有着强烈的亲近感,而且他自己也坚信编程就是艺术。两人在那场会面中建立起了一种知己般的共鸣,不仅彻底敲定了录用,也为 Naroff 日后在公司的长远发展奠定了基石。随后,Kevin 待了约 15 分钟便先行离开,乔布斯和 Naroff 又聊了一会儿。当天中午,Naroff 与操作系统团队一起在 Palo Alto 的“小花园”(Little Garden)中餐馆吃午餐面试。那是当时硅谷最酷的聚会场所,堪称整个技术圈的微缩景观:Sun 正在迅速崛起,NeXT 也势头正盛,坐在餐桌旁听着四周其他桌顶尖工程师的交谈十分有趣,整个圈子紧密交织。 - 乔布斯的面试风格:故意施加巨大压力,以此测试候选人是能够坚持捍卫观点,还是会当场崩溃。 - 音乐与技术的交汇:Naroff 的管乐演奏背景与“编程即艺术”的哲学,与乔布斯的个人审美产生极强共鸣。 - Little Garden(小花园中餐馆):20 世纪 80 年代末 Palo Alto 顶尖技术人才(包括 Sun 和 NeXT 工程师)频繁出没的非正式交流圣地。 --- ### [02:16:05](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8165s) StepStone 的诉讼威胁与版权释疑 回到东部后,NeXT 很快向 Naroff 发出了录取通知(offer)。然而当他向 StepStone 提出辞职时,公司管理层勃然大怒,甚至威胁要起诉他,决不同意他跳槽去为乔布斯的 NeXT 工作。当时 Naroff 只有 27 岁,人生中从未遭遇过法律诉讼的威胁,也根本没有足够的财力聘请律师打官司。他用高达 14% 的房贷利率购置了一套非常普通的公寓,一想到房子可能会被 StepStone 申请财产留置权查封,心里就十分害怕。于是他给乔布斯打电话直言:“听着,他们威胁要告我,你必须帮我摆平这件事,否则我没法过去入职。” 乔布斯随即指示 NeXT 的法务负责人 Gary Moore 介入处理,Gary 仅用了几天时间就将争端彻底化解。从法律和商业逻辑来看,StepStone 的起诉威胁完全站不住脚:NeXT 早就全资购买了 Objective-C 的完整源代码授权(full source license),拥有全部源码的使用权;Naroff 既没有带走 StepStone 的任何 ICpak 商业库代码(他本身也没参与其研发),也不涉及任何侵权问题。在语言层面,由于 NeXT 已经买下源码并准备自主研发全新的运行时(runtime),完全不使用 StepStone 的运行时。 Naroff 指出,那时的商业认知还不成熟,如今大家早已明白公司并不能“拥有”员工。只要没有擅自带走没有授权的代码,工程师完全有权带着自己对这门语言的专业知识离开。当时执掌 StepStone 的是 Dennis Cisco,Naroff 认为如果 StepStone 足够明智,理应退一步顺水推舟:“太棒了,我们不用在语言本身上投入资源了,让 NeXT 去推动语言演进,我们专注于自己的 ICpak 策略。”但当时 StepStone 自身经营状况混乱、高层陷入恐慌,根本无法理性思考。Naroff 感慨道,如果当年 27 岁且囊中羞涩的自己去这样劝告 Dennis,对方只会摆出“我又老又富有,你又年轻又穷,凭什么来教我做事”的傲慢姿态。这也反衬出乔布斯令人折服的特质:“你有多少钱,或者你有多大年纪,这些从来都不会进入他的考量;他在乎的是,你有什么想法。” ```mermaid flowchart TD accTitle: StepStone 离职纠纷与 NeXT 法律化解流程 accDescr: 展示 Naroff 从 StepStone 辞职遭到诉讼威胁,后由 NeXT 法务利用全源码授权顺利化解的过程。 subgraph Dispute ["StepStone 的阻挠"] A["Naroff 接受 NeXT Offer 提出辞呈"] --> B["StepStone 恐吓起诉<br/>威胁对其房产申请留置"] B --> C["Naroff 向乔布斯求助:<br/>不解决官司无法入职"] end subgraph Resolution ["NeXT 介入解决"] C --> D["乔布斯指派法务 Gary Moore 出面交涉"] D --> E["核查授权权益:<br/>NeXT 已购得 Objective-C 完整源码授权"] E --> F["厘清知识产权界限:<br/>未携带 ICpak 代码<br/>NeXT 计划自研独立 Runtime"] F --> G["数日内化解纠纷,顺利入职"] end ``` --- ### [02:19:32](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8372s) 家庭变故与 NeXT 投弹冲刺阶段的狂热 法律风波平息后,搬迁入职的过渡期却遭遇了一场巨大的个人不幸。当时夫妇二人计划搬往湾区(先住在桑尼维尔),而 Naroff 的妻子已经怀孕。就在他们准备启程搬家前夕,产科医生突然打来电话,称在超声波检查中发现了异常,胎儿的发育出了严重问题,最终他们失去了这个孩子。在跨国搬迁、更换工作的剧烈变动期承受丧子之痛,对夫妻两人来说是一次极其沉重的心理打击。 但现实没有给 Naroff 太多疗伤喘息的时间。大约在 1988 年 8 月,他正式跨入 NeXT 紧绷的高压工作环境中。彼时全公司都处于一种极度狂热的状态:NeXT Computer(即 NeXT Cube)的发布会已经定在 1988 年 10 月 12 日,距离他入职只剩下短短两个月。在公司内部,这段最后的冲刺期被称为“投弹航线”(the bomb run)——这个词据说是 Bud Tribble 发明的,形容团队顶着一切压力向最终发布目标呼啸推进。作为一个初来乍到的新人,面对的是尚未成型的硬件平台、满地尚未拼凑完整的软件碎片,局势动荡混乱却又令人无比兴奋,因为 NeXT 当时正是整个科技圈绝对的舆论中心。Naroff 还在访谈中感叹,访谈当天正好是 10 月 8 日,乔布斯在 2011 年的上一周去世,而 NeXT Cube 发布的三十周年纪念就在本周后几天,恰好夹在这两件人生大事之间。 - 入职时间:1988 年 8 月前后(5 月面试并经历数月交接与搬家)。 - 关键节点:1988 年 10 月 12 日,NeXT Computer(NeXT Cube)正式公开亮相。 - 团队术语:“投弹航线”(bomb run),指产品发布前全员顶住高压、背水一战的最后冲刺阶段。 --- ### [02:22:29](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8549s) 入职操作系统组与攻克编译器的“救火英雄” Naroff 入职后的初始职位是操作系统组的一名普通软件工程师,向操作系统经理 Mike DeMoney 汇报。当时操作系统团队刚吸纳了 Avie Tevanian(Avie 比 Naroff 早几个月加入,面试过 Naroff,但当时还未升任管理层,专注于 Mach 内核系统开发)。整个操作系统团队都在一间开阔的大平层里办公,NeXT 当时根本没有独立的“开发工具组”。在 Naroff 到来之前,负责维护和魔改编译器的是 Steve Stone。Steve Stone 本质上是一名操作系统工程师,虽然是个热爱钻研的全才,但他渴望尽快摆脱编译器的包袱。NeXT 软件部的其他工程师也迫切希望 Stone 脱手,因为随着各模块开发推进,编译器 Bug 堆积如山,而 Stone 既要忙于底层系统,又要抽业余时间修编译器,早已力不从心。 Naroff 刚坐下接手的第一项紧急任务,就是修复 StepStone 的 Objective-C 转译器(translator)遗留的大量缺陷,并确保其与刚刚引入的 GNU C 编译器(GCC)良好协同。在此之前 Naroff 甚至从未接触过 GCC,对 Richard Stallman 的自由软件基金会(FSF)产品一无所知。当时 GCC 1.0 版本才在 1987 年发布,问世仅一年左右,代码本身也存在不少 Bug。在最初的三到四周里,Naroff 集中火力两头排查,既修转译器 Bug 又修早期 GCC 的 Bug。 Naroff 扎实高效的排错能力迅速引爆了内部团队的狂喜。当时负责开发 Workspace Manager(即 NeXT 版的 Finder 文件管理器)的工程师 Chris Franklin 甚至给几乎整个软件团队群发了一封公开感谢信,盛赞 Naroff 修复这些编译器 Bug 极大地挽救并提升了他们的生产力。在过去 StepStone 的压抑环境下,Naroff 想要做任何有价值的技术创新都会遭到百般阻挠;而在这里,仅仅是帮大家把编译器修到稳定可用,就受到了“摇滚明星”一般的崇拜,这让他感受到了被强烈的需要与认可。更令他意外的是,NeXT 当时实行内部公开透明的薪酬与股票期权机制。在看到 Naroff 卓越的救火表现后,Chris Franklin 和其他几个深受其益的业务端同事主动查阅了他的薪资数据,并自发向管理层游说争取,在 Naroff 入职极短的时间内就成功为他争取到了大幅加薪和股权激励提升。 - 汇报线:Naroff 最初归属于 Mike DeMoney 领导的操作系统团队,与 Avie Tevanian 同组。 - 前任维护者:Steve Stone(主业为操作系统工程师,兼职维护编译器)。 - 工具链现状:StepStone 转译器配合刚刚发布一年的 GCC 1.0(1987 年发布),二者均不稳定,缺陷频发。 - 公司文化特色:薪资与股票信息透明公开(open salary structure),业务伙伴可根据实际贡献直接向上层游说为同事加薪。 ### [02:26:50](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8810s) NeXT 的工程文化与摆脱 Stepstone Runtime 的自主研发 在加入 NeXT 之后,Steve Naroff 感受到了前所未有的工程氛围与文化认可。那种努力被看见、被赞赏的环境彻底激发了他的创造力,让他更加全身心地投入到极致的技术攻坚中。Naroff 动情地评价道:“It was honestly the best environment and culture I had ever experienced you know so this just led to me being even that more devoted to doing crazy great things I'm like wow it's being recognized and and so I credit you know a lot of the cool stuff I did over the years with providing an environment that was nurturing and appreciative of things which is surprisingly hard to find I think in any field I was really lucky really fortunate.” 随着团队步入正轨,首要任务就是彻底摆脱对 Stepstone 公司 Objective-C 运行时(Runtime)的依赖。Naroff 开始着手编写一套专门针对 Mach 微内核与系统特性进行深度优化的全新替代运行时。当时整个 NeXT 负责编译器工具链的只有两个人:Kevin Enderby 负责汇编器、链接器和加载器(assemblers, linkers, loaders),而 Naroff 则负责前端、中间端以及与 GCC 的集成。 针对当时的硬件条件,两人展开了紧密的协同优化。NeXT 使用的 Mach-O 二进制文件格式拥有非常独特且有趣的数据与元数据组织能力。Naroff 思考如何利用链接器为 Objective-C 提供更强的底层支撑,他们设计了高度适配 Mach 特性的元数据组织方式,将内存分页开销(paging)降至最低,并保证所有运行时数据都能被极快地访问。Naroff 强调,对于 Objective-C 这种动态语言而言,掌控链接器至关重要。虽然动态语言往往倾向于把大量事务推迟到运行时处理,但考虑到当时的机器硬件配置和内存都相对有限,他们必须在编译期与链接期尽可能分担更多工作,将运行时负担压缩到最小。这一阶段的演进重心主要是底层的具体实现与性能榨取,而非扩展语言语法本身。 ```mermaid flowchart TD accTitle: 编译期与链接期协同优化元数据架构 accDescr: 展示 GCC 前端生成元数据,经链接器重组为紧凑 Mach-O 段以优化换页与性能 subgraph CompilerStage ["GCC 编译器前端 (Steve Naroff)"] A["Objective-C 源码"] --> B["解析类与元数据"] B --> C["生成未优化的元数据结构"] end subgraph LinkerStage ["链接器与 Mach-O (Kevin Enderby)"] C --> D["按 Mach-O 段组织重排元数据"] D --> E["合并与重定位符号"] end subgraph RuntimeStage ["优化后的 Mach 运行环境"] E --> F["降低内存换页开销 (Paging)"] F --> G["极速轻量的 Objective-C 动态执行"] end ``` - 当时 NeXT 编译器工具链团队仅有两人:Steve Naroff 主导 GCC 前端、中间端和整体集成;Kevin Enderby 主管汇编器、链接器与加载器。 - 架构优化的核心是通过 Mach-O 格式对 Objective-C 的元数据(Metadata)进行重构,最大程度减少虚拟内存分页交换(paging),使动态语言在有限的硬件配置上兼备灵活性与高性能。 --- ### [02:29:29](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=8969s) Interface Builder 的需求与 Categories 特性的诞生 在专注于底层实现的时期,语言层面也出现了一个早期的重大例外——Categories(分类)特性的诞生。当时正在主导图形化开发工具 Interface Builder 的 Jean-Marie Hullot 找到了 Steve Naroff。Jean-Marie Hullot 当时并不属于某个刻板划分的正式小组,而是 NeXT 扁平软件团队的重要一员。他向 Naroff 展示了自己为了让 Interface Builder 运转起来而在底层施展的“黑魔法”。 Hullot 当时依赖的是一种被称为“Posing”(类伪装,即运行时方法 `poseAs:`)的动态技巧。这种机制是一种运行时 Hack,能够在元数据链条中强行将一个类插入到另一个类的前面,从而欺骗运行时去执行特定的拦截与扩展代码。尽管这个做法构思巧妙,但 Naroff 敏锐地意识到,Interface Builder 是 NeXT 系统的核心王冠(“the crown jewel”),绝不能将其长久维系在脆弱的底层 Hack 基础之上。Naroff 坚定地认为:“Making sure it didn't depend on hacks but dependent on language features explicitly is sort of important so we developed categories for that.” 于是,为了在不修改原始类源码且不破坏继承体系的前提下干净地为现有类添加方法,Naroff 在 Objective-C 中正式引入了 Categories 语法与机制,使 Interface Builder 的动态加载和扩展获得了稳固、原生的语言级支持。 - **类伪装机制(Class Posing)**:Jean-Marie Hullot 原先通过在元数据中强行拦截类的方法欺骗运行时,以满足 Interface Builder 动态注入界面的需求。 - **Categories 特性的定位**:Naroff 为避免让 NeXT 的核心工具 Interface Builder 长期依赖这种 Hack 机制,特意扩展了 Objective-C 语法,确立了 Categories 这一语言特性。 ## Notable quotes > [27:36](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=1656s) It's that part of the rigor and art is missing today and encourages a lot of sloppy sloppy work, sloppy programming. — Steve Naroff > [01:32:56](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5576s) 你绝不能用静态的方式去实现一门动态语言,绝对不行。 — Steve Naroff > [01:26:34](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=5194s) 只要你声称自己拥抱 C 语言,你从纯粹性的角度来看就已经妥协了。 — Steve Naroff > [01:54:42](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=6882s) 用对象编程就像是在还没搞清楚这栋建筑到底是拿来干什么之前,就先在房子里砌满了隔墙。 — Steve Naroff > [01:50:02](https://www.youtube.com/watch?v=ljx0Zh7eidE&t=6602s) 你可以随心所欲地去怪罪商业模式,但事实是技术本身根本不够过硬。 — Steve Naroff ## Mentioned Steve Naroff, Hansen Hsu, Alan Kay, Craig Gracie, Doug Lea, Brad Cox, Tom Love, Steve Jobs, Steve Stone, Trey Matteson, Kevin Enderby, Bud Tribble, William Parkhurst, Avie Tevanian, Bertrand Serlet, Jean-Marie Hullot, Chris Franklin, Mike DeMoney, Gary Moore, Richard Stallman, Computer History Museum, SUNY Oswego, HHB-Softron, Cericor, Hewlett-Packard, Xidak, PPI, Stepstone, NeXT, Apple, AT&T Bell Labs, Mentor Graphics, IBM, Burroughs, Apollo, Sun Microsystems, MAINSAIL, Objective-C, C++, Pascal, Fortran, GPSS, Smalltalk, Simula, GCC, NeXTSTEP, Interface Builder, Mach, Mach-O, Display PostScript, Scientific American, Byte ## Video description Interviewed by Hansen Hsu on 2018-10-08 in Mountain View, CA X8800.2019 © Computer History Museum Steve Naroff was born in Poughkeepsie NY, 1961, of Ashkenazi Jewish parentage. His father was a jazz musician, conductor, and educator. Naroff’s childhood was spent in the Bronx, and later in the Spring Valley suburbs of New York where his father taught high school music. Naroff began playing classical clarinet at the age of six, and later jazz saxophone. Naroff received his degree in Computer Science from SUNY Oswego in 1983, with a minor in Music. His first job out of college was at Henckels, Haas & Brown (later HHB-Softron), working on Computer Aided Design and Test systems, where he had his first exposure to Unix and C. After reading about Smalltalk in Alan Kay’s 1977 Scientific American article “Microelectronics and the Personal Computer,” Naroff decided to move to Cericor in Salt Lake City, where he lead the design of graphical circuit design systems, using the language MAINSAIL, which used a dynamic runtime like Smalltalk. Naroff stayed on for a year after HP’s acquisition of Cericor, but eventually left after disagreeing with HP’s decision to port the MAILSAIL-based product to C++, which lacked the dynamic runtime. After meeting Brad Cox and Tom Love at an OOPSLA conference, Naroff joined their startup PPI in 1986, which was later renamed Stepstone. Naroff’s first task was to port the Objective-C translator to various platforms including HP-UX and Apollo, and documenting the design and implementation. After NeXT became a user of Objective-C, Naroff became the main engineer fixing Objective-C for NeXT’s needs, which he felt was not given sufficient attention at Stepstone. By 1988, Naroff had decided to join NeXT outright. At NeXT, Naroff integrated Objective-C into the GNU C Compiler, integrated C++ with Objective-C in GCC to support Lotus’ Improv spreadsheet, and added the “categories” feature to help support the graphical Interface Builder development tool. Naroff became the manager of NeXT’s Development Tools team, leading the development of an Objective-C parsing framework called DevKit, and collaborating with Bertrand Serlet and Blaine Garst on adding the “protocols” feature to Objective-C. Naroff took a break from NeXT in 1994, working at IBM evaluating various object-oriented platform plays. Naroff returned to NeXT in 1995 to create its Objective-C to Java bridge. After NeXT’s acquisition by Apple, Naroff became Apple’s Director of Java technologies and developer tools, driving Apple’s Java strategy through its transition from Mac OS 9 to OS X, merging NeXT and Apple’s developer tools teams, and managing Apple’s relationship with Metrowerks, a key third party tools developer. Naroff stepped down from management in 2002 to develop Xcode, Apple’s Integrated Development Environment (IDE), led development of Objective-C 2.0 from 2005-2007, and led the development of the LLVM/Clang C compiler front-end from 2007-2010. * Note: Transcripts represent what was said in the interview. However, to enhance meaning or add clarification, interviewees have the opportunity to modify this text afterward. This may result in discrepancies between the transcript and the video. Please refer to the transcript for further information - http://www.computerhistory.org/collections/catalog/102717385 Visit computerhistory.org/collections/oralhistories/ for more information about the Computer History Museum's Oral History Collection. Catalog Number: 102717386 Lot Number: X8800.2019 [Source](https://www.youtube.com/watch?v=ljx0Zh7eidE)

Source quotes

[27:36] Steve Naroff: It's that part of the rigor and art is missing today and encourages a lot of sloppy sloppy work, sloppy programming. [92:56] Steve Naroff: 你绝不能用静态的方式去实现一门动态语言,绝对不行。 [86:34] Steve Naroff: 只要你声称自己拥抱 C 语言,你从纯粹性的角度来看就已经妥协了。 [114:42] Steve Naroff: 用对象编程就像是在还没搞清楚这栋建筑到底是拿来干什么之前,就先在房子里砌满了隔墙。 [110:02] Steve Naroff: 你可以随心所欲地去怪罪商业模式,但事实是技术本身根本不够过硬。

Source quotes

[86:34] Steve Naroff: As soon as you say you're embracing C, you're compromising from a purity standpoint. [92:14] Steve Naroff: It's a dynamic language, it has to be implemented dynamically—you don't implement a dynamic language statically, you just don't. [119:51] Steve Naroff: Ultimately, if there are non-trivial components, companies don't want to put their future in another company's hands without control of the source code

Original transcript

[0:09] the day is October 8th 2018 [0:13] I am Hampton sook here at the center [0:16] first off her history here at the [0:17] Computer History Museum and I'm here [0:19] with Steve Nara welcome great to be here [0:23] so it's starting out where and when were [0:27] you born [0:27] so we've actually born in March of 1961 [0:31] implicit see New York my parents were [0:35] there briefly soon after I was born we [0:38] actually moved to the Bronx in New York [0:41] where I spent the first six seven years [0:43] of life oh wow [0:45] and what's your family's background [0:47] ethnically so my dad my dad's side of [0:51] the family his dad migrated from Odessa [0:54] Russia [0:55] so there's on my dad's side Russian [0:58] descent and on my mom's side hungry [1:02] Austria so and I guess in terms of sort [1:07] of sort of our heritage we consider [1:09] ourselves Ashkenazi Jews so and what [1:15] what did your parents do my dad was a [1:19] professional musician and then educator [1:21] he toured with the Navy band for four [1:26] years during the Korean War and then [1:29] after that received a master's degree [1:30] from Manhattan School of Music and plays [1:34] tenor sax mainly jazz but it is also a [1:38] fabulous conductor and has written a [1:42] book on jazz improvisation in the 80s [1:44] that was used by many universities so [1:46] he's uh he's just a heavyweight in the [1:49] jazz community and is 85 and still plays [1:52] with groups in in Florida so it's it's [1:55] pretty amazing and he was my music [1:59] teacher so I started playing the [2:01] clarinet at at a young age and did a lot [2:05] of work with him on on music right which [2:10] became influential later on yeah and [2:13] your mother was stayed at home she she [2:16] was a homemaker she also did some [2:18] miscellaneous administrative jobs for [2:20] companies in the area [2:22] was always busy but my father was the [2:26] main breadwinner so to speak in the [2:30] family and he also had a big private [2:33] following of students so he he taught at [2:36] school during the day and then at night [2:38] he had kids coming to the house for [2:40] private lessons quite often [2:44] was a family religious not really we we [2:49] had very religious grandparents and [2:53] great-grandparents because they were [2:56] more first-generation and I was bar [2:58] Mitzvahed when I was 13 basically to [3:02] make the grandparents happy but religion [3:06] wasn't a big part of my life you know we [3:09] would do some of the holidays and [3:12] observe traditions but overall I [3:15] wouldn't consider ourselves religious [3:17] but learning enough Hebrew to actually [3:20] do the bar mitzvah was definitely [3:22] stressful it was a reformed temple it's [3:28] interesting the area we grew up is now [3:30] inhabited by very religious Jews Hasidic [3:34] Jews that work in New York City the town [3:38] we actually settled in was a place [3:40] called Spring Valley which is a very [3:43] nice suburb about 30 miles outside New [3:46] York City and it's quite a religious [3:48] area now Wow what was the community like [3:56] well it was you know from the complain [3:59] compared with the Bronx where we were in [4:01] an apartment living [4:02] we were like very close to the subway [4:05] the whole apartment would shake when it [4:08] would drive by it was very quiet very [4:12] suburban you know big lot certainly by [4:18] California standards I think we had like [4:21] an acre of land and I would work on a [4:24] lot with my dad and you know big pool [4:27] just just a beautiful suburb and the [4:31] schools were exceptional there which was [4:34] one of the reasons my [4:36] moved us away from the city and after [4:38] the suburbs which was very common in the [4:41] day and you know for us it wasn't just [4:44] about him wanting better schools for his [4:46] kids but it was him wanting a better [4:48] place to work as an educator that the [4:52] schools in New York were rough my dad [4:56] actually I guess I should go back and [4:58] mention he grew up on East a hundred and [5:01] fifty which is Harlem in in New York he [5:05] grew up in a very tough part of New York [5:08] and music aside from him being drawn to [5:12] it and loving it music was a way out of [5:15] the tough projects and also a way to get [5:19] respect from all the people there so [5:22] because it was a really rough rough [5:23] place right yeah Wow do you have any [5:30] siblings sister Debbie she still lives [5:33] in Ramsey New Jersey which is close to [5:37] where we grew up and her husband that [5:41] she actually went to the same schools I [5:43] did and she met her husband there like I [5:46] met my wife there so we both attended [5:49] Oswego which I'm sure we'll talk about [5:51] later and and we both met our spouses [5:55] there any formative experiences as a [6:03] child well you know because a clarinet [6:08] was put in my mouth at the age of six [6:10] and and my father was you know somewhat [6:15] of a disciplinarian when it came to [6:17] music and an education most of its [6:22] centered around music but I played [6:26] baseball I was a pitcher did other [6:30] things but yeah but most of it was was [6:34] music and early on most of it was [6:38] classical music so by the time I was in [6:42] ninth grade I was playing the Mozart [6:44] clarinet concerto which was considered [6:46] one of the more difficult pieces for the [6:48] instrument [6:49] being graded annually at the New York [6:52] misma would would judge you and write up [6:55] all kinds of critique on your playing [6:58] and so yeah by 9/9 grade i was a pretty [7:04] established classical clarinetist yeah [7:08] and around transitioning from ninth to [7:12] tenth grade I decided that classical [7:16] music wasn't really my calling [7:18] it was very highly structured and it [7:21] didn't provide that much freedom that I [7:24] was looking for so I switched over to [7:26] tenor sax and gravitated much more to [7:29] jazz and and and that carried on for the [7:32] rest of my college I pretty much stopped [7:36] playing clarinet and just focused on sax [7:38] and jazz and something I enjoyed more [7:41] but but clarinet was a great predecessor [7:45] to the sax they're very similar in [7:46] strikes yeah what what kinds of books [7:51] did you mean you know because the music [7:55] was at such a young age I was listening [7:58] and reading music and just everything [8:01] music and when it came to reading I read [8:05] the stuff that the teachers required in [8:07] school but when I was you know looking [8:10] to just unwind it was much more around [8:12] music and even you know even magazines [8:17] you know at the time Mad Magazine was [8:20] like a huge thing growing up or National [8:22] Lampoon so when it came to you know just [8:25] having fun it was music and magazines [8:29] and not so much reading serious [8:32] literature which which is interesting [8:34] because my daughter actually at a very [8:38] young age I remember picked up Lord of [8:41] the Rings [8:42] and and read it all and like wow where [8:45] did that come from [8:48] and even my daughter actually had an [8:51] affinity for the Merc medical manual and [8:54] would read that also yeah it's like once [8:59] my daughter was in a bookstore with my [9:01] gran [9:01] and I remember them asking well what [9:03] books do you want us to buy and she said [9:05] the myrrh medical manual and yeah so so [9:09] there's there's reading somewhere in [9:11] there but as far as I go it was heavily [9:15] tilted towards music and when I got to [9:18] college I and fell in love with [9:21] computers you know it was a different [9:22] story I was reading everything I could [9:24] about computers and in those days as [9:27] we'll talk about it's actually hard to [9:29] find the books we actually had to go [9:32] into New York City and into some really [9:34] obscure places [9:36] it wasn't like going on Amazon and [9:37] searching for stuff stuff right but that [9:40] was primarily nonfiction about computers [9:42] not like science fiction or anything it [9:45] exactly I mean I was into science [9:48] fiction you know TV I was a big Star [9:51] Trek fan back in the day so I tended to [9:56] watch series or Twilight Zone you know [9:59] into that type of stuff but not so much [10:01] reading more of a visual person right [10:04] right yeah well to talk about education [10:09] at school now where do you want me just [10:14] like what what like K through 12 high [10:17] school okay yeah well you know I was a [10:22] good student I was always meticulous in [10:26] my notes in fact I actually brought some [10:29] notes from my compiler class we could [10:31] browse later from college I was always a [10:35] meticulous note-taker and school came [10:39] pretty easy to me [10:41] I wasn't ultra competitive when it came [10:45] to school and regarding SATs later on [10:49] and and and tests I was not a huge [10:52] believer in that type of testing but I [10:54] did well enough to to get around and to [10:57] do what I needed to do in high school I [11:00] did well in math but I didn't it wasn't [11:04] being taught in a way that excited me [11:07] about well what could you do with this [11:09] stuff it's like okay I'm doing well at [11:10] it but what does this mean so I I didn't [11:14] really bind with it [11:15] which is why I kept on getting back to [11:17] music but you know math and music have [11:20] interesting relationships and so I think [11:23] maybe the music background made it [11:26] easier for me to grok some of the math [11:29] the school was in Spring Valley at the [11:33] time I don't know what it's like now but [11:36] at the time was very highly rated very [11:39] well supported by the community and very [11:41] diverse a very diverse group in that [11:46] area unlike this area when I say diverse [11:49] you know we didn't have a lot of Indian [11:51] and Asian people in that area but [11:54] whatever people we had it was diverse [11:57] had a lot of african-american folks [12:00] it wasn't just you know rich white folk [12:03] in the school it was a broad spectrum [12:07] which I actually feel is great I think [12:10] that learning how to interact in a [12:13] public school setting assuming the [12:15] public school is is a good school is is [12:19] the best thing I've tried to keep my [12:20] kids as much as possible in public [12:23] schools in high school we end up [12:26] deviating from that and sent them away [12:27] to a boarding school but that was later [12:30] on in life but as far as as far as my [12:32] schooling it was fairly uneventful I'd [12:36] say the one thing that's worth noting is [12:38] my dad taught in the same school high [12:41] school and junior high school I went to [12:43] so he he was my music director and you [12:50] know that that was challenging because [12:52] he's a disciplinarian he you know he was [12:55] the head of the orchestra the conductor [12:56] and really kept people in line and at [13:02] that age kids didn't understand [13:05] discipline as much I mean some kids did [13:07] so I always felt like kids you know if [13:10] they got yelled at in Orchestra after [13:12] August her they'd look at me like man [13:14] your dad's you know grumpy so you know [13:20] it it was mixed and my dad also because [13:23] he was there was able to keep an eye on [13:24] me and if I was out of line [13:27] and another teacher talked to him it [13:30] wasn't a fun experience after school but [13:33] we didn't have that many of those [13:34] instances I was you know I was a pretty [13:39] straight ahead kid and did what I was [13:41] supposed to not very rebellious minor [13:46] stuff surrounding music you know but but [13:49] but not too bad good did you have any [13:53] mentors favorite teachers heroes growing [13:57] up you know most of my mentors and and I [14:03] don't know if heroes is the right word [14:04] but people I respected were professional [14:07] musicians who I was going to see in [14:09] Greenwich Village in jazz clubs like [14:12] Sonny Rollins or Michael Brecker who [14:14] were the saxophone players of the day I [14:17] really looked up to them because I you [14:22] know I was a talented musician but I [14:24] didn't have the dexterity or the work [14:29] ethic that some of these other people [14:32] that attained stardom do you know most [14:34] of them work five six hours a day on [14:37] their instrument and I had natural [14:39] talent and I might play one or two hours [14:42] a day and I understood the difficulty in [14:47] getting to the to where they were and [14:48] making it look as easy as they made it [14:50] look so I had a lot of respect for [14:53] musicians but in terms of academics in [15:00] the day you know I ended up having most [15:03] of my computer science mentors because [15:05] of the year because I graduated high [15:09] school in 79 you know computers were [15:12] really in their infancy as far as you [15:15] know there were mainframe computers but [15:19] certainly people like Steve Jobs and [15:21] others weren't weren't around to be [15:25] revered at that point but in college [15:28] we'll talk later I mean there's there's [15:30] lots of interesting people I ended up [15:32] having [15:32] a lot of respect for considering really [15:34] considering them mentors even if I [15:37] didn't know them you know in college I [15:39] felt Alan K was a mentor just from [15:42] reading what he was writing yeah well [15:47] that's a good segue to talk about when [15:49] when where was their first exposure to [15:52] computers it was college when we were [15:59] deciding what I was going to do after [16:02] high school [16:02] and for a while I thought I just wanted [16:08] to go music become musician my dad sat [16:15] me down and talked some sense into me [16:17] and even though he was you know a [16:21] supporter a big supporter of my music [16:24] since he had toured the world and knows [16:27] knows what it's like to to do music as a [16:30] career he suggested that I minor in [16:35] music continue doing my music but [16:38] consider another major and the major [16:42] that we casually talked about at the [16:44] time was computer science because [16:48] computer science undergraduate computer [16:52] science curriculums were not even that [16:55] common in the day in fact I did a little [16:58] research to lead up to this interview [17:02] and I didn't realize it but the computer [17:05] science curriculum at oswego where I [17:08] ended up was founded in 1970 by ooblar [17:13] Van Dyck who was a Danish mathematician [17:15] who found his way to us we go and in 68 [17:19] wrote a proposal for having a computer [17:22] science curriculum and I guess Potsdam [17:28] was the only other State University of [17:30] New York that was considering computer [17:32] science undergrad basically Bachelor of [17:35] Arts degrees in computer science and [17:37] there were 60 other [17:40] SUNY schools with bigger names like [17:43] Stony Brook and Albany and Binghamton [17:46] bigger hubs and they didn't have [17:49] computer science curriculums at the time [17:52] so I guess another note on this as well [17:55] is when I was doing research I wondered [17:59] well when did the Stanford University [18:00] start an undergraduate program and I was [18:03] actually shocked that Stanford did not [18:06] have an undergraduate curriculum for [18:08] computer science until 1986 they had [18:14] graduate programs but no undergrad so I [18:18] didn't realize it at the time but it [18:23] wasn't an easy domain to find schools to [18:27] educate you in so so yeah we well so is [18:33] that why you went to SUNY Oswego because [18:36] they had a computer science program [18:37] photograph well I wound up at us we go [18:41] for several reasons number one it's it's [18:44] worth noting that because my dad was a [18:47] school teacher and because we had to [18:51] consider the reality of what it would [18:53] cost and we were a fairly conservative [18:56] people and didn't want to take out [18:58] massive loans we pretty much said you [19:01] know the SUNY schools in New York State [19:03] were fabulous at the time why not just [19:06] limit our search to SUNY which we did [19:09] and then once I started looking at the [19:12] SUNY schools Potsdam and Oswego were the [19:16] only places with computer science [19:18] programs of the day and they also were [19:21] receptive to me being a music minor see [19:24] that's the other trick the interesting [19:26] thing is when a school adds a degree [19:30] program like that sometimes they don't [19:32] want you to minor in something that's [19:34] you know as demanding as music so they [19:38] just don't want you to be distracted so [19:41] Oswego from the get-go was like yeah [19:44] we'd love to have you play on our [19:45] Orchestra and and jazz band as a minor [19:50] and major in computer science and [19:54] Potsdam was not quite as receptive to [19:57] that so I think we decided on Oswego for [20:00] that reason it was also on Lake Ontario [20:02] which was just beautiful the only [20:05] downside in terms of locale with Oswego [20:08] is it was really cold really cold like [20:12] so cold and so windy that if you were [20:16] under a certain weight you could not [20:18] walk outside near the lake for fear of [20:20] being blown in so yeah it was I think [20:28] they have tunnels now or some of the [20:29] schools have tunnels but in the summer [20:31] it's it's just a gorgeous place so [20:33] that's so yes it's just a recap it was [20:36] you know a good value I think at the [20:38] time it was roughly $6,000 a year now [20:43] it's 27,000 if you include room and [20:46] board which you have to include because [20:49] no one lives near Oswego so and I had a [20:54] modest loan I think I had a three [20:55] thousand dollar school loan which was [20:57] paid off pretty quickly so that that was [21:01] the reason and and as you know we'll [21:04] talk it ended up being I guess you want [21:07] to hear a little bit more about us we go [21:08] yeah yeah I mean it ended up being a [21:11] perfect place for me because a fellow [21:17] named Craig Gracie who was my mentor [21:20] there and taught me most of my computer [21:23] courses had a master's in math and he [21:28] had decided to start teaching computer [21:30] science in 1978 which was the year [21:34] before I showed up and so he was [21:38] learning about compilers and operating [21:40] systems and all these great things at [21:44] the same time we were and he was a great [21:47] teacher but it makes you even greater [21:50] when you're learning it along with the [21:52] kids and he was just an amazing person [21:56] was a big part of my life they're also [21:58] very into music so we were [22:02] a kinship there as well and just took a [22:06] lot of personal interest in me which [22:09] considering I wasn't a crazy great [22:14] student in the sense that I wasn't I was [22:19] never really pushed hard in high school [22:21] I just sort of naturally got by and did [22:24] well and had pretty good grades but in [22:26] college even a college like us we go [22:29] where you're studying compilers and [22:30] operating systems it was really [22:33] challenging it was not easy and having [22:37] him take a personal interest in me made [22:40] all the difference another person that [22:44] taught that came about two years after I [22:47] showed up I think around 1980 was Doug [22:50] Lee Doug Lee was also a mentor and Doug [22:53] his Doug and Craig are still at Oswego [22:58] and and Doug's a very prolific author [23:02] he's written books on Java concurrency [23:06] C++ he's like a luminary in both the C++ [23:10] and Java communities and both those guys [23:12] just loved teaching they never felt any [23:15] need to get into industry because when I [23:17] got into industry I call Craig and I [23:19] said you know there's so many cool [23:21] things to do in industry are you [23:23] interested in getting out of academia [23:25] but had no interest in it just purely [23:28] and he's the director of their cognitive [23:30] studies there now and yeah it ended up [23:33] being a great place I mean I have [23:36] actually brought I when I left Oswego [23:41] even though we did all our work and [23:42] punch cards I printed my compiler and [23:47] still have it to this day and it's it's [23:50] something I'm really proud of it was [23:52] done in Pascal so the first program you [23:56] wrote was part of one of your classes [23:58] exactly yeah okay and I don't remember I [24:01] don't remember what that program is or [24:05] was I mean obviously we all do hello [24:08] world in whatever language we're [24:10] learning my I do know my first course [24:16] was in Fortran Fortran was the language [24:20] that was supported on the IBM 1130 which [24:22] was a big mainframe and and I'm sure [24:31] they were just probably basic sorts or [24:33] whatever you do in Fortran you know [24:37] Fortran I think I only took one or two [24:40] courses where that was the language I [24:42] programmed in lots of other languages [24:44] we programmed I think my second year in [24:47] a language called GPSS general-purpose [24:51] simulation system it's a statistical [24:54] queueing theory and you know sort of [24:56] Joe's barbershop type of problems and [24:59] that was an interesting course and then [25:03] most of my courses were in Pascal and [25:08] mostly on mainframes as well punch cards [25:11] exclusively the IBM 1130 had punch cards [25:17] we would you know do assemblers and [25:20] compilers with decks that were like this [25:23] big sometimes multiple decks and you had [25:27] three runs a day to get your program [25:30] right and that required a lot of [25:35] discipline I mean we used to flowchart [25:39] everything and used to really think [25:41] about our problems before giving it to [25:43] the computer and it's interesting I [25:48] don't want to sound like an old codger [25:49] but even though interactive development [25:53] environments like the ones we ended up [25:54] developing and Apple and next and so on [25:56] are wonderful there's also something [25:59] wonderful about thinking about your [26:01] problem that much and having that level [26:03] of respect for the computer right and it [26:07] it took a lot of discipline to get a [26:09] compiler a big piece of code thousands [26:12] of lines to work you know under that [26:16] constraint so yeah it was time sharing [26:21] later on the Burroughs 5600 I think they [26:26] added a Burroughs computer [26:29] but it was although all the work was on [26:31] on those two mainframes and did you [26:37] first discover object-oriented [26:39] programming why you were at college no [26:42] no no I [26:47] the closest thing that I remember in [26:50] college is talking about Simula to Craig [26:55] and I asked whether he was going to end [26:58] up teaching a course in Simula and he [27:00] said no not yet [27:01] but there was definitely respect for [27:04] Simula that that was being done in [27:09] Europe but no we didn't we didn't do [27:11] anything with it and to be honest most [27:15] of most of those days were spent [27:17] thinking of modular programming not not [27:21] using go twos and and stuff like that [27:23] and programming in the large and the [27:25] benefits of programming in the large [27:27] that are where objects start reaping [27:30] benefits you know that that wasn't [27:32] really a focus so much in fact even in [27:36] my first job which we'll get into [27:37] objects weren't a part of their [27:41] methodology and and frankly it took a [27:44] while for objects to start catching on [27:47] right but you were doing structured [27:50] programming and modular program very [27:51] structured very modular I considered you [27:55] know the programs I wrote to be art and [27:59] took great pride and even indentation [28:03] which again is sort of odd because [28:05] you're never really looking at it right [28:07] but when you printed it you had to look [28:10] at it so you know it was it was really [28:14] important to just manage complexity and [28:17] certainly indentation making sure you [28:21] didn't have routines that were unwieldy [28:23] were all part of trying to manage the [28:26] complexity which without managing the [28:29] complexity you wouldn't be able to get [28:31] complex program to run in three runs a [28:33] day so a lot you know so I can't sit [28:37] here and actually say the art that I was [28:40] doing the art for art's sake [28:42] it was Moorside effective how do you [28:44] really make something this a puzzle [28:47] that's this complex work under these [28:49] constraints and so that's part of the [28:51] reason I guess I feel it it's that part [28:56] of the rigor and art is missing today [28:59] and encourages a lot of sloppy sloppy [29:02] work sloppy programming did you have any [29:08] summer jobs for internships so in my [29:14] junior well let's before my junior year [29:18] I did odd jobs like cook at Nathan's you [29:23] know which was a hot dog place in New [29:25] York but my junior year I decided to [29:29] apply for an internship at IBM and I got [29:33] that job as a computer operator and that [29:36] job was basically babysitting these [29:40] really expensive high speed laser [29:43] printers keeping them fed with paper and [29:45] data and the these laser printers were [29:49] just a spectacle I mean the the you [29:52] couldn't even see the paper flyby and [29:54] this was in what let's see [29:58] basically around 80 1980 1981 probably [30:02] yeah I think one of the documents she [30:05] showed me said 1982 82 okay there we go [30:10] great so yeah I I did that internship [30:14] with IBM it was local it was in a place [30:17] called Franklin Lakes New Jersey and [30:19] Franklin Lakes ended up being across the [30:22] street from my first real job out of [30:24] school it's just kind of interesting how [30:27] that worked out [30:28] because that part of New Jersey was not [30:31] a hub of Technology but you know there [30:35] were some interesting places to work and [30:37] so yeah the the the job paid well I [30:41] think back in the day I was being paid [30:43] $14 an hour if I recall which for you [30:46] know if you do the math it's probably [30:48] like 30 40 dollars an hour by today's [30:52] standards and [30:54] and it was just I didn't learn much but [30:57] I got to see the monstrosity is that [31:01] that basically print lots of stuff it's [31:04] it's hopefully there's a lot less [31:06] printing that goes on today I would [31:07] imagine there is because we have such [31:10] great storage capabilities but yeah that [31:12] was that was a great internship so let's [31:17] let's get to your first job so you [31:20] graduated in 1983 graduated in 83 and [31:27] you know we didn't have LinkedIn in [31:29] those days I forget how I arrived at the [31:33] two job interviews I ended up taking [31:36] well I actually I remember one and the [31:39] other one opportunity I didn't take I [31:42] flew from where I grew up New York to [31:46] Pomona California to take an interview [31:49] with General Dynamics I totally forget [31:53] how I found them or they found me [31:55] chances are they found me because I [31:58] wasn't looking for them and and so they [32:03] said hey we want to talk to you so I [32:05] flew out I had no idea what I'd be [32:08] working on and I flew out and I'm [32:10] sitting in the waiting room and they [32:11] give me like these brochures on the [32:14] products that I'd be working on and they [32:16] were missiles that I'd be working on [32:21] Fortran code for their computer-aided [32:25] missile program and you know right then [32:30] I guess I should have realized that may [32:31] be the case but that was culture shock [32:33] to me I really didn't want to work on [32:35] you know war instruments so I took the [32:40] interview I have no recollection of it [32:43] but just sort of tuned it out but it was [32:46] good experience to do it was my first [32:48] job interview you know so it was good [32:51] experience there's also I think the [32:53] first time I was ever on a plane you [32:56] know my kids grew up in a different [32:59] world and they've been flying since [33:00] they're like little kids but yeah I had [33:03] no opportunities to go on a plane so [33:05] that was a little stressful I guess it's [33:06] at [33:07] I'm flying by myself too but uh the [33:10] other job I do remember what happened my [33:13] mother actually said you know her friend [33:17] Rosalie down the road works at a cool [33:20] little company called [33:21] Henckels Hassan Brown and I said ok and [33:25] she contacted Rosalie and said my son's [33:29] graduating with a computer science [33:31] degree would you'd be interested in [33:34] talking to him and I got her resume and [33:36] they called me down and they were I [33:40] don't know maybe 10 miles from where I [33:42] grew up so very close and probably [33:46] within 2 or 3 miles of my internship at [33:48] IBM and ended up loving the place great [33:53] place they were actually a company [33:56] founded by three MIT graduates let's [34:00] hang Coles Ken Brown and Rene Hass and [34:03] they were pioneers in the circuit [34:07] simulation test simulation business they [34:11] had written some really interesting [34:13] software that they ended up calling [34:15] cadet computer-aided design and test and [34:20] like a lot of startups as Hardware folks [34:24] they along with some early employees [34:27] built a product and like many startups [34:31] realized they needed to then reengineer [34:34] parts of it extend parts of it they were [34:36] growing out the customer base there was [34:38] lots of stuff to do and so they hired a [34:41] pretty nice crop of young folks out of [34:45] college I'd say between five and ten of [34:47] us start at the same time I'm still [34:50] friends with a lot of the folks Columbia [34:54] graduates call me University graduates [34:57] Carnegie Mellon MIT I was probably from [35:01] the lesser named schools but it all [35:06] worked out great learned a lot it was a [35:09] great culture the two things I remember [35:12] working on there was they had a binary [35:16] circuit file which was they had a [35:19] language for describing how the [35:21] circuits were connected and that would [35:25] compile into a binary file and they [35:27] didn't have great tools for looking at [35:30] the binary files or analyzing them so I [35:33] worked on that and later on when sockets [35:39] were added to Unix actually it's [35:41] important to note they were a UNIX and a [35:43] VMs shop pretty much when sockets were [35:47] added I worked on some software to [35:50] distribute across different machines [35:54] passes of circuit simulation to speed up [35:56] the process and that was kind of [35:59] bleeding edge at the time because [36:02] sockets were brand new the whole notion [36:05] of using the network and other computers [36:09] on the network to speed up circuit [36:12] simulation was was considered pretty [36:14] cool so that was a fun project so was [36:18] that your first introduction to the UNIX [36:21] world [36:22] it was first introduction to UNIX and C [36:26] and C and it was demanding I mean that [36:30] job was demanding mainly to bootstrap my [36:32] knowledge of all those things the work [36:35] itself seemed once once you had the [36:38] tools under your belt whether it be the [36:40] C shell or learning make or any of these [36:44] tools there's just so many tools you had [36:46] to master to get your job done [36:48] but once that learning curve was over it [36:54] seemed a lot easier and I forget how [36:56] long it took probably took I'd say three [36:59] to six months to feel comfortable I was [37:02] there for a couple years but once I felt [37:04] comfortable life was pretty good and it [37:09] was a fun place to be the management was [37:11] very cool it was a great culture just a [37:15] great first job see C was tricky I mean [37:18] I should note that I I was a little bit [37:21] surprised coming from Pascal which [37:23] encouraged safety to be working in a [37:26] language like C that was kind of neutral [37:29] or encourage bad things I won't say [37:32] encourage bad things but it was very [37:34] terse [37:35] right it was easy to make mistakes very [37:37] easy to make mistakes and that's one of [37:45] the reasons I ended up thinking about [37:49] that's that's when I first started [37:50] thinking about isn't there a better way [37:52] like it's C school but fundamentally it [37:56] was developed to aid operating system [38:00] development in this case UNIX they were [38:02] sort of developed side by side and for [38:06] what we were doing building large [38:08] simulation tools it wasn't a real [38:11] natural fit so but you know it is what [38:16] it is and and you know it ended up [38:22] working out for that company and I don't [38:23] think they ever moved to a higher-level [38:25] language so you said you were there for [38:30] two years when did you move to your [38:34] second job so the when I started getting [38:42] impatient with C and with the tools I [38:46] had read some of alan k's work on small [38:51] talk there was a scientific American [38:53] article that was very famous that I [38:55] found called micro computers and the [38:59] personal computer I forget exactly the [39:01] title but it was in 1977 a Scientific [39:05] American issue and that was almost [39:08] life-changing he talked about small talk [39:10] he talked about Dynabook and which is [39:14] basically iPads back in the late 70s and [39:19] that really expanded my thinking so I [39:27] started trying to talk up objects and [39:30] better programming tools and languages [39:33] to the principles that it was called hhb [39:37] soft Ron at the time they changed their [39:39] name and they had basically told me [39:43] listen we we agree with you some of this [39:45] stuff is interesting but we're running [39:47] business and we don't have the time or [39:50] wherewithal to to retool everything so [39:55] we love if you could stay but we also [39:57] understand if you want to go so I I [40:01] think at the time job transitions were [40:07] pretty much guided by headhunters okay [40:10] so I believe I sought out a headhunter [40:12] and said here's what I'm interested in [40:15] find me some companies that that fit the [40:18] bill and I really don't remember whether [40:23] it was the headhunter that found Sara [40:24] core in Salt Lake City or I found them [40:28] and then said can you pursue them for me [40:30] don't really remember that detail but [40:33] bottom line is I found Sara core Salt [40:36] Lake City Utah and I just remember being [40:44] really impressed with what they were [40:45] doing because they unlike hhb where you [40:52] had a text file that would plug together [40:55] all the components they were doing it [40:58] all on a screen with graphics okay so [41:02] think of it as just as Apple helped [41:05] everyone make the leap to a windowing [41:07] system they were doing this in the [41:10] computer-aided design area and their [41:13] principles were taught at Evans & [41:16] Sutherland and University of Utah which [41:19] was a hotbed of this type of work so you [41:25] know even though Salt Lake City Utah was [41:28] like the furthest thing from you know a [41:30] place I really wanted to be growing up [41:32] in New York I mean it's really culture [41:34] shock I decided to talk to my wife we [41:41] weren't married at the time what we were [41:42] planning on getting married and I said [41:45] how about we get married and then move [41:47] out to Salt Lake City and and that's [41:50] what we did and Sarah Corr well Sarah or [41:57] ended up being a great place I mean how [41:59] much how much do you want to know [42:00] about it I want to ask more about Sarah [42:05] Corr but okay actually you mentioned [42:06] wife could talk about yeah so so so I [42:11] met Nancy Allen at the time at oswego [42:16] Nancy was a violinist in the orchestra [42:18] and I was playing the Mozart clarinet [42:22] concerto my greatest hit a solo with the [42:26] orchestra and through the orchestra and [42:29] through I think we were in music theory [42:32] class together we had got to know each [42:34] other and fell in love and decided she [42:39] actually was a couple years ahead of me [42:41] so she graduated two years ahead of me [42:45] and then took a job at CBS records and [42:50] worked in the legal department interface [42:53] between the legal folks and many of the [42:57] artists classical artists in New York [43:00] City in New York City Blackrock so that [43:05] too was cool cuz we got tickets to all [43:06] kinds of great shows we got to know in [43:08] fact just recently chole Anglin who's a [43:12] very famous violinist he was playing at [43:16] a place my son was playing and we got to [43:20] meet him and and and he knew her from [43:22] those days so it's like a reunion and it [43:26] was it was really exciting and in Harry [43:28] Connick to is a big star now Harry [43:31] Connick was just he was a young gun at [43:34] the time and we got to know him and so [43:37] it was we got to see Earth Wind & Fire [43:40] Madison Square Garden we had Nancy would [43:42] bring home stacks of albums for free you [43:45] know there's all this music so I'm like [43:48] you know it was it was great we were [43:50] both really into it and yeah so when I [43:55] talked to Nancy about going to Salt Lake [43:58] City Utah I remember her being very [44:01] supportive I think once we got there she [44:04] had more reservations because at that [44:08] point in time in that heavily Mormon [44:12] culture females were very [44:14] much second-class citizens and we were [44:16] still young and she had a hard time [44:19] going from a great gig in New York to [44:23] finding a great gig in Salt Lake she did [44:27] find a gig but it wasn't great and women [44:32] at the time were not treated the way [44:35] women were treated in New York let's [44:36] just say that right right politically [44:40] speaking so seems like you were come [44:42] from a fairly liberal background very [44:45] liberal very working-class very I mean [44:50] Democratic overall liberal yeah I mean [45:00] it's not I sort of hate that there are [45:03] there's such a division especially today [45:06] there are certainly some good ideas from [45:11] the other side but in today's politics [45:14] it's so tribal that you know back in the [45:17] day though I didn't pay any attention to [45:19] politics one of the unfortunate things I [45:23] guess about getting older is you focus [45:25] more on that stuff and it's it's it's [45:28] it's pretty annoying in today's world so [45:30] yeah but in those days we were a liberal [45:34] and believed in in helping people [45:39] fundamentally and believed I mean we [45:44] grew up in New York and at the time [45:46] there was still a lot of people who [45:48] didn't have enough so you have paying [45:50] taxes and assuming the taxes are going [45:52] to the right place and helping the needy [45:54] that was all part of it and and my dad [45:57] you know grew up really poor I mean his [46:01] dad was a cab driver in New York you [46:06] know started the first dog walking [46:08] business in New York unfortunately died [46:12] young from from smoking but but they [46:15] were very poor so we we have sympathy [46:21] for people who have less and you know [46:23] when I look at everything we're talking [46:25] about [46:27] I I know that I'm standing on the [46:30] shoulders of great people and we'll talk [46:33] about some of those later but I also [46:35] know that the time that I was born and [46:38] the time I entered the computer science [46:40] business was opportune you know and [46:47] earlier you mentioned reading that [46:50] Scientific American article from L&K how [46:52] did you discover L&K his work was it [46:56] just you know I think it was just [46:58] interacting with the great people at at [47:01] the time I think it was hhb I think we [47:04] just talked about what was going on in [47:06] the industry and people shared articles [47:08] yeah cuz they know social media [47:10] certainly know let's google it like here [47:13] it's easy I found it online really [47:15] easily so it was just word of mouth [47:23] you know when byte magazine was also [47:25] very popular in 70s and 80s it was also [47:31] could be again I don't remember exactly [47:34] could be reading let's say the small [47:37] talk edition of byte and then reading [47:41] names and then searching out other [47:42] things that those people had written or [47:45] believed in so you know Alan was you [47:49] know really well published and I [47:51] actually did I I didn't realize it well [47:54] I did I didn't know what years ago but [47:56] now I was reminded when I was doing some [47:58] research for this interview that Alan [48:01] graduated from the University of Utah [48:04] yeah so University of Utah's is sort of [48:09] an important place in computing and yeah [48:16] so did you actually ever visit there [48:19] when you when you after you moved out [48:21] there did you ever have any contact with [48:23] people what well I went out to interview [48:26] was obviously with the folks from Sarah [48:30] Corr and you know had a great interview [48:34] and you [48:37] kind of interesting um you know the [48:40] person who I was reporting to was a [48:47] Mormon and he was very open about the [48:51] culture and I don't remember the exact [48:55] words but was telling me that one of [48:57] their attractions to me was not just [49:00] some of the relevant experience or my [49:03] passion for programming or the fact that [49:06] I thought mainsails sounded like a cool [49:08] language to learn and work in but he [49:12] said something very unusual he said you [49:15] know one of the reasons were we're [49:17] interested in you is your leadership [49:22] skills that are not only sort of [49:26] something we believe you have but sort [49:30] of a cultural thing it's like you're [49:31] from New York you know there's something [49:33] about being a Jew from New York that [49:38] they were attracted to there's this [49:39] whole weird Zionist thing that goes on [49:41] in the Mormon thing so so I almost felt [49:44] like there was some odd religious [49:47] connection because of my heritage and [49:51] where I came from and you know listen I [49:54] got whatever you know but he had said [49:57] something to me like you know a lot of [49:59] the the Mormon folks that work here are [50:02] our worker bees and they're happy with [50:05] that so realize that you're coming into [50:08] a culture where you will be expected to [50:12] lead and and the people working for you [50:16] want that which which was very different [50:19] from next which we're going to talk [50:20] about later but I have no problem with [50:24] that [50:24] and and and the group I led was great [50:27] high morale had a great time it was [50:31] probably the easiest management [50:34] leadership gig I've ever had because it [50:37] was so receptive to that because a lot [50:39] of Silicon Valley workplaces are like [50:43] herding cats right it's like you know [50:45] everyone's running around has ideas [50:47] right and [50:49] wants to lead so but but Salt Lake was [50:53] different but it was so yeah we worked [50:55] in mainsail that was your first [50:58] management position formerly it was [51:01] leadership but I think you know I wasn't [51:03] I don't remember writing reviews but I [51:06] was giving people their work and doing [51:09] combination of design and just project [51:12] management and and a lot of coding too [51:15] and so you weren't formally a manager [51:19] but you were I was they called you a [51:21] team lead okay yeah I don't think I was [51:25] maybe by the I was you know what's [51:27] interesting what's interesting about [51:29] doing the little research I did for the [51:31] interview is if you would have asked me [51:33] before I looked back in time how long I [51:36] was there I would have told you probably [51:38] two or three years I was only there for [51:41] a year and a half I and and when I [51:45] arrived only five to six months it [51:49] wasn't quite six months five to six [51:51] months after I arrived youlet Packard [51:53] decided to buy the company and that was [51:56] also I would have guessed that was a [51:59] year but no like really soon after the [52:02] company was acquired and and it changed [52:05] obviously and I had made a decision to [52:08] stay under HP ownership for another year [52:11] but yeah mainsail mainsail influenced me [52:16] big-time [52:17] because they they were so focused on [52:23] trying to solve programs large programs [52:27] and they were funded initially by the [52:33] Stanford biology department because the [52:37] Stanford biology department knew they [52:39] were going to have a lot of needs to [52:41] write larger systems and I don't think [52:43] they wanted to do it in C so a lot of [52:46] that funding ended up benefiting the [52:51] cake hat industry because they were [52:52] floundering I think was see they needed [52:56] something better c++ wasn't out yet but [53:00] the features that were were critical in [53:02] mainsail that [53:03] made it so portable were well first of [53:07] all it wasn't just a language it was a [53:09] runtime an environment and it wasn't [53:13] really object-oriented it was more [53:15] object based it was more module oriented [53:18] I guess it was more like Simula and [53:20] Mozilla and algal so it wasn't like a [53:24] lot of object purists would look at it [53:27] and say oh this isn't interesting from [53:29] an object-oriented perspective and they [53:31] might be right but it's it was [53:34] interesting for many other reasons and [53:36] it was one of these really pragmatic [53:38] languages where they said you shouldn't [53:40] have to link there was no link step like [53:42] see everything was dynamically loaded [53:45] you would load a module as modules [53:48] required other modules they would be [53:50] loaded all the modules were self [53:53] describing they all had metadata that [53:56] metadata was used for garbage collection [53:59] and other so in a garbage collection [54:01] built in yet was very pragmatic with [54:05] collection it actually allowed you to do [54:07] things that a lot of other languages [54:08] didn't allow you to do like get a direct [54:12] memory pointer it each module [54:14] was tagged by the compiler whether it [54:17] was a safe module or an unsafe module so [54:20] obviously in any large program you'd [54:22] hope that most of your modules were safe [54:25] but it didn't stand in the way of doing [54:28] low-level bit twiddling if you had to so [54:31] it's very pragmatic language had a [54:33] co-routine facility which similar to [54:36] blocks and other languages and they did [54:41] great things with it [54:42] mainsail came from the Stanford AI lab [54:45] so sale came sail was developed at the [54:49] AI lab and then the biology I don't know [54:55] exactly how the connection was made but [54:57] the biology department at Stanford then [55:00] hired the principles at zai dak which [55:04] was the company that was formed out of [55:07] Stanford to work on a machine [55:09] independent version of sale see people [55:13] were struggling with all these computers [55:15] that were coming out [55:17] you know there was so much diversity [55:18] with workstations you know son for a [55:22] while we'll Apollo before Sun which was [55:25] a boston-based company they were pretty [55:30] big for a while they did the aegis [55:32] operating system but then when UNIX hit [55:35] even aegis had to offer UNIX [55:38] emulation and so yeah with with all [55:43] these workstations out there companies [55:46] just wanted to be abstracted from this [55:48] and so that they write a program it runs [55:51] everywhere so so yeah main sail was [55:55] financed by the biology department and [56:00] then later they spun the company off and [56:02] I don't know how that happened [56:05] no no I don't know any of that history [56:07] but it's interesting they were located [56:09] on Deer Creek in Palo Alto right almost [56:12] beside where next was I thought that was [56:16] a really weird coincidence right so so [56:21] mainsail was a portable version of sail [56:23] essentially yes yeah okay that was a [56:25] stated goal to develop large portable [56:29] programs and it did that really well [56:32] even though it never gained wide [56:35] acceptance but it was taken up by you [56:39] mentioned CAD companies like Sarah core [56:43] because because it was good for like why [56:48] was Sarah chord why does Sarah core [56:50] decide to use me and Sarah [56:51] maybe it's the question I think this I [56:57] think [56:58] the choice was between C and in their [57:02] mind mainsail that there wasn't any [57:05] other other choice for them they had [57:10] they have found mainsail and like the [57:13] idea so much after looking at the [57:15] feature said because realize most [57:17] garbage-collected languages let's say [57:20] like small talk were born in a research [57:23] environment and they weren't pragmatic [57:25] for real products so I think that [57:30] they thought they could influence it [57:32] they thought they'd get special [57:34] attention they weren't going to be [57:35] waiting around for C++ to mature which [57:38] at the time C++ was being talked about [57:42] and being researched but there were no [57:45] implementations which people felt [57:47] comfortable with in the early eighties [57:50] it was a preprocessor still not native [57:54] compiler and and the language was just [57:57] growing and evolving and I think they [58:01] felt like they could work with Zack Zack [58:05] did give Sarah core a lot of personal [58:07] love and care which which was important [58:10] because they were a real company they [58:13] wanted to develop real products and yeah [58:18] I think I think they were happy with [58:21] their decision but HP wasn't happy with [58:24] the decision so HP came in and started [58:29] pretty quickly getting fearful of [58:32] dealing with such a proprietary language [58:35] with such a proprietary company and [58:39] obviously they could have potentially [58:42] bought it and fed it but they decided [58:45] against that and they started this five [58:49] year long effort to convert the mainsail [58:52] code to C++ and I knew from the very [58:56] beginning that this was not looking like [59:00] a smart thing for them to do and five [59:05] years later they they canned it so they [59:10] tinkered around for five years I wasn't [59:14] around at the time and and eventually [59:17] canned it and it's one of those naive [59:20] management engineering decisions that [59:22] you see far too often so much wasted [59:25] time and effort because executives make [59:29] decisions that make no sense [59:33] and they weren't they weren't asking for [59:36] our opinion I mean I'm sure I gave it to [59:39] them but they didn't care you know [59:45] taking an application which was [59:47] developed with garbage collection from [59:50] the get-go and going to a system that [59:53] isn't garbage collected just that alone [59:55] is a showstopper yeah [59:58] but then if you consider other [60:01] showstoppers like no link okay [60:04] dynamically loaded on the fly C++ wasn't [60:07] very good at that and yeah oh it's just [60:13] such a such a bonehead decision man but [60:19] so and and I don't know when's I doc [60:21] went out of business the company that [60:23] did mainsail they were just great [60:25] compiler people they were another [60:29] example where they're a great technical [60:32] startup that other great technical [60:35] startups admired I think because when I [60:38] talked to Mentor Graphics who was big in [60:40] that area and even interviewed with them [60:42] later they had tremendous respect for [60:44] our mainsail and what we had done at [60:47] Sarah core they were in his brave and [60:50] their technical people acknowledge that [60:53] and they were moving to C++ but they [60:55] were moving the C++ from C so it was a [60:57] much easier transition for them but [61:03] zayed act failed like so many startups [61:08] especially language startups where they [61:11] might have great compiler chops great [61:14] insight into runtimes and compilers and [61:17] linkers and they did but the business [61:22] plan wasn't as well articulated and [61:26] let's face it being in the language [61:28] business is a tough business and you [61:31] know I watched your Brad Cox interview [61:34] and you know Brad was very clear that it [61:37] was tough being and in the tools [61:39] business in general but the language [61:40] business in particular [61:42] yeah [61:46] one last question I guess before we move [61:48] on from Sarah Corr Sarah Corr that's C [61:52] er I cor correct correct [61:55] yeah could you talk more about the the [61:58] product that you are working on for [62:00] Sarah Corr sure well it was a schematic [62:13] capture package where people would [62:16] design circuits they would plop their [62:19] little NAND gate or whatever their gate [62:21] is on the screen and they would wire it [62:23] up to other components and then could [62:25] package those components and so on and [62:28] so forth so it was a graphical [62:31] development environment for designing [62:34] circuits and simulating them and it's so [62:37] cool we would do circuit simulation and [62:40] you would see the zeroes and ones flow [62:42] through the little wires that were on [62:45] the screen very very sexy I mean very [62:50] cool product unclear if it would scale [62:54] up to the type of demands that really [62:57] really large circuit purveyors have [63:00] that's also true for startups right I [63:03] mean there were a lot of cool features I [63:04] don't know whether it was robust enough [63:07] to support the type of things Intel does [63:10] I mean clearly Intel and other hardware [63:12] companies have a lot of homegrown tools [63:15] some of which I imagine are off the [63:17] shelf but ultimately it's a combination [63:21] of things so that was sort of at the [63:25] glass what the product was but what I [63:27] was working on was one of the projects I [63:34] did involved capturing all the input so [63:39] that we can do testing of an interactive [63:42] tool like that because with interactive [63:45] tools it's usually harder to write [63:47] regression tests right in other words [63:49] you want someone to build a circuit and [63:51] then succeed and [63:55] and as you evolve the system rerun that [63:58] schematic capture in simulation so one [64:01] of the projects I had was to capture all [64:03] the menu input and mouse input and play [64:06] it back later so we called that [64:08] journaling at the time so journaling was [64:12] something I worked on I also worked on [64:14] the object oriented architecture that [64:17] was built on top of mainsail as I said [64:20] there mainsail in and of itself wasn't [64:25] wildly object oriented so they had a [64:28] system which was designed before I got [64:32] there but I also obviously contributed [64:34] to it when I got there to develop an [64:37] object based architecture that was used [64:43] to develop the product so for example we [64:46] didn't have an interface builder to [64:49] build the GUI itself but we did have a [64:52] language that allowed you to express the [64:56] UI so that you wouldn't have to write it [64:59] in bare-bones mainsail code I think we [65:05] call that the Serra core development [65:07] language wasn't I don't believe we [65:10] published it to our clients but it was [65:13] used internally so that's where I got a [65:16] big taste of actually metadata designing [65:20] an architecture on top of a language and [65:24] my job was to educate learn it then [65:27] educate all the team members and evolve [65:30] it so that it had integrity because we [65:37] there there was a lack of knowledge [65:40] throughout the company especially when [65:42] HP came on board when you started adding [65:44] more and more engineers about well how [65:46] do I do this how do I add this or do [65:49] that [65:50] so yeah I led the infrastructure team I [65:54] forget what we called ourselves but and [65:56] they're there I was a leader and they [66:01] wanted to bring me into management but [66:04] as I said I only stayed a year and a [66:06] half [66:07] at that company and it's kind of an I [66:10] look back at some of the stuff and it's [66:11] just amazing how much was packed into [66:13] some of this time you know a lot of [66:15] stuff yeah things were moving fast in [66:18] the late 70s 80 80s mid 80s so clearly [66:25] you saw the writing on the wall [66:28] after that's at some point into the HP I [66:33] saw the writing on the wall in fact [66:35] after the acquisition I took an [66:39] interview at Mentor Graphics in Oregon [66:42] that's where they were based mentor was [66:46] the 2000 pound gorilla in that space [66:49] very successful company I think they're [66:51] still around they were sold for billions [66:54] of dollars not so long ago and they made [66:59] me an offer and I decided rather than [67:05] leave Sara car after merely six months [67:09] and go to to mentor to be a little bit [67:15] more patient and at that time I actually [67:21] made the decision that I wanted to get [67:26] out of the software tools for Hardware [67:30] people and into software tools for [67:33] software people because I was a software [67:36] person you know I pretty much made the [67:39] decision that you know mentors in good [67:40] hands they don't need me and you know [67:47] they thought they did they didn't and I [67:50] said you know let me continue helping HP [67:53] even though I know it's not heading in [67:55] the right direction there's still stuff [67:57] to do there's fun stuff to learn I like [68:00] the people so I hung out another year [68:02] and that year was the birth of oops law [68:08] so I went to law the very first one back [68:12] to Portland where it was located and [68:16] that was where my idea [68:19] that's where opportunity is where luck [68:22] meets preparation I was prepared to make [68:25] that transition and I met a lot of cool [68:28] people including Brad Cox and Tom love [68:31] at that first [68:32] oops law and I don't know whether we [68:37] decided after that brief meeting at oops [68:40] law to have me in for an interview I [68:42] don't remember exactly how it unfolded [68:44] but soon after meeting them I took an [68:48] interview in Sandy Hook Connecticut for [68:51] for them it's interesting to note before [68:59] making that connection to objective-c [69:02] and - at the time ppi productivity [69:07] products international i thought i [69:11] wanted to work at AT&T on c++ because [69:15] they they were doing really cool stuff [69:18] and AT&T [69:20] I think the yarns lab was like a lot of [69:24] their research work in Princeton New [69:26] Jersey and or near it and it's a [69:28] beautiful place it's it's a great place [69:31] and it's where near where I grew up and [69:34] so it's like wow I could sort of go back [69:36] to where I grew up and but long story [69:39] short is the little bit I pursued them [69:42] they basically immediately I forget [69:45] whether it was a headhunter or they said [69:47] directly but I didn't have a PhD so you [69:50] know we don't need you because it was [69:52] Bell Labs it was Bell Labs [69:54] it was Bell Labs only PhDs need apply [69:57] they which at the time I was actually [70:02] pretty upset I wasn't so upset I wanted [70:05] to go back and get a PhD but it was a [70:11] ding considering everything up till then [70:13] was oh yeah come on come work for us and [70:16] while you're doing good work that was my [70:18] first kind of rejection but as with lots [70:22] of things things still worked out right [70:25] because if I would have if they would [70:28] have accepted me [70:29] life would have been a lot different I'm [70:31] convinced so fortunately they rejected [70:34] me and yeah I went to two pp I had a [70:38] pretty good interview and they made me [70:41] an offer and Connecticut wasn't too far [70:43] from where I grew up so it was still I [70:46] was able to see my parents and feel like [70:48] I was back on the East Coast [70:51] go Salt Lake again was culture shock so [70:55] so that was good [70:56] and wasn't asking able to find a better [70:59] gig she did she did she did actually [71:08] when we were yeah yeah I forget what the [71:13] company was called or maybe she worked [71:15] for a physics professor there was some [71:17] physics lab there I'm drawing a little [71:22] bit of a blank on on where she worked [71:24] but but we liked it we it was we also [71:27] bought our first house a condominium [71:31] interest rates for fourteen percent [71:36] imagine that imagine that 14 percent [71:41] yeah I guess I guess it encourages the [71:46] houses to go down and value right [71:49] that's the good news you pay less for [71:50] the house hopefully but you know we [71:54] moved to Connecticut and Sandy Hook and [71:56] the location of PPI was so beautiful so [72:02] beautiful I wish I had more pictures in [72:03] the day so so yeah that that was my [72:08] transition into working on software [72:10] tools for software people so yeah so you [72:16] said he meant you [72:17] you met Brad and Tom at Uppsala what was [72:21] your first impression of them my first [72:25] impression of Brad was how composed a [72:29] speaker he was he was a really composed [72:32] on panels I think I saw him on a panel [72:35] and very professional well-spoken [72:41] and at the time most of what he was [72:44] speaking about was not objective-c the [72:49] language but the revolution that he saw [72:53] with evolving to object-oriented as you [72:56] know he wrote a famous book [72:58] object-oriented an evolutionary approach [73:01] and I picked that up and you know I I [73:07] wasn't as smitten with the book I [73:09] thought it was a little bit more [73:11] marketing than it was technical but [73:15] that's not necessarily bad right it was [73:18] it's clear that he had a knack for [73:22] selling the vision and he talked about [73:25] the Industrial Revolution and he talked [73:27] about you know soldering icees together [73:31] and there was something compelling about [73:32] what he was saying at the time and I [73:35] don't think I was the only one who felt [73:37] that I think he his shtick put PPI on [73:41] the map [73:41] tom was more in the background right tom [73:44] was more the business guy tom was also a [73:46] very charismatic speaker but he was [73:48] typically speaking to business people [73:50] not on technical people but Tom and I [73:55] actually lived in the same condo [73:57] community and got to know each other [73:58] quite well and and he's just a fantastic [74:02] human and really like really like Tom [74:06] and so I was I liked both of them when I [74:12] met them and felt like they seemed [74:16] though they were high minded and [74:19] aggressive they seemed to have some [74:23] pragmatics as well which you know I [74:25] really wanted to work for a company that [74:27] wasn't too ivory tower but wanted to [74:30] work for a company that was lean and [74:32] mean and trying to do stuff for real [74:35] people and real projects I wasn't [74:38] interested in research I mean I research [74:40] was something that I had avoided till [74:44] that point and I just felt my [74:47] personality type which tended to be a [74:50] little impatient and a little emotional [74:52] was probably best in a product [74:54] Herman or I should say maybe even just [74:58] better recognized in a product [75:00] environment so fellow it's just a better [75:02] fit I ended up being little wrong with [75:08] with productivity products the meaning [75:11] them and then going to work for them [75:13] ended up being different so I don't know [75:17] if I got an accurate picture I don't [75:19] know whether I was green and just so [75:21] smitten with the idea because the whole [75:25] idea of making or evolving the SI [75:29] community to an object-oriented [75:31] programming language was so desirable to [75:34] me because I had seen mainsail take a [75:38] more radical approach and I saw it fail [75:41] so you know the idea of taking a radical [75:44] approach because I was really [75:48] disappointed with with what had happened [75:50] at HP and mainsail and Sarah core I mean [75:53] I put a lie I mean let's face it moving [75:55] cross-country I put a lot of my soul [75:58] into that and it really was a big [76:00] disappointment so I wanted the next [76:02] opportunity to be less disappointing so [76:09] part of it was the vision the division [76:12] and the pragmatics together together [76:15] yeah and I like both of them mm-hmm yeah [76:19] yeah so you joined PPI it was still [76:23] called PPI then at in 85 yeah yeah yeah [76:29] I forget when the name was changed to [76:32] StepStone but it was coincident with the [76:35] venture capitalists coming in I forget [76:38] when the venture capitalists and Tom [76:40] love parted ways but they did you know [76:43] part ways and that was tough for me [76:48] because tom was a mentor of mine and so [76:52] he was forced out that's me that's my [76:56] recollection but I think tom is is [77:02] better prepared to ever talk about the [77:05] details I spoke to Tom fair [77:08] recently and I don't think he felt he [77:14] was forced out but it almost doesn't [77:19] matter the perception of the company was [77:23] that the venture capitalists came in and [77:24] forced Tom out so you know that's my [77:29] perception of it and I you know listen I [77:33] it's just like some people perceived [77:35] that Steve was ousted from Apple and [77:38] some people perceived he wasn't you know [77:41] some people perceived he was just sort [77:43] of put into a place where he would then [77:45] want to leave which which could have [77:47] been the same situation with Tom for all [77:49] I know you know it could have been okay [77:52] well you can stay and do this and we [77:55] know you won't be happy so you leave so [77:56] it's the result is the same interesting [78:01] way so could you maybe describe how how [78:04] the company was before when Tom was [78:08] still there and you know how big it was [78:12] it what was the culture like and then [78:14] maybe talked about how what thing how do [78:16] things changed after the VCS came in you [78:19] know to be honest tom was not around ppi [78:28] a lot at the time at least that's my [78:30] recollection he was always out trying to [78:33] do deals he was prolific in the number [78:36] of companies he made contact with and [78:42] which is one of the reasons it was it [78:45] was bad that he left because he was [78:47] really great like HP Labs for instance [78:50] was a customer I'm pretty sure Tom made [78:53] that happen so I don't think Tom had [78:58] much influence on the culture of the [79:01] company because he was always trying to [79:03] do deals [79:03] he was very outbound and which to be [79:09] honest was disappointing to me because [79:11] here's a guy I admired I almost wanted [79:14] more interaction with him so the other [79:17] person I had interaction with was was [79:19] Brad and he was closer to [79:21] what I was working on so it made sense [79:24] that you know he was around but he was [79:28] focused on other things like he pretty [79:31] much handed the language off to me and [79:35] decided that he was going to go work on [79:38] other stuff so Brad and I ended up not [79:42] having that much collaboration because [79:45] he trusted me with what I was doing and [79:48] he was interested in other stuff so Brad [79:51] and I - so there was a void in the [79:55] company with leadership / management [79:58] because the the guy that all of software [80:02] reported to and I think all of software [80:04] just to quantify it was probably 12 [80:07] developers fairly small maybe less but [80:13] my recollection is somewhere between 8 [80:15] and 12 and sometimes we'd hire [80:19] consultants temporarily to help out so [80:24] we had a manager of software who was [80:28] actually the person who signed my offer [80:30] letter who went away soon after and then [80:34] they hired someone from ITT that they [80:38] felt comfortable with because a lot of [80:40] the folks who founded PPI were ex ITT [80:45] folks so they hired a fellow named Ken [80:48] hammer Hodges who was running software [80:51] and Ken I think had a technical [80:55] background but wasn't really driving [80:59] software so Brad was off in his ivory [81:03] tower ken was the manager tom was off [81:06] trying to get stuff done and you had a [81:08] guy like me trying to lead the future of [81:10] the language and then you had someone [81:12] working on the interpreter and someone [81:14] working on a few people work in icy [81:16] packs it was pretty scattered it was not [81:19] well managed it was probably the least [81:24] managed company of the three companies I [81:27] had worked with to date the first two [81:32] were extremely well managed [81:34] yeah so you mentioned Brad was doing [81:39] other stuff was he working on v.i.c [81:40] packs yes the library he was working on [81:44] icy packs he was also I believe either [81:48] before or after working on blocks now he [81:54] was doing blocks as a library component [81:57] without language support yes yeah so and [82:04] that work wasn't really in any way being [82:07] coordinated with development and at the [82:12] time at least my recollection was Brad [82:15] you know Brad's door was usually shut [82:18] and not really open it was really [82:21] distinct it's almost like he was the [82:23] research wing him alone and everyone [82:27] else was development now you know at [82:30] some level that's not necessarily bad [82:32] but there was a void there was a because [82:39] often you look to the sort of visionary [82:42] founder for at least some direction but [82:46] there were enough problems with the [82:50] prototype implementation the first and [82:52] second iterations of objective-c that [82:55] there was plenty of stuff for me to work [82:57] on and identify so my decision was to [83:02] just put your head down my first six [83:06] months were spent porting it all over [83:08] the place and there was like no [83:13] documentation on it whatsoever [83:15] so I documented the architecture what [83:19] and the implementation so that we could [83:22] make decisions moving forward and part [83:25] of that was where I figured out oh my [83:27] god some of this stuff is really flawed [83:28] so it you know porting porting at some [83:35] level I felt like oh my god I was doing [83:37] so much interesting work at Sarah core [83:40] with architecture and objects and Here I [83:43] am porting this you know preprocessor [83:47] to all kinds of weird architectures and [83:49] finding all kinds of problems and it did [83:54] feel a little bit like sweeping the [83:55] floors like I wasn't moving in a totally [83:58] upward direction but it didn't really [84:01] matter to me because I believed that [84:05] there was so much opportunity well let's [84:09] let's get into the you know the the [84:13] state of the language you know when you [84:15] started on it I mean so you've mentioned [84:17] to me before that it was sort of a you [84:22] considered it kind of a prototype like [84:24] so what was the state of objective-c and [84:27] the compiler if it even was a compiler [84:30] or not yeah I mean you came in Brad Brad [84:33] talks a little bit about this you know I [84:36] I calling it a compiler was probably [84:39] loose it was more like some scripts that [84:42] would key off certain things and then [84:45] generate code and generate C code or [84:51] actually generate like it would actually [84:54] it wouldn't even touch the C code it [84:57] would it would just try and touch the [85:00] Objective C parts and translate and and [85:03] expand them in line and leave the C code [85:06] alone okay so it would just translate [85:10] the Objective C into c or exactly okay [85:14] right along with the other C so the C [85:16] compiler could accept it right so then [85:18] you would feed it to a full regular C [85:20] compiler and that would precisely okay [85:21] yeah so it was just a translator it was [85:25] a translator now translators a very [85:29] general term [85:29] I mean compiler people use that for lots [85:32] of different things but it was naive it [85:35] wasn't full-bodied it was not capable of [85:39] detecting programming errors that are [85:42] common even a misspelling now part of [85:47] the reason it wasn't detecting errors [85:48] was not only the technology but the [85:50] language definition there was no [85:53] interface deck Lorex plis --it interface [85:56] declaration whatsoever so if you typed a [85:59] message expression and sent an [86:01] jacked a message of a certain name and [86:04] typed it in correctly [86:06] it would just assume that that was the [86:08] name of the method yeah [86:11] oh well especially when you consider the [86:16] compile debug link debug that whole [86:19] chain was slow in those days so yeah it [86:27] wasn't pretty so so we after porting and [86:34] it was clear two things were clear we [86:37] needed to evolve the language as as [86:43] minimally as possible from my [86:45] perspective at the time for it to be [86:48] reasonable the goal wasn't how do we [86:51] make the greatest language it's like [86:53] okay we're in sort of a bad place right [86:56] now just from some very basic places and [87:01] that we need to add stuff that minimally [87:06] enables the compiler to detect errors [87:07] and we need to write a compiler that's [87:12] capable of processing the language in [87:16] its entirety so that it's far less naive [87:20] and and lastly we need to make sure the [87:24] code that's generated is robust because [87:30] they were trying to work with make and [87:34] other UNIX tools so just like Objective [87:39] C was a compromise from the beginning by [87:42] saying we're embracing C I mean as soon [87:44] as you say you're embracing C you're [87:45] compromising from a purity standpoint [87:49] with with that in mind they were also [87:53] impure in the sense that they wanted to [87:55] work with UNIX tools like make they [87:59] didn't want to have to build their own [88:00] build system and so on so you had to be [88:04] sensitive to if the compiler is going to [88:07] be generating a file and make detects [88:10] that file [88:12] but doesn't recompile the right things [88:15] and you produce an executable that [88:18] doesn't work that's really bad and the [88:21] compiler was doing that the compiler is [88:23] actually along with the make system [88:26] often you'd run you'd link a program and [88:30] it would crash and you'd find out oh wow [88:34] it's because our intermediate file isn't [88:39] being managed properly so that make [88:41] isn't recognizing that that file needs [88:45] to be regenerated and bad things would [88:47] happen so to me it was a mess so I wrote [88:53] a proposal with a minimal set of things [88:57] along with an engineer named Alan watt [89:00] who was I believe also an ITT engineer [89:04] and we we wrote this paper and part of [89:10] the paper was what are some of our other [89:13] customers asking for like HP had [89:18] developed a garbage collector and they [89:20] wanted us to integrate their garbage [89:22] collector so on one end of the spectrum [89:24] you had researchers who were asking for [89:29] things on the other end of the spectrum [89:31] you had a company like next who was [89:34] developing an operating system and a set [89:36] of tools and they were more sensitive to [89:41] the type of problems I were I was just [89:43] talking about and you know I fought [89:48] pretty hard for fixing the basics which [89:55] to me wasn't even to me what it was as [89:58] obvious as oh my god rhe crafting this [90:01] main sale program in C++ is heading in [90:03] the wrong direction it was as obvious as [90:05] that yet I got pushback from the venture [90:09] capitalist who were thinking in dollar [90:12] signs thinking why should we pay you to [90:16] recraft and add some of these things [90:19] that will make it more robust to them [90:21] error handling there are their money [90:24] people [90:25] this notion of well we can't flag an [90:27] error to them that's like well so what [90:31] they're not programmers right so you [90:36] know I was getting a little bit [90:38] frustrated when I was basically being [90:41] someone ignored there was some [90:44] appreciation but this person Ken who was [90:47] leading software he didn't have the [90:49] technical chops to as the guy who was [90:51] running software to fight for me I had [90:54] to fight myself so the great fortune was [91:00] next arranged a trip for two of their [91:05] engineers Steve stone who was an OS guy [91:08] and Trey Madison who was just out of [91:11] brown really bright young guy they both [91:15] came to visit us in Sandy Hook and read [91:19] my proposal and were just jazzed totally [91:23] just they're like oh my god this is [91:25] exactly what we're bumping into this I [91:28] this solves our problems and Steve stone [91:33] was a bass player and he and I like hit [91:36] it off there are lots of obscure groups [91:38] that I was listening to at the time that [91:40] Steve was totally plugged into we went [91:42] out to Greenwich Village had a great [91:43] time and and so it ended up being a [91:47] really easy meeting because I sort of [91:50] had it all out laid out there for them [91:52] but I said guys when you go back to Palo [91:56] Alto I need you to write a letter that [92:00] identifies what we talked about and why [92:03] you were supportive of this so I can [92:06] basically do the political dance at [92:12] StepStone and they wrote the letter and [92:14] I have the letter to this day I think I [92:16] think you've seen it and after that they [92:22] had to let me work on this stuff so that [92:25] that was how I got to ad interfaces and [92:28] fix some of the runtime problems that [92:31] we've talked about before I mean I don't [92:34] think I just described some of them [92:37] an object module not being recompiled [92:40] but creating a bug because of the poor [92:43] language and compiler tools that's [92:45] clearly bad right so we in another [92:50] interview have talked in gory detail [92:51] about that but I I it's probably not [92:54] necessary for this context right yeah [92:56] that's probably yeah maybe just like in [92:59] this a sentence or two well there used [93:03] to be a global pool of selectors which [93:05] are the names that's used by objective-c [93:08] that global pool was contributed to by [93:15] the object modules the linker would [93:18] basically coalesce things and if the [93:22] table that was in the object modules was [93:24] not up-to-date then when it got copied [93:27] to the global pool the global pool would [93:30] be corrupt and it and the program [93:33] wouldn't run so simply put it was a good [93:38] prototype it was a toy it was a toy in [93:41] the early days my job was to try and [93:43] build it into a tool that had more wins [93:48] than then drawbacks and and yeah the the [93:53] letter worked I got the freedom to [93:57] recraft the compiler from the ground up [93:59] and solve all these problems and you [94:02] know even on the machines of the day [94:04] which were typically running four [94:06] megabytes the performance of it was not [94:10] that bad and we the performance of [94:12] launch time and the more dynamic runtime [94:15] I added was work that we did throughout [94:18] you know many many years and you know at [94:24] the time the some of the resistance I [94:27] got not only from the venture capital [94:28] people but the the engineers was can we [94:33] really do dynamic relocation of some of [94:37] these big data tables and I said it's a [94:41] dynamic language it has to be [94:43] implemented dynamically you don't [94:45] implement a dynamic language statically [94:47] you just don't sure there are some [94:49] static elements I'm [94:51] not saying it needs to be you know all [94:53] class descriptors need to be constable I [94:56] can imagine that the class descriptors [94:58] were laid out by the compiler and [95:00] coalesced by the linker even that could [95:04] be dynamic you could read a text file [95:06] with all the attributes in it and [95:08] actually generate the data structures on [95:10] the fly so it was a really delicate [95:13] dance between what does the compiler and [95:16] linker do and what does the runtime do [95:19] but because I had worked in a rich [95:21] runtime like mainsail and they were [95:23] always trying to understand that [95:26] delicate balance I had some relevant [95:29] experience not as a compiler writer but [95:31] as a language user which also includes [95:34] metadata the the original metadata that [95:37] was in Objective C was incomplete so I [95:40] had proposed making sure the metadata [95:42] which is the data that describes the [95:44] classes and the instances and the [95:46] methods and so on that that'd be much [95:49] more robust and that also was something [95:53] that evolved over time yeah [95:58] earlier you mentioned their porting the [96:02] language to various places what what [96:05] sorts of platforms were important to you [96:07] oh man well [96:08] hp-ux apollo the most obscure machine i [96:14] ported to was a gould which was like an [96:17] IBM clone mini computer like and it was [96:23] really weird because i had to generate [96:29] you know i don't remember the exact [96:31] details but it was something like the [96:33] assembly language was accepting VAX [96:35] mnemonics but they were then being [96:39] translated to IBM like instructions and [96:43] I was like wow that is so weird [96:46] it's because whoever wrote the assembler [96:48] at the time didn't like took the code [96:50] from somewhere else and just hacked it [96:53] and stuff like that but yeah the google [96:58] port was really weird there wasn't [97:00] really much assembly that was another [97:02] requirement [97:03] and I would dive into this is how do we [97:08] there's various ways to implement [97:10] message dispatch the way that they [97:14] originally implemented it required some [97:17] assembly language because you call a [97:20] function let's say message send and [97:22] you're in the message send routine but [97:25] that message send has arguments that [97:28] need to be passed to the eventual object [97:33] you have to leave those on the stack [97:36] frame so the notion of a way to jump to [97:41] that which is really only done in [97:43] assembly language at least when you put [97:46] the message send arguments and the user [97:48] arguments on the same stack frame which [97:51] is what we were doing for efficiency [97:53] another way to implement messaging is to [97:55] have the message dispatcher or the [97:58] message lookup routine return a pointer [98:00] to the target and then call it again so [98:03] you have two function calls so it's a [98:06] classic difference of speed versus you [98:11] know elegance right one was easy to port [98:13] slower to function calls one is one [98:16] function call requires some assembly [98:18] hack but it's faster and obviously on [98:22] when you don't care about portability [98:24] and you're developing an operating [98:26] system like we were at next and Apple [98:29] you just do whatever's the absolute [98:31] fastest on your processor and an [98:33] operating system but StepStone was in [98:37] the we don't own an operating system our [98:40] processor so there are various [98:41] techniques and often what I would [98:44] promote is let's get the port up and [98:46] running with the slow mechanism and if [98:48] we sell enough of these we can go and do [98:50] the assembly work to make it faster [98:53] right yeah makes sense so for what you [98:59] mentioned some of the you know next in [99:00] HP what were some of the other customers [99:02] that that you are doing these ports for [99:05] and how did you how did you get these [99:08] customers [99:10] you know I think Tom at the time [99:14] originally and how do we get the other [99:16] customers I mean they were advertising [99:18] and bite actually found one of the old [99:21] ads and and and copied it for you you [99:26] know they they advertised and bite [99:28] I mean bite was really well read so I [99:31] think a lot of people contacted them and [99:33] hopefully we had a port they had if not [99:35] they'd offer that's the other problem [99:38] with a small company is you know what if [99:40] someone calls you and says I need one [99:42] for this processor and it's one sale [99:46] right well in a desperate company you [99:50] allocate resources to develop that port [99:52] for that one sale in a non desperate [99:55] company you like think well let's at [99:57] least have some critical mass for [100:01] example I can't imagine they sold that [100:04] many Gould translate all that business [100:10] stuff Hanson was out of my hands all I [100:13] know is they asked for some of these [100:15] these ports I don't really know how they [100:17] got the customers I actually don't even [100:19] never interacted with that many [100:22] customers we were pretty sheltered and [100:25] even the next interaction you know I [100:28] felt like that was fostered by me given [100:33] my my position that I've described I was [100:37] in they did not really want developers [100:43] to talk much to customers or to see what [100:48] was going on there which I don't think [100:49] is that unusual [100:51] necessarily yeah [100:57] but the how did both HP and NEX become [101:03] customers was that was that through Tom [101:06] as well or how did that how they first [101:09] become customers HP I don't know I [101:16] wouldn't be surprised if it's as simple [101:19] as I know his HP Labs so it was not on [101:23] the mainstream of HP's product cycle so [101:27] I think it's pretty common for [101:30] researchers to buy tools try them out [101:34] especially people who had a you know if [101:37] you're a researcher and you've inherited [101:38] a big code C base of code you know hey [101:43] look I just saw this advertisement for [101:44] Objective C it gives me some small talk [101:46] with C so I think it was I think a lot [101:49] of it was pretty casual and an organic I [101:53] don't think anyone went out and and and [101:57] it became a bigger deal when we were [101:59] trying to sell the IC packs because then [102:03] you're selling an architecture a set of [102:06] components and you know issues like [102:10] source code do people get source code [102:12] that's a bigger issue people usually [102:15] don't like being the language business [102:17] but when they start using actual [102:18] software they become a little bit more [102:20] antsy about making sure they get source [102:22] and then it's a big you know a bigger [102:24] rathole which Richard Stallman has the [102:27] answer to but not everyone was willing [102:29] to give away their their source code but [102:35] let me make sure I answered the question [102:36] was oh well just sort of how did I guess [102:42] how did next first become oh oh so I [102:46] wasn't there obviously I was at steps on [102:49] but I'm told that William Parkhurst who [102:54] was the original app kit developer was [103:04] smitten with it I guess he may be like I [103:07] went to law I don't know that William [103:10] was a dupe saw but I think he may have [103:11] been and he was looking for tools and [103:15] came across objective-c [103:17] and figured they give it a shot I think [103:20] they were also considering object Pascal [103:23] or Pascal I don't even I'm not sure [103:25] object Pascal existed but I do believe [103:28] they were considering some of that I [103:31] think there was also some I've heard [103:35] from some NEX folk that there was some [103:40] discussion about using display [103:41] PostScript directly because Bud Tribble [103:44] thought the overhead of Objective C [103:46] might be too great bud was running [103:48] software at the time and ran [103:50] you know the Mac project he was one of [103:53] the early very early next managers [103:56] leaders and but they decided to do quite [104:01] a bit with objective-c and hit these [104:03] walls and also hit compile time laws [104:07] there are lots of issues after they had [104:11] spent I think six to nine months with [104:13] the language roughly and that's when [104:17] they basically came or contacted [104:20] StepStone to read him the riot act and [104:23] say you know we've made a big decision [104:25] to go with your language and we need it [104:30] to be pushed in this direction or else [104:34] we might reconsider and it was borne out [104:39] it really was born out of good politics [104:41] I mean the politics were valid it wasn't [104:45] arbitrary it was it was bottom-up you [104:49] know it wasn't like bud you know was [104:52] driving this the engineers were driving [104:54] it and probably really making William [105:00] you know unhappy I mean the engineers at [105:04] necks were like William you know what [105:06] you do to us right [105:08] I don't know that never William and I [105:12] you know correspond occasionally guess I [105:15] could have asked them or should have [105:16] asked them but [105:17] I could just imagine based on when I [105:20] ended up doing some consulting for them [105:22] as a StepStone employee and later hiring [105:24] on I knew they were in pain they were in [105:27] pain so but let's face it see was at the [105:32] core of mock and they're a you know [105:35] operating system decision and it was [105:37] really the only the only path for them [105:42] was to just make this work and and and [105:46] that's that's that's something that I [105:49] sensed big time after talking with them [105:53] and then III it was so clear that this [105:57] was a major obstacle that needed to be [106:00] solved and it's funny the venture [106:03] capital people I don't know whether it's [106:06] an East Coast West Coast thing but their [106:09] respect for Steve and what next was was [106:11] doing it's almost like oh well why is [106:14] next more important than HP labs and to [106:18] me it was like so obvious will happen [106:20] how could you even question that HP Labs [106:23] is piddling around with the language and [106:26] next is building an operating system [106:28] this is like our chance they didn't they [106:32] they it didn't seem like they got it and [106:36] again it could be East Coast West Coast [106:38] because to them oh well yeah sure Steve [106:41] Jobs founded Apple but yeah that was [106:43] that was what it was and so he's [106:46] starting a company like so what to them [106:48] I was it it felt like so what and I was [106:52] not I didn't grow up with Apple I was [106:55] not a Mac person I was I was weaned on [106:58] first you know as we talked to [107:01] mainframes then minis then workstations [107:04] the reason next excited me was Wow a [107:08] workstation that mere mortals could use [107:10] was really exciting but like PCs and [107:14] Macs [107:15] to me were toys for what I was working [107:18] on [107:21] so the VC saw like HP Labs that's like [107:24] you know that's a big name big name [107:28] exactly and this next startup is who [107:31] knows where whether that's going [107:34] anywhere they didn't think that was [107:35] gonna be a big deal right [107:39] yeah there's a great video that I'm [107:42] probably gonna mention later if we get a [107:44] chance by Malcolm Gladwell it's a 20 [107:46] minute Google presentation where he [107:49] talks about elite institution cognitive [107:52] disorder have you ever seen that that [107:54] video oh my god it's brilliant [107:57] and I think StepStone had elite [108:02] institution cognitive disorder I think [108:04] from their perspective HP was an elite [108:07] institution and it was HP back then was [108:12] you know they were so respected things [108:17] have changed you know and but but yeah [108:21] to then next was just the startup [108:23] company just like us [108:24] we're startup they're startup so yeah [108:30] actually that the Malcolm Gladwell talk [108:32] is is more what he's talking about there [108:36] is how people get so smitten with elite [108:42] academic institutions and often will [108:46] mortgage the house and everything else [108:49] to go to one of these big name schools [108:51] they go to the big name school and [108:53] especially in stem and they they fail [108:58] and they fail not because they're not [109:01] smart people because if you get into you [109:04] know Yale or Harvard or any of these [109:05] really big schools you're obviously a [109:07] smart person but they fail because [109:09] they're they end up in stem or computer [109:13] science or name you're tough you know [109:15] undergrad degree they end up being in [109:18] the bottom third of the class and that's [109:21] never happened to them before and [109:23] they're convinced their failure and he [109:27] backs it up with data and he tells an [109:30] interesting story because he too didn't [109:32] go to an elite institution [109:34] and even makes fun that one of the [109:37] reasons he agreed to give this google [109:39] talk which was for free usually gets [109:41] paid was it it's for Google right he's [109:44] like really smitten with Google and you [109:47] know he even said you know it's not [109:48] about even hanging out with really smart [109:50] people I know plenty of smart people [109:55] it's a great talk I guess before we move [110:02] on to next let's finish off the [110:04] stepstones story so you mentioned the [110:08] VCS came in and then sort of the company [110:10] changed could you talk a little bit more [110:12] about that well it's a little bit hard [110:25] for me to quantify since the culture at [110:28] StepStone was already not wildly good I [110:33] sort of described that before in other [110:35] words we lacked real leadership [110:38] Brad was off doing some research the [110:41] management was from I T&T it wasn't a [110:44] hungry entrepreneurial startup like the [110:47] other two I had been a part of so when [110:51] you take that lack of focus and lack of [110:54] hunger and you bring in money people who [110:57] think they know better than the [110:58] engineers it's just not it's not a good [111:04] feeling to be part of an organization [111:05] like that because engineers along with [111:10] the customers of the technology should [111:13] be driving the technology they need to [111:18] be sensitive to deadlines they need to [111:20] be sensitive to well if we do that we [111:23] only have one customer for it there's [111:25] that type of management of priorities [111:27] that wasn't happening and we had a small [111:30] staff and we were doing too much broadly [111:34] and so the venture capitalist because [111:37] they want to make more money they view [111:41] more is better right so let's do more I [111:43] see packs they didn't understand that [111:46] even the ICP [111:47] we were doing we're half-baked they [111:50] didn't understand and something I [111:52] learned I didn't know this at the time [111:54] but now looking back and I learned it [111:57] soon after StepStone actually it next [112:01] and I'd never gone back is you cannot [112:07] develop a domain-specific IC pack or kit [112:10] whatever you want to call it or object [112:12] where you know there's been many of [112:14] these terms for grandiose libraries that [112:18] solve domain problems you cannot do one [112:21] of those without doing an app to prove [112:24] it and I would argue to apps at least [112:30] because if you do a kit and do an app [112:33] well that says okay that kits good [112:35] enough to service that app let's say [112:38] it's a spreadsheet but then if you say [112:41] now you want to do a schematic capture [112:42] package wildly different would that [112:46] graphics model support that application [112:49] as well so they didn't understand this [112:53] and I was pretty green at the time and [112:55] I'm not again I'm not saying I [112:57] understood it either but if they were [113:02] well managed and they had the right [113:05] people at the helm of the company they [113:08] should have under someone should have [113:09] understood it but I didn't understand it [113:12] I mean Brad Brad just thinks they you [113:19] know I haven't talked to Brad recently [113:21] but I saw the interview you did with [113:23] Brad a couple years ago Brad just thinks [113:25] I see packs were you know ahead of their [113:28] time or you can't sell them or it's [113:31] destined to failure almost like well we [113:34] tried and you know there wasn't a [113:37] business model well you could blame the [113:39] business model you want the technology [113:42] just wasn't good enough and there are [113:45] business model issues I'm not suggesting [113:47] there aren't there's lots of issues but [113:49] fundamentally if you're talking about a [113:52] company like next who's doing [113:54] professional stuff or Adobe that's doing [113:57] professional stuff or Lotus the guys who [114:00] are doing [114:01] Pro apps they're not gonna base their [114:04] future on your objects and where you [114:07] have no apps you know especially when [114:10] you're not giving away the source code [114:12] so it's it's you know they didn't [114:14] understand this the venture capitalists [114:16] they just wanted more icy packs they [114:18] really didn't want to support the whole [114:21] idea of working on interactive [114:23] development environments better [114:25] compilers browsers because let's face it [114:28] one of the great things about small talk [114:30] was it has a great browsing environment [114:32] and that's something I worked on it next [114:34] later on but when I was talking about [114:36] that it's depth in that well we're not [114:38] going to do that so their focus was [114:42] almost entirely on icy packs which is [114:47] also what Brad's book was about the [114:50] revolution hey we're going to develop [114:52] and and it's actually interesting [114:54] there's a talk I found a few weeks ago [114:58] called object-oriented programming is [115:01] bad okay [115:04] when I first saw it I was like oh my god [115:07] this must be really weird but half [115:10] million views and and so I said I have [115:13] to watch this if it has 1/2 million [115:15] views and and the guy who did it is [115:17] really pretty thoughtful and it's an [115:21] interesting piece I don't agree with all [115:23] of it he like absolutely is down on [115:25] encapsulation absolutely thinks that it [115:29] will lead you into the wrong place I [115:31] don't agree with that I think you can [115:34] use it effectively but one of the things [115:36] he talks about is how he always felt [115:39] when programming with objects that it's [115:41] like designing a house with lots of [115:43] walls before you really know what you're [115:46] using the house for or the building for [115:48] that I that struck a chord with me and I [115:52] think to some degree it relates to this [115:55] discussion where where StepStone was [115:58] drawing these making these plans and and [116:01] architectures and other companies were [116:03] guilty of it too Tala Junt [116:05] in the future where they're building all [116:07] this stuff but they really don't know [116:10] what's going to be sitting above them [116:11] and it's almost too soon [116:14] to hardwire the architecture so they're [116:18] building tools but they haven't talked [116:21] to who's using the tool so they're [116:22] building it without an idea in mind for [116:25] how they should be building these that's [116:28] right one is I mean even something as [116:30] simple as a hash table or a lookup [116:33] routine you know you can build obviously [116:37] a hash table object without writing an [116:42] app however the different apps well will [116:49] or will not work well with that hash [116:51] function or our hash table so by using [116:55] that hash table in many different [116:56] scenarios you will parameterize it [116:59] differently you will build it [117:00] differently even the the hash table for [117:04] message sending which we may talk about [117:06] a little bit later that we want with [117:09] this I went with the simplest thing on [117:11] the planet [117:12] linear probing with a particular hash [117:14] code that was computed from the [117:16] selectors and we Bertrand and I and [117:20] others in the early days we played [117:22] around with lots of different schemes [117:23] and the simplest thing is what worked [117:26] the best for objective-c it's not [117:29] intuitive some of this stuff you have to [117:32] build lots of different things and [117:34] measure them and there's a lot of work [117:37] involved in that type of craftsmanship [117:40] which clearly wasn't happening at [117:43] StepStone it was purely listen we need [117:47] this we need that and and and there [117:52] unlike the and it's interesting like the [117:55] open source movement one other thing [117:57] that's wonderful about it is people will [117:59] get it and there'll be more of this loop [118:01] and collaboration that's the other thing [118:03] that wasn't happening that much like [118:06] when HP contacted StepStone to politic [118:10] for taking their collector they [118:12] literally wanted to just give us the [118:14] collector without any iteration with [118:17] other customers there's another perfect [118:19] example if we integrated their collector [118:21] yes it might have made them happy but it [118:24] I can guarantee you would not have [118:27] worked for stuff or for now [118:31] and so I felt like just to tie this I [118:37] felt like you know the first two [118:39] startups I work for were professional [118:42] companies with professional people and I [118:45] was treated professionally and a [118:48] StepStone though I really love Tom and [118:52] and like Brad the company was [118:58] dysfunctional and the fact that they [119:01] didn't make it is not as not surprising [119:05] to me at all it's not about the concepts [119:10] they had the right concepts they didn't [119:13] execute the business they didn't execute [119:16] on the technology and that was their [119:20] problem and that's why it was [119:24] interesting when I was listening to [119:25] Brad's interview with you I you know a [119:28] little bit animated and like no Brad [119:31] it's you know there's other things and [119:34] and but Brad's a brilliant guy and Brad [119:38] just there were so many business things [119:40] you asked him that he really couldn't [119:41] answer so he was divorced from that as [119:44] well but in a startup company with very [119:47] few people the principles need to have [119:51] strong opinions or else other people [119:53] will come in and ravage and that's what [119:56] happened so before the break I guess I [120:00] just wanted to ask sort of one less [120:01] question about was when that StepStone [120:06] particular but we mentioned the idea of [120:08] object wear which I guess came from [120:13] Brad's vision Brad Cox's vision of [120:16] software components as being a [120:18] revolutionary revolutionising force in [120:21] the software industry and I think he [120:26] your take on that was that it was not [120:31] necessarily the vision itself that was [120:34] the issue it was the execution but I was [120:38] sort of curious about your take on the [120:40] whole idea of [120:42] selling objects on the open market and [120:44] in the potential impact that that might [120:48] have since you know that was clearly [120:53] Brad's vision it was maybe part of that [120:57] vision was what motivated to join except [121:02] zone in the first place I don't know if [121:04] that's true or not but maybe just talk [121:06] about what your view of that at an [121:08] abstract level it was definitely part of [121:11] it I at the time wasn't a real deep [121:18] thinker in that area but as far as the [121:21] sales pitch goes I was partly sold and [121:25] and just skeptical and I think I didn't [121:33] really put any meat on the bones while I [121:36] was at StepStone because I had my hands [121:38] full with trying to save the compiler [121:40] and language if the compiler language [121:43] we're in a better spot I probably would [121:46] have been more intrigued with stepstones [121:50] decision-making in the IC Pak area but [121:53] it was almost like it was going on as a [121:55] separate thread within the company that [121:59] I just didn't pay much attention to and [122:01] in fact not only did I have my hands [122:05] full but the culture of the company [122:08] encouraged people on different threads [122:11] not to communicate which wasn't the [122:15] culture at other companies but it really [122:17] was the culture there in other words I [122:19] had some ideas on the interpreter and I [122:23] was really never encouraged to [122:25] participate in interpreter plans which [122:30] clearly the language changes I was [122:33] proposing did affect the interpreter [122:34] because it was yet another [122:37] implementation of the language it was [122:41] just more interactive so but the [122:45] interpreter was also a half-baked when [122:47] you hear a brad talk about the company [122:49] he he doesn't really talk much about the [122:52] interpreter [122:54] if I recall a lot of that may have even [122:56] been inherited from another company that [122:58] they were working with and then so it [123:01] was it was just a hodgepodge of stuff [123:05] and I as we previously talked looking [123:13] back I know very clearly you know and I [123:17] don't need to be pedantic about it [123:19] unless you want me to clarify something [123:21] but I just think it was the execution I [123:24] also think I think I said this before [123:27] with components shipping software [123:30] becomes pretty important because [123:33] ultimately if there are non-trivial [123:36] components companies don't want to put [123:40] their future in another company's hands [123:42] without control of the source code which [123:46] is true for other stuff too but it's [123:48] particularly true for components so [123:53] right and then I mean in some ways this [123:56] seems almost as if Brad's model of [123:59] selling objects I guess I guess you [124:04] could modify to include the source but [124:05] his model was that it would be [124:07] completely black box and you wouldn't [124:09] get the source so you were stuck if you [124:11] had if there are problems with it [124:12] exactly and if they if StepStone was [124:15] more active in app development they [124:18] would have had more combat experience [124:21] with those realities so I think they [124:24] were just naive I think it was naive and [124:29] I I don't know why it was naive but [124:35] sometimes people just have to experience [124:37] things and move on there was just never [124:39] any thoughtful I don't remember any like [124:43] company meeting where there was any [124:46] thoughtful discussion on can people [124:50] speak up on why were not succeeding as a [124:54] company it was almost like the engineers [124:57] were pawns the engineers were doing [124:59] their thing and higher-level people were [125:01] trying to figure out how to make this a [125:06] business where [125:08] at next which we're going to talk about [125:10] soon [125:11] you know Steve Jobs especially this size [125:14] company Steve Jobs would have called [125:15] everyone into the room and say well how [125:18] come this isn't working or that isn't [125:20] working let's hash it out that's how a [125:24] functional company works they put the [125:27] cards on the table and figure out what's [125:30] working and what isn't working and that [125:33] exercise never to my knowledge at least [125:36] if it happened it didn't include me or [125:41] Brad apparently again when when someone [125:47] people come in writing checks for a [125:49] small company beware beware well that's [125:55] a good segue to the next story we've [125:59] already talked a little bit about how [126:01] objective-c came to be used at next [126:07] you mentioned William Parkhurst and you [126:11] know buds original ideas about what the [126:14] software should be is it anymore you [126:16] want to add to that that's that story [126:22] regarding before I arrived it next yeah [126:27] I guess the door you had the decision [126:28] that led to using Objective C I think to [126:34] some degree it was also born out of C [126:39] being the base language them wanting it [126:43] seeming very desirable to have a dynamic [126:46] message-passing idiom on top of the C [126:50] language and certainly it being based on [126:55] small talk which has the park [126:58] you know heritage there was also sort of [127:00] this cultural nice match with with Park [127:06] and small talk and dynamism and making a [127:10] small runtime that would fit on a four [127:13] megabyte 68k that type of stuff but [127:18] they too were a little naive and being [127:24] sold a bill of goods that they didn't [127:27] know upfront where the bodies were [127:31] buried they just didn't know so they [127:34] they decided to use it and they then [127:39] worked hard to make sure the the [127:42] problems were fixed and even Steve was [127:45] very vocal with Tom love so sort of CEO [127:51] to CEO about you know we we took a bet [127:53] on you guys and because before I [127:56] actually got hired by next I was out [127:58] there doing some consulting where I was [128:00] delivering a more advanced version of [128:04] the translator that did better with [128:06] errors that generated better code I was [128:09] working in NEX business office on Deer [128:15] Creek that was segregated from the [128:17] engineering because it was very [128:19] secretive I wasn't allowed to see the [128:21] cube or anything I had no idea what they [128:24] were doing [128:24] they had a Sun workstation set to the [128:27] side where I was working with the Sun C [128:30] compiler and the Objective C translator [128:33] to demonstrate the work I had done so [128:36] when I was out there demonstrating this [128:40] work to their engineers Steve Jobs had [128:44] shown up in the entryway of the main [128:50] office and had a talk with myself bud [128:55] Tribble Steve stone who was the other [128:57] engineer at next to was my liaison and [129:01] Tom love and Steve had pretty much read [129:07] Tom the riot act in terms of you know we [129:11] made a bet on you guys and you're not [129:15] delivering and you know Steve is doing [129:18] great stuff but we need your whole [129:22] company to be engaged and support Steve [129:25] because we care about the language we [129:29] care about the infrastructure we [129:31] care about the runtime the errormsgs and [129:33] he like went through he sounded like an [129:35] engineer it was amazing [129:37] he was parroting what his engineers were [129:40] saying and spinning it a certain way but [129:43] ultimately told Tom that invest more in [129:47] the language infrastructure and less in [129:50] the IC PACs and you know Tom listened [129:54] and and was respectful and Budd was very [129:57] quiet but a very quiet person in general [129:59] he didn't say much and and I was sort of [130:02] just smiling saying you know here's a [130:06] CEO which has a clue my goodness what a [130:10] difference from the venture capital is [130:12] now running StepStone this is a guy I [130:15] could see working for so it was I was [130:17] just jazzed that here's here's someone [130:20] who understands you have to make the [130:22] language work before you start building [130:24] on top of it which you know the end of [130:27] the day as Steve left to say isn't [130:28] rocket science right it's really basic [130:33] engineering and so that was the point in [130:40] time when I think Steve probably told [130:43] bud and Steve stone ask Steve narrow off [130:48] to come in for an interview I don't want [130:50] to deal with this company who knows they [130:55] probably talked about buying the company [130:56] too but Steve is well known for targeted [131:01] hiring practices let's just say it's a [131:06] lot easier than buying a company right [131:08] especially since he doesn't care about a [131:10] lot of the other stuff especially the [131:13] icy packs right so so then [131:24] then talk about how the process was like [131:27] sort of joining next and leaving step [131:33] stone well when I gave well first I [131:43] guess it's interesting to talk about the [131:45] interview [131:45] you know I flew out for the interview [131:49] and I actually have the interview list [131:52] here let me see where it is yeah so so I [131:58] had a bunch of group interviews like I [132:01] had William Parker's Kevin Enderby Joe [132:05] Capriati who interviewed me in the [132:07] morning and then a 45-minute interview [132:10] with just Steve okay and then lunch with [132:15] the OS group and then a bunch of group [132:18] interviews with avi - Vania and Peter [132:21] King mic demony but Tribble like the [132:22] whole cast of characters but all like [132:24] long group interviews and when when [132:30] Steve came into the room Kevin Enderby [132:33] who was a compiler linker guy was held [132:38] over we were babbling about something [132:43] Kevin you know respected that it was [132:46] Steve's time and said well Steve you [132:48] know I'll let you get to it and she's [132:50] like oh no Kevin you know you could stay [132:51] you know [132:52] so Kevin begrudging Lee stayed for [132:57] awhile while Steve proceeded to confront [133:02] me and and it's funny Kevin probably [133:06] remembers this better than I do because [133:09] whenever I see Kevin he loves to mention [133:11] this like oh man that was tough sitting [133:13] through that but Steve basically looked [133:17] at my resume was with some disdain [133:22] questioning my career what I had done [133:26] and it was interesting I proceeded to [133:31] defend my life and you know talk about [133:34] the work I had done and talk about the [133:36] two startups I was a [133:37] part of and how I wound up at at [133:41] StepStone who accompany he didn't [133:44] respect right so I went through that and [133:49] I saw Steve immediately sort of relaxed [133:53] and I don't think I was smart enough at [133:58] the time to truly know what was going on [134:00] but it didn't take long to figure it out [134:03] afterwards I mean Steve's Steve was [134:07] convinced I should be at the company [134:09] before he entered the room yet he was [134:12] very he made it a tough interview and he [134:16] did it because he knew I had leadership [134:19] potential at the company and he wanted [134:22] to see whether I would shrivel up and [134:23] die under his questioning he wanted he [134:27] wanted to see can this guy defend [134:29] himself can this guy defend his ideas [134:31] and can or is he going to shrivel up and [134:35] die and again given my background New [134:39] York played in ban many bands and had to [134:42] deal with a wide array of people I just [134:46] sort of had fun telling him about all [134:48] the stuff I had done and when I got [134:51] around to telling him how I thought [134:53] programming was an art and how it [134:55] related to music and how all that [134:58] brought me to this place he was sold and [135:03] um because he really does have had an [135:07] inner affinity for people that loved [135:09] music he loved music and and I know that [135:14] he felt programming was an art you know [135:17] and so I think we developed a kinship in [135:21] that meeting that catapulted me to great [135:25] places from that point on I forget when [135:28] Ken I think Kevin stayed for like 15 [135:29] minutes and Steve and I held over a [135:31] little bit and then the rest of the day [135:34] we had a great lunch interview with the [135:37] OS team at little garden which was in [135:39] the day just the coolest Silicon Valley [135:43] it was a Chinese restaurant [135:46] in Palo Alto that was like a who's who [135:49] you know lots of great Sun engineers as [135:52] Sun was coming up and and next and just [135:55] listening to the conversations that all [135:57] the tables was very amusing it was just [136:00] very incestuous place to be but so that [136:05] was that was my recollection of the [136:08] interview and and so when I went back [136:13] they they made me an offer and I told [136:16] StepStone and they they threatened to [136:21] sue me they did not want to bless me [136:26] leaving them and going to work for Steve [136:30] it and next and so I I told Stephen next [136:36] listen this is like crazy stuff I've [136:38] never I've never you know I was a young [136:40] I was 25 26 and I let's see no 27 and I [136:51] but I never been threatened with a [136:53] lawsuit and I didn't have the means to [136:56] defend myself and the whole notion of [136:58] them taking a lien on my modest condo [137:02] that I bought with 14 percent mortgage [137:04] was was was intimidating so I said Steve [137:11] listen they're threatening me and you [137:15] need to solve this for me or or I can't [137:17] come and he told Gary Moore his lawyer [137:22] to deal with it Gary dealt with it [137:24] within I don't know a few days and it [137:27] all made sense though because they next [137:30] had bought a full source license okay so [137:35] they had the source code and I wasn't [137:40] going to be taking any I see pack code [137:43] with me I didn't work on that I you know [137:46] there was no intellectual property [137:47] issues regarding that so as far as the [137:50] language goes we since they bought the [137:53] source code we were really free to and [137:55] we were going to develop our own runtime [137:57] we weren't [137:58] I'm gonna use their runtime and so that [138:02] problem got solved pretty quickly and I [138:07] think things have changed over the years [138:08] people realized companies don't own [138:11] employees and that you know if they [138:15] didn't have a source code license and I [138:17] took source code out of the building yes [138:19] that's not cool but I'm allowed to take [138:21] my knowledge of the language with me [138:23] because they were working on the [138:25] language and in fact if they steps [138:29] almost smart and Dennis Cisco who was [138:33] running the place at the time really [138:35] stepped back [138:36] he'd say great we don't want to invest [138:39] in the language let next drive the [138:42] language and we'll drive our icy pack [138:45] strategy so it's just people were [138:53] frantic because they were having a [138:56] problem running their company there [138:58] there was no really grounded thinking [139:00] and if I would have told Dennis what I [139:03] just told you he would have probably [139:06] looked at me like you're 27 and and poor [139:10] and I'm old and rich so why are why are [139:13] you trying to tell me what to do yeah [139:16] stupid stuff like that you know it's and [139:19] and that's what was also beautiful about [139:22] Steve is how much money you had or how [139:24] old you are [139:26] none of that entered into his thinking [139:28] it's what are your ideas right and so I [139:32] think so so the transition was after [139:37] that scare all went pretty well a you [139:45] know we don't get too much into personal [139:47] stuff in an interview like this but one [139:49] of the personal issues that affected my [139:52] my wife even more than me but was still [139:55] a family thing was as we were making the [139:59] plans with moving to Palo [140:03] well actually Sunnyvale and [140:07] taking the job was my wife was pregnant [140:09] and we got a call from the doctor like [140:13] right before we're about to move out [140:15] that he saw something on the sonogram [140:18] and the pregnancy was not going in the [140:23] right direction and we lost that baby [140:26] and you know a traumatic event [140:30] considering you're switching jobs you [140:32] know there's been so much moving and and [140:35] that happens and it really was was tough [140:40] so but you know we got through it and [140:46] then I went into this pressure cooker [140:48] situation where I'm at next I start [140:52] learning about the hardware and the [140:54] strategy and the fact that I think I [140:57] started in August and the of what ER 88 [141:02] 88 [141:04] yeah the interview was in May that maybe [141:09] I started I don't know how many months [141:10] been told some number of months past [141:12] close enough I think it was August that [141:15] I started there question across country [141:17] moves and the pregnancy issue and stuff [141:23] so but we had the introduction of the [141:29] compute of the cube in October October [141:32] 12th I think of 88 so we were in the [141:38] bomb run as but that was the big next [141:41] term a bunch think bud coined it but who [141:43] knows but it's always like you're in the [141:45] bomb run for the release so here I'm new [141:48] don't have a product yet so many pieces [141:51] on the floor it was it was a tumultuous [141:56] time but an excited really exciting time [141:59] because we were you know next was the [142:01] talk of the town [142:02] that it's actually interesting that this [142:04] is October 8th so Steve passed last week [142:08] in 2011 and the intro was the end of [142:14] this week so it's interesting that this [142:16] this is happening between those two [142:18] pretty big events and [142:20] my life at least but let's see well yeah [142:29] so the what so what was your first [142:31] position and what was what was her what [142:34] would he do work on it first so so I was [142:36] an engineer who worked for a fellow [142:39] named Mike demony who was in the [142:41] operating system group ok evita vein ian [142:45] had hired on a couple months before me [142:48] we're very close he was on the interview [142:51] scheduled but he was pretty new he was [142:54] not running anything he was mr. Mach and [142:56] was doing OS work so I was reporting to [143:00] Mike demony who had was the manager for [143:03] the OS group and it was a big open room [143:06] with I was thrown in with the OS group [143:11] so there was no tools group Steve stone [143:16] who was basically hacking the compiler [143:21] prior to hiring me was trained as an OS [143:25] guy but was just a jack-of-all-trades [143:27] and he loved it and was driving this [143:31] hire because he was just dying to get [143:34] out of the compiler business and and his [143:39] clients throughout next software were [143:41] also dying for him to get out of the [143:42] compiler business because they had lots [143:45] of bugs that were on their list and you [143:49] know Steve was an OS guy and he had lots [143:52] of stuff going on helping out with the [143:54] OS and stuff doing compiler work in your [143:56] spare time when you are in a compiler [143:58] guy and trying to help people it's tough [144:00] so I was the very first thing was just [144:10] fixing bugs in the StepStone translator [144:13] that I had done as StepStone employee [144:16] and making sure the integration with at [144:19] the time the canoe compiler see that was [144:22] totally new to me I had no idea that [144:24] they were using Richard Stallman's free [144:27] software foundation product which was [144:31] also very new the 1.0 [144:33] of GCC happened in 1987 and this was 88 [144:38] so it was a year out of the chute out of [144:42] the 1.0 release and there were bugs in [144:46] it too so [144:47] bugs in the StepStone translator bugs [144:49] and the early versions of GCC and that [144:54] was I'd say at least two to four weeks [144:58] of my first month there and it's [145:05] interesting like after two to three to [145:06] four weeks of bug fixing and [145:09] concentrated helping everyone I know the [145:15] person who was working on the workspace [145:17] the finder at the time Chris Franklin I [145:19] remember like sending me a fairly public [145:22] email that was copied to most of [145:25] software saying like how much she [145:27] thanked me for helping fix these bugs [145:30] and how it's really helping their [145:32] productivity and you know it was such an [145:34] open environment that simple things like [145:37] making sure the compiler worked was like [145:40] I was a rock star just because they were [145:42] getting stuff done that they couldn't [145:44] get done before and and that was great [145:49] I made me feel it motivated me right I [145:51] felt like I was needed I'm went from an [145:53] environment where I was but grudgingly [145:56] let loose or to do anything interesting [145:59] to an environment where just fixing bugs [146:02] made people like giddy [146:06] so I mean honestly really soon after [146:10] that they raised my salary and treated [146:14] me really well because they just were [146:18] happy and I I think we've talked offline [146:21] next had an open salary and stock [146:24] structure where people when they were [146:26] happy with other people or not happy [146:29] they some people it really wasn't [146:31] referenced often I don't think but in [146:33] this case I think Chris or others went [146:36] and saw what I was being paid in my [146:38] stock position and I mean very soon [146:41] after because it was an open salary [146:44] structure my clients lobbied for [146:47] me to get a bump and that was also like [146:50] unheard of I'd never experienced [146:52] anything like that I was so I it was [146:56] honestly the best environment and [146:59] culture I had ever experienced you know [147:03] so this just led to me being even that [147:08] more devoted to doing crazy great things [147:11] I'm like wow it's being recognized and [147:14] and so I credit you know a lot of the [147:17] cool stuff I did over the years with [147:19] providing an environment that was [147:21] nurturing and appreciative of things [147:25] which is surprisingly hard to find I [147:28] think in any field I was really lucky [147:32] really fortunate so other than that then [147:38] we had to draw up plans for what is next [147:45] when are we going to not be dependent on [147:50] their run time so I started working on a [147:51] replacement runtime that was optimized [147:54] for mock and optimized for there and I [147:58] had the only two people working on [148:00] compilers then was me and Kevin Enderby [148:04] he worked on assemblers linkers loaders [148:06] and I worked on the front end in the [148:09] middle and the integration with GCC and [148:13] so I had had ideas for what the linker [148:18] could do for me to make Objective C [148:20] better and ma Co had very interesting [148:24] features for organizing data organizing [148:28] the metadata and we developed really [148:32] interesting system specific Mach [148:34] specific ways to optimize the metadata [148:37] so the paging was minimized and that all [148:40] the stuff was organized and accessible [148:42] really easily so that was fun and Kevin [148:47] did a lot of that work and just more and [148:50] more owning a linker for a language like [148:54] Objective C is really important because [148:58] even though it's a dynamic language [149:01] and you could just defer to run time for [149:04] so much because we were running on [149:08] modest machines with modest memory [149:11] devising creative ways to distribute the [149:14] workload get the compiler and linker to [149:16] do as much as possible and deferring as [149:19] little as possible to run time was was [149:23] really important and it took a fair [149:25] amount of work to do that well so we [149:29] weren't doing that much with evolving [149:32] the language we were evolving the [149:34] implementation now one notable exception [149:41] which happened fairly early on was [149:44] categories jean-marie [149:48] ehlo who was working on interface [149:50] builder again not in any formal team but [149:55] just another part of the software group [149:56] he had come to me and talked to me about [149:59] what magic he was doing to make [150:02] interface builder work and he was using [150:04] something called poses which was a [150:06] runtime hack to basically take a class [150:09] and interject another class ahead of it [150:12] in the metadata so that you could [150:15] basically spoof the runtime into [150:17] executing code and while that was cool I [150:22] decided that it needed linguistic [150:25] support to support interface builder [150:28] because interface builder was was really [150:31] the crown jewel and making sure it [150:35] didn't depend on hacks but defendant but [150:38] dependent on language features [150:39] explicitly is sort of important [150:43] so we developed categories for that