Please know that I think all your arguments are great and they have really gotten us to recognize this as a potential issue.
@Simeon I have to disagree that that Java and .Net are somehow bad examples. Your asserted that one wouldn’t put core graphics functions in a namespace, and I said yes I would. I also pointed out that there are languages that do that. The comparison is apropos.
I also admit that I find your complaints about namespaces baffling. foo.ellipse()is no harder or easier to remember than ellipse(). In my own experiences with the authoring system I created was that namespaces helped understanding because it gave extra information to notices. It gave them context. And I should point out they had to type dramatix. before every call they made. Out of the dozens I trained, no one complained about that.
You made the comment that you liked processing’s API because there was no digging. I have exactly the opposite reaction to Codea’s API. I am constantly digging though the Codea documentation — which I cannot search and has no table of contents — to figure out what I want. There are no overviews, details are spread out between the definitions, and the API is periodically oddly non-orthogonal.
My point? Its that one man’s simple is another man’s mess. It is also dangerous for us to be objective about our creations because we have been with them, and know them far better, than anyone else.
It probably would have been better if you are tested Codea with what I suspect would have been a broader group of people; because you would have had a chance to hash though these issues and check your assumptions at a time when you could have made changes.
I am going to make a prediction, though I have no intention of saying “I told you so”: In a couple of years the API will have grown considerably and it is going to be a mixture of stuff in namespaces, and a bunch that isn’t. A new user will make a post in the forums that they can find no rhyme of reason as to what gets a namespace and what doesn’t, and how that hurts understanding and makes it all confusing… and they will be right.
@JockM I understand your point. And I am the least objective person to talk to when it comes to Codea.
Java and .Net are not specialised programming tools. They are all-encompassing, general purpose libraries. They don’t enforce a run loop, nor do they focus on graphics and interaction programming. I think it is more appropriate to compare Codea to Löve, Flixel or Processing.
Perhaps it comes down to personal taste. I find I am no where near as fast or creative with Java or Löve as I am with Processing or Codea (and Processing uses Java). Much of this I attribute to the lack of namespaces and fast visual feedback.
I wrote Codea as the tool that I wanted on iPad. I was using Processing on my laptop and wanted a similar coding experience on iPad — though I had many of my own ideas, especially in a touch-oriented environment. I wanted to strip away traditional programming overhead and leave things bare and simple. You and a draw loop and primitives.
In fact, I even strongly disliked that users had to define classes by saying “TypeName = class()” at the start of a class. I wanted to hide all of that and just let users focus on the contents. I couldn’t find a nice solution to that particular issue, though.
(I agree that Codea’s documentation is lacking. But that is a flaw in the documentation, not the API. This is due to the fact that it relies on a web framework. I plan to rewrite it using UIKit — web apps are pretty terrible.)
in my opinion, code is something different at all… it is a toy.
imagine a smal tiny shovel for kids, that is not a professional tool, but you could use it to build the moste elegant and biggest sandcastle one can imagine… yes, maybe youd could do it faster or more effecient with an excavator, but the point is… if your start with a sandcastle, it is easier to try yourself out with that tiny kiddy shovel… maybe it’s a bad idea to start something like this with an excavator…
if you want xcode and c++, use that… but i think the intention of codea is primarily to have fun and get fast nice results…
and yes, i plan to create a game with codea and submit it to the appstore, because it’s much more fun for me to code with codea on my ipad than to learn xcode completely…
and for the starters with code, it matters a lot if a sprite() draws a sprite or if a codea.sprite() draws a sprite… to target for Simeon is, so i think, to make the learning curve lighter, and such details as a namespace should be no problem for the average programmer, but for starters and “just want that thing like that” is that not necessary… and the final point is, as Simeon stated before, your could use namespaces for your own librarys, so what’s the point?
and the comparison of codea to a toy, don’t be mad at me Simeon 
for me personally it’s far more than that, but if i were as ambitious as JockM about this, i would use xcode…
@Simeon
Namespaces and creativity and learning
Yeah I don’t know what to say to that, except that I think you are the exception rather than the rule, and that I wish you had looked into it a little.
Also would a single letter really hurt your creativity, or be hard to learn? I have taught a fair number of people to program in my lifetime and oddly enough I find novices have no problem with namespaces, because to them love.draw() is exactly the same as draw() a magic incantation, one does not make more sense than the other.
However once they go down a little further and the start to grok what is happening, I have watched the lightbulb go off in their eyes and they say things like “oh it is a way to keep everything organized”. In my years I have never had anyone complain about namespaces. And while it is anecdotal, it is the most data we have in this conversation.
In five minutes you could write a script in Lua and make “c” prefixed versions of every Codea call. You could then spend another five writing something.
And at the end of that 10 minutes what would you have? Data. You would have challenged your assumptions, and everyone who wants to master their craft needs to do that.
Documentation
Actually if you read my message closely you will see that my complaint has more to do with how it is written and organized. You need overview sections, for example: you need to make sure that the details of how sprites and contexts work together are covered in the overview to contexts.
None of that has to do with what the help system is written in.
And you need to make is searchable, which is very very easy to do in JavaScript — a language semantically similar to Lua with better string functions.
I don’t really care what you write the help system in, but I do think your statement that “web apps are pretty terrible” doesn’t carry a lot of water.
More to the point it would take far less time to add search to what you have now, than to rewrite it in UIKit, and where is your time better spent right now?
But there is one more point about digging I made poorly. Assume the documentation were better, and it had search. I don’t find processing’s API to take less digging than say Love’s. I personally had to dig more in Codea and Processing than with Love.
Why is your experience different? At least in part it is because you seriously learned one system and then found something that was simpler and more pared down. At that point Processing made sense and then you went off an made your clone of it. So now you know it like the back of your hand.
@Inviso I could not disagree more. There are plenty of toy development environments for the iPad, and Codea is not one of them. Codea is the most powerful IDE on the iPad.
In fact if you want to find the closest thing to what you described — a toy for learning and making games — go look at AppCraftHD. Codea is far from a toy. But more to the point, let me reiterate something I have said before in this conversation: If Codea is meant as a toy, and is primarily intended to be used by novices to make highly disposable code; then they need to change their messaging.
What is said in the forums doesn’t matter. What matters is what is written in the App Store, and what they say to reviews, etc.
I like Codea because I do like to use it for prototypes, and to work out ideas, but that doesn’t mean I do them crudely or poorly. But I also want an environment that is on my iPad, one I can use without an internet connection.
I use XCode (amongst other IDEs), I have a number of apps in the app store — a handful under my own name, and others I was contracted to write. And I use the right tool for the job.
In the case of Codea I use it because it is powerful, and I would not have written quite so many words did I not love it
But none of that says that “Codea, love it, or leave it” — to paraphrase the bumper stickers used to say. When you care about what you use, it is our responsibly to work to make it better. It is a poor craftsman who doesn’t have an opinion about their tools.
But before someone else chimes in to say they like Codea as is, or to say that namespaces help or hurt, or whatever; please take a few seconds and see if you can find some data to support what you are saying. I will admit the data I have brought to the table hasn’t been great, but it more than just my opinion or experience.
“In five minutes you could write a script in Lua and make “c” prefixed versions of every Codea call. You could then spend another five writing something.”
@JockM that is exactly the sort of thing I want to avoid in Codea.
There are plenty of engineered, deep APIs out there for building things (and I use them daily). I intended an elegant, simple API that was entirely about making visuals and moving them.
Like I said before, I certainly don’t have anything against namespaces. I think they are valuable and have their place. Codea makes use of them where appropriate, such as physics.* and http.* — and we may choose to encapsulate certain future functionality if it is appropriate.
Most of our time is spent designing the Codea API. Implementation is secondary. We are very passionate about choosing the right interfaces, and positioning them for optimal use.
Regarding documentation
Agreed about more overview sections.
Agreed about making it searchable — the web framework we use doesn’t make this easy (or fast). Currently the documentation feels clunky because it is javascript — that’s why it takes so long to load. I haven’t found a web framework that feels as smooth or pleasant as a native iOS App. (The closest I’ve seen is the Financial Times web app, but that still doesn’t come close to UIKit.)
I used Löve for a long time before Processing. I like Processing more because of the way it is designed (though as I said before, I still really enjoy Löve). I’ve written a similar number of prototypes using both systems. Please don’t make assumptions about what systems I have used before.
@simeon you know that users don’t have to type foo = class() there are a couple of approaches you could take. You could go JavaScript like an put functions inside of functions (which would be the methods, and the master function the constructor).
Or you could do something like this:
`
AClass = {
init = function()
– do whatever
end,
foo = function()
-- do whatever
end,
bar = function(z)
-- do whatever
end
};
`
You would then create a function called new()that makes a shallow copy of the table. If there is no object hierarchy (about 70-80% of the time) then that is all you need to do. For the other cases you could have a function named inherit(class, newFunctions) where class is the parent class, and newFunctions is a table like AClass above.
Lua, like JavaScript, has more than one way to skin the class definition cat…
@Simeon I think you missed my point about the “five minites and then five minutes” I was not describing some generic way of operating, I was saying that in less than 10 minute you could take the existing Codea and have a version that used a “c” prefix and then you could actually know if typing cEllipse() actually slowed you down, and not just make assumptions.
You asserted that even that would be to much, my point is you could take it out of the realm of speculation and know. It wouldn’t be for Codea, but for some other thing you do down the road.
@JockM I understand your class example, though it’s not quite what I had in mind.
What I wanted was to remove all the cruft when creating a class. That is, my initial goal for Codea was that when the user adds a new class the tab has a special appearance (a different colour or a special icon, say).
All they would have to do then would be define functions (not even prefixed by ClassName:, and no ClassName = class()). I wanted Codea to pre-process these classes and add the required code.
In the end I decided against it because it I couldn’t think of an elegant way to allow for inheritance, and I could see some benefits in exposing the underlying class mechanism (multiple classes per file, inner classes). I still feel this is a rough edge, though.
Having a ‘c’ prefix
Your example with the “c” prefix would make auto complete a lot more difficult to navigate.
- One of the goals for Codea is to make sure it is comfortable on the iPad software keyboard. When I use it I often just tap the first letter of what I’m looking for, then tap the appropriate symbol in the autocomplete list. Prefixing everything with ‘c’ would remove this convenience.
The iPad form factor influences some other aspects of Codea, such as:
-
Keeping your code short. The iPad has a narrow screen, especially in portrait mode. Long lines cause wrapping and make things messy. We aim to keep things short. (E.g., the advanced sound() picker generates lower-resolution encodings in order to keep lines short. You can get full resolution encodings by using table sound parameters.)
-
How many key-presses does it take (using autocomplete)? Typing on the iPad keyboard is not as pleasant as a hardware keyboard. We want to make it as pleasant as we can. (I like to code in portrait mode, with my thumbs — so getting this to feel comfortable is important to me.)
-
Minimize non-letter characters — these are hard to type on the iPad keyboard. They also make the code extremely hard to navigate with Apple’s text loupe, which is biased toward word-endings.
@Simeon I can give you a counter example on the c prefix. For me, at least, it would make autocomplete more useful, because I could type c and have the codea functions laid out for me. Right now I go to the help far more often than I like because I need to be reminded of what the names are.
But again my point about testing the “c-fix” (if you will is that you are making a lot of arguments as to why it would be bad, but you don’t really know. In less than ten minutes you could try it and say “hey that isn’t as bad as I thought” or say “I tried it and it is just as much of a problem”
And then the next time you make something Codea-ish you could go in with more knowledge than assumptions.
Last night I took my makeGlobal() function above and then used it to unravel table, string, and os and actually tried writing code that way. It made writing the code easier… when I didn’t use autocomplete. It made auto complete harder (since I didn’t have the organizational benefits of namespaces). And finally it made reading my code an hour later harder. Also I found myself wanting to use string functions on tables, and table functions on strings.
@JockM I don’t argue for unraveling the string functions into global namespace, or os. I think those are good where they are. I am also unsure about table — I find table.insert quite annoying every time I encounter it, but having insert() in the global namespace would be inappropriate, too. That doesn’t make table.insert any less annoying.
On a side note, I would like myTable:insert( item ) to work. Obviously it doesn’t because table isn’t the metatable for table instances. That could be resolved by:
table.__index = table
setmetatable( myTable, table )
Though you certainly wouldn’t want to do that for every table you create.
Anyway, I have nothing against using namespaces. I think they can benefit autocomplete in the way you mention — having a specific sub-group autocomplete is a nice thing. That’s why we put it in Codea.
I also feel that the graphics primitives are okay where they are. We will be adding a tween() function to the global namespace in the future. As I consider that to be a primitive of Codea.
There are parts of Codea that I might be persuaded to move out of the global namespace — storage functions, for instance. Though I feel their function names are too long as is. Adding a namespace qualifier would make lines too long. They could probably do with a redesign, a move to generalised storage.save() and storage.read(). The highly specific storage function names are confusing.
It seems to me that a compromise solution would be to have an “import” or “using” function like those in c, c#, java, python, etc. All the Codea stuff sitting in the Global namespace currently could be moved to the Codea namespace, and the line of code “using Codea.lib” (or something like that) would automatically be added to the beginning of new projects. If a coder wanted to, he could delete that and fully qualify all of his function calls, etc.
@Simeon I didn’t say you did argue for unraveling string or os. I said I did them. I did it so I could have a body of unraveled calls to work with.
I understand that the Codea core APIs are going to stay in the global namespace, I am not trying to change your mind (and never have been)… for Codea.
What I am saying is every time you feel very strongly about something you should double check it. The beauty of a language like Lua is that you could test namespaceing, or prefixing with almost no work and know and not just assume.
As for tables I am 100% with you that everything in table.should be methods of table. I was thinking this morning that you could replace __newindex with a version that tested if the value was a table, and if it was then automatically mixin table.
It would work, but I personally wouldn’t do it for the same reason I am not crazy about Triggers in SQL: they hide functionality. For me, at least, it is probably better to create a “BetterTable” class (or function) that would take care of it.
@JockM theres one thing that bothers me a little.
I disagree when you say, that if you are able to get your codea app out on the AppStore, that you have to reorientate the position of codea, because now it has grown out of its shoes and cannot be seen as what it was anymore…
I don’t understand why it’s so important to you, what kind of projects are you planning with codea that this is such a big issue? Don’t get me wrong, I think I understand your point, but I don’t get why it’s so high on your importance list. And I imagine that to preserve backwards compatibility a function like ellipse() would be still there, and would confuse so many people, when they see your examples where it would say cellipse and then older examples from someone else where it’s still ellipse…
I think that is a convention in code and Simeon and the Team are deciding, what is used why… And I know for sure, that a keyword like ellipse or square IS easier to read/understand than csquare etc. because it is a bit more naturall…
Another point is maybe, if your not a native English speaker, that prefix is confusing you just a little bit more… Keep it simple, keep it easy… I think there’s a reason, that programming was never more fun for me than with codea, because I get results so fast.
@Inviso My point was that regardless of the original intention for Codea, once it was put into the wild people didn’t use it in just that way. Nor has Codea’s messaging ever been about it being a toy app (as you put it). The only place I have ever really seen that idea presented is in this thread and it was news to me.
Yes it is great for prototyping and trying out ideas, but it was never presented as just that. And that stepped up once they shipped a a game and said “look what you can do with Codea”, then they open sourced the back end and said “and you can to”
So regardless of the original intention, it was definitely no longer that toy app.
Now as to namespaces and prefix, yes it might be ever so slightly harder to read. But there are costs and benefits to everything. From my perspective everything that isn’t core Lua should be in a namespace. The only person who is allowed (though it is still ill-advised) is the end user. The cost is trivial compared to the benefit.
I say this from both decades of experience, and from my direct efforts to teach novices to program.
I am reminded of Jeff Atwood over at StackExcange who would write scripts to strip out greetings, and thanks from questions and responses because they were unneeded and took extra time to read. Was he right? Of course. Was he right in a way that had any meaningful effect? Of course not. Were there unintended consequences that could hurt StackExchange in the long run? Yup.
Also be careful with arguments that begin with saying something is more natural or intuitive, because there is nothing natural or intuitive about computers, or programming. It depends on context after context built up over generations.
ellipse() is no more intuitive than cEllipse()or codea.ellipse(). Indeed to someone from a mathematical background (or who remembers high school algebra) the arguments to the aforementioned ellipse() call make little sense — they have nothing to do with how ellipses are drawn. Different contexts yield different naturals.
But again I want to point out why I think namespaces are a good idea, and that I regret they weren’t used. I have never advocated for Codea to adopt them. But because people were curious I outlined three easy ways to support legacy code.
Actually, I think there is a difference. I know that in diving into OO languages in the past, I’ve had little trouble grasping the syntax. How a for-next loop is structured, or how variables are defined can be grasped in an afternoon (which isnt to say you still won’t be cursing minor differences from some beloved language a year later). It’s the code libraries that cause the problem. Something as simple as printing to the screen can buried under System.out.println or Console.WriteLn. Knowing where all the power is buried requires a level of gestalt that’s often daunting.
This is particularly true for graphics, where not only do you have to wrangle a sometimes confusing set of primitives, styling, and scaling, you’re often faced with building the canvas on which drawing takes place… and facing a lot of head scratching when it doesn’t.
What Codea has done is privilege a lot of common graphics primitives in a way that removes the requirement of understanding Codea or Lua as a whole. It makes it easier to tackle Codea piecemeal, and brings the graphics primitives one step closer to being part of the syntax. It turned the graphics I wanted to use into something I could use, day 1.
Of course, that’s just how it feels to me, I can’t speak for anyone else.
I don’t think we are arguing the same thing really. We agree with you that namespaces are useful and even necessary in most contexts. We are seasoned programmers as well, and have used a lot of different languages and libraries. Where we differ with you is in whether Codea should use a namespace for its core functions.
Not putting the core functions in a namespace was @Simeon’s attempt at doing just as you say and questioning his assumptions about code structure. The obvious way would be to put them in a namespace, but in the context of Codea it made more sense not to.
At this point the discussion seems to be going in circles, so I am going to bow out 
@Dylan actually the only thing I have been arguing for the last however messages is that far too much of this discussion is about hypotheticals. People saying namespaces are hard (as a concept, I concede they are harder to type on the iPad), or will put off users. And that it would behoove Simeon would test his assumptions about a simple prefix as an experiment to inform future decisions.
I am sure you two are seasoned and experts, you could not have produced Codea if you were not. The point of me bringing up my experience was to try and inject a little data about novices and namespaces, in a conversation that only consisted of subjective opinion.
The other reason was to explain why you needed to check if the user overrode any codea functions in the global namespace. Lua is a small language, but it is not a simple language. I know engineers with far more experience than myself who have shot themselves in the foot because of the trouble you can get into with a prototype language.
I feel minority frustrated because I have not been trying to change Codea in this regard. I have accepted that this is how Codea is and will be from the beginning of this thread. The whole reason I even brought it up was in saying that Codea is more than the sum of its parts.
Edited for clarity
@Vega sadly that isn’t quite how Lua works. The closest you have to the concept of a using keyword is a lua file that returns a table containing all the functions and classes for the module. This would then be loaded via requireand assigned to whatever variable (namespace) the user wishes.
At that point the user could choose to use something like the makeGlobal()function I described earlier to put all the APIs in the global namespace.
Codea (for good and ill) gets rid of the need for dofileandrequire. Which means a module can’t return itself so the user can assign it to a variable. Either the module assigns itself to a variable or it uses the global namespace. The middle-ground of a required module isn’t an option in Codea.
There is a part of me that wishes there were another product — call it LovePad — that took Codea’s editor and project manager, used a different name for the internal way of making a class, and used the Love2D API directly. Then you would have a Codea to fulfill Simeon’s vision of a rapid prototyping environment and something that would accomodate a more production like environment (for wont of a better term).
The closest we may get to this is If/when the iLuaBox ships the version with a graphics API (and a way of loading images into the environment). It won’t have Codea’s editor, but at least there will be some kind of alternative.