It's funny because some of us have the opposite problem. Too many ideas, but not that much interest in learning new languages for their own sake. So when it comes down to implementing a new idea, we want it done quickly. We don't want to take the time to try to figure out how to make it in Haskell, and just revert back to Python.
I agree, that is the one the (relative) dangers when you are proficient in a language; it is so much easier and faster to write something in the language you already know, rather than having to learn everything from scratch. Of course, it also depends on how much difference there is between old and new languages; a Python expert could probably pick up Ruby in no time, and vice versa; but Python vs Haskell is a different story.
Yeah, Python is my Blub. I know I should learn stuff like Haskell and Clojure, but I just haven't come across any cases where it's more than a minor inconvenience to make Python do what I need.
I recently ran into this. Thought of implementing a new project in clojure and quickly defaulted to the language i am used to.
One way to mitigate this is to re implement a small project that you have already implemented in your older language. At least you can focus on the language instead of the project nuances.
Another way is to pick a top-notch library or framework in your target language, and learn to use that. For Clojure, I'd try making some clever charts with Incanter:
(Incidentally, the only new language I've been able to stick with after learning Python is R, because it solves completely different problems. Which means R is now my Blub for stuff that I'd like to, given some free time, try with Clojure/Incanter...)
It can be a problem because you use your favourite language/tools over and over to be productive, but then you look up and ten years have passed and your skills are no longer marketable.
This is easier to see in the older generation - I have the pleasure of knowing some totally top-class programmers who have happened to spend their whole career writing FORTRAN. Would any of you guys hire them? No, you want the RoR kids, not surprisingly.
Like everything else in in life, there is a Middle Way. Don't have new-shiny ADHD, but try and tick over a new language or technology every few years.
Just be sure to finish them. The mantra in indie/hobby video game development is "finish your games, and if you can't finish, try making something simpler".
My advice would have been to reinvent the wheel. Yeah it might not add to anything useful but there is an off chance it could. The reason why reinventing the wheel is good is that you have direction as to what you should implement. Trying to do something new all the time isn't possible.
I used to build tic tac toe games It was never complete or useful but it helped me learn the tech I was using. Now days creating a blog engine is my new tic tac toe.
One of the coolest programs I ever made was a tic-tac-toe with an AI that learned the optimal strategy by playing itself over and over. I wrote that in the process of learning Lisp, which made writing the program easy, and I got to exercise a lot of the language features.
What was so cool about it was watching it learn, and realizing that unless I programmed it to make random mistakes, it would settle for sub-optimal strategies.
It's simulated annealing specifically when you start with more tolerance for unfavorable random mistakes, then gradually move toward only accepting random variation that improves.
>I believe the AI strategy you describe is known as "simulated annealing".
Not necessarily. You could get much the same effect (the program learning by playing itself over and over) with many Reinforcement Learning algorithms (like TD learning, say).
There are major differences between Value Function (loosely, perceived_state -> perceived_long_term_reward map) based RL algorithms and algorithms that work only in the policy (loosely, the perceived-state -> chosen_action map) space like Simulated Annealing (or Genetic Algorithms). Barto and Sutton (somewhat loosely) use the term "evolutionary algorithms" to distinguish Value Function based algorithms from those that only manipulate policy
Agreed. I find that when you're actually building something, that's when the great ideas come. You start to think of improvements and new approaches that you just can't think of without first getting your hands dirty.
I haven't done this myself (not enough experience) but I saw a similar idea discussed years ago - for an experienced programmer learning a new language, reimplement something you have already written in the new language. Supposedly, the fact that you had written the first application shows that you understand the problem domain, so you can concentrate on the new language.
Yup, just try it, make the board and how to check if someone won or if it's full, figure out how to get input from the user. Then if you like the language move to implementing a simple ai (start with randomly putting pieces ;p).
By then you should know a good chunk (IO, loops, built in data structures ...)
I have never done any graphics at all. All I know is bash and some awk and perl, mostly for text processing. I keep planning to learn more, which is why I read about it a bit, and browse HN, but I have too many other things I want to do too.
o | o | o
----------
x | x | x
----------
o | o | o
That (if HN doesn't mangle it) should be a fully working Tic-Tac-Toe board. You can store it as a string, hashtable, whatever you want. You could label the squares 1-9 for the prompt asking the user where to move.
This is all doable with perl and a command line. Try it out, see what you learn.
My first implementation (in c++) was exactly like that. A 3x3 array that printed out like that. You had to enter 1,1 for the left upper corner (that's how I learned that arrays start at 0 in almost all languages ;p)
There is a surprising number of these. Although I would wager that the ones who hang around wanting to make it big and having lots of ideas as to how, just no useful ones are on the right track. They just have to improve their ideas so they can be useful.
The real problem are those who don't even have useless ideas.
I'm coming at it from a technical background, but something that excites me from a business perspective is developing a business system that is able to efficiently execute plans in a certain space. However, just as I'm about to do that, I find there's one particular plan that's got the potential to make it bigger than all the others, and I make an "all in" bet...
For most of the people looking to program something in Haskell or Erlang, programming is their outside interest. Perhaps that's why we get so many compilers written in exotic languages...
While I think it's completely correct that the best software is produced when a programmer recognizes one of his own needs which isn't being met and decides there's a better way to do it. It's bad to take such a disdainful stance toward programmers in that stage between producing simple self contained projects and software that can be integrated into an OS or other applications. Charting your own course is tough and frustrating. The best advice for aimless but excited programmers in terms of what will help them and the community the most is to join another project. Opensource is an obvious choice since it has a low barrier to entry but an internship at a company could work well too.
I think I suffer from this problem, I like to compare it to writers block or something like that, my problem is that I want to develop something but I don't know what and get frustrated at having a lack of ideas.
This frustration then gets interspersed with furious bouts of development on personal projects that can last 4-6 weeks, and then I go back to another 3 months of doing nothing and hitting my head against a brick wall.
This might seem counter-intuitive, but get a new hobby.
By which I mean, if your life as you're living it isn't providing itches that you need to scratch with software, a new hobby might provide some. Or, you might spot an unserved opportunity or market.
I think we've all had a shiny new tool that we are just dying to use, but don't really have a use for it. That's what these posts are.
The advice is correct, but could be summed up better:
Go work on something.
It doesn't matter what, just pick something. Don't ask someone else to give you work to do. That -never- works out without external pressure, like a paycheck.
I get the urge as much as anyone else to "build something new and cool" (spend enough time Googling me and you'll see I'm pretty guilty of this) but I think FOSS would be farther along if fewer people tried to start their own projects and instead contributed to existing projects.
Summary: “You should be motivated in the same manner that I am.”
Er, what’s wrong with someone looking to non-specifically contribute something to a movement (GNU/Linux) or to improve their skills in a particular language? Not anything, necessarily; they’re probably just young.
The point is that with the given strategy, the developer won't be able to contribute anything meaningful to their pet movement. They might learn something, but they won't create something useful.
