Chickencha
It might not make a difference, but it can't hurt.
min(a, b) {
if(a < b)
return a;
return b;
}
Also, there is a small team working on Go full time (http://groups.google.com/group/golang-nuts/msg/198b0b742d02b...).
Nobody on the Garmin Connect team or here on Hacker News needs to give me a reason for not wanting to relocate here. In a way, the place where you want to live is a very personal thing. Different people have different reasons for what they do and they don't need to justify their choices to me, just as I feel no need to justify my choice to them.
That said, I definitely think there are people blindly saying "Kansas sucks" without having lived there or even traveled there. I sympathize with the Garmin Connect team, as I would not want my employer to try to force me to move anywhere. However, I also resent the attitude that they seem to have taken toward Kansas and the implication that no one would choose to live there. (I admit that perhaps I'm reading too far into it.) To me, it would be enough to say that Garmin asked them to move and they didn't want to.
It would be nice if John Gruber opened up the contribution process or officially handed off development to someone else, but he's under no obligation to do so. We're not paying him. He probably started Markdown for his own purposes and was kind enough to release it under a free license. It's totally fine if he doesn't want to continue work on it, because I can easily take his code, check it into GitHub, and start my own fork.
Many (if not most) university computer science programs do attempt to prepare you for a software engineering career, but the point is that they're failing in several areas. You could call it a software engineering degree and they'd still have the same issues.
First, speech recognition is very difficult. Fortunately you have a limited number of key words you have to support. Unfortunately, there's an almost infinite number of symbol names available, many of which can't be pronounced in a definite way. Variables created through speech recognition are going to be pronounceable, but what if you're working on a project with someone else who's not using speech recognition? What if you're working on existing code and don't want to refactor all the variable names? It seems to me that this could be even more difficult than natural language speech recognition.
Second, what problem does this solve? You mentioned RSI sufferers, which is certainly a problem, but how large is the market of Python programmers suffering from RSI? I'm guessing not that large. The software would have to be extremely accurate in order for me to not get quickly frustrated. On top of that, it would have to offer some benefit over typing, and that's not something I see in your pitch.
Third, I'm not so sure about your business model. I think in order for people to want to pay to download their personal acoustic model, the default model would already have to work really well. If it didn't, programmers would probably find themselves thinking "If the default model works so poorly, will the custom model really be that much better?" However, if it's too good, then there's no incentive to get the custom model. You're creating a balancing act that you'll have to perform in order for anyone to want to give you money.
A more interesting goal would be to supplement the keyboard and mouse setup rather than replace it. Think of ways that any programmer might become more productive through using voice in addition to hands. This would probably be much simpler, which allows you to release more quickly. I think it would also increase your potential user base, and eventually you could expand it to do everything if need be.
On a similar note, is any of the code run on the server side? If so, how do you prevent DoS attacks? Are there checks in place to make sure that I don't create an infinite loop or allocate a ridiculous amount of memory?
How does it handle vandalism? It seems to me that vandalism could be a lot more devastating in this environment than in, say, Wikipedia.
In your text editor example, the author can add an SFTP feature, but once it's coded it's coded. There's no extra cost to ship out all software with that feature after it's coded, except perhaps some extra support costs. (I imagine those would be pretty minimal.) At that point, I only see two reasons to segment the market from the users' perspective:
1) To not confuse your less advanced users with more features. This is a pretty weak reason, IMO. 2) To make sure that the people who actually wanted the feature are the ones paying for it. After the cost of development is paid for, this reason goes away.
Beyond these reasons (unless I'm missing something, which is entirely possible), releasing different grades of software just hurts your users. It makes you more money, though, so maybe that's enough justification.
Guitar Pro tabs are user generated and vary in quality. And good luck if you want to find an obscure song.
Hook it into something I can use without hassle and I'll try it out immediately.
Please, please let StarTeam die so that my work might switch to something else. It will probably take a few years, but anything at all would be better. Those of you who have never used StarTeam don't know how good you have it.
Journalists have a responsibility to make sure they're printing the truth. It's really distressing to know that there are some out there who are so lazy. This particular example isn't that big of a deal, but it's easy to imagine something similar happening with something more important.
If you're using Wikipedia for anything more than casual learning, then you'd better make sure that you can find another source to confirm what you find (and make sure that that source doesn't cite Wikipedia).