Desktop Version?

[frosty]

My last two cents on this (as the discussion is getting rather circular) is simply:

• I see Codea as a great (fun!) tool to very quickly prototype ideas and try them out on an iPad. I think that’s always been its main purpose, and the fact that people can build complete games with it doesn’t mean that everyone should. I like to think of it as a sketchbook for my code ideas.
• I agree with Simeon that Codea’s Processing-like API facilitates this immediacy and fun factor, for me. A namespace for basic graphics commands would personally slow this down for me. Typing code on an iPad isn’t the fastest, and Codea does as much as it can to speed this up and let you throw down ideas. I’m really glad Codea was made the way it was.
• @JockM, you say ‘Yes it is great for prototyping and trying out ideas, but it was never presented as just that.’ - I have to disagree and say that that’s exactly what it’s been presented as. The release of the Codea runtime is a very recent development, and if you check out Codea’s App Store listing, the Runtime is a single bulletpoint at the bottom of a list that is geared towards prototyping and creative code.
• I think the issues that @JockM is describing as being potential problems and pitfalls would potentially impact only a very, very small number of Codea users. Perhaps a simpler solution would be updating the currently-beta Find functionality with a nice Find-and-Replace. If, on the off chance, an API update does break someone’s code then it can probably be fixed with a find-and-replace.

I think that’s probably everything.

[JockM]

@frosty I, like everyone else, am tired of this conversation. So I am only going to address one part of it: It often doesn’t matter how many people a bug/flaw/design hole will affect but the damage it will cause.

The problem I described could only affect one person, or it could affect dozens or hundreds. The problem is that diagnosing and fixing it could take a lot of effort and frustration. It could leave a bitter taste in people’s mouths and cast a negative impression on Codea. It could scare people away, and make people think it isn’t that friendly easy place to make prototypes if there are timebombs in the product like that.

But the good news is that a solution discussed in this thread and it sounds like they plan to implement it. Once they do it will be up to people to read and understand the warning, but at least they will the information now.

I am going to provide one last thought, a nugget to consider, on the whole “namespaces slow things down thing”:

For the majority namespaces are not a problem, in part because of code completion. For me most namespaces are one (or two) letters and then a keystroke and I am on my way. While Codea has completion, it isn’t quite as handy (for understandable reasons related to the form factor).

So perhaps the perhaps the problem isn’t one of namespaces, but for how they are entered. Perhaps it is a UI issue, and not a namespace issue.

I could imagine a version of Codea what had a button that brought up semi transparent overlay. In it would be every namespace Codea uses (including global). You touch it, and you see all the commands in that namespace, you then touch that and the command is inserted into the code.

At that point every command, regardless of namespace, is three clicks away. There is litterally no difference in the difficulty in typing ellipse(),cEllipse(), and exceptionallyLongAndCombersomeNamespace.ellipse().

If we had that feature, then Codea would be faster and easier to use than it is now. @Simeon?

Every single one of us needs to challenge our assumptions. Each time we say “we can’t do it because of XX” we should stop and think “why not? what is the real problem? and is there another way of solving it?”

[Vega]

This may be a slight branch to the conversation, but I would guess that perhaps the developers may be slightly misjudging the audience of Codea. It seems like it was designed for regular folks with zero programming experience to come in and have some fun, play with code a bit, maybe learn the basics of programming.

However, I suggest that these are not the people (by and large) using Codea. Let’s say you had a little survey popup after someone uses Codea 10 times or so. And the first question was “How much experience do you have coding, 1-5?” and the second was “What is the primary draw of Codea for you, playing around with code, learning code, or making an app for the app store?”. What do you think would be the results?

I hypothesize that the average Codea user is at least an intermediate programmer, and that the largest draw would be creating an app for the app store. Just a guess, but that is the vibe I get.

Things like a Codea namespace as suggested by @JockM would appeal to advanced coders who want to make serious apps simply because it would make programs harder to break and code easier to read. It would not appeal to people (regardless of skill) who just want to play around, prototype, and create disposable code.

So, my longwinded point is, I love the idea of a Codea namespace, but if the average Codea user is a noob or someone who just wants to play, then it would be detrimental.

[sim]

@Vega learners were never the target audience. It was never designed for beginners to learn coding — the fact that many beginners have taken to it is delightful. The target audience was actually me. When I developed it I wanted the best tool on iPad for making my ideas come to life.

I wanted something to go from code to visuals with none of the cruft of regular programming systems. I wanted to be inside the draw loop immediately with a wide range of graphics primitives and easy ways to read user interaction.

[John]

Personally I think namespaces tend to be quite cumbersome in most APIs. Java exposes a lot of things, which by default would be hidden in a namespace somewhere, like strings (java.lang.String), the Math class (java.lang.Math) and various other basic doodads .

