XCode

Steve Jobs are cancer la pancreas deoarece o multime de programatori au vrut sa-si bage pulile in ficatul lui si unii din ei au nimerit pe linga. Probabil Steve nu e direct de vina pentru faptul ca XCode este un puroi revoltator, dar oftica e mult mai spornica atunci cind o poti canaliza in directia unei persoane si Steve e usor de nimerit in pozitia fruntasa in care s-a postat. Cancerul nu este total nejustificat insa, caci rolul de Führer al Nationalsozialistische Hipsterisch Arbeiterpartei ii confera lui Steve dreptul de a-i spinzura cu coarde de pian pe cei care au adus pe lume abominatia; faptul ca el nu-si exercita acest drept este o insulta la adresa intregii omeniri de la Charles Babbage incoace.

Pentru a intelege cum a putut lua nastere XCode, acest abject esec al spiritului uman, trebuie sa examinam intii contextul in care a fost construit el. Vom vedea ca soarta lui a fost pecetluita inca inainte de a se scrie prima linie de cod, dar ca maimutele care au lucrat la el nu s-au multumit sa mosteneasca imbecilitatile platformei pe care cladeau, ci au dus stafeta prostiei pe noi culmi.

Contextul lui XCode este OS X. In Finder (echivalentul hipsteristic al lui Windows Explorer, pentru neinitiati), tasta pentru a deschide un fisier selectat nu este Enter, ci Cmd+O. Enter face rename. Articolul asta s-ar putea incheia aici. Evident n-o sa se incheie, dar macar discutiile din magazinele Apple intre clientii potentiali si vinzatori ar trebui sa se sfirseasca in acest mod.

– Cum fac rename la un fisier?
– Apesi Enter.
– Muie.

Este clar de ce cred Apple ca au facut asta cu Cmd+O: pentru consistenta. In alte programe, “Open” este Cmd+O, deci sa fie si in Finder. Motivul real pentru care au facut asta este la fel de clar: pentru ca sint retardati. Pentru rename cu enter nici macar nu exista un motiv inchipuit, exista doar retardarea.

Fanboii vor spune ca asta cu tastele e doar o preconceptie a cuiva care vine dintr-un alt mediu. Pentru ei am exemplul redimensionarii. In OS X, ferestrele se pot redimensiona doar din coltul din dreapta-jos. Daca ai un geam in dreapta ecranului si vrei sa-l faci mai lat, intii trebuie sa-l tragi mai la stinga, dupa care sa-l maresti. In general n-o sa stii cit de mare vrei sa-l faci, deci n-o sa-l tragi suficient de mult in stinga si n-o sa ai loc sa-l faci cit de mare vrei, asa ca o sa-l mai tragi un pic, si o sa-l mai maresti un pic. Aparent, un test cu un focus grup a relevat faptul ca utilizatorii sufera un atac de panica daca ii lasi sa redimensioneze geamurile din orice colt. Eu cred ca de fapt testul a relevat surprinzatoarea implicatie ca daca faci focus grupuri cu retardati, ajungi la concluzii retardate.

In Biblia UI-ului Apple, unde regasim porunca asta cu strictetea redimensionarii, putem citi si citeva reguli de bun simt. Una din ele e sa nu-ti faci alfabetul tau din pictograme, pentru ca in general oamenii stiu deja un alfabet. Pictogramele trebuie folosite pentru grupat vizual chestiile similare, nu pentru a inlocui textul. Exceptie fac pictogramele pe care le pricepe orice om, gen sagetile, dar si alea trebuie folosite cu mare grija. In aroganta lor, Apple isi dau derogare de la regula asta si pentru mazgalelile de pe tastele lor speciale, caci daca nu vrei sa inveti ca semnul de puscarie e tasta de linga spatiu, nu meriti Lumina lui Steve. Scrie in pula mea “Alt+Cmd+Enter”, nu “juma’ de zvastica puscarie inapoi”, ca nu vreau sa invat ideograme hipsteristice doar ca sa pot sa joc Finder din taste. De asemenea, tastaturile Apple au ergonomia unei mine antipersonal, deci daca vrei sa-ti mai poti misca miinile dupa o zi de interactionat cu un Mac trebuie sa-ti iei o tastatura de oameni, care n-o sa aiba simbolurile cultului Apple pe tastele speciale si n-o sa poti sa te uiti sub degete sa vezi pe ce cacat de buton vrea sa apesi. Pentru avansati avem si o intrebare bonus: cum se numesc cele trei taste din poza urmatoare? Indiciu 1: nici macar pe tastaturile Apple nu sint. Indiciu 2: da, sint 3, muia aia din stinga care abia se vede asa apare in dialogurile de configurare.

