У меня нет сторонних переключалок и переключение стоит на Ctrl+Shift, но симптомы те же. Так что дело не в переключалках.
Набираю быстро и иногда забавно наблюдать: переключил раскладку, начинаешь набирать и видишь, как первые 1-3 символа выходят в старой раскладке, а остальные — уже в новой. :)
В вашей контраргументации для меня остались непонятными следующие моменты:
1. С какими причинами будут бороться проектировщики, если, как вы утверждаете, эти причины невозможно установить?
2. В чем проблема установить причину сбоя банковского компьютера или самоуправляемого автомобиля?
Причем все компоненты и сенсоры от разных производителей. Кто отвечать будет?
Спасибо, вы мне напомнили замечательную сценку Аркадия Райкина «Кто сшил костюм?». :)
А теперь серьезно:
Самое главное в снижении вероятности возникновения нежелательной ситуации — бороться с причинами, а не со следствием. Согласны?
Если да, то согласитесь и с тем, что банковские компьютеры/самоуправляемые автомобили/собаки/etc. пока не могут бороться с причинами, чтобы снизить вероятность повторения подобных ситуаций в будущем. А вот homo sapiens — может.
Отсюда вопрос: если мы хотим улучшить ситуацию, то кого в первую очередь надо бить по мягкому месту? Homo sapiens или компьютер/автомобиль/собаку? :)
Поэтому никакого «прекрасного прецедента» для автомобилей/роботов я пока не вижу.
Насчет красивости — вопросы личного вкуса.
Лично мне окольные пути (когда чтобы наказать банк, сначала пришлось «наказать» компьютер) красивыми не кажутся. Это как почесать левой ногой правой ухо: цель достигнута, но окольными путями. Хотелось бы, чтобы таких решений в реале было поменьше. Наверное, я — безнадежный технарь. :)))
И они ему физически отломают часть винта и часть памяти.
Любопытно, как судебные приставы смогли бы отломать часть винта? :)
Всё равно считаю судебное решение некрасивым. За ошибки техники должна отвечать организация, а не мертвое железо. Отвечать прямо, а не путем нахождения подходящих юридических уловок.
А если, допустим, на заводе взрывоопасные емкости самопроизвольно взрываются и наносят ущерб прилегающим жилым кварталам? Емкости накажем? Приговорим их к смертной казни путем принудительного подрыва? :)
1. Если видите разницу и понимаете, что это две разные темы, то почему безо всяких переходов, оговорок и т.п. перескакиваете с одной темы на другую?
2. Что непонятного в контрпримере? В нем показано, что для определенных людей (цитирую) «есть понятие «черная работа» и им не всё равно, что делать». Это согласуется с вашим заявлением «нет такого понятия «черная работа»»? Нет. Тогда в чем проблемы с пониманием контрпримера? С точки зрения логики вы должны либо поставить под сомнение существование таких людей, либо согласиться с тем, что «черная работа» всё-таки существует (пусть даже не для вас, а для них — речь-то шла о всех людях, а не конкретно о вас).
Проблема в том, что вы сначала делаете слишком категоричные/общие заявления (из-за чего люди с вами не соглашаются) и только потом начинаете добавлять различные оговорки/ограничения, постепенно приближающие ваши заявления к более-менее приемлемым.
Ваше утверждение (см. выше) об отсутствии черной работы слишком жесткое/категоричное. А комментарий, на который вы сейчас ссылаетесь, — уже более мягкий: существование черной/грязной/слишком простой работы косвенно всё-таки признается и так же косвенно признается, что ее желательно ограничивать для специалистов рангом намного выше.
Вы подменили контекст нашего обсуждения:
Изначально было — «Нет черной работы».
Теперь вы обсуждаете — «Делать только что интересно».
Это две разные темы (хотя частично и пересекаются). Неужели не видите между ними разницу?
Не для всех это правило верно.
Есть люди из серии «любой каприз за ваши деньги»: они готовы работать хоть на побегушках — лишь бы вы им платили з/п специалиста экстра-класса.
А есть люди, которые хотят расти профессионально: они хотят заниматься задачами экстра-класса даже на условиях зарплаты работника на побегушках. Так вот для этих людей есть понятие «черная работа» и им не всё равно, что делать.
24 года профессионального, т.е. за деньги программирования. Начиная с ЕС ЭВМ.
А теперь по делу:
1. Кол-во строк кода зависит от языка программирования. Когда слышу об ограничениях 15-20-30 строк в методе, становится смешно — у нас часто одна SQL-команда имеет больше размер.
2. Манера написания кода зависит от преследуемых целей. Если «Лишь бы заработало (написал-сдал-забыл)», то это одно. Если «Чтобы потом проще было 100500 раз модифицировать», то совсем другое. А если главное — как можно быстрее находить и устранять ошибки в практически незнакомом коде в режиме жесткого цейтнота, то это уже третье.
Теперь представьте ситуацию:
— Большой проект (сотни тысяч строк кода).
— Работа с базами данных (см. про размер команд).
— Допустимый срок устранения ошибок — максимум час-другой (обычно не более 20-30 минут) силами одного(!) дежурного программиста. Соответственно, на большинство кода он смотрит, будто видит в первый раз (даже если он сам его написал полгода назад).
— Произошла ошибка, характер которой пока неясен: то ли ошибка в постановке, то ли в алгоритме, то ли защита от дурака не всё выловила, а может просто непонятный сбой какой-то произошел и т.д. Т.е. по ходу дела нужно вникать в ситуацию.
По своему опыту скажу, что локализация места ошибки с точностью до функции предметного уровня обычно проходит достаточно быстро. А дальше наступает черед уровня языка программирования. И от того, как представлена эта предметная функция — одним куском или развесистой иерархией мелких методов — сильно зависит скорость и время разборки с проблемой.
Оперативная память в мозгах у программиста не резиновая (а кэш еще меньше — слышали, наверное, о 7+-2?), а время ограничено. Что такое каждый дополнительный метод? Это дополнительная информация как минимум в виде:
— названия метода
— списка и порядка его параметров
— позиции этого метода в последовательности вызовов
— позиции этого метода в иерархии других методов.
А теперь представьте, что искусственно созданных на ровном месте методов десятки и образуют они многоуровневое дерево (правильная с точки зрения теории декомпозиция). Всё — выгрузка в своп обеспечена! А это — дополнительные затраты сил и времени. В то время, когда можно было бы обойтись без них.
Есть и другие моменты. Например, отслеживание, где присваиваются/меняются поля таблиц из искомого вами списка. Особенно если учесть, что таких полей может быть несколько и в SELECT SQL допускается неявное присвоение им значений. Даже если текстовый редактор при поиске забросит вас в какой-нибудь метод, вам это слабо поможет, т.к. сам найденный код еще ничего не значит — для анализа вам придется сначала сориентироваться: когда, откуда и при каких обстоятельствах этот метод вызывается, есть ли до его вызова другие присвоения искомым полям и т.д. В рамках единого последовательного куска кода таких проблем нет — скользишь взглядом сверху вниз и последовательно видишь весь ход процесса, попутно отслеживая нужные имена.
Есть и другие нюансы, которые слету не вспомнить. Можете поверить на слово: программисты, которые работают с проектом такого уровня и способны в столь короткое время локализовывать проблемы, — далеко не чайники. И профнепригодными в плане декомпозиции их не назовешь, раз они ее сначала сделали, а потом часть методов всё же решили собрать в один большой. И уж поверьте: раз эти программисты, поработав с «правильной» декомпозицией какой-то предметной функции, заменили ее на единый кусок кода, то им было с чем сравнивать и были серьезные доводы для такого шага.
Я не агитирую за написание кода единым куском.
Я просто хочу еще раз напомнить, что у всякого правила бывают исключения.
В нашем случае это код, который обладает следующими характеристиками:
— длинный, но последовательно выполняемый (без ветвлений и циклов)
— никакая его часть нигде больше не используется
— с предметной точки зрения выполняет одну функцию
— требует максимально быстрого поиска и устранения ошибок.
Вот такой код действительно легче обслуживается единым куском — без разбиения на иерархию методов.
У нас подобных участков кода крайне мало (наверное, доли процента), но они есть.
P.S. Ситуация схожа с командой GOTO. Я помню времена, когда ее чуть ли не анафеме предали. Потом оказалось, что в отдельных случаях грамотнее делать всё-таки с GOTO (если язык позволяет), чем на ровном месте плодить кучу флагов.
Очень помогал обсчитывать результаты в лабах, когда нужно было сделать много однотипных, повторяющихся действий над разными наборами чисел. Пока остальные ковырялись с обычными инженерными калькуляторами, я лишь вбивал исходные данные, а потом доставал результаты обсчета.
P.S. Книжка Дьяконова до сих пор у родителей дома валяется.
Fortran у нас тоже был, но только в порядке общего ознакомления. По программе был положен, но наш препод его не любил и поэтому больше времени уделял предпочитаемому им PL/I. За что я ему благодарен, т.к. именно PL/I позже стал моим первым профессиональным языком (за программирование на котором я получал зарплату на заводе).
Нас тоже не допускали. Сдавали на допуск к перфоратору, вслепую (не видя, что же в действительности набралось) набивали программу на перфокартах и клали в специальные ящички. На следующий день шли за распечатками результатов.
Я тоже раньше думал с такими же категоричностью и максимализмом. Пока жизнь не показала ситуации, когда код метода в 500 строк оказывался на порядок удобнее для сопровождения и понимания. Нашим программистам даже пришлось в некоторых местах собирать код нескольких методов обратно в один метод — чтобы удобнее работать было. «Не бывает правил без исключений, включая данное правило». (С) Не мой.
Кстати, и развитие человечества часто идет по следующему пути: что-то сначала кажется универсальным и очевидным, имеющим бесконечные границы (правило на все случаи жизни), а через некоторое время кто-то натыкается на границы применимости и «Прощай, догма!».
1. Знаете, я, в отличие от вас, еще успел застать те времена. А вы хотя бы почитайте, чья бытовая аудио- (а позже и видео-) техника, одежда, обувь, сантехника/мебель/т.п. особо ценилась в те времена — импортная или отечественная. Заодно узнаете, за что ценились поездки за рубеж, откуда возникло такое явление, как фарцовщики, «фирмА», почему ни один знающий человек не желал покупать отечественную технику, сделанную в конце декабря и т.д.
2. Знаете другие, более эффективные варианты? Экономикс не знает. И я лично не знаю. Если вы знаете — поделитесь со всеми. Думаю, что очень многие будут сильно удивлены. А я лично буду очень благодарен. ;)
Сколько человек надо подкупить, что протолкнуть хреновый товар через 1 контроллера/отдел/службу/т.п.? А сколько — чтобы втюхать некачественный товар сотням тысяч и даже миллионам покупателей этого товара? Т.е. разница — на много-много порядков. Вот и сравнивайте, где система надежнее и неподкупнее. Причем наказание контроллеру за пропуск некачественного товара может будет, а может нет, а вот покупатель такой товар ощутит на своей шкуре уже гарантированно.
Извините, что я тут настолько примитивнейшие истины вам рассказываю. Но вы сами напросились. ;)
А теперь с превеликим интересом выслушаю ваши контраргументы. Если, конечно, они есть. ;)
Хм, кто согласен со мной — ставит плюс, а кто не согласен — втихаря минусует мне карму. :( Нет бы аргументированно (а еще лучше с примерами) возразить…
Набираю быстро и иногда забавно наблюдать: переключил раскладку, начинаешь набирать и видишь, как первые 1-3 символа выходят в старой раскладке, а остальные — уже в новой. :)
1. С какими причинами будут бороться проектировщики, если, как вы утверждаете, эти причины невозможно установить?
2. В чем проблема установить причину сбоя банковского компьютера или самоуправляемого автомобиля?
Спасибо, вы мне напомнили замечательную сценку Аркадия Райкина «Кто сшил костюм?». :)
А теперь серьезно:
Самое главное в снижении вероятности возникновения нежелательной ситуации — бороться с причинами, а не со следствием. Согласны?
Если да, то согласитесь и с тем, что банковские компьютеры/самоуправляемые автомобили/собаки/etc. пока не могут бороться с причинами, чтобы снизить вероятность повторения подобных ситуаций в будущем. А вот homo sapiens — может.
Отсюда вопрос: если мы хотим улучшить ситуацию, то кого в первую очередь надо бить по мягкому месту? Homo sapiens или компьютер/автомобиль/собаку? :)
Поэтому никакого «прекрасного прецедента» для автомобилей/роботов я пока не вижу.
Лично мне окольные пути (когда чтобы наказать банк, сначала пришлось «наказать» компьютер) красивыми не кажутся. Это как почесать левой ногой правой ухо: цель достигнута, но окольными путями. Хотелось бы, чтобы таких решений в реале было поменьше. Наверное, я — безнадежный технарь. :)))
Всё равно считаю судебное решение некрасивым. За ошибки техники должна отвечать организация, а не мертвое железо. Отвечать прямо, а не путем нахождения подходящих юридических уловок.
А если, допустим, на заводе взрывоопасные емкости самопроизвольно взрываются и наносят ущерб прилегающим жилым кварталам? Емкости накажем? Приговорим их к смертной казни путем принудительного подрыва? :)
2. Что непонятного в контрпримере? В нем показано, что для определенных людей (цитирую) «есть понятие «черная работа» и им не всё равно, что делать». Это согласуется с вашим заявлением «нет такого понятия «черная работа»»? Нет. Тогда в чем проблемы с пониманием контрпримера? С точки зрения логики вы должны либо поставить под сомнение существование таких людей, либо согласиться с тем, что «черная работа» всё-таки существует (пусть даже не для вас, а для них — речь-то шла о всех людях, а не конкретно о вас).
Ваше утверждение (см. выше) об отсутствии черной работы слишком жесткое/категоричное. А комментарий, на который вы сейчас ссылаетесь, — уже более мягкий: существование черной/грязной/слишком простой работы косвенно всё-таки признается и так же косвенно признается, что ее желательно ограничивать для специалистов рангом намного выше.
Изначально было — «Нет черной работы».
Теперь вы обсуждаете — «Делать только что интересно».
Это две разные темы (хотя частично и пересекаются). Неужели не видите между ними разницу?
Вы сказали, что нет такого понятия как «черная работа» — я привел контрпример, только и всего.
N.B. Минус поставил вам не я.
Есть люди из серии «любой каприз за ваши деньги»: они готовы работать хоть на побегушках — лишь бы вы им платили з/п специалиста экстра-класса.
А есть люди, которые хотят расти профессионально: они хотят заниматься задачами экстра-класса даже на условиях зарплаты работника на побегушках. Так вот для этих людей есть понятие «черная работа» и им не всё равно, что делать.
А теперь по делу:
1. Кол-во строк кода зависит от языка программирования. Когда слышу об ограничениях 15-20-30 строк в методе, становится смешно — у нас часто одна SQL-команда имеет больше размер.
2. Манера написания кода зависит от преследуемых целей. Если «Лишь бы заработало (написал-сдал-забыл)», то это одно. Если «Чтобы потом проще было 100500 раз модифицировать», то совсем другое. А если главное — как можно быстрее находить и устранять ошибки в практически незнакомом коде в режиме жесткого цейтнота, то это уже третье.
Теперь представьте ситуацию:
— Большой проект (сотни тысяч строк кода).
— Работа с базами данных (см. про размер команд).
— Допустимый срок устранения ошибок — максимум час-другой (обычно не более 20-30 минут) силами одного(!) дежурного программиста. Соответственно, на большинство кода он смотрит, будто видит в первый раз (даже если он сам его написал полгода назад).
— Произошла ошибка, характер которой пока неясен: то ли ошибка в постановке, то ли в алгоритме, то ли защита от дурака не всё выловила, а может просто непонятный сбой какой-то произошел и т.д. Т.е. по ходу дела нужно вникать в ситуацию.
По своему опыту скажу, что локализация места ошибки с точностью до функции предметного уровня обычно проходит достаточно быстро. А дальше наступает черед уровня языка программирования. И от того, как представлена эта предметная функция — одним куском или развесистой иерархией мелких методов — сильно зависит скорость и время разборки с проблемой.
Оперативная память в мозгах у программиста не резиновая (а кэш еще меньше — слышали, наверное, о 7+-2?), а время ограничено. Что такое каждый дополнительный метод? Это дополнительная информация как минимум в виде:
— названия метода
— списка и порядка его параметров
— позиции этого метода в последовательности вызовов
— позиции этого метода в иерархии других методов.
А теперь представьте, что искусственно созданных на ровном месте методов десятки и образуют они многоуровневое дерево (правильная с точки зрения теории декомпозиция). Всё — выгрузка в своп обеспечена! А это — дополнительные затраты сил и времени. В то время, когда можно было бы обойтись без них.
Есть и другие моменты. Например, отслеживание, где присваиваются/меняются поля таблиц из искомого вами списка. Особенно если учесть, что таких полей может быть несколько и в SELECT SQL допускается неявное присвоение им значений. Даже если текстовый редактор при поиске забросит вас в какой-нибудь метод, вам это слабо поможет, т.к. сам найденный код еще ничего не значит — для анализа вам придется сначала сориентироваться: когда, откуда и при каких обстоятельствах этот метод вызывается, есть ли до его вызова другие присвоения искомым полям и т.д. В рамках единого последовательного куска кода таких проблем нет — скользишь взглядом сверху вниз и последовательно видишь весь ход процесса, попутно отслеживая нужные имена.
Есть и другие нюансы, которые слету не вспомнить. Можете поверить на слово: программисты, которые работают с проектом такого уровня и способны в столь короткое время локализовывать проблемы, — далеко не чайники. И профнепригодными в плане декомпозиции их не назовешь, раз они ее сначала сделали, а потом часть методов всё же решили собрать в один большой. И уж поверьте: раз эти программисты, поработав с «правильной» декомпозицией какой-то предметной функции, заменили ее на единый кусок кода, то им было с чем сравнивать и были серьезные доводы для такого шага.
Я не агитирую за написание кода единым куском.
Я просто хочу еще раз напомнить, что у всякого правила бывают исключения.
В нашем случае это код, который обладает следующими характеристиками:
— длинный, но последовательно выполняемый (без ветвлений и циклов)
— никакая его часть нигде больше не используется
— с предметной точки зрения выполняет одну функцию
— требует максимально быстрого поиска и устранения ошибок.
Вот такой код действительно легче обслуживается единым куском — без разбиения на иерархию методов.
У нас подобных участков кода крайне мало (наверное, доли процента), но они есть.
P.S. Ситуация схожа с командой GOTO. Я помню времена, когда ее чуть ли не анафеме предали. Потом оказалось, что в отдельных случаях грамотнее делать всё-таки с GOTO (если язык позволяет), чем на ровном месте плодить кучу флагов.
P.S. Книжка Дьяконова до сих пор у родителей дома валяется.
PL/I на ЕС ЭВМ (1020). Еще на перфокартах.
Есть тут динозавры из той эпохи? ;)
«Не бывает правил без исключений, включая данное правило». (С) Не мой.
Кстати, и развитие человечества часто идет по следующему пути: что-то сначала кажется универсальным и очевидным, имеющим бесконечные границы (правило на все случаи жизни), а через некоторое время кто-то натыкается на границы применимости и «Прощай, догма!».
2. Знаете другие, более эффективные варианты? Экономикс не знает. И я лично не знаю. Если вы знаете — поделитесь со всеми. Думаю, что очень многие будут сильно удивлены. А я лично буду очень благодарен. ;)
Сколько человек надо подкупить, что протолкнуть хреновый товар через 1 контроллера/отдел/службу/т.п.? А сколько — чтобы втюхать некачественный товар сотням тысяч и даже миллионам покупателей этого товара? Т.е. разница — на много-много порядков. Вот и сравнивайте, где система надежнее и неподкупнее. Причем наказание контроллеру за пропуск некачественного товара может будет, а может нет, а вот покупатель такой товар ощутит на своей шкуре уже гарантированно.
Извините, что я тут настолько примитивнейшие истины вам рассказываю. Но вы сами напросились. ;)
А теперь с превеликим интересом выслушаю ваши контраргументы. Если, конечно, они есть. ;)
P.S. Это вы карму мне минусанули? ;)