Original Post Date: 08.17.2018 by Bob Calco
This post is to provide a brief, and somewhat overdue, pre-release update on the status of Apex Athena & friends.
We know many people (Pax Compiler customers in particular) have been waiting, more or less patiently, for Apex Athena, and our dates have clearly slipped a bit… again, so we felt it was important to check in with some new insights into what we’ve been up to.
More importantly, we want to explain why it will be worth the wait, and how much more of a wait you can reasonably expect at this point.
Two words: Get ready!
The Lofty View from Mons Olympos
As we previously disclosed, we have been working hard to bundle an initial “Community Edition” of our core products. Here’s the 30,000 ft. explanation.
Our internal code name for this bundle is Apex Olympos, and the Community Edition will be free and contain (among other goodies) the following components:
- agora.exe – Our license management utility.
- perseus.exe – Our project and package management utility.
- athena.exe – The Apex Athena static, imperative language runtime and compiler as a standalone scripting engine.
On the edge of maybe being included in the initial release, but probably not:
- muse.exe – The Apex Muse dynamic, functional langauge runtime and compiler as a standalone scripting engine.
In future releases we also plan to deliver:
- zeus.exe – The Apex Zeus WASM runtime and compiler as a standalone scripting engine.
- odyssey.exe – A new kind of browser with special support for FRP-style UX that is uniquely suited to the security needs of distributed enterprises.
The Apex Olympos bundle will provide free versions of all of these utilities, and constitute a complete toolchain for rapid development of distributed microservices in the service of legacy modernization and the data interoperability and reconciliation mission of our Apex Unify! stack.
That’s nice, but what are these mythological beasties, exactly? you ask
Let’s discuss each of these applications in a bit more detail, shall we?
Apex Agora (agora.exe)
Apex Agora is our command-line license management utilty. It’s a command line application because all of the tools in the stack (with the exception of Odyssey) also have to run on headless Linux servers, in addition to Windows and Mac OS X.
Technically, the fully realized Apex Agora will be distributed and include our online customer web portal and e-commerce backend as well, but the command line utilty will be done before the portal, so in the interest of generating community buzz, we’ll be releasing it sooner.
The main function of Agora in the free Community Edition will simply be to unlock features of the free functionality constrained by the 30 day trial period. We want folks who “get” what the tools are about to help us build a development community around the vision, and to discourage non-committal use of these technologies.
So: Yes, we insist on registering even the free edition, so we can provide good community support. You’ll really appreciate this once the web portal is complete.
Longer term we see it also as a means to distrubute partner products built atop the core components using our Professional Edition (see below). We’ll be discussing this in future blog posts when that becomes more relevant. Stay tuned.
Apex Perseus (perseus.exe)
Apex Perseus started off its secret life as a humble code library chock full of bleeding edge awesome, but has morphed in the making into an eminently practical package and project management utility for Athena, Muse and eventually Zeus.
perseus is to
athena et al. what
npm is to Node.js,
mix is to Elixir,
gem is to Ruby,
lein is to Clojure, and so on.
Initially, Perseus will focus on code-generation templates, local script tasks and custom commands, but as the toolchain rapidly matures, it will include being able to share code through public repositories and open source Athena, Muse and Zeus projects on Github, Bitbucket, etc. We won’t be holding the initial release up over that, but know that it’s coming soon!
perseus will still contain oodles of awesome but much of that awesomeness will be surfaced directly via novel features of the varous languages supported by each runtime in a more or less uniform way, rather than as a native library. More on that shortly… keep reading. 🙂
Apex Athena (athena.exe, apexathena.dll)
Apex Athena is the evolutionary successor to the PAX compiler, but the concept of extensibility it supports is considerably expanded and in fact arguably the converse of PAX’s. The focus isn’t so much on extending a particular EXE, but on distributing a system created by modernizing a single EXE. In other words, the focus is on legacy application modernization and rapid development of enterprise web applications and micro-services, not merely on application automation or customization.
In the long range, we expect the popular languages supported by Athena et al. to bring developers in the Embarcadero stack into better alignment with developers on other stacks, and to attract new developers to a new Embarcadero-powered toolchain that is savvy with respect to modern “agile” development.
There are, it turns out, many ways to RAD, and we’re hoping Athena creates new opportunities for old-time Pascalers to join a club previously restricted to developers working on script-based runtimes like Node, Python, Ruby etc.
Put another way: The old PAX compiler’s main goal was to support extensibility of Delphi and C++ Builder GUI applications via in-process scripting. Athena’s concept of extensibility is more in line with current industry trends toward distributed programming and rapid development of micro-services powered by scripting runtimes.
While the Professional Edition of Athena will support embedding of the runtime in Delphi and C++ Builder applications of all kinds, it will do so very differently.
PAX was marketed as traditional component like any other in the Delphi stack, and was available with source and embeddable without restriction. This was great for PAX customers, but it made it impossible to prevent software piracy, which was a huge problem for PAX’s original author, Alexander Baranovsky, before we joined forces to reinvent it from the ground up.
By contrast, Athena in the Professional Edition will be embeddable according to an OEM license via a DLL (
apexathena.dll), with a C-style interface that permits any application to embed and extend it, and without regard to the native compiler or native compiler version.
But unlike PAX, it will also allow you to create complete web applications and micro-services of all kinds in elegant, extensible flavors of Pascal, Basic and C/C# that are quite powerful and uniquely suited to tackling the most difficult challenges of legacy modernization and data interoperability.
Which (not coincidentally) is why we’ll be embedding them in Apex Unify! as well. 🙂
Apex Muse (muse.exe, apexmuse.dll)
Muse represents a real innovation in “polyglot” virtual machine design, optimized for functional and dynamic languages, and our long-term goal for Muse is to combine the RAD benefits of Node.js with the distributed savvy of the BEAM VM and the power and speed of popular enterprise “nanny” runtimes like the JVM and CLR, but with a much smaller footprint.
The decision to choose Muse over Athena is mostly one of paradigm preference. Some people prefer imperative, statically typed languages. That’s OK, we have known and loved them all, and Athena fits that bill. Others prefer dynamic and functional languages, and that’s OK, too. Muse has them covered.
What we didn’t want to do, is paint our larger legacy modernization and enterprise data interoperabilty vision into a language corner or get in a turf war with other established “commodity” languages. So we did the only sensible thing under the circumstances: we made sure our language options included something for everythone.
So Muse is the ying to Athena’s yang, you might say. Both will allow you to pick from a virtual smorgasbord of languages in which to code, languages that are familiar yet in some respects new.
Whichever you choose, our motto is: “what is old is new again.” None of the languages supported by either runtime are stuck in the past. Quite the contrary, we have worked hard to bring innovative new features to them, and to make them extensible through meta-programming. More on that, later.
Apex Zeus (zeus.exe, apexzeus.dll)
Apex Zeus is an implementation of the up and coming Web Assembly language, or WASM, with a twist. Zeus aims to provide first-class language support for web programming, but with additional primitives to support the React.js style of programming.
Zeus is still in the early R&D phase of development, but it’s a high priority for us as we intend to use it in a new, specialized browser we call Apex Odyssey. Which brings us to…
Apex Odyssey (odyssey.exe)
Apex Odyssey is a new kind of browser client built specifically to support Zeus’ flavor of WASM, not “yet another browser” trying to compete with the Big Boys.
Odyssey aims to change the game primariy on mobile platforms, both in terms of performance (the primary driver for WASM) and in terms of usability and development support. Also, we intend to use Odyssey to create a new kind of UX that makes it much easier to “tell a story” from linked data, so in this sense it’s a specialized kind of UX that specifically supports our Unify! stack’s interoperability requirements, but we expect it to outgrow even our use cases if it is successful.
So, keep an eye out for Odyssey too, once we start releasing the Community Edition of the Apex Olympos bundle.
There are two really exciting innovations that have evolved in the course of our work bundling all these products.
Apex MetaTree (MTree) and MetaPath (MPath)
We’ve alluded to these before. Every language we release as part of Athena, Muse and eventually Zeus will feature MPath, a generic kind of XPath, based on MTree, an in-memory intermediate data structure for parsing data exchange formats like XML, JSON, YAML, EDN and countless others.
MPath will provide declarative syntax for querying MTree structures obtained from files and streams in almost any format you can imagine (or otherwise implement). Each language will allow you to extend the range of formats and manipulate such files and streams at a higher level of abstraction than mere format parsers.
This feature is a relatively recent development that is one of several reasons why we decided to let our initial release dates slip. It represents a way to add meta-programming to any Athena, Muse or Zeus language that is uniform and much more powerful than traditional C-style macros. If you are familiar with Lisp, Elixir or Rust macros, you have a better idea what we’re talking about.
Each language will allow you to define not just boilerplate code but even new constructs or features. We will be documenting some interesting examples with our initial release that we hope will get you excited, too.
The Bottom Line
OK, so this is where you get to ask, “When will the first release be ready?”
Glad you asked! Presently we are on track to get the initial Community Edition release done by mid-September. We are trying to get Muse included in that release, but may have to let that slip to get something in your hands. We are also weighing our desire to produce full documentation with the need to have some tires out for the Community to kick around sooner than later. Minimally we will strive to have several good tutorials and videos to help the Community wrap its mind around the vision and direction we’re taking these technologies.
So, keep checking in weekly for new blog posts as we near our initial release and determine its official date. We hope you see that we’re doing A LOT in the final home stretch to make this release special and deeply appreciate your continued patience. 🙂