Управление геометрией виджетов в PyGTK

Если такой умный - предложи новый язык, с автоматическим управлением памятью и такой же производительностью приложений, как у C/C++. Java/C# не вариант - слишком уж тяжеловесные и тормознутые.

>и на упоминание Mono сразу разражаются воплями "C/C++ не нужен!

все как раз наоборот, при упоминании mono разраражаются воплями mono не нужен. Про C/C++ никто ничего и не говорит.

>Такие убогие инструменты для "быстрой" разработки популярны только среди недопрограммистов ака кодеманкейс.

Если нашел работу, где требуется разработка нижнего уровня с ограниченными ресурсами, то считай, что тебе повезло, не лезь в mono, java, .NET (нужное подчеркнуть). Если нет, то взгляни на реальное положение дел и пойми, что СКОРОСТЬ разработки для 95% проектов является решающим фактором. Соответственно и "недо"программисты, владеющие "быстрым гомном" востребованы. Кушать всем хочется, поэтому надо владеть тем, что востребовано. А обосрать технологию все мастера.

хочешь сказать, что в mono, java, .NET самая быстрая разработка?

>Если такой умный - предложи новый язык, с автоматическим управлением памятью и такой же производительностью приложений, как у C/C++. Java/C# не вариант - слишком уж тяжеловесные и тормознутые.

сколько раз уже здесь обсуждали D... Потом OCaml еще, но он функциональный и впечатления людей о нем различаются.

одна из самых быстрых. и это понятно когда столько вещей за тебя делает среда. проще(=быстрее) поддерживать кроссплатформенность а в случае .NET еще есть VS Studio которая тоже направлена на ускорение процесса разработки.

> предложи новый язык, с автоматическим управлением памятью и такой же производительностью приложений, как у C/C++.

D и Ocaml уже предложили. Есть очень быстрые реализации LISP.

> Java/C# не вариант - слишком уж тяжеловесные и тормознутые.

А тут, как раз, зависит больше от того, как написано. Например, сравни скорость работы Subversion, всего из себя на православном С написанного и Mercurial, написанном на тормознутом, даже по сравнению с жабонетами Python. Кстати, создатели жабореализаци питон утверждают, что их реализация быстрее нативной. Правда я этого не заметил, но на определенных операциях - вполне может такое и быть.

>А тут, как раз, зависит больше от того, как написано

вот согласен. Инструментом надо в первую очередь научится владеть. Тормознутость программы в первую очередь зависит от кривизны рук, и чем она > , тем медлительнее и глючнее будет программа написаная на C/C++.

Сколько уже можно спорить. <К.О.> Скорость разработки зависит не от синтаксиса языка, потому что большую часть кода ты не пишешь - она должна быть уже написана. Так вот, в джаве я пишу меньше не потому что язык хороший(синтаксиески он слегка отвратен), а потому что уже куча библиотек и фреймворков написано. ну нету ничего подобного Eclipse RCP. И не случайно. Потому что повторная используемость в джаве-дотнете выше чем у с, с++. и D. </К.О.>

>вообще хотелось бы статью типа "пишем простое Qt приложение с GUI" с обработчиками кнопок и прочая...

Не дельфи. Всё равно надо осиливать наследование и сигнало-слоты. Правда в принципе там нефиг осиливать.

>Эдуард, я замкадыш, к нам такие не возят, это в Default city надо ехать..

Первые две точно есть в электронке, нормально отсканеные. Не кошерно, но если сильно нужно, то всегда можно.

>ага, как напимер, в куте3 сделать listviewitem с несколькими чекбоксами, или как сделать их черезстрочную подсветку.

ППЦ. Не помню. И как в qt2 было тоже не скажу.

>я конешно это сделал давно, и мне не интересно, но, дивись: в гтк это работает искаропки. да. как и мегакрутые listitems с безпредельными возможностями отображения. посортировать по порядку столбец с цыферками слабо? а в гтк - искаропки. ибо, в гтк грамотный подход. а в куте - как будто всё прилепили второпях.

Тупо троллинг же. Вам самому не противно?

>Скорость разработки зависит не от синтаксиса языка, потому что большую часть кода ты не пишешь - она должна быть уже написана. Так вот, в джаве я пишу меньше не потому что язык хороший(синтаксиески он слегка отвратен), а потому что уже куча библиотек и фреймворков написано. ну нету ничего подобного Eclipse RCP. И не случайно. Потому что повторная используемость в джаве-дотнете выше чем у с, с++. и D.

Вот что верно, то верно. Но как-то однобоко вы вывод делаете. Потому что для C/C++ как раз этих библиотек и фреймворков дофига и больше. Фактически тоже почти на все случаи жизни. Ну может не хватает унификации и централизации чтоли, чтобы искаропки всё и сразу. А так-то есть всё.

Кстати Qt тому хороший пример. Фреймворк с умеренно громадным функционалом искаропки.

Да. Под с++ дофига библиотек. Только все они разношерстые от принципов кодирования и именования до использования каждой библиотекой своих строк и контейнеров. И это дико раздражает. И в Стл- стандартной библиотеке все построенно намертво. Попробуте сделать поток который бы читал из сокетов. Это абзац. А в джаве и дотнете это нахаляву.

Будут ширпотребные приложения на D и OCaml - будет о чём говорить. Пока я ничего не могу сказать об их производительности.

Вполне возможно. Но пока мои глаза говорят мне, что те несколько десктопных приложений, написанных на Java/C#, которые я пробовал использовать - тормозят жутко. Пробовал пользовать я следующее:
Azureus(java)
Eclipse(java)
NetBeans(java)
Beagle(mono)

Я не знаю, как они там написаны - кривыми руками или нет. Но тормозят и жрут память.