Hruške, jabuke, jablane, čežane.

Na Diggu sem zasledil eno “novico” (če se objavam na diggu lahko reče novica) o zanimivih “besednih zvezah” v programski kodi. Celo stvar je seveda omogočil Google s svojim “code search”. No, potem pa se je seveda pojavila še zanimiva analiza kletvic glede na programski jezik. Torej, kako kaže programskim jezikom?

PHP očitno povzroča največ frustracij, saj je število kletvic v PHP kodi bistveno večje kot pri ostalih jezikih. Po drugi strani pa Python ni bistveno bolj miroljuben kot npr. Java ali C#. Presenetljivo – niti C++ in sam C nista tako požrešna z živci in sploh nista dosti bolj agresivna od Pythona.

Podobno je zanimiva tudi (zraven priložena) analiza o frustraciji glede na lincence.

Sicer ene uboge statistike, izvedene po vsej odprti kodi, ki jo Google lahko najde, ne gre ravno jemati za mero… sapienti sat.

I’m currently migrating Pootle to Django. All releases till now are based on jToolkit (no, it has nothing to do with Java, it’s just following a naming pattern), which is poorly documented and has few available developers. Therefore I started a movement … migration to try to speed up Pootle development.

I can’t really say current Pootle is not organized or anything, it’s just it’s not organized how a developer would expect. It does have code separated depending on what it does, but based rather on content than on technical details, so it’s a bit clumsy to trace some functions back and forth through files.

Anyhow, I have now running mostly functional Django Pootle, but the GET or POST actions and the i18n are currently broken. First I’ll have to migrate GET and POST, the i18n will have to wait.

There have been numerous questions on Pootle mailing list as to why choose Django and not something else. I’ll try to post some answers here too.

Django has great error (debug) page. It is very helpful when developing applications, in fact I think web.py has copied the thing. If I was Guido, I’d probably suggest putting this right into traceback module.

Django is explicit. Most of the stuff in Django is declared explicitly. There is as little “magic” as possible and all imports are explicit. While this may be a little hard to get used to, if you come from CherryPy, it’s in fact very good. This way you know exactly where to look for a specific function, since you already had to import it. Also, with less magic Django is more open for developers.

Django is built for speed. Even if written in Python, all the functions are written with performance in mind. The values are evaluated only if they’re accessed, the queries to the database are only made if you access the contents of the query. So if your page takes time to load, it’s most likely there’s something wrong with your code.

A framework should stay out of your way. Because Django was built with speed in mind, it also means you don’t need to optimize the framework, so it stays out of your way. On the other hand, it is sometimes annoying to figure out what to import.

Sensible templates. Who cares about technical supremacy, if it’s incomprehensible? I’ve seen a bunch of people trying to figure out details of Kid templating. And the Kid errors are just as incomprehensible as the template language. Christian Lenz then reimplemented a templating engine very similar to Kid, called Genshi, but it does not appeal to me. While it may be technically supreme from both Django’s templates and Kid templating, that still isn’t the reason for me to embrace it. To me, it just seems complicating things that needn’t be complicated. The one thing I am still on the lookout for is template inheritance in Kid; does it even support top down templates?

Neat and powerful URL resolving. Django has really good, regular expression based URL resolving thingie. It’s nothing like the class tree in CherryPy 2, but is a bit similar to RoR routes (or a Python implementation used in CherryPy 3), except it again isn’t that complicated, since it does not feature conditionals on cookie, HTTP method and similar routes features.

That probably wraps some reasons, but surely I could find some more. Better get back to coding.

… je grozen. Preseneča me, da odprtokodni projekti sploh pridejo kam, ko pa ima Sourceforge toliko tehničnih neprijetnosti. Zadnji dve uri se mi Subverision reži v glavo kot pečena šunka, jaz pa gledam kako mi serje napake tipa 500 (isti tip kot najbolj poceni moka, ki jo najdeš v štacuni).

Ne dela ‘commit’, dela ‘checkout’, ampak ne pravilno, kar pomeni, da praktično ne dela nič.

Klinc pa taka infrastruktura.

Mplayer je končno prišel v uradno Debianovo skladišče. V unstable je baje že od 26. oktobra, tja pa je prispel nekaj več kot 5 let za naznanitvijo ITP (intention to package), kar je svojevrsten rekord.