ну я считал, что все эти S S S S Z это они и есть

Ну меня смущает, что это не функция, а алгтд

надо подумать

Ну, у пирса числа чёрча определяются как c₀ = λs. λz. z c₁ = λs. λz. s z ....

Ну и функция следования, очевидно, scc = λn. λs. λz. s (n s z)

ну я считал, что все эти S S S S Z это они и есть

С другой стороны, видел, что на алгтд тоже называют (что неверно), когда на них реализуют зависимые типы там, где их нет (скажем, в том же расте в одной либе на них арифметика на типах построена, чтобы можно было делать Matrix<Three, Two> и пр)

https://www.youtube.com/watch?v=9zpG_hJsrL8

Чел так интересно начал, вы меня не знаете, но я ненавижу ООП :D property based testing

property based testing оч клевая и занятная тема

ну на 1,5 можно смотреть

но оно не особо про "TDD без моков" и ложится хорошо и на ООП и на функциональщину и вообще и то и то это одно и тоже

сначала много воды

ну property based testing вообще несильно к tdd относится

ну тип да)

ну он рассматривает tdd как software testing

не в его общем плане

знаменитое понимание tdd как большое число тестов)

https://www.youtube.com/watch?v=9zpG_hJsrL8

Антон уже не первый год пересказывает доклады Марка Симана, используя его слайды и даже примеры кода :)

привет всем

подскажите книжку хорошую

https://oopru.github.io/

это ваш сайт чатика ?

скромно

???

скромно

KISS

https://blogs.msdn.microsoft.com/ericgu/2017/06/22/notdd/

> It takes us longer to write code using TDD бездоказательное утверждение. Я знаю только про один прецидент когда решили проверить и выходило что с TDD выходит либо сколько же, либо быстрее. Другое дело что психологически испытуемым казалось что дольше.

> Because my design does not have low coupling, ну да, TDD и говнокод не очень хорошо дружат

> Instead of spending time teaching people TDD, we should instead be spending time teaching them more about design and especially more about refactoring А, простите, TDD про что?

ну то есть как по мне - человек путает test-first и test driven

Смысл в том что tdd может тоже получить хреновый код и трудноподдерживаемые тесты в довесок, если рефакторинг не твоя сильная сторона

Смысл в том что tdd может тоже получить хреновый код и трудноподдерживаемые тесты в довесок, если рефакторинг не твоя сильная сторона

вот только рефакторинг - обязательная часть TDD

потому если у тебя все плохо с рефакторингом то и от TDD толку мало

TDD - оно не про тесты

Согласен. Refactoring driven тогда

Смысл в том что tdd может тоже получить хреновый код и трудноподдерживаемые тесты в довесок, если рефакторинг не твоя сильная сторона

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

Согласен. Refactoring driven тогда

а какой refactoring driven без тестов?

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

когда неудобно тесты становится писать - можно подумать как сделать что бы было чуть удобнее

Кто то хочет немного троллинга? Из одной статьи "Больше кода, не значит лучше Существует понятие overengineering, которое описывает желание сделать решение простой по своей сути задачи более масштабным, чем оно того заслуживает в реальности. Предположим, по условию задачи нам необходимо обойти все файлы в указанной пользователем директории и сложить записанные в них числа. Хоть это задание и предлагается выполнить на объектно-ориентированном языке программирования, нет ничего плохого в решении, написанном в процедурном стиле. Весь код может уместиться буквально в пару десятков строк, так зачем «размазывать» его на нечто большее? Многие разработчики могут подумать, что подход с написанием классов даже в таком простом случае может показать представителям компании, что кандидат разбирается в основных принципах ООП, а также заботится о дальнейшем сопровождении и развитии кода. На самом же деле зачастую гораздо приятнее видеть, что разработчик может провести грань между «демонстрационным заданием» и «проектом с 10 годами поддержки в будущем». Не нужно забывать о том, что код тестового задания будет читать человек, у которого, возможно, не так много времени на его доскональное изучение. Краткость — сестра таланта!"

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

и как бы работает на порядок лучше чем тот же ФБ

