When I first discovered Codea, I was (finally) enthralled. Here was a tool I could use to build cool games, but on the iPad itself, sitting on the couch every night while semi-watching TV. I worked feverishly for a very long time, trying to move past every hurdle, until finally I’ve realized I can just never do what I want to with Codea. I need to wait for Codea to mature, or something else to come out, or give in and buy a MacBook so I can use a proper development environment.
The death knell came a few months ago. I’d gotten frustrated with Codea and abandoned it for a few months (I honestly don’t know how long it had been). When I went back to it, all of my projects were broken. Codea must have undergone an update. In some cases, my files were out of order so they didn’t assemble properly. In two simpler projects, I fixed things by figuring out where the file order went south. Others are too complex to do that. Other problems resulted from changes in code behavior (such as orientationChanged no longer being called at the same times).
It basically trashed a lot of good work, and added one more laborious task to the job of finishing anything. One step forward, two steps back. That it led me to the realization that…
Coding real, useful things is just too difficult in Codea. It’s great for playing around, but.
Mind you, I am a professional software developer, and have been for 42 years. I know what I need to get a job done. I work on massively complex projects requiring many teams of developers. We use real tools, not toys, because we have to. I thought I wouldn’t need that for a simple game, but I do, and if I do, everyone does.
What’s wrong, and how can Codea get closer?
-
Project/file management; anything of any value is going to have a LOT of source files. The current system of tabs (which, because of Lua, need to be arranged in the right order) is beyond useless when you get a lot of files, and artificially breaking everything into project dependencies just to get a “1 level folder structure” isn’t reasonable. Codea needs hierarchical folders for logically structuring masses of files. It also needs some sort of compile priority method other than the order of the files in the project (ideas on how in bullet point two). This is an absolute requirement to make Codea relevant. I simple can’t work on my projects that have over 100 files (and growing) without this.
-
Too many basic tasks need to be coded from scratch. The biggest one here is basic UI support. I spent ages writing an editor to let a user scroll, enter and edit text (the user name in an app or game, a name for saving an app file, a description to go with a saved object). Same with a basic layout scheme, ways of swiping between pages, enabling/disabling/highlighting buttons, etc. This kind of UI stuff should be available out of the box; it’s 2019. I don’t need to spend valuable cycles writing code that handles low level tasks like a basic text editing UI. Codea needs to put more effort into providing the basics (UI widgets) than using every new library like AR and face stuff in a minimal way. No one can write the latest FaceApp or AR game if you can’t even get through basic app management because the UI takes weeks to write. [One of my best now-broken projects was a library I was hoping to release that does much of this using a “CSS” stylesheet-like approach, but it’s way too much work to get it working again, let alone finish it.]
-
Lua sucks; there’s a way to get totally around this without abandoning Lua, which obviously is the core of Codea, but the reality is that while Lua is a cute scripting language, it contains just enough unstructured nonsense to make large, more complex projects too unwieldy. To be useful, the language doesn’t necessarily need to change, but it at least needs better support from Codea as a platform, to make up for the language’s shortfalls. Everything in my wish list here can be solved with various annotations, which can be embedded in the code using comments (just pick a syntax, like lines/comment-blocks begin with --@ to start an annotation).
A) Use annotations for something like “javadoc”; Specifically, a way to describe what a class, field or method does, and what parameters are expected, and let this info pop up as you edit code. This is absolutely crucial… not just for provided functions, but for my own classes, methods and fields. Six months from now I’m not going to remember that my self:addButton() method requires a title, x, y, w, h, and a handler, in that order, and that the handler is optional (yes, yes, I can use a {} parameter map, but even for that I have to remember the exact parameter names, etc.). I know this can be hard, because without type definitions, the interpreter needs to figure out what sort of object a variable will contain in order to provide the pop up. At a minimum, it can work for self:, or by suggesting methods by method name alone within that file. Or just do a simple method name match, so if a user is entering variable:addComponent, then list anything like UIComponent:addComponent or UIContainer:addComponent or MyStuff:addComponent to choose from), or…
B) Fix a ghastly flaw in Lua (and Javascript, and all other scripting languages) by using annotations to allow for optional type definitions, even if they are not enforced by the interpreter. Just documenting how the programmer should use a variable is at least a step, and it would enable a more intelligent implementation of 3A above. You’ll notice Javascript is giving way to Typescript and other languages that do allow for at least optional typing. If you wanted to enforce it, you could encumber the code produced by the interpreter with calls that perform assertions before every right-hand variable reference, and/or after every assignment; this might be a lot of work, however. But at least add some pop up highlights to remind the programmer what he should be doing with a variable as the code is edited.
C) Better object oriented support. Lua’s complex, cutesie class system that exists on top of the language isn’t horrible, but… it’s horrible. That’s where Javascript dies (with it’s own silly prototyping approach), and again, where things like TypeScript are arising. OOP is supposed to make architecture, design and coding easier, not create one more gotcha-riddled minefield and layer of knowledge and effort the programmer needs to juggle. At a minimum, design and provide a class system that makes it easy to do all of the inheritance management necessary, including equivalents of Java’s “instanceof” operator (yes, yes, I wrote that into the code, which is a few more hours wasted just making things useable). If annotations help this (for instance, by providing a way of documenting effective polymorphism or Java-like interfaces), then great.
D) To fix a problem mentioned previously (file compile sequence), use an annotation to declare dependencies, and use this to determine the proper compilation order for files. At a minimum, if class A is descended from B, compile B first, right? But things can get more complicated than that, like fields that create an instance of A, or use global functions defined in C, so a simple annotation at the beginning of a file to either declare “includes/imports” (that’s what other languages do) or at least a compilation priority (do all 1’s first, 2’s next, etc) would solve this.
- Change the entire product name! It is almost impossible to google “codea”, because google keeps asking if I meant “code”, so finding help on particular problem is by itself a frustrating game (unless I remember to double-quote codea in the search). Codea is just too edge/niche to get away with a name that is so close to a simple word. Just be less cute and call it CodeLua, or PadCode, or something. Anything that lets a google search work.
Sorry for the rant; I know you guys have worked hard, and you have done something really cool, but for now, it exists almost solely to let people play with coding until they get either bored, or frustrated enough to do what I’ll do, which is to switch to XCode, and maybe Cordova (or a non-Lua library/environment, if I can find one). Don’t give up, but I think you need to reprioritize you efforts with the things that real developers need to create real, useful apps.