Здравствуйте, konsoletyper, Вы писали:
K>Я же, может быть, не совсем корректно выразил мысль в одном из постов, но это только из-за того, что на меня хлынул поток демагогии и немного меня дезориентировал.
Здравствуйте, konsoletyper, Вы писали:
K> !!! Вот мне, сирому и убогому кодеру что-либо, кроме VS2005, и открывать-то старшно. Воистину, респект!
Ничего, у Вас еще все впереди. А по делу что-нибудь сказать можно?
TBG>>Отладка может несколькими путями делаться. В том числе и интерактивно, где нужен отладчик. Удобно, если встроенный. Но это не единственный путь. K>Какие же ещё есть пути?
Здравствуйте, IT, Вы писали:
E>>Последние среды, которыми я пытался пользоваться более-менее серьезно, были VS 6.0 и CodeGuide 3.0 (или 4.0, не помню), в 2001-м году. Причем VS 6.0 меня настолько задолбал, что я сначала выключил в нем все подсказки, а затем и перестал пользоваться вообще.
IT>Разве в VS 6.0 были подсказки?
Автокомплит, который определял по типу переменной список доступных методов точно был. Очень глючил или вообще отказывался работать на шаблонах. Не помню про tooltip-ы при наведении курсора, но по правой кнопке точно выпадало меню, из которого можно было перейти на декларацию/реализацию и получить список свойств выделенной сущности.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, IT, Вы писали:
E>>* есть набор фундаментальных понятий, которые должны отложиться в подкорке (или речь вообще не должна идти о знании языка). Например, в C++ элементарно запоминается, что у большинства контейнеров есть push_back, а у ассоциативных -- insert.
IT>Неужели ты всерьёз полагаешь, что те, кто здесь общаются с тобой не понимают такие элементарные вещи? Конечно же, нужны фундаментальные понятия, конечно же, они у всех у нас в подкорке, конечно же, некоторые вещи элементарно всеми нами запоминаются и усваиваются. К чему вообще это глубокомысленная банальность?
К тому, что в качестве демонстрации крутости autocomplete приводятся вот такие банальности.
IT>Поверь мне на слово, качество кода вполне коррелирует с качеством IDE.
Не поверю.
IT>Подсказки, как минимум не мешают.
Лично мне мешали, а я здесь говорю не за "народ", а за себя.
IT>Очень помогают подсказки, когда надо разобрать с незнакомым или забытым кодом.
Это может быть, но изначально я спрашивал про написание кода.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, IT, Вы писали:
E>>Если еще и разделить на количество учавствующих в проекте разработчиков, то получится еще меньшее значение.
IT>Да, и ещё в качестве конкретного примера по конкретному подсчёту строк. Вчера я потратил около часа на то, чтобы найти в компиляторе багу, исправить её и проверить, что ничего не сломалось. В результате была изменено строчек кода — один, добавлено новых строчек кода — один, добавлено строчек с коментариями — три. Больше я вчера ничего серьёзного по проекту не делал. Надеюсь ты учтёшь это как-нибудь в своих расчётах.
Игорь, блин, ты же сам сейчас сказал самую суть -- при разработке проекта далеко не всегда приходится писать код. Есть еще масса вещей, которые отвлекают разработчиков от кодирования: документирование, тестирование, митинги с другими разработчиками, участие во внедрении, консультации со службой техподдержки, поиск узких мест и оптимизация... Не знаю как в больших командах, где роли участников строго регламентированы, но я уже больше десяти лет работаю в небольших коллективах, где такого разделения нет, каждый разработчик участвует во множестве связанных с проектом задач.
Поэтому и бывает, что человек пишет код всего-то неделю, каждый день выдавая по 200-300 строк отлаженного кода (а с учетом комментариев и тестов так вообще по 500-700). Но, если затем подбить статистику за пару-тройку месяцев, то и выходит, что производительность оказывается на уровне 20-50 строк в день.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, Курилка, Вы писали:
К>>Глобально удобнее? К>>А ты не думаешь, что всё зависит от конкретной задачи? К>>Допустим мне нужно найти опр. строку в логе на серваке под солярисом, куда есть только ssh? Причём задача "разовая", т.е. критерии для поиска, файл и т.п. — вещь ситуативная и "сделал/выбросил". К>>Как ты будешь решать такую задачу?
K>Мы кажется про языки говорили в аспекте их использования программистами. Так вот, такая задача — она не столько программерская, сколько админская. Я же не призываю каждого пользователя пользоваться IDE.
Т.е. ты только программист и ни за что другое браться не будешь?
Просто банально — происходит что-то в написанном тобой софте и тебе надо разобраться в ситуации (тупо глянуть в лог).
Понимаю, условия специфические, но о том и была речь.
Здравствуйте, VladD2, Вы писали:
E>>Вот я сделал только что svn export http://nemerle.org/svn/vs-plugin/trunk E>>Затем подсчитал количество непустых строк во всех *.cs/*.n файлах (чуть больше 20K) и разделил на количество дней, прошедших с 2005-05-07 (это дата сообщения: Содержимое SVN://RSDN/Nemerle
). Получилось, что за один день писалось всего 90 строк:
VD>А ты учел, что мы работаем над проктом в свободное от основной работы время? А то что первое время проект писал я в одну что называется харую? А то что большиую часть времени лично я трачу на то чтобы разобраться в компиляторе и подправить его так чтобы он делал то что нужно?
Здесь не учтено очень многое. Например, это тупой подсчет не пустых физических строк (с комментариями, переносами длинных выражений и пр.) Логические же строки кода, AFAIK, считаются более жестко и их окажется гораздо меньше.
Далее, не нужно упускать из виду, что разработчики коммерческих проектов тратят не меньше времени на то, чтобы разобраться в своей предметной области и в унаследованном коде или с 3rd-party библиотеками. А иногда еще и на длительные выяснения конкретных желаний пользвателей.
И еще один фактор -- работа для себя, для собственного удовольствия, некоторыми считается (и с ними я согласен) гораздо более продуктивной, чем работа на "дядю" от звонка до звонка.
Так что не смотря, что этот подсчет был очень грубым и приблизительным, его корреляция с действительностью гораздо сильнее, чем кажется.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Ну да. Принцип помнит, но немного подзабыл.. Если уже работал и работает, он даже сам не знает что подставлять надо — все само подставляется. Если чуток подзабыл, то ой.. Подсказки не подсказки, вот цитаты из разделы справки — это то, что я ценю в IDE (можно быстренько по диагонили пробежаться и вспомнить). Дополнения разные, ну разве что при хитром комплите по большим буквам тоже удобно. Ну еще универсальная Ctrl-1 в Eclipse. TBG>Но если человек ни с технологией не работал, ни толком то не программил, то по "." начинает гадать и додумывать, что этот метод делает. Ну тоже хорошо, конечно, в определенных ситуациях..
Привести конкретный пример?
public Region[] MeasureCharacterRanges (
string text,
Font font,
RectangleF layoutRect,
StringFormat stringFormat
)
Я вот прекрасно помню, что в stringFormat должны быть заданы измеримые интервалы, что их число не должно превышать 32, что регионы потом нужно явно уничтожать, но я ни за что не запомню (зачем память забивать), в каком порядке идут параметры. Так зачем мне лезть в справку (тем самым теряя время), если тут же можн посмотреть порядок?
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Ничего, у Вас еще все впереди. А по делу что-нибудь сказать можно?
А если по делу, то мне непонятно, зачем одновременно пользоваться утилитами командной строки и IDE, если есть IDE? Зачем пользовать vim, если есть Eclipse, MinGWDeveloperStudio, SharpDevelop, а для простейших нужд по модификации текста с головой хватит gedit (или kate, кому как нравится).
TBG>>>Отладка может несколькими путями делаться. В том числе и интерактивно, где нужен отладчик. Удобно, если встроенный. Но это не единственный путь. K>>Какие же ещё есть пути?
TBG>Отладка логированием, к примеру.
В смысле? Вывести что-то на консоль или в файл и посмотреть, какие данные выводятся? Я вот так же часто отлаживаю GUI-контролы, потому что по понятным причинам брейкпоинты на них не наставишь. Потом смотрю, что вывелось, и если действительно, что-то пошло не так, я уже могу приблизительно сказать, где ошибка. Потом я беру подозреваемый метод, пишу в него что-то вроде
if (бла-бла-бла)
{
Console.WriteLine("ё-моё!")
}
и ставлю на второй строке брейкпоинт. А дальше уже идёт интерактивная отладка.
Естественно, система, которую мы поставляем клиентам, ведёт лог, и мы клиентов постоянно просим эти самые логи нас выслать (особенно, если от клиентов поступают жалобы на ошибки). Но и тут, поняв по логам, что может вызывать ошибку, мы садимся и ковыряемся в подозреваемых методах интерактивным отладчиком.
VD>А ты учел, что мы работаем над проктом в свободное от основной работы время? А то что первое время проект писал я в одну что называется харую? А то что большиую часть времени лично я трачу на то чтобы разобраться в компиляторе и подправить его так чтобы он делал то что нужно?
VD>Фактически над проектом долгое время работали двое, а то и вообще один человек и не полный работчий день. Так что цифру 90 можно смело умножать на 4. Плюсь еще надо понимать, что код на Немерле зачастую в 2-4 раза компактнее аналогичного Шарповского. Вот и получается, что 20 строк в день это сильно заниженный результат. А точнее просто ахинея. Так просто нельзя считать.
К слову. Если я не ошибаюсь, то интеграция пишется без использования IDE (кстати, а кто что использует?). Вот когда интеграция будет писаться на интеграции, тогда и посмотрим, какая будет производительность (хотя объективно её оценивать нельзя по вышеназванным причинам).
Здравствуйте, IT, Вы писали:
IT>Женя, при всём моём к тебе уважении я тебя и в правду скоро забаню за подобную хрень И не жалко же собственного времени?
Экспорт из репозитория по dial-up занял гораздо больше времени.
IT>У меня как-то был один проект, в котором общее количество строк при его сопровождении и добавлении новых фич неумолимо уменьшалось. Хобби у меня такое — переписывать откровенный бред, своего писать как можно меньше и отжимать из кода всё лишнее. По-твоему получается я писал по -20 строк в день?
По-моему получается, что если подсчитать среднее количество строк в день, написанных за год (например, как банальную разность между объемом проекта в начале года и в конце), то показатель будет не большой. Именно за счет того, что рефакторинги способствуют уменьшению объема кода и далеко не все время разработчики тратят на кодирование.
Статистика, которую приводят Брукс и МакКоннел именно это и отражает, но не объясняет почему так происходит.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VladD2 wrote: > R>Особенно очевидно это мне на задачах, для которых упомянутый язык плох, > R>так как вдаётся в детали. График можно быстро построить в maple, octave > R>или на J, но не пользоваться же для этого языком общего назначения. > > Смотря где данные берутся, как обрабатываются и какой сложнсоти нужен > графиг. В простых случаях все что ты перечислил будет оврекилом, так как > на Excel-е это будет куда проще. А в сложных как раз отлично подойдет
Гм, как я туда введу средней сложности функцию? Я просто представляю
себе как там построить график по имеющимся точкам, но вычислить....
К тому же, excel тяжелее по любому параметру, чем названные мной вещи.
> язык общего назначения. Благо графики вручную рисовать не надо. Для > этого есть компоненты.
Но надо эту компоненту указать, создавать массив значений — или
передавать точки в цикле.
> R>Быстро провести подсчёт вхождений слова в файл удобно в vim или на > R>shell, но не пользоваться же для этого языком общего назначения — это > R>будет длиннее. > > shell такими возможностями не обладает. А фукнцию по фигу где вызвать.
Ваше стремление отделить shell от положенных с ним по стандарту и всегда
с ним наблюдаемых утилит заслуживает восхищения. > Даже в shell менее удобно.
Покажите мне такую библиотеку для чего-то кроме shell... Насчёт удобства
— спорный вопрос, для краткого указания опций нужен язык (если брать
универсальный), поддерживающий symbols, скажем, Схема.
> В простейшем случае же конечно проще воспользоваться приложием где > подсчет слов уже есть. Например тем же VIM-ом или Word-ом. У меня VIM-а > нет, но мне Word-а хватает.
А по regexp он умеет?
> R> Выборки из базы данных со сложными условиями пишутся на > R>разных диалектах SQL, не пишут же их на языках общего назначения... > > Понятно, что если есть мощьный ДСЛ, то применять универсальные языки > глупо. Вот только shell не есть ДСЛ. Это как раз убогий универсальный > язык. Причем очень убогий. И спасают его только библиотеки в виде утилит.
Почему Вы не считаете shell DSL? Какое Ваше определение DSL?
konsoletyper wrote: > TBG>Ничего, у Вас еще все впереди. А по делу что-нибудь сказать можно? > > А если по делу, то мне непонятно, зачем одновременно пользоваться > утилитами командной строки и IDE, если есть IDE? Зачем пользовать vim, > если есть Eclipse, MinGWDeveloperStudio, SharpDevelop, а для простейших > нужд по модификации текста с головой хватит gedit (или kate, кому как > нравится).
Для набора ТеХ мне нужен нормальный редактор. Переносимый между всеми
платформами, желательно. Так что явно ViM или Emacs мне уже нужен. Ну а
дальше явно его надо настроить — значит, использовать блокноты для
мелкой правки уже не хочется. А дальше граница мелкой правки может
покрыть или нет написание всей программы.
VladD2 wrote: > R>grep something file | sort -k 1n | uniq -c > > R>Имеем 3 библиотечных функции. И удобный метод их скомбинировать. Который > R>не требует — для больших файлов — выделять память по размеру всего файла. > > Сортировка один фиг не возможна без полного считывания. Выбор уникальных > значений тоже.
Выбор уникальных значений не требует. Так что полное считывание
понадобится один раз, а не в двойном объёме.
> Функции могут возвращать итераторы. Так что проблем с объемом памяти не > будет. И выглядить это будет примерно так: > > grep.Something(file).Sort().Uniq() > > R>Как этот метод комбинации функций добавляется в С# из .NET 1.1? > > Так же как и 2.0. На входе и выходе энумераторы. Конечно с дженериками и > итераторами было бы чуть удобнее, но не суть важно.
А, то есть хоть какое-то подобие функциональных возможностей там имелось
сразу.
> R>Но некоторым обработка текста нужна. > > Может и нужна. Сделают бибоиотеку или надыбают готовую. Греп тоже не > часть скриптового языка. И его тоже качать надо.
Скачать bash и не скачать grep — нетрудно. Но это надо хотеть.. В
busybox grep и sed встроены, дальше что...
> R>И так много лет.. В таком случае надо продвигать хотя бы то, что есть - > R>чтобы люди не мучались. > > Проще создать управляемую библиотеки с возможностями грепа. Благо весь > функционал уже есть.
Что-то мне подсказывает, что нескоро будет такая библиотека, удобная
именно для
one-liners и one-screeners. К тому же толку с ней, если mono — это
довольно много места, и под unix-like его ставить ленятся, а под виндой
большинство всё равно начнёт с поиска в FAR (ну или в TC). Так что
хвалить чудо природы будет некому.
EC>Так в этом и была суть моего вопроса. Просто куча народа в том треде кинулась приводить код на C# для решения этой задачи. EC>То, что её можно на нём решить сомнений не вызывает. Вызывает сомнения целесообразность её решения этим способом.
а ты сравни код для шелла с кодом на немерле по объёму там — примерно те же яйца, только в профиль
теперь смотри, был у меня небольшой скрипт, выполняющий некоторые операции с файлами
я начал в него добавлять что-то, потом опять что-то, потом ещё чуть-чуть...
— проверку файлов на целостность (сначала для одного типа, потом для другого) — легкую
— проверку на целостность тяжёлую — по хэш суммам
— манипуляции с перемещением/удалением разрушенных файлов
... потом стал подключать скрипт к проге, которая эти файлы реально с инета тянет...
потом потребовалось чуть навернуть скрипт, потом прогу, потом скрипт, потом прогу
скрипт, потом прогу, потом скрипт, потом прогу
скрипт, потом прогу, потом скрипт, потом прогу
потом выяснилось, что регекспы мои тормозят, пришлось из скрипта их вынести в прогу, и оптимизировать обычным парсингом
...
в результате получился скрипт на 500 строк, и программа на 1000 строк
внимание, фокус — весь этот геморрой я упростил, начав сразу писать "скрипт" на немерле — да, именно эти первые 30-70 строчек
потом на "скрипт" собственно, и начал наворачивать функциональности
— итого, вывод, если мне нужно то, что можно сделать быстро простыми манипуляциями в фаре (FAR manager), делаю это там, если не всё так просто — сразу пишу на немерле (раньше на сишарпе писал то же, но это несколько более многословно получалось)
...
если хочешь заценить "скриптец", в нем сейчас где-то 1.5 тысячи строк, лежит он как подопытный кролик (TestProjectOne) на репозитории nemerle.org (проект интеграции)
E>Здесь не учтено очень многое. Например, это тупой подсчет не пустых физических строк (с комментариями, переносами длинных выражений и пр.) Логические же строки кода, AFAIK, считаются более жестко и их окажется гораздо меньше.
а ну ка, я попрошу скриптец с обсчётом других метрик...
вложенность там средняя... количество методов на класс...
и чтоб чекпоинты во времени сохранялись в файлик
слабо?
упрощенный аналог вот этого типа
K>К слову. Если я не ошибаюсь, то интеграция пишется без использования IDE (кстати, а кто что использует?).
ошибаешься
лично я пишу интеграцию на интеграции, пользуюсь подсветкой, автокомплитом, хинтами, поиском вхождений и прочими радостями жизни
когда готов некоторый апдейт к функциям среды, я закрываю (экспериментальную) студию, ребилжу, и открываю снова
можешь догадаться, некоторые функции глючат — это и есть хорошо — тестинг не отходя от кассы
кроме того, для своего "поиска вхождений" я налабал тестовый фреймворк, так что закрывать экспериментальную студию вообще не нужно — запускаю тесты сразу из иде и дебажу
фреймворкчик этот будет работать и для других функций
K> Вот когда интеграция будет писаться на интеграции, тогда и посмотрим, какая будет производительность (хотя объективно её оценивать нельзя по вышеназванным причинам).
ну, можешь попросить любителей башей получить метрики чисто по моим апдейтам
И не жалко же собственного времени? 
