One of the side projects I have to embark on is writing a companion to TAOCP that shows how to implement the algorithms in a functional language, probably Scheme or some subset of Common Lisp. The main complaint I have about TAOCP is Knuth's insistence on using assembly language to illustrate the algorithms -- otherwise, they give what is probably the most in-depth description of the motivation and analysis of algorithms I have seen (much more detailed than CLRS, though CLRS is more complete).
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).
This is exactly what I thought: Pretty much every great inventor or researcher has that one big problem, or one big question that drives them ... but I think it is a good point to say that one should not be too disappointed about not necessarily making rapid progress on "the forever project" all the time. Thanks for making me feel a bit better about seemingly (and for the duration of typing this actually) procrastinating from tackling the underlying challenges behind my PhD topic ;) ...
This is unfortunate; it would be nice if dissertations were the beginning of a "forever" project, or perhaps the continuation of one. Sadly, most of the dissertations I have seen have been a bunch of quick projects stapled together with one overarching theme, with a minority being answers to big questions (like Craig Gentry's thesis on FHE). I can think of only one, in fact, that was the beginning of someone's "forever" project, and that is Darse Billing's dissertation on computer poker players (he seems to be spending year after year working on poker AI).
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.
I very much see dissertations as the beginning of forever projects; but maybe that's because my advisor's dissertation was†, and his own advisor (Ishii, cf my first post) saw it that way as well.
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.
I'd add one more thing to this article: don't throw these projects away, even if they seem failed/doomed/incomplete. Store them somewhere. Back them up. Whatever. You might need them.
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!
"... art package for an obscure computer -> wrote my own assembler... port LCC... linker..."
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.
Can you imagine how weird I felt when I finished my "forever" project?
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.
Nice! I've always been fascinated by tools and techniques that reduce the burden of solving complicated PDEs. After deriving, by hand, the finite difference matrix for a two-dimensional 2nd order PDE with varied boundary conditions I thought "there has to be a better way!"
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
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 :)
Modeling dynamic systems is kind of where I'm moving towards with my project at the moment. It's a visual programming language where you create "non-casual" models instead of functions. My current lead is to use a modelica-like library, Hydra, as the back-end.
Around 1980 I read Heinlein's "The Moon is a Harsh Mistress".
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 should add: I've become so interested in the world and characters and situations I've created (and so have a half dozen or so alpha readers) that I'm planning on writing another two novels as follow-ups.
Awesome! Some advice from a writing group I've attended: Find a good editor that has the time to do a good job. Think of it like this, you can have the greatest band in existence and it can sound like crap with a bad person on the mixer.
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. :)
My forever project is a cooking robot. I've been thinking about how I'd approach it for years, but never had the chance to make what I thought would be a worthwhile start.
That is awesome. That's the ultimate DRY (don't repeat yourself) thing humanity needs. It will free us from all the work required to raise the quality of our food, making eating well as easy as fast food.
My personal touchstone for the beginning of the true Robot Age is a fully-automated McDonald's or equivalent being seriously deployed not as a tech demo, but because it is the best solution. Supplies in one end, someone carting the waste out the other, and everything else, including cleaning, should be done by the robot itself. (Though perhaps I'll bend on the cleaning. That does add another very significant level of complexity.)
Robots will be cheaper eventually. And very easily reprogrammed.
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.
I would love to have a cooking robot because I don't like to spend time cooking. I worked on a related project, an automatic bartender: http://youtu.be/iqvUJ6vvzxk as a group project in one of my classes.
Thanks! The blog is on the todo list.. I'm preparing some presentations for next month so that might be the kickoff. For now I've just put up a FB page for a first device: https://www.facebook.com/vaporware.robot
Maybe some forever projects are just huge time sinks with a plainly delusional background.
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.
It's an useless effort to build a new free operating system kernel now that GNU Hurd is just around the corner. What chance you have to compete with those MIT hackers? Besides, monolithic kernels are so 80s.
---
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.
I'm going to guess that your forever project is a distributed social network. I think a lot of people (me included) are in a similar position. The challenges are really big, and most of us (me included) get disheartened at some point. I think at some point Facebook will drop the ball and something else will get to pick up the pieces. I guess that will be whoever had the stamina and resources to keep iterating.
> I think at some point Facebook will drop the ball and something else will get to pick up the pieces.
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 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.
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.
Sure. There are many technical flaws, but to me, the worst part is how Tent is very opinionated about removing content. The developers deliberately made it difficult. In version 0.2, their changelog[1] casually mentioned a new feature:
> 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.
Being able to remove content is one of the few real advantages centralized social networks have over decentralized ones. Since it would be very hard (actually impossible) for the tent protocol ensure information is deleted once it's left a server, I kind of like their approach of embracing the issue and not trying to paper it over.
I don't. If the hosted service (Tent.is) and reference implementation (tentd) only saved the latest version of a followee's profile, and the spec made it clear this was supposed to happen, we'd have a sensible default that would be respected in most cases. Also, your old profile being available directly from you is much worse than it being available from a follower: it's much easier to find and it proves the content is authentic.
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.
> But pick 5 or 10 existing ones that look promising. Try them all. What's good about each one? What sucks?
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.
Love this idea. This must be what drives all the people writing toy scripting languages, like _why's Potion[1] or TJ Holowaychuk's Luna[2]. Or the zillions of tiny Scheme implementations out there.
jdrake, you're hellbanned, so I can't answer you directly.
> 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'm 42. I've had such a project since 14 or so, more than a 1/4 century. There has been long stretches of inactivity, exp lately. But, I've used it to learn many languages, GUI frameworks, OOP, the non-existence of silver bullets (aka OOP ain't all that), and many other topics/skills. Originally started in K&R C, then Turbo Pascal, Perl, C++ (it was new and exciting when I was in college), back to Perl, finally and for the long time now Python (with which I made more progress in shorter time than all other efforts/languages combined). Lately (last couple years) been toying with writing parts in Erlang.
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.
funfact: in the expression "reach exceeds grasp", your reach is what your fingertips can brush, your grasp is what they can wrap around.
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.
In the best case you can break it down in reusable parts. I took some of the commandline tools I created for my forever project, and turned them into a stand alone application.
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".
Forever Projects are like stars, we set our course by them but never reach them.
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.
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.
My forever project is a novel. It's a great way to fall asleep. It's a project fun enough to focus on and ignore everything else, but completely stress-free so it's very relaxing.
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.
Mine is too. I'm actually on my second one. I started back in the late 1980's and spent some fifteen years planning and plotting the first one before I put that outline in a drawer and began planning and plotting the second one. I'm hopeful that someday all that writing around will morph into a real novel that other people want to read but even if not the process has forever changed me.
I'm an artist. Back in 1995 I started coming up with this dark urban fantasy, somewhat inspired by my unexpected homesickness when leaving New Orleans for Los Angeles. I ended up with an interesting setting and some flat characters.
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.
Interesting perspective on long-term projects. I too am working on a service I consider my forever project, but one which may actually be launchable quite soon. I can definitely relate to the dreamy state the author refers to, as I too dream of a constant barrage of features I want to build into the service. This can quickly get out of control though and become endless as a developer delves deeper, but maybe that's why it's a forever project. You want this service to exist so bad for yourself, it doesn't matter if you're the only user. It's sort of like a nagging child. It's a part of you, no matter how many diapers you got to change.
I think that part of what the author is trying to convey about such projects, rather than they being de facto 'forever projects' is that such projects are worth it by the journey alone. Even if you don't ever reach the end of it - the inspiration and learnings it gives you is enough to motivate continue working on it.
When I started thinking about my forever project, http://automicrofarm.com, it certainly seemed almost impossible. But as I started implementing a subset of it, it got less and less impossible, and now is even feasible enough that we've got a product (vs. a proof-of-concept) prototype (of the subset, not the grand vision).
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.
This is a great article. It is great to know that there are other people like this.
I always have had these projects that I can't forget off.
There have been various, but after I matured, I ended up focusing in two.
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.
So what are your hunches that lead you to believe that a graphical programming language is the way to go? Not saying that it couldn't, but it hasn't really been a success so far.
I am 100% sure, that at least for me, I can imagine and design a graphics language, superior to text representation of programs. And I expect that for most people, once they surpass the learning curve, will also be better. And even more sure about it working for people new to programming.
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.
Here's mine: http://www.pubsoccermanager.com/ It has gotten really slow in the last year, but I am planning to do something around it full time. Most obviously it would be a game, but I also have a couple of other ideas of how to monetize.
Haha this is so true. I used my forever project (indeed, a obscure fantasy football game =) ) over the past year as a narrative to pick up the basics of programming. Although the game is still not live, I learned so much building it.
Yes, I think if you are really obsessed with something for over 10 years, it's time to make it your life's work and not a side thing. But maybe the point is that you don't want that to happen as you lose your forever project (if it gets done) or fall out of love with it.
No, but I don't think that's necessarily the point of a forever project nor of life in general. It's not a goal of mine nor of none of my friends who have one; most of the projects from people I know cannot even make money even if (partly) completed.
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).
I don't necessarily think that it needs to be a Forever Project, as long as it lasts for at least 6 months or so.
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 liked this article. I for one have been overly conscious on ends rather than means, and I forget that it was the means that got me into software development in the first place. I used to have so much fun! It never felt like work (it does now).
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.
I had different forever projects at different points in time. I often come back to a planet renderer based on a certain algorithm (P-BDAM), but it lost its lure on me in recent times.
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.
Interesting rgd. the functional reactive programming. I am obsessed with this, in a networking/mobile device context instead of a gaming context - not that it should matter. And applying this to real problems beyond the toy problems that you find in tutorials on the web turns out to be real hard - this may end up becoming my Forever Project yet. Email me at hank[at]ml1.net if you want to discuss this.
Hm. I actually have four things that qualify as a "Forever Project", and I've sunk a decent amount of time and money and energy into each one. Results... nothing worth noticing.
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.
Release it now, it's no use just collecting dust on your hard drive. You can always improve it in the future—think of it being in constant development.
Normalizing source code, storing it as annotated ASTs. Designing a structure editor that is actually usable for real code. Applying precise version control to those ASTs' nodes.
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.
Well, there isn't really a body of code to version control yet, as the AST forms still aren't quite finished, and so all the ASTs will have to be generated from text code (yes, Python) until the language is properly bootstrapped.
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.
Versioning AST's has been on my mind for some time as well, I got interested it as a way to store source-code in a coding-style-neutral way (check it in & out with whatever coding style you're used to), and to be able to categorize check-ins based on the type of changes to the code (only comments, moved code, variable renames, etc).
Probably you already know about it, but have a look at papers aboht the tree edit/tree distance problem:
I´m about dreaming such a language for years. But I already have a forever project so I never really did anything about it :/ Got anything online? I´d love to watch this project.
I actually thought this was about those projects you make for a client that will never end. Clients that keep coming back with more and more changes. Usually accompanied by a Project Manger that's afraid of the client. I ocasionally have nightmares of pressure cookers after working on a terrible website for more than a bloody year.
Since childhood I have wanted to build on scale humanoid robot. Though I have not done anything towards that goal except some thinking of what kind of materials it has to have as the body. How to power it and what kind of brain it needs. Though currently the only thing stopping me from starting to build skeleton for it is money. :P
You are very right. Processing the data is what drives me. Its just hard to the point of impossible in my trained field(s) [architecture/GIS/planning/etc.] with current tools so I need to invent something to do it for me (which should help others in different fields too). Its on its way...
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.
My Forever Project is indeed a “game of some sort”, to quote the article.
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!
A while back I decided I would get a bit clever about my Forever Project. I evolved it into a setting instead of a single project, and that setting can contain as many sub-projects as I like. Even completely unrelated projects can be worked into it via my internal head-canon. It's a well I can keep going back to, and serves as an excellent starting place for smaller projects or brainstorming.
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.
Sometimes the goal of a personal side-project is not to produce something meaningful, but just to learn and have fun while doing it.
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.
Take me as an example. My Forever Project is Physics. I have a degree in both CS and Physics. I made the decision years ago to work in the industry as a programmer, because it's more fun and pays better than being an academic, especially where I live. I'm not officially involved with my old University, but I still take part in their mailing lists, think about Physics in my free time, I even submit simple papers to journals [+]. I don't have delusions about being a good physicists or ever doing anything of any importance, but Physics still fascinates me, I like to ponder its problems and sometimes marvel at its beauty.
Regarding the mention of GTD: I don't think it's incompatible at all. I think DA would say that it belongs on your Someday Maybe list, and you're welcome to bring it back up for review anytime you like. Just keep it in the system so it doesn't take over your life right now. GTD is exactly for this.
It is great to have a forever project. But we have only a limited time on this planet, so definitely not forever, and at some point you should look at yourself in the mirror and ask yourself, "Am I going to do this, or what?".
my forever project, of course, is to build the metaverse. I loved this article because i can reassure myself i am not crazy after all ... or at least that I am in good company :)
My forever project's been going since 2008 (yikes!) I've been working on a computing environment for kids, and I'm super proud with how far it has come. https://clubcompy.com
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.
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 :) )