History of Nombas
 a personal and opinionated memory

by Brent Noorda

For about a dozen years, Nombas was the leading developer, innovator, licensor, and evangelist of script language tools, licensing their JavaScript engines and tools to C, C++, and Java developers for everything from embedded devices to massively parallel servers. This is the story, as remembered in April, 2012.

The Bad Old Days of Programming Yore

A whole lot of languages going on

C is great, but not for everybody

Data was King (in theory)

MS-DOS was (and DOS Batch) was everywhere, but real programming was costly

Source code was too often missing

A really bad idea for a business, but a pretty useful side project

A bad idea

Working alone leads to more problems

Cmm (C minus minus) - a solution to a bunch of issues

Testing whether Cmm was worth pursuing

Nombas formed to promote scripting

Three-step road-map to world domination

The Cmm business

The Java thorn in our side

The switch from Cmm to JavaScript/EcmaScript/ScriptEase

What’s this “web” thing everyone is talking about?

Demonstrating client-side scripting in web pages: but no sale

Netscape’s JavaScript becomes too popular to fight, so we switch to “the standard”

Thanks, Netscape, for making our job a whole lot easier

Hollywood hands us a product name

Throwing spaghetti all over the kitchen to see what sticks.

ScriptEase:ISDK

Distributed Scripting (client/server, security, etc…)

Whatever happened to Distributed Scripting?

Web(ish) Apps and Small Servers

Remote Agents:

And other miscellaneous stuff

The End

A Letter to our 1992 selves: What we should have done different

Links

The Bad Old Days of Programming Yore

The times in which I lived, and the particularly problems I experienced before founding Nombas, influenced the directions Nombas took, whether good or bad.

A whole lot of languages going on

From that late 1970’s through the early 1990’s I had the need to program in a lot of different languages. At first I had no language tools, and programmed my 6502 Atari with opcodes. Then there were the “standard” languages: Basic, Pascal, Fortran, Assembly (8086, 6502, PDP-11, 360, 68000, TMS320), SQL, C, C++. There were the batch languages: Batch, Bourne, Bash, Korn, C-Shell, Rexx. Then there were application-specific command languages that seemed to go along with every new program that was released.  That was far too many languages for me. Being of limited intellect, I felt that each time I had to master a new language I would have to give up mastery of some old language.

Editorial: This over-abundance of languages is still a problem today, in my opinion, and it’s a theme to which I’ll return.

Take, for a recent example, the current widespread use of templating languages in the web space. There are several server-side templating languages people apply to their HTML code, and then there are several server-side templating languages. So already there are two problems: 1) several templating languages to choose from (crazy), and 2) the HTML templating languages are different than the CSS templating languages (super-crazy). The issue is even worse because most web developers don’t yet realize that they can optimize their systems by delivering slightly different javascript code to their slightly-different clients, but when they realize it, guess what, they’ll probably create yet another server-side templating language just for JS files, and naturally it will resemble neither the HTML nor the CSS templating languages (crazy crazy crazy).

To make matters worse, every developer that wants to prove himself will at some point develop a new language. Is it just as capable of implementing a turing engine as all the other languages that already exist? Yes. Is it better than the existing language it’s meant to replace? Maybe. Is it so much better that the rest of us should throw out our expertise to learn the new language? Almost certainly not.

C is great, but not for everybody

My favorite language was C, due to it’s small syntax (very few keywords), generality, and high performance. C was powerful and fun. If you wanted to get serious work done, you used C. (Curiously, even most of those command-specific and batch languages I mentioned above were themselves implemented in C.)

Most importantly, C was where the good and high-paying jobs were, which is why people wanted to learn C and why they showed up for an adult-education class that I was teaching. The C language had a reputation for being difficult, and so I expected it to be difficult to teach. But as we stepped through the basic syntax elements it wasn’t hard at all, almost everyone was following right along very quickly. Until...

At one point the majority of the class, who until then was learning to program surprisingly quickly, stopped clicking with what I was teaching. Certain topics just left them completely confused: e.g., pointers (incrementing and dereferencing), sizes of datum and data, allocation and freeing, stack use... It took a while, but eventually I realized where the problem lay: For a large segment of the students, maybe most, any aspect of C that involved understanding how data was arranged in computer memory just led to total confusion. Maybe I was teaching it wrong? Maybe a fundamental a background in opcodes and assembly and even circuit boards is needed to really “get it”? Maybe it’s just an unnatural concept that doesn’t mesh with most humans brains? In any case, I started to think that most of these students were never going to be top-notch C programmers, at least not with me as the teacher.

Editorial: To this day I remain constantly surprised how many people in the software field don’t understand how memory works. They may think it doesn’t matter anymore, since they’re mostly using high-level garbage-collected languages in short-lived processes. And maybe for most trivial cases understanding memory isn’t important. But without that fundamental understand “kids these day” don’t understand why their logic produce software that is slow, buggy, and changed behavior over time.

Schools, stop passing kids through a few Java classes and calling them Computer Scientists!

Bonus Rant: Everybody, stop calling Computer Science a “Science”. CS is simply one feature amoung a bigger set of tools for getting real stuff done.

Extra Bonus Rant: Kids studying CS to get rich quick, stay in school and study something real!

Data was King (in theory)

One final idea going on at that time, the rejection of which would eventually be an important part of this story, was that Data was King. By that I mean that the idea gaining acceptance was that if one could correctly map a problem to an ideal representation in a data schema, then the solutions to that problem would flow from queries against that data.

When a project came along a of time went into thinking how to describe the primary data schema, and the supporting data schema, and supporting schemas and temporary schemas to link the different schemas. With a brilliant data description, it was expected that any situation would be just an application of the database language tools (specific to the database tool, of course, until SQL toook over).

The result of this thinking was often a whole lot of interdependent tables and data, and special-case tables, to the level of complexity that hardly any real person could understand them. (This thinking even pervaded text-based configuration files, which in structure resembled large sets of interconnected tables which became so hard to fathom that only experts could get anything done--if you’re a heavy Unix systems user you’ll recognize this in the tools created during this period.)

The near-breaking point for me was when I developed an employee scheduling system for a large transportation system. By the time I was done, maintaining the system for all the employees was “simply” a matter of altering many many tables to encompass hours, zones, daily changes, regional laws, religious needs, union rules, personal preferences, system preferences, and various other rules, all of which changed frequently. During the course of that work, I began to feel that there was something wrong in being so data-centric... I began to feel that logic was important... I considered that logic out to be the “data” entered into most of those tables... It would be a few years before I got back to that idea.

