Здравствуйте, WolfHound, Вы писали:

Q>>Мода на этом сайте есть пугать какой-то страшной спецификой проектов. Гапертон меня пугал, теперь вы. Не расскажете, что такого ужасного в этой специфике, что ее нельзя изучить так же быстро, как и стандартные линуксовские библиотечки?
WH>Старый активно развивающийся проект это огромная гора кода причем никто даже те кто в нем с самого начала не знают как именно она работает.
WH>По сравнению с этим насквозь стандартизированные стандартные и со всех стором обсосанные библиотечки просто ничто.

Вот и отлично. У вас одни проблемы, у других — другие. Для вас знания linux не критичны, вы и в названии вакансии о linux небось не пишите. Но если другие об этом пишут значит именно это и надо.
Может хватит "прикладывать свой аршинчик" ко всему и ко всем?

Здравствуйте, kaa.python, Вы писали:

KP>Возможно я такой извращенец, но последнее время в процессе осваивания Emacs-а мне нравится им пользоваться все больше и больше. Как под Linux, так и под Windows.
KP>Есть все что необходимо для комфортной работы.

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

Здравствуйте, DerBober, Вы писали:

DB>Вот и отлично. У вас одни проблемы, у других — другие. Для вас знания linux не критичны, вы и в названии вакансии о linux небось не пишите. Но если другие об этом пишут значит именно это и надо.
Если в вакансии написано линукс то это значит что разработка будет под линукс.
И больше ничего.
А разобраться с линухом не сложенне чем с любой другой библиотечкой. Особенно при наличии общих знаний.
Ибо с точки зрения изучения нет никакой разници между функциями библиоткеки и функциями ОС.
Это я тебе говорю как человек который пришол с винды и сходу начал писать линуховые кластерные решения.
Проблем было много и разных но ни одна из них не была связана с не знанием API линуха.

И уж точно небыло никаких проблем с освоением коммандной строки.
Это при том что до этого линух я видел пару раз у знакомх на компе.

Здравствуйте, machine3000, Вы писали:

M>Такие интерфейсы хороши для повседневной работы узкоспециализированного профессионала. Только навыки работы с ними долго приобретать и легко утратить, если какое-то время не пользоваться. Интерфейс с человеческим лицом должен быть понятен любому, кто видит его хоть впервые, если он знает соответствующую предметную область.

Лично мне не важно, понятен ли интерфейс любому, кто видит его в первые. Важно понятен ли он мне и насколько удобен в использовании. На данный момент, возможности которые предоставляет Emacs превосходят возможности VS и мне этого достаточно для выбора редактора кода. Хотя сам начинал с VS и тоже был очень доволен предоставляемыми возможностями редактирования. Только вот постепенно изобили окон стало раздражать, лазить за мышкой стало лень, а настроить все полностью на клавиатуру в студии довольно проблематично.

Здравствуйте, AndrewJD, Вы писали:

Q>>Каждый из блоков достаточно легко изучить, в отличие от монолитной монстроидальной MFC.
AJD>Оффтопик.
AJD>Между прочим MFC будет менее монолитной и монстроидальной чем тот же Qt. Но на Qt, почему-то, никто не наезжает.

Ты знаешь Qt по сравнению с MFC, это верх искусства дизайна. Монстроуозной ее никак не назовешь.

Здравствуйте, Quintanar, Вы писали:

A>>(Мне просто в свое время показалось изучить unix сильно проще чем MFC, которую я так до конца и не осилил вкурить)

Q>Извини за глупый и бестактный вопрос: но ты под Unix писал когда-нибудь?
Да писал. Уже 2.5 года не пишу под винду. У меня даже на рабочей станции Linux стоит, притом что VS мне нравится до сих пор.
Твоя очередь отвечать на бестактный вопрос.

