[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: few newbie questions -- luaforge/kepler website, REST, bindings etc.
- From: Chris Babcock <cbabcock@...>
- Date: Thu, 3 Mar 2011 23:54:47 -0700
On Thu, Mar 3, 2011 at 5:31 AM, Jayanth Acharya <jayachar88@gmail.com> wrote:
> Thanks Chris. Had a look at kepler, and my first impression is, it
> looks a bit complicated to use. However that is quite likely to an
> incorrect impression due to my lack of familiarity with Lua itself.
> Will explore it further, and particularly Copas.
My impression, Looking at Lua after exploring Python-based frameworks,
was that Kepler was building tools at those abstraction levels between
WSGI and frameworks like Pylons or CherryPy. There's nothing
full-stack MVC like TurboGears (whatever it's called now) or Django in
the Lua world, but you can do a good approximation of it with
Versium/Saci, Cosmo and Copas... and enjoy stable APIs as a bonus. If
you want that stack in a CMS, Sputnik is power and joy. Object storage
beats ORM for flexibility, ease of implementation and ease of
maintenance 8 days a week. Well, that reflects my current bias that
ORM is a curious anti-pattern.
For something lighter than REST, consider Reactive Server Pages. A
full REST implementation is great for transaction safety and
portability, e.g. if you want a shopper to be able to bookmark his
shopping list and send it to mom to pay for or to expose an API to
third parties. RSP will be more responsive for short-lived state, like
a game session.
In other words, if your data is processed as objects or tables then
normalizing and de-normalizing the data and retrieving it from storage
with blocking I/O is the fail whale dance. You can lose the ORM and
memcached layers of a full stack web framework by playing to Lua's
strengths as a Data Description Language and using a key-value store
for persistence. Then look at the transaction profile of the app and
build your own stack (or extend Sputnik) on top of WSAPI depending on
whether your transactions tend towards atomicity and long-lived state
or cluster in related transactions.
> Was attracted to Lua simply due to it's fast, lightweight, and
> familiar feel (has a bit of Erlang, bit of Python, tiny bit of Java
> and lot of C appeal to it). I agree that probably expecting
> heavy-weight CMS'ish frameworks might not be quite right, but I was
> looking for something that really eases development, helps minimize
> lines-of-code.
Whether a Python web framework has five thousand or five millions LoCs
depends on how you count dependencies. ;)
> At the outset Lua looks very simple, and elegant, so I
> am eager to learn more.
It's easy to look at Lua and think "If only..." That's a trap. I went
for it. You won't be the last. Java has a strong culture of code
reuse. Python, less so. Lua, even less than Python. There's probably a
good reason there that doesn't have anything to do with Java making it
any easier to share code than any other language.
I still think Lua is as good as anything else available for rapid
prototyping. Its real strengths don't come into play unless you've got
legacy code or otherwise want to operate in a mixed environment with C
or another language, but it's still competitive even if that isn't
your frame of reference.
Chris
--
Yippee-ki-yay, coffee maker.
PS - Feel free to take this off-list.