PI>>да, но только надо понимать, что форум и так — большая мусорка,
VD>Ошибочка. Не "и так", в "именно по этому".
ты не можешь заставить людей ходить строем
большая часть, конечно, способна принять правила, и таки ходить,
но всегда будут "несогласные" во всех их разнообразии, не принимающие правил, поскольку считают их слишком ограничивающими их личную свободу
в среднем, люди всегда и везде генерировали спам (бессмысленные и бесполезные высказывания), и заставить их изменить природу общения невозможно
другое дело, когда в качестве цели ставится не общение само по себе, а создание/компрессия информации
но тогда бы получилась бы вики, не так ли?
PI>>и по поводу "тролления" у меня есть также мнение — "троллизм" бывает полезным PI>>к примеру древние греки очень любили писывать книги в форме диалога PI>>это крайне полезно — следить за 2 линиями сразу PI>>а тот, кто может последовательно и наглядно изложить несколько линий (ну, Сократ тому пример) PI>>тот и молодец
VD>http://en.wikipedia.org/wiki/Troll_%28internet%29
да, я знаю, что такое тролль
проверить комьюнити на устойчивость, а отдельных участников — на скилл умения вести дискуссию, — это тоже можно рассматривать как полезность, не так ли?
да и вообще, никакое несущее смысл мнение не должно быть угнетено, не так ли?
а свободное от смысла высказывание — на него и отвечать не нужно, не так ли?
VladD2 wrote: > R>Тема начиналась с того, что объявлялось, что shell скрипты никогда не > R>удобнее программы на C#. Мне предлагали ставить mono на GNU/Linux, а он > R>больше по размеру. > > Насколько я помню исходно ставлися тезис что шел-скрипт — это ДСЛ > который чем-то лучше чем универсальный язык. Вместо доказательства этой > позиции тема сошла в демогагическое обсуждение того, то наличие готовых > утилит оправдывает убогость ЯП и его среды.
Что такое DSL? Синтаксис, заточенный под задачу, недостаточен?
> R>Да, действительно, нормальный matching там есть. Хотя необходимость > R>что-то подключать для кода короче десяти строк — минус, хотя и мелкий. > > Для скриптов можно специально по умолчанию открыть пару пространств > имен, чтобы не дублировать код. К тому же визарды никто не отменял. > Достаточно создать проект "скрипта" и одни нажатием мы получим нужное > окружение.
Всё же неприятно читать, когда мусора больше, чем кода. Но не так важно.
>>> По-моему, даже применение Явы для этого уже дало бы множество > R>Какие? > > Полноценный язык который (компилируемый, что немаловажно), возможность
В чём немаловажность для кода, исполняемого раз в день секунду в фоне —
станет 0.1 с, и что?
> использования отличной IDE, отладчика, моря библиотек, качественной
Отладчик? На таком объёме? При инкрементальном написании (смотрим, что
выдаёт каждая строчка)? В задачах shell обычно имеется сплошной поток
данных, который в силу синтаксиса легко разорвать в каждой точке.
Атомарные операции просты и понятны (как иначе..). Что даст отладчик?
> документации.
info bash вполне удобоварима как документация. Как и info coreutils. Как
и man netcat, если на то пошло.
> R> Что я получу взамен case, > > Hashtable и кучу других библиотечных фунций. Конечно приятно было бы
Спасибо большое. Только case нужен каждый шаг, а вот зачем в скрипте на
экран hashtable...
> заполучить возможности Немерле, но их ведь и в шел-скриптах нет. > > R>for, > for в Яве 1.5 расширен до возможностей foeeach C#-а.
А список для этого foreach я в каком синтаксисе буду генерировать?
*.txt; или немного (раза в три) больше мусора?
> R> предельно краткого синтаксиса > > Предельно экзотического и извращенного. Причем разного вразных вариантах.
POSIX shell давно можно считать имеющимся. csh не столь существенен.
> R>вызова функций > > вызов функций Причем полноценный, рекурсивный и быстрый.
В shell нет проблем с рекурсией. А вот лишние скобки, запятые вместо
пробелов и тому подобное в Java мне придёт по полной программе. Порвать
словосочетание посередине, не потеряв смысл, Вам не совсем удалось.
> R>и краткого синтаксиса перенаправления потоков данных? > > Полноценным языкам не требуются подпорки вроде пайпов. Они и так > повзовляют передавать результаты одной функции другой. Для этого
У shell тоже есть варианты, как это делать. Просто pipes часто очень
хорошо подходят под описание имеющейся задачи.
> придумана куча мехонизмов. В том числе потоки ввода вывода и итераторы.
И что, я небось ещё переменную должен объявить и тип указать?
> R> Я успею этим воспользоваться в экране кода? На Яве столько обвязка для > R>Hello world занимает.. > > Для целей скрипта можно сделать простенький снипет-компилятор который > уберет эту "обвязку". Плюс опять же с ней нет проблем если ты пользуешся
И что я выиграю в результате-то?
> IDE.
А читать весь этот мусор?
>>> приемуществ. Соорудить набор соотвесвующих библиотек и удобные средства >>> запуска. Остальное уже есть. Конечно более мощьный язык вроде Немерла > R>На экране кода синтаксис стоит тоже немало. > > Синтаксис шелов ужесен. Что на экране, что на 20. Причем скрипты в 20
Си не лучше — это не помешало С++ взять всё плохое, что было. Shell
позволяет писать вполне нормально, и не провоцирует на извращения.
> экранов очень даже встречаются.
Они могут быть читаемы. Имеют, как правило, хорошую переносимость. Если
же нет — ну, забивание молотком лампочек в патрон не дискредитирует
молоток как инструмент, и не говорит ничего о том, что гвоздь в стену
иначе, как специальным роботом помещать еретично.
> R>Полноценная IDE не нужна для скриптов короче экрана — ей просто некогда > R>воспользоваться на таком малом объёме. > > Она нужна для любого объема код. От одного вызова, до проекта на 1000 > файлов. > Это и удобство для опытных пользователей, и простота вхождения для новичков.
Что он даст на одном экране? В shell нормальный completion.
> R>Основание — shell имеет сочетание свойств, выгодное для его роли. > > И как мы выяснили все они упираются в греп и еще пару утилит к шел-у по
Это искажение фактов — выяснили только Вы. > большому счету отношения не имеющих.
Ну, Вы игнорируете синтаксис, в котором есть ровно то, что нужно для
задач shell. И REPL. В результате имеем нормальное сочетание синтаксиса
под задачу и стандартной библиотеки. Вполне DSL.
> R> Вызов > R>функций — просто с аргументами через пробел. С учётом специфики - > R>удобно. > > Не сказал бы. Это твоя привычка. Мне как программисту всю жизнь > использовавшему С- и Паскале-подобные языки (а до этого учившегося в
Паскаль я учил раньше shell, предпочитаю его Си-подобному убогому
синтаксису. Однако к shell привык быстро.. Хотя конечно, команды DOS я
как-то представлял ещё до Pascal, и даже до BASIC.
> школе математике) понятнее и привычнее синтаксис со скобками и запятыми.
Привычнее? Сколько угодно. Только набирать неудобно. Бонус: как раз в
специализированных математических предметах я иногда наблюдаю
бесскобочные записи.
> R> Далее имеем такую вещь, как флаги вида -<буква> > > И чем это отличается от перечислений передающихся в параметры? Хотя > отличие есть. В параметрах задолбашся разбираться (пока их не > зазубришь), а перечисления как раз будут отлично понятны без пояснений. > Да и пояснения для них получить будет раз плюнуть (помним про Интеллисенс).
Пояснения и так на экране... Если их забыть. И они на него влезают. А
вот набирать придётся перечисления несколько дольше.
> R>. С выдачей списка по <tab>-<tab> при наборе. > > Он отдыхает по сравнению с полноценным комплитом и хинтами. Расширить
Чем же он хуже? Помощь в него включена. > комплит для подсказки каталогов на текущей машине и стандартных > каталогов и будет вообще улет.
Только, похоже, не в этой жизни...
> R> Как их передавать — как строки? > > Зависит от задачи. > > R> Подозрительная похожесть решения проблемы флагов в shell и Lisp > наводит на мысли, что сделать лучше можно, но весьма сложно. > > А не наводит на мысль то что Лисп уже 45 лет на задворках? Может ну его > на такое удобство?
Ну как-то все идеи, совместимые с динамической типизацией, появляются
там вполне не в последних рядах... Так что можно не любить писать syntax
tree (продвинутые reader'ы есть не для всего, и их никто не упоминает),
но вот реализация побочных вещей в нём о чём-то говорит.
> R>Я пробовал использовать как shell что-нибудь помощнее. Но многословность > R>в тривиальных случаях быстро добивает. > > Это только говорит о тебе. Вместо того чтобы создать библиотеки ты все > добил в коде скрипта.
Библиотеку? Толку? Задалбывает, что надо вызвать две функции, и на
каждом вызове — мусорная обвязка. Или лучше — надо запустить grep. Ну
после привычки grep what where уже ломает писать больше для частой операции.
> R> А shell-скрипт — это как раз не больше экрана кода, из которого > обвязку выкинули как класс и при этом в большинстве строк по несколько > вызовов вложенных вызовов функций. > > В коде любого языка все коротго если код вызвает гтовые выскоуровневые > библиотеки. В ранних версиях Юникс и ДОС-е выбор утилит и кривых > скриптовых языков было обяснимо. В те времена компонентных технологий > еще попросту не существовало. Но почему в современных ОС дела обстоят не
Кроме тех самых, на которых строился unix shell.
> сильно лучше лично я понять не могу. Это банальная костность мышления.
Если синтаксис сделан так, что из пяти строк делается две — эти две я
буду писать на shell. А для чего-то большего уже думать, писать ли на
pascal или на scheme.
TBG>>Диаграммы, еще раз диаграммы. Без диаграм ваша IDE и не I вовсе, а специализированный редактор кода.
K>О, прямо в яблочко. Вот что-то вроде IDE я на данный момент и делаю. Вот на какой стадии:
о, чрезвычайно интересно
а что в качестве технологии используется?
рисование прямоугольников, графов с нуля? или что-то готовое есть?
что там ещё интересного есть?
Здравствуйте, EvilChild, Вы писали: EC>Но некоторые передёргивают и пытаются преподнести это так, как будто им предлагают писать EJB компоненты на bash.
Видишь ли в чем дело, шелл-скрипты — очень-очень старая технология.
Нет никакой уверенности в том, что она же является оптимальной. Совершенно не факт, что именно такая технология скриптинга является правильной.
Запросто может оказаться, что все преимущества типичных шеллов являются просто наследием тяжкого прошлого. Что введение типизации в современный шелл возможно и даже оправдано. На практике это может оказаться невозможным из-за обилия legacy. Тем не менее, мы же здесь занимаемся философией, а с ее точки зрения затраты на ввод передовой технологии все равно бесконечно малы по сравнению с выгодой от ее использования (т.к. выгода может быть сколь угодно велика — всегда можно предположить достаточно длительный период эксплуатации) .
Так вот, запросто может оказаться, что через X лет управление ОС будет осуществляться на строготипизированном скрипте, а современные шелл-скрипты будут вызывать веселый смех, как сейчас забавляет процедура загрузки электроники-60 с вводом машкодов.
Разве не круто было бы при попытке поредактировать батничек сразу получить предупреждение шелла о том, что N зависящих от него батничков перестанут работать? Получить рефакторинг, в том числе и глобальный? Иметь все прелести автокомплита и всплывающего хелпа? Иметь программный доступ к истории команд и продвинутую обработку ошибок?
Почему в 21 веке мы до сих пор вынуждены писать совершенно дурацкие скрипты с проверкой error_level после каждого вызова и корявыми goto вместо обработки исключений? Почему единственным механизмом взаимодействия процессов, управляемым из шелла, является piping stdin/stdout?
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, raskin, Вы писали: R>На 1000 точек руками будут вбивать мои враги.
Ексель позволяет это сделать даже без изучения макросов. Позор программисту, неспособному освоить настолько оптимизированный под пользователя инструмент. R>Автоматизировать — не хватит мне знания Excel на то, чтобы результат не R>требовал лишних телодвижений.
О да, конечно. Куда проще освоить новый язык программирования/разметки, чем включить запись макроса в екселе и посмотреть, что именно ты делаешь ручками.
>> Так что не выдумывай. R>У меня RAM 768MB. Эффект мгновенного запуска Excel я не наблюдаю.
Не выдумывай. Ексель страшным образом оптимизирован по потреблению памяти. Он прекрасно работал у нас и на 256MB.
Только что запустил его на перезагруженной машине (так что кэшироваться он не мог) — меньше 1 секунды. Workset — 38MB, из них ~21 shareable.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Так вот, запросто может оказаться, что через X лет управление ОС будет осуществляться на строготипизированном скрипте, а современные шелл-скрипты будут вызывать веселый смех, как сейчас забавляет процедура загрузки электроники-60 с вводом машкодов.
А есть какие-нибудь реальные наработки в этом направлении?
Здравствуйте, konsoletyper, Вы писали:
TBG>>Я вот прекрасно помню, что он примет число какое-нибудь (0, 7, по вкусу). Зачем мне забивать голову еще чем-то, что мне не нужно? И также кнопки нажимать Ctrl-Space? И также зачем ему автоматически выпадать, место при этом занимая? K>А вот этого я, как демагогофоб с мировым именем, боюсь
А может, под другим углом на все это посмотреть?
K>На самом деле, никто не требует изучать по выпадающему списку, а вот пропоминание по autocompletion'у только приветствуется. Причём, порой приходится вот так "припоминать" собственный код, написанный буквально пару месяцев назад.
Мне не припоминать надо, мне напечатать надо. При этом затратив как можно меньше действий пальцами. Для этого автокомплит рулит. Ну а если свой код, который два дня назад припомнить не можете, то лучше пересмотреть политику именования переменных и классов.
K>Кстати, места выпадающий список много не занимает, по крайней мере, редактируемую строку не закрывает. А вот пользы от него много. Например, позволяет набирать длиннющие названия методов в два касания — благо VS2005 ведёт статистику выбранных идентификаторов и при следующем показе
Не знаю, длиннющие набирать проще и быстрее автокомплитом (который setValueForLong типа sVFL). Мне просто долго позиционироваться курсором на нужном методе. Особенно если похожи (setValueForLongi). Но это так, для примера.
Здравствуйте, IT, Вы писали:
IT>Вообще же, до сегодняшнего дня, все те, кто мне встречался в жизни и негативно отзывался об отладчике просто не умели им пользоваться. Но если вдруг припекало, то после небольшого лекбеза всё становилось на свои места. Некоторые даже с восторгом потом рассказывали как это кульно, когда отладчик сам останавливается в случае возникновения исключения. Вау! Круто!
Ой, кульно, ой, круто. И? Все это лишь отодвигает разработку в динамику.
IT>Это относится обсолютно ко всем тем, с кем я когда-либо работал и кто клеймил по чём зря и сам отладчик и тех кто им пользуется. Я даже сам
Я не ставлю клеймо на отладчик. Я стараюсь им пользоваться именно там, где ему место (как я считаю). Ниже поясню.
IT>когда-то был таким. Боюсь, в онлайн эта ситуация (неприятие из-за непонимания, а не из-за чего-либо по делу) мало чем отличается, для этого просто нет никаких причин. По-крайней мере, до сих пор их никто не озвучил. Непонимание, неумение, домыслы, заблуждения, IT>необоснованные суждения (как в твоём случае) — этого хоть отбавляй, но вот реальных фактов я пока не встречал ни разу. По-этому,
Прошу примеры в студию необоснованного суждения.
IT>хочется пожелать только одного — учите мат. часть и учитесь пользоваться инструментарием, который имеется в вашем распоряжении. Это гораздо полезей, чем хаить то, чего не понимаешь и чем не умеешь пользоваться.
Если хотите сказать, что я не умею пользоваться отладчиком — тут уж вы ошибаетесь. При этом довольно сильно. Да и вообще, своими инструментами я умею пользоватсья (иное мнение лишь Ваши домыслы и необоснованные суждения).
По поводу отладчика. Сам не раз видел код, который написан под веянием (а, если что, потом..). И это "потом" происходило в долгом сидении в отладчике и долгого мучительного выяснения, пересмотра, перепроектирования, грубого хака. С этой позиции отладчик зло. И вы тут меня разубедить не сможете, поскольку примеры были из жизни, а не из абстрактных высказываний на этом форуме.
Здравствуйте, VladD2, Вы писали:
IT>>Первый раз сталкиваюсь с таким мнением. Тем не менее не удивительно, что оно из серии закручивания гвоздей отвёрткой. VD>Не. Оно скорее напоминает обругивание молотка за то что кто-то им болты пытается забивать.
В принципе, вы наиболее близко меня поняли. Хотя я не столько обругиваю сам молоток, я лишь не понимаю почему он не спроектирован таким образом, чтобы не позволял забивать им болты.
VD>Опять же в случае данного гражданина мы имеем скорее обратную картину. Он явно понимает что такое отладчик и возможно эффективно им пользуется в реальной работе, но чисто для поддержания беседы тролит по маленьку.
Не тролит, а высказывает свое мнение. Есть проблемы. Есть опыт. Делюсь.
Здравствуйте, PhantomIvan, Вы писали:
PI>вот, открыл файл, копирую случайную формулу оттуда: PI>и ты мне говоришь, что компилить совсем-совсем не нужно?
В этом случае и F5 нажать не жалко. Зачем все время актуальные изменения видеть?
TBG>> Или docbook, если нравится. PI>(ла)тех — для формул, а не для "логической разметки текста"
В том числе и для формул. Дедушка Кнут для этого и делал — для написания книг своих. И в ТеХ используется "логическая разметка". Ну используется, и ничего с этим не поделать.
Здравствуйте, VladD2, Вы писали:
TBG>>А давайте произнесем это по другому. Зачем пользоваться Eclipse, MinGWDeveloperStudio, SharpDevelop, если есть vim? VD>Ты и сам знаешь. Затем, что редактируется не "текст", а код некоторой программной системы — проект.
Если проект со всеми вытекающими, то тогда да. Но если нужно подредактировать файлик (настроек к примеру), зачем мне для этого использовать полновесную IDE?
TBG>> Если нужно произвести редактирования текста? VD>Если текст на разговорном языке, то для этого есть специализированные редакторы вроде МС Ворда или Стар офисовского Ворда.
Почему же? ТеХ, вон, прекрасно редактируется в VIM. Про Lyx знаю. И про TeXMacs тоже.
VD>vim хорош там где нет более мощьных продуктов так как его можно настроить больше чем простой редактор. По сути vim — это практически IDE, только по слабее чем лучшие аналоги.
Я его использую не как IDE, хотя и не отрицаю, что до этого состояния его можно довести и им удобно будет для этого пользоваться.
VD>А другим vim не привычнее. И что?
Пусть тогда пользуются тем, что привычнее..
TBG>>Когда не хочется думать, а просто посидеть, поразмышлять о вечном, то тогда чашечка чая, интерактивная отладка. VD>Хм. А кто-то радяом спрашивал "зачем нружен отладчик?". Это не ты был?
Здравствуйте, konsoletyper, Вы писали:
K>Ну и пользуйтесь себе vim наздоровье, если он такой удобный. Зачем столько эклектики, так много разных IDE?
Ну наконец-то!
А так IDE много разных потому, что в одном удобнее одно, в другом — другое.
K>Вот я занимаюсь одним большим проектом, иногда приходится параллельно заниматься маленькими, но и то и то под .NET. Наш начальник говорит: "запомните, мы пишем на трёх языках: C#, C# и C#". Интересно, где это такие "прогрессивные" начальники, которые позволяют на разных языка в разных средах писать одному программеру? Как говорится, Лиспу — лиспово, C#'у — C#-повою.
Это все, что я говорил — в свободное время что происходит.
В рабочее — Java, Eclipse, Idea, Netbeans, vim.
K>Ну и зачем тратить своё время, когда можно в интерактивном режиме то же самое сделать раз в 5 быстрее, а потом и чайку попить, и о вечном подумать и красивое архитектурное решение найти?
Ну правильно, зачем тратить время на интерактивный дебаг, если можно все отловить до этого?
Здравствуйте, VladD2, Вы писали:
TBG>>shell обладает теми возможностями, которми наделяет ее тот, кто этим shell'ом пользуется. VD>Извини, но твои сообщения все более и более бессмысленны. Я даже не понимаю что на них отвечать то?
Ну тогда лучше не отвечать?
Не стоит ожидать большого смысла от сообщений в вечер ВС.
Тепрь по делу. Про shell. Это же среда. И программы, которые пишутся под нее (awk, grep, wc и т.д.) являются екстендерами. Это я хотел сказать. И средства взаимообмена между процессами тоже хоть какие-то есть. Все это позволяет сказать, что шелл очень даже себе расширяем (а раз расширяем, то и возможности добавить возможно), пусть и синтаксис у него еще годов эдак 80-х. Ну с кем не бывает, legacy ведь тоже дает о себе знать.
Здравствуйте, PhantomIvan, Вы писали:
PI>немерле обладает теми возможностями, которыми наделяет её тот, кто этим немерле пользуется
Справедливо для любого языка программирования. Речь пойдет лишь о степени расширяемости. То есть немерле, лисп могут расширить свой синтаксис. Многие мейнстримовые — нет, но они расширяют свою функциональность за счет библиотек.
Здравствуйте, VladD2, Вы писали:
TBG>>А по-моему, надо выделить слово цели и рассматривать с этих позиций. Вполне допустимо, что при таком положении возможно сравнение с IDE, хотя с другой позиции и нет. VD>Надо было в институте логику изучать, тогда трепаться на тему сравнения мягкого с теплым даже говорить не захотелось бы.
Может, тогда быстренько на вики прочитаете, а потом договорим?
Теперь по делу. Я ведь не зря выделил слово цели. Мягкое с теплым, если отбросить несущественные для сравнения детали, становятся оба черными. И сравнивается степень черноты.. Приведу пример. Швабра и забор — мягкое и теплое. Но у швабры есть ручка (палка), а кусок от забора (палка) — вещи сопоставимые.
Здравствуйте, VladD2, Вы писали:
VD>"Если" замечательное слово. На практике же сравниваются язык с утилитой, а Turtle.BAZON.Group вообще дошел до сравнения утилиты с IDE.
Еще для примера. Программерский Под Eclipse проект собирается правой кнопкой мыши и экспорт. Для сборки существуют отдельные утилиты (Ant, Maven). Вот процесс сборки у IDE и этих утилит можно сравнить. Не согласны?
1.2.0 alpha rev. 655
