Python代写 - Comparative Programming Languages
The goal of this project is to build a single system that uses
multiple languages to do its work.
It is very difficult to quantify the “size” of a project, but it should
be enough to justify marks for 26% of a 3rd year CMPT course. In
particular for this project, you should have:
• several pieces of interacting functionality (which give us
the excuse to use multiple languages);
• overall complexity that leads to a thousand to several
thousand lines of code (while also noting that lines of code is
a horrible way to measure complexity of software);
• complexity added by the technical challenge of getting
multiple languages to work together;
• a system that can be easily deployed and actually
A couple of possible topics for the project can be found on the
project ideas page. You do not have to choose from those
ideas and are free to choose any topic if it meets the
requirements specified below.
You project must be implemented using three different
languages. The focus of the project will be cross-language
implementations and communicating between languages. Some
restrictions on your language choices:
• At least one “systems” language (like C, C++, Go, Rust).
Julia, Perl, PHP, Python, R, Tcl).
• C and C++ count as one language.
• Only programming languages count toward your
language count (e.g. not SQL, HTML, CSS, etc).
• Languages should be reasonably appropriate to the
work done with them.
It is expected that you write some code in each of the three
languages, but not that you write an equal amount in each
language. It is reasonable to have one language that is used fairly
little (possibly just a little code to connect a library from that
language), and possibly another that is a relatively minor part of
You must use two different ways to communicate between
languages your languages. These might include:
• A foreign function interface where you can somehow
call a function from one language in another. If you search
for “call language1 function from language2”, you'll
probably find something (if it exists). See also SWIG which
helps call C/C++ from many languages.
• A message queue such as RabbitMQ or ZeroMQ. The
RabbitMQ tutorials give good RPC (remote procedure call)
examples in many languages: you can use one language as
the client and the other as the server.
• Create an RPC (XML-RPC or REST) server in one
language and make a request to it from another. You can
probably find an XML-RPC or REST library for either
language and write relatively little code to connect them to
your function/function call.
• A compiler toolchain that will compile both languages
and let you call one from the other, like the GraalVM polyglot
features or the various languages that compile to the JVM.
• Run the other language's code as an executable (exec
and friends, or often a “system” function in many languages)
and capture its output (stdout) into a string. Or have it write
a temporary file and read it from the other program.
Option 1: A Virtual Machine + Chef
We have provided you with a template for the project using a VM
that contains (mostly commented-out) setup for running code in
many languages in a virtual machine. You can modify the setup
recipe (cookbooks/polyglot/recipes/default.rb) to
install whatever tools you need so your system can run.
By the time you're done, starting the VM (with vagrant up)
should get your system into a runnable state. You may have a few
components that need to be started by hand (like an RPC server).
That is fine, but only one or two, and make sure they are clearly
documented in your project summary (described below).
See the Project VM Deployment page for more information on
working with the virtual machine and Chef recipes.
Option 2: Docker Compose + Containers
We have provided you with a template for the project using
Docker containers that contains (mostly commented-out) setup
for running code in many languages in separate containers. You
can modify the setup recipe (docker-compose.yml and the
various *.Dockerfile files) to start whatever containers you
need so your system can run.
By the time you're done, starting the containers (with dockercompose up) should get your system into a running state. You
may have a few components that need to be accessed by hand (like
running an interactive program in a container). That is fine, but
only one or two, and make sure they are clearly documented in
your project summary (described below).
Note that with Docker, you are limiting your cross-language
communication methods somewhat. It will be much harder to do
a FFI-based call or to execute a program compiled from another
language, because it will involve setting up tools for different
languages in one container (which isn't usually done, and won't be
done in base Dockerfiles you'll find).
See the Project Docker Deployment page for more information on
working with a Docker Compose setup.
In your project repository, include a file cmpt383.txt or
cmpt383.md and briefly summarize:
• What is the overall goal of the project (i.e. what does it
do, or what problem is it solving)?
• Which languages did you use, and what parts of the
system are implemented in each?
• What methods did you use to communicate between
• Exactly what steps should be taken to get the project
working, after getting your code? [This should start with
vagrant up or docker-compose up and can include one
or two commands to start components after that.]
• What features should we be looking for when marking
The purpose of this is not to make you write an essay, just to guide
the marking so we don't miss anything important. (There will be
many projects, and the TAs are human.)
The marking scheme will include marks for: [These may change,
but will give an idea of what we're looking for.]
• Problem: Is the problem you are solving interesting and
appropriate to a polyglot system?
• Languages: Three appropriate languages have been
used meeting the requirements of the project.
• Cross-Language Communication: Two different
methods to communicate between languages have been used
• Difficulty: The project includes features that required
non-trivial implementations or techniques.
• Extras: The project includes interesting features, or
uses techniques that go beyond the minimum requirements.