T>>Я практически четыре года подряд пишу программы, алгоритмы которых не знаю. Представляешь, каково это — ловить алгоритмические ошибки в программе, алгоритм которой ты толком не представляешь?
V>Нет, совершенно не представляю (идиотская ситуация, согласен), но не суть — громкое заявление ты сделал не на этот счёт. Ладно бы ты еще упёрся именно насчёт пошаговой отладки, я бы и не встрял, ибо само существование спора "пошаговая отладка vs отладочная печать" с моей т.з. — пример наличия идиотизма в нашей профессии. Мне этот спор не интересен. Но отказаться от отладки как таковой в любом её проявлении — это для меня открытие.

Этот спор тебе интересен. Ты его продолжаешь.

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

Посмотрим.

T>>Дорогой друг, какое конкретно количество строк написал ты или любой твой коллега на любом ФЯ?
T>>Если это количество больше 100, я продолжу спор, но уже доказательно. Если меньше, то поверь мне на слово — ты не прав. Ты просто не в курсе, как нельзя накосячить на ФЯ.
V>Спасибо, за лестное звание друга. Очень не люблю количественные вопросы, но на схеме писал прилично, собственно, как и самописный мини-интерпретатор схемы тоже имеется. Бока в другом: тщательно изучил в своё время более 20-ти (!!!) исходников популярных лиспов и схем на предмет реализации замыканий, потому как оно где byvalue, а где-то byref (byname). Самое интересное, что все эти виды замыканий имеют право на существование, но они имеют разную семантику (разную модель), и отсюда несовместимость и косяки отлаженного исходника при смене платформы.

Что ты мне в качестве примера приводишь всё самое плохое, что есть в мире ФЯ?

Приводи всё самое хорошее.

Хотя бы ML возьми, если Хаскел не хочешь.

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

Современные ФЯ дают гораздо больше. Я, например, написал DSEL для описания ядер (аппаратуры), там в систему типов Хаскеля вынесены проверки размерности получаемых результатов. Да, это доступно на плюсах, но более громоздко и менее прямо.

T>>За более, чем 10 лет использования Хаскеля, я столкнулся всего с двумя ошибками: проблемы рантайма под windows в ghc 6.6 (ограничение сверху на хип) и, недавно, совершенно не критичная ошибка с отсутствие поддержки семейств типов в template haskell.
V>Знаешь, меня даже не кол-во багов смущает в багтрекере ghc, а их характер. Ведь компилятор написан на Хаскеле! Ладно бы на С, как же так? (10 раз "ай-ай-ай"). Ты ведь не первый здесь Хаскель хвалишь, за последние годы было много рекламы такого плана.

1) Библиотека времени выполнения написана на Си.
2) ghc очень большой. Его поддерживает всего ничего человек, около 10. И при этом я встретил всего две ошибки несмотря на его выбор в качестве основного ЯП.

Для сравнения. Над icc трудится что-то около тысячи человек по всему миру.

Поэтому проводи повторный анализ.

V>И что характерно — по большей части в хамоватом тоне.

Если тебе не нравится мой тон, не общайся. Если тебе не нравится мой тон, не делай Gлупых ошибок.

V>То, что ты с чем-то там не столкнулся — это еще ничего не значит. Я, например, несколько лет использовал ADO для Compact SQL от MS, а потом, в одном из сценариев, обнаружил грубейший баг, о чём запостил, получил в ответ "спасибо", но баг был единственный на всю эту либу, а там море interop-a и прочей явной реинтерепретации памяти. Так что, не только в технологиях серебрянная пуля зарыта, она в первую очередь зарыта в организации работ, в ресурсах, в контроле кач-ва и т.д.

И не допускай non sequitur и смешения понятий.

Серебренная пуля относится только к ЯП. Всё остальное к выбору ЯП ортогонально.

V>Мой поинт такой: за Хаскель было сказано уже слишком много на этом сайте. Кому надо, тот давно понял. Если бы у меня были подходящие задачи, я бы им, наверно, пользовался поактивней. А так у меня то возня с WinAPI, то VoIP. То по размеру программ ограничения идут, то сверхжёсткие по быстродействию... и на фоне этого меня улыбает твоя постоянная мантра о "несвоевременной оптимизации".

Да ты ж оптимизируешь без огонька и без особых рассуждений.

"Тут у меня сверхжёсткие ограничения на быстродействие, надо оптимизировать". И ну профайлер гонять.

Придумать что-то за рамками этого ты не в силах.

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

V>Знал бы ты, сколько тяп-ляп кода лежит у нас в местах, которые не критичны в плане ресурсов. Как говорится, знаю, как сделать эти места лучше, не знаю — зачем.

Чтобы кода было меньше.

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