Mmhm!  But not without confusing the hell out of everyone.  But who cares?  It&#x27;s fun!<p>I should start by clarifying that I&#x27;m not associated with Arc in any way.  Everything that I show should be thought of as an eager derivative, at best.  But for several months a colleague and I have been working on a derivative, which we&#x27;ve been calling laarc, which incorporates a few additions that make it a bit easier to write programs with.  Here&#x27;s a debugger similar to pdb.set_trace(), for example: <a href="http:&#x2F;&#x2F;i.imgur.com&#x2F;WWKa4kw.png" rel="nofollow">http:&#x2F;&#x2F;i.imgur.com&#x2F;WWKa4kw.png</a>  Except when it breaks, it shows a list of the values of all the local variables.  It&#x27;s really useful for stepping through macro expansions and understanding them, because there&#x27;s no longer any mystery when something breaks.  Laarc isn&#x27;t anywhere near ready yet, so it&#x27;s too early to know whether it&#x27;ll be useful generally, but the goal is to discover a way to make programming feel like a Tesla.<p>So, what are the benefits?  Well, here&#x27;s an example of a real-world program.  It&#x27;s all pimply and has a few hacks in it, but on the other hand, you can get a gist of how it might look:  <a href="https:&#x2F;&#x2F;github.com&#x2F;laarc&#x2F;monki&#x2F;blob&#x2F;master&#x2F;main.l" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;laarc&#x2F;monki&#x2F;blob&#x2F;master&#x2F;main.l</a><p>Note that this was made two days ago, and I&#x27;ve been working very fast.  So it&#x27;s pretty rough.  The program (monki) is essentially &quot;cp for git&quot;, and while it works, it&#x27;s not quite finished.  Monki is Yet Another alternative to git subtrees &#x2F; submodules; think of it like &quot;cp for git&quot;.  `monki clone voltagex&#x2F;foo foo` would create a clone of that repo into the subdir &quot;foo&quot;.  But that subdir can be within one of your existing repositories.<p>Here&#x27;s the scenario it&#x27;s useful for:  <a href="https:&#x2F;&#x2F;github.com&#x2F;tlbtlbtlb&#x2F;startuptools" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tlbtlbtlb&#x2F;startuptools</a><p><i>This requires an installation of tlbcore (<a href="https:&#x2F;&#x2F;github.com&#x2F;tlbtlbtlb&#x2F;tlbcore" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tlbtlbtlb&#x2F;tlbcore</a>) symlinked to this directory.</i><p>With monki, you&#x27;d just type `monki clone tlbtlbtlb&#x2F;tlbcore tlbcore` from within a clone of startuptools, and then you&#x27;d commit the result.  Monki takes care of pulling updates, so that whenever tlbcore changes, startuptools would also get the new stuff.  But you can `monki clone` a specific commit instead, if you want to pin to a &quot;known working&quot; version.<p>Anyway, that monki business was the result of trying to answer &quot;What&#x27;s a simple way where I can share code between all my repositories, pull in updates as I make them, and not have to worry too much?&quot;  And it was a good chance to exercise... Lumen!<p>Confused yet?  Ok, so Arc runs on Racket.  So did Laarc.  Then we had the good fortune to hear about Lumen:  <a href="https:&#x2F;&#x2F;github.com&#x2F;sctb&#x2F;lumen" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;sctb&#x2F;lumen</a><p>It&#x27;s a Lisp that compiles to either Javascript or Lua.  It literally exhibits the same behavior whether you&#x27;re running via luajit, node, or the browser.  Since LuaJIT&#x27;s FFI is awesome, that makes it incredibly easy to interface with existing C libraries using Lumen.  Just look how beautiful his postgres bindings are!  <a href="https:&#x2F;&#x2F;github.com&#x2F;sctb&#x2F;motor&#x2F;blob&#x2F;master&#x2F;pq.l" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;sctb&#x2F;motor&#x2F;blob&#x2F;master&#x2F;pq.l</a><p>That should catch anyone&#x27;s attention -- the FFI is literally &quot;copy paste some C declarations and you&#x27;re done.&quot;<p>I want to take that further.  In Lumen, it&#x27;s already possible to interface with node libraries or with lua libraries as-needed.  What if we extend it to work with python and go libs as easily as it works with C?  You might end up with a language that could do any given task very easily, because you&#x27;d simply use whatever library happens to be convenient regardless of whether it&#x27;s a C lib, a node package, or a Ruby gem.<p>So why have I been yakking about Lumen?  Because it seems like it offers a bunch of interesting benefits as a runtime.  I&#x27;ve been porting Laarc from Racket to it, slowly.  It&#x27;s extremely early, but here&#x27;s an early version of the compiler:  <a href="https:&#x2F;&#x2F;github.com&#x2F;laarc&#x2F;lumen-arc&#x2F;blob&#x2F;master&#x2F;arc.l" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;laarc&#x2F;lumen-arc&#x2F;blob&#x2F;master&#x2F;arc.l</a> ... It&#x27;s essentially ac.scm.  I wanted to make it match as closely as possible, both because ac.scm is a good answer to &quot;What&#x27;s a good way to write a lisp compiler in a lisp language?&quot; and because it&#x27;s dangerous to assume you can write from scratch something that a smart team has been thinking about and working on for 13 years.<p>Sooo... That&#x27;s a whirlwind tour of stuff that&#x27;s not even ready to tour.  On the plus side, the plan is to get an in-browser repl running soon (arc can already run in the browser, so it&#x27;s a matter of coaxing CodeMirror into submission).  There&#x27;s a server running Lumen over at <a href="http:&#x2F;&#x2F;arc.lol:9999" rel="nofollow">http:&#x2F;&#x2F;arc.lol:9999</a> which does absolutely nothing useful yet.  The plan is to get a REPL up and to dub it &quot;Arc dot tiefighter&quot; since &quot;lol&quot; obviously looks like a tie fighter.