Problemele astea sint minore, dar le-am mentionat pentru a putea zugravi o mentalitate. Apple cred ca orice iese din mina lor este perfectiunea intruchipata si o binecuvintare pentru intreaga suflare a planetei, asa ca vor tine cu dintii de orice idee, chiar daca se dovedeste a fi o imbecilitate. Mai mult, daca intrebi cum poti face o chestie care nu se poate face, nu-ti vor spune “nu se poate, sintem retardati”, ci vor incerca sa-ti explice ca de fapt nu vrei sa faci chestia aia. Nu vei putea redimensiona niciodata geamurile ca oamenii, din orice colt, pentru ca Apple stiu mai bine decit tine ca nu vrei sa faci asta, asa cum au stiut timp de 20 de ani ca mouse-ul trebuie sa aiba un singur buton. Heil Apple.

De la mentalitatea asta ajungem la problema editarii textului, care il afecteaza direct pe XCode. Prin 1986, IBM s-au prins ca oamenii folosesc tastatura pentru a scrie text si ca ar fi frumos daca ar pune pe ea niste butoane pentru chestii uzuale cum ar fi mers la inceputul rindului, la sfirsitul lui, o pagina in sus sau una in jos. Apple nu au fost de acord. Cine cacat vrea un buton de home? De la balconul Geamiei Perfectiunii si Adevarului Suprem, muezinii Apple le-au tot repetat credinciosilor: mouse-ul are un buton si n-aveti nevoie de home, end sau function keys. Pina la urma fatwa-ul impotriva butoanelor a fost ridicat si o vreme tastaturile Apple au avut butoane de home si end, dar tocmai a fost reinstituit, si ultimele instrumente de torturat degete marca Steve iar au pierdut butoanele astea eretice. Oricum, nici cind le aveau nu mergeau, pentru ca in dorinta lor de a fi altfel, Apple le-au pus sa te duca la inceputul si sfirsitul documentului, dar fara sa mute cursorul, ca asta sigur e o chestie care-ti trebuie foarte des (mult mai des decit sa duci cursorul la inceputul liniei). De asemenea, page up si page down muta doar view-ul, nu si cursorul, alta chestie teribil de utila (mai ales cind ai scroll wheel la mouse, o inventie recenta in lumea Apple, ce-i drept).

In concluzie, viteza cu care poti edita text in XCode l-ar face pe Gutenberg sa se sufoce de ris. Risul lui Gutenberg poate duce la cancer la pancreas pentru Steve prin mecanismul descris in introducere, avind in vedere ca programatorii tind sa-si petreaca majoritatea timpului scriind text. Sigur, te poti duce la inceputul rindului apasind Ctrl+A, ca pe vremea lui VT100, sau Cmd+Stinga, dar Apple n-au auzit nici macar de smart home, un feature care e in toate editoarele de text din ultimii 20 de ani. Ctrl+A si Cmd+Stinga te duc intotdeauna la prima coloana, nu schimba intre primul caracter din rind si prima coloana, ca la oameni. Au si Alt+Page Up / Alt+Page Down, care muta si cursorul (normal, doua taste pentru functia uzuala si una singura pentru aia inutila). Daca te simti aventuros poti chiar sa-ti redefinesti tastele ca-n jocuri si sa pui home sa faca home, doar ca sa-ti amplifici frustrarea in momentul in care trebuie sa faci ceva la calculatorul altcuiva. Cu putina vointa poti sa-ti cresti productivitatea pina undeva la nivelul lui notepad din Windows, moment in care intervin feature-urile avansate, alea care ne arata ca XCode stie ca nu-i un editor de text chior, ci un editor de cod.

XCode are code completion. Tasta cu care il activezi este Escape. Asta e si mai tare decit rename cu Enter. Escape, in pula mea. Bine, ca in practica nu conteaza, deoarece parserul de C++ e cam la nivelul pe care l-ai obtine daca i-ai cere celui mai prost student din grupa sa-ti faca un parser de C++ dupa ce a mers mahmur la prima ora a unui curs in care se mentioneaza tangential programele “flex” si “bison”. Code completion-ul intelege functii, metode si uneori nume de variabile, dar cam atit. Daca ii arati un template intra in fibrilatie. Totusi, in rarele ocazii cind incepi sa scrii numele unei functii si i se pare ca stie ce vrei sa scrii, iti sugereaza functia, cu tot cu parametrii sai:

