Здравствуйте, Шахтер, Вы писали:
Ш>люди знали, как писать маленькие, эффективные программы -- навык, который впоследствии был утерян. (с) Таненбаум.
В доказательство:
I've always been amazed at the Apollo spacecraft guidance system, built by the MIT Instrumentation Lab. In 1969, this software got Apollo 11 to the moon, detached the lunar module, landed it on the moon's surface, and brought three astronauts home. It had to function on the tiny amount of memory available in the onboard Raytheon computer--it carried 8 Kbytes, not enough for a printer driver these days. And there wouldn't be time to reboot in case of system failure when the craft made re-entry. It's just as well Windows wasn't available for the job.
Здравствуйте, Шахтер, Вы писали:
Ш>люди знали, как писать маленькие, эффективные программы -- навык, который впоследствии был утерян. (с) Таненбаум.
Интересно было бы выяснить причины утраты такого навыка.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Только справедливости для: Оберон-система включает в свой состав post-mortem debugger.
Необходимая для отладки информация может храниться в специальной незагружаемой части модуля.
Думается, Вирт все же имел в виду пошаговый отладчик, в чем я с ним полностью согласен: не припомню, когда я нуждался в таком инструменте.
По моим наблюдениям, пошаговый отладчик — всего лишь способ убить рабочее время с умным видом.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Шахтер, Вы писали:
Ш>>люди знали, как писать маленькие, эффективные программы -- навык, который впоследствии был утерян. (с) Таненбаум.
AVC>Интересно было бы выяснить причины утраты такого навыка.
Я думаю что основная вина лежит на разработчиках микропроцессоров
Здравствуйте, FR, Вы писали:
FR>Я думаю что основная вина лежит на разработчиках микропроцессоров
А может всему причиной закон Паркинсона?
Согласен, что разработчики микропроцессоров здесь сильно "виноваты".
Но одного этого мало, здесь еще хорошо "постарались" и сами программисты.
Вопрос как раз о программистах.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
Ш>>люди знали, как писать маленькие, эффективные программы -- навык, который впоследствии был утерян. (с) Таненбаум.
AVC>Интересно было бы выяснить причины утраты такого навыка.
Элементарно: Задачи стали сложнее.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, IT, Вы писали:
AVC>>По моим наблюдениям, пошаговый отладчик — всего лишь способ убить рабочее время с умным видом.
IT>Несчастный, как же ты вообще работаешь?
Видимо, имеется в виду, как я отлаживаюсь?
Надеюсь, что с моей стороны это не слишком большой оффтоп в теме о "маленьких и эффективных программах".
Я не пользуюсь пошаговым отладчиком вовсе не потому, что у меня его нет.
Пишу я в основном на Си и Си++, компиляторов и отладчиков "навалом". (Больше того, сам иногда пишу и те, и другие.)
Просто обхожусь ассертами и отладочной выдачей (в крайнем случае).
Т.е. стараюсь максимально переложить контроль за программой на саму программу.
Если программа достаточно сложная, то использую набор тестов и скриптик, прогоняющий все эти тесты.
Думаю, что никакую Африку я этим не открыл.
Ах да, чуть не забыл... еще конечно — огромный опыт работы и ну просто невероятный интеллект...
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, WolfHound, Вы писали:
AVC>>Интересно было бы выяснить причины утраты такого навыка. WH>Элементарно: Задачи стали сложнее.
Это объясняет, почему сами программы стали больше. (И, вероятно, является следствием успехов "заводчиков" микропроцессоров.)
Но объясняет ли это потерю навыка писать короткие и эффективные куски кода?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC>>>Интересно было бы выяснить причины утраты такого навыка. WH>>Элементарно: Задачи стали сложнее.
AVC>Это объясняет, почему сами программы стали больше. (И, вероятно, является следствием успехов "заводчиков" микропроцессоров.) AVC>Но объясняет ли это потерю навыка писать короткие и эффективные куски кода?
Мантра последних лет — "память все дешевеет". ИМХО, конечно.
Здравствуйте, eao197, Вы писали:
E> E>За это отдельное спасибо
, если не шутишь.
Говорить правду легко и приятно.
Интеллект и впрямь не рядовой: иногда так спрячется — не найдешь...
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Mamut, Вы писали:
AVC>>Но объясняет ли это потерю навыка писать короткие и эффективные куски кода? M>Мантра последних лет — "память все дешевеет". ИМХО, конечно.
Короче, позор высоким технологиям!
До чего довели искусство программирования...
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Шахтер, Вы писали:
Ш>>люди знали, как писать маленькие, эффективные программы -- навык, который впоследствии был утерян. (с) Таненбаум.
E>В доказательство: E>
E> Apollo 11 to the moon, detached the lunar module, landed it on the moon's surface, and brought three astronauts home.
Это тот полет где они прыгали по луне, поднимаясь на два сантиметра вверх,
вопрос в том был ли вообще этот полет.
Здравствуйте, AVC, Вы писали:
WH>>Элементарно: Задачи стали сложнее. AVC>Это объясняет, почему сами программы стали больше. (И, вероятно, является следствием успехов "заводчиков" микропроцессоров.) AVC>Но объясняет ли это потерю навыка писать короткие и эффективные куски кода?
А на каком основании сделано заключение что навык утерян?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AVC, Вы писали:
AVC>>>По моим наблюдениям, пошаговый отладчик — всего лишь способ убить рабочее время с умным видом. IT>>Несчастный, как же ты вообще работаешь? AVC>Я не пользуюсь пошаговым отладчиком вовсе не потому, что у меня его нет. AVC>Просто обхожусь ассертами и отладочной выдачей (в крайнем случае).
Я в таком стиле на жаббе когда то писал. И сильно жалел что нет отладчика.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
_>Это тот полет где они прыгали по луне, поднимаясь на два сантиметра вверх, _>вопрос в том был ли вообще этот полет.
[оффтоп]
Был. Главный довод за: сли бы его не было, СССР первыми бы раструбили об этом на весь мир. Потому что за этим полетом (и следующими 5-ю высадками) следил весь мир. Остальное (на английском) здесь (русский вариант сейчас не найду).
[/оффтоп]
[оффтоп] M>Был. Главный довод за: сли бы его не было, СССР первыми бы раструбили об этом на весь мир. Потому что за этим полетом (и следующими 5-ю высадками) следил весь мир. Остальное (на английском) здесь (русский вариант сейчас не найду).
Спасибо за хорошую ссылку!
BTW, в последнее время Википедия стала мне нравиться: много актуальных (и притом довольно качественных) статей, что ценно.
[/оффтоп]
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, AVC, Вы писали:
Ш>>>люди знали, как писать маленькие, эффективные программы -- навык, который впоследствии был утерян. (с) Таненбаум.
AVC>>Интересно было бы выяснить причины утраты такого навыка. WH>Элементарно: Задачи стали сложнее.
В Линуксе моя home директория называется /home/strukov.
Под Виндами C:\Documents and Settings\SS.
Чем второй путь лучше первого я не понимаю. Зато хорошо понимаю, что он существенно длиннее.
Это хороший простой пример, который показывает, что совершенно элементарные задачи стали решатся более затратными средствами.
Здравствуйте, WolfHound, Вы писали:
WH>>>Элементарно: Задачи стали сложнее. AVC>>Это объясняет, почему сами программы стали больше. (И, вероятно, является следствием успехов "заводчиков" микропроцессоров.) AVC>>Но объясняет ли это потерю навыка писать короткие и эффективные куски кода? WH>А на каком основании сделано заключение что навык утерян?
На основании личных наблюдений.
Читаю иногда, что молодежь понаписала.
(Не на основании же учебников по алгоритмам судить о рядовом коде.)
Думается, что вопрос об отладчике здесь не такой уж оффтоп.
Связь есть.
Пишут программу и гоняют в отладчике, пока не "заработает".
Нет бы подумать и переструктурировать... ре-фак-то-ринг (трудное слово) провести...
Отсюда запутанная логика (заплатки на заплатках в коде) и, как следствие, снижение эффективности.
Впрочем, возможно, делать заключения преждевременно.
Где-то же она там пишет (и, следовательно, существует), наша золотая молодежь, Олимпиады выигрывает...
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC wrote: > Пишут программу и гоняют в отладчике, пока не "заработает". > Нет бы подумать и переструктурировать... ре-фак-то-ринг (трудное слово) > провести...
Не знаю, лично мне отладчик помогает понять где именно ошибка. То же
самое можно делать отладочной печатью, но это просто занимает больше
времени.
AVC>[оффтоп] M>>Был. Главный довод за: сли бы его не было, СССР первыми бы раструбили об этом на весь мир. Потому что за этим полетом (и следующими 5-ю высадками) следил весь мир. Остальное (на английском) здесь (русский вариант сейчас не найду).
AVC>Спасибо за хорошую ссылку! AVC>BTW, в последнее время Википедия стала мне нравиться: много актуальных (и притом довольно качественных) статей, что ценно.
Здравствуйте, CreatorCray, Вы писали:
AVC>>Просто обхожусь ассертами и отладочной выдачей (в крайнем случае). CC>Я в таком стиле на жаббе когда то писал. И сильно жалел что нет отладчика.
Привычка — вторая натура.
Я знаю много программистов, днюющих и ночующих в отладчике, даже жующих в нем бутерброды...
Я не понимаю их. Они не понимают меня.
Господи, как одиноки мы, программисты, бываем в этом мире!
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Cyberax, Вы писали:
C>Не знаю, лично мне отладчик помогает понять где именно ошибка. То же C>самое можно делать отладочной печатью, но это просто занимает больше C>времени.
Отладчик экономит время поиска места возникновения ошибки. Зато отладочные печати показывают как и почему ошибка произошла именно там.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Не знаю, лично мне отладчик помогает понять где именно ошибка. То же C>самое можно делать отладочной печатью, но это просто занимает больше C>времени.
Допускаю, что иногда (если сильно повезет) так и есть.
Допускаю также, что это дело привычки.
Но давай подумаем.
Сидишь в отладчике, щелкаешь мышкой или стучишь по клаве. Щелк-щелк/стук-стук... Неужели это быстро?
Ну, ладно, согласен, брейкпойнты никто не отменял.
Так ведь их тоже надо поставить, да еще найти куда...
Сидишь, значит, щелкаешь, визуально контролируешь ситуацию... кажись, все в порядке.
А с помощью ассертов программа за то же время сама успевает проконтролировать миллионы инвариантов.
Это раз.
Некоторые ситуации в принципе с отладчиком не отследишь: ситуацию гонок, например.
Это два.
Если сработал ассерт (или еще что-то ужасное случилось), то пост-мортем ("посмотрим") отладчик в твоем распоряжении.
Это три.
Я не спорю, просто предлагаю посмотреть с другой стороны.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>На основании личных наблюдений. AVC>Читаю иногда, что молодежь понаписала.
Молодеж бывает разная.
AVC>Думается, что вопрос об отладчике здесь не такой уж оффтоп. AVC>Связь есть. AVC>Пишут программу и гоняют в отладчике, пока не "заработает". AVC>Нет бы подумать и переструктурировать... ре-фак-то-ринг (трудное слово) провести... AVC>Отсюда запутанная логика (заплатки на заплатках в коде) и, как следствие, снижение эффективности.
Не нужно смешавать в одну кучу отладчик, рефакторинг и запутанный код. Эти понятия совершенно друг с другом не связаны.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
eao197 wrote: > C>Не знаю, лично мне отладчик помогает понять где именно ошибка. То же > C>самое можно делать отладочной печатью, но это просто занимает больше > C>времени. > Отладчик экономит время поиска места возникновения ошибки. Зато > отладочные печати показывают как и почему ошибка произошла именно там.
Это обычно и так понятно У меня, во всяком случае.
Здравствуйте, WolfHound, Вы писали:
WH>Не нужно смешавать в одну кучу отладчик, рефакторинг и запутанный код. Эти понятия совершенно друг с другом не связаны.
Смелое утверждение, однако!
Давай тогда брать попарно.
Запутанный код -> отладчик.
Запутанный код -> рефакторинг.
Неужели нет связи?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Видимо, имеется в виду, как я отлаживаюсь?
Именно. Как ты отлаживаешься, несчастный?
AVC>Пишу я в основном на Си и Си++, компиляторов и отладчиков "навалом". (Больше того, сам иногда пишу и те, и другие.) AVC>Просто обхожусь ассертами и отладочной выдачей (в крайнем случае).
Это всё тоже у нас в комплекте. Только вместо ассёртов исключения.
AVC>Т.е. стараюсь максимально переложить контроль за программой на саму программу.
А если код не твой или давно это было? Нужно по стеку побродить, посмотреть как оно куда чего.
AVC>Если программа достаточно сложная, то использую набор тестов и скриптик, прогоняющий все эти тесты.
Это уже не совсем отладка.
AVC>Ах да, чуть не забыл... еще конечно — огромный опыт работы и ну просто невероятный интеллект...
Этого у нас у всех в избытке. Иногда бывает такой заходишь в офис, а голова в проём двери не пролазит, потому что такая большая и умная, интелектом переполненная.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AVC, Вы писали:
AVC>Давай тогда брать попарно. AVC>Запутанный код -> отладчик. AVC>Запутанный код -> рефакторинг. AVC>Неужели нет связи?
Нету.
Я использую отладчик и без запутанного кода. Я рефакторю код который ну никак нельзя назвать запутанным. Я видел очень запутанный код который отлаживался исключительно логированием и ассертами. И этот код никогда не рефакторился.
Короче связи тут нету.
Все зависит от радиуса кривизны рук программиста и его предпочтений.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AVC, Вы писали:
WH>>Элементарно: Задачи стали сложнее.
AVC>Это объясняет, почему сами программы стали больше. (И, вероятно, является следствием успехов "заводчиков" микропроцессоров.) AVC>Но объясняет ли это потерю навыка писать короткие и эффективные куски кода?
подмена понятий!
В оригинальном тексте говорилось:
люди знали, как писать маленькие, эффективные программы -- навык, который впоследствии был утерян
Программы, а не куски кода!
Большая програма может содержать кучу замечательных отдельных коротких и эффективных кусков кода, но при этом все равно быть большой, сложной и неэффективной...
ЗЫ.
В "те времена" вообще-то тоже не все люди знали, как писать эффективные программы и не все программы такими были Просто только о лучших программах вспоминается спустя время
Здравствуйте, WolfHound, Вы писали:
AVC>>Интересно было бы выяснить причины утраты такого навыка. WH>Элементарно: Задачи стали сложнее.
Согласен.
А еще причина — во многих случаях просто исчезла необходимость писать экстремально эффективно.
Потому что раньше писали программы эффективно в основном все же не из любви к искусству, а просто потому что иначе бы на нее не хватило ресурсов и она бы вообще не работала
Сейчас большой спектр задач с бааальшим запасом укладывается в ограничения по ресурсам. И часто полезнее написать быстрее или написать "покрасивее". Потому что если делается какой-нибудь, условно говоря веб-педжер, то среднестатистическому пользователю пофик 2Мб оперативки он использует или 22. Ну без разницы ему это — рабтать на его компе все равно будет и заметных тормозов тоже не появится... А вот более красивые иконки, менюшки, анимашки, подсказки и проч. тому же среднестатистическому пользователю весьма нравятся.
Хотя к эффективности работы программы они отношение если и имеют — то только отрицательное...
AVC wrote: > Но давай подумаем. > Сидишь в отладчике, щелкаешь мышкой или стучишь по клаве. > Щелк-щелк/стук-стук... Неужели это быстро?
Быстро. Так как в самом отладчике обычно ничего трогать не надо.
> Ну, ладно, согласен, брейкпойнты никто не отменял. > Так ведь их тоже надо поставить, да еще найти куда...
Пришло от тестировщика объяснение "программа не так себя ведет при
нажатии на blah-blah". Ставим в орбработчик blah-blah точку прерывания и
жмем на blah-blah на экране.
> А с помощью ассертов программа за то же время сама успевает > проконтролировать миллионы инвариантов.
Но ошибка-то как раз не в миллионе вариантов, а в непроверенном миллион
плюс персом.
> Некоторые ситуации в принципе с отладчиком не отследишь: ситуацию гонок, > например. > Это два.
Valgrind'ом — вполне себе отследишь
> Если сработал ассерт (или еще что-то ужасное случилось), то пост-мортем > ("посмотрим") отладчик в твоем распоряжении. > Это три.
Кстати, на сработавший assert очень удобно тут же подключиться
отладчиком (без прерывания программы!) и посмотреть в подробностях на
фрейм функции.
Здравствуйте, WolfHound, Вы писали:
WH>Я использую отладчик и без запутанного кода. Я рефакторю код который ну никак нельзя назвать запутанным. Я видел очень запутанный код который отлаживался исключительно логированием и ассертами. И этот код никогда не рефакторился. WH>Короче связи тут нету.
Надо же, а я вижу связь — прямо-таки физически вижу.
Такой вот гештальт себе отрастил...
Собственно, моя мысль проста (других не держим ) — 33 несчастья от плохого структурирования.
В частности, от этого снижается эффективность программ (с чего начался топик).
А начинается все с того, что садятся и пишут код, не подумав как следует.
А затем наскоро правят код в перерывах между сессиями в отладчике.
Вот и получается такая структура.
WH>Все зависит от радиуса кривизны рук программиста и его предпочтений.
Не, все зависит от головы.
Голова — она главная, а не руки.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
F>Согласен. F>А еще причина — во многих случаях просто исчезла необходимость писать экстремально эффективно. F>Потому что раньше писали программы эффективно в основном все же не из любви к искусству, а просто потому что иначе бы на нее не хватило ресурсов и она бы вообще не работала F>Сейчас большой спектр задач с бааальшим запасом укладывается в ограничения по ресурсам. И часто полезнее написать быстрее или написать "покрасивее". Потому что если делается какой-нибудь, условно говоря веб-педжер, то среднестатистическому пользователю пофик 2Мб оперативки он использует или 22. Ну без разницы ему это — рабтать на его компе все равно будет и заметных тормозов тоже не появится... А вот более красивые иконки, менюшки, анимашки, подсказки и проч. тому же среднестатистическому пользователю весьма нравятся. F>Хотя к эффективности работы программы они отношение если и имеют — то только отрицательное...
комментарий не конкретно к вам, а как бы мысли в слух.
Почему-то все забывают о динамике (реальной) работы. Ну почему многие думают, что на компе будет работать одна программа и «среднестатистическому пользователю пофик 2Мб оперативки он использует или 22»?!
В реальности таких программ будет штук 10, при этом ещё что-то в трее будет висеть и будет (всего) 512 Мб памяти, так как такие компы продают по умолчанию в магазинах. Простой пользователь даже не подумает, что надо что-то обновлять, пока ему умельцы от IT об этом не скажут.
Здравствуйте, fmiracle, Вы писали:
AVC>>Это объясняет, почему сами программы стали больше. (И, вероятно, является следствием успехов "заводчиков" микропроцессоров.) AVC>>Но объясняет ли это потерю навыка писать короткие и эффективные куски кода?
F>подмена понятий! F>В оригинальном тексте говорилось: F>
F>люди знали, как писать маленькие, эффективные программы -- навык, который впоследствии был утерян
F>Программы, а не куски кода! F>Большая програма может содержать кучу замечательных отдельных коротких и эффективных кусков кода, но при этом все равно быть большой, сложной и неэффективной...
Ну, не такая уж подмена — я с самого начала выделил для себя в исходном тексте слова знали и навык.
Ведь заранее ясно было, что программы как таковые стали больше во многом в силу объективных обстоятельств.
Меня же интересует именно субъективный (здесь — программистский) аспект.
Что же касается "программ", то "программа" — понятие растяжимое. (И не только логически. Посмотрите на объемы и пышные формы нынешних программ. )
Что именно считать программой?
Отдельную EXE-шку? Отдельную DLL-ку? Отдельное приложение со всеми EXE-шками, DLL-ками и т.д.?
Операционную систему со всем прикладным ПО поверх нее?
[offtop]
Вот в моем любимом Обероне вообще нет понятия программы, там единицей является модуль.
Наверное (сейчас пришло в голову благодаря нашей беседе) Оберон вполне можно определить в древнегреческом стиле как потомка Модулы-2, в котором отсутствует понятие программы. (Я, кстати, вполне серьезно. На данный момент это лучшее "определение" Оберона. Практически все остальные отличительные свойства Оберона можно вывести из этого опреления логически. ИМХО, Сергей Губанов был на правильном пути в своем топике о модульных системах, только взялся доказывать не ту мысль, переключившись на воинственную тему "вот какими должны быть модули".)
[/offtop]
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Шахтер, Вы писали:
Ш>>люди знали, как писать маленькие, эффективные программы -- навык, который впоследствии был утерян. (с) Таненбаум.
M>Да ладно , это все старчкское нытье, лучше бы посмотрели состязания demo4k, demo64k. Рейтрейсер в 4 кб, или игра типа дума3 на 96 килобайт.
У них с выделенным не всегда все в порядке (конечно демка в 96 кб с аппаратными требованиями побольше чем у Doom 3 забавна, но малополезна)
Здравствуйте, Mamut, Вы писали:
M>[оффтоп] M>Был. Главный довод за: сли бы его не было, СССР первыми бы раструбили об этом на весь мир. Потому что за этим полетом (и следующими 5-ю высадками) следил весь мир. Остальное (на английском) здесь (русский вариант сейчас не найду). M>[/оффтоп]
[офф]
а еще мне "омон ра" пелевина нравится
[/офф]
Здравствуйте, AVC, Вы писали:
WH>>А на каком основании сделано заключение что навык утерян? AVC>На основании личных наблюдений. AVC>Читаю иногда, что молодежь понаписала.
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Mamut, Вы писали:
AVC>[оффтоп] M>>Был. Главный довод за: сли бы его не было, СССР первыми бы раструбили об этом на весь мир. Потому что за этим полетом (и следующими 5-ю высадками) следил весь мир. Остальное (на английском) здесь (русский вариант сейчас не найду).
AVC>Спасибо за хорошую ссылку! AVC>BTW, в последнее время Википедия стала мне нравиться: много актуальных (и притом довольно качественных) статей, что ценно. AVC>[/оффтоп]
Есть другие источники. Разумной критики на эти факты я не видел
Здравствуйте, AVC, Вы писали:
AVC>Интересно было бы выяснить причины утраты такого навыка.
Ну, во-первых, навык никуда не делся. Если посмотреть на размер скомпилированных программ на C# или Java, то он исчисляется килобайтами. И основным источником размера является страничное выравнивание.
Раздутость типичных современных программ напрямую связана со статической линковкой стандартных библиотек. Есть известные техники по уменьшению, к примеру, Delphi программ при помощи выкидывания ненужного мусора.
Во-вторых, с течением времени снижается спрос на маленькие и эффективные, и повышается на быстро написанные и легко развиваемые. Более того, вся история вычислительной техники посвящена именно тому, чтобы дать возможность ускорить разработку и развитие софта.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Шахтер, Вы писали:
Ш>люди знали, как писать маленькие, эффективные программы -- навык, который впоследствии был утерян. (с) Таненбаум.
Правильно. Потому что маленьких и эффективных программ не может быть много. Но они этого не знали и, написав последнюю маленькую и эффективную программу, остались без работы. Возможно, погибли, как мамонты или герои, возможно, стали деградировать за получение зарплаты. Никто не знает.
Здравствуйте, eao197, Вы писали:
E>В доказательство:
Плохое доказательство. Из-за убогости систем управления приходилось летать по фиксированным и заранее вычисленным траекториям, для чего необходимо было делать гарантийные остатки топлива. Что весьма неположительно сказывалось на эффективности системы (особенно неприятна была переразмеренность S-IVB). Современные ракеты за счет более совершенной системы управления выгадывают 10-15% ПН при том же железе.
Здравствуйте, Sinclair, Вы писали:
S>Ну, во-первых, навык никуда не делся. Если посмотреть на размер скомпилированных программ на C# или Java, то он исчисляется килобайтами. И основным источником размера является страничное выравнивание.
Аналогично у их (Java/C#) прототипа.
Вся операционка, равномощная тогдашним Виндам, занимала меньше 200K.
S>Во-вторых, с течением времени снижается спрос на маленькие и эффективные, и повышается на быстро написанные и легко развиваемые. Более того, вся история вычислительной техники посвящена именно тому, чтобы дать возможность ускорить разработку и развитие софта.
Итак, скорость написания софта — раз.
(О том же, ИМХО, сказал и eao197, приведя цитату из Паскаля-человека(!). )
Но действительно ли скорость написания обязательно должна приводить к раздуванию софта?
Насколько я понял, eao197 говорит о том, что некогда свой код отредактировать (отрефакти... тьфу! ), а Вы — о влиянии инструментария.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, AVC, Вы писали:
AVC>>Видимо, имеется в виду, как я отлаживаюсь?
IT>Именно. Как ты отлаживаешься, несчастный?
Я то же так иногда отлаживаюсь: в основном когда на C++ или Assembler программирую. Это иногда даже проще, чем в отладчике, если использовать следующие правила:
1. Нашёл ошибку — думаешь от чего она может быть.
2. Не понимаешь — ставишь отладочный дамп в файл каких-нибудь значимых файлов или простую проверку прямо в программу.
3. Находишь модуль где сделана ошибка — изучаешь полностью несколько методов (имеется ввиду инспекция кода, неформальная ), связанных с ошибочной ситуацией.
4. Не можешть найти ошибку — выполняешь ещё дампы и локализуешь её сильнее
5. Изучаешь совсем не те методы, на которые ты думал в начале и находишь ошибку
6. Если ошибка всё ещё не найдена — не работать в течени 48 (сорока восьми) часов
AVC>>Т.е. стараюсь максимально переложить контроль за программой на саму программу.
IT>А если код не твой или давно это было? Нужно по стеку побродить, посмотреть как оно куда чего.
Ужас! Вы меня разочаровываете... неужели вы и вправду изучаете чужой код в отладчике? И помогает?
AVC>>Ах да, чуть не забыл... еще конечно — огромный опыт работы и ну просто невероятный интеллект... IT>Этого у нас у всех в избытке. Иногда бывает такой заходишь в офис, а голова в проём двери не пролазит, потому что такая большая и умная, интелектом переполненная.
Здравствуйте, Шахтер, Вы писали:
Ш>люди знали, как писать маленькие, эффективные программы -- навык, который впоследствии был утерян. (с) Таненбаум.
Ну, это же уже не смешно! Все знают, что чем программа меньше — тем сложнее её написать. Чем программа эффективнее — тем сложнее её написать (и поддерживать).
Недавно я писал для друзей (точнее для себя, но соревновался с другом) программу FDSC Informer. Альтернативная программа (функция — уведомлять о новых сообщениях на сайте) занимает более 700K, у меня не так давно было 40, сейчас с локальными данными больше. Exe — 48К и ещё рисунки. НО! Он её написал на Delphi 7 с использованием стандартных технологий и не мучался, а я её писал только с использованием WinAPI на той же Delphi 7, в результате даже нашёл в одной RSDN-овской статье небольшую ошибку, которая приводила мою программу к полной неработоспособности. Вот и вопрос: зачем (кроме как ради соревнования) писать такую программу, если даже Dial-up пользователь спокойно может скачать более простую (и более красивую) прогу?
Не так давно (года 3-4 назад) мне пришлось переписывать три алгоритма. Оба были написаны на Delphi 7 и были относительно понятными.
Один алгоритм Delphi безобразно компилировала так, что во внутреннем цикле счётчик был в памяти, а не в регистре, тогда как во внешних циклах счётчики были в регистрах. + ко всему там были преобразования форматов слова в двойное слово и т.п., которые Delphi выполняла не эффективно (нужно было работать попеременно с, например, eax, ax. ah и al, а она вместо этого делала жуткие преобразования). Код в этом случае ускорился примерно в 3,5 раза, но программа стала полностью нечитаемой, к тому же я потратил на это много времени. Позже я изменил структуру данных и вызовов методов и написал аналогичный алгоритм на той же Delphi так, что он отставал от assembler только на 7-11%. Для изменения этой структуры мне пришлось, в частности, написать этот ассемблерный код, что бы посмотреть на алгоритм со всех сторон и сделать ещё много других вещей.
Второй алгоритм работал хорошо, но только когда его данные помещались в память. Мне пришлось сильно изменить логику работы программы для оптимизации работы с файлом подкачки. Программа стала гораздо более сложной и определить что она делает по тексту программы было очень трудно (в отличие от первого варианта), к тому же я, сдуру, некоторую часть переписал на ассемблере. Это было не так сложно, но как я уже сказал, код стал гораздо менее читаемым и поддерживаемым, а, значит, и содержал потенциально больше ошибок. В данном случае, по скромным подсчётам, программа стала работать эффективнее с большими данными примерно в 3000 раз (по скромным!).
Третий алгоритм был алгоритмом обработки большого струкутрированного текстового файла (БД). Моя задача заключалась в поддержке ассинхронного ввода/вывода, который действительно чуть-чуть ускорил обработку (процентов на 10). Ещё процентов 50 я выиграл за счёт менее кривого кода. И ещё примерно 20-30% за счёт прямого вызова функции WinAPI с нужными параметрами (отсутствие буферизации), которые невозможно было использовать в библиотечной функции.
Вот вопрос: зачем писать эффективный и маленький код, когда можно написать просто тяп-ляп или, если прижмёт, более качественный код, который будет работать быстрее за счёт удачного формата данных? В любом случае, обычно дешевле заставить пользователя купить новый компьютер, чем написать более быстрый и маленький код. К тому же существует вероятность, что этот код окажется не таким уж маленьким и быстрым. Я завалил не так мало программ просто потому, что заботился об их эффективности больше, чем обо всём остальном, хотя эффективность была не так важна.
Кстати, мой любимый Макконнелл провёл через всю книгу ("Совершенный код") идею, что нужно написать качественную программу, а затем оптимизировать некоторые фрагменты. ЕСЛИ ОКАЖЕТСЯ НАДО!
Ты не вкурил. Ключевое слово в цитате -- навык. Навык -- вещь которую человек использует неосознанно, автоматически по большей части. Навыки не берутся из ничего, их вырабатывают. Это требует времени и усилий. Но зато потом ты получишь отдачу. Человек не имеющий навыка писать эффективные программы никогда не будет делать эффективные программы.
FDS>Кстати, мой любимый Макконнелл провёл через всю книгу ("Совершенный код") идею, что нужно написать качественную программу, а затем оптимизировать некоторые фрагменты. ЕСЛИ ОКАЖЕТСЯ НАДО!
Дурак твой Макконнелл. Если ты писал программу не думая об эффективности, то потом сделать её эффективно не получится. Это первое. Неэффективная программа -- некачественная. Это второе.
Здравствуйте, FDSC, Вы писали:
FDS>Кстати, мой любимый Макконнелл провёл через всю книгу ("Совершенный код") идею, что нужно написать качественную программу, а затем оптимизировать некоторые фрагменты. ЕСЛИ ОКАЖЕТСЯ НАДО!
Это разумная мысль.
Но надо поставить акцент на том, что сначала надо написать качественную программу.
А качественная программа прежде всего разумно структурирована и только поэтому позволяет последующую оптимизацию.
Я уже несколько постов стараюсь донести мысль, что если программа не будет хорошо структурирована, то ее не удастся ни сделать действительно эффективной, ни отладить как следует.
WolfHound возражал:
Я видел очень запутанный код который отлаживался исключительно логированием и ассертами.
Но это, ИМХО, ошибочное возражение.
Ассерты не вставляют в готовый запутанный код, да еще куда попало.
Они формируют создание ясного, отлаживаемого и способного к оптимизации кода с помощью продуманных инвариантов.
Можно сказать, впоследствии такой код сам себя отлаживает.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, FDSC, Вы писали: ...
Ш>Ты не вкурил. Ключевое слово в цитате -- навык. Навык -- вещь которую человек использует неосознанно, автоматически по большей части. Навыки не берутся из ничего, их вырабатывают. Это требует времени и усилий. Но зато потом ты получишь отдачу. Человек не имеющий навыка писать эффективные программы никогда не будет делать эффективные программы.
Конечно я не вкурил! Я не курю.
По сути:
1. Навык, может, никуда и не делся. Возможно, делись программисты, которые этим навыком обладают (например, ушли в менеджеры)
2. Навык нужно поддерживать. В большинстве фирм сейчас (и некоторое время назад, лет 20) вместо эффективности требовалась высокая отдача. Программистов гнали и никто их не просил делать не только эффективный, но даже качественный код. При таком программировании навык забывается. К тому же написание эффективных программ — это не навык. Это характер и наличие определённых знаний (которые нужно постоянно обновлять и поддерживать, ну, может не постоянно, но по крайней мере не очень редко, не раз в 10 лет). Плюс, возможно, опыт. Даже наверняка опыт.
3. Человек, имеющий навык писать эффективные программы совершенно не обязательно их пишет. Может я не гений оптимизации, но частенько спокойно упускаю производительность в разы, используя .NET, MS Windows, и более лёгкие в реализации алгоритмы. Кстати, использование более лёгких в реализации алгоритмов или каких-либо специфических алгоритмов может требовать начальство, даже если эти алгоритмы не оптимальны для данной задачи (зато соотв. корпоративной политике ).
FDS>>Кстати, мой любимый Макконнелл провёл через всю книгу ("Совершенный код") идею, что нужно написать качественную программу, а затем оптимизировать некоторые фрагменты. ЕСЛИ ОКАЖЕТСЯ НАДО!
Ш>Дурак твой Макконнелл. Если ты писал программу не думая об эффективности, то потом сделать её эффективно не получится. Это первое. Неэффективная программа -- некачественная. Это второе.
Ай-ай-ай. Не забудь послать ему это на почту.
1. Если ты писал программу не думая об эффективности, то потом её можно оптимизировать. Из 3-х случаев, которые я привёл, два — оптимизация уже готовой программы. Или вы скажете что прирост производительности в 3000 раз — это мало? Посмотрите у Макконнелла, у него то же есть пример, где он описывает как он самолично оптимизировал алгоритм шифрования. Он написал его на высокоуровневом языке, а затем методично применял методики оптимизации, пока, наконец, не улучшил скорость выполнения программы на 2 порядка.
2. Неэффективная программа совершенно не обязательно некачественная. Качество определяется соответствием ТЗ и неявным желаниям пользователя. Если программа удовлетворяет этим желанием (в частности, неосознанным требованиям безопасности и скорости), то программа качественная.
Другой пример: допустим программа эффективна. Эффективность в плане использования ресурсов процессора означает более сложные алгоритмы и более сложный и непонятный код. Это почти всегда так. Тогда программа не слишком легка в поддержке. Теперь допустим, что заказчик хочет, что бы программа, прежде всего, была легка именно в поддержке (т.е. его цель: минимизация затрат на поддержку. Оборудование у него хорошее независимо от программы и он не нуждается в высоком быстродействии). Тогда программа не удовлетворяет заказчика и, следовательно, не является качественной, пока является эффективной.
Не многие люди делают то, что им не нужно. Не многие делают то, что от них не требуют, если только по глупости (или им это не нужно почему-либо другому). Зачем делать программу более производительной, если это не требуется? Зачем зря удорожать стоимость разработки и вводить заказчика в состояние неопределённости? Разве ничем не обоснованная повышенная стоимость не есть показатель плохого качества программы?
Малое количество эффективных программ и кажущеяся пропажа навыка обусловлена тем, что эффективность теперь не входит в требования по качеству. Если, конечно, она не совсем низка.
Если вы будете исходить из другого предположения, то можете удивляться "пропаже навыков" сколько угодно. Игнорировать причины, которые вы ищете, это, конечно, очень умно, так же, как и обзываться дураком на некоторых людей.
можно я влезу, да?
Ш>>Дурак твой Макконнелл. Если ты писал программу не думая об эффективности, то потом сделать её эффективно не получится. Это первое. Неэффективная программа -- некачественная. Это второе. FDS>1. Если ты писал программу не думая об эффективности, то потом её можно оптимизировать.
имхо ключевое слово "потом".
"все, что не делается -- все и не делается и не делается и не..."
тем более что сроки, как тут уже было сказано... как же при "сроках" писать программу 2-3 раза, переписывая одни и те же куски кода?
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, FDSC, Вы писали:
FDS>>Кстати, мой любимый Макконнелл провёл через всю книгу ("Совершенный код") идею, что нужно написать качественную программу, а затем оптимизировать некоторые фрагменты. ЕСЛИ ОКАЖЕТСЯ НАДО!
AVC>Это разумная мысль. AVC>Но надо поставить акцент на том, что сначала надо написать качественную программу. AVC>А качественная программа прежде всего разумно структурирована и только поэтому позволяет последующую оптимизацию.
Согласен.
AVC>Я уже несколько постов стараюсь донести мысль, что если программа не будет хорошо структурирована, то ее не удастся ни сделать действительно эффективной, ни отладить как следует. AVC>WolfHound возражал: AVC>
Я видел очень запутанный код который отлаживался исключительно логированием и ассертами.
AVC>Но это, ИМХО, ошибочное возражение.
Конечно, ошибочное. Просто он хотел показать, что само по себе применение отладчика — не показатель.
AVC>Ассерты не вставляют в готовый запутанный код, да еще куда попало.
Вставляют, ещё как . Вопрос в том, кто кодирует. Я, например, никогда не использую ассерты, потому что считаю избыточной любую проверку, которую нужно исключать из релизной версии. Хотя при отладке я иногда вставляю определённые проверки. Замечу, при отладке, хотя и не куда попало.
Хотя, обычно, ограниченное использование отладчика делает процесс разработки более строгим. Но некоторые типы ошибок без отладчика найти сложнее (например, когда неправильно понимаешь, как код скомпилирован в машинные команды).
AVC>Они формируют создание ясного, отлаживаемого и способного к оптимизации кода с помощью продуманных инвариантов.
Вот это для меня слишком сложно...
AVC>Можно сказать, впоследствии такой код сам себя отлаживает.
Здравствуйте, _rasta, Вы писали:
_>Здравствуйте, FDSC, Вы писали:
_>можно я влезу, да?
Ш>>>Дурак твой Макконнелл. Если ты писал программу не думая об эффективности, то потом сделать её эффективно не получится. Это первое. Неэффективная программа -- некачественная. Это второе. FDS>>1. Если ты писал программу не думая об эффективности, то потом её можно оптимизировать.
_>имхо ключевое слово "потом". _>"все, что не делается -- все и не делается и не делается и не..."
_>тем более что сроки, как тут уже было сказано... как же при "сроках" писать программу 2-3 раза, переписывая одни и те же куски кода?
Сроки тут были с точки зрения того, что большинство программ не требует переписывания: они уже достаточно эффективны и ещё большая эффективность только неоправданно увеличит сроки.
А вы попробуйте с первого раза написать "эффективную" программу. Вообще-то всё, что работает очень быстро, обычно переписывается по нескольку раз. К тому же программу нужно переписывать не целиком, а только самые медленные фрагменты.
Здравствуйте, AVC, Вы писали: AVC>Итак, скорость написания софта — раз. AVC>(О том же, ИМХО, сказал и eao197, приведя цитату из Паскаля-человека(!). ) AVC>Но действительно ли скорость написания обязательно должна приводить к раздуванию софта? AVC>Насколько я понял, eao197 говорит о том, что некогда свой код отредактировать (отрефакти... тьфу! ), а Вы — о влиянии инструментария.
Инструментарий практически не влияет. Ну разве что убогий линкер без возможности оптимизации размера кода.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Шахтер, Вы писали:
Ш>люди знали, как писать маленькие, эффективные программы -- навык, который впоследствии был утерян. (с) Таненбаум.
Немного оффтопично, в той же книге (неточно):
Под UNIX есть программа nice, которая позволяет снизить приоритет своей задачи и отдать ресурсы другим пользователям. Это программой никто не пользуется.
Здравствуйте, Шахтер, Вы писали:
Ш>В Линуксе моя home директория называется /home/strukov. Ш>Под Виндами C:\Documents and Settings\SS. Ш>Чем второй путь лучше первого я не понимаю. Зато хорошо понимаю, что он существенно длиннее. Ш>Это хороший простой пример, который показывает, что совершенно элементарные задачи стали решатся более затратными средствами.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, FDSC, Вы писали:
AVC>>Ассерты не вставляют в готовый запутанный код, да еще куда попало. FDS>Вставляют, ещё как . Вопрос в том, кто кодирует. Я, например, никогда не использую ассерты, потому что считаю избыточной любую проверку, которую нужно исключать из релизной версии. Хотя при отладке я иногда вставляю определённые проверки. Замечу, при отладке, хотя и не куда попало.
Вот здесь как раз различие в подходах.
Программирование — человеческая деятельность.
Поэтому, ИМХО, ее надо рассматривать не только объективно (описательно; что есть, то есть, ничего тут не изменишь), но и субъективно: отличать хорошую практику от плохой.
AVC>>Они формируют создание ясного, отлаживаемого и способного к оптимизации кода с помощью продуманных инвариантов. FDS>Вот это для меня слишком сложно...
Значит, я сложно выразился.
Инварианты цикла известны многим. Ершов в свое время даже предлагал дисквалифицировать программистов, пишущих цикл без предварительной формулировки его инварианта.
А какие еще бывают инварианты?
Во-первых, инварианты памяти. Ко всякой сущности ЯВУ следует обращаться только в соответствии с ее типом.
Ряд языков предлагает такие "герметичные" системы типов: Оберон, Java, C#.
Там нет вариантных записей и нельзя незамеченным выйти за границу массива.
Во-вторых, предикаты, которые должны выполняться всегда. Особенно важно определить такие предикаты на границах подпрограмм, модулей, подсистем и т.п.
Например, если у нас определена вещественная функция вычисления квадратного корня, то отрицательный аргумент не может быть корректным.
Следовательно, пишем ASSERT(x >= 0.0);.
Это приводит нас к идее контрактного программирования (Мейер) и т.д.
AVC>>Можно сказать, впоследствии такой код сам себя отлаживает. FDS>Я бы сказал, он сам себя тестирует.
Формально Вы совершенно правы.
Но если заглянуть чуть дальше, то в ряде систем программирования ASSERT не только прерывает выполнение программы в случае ложности своего предиката, но и вызвает посмертный отладчик, раскрывает фреймы стека, показывает место и характер ошибки и т.д.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Вот здесь как раз различие в подходах. AVC>Программирование — человеческая деятельность. AVC>Поэтому, ИМХО, ее надо рассматривать не только объективно (описательно; что есть, то есть, ничего тут не изменишь), но и субъективно: отличать хорошую практику от плохой.
В данном случае рассмотрение велось описательно и в споре приводились фрагменты личного опыта.
Естественно, если не думать, что можно изменить в своей работе не будешь прогрессировать, да и работа быстро надоест и будет вызывать отвращение.
AVC>>>Они формируют создание ясного, отлаживаемого и способного к оптимизации кода с помощью продуманных инвариантов. FDS>>Вот это для меня слишком сложно...
AVC>Значит, я сложно выразился. AVC>Инварианты цикла известны многим. Ершов в свое время даже предлагал дисквалифицировать программистов, пишущих цикл без предварительной формулировки его инварианта.
Ага, я вот не знаю что это такое, хотя все вокруг говорят (хоть бы кто-нибудь объяснил!). А вот циклы я пишу нормально, по крайней мере лучше, чем некоторые, которые утверждают, что знают что такое инвариант цикла...
Это какой Ершов? Который А.П. (есть ещё Ю.Л.)?
AVC>А какие еще бывают инварианты? AVC>Во-первых, инварианты памяти. Ко всякой сущности ЯВУ следует обращаться только в соответствии с ее типом. AVC>Ряд языков предлагает такие "герметичные" системы типов: Оберон, Java, C#. AVC>Там нет вариантных записей и нельзя незамеченным выйти за границу массива. AVC>Во-вторых, предикаты, которые должны выполняться всегда. Особенно важно определить такие предикаты на границах подпрограмм, модулей, подсистем и т.п.
AVC>>>Можно сказать, впоследствии такой код сам себя отлаживает. FDS>>Я бы сказал, он сам себя тестирует.
AVC>Формально Вы совершенно правы. AVC>Но если заглянуть чуть дальше, то в ряде систем программирования ASSERT не только прерывает выполнение программы в случае ложности своего предиката, но и вызвает посмертный отладчик, раскрывает фреймы стека, показывает место и характер ошибки и т.д.
Ну да, но процесс отладки сам по себе включает и исправление ошибки. Этого, к сожалению, пока никто не делает.
Здравствуйте, FDSC, Вы писали:
FDS>Ага, я вот не знаю что это такое, хотя все вокруг говорят (хоть бы кто-нибудь объяснил!). А вот циклы я пишу нормально, по крайней мере лучше, чем некоторые, которые утверждают, что знают что такое инвариант цикла... FDS>Это какой Ершов? Который А.П. (есть ещё Ю.Л.)?
А.П.Ершов. http://www.oberon2005.ru/classics.html
Насчет инварианта цикла, первое, что пришло в голову — посмотреть в Википедии: http://en.wikipedia.org/wiki/Loop_invariant
Впрочем, написанное там не слишком вдохновляет. Наверное, имеет смысл пройтись по ссылкам.
FDS>Ну да, но процесс отладки сам по себе включает и исправление ошибки. Этого, к сожалению, пока никто не делает.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Насчет инварианта цикла, первое, что пришло в голову — посмотреть в Википедии: AVC>http://en.wikipedia.org/wiki/Loop_invariant AVC>Впрочем, написанное там не слишком вдохновляет. Наверное, имеет смысл пройтись по ссылкам.
Здравствуйте, Шахтер, Вы писали:
Ш>люди знали, как писать маленькие, эффективные программы -- навык, который впоследствии был утерян. (с) Таненбаум.
Так как пришли менеджеры, и сказали: а теперь пора заняться делом!
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, minorlogic, Вы писали:
M>>Здравствуйте, Шахтер, Вы писали:
Ш>>>люди знали, как писать маленькие, эффективные программы -- навык, который впоследствии был утерян. (с) Таненбаум.
M>>Да ладно , это все старчкское нытье, лучше бы посмотрели состязания demo4k, demo64k. Рейтрейсер в 4 кб, или игра типа дума3 на 96 килобайт.
FR>У них с выделенным не всегда все в порядке (конечно демка в 96 кб с аппаратными требованиями побольше чем у Doom 3 забавна, но малополезна)
Уверен, что хорошо поискав , можно найти демку демонстрирующую и эффективность , и минимализм.
Здравствуйте, IT, Вы писали:
AVC>>По моим наблюдениям, пошаговый отладчик — всего лишь способ убить рабочее время с умным видом.
IT>Несчастный, как же ты вообще работаешь?
Господа, остерегайтесь программистов, задающих подобные вопросы. Видите программиста с отладчиком — увольняйте немедленно!!! Он вам понасажает множество труднообнаружимых ошибок, когда будет втыкать на скорую руку заплатки, устраняющие симптомы проблем (до сути проблем ведь они с дебаггерами никогда не докопаются, это просто физически невозможно).
Здравствуйте, IT, Вы писали:
AVC>>Пишу я в основном на Си и Си++, компиляторов и отладчиков "навалом". (Больше того, сам иногда пишу и те, и другие.) AVC>>Просто обхожусь ассертами и отладочной выдачей (в крайнем случае).
IT>Это всё тоже у нас в комплекте. Только вместо ассёртов исключения.
Можно посмеяться? Спасибо.
В общем, исключения вообще проблемы не решают. Что такое ассерт? Это контракт. Это документация к коду. Это декларативное описание
сути работы функции или метода. А если добавить ещё и тесты, то из ассертов и тестов, при грамотном подходе, можно не задумываясь восстановить код самой функции. А вы тут с исключениями...
AVC>>Т.е. стараюсь максимально переложить контроль за программой на саму программу.
IT>А если код не твой или давно это было?
Вот именно. В этой ситуации и надо всё максимально заавтоматизировать. И код должен быть самодокументированным. Комментарии на человеческом языке непонятны, потому как писавший их всегда предполагает неосознанно какой либо контекст, другим прочим совершенно неведомый.
IT> Нужно по стеку побродить, посмотреть как оно куда чего.
Не нужно. Уверяю вас, нет ничего глупее, чем бродить по стеку.
AVC>>Если программа достаточно сложная, то использую набор тестов и скриптик, прогоняющий все эти тесты.
IT>Это уже не совсем отладка.
А что тогда отладка? Пошагово смотреть, как работает и без того очевидный код (ваш код не очевиден? переписать!)? Ну найдете, что пришедший из хрензнаетоткуда поинтер показывает на чушь, и туда ещё раза три нагадили по дороге в других местах. Не покажет дебаггер, где именно указатель потерял смысл, никогда и ни за что. Он симптом покажет, то место, где всё сегфолтнулось. И это, кстати, самый тривиальный из примеров. Обычно ошибки гораздо коварнее. Не по зубам они тем, кто привык дебаггерами играться.
Здравствуйте, FDSC, Вы писали:
FDS>Вставляют, ещё как . Вопрос в том, кто кодирует. Я, например, никогда не использую ассерты, потому что считаю избыточной любую проверку, которую нужно исключать из релизной версии. Хотя при отладке я иногда вставляю определённые проверки. Замечу, при отладке, хотя и не куда попало.
В корне неверный подход. Ассерт — это, считай, документация. То, что словами ты писать поленишься. Ознакомься, например, с языком Eiffel, там эту мысль довели до совершенства.
FDS>Хотя, обычно, ограниченное использование отладчика делает процесс разработки более строгим. Но некоторые типы ошибок без отладчика найти сложнее (например, когда неправильно понимаешь, как код скомпилирован в машинные команды).
Основной плюс отладчика — это то что не нужно перекомпилировать (и во многих случаях — даже перезапускать программы). Что для больших проектов в итоге выливается во вполне приличное время. Особенно хорошо плюсы отладчика проявляются на скриптовых языках.
Так что не вижу зачем отказывать себе в удобном средстве разработки. Ещё раз подчеркну — отладчик не отменяет ни ассертов, ни отладочной печати.
Здравствуйте, Left2, Вы писали:
L>Основной плюс отладчика — это то что не нужно перекомпилировать (и во многих случаях — даже перезапускать программы). Что для больших проектов в итоге выливается во вполне приличное время. Особенно хорошо плюсы отладчика проявляются на скриптовых языках.
Что-то я не въезжаю. Проблема перекомпилияции больших проектов для скриптовых языков стоит особенно остро?
Здравствуйте, Win2k, Вы писали:
W> Господа, остерегайтесь программистов, задающих подобные вопросы. Видите программиста с отладчиком — увольняйте немедленно!!! Он вам понасажает множество труднообнаружимых ошибок, когда будет втыкать на скорую руку заплатки, устраняющие симптомы проблем (до сути проблем ведь они с дебаггерами никогда не докопаются, это просто физически невозможно).
Если ты не умеешь пользоватся отладчиком то это не твое достоинство, а твой недостаток. И не надо по себе судить других.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Win2k, Вы писали:
W>Здравствуйте, IT, Вы писали:
AVC>>>Пишу я в основном на Си и Си++, компиляторов и отладчиков "навалом". (Больше того, сам иногда пишу и те, и другие.) AVC>>>Просто обхожусь ассертами и отладочной выдачей (в крайнем случае).
IT>>Это всё тоже у нас в комплекте. Только вместо ассёртов исключения.
W> Можно посмеяться? Спасибо.
W> В общем, исключения вообще проблемы не решают. Что такое ассерт? Это контракт. Это документация к коду. Это декларативное описание W>сути работы функции или метода. А если добавить ещё и тесты, то из ассертов и тестов, при грамотном подходе, можно не задумываясь восстановить код самой функции. А вы тут с исключениями...
Вы ещё скажите, что исключениями нельзя реализовать контракты Я то же пишу вместо ассертов исключения — те же контракты, но работают они и в релизной версии.
AVC>>>Т.е. стараюсь максимально переложить контроль за программой на саму программу.
IT>> Нужно по стеку побродить, посмотреть как оно куда чего.
W> Не нужно. Уверяю вас, нет ничего глупее, чем бродить по стеку.
Правильно, ничего интересного там нет....
AVC>>>Если программа достаточно сложная, то использую набор тестов и скриптик, прогоняющий все эти тесты.
IT>>Это уже не совсем отладка.
W> А что тогда отладка? Пошагово смотреть, как работает и без того очевидный код (ваш код не очевиден? переписать!)? Ну найдете, что пришедший из хрензнаетоткуда поинтер показывает на чушь, и туда ещё раза три нагадили по дороге в других местах. Не покажет дебаггер, где именно указатель потерял смысл, никогда и ни за что. Он симптом покажет, то место, где всё сегфолтнулось. И это, кстати, самый тривиальный из примеров. Обычно ошибки гораздо коварнее. Не по зубам они тем, кто привык дебаггерами играться.
Отладка — это локализация и исправление ошибки. А тестирование — это максимум только часть локализации
Здравствуйте, Left2, Вы писали:
L>Основной плюс отладчика — это то что не нужно перекомпилировать (и во многих случаях — даже перезапускать программы). Что для больших проектов в итоге выливается во вполне приличное время. Особенно хорошо плюсы отладчика проявляются на скриптовых языках.
L>Так что не вижу зачем отказывать себе в удобном средстве разработки. Ещё раз подчеркну — отладчик не отменяет ни ассертов, ни отладочной печати.
Между прочим, если нормально поставить разработку, не так уж и долго всё будет перекомпилироваться: программу можно разбить на много dll, например, или на много отдельно получаемых obj-файлов, так что для всех файлов выполняется только компоновка, а не компиляция (это будет то же не быстро, для очень больших приложений). Если такой большой проект, то и в отладчике в нём потонешь.
Трурль: Т>Что-то я не въезжаю. Проблема перекомпилияции больших проектов для скриптовых языков стоит особенно остро?
Здравствуйте, Win2k, Вы писали:
W>Здравствуйте, FDSC, Вы писали:
FDS>>Вставляют, ещё как . Вопрос в том, кто кодирует. Я, например, никогда не использую ассерты, потому что считаю избыточной любую проверку, которую нужно исключать из релизной версии. Хотя при отладке я иногда вставляю определённые проверки. Замечу, при отладке, хотя и не куда попало.
W> В корне неверный подход. Ассерт — это, считай, документация. То, что словами ты писать поленишься. Ознакомься, например, с языком Eiffel, там эту мысль довели до совершенства.
Насколько мне помнится, в Eiffel эти проверки и в релиз идут, или нет? Я в общем-то знаю, там классные идеи.
Вопрос только в том, что я обычно пишу некоторые вещи словами, а assert'ы писать ленюсь — они очень тормозят работу, причём совершенно необоснованно. А обоснованные проверки я и в релиз включаю.
FDS>>Хотя, обычно, ограниченное использование отладчика делает процесс разработки более строгим. Но некоторые типы ошибок без отладчика найти сложнее (например, когда неправильно понимаешь, как код скомпилирован в машинные команды).
W> Когда не понимаешь — надо компилятор менять.
На какой? В любом компиляторе может найтись некоторая ошибка или неточность, которая будет видна только на уровне машинных команд, я, в основном, про это.
Здравствуйте, Kisloid, Вы писали:
K>Здравствуйте, Шахтер, Вы писали:
Ш>>люди знали, как писать маленькие, эффективные программы -- навык, который впоследствии был утерян. (с) Таненбаум.
K>В те дни, в те дни... незнаю почему, но когда читаю топик, в голове почему то начинает вертеться не "в те дни", а "в те критические дни"
Телевизор надо меньше смотреть. У меня вот в голове вертится
То были дни, когда я познал, что значит: страдать; что значит: стыдиться; что значит: отчаяться
Не думайте, что я читал этого автора, просто цитата у Стругацких в эпиграфе....
Здравствуйте, FDSC, Вы писали:
W>> В корне неверный подход. Ассерт — это, считай, документация. То, что словами ты писать поленишься. Ознакомься, например, с языком Eiffel, там эту мысль довели до совершенства.
FDS>Насколько мне помнится, в Eiffel эти проверки и в релиз идут, или нет? Я в общем-то знаю, там классные идеи.
Насколько помню, там это определяется на этапе конфигурирования приложения (в EffeilStudio для приложения создается специальный файл ACE, который является чем-то вроде манифеста. Среди прочего там указывается, должны ли проверятся контракты во время работы приложения), но сам код контрактов присутствует в приложении всегда.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Т>Что-то я не въезжаю. Проблема перекомпилияции больших проектов для скриптовых языков стоит особенно остро?
Не, это я косноязычно выразился. Предложения не связаны. Просто в скриптовых языках отладчик особенно удобен — для них он существенно проще и одновременно богаче по возможностям. Повозившись некоторое время с отладкой JavaScript-ов под VisualStudio лично я почувствовал насколько неудобно отлаживать C++ код.
FDS>Между прочим, если нормально поставить разработку, не так уж и долго всё будет перекомпилироваться: программу можно разбить на много dll, например, или на много отдельно получаемых obj-файлов, так что для всех файлов выполняется только компоновка, а не компиляция (это будет то же не быстро, для очень больших приложений). Если такой большой проект, то и в отладчике в нём потонешь.
Всё это прекрасно и замечательно и со всем этим я согласен на 100%. Но для реально больших проектов даже при всех ухищрениях скорость билда приводит в уныние Ну и к тому же периодически надо отлаживать вещи, которые хош-не-хош а тянут за собой перебилд бОльшей части проекта.
L>Всё это прекрасно и замечательно и со всем этим я согласен на 100%. Но для реально больших проектов даже при всех ухищрениях скорость билда приводит в уныние Ну и к тому же периодически надо отлаживать вещи, которые хош-не-хош а тянут за собой перебилд бОльшей части проекта.
Даже большой размер проекта не нужен, достаточно интенсивно пользоватся шаблонами, те же бустом например.
Здравствуйте, Kisloid, Вы писали:
K>Здравствуйте, FDSC, Вы писали:
FDS>>Телевизор надо меньше смотреть. У меня вот в голове вертится
K>Кстати странно, но я телек не смотрю уже больше 2 лет
Читать нужно больше. Вы видимо эти два года не только телевизор не смотрели, но и ничем интеелектуальным, кроме программирования, не занимались
Здравствуйте, Left2, Вы писали:
FDS>>Между прочим, если нормально поставить разработку, не так уж и долго всё будет перекомпилироваться: программу можно разбить на много dll, например, или на много отдельно получаемых obj-файлов, так что для всех файлов выполняется только компоновка, а не компиляция (это будет то же не быстро, для очень больших приложений). Если такой большой проект, то и в отладчике в нём потонешь.
L>Всё это прекрасно и замечательно и со всем этим я согласен на 100%. Но для реально больших проектов даже при всех ухищрениях скорость билда приводит в уныние Ну и к тому же периодически надо отлаживать вещи, которые хош-не-хош а тянут за собой перебилд бОльшей части проекта.
Плохая архитектура значит . Единственное, что тут можно предложить взамен отладчика, дак это дампить кучу информации на всех стадиях завала программы . Вообще конечно, согласен.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, FDSC, Вы писали:
W>>> В корне неверный подход. Ассерт — это, считай, документация. То, что словами ты писать поленишься. Ознакомься, например, с языком Eiffel, там эту мысль довели до совершенства.
FDS>>Насколько мне помнится, в Eiffel эти проверки и в релиз идут, или нет? Я в общем-то знаю, там классные идеи.
E>Насколько помню, там это определяется на этапе конфигурирования приложения (в EffeilStudio для приложения создается специальный файл ACE, который является чем-то вроде манифеста. Среди прочего там указывается, должны ли проверятся контракты во время работы приложения), но сам код контрактов присутствует в приложении всегда.
Ага, вы подтвердили мои предположения. У меня в приложениях то же есть проверки на корректность, правда далеко не во всех модулях, но конкретно ассертами я не пользуюсь
Здравствуйте, Win2k, Вы писали:
IT>>Это всё тоже у нас в комплекте. Только вместо ассёртов исключения.
W> Можно посмеяться? Спасибо.
На здоровье.
W> В общем, исключения вообще проблемы не решают. Что такое ассерт? Это контракт. Это документация к коду. Это декларативное описание сути работы функции или метода.
Ассёрты — это мусор в коде. Ничего более. Причём мусор довольно опасный, т.к. в разных версиях компиляции программа ведёт себя по разному. Вообще, асёрты ещё как-то можно было простить лет 10 назад, но сегодня это такой же анахронизм как венгерка или, скажем, запрет звёздочки в SELECT. Что касается декларации, то тут я действительно от души посмеялся Настоящие индейцы сегодня пользуют DBC.
W>А если добавить ещё и тесты, то из ассертов и тестов, при грамотном подходе, можно не задумываясь восстановить код самой функции. А вы тут с исключениями...
Ну это понятно. Если написать асёрты и тесты, то сам код уже писать не надо.
IT>>А если код не твой или давно это было?
W> Вот именно. В этой ситуации и надо всё максимально заавтоматизировать. И код должен быть самодокументированным.
Код должен быть не самодукументируемым, а простым и понятным. Асётры, как я уже сказал, код только замусоривают, что приводит к совершенно противоположному эффекту.
IT>> Нужно по стеку побродить, посмотреть как оно куда чего.
W>Не нужно. Уверяю вас, нет ничего глупее, чем бродить по стеку.
Нет ничего глупее уверять меня в этом. Если в программе не испорчена поддержка исключений, то на поиск и диагностику практически любой стабильно повторяющейся ошибки уходит лишь нескольких секунд. Брожение по стеку незаменимая вещь при изучении контекста вызова и используемых им структур данных. Это особенно важно при изучении чужого кода. Ни один асёрт мне не скажет куда заведёт меня программа при определённом наборе параметров. Ведь часто меня интересует не почему программа не работает, а почему она работает так или иначе.
IT>>Это уже не совсем отладка.
W> А что тогда отладка? Пошагово смотреть, как работает и без того очевидный код
Определение очевидного кода в студию.
W>(ваш код не очевиден?
Не всегда.
W>переписать!)?
Без проблем. Вот один неочевидный код. Переписывай.
W>Ну найдете, что пришедший из хрензнаетоткуда поинтер показывает на чушь, и туда ещё раза три нагадили по дороге в других местах. Не покажет дебаггер, где именно указатель потерял смысл, никогда и ни за что. Он симптом покажет, то место, где всё сегфолтнулось. И это, кстати, самый тривиальный из примеров. Обычно ошибки гораздо коварнее.
Таких ошибок мы давно не видали. "хрензнаетоткуда поинтер" "показывает на чушь" Это всё глупости небезопасных сред. Впрочем, когда приходилось заниматься такой ерундой, то опция дебагера отловить изменение конкретного участка памяти (не помню как точно называется) не раз помогала без всяких асёртов.
W>Не по зубам они тем, кто привык дебаггерами играться.
Я по настоящему научился пользоваться отладчиком, когда после трёхдневных поисков одного бага и исчерпав все возможные асёрты, понял, что хватит страдать фигнёй и пора учиться пользоваться нормальными инструментами. Мне тогда было лет 25, я был невероятно крут и рассуждал примерно так же. Любую багу я мог попросту загонять голыми руками, что называется перебегать. Рано или поздно она сдавалась, шансов у неё не было. Но только не у ТОЙ. ТА бага меня победила. Победила в рукопашном бою. После этого я почесал репу, потратил немного времени на изучение отладчика и словил её родимую как миленькую. С тех пор я пользуюсь только хорошими и проверенными инструментами. Иногда приходится учится ими пользоваться, но ситуаций подобной той у меня больше никогда не было. Да и постарел я малость с тех пор, стал ленив. Мне проще подождать когда отладчик сам словит исключение, чем бегать по всему коду и голыми руками проверять не попалось ли что в капканы в виде асёртов.
Так что всё это мы давным давно проходили. И не надо тут выдавать за невероятную крутизну собственное неумение пользоваться инструментами и нежелание учиться это делать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Win2k, Вы писали:
IT>>Несчастный, как же ты вообще работаешь?
W> Господа, остерегайтесь программистов, задающих подобные вопросы. Видите программиста с отладчиком — увольняйте немедленно!!! Он вам понасажает множество труднообнаружимых ошибок, когда будет втыкать на скорую руку заплатки, устраняющие симптомы проблем (до сути проблем ведь они с дебаггерами никогда не докопаются, это просто физически невозможно).
Детский сад, штаны на лямках. Ты ещё порекомендуй вместо современных сред разработки пользоваться copy con hello.cpp.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
W>> Господа, остерегайтесь программистов, задающих подобные вопросы. Видите программиста с отладчиком — увольняйте немедленно!!! Он вам понасажает множество труднообнаружимых ошибок, когда будет втыкать на скорую руку заплатки, устраняющие симптомы проблем (до сути проблем ведь они с дебаггерами никогда не докопаются, это просто физически невозможно).
IT>Детский сад, штаны на лямках. Ты ещё порекомендуй вместо современных сред разработки пользоваться copy con hello.cpp.
Здравствуйте, FDSC, Вы писали:
FDS>>>Вставляют, ещё как . Вопрос в том, кто кодирует. Я, например, никогда не использую ассерты, потому что считаю избыточной любую проверку, которую нужно исключать из релизной версии. Хотя при отладке я иногда вставляю определённые проверки. Замечу, при отладке, хотя и не куда попало.
W>> В корне неверный подход. Ассерт — это, считай, документация. То, что словами ты писать поленишься. Ознакомься, например, с языком Eiffel, там эту мысль довели до совершенства.
FDS>Насколько мне помнится, в Eiffel эти проверки и в релиз идут, или нет? Я в общем-то знаю, там классные идеи.
Так это частности, идут или не идут. Детали реализации языка, к идеологии касательства не имеют. У меня в Java, например, контракты только в debug-версии собираются, а в release их и близко нет. Потому что за этим макры на Jatha следят. В программах на Common Lisp оно и вовсе просто делается, никаких сторонних примочек не надо.
FDS>Вопрос только в том, что я обычно пишу некоторые вещи словами, а assert'ы писать ленюсь — они очень тормозят работу, причём совершенно необоснованно. А обоснованные проверки я и в релиз включаю.
А препроцессор на что?
FDS>>>Хотя, обычно, ограниченное использование отладчика делает процесс разработки более строгим. Но некоторые типы ошибок без отладчика найти сложнее (например, когда неправильно понимаешь, как код скомпилирован в машинные команды).
W>> Когда не понимаешь — надо компилятор менять.
FDS> На какой? В любом компиляторе может найтись некоторая ошибка или неточность, которая будет видна только на уровне машинных команд, я, в основном, про это.
Так в этой ситуации тебе дебаггер тем более не помощник. По отладочному выводу обнаруживаешь несоответствие поведения кода ожидаемому, локализуешь проблему, и только после этого смотришь на то, какой ассемблер генерит компилятор (уж лучше на промежуточные файлы смотреть, с каментами, чем на результат дизассемблирования).
Здравствуйте, FDSC, Вы писали:
W>>сути работы функции или метода. А если добавить ещё и тесты, то из ассертов и тестов, при грамотном подходе, можно не задумываясь восстановить код самой функции. А вы тут с исключениями...
FDS>Вы ещё скажите, что исключениями нельзя реализовать контракты Я то же пишу вместо ассертов исключения — те же контракты, но работают они и в релизной версии.
Нельзя. Исключениями можно сообщать о результате срабатывания контракта. А сам контракт должен реализовываться макрами.
W>> Не нужно. Уверяю вас, нет ничего глупее, чем бродить по стеку.
FDS>Правильно, ничего интересного там нет....
Консенсус достигнут.
W>> А что тогда отладка? Пошагово смотреть, как работает и без того очевидный код (ваш код не очевиден? переписать!)? Ну найдете, что пришедший из хрензнаетоткуда поинтер показывает на чушь, и туда ещё раза три нагадили по дороге в других местах. Не покажет дебаггер, где именно указатель потерял смысл, никогда и ни за что. Он симптом покажет, то место, где всё сегфолтнулось. И это, кстати, самый тривиальный из примеров. Обычно ошибки гораздо коварнее. Не по зубам они тем, кто привык дебаггерами играться.
FDS>Отладка — это локализация и исправление ошибки.
Ошибки. А не её симптоматики. В этом то вся и проблема с пошаговым итерационным дебагом.
FDS> А тестирование — это максимум только часть локализации
Здравствуйте, IT, Вы писали:
W>> В общем, исключения вообще проблемы не решают. Что такое ассерт? Это контракт. Это документация к коду. Это декларативное описание сути работы функции или метода.
IT>Ассёрты — это мусор в коде. Ничего более.
Позвольте презреть ваше некомпетентное мнение.
IT> Причём мусор довольно опасный, т.к. в разных версиях компиляции программа ведёт себя по разному.
Это на самом деле полезно. Способствует скорейшему достижению стабильного инварианта.
IT> Вообще, асёрты ещё как-то можно было простить лет 10 назад, но сегодня это такой же анахронизм как венгерка или, скажем, запрет звёздочки в SELECT. Что касается декларации, то тут я действительно от души посмеялся Настоящие индейцы сегодня пользуют DBC.
А это тоже форма ассертов, между прочим. Да и аннотации в Why или Krokatoa — тоже такая вот декларативная форма ассертов.
IT>Ну это понятно. Если написать асёрты и тесты, то сам код уже писать не надо.
Именно так. Я не шучу.
W>> Вот именно. В этой ситуации и надо всё максимально заавтоматизировать. И код должен быть самодокументированным.
IT>Код должен быть не самодукументируемым, а простым и понятным. Асётры, как я уже сказал, код только замусоривают, что приводит к совершенно противоположному эффекту.
Ассерты несут в себе информацию, необходимую для понимания, которая в самом коде ОТСУТСТВУЕТ. Так что как раз наоборот без этой части информации оставшийся код является почти что шумом. Когда мы вычисляем, например, квадратный корень, то из выраженной в коде формулы соверешнно не следует, что аргумент должен быть строго положительным. Это внешняя информация, которая при выводе численного метода может быть потеряна — если её не притащить с собой аккуратно в виде констрейна.
За это, кстати, я и уважаю Axiom более всех прочих систем — только Axiom умеет не терять констрейны в процессе вычислений.
IT>>> Нужно по стеку побродить, посмотреть как оно куда чего.
W>>Не нужно. Уверяю вас, нет ничего глупее, чем бродить по стеку.
IT>Нет ничего глупее уверять меня в этом. Если в программе не испорчена поддержка исключений, то на поиск и диагностику практически любой стабильно повторяющейся ошибки уходит лишь нескольких секунд.
Это у вас ошибки примитивные. У меня такие ошибки на этапе компиляции обламываются. Посмотрю я, что будут делать любители бродить интерактивно по стеку в случае встречи с типичной сложной ошибкой.
IT> Брожение по стеку незаменимая вещь при изучении контекста вызова и используемых им структур данных.
А мне этого не надо. У меня каждый вызов сам знает, какие ограничения накладываются на принимаемые им структуры данных и на его результаты.
IT> Это особенно важно при изучении чужого кода. Ни один асёрт мне не скажет куда заведёт меня программа при определённом наборе параметров. Ведь часто меня интересует не почему программа не работает, а почему она работает так или иначе.
А в этой ситуации тем более ассерт полезнее всего прочего — ибо несёт ту самую потерянную информацию.
IT>Определение очевидного кода в студию.
Провокации отметаем на месте.
W>>(ваш код не очевиден?
IT>Не всегда.
Не программируйте больше.
W>>переписать!)?
IT>Без проблем. Вот один неочевидный код. Переписывай.
Ну да, я бы переписал покороче. Код хоть и вполне очевидный, но чрезмерно избыточный. Шума много, информации мало. Но при этом читается в один проход и никаких сложных записей и выкладок для понимания не требует.
Кстати, за такие приколы с properties я и люблю C#, в Java тот же код был бы ещё более громоздким.
IT>Таких ошибок мы давно не видали. "хрензнаетоткуда поинтер" "показывает на чушь" Это всё глупости небезопасных сред.
А в безопасных средах тем более на фиг не нужны дебаггеры.
IT>Впрочем, когда приходилось заниматься такой ерундой, то опция дебагера отловить изменение конкретного участка памяти (не помню как точно называется) не раз помогала без всяких асёртов.
Не вижу ни единого сценария, когда это могло бы помочь.
W>>Не по зубам они тем, кто привык дебаггерами играться.
IT> Я по настоящему научился пользоваться отладчиком, когда после трёхдневных поисков одного бага и исчерпав все возможные асёрты, понял, что хватит страдать фигнёй и пора учиться пользоваться нормальными инструментами.
А я после такой ситуации перестал пользоваться дебаггерами. И начал писать правильный код.
IT>Так что всё это мы давным давно проходили. И не надо тут выдавать за невероятную крутизну собственное неумение пользоваться инструментами и нежелание учиться это делать.
Дебаггерами я пользоваться умею. Точнее, умел. Уже лет 8 этого не делал. Ни разу не потребовалось. При том что ошибки бывали ну очень ядрёные.
Здравствуйте, IT, Вы писали:
W>> Господа, остерегайтесь программистов, задающих подобные вопросы. Видите программиста с отладчиком — увольняйте немедленно!!! Он вам понасажает множество труднообнаружимых ошибок, когда будет втыкать на скорую руку заплатки, устраняющие симптомы проблем (до сути проблем ведь они с дебаггерами никогда не докопаются, это просто физически невозможно).
IT>Детский сад, штаны на лямках. Ты ещё порекомендуй вместо современных сред разработки пользоваться copy con hello.cpp.
"Современные среды разработки" — как раз нечто из лексикона детсадовцев. Умные люди пользуются проверенными средствами, а не игрушками для сопляков, раскурченными ушлыми маркетоидами.
Здравствуйте, Win2k, Вы писали:
IT>>Ассёрты — это мусор в коде. Ничего более.
W> Позвольте презреть ваше некомпетентное мнение.
Позволяю, можешь его презреть даже два раза. Хоть три.
IT>> Причём мусор довольно опасный, т.к. в разных версиях компиляции программа ведёт себя по разному.
W> Это на самом деле полезно. Способствует скорейшему достижению стабильного инварианта.
Это способствует только более быстрому отказу от использования таких продуктов заказчиками. Т.к. качество сопровождения и оперативность фиксов багов в таких системах стремительно стремится к нулю. Только не надо здесь высказывать своё компетентное мнение, что багов в твоих продуктах не бывает... впрочем, я забыл, ты же кода не пишешь, одни асёрты
IT>> Вообще, асёрты ещё как-то можно было простить лет 10 назад, но сегодня это такой же анахронизм как венгерка или, скажем, запрет звёздочки в SELECT. Что касается декларации, то тут я действительно от души посмеялся Настоящие индейцы сегодня пользуют DBC.
W> А это тоже форма ассертов, между прочим. Да и аннотации в Why или Krokatoa — тоже такая вот декларативная форма ассертов.
Между этими формами такая же пропасть как между кодами возврата и исключениями. Т.е. фактически между ними нет ничего общего, кроме попыток решать одни и те же задачи.
IT>>Ну это понятно. Если написать асёрты и тесты, то сам код уже писать не надо.
W> Именно так. Я не шучу.
И не шути, а то уже не смешно становится.
IT>>Код должен быть не самодукументируемым, а простым и понятным. Асётры, как я уже сказал, код только замусоривают, что приводит к совершенно противоположному эффекту.
W> Ассерты несут в себе информацию, необходимую для понимания, которая в самом коде ОТСУТСТВУЕТ. Так что как раз наоборот без этой части информации оставшийся код является почти что шумом. Когда мы вычисляем, например, квадратный корень, то из выраженной в коде формулы соверешнно не следует, что аргумент должен быть строго положительным. Это внешняя информация, которая при выводе численного метода может быть потеряна — если её не притащить с собой аккуратно в виде констрейна.
Ну и в чём проблема? Эта информация может быть представлена в виде DBC, может быть программно захардкожена в предусловиях метода. Кто сказал, что варварский способ с асёртами является наилучшим?
IT>>Нет ничего глупее уверять меня в этом. Если в программе не испорчена поддержка исключений, то на поиск и диагностику практически любой стабильно повторяющейся ошибки уходит лишь нескольких секунд.
W>Это у вас ошибки примитивные.
Подобное течение беседы на этом сайте обычно плавно перетекает в обсуждение размеров головного мозга, обсуждающего примитивность собеседника, и заканчивается вопросами из серии: ты такой умный, тебе череп не жмёт? Так что давай лучше не будем двигаться в эту сторону. Договорились? Ну вот и славненько.
W>У меня такие ошибки на этапе компиляции обламываются. Посмотрю я, что будут делать любители бродить интерактивно по стеку в случае встречи с типичной сложной ошибкой.
Пример твоей типичной сложной ошибки приведёшь?
IT>> Брожение по стеку незаменимая вещь при изучении контекста вызова и используемых им структур данных.
W> А мне этого не надо. У меня каждый вызов сам знает, какие ограничения накладываются на принимаемые им структуры данных и на его результаты.
Причём тут ограничения? Что если меня ограничения не интересуют?
IT>> Это особенно важно при изучении чужого кода. Ни один асёрт мне не скажет куда заведёт меня программа при определённом наборе параметров. Ведь часто меня интересует не почему программа не работает, а почему она работает так или иначе.
W> А в этой ситуации тем более ассерт полезнее всего прочего — ибо несёт ту самую потерянную информацию.
Ещё раз для особо одарённых. Мне нужно понять как работает чужой код в тех или иных условиях, когда все формальные условия соблюдены.
IT>>Определение очевидного кода в студию.
W> Провокации отметаем на месте.
Так и запишем — привести определение отказался, склонен к демагогии.
W>>>(ваш код не очевиден? IT>>Не всегда. W> Не программируйте больше.
Стараюсь как можно меньше. Пока получается. Скорее всего потому, что не замусориваю свой код всякой дрянью.
W>>>переписать!)? IT>>Без проблем. Вот один неочевидный код. Переписывай. W> Ну да, я бы переписал покороче.
Я так понимаю, что языком
W>Код хоть и вполне очевидный, но чрезмерно избыточный. Шума много, информации мало. Но при этом читается в один проход и никаких сложных записей и выкладок для понимания не требует.
Так давай перепиши, в чём проблема. Убери шум, добавь информацию. А пока так и запишем — склонен к трепачеству.
IT>>Таких ошибок мы давно не видали. "хрензнаетоткуда поинтер" "показывает на чушь" Это всё глупости небезопасных сред.
W> А в безопасных средах тем более на фиг не нужны дебаггеры.
Часто действительно не нужны. В той же студии я запускаю программу чаще без отладки, чем с оной.
IT>>Впрочем, когда приходилось заниматься такой ерундой, то опция дебагера отловить изменение конкретного участка памяти (не помню как точно называется) не раз помогала без всяких асёртов.
W> Не вижу ни единого сценария, когда это могло бы помочь.
Перечитай своё предыдущее сообщение.
IT>> Я по настоящему научился пользоваться отладчиком, когда после трёхдневных поисков одного бага и исчерпав все возможные асёрты, понял, что хватит страдать фигнёй и пора учиться пользоваться нормальными инструментами.
W> А я после такой ситуации перестал пользоваться дебаггерами. И начал писать правильный код.
Если бы ты умел писать правильный код, то не говорил бы про... как ты там сказал?... "типичной сложной ошибкой". Во! Такие ошибки настоящие индейцы устраняют ещё на этапе проектирования. При кодировании должны оставаться как раз только примитивные ошибки, связанные с небрежностью, ленью, спешкой.
IT>>Так что всё это мы давным давно проходили. И не надо тут выдавать за невероятную крутизну собственное неумение пользоваться инструментами и нежелание учиться это делать.
W>Дебаггерами я пользоваться умею. Точнее, умел.
Я в этом сильно сомневаюсь.
W>Уже лет 8 этого не делал. Ни разу не потребовалось. При том что ошибки бывали ну очень ядрёные.
Вот-вот, опять про ядрёные. Ядрёные — это ошибки дизайна и архитектуры. Как тут могут помочь асёрты я вообще не понимаю
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Win2k, Вы писали:
IT>>Детский сад, штаны на лямках. Ты ещё порекомендуй вместо современных сред разработки пользоваться copy con hello.cpp.
W> "Современные среды разработки" — как раз нечто из лексикона детсадовцев. Умные люди пользуются проверенными средствами, а не игрушками для сопляков, раскурченными ушлыми маркетоидами.
Умным людям всё равно, считают ли разные трепачи и демагори используюемые ими инструменты игрушками для сопляков и раскручены ли они ушлыми маркетологами. Главное, чтобы бы было быстро, удобно и надёжно. А трепачи и демагоги идут в сад пользоваться своими каменными топорами, асёртами, кодами возврата, венгеркой и другими "проверенными средствами".
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, Шахтер, Вы писали:
Ш>>люди знали, как писать маленькие, эффективные программы -- навык, который впоследствии был утерян. (с) Таненбаум.
CS>You've made my day, дядько Шахтарь!
Здравствуйте, FDSC, Вы писали:
FDS>Читать нужно больше. Вы видимо эти два года не только телевизор не смотрели, но и ничем интеелектуальным, кроме программирования, не занимались
И кстати с чего ты взял, что я мало читаю ? И вообще давай завязывать с этим оффтопом.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
AVC>>По моим наблюдениям, пошаговый отладчик — всего лишь способ убить рабочее время с умным видом.
IT>Несчастный, как же ты вообще работаешь?
Я уже как-то тут делился наблюдением, что после перехода на C# стал частенько использовать пошаговый отладчик. В С++ все-равно много в отладчике не посмотришь при всем желании. Внутренности построенного шаблонного функтора ничего не скажут, тем более ничего не скажет полученный бог весть откуда интерфейс. ИНОГДА используем отладочный вывод/печать, по-сути та же пошаговая отладка, только в профиль.
К тому же в этой сильной статической типизации С++ больше уверенности, т.е. если уж получил коллекцию, где элементы по значению сидят, то можно даже не сомневаться в содержимом коллекции.
Здравствуйте, IT, Вы писали:
IT> Я по настоящему научился пользоваться отладчиком, когда после трёхдневных поисков одного бага и исчерпав все возможные асёрты, понял, что хватит страдать фигнёй и пора учиться пользоваться нормальными инструментами. Мне тогда было лет 25, я был невероятно крут и рассуждал примерно так же. Любую багу я мог попросту загонять голыми руками, что называется перебегать. Рано или поздно она сдавалась, шансов у неё не было. Но только не у ТОЙ. ТА бага меня победила. Победила в рукопашном бою. После этого я почесал репу, потратил немного времени на изучение отладчика и словил её родимую как миленькую. С тех пор я пользуюсь только хорошими и проверенными инструментами.
Если не секрет, в каком году это было?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
IT>Без проблем. Вот один неочевидный код. Переписывай.
Так и знал, что по ссылке гора еммита
Согласен, на ассемблере без дебага — ну никак вообще... В свое время я вдоволь намурыжил fd48/fd50... Альтернативой программным эмуляторам процессоров было выводить импульсы на свободные ножки портов.. Это вроде за отладочную печать сходило
Здравствуйте, vdimas, Вы писали:
IT>>Без проблем. Вот один неочевидный код. Переписывай.
V>Так и знал, что по ссылке гора еммита
Ну так а больше ничего интересного в управляемых средах и не придумать
V>Согласен, на ассемблере без дебага — ну никак вообще...
Не только на ассемблере. Сейчас приходится ковыряться в кишочках компилятора Nemerle, так там без отладчика, а именно без кнопки Watch делать нечего. Изучить полностью работу компилятора, а потом взять и всё написать — это утопия. Печатать всё в output, так сначала надо знать что печатать. Ставить асёрты, гы-гы, к чему это я? А вот поползать в отладчике по изучаемой структуре самое оно. Быстро, удобно, наглядно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
E>>Если не секрет, в каком году это было?
IT>Точно не помню, где-то между 92-м и 94-м. Borland C++, inline assembler, push в начале метода, pop в конце, return посередине
Я как раз в это время начал сталкиваться со случаями, когда отладчик не помогал в отладке. А до этого пошаговый трейс в Turbo Pascal/Turbo C/Turbo Debugger, штук десять переменных в окне Watch, окошко Evaluate на каждый чих. Иногда доходило вообще до смешного -- в первый раз на исполнение программа сразу под отладчиком запускалась
Так что у меня другая история -- от отладчика к отладочным печатям.
Сейчас запускаю отладчик раз в месяц, если какой-то Access Violation нужно быстренько обнаружить. А уж когда последний раз пошаговую отладку запускал, так вообще не вспомню.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
IT>>А если код не твой или давно это было? Нужно по стеку побродить, посмотреть как оно куда чего.
FDS>Ужас! Вы меня разочаровываете... неужели вы и вправду изучаете чужой код в отладчике? И помогает?
Я изучаю чужой код в отладчике и при этом ничуть этого не стыжусь.
Возможно если есть идеальный, достаточно сложный и объймный код, документированный и с кучей документации, который можно изучить без отладчика, на предмет внеснеиня фич, или устранения багов. Но это сродни вопросу про серебрянную(золотую титановую) пулю.
Моя реальность такова, что код писался какими-то полуграмотныит программистами в далеком 1998 в не менее далекой канаде, и по нему нет ничего кроме кода, закзчика и тучи клиентов. И вот что я Вам скажу, в отладчике гораздо проще понять что, когда, откуда и почему.
Возможно если программа чисто прикладная без работы со всякого рода "железками", то можно и без отладчика но в моём случае — это туева хуча контроллеров. Наверное и со всеми контроллерами можно разобраться, если они работают адекватно, и по ним есть документация, но, как Вы уже поняли, в моем случае это не так
Так что, в моей реальной жизни рулит отладчик.
ЗЫ Есть подозрение что для написание идеальной программы нужно дышать идеальным газом. Но увы и ах..
V>>Так и знал, что по ссылке гора еммита
IT>Ну так а больше ничего интересного в управляемых средах и не придумать
В рамках твоей работы нижесказанное прозвучит как ересь, тем не менее:
— я очень склонен определять для кодогенерации место в случае BLT как post-build step
— если мы имеем кодогенерацию как часть разработки, то с тем же успехом можно было генерить код в виде исходника на читабельном языке, ну а затем — один из мн-ва путей, начиная от интеграции tool+designer+VS2005+partial_classes, до генерации и компиляции исходников во временной директории с последующим уничтожением после получения бинарника.
В общем, мне оно так с самого начала показалось , (когда-то постил предложения по этому поводу).
V>>Согласен, на ассемблере без дебага — ну никак вообще...
IT>Не только на ассемблере. Сейчас приходится ковыряться в кишочках компилятора Nemerle, так там без отладчика, а именно без кнопки Watch делать нечего.
Вернее, не столько в кишочках самого компилятора ради академического интереса, сколько для контроля того, как твое некое расширение внутри компилятора себя чувствует, правильно? Тут я полностью согласен, именно пошагово и именно много я в дотнете отлаживал свои компоненты, когда они должны были работать в уже готовом довольно-таки сложном окружении. Что характерно, при работе в дотнете не меньше половины подобного кода.
IT>Изучить полностью работу компилятора, а потом взять и всё написать — это утопия. Печатать всё в output, так сначала надо знать что печатать. Ставить асёрты, гы-гы, к чему это я? А вот поползать в отладчике по изучаемой структуре самое оно. Быстро, удобно, наглядно.
Да все понятно. Собственно, все мы стараемся без фанатизма. Если не участвовать в "Философии" а смотреть со стороны, то замечаешь интересный эффект: стоит кому-нить из оппонентов проявить твердость и фанатизм, как вирус непокобелимости и твордости взглядов мгновенно перекидывается на оппонентов... В смысле, ты же сам однажды верно подметил, что некоторые вещи принципиально нереально в пошаговом режиме отлаживать. Например, критичный ассинхронный обмен (отладка в основном путем анализа отладочного лога), или же — пресловутые lazy-initialized св-ва, которые могут даже подвесить дебаггер студии при удачном раскладе (отладка — в основном на юнит-тестах).
В общем, как и 99% всех споров в "Философии" этот можно заканчивать банальным: "всё хорошо, если в меру и к месту".
Если нам не помогут, то мы тоже никого не пощадим.
1.1.4 stable rev. 510
Это всё глупости небезопасных сред. Впрочем, когда приходилось заниматься такой ерундой, то опция дебагера отловить изменение конкретного участка памяти (не помню как точно называется) не раз помогала без всяких асёртов.
"Всё что не убивает нас, делает нас сильнее..."
