Set::Object was certainly not around when I was learning Perl. I think this is good thing though. Not learning all these new Perl routines and functions probably slows down my program. But since we are probably dealing with 5 milliseconds or less, I'm not overly concerned.
I agree that defining the hash the "old fashion way" may be wordy but what I like about wordy things is they are usually easier to understand. Those looking at the wordy code will have one less thing to learn, which will translate into faster learning.
Another thing that I like about wordy is it tends to make porting to other languages a lot easier. For example, one of the tools that I had written in Perl was translated to Javascript with fair ease because I stucked with the basics.
I personally find that being wordy is a good thing instead of a bad thing. Obviously there is a point where not accepting change or wanting to learn a new trick is just being ignorant though.
I agree that defining the hash the "old fashion way" may be wordy but what I like about wordy things is they are usually easier to understand. Those looking at the wordy code will have one less thing to learn, which will translate into faster learning.
I disagree. Using a set to represent a set is more readable than using hash keys to stand in as a set. As it stands, the hash maps values in the set to undef, and maps values outside the set to undef. This is confusing. Confusion translates to slow knowledge uptake.
Don't try to jam a square peg into a round hole when you have a round peg in your other hand.
He's parsing queries to DDG to determine if they are the type that WolframAlpha has good results for. The objective is to cut down the number of queries sent to WolframAlpha.
Interesting pricing. The lower three tiers of the small business plans seem to be strictly worse than the most similar of the personal plans, and the highest is only a better value in a particular (small) range of request counts (490384 < number of queries < 666667). I'd hope they at least provide an SLA or something to justify the extra cost.
This makes me think of an idea, I think it would be awesome if Duck Duck Go offered me the ability to make a "plugin" for their site. In much the same way you can pay for key words on google, i'd love to pay for a topic. For example, I've been working on a side project which gives you recipe ideas for ingredients you have. I built the technology in a very modular way, which would make the construction of a plugin pretty easy. I would like to purchase the idea of ingredients so say for example someone does a search for "celery carrots peas" the zero click box would show my results.
In addition, I've noticed many people use Google for anything they want. My mom found her email by googling for "email" if the search terms ever change... she wouldn't know how to get to it. I would love to have it so if my mom already has an account on my site (which has a record of her kitchens inventory) she could search for "recipes" and in the zero click box would be a listing, but customized just for her.
I'd love to do plug-ins. The trouble is this initial filter step, i.e. I can't be sending all queries to all plugins for many reasons (privacy, resources, speed, etc.). But I'm very open to integrating vertical engine APIs where it makes sense, or linking to them directly. For example, last night I added links at the top based on this type of routing, e.g. http://duckduckgo.com/?q=php+date+function
So if any one has any implementation ideas, I'm ready!
Just an idea, instead of sending all queries to all plugins could you do a look up instead? Such as my example above, part of the process of registering a plugin might be specifying a keyword, and a identification function. So during the process of creating your zero click results you could check an index if any of the keywords have plugins associated with them. Once you have a narrow list of plugins then you could run through the list of plugins to see if the results are relevant.
Also, I'm totally declaring a new holiday: "milk day".