Рубрика «философия программирования»

Я работаю программистом 12 лет. Последние 2 года в мобильной разработке, а до этого php со всей своей экосистемой, фронт-энд - по мере необходимости.

И проблема конфликта между красотой кода и быстротой реализации новых фич давно меня занимала. Раньше были разговоры и даже холивары на эту тему. Однако сегодня поднимать этот вопрос уже моветон.

И вот конкретный пример.

Для мобильной разработки пользуюсь таким замечательным продуктом как Android Studio. И решил давеча отключить ненужные плагины в настройках. Снял галочки напротив плагинов которые для меня не нужны, IDE не предупредила ни о каких возможных проблемах.

Читать полностью »

Дао программирования - 1

Книга 1: Безмолвная пустота

Сказано мастером-программистом: "Уходи, когда поймёшь как найти код ошибки в трап фрейме"

1.1

Нечто загадочное сформировалось, зародилось в безмолвной пустоте. Оно одиноко ждёт без движения. Оно замерло, но постоянно двигается. Оно — источник всех программ. Я не знаю его имени и назову его Дао программирования.

 Если Дао прекрасно — операционная система прекрасна.
 Если операционная система прекрасна — компилятор прекрасен.
 Если компилятор прекрасен — приложение прекрасно.
 Пользователь доволен и в мире царит гармония.

Дао программирования уносится вдаль и возвращается с утренним ветром

Читать полностью »

Программисты много говорят про сложность решений. Мы можем часами размышлять о правильных шаблонах, красивых абстракциях и цепочках зависимостей. Однако, давайте поговорим открыто, всегда ли сложность обусловлена решаемой проблемой? Не оказываемся ли мы в плену наших стереотипов и убеждений?

Имитация Сложности — Антиномия Простого и Сложного - 1

Читать полностью »

Привет!

Предлагаю вашему вниманию перевод статьи «Language Layers» автора Robert C. Martin (Uncle Bob).

image

Читать полностью »

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

Здесь и далее я буду рассматривать общекнижный пример с сотрудниками предприятия, писать будем на чем-то СИ-подобном. Наследовать класс Сотрудник (Employee) от класса Человек (Person) – прекрасная идея, особенно если хранить данные исключительно в памяти: SQL имеет некоторые проблемы с наследованием таблиц, но речь не об этом — ООП со своим иерархизмом, агрегациями, композициями и наследованиями предлагает идеальный способ организации данных. Проблемы с методами.

За каждым методом бизнес-логики стоит факт мира, который этот метод (чаще не в одиночку) моделирует. Факты программирования – это операции: дальше будем называть их так. Делая метод членом класса, ООП требует от нас привязать операцию к объекту, что невозможно, потому что операция – это взаимодействие объектов (двух и более), кроме случая унарной операции, чистой рефлексии. Метод ВыдатьЗарплату (PaySalary) может быть отнесен к классам Сотрудник (Employee), Касса (Cash), БанковскийСчет (Account) – все они равнозначны в праве владения им. Дилемма о расположении методов сопутствует всему процессу разработки: неловкое ее разрешение может оказаться критичным и даже фатальным.

В книгах по программированию честные авторы стыдливо признают, что «объекты – это как бы не совсем объекты», а ООП – всего лишь способ организации кода, а не механизм моделирования. Но все дело том, что «мир есть совокупность фактов, а не вещей» – отсюда принципиальная неспособность построить адекватную модель, применяя ООП в том виде, как этого требуют писатели учебников. Важно понять: в коде возможно моделировать мир, но атомами модели должны стать факты, а не объекты.
Читать полностью »

Американцы вполне себе вложились в мировую и тем-более англоязычную литературу. Лучше сказать, что так называемый золотой век американской фантастики это один из последних витков развития мировой литературы, если не последний.

Философия программирования 11 — фантастика сегодня - 1

Читать полностью »

JavaScript в 2016 году: функциональное программирование пришло всерьез и надолго - 1В 2015 году вы могли заметить перемены в способе разработки приложений на JavaScript. Разработчики уходят от непредсказуемой архитектуры с мутабельным состоянием в сторону более предсказуемой иммутабельной архитектуры приложений.

С такими фреймворками как Backbone, было принято синхронизировать сами данные и представление данных – для этого приходилось вручную подписываться на нужные события dom. Такой способ был подвержен ошибкам и вынуждал использовать слишком много типового кода. Пришел Angular и исправил это с помощью автоматизированного двустороннего биндинга.

Но сейчас все движется в другом направлении.
Читать полностью »

Термин «О-большое», знакомый нам из курса матанализа, был введён Паулем Бахманом в конце XIX века для описания асимптотического поведения функций. В конце 1970-х Дональд Кнут придумал применять этот термин для оценки эффективности и ресурсоёмкости алгоритмов, благодаря чему с «О-большим» знакомо большинство программистов. Понимание асимптотики быстродействия и ресурсоёмкости даёт возможность выбрать наиболее подходящий метод решения задачи в зависимости от текущих потребностей. «Плохая» асимптотика позволяет сразу же отбросить неподходящий метод.

«А как всё хорошо начиналось...», или О пользе O-нотации не только для анализа алгоритмов - 1

Идею, которой я хочу поделиться, глубокой не назовёшь: скорее, она лежит на поверхности, но далеко не все её замечают.
Методами, похожими на анализ алгоритмов, можно пользоваться для того, чтобы оценить асимптотику характеристик системы управления проектом разработки программного продукта, таких как общее время и стоимость разработки дополнительной функциональности.

