|
|
Subscribe / Log in / New account

Awesome: A window manager that gets out of the way

Awesome: A window manager that gets out of the way

Posted Nov 17, 2011 6:23 UTC (Thu) by alankila (guest, #47141)
In reply to: Awesome: A window manager that gets out of the way by HelloWorld
Parent article: Awesome: A window manager that gets out of the way

Amusingly, the man who wrote Awesome agrees in retrospect that he should have chosen Python. He wanted an object-oriented language and since LUA doesn't really provide you with this out of the box, he realized he was spending his engineering effort into writing a programming language implementation, not a window manager implementation.

He now advocates against LUA because of this, apparently.


to post comments

Awesome: A window manager that gets out of the way

Posted Nov 17, 2011 19:12 UTC (Thu) by oblio (guest, #33465) [Link] (4 responses)

A bit strange, seeing this: http://www.lua.org/pil/16.html

Object oriented Lua

Posted Nov 17, 2011 23:33 UTC (Thu) by man_ls (guest, #15091) [Link] (2 responses)

Apparently Danjou is not happy with metatables as an object-oriented technique. You can read more about it in his 2011 blog (scroll down to "Why not Lua").

All my knowledge of Lua is theoretical, but the explanation in pil (from which you link the older online version) is really messy. I can relate to how JavaScript prototypes are a clumsy solution for a real class system. JavaScript also has other flaws such as the disappearing "this" reference. When you feel that a language is working against you instead of for you, you feel frustrated.

Of course with Python you have the obnoxious self parameter, and Java is not functional (pun intended), but what can you do about it. Obvious sentence of the day: no language is perfect, and choosing the right one for a particular job is really hard.

Object oriented Lua

Posted Nov 19, 2011 9:46 UTC (Sat) by alankila (guest, #47141) [Link] (1 responses)

The "this" reference does not disappear. It's just always set on every method call, and in this case it will be the contained DOM node, as you'd expect (it's the DOM node's method being called). You simply capture that other object into a variable -- a strategy you might not like -- but it's not unreasonable.

Incidentally, Java would allow people to write Node.this to represent the Node object, assuming the function objects were written as anonymous inner classes.

Object oriented JavaScript

Posted Nov 19, 2011 13:02 UTC (Sat) by man_ls (guest, #15091) [Link]

It is especially annoying in callbacks: I would expect that this would be part of the function context as any other closure, but no: this points to the DOM node where the callback is running.

It can be worked around, of course: using a real closure, or calling the callback using weird call() techniques. But it makes for one of those "what were they thinking" moments. Same for prototypes, metatables' bastard son.

Frankly, JavaScript is surprisingly sane given that it was invented in 10 days.

Awesome: A window manager that gets out of the way

Posted Nov 18, 2011 8:42 UTC (Fri) by alankila (guest, #47141) [Link]

*sigh* I wouldn't exactly call that an object system. Sure, it's not *that* complex to do from scratch if you insist, but the point here is, you are manually implementing an object system.

Apparently he wanted python's semantics, too, and was dismayed to discover that some internal functions like __len were not overridable for some built-in types. I'm going to guess this restriction was because of performance.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds