Why I’m Abandoning Codea

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?

  1. 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.

  2. 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.]

  3. 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.

  1. 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.

Some edits: when I said “ideas on how in bullet point two”, I meant “bullet point three”. And my B ) got changed to a cool smiley face (I should have used Preview before posting, sigh). And “fields that create an instance of” should be “files that create an instance of”.

I also forgot another basic from point #2: a drawing library. It’s silly that I need to write my own function to fake my way into buttons with rounded corners, because there’s no simple arc method (let alone a rounded rectangle function). There are just a handful of basic drawing functions anyone expects to be there, and they aren’t. This doesn’t need to be too elaborate, but it needs more than exists today; just think of the obvious things we want to do, like draw buttons with rounded corners, and make sure the core functions exist to do that.

@blacatena You probably feel a lot better now that you got all of that off your chest. You’ve been with this forum for about a year and a half. I too sit on the couch watching TV as I code. I’ve been doing that for over 7 years and I’m not tired of it. I don’t write anything large anymore because I’m done with that. I did that for 35 years and now I find Codea an enjoyable pastime. I don’t think Codea is meant to be a full blown development package. It has to work within the Apple framework which creates a lot of restrictions. You’re not going to buy a compact car to run in the Indy 500. I’m sure there’s a lot of development packages out there that will let you do what you want, but I doubt you’ll find them on an iPad or iPhone. I also don’t mind that I have to write everything from scratch. Sure, I can include routines that were written by someone else, but I like my own routines and I don’t want to rely on someone else’s code. I guess it comes down to what you expect. You want a full blown development package, I just want something fun. I’m sure there are a lot of people here that find something in between those ranges. I’m sure TLL is doing whatever they can to improve Codea, but for the price of Codea compared to a PC development package, you can’t go wrong.

Codea is a prototype platform, so not designed for big projects. But you can easily do big projects with it, even if it’s probably more easy with others techs in particular for UI things. There is also community libraries like Soda for UI.

Because Codea is for prototyping, all tabs are loaded in the same env. If you didn’t want to be dependent of tab order, just use the require function and define your package.path. Sure, it’s difficult to work with 100 of files. And I will love to have a hierarchical structure like in others developments tools. As far as I remember, the last time I did a very big project, I have coded on my PC and only sync files and run on my ipad.

Personaly, I prefer type inferring like in ocaml without annotations. I don’t really like Typescript. Writing types is not really useful if the flow is sufficient. But I understand some peoples prefer typing it and being in a more guided way of coding.

Lua, like javascript, is free of paradigm. If you dislike the class function, you can code it yourself and doing something that is more like you want. But in general, I think that composition is better than inheritance.

Personaly, I like Lua. It’s lightweight and simple. I just need sometimes to remember that index begins at 1. x)

I also love the name of the app. For discoverability, it’s just a matter of search engine optimization. There is also a search bar on the forum where the majority of the answers can be found.

And I also personaly think that the strenght of Codea is it’s kind community. Peoples are cools and help each others whether for simple or complicated questions. Some guys are here for a long time, and I thanks them for being so awesome.

I am super impressed that you have projects with over 100 files @blacatena. Really sorry about frustrating you with changes that caused your projects to stop working.

Thank you for your feedback.

  1. I think at some point, possibly when you’re getting into 100s of files, Codea’s editor will no longer cut it. It would be nice if we could, instead of trying to handle this ourselves, make Codea play nicely with other iOS editors and version control systems. And better expose its compile order (it’s stored in the “Buffer Order” key in a project’s Info.plist)

  2. Absolutely agree on UI. I don’t know what that looks like yet. I’d like to do something declarative like React with sensible and pretty defaults

  3. I love strongly typed languages too. There are typed versions of Lua but they are all half-finished research projects. If I were to move language now I’d consider TypeScript. (Though I hate the JavaScript weirdness and aesthetic.)

A. Like the idea of having documentation style comments used by the editor. A lot of editors do this and it could make Lua bearable for larger projects

B. Yeah I think the only good direction to achieve this is to move Codea to TypeScript. Typed Lua just doesn’t have the momentum

C. I would prefer simpler classes and no inheritance. It always ends up hurting my larger projects so I tend to favour composition. Agreed the Lua and JS classes are hacky

D. Compile order being defined in code would be better, like you say

4: We keep choosing those Google-unfriendly names. I got the same feedback with Shade, our latest app :smiley:

I actually don’t know if Codea should move to TypeScript, although I wouldn’t mind it. But an annotation system to just remind you about available method calls and parameters is what I’m looking for, not necessarily the strength of the typing itself. That’s something every professional IDE offers, and what allows one to work happily within a huge ecosystem of libraries, classes and methods.

On the editor and the tabs, I was thinking about how to fit a folder hierarchy within the current interface, and I think it’s pretty easy. Just allow the creation of “folder” tabs. Click on a folder tab just replaces all of the tabs with tabs for the files within that folder, as well as an up arrow (next to the + for creating new files) when within a folder, to go up one level.