Кто то хочет немного троллинга? Из одной статьи "Больше кода, не значит лучше Существует понятие overengineering, которое описывает желание сделать решение простой по своей сути задачи более масштабным, чем оно того заслуживает в реальности. Предположим, по условию задачи нам необходимо обойти все файлы в указанной пользователем директории и сложить записанные в них числа. Хоть это задание и предлагается выполнить на объектно-ориентированном языке программирования, нет ничего плохого в решении, написанном в процедурном стиле. Весь код может уместиться буквально в пару десятков строк, так зачем «размазывать» его на нечто большее? Многие разработчики могут подумать, что подход с написанием классов даже в таком простом случае может показать представителям компании, что кандидат разбирается в основных принципах ООП, а также заботится о дальнейшем сопровождении и развитии кода. На самом же деле зачастую гораздо приятнее видеть, что разработчик может провести грань между «демонстрационным заданием» и «проектом с 10 годами поддержки в будущем». Не нужно забывать о том, что код тестового задания будет читать человек, у которого, возможно, не так много времени на его доскональное изучение. Краткость — сестра таланта!"

Отличное замечание. ООП - инструмент, а не цель. В первую очередь нужен результат, всё остальное вторично.

p.s. небольшой спойлер, это не троллинг, а наркомания, оттуда же: "Дурным тоном также считается выполнение в одной и той же функции нескольких несвязанных по своей сути вещей. Например, когда функция, читающая число из указанного файла, не только, собственно, читает этот файл, но и прибавляет его к переменной, обозначающей сумму." Прямо противоположно тому что было в первом отрывке. Отсюда https://gmsservices.ru/blog/2017/05/22/dev-task-fails/

Отличное замечание. ООП - инструмент, а не цель. В первую очередь нужен результат, всё остальное вторично.

ООП инструмент, нет инструмента - нет достижения цели

p.s. небольшой спойлер, это не троллинг, а наркомания, оттуда же: "Дурным тоном также считается выполнение в одной и той же функции нескольких несвязанных по своей сути вещей. Например, когда функция, читающая число из указанного файла, не только, собственно, читает этот файл, но и прибавляет его к переменной, обозначающей сумму." Прямо противоположно тому что было в первом отрывке. Отсюда https://gmsservices.ru/blog/2017/05/22/dev-task-fails/

По-моему всё как раз очень разумно и непротиворечиво. 1) "красиво" не надо - надо эффективно; 2) "плохо" не надо делать никогда.

ООП инструмент, нет инструмента - нет достижения цели

Ещё есть сотня инструментов, которые не хуже.

Тот же GC сделал для индустрии существенно больше, чем "все эти SOLID" вместе взятые.

С кривыми руками и самый продуманный фреймворк с ООП не поможет, а с ровными можно и процедурно написать расширяемое, продуманное приложение которое будет просто развивать и поддерживать.

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

У них и зам нету топ. Они пыху же форкнули и выпили всё оттуда

Тот же GC сделал для индустрии существенно больше, чем "все эти SOLID" вместе взятые.

А какие критерии оценки?

Наверное, стоит применять такие же, как и при оценке "с ООП лучше, чем без ООП".

Надёжность кода, простота разработки и поддержки, бизнес-эффект.

