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)