Войти
Регистрация
Сообщение отредактировал yedyge: 14.04.2010, 17:57:39
Программистский юмор(без сисадминского)
Автор yedyge, 10.09.2009, 13:16
Наверх
#103
Отправлено 22.04.2010, 17:05:01
asr
-
- Модератор
- 24 325 сообщений
Не мое прислали по почте:
Программизм:
история одной болезни
Вероятно, в этой статье нет ни одной новой или свежей мысли, мало того, я уверен, что вы уже не раз читали нечто подобное. Статья не претендует и на то, чтобы быть истиной. Ее содержание – плод собственного опыта, проб, ошибок и одновременно выжимка из тех знаний, которые удалось перенять от коллег, прочитать на Хабре и в других местах. Наверное, для каждого конкретного индивидуума то, что сказано в этом тексте, будет сильно отличатся от действительности, но, я уверен, многие смогут узнать в описании себя. Первая стадия, наверное, не очень характерна для программистов, которые не занимались олимпиадным программированием в бытность студентами или учениками, а вот следующие уже практически никак не зависят от этого фактора.
Стадия первая.
Рождение
«Я программист. Я олимпиадник. Я знаю что такое «о»-маленькое. Я знаю, что такое «О»-большое. Я понимаю, чем отличается «эн-квадрат» от «эн-факториала» и почему они оба стыдливо прячутся при виде «эн-логарифм-эн». Сейчас я приду на проект и перепишу эту тормозную кашу из кода так, что она будет работать в много раз быстрее! Смотрите, я знаю алгоритм Кнута-Морриса-Пратта! А здесь можно сэкономить одно сравнение строчек на равность! А если эту рекурсию развернуть в цикл, то за счет экономии вызовов методов и выделения памяти в стэке… Что, программа тормозит? Сейчас я посмотрю код… Вот! Смотрите, здесь вместо двух вложенных циклов можно написать один и использовать бинарный поиск вместо внутреннего!»
Знакомтесь, это первая стадия. Она, в отличие от следущих, особенно характерна именно для олимпиадников. Пациент думает о том, как написать быстрый код. Он одержим быстрым кодом. К сожалению, наличие быстрого кода не всегда делает быстрым программный продукт в целом.
Пациент переписал оптимальным образом кусок кода, который выполняется один раз при старте веб-сервера и на общей производительности это никак не отразилось. Пациент переписал кусок кода, который потом 10 раз меняли в связи с изменением требований по проекту и его микрооптимизации вызвали при этом тучу трудноуловимых багов. Его алгоритм выполняется за линейное время, тогда как старый выполнялся за квадратическое, но старый при этом делал один запрос к базе данных, а новый делает его в каждой итерации. Пациент не догадывается, что с веб-проектом работает много пользователей одновременно и использование статических данных чревато… Продолжать можно долго.
Основная проблема пациента в том, что он мыслит парой классов или методов и при этом не совсем осознает, что происходит вокруг этой части проекта. Его мышление ограничено кодом и алгоритмом его работы, то есть тем, как работает программа, а не тем, что она должна делать. Впрочем, эта стадия редко продолжается достаточно долго, чтобы больной мог нанести вред себе или окружающим. Довольно быстро приходит понимание, что что-то из того, что он делает, он делает не так, и он начинает учится.
Программизм:
история одной болезни
Вероятно, в этой статье нет ни одной новой или свежей мысли, мало того, я уверен, что вы уже не раз читали нечто подобное. Статья не претендует и на то, чтобы быть истиной. Ее содержание – плод собственного опыта, проб, ошибок и одновременно выжимка из тех знаний, которые удалось перенять от коллег, прочитать на Хабре и в других местах. Наверное, для каждого конкретного индивидуума то, что сказано в этом тексте, будет сильно отличатся от действительности, но, я уверен, многие смогут узнать в описании себя. Первая стадия, наверное, не очень характерна для программистов, которые не занимались олимпиадным программированием в бытность студентами или учениками, а вот следующие уже практически никак не зависят от этого фактора.
Стадия первая.
Рождение
«Я программист. Я олимпиадник. Я знаю что такое «о»-маленькое. Я знаю, что такое «О»-большое. Я понимаю, чем отличается «эн-квадрат» от «эн-факториала» и почему они оба стыдливо прячутся при виде «эн-логарифм-эн». Сейчас я приду на проект и перепишу эту тормозную кашу из кода так, что она будет работать в много раз быстрее! Смотрите, я знаю алгоритм Кнута-Морриса-Пратта! А здесь можно сэкономить одно сравнение строчек на равность! А если эту рекурсию развернуть в цикл, то за счет экономии вызовов методов и выделения памяти в стэке… Что, программа тормозит? Сейчас я посмотрю код… Вот! Смотрите, здесь вместо двух вложенных циклов можно написать один и использовать бинарный поиск вместо внутреннего!»
Знакомтесь, это первая стадия. Она, в отличие от следущих, особенно характерна именно для олимпиадников. Пациент думает о том, как написать быстрый код. Он одержим быстрым кодом. К сожалению, наличие быстрого кода не всегда делает быстрым программный продукт в целом.
Пациент переписал оптимальным образом кусок кода, который выполняется один раз при старте веб-сервера и на общей производительности это никак не отразилось. Пациент переписал кусок кода, который потом 10 раз меняли в связи с изменением требований по проекту и его микрооптимизации вызвали при этом тучу трудноуловимых багов. Его алгоритм выполняется за линейное время, тогда как старый выполнялся за квадратическое, но старый при этом делал один запрос к базе данных, а новый делает его в каждой итерации. Пациент не догадывается, что с веб-проектом работает много пользователей одновременно и использование статических данных чревато… Продолжать можно долго.
Основная проблема пациента в том, что он мыслит парой классов или методов и при этом не совсем осознает, что происходит вокруг этой части проекта. Его мышление ограничено кодом и алгоритмом его работы, то есть тем, как работает программа, а не тем, что она должна делать. Впрочем, эта стадия редко продолжается достаточно долго, чтобы больной мог нанести вред себе или окружающим. Довольно быстро приходит понимание, что что-то из того, что он делает, он делает не так, и он начинает учится.
Сообщение отредактировал asr: 22.04.2010, 17:47:59
#104
Отправлено 22.04.2010, 17:05:36
asr
-
- Модератор
- 24 325 сообщений
Стадия вторая.
Идеализм и самоуверенность
«Я разработчик. Да, именно так, я разработчик программного обеспечения, а не программист. Мое задание – разработать продукт, который будет стабильно работать и состоять из правильного кода. Код, который я пишу, должен работать сначала правильно, а потом уже быстро. Код должен быть структурированным и откомментированным – возможно его будут поддерживать другие разработчики. ООП – мой главный инструмент, я умею анализировать предметную область и выделять в ней иерархии классов. Все, что можно описать шаблонами или дженериками описывается шаблонами или дженериками. Я применяю декларативное прораммирование везде, где это возможно, ведь этот инструмент делает код максимально читабельным и понятным. Я использую кодогенерацию ведь это экономит мое время на написание кода. Я использую только новые технологии. Я провожу много времени в спорах с коллегами, какой паттерн или технология лучше подходят для решения поставленной задачи и правильно ли использовать здесь тот или иной подход...»
А это уже вторая. Пациент повзрослел и набил много шишек во время предыдущей стадии. Изречение Кнута о том, что преждевременная оптимизация – корень всех бед, выучено на память и выжжено каленым железом на теле пациента. Больше всего на свете его волнует уже не быстродействие, а красота кода.
Гигантские деревья иерархий классов покрывают проект густым лесом, с их развесистых крон свисают специальные аттрибуты, дженерики, интерфейсы. В гуще этого леса монолитными скалами возвышаются фабрики объектов, бродят функции обратного вызова, наблюдатели, итераторы, посетители, контроллеры и другие представители племени поклонников банды четырех. Где-то в глубине леса генерируется код, который в свою очередь генерирует код, который генерирует код, который генерирует XSLT-шаблон, который генерирует интерфейс пользователя. Весь код обильно покрыт комментариями о том, как его правильно использовать и что он делает. Восторг у пациента вызывают проекты, в которых он не способен разобраться быстрее чем за несколько дней из-за нетривиальной объектно-ориентированной структуры.
Изменения в требованиях часто сопровождаются крупномасштабным рефакторингом, введением еще одного абстрактного уровня, выделением новых сущностей и применением новых технологий и подходов, про которые только что прочитал на Хабре. После прочтения статьи о защитном программировании он начинает пихать ассерты во все методы. После знакомства с кешированием данных в памяти он кеширует все данные в проекте. Познакомившись с TDD он пишет кучу тестов для элементарной логики прежде чем написать саму логику. Плод его трудов монументален и вызывает восторг у коллег находящихся на этой же стадии. Он искренне верит, что язык, на котором он пишет, идеален, а технология самая современная. Часто пациент заводит блог, в котором пишет о том как правильно писать код или использовать определенный фреймворк, описывает найденные в своем коде баги и остроумные, как ему кажется, пути их устранения и предупреждения. Он подписывается на блоги евангелистов его любимых технологий и внемлет их словам как истине последней инстанции.
Когда его ставят перед фактом, что его детище тормозит, он берется за профайлер и пытается разобратся с его помощью в дереве вызовов высотой в тысячу этажей. Иногда это удается и проблема решается… да, введением еще одного абстрактного уровня с дополнительным кешированием. Или наоборот, часть логики переносится на сервер базы данных в виде хранимых процедур.
При приближении сроков сдачи проекта пациент внезапно понимает, что слишком многое еще не готово, а время потрачено на постоянные рефакторинги и споры о том, какой паттерн выбрать. Он ночует на работе чтобы успеть в срок и иногда ему это удается. Впрочем, после сдачи проект надо еще поддерживать, дописывать новую функциональность для следующей версии, удовлетворять требования новых пользователей и тут, опять же, внезапно, оказывается, что новый функционал практически невозможно вписать в монолит проекта, не разрушив его до основания. Так как времени на тотальное разрушение не выделяют, ведь продукт уже работает на продакшене и этот баг надо было пофиксить еще в прошлую пятницу, то код начинает обрастать костылями, подпорками, быстрыми и грязными исправлениями с комментариями «todo: fix this later». А чем монументальнее конструкция, тем монументальнее подпорки и костыли для нее.
Идеализм и самоуверенность
«Я разработчик. Да, именно так, я разработчик программного обеспечения, а не программист. Мое задание – разработать продукт, который будет стабильно работать и состоять из правильного кода. Код, который я пишу, должен работать сначала правильно, а потом уже быстро. Код должен быть структурированным и откомментированным – возможно его будут поддерживать другие разработчики. ООП – мой главный инструмент, я умею анализировать предметную область и выделять в ней иерархии классов. Все, что можно описать шаблонами или дженериками описывается шаблонами или дженериками. Я применяю декларативное прораммирование везде, где это возможно, ведь этот инструмент делает код максимально читабельным и понятным. Я использую кодогенерацию ведь это экономит мое время на написание кода. Я использую только новые технологии. Я провожу много времени в спорах с коллегами, какой паттерн или технология лучше подходят для решения поставленной задачи и правильно ли использовать здесь тот или иной подход...»
А это уже вторая. Пациент повзрослел и набил много шишек во время предыдущей стадии. Изречение Кнута о том, что преждевременная оптимизация – корень всех бед, выучено на память и выжжено каленым железом на теле пациента. Больше всего на свете его волнует уже не быстродействие, а красота кода.
Гигантские деревья иерархий классов покрывают проект густым лесом, с их развесистых крон свисают специальные аттрибуты, дженерики, интерфейсы. В гуще этого леса монолитными скалами возвышаются фабрики объектов, бродят функции обратного вызова, наблюдатели, итераторы, посетители, контроллеры и другие представители племени поклонников банды четырех. Где-то в глубине леса генерируется код, который в свою очередь генерирует код, который генерирует код, который генерирует XSLT-шаблон, который генерирует интерфейс пользователя. Весь код обильно покрыт комментариями о том, как его правильно использовать и что он делает. Восторг у пациента вызывают проекты, в которых он не способен разобраться быстрее чем за несколько дней из-за нетривиальной объектно-ориентированной структуры.
Изменения в требованиях часто сопровождаются крупномасштабным рефакторингом, введением еще одного абстрактного уровня, выделением новых сущностей и применением новых технологий и подходов, про которые только что прочитал на Хабре. После прочтения статьи о защитном программировании он начинает пихать ассерты во все методы. После знакомства с кешированием данных в памяти он кеширует все данные в проекте. Познакомившись с TDD он пишет кучу тестов для элементарной логики прежде чем написать саму логику. Плод его трудов монументален и вызывает восторг у коллег находящихся на этой же стадии. Он искренне верит, что язык, на котором он пишет, идеален, а технология самая современная. Часто пациент заводит блог, в котором пишет о том как правильно писать код или использовать определенный фреймворк, описывает найденные в своем коде баги и остроумные, как ему кажется, пути их устранения и предупреждения. Он подписывается на блоги евангелистов его любимых технологий и внемлет их словам как истине последней инстанции.
Когда его ставят перед фактом, что его детище тормозит, он берется за профайлер и пытается разобратся с его помощью в дереве вызовов высотой в тысячу этажей. Иногда это удается и проблема решается… да, введением еще одного абстрактного уровня с дополнительным кешированием. Или наоборот, часть логики переносится на сервер базы данных в виде хранимых процедур.
При приближении сроков сдачи проекта пациент внезапно понимает, что слишком многое еще не готово, а время потрачено на постоянные рефакторинги и споры о том, какой паттерн выбрать. Он ночует на работе чтобы успеть в срок и иногда ему это удается. Впрочем, после сдачи проект надо еще поддерживать, дописывать новую функциональность для следующей версии, удовлетворять требования новых пользователей и тут, опять же, внезапно, оказывается, что новый функционал практически невозможно вписать в монолит проекта, не разрушив его до основания. Так как времени на тотальное разрушение не выделяют, ведь продукт уже работает на продакшене и этот баг надо было пофиксить еще в прошлую пятницу, то код начинает обрастать костылями, подпорками, быстрыми и грязными исправлениями с комментариями «todo: fix this later». А чем монументальнее конструкция, тем монументальнее подпорки и костыли для нее.
#105
Отправлено 22.04.2010, 17:05:53
asr
-
- Модератор
- 24 325 сообщений
Проблема пациента в том, что он потерял содержание за формой. Он пишет код так, как художник рисует картину: с восторгом, с восхищением, он влюблен в этот код и часто забывает о том, что основная цель его работы написать не красивый код, а продукт, который будет работать, будет работать быстро и будет легко поддерживаемым. Он часто забывает и о том, что программный продукт – это товар, который должен найти своего покупателя, которому (нет, вы только подумайте!) совершенно плевать, какова концентрация паттернов на строку в коде программы. Зато этот пользователь готов заплатить деньги за то, что в продукт добавят новую фичу, о которой никто не догадывался при написании первой версии, при чем добавление этой фичи не должно отвалить ни единой существующей функции проекта и времени этот процесс должен занять минимум. И да, пользователю правда важно, что бы у этих кнопочек были кругленькие уголки.
Стадия третья.
Просветление
«Кажется я ошибаюсь. Нет, определенно, я ошибаюсь.»
Да, третья стадия – это осознание пациентом того, что он находится на второй стадии болезни и понимание собственных недостатков и ошибок. Осознание болезни ведет к исцелению.
Иерархии классов в проекте редко превышают два-три уровня наследования, методы содержат не более пары десятков строк, а чаще всего меньше десяти. Код практически не содержит комментариев, за исключением внешних интерфейсов, с которыми могут работать сторонние разработчики, не имеющие доступа к коду. На удивление, остутствие комментариев не делает код нечитабельным – правильные имена переменных и методов, четкий code-convention и небольшой объем кода творят чудеса. Если действие можно описать просто и без применения сложных паттернов проектирования – то оно будет описано именно таким образом. Если существует вероятность того, что более сложное решение упростит жизнь в будущем, то оно будет реализовано ровно настолько, чтобы обеспечить это упрощение.
Декларативное программирование используется в тех местах, где это не вредит производительности. Код генерируется, но только там, где это экономит время разработчиков, при чем в результат генерации максимально простой и отлаживаемый, даже если для этого приходится генерировать в десять раз больше кода. Юнит-тесты покрывают лишь часть кода, но это именно та часть, которая может пострадать в случае ошибки при внесении новой функциональности или исправлении бага. Прежде чем добавить кеширование данных из базы, пациент обязательно задумается о том, насколько это необходимо, и не повредит ли масштабируемости решения, точно так же, как и в случае переноса логики в код хранимой процедуры на сервере базы данных. Он понимает, что покупка еще одного сервера может в итоге обойтись намного дешевле, чем переписывание и тестирование части проекта. Впрочем, в тех местах, где оптимизация может дать серьезный прирост производительности она… не делается до поры до времени, но код пишется таким образом, чтобы в случае необходимости можно было легко ускорить его выполнение. Если это, конечно, будет нужно.
Щенячий восторг от технологий и языков сменяется более спокойным отношением – всему свое время и место. Пациент понимает, что каждый инструмент хорош для определенного круга задач, поэтому не принимает участия в холиворах на тему «динамические языки vs. статические», «Java vs. .Net vs. C++» и т.п. Он с удовольствием пробует новые языки и технологии для своих собственных проектов, но решается на их использование в рабочем коде только после внимательного взвешивания всех «за» и «против» и опробирования новшевств на прототипе или отдельной ветке проекта.
Он критически относится ко всему новому, пытаясь выделить в нем как плюсы так и минусы и внимательно выслушать все стороны спора, если таковой имеет место быть. Он хорошо знает несколько языков и технологий, достаточно много, чтобы решить любую поставленную перед ним задачу, но достаточно мало, чтобы овладеть ими в нужном ему объеме. Изречения евангелистов и гуру не воспринимаются им как истина последней инстанции – он пытается понять не столько что они сказали, а почему и почему это имеет смысл. Если пациент понимает, что в определенном случае собственный велосипед может быть эффективнее существующих технологий – он пишет собственный велосипед, но только тогда, когда докажет сам себе его необходимость. Если велосипед доставляет ему удовольствие своей эстетикой и остроумными решениями и это не противоречит соглашению с работодателем – он не гнушается опубликовать код под оупен-сорсной лицензией или хотя бы в общих чертах описать решение в своем блоге. И да, если эти идиоты и правда хотят видеть закругленные уголки в кнопках, то пациент обязательно их сделает. Впрочем, пациент ли?
Вместо послесловия
Я сам никогда не встречался с пациентом – это скорее сборный сферический образ, живущий глубоко в космическом вакууме, списанный с моих друзей, коллег, собственного опыта и просто историй без авторства и происхождения, которые время от времени всплывают на различных ресурсах в Сети.
Стадия третья.
Просветление
«Кажется я ошибаюсь. Нет, определенно, я ошибаюсь.»
Да, третья стадия – это осознание пациентом того, что он находится на второй стадии болезни и понимание собственных недостатков и ошибок. Осознание болезни ведет к исцелению.
Иерархии классов в проекте редко превышают два-три уровня наследования, методы содержат не более пары десятков строк, а чаще всего меньше десяти. Код практически не содержит комментариев, за исключением внешних интерфейсов, с которыми могут работать сторонние разработчики, не имеющие доступа к коду. На удивление, остутствие комментариев не делает код нечитабельным – правильные имена переменных и методов, четкий code-convention и небольшой объем кода творят чудеса. Если действие можно описать просто и без применения сложных паттернов проектирования – то оно будет описано именно таким образом. Если существует вероятность того, что более сложное решение упростит жизнь в будущем, то оно будет реализовано ровно настолько, чтобы обеспечить это упрощение.
Декларативное программирование используется в тех местах, где это не вредит производительности. Код генерируется, но только там, где это экономит время разработчиков, при чем в результат генерации максимально простой и отлаживаемый, даже если для этого приходится генерировать в десять раз больше кода. Юнит-тесты покрывают лишь часть кода, но это именно та часть, которая может пострадать в случае ошибки при внесении новой функциональности или исправлении бага. Прежде чем добавить кеширование данных из базы, пациент обязательно задумается о том, насколько это необходимо, и не повредит ли масштабируемости решения, точно так же, как и в случае переноса логики в код хранимой процедуры на сервере базы данных. Он понимает, что покупка еще одного сервера может в итоге обойтись намного дешевле, чем переписывание и тестирование части проекта. Впрочем, в тех местах, где оптимизация может дать серьезный прирост производительности она… не делается до поры до времени, но код пишется таким образом, чтобы в случае необходимости можно было легко ускорить его выполнение. Если это, конечно, будет нужно.
Щенячий восторг от технологий и языков сменяется более спокойным отношением – всему свое время и место. Пациент понимает, что каждый инструмент хорош для определенного круга задач, поэтому не принимает участия в холиворах на тему «динамические языки vs. статические», «Java vs. .Net vs. C++» и т.п. Он с удовольствием пробует новые языки и технологии для своих собственных проектов, но решается на их использование в рабочем коде только после внимательного взвешивания всех «за» и «против» и опробирования новшевств на прототипе или отдельной ветке проекта.
Он критически относится ко всему новому, пытаясь выделить в нем как плюсы так и минусы и внимательно выслушать все стороны спора, если таковой имеет место быть. Он хорошо знает несколько языков и технологий, достаточно много, чтобы решить любую поставленную перед ним задачу, но достаточно мало, чтобы овладеть ими в нужном ему объеме. Изречения евангелистов и гуру не воспринимаются им как истина последней инстанции – он пытается понять не столько что они сказали, а почему и почему это имеет смысл. Если пациент понимает, что в определенном случае собственный велосипед может быть эффективнее существующих технологий – он пишет собственный велосипед, но только тогда, когда докажет сам себе его необходимость. Если велосипед доставляет ему удовольствие своей эстетикой и остроумными решениями и это не противоречит соглашению с работодателем – он не гнушается опубликовать код под оупен-сорсной лицензией или хотя бы в общих чертах описать решение в своем блоге. И да, если эти идиоты и правда хотят видеть закругленные уголки в кнопках, то пациент обязательно их сделает. Впрочем, пациент ли?
Вместо послесловия
Я сам никогда не встречался с пациентом – это скорее сборный сферический образ, живущий глубоко в космическом вакууме, списанный с моих друзей, коллег, собственного опыта и просто историй без авторства и происхождения, которые время от времени всплывают на различных ресурсах в Сети.
#110
Отправлено 17.05.2010, 14:16:33
yedyge
-
- Свой человек
- 879 сообщений
Настоящие программисты не пишут спецификаций — пользователи должны считать себя счастливыми, получая любую программу и принимать ее такой, какая она есть.
Настоящие программисты не комментируют свои программы. Это затрудняет написание, и это затруднит чтение.
Настоящие программисты не пишут прикладные программы, они программируют не ради презренного металла. Прикладное программирование есть кусок хлеба для тех, кто не может заниматься системным программированием.
Настоящие программисты не готовят сами. Они питаются в закусочных и забегаловках.
Настоящие программисты не пишут на КОБОЛЕ. КОБОЛ — это для простоватых прикладных программистов.
Настоящие программисты никогда не сдают свою работу с первого раза. Но если отдать им машину, они могут залатать все прорехи в своей программе за один или несколько 30–часовых отладочных сеанса.
Настоящие программисты не пишут на ФОРТРАНЕ. ФОРТРАН — это для расчетов труб под давлением и кристаллографических игрушек.
Настоящие программисты никогда не работают с 9 до 5. Если какой–нибудь настоящий программист в девять часов утра на работе, это значит, что он провел на работе всю ночь.
Настоящие программисты не пишут на Бэйсике. Обычно программист не пишет на Бэйсике, если он старше 12 лет.
Настоящие программисты не пишут на pl/i. pl/i — это для программистов, которые не могут решится писать на КОБОЛЕ или ФОРТРАНЕ.
Настоящие программисты не пишут на АПЛ. Любой дурак может быть непонятным, если пишет на АПЛ.
Настоящие программисты не играют в теннис или любую другую спортивную игру, поскольку для этого надо сменить одежду. Однако альпинизм вполне подходит, и настоящие программисты могут надеть свои бахилы в случае, если в результате подьема они вдруг окажутся посередине машинного зала.
Настоящие программисты не готовят документацию. Документация — это для тех простаков, кто не может читать листинги или объектный код.
Настоящие программисты не пишут на Паскале или на АДЕ, или на любом другом изобретенном учеными языке. Строгие правила написания программ — это для людей со слабой памятью.
Настоящие программисты знают лучше пользователя, что ему нужно.
Настоящие программисты считают структурное программирование частью коммунистического заговора.
Настоящие программисты не работают по расписанию. Расписание — это для лизоблюдов. Настоящим программистам нравится держать своих начальников в полной неизвестности.
Настоящие программисты думают лучше, когда играют в "Приключения".
Настоящие программисты наслаждаются, установив cp/m для работы на машинaх ibm/370 и mvs на Спектруме.
Настоящим программистам никогда не досаждают системы безопасности, они сбрасывают биты где нужно и вставляют непонятные сообщения в данные системы безопасности.
Настоящие программисты никогда на исправляют исходный код после работы с программой zap, кроме всего прочего, завтра может потребоваться исправ ления вносить снова.
Настоящие программисты не тестируют программы. Тестирование для людей со слабыми нервами и к тому же не уверенных в себе.
Настоящие программисты всегда программируют рекурсивно и запускают программы только в режиме супервизора, иначе программирование нельзя считать настоящим развлечением.
Настоящие программисты никогда не занимаются архивированием.
Настоящие программисты не комментируют свои программы. Это затрудняет написание, и это затруднит чтение.
Настоящие программисты не пишут прикладные программы, они программируют не ради презренного металла. Прикладное программирование есть кусок хлеба для тех, кто не может заниматься системным программированием.
Настоящие программисты не готовят сами. Они питаются в закусочных и забегаловках.
Настоящие программисты не пишут на КОБОЛЕ. КОБОЛ — это для простоватых прикладных программистов.
Настоящие программисты никогда не сдают свою работу с первого раза. Но если отдать им машину, они могут залатать все прорехи в своей программе за один или несколько 30–часовых отладочных сеанса.
Настоящие программисты не пишут на ФОРТРАНЕ. ФОРТРАН — это для расчетов труб под давлением и кристаллографических игрушек.
Настоящие программисты никогда не работают с 9 до 5. Если какой–нибудь настоящий программист в девять часов утра на работе, это значит, что он провел на работе всю ночь.
Настоящие программисты не пишут на Бэйсике. Обычно программист не пишет на Бэйсике, если он старше 12 лет.
Настоящие программисты не пишут на pl/i. pl/i — это для программистов, которые не могут решится писать на КОБОЛЕ или ФОРТРАНЕ.
Настоящие программисты не пишут на АПЛ. Любой дурак может быть непонятным, если пишет на АПЛ.
Настоящие программисты не играют в теннис или любую другую спортивную игру, поскольку для этого надо сменить одежду. Однако альпинизм вполне подходит, и настоящие программисты могут надеть свои бахилы в случае, если в результате подьема они вдруг окажутся посередине машинного зала.
Настоящие программисты не готовят документацию. Документация — это для тех простаков, кто не может читать листинги или объектный код.
Настоящие программисты не пишут на Паскале или на АДЕ, или на любом другом изобретенном учеными языке. Строгие правила написания программ — это для людей со слабой памятью.
Настоящие программисты знают лучше пользователя, что ему нужно.
Настоящие программисты считают структурное программирование частью коммунистического заговора.
Настоящие программисты не работают по расписанию. Расписание — это для лизоблюдов. Настоящим программистам нравится держать своих начальников в полной неизвестности.
Настоящие программисты думают лучше, когда играют в "Приключения".
Настоящие программисты наслаждаются, установив cp/m для работы на машинaх ibm/370 и mvs на Спектруме.
Настоящим программистам никогда не досаждают системы безопасности, они сбрасывают биты где нужно и вставляют непонятные сообщения в данные системы безопасности.
Настоящие программисты никогда на исправляют исходный код после работы с программой zap, кроме всего прочего, завтра может потребоваться исправ ления вносить снова.
Настоящие программисты не тестируют программы. Тестирование для людей со слабыми нервами и к тому же не уверенных в себе.
Настоящие программисты всегда программируют рекурсивно и запускают программы только в режиме супервизора, иначе программирование нельзя считать настоящим развлечением.
Настоящие программисты никогда не занимаются архивированием.
#111
Отправлено 17.05.2010, 14:17:15
yedyge
-
- Свой человек
- 879 сообщений
#112
Отправлено 17.05.2010, 14:46:51
yedyge
-
- Свой человек
- 879 сообщений
Что такое программирование
Как объяснить непосвященному что такое программирование?
Если вы когда-нибудь задавались этим вопросом, то знаете, насколько непросто на него ответить. hу, например, что такое "эффективный алгоритм"? Прочитав эту статью, вы уже не будете отделываться замечаниями вроде "это все слишком сложно", а сможете объяснить основные понятия даже ребенку. Итак.
Что такое программирование?
Представьте, что вы подробно описываете надевание штанов: "взять штаны так, чтобы ширинка была спереди, а задний карман - сзади; нагнуться, опустить руки до уровня коленок..." и т. д. Это и есть программирование.
Что такое программирование на языке ассемблера?
Представьте, что вы описываете надевание штанов очень подробно, в виде: "сократить такую-то мышцу, растянуть такую-то..."
Что такое тестирование программы?
Протестировать программу - значит попробовать надеть штаны. Могу гарантировать, что с первого раза у вас ничего не получится: штаны вы наденете задом наперед или на голову.
Чем отличаются эффективный и неэффективный алгоритмы?
Если вы действуете по эффективному алгоритму надевания штанов, то надеваете их секунд за 20, в ином случае - будете надевать до вечера.
Что такое ошибка в программе?
Если, надев штаны по своему описанию, вы обнаружили, что ширинка застегнута у вас на затылке или что вы не можете ее застегнуть совсем (из-за стянутых штанами рук), значит, вами была допущена ошибка в программе.
Что такое ошибка, приводящая к зависанию компьютера?
Если, надев штаны, вы обнаружили, что задохнулись.
Что такое оптимизация программы?
Сначала вы читаете один из вариантов надевания штанов, а потом пытаетесь сделать его более эффективным. hапример, меняете последовательность: "распороть штаны, приложить все куски куда нужно и затем сшить по старым швам" на любую другую, менее трудоемкую.
Что такое переносимость?
Это когда по вашему алгоритму можно надеть любые штаны на любого человека.
Что такое крах системы?
Исчезновение ваших штанов - как результат вашей деятельности.
Источник: http://korova.ru/
Как объяснить непосвященному что такое программирование?
Если вы когда-нибудь задавались этим вопросом, то знаете, насколько непросто на него ответить. hу, например, что такое "эффективный алгоритм"? Прочитав эту статью, вы уже не будете отделываться замечаниями вроде "это все слишком сложно", а сможете объяснить основные понятия даже ребенку. Итак.
Что такое программирование?
Представьте, что вы подробно описываете надевание штанов: "взять штаны так, чтобы ширинка была спереди, а задний карман - сзади; нагнуться, опустить руки до уровня коленок..." и т. д. Это и есть программирование.
Что такое программирование на языке ассемблера?
Представьте, что вы описываете надевание штанов очень подробно, в виде: "сократить такую-то мышцу, растянуть такую-то..."
Что такое тестирование программы?
Протестировать программу - значит попробовать надеть штаны. Могу гарантировать, что с первого раза у вас ничего не получится: штаны вы наденете задом наперед или на голову.
Чем отличаются эффективный и неэффективный алгоритмы?
Если вы действуете по эффективному алгоритму надевания штанов, то надеваете их секунд за 20, в ином случае - будете надевать до вечера.
Что такое ошибка в программе?
Если, надев штаны по своему описанию, вы обнаружили, что ширинка застегнута у вас на затылке или что вы не можете ее застегнуть совсем (из-за стянутых штанами рук), значит, вами была допущена ошибка в программе.
Что такое ошибка, приводящая к зависанию компьютера?
Если, надев штаны, вы обнаружили, что задохнулись.
Что такое оптимизация программы?
Сначала вы читаете один из вариантов надевания штанов, а потом пытаетесь сделать его более эффективным. hапример, меняете последовательность: "распороть штаны, приложить все куски куда нужно и затем сшить по старым швам" на любую другую, менее трудоемкую.
Что такое переносимость?
Это когда по вашему алгоритму можно надеть любые штаны на любого человека.
Что такое крах системы?
Исчезновение ваших штанов - как результат вашей деятельности.
Источник: http://korova.ru/
#113
Отправлено 17.05.2010, 15:16:52
yedyge
-
- Свой человек
- 879 сообщений
Глюки и религия
Иудаизм.
К чему спрашивать, почему глючат программы? Надо ждать патча!
Католицизм.
Первая программа была безглючной. Но захотела идти на компьютере apple и заглючила. Все программы являются версиями первой и сохраняют глюки в целях совместимости.
Православие.
Нельзя спрашивать, почему глючат программы. И пользоваться патчами тоже нельзя, Особенно западными. Надо заботиться не о том, чтобы программа работала, а о том, что с ней будет после деинсталляции.
Протестантизм.
Программист так любит программы, что позволяет им глючить, падать и вешаться. И вообще, надо больше работать с глючными программами. Глюков это не исправит, зато заработаете больше денег.
Свидетели Иеговы.
Только у нас есть настоящий патч, исправляющий любые глюки! И мы готовы предложить его всем практически бесплатно. Но он не будет работать, если вы не уверуете, что он действительно исправляет глюки. Если вы поставили патч, а глюки не исчезли, значит вы не уверовали.
Мормоны.
Программы глючат потому, что их запускают на неправильных компьютерах. Правильные компьютеры есть только у нас. Еще немного, и мы узнаем, как их включить.
Ислам (сунниты).
Если программа глючит, значит, она неверная. Неверные программы надо стереть. Безглючны только верные программы. Если верная программа выдает, что 2х2=5, значит, глючат все программы, дающие другие результаты.
Ислам (шииты).
Только один программист писал верные программы. Верными являются также последующие версии этих программ. Все остальные программы глючат по определению.
Индуизм.
Программы глючат потому, что в них были глюки до инсталляции, когда они были другими программами и на других компьютерах. После деинсталляции они снова станут другими программами и будут глючить из-за глюков, которые в них есть сейчас. Патчи тут не помогут, потому что все предопределено.
Буддизм.
Программы глючат потому, что вы задаетесь этим вопросом. Не следует стремиться избавляться от них. Патчи лишь умножают глюки. Нет никакой разницы между хардом и софтом, программой и программистом. Программа, избавленная от глюков, впадает в нирвану. Программы в нирване не глючат, но и не работают.
Дзен-буддизм.
Глючит ли программа, распечатывающая сама себя? Как выглядит программа, не записанная ни на одном носителе? Однажды ученик спросил учителя, как избавиться от глюков в программах, и учитель дал ему вирус ciН. Однажды другой ученик сказал учителю, что хочет программу без глюков. "Дурак! - крикнул учитель, - почему ты не просишь глюк без программы?", - и ударил его винчестером по голове. Если вы еще не обрели просветление, с вами не о чем говорить.
Даосизм.
Глюк, который можно отловить, не есть истинный глюк. Патч, который можно написать, не есть истинный патч.
Конфуцианство.
Программы глючат из-за неверного понимания порядка вещей. Попытки исправить их с помощью патчей, как делают западные варвары, противны этикету и должны быть упразднены. Совершенно мудрый постигнет истинный смысл и необходимость глюков.
Иудаизм.
К чему спрашивать, почему глючат программы? Надо ждать патча!
Католицизм.
Первая программа была безглючной. Но захотела идти на компьютере apple и заглючила. Все программы являются версиями первой и сохраняют глюки в целях совместимости.
Православие.
Нельзя спрашивать, почему глючат программы. И пользоваться патчами тоже нельзя, Особенно западными. Надо заботиться не о том, чтобы программа работала, а о том, что с ней будет после деинсталляции.
Протестантизм.
Программист так любит программы, что позволяет им глючить, падать и вешаться. И вообще, надо больше работать с глючными программами. Глюков это не исправит, зато заработаете больше денег.
Свидетели Иеговы.
Только у нас есть настоящий патч, исправляющий любые глюки! И мы готовы предложить его всем практически бесплатно. Но он не будет работать, если вы не уверуете, что он действительно исправляет глюки. Если вы поставили патч, а глюки не исчезли, значит вы не уверовали.
Мормоны.
Программы глючат потому, что их запускают на неправильных компьютерах. Правильные компьютеры есть только у нас. Еще немного, и мы узнаем, как их включить.
Ислам (сунниты).
Если программа глючит, значит, она неверная. Неверные программы надо стереть. Безглючны только верные программы. Если верная программа выдает, что 2х2=5, значит, глючат все программы, дающие другие результаты.
Ислам (шииты).
Только один программист писал верные программы. Верными являются также последующие версии этих программ. Все остальные программы глючат по определению.
Индуизм.
Программы глючат потому, что в них были глюки до инсталляции, когда они были другими программами и на других компьютерах. После деинсталляции они снова станут другими программами и будут глючить из-за глюков, которые в них есть сейчас. Патчи тут не помогут, потому что все предопределено.
Буддизм.
Программы глючат потому, что вы задаетесь этим вопросом. Не следует стремиться избавляться от них. Патчи лишь умножают глюки. Нет никакой разницы между хардом и софтом, программой и программистом. Программа, избавленная от глюков, впадает в нирвану. Программы в нирване не глючат, но и не работают.
Дзен-буддизм.
Глючит ли программа, распечатывающая сама себя? Как выглядит программа, не записанная ни на одном носителе? Однажды ученик спросил учителя, как избавиться от глюков в программах, и учитель дал ему вирус ciН. Однажды другой ученик сказал учителю, что хочет программу без глюков. "Дурак! - крикнул учитель, - почему ты не просишь глюк без программы?", - и ударил его винчестером по голове. Если вы еще не обрели просветление, с вами не о чем говорить.
Даосизм.
Глюк, который можно отловить, не есть истинный глюк. Патч, который можно написать, не есть истинный патч.
Конфуцианство.
Программы глючат из-за неверного понимания порядка вещей. Попытки исправить их с помощью патчей, как делают западные варвары, противны этикету и должны быть упразднены. Совершенно мудрый постигнет истинный смысл и необходимость глюков.
#114
Отправлено 17.05.2010, 15:17:56
yedyge
-
- Свой человек
- 879 сообщений
Сатанизм.
Каждая программа имеет право глючить! Постыдность глюков - христианская пропаганда!
Растафарианство.
О, и программы тоже? А где они траву берут?
Экуменизм.
А давайте глюки всех программ объединим в одну!
Атеизм.
Вера в так называемый патч - средство оболванивания пользователей. Глючность программ - объективный закон природы, и с этим ничего не поделаешь.
Социализм.
Программы глючат из-за неравенства. У них разная длина, разное расширение и разные запросы к памяти. Патчи не помогут бороться с глюками, ибо не устраняют причину. Следует сделать все программы одинаковыми, уничтожить все операционные системы, кроме одной, отобрать у всех пользователей персоналки и сделать вместо них один большой компьютер.
Коммунизм.
Программы глючат из-за вредительства! Надо расстрелять программистов. А заодно, на всякий случай, производителей компьютеров. Да и вообще, зачем нам какие-то программы? У нас уже есть Программа партии!
Нацизм.
Кстати, и воды в кране нет по той же причине.
Ницшеанство.
Программы глючат потому, что они - всего лишь программы и достойны презрения. Только сверхпрограмма будет безглючной.
Критики ницшеанства.
У сверхпрограммы будут сверхглюки, ха-ха!
Фрейдизм.
На самом деле все графические оболочки предназначены для просмотра порнокартинок. А все текстовые редакторы для печатанья порнотекстов. А все языки программирования - для написания оболочек и редакторов, используемых для просмотра порнокартинок и порнотекстов. Если их использовать для других целей, глюки неизбежны.
Юнгианство.
Программы глючат потому, что в коллективном бессознательном существует архетип глюка, которому противостоит архетип патча. Таким образом, ошибаются те, кто думает, будто патчами они смогут победить глюки; на самом деле, работая на архетип патча, они тем самым укрепляют и архетип глюка.
Экзистенционализм.
На самом деле вас не интересует, почему глючат программы. Если вы спрашиваете об этом, значит, у вас уже есть патч.
Феминизм.
Программы глючат из-за дискриминации по расширению! И вообще, миф о глючности программ придумали шовинистические свиньи из служб техподдержки, которые боятся потерять работу!
Сексуальные меньшинства.
Называть это глюками - оскорбительный предрассудок! Это не глюки, а особенности! Которыми можно гордиться! Они, между прочим, есть даже у таких знаменитых программ, как microsoft windows, netscape navigator и borland delphi!
Пролайферы (движение противников абортов).
Глючные программы тоже имеют право на инсталляцию!
greenpeace.
Программы глючат из-за загрязнения окружающей среды! 500 лет назад, когда промышленность не отравляла Землю, о глюках программ никто и не слышал! Что, скажете не так?
Каждая программа имеет право глючить! Постыдность глюков - христианская пропаганда!
Растафарианство.
О, и программы тоже? А где они траву берут?
Экуменизм.
А давайте глюки всех программ объединим в одну!
Атеизм.
Вера в так называемый патч - средство оболванивания пользователей. Глючность программ - объективный закон природы, и с этим ничего не поделаешь.
Социализм.
Программы глючат из-за неравенства. У них разная длина, разное расширение и разные запросы к памяти. Патчи не помогут бороться с глюками, ибо не устраняют причину. Следует сделать все программы одинаковыми, уничтожить все операционные системы, кроме одной, отобрать у всех пользователей персоналки и сделать вместо них один большой компьютер.
Коммунизм.
Программы глючат из-за вредительства! Надо расстрелять программистов. А заодно, на всякий случай, производителей компьютеров. Да и вообще, зачем нам какие-то программы? У нас уже есть Программа партии!
Нацизм.
Кстати, и воды в кране нет по той же причине.
Ницшеанство.
Программы глючат потому, что они - всего лишь программы и достойны презрения. Только сверхпрограмма будет безглючной.
Критики ницшеанства.
У сверхпрограммы будут сверхглюки, ха-ха!
Фрейдизм.
На самом деле все графические оболочки предназначены для просмотра порнокартинок. А все текстовые редакторы для печатанья порнотекстов. А все языки программирования - для написания оболочек и редакторов, используемых для просмотра порнокартинок и порнотекстов. Если их использовать для других целей, глюки неизбежны.
Юнгианство.
Программы глючат потому, что в коллективном бессознательном существует архетип глюка, которому противостоит архетип патча. Таким образом, ошибаются те, кто думает, будто патчами они смогут победить глюки; на самом деле, работая на архетип патча, они тем самым укрепляют и архетип глюка.
Экзистенционализм.
На самом деле вас не интересует, почему глючат программы. Если вы спрашиваете об этом, значит, у вас уже есть патч.
Феминизм.
Программы глючат из-за дискриминации по расширению! И вообще, миф о глючности программ придумали шовинистические свиньи из служб техподдержки, которые боятся потерять работу!
Сексуальные меньшинства.
Называть это глюками - оскорбительный предрассудок! Это не глюки, а особенности! Которыми можно гордиться! Они, между прочим, есть даже у таких знаменитых программ, как microsoft windows, netscape navigator и borland delphi!
Пролайферы (движение противников абортов).
Глючные программы тоже имеют право на инсталляцию!
greenpeace.
Программы глючат из-за загрязнения окружающей среды! 500 лет назад, когда промышленность не отравляла Землю, о глюках программ никто и не слышал! Что, скажете не так?
#117
Отправлено 29.05.2010, 13:07:23
Oris
-
- Гость
- 8 сообщений
Туда же, но ссылка работает всегда:краткая, неполная и ошибочкая история языков программирования
http://james-iry.blo...stly-wrong.html
http://james-iry.blo...stly-wrong.html
#118
Отправлено 23.06.2010, 00:45:15
Gonzo
-
- Свой человек
- 565 сообщений
Объявление: "Для ухода за пожилым программистом требуется приятная женщина, свободно разговаривающая на C++, Fortran, Prolog, Lisp."
Объявление: "Потомственный программист в седьмом байте избавит от System Policy и Access Denied. Снимет пароль. Наворожит номера кредиток. Быстро, анонимно, с гарантией."
Объявление: "Потомственный программист в седьмом байте избавит от System Policy и Access Denied. Снимет пароль. Наворожит номера кредиток. Быстро, анонимно, с гарантией."
#120
Отправлено 14.03.2011, 12:07:12
yedyge
-
- Свой человек
- 879 сообщений
Количество пользователей, читающих эту тему: 1
пользователей: 0, неизвестных прохожих: 1, скрытых пользователей: 0
