Rad bych se autora (pripadne kohokoliv jineho) zeptal na jednu vec. V casopise Computer 5/02 byla uverejnena srovnavaci minirecenze Kylix 2/Delphi, v niz mimojine autor pise:" Pokud bych mel srovnat komfort prace v Kylixu a Delphi, vitezstvi by asi patrilo Delphi. Dalo se to ale cekat, protoze Windows maji propracovanejsi ovladani grafickeho prostredi. I kdyz KDE nebo Gnome jsou take velmi pekne, Kylix 2 zalozeny na Qt knihovnach pusobi ponekud neohrabane. Take na Object Inspectoru je stale co zlepsovat a dohanet." Chtel bych tedy jen vedet, zda je vase zkusenost podobna a myslite-li si totez, co autor zminene recenze.
Pah. Modelova situace: Zamen MSIE, Netscapa nekomu z zvyklemu za Lynx (nebo aspon Amayu). Open projekty proste (vetsinou) neplati armady grafiku, kteri matlaji ikonky a proto pak dopadaji tak spatne v testech renomovanych casopisu jako kupr prave Computer.
Diskutujeme v debate o nicem - lide proste maji radi ikonky, barvicky,...
Muj nazor je, ze komfort prace v Delphi je opravdu trosku vetsi. Neni to z duvodu toho, ze by Wokna byla kvalitnejsi platformou, ale z toho, ze proste nektere prvky se musely pri portovani obejit (proto taky IDE pusobi trosku neohrabaneji nez v Delphi - bylo hodne svazane s prvky jako COM a to se muselo necim nahradit - treba pomoci winelib) a nebo (doufam docasne) zakazat. To ale neplati pro vysledne aplikace a ja pevne verim, ze se to casem jeste vylepsi. Rozdil je taky v edicich, nelze srovnavat Open a Professional.
I tak si myslim, ze port je proveden velmi slusne (zvlaste K2).
Došlo zde k menšímu nedorozumění. Já jsem neměl snahu vyjadřovat svůj názor stran portovatelnosti Pascal-> Linux, ale názor člověka z oné firmy. Ten prostě prohlásil (samozřejmě jinými slovy, je to již nějaký ten pátek), že stávající části "účta" jsou psány v Pascalu a lidé z firmy ten kód považují za nepřenositelný. Než by se jej pokoušeli portovat, že by bylo lepší začít úplně od začátku. Jelikož si dovedu představit kolika změnami ten kód od prvního vydání prošel a jak se nejspíše komplikoval, tak s nimi musím souhlasit. Od jisté fáze je prostě lepší začít od nuly a vyhnout kompromisům.
Samozřejmě na LinuxExpu byl mj. vystavován i Kylix a protože se drží osvědčených fíglů ostatních Builderů firmy Borland, tak o portovatelnosti kódu v Pascalu pro Linux nepochybuji.
No a jestli mám opravdu zásluhu na vzniku tohoto pěkného článku, tak se neubráním jistému uspokojení:)
no ja som bol na prednaske borlandakou ohladne kylixu a dusovali sa ze vyse 80% SW napisaneho v delphy staci len prekompilovat v kylixe. tych 20% su aplykacie pouzivajuce niektore casti stareho DB engine. ale casom bude delphy i kylix na urovni zdrojovych kodou 100% kompatibilnych (pokial nebudete liezt do systemovych volani priamo)
Jen par poznamek:
1/IMHO by bylo pekne pokud by se v textech pro programatory neobjevovalo, ze mame rychle procesory a tedy nejake to procento na rychlosti aplikace je nepodstatne. Mozna je to nepodstatne pri jednom pouziti, ale pokud je to modul napr. do apache tak po 10000 pouziti uz celkova casova ztrata muze byt tak dlouha, ze se to muze rovnat casu ktery je potreba na obsuhu nekolika dalsich platicich zakazniku :-)
2/V cem je psani modulu do apache v jinych jazycich nepohodlne? Mel jsem za to, ze naplnit strukturu pointry na nejake handlery je snadne...
3/Cas kompilce -- jaky je pomer mezi cetnosti kompilace behem vyvoje a cetnosti behu aplikace v rukou uzivatele?
Jinak dobre a tesim se na dalsi dil!
1) Ja se ted musim ozvat - k cemu jsou pouzivany delphi a v cem je jejich sila - k psani aplikaci, ktere vyuzivaji pouze GUI. Pokud budu psat moduly do kernelu, zacnu se ucit cecko. Pokud potrebuji napsat primitivni telefonni seznam (par funkci a policek, ), pouziji delphi, c++ builder nebo kdevelop (parkrat kliknout mysi a aplikace je hotova). A nikomu pri vytvareni teto aplikace nevysvetlim, ze mi vyvoj trval pul roku, protoze jsem potreboval nekolik tydnu na optimalizaci (ceho???) a ze to je napsane v pure c (tudiz super a to nejlepsi, co si klient mohl prat), kdyz jsem to mohl pomoci RAD nastroje udelat za odpoledne.
Uznavam, ze autor clanku mel zvolit jiny priklad, nez moduly do apache (taky bych to nepsal v kylixu nebo v delphach).
3) Kdysi jsem videl statistiku, ze pocitac pres 99 % doby prace s nim ceka na odezvu uzivatele. Tudiz cekani uzivatele u bezne aplikace je zanedbatelne :-) (pls zadnou flamewar, taky me vzdy rozcili, kdyz odpalim omylem full table scan v databazi a pak se divim, proc to tak trva ...)
ehm... uz jen rozsah ceske delphi konference naznacuje, ze se mylis! jen v cechach jsou tisice lidi, kteri v Delphi rutinne programuji. Neni ti to divne?
Jak uz bylo receno, neni pascal jako pascal... pascal je trosku jiny jazyk nez objectPascal.. a ObjectPascal je trosu jiny jazyk nez pascal v Delphi! Postupem casu se totiz do Delphi Pascalu dostalo mnoho kontrukci, kterymi se schopnsti jazyka Pascal vyrovnaly Ccku... V delphi mas s pascalem stejne moznosti jako u jazka C.
jenze to ten, kdo naposled videl pascal (a to ten drevni standardni) ve skole jaksio nemuze posoudit, vid? neodsuzuj neco co neznas. Vnimej to jako realitu! v pascalu se mnoha lidem programuje vyrazne pohodlneji nez v ccku, protoze samony jazyk umozni udelat mnohem mene chyb a take pascal je mnohem prehlednejsi!
Rychlost, jak jsem psal zavisi na typu aplikace a na hlavne na programatoru.
Je mozne napsat stejne rychlou aplikaci jako v C, ale priznavam, ze moc rad vyuziju nejakou tu vychytavku vyssiho programovaciho jazyka, takze tam se muze stat, ze to muze byt o neco pomalejsi nez to nabouchat pres pointery (ale mnohem rychlejsi nez java nebo modul php pro indiana).
ad 2) Ja jsem snad nerekl nepohodlne, ja jsem rekl, ze ve vyssich verzich je to usnadneno
ad 3)
V komercnich firmach je vyvojovy cas tvrde placen.
To zpomaleni vysledne aplikace je fakt nevyznamne (aby to uzivatel poznal), ba troufam si rict, ze diky popsanym technikam je kod rychlejsi (a prehlednejsi).
Ja jsem fakt nechtel flame...
Po prechodu na linux jsem si zvykl, ze okno pod mysi je aktivni (usetri mi to klikani), ale Kylix (Open Edition) to nejak spatne nese (aktivni okno mi vzdy hodi do popredi). Zatim jsem to vyresil tak, ze jsem WM zakazal menit aktivni okno bez klikani, ale moc me to neuspokojuje. Zna nekdo reseni, nebo vi nekdo, ze je to neresitelne?
Ja jsem pravy kokot. Nekdo me leze do zeli.
Ja Kylix zkousel a rekneme prave pri uctu by byl nepouzitelny.Sice je nekde v mytech napsano, ze umi pracovat s databazema, ale jak? To co pri uctu nebo jinem kvalitnejsim programu potrebujete je rozdelit celou aplikaci na nekolik casti napriklad server, komunikacni cast a pak clientskou, nelze sice vyloucit ze vsechno by slo napsat v tom prostedi a s pascalem ale budete mit zarucene velke problemy, zrejme bude vhodne pouzit na komunikaci neco na bazi CORBa (omiorb, ORBit,..) a to pouzit teprve na komunikacni vrstu ke GUI. Sice se vsude prohlasuje, ze CORBa je na jazyku nezavisla, ale Borlandskou mutaci Pascalu to nezzvlada (aspon podle mych pramenu) takze budete mustet cast udelat v C++, Python.. a tu na klientske strane slinkovat s tim prostedim... no ja bych do toho praci nedal. Taky investovat cas do Pascalu, kdy mate tak 90% pravdepodobnost ze to budete prepisovat je podle me plytavni casem... no ale zrejme to muze byt zajimavy, pokud clovek bude chtit rychle a bez prace napsat nejake nenarocne GUI.
Bod 1) Nejak jsem nepochopil, co vlastne tvrdite. Ze kylix neumi pracovat s databazema? To jste vzal kde? Nezlobte se na me, ale to je FUD jak od velkeho Billa. Osobne povazuji za implementovanou vrstvu - dbExpress za prasackou zalezitost, ale napr. pro praci s MySQL a Postgresem existuje projekt ZEOS (http://www.codepunk.com/), pro praci s Oraclem je fantasticka knihovna ODAC od www.crlab.com . Delam s db nekolik let (a v nekolika prostredich) a takovydle blud uz jsem dlouho neslysel (a jeste ted dostavam vyrazku, kdyz si vzpomenu na praci v php a pythonu proti postgresu - nikdy vice).
Bod 2) Implementace CORBY od Borlandu je kapitola sama o sobe, ale nikdo Vas nenuti ji pouzivat (mam pomerne slusnou zkusenost s implementaci od http://www.millennium-group.ru/tools .... opensource reseni.
Bod 3) A pak uz nechapu, co myslite tou investici do Pascalu - Kylix je primarne urcen pro pascalovske pojidace kolacu, kteri by radi programovali i pod linuxem a nebo do linuxu radi konvertovali sve stavajici aplikace (<flame>coz je hruza a perverze, vase linkovani je vedle toho legrace</flame>).
Dobrý den,
chtěl bych se zeptat, jestli je Kylix křížový překladač. Tedy jestli lze v Kylixu pod Linux překládat programy do spustitelných souborů pro Win. A taky by mě to zajímalo naopak. Jestli poslední Delphi umí překládat do spustitelných souborů Linuxu. Hledal jsem to na internetu, ale nikde jsem nenašel informaci o tom, že Kylix je cross compiler. Takže asi není že?
Hodilo by se to zejména proto, že by člověk měl koupenou pouze jednu verzi, a dělal by programy pro oba OS.
Co se tyka proklamovane prenosirelnosti softwaru z Windows na Linux, tak o tom trosku pochybuji, protoze pokud aplikace pouziva komponenty z windows (Win32, System), tak je neprenositelna, protoze tyto komponenty v Kylixu nejsou. Napadaji me treba komonenta Kalendar. Nebo seriove porty. Resenim by bylo mit komponentu, ktera bude existovat pro oba systemy. Pokud takove komonenty existuji, pak aby aplikace mohly byt prenositelne. S Kylixem laskuji teprve nedloho, tak mozna placam nesmysly...
Ale ucim se Kylix podle prikladu pro Delphi a dost casto narazim na problem "to se v Kylixu asi musi udelat jinak", protoze tato standartni komponenta z Delphi v Kylixu neni...
Lze treba napsat aplikaci pro upgrade firmwaru mobilniho telefonu pres seriovy port tak, aby byla nezavisla na OS? Jak je to slozite??
Ahoj
ja na rozdily docela narazil pri instalaci komponent
-pochopitelnet nepujde prevest komponenty zalozene na com,ale lze najit ekvivalenty
chtel bych se zeptat - jakym spusobem lze propojit kylix a interpret . jazyky jako perl atd...? ja jsem trosku narazil - predam parametry ,ale uz nevim jak dostat result... Dekuji
This component let you execute a DOS program and catch the ouput in order to put it in a memo or in a listbox ...
je to sice pro delphi, na linuchu nejsem, ale snad ti helfne kdyz uvidis jak se to dela pod winama (mozna)
http://homepages.borland.com/torry/vcl/system/tasks/doscommand.zip
btw ... existuje cela rada stranek na kterych se daji nalezt VCL komponenty (nyni i CLX) pro delphi/kylix, rada z nich je free vc. zdroje (a to i pro win platformu)
je to nejen idealni vyukovy material, ale pomoci techto komponent je mozne snadno "zbastlit" skoro cokoli
naprosto staci zakladni verze delphi - a pokud se budete kuci od linuxu snazit a rozsirite si i kylix k obrazu svemu, ziskaji poziraci kolacu mocny nastroj, kterym vam v soutezi pred vasimi manazery nakopou prdel :)
(nic proti cecku apod., ale priznejme si to: jsou oblasti, kde muze byt delphi/kylix lepsi a jeho nasazeni rozumejsi)
Ahoj
ja na rozdily docela narazil pri instalaci komponent
-pochopitelnet nepujde prevest komponenty zalozene na com,ale lze najit ekvivalenty
chtel bych se zeptat - jakym spusobem lze propojit kylix a interpret . jazyky jako perl atd...? ja jsem trosku narazil - predam parametry ,ale uz nevim jak dostat result... Dekuji
Plne s vami souhlasim. Rozdily platforem windows a linuxu by se mely ukryt do kodu komponent ci by mely vzniknout knihovny, ktere tyto rozdily pred programatoem skryji. Takze programator pak pise aplikace opirajici se o 'nezavisly kod'.
Presne tuto filozofii napriklad ja uplatnuji, a davam tak k dispozici napriklad knihovnu SynaSer (obsluha seriovych portu pod windows i linux) a Synapse (TCP/IP knihovna, ktera si s linuxem rozumi o mnoho lepe nez dodavane INDY).