Вот читаю такие статьи и складывается у меня стойкое ощущение, что AI, с одной стороны, действительно создаёт пропасть между энтузиастами и луддитами (что в целом норм), а с другой - ещё бОльшую пропасть между новичками и опытными разработчиками. Потому что джун пытается через AI бустить количество, а сениор - всё таки качество, и это буквально движение в противоположных направлениях.
Автор, перечитайте плиз свой список из 7 задач (в котором 8 пунктов, но вообще типа около 20 и из них многие дублируются). Это абсолютно бессистемное месиво.
Особого комментария заслуживает пункт с саммари созвонов. Вот бесплатный совет: всячески бойкотируйте бесполезные созвоны. Не допускайте их в свой рабочий процесс. А из действительно полезных вы и без автоматизаций вынесите все что нужно.
Все просто, нашёл запросом "php profiler", когда возникла потребность в профайлере) Сравнивал только с Xprof/Xdebug и Blackfire, это решение показалось существенно проще и наглядней.
Да, без всяких интеграций и только для локального пользования, только это мне и было нужно.
Разве для программиста или пользователя важна эквивалентность в смысле - эти две программы теоретически представимы одним набором инструкций и это можно доказать? Это просто забавный факт как по мне. Парадигмы не по такому принципу надо сравнивать, а с учетом кучи нюансов реального мира. Одна и та же программа в разных парадигмах будет с разной скоростью выполняться (потому что компиляторы не идеальны) и самое главное - по разному читаться и пониматься. Это архиважно, если мы говорим о сравнении парадигм.
Представляете, практический пример это код. Моё предположение в том, что автоматически верифицируемые программы настолько тривиальны, что польза в такой верификации совершенно незначительна. А для всего что "нечистое" всё так же нужно писать тесты. Ваш пример развеет моё невежество.
Тут требуется очень подробное объяснение (или авторитетная ссылка), т.к. меня учили что это принципиально разные парадигмы, хотя в каком-то смысле...
2.Практичный пример того, про что вы написали - простого автоматического верифицирования. Именно практичный, полезный пример использования, хочу видеть насколько это круто.
3. Ну допустим, я написал пару десятков программ на NASM в лохматые годы. Это вообще никак не относится к идее, что ассемблер не единственный язык ТОЛЬКО потому, что код пишут человеки.
Вот это хорошее объяснение, мотивирует в 3 раз попытаться разобраться с Haskell =)
Справедливости ради, типизация везде дает эффект лучшей предсказуемости. Но не настолько крутой, чтобы вообще не писать тесты. Кстати, как выглядят тесты на Haskell, они вообще бывают нужны?
Ассемблер - отличный пример. Есть места где ассемблер будет просто незаменим в практическом смысле. Незаменимого ФП я придумать не могу.
Ну а издержки и компромиссы буквально везде есть. Небольшой доп.объём кода я переживу, а вот ментальную модель без переменных но с необъяснимыми монадами - спасибо, но нет.
ФП противопоставляют ООП не просто так - в ООП меньше концепций. Да, они не так глубоки и универсальны. Постоянно то тут то там всплывают досадные неудобства - то null обработать, то временную переменную завести, то хочется скомбинировать функционал, который почему-то не спроектирован как комбинирующийся. НО. Это буквально вопрос эстетики, мир не рушиться от этих именно что не удобств. Со временем ООП-макака становиться мудрой ООП-макакой и заранее знает как аккуратно нивелировать эти неудобства, оставаясь в приятных рамках всё того же небольшого набора концепций.
От ФП Троггу грустно. ФП Троггу давать молоток для всего с алмазным напылением с большая инструкция на 500 страниц. ООП давать Троггу молоток, отвёртка, микроскоп. Всё подходит забить гвоздь!
А если серьёзно, ну давайте лучше с процедурным программированием сравним и ответим честно на 2 вопроса: что нельзя написать процедурно? В чём отличие, кроме "красоты"? Хотите красоты - делаете DSL, не пытаясь решать сразу все проблемы мира
Календари, имхо, нужны для сугубо 3 целей - не забывать о важных делах, привязанных к строго определённому времени. Причем, для этого основную пользу составляет не календарь, а привязанные к нему оповещения за день/час. - быстро найти подходящее свободное время под новую задачу. Эээ, у меня например всегда без календаря получалось. - психотерапевтический эффект - открыть календарь и сказать самому себе "ооо, какой я занятой, какой я молодец"
Всё. Всякую рутину туда заносить, причём динамически - это мусорные действия, даже с точки зрения той же эффективности
Существуют ли вообще хоть какие-то попытки стандартизировать эти многочисленные ui-библиотеки?
3/4 компонентов кочуют из одной либы в другую, просто кастомизируя апи кто во что горазд. С очень большой вероятностью половина перечисленных либ будет заброшена через несколько лет. Разве это не безумие, использовать ни с чем не совместимую библиотеку, создавая себе долг на ровном месте? Ладно, если это был бы действительно специфичный функционал. Но ui компоненты, Карл!
Для начала стоит команды не напрямую на хосте выполнять, а проксировать в виртуалку / контейнер. Если ai не знает что он в виртуалке, случайно вылезти из неё не особо реальная ситуация.
Второе - в случае GPT, стоит использовать апи функций, что позволит более конкретно ограничивать, какие именно возможности будут у нейронки.
Странно мешать в одну кучу конфиденциальность и AI специфику.
Очевидно, openai пылесосит данные пользователей абсолютно также, как и любая другая "корпорация добра". И использует их ровно также. А вот подмешивать конфиденциальные данные в нейронку крайне тупо, так как, насколько я понимаю, потом невозможно будет гарантировать, что она не начнёт их выплёвывать направо и налево с максимальными репутационными потерями. Более того, непубличные персональные данные это не то чтобы полезный датасет в плане обучения - что, возможно, негативно скажется на качестве.
Странно мешать в одну кучу конфиденциальность и "злую корпорацию".
Что если юзер сам копипастит файлик с паролями в чат (уверен, такие люди есть)? И чем это принципиально отличается от варианта распечатать этот файлик на бумажке и наклеить её на видное место? Это совсем никак с компанией не связано, зато даёт хороший ответ на вопрос "Можно ли доверять GPT-4o конфиденциальные данные?" - НУ КОНЕЧНО НЕТ. Если вы не хотите утечки своих данных - как минимум, они не должны быть в Интернете.
Cоветы в целом полезные, я бы примеры поправил на более показательные.
Сгруппировал по степени принятия
Категория "мегаимбовая гиперзачетная убербаза"
Не надо пробрасывать в классы весь контейнер целиком
Не мутировать объекты переданные в метод/функцию
Тестируем поведение, а не детали реализации
Композиция, а не наследование
Соблюдаем закон Деметры
Чем меньше методов в интерфейсе, тем лучше (Только это не про SRP, а про Interface Segregation)
Unit тесты всегда
Категория "Чую, куда ветер дует"
Максимально строгая типизация
Заполнение DTO через конструктор с именованными аргументами, readonly свойствами, без get/set методов
По умолчанию указываем final для классов
Не работаем с ассоциативными массивами, только с объектами
Категория "Благие намерения"
В DI подставляем реализации, а не интерфейсы
В интерфейсах указываем какие exception могут быть выброшены
Минимальная цикломатическая сложность
Количество аргументов в функции максимум 3
Категория "Автор что-то имел сказать"
Зависимости в di указываем явно. Явные зависимости в конструкторе класса, autowiring не разу не создавал проблем. Хочу конкретный пример, который убедит меня использовать искусственный идентификатор app.services.my_service в замен натуральному
Каждый класс закрывается интерфейсом Смущает слово "каждый". Это как делать настоящий самолет из лего - мы выкидываем жёсткую связь даже там, где она, прикиньте, бывает полезна.
Разбиваем большие классы и методы По моему опыту, 150 строк на класс в большинстве случаев мало. Конечно, большие классы и методы это хороший признак плохих решений в коде, но делать из него правило с конкретными цифрами, которое надо учитывать при разработке немного сомнительно.
Флаги в аргументах функций Смысл есть, но пример с всего лишь 1 флагом не вдохновляет на подвиги. Также как пример про большие классы - негуманно делать из этого правила (то что соблюдают?), это скорее небольшой notice на будущее.
Преимущество нетипизированых ЯП не в том, что можно не писать типы, а в том, что можно самому решать, когда они нужны, а когда нет.
Есть понятие контрактов - на их уровне типизация крайне полезна. В остальных местах менее важна и во многом зависит от предпочтений разработчиков.
Очевидно, типы увеличивают предсказуемость кода. Не сколько для непосредственно программистов (если они привыкли писать без типов, для них типы реально выглядят как гемор, ну ок), сколько для стат. анализа. А если и стат.анализ не использовать - ну извините, вы просто выбрали нишу разработки, где качество не сильно важно, такое бывает.
Не увидел в примерах пять поколений и перегрузки интерфейсами. И вообще не видел в реальности таких примеров, кроме специально надуманных fuzzBuzz-ов, которыми детей пугают. Что не так с читаемостью? Думаю, важно что php тут не выбран, а является данным контекстом. + php гораздо больше ориентирован на ООП чем на функциональщину, вот и всё
Я предполагаю что кейс такой. Когда вы собираете образ для своего сервиса и этот сервис использует курл как зависимость, вы можете вытянуть бинарник курла в свой образ при сборке, прописав в dockerfile что то вроде
Вот читаю такие статьи и складывается у меня стойкое ощущение, что AI, с одной стороны, действительно создаёт пропасть между энтузиастами и луддитами (что в целом норм), а с другой - ещё бОльшую пропасть между новичками и опытными разработчиками. Потому что джун пытается через AI бустить количество, а сениор - всё таки качество, и это буквально движение в противоположных направлениях.
Автор, перечитайте плиз свой список из 7 задач (в котором 8 пунктов, но вообще типа около 20 и из них многие дублируются). Это абсолютно бессистемное месиво.
Особого комментария заслуживает пункт с саммари созвонов. Вот бесплатный совет: всячески бойкотируйте бесполезные созвоны. Не допускайте их в свой рабочий процесс. А из действительно полезных вы и без автоматизаций вынесите все что нужно.
кстати, вроде как единственный профайлер, которой сейчас можно просто через PIE установить
Все просто, нашёл запросом "php profiler", когда возникла потребность в профайлере) Сравнивал только с Xprof/Xdebug и Blackfire, это решение показалось существенно проще и наглядней.
Да, без всяких интеграций и только для локального пользования, только это мне и было нужно.
Разве для программиста или пользователя важна эквивалентность в смысле - эти две программы теоретически представимы одним набором инструкций и это можно доказать? Это просто забавный факт как по мне.
Парадигмы не по такому принципу надо сравнивать, а с учетом кучи нюансов реального мира. Одна и та же программа в разных парадигмах будет с разной скоростью выполняться (потому что компиляторы не идеальны) и самое главное - по разному читаться и пониматься. Это архиважно, если мы говорим о сравнении парадигм.
Представляете, практический пример это код. Моё предположение в том, что автоматически верифицируемые программы настолько тривиальны, что польза в такой верификации совершенно незначительна. А для всего что "нечистое" всё так же нужно писать тесты. Ваш пример развеет моё невежество.
Тут требуется очень подробное объяснение (или авторитетная ссылка), т.к. меня учили что это принципиально разные парадигмы, хотя в каком-то смысле...
2.Практичный пример того, про что вы написали - простого автоматического верифицирования. Именно практичный, полезный пример использования, хочу видеть насколько это круто.
3. Ну допустим, я написал пару десятков программ на NASM в лохматые годы. Это вообще никак не относится к идее, что ассемблер не единственный язык ТОЛЬКО потому, что код пишут человеки.
Извиняюсь, что с чем эквивалентно?
Приведите, пожалуйста, практичный пример
Меня полностью устраивает, если останется только ассемблер. С ИИ всё к этому и идёт.
Странно, что до сих пор на хабре не всплывал SPX profiler
https://github.com/NoiseByNorthwest/php-spx
Пользуюсь несколько лет, маскимально удобная штука.
upd.: не, кое что было
https://habr.com/ru/articles/505192/
Вот это хорошее объяснение, мотивирует в 3 раз попытаться разобраться с Haskell =)
Справедливости ради, типизация везде дает эффект лучшей предсказуемости. Но не настолько крутой, чтобы вообще не писать тесты. Кстати, как выглядят тесты на Haskell, они вообще бывают нужны?
Ассемблер - отличный пример. Есть места где ассемблер будет просто незаменим в практическом смысле. Незаменимого ФП я придумать не могу.
Ну а издержки и компромиссы буквально везде есть. Небольшой доп.объём кода я переживу, а вот ментальную модель без переменных но с необъяснимыми монадами - спасибо, но нет.
После таких статей стараюсь о нём не думать =)
ФП противопоставляют ООП не просто так - в ООП меньше концепций. Да, они не так глубоки и универсальны. Постоянно то тут то там всплывают досадные неудобства - то null обработать, то временную переменную завести, то хочется скомбинировать функционал, который почему-то не спроектирован как комбинирующийся. НО. Это буквально вопрос эстетики, мир не рушиться от этих именно что не удобств. Со временем ООП-макака становиться мудрой ООП-макакой и заранее знает как аккуратно нивелировать эти неудобства, оставаясь в приятных рамках всё того же небольшого набора концепций.
От ФП Троггу грустно. ФП Троггу давать молоток для всего с алмазным напылением с большая инструкция на 500 страниц. ООП давать Троггу молоток, отвёртка, микроскоп. Всё подходит забить гвоздь!
А если серьёзно, ну давайте лучше с процедурным программированием сравним и ответим честно на 2 вопроса: что нельзя написать процедурно? В чём отличие, кроме "красоты"?
Хотите красоты - делаете DSL, не пытаясь решать сразу все проблемы мира
Календари, имхо, нужны для сугубо 3 целей
- не забывать о важных делах, привязанных к строго определённому времени. Причем, для этого основную пользу составляет не календарь, а привязанные к нему оповещения за день/час.
- быстро найти подходящее свободное время под новую задачу. Эээ, у меня например всегда без календаря получалось.
- психотерапевтический эффект - открыть календарь и сказать самому себе "ооо, какой я занятой, какой я молодец"
Всё. Всякую рутину туда заносить, причём динамически - это мусорные действия, даже с точки зрения той же эффективности
Вы не правы. IoC может быть вообще без интерфейсов. Он про то, что не программист управляет потоком выполнения, а фреймворк.
Если уж пытаться дружить эти термины, DI это очень частный случай IoC. Поэтому DI-контейнер более точный термин.
Вот у меня вопрос к фронтенд комьюнити.
Существуют ли вообще хоть какие-то попытки стандартизировать эти многочисленные ui-библиотеки?
3/4 компонентов кочуют из одной либы в другую, просто кастомизируя апи кто во что горазд. С очень большой вероятностью половина перечисленных либ будет заброшена через несколько лет. Разве это не безумие, использовать ни с чем не совместимую библиотеку, создавая себе долг на ровном месте? Ладно, если это был бы действительно специфичный функционал. Но ui компоненты, Карл!
Для начала стоит команды не напрямую на хосте выполнять, а проксировать в виртуалку / контейнер. Если ai не знает что он в виртуалке, случайно вылезти из неё не особо реальная ситуация.
Второе - в случае GPT, стоит использовать апи функций, что позволит более конкретно ограничивать, какие именно возможности будут у нейронки.
Странно мешать в одну кучу конфиденциальность и AI специфику.
Очевидно, openai пылесосит данные пользователей абсолютно также, как и любая другая "корпорация добра". И использует их ровно также. А вот подмешивать конфиденциальные данные в нейронку крайне тупо, так как, насколько я понимаю, потом невозможно будет гарантировать, что она не начнёт их выплёвывать направо и налево с максимальными репутационными потерями. Более того, непубличные персональные данные это не то чтобы полезный датасет в плане обучения - что, возможно, негативно скажется на качестве.
Странно мешать в одну кучу конфиденциальность и "злую корпорацию".
Что если юзер сам копипастит файлик с паролями в чат (уверен, такие люди есть)? И чем это принципиально отличается от варианта распечатать этот файлик на бумажке и наклеить её на видное место? Это совсем никак с компанией не связано, зато даёт хороший ответ на вопрос "Можно ли доверять GPT-4o конфиденциальные данные?" - НУ КОНЕЧНО НЕТ. Если вы не хотите утечки своих данных - как минимум, они не должны быть в Интернете.
А можно в список кринж-ситуаций такие формулировки добавить?
Предположил что имелось в виду "диагональ" - так у вас ещё и бинго неквадратное
Cоветы в целом полезные, я бы примеры поправил на более показательные.
Сгруппировал по степени принятия
Категория "мегаимбовая гиперзачетная убербаза"
Не надо пробрасывать в классы весь контейнер целиком
Не мутировать объекты переданные в метод/функцию
Тестируем поведение, а не детали реализации
Композиция, а не наследование
Соблюдаем закон Деметры
Чем меньше методов в интерфейсе, тем лучше (Только это не про SRP, а про Interface Segregation)
Unit тесты всегда
Категория "Чую, куда ветер дует"
Максимально строгая типизация
Заполнение DTO через конструктор с именованными аргументами, readonly свойствами, без get/set методов
По умолчанию указываем final для классов
Не работаем с ассоциативными массивами, только с объектами
Категория "Благие намерения"
В DI подставляем реализации, а не интерфейсы
В интерфейсах указываем какие exception могут быть выброшены
Минимальная цикломатическая сложность
Количество аргументов в функции максимум 3
Категория "Автор что-то имел сказать"
Зависимости в di указываем явно.
Явные зависимости в конструкторе класса, autowiring не разу не создавал проблем.
Хочу конкретный пример, который убедит меня использовать искусственный идентификатор
app.services.my_serviceв замен натуральномуКаждый класс закрывается интерфейсом
Смущает слово "каждый". Это как делать настоящий самолет из лего -
мы выкидываем жёсткую связь даже там, где она, прикиньте, бывает полезна.
Разбиваем большие классы и методы
По моему опыту, 150 строк на класс в большинстве случаев мало. Конечно, большие классы и методы это хороший признак плохих решений в коде, но делать из него правило с конкретными цифрами, которое надо учитывать при разработке немного сомнительно.
Флаги в аргументах функций
Смысл есть, но пример с всего лишь 1 флагом не вдохновляет на подвиги. Также как пример про большие классы - негуманно делать из этого правила (то что соблюдают?), это скорее небольшой notice на будущее.
Преимущество нетипизированых ЯП не в том, что можно не писать типы, а в том, что можно самому решать, когда они нужны, а когда нет.
Есть понятие контрактов - на их уровне типизация крайне полезна. В остальных местах менее важна и во многом зависит от предпочтений разработчиков.
Очевидно, типы увеличивают предсказуемость кода. Не сколько для непосредственно программистов (если они привыкли писать без типов, для них типы реально выглядят как гемор, ну ок), сколько для стат. анализа. А если и стат.анализ не использовать - ну извините, вы просто выбрали нишу разработки, где качество не сильно важно, такое бывает.
Не увидел в примерах пять поколений и перегрузки интерфейсами. И вообще не видел в реальности таких примеров, кроме специально надуманных fuzzBuzz-ов, которыми детей пугают.
Что не так с читаемостью? Думаю, важно что php тут не выбран, а является данным контекстом. + php гораздо больше ориентирован на ООП чем на функциональщину, вот и всё
Я предполагаю что кейс такой. Когда вы собираете образ для своего сервиса и этот сервис использует курл как зависимость, вы можете вытянуть бинарник курла в свой образ при сборке, прописав в dockerfile что то вроде
Не берусь судить, насколько это феншуй, но для маленькой утилиты как раз удобно