В качестве "доказательства" высокой важности GC (автоматического управления памятью) я бы привёл такое наблюдение: системы разработки всякого серверного ПО (java, javascript, php, python, C#, scala, - что там ещё реально применяют?) почти на 100% содержат garbage collector.

При этом "тру ООП" среди них очень мало.

(Да, это всё очень спорно и сомнительно; тем не менее наблюдение имеет место быть)

ERROR: S client not available

Сравнение теплого с мягким

В общем да.

/stat@combot

combot.org/chat/-1001071233926

Сравнение теплого с мягким

Хотя в разрезе "что выгоднее для бизнеса - система со сборкой мусора, или с ООП" - вполне нормальное сравнение.

Кто то хочет немного троллинга? Из одной статьи "Больше кода, не значит лучше Существует понятие overengineering, которое описывает желание сделать решение простой по своей сути задачи более масштабным, чем оно того заслуживает в реальности. Предположим, по условию задачи нам необходимо обойти все файлы в указанной пользователем директории и сложить записанные в них числа. Хоть это задание и предлагается выполнить на объектно-ориентированном языке программирования, нет ничего плохого в решении, написанном в процедурном стиле. Весь код может уместиться буквально в пару десятков строк, так зачем «размазывать» его на нечто большее? Многие разработчики могут подумать, что подход с написанием классов даже в таком простом случае может показать представителям компании, что кандидат разбирается в основных принципах ООП, а также заботится о дальнейшем сопровождении и развитии кода. На самом же деле зачастую гораздо приятнее видеть, что разработчик может провести грань между «демонстрационным заданием» и «проектом с 10 годами поддержки в будущем». Не нужно забывать о том, что код тестового задания будет читать человек, у которого, возможно, не так много времени на его доскональное изучение. Краткость — сестра таланта!"

а почему троллинг? так и есть, чем меньше деталей тебе нужно держать в голове, даже в случае с ооп - минимум абстракций с минимумом кода + максимальное соблюдение принципов и правил

p.s. небольшой спойлер, это не троллинг, а наркомания, оттуда же: "Дурным тоном также считается выполнение в одной и той же функции нескольких несвязанных по своей сути вещей. Например, когда функция, читающая число из указанного файла, не только, собственно, читает этот файл, но и прибавляет его к переменной, обозначающей сумму." Прямо противоположно тому что было в первом отрывке. Отсюда https://gmsservices.ru/blog/2017/05/22/dev-task-fails/

так это нарушение spr епт, который справедлив не только для классов но и для функций и методов

а почему троллинг? так и есть, чем меньше деталей тебе нужно держать в голове, даже в случае с ооп - минимум абстракций с минимумом кода + максимальное соблюдение принципов и правил

Вот и я о том же. Легко увлечься "красотой ООП" (или там любой другой "красотой") и за деревьями перестать видеть лес.

Кто то хочет немного троллинга? Из одной статьи "Больше кода, не значит лучше Существует понятие overengineering, которое описывает желание сделать решение простой по своей сути задачи более масштабным, чем оно того заслуживает в реальности. Предположим, по условию задачи нам необходимо обойти все файлы в указанной пользователем директории и сложить записанные в них числа. Хоть это задание и предлагается выполнить на объектно-ориентированном языке программирования, нет ничего плохого в решении, написанном в процедурном стиле. Весь код может уместиться буквально в пару десятков строк, так зачем «размазывать» его на нечто большее? Многие разработчики могут подумать, что подход с написанием классов даже в таком простом случае может показать представителям компании, что кандидат разбирается в основных принципах ООП, а также заботится о дальнейшем сопровождении и развитии кода. На самом же деле зачастую гораздо приятнее видеть, что разработчик может провести грань между «демонстрационным заданием» и «проектом с 10 годами поддержки в будущем». Не нужно забывать о том, что код тестового задания будет читать человек, у которого, возможно, не так много времени на его доскональное изучение. Краткость — сестра таланта!"

так типа return directory.findFiles().map(getContent).map(findNumbers).reduce(sum, 0)

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

вот неплохой пост на счет минимума кода https://habrahabr.ru/company/ruvds/blog/313836/

вот неплохой пост на счет минимума кода https://habrahabr.ru/company/ruvds/blog/313836/

Хе хе хе, это может стать новой парадигмой - "хороший вкус - следующий шаг после объектного и функционального программирования".

нет

Со своими паттернами, новыми гуру, непонятными аббревиатурами.

фп или ооп тут вообще не причем)

Для становления парадигмы это не помеха.

Хе хе хе, это может стать новой парадигмой - "хороший вкус - следующий шаг после объектного и функционального программирования".

я бы это сравнил с навыком, игрой на тех же барабанах - тебе кроме чувства (понимания) ритма нужны еще отработанные до автоматизма движения

Для становления парадигмы это не помеха.

ну хз, каждая парадигма решает какую-то бизнес проблему

а что здесь?)

Ну если говорить серьёзно - то конечно это не парадигма, и даже не "метод". Скорее - навык, полезное свойство мышления.

и кстати этот навык еще не плохо форсится изучением других языков

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

джаваскриптово)

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

ФПООП

ФПООП

у

ТРУ АОПЕ ПРОГРОМЕСТЫ

ПРИВЕТ

https://twitter.com/delawen/status/880517810400759808 Егор пошел еще дальше в высказываниях))