And yes, I understand the point of the other two respondents, that Codea isn’t supposed to be a professional tool, or they don’t care that it’s not. That’s fine for them, but Codea clearly wants people getting apps into the App Store, yet that’s never going to happen much with the current development environment (although I will admit that AirCode is a great idea). If Codea just wants to be something people use to play around with code, so be it. I’m trying to offer constructive suggestions for how to take it to the next level.

I have no idea what is typescript and I am still learning to code - so maybe I am not fully grasping correctly what you are saying @Simeon by saying the correct move, is to move codea over to typescript.

I googled typescript and from what I am reading it is a syntax that scales to javascript. Basically it’s another programming language.

I want to make sure I am understanding you correctly - are you saying… you are going to make Codea into a full typescript syntax and remove Lua entirely from Codea? (if so) I have to speak up!

I was about to abandon Codea months ago, because… no one really answered me, as to, if in the future are there plans for Codea, to integrate, or somehow allow us to create programs for virtual reality platforms like (Oculus, Vive, Windows, Hololens, Magic Leap, Apple AR Kit, Google Core… etc) It was crickets (silence) when I asked my question.

That’s when I was like… yep, time to move on, good luck to them.

something about the devs, this community and even the program kept calling me back, and so I let it take me- it felt right, I will end up learning coding concepts and really applying it by using Codea. I even invested $50 on the shader app or whatever was the cost amount.

Then the damned unthinkable (for me) happened, I went all deep into academics to learn Codea as if it’s gonna land me a career somewhere. What do I do?

• I purchased courses on Udemy to learn Lua.
• Followed along with the Lua for beginners course from @Ignatz
• Learning about shaders on youtube and any source teaching me shaders in a way my noob mind can comprehend.
• While Driving, Showering, Idle time, about 68% of my time… I have something in the background speaking to me about Lua, straight up immersing myself.

Now, with me presenting you with this knowledge about what I am doing @Simeon Here’s my question: Am I wasting my time learning all of this because you will eventually move Codea over into the typescript syntax and abandon Lua?

If that’s the case, can I make a request too?
How about adding c# language in Codea with the .Net Framework?

@blacatena I found your feedback very constructive. People use Codea for different things and I agree that more easily being able to publish projects to the App Store should be one of them.

@tactfulgamer I don’t have any plan to move Codea to TypeScript. It’s more of an idle wish for a strong type system. Also the next version of the runtime being worked on is still Lua-based. I think some of @blacatena’s suggestions re. annotations would go a way towards helping manage larger projects for those who are disciplined (the benefits of strong typing are that it forces you to be disciplined)

@tactfulgamer. If you’re looking for a career in programming or anything in computers; I’ve been fond of telling my clients in the 1980s (I was self employed for a very long time) and employers that “I’ve already forgotten more computer languages than most people ever learn.” Now, in 2019, I can’t really say that, because everyone has to learn and relearn something new every year, and that’s not limited to just languages; technologies, interfaces, libraries, paradigms, conventions, patterns, styles, IDEs, development life cycles, tools, etc., etc., etc. Every programmer needs at least 3 (or is it 5? Or 7?) languages and a host of other things to be able to function today… even a “hobbiest”.

So while I agree with Simeon that Codea should not abandon Lua in the near future (but there’s a thought; what about adding a few more languages, so you can choose? Although that’s a massively complex undertaking), you personally should branch out. Try Python, and Typescript, and maybe some others. Learning multiple languages helps teach you to understand languages rather than just using them, and helps expand your capabilities.

@Simeon. I had an idea that I may play with. I already have done something with globals, which were a source of many bugs for me in Lua (e.g you forget to declare a variable in a function as local, with the end result that the variable retains its value from a prior function call, and you don’t get what you want to get from the next call as a result). I wrote a function that is periodically called to check the list of global variables, and warn me when I’ve used a new one. This has saved me from countless problems that once took hours to debug; and as a matter of style/convention I only use a handful of globals that are declared early in setup(). I use singleton constructs for most things that other people might use globals, which helps to keep my code more organized and manageable; basically, every variable ever used is a member of a class, a member of a singleton, a parameter, or local to a function. No globals allowed. I even have a Globals class, that is a singleton, off of which to hang necessary globals.

But my idea: I realized that using __index() and __newindex(), with the concept of a hidden backing table, will allow me to construct a base class called StronglyTyped that enforces typing. There will be overhead, of course, but I can (and will try to) write something that requires that all fields in the table be declared by calling a self:declareField() method, giving the field name and a type (using predefined constants), and then __newindex() can enforce type restrictions whenever the fields are set. I can even have fields that aren’t allowed to be set to nil.

This would also have to be used for function definitions. I’d add a method to the StronglyTyped class called declareMethod(). by calling self:declareMethod(name, function, paremeter-definitions…). This can method will add the method to the table, but wrapped inside another function that first does the parameter checking, and only calls the enclosed function after that. It can even test a return result for validity. Now I have control not only over enforcing field types, but also method parameter and return types.