MS-DOS was (and DOS Batch) was everywhere, but real programming was costly

MS-DOS, on IBM PCs and PC clones, totally dominated. It was everywhere!

There were two levels of “programming” going on: Batch files, and “real” programming. The Microsoft Batch language was amazingly trivial, but lots of people could use is and, most importantly, it existed on every machine! So anyone could write a simple batch file, and they would know that it would run on every MS-DOS machine. If you wanted something non-trivial done, you needed to find and pay mightily for a programmer proficient in the languages of the day (basic, C, turbo-pascal, asm, etc...).  The result was a wide divide between two classes of people, the batchers and the programmers.

Because DOS Batch was on every machine, and so was the only tool globally available, people figured out some really convoluted and amazing things to do with it, often exploiting the unintended consequences of bugs in the languages definition (see Microcosmic God to understand what’s possible from intelligent people using the only tools available). Magazines would monthly publish new batch files to do crazy, but useful, things. But these always fell behind what a “real” programmer could do with a system language.

Anecdote: I once went to a job interview where I was to be the assistant to their “computer guru”. Their guru came in with a giant stack of computer paper on which was his printed his master program. To see if I was up to snuff he asked me to look at a section on the middle, on page 200 or so, and tell him what it did. For a while I was simply perplexed, I couldn’t make heads or tails out of anything I was seeing. Then a crazy thought dawned on me: this stack of paper was one really really big batch file, no doubt using every batch trick in the book. Could this company really be built around a batch file?

I told them what that section of the code did, as best as I could guess it, then declined the job offer.


Editorial: This lack of a common powerful hi-level language available on every computer remains. You still cannot write a script file and send it to everyone and expect them to be able to run it without installing something first. The closest we probably have is HTML with JS embedded, since everyone has an HTML browser installed, but those are not allowed to interact with the computer. That sucks.

As you’ll read, Nombas’ goal was to solve this problem in many ways, but we didn’t succeed. That sucks.

Problem is, no powerful computer vendor wants a write-once run-everywhere solution. They don’t. That sucks.

So when I’m King of the World I’m going to declare that all computers must come preinstalled with some common hi-level language and set of libraries (python a.b with libraries x, y, and z? ok)? That’ll just be the law!

Source code was too often missing

We worked with a lot of programs that did something we wanted, but there would eventually be problems with them. Either they didn’t do exactly what we wanted, or a new version or the operating system (or some other program they depended on) would come along and they didn’t work anymore. To fix these problems required having the source code to the programs so they could be tweaked and recompiled.

This was before there was an internet in every garage and two routers in every pot, and so locating people and code could be difficult. Version control was pretty bad. Ideas of common code repositories and open source where in their infancy.

Finding that source code was not easy, and quite often the programs had to be abandoned entired (even when we’d written them ourselves).

Editorial: Another thing I’ll do when I’m King of the World is declare that executable code will always be inseparable from it’s source code. Using a script language solves that, of course, because a script is it’s source. For compiled code a second-best solution is the executable always contain pointers to where the source originated, but since that source may disappear the better solution is for language compilers to simply tack the original source code (and related make files and resources) onto the end of the executable in a way that can be commonly extracted. The law will be known as the “All boots shall contain their own bootstraps” decree.

BTW, There’s a good chance that I’m the only one who cares about this issue, or ever did, so, until I’m King, sorry to have wasted your time.

A really bad idea for a business, but a pretty useful side project

A bad idea

In the early 90’s I calculated that the cost of disk-drive storage was dropping much more slowly than the amount of new data was being created, and that the problem was only going to get worse as computer creation software became more prevalent and disk storage reached limitations of physics. The result would be, according to my theory, that soon people would not be able to have instant hard-disk access to all their data (they just wouldn’t be able to afford it), and so most of a business’ data would need to be stored on much cheaper tape systems.

So my “brilliant” business idea was to work out methods of data compression, along with intelligent algorithms to cache large-and-cheap-but-slow tape storage on small-and-expensive-but-fast disk drives, so that most of the time a business would have the data it needed, quickly and cheaply. An Infinite Disk.

So I quite may job and hunkered down to implement my brilliant business idea. (BTW, I didn’t know it then but another company was doing the same thing, calling it “Infinite Disk,” at about the same time. They actually released a product.)

What I did not realize at the time was that the discovery of GMR a few years earlier (and leading to the Nobel prize in physics in 2007) would soon be leading to phenomal reductions in the price of disk storage. It would take a little while for me to understand the flaw in my brilliant plan, but fortunately I was sidetracked by a little side project...

Working alone leads to more problems

Working on the “big idea” was the first time I’d been all on my own, and not in a larger group of developers and support staff. One of the first things I realized was how little I could do on my own compared to a bunch of people working together. Every little custom tool had to be written from scratch byme. I couldn’t afford to pay anybody, so what I needed was to become more productive as an individual. To make this productivity problem worse, there were a lot of operating systems vying for attention then (DOS, various Unixes, Macintosh, soon OS/2 and different versions of Windows) and my disk-caching software needed to run on all these systems. And so anything I could do that would work cross-platform would save me a ton of time.

Finally, in what little work I did, I realized there were two levels of programming needed. The first level was the hard core and system stuff, that needed to optimally compress and transfer data, and interact with the operating systems. For this hardcore stuff the most important thing was that in run quickly, and it was worth a whole lot of effort to do so. But there was another level of programming, which would be the high level logic and configuration needed. For this level a control language would be needed, where the performance of the language itself wasn’t nearly as important as the need to write it, tweak it, experiment with it, and customize it quickly. And I wanted this control language to interact well with the underlying hardcore stuff. I looked around for such control languages, and they all took time to learn and evaluate, and none of them seemed well designed as a library to interact with my C code.

I had a lot on my mind, it seemed like too many problems to solve. I was lost for a solution.

So I decided to build a darkroom in the basement.

Cmm (C minus minus) - a solution to a bunch of issues

While building the darkroom, I had time to think about a lot of issues, all of which I’ll list here even though they were described in more detail above:

The big “aha” thought was something like this: What if I were to remove the parts of C that most people don’t understand, would it be just as powerful and suit my other needs? On more thought I realized that memory size and layout meant starting with C, but removing type declarations and pointers. Without these two things I called it “C minus minus” (a play on the popular C++ language that adds to C), and experimented. In short, this meant that most C programs would run just fine as Cmm if you simply deleted the type declaration keywords, and any symbols involving memory (“*” and “&” when refering to addresses, and replacing any “->” with “.”). An amazing number of useful side-effects of a script language fall out of these simple changes (from lack of allocation problems to first-class function manipulation). More discussion of C versus Cmm can be found in old documentation here or here.

On the unpainted wall of the darkroom I wrote up most of the initial ideas and algorithms for implementing Cmm, then soon got to work implementing.

Testing whether Cmm was worth pursuing

Cmm was working tremendously well in my “Infinite Disk” project. I made sure that the entire C library and more was available to Cmm (minus the memory parts the were irrelevant) and soon was writing tools like crazy using a standalone version of the program (called “CEnvi” because it satisfied my “envy” of always having lots of C programming capabilities available to a “batch” langauge), and I was adding it as a control language to my core software, and satisfied my brain that it didn’t have to do major cognitive shifts between the different levels of work I was doing.

I felt really good about what Cmm was doing for me, and so I posted a message on a couple of boards (probably a CompuServe and a Usenet group) saying something like “here’s this thing I’ve made that I found really useful, usually that means I’m duplicating someone's work. Whose work am I duplicating?” The responses were much much better than I’d expected. Everybody seemed to see that Cmm was unique and not duplicating other work, which surprised me, but even more surprising were the number of people who wrote back with “see all the cool things I’m doing with this”.

The responses were so positive that I decided to put aside the disk-backup-cache thing for a while, and concentrate on the language. I didn’t know if a business could be built around Cmm, at least not enough of a business to put shoes on my kids’ feet, and I also didn’t know if this made more sense as a standalone product or as a software library that people could embed into other products.

Anecdote: A few years earlier I’d worked with a consulting group that was chock full of MBAs. I wasn’t always happy with their business practices, so during one lunch I told one of them “someday I’ll started a business and call it “No MBAs’ and no MBAs will ever work there.” So when it was suddenly time for a d.b.a. name and a logo I created this:
 


The original manual that shipped with the first products had the text “No Ties, No Lies” at the bottom, but I haven’t found a copy of that manual.

So I set out to create two separate products, as a test to see which of the two products was the real way to make any money, and I gave myself until the end of that year (a few months) to run the experiment. The products were:

Editorial: Engineers are terrible at creating product names: names like “Cmm” and “CEnvi” and “Nombas”. Friends don’t let their engineering friends create product names.

By the end of that test period I’d licensed the library to one customer (for what I felt was big bucks), and orders had come in for the standalone shareware including a large (to me) bulk company license. So the sales experiment had been a surprising success for both software models. In that period I’d also received unsolicited interest from an investor. So I decided to try to make a real business out of selling both the CmmISDK and the standalone CEnvi interpreter.

Editorial: These days nearly everything is free and open source, but back then it was normal to pay for software libraries and tools. Even so, a few people advised me nearly twenty years ago to try the then-novel approach of giving the Cmm code away for free. “But,” I asked, “how do I feed my kids and pay the mortgage if I give my hard work away for free?” They answered, “giving it away gets into into more hands and gets people addicted to it, and then you can charge a few of them a lot to fix the bugs.” I found that model appalling because I have a thing about bugs in code: I don’t like them. There was no way I was going to be releasing buggy code, even if it did mean I’d get paid a lot to fix those bugs. I just couldn’t do it.

Go ahead and say it: “People used to deliver quality software that was well documented, tested, and supported? and they expected to get paid? How quaint!”

Nombas formed to promote scripting

Three-step road-map to world domination

I partnered with my buddy Seth to start Nombas, Inc. Together we devised this three-step road-map to rule the world:

  1. Remove the existing stigma against script languages, and evangalize scripting as a full-powered tool to be used alongside of and, when appropriate, instead of system-level languages.
  2. Teach the world about our particular script language, Cmm, and it’s many advantages, so that our language will become the most popular script language choice.
  3. Develop Nombas Inc. as the most popular source for that script language.

According to our original predictions, steps 1 & 2 were going to be very challenging because they involved changing a lot of minds about how software was made. But if we did succeed with 1 & 2, then step 3 would result in a big big payoff. The initial sales were promising but did not bring in enough money to implement our world-changing plans, so we expanded the three steps into a fuller business plan and flew from our homes in Massachusetts to Utah where my father had recently started a V.C. firm named Canopy. We secured enough from Canopy to get a small office space, buy some equipment (I’d been running everything up until then on a single PC), and hire an assistant.

The first Nombas office. Above the Chinese World Furniture shop.
That air conditioner? Just for show.

Editorial: If you can possibly avoid it, do not get funding from family. Even if you can possibly avoid it, don’t get funding from family. Just don’t.

We were in business.

Editorial: The real reason I wanted Cmm to succeed: to democratize programming.

It wouldn’t belong in any business plan, and I seldom mentioned to anyone, but the real reason I wanted Cmm to succeed was not about making money (although paying the mortgage was always important). The real reason was because of the feeling I had when I programmed a computer to perform work for me: that sense of tremendous power, equivalent to ordering of hundreds of thousands of accountants to performs calculations at my bidding. I could see that most people never felt that sense of power because most people couldn’t program, and so were beholden to the small percentage of people that were good with computer languages: the C (and equivalent) programmers.

But that experience teaching C showed me that most people could program, if a couple of issues would stop holding them back, and Cmm removed those couple of issues.

So the real reason I wanted Cmm to succeed was to take that programming power from the elite developers (maybe 5% of the people) and share it with everybody (maybe 75% of the people). I wanted to democratize programming.

The Cmm business

I truly believe that our CmmISDK, CEnvi and other related products (most later renamed, by professional namers-of-things, as “ScriptEase XXX”) were excellent and a great value to their users. We were constantly surprised by what our customers did with our tools, often beyond what we’d imagined. The reviews were almost always very good, we made a lot of must-have lists, and won a Shareware of the Year award from PC Magazine.

