Jakou ma ted QT licenci? GPL nebo LGPL?

http://www.qtsoftware.com/products/licensing

Ja bych dneska uz asi QT na novy projekt nepouzil pokud by k tomu nebyl opravdu dobry duvod (treba aplikace pro mobil).
V Jave s SWT/JFACE/RCP knihovnami se mnohem lepe dela, navic je mozne mit pomoci OGI modularni aplikaci, pres p2 to umi velmi hezky delat aktualizaci komponent pres net.
Taky je Java jako programovaci jazyk lepsi nez C++. Programator v nem nenadela tolik chyb, lepe se ladi, nejsou potreba hlavickove soubory, odpadaji zde problemy s kompilatory C++ ktere jsou navzajem nekompatibilni. C++ ma doby sve slavy jiz zasebou. Dneska lidi uz delaji mnohem vice ve skriptovacich jazycich a C#.
QT neni zase uplne spatny framework, asi nejlepsi z OSS co lze sehnat. QT pro javu jsem nikdy nezkousel http://www.javaworld.com/javaworld/jw-08-2007/jw-08-qtjambi.html Otazka je ale kde sehnat lidi do projektu co v QT/Java umi delat.

S C# bych souhlasil. Javu nechci odsuzovat. C/C++ bych rozhodně "nezakopával". ;-)

Jediny duvod, proc je dobre zakopat C/C++ je prave tenhle uzasne nesmyslny pojem, ktery implikuje, ze ty jazyky snad maji neco spolecneho.

Ale maji. Dlouhou dobu bylo C++ implementovano jako preprocesor k C.

No to prave neni az tak uplne pravda. On ten cfront neni zrovna to co si clovek predstavi pod pojmem preprocesor, to C na vystupu to generuje vicemene odznova. Nicmene o to tu nejde.

Jde o to, ze C je takovy kapotovany assembler, kde clovek muze celkem dobre odhadovat efektivitu vysledneho kodu ze zdrojaku (malokdy kompilator vygeneruje z nevinne vypadajici operace nejakou monstrozitu), zaroven je dostatecne abstraktni na to, aby bylo mozne v C psat celkem obrovske, a typicky dokonce objektove orientovane, systemy (Gtk, kernel, Apache, PostgreSQL...). C++ tuhle vlastnost proste nema a to ze ten jazyk je obludne komplikovany a dost casto prekvapivy v programovani (a i nasazeni) prilis nepomaha.

Jinak zrovna Qt je u tohohle docela pekna ukazka, protoze neodpovida takovete moderni predstave o programovani v C++ (coz je spolecna vlastnost vetsiny vicemene komercne vyvijenych knihoven v C++), protoze to proste neni u knihovny takovehoto typu rozumne udrzitelne (prilis rozsahle hlavickove soubory, nestabilni ABI...).

Ja proti C nic nenamitam. Je to nizkourovnovy jazyk, vhodny pro psani knihoven, driveru, operacnich systemu a ehm Java runtime. V Jave primo nesnasim JNI.

Delal jsem na hodne velkych projektech v Jave (rozpakovane zdrojaky asi 0,5GB) a strednich C++ (asi 500 trid). V C++ bylo neskutecne bugu, ony ty featury jazyka jako pretypovani ktere se nekontroluje run-time si o to primo rikaji.