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

VD>Какие наезды? Ты на вопрос то ответь.

Вопроса не было, был очередной переход на личность.

E>>Я веду к тому, что документацию по тем классам/методам, которые собираешься использовать, нужно смотреть до их использования.

VD>Ясно. То есть ты действительно никогда не пользовался нормальной IDE.
VD>Ну, вот ответь мне на вопрос. Зачем мне читать документацию на скажем метод Add в классе Dictionary<T>? Я и так прекрасно понимаю, что он делает. Но чтобы не лезть в документацию я и не узнавать, что он называется Add, а не скажем AppendNewElem я пишу "x." и жму Ctrl+Space. В результате выпадает список из которого я выбираю нужный метод. Далее я вбиваю "(" и появляется описание параметров. Из него я вижу, что первый параметр это ключ, а второй — это ассоциируемое с ним значение. Причем тут же, сразу за описанием метода и параметров, я вижу краткую справку по этому методу. И мне вообще не надо лезть в справку.

VD>Понятно?

Это все не серьезно. Методы вроде Add/AppendNewElem или std::map::insert элементарно усваиваются еще при знакомстве с языком/библиотекой. Если кому-то нужны всплывающие подсказки для работы с такими базовыми вещами, то я, пожалуй, лучше оставлю свое мнение невысказанным. Мне по работе приходится использовать что-то вроде ACE_Connector::connect, когда поверхностное знакомство с предметом во время написания кода ни к чему хорошему не приводит.

VladD2 wrote:
> R>Если речь про ViM или Emacs — то ctags уже явно прикручен, поэтому время
> R>равно времени нажатия Ctrl-] плюс времени на просмотр редактором
> R>сортированного списка на предмет наличия этого слова (типа или названия
> R>метода) плюс время на загрузку файла (буде он ещё не в памяти).
>
> И что это чудо умеет без ошибочно распознать любой исходник на С++
> (включая шаблоны и маросы) и верно перейти к нужному месту?
Не вполне уверен, так как не пользовался на сложном С++ (ну не узрел я
преимуществ писания на С++ по сравнению с Паскаль с кодогенерацией), но
по утверждениям на сайте, с макросами они борются всеми силами.

> Ой не верю я вообще в корректный парсинг С++-исходников. Но если это
Периодически слыша странные беседы про UB, я перестал верить в
корректный их разбор компилятором.

Впрочем, если собраться поставить mono, то я надеюсь

> так, то это уже и есть свойства IDE. Это уже не просто редактор. А хинты
Никто не утверждает, что vim не несёт функций, нужных, скорее, IDE.
Вопрос исходно был, что любую задачу легче решать в полноценных средах
разработки на нормальных языках, чем накидать строчку на shell.

А то, что REPL для shell и scheme, вставленный в редактор — это уже
движение в сторону IDE, я не отрицаю.

> с описанием типов это чудо показывать умеет? Ну, наводишь мышку на
> произвольный идентификатор в фале, а тебе хинт вылазит с полным
> описанием того что этот идентификатор представляет (ну, или хотя бы
> отдельное окошко).
Нет, не умеет. Впрочем, на маленьких проектах (я не отрицаю, что
возможности IDE критичны как раз на больших) я даже помню, где что
объявлено (а что помнить на размере 10К строк), так что на это я не
натыкаюсь.

Кстати, Delphi и Lazarus я пользовался довольно долго, с использованием
дополнения и навигации. Но как-то не чувствую себя обделённым без них.

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

EC>Здесь малость коряво вопрос сформулирован: имелось в виду что быстрее — воспользоваться grep'ом или написать программу на C#.
EC>Это понятно, если прочитать сообщения чуть выше по треду.

Вообще-то не ясно, зачем писать программу если нужно всего лишь что-то найти. Программы пишутся тогда когда надо что-то серьезно автоматизировать.
Лично я для себя строю выбор так. Сначала пользуюсь поиском в Студии или ТоталКомандере. Если этого мало, то записываю макрос в студии. Если и этого мало, то пишу программу. Но последнее уже обычно используется более одного раза и на это не страшно убить час другой.

EC>Кстати: твоё молчание в ответ на моё сообщение

Автор: EvilChild
Дата: 06.12.06

можно рассматривать как согласие с тем, что мой вариант оптимальние написания программы на C#?

