Comments 24
Самый дешёвый, быстрый и надёжный компонент компьютерной системы — это тот, которого нет. Гордон Белл, Encore Computer Corporation
Тут скорее речь идет про софт. То чего нет не может сломаться.
То чего нет не может сломаться.
Именно. Поэтому отсутствующий тормоз лучше сломанного.
Чем лучше?
Меньше шансов что заподозрят в принадлежности к тем трусам, которые тормоза придумали.
Нет, это не так работает. Считается что при этом функционал системы - константа. И чем меньше в ней компонентов, чем меньше сложность - тем лучше.
Об отсутствии тормоза ты знаешь, а о поломке имеющегося -- не факт. Соответственно при отсутствии тормоза ты это учитываешь в своем поведении, а поломка имеющегося будет для тебя сюрпризом в неподходящий момент.
Отсутствующий тормоз действительно лучше сломанного тем, что садясь в транспортное средство без тормозов, ты заранее это знаешь и имеешь какой-то план, а как же все-таки тормозить, так как отсутствие тормоза в данном случае штатная ситуация.
А вот сломанный тормоз вынуждает действовать экспромтом в большинстве случаев? И даже если ты специально к этому готовился и имеешь план на случай отказа тормозов, то это проблема и нештатная ситуация.
В ТРИЗ идеальная техническая подсистема — это подсистема, которая ликвидирована при полном сохранении её функциональности.
Насчет акрксинуса и арккосинуса готов поспорить. Тут речь не об оптимизации, а о том, что при правильном использовании векторной геометии их можно вобще не вычислять.
Константа для одного человека — это переменная для другого. Сьюзан Герхарт, Microelectronics and Computer Technology Corp.
Тут речь не о программерском смысле слов "константа" и "переменная". Что одни видят неизменным, другие умеют менять и регулярно это делают.
Глубинный смысл этого афоризма — любая часть системы может стать настраиваемой.
Есть классическая цитата про дзен-ПО:
Самый лучший код - это код, который не написан. Он не тормозит, не занимает память и не содержит ошибок
Его единственная проблема - он не делает ничего полезного.
Думаю, по большей мере этот афоризм сегодня неактуален. Скорость человеческого ввода ограничена, но компьютеры могут мгновенно генерировать огромные объёмы данных. Однако выросли и способности машин в потреблении данных.
Недавно разбирал заявку от тестирования "не проходит регрес тест в web сайта на смену пароля пользователя". Ну да.. скриптом же эмулировали работу с сайтом. "после заполненния формы смены пароля - закрыть страницу - открыть заново и попытаться войти новым паролем". Судя по логу пытались сделать это в течении 10ms. Пароль просто не успевал сменится. Так что все это актуально.
Самый дешёвый, быстрый и надёжный компонент компьютерной системы — это тот, которого нет. Гордон Белл, Encore Computer Corporation
Мне кажется, это немного несправедливо. С меньшим количеством ОЗУ ноутбук дешевле, но от этого он не становится быстрее.
С точки зрения сотрудников эксплуатации (чьи результаты работы определяются отсутсвиеме инцидентов), самое надежное и доставляющее меньше проблем ПО - это то что стоит на выключенном компе, закрытом в сейфе, что бы никто его не смог включить.
Подозреваю эта вечная истина и имелась в виду.
[Правило доверия] На первые 90% кода тратится 90% времени разработки. На оставшиеся 10% кода тратится ещё 90% времени разработки. Том Кэргилл, Bell Labs
Методология Agile немного ослабила силу этого прогноза. Мне кажется, сегодня разработчики обычно лучше справляются с оценками затрат времени. Но избежать парадокса Зенона всё равно сложно.
Agile.. Это методология позволяющая, в частности, не говорить заказачику "сколько тебе это обойдется" сразу, а просто тянуть с него деньги в процессе работы. Так что ничего она не меняет с точки зрения "того кто платит". Как были неопредеенности и риски на 0-м этапе. Так и осталось.
Нам больше не приходится выравнивать данные по физическим дорожкам вращающегося диска
Вот только потроха всего ПО с историей длиннее 10 лет (Postgre к примеру) ориентировано на физические дорожки и минимизацию дерганья головки по диску.
Тестирование может показать присутствие багов, но не их отсутствие. Эдсгер Дейкстра, Техасский университет
Осмелимся ли мы перечить Дейкстре?! Ну, только если немного. Благодаря современным инструментам фаззинга мы можем показать отсутствие определённых видов багов.
Ничо не поменялось. Никакие "соврменные" (тесты со случаным набором данным и 30 лет назад использовались) инструменты с умными названиями не отменяют того, что любая более менее сложная программа содерждит баги (не найденные сейчас или не найденный никогда).
И передача на вход случайных данных никак не гарантирует что программа не сломается на случайных данных которые не были спользованы на данный момент тестирования. И никак не гарантирует, что программа на самом деле сломалась, просто критерии "сломалось" в инструменте задали не правильно или вообще не учли.
Так что тестирование находит баги, а не доказывает что их нет. Так было и будет.
Электричество движется со скоростью фут в наносекунду. Коммодор Грейс Мюррей Хоппер, ВМФ США
И на нановек за пи секунд! Это один из тех фактов для викторин, неактуальных в современных компьютерных системах.
Эхх. современным программистам уже не обязательно знать как железо работает. А так то 40 лет назад (да и 30) схемотехнику знали большинство программеров. И этот афоризм и на что он намекает не вызывал удивления.
А ща, для программеров, железо это "черный ящик" и отсюда коммент "неактуальных в современных компьютерных системах". Актуально. Только этим другие люди озабочены (которые микросхемы проектируют и дорожки на платах и т.п.)
...
Было очень забавно прочитать и сами афоризмы (когда то читал и понимаю о чем речь в них) и коментарии.
Напиши свою программу с молоду а не к пенсии.
Самый дешёвый, быстрый и надёжный компонент компьютерной системы — это тот, которого нет. Гордон Белл, Encore Computer Corporation
Мне кажется, это немного несправедливо. С меньшим количеством ОЗУ ноутбук дешевле, но от этого он не становится быстрее.
Мне кажется что вы не совсем правильно поняли что имелось ввиду.
Я всегда это понимал как принцип YAGNI.
В ТРИХ есть понятие идеальной системы:
Идеальная система – это такая система, которой нет, а функция которой выполняется.
P.S. Я как-то слышал байку о том что конструктор танка T-34 говорил что: "Cамая лучшая деталь в танке та, которой в нем нет!"
старые советы сильно более глубокие и мудрые, чем современные комментарии к ним
Мне во эта подборка нравится:
Мысли о программировании https://lib.ru/ANEKDOTY/merfi.txt#13
И ещё БУСИДО ПРОГРАММИСТА НА IBM, PC, XT, AT, PS/2 и т.д. В СССР
Скрытый текст
1. Программист должен иметь толстую задницу, пустую голову и коротко остриженные ногти на правой руке.
2. Программист должен стремиться к отладке. Если ситуация имеет два выхода, один из которых - завершить работу над программой, а другой отлаживать дальше, то программист должен выбирать второй путь.
3. Дата завершения программы невычислима и непостижима. Для спокойствия души программист должен вообще забыть о том, что он когда-нибудь кончит писать эту программу.
4. Программист программирует процесс собственного программирования.
5. Если в вашей программе есть байт, который вам не нравится, перепишите ее всю.
6. Хороша та программа, которая продается. Программа не считается законченной, пока клиент не расплатился.
7. На вопрос: "Можете ли вы написать данную программу?" настоящий программист отвечает одним из двух способов:"Могу" или "Могу, но не знаю как".
8. Нет игр, кроме ТЕТРИСа, да и тот нудянка страшная.
9. Настоящий программист пользуется стандартными средствами. Почти все программы уже давно написаны.
10. Обязательные действия настоящего программиста: распечатывать дампы, читать документацию, дышать, есть и спать. Высший приоритет у сна.
11. Информация аддитивна.
12. Настоящий программист должен иметь четко сформулированное представление о месте программирования в жизни. Например:
- Любое неотложное дело можно отложить на любое неопределенное время. Нельзя откладывать только излишества и развлечения.
- Работа должна напоминать досуг.
- От работы кони дохнут.
- Лучше ничего не делать, чем делать ничего. и т.д.
13. Зарезервировано для дальнейшего развития.
Полная версия с комментариями: http://home.onego.ru/~sacur/11ibm.shtml
Слишком большое количество багов возникает из-за непонимания требований пользователя/заказчика.
При чем тут требования заказчика если речь явно о формализации логики и дизайна
Считаю лучшей книгой по программированию. Первый раз читал во время становления как разработчика, с удовольствием перечитаю в будущем и сравню восприятие.
Круто! Мой покойный отец когда-то рассказывал мне про эту книгу и всегда сыпал цитатами из нее. Тем интереснее было спустя десятилетия прочитать оригиналы и современные интерпретации.
Особенно про то что на английском сначала понятно нужно написать. Все так переживают что GPT заменит программистов, а толково задачу в джире описать не могут, даже зная что читать этот бред будет человек.
«Программисты на LISP знают ценность всего и стоимость ничего.» Алан Перлис, Йельский университет
Сегодня программисты на LISP занесены в Красную книгу, и с ними нельзя обращаться столь строго.
цитата и ответ на неё чушь, здесь непереводимая игра слов, это раз
«Программисты на Лисп знают значение всего на свете, но не знают ничему цену»
переводится она так, это два
а значит то, что всё в лиспе это выражение, а значит и значение имеет абсолютно всё, но с вычислениями у языка беда, это три
Актуальны ли спустя 40 лет советы из «Жемчужин программирования»?