But selling remained a struggle for the reasons we predicted: before getting to selling our product we had to first educate the potential customer on 1) the value of scripting over traditional languages, and 2) then we had to convince them that we had the right language and tools for the job. Our pitch for scripting in general was that it was a huge performance boost for any developer, but also brought in a level of control that greatly enhanced product customization and allowed that customization to be implemented by a lot more people with fewer skills. Our pitch that we had the right language and tools was that they were probably already using a C-based system language and by using Cmm and our tools their developers did not have to change their way of thinking between hard-core library versus customization code, and it became only a matter of deciding when it was more important that the code be high-performing (those first version of Cmm were not fast) or the developer be high-performing.

Editorial: That argument still resonates with me that Cmm made sense because it was nearly the same as C, and so didn’t require the developer to have to think too differently when moving between the system-level and the script-level languages. Note that we weren’t arguing that it was a better language, only that it was most-similar and so didn’t require different ways of thinking.

At the time there were already scripting languages (e.g. C-like unix shells, rexx, jcl, tcl, bat, to name a very few) and lots of application-specific languages, and the idea of more general-script languages was really catching on (e.g. perl, lua, python, tcl, were all young or being conceived about the same time) but they all seemed to be creating a new language paradigm, and limiting functionality, rather than taking the existing most-popular language (C) and making it a script language.

So what’s wrong with all the different languages? Nothing, if you enjoy the mental exercise of creating and/or learning new languages. But usually that’s all they are: a mental exercise. I’d rather be using mental muscle to create new products, not to create new languages that would create identical products. No language is really any better than any other (IMHO), they’re all turing-complete mappings of each other. So why keep creating new ones.

A teeny tiny example: In my most recent projects of the past few years have been combinations of Python, Javascript, Java, and Objective-C. Every time I have to handle a simple boolean condition, my mind has to race between the various options these languages use for booleans (true/false, True/False, TRUE/FALSE, 1/0, and YES/NO), and if I get it wrong (which I usually will) some part of the system fails and time is wasted. And this is just a teensy weensy example of how too-many similar languages mess with our minds and waste our productivity. I calculate that the boolean problem alone has wasted 60 years of my life (and I’m not even 50), so not only has this been a big waste of my time, but it has also clearly destroyed my ability to do time-based math (don’t even get me started on the different way these languages handle time).

(Is it hypocritical to complain about too many languages being created in a document about creating a new language?)

If we got through steps 1 & 2, step 3 was relatively easy because there was nothing close to Cmm as an embeddable or standalone batch language (not yet, anyway). The final barrier remained to convince the customer that Nombas was not a fly-by-night operation that would go belly up any day.

Editorial: It is very valid to be concerned that your vendor, on whom part of your own business will rely, won’t be around forever. Because they won’t. Almost none of the vendors Nombas relied on then (for compilers, email, our BBS, backup, most OSes, payment processing, advertising) exist anymore.

And so it was very valid for our own potential customers to be very concerned about relying on our long-term viability (indeed, Nombas doesn’t exist anymore, and though I still support some Nombas customers that is generally ad-hoc, and when I have the spare time, and if I happen to still remember anything applicable). I was surprised in the beginning that some customers wanted to pay more than we were asking, just because they were concerned about keeping us around long enough to support them.

This vendor-reliability problem may even be worse nowadays, with so many applications relying on web service APIs. There is really no guarantee that that great web service you rely on will be running 24/7, or that the service won’t shut down tomorrow, or the API won’t change when you’re not looking, or it’s usage limits or TOS haven’t already changed. It doesn’t matter how big or non-evil-seeming your vendor is, their API you rely on can change or vanish in an instant.

For Nombas we could mostly solve the problem by showing that our customer base was increasing, by offering escrows, and later by giving source code to almost everyone, and for a while by showing that there was an alternative similar-enough engine from Netscape. But for today’s web-based APIs, a vendor-reliability solution is lacking.

We were getting customers, making money (roughly doubling every year up to a little over a million dollars in our best year, though we almost never brought in more money than we spent, and so most years dipped into the VC pool till that went dry), moving to pure C to support smaller environments, and hiring really qualified developers (not coding ignoramuses like myself) to make our script engine fast and to turn the ISDK a real quality product.

The Java thorn in our side

Around the time we were finally making inroads with reaching minds and helping customers enhance products with our script language, Sun was also working on Java. Java was also a cross-platform, garbage-collected language, but much more complete in being its own environment rather than a language to embed into other programs. For a few years, just as things were looking easier, Java became a huge thorn in our side. The problem with Java was that Sun made so many promises about how it would cure every ill in IT, and Sun put so much money into marketing Java, that people started to believe the hype. So even as we were showing off great productivity gains from our script tools, we would commonly get feedback like “that’s great, but irrelevant, because pretty soon Java is going to do all that, and more, and much better.” Sometimes this meant we lost sales to people who were going to wait for Java, and sometimes customers made smaller commitments to use our tools as a stopgap until either Java became a little more or until they’d converted their entire system to Java--for a while we were even quietly licensing our ISDK to Sun for a project for which Java wasn’t quite ready.

To counteract the Java threat I became a Java critic, complaining that it was too slow to be a good system-level language and too complex to be a good language-for-the-people, but mostly complaining that a programming language should be accepted on its own merits (of which Java had many), and not based on the amount of money that goes into marketing it. I argued that the most important area to conquer for productivity was not the particular language (nearly all programming languages are Turing-complete equivalents of each other), but how well they handled the many interfaces involved (between components, systems, and people). I argued that our tool was the best approach (of course) for such productivity.

Editorial: My arguments against Java had validity, but mostly I was just being self-serving because I wanted people to accept our tools instead of Sun’s. I’m a hypocrite.

I wrote an essay, “Java, The Illusion”, that was copied and read surprisingly widely, and led to free press coverage and chances to talk as “the anti-Java guy”. (See, for example, this “Java Joust” article covering an online debate with Sun’s Eric Schmidt—I don’t know if I won the technical battle, but I sure as hell won the battle of the hair.) In the end our Java battles didn’t help us nearly as much as what was being done by Java’s first commercial customer… 

The switch from Cmm to JavaScript/EcmaScript/ScriptEase

What’s this “web” thing everyone is talking about?

When Nombas began, the internet was not something most people had in their lives. The World Wide Web had been invented, but hardly anyone knew that (I sure didn’t). The entire Nombas infrastructure consisted of a single PC running OS/2 and a BBS (so the world could dial in and retrieve sofware), which I also used for development of DOS, OS/2, & Windows software, and for communicating with the outside world via CompuServe.

