Swift. Tak se jmenuje nový, včera představený jazyk od Applu. Nová je vlastně jen syntax, tedy frontend pro LLVM, protože se využívá již existující překladač a jako API Cocoa. Ale právě ta syntax je zajímavá.
Na první pohled Swift vypadá jako skriptovací jazyk, něco mezi Javascriptem a Pythonem. Nemá například funkci “main”, žádné include atd. Funkčně je to jakési (méně čitelné) ObjC bez nízkoúrovňových věcí. Stručně shrnuto žádná revoluce, ale mírná evoluce. Nicméně kouzlo se skrývá v detailech.
Nejhezčí jsou jednoznačně generika a přetěžování operátorů. To první zvýší bezpečnost programů, to druhé zpřehlední kód. Pěkně jsou také řešeny uzávěry, narozdíl od všech rozšířených jazyků překladač automaticky určí, jaký parametr bude zkopírován nebo přenesen na haldu. Tím odpadá kód typu
__block __typeof(self) me = self;
a podobné divnosti. Celkově se jazyk tváří značně funkcionálně a dá se říct, že role tříd (resp. OO jako takového) poklesne, případně zůstane omezena na API, jež stejně většina používá jako blackbox.
Většinou protáčím oči vždy, když čtu o novém jazyce. V případě Swiftu se jedná o opravdu inovativní počin, byť na zhodnocení je ještě brzy. Pokud jej bude Apple tlačit jako Microsoft své C#, bezpochyby se uchytí. Minimálně by mohl být snazší na naučení pro začátečníky než ObjC, i když pokročilí beztak sáhnou spíše po ObjC.
Zajímavým postřehem je, že ObjC se s příchodem Swiftu dostává do pozice C++/CLI, tedy jazyka pro psaní wrapperů nativních knihoven. Toto srovnání sice trochu pokulhává, protože Swift se překládá přímo do nativního kódu, ale na úrovni API se to nabízí (pokud neexistuje nějaká přímější metoda à la JNA, informací je zatím málo).
Teď už jen doufat, že Swift bude použitelný i na Windows (třeba jako frontend pro .NET) a *nixech. To ale zcela jistě prioritou Applu nebude.
Update: Swift podruhé
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.
>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).
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.
@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 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í.
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ý.
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.
> 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.
[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?
[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.
[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.
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
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.
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
Autor se zabývá vývojem kompilátorů a knihoven pro objektově-orientované programovací jazyky.
Přečteno 36 064×
Přečteno 25 245×
Přečteno 23 707×
Přečteno 20 089×
Přečteno 17 780×