Ask HN: What interesting software did you work on in the past?
This comment https://news.ycombinator.com/item?id=12037548 by lisper about his time writing a patch for the software running on an instrument on the Galileo spacecraft makes me wonder how many other interesting stories HN members have.
So, What interesting software did you work on in the past?
I don't care if it is famous or if it made a billion $, just interesting.
18 comments
[ 5.1 ms ] story [ 54.4 ms ] thread~adsense clone, crawl page, find top keywords, and for each advertiser (which has a catalog of up to 5M products) find best product and display as ad in a widget.
~smart ~ai in a complex game of pong (powerups, multiple balls with different speeds, dynamic net size, special abilites). it was a very complex if-else-if tree, but I was in 7th grade learning by myself with no home internet-connection
- A hardware/software solution for thin-layer chromatography. This was the product that actually got the company started. Basically we built a chamber with a camera and UV lamp that people could put their TLC plates in and have the software take pictures with and without UV an analyze the results.
- A point-cloud visualization application for LIDAR data, used by geologists to scan large rock outcrops and study them. By far the most challenging of our projects, since LIDAR data consists of gigabytes of 3D point data and we had to figure out how to enable quick interactive manipulation of the data (rotating, zooming, etc.) without requiring hundreds of gigs of memory to hold it all at once.
- An image processing application for enhancing electron micrographs of ostracod fossils. It required only a few "hints" (in the form of clicks) from the user to know about important areas in the image, then cropped unimportant parts, enhanced contrast, and whatnot. It also had some tools for layering annotations on top of the enhanced image, taking measurements, plus a few other things.
By far the coolest job I've ever had. Sadly, the company failed. It was founded in a rather business-hostile country in South America, where taxes are absurd and one can't hope to start a company that isn't in an already established market where money can be made right away. I'm fairly positive it would have succeeded had it been in the US.
My most personal one was when we were first installing the system on-site at Fort Knox, in a massive building which housed about 90 4-person M1 tank simulators - all networked. 320 soldiers all participating simultaneously. (I also wrote the networking implementation for the simulators, and also helped integrate the custom image generators, which notably contained the first hardware-based texture mapping). The NPC system had Symbolics Lisp machine front-ends hooked up to a multiprocessor system running up to 256 separate CPUs on lightweight OS.
So we installed and booted up the system in the raised-floor machine room (remember them?), which took a long damned time. We were of course concerned about race conditions and memory leaks (the Butterfly was no less tricky to program than any other shared memory box with lots of CPUS). So we dropped down a company of Ivans (Russian tanks), and figured we'd let it run and go get fed (since we were tired and hungry - we might have been there all night - I cannot recall). When we came back into the building after lunch, lots of soldiers were running around, very pissed off, asking "who shot my tank?" and "will you please reset it?" So, I reset the tanks with the magic keyboard sequence, and retreated to the safety of the magnetic swipe-card-protected machine room to check on the Beast.
And lo and behold, there on the digital map display was the Russian tank company, surrounded by the digital corpses of many manned tank simulators.
The Beast was ALIVE. (I had, arguably mistakenly, initialized Ivan to be weapons-free when emplaced. I had also not known the soldiers would joyride through the vast terrain database during lunch break every day, shooting up everything around - none of which would have shot back before the Beast was delivered.)
It was a very Dr. Frankenstein moment.
It's impressive how far ahead of mainstream computing the system appeared to be in 1980s. Wonder if there's any technology gap of that magnitude anywhere now: things seem to have levelled out.
It's 15 years beyond 2001 - where is my HAL-9000? There are thousands of times more computing power in my kids' cell phones [insert obligatory reference to cat pictures here] than the computer I shared with 20 other geeks at MIT. The hardware guys have done their jobs - we software guys (for reasons that are probably worth discussing) have not.
My hobby stuff ("it's a hobby until you get paid") is done in Common Lisp wherever possible.
Being underwhelmed by software is quite common in the trade. Sometimes at the day job I contemplate why my embedded Linux system is able to run at 32 megs of memory and in 8Mb of flash footprint, while the "off the shelf" Linux server box to the side of it eats 600Mb RAM just to idle in one console. It almost feels as we are forced for the lack of depth in systems development to push into the width just to keep the machines busy.
Beasties was a pond-life simulation on the Mac, circa 1989. It was a Common Lisp program loosely based on a BASIC and assembly-language program I had written earlier that ran Conway's Life with 4 slightly-different sets of rules in the same world. Each ruleset had a different color for its live cells.
Panels was a simple experimental window system, in Lisp again. There's a theme here. Once I learned Common Lisp a lot of my own projects ended up being written in Lisp, and so did some of the things I did in my day jobs. Panels was built around constraints satisfaction and continuous event recording. I started with this vague desire to be able at any time to ask, "What was I doing at exactly X o'clock?" and have the UI system be able to give me an understandable answer. Another idiosyncratic feature it had was a rule that whenever the user started doing something, you should try to figure out something sensible to do with the input, regardless of what was on the screen--even if it was nothing. That idea went with the continuous event recording. The general idea was that if you really couldn't figure out anything reasonable to do, at least you would have a log of all the recent events, so that if the user's actions started to make some sort of sense you could maybe fit the logged events into it somehow.
Yeah, I know how bizarre this sounds now, but it did some kind of cool things. Like, for example, if you just started dragging the mouse around with nothing on the screen, it would go, "oh, mouse-dragging. Well, let's just capture that in a vector and plop a window around it. If nothing else maybe it'll be a drawing." Or, "oh, keystrokes. I know, let's shove them in a buffer and render them as text in a window."
The whole thing was sort of organized around that kind of ad hoc thinking.
GATE, the Generalized Automated Test Environment was a big honking Lisp program written originally by Matt Maclaurin, with later contributions by Chuck Lins and me. It was a big knowledge-based system written in a frame language called MacFrames (invented by Ruben Kleiman; MacFrames later evolved into SK8). MacFrames was of course written in Macintosh Common Lisp. GATE stored a bunch of descriptions of application software in terms of frames called "features". Each feature was something a user could activate in the application in order to cause some particular effect to happen. GATE would traverse the description of an application and use the feature descriptions to transmit synthesized events to a remote program called the Mole which ran as a system extension on a fleet of Macs of various models. Basically, the GATE machine would pretend to be a user who was exhaustively exercising every window, menu item, and dialog box in a whole raft of applications and spying on the remote Mac's screen, recording very time it saw something it didn't expect.
We used GATE to find and report legions of application compatibility bugs in Mac system releases. Later the event-recording code from panels came back to life in a utility called ShowMe that was supposed to make it easier to create the app descriptions in the knowledgebase.
I worked on Bauhaus. Matt Maclaurin was on that, too. It was the second OS written in Lisp for the Apple Newton. We wrote it after John Sculley ordered the Newton group to scrap the first Lisp OS and do a new one in C++. Larry Tesler told a small group of us to see if we could do anything useful or interesting with Lisp on Newton and we took him at his word. Actually, we probably took it too far. But we wrote an OS for a handheld mobile computer in Lisp in 1992. I regret nothing.
I worked on SK8, Apple ATG's "HyperCard on steroids", also written in Lisp. I didn't create it; that was Ruben Kleiman and Dave Vronay, and later Brian Roddy and Sidney Markowitz and Hernan Epelman and Adam Chipkin and Dave Yost and more folks I am not remembering. I came in late and worked on the object syste...
I happened to be in the QuickTime group just then, and my boss said, "Steve has said Let there be brushed metal. Make it happen."
So I scratched my head and remembered that I had had a NeXT machine for several years and there was some piece of NeXT UI that had a brushed metal looking thing in it. Surely Steve must approve of the NeXT brushed metal? So I rummaged around and captured an image of that thing (I don't remember what it was; something to do with WebObjects, maybe?) and looked at the image in Photoshop or Studio 8 or something. I copied out a likely looking chunk of that image of brushed metal and fiddled with it in the graphic editor, changing the size and tweaking individual pixels until I got it to tile without obvious visual repetition.
Then I wrote a little piece of code that blitted that pattern into arbitrary areas and checked it in to the MoviePlayer sources and then MoviePlayer windows had brushed metal. Tom Dowdy made it faster. That was his job. He was QuickTime's make-the-C-code-even-faster guy. He was the nicest guy in the universe, but I can be so unintentionally irritating sometimes that I once provoked him to yell at me. Sorry, Tom.
After that, all of Apple's stuff had brushed metal. I suspect that the Apple brushed metal that you see everywhere now may not be my code. I was working on MoviePlayer for MacOS 9, and the code for Mac OS X was mostly separate.
Wow sounds like the Genesis.
Some examples:
- Re-implemented Apples "Assistive Touch"
- Made an app launcher
- Screenshot cropper-keep on top (Hard to explain in a word but see: http://cydia.online/package/com.jontelang.snapper2)
Anyway I find this extremely interesting since I can shape iOS to my exact wants and needs.
- One of the original programming department heads of 0 A.D., one of the leading open-source RTS engines. I led the switch to a 3D engine.
- 2D library for the VESA Video BIOS Extensions (paged "hi-res" graphics), written in X86 assembly straight from the lengthy VBE spec.
- Haptic simulator software. Simulated the bending forces applied to a carbon nanotube attached to the tip of an Atomic Force Microscope. You could literally feel these forces using a special input device (http://www.geomagic.com/en/products/phantom-premium-6dof/ove...).
- Made a working physical eReader. Was similar to the Kindle but with a power-hungry LED display and USB drive support (team-based senior project). We asked eInk for a free sample, but they wanted us to buy one for hundreds of dollars.
- FPGA-based graphics accelerator (in VHDL) that rendered 2D and some 3D primitives (team-based for school).
- In 1996 a government agency wanted to compress their file transfers because X.25 was very slow and it connected hundreds of branches. The critical part was running the compression program in an IBM mainframe because they didn't have a budget for that (e.g. buying THE C compiler or specific hardware). We first tried implementing it with Rexx but finally ended up implementing a file compression program in Cobol! If I remember well the use of Cobol improved the use of resources vs Rexx.
Just for fun:
- With a friend, in the late 80s, we removed a keyboard from a Commodore 64C and added it to the Commodore Amiga 500, then implemented a program where two people were able to use the Amiga at the same time in different Windows.
- After the QNX Floppy Disk Demo [2] we ported Squeak from X to SVGAlib to run it from a 1.44 floppy disk [3].
- 8 years ago I implemented Cookiepie in Firefox [1] where the use can simultaneously-cookie-sandboxed accounts in different tabs. To my knowledge it was the first implementation of this concept and it was "impossible" to achieve in Firefox because there was no API to link a tab with an HTTP connection. I solved this issue trying to find indirect relationships navigating between the object graph.
[1] https://www.youtube.com/watch?v=1EBkB-Yp-zM and https://www.youtube.com/watch?v=2Pfg-kJ4nAw
[2] http://toastytech.com/guis/qnxdemo.html
[3] http://swain.webframe.org/squeak/floppy/