These are some great suggestions! We definitely are excited to try to eventually branch out and allow people to configure the actual layout of their interface through some sort of nesting approach like the one you provided. Great idea!
Thank you! I appreciate the support! We're focusing hard on covering applications, languages, and challenges that lack coverage from existing products like Jupyter Notebook.
Yes! That's actually one of the primary motivations behind why we made this "comment-based." The caveat of course is that we presently only support Python at the moment, but you can expect to see C++ and Java support rolled out in the next few weeks. This particularly excites me since these languages are heavily lacking these sorts of tools IMO.
To avoid duplication of input/output tags; it would be nice to have a bridge that coincides with existing documentation comment tools.
For example Scaladoc has @param, and @return.
Great suggestion! I am actively pushing to try to make small decisions like this to make it flow with one's current documentation format as much as possible. I will definitely add this to the to-do list.
Great question! This does not require any dependency whatsoever -- adding comments and running the tool is sufficient. This was important, as our core mission is to ensure that integrating Artemis into your code does not require you to bend your dependencies, executable code, or workflow around this tool.
Thank you for the compliment! How funny! The inspiration for this project actually came from my work in a lab during my undergraduate work. Being constantly emailed mega-scripts with no context wears down the soul, haha. You can see traces of its academic roots in some of our features (eg. LaTeX support for documentation).
Thank you for taking a look at it! Great question!
Funnily enough, we actually pursued this approach initially for the same reasoning you provided. I absolutely agree with your point regarding highlighting. However, we pivoted to using purely comments after several realizations:
1. Artemis can be used in contexts beyond simply decoration. For instance, if you want to create a documentation card whose sole purpose is to display some Markdown, LaTeX, or Multimedia, there isn't really something to decorate.
2. By making ourselves comment-based, it ensures that it won't throw off any IDEs or linters, and it ensures that these commands will have absolutely no impact on production code when ran without our command-line utility.
3. If you force the user to use a decorator, it restricts the user to only being able to create inputs or outputs for a particular variable right above that line of code. TLDR; it gives the user more freedom to organize their code
however they'd like.
4. It lets us allow users to use our special comments to output more than just simple variables. For instance, if a user wrote "@output table data=<<np.arange(5)>>", this would display a table of np.arange(5). However, if we forced users to use decorators, this would prevent functionality like this, which can often be useful.
5. Artemis will be language agnostic, so we wanted to pursue an approach that could be held relatively consistent across other languages.
Nonetheless, your point about highlighting is absolutely valid. We're actually looking to push out extensions for popular IDEs to correctly detect and syntax highlight our commands to try to remedy this concern.
Cool! Thanks for sharing. There's always complex nuances to problems like this, it's interesting to see what the design considerations were and why this approach was taken.
