Здравствуйте, PhantomIvan, Вы писали:
PI>а ну ка, я попрошу скриптец с обсчётом других метрик... PI>вложенность там средняя... количество методов на класс... PI>и чтоб чекпоинты во времени сохранялись в файлик PI>слабо?
Да
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, raskin, Вы писали:
R>Выбор уникальных значений не требует. Так что полное считывание R>понадобится один раз, а не в двойном объёме.
Речь не о двойном. Речь о том, что для выбора уникльных значений прийдется прочесть все данные и закэшировать результат в памяти.
А для сортировки вообще потребуется или загрузить все в память или читать данные много раз (т.е. промежуточно сохранять в файл).
R>А, то есть хоть какое-то подобие функциональных возможностей там имелось R>сразу.
Паттерн Итератор применим к любому ООЯ. Да и к голому С в общем-то тоже.
R>Скачать bash и не скачать grep — нетрудно. Но это надо хотеть.. В R>busybox grep и sed встроены, дальше что...
А ничего. Библиотекой он от того быть не персатет.
R>Что-то мне подсказывает, что нескоро будет такая библиотека, удобная
Не знаю что тебе это подсказвает. Попробуй обосновать. Уверен, что не удастся.
R>именно для R>one-liners и one-screeners. К тому же толку с ней, если mono — это R>довольно много места, и под unix-like его ставить ленятся, а под виндой R>большинство всё равно начнёт с поиска в FAR (ну или в TC). Так что R>хвалить чудо природы будет некому.
Какую фигню люди только не преплетут лишбы не отказываться от своих заблуждений. Моно уже давно входит в поставку большинства дистрибутивов Линукса. Да и пофигу он всем тем кто работает под Виндвс (т.п. подавляющему бльшинству).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, raskin, Вы писали:
R>Гм, как я туда введу средней сложности функцию? Я просто представляю R>себе как там построить график по имеющимся точкам, но вычислить....
Вызваешь свою "среденй сложности функцию" в разных ячейках с разными параметрами и строишь график по этим точкам. Если очень хочется процесс легко автоматизируется.
Учитывая, что в большинстве случаев графики будут как раз по данным из того же Экселя, то и говорить не очем не приходится.
R>К тому же, excel тяжелее по любому параметру, чем названные мной вещи.
Ёксель есть у большинства пользователей ПК. Грузится он за 0.5 секунды. Так что не выдумывай.
Если ты принадлежишь к группе экстравогантных товаришей использующих мат-пакеты для вывода примитивных графиков, то не надо думать, что так жвут все остальные. Поверь, что 99% люде даже не слышали названий продуктов которые ты упомянул.
R>Но надо эту компоненту указать,
Она за один клик на форму бросается.
R> создавать массив значений — или R>передавать точки в цикле.
Иы меея креечер ищвиеи, но надо быть совсем не всебе чтобы считать, что в обычных условиях люди будут формировать график по мат-формуле. Это редкость несусветная. Как раз по точкам он в осноном строиться и будет.
Ты просто явно поварился в экзотической культуре где люди занимаются высшими материями. Спустись на землю и увидишь, что тут все по другому.
>> В простейшем случае же конечно проще воспользоваться приложием где >> подсчет слов уже есть. Например тем же VIM-ом или Word-ом. У меня VIM-а >> нет, но мне Word-а хватает. R>А по regexp он умеет?
Он еще не умеет газоны подстригать. Простим ему это.
R>Почему Вы не считаете shell DSL? Какое Ваше определение DSL?
Потому что это не ДСЛ, а убокгий язык общего назначения. Нет там ни одной осмыслнной конструкции которая бы упрощала работу. А всякие грепы — это не язык. Это билблиотеки.
Корче читай того же Грэхема: http://www.nestor.minsk.by/sr/2003/07/30710.html
Мощь языка, в которой заинтересован программист, возможно, трудно определить формальными методами, однако одно из объяснений этого понятия заключается в свойствах, которые в менее мощном языке можно получить, только написав на нем интерпретатор для более мощного языка. Если в языке A есть оператор для удаления пробелов из строк, а в языке B его нет, это не делает A более мощным, чем B, так как в B можно написать процедуру, которая делала бы это.
Но, скажем, если язык A поддерживает рекурсию, а B — нет, это нечто, что нельзя исправить написанием библиотечных функций
Мне кажется эти слова отлично описывают мою мысль.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > R>Гм, как я туда введу средней сложности функцию? Я просто представляю > R>себе как там построить график по имеющимся точкам, но вычислить.... > > Вызваешь свою "среденй сложности функцию" в разных ячейках с разными > параметрами и строишь график по этим точкам. Если очень хочется процесс > легко автоматизируется.
На 1000 точек руками будут вбивать мои враги.
Автоматизировать — не хватит мне знания Excel на то, чтобы результат не
требовал лишних телодвижений.
> Учитывая, что в большинстве случаев графики будут как раз по данным из > того же Экселя, то и говорить ни о чём не приходится.
Смотря у кого как.
> R>К тому же, excel тяжелее по любому параметру, чем названные мной вещи. > > Ёксель есть у большинства пользователей ПК. Грузится он за 0.5 секунды. > Так что не выдумывай.
У меня RAM 768MB. Эффект мгновенного запуска Excel я не наблюдаю. Ядро
компилируется не тормозя на общение с диском, поэтому я считаю
количество памяти достаточным.
> Если ты принадлежишь к группе экстравогантных товаришей использующих > мат-пакеты для вывода примитивных графиков, то не надо думать, что так > жвут все остальные. Поверь, что 99% люде даже не слышали названий > продуктов которые ты упомянул.
Если у Вас совсем много памяти на машине...
> R>Но надо эту компоненту указать, > > Она за один клик на форму бросается. > > R> создавать массив значений — или > R>передавать точки в цикле. > > Иы меея креечер ищвиеи, но надо быть совсем не всебе чтобы считать, что > в обычных условиях люди будут формировать график по мат-формуле. Это > редкость несусветная. Как раз по точкам он в осноном строиться и будет.
У кого как, мне посмотреть на график заданной формулой функции
приходится смотреть не так редко, как Вам.
> Ты просто явно поварился в экзотической культуре где люди занимаются > высшими материями. Спустись на землю и увидишь, что тут все по другому.
Ну, мне надо иметь, среди прочего, инструменты для занятий математикой.
И то, что они не нужны 95% популяции меня не остановит в поиске удобных,
улучшении перспективных и их продвижении. 75% процентов пользователей
запускают по неопытности вирусы из спама — это обязывает меня
пользоваться антивирусом под Linux?
>>> В простейшем случае же конечно проще воспользоваться приложием где >>> подсчет слов уже есть. Например тем же VIM-ом или Word-ом. У меня VIM-а >>> нет, но мне Word-а хватает. > R>А по regexp он умеет? > > Он еще не умеет газоны подстригать. Простим ему это.
Простим. Но не будем использовать как инструмент для некоторых задач.
> R>Почему Вы не считаете shell DSL? Какое Ваше определение DSL? > > Потому что это не ДСЛ, а убокгий язык общего назначения. Нет там ни > одной осмыслнной конструкции которая бы упрощала работу. А всякие грепы > — это не язык. Это билблиотеки.
Так на определение DSL ссылку дайте?
> Корче читай того же Грэхема: > http://www.nestor.minsk.by/sr/2003/07/30710.html > > Мощь языка, в которой заинтересован программист, возможно, трудно > определить формальными методами, однако одно из объяснений этого > понятия заключается в свойствах, которые в менее мощном языке можно > получить, только написав на нем интерпретатор для более мощного > языка. Если в языке A есть оператор для удаления пробелов из строк, > а в языке B его нет, это не делает A более мощным, чем B, так как в > B можно написать процедуру, которая делала бы это. > Но, скажем, если язык A поддерживает рекурсию, а B — нет, это нечто, > что нельзя исправить написанием библиотечных функций > > Мне кажется эти слова отлично описывают мою мысль.
Как-то Вам это не мешало клеймить Lisp...
Сейчас я замечу, что в Vimscript и в Ruby можно поймать факт вызова
несуществующей функции, узнать её имя, и определить. В Lisp, Scheme и
ещё нескольких приятных языках можно определить макросы, которые
определяют другие макросы при вызове, и они применяются довольно широко
для определения "форм" (special form).
Отсюда делать вывод, что не позволяющий ни того ни другого C# следует
отправить на свалку, тем более, что всё, что есть в .NET — только
библиотека по отношению к уровню, доступному Scheme, всё же не очень
своевременно.
В bash нормальным является запустить функцию, для получения названия
вызываемой функции. Кстати, case там получше, чем в большинстве языков.
Кстати, for там ровно такой, как нужен для задач shell. Ну и REPL.
VladD2 wrote: > R>Выбор уникальных значений не требует. Так что полное считывание > R>понадобится один раз, а не в двойном объёме. > > Речь не о двойном. Речь о том, что для выбора уникльных значений > прийдется прочесть все данные и закэшировать результат в памяти.
Нет, так как они предполагаются отсортированными. > А для сортировки вообще потребуется или загрузить все в память или > читать данные много раз (т.е. промежуточно сохранять в файл).
Ну да, для этого придётся. Но это не отменяет того, что при размножении
потока собирать все данные придётся только там, где это надо — а не
раздваивать данные.
> R>Что-то мне подсказывает, что нескоро будет такая библиотека, удобная > > Не знаю что тебе это подсказвает. Попробуй обосновать. Уверен, что не > удастся.
Ну, как зовут эту библиотеку?
Почему-то именно этот аргумент использовался здесь, чтобы доказать, что
Lisp безнадёжен — что некоторая вещь, которую всякий, кому она
действительно нужна, уже сделал бы, ещё не сделали.
> R>именно для > R>one-liners и one-screeners. К тому же толку с ней, если mono — это > R>довольно много места, и под unix-like его ставить ленятся, а под виндой > R>большинство всё равно начнёт с поиска в FAR (ну или в TC). Так что > R>хвалить чудо природы будет некому. > > Какую фигню люди только не преплетут лишбы не отказываться от своих > заблуждений. Моно уже давно входит в поставку большинства дистрибутивов > Линукса. Да и пофигу он всем тем кто работает под Виндвс (т.п.
А весит сколько? То, что включено везде, не обязательно всеми ставится. > подавляющему бльшинству).
Из-за большинства меньшинство не перестаёт пользоваться удобными
инструментами под задачу.
Здравствуйте, eao197, Вы писали:
E>Игорь, блин, ты же сам сейчас сказал самую суть -- при разработке проекта далеко не всегда приходится писать код.
Это не та суть. Интеграция не является обычным проектом по многим причинам. Во-первых, это opensource, в котором люди работают время от времени. Во-вторых, этот проект интегрирует две бета-версии двух продуктов. С одной стороны у нас компилятор, который требует доработки для интеграции (и который ты не учёл в своём анализе), с другой VS SDK, вообще ещё находящаяся в активной разработке. В-третьих, многие из тех, кто участвует в проекте делают то, что они делают первый раз в жизни и делают это на новом для них языке. В лучшем случае у некоторых есть теоретические знания. В нормальной ситуации их просто не подпустили бы к такому проекту по причине отсутствия необходимых навыков.
Всё это сильно тормозит развитие проекта. При наличии законченной версии SDK и готового компилятора команда из 4-х человек, работающих над проектом full-time уже давно закончила бы намеченное.
В общем, сравнение ты привёл в высшей степени некорректное.
E>Поэтому и бывает, что человек пишет код всего-то неделю, каждый день выдавая по 200-300 строк отлаженного кода (а с учетом комментариев и тестов так вообще по 500-700). Но, если затем подбить статистику за пару-тройку месяцев, то и выходит, что производительность оказывается на уровне 20-50 строк в день.
Брукс пишет о состоянии дел на момент, когда в технологическом процессе разраработки ПО присутсвовали ещё такие персонажи как девочки-перфораторщицы. Фактически они и выполняли роль IDE. Сам по себе процесс набивки кода состоял из множества итераций: принёс клочок бумаги, получил колоду перфокарт, прогнал колоду, получил листинг с ошибками, принёс клочок бумаги.
Кстати, там разве были средние 20 строчек в день? Не максимум?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, VladD2, Вы писали:
E>>>А можно мне вот такую загадку объяснить: вот пишете вы вызов метода и hint вам подсказывает, что в метод требуется передать пять параметров. Откуда вы их возьмете, если вызов метода уже начали писать, но про параметры этого метода не знали (т.е. не представляли ни их количества, ни назначения, ни формата, ни допустимых даипазонов)?
демонстрация того как это сделано в лучшей среде разработки для JAVA -IDEA
Здравствуйте, konsoletyper, Вы писали:
K>К слову. Если я не ошибаюсь, то интеграция пишется без использования IDE (кстати, а кто что использует?).
Так и есть. Интеграция слишком сырая и есть проблемы с самоблокировкой.
K> Вот когда интеграция будет писаться на интеграции, тогда и посмотрим, какая будет производительность (хотя объективно её оценивать нельзя по вышеназванным причинам).
Именно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, konsoletyper, Вы писали:
K>А если по делу, то мне непонятно, зачем одновременно пользоваться утилитами командной строки и IDE, если есть IDE?
Ну, это как раз просто. Надо, например, собрать проект в пакетном режием. Запускаем простой скрипт вызываютщий скажем МСБилд или Ант.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
EC>На мой взгляд великолепная демонстрация того, где рулит динамика. EC>Мне даже стрёмно думать сколько кода на статике надо написать, чтобы получить тот же результат. EC>И никакие инелисенсы не помогут, с комплишенами.
EC>Интересно, как эту задачу можно решить чисто виндовыми средствами, не привлекая тяжёлую артиллерию? EC>На VBScript будет выглядеть ужасно (как раз сегодня правил деплоймент скрипты). EC>Monad shell (не видел ещё)?
А могут господа несогласные аргументироавть своё несогласие кодом на статически типизированном языке, который рвёт в клочья вышеприведённый вариант?
Здравствуйте, IT, Вы писали:
IT>Всё это сильно тормозит развитие проекта. При наличии законченной версии SDK и готового компилятора команда из 4-х человек, работающих над проектом full-time уже давно закончила бы намеченное.
IT>В общем, сравнение ты привёл в высшей степени некорректное.
Мне кажется ты упустил самую суть которую тут ужен подметил Хропов. еао197 провел все эти вычисления с целью доказать то что IDE не оказывает видимого эффекта на производительность друда. Но вот одна заковыка. При разработке именно этого проекта как раз IDE используется исключительно как редактор кода с подсветкой синтаксиса и встроенным движком сборки проекта. Так что сравнание не только не корректное, но и бессмысленное.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
EC>>Так в этом и была суть моего вопроса. Просто куча народа в том треде кинулась приводить код на C# для решения этой задачи.
VD>Не скажу за кучу. Синклер тебе продемонстрировал, что даже без наличия библиотеки решение не так уж и сложно. Я тебе рядом где-то сказал, что некорректно сравнивать использование гтовой утилиты и универсальный код решающий ту же задачу.
Я именно это и пытался сказать, но люди с завидным упорством настаивали, что C# тут лучший выбор.
Вопрос не в том, что оно не так уж сложно, вопрос в том, что оно явно избыточно, если есть grep.
Для меня оно вообще тривиально, но тем не меннее я не стану так делать, потому как есть более эффективные способы потратить своё время.
Куда делись все, когда я привёл чуть более сложную задачу, которая решается тривиально средствами unixutils со своими вариантами на C#?
EC>>То, что её можно на нём решить сомнений не вызывает. Вызывает сомнения целесообразность её решения этим способом.
VD>В начале разговора речь шала о возможностях шел-скриптов по сравнению с полноценными ЯП. Никто так и не продемонстрировал приемуществ именн шел-скриптов. Вместо этого тема была подменена рассуждениями о возможностях утилит вызваемых из этих скриптов. Тебе не кажется что это несовсем нормально?
Речь шла о вполне конкретной задаче. Приведённые примеры её решения на C# никак меня не убедили в том, что есть смысл решать её таким способом.
EC>>В общем я возражал, что статика во всех задачах даёт преимущество — думаю некоторых убедил.
VD>Думю, что ты и себя то не убедил ни в чем. О какой вообще статике или динамике можно вести речь, если в ход пошла пенесометрия в области говтовых решений (вроде утилит или библиотек)?
Мне себя убеждать не надо — я могу и на grep'е и на C# (т.е. как минимум я могу реально сравнить т.к. имею опыт и там и там).
VD>Давай тогда уж изменим условия. Напрмер, поставим задачу прочесть хмл-файл с чем-то и запишем из него некоторые данные в БД. Уверен, что шел-скрипты и любые утилиты будут тут бесполезны.
Они для этого не предназначены и никто их для этого не позиционирует.
В лющем проблема этой дискуссии в том, что противники unixutils в основной массе не имеют опыта работы с ними, но тем не менее спорят, видимо из принципа.
Здравствуйте, PhantomIvan, Вы писали:
PI>а ты сравни код для шелла с кодом на немерле по объёму там — примерно те же яйца, только в профиль
Понимаешь в чём проблема, шелл скрипты имеют ограниченную область применения, эту область пытаются озвучить.
Т.е. зачастую разовые задачи, которые легко и просто решить в коммандной строке и забыть.
Но некоторые передёргивают и пытаются преподнести это так, как будто им предлагают писать EJB компоненты на bash.
Здравствуйте, konsoletyper, Вы писали:
K>самым теряя время), если тут же можн посмотреть порядок?
Еще один:
Integer number = new Integer(
Я вот прекрасно помню, что он примет число какое-нибудь (0, 7, по вкусу). Зачем мне забивать голову еще чем-то, что мне не нужно? И также кнопки нажимать Ctrl-Space? И также зачем ему автоматически выпадать, место при этом занимая?
С другой стороны, я не знаю, смогу ли я задать ему число 7876145108764357664398098457767650976032545430763460099876134563495876134509513248765098. И в контекстной справке про это тоже ничего не говорится.
Еще пример?
jContentPane = new JPanel();
jContentPane.setLayout(new BorderLayout());
jContentPane.add(getJTabbedPane(), BorderLayout.CENTER);
Я вот прекрасно помню все конструкторы класса BorderLayout (не хотел запоминать, оно само) и также знаю все методы add для класса JPanel. Вот только как это мне поможет для достижения желаемого результата? Только чтение документации. Которая благо, по Shift-F2 выскакивает (Вот это I так I).
Здравствуйте, IT, Вы писали:
TBG>>Дебаг (это зло) тоже приятнее из IDE. IT>И чем же тебе дебагер не угодил
Не угодил тем, что интегрированный отладчик позволяет незатейливо фокусирать разработку на уровень Runtime. То есть грубо говоря, пишется как получится, а в отладке исправляются последствия недоодумок.
Здравствуйте, konsoletyper, Вы писали:
K>А если по делу, то мне непонятно, зачем одновременно пользоваться утилитами командной строки и IDE, если есть IDE? Зачем пользовать vim, если есть Eclipse, MinGWDeveloperStudio, SharpDevelop, а для простейших нужд по модификации текста с головой хватит gedit (или kate, кому как нравится).
А давайте произнесем это по другому. Зачем пользоваться Eclipse, MinGWDeveloperStudio, SharpDevelop, если есть vim? Если нужно произвести редактирования текста? И не более того? Почему не kate и gedit? Потому что не привык я к ним. Мне проще vim. И удобнее, и продуктивнее. Да и не умеет kate lisp форматировать как мне нравится.
K>Естественно, система, которую мы поставляем клиентам, ведёт лог, и мы клиентов постоянно просим эти самые логи нас выслать (особенно, если от клиентов поступают жалобы на ошибки). Но и тут, поняв по логам, что может вызывать ошибку, мы садимся и ковыряемся в подозреваемых методах интерактивным отладчиком.
А мы пишем вот так (приблизительно, конечно, см. ниже), получаем логи, анализируем. Исправляем. Когда не хочется думать, а просто посидеть, поразмышлять о вечном, то тогда чашечка чая, интерактивная отладка. За последнее время интерактивну отладку использовал только в том случае, когда в программке не разбирался совсем (досталась по наследству), а производить статический анализ не хотелось (потому как надо было один лишь момент поправить и, скорее всего, о программке то и забить).
Здравствуйте, PhantomIvan, Вы писали:
PI>а у тебя автоматизирован компайл в нём? PI>(чтоб рядом dvi всегда отображался актуальным, и не нужно было каждый раз компиляцию жать)
В TeX автоматизированный компайл и не нужен, ведь это логическая разметка текста, а не верстка календарика. И зачем каждый раз компиляцию жать? Ведь это надо по сути в конце только. Или в промежутке когда устал, хочется чем-то позаниматься отвлеченным. А вообще, TeX посмотрите. Или docbook, если нравится.
Здравствуйте, VladD2, Вы писали:
VD>Вызваешь свою "среденй сложности функцию" в разных ячейках с разными параметрами и строишь график по этим точкам. Если очень хочется
Если заранее известно, что на этом диапазоне "средней сложности функция" гладкая..
Если нам не помогут, то мы тоже никого не пощадим.