[Actually, I can probably use a single declare() method in both cases; the type value can be “method”, which in turn expects a return type and parameter list after. If I go crazy, I can even implement function overloading, which is another feature of other languages that I greatly miss in Lua; I can just let the same function be declared multiple times with different parameter lists, and resolve the parameter lists into the different wrapped functions on execution.]

Of course, this doesn’t get me to what I really want; it will help prevent silly bugs, but I’m not too worried about that, I’m disciplined enough to use my fields and local variables properly. Where I’m trying to get to is that IDE autocomplete-suggestion-documentation pop-up functionality that makes working with larger code bases manageable, but that only comes with integration with the Codea editor.

But if this simple approach works, it would give you an easy avenue into using annotations to not only provide IDE-pop-up/autocomplete functionality, but also to enforce typing at runtime without needing to code it into the Lua interpreter or execution environment itself (your annotations would translate into StronglyTyped self:declare() calls in the code itself, while also populating a database for use by the editor for autocomplete pop-ups).

I’ll try to work on the new StronglyTyped class, just for fun. I don’t know if I have time to work on the more complex method-declaration logic, but the table-field-declaration logic should be trivial. If it functions as planned, you might consider using it for autocomplete functionality. Users wouldn’t have to use it, but this approach wouldn’t pollute any other code anywhere. If a developer wants autocomplete, they’d have to use annotations (and so the underlying StronglyTyped class) in order to get access to it.

Just a (complex) thought.

@Simeon Thank you, I was nervous for a minute.

@blacatena I appreciate the advice, thank you. The one I am learning alongside LUA is c# (I am definitely looking at python) I hear, Godot 3 (a game engine) uses it, in it’s engine.

I wish, @Simeon could use your idea of running several languages. That must require such a budget, such a team to and the finances required. One day @Simeon you will have all that, I think you’ve done amazing here.

but if you do happen to add @simeon, please, give us c# so us unity game devs can use your program as a way to study or test out certain things with the syntax.

Another quick idea; for the javadoc (i.e. the most useful point of the annotations, to be able to list the purpose of a method and the types and purposes of the variables and return value(s)), you could put that in a left pane, the same place as you put search results and your own reference; basically, give it an icon button along the bottom like you do for search and reference. When activated, open the pane and put either the doc for the currently selected class, or when working with a variable you know to be “an instance of class X”, it’s the information for that classes methods and fields in that pane, narrowed down as the user types.

The hard part here (and a big point of needing strong typing) is the ability to know what instance a variable might refer to… something you can only know during actual code executions without strict typing (except for self:).

I like the StronglyTyped table idea. Interesting way to add runtime type checking to Lua. But yeah, getting the IDE to make understanding and traversing your code easier is important to me. When I work on a large Lua code base (e.g., Shade) my method is often constant searching to try to learn the call hierarchies. There’s a lot of friction in that and I wonder what we can do to improve it

Adding multiple languages is not something I would do. I like the idea of designing Codea around a particular language. Not because I prefer one language, but it lets us make design choices that aren’t lowest-common-denominator across languages

@blacatena If you have Abandoned Codea, what are you doing now in front of your TV?
Personaly I switched to LowResNX.

@Simeon Codea is about the closest thing I could find to get my kids interested in coding.

The UI is uncomplicated. It has some great user-friendly features, such as editing colours and sprites in-place. Lua is easy to learn and performs really well. The Xcode export feature would make a lot of kids more likely to use Codea in the first place, because it gives them something to aspire to - making a game and putting it on the App Store.

Codea really hits that sweet spot with its combination of approachability and usefulness. There isn’t anything quite like it.

I definitely don’t want it to use TypeScript or any form of JavaScript for that matter. It’s far less approachable than Lua. (Btw, I’m a full-time JS dev.) Keep the language simple. If anything, Lua language help needs to be improved. My only gripe is 1-based array indices, ugh.

As for projects with 100s of files, it’s an entirely reasonable use case, and I wouldn’t mind seeing a hierarchical file tree as suggested. After about 10 source files, keeping track of things gets a bit dicey.

Code folding could be useful for larger projects as well.
But I agree, Lua is important for keeping Codea accessible and fun.

I’ve been away from Codea for a bit (again), for reasons. I’ve used both strongly typed languages and non, and very much prefer non, for small or large projects. That’s in part because I learned from some masters and know how to do it.

That said, I’d not use Codea for a project involving hundreds of files. One does need different tools for that, including, I think, big screens, mouse, etc. So I don’t ask that of Codea.

What I like is Lua’s extreme simplicity, which feels “close to the metal”, in the way machines felt when I was coming up. It lets me write fun code, and write about that code in the style of articles I like to write.

I admire the new power libraries, and will probably start to use some of them. The investment I’d like to see would be better documentation for those powerful new components.

As it is, Codea is a marvelous achievement, and like any creation, it deserves to be appreciated for what it is, namely an outstanding implementation of a singular vision.