17.10.2012 00:27, Sciko Good пишет: > 16 октября 2012 г., 18:56 пользователь "Артём Н." <[email protected]> > написал: >> 16.10.2012 00:51, Sciko Good пишет: >>> Я пишу в основном расчётные консольные приложения, а когда к ним нужна >>> графическая морда, использую GTK, т.к. считаю Qt фактически является >>> одной большой библиотекой, да и последние тенденции к превращению её >>> во фрейморк для JavaScript не радуют. >> Не слежу. Не знаю. В смысле? > Посмотрите на последние версии Qt -- там интерфейс пишется на > JavaScript, а создание интерфейса с помощью С++ уже помечено как > устаревшее. Nokia писала, что в Qt5 вообще интерфейс будет писаться > только на JavaScript. Разве это плохо? При наличии вменяемого движка JS, конечно? На их месте, мне кажется, я бы тоже к этому пришёл: хочу скриптовый интерфейс и маленький настраиваемый "движок", выполняющий основные функции.
>>> Code::Blocks вообще ужасен. >> Вот здесь возможно сильно подробнее? > Текстовый редактор на уровне блокнота, нет интеграции с DVCS, make не > создаёт, а каждый раз собирает проект сама, нет поддержки других > языков кроме C++. Разве уже это не повод не использовать эту поделку? О, увидел после того, как ответил. :-) Спасибо. А вы про какую версию? Я почитал, она была описана, как весьма перспективная среда. И редактор там со всеми подсветками и прочими плюшками. Да, если нет поддержки ничего другого, кроме C++, - не вариант. Но, может, есть плагины? >>> Netbeans требует таких плясок с бубуном, что убивает >>> всё желение с ним работать. >> Что там не так? > Чтобы что-то там заработало, надо настраивать всю среду. Причём долго > и весьма неочевидными способами. > >>> Eclipse страшно тормозит. Именно после него я поверил, что Java тормозит. >> Серьёзно? Eclipse, вроде бы, не на Java написан? И не исключительно для Java? > А почему у неё сырцы сплошь джавовские? Не читал. Понятно. >> Где тормозит? На какой системе? > Debian, Ubuntu, AltLinux, Fedora, CentOS, Mandriva, Rosa, openSUSE, > SLE -- тормозит везде. В других на пробовал. В смысле, на какой машине? Какие характеристики железа? >>> Lazarus представляет из себя копию Delphi со всеми его минусами. >> И плюсами. > Фактически единственный сомнительный "плюс" Dephi -- его преподают в > школах и вузах. Там действительно простое "написание кода от интерфейса". RAD. >>> А их хватает, ведь не зря Dephi называют принцем быдлокодерских IDE. >> Штамп. RAD и "разработка от интерфейса" позволяют быстро наклепать прототип. > Вот именно это и является штампом .Быстро наклепать прототип позволяет > python, perl, lisp, haskell и т.п., но не Dephi, т.к. изначально > паскаль разрабатывался вовсе не для быстрой разработки и не содержит > даже банального синтаксического сахара. Так Delphi - не Pascal. Там сахара хватает. > Быстро нарисовать интерфейс > позволяют такие программы как Glade, причём без какой-либо привязки к > языку. Кросс? Но Glade - только GTK... >> Причём, в виде скомпилированной программы. Это делает низким порог вхождения. > У интерпретируемых языков порог вхождения ещё ниже. Зависит от языка. > И не надо тратить время на компиляцию. Зато, не повышается ЧСВ, пишущего. :-) >> И среднее качество кода, считается, гораздо ниже, чем у MSVS (которая >> считается >> "сложной в освоении"). > Кстати, королём быдлокодерских IDE называют именно MSVS ^_^ Вы недавно про Delphi говорили тоже самое. Определитесь. ;-) Хотя, с появлением C#, акценты наверняка сместились... >>> В данном случае я хочу >>> оптимизировать работу там, где вижу возможность оптимизации. Смена >>> редактора кода реально мне может помочь в плане производительности. >> Понятно. >> Но, например, взять Embarcadero RAD Studio (ранее Borland C-Builder). >> Переключиться между cpp и h я могу через Ctrl+F6. >> А в vim? > А в vim ставите скрипт a.vim и получаете этот функционал. Можно > привесить на любое сочетание клавиш. Честно говоря, не очень въезжаю, как это сделать, в общем случае (когда .c и .h могут иметь разные названия), не прибегая к сложному разбору текста. >> Как оно вообще используется и где, >> Что там под windows? > Рисуешь интерфейс в редакторе, подключаешь в коде библиотеку, > описываешь какой сигнал связать с вызовом какой функции, отрисовываешь > окно. Плюс в RAD - обработчик проще найти. >> Жаль, скриншотов под Linux нет. > Запустите Synaptic. Он тоже использует Glade. Ну, типичный GTK интерфейс. Честно говоря, GTK меня раздражает. > 16 октября 2012 г., 19:11 пользователь "Артём Н." <[email protected]> > написал: >> 16.10.2012 18:41, Sciko Good пишет: >>> Вы отстали от жизни. Даже на вантузе сейчас используется как минимум >>> C++, Pascal/Delphi и C#. >> Pascal/Delphi - уже давно. На нём не так много всего имеется, по сравнению с >> C++. > Вы удивитесь, как много на нём всего понаписали и продолжают писать. Не удивлюсь. Знаю, что пишут. >> C# - вообще не имеет отношения к ОС, как правило (на нём пишут для .NET, а >> спрашивать про его поддержку какими-либо средами, думаю не стоит). > .NET использует фактически один вантуз. В остальных ОС с ним будут > весьма большие проблемы. И в GNU/Linux его не любят. Почему? Читайте > RMS. Да и меня как-то не радует .NET. Почему один Windows? А Mono - это не то? >>>>> А тратить >>>>> время на вылавливание ошибок при работе с указателями/памятью на c++ - на >>>>> это >>>>> времени нет. >>>> На C++? Вы не путаете с C? Кажется, в C++ дела обстоят намного лучше. >>> Неужели в c++11 добавили автоматические управление памятью? Каюсь, не >>> нашёл. По крайней мере сборки мусора там нет точно. >> Зато есть библиотеки с "умными" указателями, коллекциями и прочим. > Как будто такого нет в C! В той же glib есть и более интересные вещи. Например (именно в glibc)? Причём, ещё и кросс? > Вот только от ручного управления памятью это не освобождает. Я про то же. >> И классы, в >> которых очистку возможно произвести в деструкторе. > Гладко было на бумаге, но забыли про овраги... Именно такие классы и > порождают массу самых весёлых сегфолдов. По крайней мере, место возникновения ошибки локализуется (в идеале). > Программист под GNU/Linux будет переписывать на C только критически > важные по скорости участки кода. Остальные он сделает на каком-нибудь > другом языке, где есть автоматическое управление памятью. Даже на > таком тормозе как Python, если это будет удобнее. Например, прототип > Perl6 был написан на Haskell, потому что он лучше всего подходил под > эти задачи. А вантузные программисты почему-то пытаются всё сделать на > 1 языке. Может проблема действительно в узком кругозоре? А лень? :-) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
