hi everyone, author here. i am glad this project is still starting conversations six years after it came out! if youre interested in a longer read on the subject of the cultural assumptions of programming and computing systems i wrote an essay for Technology as Cultural Practice last year: http://ojs.decolonising.digital/index.php/decolonising_digit...
To your first point, Mooi is planning on using Clojure as a scripting language. Clojure compiles to CLR bytecode, and is in theory as fast as C# is as a language. Using the idiomatic persistent data structures has an overhead, of course, but Clojure allows you to be flexible with how and when you do that. I wouldn't say Lua or JavaScript are "reasonably faster" than Clojure is on the CLR.
To your second point, we're aware that there's room to optimize and we're actively working on it. We profile and optimize our code paths regularly, and the results are often surprising. If there's "obvious" stuff left in there it's because we're tackling bigger fish than e.g. a foreach loop. None of these are show stoppers, in practice, but this is part of why we're in pre-alpha.
I am aware of the compilation into CLR bytecode and I've been a .NET user since the beginning, though I don't work with it much these days. The fact that it someone is using Clojure though doesn't mean it will translate always into the most efficient byte code. On the JVM, this is a problem sometimes forcing you to either write your Clojure differently to produce something more efficient, or requiring you to write a bit in Java and call it from Clojure (contrary to amateur practices w/Unity, people do need to share code that is not just abstracted by the engine such as some behavior). The same paradigm would be true of having to drop to C# and then call it from Clojure CLR. The problem here just becomes you get further from what is good about Clojure and instead write a version of Clojure that is closer to C# or something else.
Regarding speed, I think you misunderstood part of my comment. I simply mean you pick something decently fast when picking a scripting language with regard to the host language. Obviously Clojure is decently fast on the CLR in theory, but in practice may be another matter given the properties of a game which are far different than general use computing.
As for the speed with regard to Clojure, I've covered much of the general stuff in other comments, but I was in part writing to the point of using it independent of Arcadia in a scripting context. For this, I am contending there aren't many advantages to using Clojure over other approaches as a general scripting language for most engines, ex: Unreal, CryEngine, in-house, etc. Unity obviously benefits because of the CLR, but there are still issues with both Clojure CLR and using something that is yet another abstraction on top of Unity as others have pointed out. This makes life hard for newer or less-skilled game devs especially which it tends to sound like the original post authors are in general. More than anything, unless you have unlimited time, do you want to get a game done or do you want to help fix a new runtime?
Additionally, I am not comparing Lua to Clojure for the CLR specifically, rather stating that most of the time you add a scripting language to an engine in general it depends to be languages with certain properties. The reasons have little to do with Clojure as a language and more to do with scripting specific needs, which Unity itself doesn't really handle very well depending on how you define "scripting." That is any decent scripting engine must address some of the following below in a game, or it is not a scripting engine but rather just part of the main compilation target.
- Support hot code reloading, ex: from file system, user scripts, in game commands, etc.
- Compile/JIT reasonably fast if required
- Provide bi-directional calling semantics
- Easily integrate with the primary host language of the engine
- Decent experience for script authors
- Easy tool integrations, including with 3rd party middleware
- Minimize garbage if generating any, and make collection predictable if possible
- Not require the game code core to be recompiled in tandem (a primary motivator for using one from C/C++)
Clojure on the CLR certainly does some, but I'd argue not all well to be a huge benefit over C# in terms of productivity, performance, user experience, or user-facing scripting features. Of course there are some cool things due to Clojure's reader and macros, REPL, and so on, but the point is more the aggregate benefits. The reason people use Lua, Squirrel, AngelScript, and many others is not that they are the best, or fastest languages, but are generally good in all those points with regard to the primary language of the engine they are attached. Personally, I'd rather use other languages like Clojure, but there are tons of drawbacks that don't bite you until you are working on a real project, many that I listed elsewhere in this thread.
As I noted (and you repeated), I assume the code is alpha and there are still items to address. Nonetheless, most of these things are obvious and easy up-front, and many well-known in the Unity community, so I'm not 100% buying everything is a "later," just some of it. While in a normal game I wouldn't expect various optimizations or micro-optimizations, in an engine you definitely do. Even when working in C or C++, all the engines I've worked on we used our own allocators, minimized general allocations, added indexing tricks, branch prediction and inlining tricks, array packing, alignment tricks, and so on from the start, because that's the job of the engine and the end-user (game dev) cannot optimize away all of those things if the engine is the issue. Of course Unity doesn't do all these things well and things like Clojure layers are a lot further from the actual engine, but I'd argue that it means that everything needs to strive for equal parity or better performance when and if possible. Those are things you design around mostly from the start, the other optimizations that I think you are referring to happen later. I'm simply contending I see a mix of both.
Finally, following up again on the use of Clojure, as I've said in this thread, I'm a big proponent of Clojure. That aside, the CLR vs JVM implementations do not have parity because of lack of resources more than anything else. This automatically puts a lot more work in the pipeline and ultimately on the game developer, at least until things mature more. This isn't about using something like Arcadia at all, but rather using it right now given the original constraints and resources the article author mentions or implies.
Exactly! I'm one of the core devs, and we all see Arcadia as an experiment in what game development could be. Some people want to expend effort mastering the tools of the day, and that's totally cool, but we're somewhat more motivated to spend our time trying new things. Members of the community have already pushed out a number of games, and their experiences have guided made the tool better and better.
Fair, but there's an important difference between a tool where live coding is technically possible and a tool designed to support it. Clojure is built from the ground up for the REPL experience and supports e.g. redefining functions seamlessly. The fact that it's functional helps a lot, too, since that means that the order things are defined or executed in matters less.
Python is an example of an OO + imperative language with a built in REPL.
My point was that it has to do with if there's an interpreter for the language, and if the interpreter works with your toolchain.
And that with the advent of JIT, that distinction becomes increasingly blurry, because the techniques to compile and link small blocks of code can be used by languages without an interpreter, per se.
Arcadia dev here! We're always actively working on Arcadia, and are closing in on our next release that brings with it a package manager and all kinds of other goodness. Keep an eye on the repo or jump in the gitter for updates.
Lisp in VR is super exciting! We're following Carmack's work closely.
IL2CPP has been on our radar for a while. We haven't gotten any real access to Unity 5 yet, so we can't say what the compatibility will be like for sure.
But since IL2CPP acts on the CLR bytecode, and Arcadia emits valid CLR bytecode, in theory there shouldn't be a problem. Time will tell!
Good question, reflective code emission won't work on some platforms. We think this will only be an issue for eval. In the future we'll probably have options for disabling eval while retaining macros for AOT.
IL2CPP seeks to provide similar functionality as AOT platforms supported by mono today (e.g. iOS). If something works on iOS, it has a very good chance of running on an IL2CPP supported platform.
Totally! Arcadia is based on the Clojure-CLR port (an official project) maintained by David Miller for five years or so. It supports Mono.
We had to fork the compiler to introduce a small number of changes to make Arcadia work in Unity, though. Unity ships a very old version of Mono with their own changes, so stock Clojure-CLR would not work.
That would be amazing! Can you invoke command line scripts from LT? If so you could just use our included REPL client implemented in Ruby. Otherwise you'd have to port it to ClojureScript, but the client is designed to be simple enough to make that easy to do.
Yep, though it's not as easy as it could be yet. The best way currently is to write your own command leveraging our spawning APIs (a thin wrapper around node's child_process module with some extra cljs sugar).