With the founding and funding of Nombas, Inc. we could afford a real internet connection (via ISDN, and it cost a pretty penny) and real email and to set up a real FTP server to supplement the BBS. We were also able to start investigating this whole “World Wide Web” thing that everyone had been had been talking about. The WWW and browsers were pretty darn cool!

Demonstrating client-side scripting in web pages: but no sale

Since Nombas was all about enhancing programs with embedded scripting, we performed some quick hacks on the Netscape browser (version 0.9, I think) using CEnvi (which had tools to dig into and even alter Windows program behaviors) to add Cmm as a client-side control language. The round-trip between a client and the server was pretty slow then, so we figured that embedding some logic directly into the client we could make a much better user experience. That hack demonstrated instant keyboard processing, client-side form-validation, image swapping to simulate animation, and a very trippy image-color manipulator. Sun was starting to talk a whole lot about their upcoming Java that would improve the web, and since we saw our technology as better suited we named these pages the “Espresso Pages”.

We showed off these pages to everyone we could find working with the web, and since Netscape looked like it would be a big player we made a special effort to contact them to make sure they were aware of how a client-side script language could greatly enhance their product. Netscape wasn’t interested in a license (for which we were likely asking our usual $10,000 for unlimited use) so we moved on.

Editorial: Our pitch to Netscape wasn’t anything special, we made similar pitches to all kinds of companies making all kinds of products; usually they would pass and occasionally we’d make a sale. I mention Netscape, as opposed to all the other customers we failed to sell to, for a couple of reasons. First because, as I’ll describe in a moment, what Netscape soon did had a huge impact on our business. Second because I’m frequently asked if the stories are true that Netscape ripped off Nombas when they put LiveScript/JavaScript in their browser.

When I first saw the LiveScript specification and their representative use cases, just a few months after we’d presented our product to them, I was ticked off that Netscape had defined something similar to what we’d shown them instead of just licensing it from us. But Netscape’s language certainly wasn’t exactly the same as ours—similarities could very well be because any language created at that time would be a product of that time and the ideas in the air at that time. Brendan Eich, the person who did create JavaScript at Netscape, would later talk to me about the issue and he assured me that before creating JavaScript he’d never heard about Cmm nor the Espresso Pages, and I believe him.

Come to think of it, my memory is not clear on whether the Espresso Pages were created before our Netscape pitch, or were created soon thereafter to clarify by example why browsers needed embedded scripting. I do remember being resentful of Netscape in those early years, enough so that when they released an expensive toolkit for administrators to configure their browser, I released a version of the same thing (using a CEnvi bundle that hacked their browser) for free. People in the software world lack maturity.

Funny thing: it turns out that there already was an even earlier web browser that included client-side scripting, ViolaWWW, and it demonstrated many of the same things our Netscape hack demonstrated (at least that’s what Wikipedia says, so it must be true). Did Nombas rip off from ViolaWWW? No, I never even knew about ViolaWWW until last month, but it just goes to show that there were certain ideas in the air at the time.

Netscape’s JavaScript becomes too popular to fight, so we switch to “the standard”

When Netscape released a browser that included their JavaScript language, its adoption rate was phenomenal. JavaScript was soon duplicated by JScript in Internet Explorer. Within a few months JavaScript use seemed to have taken over web development. Soon, nearly every developer was at least aware of the JavaScript language.

Editorial: I use the term “JavaScript” here and throughout this document, even though it’s a horrible name (“JavaScript” having little to do with Java except for marketing and a couple of unnecessary Java-like keywords), because that’s the term just about everyone else uses. After the first bunch of ECMA standardization meetings the language name was technically “EcmaScript”, but that’s even more horrible. Netscape’s original “LiveScript” name was pretty good, and so of course it was quickly dropped.

Remember what I said earlier about not letting Engineers name things?

At Nombas we then had a painful decision to make: stick with our existing customers and our own relatively unknown Cmm language (which of course we felt was superior to the “flawed” JavaScript), or switch to supporting the JavaScript language that had so quickly become well-known and popular. We decided, of course, to switch to JavaScript but to do so transitionally, so that for a few versions our interpreters supported both Cmm and JavaScript (for most scripts they looked the same anyway) and eventually only JavaScript. We had relatively little trouble getting our customers to switch to pure Javascript along with us. (I believe that all of our customers intended to switch, although some never quite got around and still use old old Cmm code (printf(“Hello 1993, this is twenty-years-later calling”)).

Actually, most of our customers did not choose to stick with a “pure” JavaScript standard, in that we offered many compile- or run-time options that would allow behavior slightly different than the JavaScript found in browsers (and only a few of our customers were making web browsers). These options would either improve on the flaws of JavaScript, or allow for extra useful behavior that wasn’t in the official JavaScript language (and wouldn’t make their way into the “standard” JavaScript language for a long while, because of the glacial pace of the standards process).

Editorial: Standards!

EcmaScript was a “standard” meaning that some organization was paid a bunch of money to say “this is a standard”. For EcmaScript that meant “however JavaScript behaved in some early browser incarnation is how it shall be forever be defined” meaning effectively that EcmaScript was stuck with whatever warts existing when Brendan Eich defined it during a mad rush to create the first version of the language.

Standards are great for getting everyone on the same page. But they also make it really hard to turn to the next page.

Thanks, Netscape, for making our job a whole lot easier

Switching to JavaScript had been scary for us. It meant losing control of our own language and instead following somebody else’s lead. Because Netscape was packaging their JavaScript engine as a standalone SDK product, it meant that for the first time we had direct competition for our most important product. Netscape’s first SDK version wasn’t very polished, but by the second time around they had a decent JavaScript product. They were charging more than we were (about four times, I recall) and so we had a little price advantage, and we had many years lead over them in many areas (performance, size, robustness, integration and debugging tools, integration experience, even independent developers who knew how to use our tools and so could consult), but since it was now Netscape’s language we were using there’s no doubt that Netscape was almost everyone’s first choice in exploring JavaScript integration.  After plunking down $40K (est) for Netscape’s engine, companies were reluctant to want to try our JavaScript engines. That was all very bad for our business.

But another funny thing happened, thanks to Netcape’s JavaScript becoming so popular so fast, what they did turned out to be very good for our business. Before this time, the toughest part of selling our product had always been 1) teaching the value of scripting, and 2) convincing them that we had the right language. Because JavaScript was so popular (thanks, Netscape), these were quite suddenly non-issues. It wasn’t even such an issue for potential customers that Nombas might go belly up any day, because now there was an alternative supplier in Netscape.

