jd

When I was nine I was playing with BASIC and wrote a simple program that would enumerate all colors of all pixels on the screen. I wanted to see all possible images "fly by" so to speak. First I got frustrated because it was running so slowly, only then I started to think...

If I can display a picture of a car on this monitor, then that picture would eventually also show up 'by chance' with my program! Mind blown. Then I realized it would have to show every picture in the world eventually, because every picture in the world could be displayed on my monitor. Mind blown again. Then I realized it would display every book in the world also, because a picture of a page of text is just another picture. Whoa. Then I realized the monitor would also eventually display all things that happened in the past that we had no records of and everything that was going to happen in the future!

Of course I couldn't grasp exactly how long the program was going to take, but I realized that if it had to go through infinitely many pictures it would have to take infinitely long to run.

But now I can do the real math. Should be fun:

Display 60 frames per second. 3600 seconds in an hour, 85000 in a day, 31 million seconds in a year. So 1860 million images per year.

How many possible pictures are there?

640 x 480 x 16 bits = 0.5 MB frame buffer. Kilobyte is 10 bits, megabyte is 20 bits. So there are 2 ^ 20 bits and each bit we have to toggle so there are 2 ^ (2 ^ 20) combinations.

1860 million combinations ~ 30 bits. Since we have 2 ^ 20 bits worth of statespace those 30 bits are completely insignificant. So let's assume there are a billion people with a billion computers each who work on the problem in parallel. Then there are 2 ^ (30 * 3) = 2 ^ 100 images processed each year. This still doesn't make any difference! 2 ^ 30 - 100 bits = 2 ^ 30 bits.

It would take over 10 ^ 300000 years for a billion people with a billion computers each that process 60 frames per second to enumerate the different values of a 640 x 480 monitor.

And that's just for a single megabyte. Mind blown.

We've been using a similar approach for Thymer since the beginning and we've always had a really good conversion rate (conversion between visitors and signups):

http://thymer.com/try/

Using a little creativity in the design, even for forms that users fill in only once has been a great way for us to set ourselves apart.

I'm guessing it's actually a free plan, despite the "30 day trial" text. I'm guessing it's a humongous typo.

When you sign up for the priced plans the sign up form asks for credit card info and promises 30 days free. The "Free" link goes to this sign up form: https://scoutapp.com/accounts/new?subscription_id=2 which doesn't ask for any contact details, and clearly shows the price as $0.00.

Besides, I don't think the guys running Scout would refer to their service as freemium on their blog if they didn't have a free version. Their help link at the bottom of the website is also broken ( http://scoutapp.com/info/help ), which means the the website probably hasn't been tested/proofread very carefully (understandably -- there's so much to do).

Diederik from Stunf here.

Back when we started on Thymer we considered the market. In fact, we asked ourselves: "do we want to enter a saturated market?". But then we realized that we just assumed the market was saturated, but we think the evidence points to the contrary.

True, there are a lot of competitors. But surely the number of competitors alone doesn't mean the market is saturated? The market isn't saturated until you can choose between 4 or 5 products that are all great, and that all suit your needs well. There may be hundreds of email services, but Gmail put them all to shame. Sometimes taking just a slightly different approach can make all the difference.

At this point only few of our competitors have great products, and even fewer are truly successful. Or to put it another way: in another 5 years we expect all the products to be radically different. The market hasn't matured yet (like Word Processors have), which means the market leader of tomorrow probably hasn't incorporated yet.

Or we can look at it from another perspective. Because task & project management apps attract the GTD (Getting Things Done) crowd, people will happily try out your product, blog about it, and so on. So in a way entering an established market makes life easier for us. We don't have to explain what we do, or what software as a service is -- people know what to expect. We just emphasize what we're good at and we get people to give Thymer a test drive. If they love Thymer they may buy it or recommend it to others.

So people know roughly what to expect when they hear of "another task and project management app". From that point on we just have to exceed their every expectation. That's of course easier said than done, but we don't expect it to be easy.

Contrast this with marketing, say, a new search engine. People would ask: "Why do I need this?" or "What's wrong with Google?". Even if your search engine _is_ objectively better people will still compare what you do to what Google does at every step. "Why don't you have a translate link?", and so on. Because there are a good number of competing task and project management services the comparison becomes much more nuanced. "So you have tags like Gmail, projects like X, and teams like Y. That's nifty!". That makes our life pretty easy. Imagine what marketing something entirely new would be like. I wouldn't know where to start.

If you're interested we could write some more on our blog about this; explain our point of view a little better.

Haha. The use of 3d pie charts was deliberate, and I know they convey almost no information (and often give a skewed impression). We would never use a pie chart for real decisions, but in this case we only cover 7 days worth of sales, which is way too little for any meaningful analysis.

In this case, the 3d pie charts just look shiny :)

