Как в этой "эффективнейшей среде разработке" осуществляется навигация по коду? Через утилиты find-grep, которые ничего не знают про семантику языка и ищут тупо текст? Как в консольном gdb удобно и быстро просматривать сложные вложенные структуры данных при отладке?

Чаще да. cgdb имеет смысл в ситуации, когда есть только одна консоль (и нет screen/tmux).

Добавлено через 2 минуты и 28 секунд

А нормальные редакторы уже запретили? 


Хм... а в чем проблема?

Демографический кризис в стране, а программирование область, где не получиться чтобы думали за тебя, а таких в низко конкурентной среде ещё меньше, вот так и живем

Это сообщение отредактировал(а) krundetz - 6.5.2013, 15:47

Думать надо там, где это действительно необходимо! Зачем создавать проблемы самому, когда можно один раз решить и больше не возвращаться к ним или просто тупо жать кнопки, а сэкономленное время потратить с пользой к примеру на решение других важных задач.

Возьму пример из моего небольшого опыта использования FreeBSD: Поставил себе где-то 1.5 года назад FreeBSD Release 9.1 amd64 . Поставил ничего лично ни мир ни ядро не пересобирал и программы ставил из пакетов. Вдруг захотел посмотреть фильм, оказалось VLC не содержит нужного кодека. Посмотрел на последнюю версию прекомпилированного пакета.  Но мне все-таки пришлось сконфигурировать порт с нужным кодеком, чтобы потом скомпилировать из исходников. Процесс просмотра фильма был отложен на 40 мин. Тот же самый windows на который многие Linux-оиды ругаются решает проблему просто: 1) скачать инсталятор кодека 2) установка  и все это не больше 10 мин.

Меня реально пугает то что в Open-Source обычные тривиальные вещи иногда приходится ждать в лучшем случае десятки минут. А бывают тяжелые случаи, когда много зависимостей требуют обновления!

Пока увидел только один серьезный аргумент в пользу Linux: десятилетиями отшлифованный API.

А слова "там в *Nix-система ком. строка рулит", так сейчас PowerShell в Windows столько может что просто загляденье!

Ну так FreeBSD в этом отношении - другая крайность. Причем, кстати, это и не Linux. 

Но, кстати, это тоже некоторое преимущество (хотя в основном и не для программирования) - можно подобрать дистрибутив по потребностям. Одно дело - разворачивать сервер, другое - домашную машину, на которой надо смотреть фильмы, но для каждого из этих вариантов есть готовые решения. 


Да, но есть пара неприятных моментов. Во-первых, возможности PowerShell даже сейчас не дотягивают до того, что можно получить из bash и пачки скриптовых языков. Во-вторых, он штатно появился в 2006 году, это уже третий язык такого рода в семействе DOS/Windows, и нет никакой гарантии того, что потом не появится четвертый.

Это сообщение отредактировал(а) Фантом - 6.5.2013, 17:07

Благодаря этой крайности я понял как надо организовывать и проектировать интерфейс консольных программ. 
Но это не означает,что я такой же подход не могу использовать в Windows-приложениях.


Ну .Net уже достаточно давно существует, более-того шагнула в Linux-мир. Так что говорить о том что Power-shell загнется не имеет смысла. Задачи надо решать сейчас, значит надо решать так чтобы решение было сопровождаемым и решало задачу полностью. Этот Power-Shell позволяет оочень многое сделать, в отличии от bat-аники )

Согласись, что в линупсах оно в любом случае делается быстрее - все уже собрано и аккуратно разложено по каталогам, тот же boost. Естественно в будущем наверняка потребуется пересобрать это с другими флагами/опциями/версиями, поэтому и писал, что в рамках крупного проекта это все сомнительное преимущество, но для тренировки на кошках на пути к вышеупомянутому "среднеуровневому" C++ программисту - самое то.

А студия ставится явно не в полтора клика и не одну перезагрузку (если в системе не стоит нужной версии windows installer-а и .net framework-а). Ставил в прошлом году RC 12-ой - два раза минимум перезагружался.

Ну как сказать... у меня есть пример: комплект TeX'овских стилевиков вместе со скриптами, занимающимися и автоматизированной сборкой документов и их раскладкой/печатью/рассылкой. Сейчас еще раз проверил - все это делалось в 1998 году и работает до сих пор без каких-либо правок (кроме вносившихся расширений функционала). В том, что лет через 10-15 это все по-прежнему будет работать, я практически уверен. В том, что аналог на PowerShell через те же 10-15 лет будет где запускать... пожалуй, все же нет. Возможно, в дальнейшем все будет лучше, но пока у MS репутация по этой части скорее отрицательная.

Фантом, Итого: Формулируем второй плюс средство решения задачи написанное сейчас вероятно будет работать и через десять лет.

чем больше ты пишешь, тем более понятен твой уровень, ты похоже действительно не понимаешь, что твориться в мире юникса.. но я не об этом,

все кто высказывался здесь в пользу виндоуз определенно направлен на разработку прикладного софта, но я бы хотел напомнить, что не прикладным софтом единым живет информационная индустрия..

большинство софта, которым пользуется, не побоюсь этого слова, миллиарды человек, такого как СУБД, веб-сервера, файловые сервера, почтовые сервера, программное обеспечение мобильных устройств, коммутаторы, маршрутизаторы, не говоря о самом линуксе - все это было изначально написано юникс-программистами.. ну а программы из под виндоуз их срок жизни 5 лет не больше, они не портируются никуда.. под виндоуз, только игры писать красивые, да и то серверная часть все равно будет на линуксе, если это плейстейшн нетвок, или другая приличная сеть.. (я слышал, в майкрософте используют линукс на серверах   )

но все это не главное, в линуксе есть man - вот настоящая сила, только не говорите мне про powershell я его псевдоман видел, он убог, как и сам powershell с недоразвитым дополнением..

cgdb - легко заменяет любой графический отладчик

Фантом, а ведь ни тебе, ни мне не надо, чтобы оно работало через 15 лет ))

Добавлено через 2 минуты и 38 секунд
Или ты из этих пресловутых рыцарей без страха и упрёка?

Мне - надо. Да и 15 лет - не так много, самый старый код, с которым я сейчас имею дело, написан в 70-х годах прошлого века.   



В смысле?

TeX - это круто... топорно, предсказуемо, управляемо, легко смотреть историю правок...

Не то что этот ваш ворд, который, поиграв со стилями, можно уронить на 5 страницах текста... я в своё время изматерился на нём писать диплом, нашёл шаблоны и писал в latex.

Кнут молодчик вообще...

Добавлено @ 20:47
и кто так легко поверил, что WYSIWYG необходим (MS поспособствовала?)... Я готов сознательно жертвовать наглядностью в пользу других более важных мне фич.

...

Когда ворд сломал диплом одного из одногруппников, тот в истерику впал... хотя вроде один заголовок поправил, разъехался весь документ... ворд могёт (фигли, один из самых продвинутых продуктов копрорации).

Это сообщение отредактировал(а) Farmazon - 6.5.2013, 20:50

Какие, например, считаются нормальными? В emacs/vim я не видел удобной навигации (за исключением проприетарного расширения xrefactory для emacs, которое уже не поддерживается).


Расскажите как вы это делаете, я скорее всего чего-то не знаю, но также удобно смотреть в отладчике сложные вложенные структуры данных как в MSVC у меня не получается.

Они не обязательно должны быть консольными.  Можно же использовать всякие Code::Blocks, KDevelop, Eclipse... вплоть до банальной Geany.


gdb умеет работать со скриптами. Поэтому вытащить что угодно, превратив это в любой удобный для обработки вид очень легко.