Paklausite - kodėl neturėjo?
Atsakymas paprastas – dėl tos pačios priežasties, kodėl Microsoft metė C++/CLI  (Common Language Infrastructure) ir CLR reikalą, ir nusprendė sukurti C# programavimo kalbą. Kuri iš tiesų yra tai ką norėjo padaryti, bet iki šiol dar nepadarė SUN’as su savo Java programavimo, kalba, kartu įtraukiant geriausias C++ savybes, bei įtraukiant nemažą netipizuotų programavimo kalbų, tokių kaip Python ar Php savybių. O ką bekalbėti apie tokius daiktus kaip IronPython, SilverLight ir galų gale ASP.NET (čia QT su savo web galimybėmis yra aiškiai tvarkomas į vienus vartus kad ir kokia operacinė bebūtų ant to QT C++ ). Negana to ką bekalbėti apie kodo rašymo spartą – C++ VS C#, pirmiesiems reikia galvoti apie visokius headerius, neduok dieve nesukurti rekursijos, kai vienas į kitą kreipiasi, nes atsiras begalės problemų (tiesa, Nokia su savo QT C++ šią problemą bandė spręsti naudojant Signals ir Slots, ir tai iš tiesų padeda bent jau kažkokį apps’ą parašyti, tačiau nesprendžia reikalo iš esmės).

Taigi rezultate turime Nokia ir Windows Mobile 6.5, kurią Microsoft’as pakeičia Windows Phone 7 kultas, kuri turėtų būti naujasis stebuklas ant C#’o. Tiesa pagal dabartinius feature’sus, nepaisant to kad MS C#’u koduoti žymiai patogiau, lengviau, greičiau ir maloniau, nei  QT C++, o Visual Studio 2010  >>>>>>> Nokia QT 4.7, bet pačio
Symbian^3 VS  Windows Phone 7 palyginimas 2011 metų vasariui buvo toks:

* Greitis panašus

* Resursų sunaudojimas irgi panašus (Android’ui reikia 2 branduolių ir 1,3 Ghz norint išgauti maksimumą, Symbian’ui užtenka vos 1 branduolio ir 600 Mhz, kas kartu reiškia ~2 kartus mažesnius poreikius iš telefono baterijos).

* Windows Phone 7 šiuo metu nepalaiko Multi-tasking’o, Copy-Paste, background services ir kt,. o Symbian^3 visą tai seniausiai palaiko. Nemažai iš šių trūkumų turėtų būti pašalinta iš WP7 šiuo metų pabaigai, kuomet turėtų pasirodyti pirmieji Nokia WP7 telefonai.

—-

Symbian^3 operacinei sistemai, Nokia, deja, tesugebėjo išleisti kol kas tik 4 telefonus: Nokia N8, Nokia C6-01, Nokia E7-00 and Nokia C7-00 .

Naujasis Nokia N9 turėjo būti pirmasis tobulusios MeeGo OS atstovas, su pašalintais visais N8 trūkumais, bei tomis pačiomis ir geresnėmis tech. specifikacijomis kaip ir N8, bet visas šitas reikalas tapo discontinued po to kai Nokia šių metų vasarį paskelbė pereinanti prie Windows Mobile 7 ir atsisako savo operacinių kūrimo, kartu atleidžia tūkstančius produktų, pereina iš Open-Source į Closed-Source, ir gauna ribotą galimybę šiek tiek modifikuoti Windows Mobile 7 OS savo kompanijos ribose Suomijoje.

Taigi visi tie, kas laukė Nokia N9 taip ir liko nieko nepešę, ir tikėdamiesi kad įsigyti Nokia N8 neverta nes greitai pasirodys Nokia N900 liko išvis be išmaniojo telefono .

Netgi buvo nuotraukos pasirodžiusios internete naujojo Nokia N9:

Nokia N9

 Iškart galime jį palygti su Nokia N8:

Nokia N8

Kas dar geriau Symbian’ui ir Nokia N8 šiuo atžvilgiu yra tai, kad, kadangi Symbian^3 operacinė išleista ir produktai su šia operacinė taip pat, tai Nokia paliko nemažai žmonių prie šios OS support’o, t.y. kartu ir bugfix’ai, update’ai šiai OS ir t.t., o Maemo developeriai buvo arba gražinti prie Symbian’o, arba išvis atleisti, arba perkelti į kitas pareigas. ).

