Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Artemis (YC S22) – Use comments to give code an interactive interface
90 points by austinmccoy6251 3 months ago | hide | past | favorite | 30 comments
Hello Hacker News, we’re Austin, Manvir, and Kyle, the cofounders of Artemis Labs (https://artemisdevtool.com). We turn your in-line comments into a UI that can be used to visualize, test, document and share your code. This helps engineers and scientists quickly create quality scripts.

Artemis was born in a Caltech robotics lab where I saw firsthand how much time and effort it took to create a quality script. Engineers were spending hundreds of hours making slide decks, hybrid Markdown / LaTeX documents, and demo GUIs just to make their tools accessible and usable by others. As someone who has been on the learning end of things, it can be nearly impossible to decipher or use even the smallest scripts if they lack quality documentation and interactive interfaces. Although these methods worked they were an incredible time sink and documentation became stale quickly.

Artemis was devised as a solution to this problem. We wanted a tool that allows developers to create high-quality interfaces and documentation without forcing them to invest substantial time, alter their codebases or make significant changes to their workflows.

The way it works is simple: First add special comments to your codebase; Artemis uses these comments (called “anchors”) to automatically generate a GUI for your code. Then run your program using our command-line utility. Artemis launches in an offline browser window that displays your code on one side and your new interface on the other. To see how this looks, you can watch our demo video here: https://www.youtube.com/watch?v=IDL12DkS2Hc.

This interface scrolls vertically, so as your code runs new GUI elements appear one below another at the relevant time organized into “cards.” For example, if a program takes two numbers and adds them, your interface will first show input fields for the variables in one card. When you enter numbers and press “continue,” a new card showing the result will appear.

There are three types of anchors: inputs, outputs and documentation. Inputs let you change variables in your program via the interface, outputs represent the products of your program as graphs, text, etc. and documentation lets you create interface elements that explain what is happening as your program runs. Documentation can take the form of text, Markdown, LaTeX, syntax-highlighted code snippets, multimedia, and links, and more.

These anchors all follow the same format: you put them in a comment, beginning with “@,” followed by its type— “input,” “output” or “doc.” For “doc” anchors you just proceed to add whatever you would like to appear in the document card. For inputs and outputs, you need to specify which variable they act upon by typing “data=x,” with x being your variable.

We provide a suite of default anchors, such as text inputs, and outputs in the form of text, tables, and graphs—but we also let you create your own, using regular Python. Do you need to create a custom anchor to quickly display your statistical data using Seaborn? Do you want to automatically render advanced 3D plots in Matplotlib? Artemis makes this, and more, easy.

The reason we opted to have anchors work from comments is to avoid requiring you to alter your code or the way you work. You don’t have to toggle between different environments—you stay in your preferred IDE, bringing more functionality to it rather than requiring you to go somewhere else.

For example, we subsume the functionality of Jupyter as a visualization tool without requiring you to use a notebook. In our experience, notebooks are rather constraining relative to a full Python environment— they require you to restructure your code for the notebook, run your programs on an IPython kernel, and often import new third-party libraries or widgets. With Artemis you get the interactivity of a notebook, as well as the display of UI elements and documentation alongside code, but it also works with professional-grade codebases and tooling.

Artemis interfaces can be exported as an HTML file that runs offline. This is a key feature that makes us a portable, effective documentation/walkthrough tool. These interfaces are small enough to send via email and can even be embedded in web pages. When a third party opens your HTML file, they’ll see exactly what you see when you run your program with Artemis: an interface on the left and your code on the right.

We thought the most obvious applications of this approach would be for quickly building interactive computational tools and making test scaffolding for complex programs. But it turned out to also be really good for making code walkthroughs that can explain your program to coworkers or managers, or teach people how to use your program. You can see this in action here: https://www.youtube.com/watch?v=V4c3Q6lHFPo.

Engineers at Mayo Clinic use Artemis in this way, using our Markdown, LaTeX, and multi-media documentation capabilities coupled with custom anchor outputs to produce step-by-step walkthroughs for their internal tools.

Artemis is ready to go, and we offer a free trial on our website. Setup and installation only take a minute, but we’d also be delighted to answer your questions personally and/or give you a walkthrough—we like to meet our users!

Our current pricing model is $15/month for basic Artemis. There’s a pro version that allows you to create custom anchors (beyond inputs, outputs and doc), and export your interfaces as HTML files. We also do the “contact us” enterprise thing for larger teams.

We’ll be around in the comments below and are super interested in whatever you have to say!




This looks like a nice piece of work. This area and adjacent tooling areas are ripe for improvement.


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.


Interesting app.

I'm curious about your choice of using comments, was there an advantage to using this approach over something like decorators?

As it is currently, commments are often a bit weird to debug / view (grayed out) I'm sure there's some advantages to using them here, just thought I'd ask.


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.


Very impressive! I have a question and I was wondering if you have any thoughts. In Artemis as well as in Jupyter and in 3D-oriented tools like Unity, it's common to see this pattern for defining inputs:

In the code: x = 3 Elsewhere in the GUI: (User sets x to 5)

I understand that this pattern has become popular but to me it always struck me as dangerous. It's scary that in the code I can't trust that x = 3 really means x = 3. Especially if I'm skimming the code quickly and not paying attention to the surrounding comments, I might make incorrect assumptions about flow control (if the value is a bool), or other dangerous incorrect assumptions about what the code is doing.

Do you have any ideas for a safer pattern that could be used instead? Maybe something like one of these?

    x = 3 # !INPUT

    x = GUIINPUT() # !DEFAULT=3

    x = GUIINPUT(3)   or equivalently   x = GUIINPUT(default=3)
If you use the third option, GUIINPUT could be defined at the top of the file as something like this:

    def GUIINPUT(default):
      # pseudocode:
      if interpreter == "artemis":
        return artemis_magic(default)
      else:
        sys.stderr.write(f"Warning: Assumed input is {default}; this may not be correct, especially if you the user were not the author of the script!")
        return default


There's a lot of stuff we get for free in the typical gui toolkit when we say, make a window, put some widgets in it and draw it, like how a button might have a callback function and you pass the function into the constructor so when the button gets clicked the function gets called. Thanks to what goes on behind the scenes (mostly, now) we don't have to implement hit-testing the mouse xy with every rectangle bounds to get an id to index into the array of callbacks... This old gui toolkit made you do all that and more. Imagine if the entirety of your 'layout engine' was a helper function that told you how much width and height you had available. Every widget needed xy coords for top left / bottom right and man if that sounds annoying, you're right. The convention was to assume a certain minimum amount of space and hard-code everything, literally get out the calculator and graph paper to start laying out widgets, but of course there were various copy-pasted solutions people used to page through larger interfaces than what would fit in some tiny rectangle. Nothing much like what you would call 'dynamic'.

I tried to do something like this what you have but very rudimentary and instead of comments it was an attempt to make GUIs based off function signatures. A string was parsed containing brackets around names of functions to inspect, those functions' comments parsed for labels/tooltips etc, and for each argument to the function it just did basic duck typing to figure out what kind of widget to associate. A function without any arguments was just a button, a function that took a string and a number turned into a button a text field, and a number input, for example.

Anyway, this particular part I'm trying to get at here, the thing that I was kind of proud of for being a novel way to do dynamic layout, was really only the concept of doing alternating rows and columns based on modulo the nesting depth.

say you had 300x300 pixels to work with and you had defined some functions foo, bar, and baz somewhere, you could build a ui for them like

'[foo,bar,baz]'

to have a row of three buttons or instead if you wanted columns then

'[[foo,bar,baz]]'


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!


Very nice. I use a similar approach but at a much more basuc level, to create lab reports directly from python code using special comments, which are then parsed by a special bash script which generates an html lab report.

I've been using it exclusively for my own reports, but now that I see others think this kind of thing is useful, I might put it up on github or sth.

I loathe jupyter notebooks with a passion ... good to see people working on alternatives!


Can artemis be ran in vscode? although ipywidgets now supports vscode, they weren't made for it originally (https://github.com/microsoft/vscode-jupyter-ipywidgets). Keep an eye on RStudio Quarto w Shiny for R/Python


This is really cool. I am not sure if you know, you could probably be competing with internal tools platforms like retool et al. But I think markdown take is really cool than using low-code UI driven approach. I think It might be faster to build user interfaces with markdown than any other approach.

I hope you guys have success!


That’s so cool. I had built something similar (invasive C++ probing) in grad school using txt files as IO


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).


This is a game-changer. We can use this to offer an alternate GUI to our cli scripts.


Is the exported HTML runnable? Ie. does it come with a Python interpreter embedded?

Great idea and tool overall!


Is this language agnostic?


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.


Do applications wanting this need to add your project as a dependency or is adding comments and running a tool sufficient?


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.


That’s great! Would love to see ruby supported for my use case


It’s like the inverse of org-babel


Heh, I've also been working on an app called Artemis (https://getartemis.app) for the last few years, although not related to dev tooling. Guess naming a company after the Greek goddess of the moon is not very unique.


Not to mention NASA's Artemis -- looks like we both have an uphill SEO battle ahead of us!



You could have waited till Monday with this to co-launch with NASA :D

https://www.esa.int/Science_Exploration/Human_and_Robotic_Ex...


you can always change the name, best to do that early

With the moon program ramping up, the news / search will be dominated by space related content. The first launch is slated for Monday iirc


Cool preview, Satvik. Happy to help break it if you'd like a well-intentioned tester.


Your comment made me look, I agree it looks interesting.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: