Vlákno názorů k článku Proč se má vyplatit vývoj pro Linux? od MIloš - Jestliže se Linux šíří na serverech, pak jako...
-
MIloš (neregistrovaný)Jestliže se Linux šíří na serverech, pak jako systém snad je atraktivní pro komerční sféru - nebo ne? (Ta je dnes na serverech závislá více, než na čemkoliv jiném).
Mluvit ovšem o nějakém programování komerčních aplikací výlučně pro Linux je nesmysl. Rozumnou cestou jsou portabilní aplikace a nikoliv aplikace tvrdě závislé na jediném sytému, ať už jakémkoliv. Portabilních jazyků a knihoven už je v podstatě dostatek a Linux ani jeho nadšenci se portabilitě nebrání a nikdy nebránili. Největší brzdou je však silná setrvačnost většiny softwarových firem. Ti lidé investovali spoustu času a úsilí do získání nějakých znalostí a zuby nehty se brání změnám. A budou se bránit, dokud to jen půjde - protože tolik let úsilí přece nezahodí... A z existujících aplikací je také nutno vytěžit, co se dá a prodlužovat jejich životnost, jak je to jen možné. (Mnohé DOSové komerční aplikace se nabízejí dodnes). No a pak tu jsou ještě menežeři. Ti ovšem mají na mysli výlučně vlastní prospěch, takže jimi se zabývat nehodlám.
Jedinou cestu vidím u nově zakládaných softwarových firem a programátorů, kteří jsou schopni si včas uvědomit, že při dnešní rychlosti vývoje je závislost na jediném systému sebevražedná a životnost znalostí jepičí - a takovou práci budou v zájmu své budoucnosti odmítat. -
Rejpal (neregistrovaný)Pokud můžou Mathematica, Maple a Matlab bý mulitplaformní, proč by nemohl být multiplatformní i další "výpočetní software"? Když může být multiplatformní MySQL, PostgreSQL a Firebird, proč ne databáze? Když může být multiplatformní Pro/ENGINEER, proč ne CAD? Stačí mít dostatek prozíravosti, nic většího v tom nevidím.
-
Myslel jsem FEM vypočty...
Pravděpodobně jsme si zcela nerozuměli. To o čem mluvíte jsou jistě multiplatformní aplikace, ale to jen díky tomu, že je součástí jejich zdrojových kódů API na danou platformu/OS. Pokud by na to pamatováno nebylo, multiplatformní daná aplikace není. Další kód = více práce, nutnost testování, náklady na distribuci... A to je to, do čeho výrobci jít moc nechtějí. Nemluvme ale o tom, jestli je napsání kusu kódu pro danou platformu až takový problém nebo ne. Já zde pouze vysvětluji, proč si myslím, že velké aplikace se jako multiplatformní špatně realizují. Také se mi to nelibí.
Naopak jsem měl v souvislost s multiplatformními aplikacemi na mysli treba programy psane v Javě, kde je přenostitelnost prakticky 100% na úkor výkonu ovšem. -
Miloš (neregistrovaný)Program pro výpočet konečných prvků (pokud pod FEM myslíme oba totéž) je dokonce i v repozitech SUSE. S fyzikálními a matematickými výpočty by neměl být žádný problém. Drtivá většina je psána buď v C nebo ve Fortranu (a případně konvertovaná do C), takže portabilní jsou. Když mohou využívat takové knihovny (i s požitím Pythonu coby lepidla) v CERNu nebo v NASA, pak asi použitelné budou. Jinou věcí je ovšem napojení na 3D modelovací programy či různé vizualizace - to už je problém jiného řádu.
Multiplatformní aplikace se samozřejmě nevyplatí vytvářet tam, kde není k mání přenositelné vývojové prostředí. Případné API pro danou platformu je pak jeho součástí (a starostí jeho vývojářů) a od tvůrce koncové aplikace v podstatě žádnou práci navíc nevyžaduje. Faktem je, že největší mezery v přenositelnosti jsou zatím na straně grafiky, což je dáno jednak novostí, jednak bouřlivým vývojem. Ale i v tomto směru se situace rychle zlepšuje.
Pokud jsou portabilní vývojové prostředky k mání a tvůrci aplikací je přesto nevyužijí, pak tvrdím, že trpí krátkozrakostí a zbytečně si zadělávají na budoucí problémy, nehledě na pravděpodobně kratší životnost jejich výtvoru. -
Miloš (neregistrovaný)Ještě krátký doplněk.
Vlastností přenositelných programů je nejen možnost běhu na více platformách, ale také mnohem snadnější přechod na nové verze systémů či dokonce novou architekturu procesorů. A to je solidní zárukou delšího života, což by mělo zajímat nejen autory, ale i uživatele. (Zvláště u programů, které jsou psané na míru a tudíž mnohem dražší). Je otázkou, jak dlouho bude uživatelům trvat, než jim to dojde ... -
Jan Povolný (neregistrovaný)Dobrý den, možná mám jen naivní ekonomické uvažování, ale jsem přesvědčený, že i programátor v linuxové komunitě musí přijímat potravu. Ta stojí peníze. Kde se ty peníze berou? Od lidí, kteří peníze mají. A kde ti je vzali? ....atd.
Existence nekomerční aktivity není dost dobře možná bez existence té komerční.
JP -
"Rozumnou cestou jsou portabilní aplikace a nikoliv aplikace tvrdě závislé na jediném sytému, ať už jakémkoliv."
Problém portabilitu je ekonomický. Je vždy levnější naprogramovat neportabilní aplikaci, než portabilní, s tím nic nenaděláte. A pokud zisky firmy jsou převážně z jedné platformy, a není v dohledu situace zajímavé ziskovosti na více platformách, pak je levnější udělat aplikaci nemultiplatformní a neportabilní.
Jednak můžete do mrtě využít možnosti konkrétní platformy, což u portabilní aplikace udělat nemůžete. Jednak programátoři mající nadhled a jsou tedy schopní psát kód pro více platform je málo - a jsou dražší. Klikači a lepiči knihoven jsou levnější, ale i lepením multiplatformních kniheven snadno dostanete neportabilní kód, když nepřemýšlíte. Není třeba vůbec žádný problém udělat program v Javě, který poběží jen na jedné konkrétní platformě - a to přesto, že Java se o multiplatfromovost důsledně snaží.
Multiplatfromní programy začnou pstá firmy až tehdy, až se jim výrazně vyplatí mít program alespoň na dvou rozdílných platfromách - a to dnes moc většinově nehrozí. -
Saboter (neregistrovaný)Pro firmu je levnější to nechat slepit, ale výsledek pak odpovídá tomu lepení. Mnohdy je lepší nechat si to naprogramovat od lidí kteří mají o programování trochu přehled a na přenositelnost nekašlou. Firma nikdy neví, kdy bude přecházet na jinou platformu (mohou to být klidně i nové Windows).
Využívat zdroje konkrétní platformy do mrtě potřebujete málokdy. Existují také přenostilné knihovny (například na podporu více vláken), které podle platformy použijí podporu daného operačního systému.
V Javě není problém udělat aplikaci, která bude závislá na platformě a je to dobře - volání nativních knihoven a podobně. Ale vy jste to myslel asi trochu jinak. Moc mě však nenapadá jak přesně. -
"Firma nikdy neví, kdy bude přecházet na jinou platformu (mohou to být klidně i nové Windows)."
Ano a proto pro jistotu firma udělá několikrát víc práce, zvětší si náklady, jenom proto, aby "kdyby někdy náhodou" to bylo potřeba. :-) Zkuste takto řídit firmu a moc dlouho asi nevydržíte.
Firma počítá s věcmi, které jsou reálné, a "kdyby náhodou se stalo něco s 0,01% pravděpodobností" se neřeší, protože takovéto úvahy těžko ospravedlní vyšší náklady.
"Mnohdy je lepší nechat si to naprogramovat od lidí kteří mají o programování trochu přehled a na přenositelnost nekašlou."
Opravdu si myslíte, že dobrý programátor automaticky píše přenostitelný kód? A pročpak by to dělal? K čemu by to bylo? Já myslím, že dobrý programátor volí nejlepší prostředky k cíli, a to nemusí být zdaleka vždy přenostitelný kód.
"Využívat zdroje konkrétní platformy do mrtě potřebujete málokdy. Existují také přenostilné knihovny (například na podporu více vláken), které podle platformy použijí podporu daného operačního systému."
Akorát je otázka ceny programu, který využívá speciality platformy, a ceny programu 100% přenositelného využívající jen přenositelné knihovny. To druhé je ve většině případů tak výrazně dražší, že se to prostě nedělá, není-li důvod předpokládat, že to bude potřeba. -
Saboter (neregistrovaný)Trochu jste moje slova překroutil nebo špatně pochopil. Pokud vynecháme jednočipy a další jednoúčelová zařízení, použít nějakou přenositelnou knihovnu vůbec nemusí být pracnější než použít tu nepřenositelnou. Při programování té přenositelné musel tvůrce poněkud více přemýšlet a není tak nepravděpodobné, že bude i kvalitnější.
Dobrý programátor si je vědom alespoň důsledků své práce. Například jestli jeho kód poběží na 64 bitovém procesoru a podobně.
Co je podle vás cílem práce programátora? Zplácaný program, který na WIN98 pojede bez problémů a na WIN2000 si neškrtne? I tohle je totiž otázka přenositelnosti.
Škoda, že taky někdy neodpovíte na co se vás člověk ptá - třeba ten nepřenositelný program v Javě, nebo ve starších reakcích jak vypadá ten "pravý" namespace, pravidla x volnost v projektu. Rýpat umí každý, z odpovědi na výše uvedené otázky bych si třeba mohl alespoň něco odnést. -
>Trochu jste moje slova překroutil nebo špatně pochopil. Pokud vynecháme jednočipy a další jednoúčelová zařízení, použít nějakou >přenositelnou knihovnu vůbec nemusí být pracnější než použít tu nepřenositelnou. Při programování té přenositelné musel tvůrce >poněkud více přemýšlet a není tak nepravděpodobné, že bude i kvalitnější.
Pokud musi vice premyslet, tak je tam jednoznacne vetsi prostor pro vznik chyby :)
Nicmene tohle rypnuti nechme stranou, celkem castou situaci je, ze portabilni knihovny maji horsi support/podporu vyvojovych nastroju, horsi integraci k primarni platforme atd. Coz jsou vsechno problemy, co vas pri komercnim vyvoji proste musi zajimat...
Hezkym prikladem prenositelne knihovny je treba zlib ci openssl. Pouziva ji velke mnozstvi programu, at uz na unixech ci neunixech - duvod - dobra knihovna pro izolovanou oblast pouziti u ktere nenastava problem s integraci do platformy. Ale uplne jina situace je u treba prenositelnych GUI knihoven, jsou tezkopadne, nejsou k nim dispozici kvalitni vizualni navrhare, integrace do cilove platformy je mizerna..
> Dobrý programátor si je vědom alespoň důsledků své práce. Například jestli jeho kód poběží na 64 bitovém procesoru a podobně.
To je samozrejme pravda, otazkou je, jestli mu to za to stoji se s tim namahat... Protoze tohle vsechno se musi zaplatit...
>- třeba ten nepřenositelný program v Javě,
Osobne si nedovedu predstavit neprenositelny program jinak nez integraci s JNDI (tzn. nativni knihovny). Ale to je trochu mimo misu... -
Saboter (neregistrovaný)Pokud je obtížnější tu knihovnu napsat a je potřeba více přemýšlet, dá se čekat lepší návrh té knihovny. Prostor pro chyby je samozřejmě větší.
S knihovnami s vámi jinak souhlasím.
K té Javě - JNDI nebo také JNA (které ale asi znáte). Jinak s tou nepřenositelností taky tápu :) -
"Pokud vynecháme jednočipy a další jednoúčelová zařízení, použít nějakou přenositelnou knihovnu vůbec nemusí být pracnější než použít tu nepřenositelnou."
Nemusí - pokud je přenositelná knihovna dobře napsána tak, aby si programátor nepřipadal, že se nedrbe pravou rukou za levým uchem a tím mu práce trvá déle, než pokud danou knihovnu nepoužije (tento problém má odhadem tak 95% všech knihoven). Dále pokud přenositelná knihovna obsahuje vše co je potřeba, aby to dokázalo pokrýt vše, k čemu by programátor musel sahat přímo na pltfromu (problém v této oblasti má naprostá většina knihoven, bohužel optimistický odhad mé skromné osoby by se pohyboval někde mezi 98-99% knihoven).
Další problém je licence - řada knihoven má třeba GPL licenci, tudíž je pro komerční programy de facto nepoužitelná, takže nepadají v úvahu.
Mohl bych uvádět dál a dál - ale lakování na růžovo s tím, že přenositelné knihovny vyřeší všechny problémy lidstva velmi rychle vezmou za své, pokud získáte programátorské zkušenosti v drsném komerčním prostředí, kde je kladem důraz na výsledky, náklady, funkčnost a termíny.
"Dobrý programátor si je vědom alespoň důsledků své práce. Například jestli jeho kód poběží na 64 bitovém procesoru a podobně."
K čemuž naprosto nepotřebuje psát přenositelně. Přenositelnost mezi procesory je relativně sranda. Proč? Protože prostě stále jste na stejné platformě operačního systému s celým okolím. Například Windows existují pro 32 i 64 bitů, Linux rovněž, BSD rovněž, atd. atd. Dáte-li si trochu pozor, přenositelnost na 64 bitů není nic složitého.
"Co je podle vás cílem práce programátora? Zplácaný program, který na WIN98 pojede bez problémů a na WIN2000 si neškrtne? I tohle je totiž otázka přenositelnosti."
Cílem práce programátora je vyřešit daný problém efektivním způsobem. A cíle jsou velmi různorodé a abstraktně a virtuální bez dalšího upřesnění se nemá smysl bavit. Protože programátorská práce i cíle jsou velmi různorodé.
"Škoda, že taky někdy neodpovíte na co se vás člověk ptá - třeba ten nepřenositelný program v Javě, nebo ve starších reakcích jak vypadá ten "pravý" namespace, pravidla x volnost v projektu. Rýpat umí každý, z odpovědi na výše uvedené otázky bych si třeba mohl alespoň něco odnést."
Někdo se na nic neptal - pouze napsal, že takhle je to nejlepší. Namespace je v Javě řešen asi takto - představte si, že jste ve vile o sedmi místnostech. A v pondělí byste mohl být pouze v místnosti první a nikde jinde, v úterý můžete pobývat jen ve druhé místnosti a tak dále. To je zhruba svázanost javovského namespace v Javě. Zatímco v jiných jazycích namespace fungují tak, že můžete pobývat v libovolné místnosti kderýkoli den v týdnu. Javisté pak říkají, že jejich namespace je jediná správná, protože přílišná volnost škodí, a že je škodlivé být ve více, než jedné místnosti jeden den - a že to tak zavádí správný řád. Že je naprosto nepřípustné být ve stejný den část dne v koupelně a pak v obýváku, protože to zavádí chaos. Je to analogie, ale takto se to nějak má vyjádřeno lidským jazykem. -
Saboter (neregistrovaný)Řada knihoven má take LGPL licenci. 32 a 64 - Dáte-li si trochu pozor. Aha... a to není programování přenositelně?
Někdo se na nic neptal - pouze napsal, že takhle je to nejlepší
Nikdo se na nic neptal?V Javě neexistují pravé namespaces? Třída že je silně svázána s namespace? To příliš nechápu. Obdobou namespaces jsou v javě packages. Vazba třídy a namespace a třídy a package mi přijde naprosto identická. Pouze Java měla ten rozumný nápad, že balíku bude odpovídat adresář a třídě soubor a já jsem za to rád. Co je podle vás "pravý" namespace?
Trocha demagogie neškodí. Vidím tři otazníky a ten poslední výskyt opravdu není řečnická otázka. Kde v těch větách vidíte, že tvrdím že balíky v Javě jsou nejlepším možným způsobem přístupu k něčemu jako je namespace? (opět otazník)Zatímco v jiných jazycích namespace fungují tak, že můžete pobývat v libovolné místnosti kderýkoli den v týdnu.
Přiznám se, že vubec nevím jak to myslíte. Ve kterých jazycích a pobývat v libovolné místnosti kterýkoliv den v týdnu? Jestli si dobře pamatuji takové C++, tak má také každá třída plně kvalifikované jméno určené umístěním ve jmenném prostoru. O nějakých přesunech mezi místnostmi v C++ nevím. Ale rovnou také přiznávám, že C++ jsem nikdy neuměl do hloubky a je tomu už pár let, co jsem v něm nenapsal ani řádku. Takže jak to tedy myslíte? (otazník)
ČLÁNKY DO MAILU