Abstract out the matching algorithm architecture to allow other types of comparisons

[geekygirlsarah]

Description

While comparing programming languages was the original purpose of Code Thesaurus, the goal was to enable other types of searches for things. This could include things like:

• SQL (compare MySQL SQL vs PostgreSQL SQL vs SQL Server T-SQL, SQLite, etc. but also those compared to NoSQL (like MongoDB, Cosmos DB, etc.))
• Algorithms (how to implement linked lists, Dijkstra's, breadth- or depth-first traversals but in each programming language)
• Testing frameworks (how to do asserts in common testing libraries for various languages)
• REST frameworks (like comparing how to do REST methods or other things in Django, Rails, Symfony, MVC, etc.)
• Package managers (both language based ones like npm, pip, composer, cargo, etc. as well as system ones like apk, apt, rpm, homebrew, chocolatey, winget, etc.)
• And more!

Right now the main matching algorithm is hard-coded for languages. It is also heavily tied into the reference and compare page views. This work would need to refactor the algorithms out of the views and into their own class, and also refactor the variables to be more generic for any types of comparisons. The end result would be something that's easy to add a new comparison type to the home page and with new views and thesaurus files, we have an easy way to scale this concept to multiple comparison types.

Requirements

• First, it may require a discussion here on how to do this before the work happens.
• Second, it should result in the code refactoring and/or abstraction. (Pull it out in a class/library?)
• Third, ensure the view code is rewritten using the new method.
• Finally, check that any unit tests, the language validation command, and the meta file validation command reflects the new abstracted system.

Additional Notes

I haven't thought too much on this yet but will probably start looking into it during October 2023 (Hacktoberfest). I welcome anyone that wants to join in on this!

[seabeePraveen]

hello @geekygirlsarah i have gone through the above mentioned detail but im not able to figure out whats the issue is. could u please explain the issue?

[geekygirlsarah]

@seabeePraveen sorry, I meant to write back and lost the tab I opened in a sea of other tabs!

The algorithm right now is heavily tied to the specific language compare and language reference view code. They are also written very specific to language lookups. Those algorithms need to be refactored out into their own class or something so that other types of lookups could happen (by their own views and thesaurus files) but also so the algorithm is written more generically in how it compares things.

I updated the issue's wording a bit too.