Taking Corona SDK To The Next Level by Jesse Warden

Solar2D General Questions/Discussion
#21

I have the article open to read thoroughly, but after seeing how long it was I ran down and looked at the sections that caught my eye.

So I’ll have more to say later, but two things stuck out that, to me, make it hard to read the rest of it:

  1. Dump Lua. I started programming assembly language in 1984 and since then have at least sampled most “popular” language, but Corona was my first exposure to Lua and I can’t believe it took so long for me to find it. CL could change just about any part of the framework and I’d adapt, but if they dumped Lua I’d be gone the next second and would never look back. It, more than just about anything, exemplifies the “get it done fast” part of Corona SDK.
     

  2. Adopt Eclipse as an IDE. I fully agree that Corona Labs is in increasing danger of being overlooked because it doesn’t have an IDE, but adopting something like Eclipse would be WORSE than nothing. Seriously. Eclipse and that ilk are everything that’s wrong with programming. It’s not 1990 anymore and I shouldn’t have to develop like it was. *

To say that I disagree with those points isn’t going far enough. :slight_smile:

To anyone who hasn’t seen the article, click the link above and give it a go. While I disagree (I need a stronger word there!) with some of it, many of the points were read with shouts of “Preach it!” in my head.

 Jay

* Outlaw isn’t the kind of IDE CL should adopt either, in case anyone thought I was being biased toward my own product.

#22

