

WeinbergAlpha: DuckDuckGoes opensource with its WolframAlpha integration - kn0thing
http://weinbergalpha.com

======
jrockway
FWIW, this is somewhat wordy:

    
    
        my %holidays = (
            'mlk day' => undef,
            ...
        );
    
        exists $holidays{$query}
    

It's better to use a set:

    
    
        my $holidays = Set::Object->new('mlk day', ...);
        $holidays->exists($query);
    

This generalizes to arbitrary objects, and is faster.

Also, I'm totally declaring a new holiday: "milk day".

~~~
sdesol
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.

~~~
jrockway
_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.

------
glen
Nice contribution!

------
cmelbye
So he's... re-doing WolframAlpha's complex and carefully designed language
parser? Is that working well for him?

~~~
secretasiandan
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.

~~~
brfox
That seems like it would be worthwhile (to cut down the number of queries):
<http://products.wolframalpha.com/api/pricing.html>

~~~
amalcon
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.

------
clistctrl
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.

~~~
epi0Bauqu
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!

~~~
clistctrl
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.

~~~
epi0Bauqu
Yes, something like that could work, which is essentially what I'm doing here
with WA (just in a bit more complicated fashion).

