To at si delaji jak chteji, ale uzavrenost neni nikdy dobry pristup.
JInak perex clanku "Apple Swiftem napravuje rozhodnutí z dob startu prvních iPhonů a chce přetáhnout k iOS hlavně androidové programátory." je naprosto zcestny, proc by meli android programatori kupovat apple kdyz jsou spokojeni s Windows ci Linuxem pro vyvoj android aplikaci.
To je nedostatecna motivace, pokud by opravdu chteli pretahnout vyvojare staci jim sve vyvojove prostredi portovat pro dalsi rozsirene OS.
Naprosto souhlasim. Na Obj-C neni nic zastaraleho ani spatneho. Je to nizkourovnovy jazyk, ale to neni na skodu. Prave diky tomu je lepsi pro programovani her.
Swift je sice hezky vysokourovnovy jazyk, ale v mnoha vecech zoufale nedomysleny. Kdyz si vzpomenu, kdyz prislo C#, tak to byl kvalitni jazyk a kvalitni knihovna. Apple prisel s polovinou jazyka (ano, neni to jeste ani hotove) a zakladni datove typy se chovaji nekonzistentne a priserne.
Staci se podivat na par otazek na stackoverflow, jak lide nemuzou prijit na to, jak funguji zakladni veci nebo jak naprosto nutne veci v jazyce uplne chybi (treba testovani pritomnosti tridy v API, coz je nutne pro zpetnou kompatibilitu aplikaci se starsi verzi systemu).
MS dominuje s desktopovým Windowsom a má tiež masívnu vývojársku základňu, takže sa nepotrebuje zdržovať vývojovými prostrediami pre OSX ani Linux. Skôr sa snaží skrze spoluprácu so Xamarinom prilákať na tvorbu mobilných aplikácií k sebe viac vývojárov, lebo zaspal mobilnú éru. Tlačí si teda svoje populárne Visual Studio/.Net/C# + podporuje jeho multiplatformné rozšírenia.
Apple po skúsenostiach s iTunes a Safari pre Windows sa radšej ani nepúšťa do tvorby Xcode pre Windows. Každý Mac počítač predaný vývojárovi je vítaný bonus (ušetria na portovaní Xcode a predajú viac počítačov... to je biznis... možno niektorí z vývojárov začnú aj nejaké OSX aplikácie časom tvoriť, keď už budú disponovať Macom s Xcode aj skúsenosťami s Apple frameworkami... ďalší potenciálny bonus).
Google hrá na objem a podľa možností nízke náklady. Potrebuje obslúžiť široký trh s vývojármi fungujúcimi pod desktopovými Windows, a súčasne aj masívny trh s mobilnými aplikáciami pre Apple iOS (Mac počítače). Preto vsadil na existujúce open/free multiplatformné nástroje (alebo ich prisposobené varianty) dostupné pre Win/OSX/Linux (ako bonus). Na desktopoch nemá vlastnú agendu (vynechajme chromebooky, pre programovanie Androida asi nie najlepší nápad). Potrebuje byť používaný čím viac tým lepšie, jedno kým a kde.
Ja jakozto admin tech ovyjimkovanych softu tvrdim, ze za kazdou vyjimku by bylo treba autorovi kodu zapichnou spendlik zcela kamkoli ... behem par dnu by byl casto ubodan k smrti.
Mockrat jsem totiz videl kod ve stylu "tak to zavolame a ono to nejak dopadne" ... aniz by dotycny vubec overil, ze parametr kde ma byt cislo to cislo skutecne je (a neni tam trebas kus textu) ... protoze ceka, ze mu to "kdyztak vrati vyjimku". Jenze ono treba taky nevrati ... a pak se dejou veci.
Zcela konkretne jsem narazil treba na to, ze autor si nacital pole hodnot ... misto podle nazvu podle poradi ... a kdyz dodavatel zdrojove aplikace pridal dalsi hodnotu ...
BTW: Neni to zas tak dlouho co se programovalo neobjektove, zcela bez vyjimek ... a kupodivu ty programy fugovaly velmi casto daleko spolehliveji nez cokoli dnes.
Jo jo, Apple diktuje, v jakých jazycích se bude programovat.
Navíc jsem zaslechl, že u příští verze iOS vydá závazné nařízení, že developer musí programovat pouze v červenočerných vertikálně pruhovaných boxerkách, a že to bude chodit automaticky kontrolovat CEO Applu po vývojářských firmách.
Navíc Apple odebere developerům vzorek DNA (otisky už dávno má) a pokud zjisí, že nějaký developer má Android, pak zablokuje možný vývoj nejen jemi, ale širokému příbuzenstvu, pokud by v něm byli také developeři (zjistí podle DNA databáze).
A teď vážně, ony se programovací jazyky mezi sebou dají i konvertovat. A je levnější napsat konvertor či nějaký použít, než to napsat znovu v jazyce schváleném nejvyšším vůdcem.
Ad 1) Váš subjektivní názor předkládáte bez důkazů jako fakt.
Ad 2) Pokud považujete pád binárky za zcela běžnou věc, pak ok. Možná by mohlo uvědomit si, že nejsou jen „drsně fault tolerant systémy“ a pak „padací programy“, mezi tím je široká škála a široká potřeba různých spolehlivostí.
Ad 3) Výjimky jsou způsobem ošetřování chyb, jejichž možnosti nelze plně nahradit jiným způsobem. To, že jste lenivý programátor, to je Váš problém.
Jestli ono to nebude o ... "Swift je splacený dluh Applu. Šanci má hlavně v herním průmyslu." ... pricemz kazdy kdo alespon tusi neco o hrach, tak vi, ze to jsou fakticky na vykon jedny z vubec nejnarocnejsich aplikaci. Tzn doporucovat na vyvoj her cokoli jinyho nez co jmenujete (asm/C) je proste padly na hlavu.
Samo, lze postavit nejakou hricku na ledascem, ale realita je takova, ze haci chteji hry predevsim efektni, a to neco stoji - spoustu vykonu.
Proto se tu resi, jak moc to je nebo neni vykonne.
hodne pismenek, qale celkem nesmysly. jen par malickosti:
1)pokud selhava hw, vetsinou to odstreli jakykoli kernel, temer libovolneho OS. nejake vyjimky na aplikacni urovni jsou irelevantni
2) par fault tolerant programu jsem videl, vesmes slo o soustavu procesu vzejemne se hlidajicich, master/slave watchdogy heartbeaty atd....pad binarky je v tomto kontextu zcela normalni resitelna vec, z letadla ani rakety se najednou srot nestane.
3) vyjimky jsou prevazne o falesnem pocitu bezpeci a vybizeji k lenive psanemu kodu bez vetsiho rozmyslu
Jednoduché hry podle mě není tak těžké portovat. Zvlášť dneska, kdy jsou enginy pro různé typy her poměrně na slušné úrovni a klidně zadarmo. Větší herní projekty jsou stejně často psané v C++ nebo C, takže u nich může Swift hrát stejnou roli jako doposud Objective-C: bude v něm napsaný tenký wrapper pro iOS.
Swift není jen nádstavba nad Objective-C, je to samostatný jazyk. Který ovšem výborně spolupracuje s Objective-C, z evidentních důvodů. Překladač Swiftu má zřejmě ještě hodně rezerv, ale v principu podle mě není důvod, aby se ve Swiftu nepsalo téměř cokoliv. Valná většina aplikací stejně nedělá nic, na čem by byl výrazně poznat výkon jazyka, respektive jeho aktuálního překladače.
Není. Pokud jste jenom vzdáleně přičichnul k programování tak byste to měl vědět. Jinak se podívejte na wikipedii a nastudujte si něco o LLVM – Prosím neberte to jako urážku – v této diskuzi není prostor takovéhle věci vysvětlovat.
„Navíc je známý odpor Apple k různým nástrojům, které kompilují programy“ – Přesně stejný odpor je známý v případě firmy Microsoft.
…a vůbec, proč by jakákoliv komerční firma vlastnící rozšířený operační systém (a návazný ekosystém obchodu s aplikacemi) umožňovala? Proč by vyráběla vývojové prostředí pro svou konkurenci???
PS: Google sice vlastní OS – ChromeOS, ale má mizivé rozšíření.
No a proto se ptám, kde v tomto workflow bude figurovat jazyk Swift. U těch jednoduchých nebo náročných her? Prostě u jednoho i druhého vidím optimálnější prostředky - tedy je-li řeč o hrách, které chceme od začátku mít na více platformách.
Ještě poznámka - nezapomínejte na prototypy her. Ty se občas dělají co nejrychlejším, i když ne optimálním způsobem. Teprve když se ukážou jako perspektivní, tak se investuje do dalšího vývoje.
Nezdvořilá byla spíše má poznámka.
Nicméně já nejsem příliš přesvědčen, že jakákoli velmoc, tedy nevyjímaje USA a Čínu, nemá roztahovačné ambice. A mohl bych třeba vyjmenovat také roztahovačné ambice Německa, Francie, Velké Británie a dalších v historii.
A pokud se nějaký další stát stane velmocí, nebo bude mít tu možnost, bude se roztahovat také. Máte krásný historický příklad s Mnichovskou zradou 1938, kolik zemí a států si velmi rádo ukouslo z území Československa, když jim byla dána tato možnost. Je to velice poučné.
Navíc mám dojem, že namísto faktů dostáváme v Česku z médií jen manipulace ve stylu Goebbelse, a výsledkem jsou zjednodušená dogmata typu „roztahovačné Rusko jako Apple“, či „neroztahovačné demokratické USA“.
Miloslav Ponkrác
Ještě bych mohl dodat další nedomyšlenost Swiftu, která ukazuje, že Apple zřejmě vůbec neuvažuje nad přenositelností. (Na rozdíl od C.)
Na mnoha platformách nejsou k dispozici typy Int16 a UInt16. Na řadě procesorů mimo x86 je vůbec nenajdete. Jejich emulace v programovacím jazyce je sice možná, ale výsledný kód je pak neskutečně pomalý a líný.
V C se nic takového neděje. V C nemusí takový typ existovat, namísto toho je zde int_least16, tedy typ s nejméně 16 bity.
Jednoduše Swift nic moc. Ten, kdo ho v Apple navrhoval byl hochštapler.
V C je logika naprosto jiná. V C je implicitní integer typ roven nejrychlejšímu integeru typu, většinou přirozenému typu daného procesoru.
U Swiftu je logika taková, že to Apple nedomyslel. Swift je evidentně jazyk udělaný na přitáhnutí těch, co nemají rádi ObjectiveC, ale když jsem si přečetl jeho příručku od Apple, myslím, že celkově jde o značně nedomyšlený jazyk. Na mnoha úrovních. Ostatně, deviza Swiftu je v přetáhnutí vývojářů k Apple, tedy marketinkový a obchodní cíl, nikoli být dobrým programovacím jazykem.
U Swiftu jsem existenci typů Int/UInt opravdu nepochopil. Zřejmě prostě marketinkový cíl zabránil Apple přemýšlet. Tím spíše, když ve Swiftu jsou typi Int8 až Int64 a totéž pro UInt. Na 64bitové platformě nemusí být 64bitový integer ten nejrychlejší.
Jinak řečeno, C má logiku, proč to tak dělá a důvod. Swift logiku v implicitním integer typu nemá žádnou. Kromě zbytečné složitosti a nesmyslů. Prostě jim nejspíše datové typu navrhoval asi přeučený kuchař, nebo uklízečka. Nikdo se nad tím v Apple nezamyslel.
Miloslav Ponkrác
"U her je tato vlastnost docela žádoucí."
U her je žádoucí hlavně rychlost. Pokud naprogramujete hru v C# a pak přeložíte pro všechny mobilní platformy pomocí placeného nástroje, pak to bude fungovat, ale rychlé to nebude. U nějakých jednoduchých her to rozhodně bude stačit, ale na 3D střílečky rovnou zapomeňte. Ostatně profesionální vývojáři her už tu hru navrhují tak, aby pro přenos na jinou platformu museli přepsat minimum kódu (vlastně jenom zobrazení a uživatelský vstup). Sice to znamená, že si všechno programují sami (využívají naprosté minimum volání systémového API a veškeré použité knihovny staticky linkují), ale zato potřebují přepsat minimum kódu.
…ale to je zcela stejné jako ve standardním C (http://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_20.html#SEC400)
Pokud vám nebude jedno jaký Int použít, nebo prostě jen budete chtít mít typ pod kontrolou zvolíte namísto prostého typu „Int“ následující UInt8, UInt16, UInt32 nebo UInt64. Lze to také globálně zadat při kompilaci. Jako všude jinde.
Možná laický dotaz, ale někde jsem četl, že swift je jen nějaká omalovánka nad objectivec, takže se v něm vytvořený program kompiluje nejdřív vnitřně do céčka. Tj. programátoři náročných aplikací budou stále dělat v objective c, zatímco 99 % hračiček se bude moci dělat ve swiftu. Je to tak?
Jinak s článkem souhlasím - sám bych taky rád programování pro svůj iphone/ipad/ipod vyzkoušel, ale nemám mac, nemám developer licenci... Tj. musel bych investovat 20+ tisíc, abych to třeba jen vyzkoušel. U Androidu a Windows takový problém není.
Navíc je známý odpor Apple k různým nástrojům, které kompilují programy z jednoho jazyka do všech 3 systémů a app store, dříve to dokonce zakazovali.
Více hodnot najednou dne umí vrátit třeba i C++ nebo Python. A přesto mají výjimky, protože jejich autoři mysleli prakticky, ne ideologicky.
Nedostatek paměti může vzniknout i v podprogramu, který nevrací žádnou hodnotu. Třeba si podprogram alokuje buffer, přes který provede svou činnost, ale návratová hodnota nemusí být žádná.
Přístup mimo platnou paměť je snadno ošetřitelný pomocí výjimek, a může být použit i ke zjištění, zda je adresa platná. Třeba ve Windows takový přístup vyhodí výjimku jádra operačního systému, která se předá programu, a pokud je Windows program schopen si výjimku ošetřit, pokračuje se dále. To segfaultem neošetříte, tam to max. padne na hubu.
NaN je hodnota floating point čísla. Neexistuje na proměnných typu integer, stejně jako dalších. Tedy stále nemáte ošetřeno dělení nulou.
Jednoduše, v objektivní debatě byste prohrál názor, že výjimky nejsou třeba.
Považujete NASA za idioty? (Abych použil stejný argument, jako jsem dostal?)
Miloslav Ponkrác
Swift umí vrátit víc hodnot najednou, v Objective-C se chybový objekt obvykle vrací pomocí výstupního parametru. Ano, je s tím psaní, ale zároveň je to prakticky explicitní. Pokud se programátor nechce obtěžovat ošetřováním chybových stavů, výjimky ho nedonutí, viz klasický javový idiom „catch (Exception) {}“.
Nedostatek paměti se už teď signalizuje vrácením nulového ukazatele, tam není co extra řešit. Přístup mimo platnou paměť je prostě segfault, na tom není nic špatného. Dělení nulou už se dneska neřeší výjimkou, prostě se vrátí NaN.
Protože ne všechny chyby vznikají přímo v kódu. A pokud máte jazyk bez výjimek, tak s chybami, jejichž zdroj je mimo kód často nic neuděláte, a takový program jednoduše krachne na ústa, protože nic s tím dělat nemůže.
Pouze výjimky dovolují ošetřit skutečně maximum chybových stavů. Nic jiného.
Ministerstvo obrany USA a NASA se v minulosti velmi rychle přesvědčila, že pokud si do programovacího jazyka Ada nepřidají výjimky, budou mít ve zničených raketách škody ve stovkách miliard dolarů. Protože ovládací programy budou krachovat, kdykoli se vyskytne nečekaná věc a vezmou sebou i celou raketu, která se tím pádem stane neovladatelným kusem šrotu.
Váš pokud postavit 2 jména lidí s dotazem, jestli je považuji za idioty, budu ignorovat. To, že je někdo slavný neznamená, že se nemýlí, nebo nedělá občas chybná rozhodnutí nebo nemá chybnéí názory.
Navíc kolem Unixu vznikají mnohé názory, které jsou jasně spíše ideologického (tedy sektářsky motivovaného) důvodu, často proti praxi a užitku a racionalitě.
Znovu, mnoho chyb vzniká mimo kód. Hw je dnes čím dál složitější. Chyby v něm vznikají jak na běžícím pásu. Když nastane chyba v kontrolním součtu RAM, jinak, než výjimkou z toho nevybruslíte. Když vám začne docházet místo na zásobníku, když nějaký hw uprostřed operace nečekaně zkolabuje, nebo když se vyskytne cokoli neobvyklého, co nemá původ ve vašem zdrojovém kódu – bez výjimek program pouze pane na hubu, nic jiného nejde. S výjimkami je schopen, je-li to nutné, se z toho dostat a pokračovat bezchybně v běhu.
Bez výjimek prostě neuděláte tak spolehlivý sw, jako s nimi. Chápu, že začátečníci, kteří si myslí, že chyby vznikají pouze ve zdrojovém kódu, a proto se dají vždy vrátit a ošetřit jako návratové hodnoty funkcí, že pak výjimky jsou zbytečné.
Stejně tak ošetřování chyb pomocí výjimek je v každém případě přehlednější a účinnější.
On líbivý programovací jazyk, jako Swift nebo Go, je v podstatě jen vrtkavá móda. To jsou jazyky, které se dělají z marketinkových důvodů a z důvodů reklamy, ale praktické nejsou. Při jejich návrhu se nad jejich praktičností ani za mák nepřemýšlelo. Prostě neviditelná ruka trhu prodává také iluze, nejenom užitek.
Miloslav Ponkrác
Takže je nutné zatěžovat návratovou hodnotu chybovými hodnotami. A pak je třeba taková maličkost, jako donutit programátory tyto chybové hodnoty číst a respektovat.
A až nastane chyba typu „není dostatek paměti“ nebo „přístup mimo platnou paměť“ nebo „nedostatek místa na zásobníku“, případně „dělení nulou“, apod., pak zajisté všechny funkce budou tyto hodnoty předávat do návratových hodnot. Jen musí nějak vymyslet, jak třeba to dělení nulou kód funkce odchytí.
Takto se tvoří programovací jazyka, které nejsou s to ošetřit základní stavy runtime prostředí, a bude ještě jednou velmi veselo.
Objective C byl zoufalou snahou o naroubování Smalltalku na programovací jazyk C, který se snažil o minimalizaci zásahů do jazyka C.
Z dnešního hlediska je opravdu zastaralý a nezvyklý. Není problém si zvyknout ani na šibenici, když je nutnost, klidně i rychleji, než na 14 dní.
C je tedy těžkopádné ve všem. Elegance Smalltalku se nedosáhlo ani vzdáleně. Zato se přidaly nevýhody spočívající ve vlastnostech jazyka C. Kromě toho dnes nezvyklý model předávání zpráv pomocí řetězců namísto seznamu metod, atd.
Já osobně Objective C také nemusím. A protože evidetně nedokážete chápat význam slov ani textu, tak Vás upozorním, že sloveso „stěžovat si“ nemá tentýž význam jako sloves „zvyknout si“ nebo „naučit se“.
Miloslav Ponkrác
Je úsměvné sledovat, jak se u Applu střetávají ty protichůdné proudy - na jednu stranu by chtěl mít všechno těsně pod pokličkou, uvavřené, proprietární a zkrátka vysoce "své", na druhou stranu závidí (relativně) otevřenému Androidu (potažmo Linuxu) v podstatě vše - rozmach, širokost záběru i výběru, počet vývojářů. Inu, není možné při svíci mít ve světle tvář i v teple zadnici.
"iOS platforma obecně generuje vývojářům větší zisk" - na tuhle poučku začínám být alergický. Jako by se veškerá ekonomika odehrávala v té krabičce. Ono je nutné se na to podívat trochu šířeji. Když si banka udělá hezkou aplikaci pro Android, tak jí to zákazníky určitě přivede a tržby zvýší. Ale určitě to není evidováno v kolonce "zisk z Androidu".
"V čem je Objective-C těžkopádné a zoufale zastaralé?"
VE VŠEM! Dělám pro OSX/iOs, a kdyby se neobjevili Delphi pro OSX/iOs tak se na to vykašlu.
Ale o mně nejde. Podívejte se na světové weby. Desítky tisíc uživatelů si na Objective-C stěžují, jde to najít v každém programátorském foru, noví developři ze školy zvyklí na C# a JAVU se prostě takovou nepřehlednou obludnost ani učit nechtěji! Objective-C je prostě "hnus fialovej" to se nedá jinak ani říct...
Nový jazyk byl nutností.....
B,
S tím prezentovaným výkonem swiftu to není až zase tak převratné jak to vypadalo na WWDC prezentaci. Na S/O to rozebírají a podle všeho tam dost hodně závisí na parametrech kompilátoru / zvoleném stupni optimalizace. V podstatě se musíte vzdát některých kontrol (typovost, přetečení) abyste dosáhli výkonu čistého C. Ale to je asi logické.
LINK: http://stackoverflow.com/questions/24101718/swift-performance-sorting-arrays
Obávám se že tady se autor velmi sekl. Celý článek ve mne budí dojem, že je Apple si zase něco vymyslel, co jinde mají už dávno a v podstatě se o Apple nezajímají.
Autor zcela pominul fakt, že iOS platforma obecně generuje vývojářům větší zisk, než Android. Na Androidu je valná většina lidí, kteří chtějí mít vše zadarmo. Na iOS jsou zvyklí si za dobrou aplikaci připlatit. To dělá z iOS velmi populární platformu mezi vývojáři a není výjimkou, že aplikace se vyrábí primární pro iOS a teprve po delší době se převádí pro Android.
Můžeme tu diskutovat o tom, jestli je lepší java, C# nebo Objektove C. Ale rozhodně se nedá oddiskutovat, že Objektove C a ted Swift jsou jediné jazyky, které budou fungovat pod iOS platformou a pokud chtějí vývojáři přístup k ziskům z Applovského App storu, budou muset své aplikace v těchto jazycích programovat. Mnozí to dělají rádi a mnozí si také stěžují, že programovací jazyky pro Android nedosahují kvalit Objektoveho C. V každém případě se ale vývojáři tento jazyk učili rádi, protože ve finále jim přivedl větší peníze než z Androidu.
"na každé platformě bude vypadat podobně" - to mělo být spíš před tím "ale", ne za ním, ne? :) U her je tato vlastnost docela žádoucí.
Jinak si nemyslím, že by nebyla tak dobrá jako nativní, a hlavně nemusí být řeč o kompletně multiplatformním řešení, ale aspoň o takovém, kdy sdílíte 80 nebo 70 nebo 60 procent kódu. Ale co budete sdílet se Swiftem?
Víte hodně lidí, co programuje weby (PHP/Javascript…) byla zákazníky oslovena, aby jim naprogramovala nějakou super-truper aplikaci pro mobily. Webový vývojáři si tedy koupili iPhone a začli dělat aplikace stylem aplikace ala WebViewContainer (aplikace je v podstatě jen zabalené okno prohlížeče => žádná přidaná hodnota). Ale zákazníci najednou zjistili, že tohle nechtějí (mají přece moderní responzivní web) a tak vývojáři začali používat věci typu PhoneGap apod. To už bylo trochu lepší, ale stále pro zákazníka nepřijatelný humus a žádná přidaná hodnota. Zákazníci se začali poohlížet jinde, ale zjistili mít další vývojový tým je nákladné ať již v rovině zvýšené a pomalé komunikace tak financování dalších lidí. Takže jak přiblížit zákazníky a obrovskou masu „programátorů“ webových aplikací – udělat pro ně srozumitelnnější jazyk – Swift. Takový vývojář co dělá léta v PHP a Javascriptu si na Swift zvykne mnohem snadněji a rychleji než na Microsoftí C# nebo Androidí Javu/Dalvik!
Autor trošku tápe v problematice. Jednak Objective-C nevzniklo s platformou iOS, ale už delší dobu se používalo v OSX. Potom také ta výtka proti nepoužití JavaScriptu. Vždyť to ale jde. Není problém vytvořit aplikaci víceméně z Javascriptového/HTML kódu. Jen to na první pohled nepoznáte, je to celé zabalené opět do stejného instalačního balíčku. Dokonce HTML5 byl první způsob tvorby aplikací pro iPhone, než vůbec přišla možnost nativního programování, od počátku žádaná ze všech stran právě proto, že tvorba pomocí webových technologií je proti nativním dost zásadně limitující a jejich běh je mnohem méně efektivní.
Řada lidí je proti výjimkám. V Objective-C výjimky jsou, ale používají se minimálně, chybové stavy se idiomaticky řeší vrácením chybového objektu. Což je sice na první pohled pracné, ale zato jednoduché a explicitní. Swift v tomhle přístupu pokračuje, podobně jako třeba Go.
"Na straně počítače naprosto stačí nejlevnější Mac mini v ceně 16 tisíc, u PC se obvykle pod 8-9 tisíc nedostaneme a to bez OS. I když tedy předpokládáme vývoj na Linuxu, tak to zas tak dramatický rozdíl není."
U PC se dostanete bez problému níž, nehledě na to, že většina lidí, hlavně vývojářů, to PC už jaksi dávno má :D :D :D
... téměř v ničem. Na mne působí jako článek od někoho který o celé platformě jen četl, případně ji zná jen z doslechu. Šermovat s číslem 81% je sice úžasné, ale tady se píše o vývoji aplikací a kolik lidí s Androidem KOUPÍ alespoň jedinou apikaci přes store? OBJ-C je jiný jazyk než většina současných kompilovaných, bez VM, ale je to dáno tím, že koncepčně vychází hodně ze SmallTalku. Swift je na pohled velice jednoduchý jazyk někde mezi Javou a C#. Což určitě usnadní učení ale takjako tak musí vývojář především zvládnout koncepci platformy a to je kolikrát mnohem složitější než se učit nový jazyk. IMHO ;)
V čem je Objective-C těžkopádné a zoufale zastaralé? Je to jednoduchý a pragmatický jazyk, který nabízí hezké řešení správy paměti (automatické počítání referencí), dynamické zasílání zpráv a volitelné dynamické typování, tedy relativně moderní věci. Syntaxe zasílání zpráv je odlišná téměř od všeho, na co jsou lidi zvyklí, ale oproti pozičním parametrům je taky výrazně čitelnější. Objective-C není sexy, ale je to velmi kvalitní kus technologie. Ano, není nejnovější, ale rozhodně bych ho neoznačoval za zoufale zastaralé.
Když Apple vydával první SDK pro iPhone OS, zařízení ještě byla dost pomalá. Objective-C byla z toho pohledu dobrá volba, protože se v něm dá dobře držet blízko železu, aniž by měl člověk pocit, že píše v assembleru. (Na Androidu bylo v prvních letech vidět, jak s Javou výkonnostně válčí.) Kromě toho bylo pro Apple logické využít jazyka, ve kterém se programuje pro OS X.
Nevím, jestli Apple potřebuje snížit náskok Androidu. Má smysl šermovat počtem prodaných zařízení? Co takhle finanční podíl na trhu? Apple vždycky šel po kvalitě, případně vyšších maržích, chcete-li. Nebude do krve soupeřit s Androidem na poli levných zařízení.
Co se rychlosti týká, proč by měl být Swift rychlejší? Možná se bude líp optimalizovat díky typovým anotacím, ale Objective-C je zatraceně rychlé (dýchá na krk C++), takže nepředpokládám, že by právě rychlost měla být hlavním tahákem. Kvůli některým dodatečným kontrolám může být místy naopak pomalejší než Objective-C se svým desítky let optimalizovaným runtimem.
„Konzistentní uživatelský zážitek“ stojí na jiných věcech, než je programovací jazyk. „Napsat jednou, nabídnout všude“ je iluze. Každé zařízení má vlastní pravidla, vlastní logiku. V JavaScriptu bych větší aplikace rozhodně psát nechtěl, pevnější jazyky se striktnějším typovým systémem jsou k tomu podle mě výrazně vhodnější.
Závěr článku je podle mě úplně mimo. Hlavní motivací pro existenci Swiftu není výkon. Apple se od začátku snažil modernizovat Objective-C (automatické počítání referencí, deklarované properties, closures, collection literals) a snižovat laťku pro vývoj na iOS. Swift je prostě jen logickým pokračováním těchto snah. Nic víc, nic míň.
No nevím, tato část článku je hodně přehnaná. Pominu skutečnost, že hodně (spíš většina vývojářů) si něco od Apple pořizovala zcela dobrovolně a přímou souvislost to nemá, ale i kdyby ne, tak ty náklady se zas tak neliší.
Na straně počítače naprosto stačí nejlevnější Mac mini v ceně 16 tisíc, u PC se obvykle pod 8-9 tisíc nedostaneme a to bez OS. I když tedy předpokládáme vývoj na Linuxu, tak to zas tak dramatický rozdíl není.
Koncové zařízení (telefon/tablet) sice je u Applu dražší, ale opravdu seriózní vývojář (o kterém autor píše) by si měl u Androidu držet těchto zařízení pěknou hromádku s ohledem na známé odlišnosti, což cenový rozdíl hodně srovná a leckdy i otočí. Nemohu si pomoci, ale debatovaný cenový rozdíl nedělá ani pro naprostého začátečníka "tisíce dolarů v množném čísle", je to spíš relace "jeden tisíc dolarů" rozdíl pro start, ale po nějaké době s trendem se spíš zmenšovat než zvětšovat.
Jinak ale článek zajímavý a s lecčím souhlasím :-)