[linux] Re: EIS - aky programatorsky nastroj

[Matej Pivoluska]

Dňa Ut 15. Apríl 2003 12:33 Jozo M. napísal(a):
> Zdar,
>
> Ked ste uz vylucili tu javu, uvedomte si, ze perl a python su podobne
> narocne-tiez su to interpret. jazyky. Skuste si porovnat napr. taky
> WEBMIN (napisany v Perle) a SWAT (napisany v C++) ako bezi
> na slabsich pocitacoch. Iste bude to bezat na vykonnom serveri,
> tam to nevadi - ale potom je uplne zbytocne davat tam superrychlu
> databazu, ked jadro nasej aplikacie je pomale, a kazda dbf bude
> x krat rychlejsia.

Treba si uvedomit, ze nebolo povedane zdaleka posledne slovo, ktore 
implementacne nastroje sa pouziju a ako sa pouziju. Zatial je o tom hovorit 
trochu predcasne. Predpokladam vsak, ze sa to asi bude programovat v C++ a 
bude to mat podporu skriptovania v Pythone. Ale to je len jedna z uvah, ako 
by sa to dalo urobit. 

Cas programatorov zacina byt cim dalej, tym drahsi, naopak, cena strojoveho 
casu klesa, preto treba mysliet aj na toto. 

> Otazka : Dala by sa potom aplikacia napisana v Perle/Pythone prelozit do C
> a tam potom doladovat a upravovat ? Cize hruba kostra by bola v perle ale
> konecna
> aplikacia v C ? Napr ako je to v mattlabe aa.m -> aa.c -> a.out

Toto mi nie je zname. Python sa da napriklad prekladat do binarnej formy, 
ktora sa ale aj tak interpretuje (pripona pyc), nemusi sa vsak parsovat, co 
ma svoje opodstatnenie napr. pri castom spustani programov, ci dynamickom 
nahravani kniznic. Pythonu sa da pomocou prepinaca -O povedat, aby robil 
nejake zakladne optimalizacie (pripona pyc sa meni na pyo) a ked sa to da 2x, 
odstrania sa docstringy (znizi sa velkost vysledneho suboru, ale stratime 
jednu zaujimavu vyhodu).

> Ja sa priklanam k C++ ako vyvojovemu nastroju. Kniznica NCURSES
> a podobne.

Uvazuje sa aj nad touto alternativou.

> Takisto ste zavrhli php/html - podobna komercna aplikacia existuje ako
> asp/MS SQL/htm.

Nezavrhlo sa to koli tomu, ze existuje nejaka ina aplikacia, ci uz komercna 
alebo nekomercna, ale koli tomu, lebo si myslime, ze prehliadac nie je tym 
pravym orechovym pre skladnika ci uctovnicku, dost to vnucuje mys a neda sa 
presne nadefinovat ovladanie z klavesnice, focus dost casto preskakuje medzi 
samotnou aplikaciou a prehliadacom, etc.

Nechcem tym nijak ponizovat vyznam html na tvorbu gui, preco nie, ludia si na 
to zvykli, ma to uspech...

Poviem to ale na priklade. Mate k dispozicii vo firme plnohodnotneho mailoveho 
klienta (KMail, Mutt, Outlook, Eudora...) (MUA), ktory funguje bez problemov 
(niektore aplikacie mozme vylucit) a MUA, ktory funguje cez prehliadac (imp, 
StringData, ale aj cele riesenia, ktore na ponukaju Pobox.sk, Post.sk, Yahoo, 
Centrum,...) V ktorom budete moct efektivnejsie pracovat?

Vyhoda plnokrvnej aplikacie je v tom, ze naozaj riesi to, co ma riesit, a 
riesi to vacsinou dobre. Vyhoda www MUA je zase v tom, ze poskytuje jeho 
uzivatelovy nevyslovnu mobilitu, vsade, kde je prehliadac, nema problem 
precitat postu. (Samozrejme, tato mobilita sa da [minimalne na intranete] 
zabezpecit aj u normalnych MUA, resp, da sa spravit cely desktop tak, aby sa 
dalo nan zalogovat odkialkolvek, a stale by bol ten isty pre toho uzivatela, 
ako by si ho nastavil.)

Moja otazka je: Potrebuje skladnik alebo uctovnicka viac mobilitu, ci dobre 
ergonomicke UI, v ktorom bude denne pracovat, preto potrebuje, aby sa v nom 
dalo pracovat plnohodnotne a najma rychlo, aj za cenu toho, ze dva dni (teda, 
rozumnu dobu) presedi nad manualom ci na skoleni, aby si zvykla na to 
prostredie?

A ak skladnik ci uctovnicka aj potrebuje mobilitu, je problem urobit klienta 
bezstavoveho, aby sa vsetky nastavenia o tom ktorom skladnikovi ukladali na 
serveri a podla toho, kto sa naloguje, take UI dostane, dokonca ist este 
dalej, a podla toho, odkial sa kto naloguje, take UI dostane (v sklade s 
obilim chcem mat k dispozicii rychlo ine polozky ako v sklade s nahradnymi 
suciastkami).

Na druhej strane, bude sa mysliet aj na systemovych integratorov, a system 
bude dostatocne otvoreny na to, aby nebol problem napisat pren nejaky portlet 
+ malu reziu, ktora bude sosat vhodne data pren.

Resp. takto, ak bude zaujem o HTML+JavaScript klienta, ktory bude komunikovat 
prostrednictvom HTTP protokolu s beznym prehliadacom, nebude ziaden problem 
to na poziadanie dorobit. Mozu ho urobit samotni autori, ci tretia strana, 
ale nebude sa robit primarne s app. serverom. 

-- 
Matej Pivoluska (mP)