Even with good autocomplete on the iPad, which has fairly limited screen real estate, you’ll end up with a lot more code spanning multiple lines. To me this means you either have to spend more time refactoring code to make it fit on a single line, or just put up with ugly and difficult to read multi-line statements, if-blocks and other control structures. While good programming practices dictate that namespaces help encapsulate API functionality in appropriate groups, I think it also sucks out the fun of rapid prototyping by requiring additional boilerplate code. I know that I detest having to import packages in Java, because it feels like the compiler should be smart enough to figure out what dependancies I need.

The namespace menu does sound nice, but autocomplete works just fine considering you only need to type the first 1-2 letters before the command you want will appear in the list. Also considering that there is likely to be only one version of a command, I would expect the editor to just come up with ellipse when I type e, and automatically insert codea.graphics.ellipse, if it came to that.

[JockM]

@Vega that was a bit of what I was getting at with my description of the mythical LövePad app. Codea’s IDE but with the Löve2d API.

I would love it if Codea had namespaced all their APIs, and from my experience it isn’t a novice vs amateur thing. Indeed @Simeon’s arguments have more to do with speed than experience level. It is a matter of subjective tastes. But since it is @Simeon’s and Dylan’s product they get to make that call.

Perhaps one day TLL with think about producing a Pro version of Codea. Or they will license the IDE portions of Codea to people interested in making something like “LövePad” (or the like).

But despite what people seemed to think, the lack of a codea namespace was never a major complaint. Making sure users code wouldn’t fail in nasty hidden ways was. And there is a solution for that.

[JockM]

@John yeah but Java is different because if you want to draw on the screen, the commands are part of the Graphics object. The object is a namespace in this case. In codea all the graphics primitives are just naked functions in the global namespace; and that is a very different thing.

As for your autocomple example, that is definitely not how Codea’s autocomplete works. If I type des Codea does not suggest body.destroy(), nor can I name any other IDE that does that.

The beauty of what I suggested is that it also educates the user as well. One of the tricks with any API is knowing what your options are. Code completion is great if you know what you want, but need to save effort. A menu shows you what you may not have known before.

[sim]

@JockM as I said before, we are always careful when designing the APIs. We hope that any library code that other people choose to use is appropriately namespaced.

If you look at the Processing project it has been running for many years, they have many libraries and no complaints regarding collisions.

[Bortels]

Woof. Wall of text.

I think perhaps part of the issue here is a confusion between tow similar things - Codea, the iPad app, and codea the tool to make iPad apps.

Codea the iPad app benefits from tenseness - because this on-screen keyboard is the most common means of input. That means a namespace prefix, even something short, is contraindicated - I agree with @frosty, it’d drive me nuts. If that means some level of pollution of the global namespace, so be it. If you’re using codea for “real” app writing, there’s a good chance you’re using a real keyboard, or programming outside of the codea IDE entirely (and if you’re not -consider it!) and dealing with namespaces is perhaps easier…

People might want different things from codea the iPad app development tool - but frankly, once you take the dive and grab the runtime and Xcode, you’re in big-boy land; if you don’t like the interface a library (like the codea runtime) supports, you can change it, and you should. But realize - you, and your needs, are a teensy tiny minority of codea users - don’t begrudge TLL for aiming their library design at what they think their most common users want or need. The mere fact that you are aware of namespace issues means you’re equipped to work with it (by defining your own namespace) - but you can’t say the same about beginners.

The runtime is free - you’re getting far, far more than you paid for there. (I’d say the same about codea the iPad app as well). If you don’t like how it works, change it, or use something else.

[Vega]

When in life, you find that you are arguing programming concepts against @Bortels, @Mark, @Frosty and @Simeon simultaneously, it is probably a good time to examine your own arguments for validity.

If I look at my own motivation for preferring everything boxed inside namespaces, it is not REALLY because I am worried about breaking code with API updates, it is more about my left-brained need for things to look organized and structured. Polluting the global namespace makes it feel sloppy to me.

However, it also makes Codea feel approachable, which is probably a very worthy tradeoff. The Codea learning curve is pretty mild, and it is likely due, somewhat, to not having to dig through namespaces to find what you are looking for. So I will concede now and just be happy with what we have.

About branching the API, @Bortels, that is exactly what I don’t want to do. My favorite thing about Codea is the ability to create code right on my iPad, hit run and instantly see it in action on my actual iPad. There exists a very structured, carefully namespaced game engine for creating IOS apps with LUA already, named for a Mexican beer. I’ll stick with Codea because I love the Codea app.

[JockM]

@Bortels I have answered all of your point somewhere or another in the (aptly put) “Wall of Text”, there is no point in reiterating them. But I have address the issue of difficulty, keyboards internal and external (I mostly use external), how to mitigate most concerns mentions, XCode vs Codea, etc.

I leave finding them as an intellectual exercises for the reader…

[Bortels]

I wonder if there’s not a way to have our cake and eat it too…

Perhaps some sort of “-- namespace” pragma (yes, giving comments functionality is a different sin) that would let advanced users override things and force an implicit namespace on things.

