Slo-Tech - Apple je na dogodku WWDC presenetil vse prisotne in razkril nov programski jezik z imenom Swift, ki so ga v veliki tajnosti pripravljali zadnja štiri leta. Swift želi nadomestiti Objective-C in Python, od katerih je Applovih besedah precej hitrejši, in postati prva izbira pri programiranju aplikacij za OS X in iOS.
Sintaksa in logika jezika, ki se ju lahko naučite v priročniku, ki ga je Apple že postavil na iTunes, sta precej podobni Objective-C. Sprememb je le toliko, da bi programiranje potekalo hitreje in predvsem z manj napakami, ki jih lahko v Objective-C hitro zagrešimo. Poleg glavnih inspiracij so pri razvijanju Swifta črpali tudi iz Rusta, Haskella, Rubyja, C# in CLU. Za primerjavo: klon Flappy Bird je mogoče sprogramirati v enem delovniku.
Zanimivo je, da je Apple uspel jezik razviti v strogi tajnosti, kar je izjemno težko. Projekt je trajal vsega štiri leta, in sicer se je začel julija 2010 kot samostojni projekt zgolj nekaj posameznikov. Dodatni inženirji so se mu pridružili leta 2011, glavni projekt ekipe Apple Developer Tools pa je postal šele julija lani. In do danes je zrasel v samostojni delujoči jezik. Apple pravi, da je izjemno hiter, saj naj bi kompleksno sortiranje izvedel skoraj štirikrat, šifriranje RC4 pa kar 220-krat hitreje kot Python.
V zadnjem času je bilo razvitih cel kup novih jezikov, ki pa nekako niso zmogli premagati starih dinozavrov. Swift ima precejšnje možnosti, da mu to uspe, saj za njim stoji Apple. In vsakdo, ki je kdajkoli programiral mobilne aplikacije, ve, da ne sme izpustiti platforme iOS, kjer je treba delati, kot zapoveduje Apple. Strah je sicer odveč, saj bo še vedno paralelno podprt Objective-C, tako da ne bo treba na vrat na nos skočiti v nov jezik. Vseeno pa bo prehod z Objective-C dober, saj ga je že pošteno načel čas, ugotavljajo na ArsTehnici.
V zadnjem času je bilo razvitih cel kup novih jezikov, ki pa nekako niso zmogli premagati starih dinozavrov. Swift ima precejšnje možnosti, da mu to uspe, saj za njim stoji Apple.
Swift je resda korak v pravo smer (napram objective-c), vendar malo dvomim da bo zaživel tudi zunaj applovega okolja, na drugih platformah. Apple je pač naredil svojo kopijo pythona
Stvar nima Exception-ov? Ni try,catch,final... Nima modifierjev public,private,protected,internal, ampak ima le exported(public) in vse ostalo je free for all znotraj projekta(vse je internal) Aja kr se hitrosti tiče... http://www.splasmata.com/?p=2798 nima nč za concurrency... lock? synchronized? async/await? Se bo treba bolj potrudt in Andersa ukrast ;)
Je pa seveda to osebne preference, nekateri raje vidijo, če program poskrbi za napake med izvajanjem, nekateri pa pač za to poskrbijo med programiranjem.
@zigomir pa Android tudi ;) Sej se da tudi brez try catch finnaly vse naredit samo kolk bo potem lepa koda(kvalitetna...)?
Ker končnega uporabnika predvsem zanimao kako lepa (kvalitetna) je koda...
Seveda se da naredit brez try catcha samo kaj ko ti nihče (tudi uporabnik) več ne zna povedat zakaj je zadeva crknila. "Jaz sem strokovnjak in ne delam napak... vse exceptione sem odpravil že med samim programiranjem. Jaz sem strokovnjak.. vem kaj delam... I am the mighty HULK" Looool self confidence.
Še en applov zajeb ... tako kot so zajebali, ko so splavili iphone, oblikovno optimiziran za skladiščenje, namesto nekaj, kar bi ergonomično sedlo v roko, kot npr. banana. Tokrat bi lahko sestavili jezik, ki bi onemogočal unsecure programiranje, a jih to očitno sploh ne zanima. Z vplivom, ki ga imajo na svet, bi lahko storili nekaj dobrega. Ampak ne. Prav, pa ne. In NSA veselo dalje opravlja svoj posel.
Meni ni nikoli blo jasno zakaj morajo biti programski jeziki v splošnem tako zaguljeni.
... Če bi kdaj programiral v asemblerju ali celo mikro kodo za CPU, bi videl da je večina stvari povsem logično zastavljena. ...
Podpišem
Šele tam ugotoviš, da sta si "zaguljenosti" in optimizacija obratno sorazmerni.
"Everybody is a genius. But if you judge a fish by its ability to climb a tree
it will live its whole life believing that it is stupid."
-Albert Einstein
Še en applov zajeb ... tako kot so zajebali, ko so splavili iphone, oblikovno optimiziran za skladiščenje, namesto nekaj, kar bi ergonomično sedlo v roko, kot npr. banana. Tokrat bi lahko sestavili jezik, ki bi onemogočal unsecure programiranje, a jih to očitno sploh ne zanima. Z vplivom, ki ga imajo na svet, bi lahko storili nekaj dobrega. Ampak ne. Prav, pa ne. In NSA veselo dalje opravlja svoj posel.
ne vem no, ampak če vidiš priložnost v bananah, se jih loti, te podpiram, verjetno še kdo
S tem da ergonomsko oblikovani telefoni (nokiina bananca) so že bili na trgu in prav vsi vemo kako se je zadeva končala. Ampak nima veze, pegasus ve, da je epl to naredu zato da lažje skladiščijo. Jebe se eplu za ns, važn da majo skladišča porihtana zdj k je Cook šefe.
Še en applov zajeb ... tako kot so zajebali, ko so splavili iphone, oblikovno optimiziran za skladiščenje, namesto nekaj, kar bi ergonomično sedlo v roko, kot npr. banana. Tokrat bi lahko sestavili jezik, ki bi onemogočal unsecure programiranje, a jih to očitno sploh ne zanima. Z vplivom, ki ga imajo na svet, bi lahko storili nekaj dobrega. Ampak ne. Prav, pa ne. In NSA veselo dalje opravlja svoj posel.
Ja, sploh ker so iPhonov polna skladišča, ker jih nihče noče. Razen vseh.
To da so približali pametne telefone ljudskim množicam in jih končno naredili uporabne verjetno ni nič dobrega.
NSA bo svoj posel opravljala itak še naprej, pa čeprav morajo sami izdelovati teroriste, da jih potem ganjajo.
Objective C je res se najmanjsi problem razvijanja za iOS. Ze res da ima strmo krivuljo ucenja, je pa kar nekaj principov zanimivih. Naj se raje posvetijo layotingu, podpori vecjim zaslonom k so na vidiku....
Objective C je bil nočna mora za učenje ampak, ko se ga enkrat navadiš ti pa postane blazno všeč. In kakor sem gledal tole čarovnijo od Swifta mi ni ravno všeč. Objective C izgleda kot nekaj kar ima smisel. Tole ga nima.
Kar bi moral Apple precej bolj porihtati je prokleti auto-layout sistem, ki je v trenutnih verzijah prav grozljiv za uporabo. Ko pol dneva študiraš kako nek frame premakniti za par pikslov v eno smer z auto-layoutom in hkrati veš, da bi lahko ročno stvar naredil v treh vrsticah kode ti nekako vzbudi sovražni duh.
Mislim, da so šli v nov programski jezik samo zato, da lahko k sebi privabijo vse, ki so se učili na Pythonu in podobnih in jih je Cja strah.
Meni ni nikoli blo jasno zakaj morajo biti programski jeziki v splošnem tako zaguljeni.
Zato ker se ti najbrž ne sanja preveč o stvareh ki se dogajajo spodaj, pod površjem ...
Če bi kdaj programiral v asemblerju ali celo mikro kodo za CPU, bi videl da je večina stvari povsem logično zastavljena.
In ker vsak razvijalec vleče zadevo s sabo od pamtiveka ...
Šure, ko gre za zahtevnejše zadeve je fanj imeti na razpolago vso moč. Ampak za običajnega programerja ali splošno programersko izobraženost je večina jezikov plain old silly.
Torej če te prav razumem, ti bi odstranil vse exceptione, try - catch zanke oz. kar vse nižje-nivojske jezike, pri katerih obstaja večja možnost napake kot pri HTML-ju ? Če sploh veš o čem govorim, argumentiraj, drugače pa ne bluzi ...
Pri ObjC pri asinhronih metodah imas naceloma success/failure callback, pri sinhronih ti pa pac vrne YES/objekt ce je uspesen in NO/nil ce faila. V primeru faila pa lahko skoraj vedno (pac ce metoda podpira) dobis podatke o napaki preko kazalca na NSError*.
Torej ce malo pazis kaj delas in zadeve se testiras ne bi smelo priti do napak.
ti lahko testiraš cel mesec, pa potem v produkciji fašeš napako že prvi teden, ki je test ni sproduciral
Zato mi niso všeč unit testi, ki pokrivajo samo znane napake, neznanih pa ne. Veliko raje imam formal verification, ki matematično natančno pokaže, ali nek kos kode deluje tako in samo tako, kot se od njega pričakuje.
ne bo šlo vse s testiranjem, maš en kup napak katere so povsem sistemske(prekinitve, zaklenjeni dostopi do datotek in podobno). Exceptioni so bolj ali manj namenjeni lovljenju teh napak kot pa urejanju program flowa. So pa seweda alternativee kot so monade, signali v lispu pa še kaj.
ti lahko testiraš cel mesec, pa potem v produkciji fašeš napako že prvi teden, ki je test ni sproduciral
Zato mi niso všeč unit testi, ki pokrivajo samo znane napake, neznanih pa ne. Veliko raje imam formal verification, ki matematično natančno pokaže, ali nek kos kode deluje tako in samo tako, kot se od njega pričakuje.
Katere izmed takih jezikov pa uporabljate v produkciji? Kak ML? D?
Pri ObjC pri asinhronih metodah imas naceloma success/failure callback, pri sinhronih ti pa pac vrne YES/objekt ce je uspesen in NO/nil ce faila. V primeru faila pa lahko skoraj vedno (pac ce metoda podpira) dobis podatke o napaki preko kazalca na NSError*.
Torej ce malo pazis kaj delas in zadeve se testiras ne bi smelo priti do napak.
A ti res praviš da je prastari Cjevski pattern vračanja statusa... nekaj kar preprečuje napake če "paziš kaj delaš"? Ker zgodovina in realnost tega nikakor ne potrjuje in če bi to tvoje bilo res, ne bi rabili testiranja in ostalih postopkov za povečevanje zanesljivosti kode.
A ti res praviš da je prastari Cjevski pattern vračanja statusa... nekaj kar preprečuje napake če "paziš kaj delaš"? Ker zgodovina in realnost tega nikakor ne potrjuje in če bi to tvoje bilo res, ne bi rabili testiranja in ostalih postopkov za povečevanje zanesljivosti kode.
Načeloma ta način uporabljajo tudi modernejši jeziki, kot recimo go. Pri Cju je predvsem problem ker pomnilnik direktno manipuliraš, ne pa toliko v načinu preverjanja napak.
Izkaže se da Swift niti ni tako zelo hiter razen če precej varnosti izklopiš med prevajanjem.
Apple je tako pretiraval oz. pač v večini primerov ni takšnega pohitrenja, še vseeno pa je hitrejši, predvsem tam kjer uporabljaš izključno swift, brez klicanja ObjC kode in objc_msgSend.
Sicer se še nisem resno spravil k testiranju jezika, mi je pa na prvi odtis všeč in ima iz programerskega stališča kar nekaj prednosti.
A ti res praviš da je prastari Cjevski pattern vračanja statusa... nekaj kar preprečuje napake če "paziš kaj delaš"? Ker zgodovina in realnost tega nikakor ne potrjuje in če bi to tvoje bilo res, ne bi rabili testiranja in ostalih postopkov za povečevanje zanesljivosti kode.
Načeloma ta način uporabljajo tudi modernejši jeziki, kot recimo go. Pri Cju je predvsem problem ker pomnilnik direktno manipuliraš, ne pa toliko v načinu preverjanja napak.
Izkaže se da Swift niti ni tako zelo hiter razen če precej varnosti izklopiš med prevajanjem.
Apple je tako pretiraval oz. pač v večini primerov ni takšnega pohitrenja, še vseeno pa je hitrejši, predvsem tam kjer uporabljaš izključno swift, brez klicanja ObjC kode in objc_msgSend.
Sicer se še nisem resno spravil k testiranju jezika, mi je pa na prvi odtis všeč in ima iz programerskega stališča kar nekaj prednosti.
go pa res ni sodoben programski jezik je nekoliko predelan c. z nekaj hudo bolnimi idejami, sploh kar se tiče konkurenčnosti. napalamudijo celo goro primitivov za izvajanje konkurenčne kode izpustijo pa nemutirajoče spremenljivke, skratka bolano.
z retunanjem kode napake pa načeloma ni nič narobe, dokler dela sistem kar je predvideno, ko pa ne je pa povsem neuporaben. tu pa vskočijo izjeme.
Meni ni nikoli blo jasno zakaj morajo biti programski jeziki v splošnem tako zaguljeni.
Zato ker se ti najbrž ne sanja preveč o stvareh ki se dogajajo spodaj, pod površjem ...
Če bi kdaj programiral v asemblerju ali celo mikro kodo za CPU, bi videl da je večina stvari povsem logično zastavljena.
In ker vsak razvijalec vleče zadevo s sabo od pamtiveka ...
Šure, ko gre za zahtevnejše zadeve je fanj imeti na razpolago vso moč. Ampak za običajnega programerja ali splošno programersko izobraženost je večina jezikov plain old silly.
ker jezik kot tak s seboj nosi poleg osnovnih primitivov gramatike tudi celo vrsto memoizacij, katere mora razčlenjevalnik prepoznat da sestavi ustrezno sintaktično drevo. in trenutno je tehnologija razčlenjevalnikov parserjev omejena predvsem na eno kontekstno domeno. zato obstajajo povsem preprosti in razumljivi jeziki bolj v strogo določenih domenah(recimo mathematica, logo, log parserji , različni DSLi etc...). V splošno namenskih jezikih pa smo omejeni bolj ali manj zgolj na en univerzalen jezik. Komercialno kolikor vem proba stvar premakniti naprej JetBrains s svojim projektom nitra. http://confluence.jetbrains.com/display... kateri omogoča zontarj enega kompajlerja različne sintakse ter posledično tudi prinaša v jezik različne kontekstualne memoizacije. S tem ti ni potrebno vse podati eksplicitno ampak se določene stvari vedo same po sebi. Ampak to je le prvi korak potem bo potrebno še kar nekaj dela na sami semiotiki oz semantiki šmorna katerega bo pridelal razčlenjevalnik kode.
ja kako pa ujet napake, o katerih se ti sanja ne, da obstajajo?
S testiranjem.
ne bo šlo vse s testiranjem, maš en kup napak katere so povsem sistemske(prekinitve, zaklenjeni dostopi do datotek in podobno). Exceptioni so bolj ali manj namenjeni lovljenju teh napak kot pa urejanju program flowa. So pa seweda alternativee kot so monade, signali v lispu pa še kaj.
Vse se da s testiranjem. Tudi sistemske prekinitve, zaklenjene baze, zaklenjeni page-i od baze in zaklenjeni dostopi do datotek. Zato pa se software nekaj časa testira in v večih okoljih.
Sam sem navajen na 4 okolja - developer, kjer razvijam, testno, kjer stestiram skupaj z uporabnikom, predprodukcijsko kjer se program sam testira v okolju enakem produkciji in na koncu produkcija (po bnekje šestih mesecih testiranj in preko miljona različnih vnosov (pravilnih, napačnih, z blokirano bazo, z blokiranimi datotekami in simulirano sistemsko napako, da je nekaj na siatemu narobe).
Asrock X99 Extreme 4 | Intel E5-2683V4 ES | 64GB DDR4 2400MHz ECC |
Samsung 250GB M.2 | Asus 1070 TI | 850W Antec | LC Tank Buster
ja kako pa ujet napake, o katerih se ti sanja ne, da obstajajo?
S testiranjem.
ne bo šlo vse s testiranjem, maš en kup napak katere so povsem sistemske(prekinitve, zaklenjeni dostopi do datotek in podobno). Exceptioni so bolj ali manj namenjeni lovljenju teh napak kot pa urejanju program flowa. So pa seweda alternativee kot so monade, signali v lispu pa še kaj.
Vse se da s testiranjem. Tudi sistemske prekinitve, zaklenjene baze, zaklenjeni page-i od baze in zaklenjeni dostopi do datotek. Zato pa se software nekaj časa testira in v večih okoljih.
Sam sem navajen na 4 okolja - developer, kjer razvijam, testno, kjer stestiram skupaj z uporabnikom, predprodukcijsko kjer se program sam testira v okolju enakem produkciji in na koncu produkcija (po bnekje šestih mesecih testiranj in preko miljona različnih vnosov (pravilnih, napačnih, z blokirano bazo, z blokiranimi datotekami in simulirano sistemsko napako, da je nekaj na siatemu narobe).
ne bluzi to gre kvečjemu pri dinamičnih jezikih, pri kompajliranih pa aplikacija odleti kot knof na gatah. in nisi super programer ker super programerjev ni. kaj pozabiš, mudi se stvar gre v producijo na koncu je pa štala. videno, sprobano tko osebno kot tudi v vseh knjigah in vodičih, kateri se ukvarjajo z dobrimi praksami.
