Other languages! Especially JavaScript

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.

But, as much as I hate to say it, JavaScript has a special place here - it has special dispensation, apparently, from apple, and a good version is built-in. I’d rather program in lua than js, but I’d rather have network access and apple not freaking out about what we write than lua (or perl or whatever). And I can do that, today, right now (and have). What I don’t have for js right now is… A self-hosted dev environment.

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 :slight_smile: 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)

PS. For the local web server, node.js would be awesome - but could end up opening up the same sorts of external unreviewed code loading issues you have now. Or - maybe not? It’s JavaScript. But it’s also a different engine. Worth considering.

Instead of putting JS into Codea, why not 2LL make Codea-for-JS? :slight_smile:

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.

I agree with @Bortels. An HTML5/JavaScript version would be VERY interesting to both kids and professional web developers. It would also neatly sidestep any sharing issues with apple, as you would just go to web pages in their own browser.

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.

-P

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.

I also think, as @alveda suggests, the potential user base for this may be an order of magnitude bigger than for lua. JavaScript is hot right now. And I agree -we’ll see webgl in mobile safari soon (ipad3 I’m hoping)… And that would be “free” functionality for you.

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’re missing the point, Zoyt - Apple’s rules seem to be different for javascript (or at least their javascript in mobile safari). The idea was to try to work around their restrictions by doing it the way they seem to want. It does us no good to, say, add sockets to lua if apple is just going to reject it.

You can run Processing.js programs on the iPad.

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.

However, it does make me ponder whether or not one could write a Codea.js that could take a Codea program and convert it to javascript to be truly cross-platform. One couldn’t do everything - touches would be limited to single touch and gravitational stuff would be out - but it would solve one of my “problems” with Codea: the restriction to the iPad. This is problematic in two ways: I’m developing applications with Codea for use in my lectures, where I use an iPad. As they run on the iPad, I can demonstrate them. But then students without an iPad can’t download them and play with them (LoveCodify seems a little complicated for this). I’d also like to be able to write some similar apps for some other educators who aren’t using iPads but laptops. Since I now know Codea quite well, and have a fairly large library of easily-reusable code, I’d like to do that in Codea. But then again I’d like to drop the files onto a non-iPad and know that they are usable.

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

What impressed me most in my brief glance at iProcessing.js was that it wasn’t at the engine level but at the script level. It looks as though it takes a Processing program and then reinterprets it as javascript code. So I had in mind a much smaller project than extracting the engine from Codea: simply a lua interpreter in javascript wrapped around with a setup and draw function and a simplified touch call.

As a hacker, not a programmer, having to learn a new language each time I want to do a new thing is a bit of a hassle. So far, I’ve had to learn snatches of Perl, PHP, python, ruby, javascript, java (aka processing), lua, c, c++, TeX just so that I can get something working that I want to use. Of those, I guess I feel okay with Perl, TeX, and probably now Lua (I’m just waiting for a few free days to see what I can do with LuaTeX …). So the idea of being able to take, in this case, a Processing (java) program and directly drop it into a completely different context is fantastic. I would really love to be able to take a Codea program (perhaps with a little modification for the reduced environment) and drop it onto the web.

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.

Interestingly, there are a few Lua interpreters written in Javascript. One of them is here:

http://syntensity.com/static/lua.html

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

Your right. Mabey JavaScript/HTML5 would work but that would be a hassle to put together in my opinion. Hmm. There are still other features I’d like first.