Neaišku kaip yra su QT QML projektu, kas yra kone Javascript+CSS geriausios savybės, tik kad juo rašomos programos skirtos Symbian^3. Čia apps’as rašomas ~10 kartų greičiau nei su originaliu QT C++. Tik šis dalykas dar neturi finalinės versijos, tad ne viską galima su juo sukurti. Jeigu QML’ą Nokia išbaiktų, tai ir appsų kūrimas, skirtas Symbian^3 telefonams taptų begalo paprastas. Iš tiesų tai QML’as yra Framework’as ant QT C++, kaip QT C++ yra framework’as ant orginalaus ISO C++. Ir beje QML išties nerealus dalykas, man beje labiausiai patikęs iš Nokia sukurtų programavimo produktų.

Taigi iš ‘greit žūsiančio’ produkto Nokia N8 ir Symbian^3 rodos tapo ilgalaikiu ir supportinamu produktu, ir šita situacija nuo Nokia N8 paskelbimo 2010 pavasarį iki 2011 pabaigos panašu kad ir išliks ). Na o Nokia N8 atgyvens normalų bent 1,5 metų gyvenimą, ir turint omenyje rinkos ir technologijų spartos tendencijas, bus pakeista laiku, o ne anksčiau laiko . O visi Nokia N8 savininkai prisimins turėję puikų telefoną.

Ir apskritai, aš nesupratau daugelio stumimo ant Symbian^3 ir Nokia N8 argumentų. Taip, apps’us rašyti išties yra sunkiau nei Android’ui(Google version of Java) ar WP7 (Microsoft’s C#), tačiau nepasant to Symbian^3 operacinė išties buvo funkcionali:
A-GPS, WLAN 802.11n palaikymas, HD video palaikymas, Flash palaikymas, FM radijas, Multi-tasking’as, Background-services, Multi-touch ir t.t.

O pats Nokia N8 mano nuomone apskritai buvo geriausias telefonas rinkoje pagal mano poreikus:
manieji koncentruojasi į kamerą, diktofoną, fotoaparatą, USB 2.0/3.0 ir HDMI jungtis, GPS palaikymą, WIFI 802.11n prieigos buvimą, FLASH palaikymą, radiją ir multitaskingą.
Visą tai Nokia N8 turėjo, negana to ir 16GB vidinę atmintį, kas irgi darė praktiškai visus Android telefonus, o dėl perdavimo tarp PC<->Nokia N8 per mini USB spartos, man iki šiol neprireikė įsidėti microSDHC 32GB flash atminties kortelės, kurią turėjo palaikyti šis telefonas, sumoje leidžiantis turėti visus 48GB )).

Įdomumo dėlei pasakysiu kad į Nokia N8 vidinius 16GB telpa ~2 valandos video klipas HD kokybe MP4 HD formatu @25fps filmuotu šiuo telefonu.

Neaišku kaip bus su MicroSDXC (SD eXtreme Capacity) palaikymu Nokia N8, kas yra ‘upcoming’ standartas, apimsiantis teorinę 64GB->2TB microSD kortelių gamą(kolkas SDXC serijoje yra žinomi tik du modeliai 64GB ir 128GB, ir ‘microSD’ grupėje jie dar kol kas nepreinami, tą galima padaryti tik nesumažiname SD dydyje). Tačiau net jeigu Nokia N8 to ir nepalaikytų, manau per metus gerokai atpigsiančios 32GB microSDHC kortelės man pilnai manau užteks iki šio telefono, kaip pagrindinio mano aparato rankose, vartojimo perleidimo kitam aparatui. O šis daiktas manau dar metus užsibus pas mane, nes KAMEROFONU srityje Nokia N8 padarė progresą TIK VAIZDO FILMAVIME lyginant su mano turėją EX’serija – Samsung SGH-G800 ir SGH-G810 (Symbian S60V5, 5Mpix FOTO, 3x optinis artinimas, MAKRO režimas, vaizdų atpažinimas, vaizdo stabilizavimas ir VGA (640×480) filmavimas 30fps greičiu, kas irgi nebuvo taip jau prastai).

Beje dar vienas idomus faktas – su savo 3 kartu didesniu lešiu, ir rimčiau atrodančia optika Samsung SGH G810 nuotraukos 5Mpix sveria 2,2 -> 2.9MB, tuo tarpu Nokia N8, su savo 12Mpix vaizdais nuotraukas tepagamina vos 1.6-2.2MB. Visai kitas reikalas su video filmavimu, čia jau įdomiau – 8 minutės judančio vaizdo filmavimo vidutiniškai užima ~1GB vietos telefone .

Ir nenuostabu, HD filmavimo kokybės iš Nokia reikėtų pasimokyti daugumai kompanijų, tame tarp ir Samsung, būsimiems Apple produktams, Sony Ericsson ir kitiems.