It was a bit of a dilemma for us. On the one hand, we realize the importance of the TOS and Privacy policy, on the other hand, we don't like the "Hi there, thanks for visiting. Please sign our TOS" kind of welcome; it's so cold.

EDIT: added links to the TOS and Privacy policy to the footer on thymer.com

We're happy with the numbers, but I think they can be partially explained by our long beta period. People have been asking us "when can we start paying?" since the beginning of the summer.

We are entering a crowded market, but it's not as bad as you may think. A lot of the competing project management software startups take the exact same approach. So we see Basecamp and all the Basecamp clones as just a single competitor, and we deliberately take a different approach. As a result, some people will prefer their approach, and other people tell us they've been looking for something like Thymer for over ten years, and that's the kind of feedback that confirms we may have found a good niche.

We thought about that, but often pressing Esc, or clicking away is associated with "undo, oops, I didn't want that". We figured when Thymer would save/overwrite user data without explicit permission it would result needless frustration for our users.

We had roughly 10k beta testers, many of which found eachother (we have team features and you can create accounts/invites for other people in your team), we used beta keys, invite codes, all kind of things. Twitter and blogs also played a big role. Big ones (mashable and such) gave us spikes in new signups, but other blogs (lifehacking.nl) and other more targeted sites gave us higher quality subscribers.

We haven't done any adwords at all, even though I have a bunch of free $50 adwords vouchers. It just didn't seem worth it for a private beta.

We plan to talk about this in more detail in a future blog post, when we're fairly certain that our approach was successful.

Ack, good catch. Fixed it. In fact, rewrote the sentence altogether. Thanks!

Observe how many great designs are thrown out by the designer before he finally settles on the theme.

Even great designers need to iterate. Their first sketch will be immeasurably better than our first sketch, but the concept stays the same. As you get better you notice more subtle flaws in your designs and so good and even great designs are discarded in a moment.

I wonder if the number of iterations a designer (or writer) needs stays roughly constant throughout his career. I suspect it stays roughly the same. Anecdotal data anybody?

The uninstall and disable buttons work on my FF install, for the framework assistant 1.1

> You can argue all you want about how order-of-operations makes things unnecessarily complicated

That's not what I'm arguing. It's okay for that complexity to exist, I just don't think that exposing it to the end programmer is by definition a good thing. If you have a fixed set of infix operators then you can have a well defined grammar. If you have an extensible set of infix operators, then you need to make major changes to your grammar to prevent ambiguity.

