Co přináší rorýs

Díky za poznámky, docela jsem čekal jestli k tomu něco napíšete :-)

Do příručky už jsem se začetl a i když mi v tuto chvíli připadá jako méně čitelný než Objective-C a zdá se mi že v něm půjde snadněji psát nečitelný kód - vím že je to tak s každým novým jazykem. Určitě v něm zkusím napsat nějakou z menších aplikací pro iOS na které se chystám.

Zajímavé také bude jak dobře bude fungovat ten playground...

V každém případě spolu s hromadou nových API a důrazem na vytváření kitů pro komunikaci se specifickými typy aplikací a periferií (Health, Home) je to quantum leap vpřed.

https://developer.apple.com/swift/

>Minimálně by mohl být snazší na naučení pro začátečníky než ObjC

To rozhodně, pro toho, kdo pracoval, s JavaScriptem, Ruby, Pythonem je to daleko snažší na pochopení než ObjC!
Psát se dají nejemom aplikace pro iOS ale i pro samotný OS X.
IMHO podpora je na úrovni v LLVM, takže programovat budete moci všude, kde poběží LLVM(CLANG).

@Makovec Všechno je o zvyku, taky něco zkusím a uvidíme. Zatím jsem o Swiftu jen četl, takže nemůžu blíže hodnotit. Ale vypadá slibně.

@fe To s tím LLVM není tak úplně pravda. Pokud některé literály (typicky pole, hashmapy apod.) vyžadují runtime (a předpokládám, že ano, kvůli kompatibilitě), tak to jinde použitelné nebude (bez něčeho jako gnustep).

@zboj Je jasné, že nenapíšete celou multiplatformní aplikaci – na to byste potřeboval celé API (Cocoa/gnustep) pro danou platformu, ale IMHO, že základ bude přenositelný. Myslím, že to bude podobné jako když dnes můžete programovat v ObjC na Linuxu.

Vzhledem k tomu, že Swift je překládán LLVM, tak očekávám, že bude na Windows i Linuxu fungovat také. Nicméně mi připadá jako Go pro ObjC a navíc má některé dost podivné konstrukce. Hned na hlavní stránce Swiftu mě zarazilo tohle:

var sortedStrings = sort(stringArray) {
$0.upperCaseString < $1.upperCaseString
}

Proč je ta lambda zapsaná mimo parametry funkce sort, když je to zcela evidentně její parametr?

Stejně tak zápis lambda funkcí s parametry je dost podivný, když se parametry zapisují na začátek těla té funkce. A proč některé lambdy mají explicitně uváděné parametry, zatímco třeba ta lambda pro sort má implicitní parametry, nešlo by to nějak sjednotit? Prostě mi to přijde jako ne moc domyšlený jazyk.

@Sten LLVM bez runtimu je dost na nic. V tom sortu je trailing parameter. Ten jazyk je naopak velmi promyšlený, různé skryté detaily mu dodávají na sofistikovanosti (pokud o nich člověk ví).

Sten,
lebo oni usudili, ze pokial je lambda posledny parameter funkcie, tak ju mozete napisat do { .. } za vyraz, $0 a $1 su prvy a druhy parameter lambdy

podobne to ma aj groovy a myslim aj scala

ale inak voci tejto konstrukcii frflalo vela ludi, ze vraj to evokuje perl

hmm , uz to bylo vickrat .. http://www.swift-lang.org

@zboj: Ruzne skryte detaily jsou cesta do pekel. Je fascinujici, ze v beznem prumyslu se lidi snazi o to, aby se eliminovala vsechna mozna rizika spojena se selhanim lidskeho faktoru, ale v SW prumyslu se nad tim lidi rozplyvaji.

Napr. v tom priklade se tridenim staci dat za ')' znak '\n' a vznikne validni kod, ktery ale dela neco uplne jineho. To pak staci, aby dosel clovek, ktery ma rad uzavorkovani ala C# a je o chybu postarano, proste zmenim formatovani... co se muze stat?

Jinak o rozsireni jazyka dnes nerozhoduji vlastnosti toho jazyka, ale standardni knihovna. Jelikoz to bude vazane na Cocoa, pochybuji, ze se to rozsiri jinam nez mimo platformu Apple.

@ded.kenedy