Dar kažkokie gandai buvo kad telefonas laggina ir kimba. Tai pasakysiu – aš asmeniškai jokio lago nejaudčiau, telefoną perkroviau per pusmetį gal kokius 6 kartus, kuomet nenorėjo užsidaryti atidaryti apps’ai, kas neva laikoma kibimu. Galbūt kartais jis truputi ilgiau sekunde ar pora atidarinėja kokį tai dalyką, tarkim kamerą ar GPS, tačiau kad tai ‘lėtas’, ‘lagginantis’ daiktas to nepasakyčiau.

Apie ‘bateriją laikančią 1 dieną’ – tai irgi tik gandas, telefoną aš kraunu vidutiniškai kas 4-5 dienas. Ir per pusmetį niekas nepasikeitė.

Vienintelis kvailesnis dalykas yra tai, kad jeigu ekrane yra vienintelis teksto laukelis, jums visvien pirmiausiai reikės ant jo bakstelėti kad galėtumėte įvedinėti tekstą.

Na o bene geriausias dalykas yra šio telefono kaina. Vos jam pasirodžius, šį telefoną buvo įmanoma įsigyti už maždaug 1250 litų, salonuose kaina buvo 1600-1700Lt, kas yra žymiai pigiau nei Apple iPhone4, ar Samsung Galaxy S + 16GB microSDHC kortelė. Abu pastarieji variantai tuo metu būtų atsieję po bemaž 3000 lt ir abu telefonai buvo smarkiai prastesni mano poreikių atžvilgiu – tai vienam ar kitam trūko WIFI 802.11n standarto, tai HD filmavimo, tai 12Mpix kameros.

Dar beje, teko pabuvoti stažuotėj ir konferencijoje/seminare kompanijoje Nokia, tai nuo šiol turiu naują kokybės standartą kaip turėtų būti organizuojamos stažuotės, konferencijos, seminarai… Lietuvos visiems AB’ams labai labai labai toki iki to. Pradedant tuo kad už viską sumoka Nokia – pietus, pusryčius, vakarienę prabangiame restorame, aprūpina reikiama įranga – kiekvienam dalyviui seminare nors ir po 2, kad ir Nokia N8 telefonus visoms konferencijų dienoms, svarbu bele prieš išvažiuojant atiduoti, tiek iš Nokia apmokamų tarptautinių kelionių, tie padoriais pranešimų skaitytojams, tiek normalia praktika, su visu softu etc. Na vnž, net ir mūsų Omniteliui, Bitėj ar kitiems stambiems AB’ams Lietuvoje labai toli iki to, ir man tiesa sakant dabar jau labai booring būtų šių kompanijų seminaruose būti dar kartą.

Durnesnės (NE)programavimo kalbos neteko matyti.

1. Visual Basic
2. Bandymai pagerinti ISO C++ – padarytas Visual C++/CLI. Neva turėjo pagerinti GUI kūrimą. Gal ir pagerino, bet yra iš tiesų tai totalus CRAP. Ir tai sakau, perpratęs šią C++ kalbos perdarymo rūšį. Beje, google taip pat tam pritaria, ir dauguma Visual C++/CLI programuotojų perėjo prie:
3. C#.

Nesvarbu kad visi jie naudoja tą patį .NET framework’ą 4.0. Esmė ta, kad Visual C++/CLI kalba praktiškai yra tiesiog ‘useless’. Aš suprantu kad galima surasti ISO C++ programavimo kalbos panaudojimų vietų, tačiau C# neabejotinai yra geriau nei Visual C++/CLI.

Vienas iš tokių atveju – objektų multithreadingas – t.y. GUI po mygtuko paspaudimo pabandus paduoti ‘this’ pointerį į pačią windows formą, nelabai gaunasi daryti ‘mutual connection between objects’. Nes gaunasi begalinė rekursija, arba reikia matyt labai užsiknisti.

O ir šiaip – programinimas per prototipus – headerius, tikrai yra outdated dalykas per daug lėtinantis procesą. Java ir C#, C++ kalbą šiuo atžvilgiu daro į vienus vartus…

Beje, Echo Serverį programinau su standartiniu ISO C++ su CodeBlocks IDE, be GUI. Visual C++/CLI ir Visual Studio buvo reikalingas tik dėl Echo Kliento, nes jis buvo su GUI. Tik čia normaliai ir lengvai galima padaryti ir valdyti C++ GUI, negana to be didesnių keitimų veikia Java GUI(Swing) anksčiau rašytas kodas.

O iš tiesų tai parašiau tik 2 programas – Echo Serverį ir Echo Klientą Java 1.6 su NetBeans IDE. O tik po to tą patį kodą perkėliau į ISO C++, bei Visual C++/CLI.
Port’us tarp aplikacijų daryti jau ne kartą yra tekę: Java -> C#, Java -> Python, tad ir šis portas nebuvo naujiena. )