Classes help here, a bit - they make for easy encapsulation of your own code at least - but yes, it’s far from a perfect solution.

One thing that needs serious thought is library support - I think it may simply be the case that codea’s use has grown, in terms of scope, far beyond what were very reasonable expectations.

TLL - maybe its time for “codea pro”, that does all of this, but includes the nasty bits apple doesn’t want without approva (file i/o, raw sockets, and the other juicy bits)l, with the target being Xcode and the app store (ie it wouldn’t actually run directly on the iPad). This would presumably be codea, tweaked for the needs of people targeting app store… Dunno. This is a API split, which is undesirable, but there seems to be a clear desire on the part of many to “step up” to the big leagues.

[JockM]

@bortels Actually if TLL wanted there is a trivial way of dealing with it. By default every Codea API is either in namespace, or has a prefix.

Then in your code you could call simpleMode() (or something ideally better named) which would make copies of the functions in the global namespace. See the makeGlobal()function I described somewhere on page one. Actually for compatibility sake it “simpleMode” would be the default and you would make a call to disable it, but you get the point.

At that point there is a solution for everyone. “Codea Pro” need only be a mode of the existing product.

However @simeon has made it clear that he has no interest in this. Codea is exactly how he wants it to be. And fair enough it is his product.

If I just wanted to write Lua code for iOS there are better solutions than Codea — there is Wax and a port of Löve2d, Corona, or Moai. And that list is just Lua. There are lots of options for other languages. I do most of my iOS work in Objective-C.

I use Codea so I can write Lua code on the iPad.

My original point at the beginning is that Codea is more than the sum of its parts. While the editor offers code completion and the visual editors, there are better code editors for iOS now; The API is incomplete, non-orthogonal, polutes the global namespace, contains a nasty bug (right now); it isn’t using the latest version of Lua; etc. BUT right now it is the best option there is.

But I will be honest, sooner or later the iLuaBox people will include a real editor (and the graphics library that is in the works). Or someone will make LövePador there will be some other IDE (for Lua or some other language) on the iPad that isn’t as … tailor made for @simeon.

At the time there is a real choice, and I will probably choose the alternative.

(significantly edited to fix spelling errors, typos, grammer, and content rearranged to help readability and my point)

[Bortels]

Dunno - 8 bucks for codea, free runtime, active community, and now a track record of apps going to the app store - doesn’t sound like there’s a lot of wiggle room in there for someone to come in and make a real compelling case for switching. it would have to be a labor of love on the part of someone.

[JockM]

@Bortels Of course there is. QuickOffice didn’t prevent other word processors from making a good business on iOS, and the introduction of Pages didn’t put them out of business. iLuaBox didn’t prevent Codea, and Codea didn’t put them out of business.

One of the truisms of business is that a success in the marketplace doesn’t prevent others from entering the market, it encourages it. Why? Because the market has been validated.

The world of iPad hosted dev tools is in its infancy, I would not presume to suggest that it ends with Codea. Even if Codea becomes the big dog for Lua, not everyone wants to work in that language. I didn’t pick Codea because it was Lua, I picked it because it was the best option.

But mark my words in the next 12-18 months you are going to see IDEs for Python, JavaScript, Ruby, and other languages show up for iOS. It is not unreasonable to think that Corona or Moai might create an iPad resident version of their product at some point.

[toadkick]

Ricardo Quesada is adding JavaScript to Cocos2D. I predict that when he has done so some enterprising soul will release a Codea-like app that uses JavaScript, and exposes Cocos2D functionality. I know that would be an insta-buy for me. There is definitely room in this space for competition, and I welcome it.

[Inviso]

@JockM you said you use codea to write lua code on the iPad… That one I missed earlier… I think that is the point, where our discussion is not coming together… I see codea as a product in itself, yes it uses some kind of lua based language, but that’s not so important in my opinion…
If this would declare itself as a lua interpreter/IDE/editor, I would so perfectly understand your point of view…

[JockM]

@Inviso I just scrapped my original message and want to ask: how is Lua vs Lua-like germaine? If Codea used a custom language called CodeaScript I would still have the same core belief about namespaces — if CodeaScript were prototype based. And the API being non-orthogonal is true in any language.

As I said I didn’t pick Codea because it was Lua, but because it was the best out there

I guess I don’t get your point.

[sim]

@JockM Codea is not exactly how I want it to be. I just have a different view on this particular namespace issue, but I was very happy with the discussion surrounding it and it certainly made us think.

[bee]

Since @simeon rejected the idea of providing require() (or something similar to that, in order to load external code), I knew he got his own concept of Codea. At some points, I’m not quite agree with him either. For example, he intermix visual and code which in my opinion should be separated clearly. But I also must admit that Codea is still the best on-device coding app. I thank Simeon and TLL for that. There’s nothing more I can do, Codea is his “pet” anyway. Yes, I still suggest some things once in a while, but I never expect they would be seriously considered. So, I just accept Codea as the way it is and enjoy the app.