DEV Community

Cover image for A crazy idea and a proof of concept

A crazy idea and a proof of concept

Christian Gill on January 30, 2019

In December last year I created the proof of concept (PoC) for an idea I have that seems a bit crazy, at least to me now. It’s a tool to search Typ...
Collapse
 
_nicovillanueva profile image
Nico

Not a TS user, but looks like a really cool idea.
As per the questions, I'd go for the TS signatures for searching. All in all, ts-earch users will already be familiar with them, and forcing them to learn an additional DSL could hamper your adoption rate. Also, it's prone to have it's issues here and there, further difficulting the UX.
I have a similar-ish idea for a proyect (a "snippet-oriented", openly searchable, collaborative database) where I'll have to search leveraging code itself and descriptions. I might go for a machine learning/NLP solution. Although it's a tough road to take, you could look into it. Train some NN to sort out what method/function the user looks for based on the types mentioned. Overkill and hard? Absolutely; Fun? Hopefully.

And how to do inference/indexing/matching, I may be talking out of my a[s]{2}hole here, but I feel like some sort of tree datastructure may be of help here. For example, Scala types are sorta like this: oreilly.com/library/view/learning-...
If you could make something like that for TS, flexible enough so that you could add custom types based on the properties they contain, you could start matching them by traversing the tree.
Language theory is haaaard. I have a deep admiration for people who does that, and I'm sure you could find some here in dev.to. They'll be able to guide you a bit more with this.

Collapse
 
gillchristian profile image
Christian Gill • Edited

Thanks for the comments! Very useful suggestions!

I haven't made up my mind yet about the query language. A "DSL" could be much simpler than the actual definition. For simple signatures there's no much change:

(type: string, id: string) => string
// vs
string, string => string

But for more complex ones it could become easier to type:

<A, B>(array: A[], fn: ((a: A) => B)) => B[]
// vs
<A, B> A[], (A => B) => B[]

But I did not consider the fact that it would mean learning something new. That is a strong argument.

Yeah a ML/NPL solution could also be the case. But I guess it makes more sense your your idea (which, btw, is really cool).

Yeah, I will definitely take a look at how other languages do and even how TS itself does the type resolution. Now I implemented something pretty naive. Will write a bit more in the coming week/s.