Vidutinis 1 programos dydis buvo ~1400 eilučių, na o visas 3 užduotis padaryti prisireikė mažiau mėnesio. Pradėjau rugsėjo vidurį, o spalio viduryje pabaigiau. )

Papildomai pasiGOOGLinau vieno įrankio ‘days passed since’ – ‘Date difference calculator’:
http://www.convertunits.com/dates/

Įvedęs skaičius:
http://www.convertunits.com/dates/from/Jun+23,+2009/to/Oct+6,+2010

Sužinojau kad praėjo jau 469 dienos nuo mano pirmojo blogo įrašo, o tai reiškia, jog per dieną parašau vidutiniškai po 0,21 blogo.

Hmm… gal reiktų pasiieškoti nacionalinės Lietuvos blogų lygos, galbūt į kokį sąrašą priimtų .

Ką naudoti?
Atsakymas: greičiausiai teks naudoti abu, nes tik sudėjus bendrai galima gauti normalų C++ IDE įrankį.

Code::Blocks pliusai:

1. Užima mažai vietos
2. Paprastas ir lengvai suprantamas IDE
3. Puikus debugeris
4. Daug gerų įrankių – kodo eilučių skaičiuoklis, lib finder ir pan.
5. Visai padorus IDE GUI kūrimas(ne kompilavimas) wxSmith įrankiu, drag n’ drop, event bind ir t.t.
6. Patogus išorinių bibliotekų pridėjimas.
7. Puikiai dirba su SOCKET’ais.

Code::Blocks minusai:

1. Tragiškai sudėtingas GUI aplikacijų kompilavimas naudojant wxWidgets bibliotekas. (galbūt tik Windows terpėje)
2. Nėra gero ‘on-write check’ neteisingo kodo ryškinimo – ryškinamos tik sintaksės klaidos, o ne loginės/semantinės.

Nokia Qt pliusai:

1. Bene vienintelis įrankis, kuriame normaliai kompiliuojasi C++ GUI aplikacijos (neskaitant MS Visual Studio ir Visual C++).
2. Gana paprastas Qt GUI drag n’ drop, event bind’as sudėtingesnis.
3. Puikus ‘on-write check’ tikrintuvas, leidžiantis ištaisyti daugumą klaidų kodo rašymo metu.

Nokia Qt minusai:

1. Sudėtingas ir griozdiškas, bei labai nepatogus IDE. Daug bereikalingų veiksmų, viskas padėta tikrai ne ten kur turėtų būti.
2. Rankinis projektinio failo konfigūravimas. Labai nepatogu + galimybė įvelti ir nesugebėti rasti klaidos.
3. Sunku sutvaryti su Socketais dirbantį projektą (man kol kas nepavyko).
4. Problema pernešus projektą iš vienos direktorijos į kitą. Statinis kelio įrašymas.

Kai prisiminsiu daugiau punktų sąrašą papildysiu.

Kada rinktis CodeBlocks, o kada Qt?

CodeBlocks rinktis kai:

• Norite kurti ‘Console’ tipo aplikaciją
• Norite dirbti su Socket’ais.
• Norite pradėti mokytis C++ ir norite lengvo, paprasto ir greitai perprantamo IDE.
• Norite gerai išDEBUG’inti projektą.

Qt rinktis, kai:

• Esate ‘advanced’ C++ kūrėjas.
• Norite kurti C++ GUI tipo apliakacijas.
• Norite perkelti Java aplikaciją į C++ ir kodo tvarkymo metu surasti ir ištaisyti kuo daugiau problemų.
• Norite kurti komandinį projektą (Share on TeamServer), ir naudoti Source Control įrankius: Git arba Mercurial.

Visų pirma, tik perėjęs CGI -> HTML >~~> Pascal -> Php >~~> Pascal -> ASM -> C -> C++ -> Java -> C# -> Python >~~> Java -> C++ galiu pasakyti, kad C++ programavimas C++ (aš net nekalbu apie C) yra labai labai užknisantis, ir maždaug 2-3 kartus sudėtingesnis ir mažiau patogus nei netgi tokia kalba kaip Java. O pati java ir tokie toolsai kaip NetBeans dar nežinia kada prilygs tokiems toolsams kaip Visual Studio ir C# kalbai. Ir daugiausiai problemų atsiranda su C++ kalba tada, kaip prisireikia DEBUGGINIMO, GUI bei SOCKET”ų… Siaubizmas…

Taigi, mano idėja buvo tokia – paimti Java savo parašyti programą ir padaryti portą į C++.

Tokius dalykus jau yra tekę daryti – Php HipHop’e Php kodą keičiau į C++, C++ kodą į Php, pasiėmęs Java programą ją perrašinėjau Jython’ui (Python on Java), o Java programą perrašinėjau C#.

