A fast dynamic concurrent object oriented language for the JVM
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.



A fast dynamic concurrent object oriented language for the JVM

The language's design principles are as follows:

  • Object-oriented and functional programming aren't exclusive
  • Immutable and mutable state are both useful
  • Building concurrent programs should feel natural and be free of silent errors
  • Dynamic languages can be fast but optional static typing helps prevent bugs
  • Security is not optional and capabilities should be easy to restrict


  • Ruby: syntax, object model, uniform access, correspondence
  • Io/Fancy/Elixir: relationship between functions and OOP
  • Python: some syntax, callables
  • Erlang: actor-based concurrency, fault tolerance, hot code swapping
  • Java: the JVM
  • Smalltalk: the granddaddy of all of this stuff


The JVM is a remarkable language platform, and several languages besides Java have sprung up and blossomed on top of it. The notable JVM languages are:

  • Scala: a multiparadigm statically typed object oriented language (with type inference)
  • Clojure: a fast Lisp for the JVM with richer literal syntax than most Lisps and neat concurrency features
  • Groovy: an relatively uninspired dynamic language for the JVM
  • JRuby: the Ruby language, ported to the JVM

Java 7 has introduced the InvokeDynamic instruction, which allows programming languages to wire up their own dispatch logic in such a way that it runs Java speed after the first time it has been dispatched. With InvokeDynamic, all of the power of the JVM's HotSpot compiler can be utilized to optimize any language. This is a game-changing feature for the JVM, and one which begs for the creation of a new JVM-centric language to properly utilize it.

If designed correctly, a dynamic language built with InDy can be as fast as Java, even at numerical computing. Even in a system where everything-is-an-object, integer and floating point unboxing is possible. In a properly designed programming language built around InDy, HotSpot should be able to inline across methods that perform primitive math, unboxing primitive values along the way and optimizing the code the same way it would optimize Java.

You can have your cake and eat it too: with InDy it's possible for a dynamic language with Ruby-like method signatures including a rich set of features for default arguments, keyword arguments, and capturing arguments as arrays or passing arrays as arguments to be Java speed and inlineable by HotSpot.


Paradox is a hypothetical vaporware project


Programming languages are like startup companies: most are doomed to failure, and when a programming language fails, it's typically a lot of thankless work (take it from the would-be creator of an unsuccessful language). Anyone who would undertake the creation of a programming language should be well versed in the gestalt of running an open source project, and worse, you have to build all your own tooling. A fledgling programming language requires:

  • Testing and building your language's first test framework (test inception!)
  • Building tools to document the core APIs of your language
  • Being able to effectively market your project to interested users

Can I accomplish all these things, or recruit enough early adopters to help make it happen? I don't know.

I have tried to create a new programming language, and failed. This alone might raise doubts in anyone evaluating this project. Or you might just look at it as experience in attempting this kind of project.



  • Integers: 42
  • Decimals: 42.0 (because most people don't understand floats)
  • Floats: 42.0f
  • Bignums: 18446744073709551616b


Paradox features literal syntax for both mutable and immutable collection types.

The default literal syntax produces immutable versions of aggregates, which are automatically typechecked by the compiler and ensured to be immutable-all-the-way-down. To produce a mutable aggregate instead of an immutable one, use the "+" operator when defining the collection.

The "+" operator is not intended to indicate that mutable state is in any way superior to immutable state, merely that the resulting types will have additional capabilities, namely mutation.

Immutable aggregates should provide traditional value type behavior in all cases, including referential transparency.

Mutable aggregates attempt to mimic compare-by-value by default, but do not provide referential transparency.

  • Arrays:
    • mutable: +[a,b,c]
    • immutable: [a,b,c]
  • Maps:
    • mutable: +{a:1,b:2,c:3}
    • immutable: {a:1,b:2,c:3}
  • Lists:
    • mutable: +(a,b,c)
    • immutable: (a,b,c)