Naprosto souhlasim. Navic mi prijde, ze to vlastne krome syntaxe nic noveho neprinasi, tak kde je ten "inovativni pocin"?

tohle je asi něco jiného, nebo se pletu?

http://swift-lang.org/

@JS Jasně, že to přináší nové věci, viz kniha z iBooks. Zajímavé je například řešení mutable/immutable kolekcí.

@ded.kenedy Já chápu, že někdo, kdo "kóduje" weby a sem tam napíše nějaký ten řádek SQL, asi ty užitečné detaily neuvidí nikdy a jediné, o čem je ještě schopen diskutovat na aspoň trochu relevantní úrovni, je syntax, resp. kam se dá konec řádku a co to asi udělá. Ten jazyk dost dobře eliminuje "lidský faktor", ovšem stále je určen pro vývojáře, ne někoho, kdo akorát umí syntax a pod pokličku nevidí.

@dwarven To je něco jiného – soud o ochrannou známku? Kdo ví, ale spíš ne.

@ded.kenedy "…ovšem stále je určen pro vývojáře, ne někoho, kdo akorát umí syntax a pod pokličku nevidí"
Samozřejmě, pro "nevývojáře" a lidi, kteří nechtějí vidět pod pokličku má Apple jiné nástroje (Automator, AppleScript)

Nove veci to neprinasi, neni to inovativni z pohledu vyvoje programovacih jazyku. Vsechno co tam je "inovativniho" uz existuje minimalne tak 10 let v jinych programovacich jazykach.

Inovativni to je jen pro Apple a pro Obj-c, ve kterem to predtim nebylo / bylo to slozite udelat.

@Ondra Blbost. Doporučuju získat nějaké znalosti o jazycích před ztrapňováním se "kritikou" na fóru. Jen namátkou: 1) Který jazyk automaticky rozhoduje o tom, který parametr lambdy se zkopíruje na haldu, 2) který má v syntaxi podporu mutable/immutable kolekcí? Z mainstreamu žádný.

[14] Nejak v tom prispevku postradam argument. Misto nej jsem tam nasel jen utok ad hominem.

[18] 1) Implementacni detail a navic se to resilo v lispech uz nekdy v sedmdesatych letech. 2) Opet jen otazka syntaxe.

1) napr. C# ... uzavery (closures) se takhle delaji
2) D napr.

Ty jsi sam napsal, ze: Stručně shrnuto žádná revoluce, ale mírná evoluce. Tak proc se rozcilujes?
....
Divam se sem: https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2-XID_1

a co tomu rozumim, tak nic noveho. Doufam, ze mi ted nebudes psat, at napisu nejaky jazyk co ma generika.

Swift na me pusobi dojmem, dobre navrzeneho jazyka, ve kterem jsou vsechny vymozensti modernich jazyku, ale nic co bych uz nevidel jinde. Je tam vsechno co chybelo v Obj-C. Ale nevidim duvod, zvlast kdyz je to Apple only proc se to ucit.

Ono to chce obcas zvednout hlavu od Applu a zjistit, ze venku je cely velky svet.

@Ondra Právě v C# se uzávěry chovají úplně jinak.

> Swift na me pusobi dojmem, dobre navrzeneho jazyka, ve kterem jsou vsechny vymozensti modernich jazyku, ale nic co bych uz nevidel jinde.

Bohužel si nese neduhy rozšířených programovacích jazyků - např. dědičnost s otevřenou rekurzí nebo velké množství podobných konstrukcí (zbytečně to dělá jazyk složitý a v podstatě to nic nepřináší).

Nevýhodou je rovněž počítání referencí - jednak je to pomalé a navíc v podání Swiftu může docházet k memory leakům kvůli cyklickým referencím.

@Radek Miček Počítání referencí je pořád efektivnější než jiné formy správy paměti. Na cykly je "weak" a "unowned". Syntax je někdy komplikovanější, ale naučit se asi dá (čas ukáže, co se bude používat). Na první pohled jde o nejsympatičtější "nový" jazyk poslední doby, ale chce si to pořádně osahat.

nema to ani exceptions
sablony jsou stejne jak v c++ pomoci operatoru mensi vetsi , to je peklo na zemi to napsat spravne aby to ten prekladac pak pochopil.

pocitani refrenci je dedictvi objc/cocoa na ktery je to napojeno.

co je mysleno dedicnosti s otevrenou rekurzi? diky