Ir galiu pasakyti, kad padaryti portą Java -> C++ buvo kol kas pati sudėtingiausia užduotis. Koks durnas yra C++ kodas kartais net keista.

Pvz. jeigu norite statinio metodo, tai headeryje rašote žodį static prieš metodo prototipą, o realizacijoje jau nebeįmanoma. Dar laimei kad yra toks dalykas kaip #include <vector>.

Tai va, pirmiausia Qt prieš mėnesį rašytame blogo įraše išvis išbrokavau kaip įrankį. Su Qt yra tekę susidurti ir prieš 3 mėnesius ir prieš pusmetį, vienam kursiokui darant operacinės sistemos projektą. Ir visus kartus aš Qt išbrokavau.

Bet pasirodo Qt buvo mano problemos vienas iš būtinų realizacinių sprendimų. O taip yra todėl, kad jis turi tikrai neblogą ‘debug’ą kodo rašymo (ne kompiliavimo metu). Jeigu CodeBlocks leidžia atidaryti Java projektą su *.cpp galunėmis ir nuėmus import, praktiškai pripažystą kaip VALID kodą. Todėl teko tą projektą atsidaryti su Qt programa, kuri mane būtent ir išgelbėjo. Pavyko paruošti pakankamai neblogą PORTą iš Java į C++. Tačiau kai ištaisiau dar vėliau kompiliavimo metu rastas klaidas, vėl susidūriau su Qt prastumu. Nepaisant prasto IDE, debugeris su “collect2: returned -1″ ir labai dideliu nenoru su SOCKET LIB’ais vėl išsekino mano kantrybės taurę. Todėl, viską ką buvau padaręs, persikėliau į CodeBlocks – IDE tūlsą su labai puikiu Debugeriu(kaip C++ kalbai), patogiu IDE, bei suknistu GUI kūrimu ir probleminių, ne kompiliavimo metu, klaidų radimu.

Na o Code::Blocks su Socketais dirba puikiai.

Jeigu yra nežinančių, kaip naudotis Echo Serveriu, tai atsakysiu:
1. Winsock 2 (libws2_32.a ) >>>>(daug geriau)>>>> Winsock I (libwsock32.a )
(T.y. Wsock2 yra FULL BACKWARDS COMPATIBLE su Wsock, ir turi naujų funkcijų, todėl geriau naudoti Wsock2.)

2. Taigi susikuriame ‘C++ Console Application’ projektą.

3. Tada ant projekto spaudžiame dešinį klavišą -> “Properties…”

4. Project settings kortelėle spaudžiame mygtuką “project’s build options…”

5. Atsidariusiame lange spaudžiame ant kortelės “linker settings”

6. “Link libraries:” bloke apačioje spaudžiame mygtuką “add”

7. Per [browse...] susirandame failą:

C:/MinGW/lib/libws2_32.a

arba (jeigu instaliavote MinGW kartu su CodeBlocks, nors, mano nuomone, tai blogas sprendimas, jeigu kaip ir aš naudojate kelis C++ IDE, o norite projektus mėtyti tarp vieno į IDE į kitą ir norite taupyti vietą) 

C:/Program Files(x86)/CodeBlocks 10.05/MinGW/lib/libws2_32.a

8. Pridedame tą patį prie Debug ir prie Release.

9. Dabar mūsų serverį reikės paleisti per kažkokį tai portą, geriausiai virš 10000, ir nenaudokite 80 (IE), 8080 (TFS, PostgreSQL, Skype, WAMP), 8000 (Python+Django server), nes neveiks. Taigi, spaudžiame:
Meniu -> Project -> Set programs’ arguments…

10. Prie debug ir release pridedame dalyje “programs arguments:”, pvz. “10999″, t.y. Jūsų serverio porto numerį.

11. Viską išsaugome. Susikeliate C++ Example Echo server aplikaciją, tik visur header failuose padarome pakeitimus:

Kodą:

#include "winsock.h"

keičiame į:

#include "WinSock2.h"

Beje, Visual Studio ir Visual C++ irgi turi savo alternatyvą, tačiau man daug paprasčiau viską padaryti pavyko būtent ne su Visual C++, o su Code::Blocks.

Visual C++ ketinu naudoti tik tuomet, jeigu nepavyks kliento(ne serverio) programos sukurti naudojant GUI per Qt. Visual C++ ir Visual Studio GUI Jus gana smarkiai pririš prie Windows’ų, tuo tarpu Netbeans ir Swing, Qt ir Qt GUI, bei Code::Blocks ir WxWidgets (kuris man taip niekad ir nesusikompiliavo) yra platform-independent.

