Do you guys have any plans to produce a desktop (ie OSX) version of Codea? I would love to be able to use the same kind great experience that I get on my iPad on my desktop. That version could then have support for version control, and other more advanced features.
Obviously code sharing between desktop projects and iPad projects is out, at least for now; but it would still have great value.
That would be cool, but as it is not in the immediate works, you might want to check out the Love Codea project. It is a wrapper that someone (I think it is Codeslinger?) has been working on that makes Codea apps run on top of Love 2D in Windows or MacOS. I have been using it to prototype on my Windows machine, and most non-3d stuff works.
We have thought about it, but we decided to focus on the iOS version for the time being.
That being said, now that the back end is open source, we were hoping the community might take it on!
@Vega I am more than aware of the LoveCodea project and am using it at this very moment. But it is also exceptionally incomplete. It is a minefield of what works and what doesn’t — and not just the 3D stuff — with no documentation to tell you.
But more to the point, I wasn’t asking for a backend that would work on OSX, I was asking for a desktop version of Codea. What makes Codea great is not the API, it is the whole package.
@Dylan please don’t take this the wrong way — as I love and appreciate the hard work that you guys have done — but the API makes lots of compromises to beginning programmers at the expense of good OO design. Commands aren’t fully orthogonal, there are very few objects which means naked functions are “littering” the namespace, etc. Love2D while somewhat lower level is better designed.
There are better Lua editors, and one day there might be a half decent Lua IDE (especially if the IntelliJ plugin continues to mature). There are better game engines. But what me has me coming back to Codea, and putting up LoveCodea when I develop on the desktop, is just how good the Codea App is. As a total package it is hard to beat.
And that is why I would love to see a desktop version of Codea.
Now that all being said, I more than understand the need to focus your attentions right now. You are a new company with limited resources, and you need to make every decision carefully. But I hope you revisit this one periodically.
So if someone takes the Codea backend and ports it to the desktop, or if LoveCodea ever truly gels; it will be far far better than nothing. However it still won’t be what I wanted.
Two things:
I also think a Mac version of Codea would be pretty sweet, but I totally understand about having limited resources, and I think it is a good idea to focus on iOS for the time being. If I had the time and motivation I would do it myself, and while having access to the back end is great, there would still be significant amount of work implementing the front end and bringing it up to feature parity with the current iOS Codea. Plus, I wouldn’t feel entirely right about doing it, as Codea is not my baby, and I wouldn’t want to appear to be “stealing” anything from it. I don’t think it would be Codea if anyone else did it 
To @JockM’s point re: OO design, I don’t think it is a good idea to force an object oriented paradigm on programmers using Codea, and I feel like if care is not taken further effort to do so could work against the spirit of the Lua language. I like the fact that Codea provides a simple way to handle classes and inheritance, but I also like that I don’t have to use it if I don’t want to, or that I could even roll my own implementation of it of I wanted to.
That being said, I do think better containment of the functions in the global namespace is not a terrible idea, but I also worry that doing so might make things unnecessarily complex. The only real issue I can see honestly with the API as it currently stands is that someone might accidentally misappropriate one of the function names currently used by Codea, which would lead to subtle and hard to diagnose problems, but it’s hard for me to say if the risk of that happening is enough to warrant such a breaking change to Codea. My $.02, for whatever it’s worth
@JockM Codea purposely pollutes the namespace with its API. And it has very good reasons for doing so. It’s not designed for writing well-engineered, clean code (although you can).
The philosophy of Codea is to get your ideas onto the screen as fast as possible. We don’t want you to have to consider packages or namespaces, we want you to type ellipse and see an ellipse. You write code, then throw it away and write new code. Codea is entirely focused on getting your idea right. You can always write the code again more cleanly — that’s not important. It’s important to go through lots of ideas to see what works. It’s important to throw away code.
There’s no reason not to pollute the global namespace — we’re not trying to keep it clean, we want it to be full and useful. It puts important features closer to the developer.
@simon @toadlick I think my point got lost here. Lets go back to what I said:
the API makes lots of compromises to beginning programmers at the
expense of good OO design
So I have already made the point you were making. What I was saying was that in spite of this I love and prefer Codea, even though you have made these compromises.
I was not advocating for changing the API, I was arguing for the value of a desktop Codea. What I was saying that Codea doesn’t have the best Lua editor (though it is very good), nor does it have the best API, nor the best debugger; but what it does have is a sum far greater than the whole.
And that was my point.
Sidebar:
I was the author and CTO of a multimedia authoring system back in the day.
It was designed for both experts and people who had never coded before in the life.
We found that a namespace and a simple object structure did not pose a problem for
novice coders.
I personally think that if you had put all of Codea’s API in a codea. namespace, and
usedfill(NONE)(orfill(TRANSPARENT)) instead ofnoFill(); then you wouldn’t
have hurt beginners at all.
But what is done is done. We can differ about designing APIs, and if you are ever interested we can chat about that… offline or in a different thread; because this one wasn’t about that
@JockM fair enough. I agree that there is value in a desktop Codea — and it’s something I plan to work on in the near future.
Though I must disagree strongly about a “codea” namespace. There would be more key presses required to get a function on screen (even with autocomplete), more navigating with the cumbersome iPad text loupe, and longer lines that wrap. There is no reason to put this functionality behind a namespace.
fill(NONE) is nice, I prefer it to noFill() as well.
@Simon well until the day you add a new API entry point that someone is already using — since by and large Codea’s API is based on common and obvious words. This will be especially fun if a project is using a third party library. Depending on the circumstance it can be “fun” and non obvious to unravel that kind of issue.
right now I have a utility function named loadJSON, I use in nearly every project I start. Now I keep that safely namespaced, but I don’t think most of your users will; and that name is something you might be likely to choose should you add that kind of functionality. But will the parametiers be the same? The exceptions? The return values in error situations?
Sooner or later this issue is going to come up. Most of the time it will be minor and no big deal. Occasionally however it is going to be a real problem and someone is going to have a very hard tim getting to the bottom of it, and potentially have a lot of existing code to fix.
It is to late to deal with this, but even simply prefixing every Codea function with the letter c as a crude namespace would solve this kind of problem.
Obviously it is your app, and you should do what you think is best. But I would suggest picking a nice point, say Codea 2.0 where you change the APIs to all have a common prefix, keep all the old APIs intact, but all new ones will have the prefix. No code will be broken, and the problem will effectively disappear.
@Simeon BTW sorry for getting your name wrong, my bad. As someone with an unusual name myself (Jock) it drives me mad when people take a glance and assume it must be Jack or the like.
Mea culpa…
@JockM I think we have different views on code. I see code (in Codea) as something you write to express an idea, and then perhaps throw away to work on something else. So namespace collisions aren’t a big deal to me — just throw out the code, or change it. There’s nothing sacred about it.
In practice if Codea ever introduces new APIs and you have defined your own (with the same name) then yours will overwrite Codea’s — so that’s not an issue. Any new projects you start will obviously be free of collisions.
@Simeon let me take those in reverse order, the problem arises when you have new shared code that tries to make use of the new APIs. The scenario I described is not hypothetical, it has bitten me and I have seen others make that same assumption more than once. Most of the time any conflicts that happen are minor or easy to catch, but that 10% case is the one that is going to drive people crazy.
Now onto the first part.
Once a product is released into the wild, it will be used in ways and by people you never expected.
It might have been your intention that Codea is something that is used only for experiments and/or disposable code; but that doesn’t mean your users see it that way. I must point out that just because I might be using Codea for an experiment, or for something disposable, doesn’t mean I won’t be writing classes, applying good design, or using shared code… often written by others — the use case where namespace issues will be worst.
Once you guys published Cargo-Bot (and opened the back end) you sent the message that Codea is also a professional tool that can be used to make real apps for the App Store… and potentially for other platforms if people port the back end. This is further reinforced by your plans to add more advanced features like networking and shared code
Serving a more advanced community doesn’t mean you have to hurt the beginners and novices the tool was originally aimed at. Simply prefixing all Codea APIs with the letter “c” would not hurt novices and it would help everyone in the long run.
@JockM I have to say that if TLL prefixed everything in the Codea with the letter c it would drive me round the bend - possibly to the point of not wanting to use Codea anymore.
Why don’t you just prefix all of your own code with a letter instead?
@frosty If you look above you will see that I do keep everything I write properly namespaced. However I can’t count on everyone else doing so.
Let me give you a scenario. Lets imagine a hypothetical library for Codea called CodeaPlus. CodeaPlus contains all kinds of useful methods that don’t currently exist. One of which is the hypothetical oval()function.
In Codea 1.? they also introduce an API named oval()but its signature is different. Codea also has some other function that calls oval(). But since it is no longer calling the codea oval() function it will fail. And it will fail in some very confusing and hard to figure out way.
It would be even worse if the method signatures were close but not identical. Because then things will work in some cases and not in others.
This is not some hypothetical btw, I have been bit by this kind of thing more than once. I have also been Simeon, dismissing the risk. It sadly is a lesson most of us learn the hard way.
Now to your first point, I am sorry I don’t believe you. I doubt needing to type cEliipse()or (codea.ellipse()) instead of ellipse()will drive you away. Right now you have to type:
table.in front of table functionsstring.in front of string functionsmath.in front of math functionsos.in front of OS level functionsAssuming Codea adopts LuaSockets in the next version of Codea for networking you are going be introduced to a boatload of new namespaces.
And also where would you go? What other tool exists on the iPad that does anything like what Codea does? Switching to the desktop and using something like Love2d will force you to type love.in front of all of its calls.
I am not trying to pick on you frosty, just trying to point out that Lua is filled with namespaces already, and using them is very common. They exist for just the reason I described above. It isn’t a hypothetical issue. Nor will one extra letter kill you (even if you had some other place to go).
Note: Edited for formatting, not for content
@JockM, I’m with you on the need to be careful here, the global name space drives me crazy.
But can you not avoid the problem yourself by having codea be the only one allowed to define stuff in the global namespace? I try to do that (Sometimes I get lazy), because I know that if I started to define functions and variables in the global namespace, at some point I would write two functions with the same name. So that’s already a good reason to avoid it, what’s the danger in letting codea use it then?
@ruilov The problem is that you can never control what other people do. Someone comes up with a library and they use the global namespace; and I am faced with the decision of not using it, refactoring the whole thing into a namespace (and doing that every time it is updated) and every bit of code I touch that will use it, or using it as is because it will make my life easier.
Of course I could carefully audit every bit of code I use, or make sure I never use any code I don’t write; but that’s a mug’s game and we all know it.
I make sure every bit of code I write is in a namespace. But as I said, you can’t control what other people do. I have learned that lesson the hard was more times than I can count.
@JockM I can’t stand that löve is namespaced (and I love löve). When I want to write code quickly, I don’t care if it’s hacked together. All I want to do is see the idea on the screen — anything that gets in the way of that has to go (table.insert drives me mad, too). If a prototype takes me longer than a few hours it’s too long and I need to start again. How else do you iterate through tens or hundreds of interaction ideas?
Once you settle on a great idea (after throwing out many good ideas), then you engineer it properly. But that first part is key to achieving a great idea, and I use Codea to get me there.
Edit: that’s not to say we won’t add future features under namespaces — for example, we did it with the physics library. But we will be careful about where we choose to do that.
@simeon We are probably just about at the point of diminishing returns on this conversation, but I here goes:
And I am not just talking in the abstract. People are using Codea for more than just prototypes, and the fact that you are adding features like code sharing is a sign of that. So you need to stop thinking as throw prototyping is the only (or primary) reason people use Codea.
But for the record I don’t find it a problem to type love., nor table., nor any of the other examples. It isn’t hard (and I have early onset arthritis and Carpel Tunnel), and it increases clarity. Clarity is as important (or more important) than speed.
Even when I am iterating ideas or making prototypes I do it by reusing code, and applying good software engineering practices. Namespaces don’t slow me down, they help me make sure what I am doing is clear and useful.
I have been using prototype based languages since the very early 90s (starting with Self). So when I describe the problem with overriding functions in the default namespace, I have lived the consequences*. I know what I am talking about, and it is going to happen in Codea. The only open questions are when, and how bad will it be? But it will happen sooner or later**.
*: There is an especially unpleasant two weeks of my life I would love to get back where one library overrode an existing API with a slightly different signature. To the outside world it looked like code was randomly failing. All because some unknown person though he could implement a core function better.
**: Ask anyone who tried mixing PrototypeJS and jQuery in the same project back in the day.
I am not sympathetic to arguments that namespaces are harder to type, or make the line longer, or somehow slowdown writing code. Even when cranking fast and loose code I — and every other engineer I have ever met — spend more time pausing and thinking than typing. Namespaces and prefixes don’t slow you down in any appreciable way.
It is in your interest to put all of Codea’s APIs inside of a namespace (or at least use a simple prefix). I frankly have little hope that you will, and have felt that way from the start.
However it would be in your interest to add this feature to Codea: Just after the user’s setup()function is called and then scan the global table to see if any Codea APIs have been overwritten, and log any ones that have. That way people will at least have a warning about it.
@Simeon, even in prototypes I’d like to be able to reuse library code. If I can reuse stuff I built before, or even better that @Bortels or someone else did, then I’ll be able to express ideas much more quickly. I wrote a pentago game a few weeks back and it only took me a few hours because I was able to reuse the same library that I use in cargobot. Otherwise it’d have taken me days.
You mentioned in another thread that you plan to add a feature to make importing projects easier, and that’s very cool! Codea now offers a very rich API and improving the development environment is a natural next step (more debugging tools please! red tabs on syntax errors are so helpful)
@JockM I think it’s a reasonable expectation that library code will not use the global namespace. If it does, then it’s low quality library code, and you can use at your risk.
Q: is there anyway you can programatically verify what names are defined in the global namespace?
After seeing @JockM’s arguments, I actually have to agree with him fully on this. Earlier I had wondered if moving all of the globally defined Codea functions into their own namespace would be worth the breaking changes, and at this point I think it would. Like him, I am not expecting this, but it would be nice.
@ruilov: the way to do that would be to create a table and assign all of the same functions that are currently in the global namespace to that table as well, and then compare them all to the functions in that table after setup() is called to see if they are different. But at that point all the work of moving Codea functions to their own namespace would already be done! Funny to me that a way to verify that no globally defined functions have been overridden would require doing what @JockM is asking for anyway
To that end, if (hypothetically, of course) TLL were to move all of the global functions to their own namespace, a function could be provided to export those functions back into the global namespace for backwards compatibility, or just for those (like @simeon) who are bothered by the extra typing. It would be done at your own “risk”, but that risk is already there now, so really nothing would be lost by doing so, but it would be a potential win for those concerned about the polluted global namespace.