Здравствуйте, thesz, Вы писали:
Cтранно, вроде отвечал на это сообщение сразу же, "видимо что-то случилось" (C)
------------
T>Я практически четыре года подряд пишу программы, алгоритмы которых не знаю. Представляешь, каково это — ловить алгоритмические ошибки в программе, алгоритм которой ты толком не представляешь?
Согласен, здесь "что-то не так" (используя печатные выражения).
T>Ну, задача у тебя такая — разработать алгоритм. Это означает, что его изначально нет или он описывается кругами разводимых рук.
А здесь всё так, как и положено. В отсутствие выделенного аналитика его ф-ии берут на себя сами разработчики — вполне стандартная ситуация для небольших колективов. Вникать в предметную область и общаться с заказчиками на его языке — это вполне нормально, а вот ситуация из первого абзаца — нет. Отложи кодирование, займись анализом и всё станет на свои места.
T>"Размеры современных проектов"
T>Скажи лучше, плохая структуризация современных проектов. Ничего отрезать невозможно.
Т.е. наболело?
В своей команде вполне аргументировано ты можешь проталкивать необходимые улучшения модульной структуры, а здесь это суть гадание на кофейной куче и к процессу отладки относится мало. Большие размеры современных проектов — это объективная реальность, и эти размеры растут в последние годы очень быстро. Собс-но, для этого мы, программисты, и нужны, чтобы автоматизировать как можно больше аспектов человеческой деятельности.
Сам этот заметный рост сложности проектов стал возможен только благодаря высокоуровневой поддержке ср-в разработки.
T>Дорогой друг, какое конкретно количество строк написал ты или любой твой коллега на любом ФЯ?
На Схеме несколько тысяч в своё время, включая сам мини-интерпретатор Схемы.
T>Если это количество больше 100, я продолжу спор, но уже доказательно. Если меньше, то поверь мне на слово — ты не прав. Ты просто не в курсе, как нельзя накосячить на ФЯ.
Знаю, но ты не то называешь косяком. Т.н. "косяки", связанные с низкоуровневыми ошибками, типа проходу по памяти, — это самый низкий процент ошибок в современных проектах, к тому же, эти места легко вычисляемые. Большинство ошибок (по моему опыту) — это именно ошибки алгоритмического плана. Вообще, надо признать, что вообще само по себе кол-во ошибок стало смехотворным на единицу строк кода в последние годы, ИМХО это от всё меньшей доли самописных велосипедов в проектах, даже на С++. (Еще лет 10 назад каждый проект состоял примерно на 80% из самописанины библиотечно-фреймворкового уровня). Рождая по 300-500 строк кода в день, никакой разработчик не в состоянии помнить подробности даже собственных творений уже спустя пару месяцев. "Тупой" код-ревью на таких объёмах банально не прокатывает для задачи локализации ошибок, юнит-тесты на все случаи не напишешь (да и не надо), поэтому нужны эффективные ср-ва для целей этой самой локализации. У нас в проекте VoIP, где всё происходит в динамике и точу останова не везде поставишь таким ср-вом является многоуровневое логгирование (т.е. регулируется вербальность логов по мере уточнения локации косяка).
T>За более, чем 10 лет использования Хаскеля, я столкнулся всего с двумя ошибками: проблемы рантайма под windows в ghc 6.6 (ограничение сверху на хип) и, недавно, совершенно не критичная ошибка с отсутствие поддержки семейств типов в template haskell.
Поражает даже не кол-во багов на треккере GHC, а их характер. Можешь объяснить наличие большого кол-ва низкоуровневых багов в треккере, учитывая, что сам компилятор написан на Хаскеле?
Т.е. ситуация такова, что сам этот момент у меня пока в голове не укладывается... Сам язык получился неплох, но от задумки до реализации, как известно...
А помогать им с отладкой... было бы ради чего — там помимо низкоуровневых, куча ошибок и логического плана и даже вывода типов. Вообще, кол-во багов поражает. Я как-то нашёл баг для библиотеки ADO.Net под MS SQL CE, запостил, мне сказали спасибо, дык баг был единственный (!!!) на всю либу. Просто сценарий у нас был, прямо скажем, далеко не рядовой (выжималка процессорных тиков для около-ИИ-темы). И вот я со своими далеко не рядовыми сценариями (где надо выжимать максимум из железки) полезу в Хаскель, начну его "выжимать" и он однозначно начнёт сыпаться. В общём, серьёзнее быть надо. Увлечение-увлечением, а дело надо делать сегодня на сегодняшних инструментах... Я даже любимый когда-то С/С++ не очень в критических местах юзал, ибо еще в 92-м нарвался подряд на 3 встроенных в Борландовский С++ бага в первом же более-менее крупном проекте, дособирали на ваткоме, но без IDE это было не то... После чего забросил C++ до 97-го года примерно, до выхода IDE от MS. Дальше рассказывать? На чём приличное кол-во внутренних тулзов у нас было сделано? На Форте и на VB for DOS. Про последний надо подробно, ибо к VB приклеился определённый образ у рунета. Так вот, вначале его использования я любил просматривать ассемблерный лог компиляции VB-программы (есть такая опция у компилятора), и должен сказать, что компилятор генерил прекрасный код. Мне, как ассемблерщику со стажем, по крайней мере очень нравилось. Везде, где раньше бы применялся Фортран (много было расчётных задач), мы юзали VB for DOS, благо и формы с кнопками быстро накидать можно было. В общем, рабочая лошадка, в которой нечему ломаться (и ни разу так ничего и не сломалось за 3 года плотного использования). Так что, к выбору инструментария у меня подход весьма прямолинейный — необходимо чтобы сам инструментарий не веселил своими причудами, ибо не до него.
