The joys of having a Forever Project
dev.gd
dev.gd
The Adams brothers, Dwarf Fortress: http://www.nytimes.com/2011/07/24/magazine/the-brilliance-of...
Elon Musk, Mars colony: http://www.wired.com/wiredscience/2012/11/elon-musk-mars-col...
Donald Knuth, The Art of Computer Programming: http://www-cs-faculty.stanford.edu/~uno/taocp.html
Hiroshi Ishii, Tangible Bits: http://web.media.mit.edu/~ishii/
(this is off the top of my head- I wish the list were longer, but it is late :) )
My experience in grad school has been this: we are discouraged from having "forever" projects, and encouraged to have "lots of little projects that you finish and forget about" dissertations.
Which is what led me to quit my PhD (only leaving grad school with a measly master's :) )- I felt that I was too young and inexperienced to embark on such a journey. I fully intend on going back to grad school in a couple years' time, and treat my PhD as such then.
Also, it is worth pointing out that there is no "complete TAOCP" yet. It remains a work-in-progress; I am looking forward to Volume 4B (though I have yet to actually finish any of the current volumes).
Back when I was a teenager, I wanted to write an art package for an obscure computer (Acorn Archimedes). I wrote the first version in BASIC, then decided to re-do it in assembler. The assembler I first used couldn't cope with the size of the project in the end, so I wrote my own assembler; at that point I discovered C, so wrote it in that. Unfortunately the C compiler I used was so full of bugs I decided to port LCC to produce ARM assembler, but then I needed a linker, so I wrote that as well. Got it all working lovely to the point where it could compile itself.
At university I figured Intel PCs were more useful than my obscure computer so... I forgot about it. Lost it.
And to this day, I can't help but wish I still had it... I had written, and lost, a complete C development system, faster than any of the other compilers/linkers I tried, small footprint (it had to fit in a machine with 4Mb RAM), and ARM chips are now everywhere. Damnit!
So please... save your work.
Sir, you have one very well-shaved yak there [1]. Excelsior!
In other news, I sometimes see people bemoaning losing the "easy programming" that the era putatively had. I sometimes wonder if time has simply faded the scars of a world in which that's the sort of thing that might realistically happen. The era made some moderately difficult things easy (people mostly seem to miss the ability to slam pixels on the screen), and everything else really, really freaking hard, including many things we'd call easy today.
Ever since school I wanted to write a simulation tool similar to one I've used in school, which basically lets you write differential equations in graphical form, and integrates them for you. And back when I was in school, I didn't know a thing about differential equations, and it all looked like amazing magic to me.
And while studying physics, I learned about DGLs and Runge-Kutta integration, and then I "just" needed to manage all the data (do a topological sort on the nodes to evaluate all the formulas in correct order), stuff it into the Runge-Kutta solver, and graph the output. Yay.
I never got around to writing the graphical front end, but the all interesting (to me) parts of the program are there. Oh, and it's written in Perl 6, the programming language I help to develop in my free time. If you're interested, check out http://perlgeek.de/blog-en/perl-6/physical-modelling.html
These days Perl 6 is my main "forever"-project, and it's coming along nicely.
A somewhat outdated and presentation of the idea (it's a bit buzz-wordy): https://patch-tag.com/r/worldsayshi/nodespace-staging/wiki/
It is very much a project of taking on more than I currently grasp. But I have already learned a lot by working on and thinking about it. :)
In a similar manner to you I wrote an internal DSL in Python that lets you specify your system, for example that pesky 2D 2nd order PDE
pde = PDE('dx_dt', V)
pde.eqn = mu_e * E * d(V, E) - \
(1-tau)*sigma_E*E*(sigma_gamma*A*rho_gamma_E + sigma_D*D*rho_E_D) * d(V, A*E) + \
(1 - tau) * (E - gamma*A - r_f*D) * d(V, A) + \
0.5 * (1-tau)**2 * ((sigma_gamma * A)**2 + \
(sigma_D*D)**2 - \
2*sigma_gamma*A*sigma_D*D*rho_gamma_D) * d(V, A**2) + \
0.5 * sigma_E**2 * E**2 * d(V, E**2) - \
(r_f + lambda_gamma + lambda_E) * V
and appropriate boundary conditions in Python. My pdegen tool then works on the resultant AST to generate the primary finite difference matrix. Given some initial conditions this matrix can then be used with any linear algebra library to time-step the system.You've given me motivation to clean up my code and release it :)
* for various definitions of the word released
In 1993 I started sketching some ideas for a novel loosely - very loosely! - inspired by it.
I kept poking at the ideas, and tried to write the book several times. I never got much traction, but did end up writing and publishing several non-fiction articles in national magazines in this time.
In 2011 I started. I wrote 160,000 words and created a fairly epic (in scope) science fiction novel that tied in moon colonization, desktop manufacturing, genetic uplift, AI, open source software, and more.
In 2012 I kept going. I wrote a second draft, and it reached 180,000 words, and was a MUCH better novel. In September 2012 I kept going and wrote the third draft, splitting it into two novels.
Right now I'm taking a one month hiatus before writing the fourth (and final?) draft.
I hope to publish it later this year.
So far I've sunk over 2,000 hours into this project, and it's one of the things that I'm proudest of in my life.
All of which is to say: yes, hang onto your crazy side projects; you'll be glad you did.
I'm not a novelist myself, more of a hobbyist but I've seen the results of good and bad editors in my little group. I've also run the mixer at my parent's church. The key to a good artistic performance is both you and the people supporting you. :)
The stars aligned this year, and I'm actually able to work on it now. This is the current temperature of my stove: http://dave-stuff.s3-website-us-east-1.amazonaws.com/
For me the goal is not cheap food but quality food.
And the most expensive part of going out for many people? Driving there, if you consider the cost of their time.
Ultimately, we will get robotic vehicles to do that part too. We will see some very small vehicles once robotic vehicles are commonplace, perhaps delivering only a single meal.
And we'll also see robotic cooks that can cook anything, so they may become so common you won't need to drive to them.
But how to tell?
I've been working on and off on my forever project for about 4 years now. It's cursed. I pulled the plug repeatedly for different reasons:
First time I started developing it, after a few months, a high-profile/highly-funded Open Source project with exactly the same features announced itself. I didn't want to spend time on something with so famous a competitor, it just didn't seem reasonable to duplicate/waste effort like that. If I'm honest, I was also kind of pissed that I was having such a hard time convincing people my thing was worthwhile, and then those guys come along and suddenly everyone acts like it's the most groundbreaking thing ever!
Second time, I started up again when the famous Open Source project kept drifting aimlessly somewhere between success and failure with no clear vision. I even enrolled in nReduce, mostly to keep me on schedule and make contact with like-minded developers. Then my mother got sick and died last year, that was the end of the project right then and there as I wasn't able to continue at that time. Maybe her death should have driven me even harder to develop this project, but the sad fact is that I just disintegrated unproductively.
Now I have to ask myself if I should ever continue this project. On the one hand it's not that ambitious, so it won't really take forever. On the other hand, there is mounting evidence that I won't be able to pull this off (considering the two attempts before). Wouldn't my time be better spent to start something completely new? Difficult to say because that one project is still on my mind.
> Why not fork the OS one? And sometimes 3rd time's a charm...
It's not about the technology. I think mine works better and they made some choices that I wouldn't want to inherit. I think their technology and protocol choices are part of what holds them back. I believe I can do it better, and for a time there I did.
Anyway, that's not the point. The point is finding out if I'm crazy to attempt this again or not. Sometimes you really can't tell whether you're Linux or Losethos.
I don't want to push this thread off-topic but I believe at some point Facebook, Google and others will have to open up their flood gates and allow information between them to be exchanged. I also think an open source project could nudge them in that general direction, especially when it gives people the option to just install it on their own servers like they would Wordpress or any other web app.
> I guess that will be whoever had the stamina and resources to keep iterating.
There must be literally thousands of those projects out there by now. Which brings me back to my original point: is it madness to try? Is a forever project that failed two times before even viable? At what point do you take a hint from the universe? How do you judge your own efforts, especially when nobody else cares about your work?
> There must be literally thousands of those projects out there by now. Which brings me back to my original point: is it madness to try?
Here's what I think: Don't blindly start Distributed Social Network Number 1,001. But pick 5 or 10 existing ones that look promising. Try them all. What's good about each one? What sucks?
Then, if one seems like a solid foundation, contribute and build on it. If they all seem too deeply flawed, learn from their innovations and mistakes and join others who are also learning. Explore other possibilities.
I was very excited about Tent.io, and wrote a small app for it, but after a few months began to see serious problems with its design. For now the Forever Project is on hold so I can build a music player. In a month or so I'll probably start thinking about what's next. My email's in my profile if either of you want to continue the conversation (or, if anyone reading has thoughts on this and wants to talk).
I'm kind of divided with myself on this one. I did compare some when I first started (there weren't very many of them around), and it was kind of obvious what decisions (mainly pertaining to the protocol itself) I didn't want to replicate. One of the reasons I started my own project was that I couldn't find something to be happy with. And I still can't, but admittedly I'm not looking that hard anymore.
The reason I'm reluctant to just go ahead and gather all the stuff I like from other projects is that contamination is a real problem. Especially in a space that, in my opinion, hasn't been solved yet.
> For now the Forever Project is on hold so I can build a music player.
Looking forward to your Show HN :)
I can show you my latest forever project distraction / music-player project, which I just blogged this morning and am feeling quite pleased with:
http://www.joebutton.co.uk/blog/baremetal-midi-lv2-raspberry...
It's probably not the same kind of music player as graue's though.
Can you be more specific? I've been thinking about using the Tent protocol as a foundation for my forever project, so I'd be interested in hearing what problems you've had with it.
> Profile Versioning - Profiles are versioned like posts. Previous versions can be fetched directly or if no version is specified the most recent version is returned.
What this means is if you have a real name or email on your profile, but then edit it out because you are getting stalked, surprise! The info is still there. Anyone who can see your current profile can also see every old version with everything you removed. Tent.io exposed their users by making it impossible to purge revealing info from your profile, unlike every other social networking service I can think of. When I raised concerns, the developers insisted that their users would be to blame for any consequences and basically said if you don't want something available in perpetuity, you shouldn't have put it online in the first place.
Imagine the howls if Facebook gave everyone access to the full versioned history of your profile with no way to turn it off. When we write social software, we are the professionals and we have a responsibility to give users sensible defaults and understandable tools to manage what they disclose. Violating expectations, then blaming the users for not understanding the protocol as well as we do, is unacceptable to me.
But the Tent developers don't see it that way. They're heavily inspired by an old vaporware project called Project Xanadu, which dates to the 1960s, when computers were owned by institutions, not people. Xanadu's rules of operation[2] notably make no allowance for private content. The utopian vision for Tent seems to involve this half-century-old concept, which has no relevance to the real problems people face in their social lives today, basically replacing much of the web. With OAuth2 authentication and notions of private posts haphazardly tacked on. It just doesn't seem realistic. It seems like the Tent.io folks are more interested in hewing to this ideal concept in their minds rather than looking around and solving problems people actually have.
Tent is a cool toy though. Some of the issues you might face playing with it:
There's a lack of robustness. Servers get out of sync (B believes it is following A, but A doesn't list B as a follower), and it's hard to get them back in sync. Message delivery is supposed to be retried if your server is down, but it doesn't seem to work. Discovery is slow, so app developers cache heavily, which defeats the point of discovery in the first place (moving the underlying Tent server, which should be seamless, causes problems). Authentication patterns are complex and ad-hoc depending on the relationship (or lack thereof) between two servers, something the developers plan to fix when they "add crypto" to a later version of the protocol. The server code is messy and sparsely commented. The spec is vague and omits error conditions.
I'm not sure what the next step is for me. I'd like to learn from what Tent does right (fully decentralized, app-agnostic, protocol first) as well as its mistakes. One idea I'm tossing around is building an Instagram-like social network with a Dropbox backend, as a proof of concept — see how far I can get with an unbundled storage service that's already mature.
[1]: https://tent.io/blog/tent-v02
[2]: https://en.wikipedia.org/wiki/Project_Xanadu#Original_17_rul...
Imagine if you publish a book and you've already sold 10,000 copies, when you realize there's something embarrassing in the book. You're not getting those 10K copies back, but you can at least stop printing more.
---
Even if you're building something that someone famous is building they may still lack commitment or vision to get it finished properly. Anyway, if you build it you will at least get it off your mind and get the feeling of accomplishment.
Since there's no way you can ever win, the pressure's off, and it's simply your fun little project... :]
I've long since accepted I'm not finishing this. I sort of don't want to. It's an old friend, I would miss if it went away.
The common-sense way of handling impossible projects is to break them down into doable sub-projects: components, layers, aspects etc. Then you can get satisfaction out of completing each of them. A psychological problem I have is accepting these as goals in themselves - if it doesn't do all of the project, it feels like it doesn't count.
However, this is silly of me, because it is still progress. A journey of a thousand miles consists of steps - not just the first one, all of them. And even for a commercial project, an inadequate beginning (that still does something) is beneficial: people love the sense of progress more than everything already done, your updates give you publicity, and give customers a reason to upgrade. Even with regard to competitors, it's good to have room to improve, because when they've copied you, you've moved ahead. If you're already perfect, once they copy you, you've nowhere to go. You're a sitting duck (wrt engineering competitive advantage).
Of course, this article has a more joyful attitude towards such projects. Maybe I should try it.
Personally mine has this terrible habit of consuming almost 100% of brain resources to the point where I literally can't do anything else productive. So often I have to say "no I'm not going to touch this for a month until I've got some real work done... then maybe I can take a look at it"
Still my forever project is coming to the point where I might be able to release it. Or rather, I'm running out of things to look at in it and think "that's not good enough I need to make it better", now it's mostly "that might not be good enough but I have no clue how it could be made better".
Which is rather pleasant :)
I am now creating my Forever Company - where I can work in a way compatible with living a life and still make a difference. Some people will join my journey some will leave as I change course. I cannot imagine finishing my Forever Company either. But I know the next steps.
Thank you OP - some good inspiration there
In a way the forever company is you, 'Me Inc' as it were. Hopefully forever building and growing.
My forever project is: the syntactically simplest high-level programming language. This had been kicking around in my brain for a long time, re-emerging every time I learned or read about a new programming language whose syntax seemed unnecessarily complex or conventional. As overwhelming as new language development is, I decided to set a goal for the end of 2012: a sufficiently complete proof-of-concept implementation, with documentation, to demonstrate the basic concepts. The result: http://om-language.org
Although the language itself isn't useful for anything yet, the side benefits of developing it have been many:
- Developing my C++, Doxygen, and Unicode knowledge/skills to a high-advanced level, which I have applied in my professional software career.
- Filling in lots of gaps in my knowledge of concatenative (and other) language theory.
- Discovering that using prefix notation in a concatenative language works better than postfix: no stack underflows, no data stack needed, and a program effectively becomes a partially-applied function awaiting more data (i.e. the rest of the program), elegantly allowing for data pipelining and events. As far as I know, using prefix notation in a concatenative language is a first.
- Discovering "panmorphic types": that when every piece of data can be expressed completely and equivalently in a uniform way (in this case, as a quoted program), data types become an implementation detail.
- Rethinking how to best define "number" with respect to a computation, which has led me to arbitrary-precision arithmetic implementations, Riemann spheres, APL, and down all kinds of other interesting rabbit holes -- resulting in some new number theory ideas which I am fleshing out for incorporation into the language.
- Learning all the glue technologies to actually release it (CMake, GitHub, etc.).
- Writing documentation that describes it to others. This has clarified my thinking on it more than anything.
Most importantly: I've invented a real language! It feels good.
Although I'll be adding to this project forever, none of these benefits would have happened if I didn't set some goals for getting it out of my brain and starting to flesh it out. I encourage anyone with a forever project to do the same.
I don't actually write my novel done or ever plan on doing so. I once tried during national novel writing month (nanowrimo), but that didn't work at all. Much better to keep it as a nice thing to think about as I'm falling asleep.
The day of 9/11, the right lead walked into my head and started talking. I wrote down what she had to say and did the first drawings of her.
I made a few attempts at starting the thing, but I never got very far. Multiple attempts at the beginning, random story fragments. They started to form a narrative but some stuff was missing.
In the meantime I drew some other comics and a Tarot deck. Last year, late one night, I was hit by a new idea for this story. I wrote it down, looked at it, and realized it really tied a lot of the themes together at the climax. The ending was right, after seventeen years of it bouncing around my head. Soon after I did a few experiments at getting the rough, painterly look it's always had in my head in my artistic weapon of choice, Adobe Illustrator, and nailed it. My sketches looked pretty much exactly what I couldn't actually produce all those years ago.
This November, I made significant progress on the first draft of a full script for the whole thing. I didn't finish it but I have a complete skeleton, with flesh on its bones for the first few chapters.
And I think I'll be starting to draw it when my current comic is over sometime near the end of this year.
Some things just need a lot of underpinnings. I always knew I'd do it SOMEDAY. I just had to let it boil way way on the back burner for a decade, until I worked through all the real-life issues it's a metaphor for. And I am pretty sure at this point that it will be worth the wait.
When the time is right, your Forever Project will become the current project. And it will be awesome.
I think the author is spot-on with the speed-of-light analogy, but missing an insight: you can declare a huge victory if you attain 90% (or 99%, or 50%) of your goal.
They are still early, I have been unable to dedicate on them as much as I would have liked. Because I have lived most of my life with limited means. I used to not own a computer, nor internet. While I worked to save my family from poverty, all I could afford to do, was to buy books, and learn programming, and work on my projects in theory.
It took a long time, but now I am relatively well off, and have a great full time work. I am advancing my projects, but it is too slow. I am considering to at some point, to take maybe a full year or two, to focus on my projects.
My two (still early) projects are:
Reproduce the human mind, and emotions, in a computer. Human like AI: http://www.ozkeebo.com/soul.project/ This is a problem that have fascinated me since child. I have meditated a lot on it, and have this hunch that I can pull it off. I am the kind of crazy and weird person, perfect for it. But I know that it is a hard problem. Maybe I will never be able to complete it, but at least I am sure that I will get great things out of it. Let's see how I will be doing in 10 or 20 years.
My other project, is a graphical programming language. This comes from my dissatisfaction in how we express programming languages. I feel like I want to shout to the world, that we are missing a huge opportunity here. I feel like we could be doing much better than what we have. But it is a lot of work, and it will also take me years of work, to prove if I really have a point. I will see.
Thanks for a great article, and a great hn thread anyway.
We can represent programs using texts. text is a good way to represent sequences of information. So it fit programs well, to some extent.
But text is limited. Programs contains many kinds of information, that don't fit well with a textual representation. Hierarchical data, scope, branching flow, loops, etc. After you realize this, you can also replace text commands, with symbolic representations that are easier to parse visually, and that can convey their function better than just text.
You need to maintain an appropriate level of information density. This one of the thing that has made text representation of programs successfully.
The other key thing is the UI. We are highly productive in manipulating text with editors. A successful graphical language has to beat that. It has to make possible to manipulate the information more efficiently: faster, and with less muscular effort. Allow me to call this the field of "unconventional UIs".
When I was a kid, I only had access to computer for a brief time. But I had plenty of access to console games. I used to love videogames. I spent huge deals of time detailed studying them, drawing concepts, etc. Examining why I found most of them to be bad, some average, and a few gems. A key thing was the UI. The mechanisms to manipulate the game environment.
Well, videogames are a rich field of unconventional UIs. And it is a field that I know very well. My experience with all these game UIs, makes me pretty sure. A better, more efficient UI can be designed, to manipulate programs information, on a graphical environment, than existing UI from text editors.
that's it in short.
Great inspiring read. Thanks!
http://statspotting.com/2013/01/that-one-idea-that-does-not-...
Edit: If you mean, you need money to live; you of course need some money, but not as much as most people think. Which makes it a question of priorities mostly. There are plenty of fantastic places where $600-700/mo will get you far, even without losing that much from your 'previous life'. You have to sacrifice things obviously, but not that much (depending on what you are used to).
http://deeptherapeutics.com
Determining how to apply that method to a common problem has taken a long time. Building a machine to do it is another set of challenges.I've heard many smart people recommend having a bunch of small problems to always think of. I think Richard Feynman recommended it.
Some examples of these kind of mental problems that I've been dealing with over the years:
* How long does it take from the time that the planets are aligned to the time that they are aligned once again. This was a problem I thought of in ninth grade and was the reason why I learn programming at that age on my spare time.
* How does one construct a P2P filesharing application that does not have a central single-point of failure. I thought about this for a year or so in high school. Obviously, I also wanted anonyminity for the users if possible.
* Dreaming about the perfect configuration management.
* Mining common log line patterns and automatically extracting useful information for debugging, surveillance etcetera. How I would scale such an application, what it could be used for etcetera. This actually resulted in https://github.com/JensRantil/disco-slct
* Last year or so; How to develop a web application that uses CQRS, event sourcing and a distributed model. This also involves thinking about how this would enable smooth upgrading of subsystems, scaling of such system and security.
I haven't enjoyed it in a long while, this article makes me wonder if I should start one of my idea and develop it with no clear saleable end in mind. The thought of which takes a lot of pressure off what I got done this week, this month, yesterday.
The older I grow, the more I know the way I work, my strengths and weaknesses.
I recently decided to create a behavior- / attribute-based framework for MonoGame, with functional reactive programming thrown in, and to my surprise, I currently make quick and steady progress.
He clearly articulates the emotional weight of these forever projects though.
But I like the idea of a Forever Project: just a thing that's been in your head since forever and that you can't stop thinking about. Mine have gone through many different permutations over the last 15 years, including attempts to start a company.
I intend to release it someday hopefully soon, but it will never truly be finished.
"Real artists ship."
But until I write the editor for it, there's really nothing to look at. Editor is coming Real Soon Now.
Some features:
- Optional GC with per-type granularity
- Trying to wedge uniqueness[1] into the type system too
- Can compile statically, extremely convenient C FFI
- Codifying the environment/context that a function wants/needs. E.g. a function "void render3DScene(void)" might spec its env requirements as {OpenGLContext, NonBlocking, SceneGraphState}. Similar to state monads, but intuitive, composable, and not anal.
I've been quite fascinated by ASTs (and verification thereof) ever since poking around Python's approach to it.
So the versioning is still vapor. Thing is, once you've done the structures correctly (i.e. copied git) the versioning just falls right out. The whole project really started off as a logical extrapolation of git's data structures.
I don't have a dev log at all, sorry. It would be good to get my insights down on paper.
Probably you already know about it, but have a look at papers aboht the tree edit/tree distance problem:
http://scholar.google.nl/scholar?q=tree+edit+problem&hl=...
It's exactly what you would need to store versioned trees such as AST's.
And big globs of functionality keep getting grafted on until the point where you're terrified to touch anything in case it all falls apart.
I don't like the term 'forever project' because it implies this will never be finished.
You sound more interested in processing the data than making the tool.
As for your first comment, I agree that the process is important, but finishing something can be important too, and the two [good process and good product] aren't necessarily mutually exclusive.
It’s a real time game (HTML5) where every player is a programmable entity. You define actions to trigger, and you can add an AI to the bot so it can act when you are not connected (persistent world).
Even the user interface is programmable, and I’d like to add an HTTP API to call actions on your entity!
I don't understand this idea of a Forever Project. A project/task is either important enough to do or it's a distraction in your life. Now if you're working towards that project because you don't have the resources, knowledge, people, at this point in time, you're making progress and that's a different story.
[+] http://arxiv.org/abs/1208.4990
Edit: Btw. you are right in saying that these things are a "distraction in life", but I think it's a good distraction, like a hobby.
Physics for you is an interest and a hobby. Those are great to keep you informed.
I feel sorry for you if you don't have space in your life to enjoy some unimportant things just for the sake of it.
Since I do not have to reach a target I can try solving old problems in new ways and see how it works out in the long run.
My forever project spawned some nice sub modules which I use in productiv code.
In some branches of my forever project I tryed things generally known to be bad style to see some of the problems myself.
If I take myself as an example: I have this git repository checked out as 'coding' on all my machines, which has about 15 different folders containing projects ranging from simple prototyping experiments to fully-finished projects. Only a single folder contains a project that was ever released publicly (an iOS port of a classic MS-DOS game). Everything else is half-way finished at best.
Does that mean writing all that unfinished code was merely 'a distraction'? I don't think so. All of this started out as just a way to learn about something I knew nothing about before, and most of the time I stopped working on things the moment I was satisfied with what I learned. There's an arithmetic coder in there, a marching squares implementation, an MPEG-2 decoder that fully works but is dog-slow and doesn't process the color channels, a framework for 2D pattern recognition, a component-based Python web framework, a web application that was intended as a tracker for poker scores, and some other things I can't remember.
If I had set out to complete all of these projects, I would probably have finished 1 or 2 and still know nothing about the theory that got me interested in the other 13 or so.
(brain crack is a term I think was coined by ze frank - at least that is where I saw it first)
(Great book! http://en.wikipedia.org/wiki/The_Forever_War )
Real-time streaming photos shared on Twitter.
I think modern machines and languages are far too advanced for the little little kids. So, I went the old school line-numbered, BASIC language clone route. I felt that that was the simplest (albeit crudest) approach to getting code into the computer that I've ever experienced.
Obviously, I want kids to learn to hack, so does everybody. But more than that, my angle is that I want the kids to become expert quickly and bump up against the constrained ceiling my language imposes, maybe after a year or two of tinkering. Then, I want to always dangle something more low level in the system like assembler/byte codes that they can graduate to and use to code more efficient/complex works with.
For the hardcore kid hackers, I figure by the time they master my assembler and get some chops, they'll be in high school and be eager to move on to more professional computer languages and Linux.
My computing history goes something like this: I got my start with Commodore 8-bit computers, hooked right away on type-in BASIC game listings in Compute's Gazette. (I'm still in possession of boxes of issues.) I was multiplexing sprites with 6510 assembly before I turned 10. I got my first C compiler, the lovely Microsoft QuickC 2.0, in 8th grade. Hacked on my dad's Tandy PC clone like a fiend all through high school. I skipped a year of computer science in college due to my superb AP Pascal test scores, allowing me to graduate in 4 years instead of 5! Did the artistic thing and joined NovaLogic straight out of college, hacking mostly Intel 32-bit Assembly ... to code their game installers, no less?! (Macho bunch, those dudes.) Moved on to a systems integrator in SF and have been developing intranet apps with them for over a decade, making a great living.
Family, house, cars, career -- I trace it back to BASIC and a mom with the means and foresight to invest some mad money in her little kid's hobby.
I don't think my story is all that unique for my generation, we 30-somethings have a quirky computing history. I do worry about the next generations, however. Maybe it's just the protective dad in me, but I see less and less hardcore geeks coming up the ranks; what I am seeing are people who lack context, cannot focus, and have little love for the craft. It's scary.
I feel ClubCompy is a calling: that in order to keep this whole software ball we have rolling, we need to make more hardcore coders. And don't start teaching them in high school, start in grade school.
I would be so honored to give kids a start to their life with computers. We could raise a generation of coders who are far better than the current crop, and give them their own quirky history to claim as well. That's my dream, at least.