J.A., this is the kind of feedback I like to hear. I’m making the glaring assumption here long term programmers who’ve experienced both compiled and interpreted/variant/functional languages would want to retreat back to strong-typing when things got larger (hence one of the reasons Unity using C#). So hearing the love for Lua is… confusing, but solvable.

For example, go here:

http://www.typescriptlang.org/Playground/

Visualize in your mind this on the left:

public class Person { public string firstName; public string lastName; public Person(string fn, string ln) { firstName = fn; lastName = ln; } public string getFormattedName() { return lastName + ", " + firstName; } } public class PersonView extends display.Container { public Person data; public PersonView(Person p) { data = p; } }

And the generated Lua on the right… which you could easily write yourself as you always do:

local Person = {} function Person:new() local person = {} person.firstName = nil person.lastName = nil function person:getFormattedName() return self.lastName .. ", " .. self.firstName end return person end return Person local PersonView = {} function PersonView:new(data) local view = display.newContainer() view.person = data return view end return PersonView

Much like TypeScript and CoffeeScript do, we’d still have access to, or the ability to bypass, C#. I’m making the assumption here they wouldn’t have to start from scratch on some LVVM like compiler to get C# to compile down to Lua, maybe with some CLR help… or not.

Regarding Eclipse, yeah, I hate it too, but if you want in the Enterprise club, you use Eclipse, they let you in. If you in, you can use their money to fund additional development. I’m sure I hear you saying, “deal with the devil, bro”… I’m with you there, too. I just don’t have enough transparency into their funding, so this is one option. I think a lot of us like the fact we can hit Save in our text editors and immediately see results vs. the “launching” and “compiling” nonsense that is Eclipse.

#23

I agree wholeheartedly that as the project and team gets bigger, strongly typed languages are easier to manage. Lua has a lot missing if you are used to a modern feature rich language like Java or C#… as example, it doesn’t even have bitwise operators and don’t even get me started on the major gap left by a lack of clear approach to OO has created… oh boy!

I’d say it is easy to say “Eclipse Sux balls” but what would you recommend and point to for an IDE that is truly better… nothing I’ve seen or tried for Corona even offers half of what developers get within Microsoft or Java’s development tools. Even Visual Studio had its crictics and there have been times when that platform was despised even more than Eclipse.

I’ve seen some tool vendors strip down Eclipse and build an ide on its base that is actually very, very nice - I’m not sure what you are saying about complile and launch approach - for languages like Java and J2EE if you save, it compiles instantly and gives you immediate feedback in the running container. The live code re-reading is more a feature of the in place VM in the simulator than the language per se.

I’d agree a base/generic IDE is needed… perhaps something that 3rd parties can extend?

G

#24

IntelliJ on PC. If you’re on Mac, Sublime with 10 billion plugins. None of which are where we need them to be yet.

I’m a consultant; I work on the worst code bases known to mankind for my day job; if there is a way to slow language X down in Eclipse, you’ll be sure that developers figured out how, and I’m working on that project. But yes, even on reasonably coded Flash/Flex/Java projects, Eclipse still adds a ton of overhead that just doesn’t jive with the quickness that is the whole Corona dev experience.

So far the community extensions in Sublime for JavaScript, CSS, and HTML are insanely awesome, same for IntelliJ (thought not as fast paced nor as progressive). Still, it’d be nice to have one “built for us”, even if they based it on ItelliJ (like WebStorm just being the web parts of IntelliJ) or some fork of Sublime/TextMate, etc.

#25

It’s impossible to please everyone with one product.   I know you enterprise and large project types would prefer a language that is OO and strongly typed, but some of us little guys just want to get things done (or just want to play and have fun).   

That’s what I love about Corona.   I can generate fun little apps quickly and easily.   So, maybe there should be a fork at some point.   At some version, let the little guys like me keep playing with Lua and then offer up an Enterprise version for those who want to move on.  Heck, people are still using Visual Basic 6 is still “supported” (http://msdn.microsoft.com/en-us/vstudio/ms788708.aspx) by Microsoft and it’s been more than a decade since it came out.

Even though Corona is being improved all the time, I’d be happy if I could only use the features that we have today for the next few years.   Although you can’t do everything, you can still do an infinite number of things!

#26

Really interesting ideas in that blog post!

I’m assuming “more robust programming” means OOP? 

Lua provides a lot of mechanics but as Jesse points out standardization helps in the face of flexibility.

In terms of class mechanics, I’ve looked at several libraries including middleclass. The hard part is balancing how much you want to add class-like behavior and how much you want to preserve Lua’s innate metatable capabilities. One such balancing act is to what extent do you want to still allow “__index” metamethod to work when it’s already serving double-duty to support OOP.

Our attempt at this balance is encapsulated in CoronaPrototype. It’s still “beta”, which is why there’s minimal documentation. We still want the flexibility to break things as we tune it. However, you might have noticed some interesting methods on our docs index (http://docs.coronalabs.com/api/index.html). 

The alternative is that the constructor “attaches” the methods as in the Person example above. This does involve an initialization penalty and some level of rigidity in how you achieve inheritance. I’ve gone back and forth but I think prototypes (metamethod-style) work well, as long as you favor composition over inheritance to minimize deep class hierarchies. 

On the performance front, Terra looks incredibly promising. It’s a low-level counterpart to Lua (http://terralang.org/) and it was designed to let Lua do what it does best while providing a high performance (low-level) counterpart. It has C+±template like capabiilties as well as ways to mimic class semantics that, at least on the surface, look like very interesting language features that may satisfy those looking for static typing features. 

One of the great things about Lua is the level in which you can embrace duck-typing, the idea that behaviors and interfaces matter more than static typing. This model fits well with prototype-based OOP mechanisms, which is reminiscent of AS2 and which is what Lua enables via metatables.

One of the Corona-isms we’ve had is to prefer factory methods over class constructors. I think there’s going to be tension here in terms of API consistency.

Also, it seems to be more Lua-like to pass a table to a constructor that gets “promoted” to an object. For example, the ‘Person’ constructor could have easily taken a Lua table where the caller sets the ‘firstName’ property:

[lua]

function Person:new( o )

    local person = o or {}

    – Promote to object

    function person:getFormattedName()

        return self.lastName … ", " … self.firstName

    end

    return person

end

local p = Person:new{ firstName=“Foo”, lastName=“Bar” }

[/lua]

#27

Just wanted to say (slightly off-topic) - good to see you on the forums Jesse. Your articles have always interested me (particularly the FSM implementation), I may not always agree with what you say but I’m happy to have an experienced developer here sharing his views.

On the OOP side of things - ok the lack of an “official” method can be offputting, but it’s not that hard to build a flexible yet robust OOP implementation. Thanks to David McCuskey I’ve really got a hang of metatables and love the flexibility it provides. I’ve just ported an advanced Trigger/Messaging system from C++ (from Matt Buckland’s excellent Programming Game AI By Example) with fairly deep class inheritance, and Lua/Corona is handling it marvellously.

#28

Fantastic article. I would love an official Corona OOP way. In the beginning it was my biggest obstacle getting into Corona and wanting to do things properly.

#29

The OOP isn’t the problem. I’m fine with the Lua 5.2 closure way, and the way Walter outlined his is fine too.

It’s more:

  • we need more widgets

  • we need better IDE support, particularly around refactoring

My article cited 3, but I think everyone here agrees with those 2. To support more widgets, we need, at the very least, support for more lifecycle events from DisplayObjects, preferably a “removed”. Developers would rather call “removeSelf” vs. a “destroy” convention method which causes problems when you need to do massive clean up, especially in nested controls. Once you do that, making more widgets is easier. At that point, yes even using Lua, one could make some pretty large applications. Right now, it’s quite burdensome to build everything myself. Thank God for TableView at least.

While Lua does allow quicker iteration, the lack of refactoring support forces you into a flatter package structure, and a rock solid set of conventions on how access your class API’s. Changing a method, or moving classes to another package, currently in Lua, is pretty brutal. I get I could rely on my unit tests for that, but a simple “right click on class and move to another package” would be ideal and significantly speed up development in later parts of the cycle.

#30

Jesse really nailed it.

Lua is great for utilities but anything serious it is a PIA. I think c# is a great idea, it’s a really good language with many automations and easy to
Learn. It isn’t lua isn’t but it isn’t lua limited either.

The components are a real issue. It eliminates the ability to do business apps. Between the incomplete and flakey widgets it is further made difficult by the lack of native widgets. I really like Jesse’s outline of the direction for widgets but wonder since Corona is all openGL if there is possibility of a good widget set.

One thing Jesse didn’t mention that I think is a big issue is SDK support. Even when the plugin marketplace makes it out, Corona will always be playing catch up to support popular and useful sdks. With less than 1% of the corona community having the ability to make plugins and of that probably 1% or less of them interested in making plugins for that community it is going to be real difficult and slow to get access to the sdks we want and need. Most of us don’t want to program in a language for iOS, android, Mac sim, windows sim and lua bridging to make the plugins ourselves.

True oop is a pretty big deal and the fact you have to do two implementations with lua to pretend it stinks. You have one decent way with your own objects then need to use another when working with display objects as they can’t use meta tables. Anything larger than the tutorial projects are more manageable using OOP.

These are some of the reasons I started messing with Unity and Cocos2DX. I still have six years or
so on my Corona license but not sure it is where I want to be at this point.

#31

@cspence, as jesse just mentioned, OOP support is fine. What could be better are more standardized conventions which is what I think you’re getting at. 

With OOP, you can also use composition/delegation instead of inheritance. What would really help is better lifetime semantics.

@jesterxl, about the lifetime semantics, how about adding an event that gets dispatched to the object when it is removed (e.g. when removeSelf() is called)?

#32

@walter fine maybe if you stretch but not great and certainly not good. It’s a kludge which makes projects more complex to work on. From our discussions I believe he feels the same way.

#33

@cspence, what are you trying to do that’s a kludge? Inheritance vs composition are both fine ways of doing things. And in fact, the Design Pattern folks recommend favoring the latter.

#34

@walter I need to look at your post in more detail when I get home (on iPhone now) as I use a different way of doing it. It isn’t just OOP for me but that is something that really irks me. There are lots of things in lua I do like and appreciate. Meta tables for oop is a hack and isn’t supported on display objects so you have to use two oop styles in your code.

It also means everyone’s code is written completely different as there are 30 ways to do oop in lua and many people don’t bother. Makes code re-use a big PIA.

#35

Walter, yeah, exactly.

Getting a “removed” dispatched from a Group AND Container, do not care about the rest (line, rect, image, etc)

uses: clean up of components (event listeners, global or dependent object references to nil, etc). We can’t really override removeSelf to do this ourselves. Additionally, it’d be nice if this bubbles by default like touch events. If so, we can have the option to catch it on stage. If that’s too hard, then simply the group itself is fine.

To be inline with the semantics, it’s technically a “removing” event, not removed if I can still use “self”. Either way, yeah, that’d be the guy we need.

#36

Amen!!! Couldn’t agree more. The fixes to widget 2.0 are coming in nicely but issues are piling up almost just as fast. I can’t wait to get a stable version that we don’t have to wrestle that has all the features promised + needed. Thanks for the continued effort. 

#37

Ditto on components…but is it a main objective of Corona to support building business apps? I’m not sure.

Regarding Plugins, we’d love to author them but … time is lacking and it’s not cake. I would like to get a user’s group together of plugin authors so that we could kickstart that initiative. Who’s building the plugins right now, anyway? I’d like to chat with them :slight_smile:

I feel really strongly that we need to offer a framework for younger/new devs to use to enter the field without quickly getting into bad habits. I liked Sencha for offering a clean MVC so a team can quickly get productive. This would be a real gift to new devs, and while Jesse offered up RobotLegs I wonder if there is a sort of very basic MVC framework that we could construct or borrow to help people structure their code.

best,

Jen

#38

Time to revisit this excellent article. It is sad to see how little notice CL took about the widgets / components viewpoints.

#39

Time to revisit this excellent article. It is sad to see how little notice CL took about the widgets / components viewpoints.