Q>Если да, то в чем смысл сравнения Unix и MFC? Может не будем сравнивать паровоз и карданный вал.
Это 2 технологии — требующие одинакового подхода в изучении. Просто одна из них чуть проще(unix)

Q>Если же по существу, то в Unix традиционно приветствуется подход имплементации сложных структур из простых блоков. Каждый из блоков достаточно легко изучить, в отличие от монолитной монстроидальной MFC.

Это к чему сказано? И как это подтверждает или опровергает тезисы выше по стеку?

Здравствуйте, Anatolix, Вы писали:

A>Ты знаешь Qt по сравнению с MFC, это верх искусства дизайна. Монстроуозной ее никак не назовешь.

Ntv не менее принцип один и тот же . Мегаклас_как_базовый + куча макросов на оброботчики. Хотя безусловно, дизайн Qt будет гораздо получше.

Здравствуйте, WolfHound, Вы писали:

DB>>Вот и отлично. У вас одни проблемы, у других — другие. Для вас знания linux не критичны, вы и в названии вакансии о linux небось не пишите. Но если другие об этом пишут значит именно это и надо.
WH>Если в вакансии написано линукс то это значит что разработка будет под линукс.
WH>И больше ничего.

А если написано С++ то это означает что разработка на С++ и больше ничего?

WH>А разобраться с линухом не сложенне чем с любой другой библиотечкой. Особенно при наличии общих знаний. WH>Ибо с точки зрения изучения нет никакой разници между функциями библиоткеки и функциями ОС.

WH>Это я тебе говорю как человек который пришол с винды и сходу начал писать линуховые кластерные решения.
WH>Проблем было много и разных но ни одна из них не была связана с не знанием API линуха.

Хм.. Что такое API Линуха?

WH>И уж точно небыло никаких проблем с освоением коммандной строки.
WH>Это при том что до этого линух я видел пару раз у знакомх на компе.

Знаем мы таких перебежцев.

Здравствуйте, landerhigh, Вы писали:

L>>>У меня меню Ассиста вылезает. Ку?
C>>Странный у тебя Ассист.
L>С официального сайта, между прочим.
Какой версии?

C>>Проблема в том, что я уже очень долго ищу нормальную среду для разработки под Линукс. Так ничего нормального и не нашел.
L>Под винду тоже из не густо, по большому счету.
C>>"Традиционные" решения вроде ViMа и Emacs'а — вообще идут лесом. В них даже нормальной интеграции с отладчиком нет.
L>
L>Есть. Только зачем?
НЕТУ, нету нормальных. ViM и Emacs предоставляют "замечательную" интеграцию с командным окном GDB. Спасибо, блин, называется.

Тольк в ViM 7 появилась возможность ставить отметки брекпоинтов в gutter-зоне. Этим сейчас пользуется только один интегратор Clewn. А он жутко глючный, да еще и не работает в Windows.

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

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

C>>Я вот в Студии пишу ядерные модули для Линукса и системный софт (компилирую через SSH, проект монтирую с помощью SMB). VAssist прекрасно понимает системные заголовки Linux'а и делает нормальный autocomplete.
L>Интересно, господин хороший, а какой такой отладчик Вы умудрились интегрировать со студией, да так, что можете аж ядерные линуксовые модули отлаживать.. из-под винды-то?
Одно время использовал BVRDE — вообще замечательная IDE для удаленной компиляции. Сейчас испльзую, в основном, отладочную печать, что жутко меня бесит.

L>Я правильно понимаю, что у тебя такая схема — проект сидит на целиком на линух боксе, но исходники ты редактируешь по сети(!) с виндовой машины (!) через самбу (!),
Да.

L>а для компиляции у тебя открыт шелл (впрочем, это можно прикрутить к студии)?
Да, прикручено к студии — запускается через plink из Putty.

L>Ну и где тут "интеграция с отладчиком"? Ты используешь студию исключительно как редактор кода, причем далеко не самый лучший. Это даже не "стоя и в гамаке", это какой-то гораздо более экзотический случай.
Так в том-то и дело, что этот гамак оказывается быстрее рукопашной с ViM'ом.

