It looks like you're new here. If you want to get involved, click one of these buttons!
So - I've mentioned before that a ton of the value in Codea isn't Lua - I can code in Lua for free elsewhere (or even on the iPad if I pay apple to be a dev) - the value is in the libraries twolivesleft adds, and the editor. It's self-hosting that makes Codea exciting - being able to do an app from start to finish on the same platform I run it on.
I'd pay for that same environment, again, in other languages - and I bet there are coders out there who have said "ooh, I want that... But I'm a YOUR-FAVORITE-LANGUAGE-HERE programmer, I dont want to learn Lua". I mean, I like Lua a lot, but I still think in perl - you want another 8 (or more) bucks from me, give me Codea-with-perl. I'm sure all of the modern interpreted languages are the same in this regard.
This is where you come in maybe.
What I envision is pretty simple - a local web server, maybe only answering on localhost if necessary, and an editor that can make/edit files in its document root. Js and maybe CSS syntax hilighting in the editor. Let the actual code execution happen in mobile safari where apple doesn't care! We have the parts of this already in other apps - editors, and local servers - just put me in a box with a nice bow on top. It shouldn't even phase apple, either, because you aren't even running outside code - ever!
Someone is going to do this, soon I expect. I'd rather it be you guys. Or me :-) but I know how hard a good robust editor is to make. (I've tried this with Bespin, but the local web server at the same time as the browser is what breaks me. I am NOT sure we can even multitask like that... Yet. You might need to not use safari proper, dunno)
Instead of putting JS into Codea, why not 2LL make Codea-for-JS? :)
Maybe an in-app Thing where everyone can buy other programming languages, and then a language is set for every projekt?
Textastic is good editor and can run js.
Js would run through a web view, so you wouldn't get the OpenGL based renderer.
FWIW, as a non-programming neophyte I like the ease and simplicity of lua and the fact that the code is terse (no need to declare datatypes, no need to have a semi-colon at the end of every line, etc.).
Codea's graphic functions, editing interface and lua seem a perfect match for the iPad. Using Codea (and lua) I'm constantly amazed at how quickly and fluidly I'm able to tinker with an idea.
Plus, given all the google progress in this direction, I would predict that OpenGL or WebGL will be integrated within a version or two. In the meantime you could easily integrate paper.js, or Processing code.
Frankly - canvas isn't bad at all, and web kit has a lot of the OpenGL-ish spice - transforms, and so on. Really, my main issues with js are a lack of self-hosting, which this would solve nicely, and speed. Bad past experiences with cross-browser issues. But again - I would trade those for self-hosting and a lack of Apple interfering, and the speed and features are always improving.
As an aside: does a web view come with js processing? If so - my "let us render HTML and svg" suggestion takes on added functionality. It's silly to have to say "to info from the web, you'd need to write it in another language, and render that to an image you won't use..." but meh - maybe that sort of silly is what we need to illustrate to apple this policy needs modification.
AND you nicely incorporate my web server and all the HTTP sexiness!
Codea might as well make their own language by combining languages. I'd be fine with that. Right now, I use Textastic to program things like websites. I ran across this video righ here that allows you to code apps and install them on your iPad. I'm away from my mac and haven't set up server, so somebody should check it out.
Different languages? Im leaning to no. Too complex in my opinion. Stick with Lua and add to it. It's and amazing language.
You can run Processing.js programs on the iPad.
http://www.jepstone.net/HiperPad (a primitive coding environment)
http://luckybite.com/iprocessing/ (makes processing.js programs install like native apps)
Wow! I hadn't heard of Processing.js before. Looks, frankly, amazing. It is quite possible that if I'd come across it a few months ago, I wouldn't have started on Codea (I was looking for a processing-like thing for the iPad). Now that I have, and invested a fair amount of time and effort in learning it, then I'm reluctant to go back.
@Andrew we're currently working on extracting the engine from Codea to release as open source. Hopefully with a command-line Mac OS X tool to run project bundles, and of course, an iOS example app that runs .codea bundles.
Edit: While Mac OS X support should be fairly straight forward I imagine Windows and Linux will be fairly significant undertakings.
I'm vaguely aware of that, and it would be great to have.
Don't get me wrong, I think Codea is absolutely fantastic, and as I get more dependent on my iPad for "doing stuff" then my own issues with being tied to that platform become more and more ephemeral. However, for the reasons described above, I can't just consider my own use of my code - I want others to be able to use it, and can't assume that they have an iPad.
Web based would be best, but it's also trickiest for the reasons you mention.
(Project wiki: https://github.com/kripken/emscripten/wiki)
So it's possible. The hardest bit would be getting high performance graphics rendering across browsers. My bet would be on WebGL, but at the moment that's limited to Chrome.
I'd be happy with low performance for the time-being (Firefox claims WebGL - and at a higher level of compliance than Chrome -, though after installing the necessary library I found it crashed FF a couple of times). Moreover, as Codea is essentially a 2D system (despite my best efforts), it might be possible to do the non-mesh stuff without WebGL.
It would be possible to rewrite. Processing does this and offers a few different renderers.
WebGL offers the easiest path in terms of porting though, as the shaders and engine design could largely be used as-is.
These are all thoughts for after the initial open source release, though. Maybe someone will take it upon themselves to use the source code to create a web version, or support some other platform — that would be the best outcome. We don't have the resources to maintain that many branches.
So, I think Lua is a great choice for Codea.
Plus, compared to Codea, performance sucks - especially graphical. that's changing, but meh.
"And there's still no good way to do the dev on the ipad. " -@Bortels
I like to use Textastic A LOT. It may not be the best coder, but it is wonderful in my opinion.
As you can see in the iProcessing demo video, it is struggling with a few solid filled circles. Doing anything remotely interesting would probably cause significant slowdowns.
Just an idea @Dylan - You could have an in-app preview and then say "Test in safari". Safari can read the app's files if you allow it, right? But anyways, you would make an engine for the Lua part of it. But first, I really want sprite packs.
And working out sockets with apple
guys, check out www.becomekodiak.com - it has PHP and looks pretty neat
cute. I'm taking a look, will report back.
Their keyboard is worth a look - I like the five-way keys.
This discussion is rather old, but i'll add my opinion of casual programmer. A few days ago i wrote in another discussion:
So my wish would be: keep focused on improving LUA in CODEA, add libraries and fonctionnality but don't go to other langages, LUA is fine. Just my opinion.