Pastaba: Qt projetų GUI buvo atsisakęs kompiliuoti vien dėl to, kad Windows 7 buvau paredagavęs ‘environment variables’ ir prie PATH pridėjęs MinGW kelią. Jis turi būti application-controled, o ne iš Windows’ų nustatomas. Šį dalyką buvau padaręs, nes to reikalavo WxWidgets, bet taip ir pamiršęs buvau nuimti, o WxWidgets kaip neveikė, taip ir neveikė.

Pastaba 2: C++ echo serverio pilno kodo pavyzdžių nebus, nes yra toks saitas:

http://www.justfuckinggoogleit.com/

Nelaimei, rezultate nieko gero taip iki šiol ir nesigavo. Laimei, pirmiau išbandžiau šį dalyką su laptopu ir jame esančiais 32 bitų windows 7′aisiais. Ten bent jau example projektai veikė.

Windows 7 x64 atveju kuriant “Qt C++ GUI” projektą susidūriau su analogiškomis problemomis kaip ir ”Code::Blocks C++ wxWidgets GUI” atveju:

Build issues: CreateProcess: No such file or directory
Compile output: When executing build step ‘Make’
 

O dar bjauresnis dalykas yra tas, kad klausdamas visagalio “GŪGLO”, gaudavau siūlymą problemos ieškoti šiame bloge… Kitaip tariant, gūglas aiškaus atsakymo taip pat nežino.

O dabar truputi užstumsiu ant Qt ide:
1) Jau trejetą metų nemačiau tokio bajerio, kad visokius makefile’ų papildymus, reikalingus build papildomus LIB’us reiktų įrašinėti per text editorių į projekto tekstinį failą… T.y. Qt neegzistuoja tokia funkcija kaip “add library”, kuri yra visur kitur – Visual Studio, CodeBlocks, NetBeans ir t.t.
2) Ta programa – Qt – griozdiška. Užima bene 2GB tačiau taip ir nesupratau, ko ten pridėta, kad kas būtų reikalinga. Matyt didžiąją dalį svorio sudaro įranga skirta tik mobiliems telefonams skirtų programų kūrimui. Pastebėjimui – CodeBlocks instaliuotas užima vos kelis šimtus MB.
3) Ši programa iš pradžių pasiūlo tik vieną kompiliatorių, jo keitimas pakankamai sudėtingas, kai tuo tarpu CodeBlocks yra bent 20 kompiliatorių sąrašas.
4) Qt projektai NEVEIKIA perkėlus iš vieno PC į kitą, NetBeans, CodeBlocks ir t.t. be problemų projektus mėtau tarp kompiuterių. Problema ta, kad Qt dėl tik jam pačiam suprantamų savybių, naudoja ‘absolute path’. Todėl reikia naudotis Replace all funkcijomis.
5) Qt ide yra labai nepatogus, susigaudyti jame sunku, vaikščioti tarp failų – taip pat.
6) Qt išbandžiau dėl to, kad čia turėjo gerai kompiliuotis GUI projektai – bet taip nė velnio nėra.
7) Man nepatinka Qt debugeris – labai nepatogus, man nepatinka kompiliavimas – jis labai neaiškus, klaidos ieškoti turi pats, o ne tave prie jos numeta, kaip yra kituose IDE.
8 ) Qt projektai gali būti tik tame pačiame diske, tik C:\Qt\2010.05\qt\ direktorijoje.
9) Qt gali būti instaliuotas tik į “no space” direktoriją, t.y. neįmesiu aš jo ten, kur esu pratęs, t.y. C:\Program Files(x86)\… Po to taip ir užmiršti kelių bitų yra ta Qt programa – 32 ar 64.
10) Qt nepalaiko CTRL+D metodo(‘duplicate line’), codeblocks – palaiko.

Iš Qt pliusų – tai kol kas tik vienas. C++ Gui drag’n drop kūrimas gana patogus, tačiau pvz. Code::Blocks priskirti BackgroundColor – reikia vieno žingsio, čia reikia bene 5 žingsnių.

Reziumė paprasta – Qt trumpam pabandžiau dėl to, kad tikėjausi pakurti Qt GUI projektą. Bet, deja, toli gražu iki to, su Windows 7 x64 sistema.

Prieš daugiau nei metus, rašiau blogo įrašą:

Java, C++, C#, Php, Pascal redaktoriai ir kompiliatoriai

Per daugiau nei metus padariau šiokį tokį progresą, todėl šį savo blogo įrašą dabar jau galėčiau papildyti naujomis programavimo kalbomis ir geriausių įrankių rekomendacijomis, remiantis savo ir Google patirtimi .

Taigi pradėkime:
*Kodo-kontrolė aka ’source-control’

Assembler:

IDE: Emu8086 (v4.08)
GUI įrankis: neegzistuoja
Kaina: mokamas (Shareware, egzistuoja išgydytas variantas)
Kompiliatorius: Fasm.exe
Iš kur atsisiųsti: http://www.emu8086.com/ (3,07 MB)
Instaliuotas užima: 10,4 MB
Geresnis nei: Nėra alternatyvų

Pascal:

IDE: Lazarus  (v0.9.28.2 beta)
Kaina: Nemokamas (Open Source)
Kompiliatorius: fpc.exe (v2.24)
Kodo dokumentavimas: FPDoc (automatizuotas)
Auto-complete: yra (Ctrl+Space)
GUI įrankis: integruotas
GUI drag n’ drop: egzistuoja
GUI naudojimas/build: paprastas / jokių papildomų pastangų
Lietuviška versija: yra
UTF-8: palaikomas
UNIT-testai: palaikomi (FPCUnit test)
Kodo-kontrolė: nepalaikoma
Projekto adresas: http://lazarus.freepascal.org/
Iš kur atsisiųsti: http://sourceforge.net/projects/lazarus/ (61,5 MB)
Instaliuotas užima: 474 MB
Geresnis nei: FPS, Free Pascal IDE

C/C++:

IDE: Code::Blocks (v10.05)
Kaina: Nemokamas (Open Source)
Kompiliatorius: MinGW (GCC for Win), Borland C++, Visual C++ ir kiti.
Kodo dokumentavimas: FPDoc (automatizuotas)
Auto-complete: yra (Ctrl+Space)
GUI įrankis: integruotas
GUI drag n’ drop: egzistuoja
GUI naudojimas/build: paprastas / jokių papildomų pastangų
Lietuviška versija: yra
UTF-8: palaikomas
UNIT-testai: yra
Kodo-kontrolė: Versioning, SVN
Projekto adresas: http://www.codeblocks.org/
Iš kur atsisiųsti: http://www.codeblocks.org/downloads/26 (70,5 MB)
Instaliuotas užima: 157 MB
Geresnis nei: DevC++
Alternatyvos: Qt

C# + ASP.NET, SilverLight:

IDE: Microsoft Visual Studio 2010 (.NET 4.0)
Kaina: Mokamas (Shareware, Student Edition – nemokamas)
Kompiliatorius: Microsoft Visual C#
Kodo dokumentavimas: yra(automatizuotas)
Auto-complete: yra (Ctrl+Space)
GUI įrankis: integruotas
GUI drag n’ drop: egzistuoja
GUI naudojimas/build: labai paprastas / jokių papildomų pastangų
Lietuviška versija: yra
UTF-8: palaikomas
UNIT-testai: yra
Kodo-kontrolė: Microsoft Team Foundation Server 2008
Projekto adresas: http://msdn.microsoft.com/en-us/vstudio/default.aspx
Iš kur atsisiųsti: http://msdn.microsoft.com/lt-lt/vstudio/bb984878(en-us).aspx (4,5 GB)
Instaliuotas užima: 12 GB
Geresnis nei: Nėra alternatyvų

Java:

IDE: NetBeans (v6.9)
SDK: Java SDK 1.6
Kaina: Nemokamas (Open Source)
Kompiliatorius: javac.exe (JRE – Java Runtime Environment)
Kodo dokumentavimas: JavaDoc (automatizuotas)
Auto-complete: yra (Ctrl+Space)
GUI įrankis: integruotas
GUI drag n’ drop: egzistuoja
GUI naudojimas/build: paprastas / jokių papildomų pastangų
Lietuviška versija: yra
UTF-8: palaikomas
UNIT-testai: JUnit
Kodo-kontrolė: CVS, Mercurial, Subversion
Projekto adresas: http://netbeans.org/
Iš kur atsisiųsti: http://java.sun.com/javase/downloads/widget/jdk_netbeans.jsp (149 MB)
Instaliuotas užima: 214 MB + Java SDK
Geresnis nei: Eclipse

Php+Simphony, Zend+Smarty:

IDE: NetBeans  (v6.9) + Php, Simphony,Zend,Smarty Plugins
Serveris: EasyPhp (v5.3)
Kaina: Nemokamas (Open Source)
Kompiliatorius: php.exe (v5.3.2)
Kodo dokumentavimas: Yra (automatizuotas)
Auto-complete: yra (Ctrl+Space)
GUI įrankis: nėra
GUI drag n’ drop: nėra
GUI naudojimas/build: nėra / nėra
Lietuviška versija: nėra
UTF-8: palaikomas
UNIT-testai: palaikomi
Kodo-kontrolė: CVS, Mercurial, Subversion
Projekto adresas: http://netbeans.org/
Iš kur atsisiųsti: http://netbeans.org/downloads/index.html (83,5 MB)
Instaliuotas užima: 150 MB
Alternatyva: Zend Studio 8, Notepad++