The way infix operators work is a decision the language designer has to make early on. Bolting on a way to create new infix operators in Java (not that you're suggesting that) would be a disaster. I agree with you that sacrificing the "just work" aspect in the name of strong typing (OCaml) or in the name of uniformity (Lisp) is a bad trade-off.

The problem with operators is that they have a binding strength. If you want the expression 7 + x * 4 to evaluate correctly operator * must be stronger than operator +. If programmers can define their own operators they'll either have to supply binding strength as a numeric parameter (ugly) or relative to other operators. For instance, you could have a list of operators per class type, where the first operator in the list is the strongest, and the last operator the weakest. You can then insert your operator in the "right" place in the list to specify the strength. This is a reasonable solution, but you'll run into different problems when two libraries each define operators on the same types. Either way it's not going to be an elegant solution.

It also is a problem on the grammar level. The expression 5--x is ordinarily parsed as 5 - (-x). But if you were to introduce an operator -- the meaning of that statement would change to 5 -- x. So the introduction of user defined operators can change the meaning of an expression.

Overloading and user defined operators is a hairy, hairy topic, and the "anything goes" approach is not necessarily the right solution.

In the Netherlands it's not a matter of population -- shops are not allowed to be open outside the regulated hours. I believe the law was introduced a few decades ago in order to protect the mom and pop stores (a misguided attempt to put mom and pop stores on equal footing with larger businesses. If the mom and pop store can't afford to stay open at night then nobody is allowed to. Because that's "fair".)

Since gas stations have permission to stay open around the clock they're used to get emergency food. You can also get food delivered on Sundays and in the middle of the night, so it's not so bad.

This is a great series. The guy can write (he's also funny) and he writes the series in a really accessible way. Definitely worth reading.

Also check out his "terrain" series, it's terrific. http://www.shamusyoung.com/twentysidedtale/?p=141

Does your service work for European cell phones?

You don't use the new language exclusivity, it's just an extra tool in your toolbox. You just use it to expand your horizons. Knowing even a little Haskell will show you that a little type inference can go a long way. Or that reasoning about correctness is easier in a purely functional language.

I think the primary advantage of knowing many languages is knowing when you're using the wrong tool for the job.

Good marketing gets you hired. Good networking gives you job opportunities around the globe. Good marketing gets you promotions and bonuses. Good marketing keeps your group's product from getting the axe.

0 errors, 0 warnings isn't all that important.

Rails is in a though spot right now. Facing a big challenge, a huge challenge even. And arguably, a challenge it didn't have to face.

Why introduce a new VM and break backwards compatibility at the same time? Why not first give people a better VM, with bytecode, better threads and all the other goodies? When people know that upgrading is painless (think Perl) then you can just upgrade without thinking twice about it. If you know you have to check the compatibility checklist of all software you have ever installed (for all you know your text editor depends on Ruby nowadays) then upgrading becomes a very unappealing task.

So, step one: introduce new VM. Step two, still don't break backwards compatibility. -If- you have to break the language, at least put some legacy mode in, so people don't have to port every script on their system.

Double-click edit will is on the todo-list -- will be implemented somewhere in the next week or so.

Glad you like it.

1. It is a little confusing, now you mention it. The difference is that the big check box on the left marks a task a done, and the other (small) checkbox is used to select a bunch of tasks so you can do bulk actions. At this point there is only bulk-complete, but adding tags by bulk is something you want to relatively often, so that's why we can't really get rid of the second check box. On the other hand, it is weird to have two check boxes for every todo, so we'll have to think of something.

2. Correct, D is discuss. The D button can be toggled so other people can see the todo should be discussed first. Suppose I want to work on a feature, and Wim realizes that it won't work because of X, he can click the 'D' button and add a comment. When I then go to my task list I see the 'D', I check the comments and realize what's wrong. We found that a simple flag that says "hey - wait a second" is a really effective way to indicate a possible problem.

3. Very annoying. We wanted to fix it, but we couldn't justify waiting any longer with the beta.

Thanks for the bug reports.

1. We'll fix the @today @today bug. Dropping the second today is probably the right behavior.

2. No google calendar plugin yet, but we plan to do a lot with extensibility. Since I use google calendar myself it a plugin is on the todo-list.

We haven't decided on pricing yet - but there should be a plan for everybody.

1. Projects cannot be deleted at this point -- only completed (closed). This is bad, I admit, we're going to fix it.

2. Double-click for edit - yes, absolutely. It's completely obvious now you mention it.

Glad you like Thymer!

We definitely want to build an iPhone app, but it is a lot of work to make, so we're probably first going to iron out the flaws in this version and then release version 1.

I think we know exactly how you feel. I've spent countless hours trying and installing different applications, and they ultimately all disappointed.

Thymer is by no means finished -- but we think it shows promise. If you want to invite your girlfriend to Thymer create an account and team for her via the "settings" link in the upper right corner. It's not intuitive -- I know, this will be fixed in the near future.

The load is low and Thymer is on a fast server - but our hosting provider reports package-loss and higher latency for a users in our data center, so I hope this is only a temporary problem. Responses are instant here, so we thought it didn't affect us.

If it isn't we can always lease servers in the US, so even if the latency doesn't improve we'll figure something out. Thymer is instant for us, and it should be instant for everybody else. I doubt we'll get around to leasing servers in the US before we launch though -- so please bear with us.

And thanks for wishing us luck. We want Thymer to be great too -- creating passionate users and all that.

A phone version is planned - but we've discovered that most phone browsers are really terrible. Are you looking for an iPhone web version, or for a jar version (like google did for gmail/google maps)? Or do you think something that uses Opera Mobile/Mini would be good enough?

It's pretty hard to get reliable worldwide sms delivery, but -- sms for the USA and Europe we can do, I think.

No video? That's bad. Youtube used to be pretty stable. We probably should put up a mirror of the screencast at vimeo. That's what we're going to do next.

Thanks for the heads up.

Great article - bad title. Saying that time might be an illusion is saying that time might not be "real". But a different model of time doesn't affect its realness.

Is temperature an illusion? Certainly not. And yet, as the article says, it's merely a model of the interaction between molecules.

Some models explain more than other models. Models that explain more are better. Thinking in terms of real/illusion is not helpful at all.