Ne sprecava te nista, ako pises projekat od nule. Problem je sto je u enterprise developmentu mnogo veca sansa da ces raditi na projektu koji se vec razvija godinama nego da ces imati sansu da ga radis od nule.
Opet me ne citas - ja nisam rekao rewrite, ja sam rekao da se nastavi u Swift, a ne da se pise od 0 u Swift, a sto se tice rewrite da ce se trebati raditi jednog dana (kada se bude gasio ObjC) i da ce onda biti manje posla, jer je prethodnih godina kod pisan u Swift.
Ovo nema veze sa Srbijom nego je tako bilo gde u svetu, jer je u pitanju novac, a kada je rec o novcu zar mislis da smo mi stedljiviji od zapadnjaka?
Nismo, ali nas narod uglavnom odbije da ulozi u nesto kako bi ga kasnije to isto manje kostalo, tako da u ovom slucaju izbegavas Swift i na kraju ces imati vece probleme nego da si odmah presao na isti kada je trebalo.
Firme koje su potrosile stotine hiljada ili milione evra u razvoj enterprise softvera nisu lude da sve to odbace i prepisuju kod od nule u nekom drugom jeziku samo zato sto je to nekom fetis. Takodje neko nasilno forsiranje Swifta u takav projekat apsolutno nema nikakvog smisla. Ako je vec 80% koda napisano u Objective-C jeziku, a ostalih 20% u recimo C ili C++ jeziku, zasto od codebase-a praviti jos veceg frankestajna uvodeci dodatni jezik u pricu? Da ne pricamo da to ne moze uraditi neko ko vec ne poznaje Objective-C. Zasto ne moze? Zato sto je sistem ogroman i kompleksan, a takvi sistemi su teski za razumevanje cak i kad poznajes jezik. Zato sto zivimo u realnom svetu gde je tako nesto skupo uraditi, potencijalno moze uvesti dodatne bagove. Zato sto u teoriji nesto izgleda na jedan nacin a u praksi potpuno drugacije.
Opet kazem, ne radi se od nule. Sto se tice ogromnih i kompleksnih sistema i snalazenja u istima - opet kazem, to je vise problem nestrucnosti tih sto su u firmama bili iznad tebe jer nisu forsirali dokumentovanje istih. Zamisli da ti ode par developera i dodju novi, ili stari trebaju raditi na necem drugom. Koliko vremena ces izgubiti dok ti drugi se snadju u tom ogromnom kodu koji nije dokumentovan? Takodje zar nemate negde specifikovanu arhitekturu samog sistema. Isto tako, ako si radio na ogromnim projektima onda znas da se posle par godina i sam mozes pogubiti na istom, jer kada pocnes raditi na necemu sto si radio pre 2 godine a nisi dokumentovao trebas izgubiti gomilu vremena dok pohvatas sta i kako. Kao sto rekoh, i reci cu jos milion puta (a ostali koji se bave mojim poslom ce potvrditi) - nedokumentovani projekti sa nespecifikovanom arhitekturom su odlika loseg vodjenja istih.
Nema smisla nove projekte pisati u Objective-C jeziku. Ja to nisam ni tvrdio. Ne znam da li si zaboravio, ali nasa diskusija se vodi o tome da li treba uciti samo Swift (tvoja tvrdnja) ili treba uciti i Swift i Objective-C (moja tvrdnja). Objective-C ce ostati tu mnogo duze nego sto mislis. Razlog tome je upravo gomila postojeceg koda. Niko nije lud da baca novac na pisanje novog koda ako vec ima softver koji mu obavlja posao, a ciji razvoj je papreno platio prethodnih godina.
Koliko ce ObjC ostati ne zavisi od tebe, neke srpske (ili ne daj boze strane) firme, vec iskljucivo od Apple. Onog momenta kada vise ne bude moglo da se compile za novi OS, tu je
Cak i da preptostavimo da Objective-C nece postojati za 5 godina, meni je tvoj savet ljudima da ne uce Objective-C neracionalan. Oni ce se vrlo verovatno u narednih 5 godina dosta susretati s tim jezikom (osim u slucaju da samo rade manje outsourcing projekte od nule) i poznavanje istog ce im znacajno olaksavati posao.
Zasto si i dalje ubedjen da veci outsourcing je vezan za ObjC - ja sam ti vec rekao da su US firme vec u velikom pocele da prelaze na Swift i to odavno.
Vreme koje im je potrebno da nauce Objective-C je maksimalno mesec dana. To je jedan vrlo jednostavan objektno orijentisani jezik, ekstenzija C-a sa pomalo cudnom sintaksom. Svako ko zna C i bilo koji drugi OO jezik zapravo nema mnogo sta ni da uci, pa tih mesec dana je zapravo prilicno pesimisticna prognoza. E sad, ako ti mislis da je maksimalno 30 dana ucenja necega mnogo u odnosu na to da ces od toga imati mnogo koristi narednih 5 godina, onda ja vise nemam sta da dodam po tom pitanju.
Ajde procitaj jos jednom temu - ljudi nemaju iskustva sa OO nesto, ne znaju cak ni lepo sta je petlja, a ti mislis da mogu ObjC da savladaju za 30 dana. Pa to je prosto nemoguce. Nece ni Swift koji je laksi za savladati uspeti da savladaju lepo u narednih nekih 6 meseci.
Vrlo jednostavno, kao sto sam gore objasnio neces ih nikada prebacivati u Swift jer je skupo. Nove projekte ces pisati u Swiftu, stare ces odrzavati u Objective-C-u sve do kraja zivotnog veka aplikacije.
Pa dobro, zasto onda mislis da ce neko u Srbiji ko radi sa ObjC da Swift developera stavlja da radi na starim projektima, a ne forsirati ga na nove i pustiti ga da ih radi, a kasnije i da vodi ove ObjC dev-ove koji predju na Swift.
Ako su Cobol biznis aplikacije napisane pre par decenija i dalje zive jer rade posao i izdrzale su test vremena, pa kompanije nisu htele da bacaju novac da prepisuju svoje sisteme u neki jezik koji je vise fensi, ne vidim zasto bi bacale novac prepisujuci Objective-C kod u Swift ako ne moraju. Kompaniju ne zanima privlacnost jezika, kompaniju zanima upotrebna vrednost softvera.
Istom logikom da li bi rekao programeru koji se opredeljuje za tu sferu da krene da uci Cobol? Isto tako mesas babe i zabe jer ti za iOS i OS X uredjaje moras compile kod, a to ti radi Xcode. Kada Apple ugasi ObjC kod se vise ne compile i cao zdravo. Moraces da cekas neka 3rd party resenja ako se pojave, a onda se pokrece i pitanje pouzdanosti istih. Da li se bar sa tim slazes?
Opet mi se cini da vodis pogresnu diskusiju. Mi ne raspravljamo o tome da li je Objective-C bolji od Swifta. Mi raspravljamo da li je bolje uciti samo Swift ili je bolje nauciti oba jezika ako zelis da budes ozbiljan iOS developer. Ja uopste ne tvrdim da je Objective-C bolji od Swifta (a ni obrnuto). Nemam osecanja prema jezicima. Oni su samo alat. Koristis onaj koji ti u datom momentu najbolje odradjuje posao.
Pa ako je Swift bolji jezik, kako onda to ne spada u ovo sto si napisao "Koristis onaj koji ti u datom momentu najbolje odradjuje posao". To je bas ono sto Swift radi u ovom trenutku
Mislim da je sasvim jasno da ce potraznja za Swift programerima biti sve veca i veca, ali to opet nije vezano za Srbiju nego je to globalni trend. Ne vidim cemu ogorcenje prema poslodavcima kod nas, pa oni samo igraju kako im trziste diktira. Svima je jasno da je u Swiftu buducnost sto se iOS developmenta tice, ali nece poslodavac na silu da forsira Swift ako mu za vecinu projekata jos uvek treba Objective-C.
Ne igraju oni kako im trziste diktira, vec kako se oni opredele. Kao sto rekoh za svaki novi projekat ti biras da li ces ga raditi u Swift ili ne, a svaki postojeci biras da li ces da nastavis u Swift ili ObjC. Ja mogu svaki postojeci da nastavim u ObjC koji je preuzet i ne bih imao nikakvih problema, ali zasto to nisam uradio vec smo nastavili iste da kodiramo u Swift? Zasto bih pisao vise koda, necitljiv kod i sporiji kod? To nema nikakve poslovne logike.
E ovde si me dobro nasmejao, ovo zvuci kao iz nekog udzbenika sa fakulteta
Bavim se programiranjem jako dugo i mislim da jos uvek nisam radio na aplikaciji koja je velika a dobro dokumentovana (i da, radio sam uglavnom u stranim firmama, tako da to nema veze sa Srbijom). Kolega sa posla je skoro naleteo na oglas Blizzard Entertainment-a gde im je jedan od "requirementa" za poziciju programera sposobnost snalazenja u ogromnom codebase-u nedokumentovanog koda
Zasto mislis da Blizzard ima dobru praksu - nisu jedina velika kompanija koja ima problema sa losom organizacijom. Imaju i vece od nje problema takvih i pogodi sta se desilo sa svima (ovo ti govorim iz prve ruke posto imam kontakte kod nekih) - radi se verovao ili ne rewrite koda patch po patch bas zato sto je stari bio tako organizovan da su dosli do kriticne tacke kada je broj bug-ova poceo exponencijalno rasti i vise se nije mogao kontrolisati. To su ti price iz prakse firmi u kojima radi par hiljada ljudi, pa ti vidi...
Pomesao si opste OO patterne i patterne i idiome koji su karakteristicni za odredjeni programski jezik. Navescu ti konkretan primer bas iz Objective-C jezika. Postoji pattern koji se zove "associative storage" pomocu koga mozes da nekoj klasi koristeci kategorije pridruzis i nove "member varijable", a ne samo nove metode. Ovaj pattern nije opsti OO pattern nego je usko vezan za Objective-C, a poznavanje istog i njegova pametna (i ispravna) upotreba ti omogucava neka arhitekturalna resenja koja bi izgledala potpuno drugacije ako ne bi koristio isti.
To nije pattern sto pominjes i isto tako nije usko vezan za ObjC vec se koristi u Swift (kao sto sam rekao Swift moze sve sto i ObjC, plus jos vise) - opet kazem ne poznajes Swift a diskutujes o istom... Evo ti mali primer -
http://stackoverflow.com/questions/25426780/swift-extension-stored-properties-alternative
To je to, zar ne? Associative Storage resen bez ikakvih problema... Nije usko vezan za ObjC, radi u Swift bez problema. Da li sada shvatas o cemu pricam citavo vreme, i zasto ce ObjC da bude ugasen?
Naravno da nisi mogao, jer u to vreme Swift nije ni postojao. Dakle ponovo ista prica - projekat je zapoceo mnogo pre Swifta i toliko je narastao da je apsolutno nebulozno i razmisljati o portovanju istog na Swift (Zbog cega? Novca naravno.)
Ne portujes ga, vec ga nastavljas develop u Swift. Zbog cega? Pa opet - kao sto ti kazes zbog novca u ObjC, bas suprotno ide - zbog novca u Swift jer ces brze dovrsiti ono sto trebas.
1) Da li moze da se napise? Naravno da moze da se napise u Swiftu. Vec sam rekao da bi svi novi projekti trebalo da se rade u istom.
Znaci slazemo se oko ovoga.
2) Da li ce biti napisano uz manje koda? Verovatno, s tim sto je pitanje besmisleno. Objective-C sa razlogom ima sintaksu kakvu ima (duge kobasice u nazivima metoda, sto uz neke druge konstrukte koje poseduje dovodi i do pisanja vise koda nego u klasicnim jezicima). Filozofija kojom su se vodili prilikom pravljenja jezika je ta da programeri mnogo vise vremena provode citajuci source code, a manje vremena pisuci isti. Iz tog razloga je za autore jezika bilo znacajnije da jezik bude deskriptivan kako bi bio nedvosmisleniji i laksi za citanje. Vreme u koje je jezik nastao je vreme u kome nisi imao intellisense i slicne alatke (jer su hardverski resursi bili ograniceni), pa je bilo veoma prakticno da u samom pozivu metode kao deo njenog potpisa imas tacne nazive parametara. Npr. poredeci C/C++ i Objective-C pozive metoda:
obj.getCell(2,3);
[obj getCellWithSection:2 index:3];
ocigledno je da je druga varijanta razumljivija za citanje.
Ovo je u novijim jezicima reseno pomocu named parametara, naravno. Ovo sam samo naveo kao ilustraciju da objasnim vec pomenutu filozofiju kojom su se vodili pre 30 i kusur godina kada su jezik pravili.
ne pricamo o istim stvarima - to bi u Swift glasilo obj. getCellWithSection(2, index: 3)
Sto ne napises neki kod sto nije pocetnicka lekcija, vec da imas vise zagrada, parametara i ostalog pa uporedis sa Swift kada u ObjC imas gomilu [[[[ ]]]], a ovde samo par tacki na pravim mestima kao u npr. Javi, C#. Nego reci mi koliko koda tek trebas da pises da bi napravio nesto poput Optional variable (ne optional parameter, vec variable). Tipa CGFloat koji moze biti bilo koji CGFloat ali i nil u isto vreme?
3) Da li ce bolje raditi? To zavisi iskljucivo od onog ko kod pise, a ne od jezika koji je koristen.
Slazem se, ali najjednostavniji kod napisan u ObjC i Swift ce brze raditi ako je napisan u Swift u vecini slucajeva. Imas gomilu benchmarka koji to pokazuju - vec u 1.2 je sibao ObjC u gomilu stvari.
Odgovori sad ti meni, ali iskreno, na sledece pitanje: koliko je velik najveci projekat na kome si radio?
Iskreno ne znam cime to meris pa samim tim i kako da ti odgovorim, ali trenutno sto se tice ObjC/Swift projekat koji je trajao oko 2.5 - 3 godine (i jos traje), a sto se tice ostalog (tipa PHP) radio sam i na sistemima koji funkcionisu unazad preko 10 godina i na kojima je radilo i radi gomila ljudi, cak sam i vodio u proslim firmama neke takve projekte.
Zasto te ovo pitam? Zato sto na osnovu izjava:
1) o tome kako je vrlo jednostavno veliki projekat prilagoditi da se dalje razvija u Swiftu
2) o tome kako ozbiljne firme na velikim aplikacijama pisu dokumentaciju pod konac (dokumentaciju detaljno uglavnom pise samo onaj ko mora - a to su firme koje prave middleware, jer od kvaliteta dokumentacije public API-ja najcesce zavisi i uspesnost njihovog projekta)
1) veoma lako ako je ispunjeno #2 koje ponavljam kao papagaj
2) ne bih se slozio sa 2, to se samo u Srbiji izbegava gde su nazalost nasi developeri vise lenji od ostalih (tipa US, UK, Nemacka) i gde ih trebas malo prevaspitati da je to jako bitno, jer na kraju krajeva ustedi i firmi vreme i njemu ili nekom drugom kasnije muke da se snadje u tom istom.
zaista ne mogu da verujem da si radio na nekom bas velikom projektu ili u nekoj velikoj firmi. To samo po sebi nije nista lose, niti umanjuje tvoje programersko umece (manje firme i manji projekti imaju svoje prednosti), ali ne bi trebalo da komentarises kako je nesto lako uraditi ako se sa tim nisi susreo
Provalio si me, a pretpostavljam da nemam ni 2 dev firme, niti znam da programiram ili vodim projekte? :d
Ovo ti kazem zbog toga sto kad radis na velikim projektima gotovo nista nije jednostavno i moras tri puta da meris pre nego sto doneses odluku da nesto menjas. Veliki projekti imaju tendenciju da prerastaju u zver koju je jako tesko ukrotiti. Ovo nije vezano za Srbiju, ovo je globalni fenomen. Super zvuce fraze iz raznih knjiga poput Code Complete, Refactoring i mnogih drugih kako pridrzavajuci se dobrih praksi projekat nece zavrsiti u problemima. Realnost je malo drugacija. Pridrzavajuci se dobrih praksi projekat ce moci da se zavrsi (bez tih praksi bi jos negde usput propao), ali problema ce da bude u izobilju i to je manje vise neizbezno kada na projektu radi mnogo ljudi (i to izuzetno kvalitetnih ljudi) i kada se on dovoljno dugo razvija
Veliki projekti i prerastu u zver pod losim vodstvom, a to se desava jer:
1) ljudi koji ih vode nemaju iskustva sa project managementom/arhitekturom
2) ljudi koji ih vode imaju iskustva sa programiranjem ali nisu bas izucavali i project management/arhitekturu
3) ljudi koji ih vode su lenji
Moze biti jedno od ta 3, a moze biti i kombinacija vise. Samo iz tih razloga u praksi takvi projekti se pretvaraju u zveri. Takodje mnogo ljudi koji rade na istom projektu dugi niz godina vodi projekat pravo u propast i maintainance mode i o tome imas gomilu textova na netu. Cak mnogo ljudi ode iz takvih firmi posle par godina jer se jednostavno smori. Evo ti jedan zanimljiv clanak na tu temu -
https://blog.enki.com/coding-is-boring-unless-4e496720d664#.fzc7wwb6d