Daca dai enter sa accepti sugestia, selecteaza definitia primului parametru, astfel incit s-o poti suprascrie cu ce vrei sa pasezi acolo. Urmatoarele defintii nu se mai selecteaza automat, deci trebuie sa le stergi de mina. Daca nu le stergi, ramin acolo in program si poti chiar sa salvezi textul in halul ala:

Daca te uiti in fisier dupa ce-l salvezi, observi urmatoarea aberatie:

int main()
{
    test(5, <#float y#>)
    return 0;
}

Ineficienta in editarea textului ar fi o problema daca ai putea sa ajungi la fisiere ca sa le editezi, ceea ce in general nu e cazul. Un nou focus grup compus din retardati i-a ajutat pe Apple sa decida ca schimbatul intre ferestre din taste este o alta mare sursa de confuzie pentru utilizatori. In OS X, tasta cu care schimbi intre geamurile aceleiasi aplicatii ia ferestrele la rind in ordinea in care au fost create, nu schimba ordinea in functie de ultima accesare, cum face Ctrl+Tab in Windows. Daca ai 10 fisiere deschise dar umbli in momentul de fata in doua, nu poti cicla intre ele cu o tasta. Daca apesi Cmd+`, vei trece de fiecare data prin toate cele 10 surse, plus celelate geamuri ale lui XCode care or mai fi deschise. Daca nu-ti convine asta, exista un mod in care toate sursele se deschid in acelasi geam, dar atunci nu poti sa ciclezi intre ele in nici un fel din taste. In cel mai bun caz iti pui o tasta care deschide dropdown-ul cu lista de fisiere active, dupa care il alegi cu sagetile p-ala pe care il vrei. Daca intrebi un fanboi Apple ce-i cu retardarea asta, iti va spune ori ca nu-i bine sa ai atitea fisiere deschise in acelasi timp, ori ca exista o tasta pentru schimbat intre doua fisiere .h si .cpp cu acelasi nume si e gresit sa vrei sa ciclezi intre doua fisiere care nu respecta regula asta. In orice caz, Apple stiu mai bine decit tine ce vrei sa programezi si cum.

Presupunind ca nu te deranjeaza sa tot duci mina de pe tastatura pe mouse ca sa schimbi intre ferestre de parca ai avea OCD si ti s-ar parea ca mouse-ul nu-i niciodata unde trebuie, tot vei avea o problema: ce geam sa alegi? XCode e un program saritor, care stie ca e bine sa-ti deschida acelasi fisier in cit mai multe geamuri de-odata. Recordul meu e de 5 geamuri diferite cu acelasi fisier, si l-am obtinut in felul urmator:

  1. Click pe fisier in lista din geamul principal al proiectului, se deschide in geamul ala.
  2. Dublu click pe fisier, vine si un geam separat cu el.
  3. Fa-l sa contina o eroare de compilare, da-i build. Da click pe iconu’ cu eroarea, vine un geam cu build status care va contine si el fisierul.
  4. Da find in files dupa ceva din fisierul ala. Click pe rezultat. Ai ghicit.
  5. Pune un breakpoint in fisier, deschide debugger-ul (care e un geam separat, dintr-un motiv ce-mi scapa) si fa-l sa se opreasca in breakpoint. Da, acum il ai si-n debugger.

Sint convins ca se poate depasi recordul, dar mi-e lene acum sa mai caut cacaturi prin meniuri. Mai interesant este sa ne aplecam un pic asupra debugger-ului, daca tot l-am mentionat. Fiind o companie care incearca din rasputeri sa fie altfel decit tot restul lumii doar de dragul de a fi altfel, era de asteptat ca Apple sa copieze ce fac altii fix in locurile in care nu trebuie. In speta, XCode trateaza problema debuggingului in acelasi mod retardat in care o abordeaza toate pocnitorile de IDE-uri facute pe genunchi in baie de adolescenti cuprinsi de febra Linux si open source: vorbeste cu GDB printr-un pipe. Prin viu grai. Ceva de genul write(gdb_pipe[0], “Draga gdb, poti te rog sa pui un breakpoint?”). Ca si in pocnitorile open source, schimbul de amabilitati se incheie abrupt cind gdb nu intelege sonetul expediat prin pipe, de exemplu atunci cind incerci sa faci step in printf().

Desi cu gdb se pot face multe lucruri, XCode e pe undeva pe la nivelul lui Borland C++ 1.0 ca feature-uri expuse. Tastele de step into/over nu merg in disassembly daca dai sa vezi combinat source cu disassembly. Nu exista set next statement (exista o consola unde poti vorbi direct cu gdb, insa, daca te simti poet). Exista un fel de edit & continue, dar merge doar pe programe didactice si oricum e destul de limitat fara set next statement. Daca ai un breakpoint si inserezi linii deasupra lui, uneori nu se muta mai jos, astfel incit sa ramina la codul la care era, ci ramine la linia lui, adica ti se va opri la alt cod. Daca ai un program mai complicat decit hello world, uneori se plictiseste de facut debug la el dupa citeva rulari, si nu se mai opreste in nici un breakpoint pina nu restartezi sistemul. Lista poate continua, dar cred ca s-a inteles cit de impecabil e debugger-ul. Probabil ca daca-i arati problemele unui fanboi, iti va spune sa scrii cod fara buguri, ca sa n-ai nevoie de debugger.

Totusi, ca sa ai la ce sa faci debug, trebuie sa poti intii sa-ti compilezi proiectul. Apple au vazut la Visual Studio manevra cu platforme, configuratii, Debug, Release, cacat, dar n-au inteles nimic. La ei nu poti avea doua target-uri cu configuratii diferite in acelasi proiect. Cretinatatea acestui fapt mi se pare colosala, caci nu-mi dau seama cit de retardat trebuie sa fii ca sa concepi sistemul in acest mod, mai ales cind exista alte IDE-uri care s-au lovit de aceeasi problema si au rezolvat-o deja. Raspunsul la intrebarea retorica este ca Apple au concluzionat ca configuratiile sint ca widget-ul de redimensionat geamuri: prea multe optiuni, prea mare confuzia in focus grup. Iar au stiut mai bine ca tine.

Sa presupunem ca facem doua plug-in-uri pentru doua aplicatii 3rd party. Fiecare plug-in suporta o serie de versiuni ale aplicatiei sale, si pentru fiecare versiune vom avea doua configuratii, Debug si Release. Primul plugin va avea Debug2008, Release2008, Debug2009, Release2009 etc. iar al doilea va avea Debug8.0, Release 8.0, Debug 9.0, Release 9.0 etc. Acum surpriza: facem si un lib cu care linkeaza ambele. Deoarece dezvoltarea lib-ului se intimpla concomitent cu dezvoltarea plug-in-urilor, vrem sa includem proiectul lib-ului in ambele solutii, ca asa ne-am obisnuit din Visual Studio, unde ai voie sa-ti setezi proiectele cum vrei tu, nu cum vrea Steve. Mai mult, lib-ul nu depinde de aplicatia-host, deci va avea doar doua configuratii: Debug si Release.

In primul rind, XCode nu are conceptul de proiect impartit intre doua solutii. Poti ori sa faci un proiect separat cu lib-ul si sa stai cu ambele proiecte deschise si sa dai build de mina in ambele cind schimbi ceva, ori sa faci proiectul lib-ului de doua ori, o data in fiecare proiect de plugin, cu toate fisierele si setarile si muile. Daca alegi metoda asta, vei remarca ca trebuie sa-i faci lib-ului aceleasi configuratii pe care le are plug-in-ul, pentru ca XCode nu vrea sa vada disensiuni intre target-urile aceluiasi proiect. Daca nici asta nu te convinge, o sa te rezolve faptul ca uneori oricum nu linkeaza cum trebuie, ca desi pui dependinte si cacaturi pe-acolo, nu se prinde tot timpul ca trebuie sa linkeze din nou plug-in-ul pentru ca s-a schimbat lib-ul.

Sistemul de muire a programatorilor din XCode are multiple nivele de fallback. Daca nu reuseste sa va futa cu cacaturile astea legate de configuratii si target-uri, tot va gasi un mod in care sa se asigure ca nu-l puteti folosi in nimic mai mare de hello world. De exemplu, daca va trece prin cap sa aveti un lib care se cheama altfel intre configuratii diferite (cacat_debug.lib si cacat_release.lib, sa zicem) si sa-l puneti ca dependinta la alt target din proiect, simpaticul XCode ii va trece numele curent in setarile de link ale target-ului care depinde de el. Cind schimbati configuratia activa, se schimba si numele ala, la linia corespunzatoare in fisierul cu proiectul. Daca dai commit asa si dupa aia da update un nefericit care are alta configuratie activa decit aveai tu, o sa iasa un conflict. Ca bonus, cind il rulezi in command line ca sa faci un batch build, nu-i in stare sa calculeze numele lib-ului asa cum o face cind e in GUI mode, asa ca o sa incerce sa-ti linkeze target-ul cu ce a ramas scris acolo ultima data cind ai inchis GUI-ul. Si in final, daca nici in cazuri d-astea nu va prinde, uneori se decide sa mute random chestii prin fisierul de proiect desi tu nu schimbi nimic cu mina ta, ca sa o puna totusi de un conflict cind dai urmatorul update.

XCode vine si cu o serie de unelte ajutatoare de o calitate la fel de suprema ca el. Preferatul meu este muismul ala de facut installere. Apple au decretat ca nu vor sa vada installere pentru aplicatii, ceea ce e un lucru bun (la ei aplicatiile vin ca niste arhive din care tragi fisierele afara si gata). Totusi, in unele cazuri chiar trebuie sa faci un installer, si atunci ai la dispozitie PackageMaker, cel mai bugos program pe care l-am vazut vreodata. Pe linga faptul ca periodic iti fute proiectul pentru ca asa i s-a sculat, si ca setarea proiectului in sine este un demers sisific, cel mai tare feature al acestui program mi se pare ca isi tine proiectul in format XML, dar XML-ul e tot pe o singura linie. Daca deschizi un proiect de installer, ii dai build si dai sa-l inchizi, iti va spune ca s-a schimbat. Daca faci timpenia sa-i zici sa salveze, in multe cazuri iti va distruge proiectul. Daca incerci sa dai un diff sa vezi ce-a facut, nu vei avea prea mare spor, fiind totul pe o linie. Noroc ca-i XML, acest format care poate fi citit si de oameni, si de masini, si de Silviu Ardelean.

Observ ca s-a facut tirziu si ca m-am intins un pic. As mai avea chestii de zis, dar ma voi screme inspre retorica finala. Inteleg ca pe Steve il doare la pancreas despre XCode si suferinta pe care o provoaca el programatorilor fortati sa faca aplicatii pe OS X. Nu inteleg totusi cum se face ca muistii care lucreaza la gunoiul asta nu au fost inca linsati de colegii lor, care trebuie sa-l foloseasca. Daca eu as fi programator pe plantatia de meri si as sti ca in cladire cu mine traiesc si defeca cod infectii care au abatut asupra mea cel mai rau intentionat IDE din istorie, s-ar lasa cu singe. Aia de la Apple ori au un IDE secret pe care-l folosesc in-house, ori isi cirpesc propriile solutii cu vim, emacs sau alte editoare preistorice (ceea ce nu e neaparat mai bine), ori spalarea pe creier aplicata personal de Steve fiecarui nou angajat chiar are randament 100%.

Tags: , , , , , , , , , , ,

46 Responses to “XCode”

  1. siEu Says:

    “intai”, nu “intaiiiiii”.

  2. siEu Says:

    plm, acum orbserv ca nu ati trecut pe noua caligrafie si penultimul i e “i din i”. tot vina voastra e. :)

  3. Mihnea Says:

    Pozitia mea in aceasta problema spinoasa este ca “intai” nu-i mare progres fata de “intii”, ca tot litera gresita e. Corect este “intâi”, dar cum nu-s in stare sa scriu cu diacritice, am ramas la versiunea vintage. Pe foaie scriu “intâi”.

  4. imp Says:

    Nu fi “fustrat”:
    Dacă dai de ,
    Problema o rezolvi
    Cu un Tab apăsat.

  5. imp Says:

    Nu fi “fustrat”:
    Dacă dai de #float#,
    Problema o rezolvi
    Cu un Tab apăsat.

  6. Mihnea Says:

    Aha, p-asta n-o stiam. Oricum e tare ca exista o tasta cu care ii ceri voie editorului sa poti edita codul in continuare, si ca poti salva gunoiul ala in fisier. Nu s-au putut afisa parametrii intr-un tooltip care sa nu necesite taste in plus si sa nu se salveze in fisier, ca daca faceau asa, nu mai erau speciali.

  7. raduangelescu Says:

    incearca sa faci template de template de template sa vezi ce se intampla in Xcode cand ai
    >>> la sfarsit :))

  8. Mihnea Says:

    Nu reusesc sa-l fac sa faca nimic obscen cu > > >. Ce trebuia sa vad? :)

  9. thefatredguy Says:

    Cred ca trebuia sa nu lasi spatiu intre > . Vim & Emacs are your friends :)

  10. Mihnea Says:

    Nici fara spatii nu face nimic atroce IDE-ul, doar se plinge compilatorul ca vrei sa faci shiftari in locuri nepotrivite, ceea ce e OK, ca inca nu e la moda C++0x.

    Vim & Emacs nu-s prietenii mei, sint dusmanii mei de moarte. :> Sper sa am timp sa-i trec si pe ei in analele autobazei cindva.

  11. B.L. Says:

    Câteva chestiuni am de adăugat la cele spuse de Mihnea:

    – Doamne-ajută (se pare că nu doar Steve are cancer la pancreas)

    – Întâia (vorba lu’ Funeriu)

    – :))))))))))))))))))) simbolurile alea stupide par să fi fost pictate pe un balon care s-a spart după ce s-a jucat focus grupul cu el. Cred că şi Predator ar avea probleme în a le distinge şi înţelege cu toate că simbolurile de pe jucăria lui arată ca nişte bacili.

    – după >>> trebui să vezi o curbă deosebit de periculoasă. Deci încet cu XCode-ul pe treptele programării.

  12. RRR Says:

    Am avut şi eu ocazia minunată să fiu nevoit să scriu ceva în XCode. Mă bucur că am avut asemenea ocazie. M-am convins că, şi când vine vorba de cod, Apple e o biserică, nu o firmă sănătoasă la cap.
    Nu cred că am urât vreodată mai tare un soft decât voma aia de IDE.
    Nu înţeleg cum au putut folosi oamenii ăia asemenea jeg pentru a scrie chestii prin macos, că, teoretic, aia au folosit.

    Pe lângă faptul că în editorul ăla de text nu se poate scrie nimic fără să transpiri de la atâtea mişcări ale braţelor şi de la atâtea înjurături, mai au şi un căcat de limbaj împuţit numit Objective-C în care am scris cod şi care are nevoie de un număr mediu de 20.000 de caractere pentru a apela o funcţie cu parametri, după cum se poate vedea şi pe wiki ( http://en.wikipedia.org/wiki/Objective-C ) şi care foloseşte şi un API care se foloseşte din plin de chestia asta pentru a-ţi scurta viaţa mai ceva decât lama trasă peste vene.

    Toată experienţa (oarecum scurtă) cu viaţa de programator pe macos mi-a solicitat la maxim pachetul de înjurături de care dispun şi cred că l-am şi extins cu ocazia aia.

    Oricum ce vroiam să zic e că se poate face set next statement.
    Ca să faci asta trebuie să, ţineţi-vă bine, tragi cu mausul săgeţica aia care îţi arată la ce linie de cod eşti. Abia după ce am descoperit asta mi-a trecut prin minte să încerc drăcăria asta şi în Visual Studio şi să constat că mai şi merge.

    Mai aveam mult venin de vărsat, dar am uitat pe măsură ce scriam mesajul ăsta. Poate mai revin.

  13. Mihnea Says:

    Aha, iata ca e bine sa-ti vinturi frustrarea in public, mai afli chestii cum ar fi tab ca sa sari la parametrul urmator si tras de sageti ca sa faci set next statement. Mersi. :)

    Faza tare cu Abjective-C ala e ca in 64-bit nu poti sa faci GUI decit cu el. Aparent C++ nu-i suficient de bun ca sa faci geamuri si butoane, trebuia un limbaj proprietar pentru acest lucru teribil de complicat. Daca Microsoft spuneau ca in 64-bit Windows nu poti sa interactionezi cu window manageru’ decit din .niet, ar fi iesit revolutie; la Apple e bine, ca daca Steve zice ca Abj-C e viitorul, atunci clar e.

    Eu nu inteleg de ce lumea nu boicoteaza pur si simplu cacatul asta de OS dupa cacatul asta de decizie. Nu vreti aplicatii C++ pe 64 de biti? Ok, nu facem. Adobe au rezistat cel mai mult in pozitia asta, desi si ei au cedat la Photoshop CS5. Acum isi umplu Qt buzunarele cu layer-ul lor scris in Abj-C, care-ti permite sa ai aplicatii C++ cu GUI si in 64-bit daca folosesti Qt (desi Steve e convins ca nu poti).

    Aveam si eu niste horror stories despre Carbon, Quartz si cacatul ala de dinainte de Quartz care nu mai stiu cum se cheama, dar ca si tine am uitat. Cred ca-i o reactie naturala de aparare impotriva jegului. A fost tare cind a trebuit sa fac un geam nou intr-un geam al unei aplicatii care nu-mi apartinea. 5 linii de cod in Windows ca sa redirectionezi wndproc-ul, sute de linii in OSX si la sfirsit tot nu mergea totul cum trebuie. A trebuit chiar sa implementez eu propriul scrollbar care arata si se comporta ca scrollbar-ul lor, ca daca puneam un scrollbar al OS-ului in noul geam, nu primea input sau ceva.

  14. Stefan Says:

    Dude, futere postul, m-am pishat pe mine de ras. N-am programat pe Mac (mostly a Linux/UNIX guy, stiu, boo :) ), dar nu-mi inchipuiam ca-i asa rau.

  15. Andrei Ignat Says:

    Nu am mai ris demult cu asa pofta…

  16. DarkByte Says:

    Mihnea, ai incercat Akismet ? Also, ai putea incerca chestia aia de “first post needs moderation” thingy … ti-ar mai reduce din spamuri (nu spun ca-s foarte multe, da’ am prins vreo 2 deja :) )

  17. Mihnea Says:

    Akismet e pe bani si nu merita la volumul de spam pe care-l primim noi. “First post needs moderation” este un comunism facut pentru oamenii ca Silviu, nu se potriveste cu anarhia pe care o cultivam noi aici. Momentan folosim Bitdefender Antispam pentru WordPress care merge destul de bine (speram sa nu fie mutat vreodata Silviu in echipa aia).

  18. DarkByte Says:

    Akismet e “Free for personal use, a bargain for your business” … nu cred ca scoti bani din blogul asta, so it’s personal use. Anyway, daca zici ca ai filtru de spam, it’s ok :)

    De chestia aia de BitDefender AntiSpam n-am auzit pana acum … da’ cum am ajuns sa asociez BitDefender cu Silviu, I’ll pass :)

    P.S. Daca esti interesat de un link-exchange cu un blog (tematica generala – chiar si nitel IT) cu PR 2, le me know – aici sau mail :)

  19. DarkByte Says:

    Nu ma prea lasa sa postez … dau Submit si se reincarca pagina. Comentariul meu nu apare, dar daca incerc sa-l repostez, duplicate detected.

    http://i52.tinypic.com/j0e642.png

  20. jos8cal Says:

    E nebun wordpress-ul. Si e putin dictator si Bitdefender Antispam-ul. Deunazi ne-a bagat si noua comment-urile la spam. Cred ca e un if() in cod pe nick-urile noastre :)

  21. DarkByte Says:

    Mda … bestiala treaba. This is me not being happy :))

    jos8cal: nick-uri sau adrese de mail … ca am incercat si de pe alt IP.

  22. baloane Says:

    miam placut rau de tot postul ,tiam dat subscribe ,sper sa mai pui si alte posturi asemanatoare

  23. jos8cal Says:

    Stii cum zicea si Motoc: Speranta moare ultima, Silviule!

  24. Dacrinus Says:

    Caut programator XCODE pentru jocuri iPhone.
    Contact: ccrisiarcu@yahoo.es

  25. Luceafaru' Huilei Says:

    Sau programator iPhone pentru jocuri XCode. :)

  26. alessio Says:

    Foarte fain articolul, insa nu sunt de acord cu faptul ca Vim e un editor preistoric. Dupa parerea mea bate la fundulet orice editor/IDE daca e configurat cum trebuie :)

  27. Mihnea Says:

    Da, problema e ca dureaza mai mult sa configurezi vim si Emacs sa faca ce face VS out of the box decit sa scrii un IDE de la 0.

    As dori sa stiu cum configurez vi sa faca urmatoarele chestii:
    – find in files (da, stiu, find -name “*.cpp” -or -name “*.h” -or -name “*.c” -print0 | xargs -0 grep “ce caut”)
    – replace in files
    – rename symbol (care nu-i tot aia cu replace in files, ca probabil am 1000 de variabile numite “size”, dar vreau s-o redenumesc doar p-aia pe care sint cu cursorul)
    – quick open file in project, adica ce are visual assist la alt+shift+o (cu partial matches si chestii)
    – sa-mi arate lista de fisiere din proiect (nu lista de fisiere din directorul in care e proiectul, ca nu-i tot aia)
    – build system (adica nu sa scriu eu makefile-uri, sconstruct-uri sau mai stiu eu ce)
    – go to declaration/definition (asta cica s-ar putea cu ctags sau ceva, dar da-i lui ctags un template sa vezi cum face atac de panica)
    – code completion care sa mearga (si care sa aiba ergonomia lui Visual Assist)
    – watches
    – pus breakpoint-uri in disassembly
    – step into disassembly
    – memory view in timpul debugging-ului
    – edit & continue

    Asta e o lista partiala de chestii de care am nevoie foarte des cind scriu cod. Sigur ca pot si fara, ca pina la urma pot sa scriu opcode-uri direct pe disc cu debug.exe in DOS, da’ nu vreau sa demonstrez lumii cit de haiduc sint, ci sa-mi termin treaba cit mai repede posibil.

    Pe de alta parte, ce chestii esentiale ofera vim si nu ofera VS? Vorbim, evident, de C++ in proiecte serioase, nu de proiecte Python cu 1000 de linii de cod, care se pot scrie cu orice.

  28. iuliancalin Says:

    linux roolz

  29. thefatredguy Says:

    Iar legatura dintre Xcode si Linux este … ?

  30. Mihnea Says:

    Ca ambele “roolz” la fel de tare.

  31. betonarmat Says:

    Ar fi interesant un post si despre tabara linuxista, cu editoarele lor consacrate, toata pleiada de IDE-uri si neaparat fanatismul pentru cauza open source :).

  32. Gigi Says:

    In primul rand: @siEu esti un idiot.

    In alte randuri… Superb post… Cel mai idiot “feature” existent pe Mac e ca nu ai HOOOOME!!! E o tasta mirifica, cu care duci cursorul la inceputul RANDULUI, NU LA INCEPUTUL DOCUMENTULUI!!!! (retards)

  33. Vasile Says:

    Legat de editoarele din linux,
    sunt multi care merg pe gvim, am incercat si e cam cum zicea mihnea in commentul de mai sus,
    iti lipsesc chestii care sunt destul de esentiale

    asa ca eclipse cdt !
    (sau netbeans)

  34. thefatredguy Says:

    SI eclipse si netbeans se misca precum o cizma, chiar si cu proiecte mici (10-20 fisiere). Si tot nu se ridica la nivelul lui VS2010 cel putin in ceea ce priveste code completion.

  35. Vasile Says:

    Odata instalat visual assist-ul si VC incepe sa ceara resurse. dar presupunand ca programezi pe un comp cat de cat nu ar trebui sa ai treaba cu nici unul. Eu nu am luat in calcul si compilatorul folosit, aici pot fi diferente mari.

    Legat de code completion si VC cu tot cu VA mai da rateuri, mai ales in proiectele in care am folosit template-uri.

  36. iuliancalin Says:

    hai ca ti-am bagat blogu la “interesante”
    si daca stau bine si ma gandesc linux bate piata…si nu o zic pentru ca sunt fanatic si folosesc linux doar din cod
    ba chiar imi prind urechile cand trebuie sa scriu iin consola, defapt stiu sa scriu asta (sudo su…chmod ….etc)
    daca e sa instalez ceva imi flutura urechile …
    dar daca stam sa ne uitam putin peste el o sa vedem ca are o interfata destul de prietenoasa (cateodata nu gasesti din prima ce vrei sa cauti) cauti dupa un program de iti plang ochii
    dar pana la urma te obijnuiesti si o sa incepi sa urasti windows xp, si asta poate din cauza virusilor si a rateurilor pe care le da (cel mai misto e ecranu ala albastru)
    si in ciuda pretutlui pe care ii dai pe windows…..linux e gratuit, deci are voie sa aibe lipsuri
    fui tre sa plec

  37. jos8cal Says:

    Esti plictisitor Iuliane. Ai ban.

  38. Vasile Says:

    @jos8cal: de fanboi se poate rade

    desi e drept ca-s peste tot si dupa o vreme nu mai e haios, ci erodeaza creierul

  39. jos8cal Says:

    Stiu ca se poate ride, initial la asta m-am gindit. Dar m-am uitat pe blog-ul dinsului si m-am enervat.

  40. iuliancalin Says:

    si ma rog de ce te-ai enervat?
    era alb in loc de negru sau…?

  41. iuliancalin Says:

    apropo de ban…trimite-l ptin posta te rog, o sa-l pun la pusculita si cand strange “camasa” poate o sa ma folosesc de el
    defapt primesc doar de la cent in sus :)

  42. siEu Says:

    @gigi: multumesc, la fel.
    @iulian: de fapt tu ce cauti aici?

  43. oro Says:

    Esti subiectiv. De ce nu mentionezi si lucrurile bune pe care le are XCode ? De exemplu, in cate IDE-uri poti sa selectezi codul si sa-l postezi direct pe Twitter ?

  44. anon Says:

    incearca Qt

Leave a Reply

Optionally add an image (JPEG only)