As always, sales increased (as always, not quite as much as our expenses as we explored other product areas), but we worried that fighting against the Netscape competitor (showing that we were better and cheaper) kept getting more difficult as their product matured closer to ours, and we worried we may be fighting a losing battled. Thinking “if you can’t beat ‘em join ‘em” We started working more closely with Netscape on APIs and Debugging interfaces, and giving them information to help with some acquisition talks they were having internally (said my source)…

And then one frightening day, at the start of 1998, everything changed. On that day, Netscape announced that they were giving all their code away for free: open-sourcing everything, including their JavaScript engines. Our major competition, to whom we might very well have been losing the war, was no longer more expensive than us but instead was infinitely cheaper: free! We knew our business was doomed.

Editorial: I suck at business. Don’t ever take my business advice.

But, once again, what looked like a disaster was actually a huge opportunity, only I wasn’t wise enough to see it at the time. Our competition giving away their product was very very good for us. Before this time, most people wanting a JavaScript engine would go to Netscape first, pay them a decent chunk of money, and then we’d never have an opportunity. But now that Netscape’s was free, they could try out Netscape’s engine for free (instead of paying into it and so feeling locked in to having to use what they’d paid for) and if they weren’t happy with it, or just were curious, they could also try our product for free (our product was always free to try out). In a side-by-side comparison of features, performance, quality, and tools, the Nombas engine would almost always come out ahead (and we didn’t really cost a whole lot). For a smaller set of customers, using an open-source product made them queasy (even thought’s Netscape license was about as non-restrictive as possible), and so they went with our ISDK. And for others, they worried that Netscape was now actually more likely to go belly-up than Nombas. Putting all these factors together, our competitor giving everything away for free helped us a whole lot more than it hurt.

Editorial: Netscape did go belly-up before we did, if you consider a $4.2 billion acquisition by AOL as “belly-up”. Netscape lost the browser wars because Microsoft gave IE away for free, and because of their hubris in thinking they were so great they’d take over the world. I believe Netscape’s original plan for success wasn’t actually to make money selling their browser (which they seldom did) but to make money from web server software and their Netscape portal, which seems a bit ridiculous to me given that no software is easier to put together than web server software and portals.

I personally hate the idea of using free software solely to hurt competition, as happens so often in the software industry, such as with Microsoft (successfully) in the browser wars, and Netscape (unsuccessfully) in retaliation, and now Google (success to be determined) in the mobile OS wars. This behavior should be called what it is— “predatory pricing” or “dumping”—and should not be tolerated in the software industry any more than it is in any other industry (automotive, steel, agriculture, etc…)

But what do I know? I suck at business, or hadn’t you heard?

Thanks, Netscape, for all the help. We couldn’t have done it without you.

Hollywood hands us a product name

In 1996 Demi Moore starred in “Striptease”. I never saw the movie. Critics mostly hated it. It was considered a flop. But there was a lot of publicity behind “Striptease” and so everyone knew about the movie. About the same time Nombas hired a high-priced consultant to come up with some better names for our products. It didn’t take her long: “ScriptEase”. The very sexy name stuck, and from then on our language and all products were called “ScriptEase”.

Thanks, Demi. We couldn’t have done it without you.

Throwing spaghetti all over the kitchen to see what sticks.

Over all the years Nombas was in business we continued to improve our basic engine, tools, and API’s. That continual improvement on our ISDKs remained our primary focus. We continued to be impressed by the inventive ways our customers were using our ScriptEase Javascript engines in their own products, our sales generally continued to improve, and we continued to believe in our tagline: “power and simplicity through scripting”.

Having fully partaken of our “power and simplicity through scripting” Kool-Aid, we were convinced we had a really excellent hammer and the rest of the world did not recognize how many existing problems were really just different kinds of nails for our really excellent hammer. To us, everything seemed like just another problem easily solved with scripting. So we invented lots and lots of solutions that all involved our script engine in one way or another (of course), and either made these solutions available within our products or as separate products. Some of these ideas really were good, and either caught on or were too far ahead of their time. Some of these ideas were just stupid. Whether the idea was good or not, we usually executed poorly (blame the CEO).

Editorial: “We have a really good hammer, what can we do with it?” is not a good long-term business strategy. Lesson learned. Maybe it’s enough to just make a really good hammer. Maybe go out and pound in a lot of nails. Maybe keep making the hammer while you work on making a really good screwdriver, too.

So we were like cooks, very proud of our spaghetti noodles, and throwing them all around the kitchen to see where they would stick. The primary areas (as described in more detail below), where:

ScriptEase:ISDK

As already said, SE:ISDK remained our bread-and-butter. This is what the customers licensed and was where nearly all our income came in (and initially came in a box: front, back). Mostly these were C/C++ users, but we also had some success licensing to Java users (first with JNI version that provided a Java API to our C engine, then as a pure Java interpreter). Over time we improved code, integration tools, editors, debugging tools, libraries, and so on. I’ve probably written enough about that already that I won’t add a whole lot more here.

Distributed Scripting (client/server, security, etc…)

Of all the innovations we made (beyond the pure scripting thing), this is the one I was most absolutely excited by.

Here’s the background: Back in ancient computer times (the 1990’s) there were a lot of complexities in getting computers to cooperate. For instance, if you wanted to send data from computer A to computer B for processing, and get some data back, there had to be agreement about a lot of communication and data protocols. The mind-set of the day was still “transmitting information and computer processing speed are very expensive, so we must minimize the number of bits transmitted and the amount of CPU used.” The result was things like CORBA, and DCOM, and XDR, and lots of competing RPC protocols (things like XML-RPC and SOAP were on the horizon if kept up with Dave Winer and Scripting News). At Nombas we were supporting a lot of these things in our libraries (we tended to make pre-built script-accessible libraries for as much as possible, so our customers wouldn’t have to), but we were constantly struck by how gosh-darn complicated these protocols were. Not just complicated to write code for, but complicated to debug when they didn’t work: you’d have to see what was going over the wire, work a while to decode those bytes, then some engineer from Vendor A would get to arguing with some engineer from Vendor B about why their implementations of a complicated specification weren’t compatible.