Читать полностью »

… но это нормально. Любое проектирование отстой. И всегда будет отстоем.

Если вы мне не верите, давайте объясню…

Ни один проект не переживает встречи с реализацией

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

Данные, которые вы ожидали как обязательные в ответе внешнего сервиса, могут отсутствовать (или быть невалидными). Ожидаемая уникальность может оказаться совсем не уникальной на практике (даже в sha1 когда-нибудь случаются коллизии). Процессы, которые предполагались надежными, будут падать гораздо чаще, чем вы ожидали.

Это нормально.

В некоторых случаях вы можете просто затаймаутиться, выкинуть исключение или еще как-нибудь громко упасть. В других случаях приходится ослабить требования системы. Или добавлять дополнительный фильтрующий слой, который займется «очисткой» и передаст в систему уже правильный вариант входных данных.

Недостающие данные могут быть сделаны опциональными или заменены умолчальными.

Некорректные данные можно рассматривать как отсутствующие, либо записывать их «как есть» и добавить дополнительную провалидированную версию, которая присутствует только если оригинал валидный.

Ограничение уникальности можно Читать полностью »

Я наткнулся на этот прекрасный текст (под катом) в книге Вернора Винджа "Глубина в небе". Фрагмент меня впечатлил на столько, что я решил поделиться своими мыслями с общественностью. Не часто встретишь подобную проработку вопроса в художественной литературе. Местами, текст кажется слегка… простетским, но возможно это результат не самого хорошего перевода. На самом деле, текст достаточно глубокомысленный.

Еще по ходу чтения мне вспомнился Эдсгер Дейкстра с его знаменитой фразой: «Я денно и нощно молю, чтобы как можно больше моих собратьев-программистов нашли способ освободиться от проклятья совместимости» («I pray daily that more of my fellow-programmers may find the means of freeing themselves from the curse of compatibility») из книги Смиренный программист (1972 sic!!!). А позже и Эрик Реймонд с своим Собором и Базаром (1997 год). Но текст Винджа не только о проклятье совместимости, на трех страничках поднят (и в общем то оставлен без ответов) целый пласт вопросов:

  1. Проблема совместимости в широком смысле;
  2. Проблема поддержки старого кода;
  3. Проблема зависимости человеческой жизни «от бесчувственных роботов» (с), к чему мы стремительно приближаемся;
  4. Проблема data mining`а вообще и поиска готового решения в бездонной бочке рецептов в частности (github, stack overflow?);
  5. Проблема «переписывания» старого кода (и плохого, и хорошего) — этот момент так и хочется перечитывать :);
  6. Проблема необъятности ИТ-технологий. Иногда говорят, что последний универсальный физик жил в середине пошлого века, имея ввиду Льва Ландау. Похоже сейчас наступает (или уже наступило) время, когда найти универсального программиста таки уже невозможно;
  7. В тексте нет слова хакер, ни в позитивной, ни в негативной коннотации. Но написано и об исследователях, и о тех преимуществах, которые можно получить зная те или иные backdoor`ы и о том, какую власть это может дать.
  8. и наверное это не все… :)

Складывается впечатление, что писал это человек, на своей шкуре прочувствовавший эти самые проблемы.
Хочу отметить, что «Глубина в небе» была написана в 1999 году, когда многое из того, о чем пишет Виндж еще не было проблемой, или вообще только показалось на горизонте.

В качестве критики хочется отметить, что Виндж прошел мимо ИИ (и сильного и слабого, вообще мимо пробежал, даже нейронные сети не затронул) и свел преимущества ИТ к производительности. Так же в тексте не ощущается присутствие мегакорпораций (хотя конечно «Глубина в небе» не относится к киберпанку), если не считать Кенг-Хо таковой. Нет патентных войн, не затронуты вопрос копирайта и проблема закрытых проприетарных разработок, исходные коды к которым так и не были опубликованы.

Не о программировании, но о стандартах

Дальше в той же главе затронут интереснейший вопрос галактического вещания с целью распространения собственных технологий. Зачем? Стандартизация. Распространение собственного языка и собственных стандартов и технологий, что позволит с одной стороны подтянуть отсталые цивилизации до приемлемого для торговли уровня, а с другой снизить затраты на коммуникацию и обеспечение совместимости и как следствие облегчит торговлю и повысит маржинальность. Интересно, знал ли Виндж на момент написания книги о стандартизации корабельной оснастки английского флота времен великих завоеваний, позволившей снизить затраты на ремонт и обслуживание? А о распространении английского языка в качестве делового, научного и т.д.? Англичане учили (заставляли учить?) местных аборигенов своему языку. Аналогично поступали испанцы и французы. И сейчас английский, испанский, французский, португальский имеют очень широкое распространение. А вот голландцы считали, что аборигенов не нужно учить своему языку. Много ли мест на земном шаре, где говорят на голландском кроме самой Голландии?
Сейчас обучение английскому поставлено на поток по всему миру. Использование стандартизированных методик и учебников, стандартизированных экзаменов и шкал оценок. Только ли частный бизнес?

Ниже привожу наиболее интересный отрывок из текста. В романе еще много всего интересного, не относящегося к программированию, не даром он собрал несколько премий. Так что рекомендую к прочению, причем в оригинале, попавшийся мне перевод не очень хороший.
Приятного прочтения :)
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js