Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Desktop Version?

edited May 2012 in Suggestions Posts: 141

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.

Tagged:
«1

Comments

  • Posts: 179

    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.

  • DylanDylan Admin Mod
    Posts: 121

    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!

  • Posts: 141

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

  • edited May 2012 Posts: 580

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

  • SimeonSimeon Admin Mod
    Posts: 4,998

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

  • Posts: 141

    @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
    used fill(NONE) (or fill(TRANSPARENT)) instead of noFill(); 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

  • SimeonSimeon Admin Mod
    Posts: 4,998

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

  • Posts: 141

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

  • Posts: 141

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

  • SimeonSimeon Admin Mod
    Posts: 4,998

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

  • Posts: 141

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

  • Posts: 159

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

  • edited May 2012 Posts: 141

    @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 functions
    • string.in front of string functions
    • math.in front of math functions
    • os.in front of OS level functions
    • etc

    Assuming 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

  • Posts: 447

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

  • edited May 2012 Posts: 141

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

  • SimeonSimeon Admin Mod
    edited May 2012 Posts: 4,998

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

  • Posts: 141

    @simeon We are probably just about at the point of diminishing returns on this conversation, but I here goes:

    1. As I said before Codea isn't just a tool for prototyping. The minute you released Cargo-Bot and let people make app store apps with Codea, it stopped being just about that. It stopped being about that well before that point, but Cargo Bot is a clear line.

      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.

    2. Namespaces were invented for a reason, because while it might be mildly annoying — we can argue about that elsewhere — but they are vital. How else can you build software of any size or complexity? Do you know what we did before namespaces? We invented them, at first with simple prefixes, and then later with language facilities.

      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.

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

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

  • Posts: 447

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

  • edited May 2012 Posts: 580

    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.

  • Posts: 141

    @ruilov Oh I agree, and think Codea should put everything in a namespace. I just have never had much hope that they will be. Simeon and Dylan are the ones who get to make that call, and I doubt I can change their minds.

    As to your question it is very easy:

    for k,v in pairs(_G) do
        if type(v) == "function" then
            print(k .. " is a function")
        end
    end

    If you wanted to see if any of them were changed you would make a table of all the functions and their names, and then compare the references at a later point (ie the v values).

    I have a bit of JavaScript code I wrote to make a snapshot of every global variable name I am using, and then run it periodically to make sure I am not accidentally creating new ones (ie I forgot to type var somewhere). The exact same thing could be done in Lua.

    Prototype languages are exceptionally powerful, because you can introspect the runtime environment at runtime. With a bit of code attached to the metatable it would be possible to prevent people from replacing any existing function (or just specific ones).

  • edited May 2012 Posts: 141

    @toadkick there are a couple of ways Codea could accomodate backwards compatibility if they decided to use a prefix or a namespace:

    1. They could wrap all legacy calls automatically, and then any new APIs would be only in the namespace or prefix. This would be fairly easy for Codea to implement and break the least amount of code

    2. They could add a new API (call it codea.enableLegacy()) that would reflect the Codea namespace and then make wrappers in the global namespace, at runtime.

    3. They could have a legacy.lua (or simple.lua) file that contained global namespace wrappers for all the legacy APIs

    Option #3 would probably be the best compromise, especially once shared files have been implemented.

  • edited May 2012 Posts: 580

    Yeah, something like #2 is what I had in mind. Actually I'm not sure I understand how #3 would work...would I just add the legacy.lua file to my project if I wanted legacy support? If so, how would I obtain that file? In that case, it doesn't seem much different than #2...in fact legacy.lua could just be built into Codea, and all codea.enableLegacy() would do would just be to run that file. I would prefer #2 because it would generally be less maintenance for me. Although frankly a) I would never use it and b) I doubt TLL will change their minds about this anyway, so I guess it's a moot point.

  • Posts: 447

    Cool, so depending on how the lib importing feature is implemented you might be able write your own defensive lib importing function, that makes sure that anything that the new lib creates in the global namespace gets assigned to another namespace of your own making. Something similar to "import as" or whatever the idiomatic construct is in other languages. Simeon this may be a good compromise which wouldnt affect anyone that doesnt care but not sure if it fits with what you have in mind for lib importing.

    I'm actually fine with built-in codea apis being global. If a function is important enough to be built into the environment, then i'm ok giving it the special power of owning a global name. And i trust TLL to be thoughtful about the design of those apis a lot more than i'd trust a user library.

  • Posts: 141

    To complete this though this handy function would "unravel" a namespace (ie a table) and make global namespace versions of all the functions:

    function makeGlobal(t)
        for k,v in pairs(t) do
            if type(v) == "function" then
                _G[k]  = v;
            end
        end
    end

    If you called makeGlobal(table) then you could then call insert(myTable, aValue) instead of table.insert(myTable, aValue)

    With a bit of metatable mojo you could make global variables that worked this way as well.

    I want to make it very very (very!) clear that I don't encourage doing this (I'm looking at you @simeon ;), but just wanted to underscore just how easy it would be.

  • edited May 2012 Posts: 580

    I also want to make it clear that I'm not trying to coerce @simeon into making these changes either. If nothing else I think this is a healthy discussion and a good thought exercise :)

  • edited May 2012 Posts: 141

    @toadkick In the case of #3 the legacy.lua file would be included with Codea, and be added to your project via the code sharing feature @simeon has said he is planning. The point of it would be that you wouldn't have to make a code change (just a project one) and it might be more obvious what is going on to novice users.

    @ruilov That is great so long as nobody every puts anything in the global namespace. Consider my oval()example. I use a library that defines oval()and then in a later version of Codea implements oval(). I then add another library that expects to be using Codeas oval(). If the signatures (IE the parameters they take) do not match identically, and the functions do not behave identically then you have a hard to diagnose bug on your hands.

    To my mind every bit of external code should be in a namespace. It is only the user's code that (at their discretion) add to the global namespace.

  • edited May 2012 Posts: 580

    @JockM oh yeah, that makes sense re: #3. I agree that a project change would be preferable to a code change if possible.

    Also I agree about your namespace philosophy regarding external/library code and user code, that's how I usually prefer things to be as well.

  • SimeonSimeon Admin Mod
    Posts: 4,998

    @JockM regardless of the fact that Cargo-Bot was produced with Codea, my focus is still on creating a fast, visual prototyping language. Think of Codea as its own language with its own primitives. You wouldn't store for loops, keywords and table in a "lua" namespace — that just wouldn't make sense. Neither would you store the core graphics functions in a namespace.

    I like that you are passionate about your argument. I want to assure you that we certainly don't plan to throw everything into the global namespace — we spend a lot of time thinking about the names, placement, and design of Codea's features.

    One of the reasons I stopped using löve and started using Processing was precisely because I liked the "immediateness" of Processing's API. There was no digging. I feel that setting the right emotional tone is important to being creative, and an API can hinder that if it is too formal, or buried in namespaces.

    Emotion plays a big part in coding for me (just like in sketching or painting), so having a design that feels right is very important.

  • Posts: 141

    @simeon OK lets put aside any passion and arguments about best practices aside. I think you are wrong, but that is not the point.

    It is no use crying over spilt milk, but based on your intent, you probably would have been better off using processing, or making your own language. Because Lua seems simple and direct but it is one of the more powerful languages out there, and contains a seemingly never-ending number of ways for users to get themselves into lots and lots of trouble.

    I have outlined a very real scenario about global namespace collision:

    • Library A is written to Codea 1.α, implements function oval() and is included in all of the users projects
    • Codea 1.β introduces function oval() with a different signature from Library A
    • Library B is written to expect Codea 1.β's oval() and is included in a new project with Library A

    The result of this is code that is going to fail when Library B calls oval(). The failure might be the code crashing, or it could be that the ovals don't look quite right, or look spectacularly wrong.

    This will be hard and non-obvious to the use to diagnose and deal with.

    So please, implement some kind of check to see if the code in a project redefines and of Codea's APIs, and gives a warning. It has nothing to do with the rightness or wrongness of my or your arguments, it is simple and easy to do, and it is to the benefit of yourself and to your users.

    If you want, I will write the Lua code for you and tell you the two points it should be run. Namespaces vs Globals can be seen as a matter of opinion. But this isn't, if you are (in your own words) "polluting the global namespace" and (in effect) encouraging your users to do the same; then it is wrong not to at least catch this very real issue.

    If you don't then you are wrong.

  • Posts: 141

    @simeon

    @JockM regardless of the fact that Cargo-Bot was produced with Codea,
    my focus is still on creating a fast, visual prototyping language.

    Then you have a bit of an impedance mismatch between how you are marketing Codea, and how you are describing it in the forums.

    In iTunes you say "Codea lets you create games and simulations — or just about any visual idea you have. Turn your thoughts into interactive creations that make use of iPad features like Multi-Touch and the accelerometer." And you (rightfully) brag about CargoBot and Open Sourcing the back end, and talking about your use of Lua.

    That is a very different message than (paraphrasing) "Codea is a way to make prototypes everything else is secondary", which is seemingly what you are saying here.

    Neither is wrong, both are legitimate, but you need to get your message clear. If the primary purpose is prototypes then say that on iTunes and all your other messaging. I don't care which, but right now you are giving off mixed messages.

  • edited May 2012 Posts: 580

    I think this is somewhat relevant to the impedence mismatch that @JockM describes: http://www.standalone-sysadmin.com/blog/2012/05/engineeringinfrastructures/

    Now that the backend is open sourced, and people can use Codea to publish apps on the app store, they will use Codea for that purpose. And once there is a method in place to share libraries, it is inevitable that the situation @JockM describes will occur.

    Though it was intended for Codea to be a prototyping tool initially, more and more users are not perceiving that to be the case, and the mixed messaging certainly doesn't help. I think at some point, if Codea becomes a runaway success, more and more people will be clamoring for things like a cleaner API because they are getting bitten by issues related to this. Or, they'll simply stop using Codea.

    On a different note, I must pick a nit now:

    "Neither would you store the core graphics functions in a namespace" - actually, I would.

    Graphics are not a part of the Lua language. Syntax and constructs such as for loops, tables, and keyword don't belong in a namespace because they are the language. Everything else is libraries, even a lot of the functionality that comes with Lua (@JockM already mentioned several of the provided libraries in a post above). Arguably, most general-purpose languages do make a distinction between the language itself and the functionality afforded by the language. Take C++ for example, which provides stdio, and collection templates like vector or list, which are all kept in the "std" namespace. Or the iOS/Mac SDKs with Objective-C, that prefix every class and function with NS*. They are functionality commonly provided with the language, but they are arguably not language constructs.

  • DylanDylan Admin Mod
    Posts: 121

    @JockM
    Your argument seems to stem from the use of libraries. Codea wasn't intended to be used with libraries, though we are thinking about adding them in the form of imported projects.

    Still, as I think was mentioned, the global namespace is reserved for Codea's built in functions. If a "library" adds functions to the global namespace, that is a bug and the results are undefined.

    Simeon did mention to me that you could write a function that essentially does

       codea = copy(_G)
    

    where copy is a function that does a shallow copy of all the functions from _G into a new table. If codea polluting the global namespace really irks you, you can always do this in your main file and just use the namespace yourself.

  • Posts: 141

    @Simeon

    Neither would you store the core graphics functions in a namespace

    To echo what @toadkicker, I would. And both Java and .Net put everything in a namespace. Now they happen to have a cleaner way of handling namespaces than Lua does, but the point remains.

  • DylanDylan Admin Mod
    Posts: 121

    @toadkick We have stated before that we consider Codea to be a dialect of Lua more than an extension of it. We are willing to modify the language parser/interpreter in the future if we have a good enough reason. This is the same reason why we consider the global namespace to be fine for Codea to pollute.

    I guess to be fair we should either disallow, or produce a warning when a function of the same name as a Codea function is defined (similarly to how "local" is a reserved word in the language and you cant use it as a function name).

  • Posts: 141

    @Dylan I think polluting the global namespace is a bad idea, but I will call back to two points I keep making: I put all my own code in namespaces and I don't expect the Codea API to change vis a vis namespaces. I just think you guys are making a mistake using the global namespace for your API. I am not advocating for it to change, nor do I need it to change.

    However I am pointing out a very real risk that is going to happen sooner or later. I also provided a easy thing to implement to help people detect if they do trigger it. If you ignore this and do nothing, then I have no problem calling that decision foolish.

    The other point is that it matters very little what your intentions are for your product. Once you release it into the wild, it is going to be used in lots of ways you never intend. Most of my friends who are engineers and iPad users own a copy of Codea. And none of us are using it in the highly disposable slap-dash way @Simeon describes. And we are sharing libraries with each other.

    So you may not have intended people to use libraries, but they are.

    And I want to reiterate that I hold the two of you in high esteem and love Codea.

  • SimeonSimeon Admin Mod
    edited May 2012 Posts: 4,998

    @JockM I strongly believe that Codea would be far less attractive to use if we were to encapsulate its core graphics abilities within a namespace. It's the same reason I stopped using löve. (Löve is an excellent library, but it inhibited my creativity more than Processing.)

    Your example of Java and .NET is not realistic. Those are general purpose, all-encompassing libraries and use namespaces appropriate to their scope. In Codea, functions like sprite, ellipse, sound and so on, are primitives of the language. They are so fundamental that Codea does not really make sense without them.

    Codea is modelled on the Processing API, which uses the global namespace for these things (to good effect, I think. It quickly became my favourite programming tool because of this.)

  • edited May 2012 Posts: 580

    For my part, modifying the parser/interpreter would be an instant dealbreaker for me. Part of my attraction to Codea is that it provides a great playground for experimenting with Lua. If the work I did on Codea could not be transferred elsewhere, it becomes a lot less attractive. I find it interesting that you would consider doing that, but are adamant against doing something that the language provides out of the box, that would add value to many programmers who are using Codea.

    Anyway, at the risk of making a liar out of myself and seeming like I am trying to coerce you guys into doing something you don't want to do or taking Codea in a direction you don't want it to go in, I'll cease my arguments here. I think the finer points have been expressed sufficiently, and there's not really much else to say.

    So, I just want to conclude by saying that I love Codea and think it is a wonderful tool, and I'm really glad you guys have worked so hard to get it out there.

  • DylanDylan Admin Mod
    Posts: 121

    @JockM

    Ok. I agree that silently failing when someone overwrites a codea function is bad, and that eventually someone will shoot themselves in the foot with it. However I think putting codea in a namespace ultimately makes the tool less useful. I agree with you that in general its a good idea for code to be in namespaces.

    Processing pollutes the "global" namespace freely (technically the functions are in a package, but it imports them into the file namespace automatically). Javascript has plenty of global APIs. I think its just inevitable that as you move toward domain specific languages, they will generally become "messier" in order to make what they intended to do easier at the expense of strong engineering principals.

  • SimeonSimeon Admin Mod
    edited May 2012 Posts: 4,998

    "Once you release it into the wild, it is going to be used in lots of ways you never intend."

    @JockM That's a very good point. I think your suggestion of having a system that warns you when you override Codea's API would be a good thing.

  • SimeonSimeon Admin Mod
    Posts: 4,998

    Please know that I think all your arguments are great and they have really gotten us to recognize this as a potential issue.

  • Posts: 141

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

  • SimeonSimeon Admin Mod
    edited May 2012 Posts: 4,998

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

  • Posts: 80

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

  • Posts: 141

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

  • edited May 2012 Posts: 141

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

  • SimeonSimeon Admin Mod
    Posts: 4,998

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

  • Posts: 141

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

  • Posts: 141

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

  • SimeonSimeon Admin Mod
    Posts: 4,998

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

  • Posts: 141

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

Sign In or Register to comment.