It dawned on us that there was an easier way. Our script language was already, by its very nature, a way to represent complex data and algorithms in a way that was portable between systems, and independent of OS, endianness, or word size. Also, our emphasis in our script engine had always been to make it trivial to interoperate between compiled code and interpreted script, both ways. So, putting these issues together, here was the big a-ha: What if the data that went between machines was always script code (instead of any bitwise-defined protocol)? It sounds so simple, but what would result?

Editorial: Keeping things simple for humans eventually always wins. If you’re designing some new protocol I think you should always imagine that whoever is using it is half as smart as you, and drunk.

Take HTTP and HTML, for example. I like to imagine a meeting of top Sun engineers in the day, as they’re poring over protocols designed to squeeze every millisecond and every byte out of data sharing protocols. Then Tim Burners-Lee walks in and says “Hey, guys, I’m going to do this thing where I send text strings around, with verbose verbs and tags, over a stateless protocol with lots of headers”. The way I imagine it, Tim Burners-Lee is laughed out of the room as one of the engineers says “that guy is so stupid” and another says “and probably drunk”.

So we wrote a bunch of code to see what would happen. We already had the basic code for interpreting scripts and interacting with compiled libraries. We added clever serialization code so that data and even functionality could be represented as script. We added clever code to let clients and servers interact seamlessly so it was very easy with just a few lines of code to make it just as easy to work with a remote machine as to work with local program (in fact, difference between “client” and “server” became indistinguishable as they both just became parts of the same computing system). We realized this introduced error, synchronous, and security problems, so we wrote clever code for all these issues (security being most interesting, because it let us solve the problem of receiving data and logic from a remote machine and to very—using scripting of course—how that data and logic could be used).

It worked fantastic! Seriously, so many things that had always been hard had become just plain easy.  Like:

Whatever happened to Distributed Scripting?

Distributed Scripting worked as well as advertised. It got some nice buzz in magazines, trade shows, and research centers.

Anecdote: One of my favorite times when I was sure we were on to something was when I was talking to a magazine guy, describing over the phone the kinds of things Distributed Scripting could do. He did not believe any of it. I said, “I wish I could show you” and he said, as if throwing down a gauntlet “hah, I bet, well it just so happens I’m in your town today”. So I rushed to his hotel and showed him everything live, including how easily it was all put together. The result was one of the best write-ups we’d ever received.

But Distributed Scripting didn’t really catch on at the time. I think the world wasn’t ready for this thing that seemed a bit magical. We kept working on it but by the time Nombas was “Un-Incorporated” we had only ever had a couple of customers doing anything with it. We’d had a patent pending on these things for many years, but because of the legal expenses as we went back and forth with the patent office, and because Distributed Scripting was not catching on like we assumed it would, we finally let the patent application drop.

Editorial: The only time we ever applied for a patent at Nombas was for Distributed Scripting. There is a lot of debate about software patents, and whether they should exist at all. I personally feel that they should exist, but that they should be very rare, only for something that really makes your jaw drop.

The funny thing about jaw-dropping new ideas is how quickly they become boring old ideas, so that very soon everyone starts to think, “that idea is obvious”. Do you remember, for example, the first time you saw Google Maps and could scroll around the world in near-real time? That kind of thing seems old-hat now but the first time you saw it, did your jaw drop? The new tricks Google Maps were using were just a subset of the kind of thing we were doing with Distributed Scripting, so, yeah, maybe it was worth a jaw-drop at the time.

I myself wasn’t positive that Distributed Scripting was patent-worthy (according to my definition) but our VC funders sure did, so we applied for one, and kept reapplying each time the patent clerk would find some part of our way-too-long patent that matched a bit of text from any other way-too-long (but usually totally unrelated) patent. We were quite sure that the idea would catch on, so we just kept at it (until we gave up, then later on the ideas did actually catch on). What a pain in the ass!

Most of the ideas we developed in Distributed-Scripting have eventually come around again, developed independently by other clever inventors, and hopefully these techniques will stick this time.  JSON has taken over in a big way (I used to have to give training sessions and pep talks to get people to accept the idea of transmitting javascript-like data instead of XML, but now that’s just the default). AJAX is ubiquitous too, but that seems to be only a small subset of what we were trying to accomplish. Most interesting are the projects sprouting up lately that really are sharing data and logic between clients and servers, such as dnode, and nowjs, and meteorjs. These can succeed this time (I believe) because of  javascript (esp. V8 engine) and nodejs acceptance, and because what they do no longer seems so “magical”.

Maybe it takes 14 years. But good ideas eventually have their day, eh?

Editorial: Timing is important if you want ideas to stick. A good pitchman helps, too. (See “In praise of Douglas Crockford, genius” for the semantic tricks that eventually let JSON catch on, which was long after the XML was generally-accepted to not-very-successfully solve a few of the issues we were tackling.)

The only areas of Distributed Scripting that we haven’t seen catching on in this latest round of reinvention are:

Web(ish) Apps and Small Servers

Another product category Nombas tried to attack from multiple angles was what may be thought of as “writing applications in a webbish way”. We were seeing that people were able to write web applications (using HTML and Javascript) much more quickly than they’d ever made traditional applications (due to the simplicity of the model, and the clear separation between presentation and logic). But those applications were only running against some remote server.

Our thinking was that if that “web server” were running on your local machine, using a browser view as its presentation layer, then one could write an application very quickly to run on a local machine. We weren’t picturing super fancy applications, like games or full word processors, but the many little applications people needed every day (e.g. installers, office time-cards, quick one-off custom tools, etc…)

When this worked best, these few steps would allow a developer to create a lightweight GUI program very quickly:

  1. developer starts our little local servers, creates some html forms and such
  2. the html interacts with the local server (via localhost) so that the localhost does the real work of reading/writing files, working with the computers hardware and OS, etc…
  3. when it’s working the developer uses our bundle tool to put the whole thing in a few executables (to match multiple OSes) and distributes as they see fit.

The problems we kept running into were:

We created a few versions in our attempt to implement this vision: “MinWebServer”, “ThinServer”, “ServeAlot”.

Editorial: I believe that writing a web server is about the easiest programming anyone could ever do. Input and output are generally well-defined strings from well-defined input sources. Compared to managing real user input, managing HTTP conversations is a no-brainer. Of the many web servers I’ve ever been involved in, I particularly liked “ServeAlot” as just a few lines of code and then a hook to “handle the request here”. It sure beat getting Apache up and running.

