Re: Среды разработки

["Артём Н." <artiom14@yandex.ru>]

17.10.2012 00:27, Sciko Good пишет:
> 16 октября 2012 г., 18:56 пользователь "Артём Н." <artiom14@yandex.ru> написал:
>> 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 пользователь "Артём Н." <artiom14@yandex.ru> написал:
>> 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 языке. Может проблема действительно в узком кругозоре?
А лень? :-)