Python+Django:

IDE: PyCharm  (1.0 beta 2, PY-96.1203)
Kaina: Mokamas (Beta testing šiuo metu, todėl nemokamas)
Kompiliatorius: pythonw.exe (v2.7.2) [Neitegruotas]
Kodo dokumentavimas: yra (automatizuotas)
Auto-complete: yra (Ctrl+Space) [ir Python ir Django]
GUI įrankis: nėra
GUI drag n’ drop: nėra
GUI naudojimas/build: nėra / nėra
Lietuviška versija: nėra
UTF-8: palaikomas
UNIT-testai: palaikomi
Kodo-kontrolė: Mercurial, Perforce, Subversion, CVS, Git
Projekto adresas: http://blogs.jetbrains.com/pycharm/
Iš kur atsisiųsti: http://confluence.jetbrains.net/display/PYH/JetBrains+PyCharm+Preview (69,3 MB)
Instaliuotas užima: 215 MB
Geresnis nei: Komodo Edit, WingIDE 4, µ.dev, Eric 5, Aptana Studio 2+PyDev, Eclipse+PyDev, Python IDLE

O dabar viską į ‘po vieną eilutę’:

Assembler IDE: Emu8086 4.08
C/C++ IDE: Code::Blocks 10.05
C# + ASP.NET IDE: Microsft Visual Studio 2010
Java+Swing IDE: NetBeans 6.9
Php+Simphony,Zend IDE: NetBeans 6.9 + Php, Simphony,Zend,Smarty Plugins
Jython+PostgreSQL IDE: NetBeans 6.9
Python+Django IDE: PyCharm 1.0 beta 2

Dar  pora pastabų:
1. Nepaminėjau perl – bet tai skriptinė kalba, su kuria serverio skanavimus ir automatizuotus instalus yra išties patogu ir lengva pasidaryti. Tačiau kitam ji nelabai skirta.

2. Internete yra RubyOnRails(Ruby web framewok), Visual Basic, Delphi ir netgi Ada gerbėjų. Tačiau susižavėjimo ir didelių perspektyvų šioms programavimo kalboms nejaučiu, bent jau šiuo metu, todėl, perpratus pagrindines žinomiausias ir populiariausias programavimo kalbas, didžiausias galimybes matau skill’ų kelimu šiose kalbose.

3. Na o dar viena, labai įdomi, bet mažai ištyrinėta sritis yra Cisco ir apskritai kompiuterių tinklų sritis. Nors su Cisco reikalų turiu jau daugiau nei metus, tačiau ši sritis yra tokia plati ir didžiulė, kad kai kuriems žmonėms prisireikia 10-15 metų tapti šios srities žinovais.

http://wxpython.org/download.php

Ir mane suintriguoja eilutė:

“Like any other complex piece of software, wxPython requires other software in order to function properly. Obviously you’ll need Python itself, but if you’re reading this you’ve probably already got Python and are just here looking for the best GUI toolkit available for Python.”

Negi galima su šiuo pasisakymu sutikti. Ypač po mano paskutinio susidūrimo su wx įrankiais:
Pastrigau, Windows 7 + wxWidgets + MinGW + wxSmith

Aš tikrai nepulčiau šlovinti wx grupės. Taip, galbūt jie ir suteikia nemažai galimybių kuriant tokiais IDE kaip CodeBlocks + wxSmith, tačiau jų paruošimas naudojimui ir kompiliavimas yra tragedija. Aš, kaip tipinis useris, noriu produktyvumo, kuri kol kas idealiai siūlo tik Microsoft Visual Studio 2008/2010, bei antroje vietoje esantis NetBeans+Swing.

Taigi, wxPython galbūt yra išeitis jeigu mes programuojama būtent tik CPython. Tačiau, kaip bebūtų keista, aš to nedarau. CPython’as, arba orginalusis Python’as mano suprantamas tik kaip Django komponentas PyCharm IDE.

Jeigu aš sumastau rašyti Desktop tipo aplikaciją su Python’u, tai mano pasirinkimas visai kitas:

Arba renkuosi Jython ir naudoju NetBeans IDE ir Java Swing GUI kūrimo įrankį,

arba renkuosi IronPython ir Microsoft Visual Studio kūrimo įrankį.

Abiem atvejais GUI elementarų paruošiu per pusvalandį, o konfigūravimui, kad projektą pavyktų sukompiliuoti – LYGIAI 0 sekundžių.

Ir gaunu atitinkamai:

arba Java+Swing galimybes ir Python paprastumą

arba C# ir Visual Studio galimybes ir Python paprastumą.

Kam man reiktų rašyti Desktop aplikaciją tik su CPython? – na kol kas to neprisireikė.