Authors: Shannon Lawrence, Anthony Mak
What is the problem?
Choosing a city, whether it's someplace to travel to more briefly, or someplace to settle down in more long term, can be a big decision. Our world is full of so many wonderful cities to visit and live in, and often people are intimidated by the options and this prevents them from being able to discover new places. Our program will help in this pursuit. Using data collected from the teleport API, users will be able to easily search up information on, and find and compare cities that they may potentially want to visit/live in, and discover new options that fit their most prioritized criteria. All data is conveniently arranged on a 10-point scale, so users can easily assess and compare cities along categories such as Housing, Education, Healthcare, Safety, Leisure & Culture, Outdoors etc.
There are three modes:
- Single city
- Two cities
- A list of cities
Each mode has two options:
- Information on teleport city score
- Information on their individual category score
What is the something extra?
We used the teleport API: https://developers.teleport.org/ It is integrated throughout the program, so that all users can inquire about a large range of cities and get information quickly on many different categories.
What did we learn from doing this?
Overall, we found Prolog to be quite suitable for this task, since it was quick and concise to implement, and had strengths when it came to reading and handling our dataset. The structure of Prolog was basic, which was a positive when it came to easily breaking down the larger problem of building a city recommender into very simple components - there wasn't nearly as much code needed for the UI and API as there would be in an object-oriented programming language, for example. For me it was easier to understand how to use and I found that I was less likely to make syntax errors and had less bugs than with another programming language, and this was thanks to the clear-cut nature of this logic programming language. However, there were some downsides to this as we weren't able to use things like if-statements, for example, which would have made things a lot more intuitive and easier to read when looping through the UI code in our cityRecommender.pl file. However it was also easier to account for different responses a user might give by just setting clear rules on what responses would be acceptable in just a single line of code.
Cons - Debugging was harder as there weren't any easy-to-use debugger that many other languages would have, and it was hard to tell where exactly the code went wrong when we got an answer other than what we were expecting. GUI and graphics are something else we might have wanted for a program such as this which decided not to implement because it's not very feasible in prolog or supported at all, so this was another limitation.
More Pros - Lists were also relatively easy to use in Prolog thanks to it's powerful pattern-matching (thanks to unification), and this was useful in our api.pl file. It was easy to access the head of the list to check if it met certain rules, and then iterate through the rest of the list simply.
Prolog also has non-determinism through search, meaning that if one option/path failed, it would backtrack and choose a different option automatically, which was good
- could extend relational databases
- referential transparency - variables didn't change their values once assigned