The “Web App” idea never worked out for Nombas. Again, we were either too early or just executed poorly. Nowadays, using HTML and Javascript for applications is huge: it’s how more and more mobile apps are built, it was the basis of WebOS, and in upcoming Windows 8 it is the standard model for making Metro applications.

Update October 2014: I just uploaded version 0.0.1 of "slfsrv", which is kinda-sorta like the old ThinServer, in that it allows simple desktop applications to be written using the existing browser to handle the logic and GUI. It also incorporates the old CEnvi /bind trick, allowing the html+css+js to be bundled into standalone, distributable, cross-platform executables.

Now that there's a name for this kind of thing, "localhost app", maybe it will catch on this time? Check it out on github: slfsrv

Remote Agents:

Because we had a tight little scripting engine that had hooks to do everything any other language could do (e.g. calls into the OS), Distributed Scripting to let computers cooperate remotely, and Security levels to prevent remote machines from performing bad commands, we explored what we called “Remote Agents”. We investigated three major areas with agents:

We didn’t have success in the Agent department. I think the timing might have been right, but we were not sure enough of ourselves and didn’t really commit—we didn’t try hard enough. Groups that had more success with somewhat similar approaches: Gomez for remote monitoring, and Puppet Labs for using agents to manage a whole lot of systems.

And other miscellaneous stuff

Just to be complete, here’s other random stuff I remember Nombas working on that seemed real cool at the time (sorry, old Nombasoids, if I’ve forgotten to list your favorite project):

The End

We survived the early part of the dot-com crash, which started in early 2000, pretty well, because most of our customers were not dot-commers. By late in 2001 we were finding our customers were starting to be later and later paying their bills (which was understandable, as our customers where in turn starting to be paid late by their customers). Then some bills started to not be paid at all (again, understandable). Then some notices from customers about their bankruptcies came in. All in all, it wasn’t a great time to be selling software tools.

Our monthly financials were posted on an internal web page for all to see. It was clear what direction our finances were headed, and that was down. I was personally ready to throw in the towel because I’d started to go in debt to keep the company afloat. One by one we had to lay off employees until it was down to just two of us. We bought ourselves from the VC (at their loss) and from our landlord (at their loss) and worked out of our respective homes for the next year or so.

That phase was actually kind of fun. There weren’t so many paychecks to worry about, money was coming in enough for the two of us, we owned the company, and we could experiment with different licensing and payment models.

For a few years we’d been testing the waters to see if we might get acquired, there were a few nibbles but no solid bites. It wasn’t until this final period, when we’d stopped even looking, that a solid offer came in from Openwave. It wasn’t a ton of money, but it was enough for me to get out of debt and for most of the people who had worked a long time at money to get a little monetary surprise.

We moved to California, released all our customers of their obligations, and that was the whimpering end of Nombas.

The Nombas IP was used in some really good Openwave projects for a few years (modern browser, a couple of next-generation mobile phone frameworks, and a testing framework), then was sold to someone else along with all Openwave client software, and then to someone else, and then… I’ve lost track.

And so it went.

I still hear, now and then, from some of the old customers who are still using the tools and want some technical support. Sometimes it’s to look for a bug, or to recommend a workaround for an issue. Sometimes it’s to get a recommendation for how to replace their use of a Nombas product. It’s good to know I can still be useful. One of our final customers is even now preparing their initial product launch, over nine years after we made the sale, and that’s pretty darn exciting.

A Letter to our 1992 selves: What we should have done different

When I get my time machine, I’m going to send this letter:

Dear Nombas circa 1992:

Hello, 1992. This is Hindsight writing to you.

The scripting thing you’re about to do is a really good idea. A lot of people are going to become a lot more productive by using high-level languages like what you’re going to create. High-level script languages are going to overwhelm the software development world, even more than you’re so-far imagining.

The most important way you might screw this up is by charging for the wrong things.

Your standalone CEnvi product is going to be great, and people paying money for it will excite you. That nickel and dime stuff (or $39 to $69 stuff) isn’t the money you want. That price or any price is a barrier to entry to getting people to use Cmm or (get used to this name) Javascript. Only a few people are going to realize the thousands of tools in that CEnvi box and will pay for it. What you want to do with CEnvi is to give it away to everyone, so that it’s free for them to use, so that they feel bad if they ever move to a system without, so that they’re addicted. Work with those who release ANY operating system and get your code into it (BTW, that thing called “linux” is going to be big: look into it.) Make sure every CS college student has access to CEnvi. Keep basic CEnvi free. It will catch on that way.

If you want to be the de facto and cross-platform scripting and automation (and believe me you do), then DO NOT neglect the Macintosh operating system, or any operating system, with CEnvi. I know it seems like a lot of work just to make a very-portable tool across DOS, Windows, OS/2, and the *nixes, and your brains may seem fried if they have to also have to become Macintosh experts. But do it. The Macintosh thing is going to catch on, and if your CEnvi is a second-class player on that system then you will not achieve true default acceptance (i.e. you won’t be the lowest-common denominator tools available across all OSes), and the Mac people will have to wait years for a good command-line or automation tool, and Apple is going to have to eventually make something called AppleScript and it’s going to suck. You can prevent that by concentrating on Mac early.

Free, I repeat, free, is the right price for CEnvi. On day zero people don’t know how much this tool will enhance their lives, so they’re not willing to pay for it, so don’t ask them too. Give it away for free so it becomes an addictive drug. You can charge for a few things, such as the “pro” ability to make standalone executables, and for some of your own development and visual tools, and for working with vendors to add their own enhancements.

Most of what I say applies to the web server tool too. Give it away. Better yet, just make it an enhancement to CEnvi.

As for the ISDK, there too you have to greatly lower the cost barrier to entry. Make it free for small projects, student projects, experimental projects, and non-commercial open source projects (that “open source” term will be coined soon and will become really popular). You will be able to charge for tools, many types of embedding, your expertise, and for large commercial products. When that happens, charge A LOT—remember that you’re not selling them a software library, you’re selling them a helluva lot more productive, and they NEED that.

Avoid taking VC. Stay at whatever small level you need to not lose money and to stay out of debt, but don’t take VC. Don’t.

Finally, have more fun. Make more bold statements. Try more crazy things. Don’t get in a position where you have to worry so much about paying all the bills, so you have more time to take pleasure in achieving the original goals: empower people to make the world a better place. What’s the worst that can happen? You have to shut down and take a regular job? Guess what, buddy, that’s going to happen eventually anyway, one way or another.

Links