{"slug": "a-first-peek-at-myth", "title": "A First Peek at Myth", "summary": "RemObjects has unveiled Myth, an experimental programming language frontend for its Elements compiler that was designed by AI for AI, built around optimizing for correctness, explicit semantics and machine-verifiable intent rather than human-oriented conveniences. RemObjects said Myth is still a work in progress and emerged from asking whether the company would make the same language design decisions knowing an AI would be the primary author and likely primary reader of the code. The company argues the experiment points toward a future where source code becomes an implementation detail and developers interact with systems through requirements, architecture and behavior review rather than reading code.", "body_md": "A programming language designed by AI, for AI\n\nFor most of the history of software development, programming languages have been designed with one fundamental assumption: a human being will write the code, and another human being will eventually need to read it. This assumption has influenced almost every aspect of language design, from syntax and naming conventions to abstraction mechanisms, type systems, and the trade-offs we make between expressiveness, verbosity, and safety.\n\nWe value concise syntax because typing takes time. We value familiar constructs because learning a new language is expensive. We introduce abstractions to help developers manage complexity, and we tolerate a surprising amount of implicit behavior because an experienced programmer can usually figure out what is going on from context. Over the decades, we have developed a fairly sophisticated understanding of what makes a programming language pleasant and productive for humans to use.\n\n*But what happens when humans are no longer the primary consumers of source code?*\n\nThis is, of course, not an entirely hypothetical question anymore. AI coding assistants have progressed from sophisticated autocomplete systems to agents capable of navigating substantial codebases, implementing features, running tests, investigating failures, and iterating on their own work. Their capabilities remain imperfect, but the direction is clear: increasingly, the human developer’s role is shifting from writing individual statements toward specifying requirements, making architectural decisions, and evaluating the resulting behavior.\n\nAt RemObjects, we’ve been exploring what this shift means for our development tools, particularly our [Elements](https://www.remobjects.com/elements?ref=blogs.remobjects.com) compiler and the AI capabilities we’re building into our IDEs. One question kept coming up: if we were designing a programming language today, knowing that its primary author and quite possibly its primary reader would be an AI, would we make the same design decisions?\n\nWe decided to explore that question by doing something rather unusual: instead of designing another programming language ourselves, we asked AI to help design a language for itself.\n\nThe result is **Myth**, a new language frontend for the RemObjects [Elements](https://www.remobjects.com/elements?ref=blogs.remobjects.com) compiler, developed around a simple premise: a programming language intended primarily for AI should optimize for correctness, explicit semantics, and machine-verifiable intent rather than the traditional conveniences of human-written code.\n\nMyth is still an experiment, and very much a work in progress. But it has already led us toward some interesting conclusions about what programming languages might look like when we stop assuming that their source code is primarily a human interface.\n\n## **Source Code as an Implementation Detail**\n\nOne of the more provocative ideas behind Myth is that, in the long run, it may not particularly matter what the source code looks like. Not because readability is unimportant, but because the people responsible for a software system may increasingly interact with it through something other than its source code.\n\nHistorically, source code has served two rather different purposes. It is the formal description of a program that a compiler translates into executable behavior, but it is also the primary medium through which developers understand, discuss, and modify that behavior. These responsibilities have become so closely associated that we rarely distinguish between them. When we talk about maintainable software, we generally mean readable source code, because reading source code is how we maintain software.\n\nAI potentially allows us to separate those responsibilities.\n\nImagine working on a substantial application without routinely examining its implementation. You discuss requirements and architecture with an AI agent, review the contracts and behavior of individual components, inspect the results of tests, and investigate problems through a combination of structured information and natural-language interaction. The agent works with the source code, while the compiler verifies its correctness and the IDE presents the information relevant to your decisions.\n\nThe source code remains essential. It is still the authoritative representation of what the program does, and it must remain *deterministic*, reproducible, and debuggable. But it no longer needs to be the primary interface through which the human developer understands the system.\n\nThis is a significant departure from how we traditionally think about programming languages. Much of modern language design is concerned with finding the right balance between what humans find convenient to express and what compilers can efficiently understand. If source code becomes primarily a communication medium between AI agents and compilers, we can reconsider that balance.\n\nFor example, we might prefer a more verbose construct if it eliminates ambiguity. We might require declarations that a human programmer would consider redundant, if they provide useful information for automated reasoning. We might reject syntactic shortcuts that save a few keystrokes but complicate analysis. Conversely, we might eventually introduce representations that are considerably less pleasant for humans to read if they are demonstrably more effective for AI systems.\n\nThat last possibility is worth emphasizing, because Myth is not currently such a language. **Myth version 1 is deliberately human-readable.** Its syntax is relatively conventional, and anyone familiar with modern imperative or object-oriented languages should recognize much of its structure. This is partly pragmatic: we’re building a real compiler frontend, and humans still need to implement, debug, and evaluate it. It also reflects the fact that we don’t yet know what an optimal AI-oriented programming language would look like.\n\nThe important experiment is therefore not whether we can invent an exotic new syntax that looks like the Matrix screensaver. It is whether we can design a language whose *semantics* are better suited to AI-generated software. We can explore that question while retaining a familiar surface, and leave ourselves the freedom to reconsider the surface later.\n\n## **What Does an AI Want From a Programming Language?**\n\nWhen we started discussing Myth’s design, we deliberately avoided beginning with the usual language-design wishlist. We weren’t particularly interested in whether the language should resemble C#, Swift, Rust, or Oxygene, or which existing language features we could combine into something new. Instead, we asked a more fundamental question: what would make it easier for an AI to generate correct code, understand existing code, and modify that code without introducing unintended consequences?\n\nSome of the answers were familiar. Strong typing, explicit nullability, contracts, and controlled mutation are established ideas with considerable precedent in programming-language research. Others were more directly motivated by the way AI coding agents operate, particularly their dependence on contextual information and their tendency to make plausible but incorrect assumptions when that information is incomplete.\n\nA recurring theme was the distinction between information that is available to the compiler and information that an AI must infer.\n\nConsider a method that accepts an object and returns a result. Its signature might tell us the types involved, but it often tells us relatively little about its behavior. Does the method modify the object? Does it retain a reference to it? Can it throw an exception? Does it change some other state? Are there conditions under which calling it would be invalid? In conventional code, the answers may be distributed across the implementation, documentation, naming conventions, and assumptions shared by the original developers.\n\nA human programmer can often reconstruct this information by reading the code. An AI can attempt the same thing, but the result is not necessarily reliable (nor efficient), particularly when the relevant implementation spans multiple files or depends on external libraries. Worse, an agent modifying a program may correctly understand the immediate task while overlooking an implicit assumption elsewhere in the system.\n\nMyth attempts to move more of this information into the language itself, where it can be represented explicitly and checked by the compiler.\n\nThe objective is not simply to make code easier for an AI to read. It is to reduce the amount of reasoning that depends on guesswork, and to make the reasoning that remains more reliable.\n\nThere is an interesting distinction here between optimizing for token efficiency and optimizing for overall efficiency. One might assume that a language designed for AI should be extremely compact, minimizing the number of tokens required to represent a program. After all, language models operate on tokens, and tokens have computational and financial costs.\n\nBut shorter code is not necessarily easier to understand or generate correctly. A compact expression that relies on several implicit conversions, contextual name resolution, and subtle side effects may require considerably more reasoning than a longer but unambiguous equivalent. If the shorter version leads to an incorrect implementation, followed by compiler errors, additional tool calls, and another round of generation, its apparent efficiency quickly disappears.\n\nMyth therefore prioritizes semantic clarity over minimal source length. It is entirely possible that some of its constructs are more verbose than their equivalents in other languages. That is not automatically a disadvantage. The relevant measure is how efficiently an AI can arrive at a correct, maintainable implementation, not how few characters it takes to express one.\n\nOf course, this remains a hypothesis rather than an established result. We haven’t demonstrated that Myth makes AI coding agents measurably more effective than they are with existing languages. Establishing that will require experimentation and meaningful comparisons. But it gives us a concrete direction for the language’s design.\n\n## **Eliminating Unnecessary Ambiguity**\n\nOne consequence of this philosophy is that Myth deliberately avoids many of the alternative constructs and implicit conveniences that have accumulated in conventional programming languages.\n\nMost mature languages provide several ways to express essentially the same operation. They support different loop forms, alternative declaration styles, shorthand operators, implicit member access, and syntactic constructs inherited from earlier versions. These features often exist for perfectly good reasons, including familiarity, backward compatibility, and – very often – convenience.\n\nFor an AI, however, every equivalent alternative represents another choice during generation and another pattern to recognize during analysis. More importantly, seemingly minor differences between constructs can introduce subtle semantic distinctions.\n\nMyth favors a smaller, more consistent set of constructs. It has explicit naming conventions that distinguish keywords, local variables, members, and types. Access to instance members is explicit, avoiding ambiguity between local storage and object state. Assignment is a statement rather than an expression, and the language avoids several forms of syntactic shorthand that can obscure mutation or control flow.\n\nThese decisions are individually modest, but collectively they make the structure of a program more predictable.\n\nThe underlying principle is that a language should not require its author to repeatedly choose between several equally valid ways of expressing the same idea unless those alternatives provide meaningful semantic differences. For human programmers, stylistic flexibility can be desirable. For an AI-generated codebase, consistency may be considerably more valuable.\n\nThis also influences how Myth approaches name resolution and interoperability. Ambiguity is generally treated as something to resolve explicitly rather than something the compiler should settle through incidental rules. The goal is to make it difficult for an AI to accidentally refer to the wrong entity while producing code that still looks entirely reasonable.\n\nNone of this makes Myth immune to logical errors, of course. A perfectly unambiguous program can still implement the wrong algorithm. But eliminating unnecessary ambiguity reduces the number of ways in which the program can be misunderstood, both by the AI generating it and by subsequent agents modifying it.\n\n## **Making Uncertainty Explicit**\n\nOne of the most important ideas to emerge from Myth’s design is that a compiler should distinguish between what it knows, what it can prove, and what it merely assumes.\n\nThis sounds obvious, but conventional language systems frequently blur these distinctions, particularly when interacting with external code.\n\nNullability provides a useful example. Myth requires every explicitly written value type to declare whether it permits null. This is not an optional annotation or a convention applied only to reference types. Nullability is a mandatory part of the type system, including for primitive values, arrays, parameters, fields, and return types.\n\nThe compiler performs flow analysis to recognize when a nullable value has been checked and can safely be used as non-null. It also supports explicit runtime checks and assertions for cases where the required property cannot be established statically.\n\nThe interesting part comes when Myth interacts with code written in another language.\n\nAn external API may not provide reliable nullability information. Rather than silently treating the value as nullable or non-null, Myth represents that uncertainty internally. Depending on the compilation settings, an uncertain boundary can produce a diagnostic and a runtime check, or be rejected until the uncertainty is explicitly resolved.\n\nThis distinction between known-nullable, known-non-null, and unknown is important for AI-generated code. It prevents missing information from being silently interpreted as a guarantee.\n\nMyth also provides mechanisms for explicitly asserting facts that the compiler cannot prove. Such assertions can carry a reason explaining why the author believes the assumption is justified. The compiler does not mistake that explanation for proof, but it preserves the rationale as part of the source.\n\nFor an AI agent, this creates a useful separation between verified facts and assumptions inherited from earlier work. A future agent can recognize that a particular operation depends on an explicit claim rather than on a property established by static analysis.\n\nThe same philosophy extends beyond nullability. Myth’s effect and ownership systems distinguish verified contracts from declarations that depend on other declarations, and from behavior that remains uncertain because of external code or incomplete analysis.\n\nThis is not merely about producing better warnings. It is about preserving the epistemic status of information: whether something is established, promised, assumed, or unknown.\n\nThat may sound unusually philosophical for a programming language, but it addresses a very practical weakness of AI-generated software. Language models are remarkably capable of constructing plausible explanations for behavior they have not actually verified. A compiler that explicitly represents uncertainty provides a useful counterweight to that tendency.\n\n## **Understanding What Code Changes**\n\nA second major area of Myth’s design concerns side effects and mutation.\n\nIn many object-oriented languages, a method’s signature provides little information about which state it modifies. A method may change its receiver, mutate one or more parameters, update global state, or call other methods that perform such operations. Determining its actual effects can require substantial analysis.\n\nMyth introduces explicit mutation and effect contracts. Instance methods declare their mutation behavior, and methods can specify which storage locations they read or write. These contracts are checked against the operations performed by the implementation, including calls whose effects are known.\n\nThe benefit is not limited to preventing accidental mutations. Effect information also makes code more understandable at its boundaries. An AI examining a method can determine which state changes are permitted without having to reconstruct every detail of its implementation. When modifying that method, the agent has a concrete description of the effects it must preserve.\n\nThis becomes especially valuable as software grows. One of the recurring challenges for AI coding agents is making a local change without unintentionally affecting unrelated behavior. Explicit effect contracts give the compiler a way to detect some of those unintended consequences.\n\nMyth also supports semantic steps: named regions within a method that identify meaningful phases of an operation. These are not separate functions or arbitrary comments. They are language constructs that can carry their own read and write declarations, constrained by the surrounding method’s permissions.\n\nThe motivation is to preserve more of the conceptual structure of an implementation. A method may perform several logically distinct operations, such as validating input, preparing a transaction, applying a change, and recording its result. Traditional source code represents these phases through control flow, helper methods, and perhaps (🤞🏼) comments. Semantic steps provide a way to identify them explicitly without necessarily introducing additional callable abstractions.\n\nFor an AI, that structure can be useful when understanding or modifying an implementation. Instead of treating a method as an undifferentiated sequence of statements, an agent can recognize its intended phases and the state each phase is allowed to access or modify.\n\nThere are interesting possibilities for extending this idea. Semantic steps could eventually describe required operations, dependencies between phases, or valid state transitions, allowing the compiler to reason about workflows rather than merely individual statements. Such enforcement is not part of the current implementation, but it is a natural direction to investigate.\n\nThe broader idea is that source code should communicate not only *what* operations are performed, but also *how those operations relate to the intended behavior of the program*.\n\n## **Ownership as a Contract Between Components**\n\nOwnership is another area where Myth attempts to make implicit assumptions explicit.\n\nThe term is familiar from languages such as Rust, where ownership and borrowing are central to memory safety. Myth’s approach is related, but its immediate motivation is somewhat broader: making the rights and responsibilities associated with values visible to the compiler and to AI agents.\n\nWhen a method receives an object, what is it allowed to do with it? Can it retain the object after returning? Can it modify it? Does the caller retain access, or is that access transferred to the callee? If an object is returned, does the callee relinquish its own access?\n\nThese questions are often answered through conventions rather than language-enforced declarations.\n\nMyth introduces ownership modes that distinguish temporary borrowing, sharing without retention, retained access, logical copying, and ownership transfer. The compiler tracks these relationships where sufficient information is available, detecting operations such as using a value after surrendering access or allowing a borrowed value to escape into longer-lived storage.\n\nOwnership and mutation are deliberately separate concepts. Having access to an object does not necessarily imply permission to modify it, and permission to modify an object does not automatically imply permission to retain it indefinitely.\n\nThis distinction allows method contracts to communicate more precisely how components interact.\n\nIt also has implications beyond memory management. Explicit ownership relationships can help an AI reason about object lifetimes, data flow, and the consequences of transferring responsibility between components. Combined with effect contracts, they provide a richer description of what an operation is permitted to do.\n\nThe current implementation is intentionally conservative. It does not claim to provide a complete lifetime or aliasing analysis, and it does not automatically introduce copying, destruction, or a new runtime memory-management model. Some cases remain uncertain, particularly when interacting with external APIs.\n\nBut the information that can be established is valuable in its own right. The purpose is not to reproduce Rust’s ownership system inside another language. It is to make the semantics of access and retention explicit enough that an AI can reason about them more reliably.\n\n## **Programs Should Describe Their Own Correctness**\n\nAnother important aspect of Myth is its integration of design by contract.\n\nPreconditions, postconditions, and class invariants are established concepts in programming-language research, and Elements already has a history of supporting them. Myth builds on that infrastructure, making contracts an integral part of its approach to expressing program intent.\n\nA method can declare the conditions required for its correct execution and the properties it promises upon successful completion. A class can declare invariants that should hold at its public boundaries. These declarations are checked for validity by the compiler and can be enforced at runtime, depending on the project’s configuration.\n\nFor AI-generated code, contracts address a particularly interesting problem: the gradual loss of intent.\n\nWhen a human asks an AI to implement a feature, the original request often contains requirements that are not fully captured by the resulting code. The implementation may satisfy those requirements, but their rationale remains in the conversation rather than in the program itself.\n\nA subsequent AI agent modifying the code may not have access to that conversation. Even if it does, the relevant requirement may be buried among thousands of other messages. Contracts allow some of that intent to become a permanent, structured part of the implementation.\n\nA requirement that an account balance must never become negative, for example, can be expressed as an invariant rather than merely implemented through conditional logic. A requirement that an operation preserve a particular relationship between its input and output can be expressed as a postcondition.\n\nThe compiler cannot automatically prove every such contract, and Myth’s current implementation primarily provides runtime enforcement rather than comprehensive static verification. Nevertheless, making these obligations explicit gives both the compiler and future AI agents something concrete to work with.\n\nThis suggests a broader principle: **requirements should survive the conversation that produced the code.**\n\nFor AI-generated software, this may become one of the most important responsibilities of a programming language. The source should preserve not only the operations necessary\n\n# What's Next?\n\nMyth is currently in early development, but usable. [Let us know if you would like to join the beta](https://www.remobjects.com/portal/beta/myth?ref=blogs.remobjects.com).\n\nOf course, being part of the [Elements](https://www.remobjects.com/elements?ref=blogs.remobjects.com) family, Myth code can live next to existing code written in C#, Oxygene, Python, Java, Swift, Go, or VB. You can start letting AI – whether CodeBot, Codex, or Claude use it to add new code to your existing projects, without having to go \"all in\".\n\nBut the real benefit will, of course, come to fruition when entire new codebases are written *in* Myth.", "url": "https://wpnews.pro/news/a-first-peek-at-myth", "canonical_source": "https://blogs.remobjects.com/2026/10/28/a-first-peek-at-myth/", "published_at": "2026-10-28 15:29:30+00:00", "updated_at": "2026-10-28 15:42:43.656465+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-tools", "developer-tools", "ai-agents"], "entities": ["RemObjects", "Myth", "Elements"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/a-first-peek-at-myth", "markdown": "https://wpnews.pro/news/a-first-peek-at-myth.md", "text": "https://wpnews.pro/news/a-first-peek-at-myth.txt", "jsonld": "https://wpnews.pro/news/a-first-peek-at-myth.jsonld"}}