[23] Tak na to pozor! Počítání referencí je sice možná rychlejší, ale na úkor práce vývojáře, který musí řešit rozpojování cyklů, které jsou z podstaty věci v pořádku. Co jít do důsledku a udělat rovnou všechno weak? (To je pochopitelně nesmysl.) Takže z mého pohledu prasárna a ještě k tomu místo potenciálních průserů.

[25] - Ja bych k tomu nebyl tak kritickej, tech par cyklu se da ohlidat. Ten jazyk je primarne urcen na iphone/ipad vyvoj. A apple to ma celej framework pro to zalozenej na pocitani referenci a velky zkusenosti s takovym pristupem (Obj-C 2). Oni asi tezko prepisi kvuli tomu komplet cele api.

Otazka je jestli, to jde udelat i jinak, jestli mam moznost, kdyz nechci pocitat reference, tak si pamet spravovat sam? Mam?

@SB Kdo nezvládne pochopit a efektivně používat RC, nemá v programování co dělat. Swift předpokládá (jako většina jazyků) od vývojáře určitou míru inteligence.

[27] Znamená to tedy, že garbage collector s detekcí cyklů byl vyvinut pro debily? Svatá prostoto... Popravdě si nyní nejsem jistý, komu ta inteligence vlastně chybí.
Každopádně radši budu za debila a Swiftům ap. se vyhnu a budu ve vývoji řešit důležitější problémy, než je rozpojování cyklů.

@SB V podstatě, i když spíše bych užil výrazu "cvičené opice". RC je prostě jeden způsob GC. Server s 16GB si klidně může pouštět aplikace s plně automatickým GC, nicméně na mobilním zařízení nebo dokonce něčem à la Raspberry s omezenou pamětí by to použil fakt jen trotl. On i ten Swift nemá typické RC, protože má pooly atd. Čisté RC jsou například chytré ukazatele v C++. Tímto diskusi o RC končím.

na androidoch bezi plnopravny gc

takze pozor s tymi trotlami

@perceptron Taky to podle toho vypadá :)

[30] To by možná vysvětlovalo, proč jsou levnější telefony, nebo tablety (s Androidem) tak nervy ničící.

[28] Apple se dává vývojářům to, co je podle něj nejlepší. Všichni s tím nemusí souhlasit a nelze se zavděčit všem. Rozumím tomu, že vývojáři, kteří budou chtít dělat multiplatformní aplikace mají dnes jen jedinou, i když finančně náročnou, volbu – Xamarin. Avšak opakuji ani MS ani Apple ani Google nebude dělat pro vývojáře vývojové prostředí, kde budete moci naprogramovat aplikaci a pak ji vyexportovat pro všechny stolní i mobilní systémy – to by byli sami proti sobě.

[29] Souhlas.
[30] Nesouhlas.

Co se týká Androidu a iOS, každý kdo vedle sebe viděl oba systémy s podobnými parametry (např. iPad2 (iOS 5/6) a ASUS Transformer 101 (Android 4)) tak musí uznat, že iOS je daleko svižnější systém. Stačí jen zapnout prohlížeč (v případě Androidu jakýkoliv) a navštívit Facebook nebo jinou stránku s větším obsahem JavaScriptu.
Netvrdím, že je to zrovna následek použití jiného CG na Androidu a jiného na iOS, spíše to bude kompletním návrhem systému, který je v případě Androidu Google udělal tak, aby se co nejrychleji OS rozšířil mezi programátory, aby se museli učit minimum nových věcí. Bit je na tom pak jen a pouze uživatel.

@fe Tak to bývá, když dá někdo Javu na mobil (i když Google si napsal Dalvik, jenže některé problémy jsou prostě inherentní jazyku). V době vzniku Androida ovšem ObjC bylo ještě dost náročnější na naučení. Kdyby Google chtěl problémy s výkonem řešit, začal by prosazovat NDK.

a: google nemusi riesit problemy s performance: pozrite sa ako vyzeraju jeho stock zariadenia proti zabloatwarovanym nadstavbam. a pozrite sa co sa stalo s performancom na 4.x rade oproti 2.x, a pozrite sa, co sa deje s artom

a nic z toho nema spolocne s tym, ze full gc a java je primarny vinnik domnelej pomalosti

[35] Díky že potvrzuješ [33]

