Used: CBasic -> FORTRAN -> Z80 Assembly -> Lotus 123 (see below if you don’t think spreadsheets are a programming language) -> C -> 8080 / 8086 / x86 / 68000 Assembly -> Hyperscript -> Eiffel -> Objective C -> C++ -> Java -> C#.
Tinkered With: TRS-80 Basic -> 6502 Assembly -> Lisp, PL/1, MBasic, Dbase, Postscript, Visual Basic, SQL, Delphi, JavaScript, F#.
Someday I’ll have a look at what all the fuss is with dynamic languages, but I am too busy lately. Will C# 4’s new dynamic features count?
If you have nothing better to do, below is a little insight into how / why I ended up using some of these and how / why I moved on to something else.
TRS-80 Basic – I was a young Honda motorcycle mechanic in 1978 when the owner of the motorcycle shop purchased a TRS-80 in an attempt to automate the parts department (all those parts and no computer – how did we do it?). I tinkered with it some, but the unreliable cassette tape storage was too frustrating and racing motocross was a lot more rewarding for a 19 year old with a competitive streak. Too bad for me.
6502 Assembly - I was a bored motorcycle service manager in the dead of winter in Lawrence, Kansas (Rock Chalk, Jayhawk!) in 1982 (too cold for motorcycles and not enough snow for snowmobiles). So I bought an Atari 800 to play video games and found that programming was more fun. My Atari 800 did not have enough RAM for Basic - sometimes it's better to be lucky than good (I’ve often thought that learning assembly before anything else taught me something useful). I actually got a Reversi game and disk copy program working and somehow convinced Byte magazine to publish a reference to them. I think I sold three copies…not very rewarding considering the fact that I was sure I had the fastest disk copy program ever created.
CBasic – I decided it might be nice to get paid more than 9 months out of the year (motorcycle service in Kansas does not pay too well in January) so I sold the Atari and bought a Xerox 820 CP/M computer which had a pair of huge 241K 8 inch floppy disk drives and an unbelievable 64K of RAM! It was the most expensive thing I had ever purchased at the time. I was fortunate to find consulting work for a local VAR customizing CBasic accounting software for local businesses. CBasic was far superior to MBasic (Microsoft Basic) for many reasons (did I mention it was much faster). Looking back, CBasic was the first language I used which was reasonably good for developing business software.
Z80 Assembly - the VAR got involved in marketing a portable computer called the Zorba (like the old Osborne portable). It had reliability issues and I got involved in fixing some of the issues which was a great learning experience. Wow, I could write some amazingly fast stuff in Z80 assembly. Did I mention that I used to race Motocross and I like “fast”?
Lotus 123 - I know, most programmers don't think of spreadsheets as a programming language, but you could make a case that "spreadsheets are the most popular functional programming languages in the world" (Google it and you'll see what I mean). Lotus 123 was the first really great piece of software I used. It was so much better than VisiCalc, SupreCalc and Microsoft's Multiplan which I had helped our customers with. Did I mention that Lotus 123 was faster - like night and day! I went to my boss and told him we should develop our own spreadsheet, because as good as 123 was, we could do it better (I think I probably meant “even faster”). He laughed and promptly dismissed the idea – but I never forgot it.
C – Through a series of fortunate events, two years later I was leading the development of the Smart Spreadsheet 2.0, and later SmartWare 3.0 (office productivity software for DOS / Unix which never made the transition to Windows). After going to COMDEX in 1986, I persuaded the powers that be to let me start building a new spreadsheet for Windows – which eventually became Wingz for Macintosh because Windows wasn’t quite ready for prime time. Wingz went from 0% to ~25% of the run rate for spreadsheets on the Mac in a short period of time thanks to the fact that it was years ahead of Excel in several areas (yes, it was faster, but it was a lot more than that). Unfortunately for me, Informix had purchased the company and decided to get out of productivity software when their core database business hit a rough patch, so all that hard work went down the tubes (biz lesson – own your own code if you possibly can).
Smart Project Processing and Hyperscript - SmartWare and Wingz actually had their own builtin languages - Smart Project Processing and Hyperscript. Both were English like (wordy). I had argued for making the language built into Wingz a derivitive of Pascal - but the powers that be were sure that nobody who used a spreadsheet would ever want a real programming language.
8080 / 8086 / x86 / 68000 Assembly – back in the day when it was the exception to have floating point hardware it was crucial to have your own floating point routines. Smart Software and Wingz also had a fair amount of assembly for frequently used string and memory routines. Sometimes I still wish I could implement a crucial C# method in assembly…but who wants .NET code that is unsafe these days?
Eiffel - I stumbled upon one of Bertrand Meyer’s early books on OO programming in Eiffel. I never did any real work in Eiffel but I believe reading this book taught me more about creating reliable and reusable software than anything else I’ve done in all my years of programming (that sounds like something an old person would say).
Objective C – I purchased a beautiful Next Cube for $15K of my own hard earned cash (my wonderful wife though I was nuts). I quit my job (guess what my wife thought about that?) and tinkered around for a while, did some performance work for a networking company and eventually started to write my own spreadsheet for NextStep in Objective C. The Next was built on the Mach kernel and was the first OS I used with real lightweight threads – the things I learned about multi-threading back then are definitely useful now! It had Display PostScript – which was actually the thing that first attracted me to it. The concept of the display and printer having the same graphics language seemed like a no brainer to me and I was sure Next was the next big thing. Most people know the descendant to NextStep as Macintosh OS X.
C++ - Unfortunately, Next didn’t make it and I needed to find a way to pay the bills, so I converted my Objective C / NextStep spreadsheet to C++ / Windows (via MPW Pascal but that’s another story) and teamed up with some guys who knew how to run a business and sell things. We released Formula One as a VBX (Visual Basic 4 Extension) and C library in 1993, followed by a C++ wrapper, an ActiveX (COM) version and even a Netscape Navigator plugin – which was the first internet spreadsheet AFAIK.
Java – Having led the development of commercial software which ran on multiple platforms, I completely bought into Java’s Write Once Run Anywhere mantra. I already thought the idea of a “real” spreadsheet running in the browser was a real solution to a real problem and Java Applets seemed to be the perfect way to implement this. Formula One for Java was the dominant spreadsheet component for Java for several years – basically until the pricing model was changed to “as much as we can get” which drastically reduced the ability to add customers. Formula One is now the engine behind Actuate’s e.Spreadsheet which is still a pretty good product as far as I can tell (albeit expensive).
C# - My official reason for leaving Actuate several months after they purchased Formula One was the fact that they would not let me build Formula One for .NET (biz lesson – don’t have business partners who will sell your code to someone else if you can possibly avoid it). They had and still have good reasons for this and I still like the people there – but I was tired of trying to build a real GUI application with Java / Swing. While Java was great at some things, it was definitely not so good for building GUI applications (remember, this was 2002, I don’t know how true that would be today). C# made some important improvements (Java still had no enumerated type after 7 years!). But the key was that, IMO, Java’s Write Once Run Everywhere mentality led to sub-standard Windows applications – and most business software developers who wanted a spreadsheet component wanted it to look and feel like proper Windows software.
Managed C++? – I sometimes think we might rewrite our core engine in Managed C++. Theoretically, we could then build safe .NET components as well as a native core engine from the same source code base. I have no doubt that a C++ core engine compiled to native code would be faster at any given point in time than the C# equivalent. But my concern is that adding features and improving algorithms would take much longer in C++ than in C#, and that eventually we would get to the point where we would have been better off sticking with C# for it’s increased programmer productivity.
F#? - As I consider the work we need to do to take better advantage of multi-core processors, it seems that it might make sense to convert portions of our code to F#. If we’re lucky, all of the features which make F# better for multi-threaded scalability will find their way into C#.