The computers in Jurassic Park is what got me into programming when I was young. I saw their 3D weather overlay when the storm was approaching and thought "THAT IS IT!". I was 8 years old at the time.
I was determined to learn and create that system - I started learning C, so that I could open and close files. I learnt OpenGL so that I could create the 3D scene. I learnt socket programming so that I could download weather images from the NOAA.
It took me until I was 15 (I was totally self taught and it took me a while before I could learn all of the vector / matrix math myself) but I ended up building it! I made a program in C that downloaded the weather jpg, cleaned it up (removed noise, removed the NOAA logo, smoothed out the clouds) then generated a heightmap in OpenGL, and made a fly-over.
I wish I still had the code, it's sitting on my old computer at the Farm in New Zealand :<
No, _your story_ is cool. Its amazing how dogged a kid with a vision can be. This sort of attitude and environment needs to be passed on to future programmers, and preserved in the current ones. Kudos.
> The computers in Jurassic Park is what got me into programming when I was young. I saw their 3D weather overlay when the storm was approaching and thought "THAT IS IT!". I was 8 years old at the time.
I'm guessing you would be around 28-30 years old, so I'm a couple of years or more older ... but I started learning C when I was 31, currently I'm interested in stuff like parsers and data structures (I really should look at sockets soon). Perhaps I'm just too old to hack.
> I wish I still had the code, it's sitting on my old computer at the Farm in New Zealand :<
I bet a fair few people on HN would be interested in it as well, it sounds quite hardcore.
Warning: anecdotes and unsubstantiated speculation ahead
Did you do any programming at all before 31?
I don't think you're ever too old to do anything, personally. I was 26 (which isn't terribly old, admittedly, but definitely past the little kid age) when I talked to a friend who was a professional programmer and decided "huh, I like computers and solving problems. I'm going to do that." I hadn't programmed before then, though I was computer savvy, I guess. I also have a degree in sociology, heh.
Took me about four years, but now I have a corporate job doing full stack .net work in C#/MVC, I've done side projects in ruby, and I do some C, Haskell, and python on the side. I'm also working my way through The Algorithm Design manual and have Concrete Mathematics to work through later on.
I always got really discouraged because I constantly see and hear about people who started programming when they were five, or eight, or something like that, and I'd think "no way could I get into it that deeply, starting so late" but that's just totally untrue. I'm finally at a point where I think "given the desire and time, I can learn whatever comp sci topic I want," so I get discouraged less.
I think part of it has to do with notions of talent, and natural abilities. When I was a kid, I took for granted that something would be hard until I learned it. I don't remember learning most of the basic skills I have, so I forget that things can be difficult starting out. Every topic I've started learning and stuck with in programming has pretty fully integrated itself into the core of how I think about the topic. One for-example would be immutable data structures as they're implemented in Clojure, or functional programming in general.
Anyway, that's a rambling tl:dr for: stick with it. You're never too old. You just have to try that much harder to catch up initially, but if you can teach yourself to keep learning now, you've got an extra skill a lot of people don't have, which is learning how to learn as an adult. I think it's the most valuable skill I have right now.
(ps I'm making a lot of assumptions in this post; sorry if any of them are way off base)
This is exactly my situation as well. I was always into computers when I was young but didn't really have access to any until high school. I always envied people that started learning how to code when they were kids, I still do. Like you, I always thought my chance to code had come and gone because I'd only ever heard of people that started when they were young. Like you, I always felt discouraged.
A couple years ago I figured I would try anyways, so I started looking up good books to read through and do the exercises. Started with Python and I've read books on and written assembly and C. Now I'm an independent contractor doing webmaster/web developer.
Any books you'd recommend other than The Algorithm Design/Concrete Mathematics? Those look interesting and I'll probably go through them.
Code Complete 2 [1] was one of the first coding books I've read. As with anything else, it's good to look around (HN is a good place) for people who have problems with the book. I think I learn as much reading the commentary people make about books like that as I do from the book itself.
I think I've listened to every podcast on software engineering radio a few times [2]. The older ones are especially nice because they usually pick a specific topic and cover the high points. I liked that I could listen to it while I was driving, or otherwise not in front of a computer.
It's specific, but Javascript: The Good Parts is probably the most used book I have on my shelf. It has such a perfect amount of usable information in it. It's pretty great. Again, it's definitely worth looking up critiques and counterpoints.
I've also got Introduction to Algorithms, which I use as a reference, sometimes. I switched over to The Algorithm Design Manual [5] after I saw it referenced in an older Steve Yegge post [6]. I read through the intro and it seemed like a book that would be more appropriate from an autodidactic standpoint. I really have no idea if that's going to pan out, since I'm not that far into it, but we'll see, for sure. Doesn't kill me to have an extra algorithms book laying about, though, and I've always got intro to algorithms for cross reference. I've found that I really need to have as many sources available as possible when I'm learning alone. Usually I don't get something until the fifth person describes it from the tenth different angle.
That's most of what I can think of off hand. I really enjoyed The Joy of Clojure [7], though haven't checked out the newer version. Programming Collective Intelligence [8] is a fun book, and is what made me want to go back down the maths route to get more into machine learning.
And of course habitually reading hacker news for an hour or three every night :)
So that's my totally inexpert list of random stuff that I enjoy
Hey, no problem. I'm going through my comments, and just now saw you replied almost a month ago.
I just wanted to say, get in there and start doing it. I honestly think that, to a point, I'm at an advantage. I've had so much work experience outside of coding, that my context for interacting with people seems to work in my favor. I'm also just super glad to have a programming job. Mix a (hopefully) more level head, with an exuberance for the job, and I think I put across a pretty good image.
If I can throw some suggestions out there, listen to every episode of software engineering radio. The other books I mentioned are great, but SE radio is nice in that you can just casually listen to it while you're commuting or whatever else. I listened to it when I had barely done any coding and I think it lent a lot of perspective to what I was doing. I still run into random situations where someone says something like "do you know anything about AS400?" and I'll say, "well, not really, but I have a general context as far as the ibm i series os goes, and some of the general ideas behind it. I could probably pick up material and get going." It's not much, but being familiar enough with a ton of random stuff has given me credibility in a lot of situations I wouldn't have had before.
I also relisten to them a lot, and get new tidbits because I didn't understand bits and pieces before.
I hope this doesn't sound preachy. I think our culture pushes this idea of the talented hacker, or the person that started x or y when they were five. That's great, but man, screw that. I don't plan on stopping learning until my brain doesn't work, and I'm going to use that to my advantage.
I'm 31. When I was 9, I wanted to copy Ultima, my dad had a copy of Visual Basic so I learned how to use that and made an RPG engine. When I was 11 or 12 I started getting frustrated with the performance of VB/QBasic (this is before we had Internet access, so reference material was sparse) but I had a copy of the programmer's guide to the IBM PC and PS/2 and managed to figure out how to use assembler to draw in mode 13h in BASIC. As I got on to be about 14-15, I started to try to use higher resolution modes and had real challenges with drivers, and moved on to using Pascal and C. I bought a Borland C++ package, it was hundreds of dollars.
My point to all of that is that, in the end, those experiences meant very little to me now. They were indicative of the kind of person I am, and they are pretty cool to look back on and brag about, but in the end, they don't really make me better at any specific programming task. If I were to have not had the same resources to try to do those things, I would probably not be significantly better or worse. I would have spent my time trying to take apart electronics or learning a language or something instead, developed my problem solving skills and semantic skills in other areas. Maybe a little bit less experience, but in the end I think I would not be significantly impacted.
The reason that people might fear that starting late holds them back is because they might not be the kind of person who, even with access to the tools and resources, would be interested in taking things apart and finding out how they worked to start with.
If you can say at this point that you're interested in stuff like parsers and data structures, then that's awesome. If you're interested in it and you want to learn more, you will learn more, and you will succeed. If on the other hand you are uninterested but think that programming is a smart career path, you'll probably do poorly.
I was lucky enough to have the pleasure of working with a few of the smart folks who were responsible for those weather visualizations.
They were created by a little known startup in Minneapolis, Minnesota called EarthWatch Communications. At the time they were creating 3D displays of weather data long before such visualizations were commonplace on every TV weather forecast.
me too, I want it back now! ... I was just remembering what a PITA it was programming when I was younger - no internet at home meant I had to read the code of similar programs to try and figure out how to do things.
Every day I'd come home with a box of floppy disks full of open source programs to read, and satellite jpgs downloaded from the noaa website.
later on I got internet access and that's when I hooked it up live ... good old NZ Farm internet : 0.5kb/s because our electric fences caused so much electrical interference with the phone lines ....
that's an awesome story. Currently compiling a blog post series of interviews with people who have interesting stories about how they learned to code, would be great to interview you! If you're interested my emails ben at talkingquickly co uk
The cool thing about Jurassic Park is that it showcases all this high-end tech (at the time) to set the mood. The setting of this movie made a huge impact on me as a kid.
In the computer room scene you can see a CM-5 [1] from Thinking Machines in the background (or at least, only the front panels with the futuristic blinking red leds). Those were very interesting computers when launched, with a fundamentally different architecture for parallel computing.
Also, fun story: the company hired Richard Feynman [2].
I used that at my first programming internship at university. Even then (1999) it was a dated OS, but it was still fun it.
I wonder if they used IRIX in the movie because the VFX guys making the movie, ILM, were doing all the VFX work using Softimage on SGI machines running IRIX at the time.
Apparently the specific "It's a Unix system" scene used an experimental fsn (file system navigator) that SGI developed but which was never released as a product.
It was released on one of the Indie demo disks that SGI liked to hand out at conferences and subscribers and so on .. the source is still around, and of course there are a few clones by now: http://fsv.sourceforge.net/
It was released. The university I went to had a computer lab full of SGI Indy's that they'd gotten really cheap from the distributor, and they all had the 3d navigator installed.
It was also extremely repairable compared to modern computers. Everything was modular and upgradeable, including the CPU board, which just slid out of the machine on a lovely tray.
When I was working at UniPress in New Jersey, we had an SGI Iris. Those things are fucking heavy! It was raining outside and the office started to flood, so we had to keep taking shelves down off the wall and wedging them underneath the Iris to jack it up above the water, as it kept getting deeper and deeper.
The Indigos were another story entirely: They couldn't touch the raw graphics performance of an Iris, since the rendering was all in software, but you could actually stuff one of them in the overhead compartment on an airplane!
And then there was the SGI Indy... They made up for being small on the outside, by being HUGE and BLOATED in the inside:
"Indy: an Indigo without the 'go'".
-- Mark Hughes (?)
This legendary leaked memo has become required reading for operating system design courses:
Last May, I published my first report on software usability, which Rocky Rhodes and I presented to at Tom Jermoluk's staff meeting (with Ed, but without Tom). Subsequently, I made it available to quite a few other people.
This sequel is to satisfy all those people who have urged me to bring it up to date. I begin with a summary; details follow.
Please read at least the summary.
SUMMARY
Release 5.1 is a disappointment. Performance for common operations has dropped 40% from 4.0.5, we shipped with 500 priority 1 and 2 bugs, and a base Indy is much more sluggish than a Macintosh. Disk space requirements have increased dramatically.
The primary cause is that we attempted far too much in too little time. Management would not cut features early, so we were forced to make massive cuts in the final weeks of the release.
What shall we do now? Let's not look for scapegoats, but learn from our mistakes and do better next time.
A December release of 5.1.2 is too early to fix much -- we'll spend much more time on the release process than fixing things. Allow enough time for a solid release so we don't get: 5.1.2.1, 5.1.2.2, 5.1.2.3, ...
Let's decide ahead of time exactly what features are in 5.1.2. If we pick a reasonable set we'll avoid emergency feature cuts at the end.
Nobody knows what's wrong -- opinions are as common as senior engineers. The software environment is so convoluted that at times it seems to rival the US economy for complexity and unpredictability. I propose massive code walk-throughs and design reviews to analyze the software. We'll be forced to look closely at the code, and fresh reviewers can provide fresh insights.
For the long term, let's change the way we do things so that the contents and scheduling of releases are better planned and executed. Make sure marketing and engineering expectations are in agreement.
INTRODUCTION
We've addressed some of the problems presented in the original May report, but not enough. Most of the report's warnings and predictions have come true in 5.1. If we keep doing the exact same thing, we'll keep getting the exact same results.
I'm preparing this report in ASCII to make it widely available. It's easy to distribute via news and mail, and everyone can read it.
An ASCII version of the May 12 report can be found in:
bedlam.asd:/usr/tmp/report.text
The included quotations are not verbatim. Although the wordings are inexact, I believe they capture the spirit of the originals.
BLOAT UPDATE
"Do you want to be a bloat detective? It's easy; just pick any executable. There! You found some!"
-- Rolf van Widenfelt
The Jurassic Park Computer System...created and maintained by Newman. Credit where credit is due: it takes a lot of skills to keep a bunch of velociraptors pent up using a Macintosh LC II.
What always amused me is that in order to trigger the locks, the "computer whiz" girl had to navigate some sort of 3d control environment, probably the most ineffective way possible to control something that should be random access.
I thought it was so cheesy that it had to be fictional, because of all the misrepresentations of computer interfaces in other movies like "Hackers." This is apparently a common assumption.
It's admirable that SGI was experimenting with interfaces. However in this situation having to navigate such an interface created a very real safety hazard. I suppose she could have used the regular file browser instead - or perhaps the substantially less exciting XTerm.
Sometimes life imitates art -- I spent a good amount of time in high school making my Linux system's bootup and login screens look like those on Hackers.
I suspect in SGI's case it was probably mostly another demo to show off their graphics capabilities. Nobody used it, but everyone I know who tried out the SGI boxes at uni had their five minutes of fun with it.
Things like that and running xearth as the background when logging in on the Indy's made them stand out massively next to the Sun boxes with monochrome terminals in our computer labs, which seemed ancient and outdated.
Heck, even booting them, with their nice blue gradient background and metallic frame around the window where the boot messages scrolled by set them apart from the boring Sun boxes. SGI early on had a lot of the design sense and flair that Apple has today.
Haha! My mom was a Sun reseller who sold them a bunch of Sparc stations for the movies and I think even wrote some shell scripts to launch some spinning 3D dino-skull scripts on startup, etc. Around this time we were a pretty rare family home with one of those boxes and an ISDN line at home as the family computer.
This brings me so much joy. This movie - the SGI and this scene in particular made me want to switch from being a business major to a computer science major in college. I did and it was the right decision.
I bought an SGI Indy and spent a lot of time in the shell just so it would look and feel like the scene from this movie. I don't know why it affected me so much but it did.
So much love for the author who create this simulator.
Apple already had a unix-based Mac OS for five years by the time Jurassic Park came out, A/UX. My first computer job was at a nascent ISP around this time and most of the servers (mail, www, accounting) were Quadras running A/UX. One IIfx with several massive (for the time) hard drives for Usenet. It was basically the System 7 (Mac) UI bolted on top of System V unix.
"Everybody" had Unix systems back in the day. People forget that there was a time when it was seen as critical to have a Unix offering to be taken seriously in certain markets.
On the "low end", besides Apple's A/UX, Microsoft had Xenix and Commodore had Amiga Unix.
also MachTen, Tenon's UNIX on MacOS. it ran as a process on top of MacOS, not in place of (as A/UX did). i never got my hands on A/UX but ran MachTen for a while in grad school (i was too poor to own an SGI). this was before LinuxPPC and MkLinux/PPC were around, and before UN*X ports to mac68ks were working.
Seems it shows up each time the site tries to play short audio clips. See starting line 32 in http://www.jurassicsystems.com/js/jurassicSystems.js Instead of feature detection it'll use HTML5 audio in Chrome, show an annoying dialog in Safari, and an SWF fallback for anything else.
Ugh. In that case, they're missing the point of Modernizr. If there's no polyfill or fallback available, the solution isn't to say "Don't use Safari". At the very least, they could display as useful message that says something like "Your browser doesn't appear to support feature X, try browser Y instead."
When I see "Don't use Safari", I interpret that as "I'm too lazy to make this work in Safari", rather than "this doesn't work in Safari".
I used fsn on the SGIs in 1994/5, but I think this initially free (as in beer) program was later bundled with some for-pay package and vanished from the downloads area.
The funny part is I probably still have a working copy of it on the SGI Onyx in my garage.
I used to work with some Silicon Graphics in the 90's in a F-18 Simulator for Spanish DoD. We used C with GL (the graphic library that existed before OpenGL) and had Indigo² workstations for each developer. Origin and Onyx were used for calculation and visualization. When they offered me that job I couldn't refuse! I was like "Yes! I'm going to use the same computers that appeared in Jurassic Park!!!" :D
We have a SGI machine (wights like ton) in our shop. Can't remember the exact model but I remember how someone mentioned it's the exact model used for animation in the movie....we use it mostly as a chair XD
The computers in Jurassic Park is what got me into programming when I was young. I saw their 3D weather overlay when the storm was approaching and thought "THAT IS IT!". I was 8 years old at the time.
I was determined to learn and create that system - I started learning C, so that I could open and close files. I learnt OpenGL so that I could create the 3D scene. I learnt socket programming so that I could download weather images from the NOAA.
It took me until I was 15 (I was totally self taught and it took me a while before I could learn all of the vector / matrix math myself) but I ended up building it! I made a program in C that downloaded the weather jpg, cleaned it up (removed noise, removed the NOAA logo, smoothed out the clouds) then generated a heightmap in OpenGL, and made a fly-over.
I wish I still had the code, it's sitting on my old computer at the Farm in New Zealand :<