ano, suhlasim s tym, ze android je mnohokrat menej svizny nez ios, ale rozhodne to nie je ani kvoli jave, ani kvoli gc. sny, ze keby sa tam nahodil nejaky low-level jazyk, android by sa magicky rozbehol a porazil ios, su ale mimo reality.

[37] "sny, ze keby sa tam nahodil nejaky low-level jazyk, android by sa magicky rozbehol a porazil ios, su ale mimo reality" – Vidíš, a Apple si myslí, nový jazyk je cesta – nejenom k rychlosti samotných aplikací ale i k rychlosti vývoje.

apple vsak ide (mudro) takticky od syntakticky zlozitejsieho objectivec k jednoduchsiemu swiftu, pricom low-level platforma ostava rovnaka: motivacia je aj tak prilakat novacikov.

android je na tom inak: ako som pisal vyssie, uz teraz je na stock hardveri vanilla android 4.x pohodlne vykonny a google nema potrebu tam rvat nieco diametralne odlisne v duchu "strcime tam kompilovane go": jednoducho ta java a jvm funguje uspokojivo aj "napriek" povysenym vykrikom z davu, ze "full-gc-by-tam-dali-len-trotli".

a, kto programoval androidy, vie, ze aj tak jadro problemov (a vykonnosti) nie je ani v syntaxi, ani v gc, ale v nuansach a vyuzitiach jeho api

[39] Nemyslím si že je to kvůli nováčkům, myslím, že o vývojáře nemá Apple nouzi – rychlost loňského a předloňského rozprodání lístků na WWDC je toho důkazem.
Spíš si myslím, že je to taktika: „Pojďte programovat na iOS u nás to jde snadno a na Android/Win zapomeňte, tam to jde složitě“ – ostatně o tom je celá filozofie Apple už od vzniku firmy.

[14] Nikoliv, tohle je naprostý fail u jazyku, který se snaží zaujmout tím, že údajně zabraňuje vzniku chyb, když jen jinou coding convention způsobí polonefunkční programy, protože to bude nadále fungovat u všech funkcí i lamb kromě těch trailing. Nevím o jiném jazyku, kde by bylo něco podobného. Navíc v dokumentaci se píše „Whitespace has two uses: to separate tokens in the source file and to help determine whether an operator is a prefix or postfix (see Operators), but is otherwise ignored“, což evidentně v tomto případě není pravda.

[27] Tenhle fundamentalismus se dá snadno obrátit proti vám: kdo si nedokáže hlídat paměť sám, nemá v programování co dělat ;-)

[33] Navštívení webu Facebooku ale o použité správě paměti neříká vůbec nic, protože JavaScript má plný GC jak na Androidu, tak na iOSu. Ono to ani jinak nejde, JS nemá nic jako weak reference a bez plnohodnotného GC by Safari celkem rychle sežralo veškerou paměť (obzvlášť na iPhonech).

[38] To si MS myslel se C# taky :-)

@Sten "kdo si nedokáže hlídat paměť sám, nemá v programování co dělat" Taky že ne, i když trochu bych to upřesnil. Každý jazyk má správu paměti trochu jinak. Každý by měl zvládnout právě ty specifické rozdíly. V C++ taky není manuální správa paměti (ve smyslu "není žádoucí"), maximálně se má využívat RAII. Ve Swiftu člověk nemá moc na výběr, je tam ARC. V C++/CX je taky RC atd.

"pokročilí beztak sáhnou spíše po ObjC" - prosim o rozvedeni. Umoznuje ObjC neco, co ještěrka/moták/ro­rýs ne?

@Cousot Jistě, nízkoúrovňové programování. A taky mixování s C++ (to je tedy oficiálně v ObjC++, ale stará se o to stejný překladač).

Tim nizkourovnovym programovanim je mysleno konkretne co? Pointery by to umet melo: https://developer.apple.com/library/prerelease/ios/documentation/swift/conceptual/buildingcocoaapps/InteractingWithCAPIs.html Byl by konkretni pripad co ve swiftu udelat nejde a v objc jde? Dodalo by to tvrzeni vahu… Tim prekladacem je myslen frontend pro LLVM? Diky

@Cousot Tím je myšleno C jako takové. Překladačem je myšlen buď clang nebo GCC (takže ano, frontend, i když ne nutně pro LLVM).