А на что там отвечать? Ты воспользовался программой в которй фунцинальность уже реализована. В отевет я конечно могу привести тебе пример задачи уже решенной кем-то в библиотеке и не решаемый средствами шел-утилит. Но кому это интересно? Спор ради спора?

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

Вся моя мысль в этом и заключается. В корене не верно сравнивать мощьность и удоство на основе наличия некой библиотечной (назавем ее так) фунциональности.

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

E>Вопроса не было, был очередной переход на личность.

Вопрос был как раз четкий. Просто ты явно не хочешь на него отвечать.

Итак. Задаю его еще один, последний раж. Ты когда нибудь пользовался сорвеменной IDE (C# в VS 2005 или Java в IDEA)? Если, да, то сколько времени и каким количеством фич?

E>Это все не серьезно.

Агащазблин.

E> Методы вроде Add/AppendNewElem или std::map::insert элементарно усваиваются еще при знакомстве с языком/библиотекой.

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

E> Если кому-то нужны всплывающие подсказки для работы с такими базовыми вещами, то я, пожалуй, лучше оставлю свое мнение невысказанным.

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

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

VD>А на что там отвечать? Ты воспользовался программой в которй фунцинальность уже реализована.

Так в этом и была суть моего вопроса. Просто куча народа в том треде кинулась приводить код на C# для решения этой задачи.
То, что её можно на нём решить сомнений не вызывает. Вызывает сомнения целесообразность её решения этим способом.
Я там сразу оговорил, что это тривиальный пример, но при этом большинство предложенных вариантов были неправильные. На чуть более
сложном примере это было бы ещё очевиднее. Правда у людей хватило вменяемости, чтобы не настаивать дальше.

В общем я возражал, что статика во всех задачах даёт преимущество — думаю некоторых убедил.

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

E>Древнее, говоришь.
E>Вот я сделал только что svn export http://nemerle.org/svn/vs-plugin/trunk
E>Затем подсчитал количество непустых строк во всех *.cs/*.n файлах (чуть больше 20K) и разделил на количество дней, прошедших с 2005-05-07 (это дата сообщения: Содержимое SVN://RSDN/Nemerle

Автор: V.Petrovski
Дата: 07.05.06

). Получилось, что за один день писалось всего 90 строк:
E>

E>bash-3.1$ /usr/bin/find . -name '*' | grep -E '\.(cs|n)$' | xargs cat | grep -v -E '^[[:space:]]*$' | wc -l | \
E>ruby -e'lines = gets.to_i;puts lines/((Time.now - Time.parse("2006-05-07"))/86400)'
E>90.4658565961219
E>

E>Если еще и разделить на количество учавствующих в проекте разработчиков, то получится еще меньшее значение.

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

Интересно, как эту задачу можно решить чисто виндовыми средствами, не привлекая тяжёлую артиллерию?
На VBScript будет выглядеть ужасно (как раз сегодня правил деплоймент скрипты).
Monad shell (не видел ещё)?

VladD2 wrote:
> Достаочно того, что грпе пожно перенести в библиотеку. Тогда разницы в
> наличии готовых решений не будет. А разница в удобстве написания,
> отладки и повторного использования будет. И не в пользу шел-скриптов.
Понятие pipe, нормально загнанное в библиотеку, жизнеспособно на
Nemerle. На свежем C#, возможно, жизнеспособно, но за это я не поручусь
(не держу я mono). На предыдущей версии C# — судя по тому, как её
упоминали — заведомо не живёт. Так что это всё же вопрос не только
библиотек. Когда строк кода 1 раз по 1К — это неважно, когда 50 раз по
20 — неприятно.

> Вся моя мысль в этом и заключается. В корене не верно сравнивать
> мощьность и удоство на основе наличия некой библиотечной (назавем ее
> так) фунциональности.
А тут так любят ссылаться на практику применения как на недостаток Lisp.
За много лет никто так в библиотеку это до конца и не загнал, или о
результате никто не слышал, в результате программы в десять строк на
shell превращаются во что-то больше 25 на других языках, с некоторой
потерей читаемости. И отсутствие подсказок в shell-скрипте не портит
читаемость для тех, кому хоть что-то приходится настраивать на unix-like
сервере, так как базовые команды запомнились давно.

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

К>Глобально удобнее?
К>А ты не думаешь, что всё зависит от конкретной задачи?
К>Допустим мне нужно найти опр. строку в логе на серваке под солярисом, куда есть только ssh? Причём задача "разовая", т.е. критерии для поиска, файл и т.п. — вещь ситуативная и "сделал/выбросил".
К>Как ты будешь решать такую задачу?

Мы кажется про языки говорили в аспекте их использования программистами. Так вот, такая задача — она не столько программерская, сколько админская. Я же не призываю каждого пользователя пользоваться IDE.

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


K>>Зато в 2003 не было подсветки типов. И autocompletion там был без приоритетов по частоте использования. Да и сами autocompletion в 2005 студии сами собой выпадают, что позволяет сэкономить время на нажатие Control+Space (а это сочетание отвлекает при десятипальцевом наборе), и тем самым набирать довольно-таки длинные имена в 3-4 касания. А это сильно повышает продуктивность кодинга. Сколько я не заставлял когда-то себя привыкнуть к vim, у меня так производительно никогда не получалось.

К>Это всё здорово, конечно, но есть другой вопрос — скорость программирования у тебя определяется скоростью набора на клавиатуре? ИМХО это далеко не так и гораздо больше времени уходит на обдумывание и проектирование.

Я говорил не про скорость программирования а про скорость кодинга. ИМХО, это разные понятия. Я никогда не пишу код, пока точно не представлю, что и как мне нужно написать. Но когда я чётко представил, что нужно, в Студии я реализую свои мысли максимально быстро. Вот если бы я писал в Блокноте, то я свои мысли не реализовал бы вообще, так как просто плюнул бы на эту затею.

К>А тут могут быть полезны диаграмки классов и т.п. инструменты.

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

К>Не зря кто-то из довольно известных людей (Брукс?) говорил, что средняя норма — 20 чтоли строчек отлаженного кода в день для программиста.

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

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

EC>Здесь малость коряво вопрос сформулирован: имелось в виду что быстрее — воспользоваться grep'ом или написать программу на C#.
EC>Это понятно, если прочитать сообщения чуть выше по треду.

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

Сторона, стоящая за статику, утверждала, что для всех задач хватит статических ЯП. Оппоненты утверждали, что де-нет, вот всякие аналоги командной строки лучше реализовывать на Python/Ruby. Но тут надо сразу отбросить случаи простейших регэкспов, так как лучше вообще обойтись без консоли, а пользоваться апплетами IDE. Так что надо уяснить, что говорим мы только о сложных регэкспах, которые сложно написать/отладить. Так вот сторонники статики утверждают, что нет никакой разницы между статикой и динамикой, что такой пункт как "скомпилировать" просто отпадает в современных IDE. Тут же нашлись товарищи, которые закричали, что они против IDE и всё подряд компилируют из командной строки. Правда, потом оказалось, что эти товарищи то за IDE, то против неё, видимо пока не определились.

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

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

K>Если совсем уж уйти в корень спора, то можно заметить, почему он собственно возник. Чтобы лучше понять суть, можно даже посмотреть на ники участников. А суть флейма — давнишняя война между статической типизацией и динамической.

K>Сторона, стоящая за статику, утверждала, что для всех задач хватит статических ЯП. Оппоненты утверждали, что де-нет, вот всякие аналоги командной строки лучше реализовывать на Python/Ruby. Но тут надо сразу отбросить случаи простейших регэкспов, так как лучше вообще обойтись без консоли, а пользоваться апплетами IDE. Так что надо уяснить, что говорим мы только о сложных регэкспах, которые сложно написать/отладить. Так вот сторонники статики утверждают, что нет никакой разницы между статикой и динамикой, что такой пункт как "скомпилировать" просто отпадает в современных IDE. Тут же нашлись товарищи, которые закричали, что они против IDE и всё подряд компилируют из командной строки. Правда, потом оказалось, что эти товарищи то за IDE, то против неё, видимо пока не определились.

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

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

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

E>Это все не серьезно. Методы вроде Add/AppendNewElem или std::map::insert элементарно усваиваются еще при знакомстве с языком/библиотекой.

Неужели не ясно, что это просто пример одного из тысяч существующих классов

E>Если кому-то нужны всплывающие подсказки для работы с такими базовыми вещами,

А если не только базовые?!

E>Мне по работе приходится использовать что-то вроде ACE_Connector::connect, когда поверхностное знакомство с предметом во время написания кода ни к чему хорошему не приводит.

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

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

VD>Итак. Задаю его еще один, последний раж. Ты когда нибудь пользовался сорвеменной IDE (C# в VS 2005 или Java в IDEA)? Если, да, то сколько времени и каким количеством фич?

Последние среды, которыми я пытался пользоваться более-менее серьезно, были VS 6.0 и CodeGuide 3.0 (или 4.0, не помню), в 2001-м году. Причем VS 6.0 меня настолько задолбал, что я сначала выключил в нем все подсказки, а затем и перестал пользоваться вообще. И CodeGuide в плане IDE был на порядок круче VS 6.0. А от CodeGuide отказался довольно быстро, когда увидел, что его подсказки мне мешают. С тех пор я несколько раз смотрел на IDEA, но не работал в ней, т.к. на Java не программировал с 2001-го.

E>> Методы вроде Add/AppendNewElem или std::map::insert элементарно усваиваются еще при знакомстве с языком/библиотекой.

VD>В дотнете, например, несколько десятков тысяч классов и наврено около нескольких сотен тысяч методов. Запомнить описание для них не может никто. Так что не серозно говорить об их запоминании.

А никто и не говорит о запоминании сотен тысяч методов. Как правило, разработчик ограничивается совсем небольшим количеством сущностей. Очень небольшим, настолько, что самые употребимые хорошо запоминаются, а за остальными совсем не сложно залезть в Help.

VD>Но пойми и других кого это не устраивает, и кто думает о своей производительности турда.

Как раз я никого не отговариваю от использования IDE. Это здесь в адрес тех, кто IDE не пользуется, слишком много критики высказывается.

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

E>Древнее, говоришь.
E>Вот я сделал только что svn export http://nemerle.org/svn/vs-plugin/trunk
E>Затем подсчитал количество непустых строк во всех *.cs/*.n файлах (чуть больше 20K) и разделил на количество дней, прошедших с 2005-05-07 (это дата сообщения: Содержимое SVN://RSDN/Nemerle

Автор: V.Petrovski
Дата: 07.05.06

). Получилось, что за один день писалось всего 90 строк:
E>Если еще и разделить на количество учавствующих в проекте разработчиков, то получится еще меньшее значение.

Не стоит забывать, что этот код пишется в свободное от работы и отдыха время. Я что-то не видел утверждении, что кто-то этим занимается full-time и каждый день

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

E>>Это все не серьезно. Методы вроде Add/AppendNewElem или std::map::insert элементарно усваиваются еще при знакомстве с языком/библиотекой.

R>Неужели не ясно, что это просто пример одного из тысяч существующих классов

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

E>>Мне по работе приходится использовать что-то вроде ACE_Connector::connect, когда поверхностное знакомство с предметом во время написания кода ни к чему хорошему не приводит.

R>Тут никто не говорит о поверхностном знании предмета. Просто заучивать наизусть все методы с правильным чередованием их параметров и какого типа эти параметры это мягко сказать глупость, а таких классов вагон и маленькая тележка, и в любом большом проекте так оно обычно и бывает. А если приходится поддерживать или развивать параллельно несколько других проектов... Что делать что ли больше нечего на работе как сидеть в тупую зазубривать названия классов, методов, их параметры, с какими они типами и в какой очередности

Речь не о зазубривании. Речь вот о чем:
* есть набор фундаментальных понятий, которые должны отложиться в подкорке (или речь вообще не должна идти о знании языка). Например, в C++ элементарно запоминается, что у большинства контейнеров есть push_back, а у ассоциативных -- insert. В Ruby, например, конкатенация строк и добавление элементов в конец массива выполняется через <<. Это такой базис, который позволяет писать основные действия не задумываясь;
* есть набор более сложных вещей, с которыми приходится сталкиваться время от времени. Например, установление SSL соединения, выбор подходящего класса-Connector в ACE, выборка нужного сертификата в хранилище сертификатов и т.д. В этих случаях разработчику нужно погрузиться в предметную область, ознакомится с существующими API-вызовами (как правило, выбрать какую-то из альтернатив), определиться с последовательностью действий и порядком подготовки API вызовов (что бы нужные параметры формировались в нужных местах и в нужных форматах). Это все обычный процесс проектирования в процессе которого приходится перелопачивать приличное количество документации. В этом процессе роль всплывающих подсказок и autocomplete сильно преувеличивается, поскольку разработчик сначала должен понять, что и как он будет вызывать.

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

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

EC>На мой взгляд великолепная демонстрация того, где рулит динамика.
EC>Мне даже стрёмно думать сколько кода на статике надо написать, чтобы получить тот же результат.
EC>И никакие инелисенсы не помогут, с комплишенами.

Дело вовсе не в этом.
Имхо, дело в том, что уже есть годами отработанные механизмы для решения этих задачек -- unix-овые утилиты. Они адаптированны под такие цели не хуже (если не лучше), чем современные IDE для разработки "серьезных" программ. И просто глупо оказываться от использования отлаженных и проверенных инструментов в пользу написания еще одной программки для решения каждой задачки (даже если это не отнимает много времени).

Тем более, есть у меня подозрения, что большинство из противников shell и binutils просто никогда не занимались более-менее внимательным их изучением.

eao197 wrote:
> Тем более, есть у меня подозрения, что большинство из противников shell
> и binutils просто никогда не занимались более-менее внимательным их
> изучением.

В панике прячусь от всех, кто соберётся использовать binutils для
обработки текста...

А про POSIX shell environment — есть те, кому всё равно пришлось
разобраться, и они пользуются. Остальные — нет. Ну это как с Nemerle —
те, кто и так держит .NET, относятся к Nemerle хорошо и практически,
остальные — хорошо, но теоретически. Ваше отношение, что не всё пригодно
для командной разработки имеет своё отражение — тех, что shell
использует, но пишет $* вместо "$@".

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

EC>Так в этом и была суть моего вопроса. Просто куча народа в том треде кинулась приводить код на C# для решения этой задачи.

Не скажу за кучу. Синклер тебе продемонстрировал, что даже без наличия библиотеки решение не так уж и сложно. Я тебе рядом где-то сказал, что некорректно сравнивать использование гтовой утилиты и универсальный код решающий ту же задачу.

EC>То, что её можно на нём решить сомнений не вызывает. Вызывает сомнения целесообразность её решения этим способом.

В начале разговора речь шала о возможностях шел-скриптов по сравнению с полноценными ЯП. Никто так и не продемонстрировал приемуществ именн шел-скриптов. Вместо этого тема была подменена рассуждениями о возможностях утилит вызваемых из этих скриптов. Тебе не кажется что это несовсем нормально?

EC>В общем я возражал, что статика во всех задачах даёт преимущество — думаю некоторых убедил.

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

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

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

R>Понятие pipe, нормально загнанное в библиотеку, жизнеспособно на
R>Nemerle. На свежем C#, возможно, жизнеспособно, но за это я не поручусь
R>(не держу я mono). На предыдущей версии C# — судя по тому, как её
R>упоминали — заведомо не живёт. Так что это всё же вопрос не только
R>библиотек. Когда строк кода 1 раз по 1К — это неважно, когда 50 раз по
R>20 — неприятно.

Ничего не понял. Какша какая-то.

>> Вся моя мысль в этом и заключается. В корене не верно сравнивать
>> мощьность и удоство на основе наличия некой библиотечной (назавем ее
>> так) фунциональности.
R>А тут так любят ссылаться на практику применения как на недостаток Lisp.
R>За много лет никто так в библиотеку это до конца и не загнал, или о
R>результате никто не слышал, в результате программы в десять строк на
R>shell превращаются во что-то больше 25 на других языках, с некоторой
R>потерей читаемости. И отсутствие подсказок в shell-скрипте не портит
R>читаемость для тех, кому хоть что-то приходится настраивать на unix-like
R>сервере, так как базовые команды запомнились давно.

1. Кто-то что-то загнал. Не надо обобщать.
2. Возможно большинству людей это просто не нужно. Я вот лично очень редко вообще скрипты пишу. И когда пишу, то почему-то функциональность греп-а мне нужна не часто.
3. Возможно многие просто не знают о некоторых возможностях некоторых утилит и изобретают велосипеды на ровном месте.

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

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

К>А ты не думаешь, что всё зависит от конкретной задачи?
К>Допустим мне нужно найти опр. строку в логе на серваке под солярисом, куда есть только ssh? Причём задача "разовая", т.е. критерии для поиска, файл и т.п. — вещь ситуативная и "сделал/выбросил".
К>Как ты будешь решать такую задачу?

Мне кажется все зависит даже не от задачи, а от того кто будет ее решать. Ну, не возникнет у меня, например, задачи искать что-то под соляркой. Просто потому, что ее я видил в последний раз 6 лет назад и ничего интересного я там для себя не нашел.

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

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