L>You've made my night
Всегда рад помочь.

L>Хочешь совет? Два-пять дней, инвестированных в изучение родного для линукса редактора кода окупаются очень быстро. Шпаргалок в интернете полно, да и команд там не так много, зато экономия времени впоследствии просто ошеломительная.
ДВА-ПЯТЬ ДНЕЙ?? Ты смеешься?

Я месяц потратил на изучение Линуксовых инструментов. В ходе изучения отослал патчи в Code::Blocks, ECB, distcc и еще пару проектов, и пересмотрел с десяток IDE. В ViM я заныривал в исходники в поисках нужных мне фич (ну ПОЧЕМУ там нельзя сделать свой popup-диалог как для completion'а???), в Emacs — можешь посмотреть тему "XEmacs — помойка".

Здравствуйте, kaa.python, Вы писали:

C>>Проблема в том, что я уже очень долго ищу нормальную среду для разработки под Линукс. Так ничего нормального и не нашел.
C>>"Традиционные" решения вроде ViMа и Emacs'а — вообще идут лесом. В них даже нормальной интеграции с отладчиком нет.
KP>Возможно я такой извращенец, но последнее время в процессе осваивания Emacs-а мне нравится им пользоваться все больше и больше. Как под Linux, так и под Windows.
KP>Есть все что необходимо для комфортной работы.
Поработай c IDEA/Eclipse для Java — чтобы понять КАКОЙ должна быть настоящая IDE. Потом посмотри VAssist+MSVS в качестве бледного приближения к настоящей IDE. Потом посмотри на Emacs/ViM.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, mr_jek, Вы писали:

C>>>"Традиционные" решения вроде ViMа и Emacs'а — вообще идут лесом. В них даже нормальной интеграции с отладчиком нет.
_>>Эээ, а Tools->Debuger, там тебе и breakpoints и step into, step over и т.д.,
_>>по-моему это лет 5 как есть.
C>Кааааакой, блин, Tools->Debugger в ViMе???? Там есть глючащий http://clewn.sourceforge.net/ , который еще и под Windows не работает.

Вообще-то имелся ввиду естественно emacs, у классического vim, стандартного меню.

C>Для EMacs'а есть аналогичные глюкоделки.

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

Здравствуйте, mr_jek, Вы писали:

C>>Кааааакой, блин, Tools->Debugger в ViMе???? Там есть глючащий http://clewn.sourceforge.net/ , который еще и под Windows не работает.
_>Вообще-то имелся ввиду естественно emacs, у классического vim, стандартного меню.
А, ну так это не нормальная интеграция с отладчиком, а просто запуск консоли GDB.

C>>Для EMacs'а есть аналогичные глюкоделки.
_>По крайней мере для взаимодействия с дебагером нету, т.к. есть работающее из коробки.
Нетути. Есть http://www.inet.net.nz/~nickrob/ , который приближается уже к работающей версии. Но у меня он с С++ глючит.

AZ>>Профессионалы пишут код при помощи головы. Пацаны типа machine3000 — при помощи Visual Studio.
AJD>Если Visual Studio позволяет писать код только при помощи конечностей и без участия головы — то M$ создало просто гениальную супер-софтину.

Сколько win32 программеров могут объяснить процесс линковки? Один знакомый мне знакомый впал в глубокий ступор, когда проект отказался линковать либы с приложеним — простейщий вопрос типа unresolved symbol или неправильный тип библиотеки — и все... приплыли

AZ>>Без автокомплита жить можно, и даже без подсветки синтаксиса, а вот без головы совсем хреново, приходится рассчитывать на помощь IDE
AJD>Т.е. те кто пользуются IDE это люди у которых "совсем хреново"(с) с головой?

Нет. Совсем хреново с головой у того, кто не может собрать проект без IDE

УЁ>В корень не согласен с позицией. IDE позволяет не думать о порядке параметров и именах методов\переменных, не отвлекаться на добавление импортов, не искать в каком же там файле живет тот или иной класс\метод, не считать количество открывающихся и закрывающих скобок, не заниматься распознаванием образов в криво оформленном коде, а так же не делать много чего другого, что к программированию как таковому не относится, и сфокусироваться на решении проблемы. IDE это инструмент, и никаким образом не претендует на заменитель головы.

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

Я не против IDЕ, но если программер неможет собрать "Hello, world" с командной строки, то в линуксе ему делать нечего

Здравствуйте, AntZ, Вы писали:

AZ>Сколько win32 программеров могут объяснить процесс линковки? Один знакомый мне знакомый впал в глубокий ступор, когда проект отказался линковать либы с приложеним — простейщий вопрос типа unresolved symbol или неправильный тип библиотеки — и все... приплыли
Я думаю большинство программеров которые работают с С++. VB/C#'щиков такие вещи не волнуют .

AZ>Нет. Совсем хреново с головой у того, кто не может собрать проект без IDE
А нафиг оно надо большинству, а особенно тем кто не занимается кросс-платформенной разработкой? Чем описание процесса сборки с помощью make лучше чем описание файла в проекте?

Здравствуйте, AntZ, Вы писали:

УЁ>>В корень не согласен с позицией. IDE позволяет не думать о порядке параметров и именах методов\переменных, не отвлекаться на добавление импортов, не искать в каком же там файле живет тот или иной класс\метод, не считать количество открывающихся и закрывающих скобок, не заниматься распознаванием образов в криво оформленном коде, а так же не делать много чего другого, что к программированию как таковому не относится, и сфокусироваться на решении проблемы. IDE это инструмент, и никаким образом не претендует на заменитель головы.

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

Не стимулирование, а средство выживание. В проекте в котором я работаю, к коду приложило руку несколько десятков человек , из России, Штатов, Индии и даже Бразилии. Стоит ли говорить о качестве кода? А жить как то надо.

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

AZ>Я не против IDЕ, но если программер неможет собрать "Hello, world" с командной строки, то в линуксе ему делать нечего

С этим никто не спорит. Каждый программист должен начинать проект со скрипта автоматической сборки (не важно в какой OS), но это не означает что кто то в здравом уме будет (или должен уметь) работать без IDE.

Здравствуйте, AntZ, Вы писали:

AZ>Почти все упомянутое — стимулирование плохого стиля программирования.
Спорно. Сбрасывая некоторые организационные моменты на среду — ты освобождаешь время в том числе и на улучшение стиля программирования. Хотя по сути — как показывает опыт — стиль зависит ИСКЛЮЧИТЕЛЬНО от культуры программиста.

AZ>если по имени класса я не могу определить файл где он лежит — то дизайн дерьмо,
Тоже спорно. В проектах тысячи, даже десятки тысяч файлов. Всегда лично определять, где лежит файл — непроизводительная трата времени, т.е. по сути это бесполезное знание. Я считаю, что условие конечно должно выполнятся, но это скорее красивая презентативная фенечка, без серьезного практического применения.

AZ>если я вынужден использовать тул который считает скобки — значит выражение переусложнено,
Вообще-то это нарушение ООП или стандарта кодирования. Это так же не относится к IDE.

AZ>криво оформленный код — проблема скорее организационная
Ну да, это лишнее пятно на карме программиста

AZ>Я не против IDЕ, но если программер неможет собрать "Hello, world" с командной строки, то в линуксе ему делать нечего
ИМХО, это тоже самое, что сказать — если программер неспособен набить на асме "Hello, world" то в программировании ему делать нечего

Здравствуйте, NikeByNike, Вы писали:

NBN>Здравствуйте, landerhigh, Вы писали:

L>>А кроме инклюдов?
L>>Вот батничек там написать или еще чего...

NBN>Хм, я помню один случай за последний год когда писал батник... Зачем они сейчас нужны?
И правда, зачем нужны командные файлы/скрипты, когда всегда есть юзер?

Здравствуйте, landerhigh, Вы писали:

NBN>>Хм, я помню один случай за последний год когда писал батник... Зачем они сейчас нужны?
L>И правда, зачем нужны командные файлы/скрипты, когда всегда есть юзер?

Ну вот я месяц назад настраивал автоматическую сборку проекта (инсталяхи под несколько платформ, 10 языков и прочие радости жизни). Единственный батник — отчищает папку, берёт всё из svn и запускает билд. Порядка 7 примитивных строк.

На время отладки — работают Build Events и иже с ними.

Здравствуйте, Cyberax, Вы писали:

L>>С официального сайта, между прочим.
C>Какой версии?
Самой последней.
L>>Есть. Только зачем?
C>НЕТУ, нету нормальных. ViM и Emacs предоставляют "замечательную" интеграцию с командным окном GDB. Спасибо, блин, называется.
Не вижу проблемы. Или Вы без ГУЯ и шагу уже ступить не можете?

C>>>Я вот в Студии пишу ядерные модули для Линукса и системный софт (компилирую через SSH, проект монтирую с помощью SMB). VAssist прекрасно понимает системные заголовки Linux'а и делает нормальный autocomplete.
Вы, кстати, автокомплит в виме видели вообще?
L>>Интересно, господин хороший, а какой такой отладчик Вы умудрились интегрировать со студией, да так, что можете аж ядерные линуксовые модули отлаживать.. из-под винды-то?
C>Одно время использовал BVRDE — вообще замечательная IDE для удаленной компиляции. Сейчас испльзую, в основном, отладочную печать, что жутко меня бесит.

L>>Я правильно понимаю, что у тебя такая схема — проект сидит на целиком на линух боксе, но исходники ты редактируешь по сети(!) с виндовой машины (!) через самбу (!),
C>Да.
L>>Ну и где тут "интеграция с отладчиком"? Ты используешь студию исключительно как редактор кода, причем далеко не самый лучший. Это даже не "стоя и в гамаке", это какой-то гораздо более экзотический случай.
C>Так в том-то и дело, что этот гамак оказывается быстрее рукопашной с ViM'ом.
Отладчик-то где, я так и не понял? Меня убеждать не надо, какой редактор "быстрее", я всех устриц ел. Живих тоже, они, кстати, вкуснее.
L>>You've made my night
C>Всегда рад помочь.

L>>Хочешь совет? Два-пять дней, инвестированных в изучение родного для линукса редактора кода окупаются очень быстро. Шпаргалок в интернете полно, да и команд там не так много, зато экономия времени впоследствии просто ошеломительная.
C>ДВА-ПЯТЬ ДНЕЙ?? Ты смеешься?
А чего там изучать? гугль.ком — Шпаргалка по vim. Там две-три страницы наиболее используемых команд. Или это слишком сложно/долго для программиста? (Вспоминаются где-то подслушанные слова "нам некогда юнит тесты писать, кодить надо" )
C>Я месяц потратил на изучение Линуксовых инструментов. В ходе изучения отослал патчи в Code::Blocks, ECB, distcc и еще пару проектов, и пересмотрел с десяток IDE. В ViM я заныривал в исходники в поисках нужных мне фич (ну ПОЧЕМУ там нельзя сделать свой popup-диалог как для completion'а???), в Emacs — можешь посмотреть тему "XEmacs — помойка".
Э, нет. Вы не Вим изучали, а пытались сделать из него студию. Почувствуйте разницу, как говорится.
Более того, если десяток команд редактора Вам за месяц ниасилить, то как, позвольте спросить, Вы умудряетесь ядерные модули писать?