Можно ли внедрить в Haskell постфиксный калькулятор?
begin push 1 push 2 add end
begin push 1 push 2 push 3 add mul end
На первый взгляд такой код на Haskell не может работать. Функция begin должна иметь произвольное количество аргументов, а Haskell является языком со статической типизацией. Но на самом деле, для написания вариативных (polyvariadic) функций достаточно полиморфизма.
«ООП для меня означает лишь обмен сообщениями, локальные ограничения и защиту, сокрытие состояния процесса и крайне позднее привязывание», — Алан Кэй (человек, придумавший термин «объектно-ориентированное программирование»)1
Константы — это здорово. Типы — это замечательно. Константы определенного типа — еще лучше. А enum классы — это просто фантастика.
В прошлом году мы говорили о том, почему следует избегать использования булевых параметров функций. Одно из предложенных решений — использование сильных типов, в частности, использование перечислений вместо голых булевых значений. В этот раз давайте посмотрим, как развивались перечисления и связанная с ними поддержка на протяжении всего жизненного пути нашего любимого языка.
Полиморфизм в языках программирования и теории типов — способность функции обрабатывать данные разных типов
- // getRectangleArea(x1, y1, x2, y2) или
- // getRectangleArea(width, height)
- function getRectangleArea(x1, y1, x2, y2) {
- if(arguments.length==2) return x1*y1;
- return (x2-x1)*(y2-y1);
- }
* This source code was highlighted with Source Code Highlighter.
Последнее время мне приходится много ревьювить, анализировать, рефакторить C# код. Практика показывает, что принципы Объектно-Ориентированного Программирования не просто вызывают затруднения в понимании, и в применении, в большинстве случаев разработчики просто избегают их использования на практике. Я очень надеюсь, что мой относительно простой пример, который можно не только скомпилировать и выполнить, но и написать свой класс расширения и снова скомпилировать, и оценить результат уже своего труда внутри небольшой законченной программы, надеюсь это поможет кому-то преодолеть барьер к использованию принципов ООП на практике.
Конечно, мне придется продемонстрировать применение на практике принципов ООП: инкапсуляция, наследование, полиморфизм и то, как они работают.
Конечно, разберем как все это влияет на производительность. Я надеюсь, что получится сформулировать некое подобие ответа на критику постулатов «чистого» кода от достаточно успешного (видимо) иностранного программиста в переводе на Хабре: «Чистый» код, ужасная производительность.
Правила «чистого» кода, изложенные в той статье помогут нам подойти к реализации принципов ООП в нашей задаче.
Начав свою карьеру в качестве C# разработчика, я постоянно сталкивался с использованием техники внедрения зависимостей (Dependency Injection). За то время, что я работаю с C++, я не заметил здесь такого же широкого распространения этой идеи.
В то же время мне показалась весьма интересной такая возможность C++, как написание кода, который частично либо полностью может быть выполнен на этапе компиляции.
Объединив две эти идеи, у меня получилась простая библиотека для внедрения зависимостей, которая обходится средствами статического полиморфизма, не прибегая к позднему связыванию. О ней и пойдёт речь в этой статье. На её примере разберёмся с тем, как работает внедрение зависимостей и какие каждодневные проблемы оно решает.
for или итератор можно было бы заставить работать в несколько потоков. Например если у вас есть такая цепочка итераторов:let total_price = stores.iter()
.map(|store| store.compute_price(&list))
.sum()
let total_price = stores.par_iter()
.map(|store| store.compute_price(&list))
.sum()
Область ИТ растёт, и легко заблудиться в зоопарке подходов, фреймворков и технологий, которые громко заявляют о своей "новизне" и "эффективности". Но за обёрткой обычно скрываются старые добрые идеи, заново "изобретённые" в другом контексте. В итоге распространяется не самая простая и эффективная, а самая разрекламированная реализация. Разработчики не успевают вдумчиво произвести выбор из-за постоянного недостатка времени, а менеджеры выбирают самое распространённое, чтобы снизить риски при поиске разработчиков.
Для себя я стараюсь свести используемый в индустрии термин или технологию к простому определению или наглядному примеру. Предлагаю справочник, очень краткий, и поэтому неполный и не претендующий на точность.
