Можете пожалуйста пояснить, кого можно называть инженером (в айтишке, офк) и почему?
Если по уму то никого. Есть профессия инженер а есть программист. В большинстве своем, названия типо software engineer и прочее - это странные понты некоторых компаний, которые хотят поставить себя выше остальных, потому что у них не какие то никчемные программисты работают а целые software engineers.
Но если бы ко мне пристали с задачей - "нет ну ты все-таки придумай, хотя бы субъективно, как разделить программистов и инженеров", то я бы наверное поделил так: инженеры, пусть это будут разработчики ОС, драфверов, компиляторов, виртуальных машин, игровых движков, железячники т.д., т.е. специалисты, для работы которым нужны фундаментальные знания, часто научный подход, люди которые строят базу для всех остальных, а вот все остальные - это программисты, по сути пользователи того что сделали инженеры. Наверное так.
Интересно наблюдать, в какое еще говно мокнут и обесценят некогда почетное слово инженер.
Сначала, формошлеперы и json-перекладчики провозгласили что все, они теперь не какие то там веб программисты а целые инженеры. Теперь вот докатились что уже вайбкодеры на себе примеряют.
Правильно, сейчас не модно как раньше расти чтобы соответствовать, сейчас проще обесценить термин и натянуть его на себя.
Тогда, во многом солидарен. Мне вообще нравиться отчасти перекликающийся подход в Rust в этом плане. Где трейты, очень похожи внешне на интерфейсы но являются не контрактами а по сути ограничителями для дженериков, и по больше части используются для ограничения параметров функций.
Вы показали примеры где интерфейс используется для сокрытия реальной зависимости и как абстрактное возвращаемое значение, но самое интересное обошли стороной - интерфейс как параметр функции. Хотелось бы услышать Ваше мнение по этому поводу.
Постоянные и непременные отсылки к дядюшке Бобу, или другим корифеям как-то странно звучат. Я не опираюсь на авторитет, никогда не апеллирую к нему в аргументах, мне он не важен. Это интересно как историческая справка, не более.
Ну, во первых, я специально не привожу это как аргумент из-за субъективной его природы. Но тем не менее, полностью не учитывать связь между творчеством и творцом - нельзя.
Благодаря популярности и широкому охвату аудитории среди специалистов, принципы на сегодняшний день очень хорошо разжёваны и расписаны, и достаточно раскритикованы. Смотрите на это, как на библиотеку, которую написали сообществом и можно использовать в работе, не затрачивая усилий на создание новых, узких и малоизвестных принципов или подходов.
То что он разжёваны и то что их вообще нужно толковать - это и есть проблема, у нас вроде бы не теология а программирование. Если у принципа нет однозначной интерпретации то пойдут толкования, различные взгляды и направления. Кто будет определять кто из толкователей самый правильный и какая трактовка самая верная? И мы приходим к тому с чего начали: на МР два разработчика будут спорить каждый со своей колокольни, потому что правильного ответа нет как и методики. Если же ссылается к толкованиям от авторитетов то мы превратиться в подобие религии а должны хоть как то походить на науку.
Да, это не формула, высеченная в камне, не аксиома, не ответ на все вопросы, не решение всех задач, но это весьма конкретные указания, общие принципы, которым итак многие следуют вполне естественным образом.
Когда строят здание то руководствуются не абстрактными общими принципами а конкретными обоснованными с точки зрения науки и практики нормами.
Отдельные принципы могут иметь различия в деталях, на то они и принципы, а не конкретные методики, где написано до буквы: делай А, получишь Б.
Проблема в том что такое прокатывает в гуманитарных дисциплинах, когда судья руководствуется внутренним чувством справедливости, к примеру, в отдельных аспекта. И такое абсолютно не применимо в технических.
Т.е. суть в том, что они действуют не только между участниками одной команды, а между участниками всех команд в мире.
В том и проблема, что даже между участниками одной команды не будет понимания, потому что эти самые принципы не дают никакой конкретики, они просто хорошо и красиво звучат. А прицип, который для каждого звучит по разному имеет низкую практическую ценность.
Но я наблюдаю другой тренд: давайте вообще всё выкинем, под корень. Всё это туфта. Конечно, не забудем принизить значимость авторов: да это какой-то писака, вообще не шарит и далёк от реальных задач.
Ну тут Вы явно преувеличиваете. Я ни разу не видел что кто-то предлагал выкинуть вообще все. Чаще, одно радикально поперек другого. И оно не удивительно. К примеру, тот же ООП, который захватил огромную часть IT на несколько десятилетий, практически выдавив любое инакомыслие. Чистый код, SOLID и паттерны проектирования, про которые можно было послушать из каждого утюга. Все это в том числе, дичайшим образом догматизировало огромную часть сообщества и остановило в развитии. Огромное число людей стали не искать решение проблем а то как пользоваться инструментом. Ожидаемо было, что после многих лет в таком режиме, оно бомбанет и многие люди, разочаровавшись в старых инструментах, подходах и авторах, пойдут искать радикально другие подходы. И это хорошо, т.к. маятник будет ходить туда сюда балансируя и выверяя эти самые инструменты и подходы. Намного лучше, чем застрять в развитии, заменив прагматизм на веру.
У меня другое мнение на этот счёт. Многие люди признают, что с опытом заявленные принципы становятся очевидными и применяются даже без явного знания или умышленного следования им. Эти принципы нужны для согласования работы, новичкам.
Понимаете, вопрос ни в том какой у кого мнение. Можно было бы сказать что Роберт Мартин и ко, никакие не светилы с олимпа создавшие грандиозные проекты а скорей успешные писатели. Что если посмотреть его проекты то он давно не следует своим же принципам. Что в своем блоге он писал что когда придумывал SOLID не очень понимал принцип подстановки Лисков. Что принципы формировались так чтобы получилось красивое слово а не по соображениям важности. Но я не будет приводить это как аргументы так как это в некоторой мере субъективно. Я приведу объективный аргумент.
На мой взгляд, в каких либо принципах, главное - это точки их приложения а не красивая идея на фоне. И вот здесь главная проблема. Возьмем SRP, вроде бы и звучит красиво и как будто бы о правильном - "хорошо делай - хорошо будет", но говорит ли нам этот принцип о том как делать хорошо или хотя бы о том что такое ответственность, как это все посчитать или распределить? Нет? Возьмите двух разработчиков дайте им одну и ту же задачу и попросите использовать SRP. С огромной долей вероятности Вы получите разные решения, потому что каждый будет интерпретировать SRP по своему.
Как минимум, это может быть полезно на code review, естественно без фанатизма.
Выкатил Петя МР, а ему Дима говорит: ты тут нарушаешь SRP, после чего начинается срачь, т.к у каждого свое видение. Потому как SRP не описываем хоть как то детерминированный механизм реализации собственного постулата а получается тотальная субъективщина. Толку от такого принципа, как от совета прохожего: "живите правильно и все у вас будет". Тоже самое с ISP и т.д. Принцип LSP наиболее адекватный и детерминированный но самый редко применимый, да и к примеру, если посмотреть на стандартную библиотеку Java, то там раз через раз он нарушается (видимо разработчики языка программирования забыли сходить к Мартину).
В общем говоря, принципы SOLID по большей части это красивые советы (возможно даже где-то правильные) без определений их приложения (и соответственно большого практического смысла), которые появились потому что пару человек, которые ни разу не гении в IT, по приколу их собрали исходя из своих субъективных взглядов и понятий красоты, при этом вся заслуга популярности принципов это популярность их автора а не ценность или важность для сферы. Не нужно делать из попсы религию.
Тренд отрицания всего и вся тоже можно назвать завирусившимся.
Завирусившимся можно назвать тренд на возврат к критическому мышлений, когда мы должны во всем сомневаться, переосмысливать, критиковать и требовать доказательств в противовес догматическому мышлению когда миллионы людей поклоняются тому что какой-нибудь дяденька написал в книжке.
К сожалению, в русскоязычном Go-сообществе действительно очень слабо с пониманием SOLID и чистой архитектуры в частности. Вместо того чтобы разобраться, как это работает, многие разработчики просто уходят в отрицание и заявляют, что им это не нужно, хотя на самом деле, скорее всего, просто стесняются признаться, что не смогли разобраться.
YAGNI упомянут совершенно не к месту. Это не «принцип, который почему-то большинство игнорирует», а скорее философская установка, которая формально «за всё хорошее и против всего плохого», но при этом не даёт никаких конкретных границ или ограничений, в отличии от реальных принципов
Для меня загадка как Вы это видите в YAGNI но в упор не замечаете что SOLID - ровно тоже самое. При этом считаете что сообщество языка, авторы которого активно продвигали философию простоты во всем, обязано наперекор принципам языка, тащить туда неповоротливые чистые архитектуры, с которыми уже и так намучались в других языках.
Что значит "отказался" от YAGNI, KISS, SOLID? Делаем наперекор? Если не упарываться, то эти принципы выведены из практики, а не практика построена на этих принципах.
Наверное - это перестать делать вид что какой-нибудь SOLID - это действительно что-то умное и важное посланное нам полу-богами величайшими светилами IT а не абстрактный, завирусившийся набор практически бесполезных советов в духе "хорошо делай - хорошо будет", придуманных из буков собранных по принципу как красивее в слово собрать, дяденьками которым банально было нечем заняться.
Вы делаете эти предположения на уровне конфигурации.
Нет. На уровне кода. В любом месте можно задать контекст выполнения.
То у вас уже большие проблемы, и да, автоматически их виртуальные потоки не починят. К счастью, таких библиотек исчезающе мало.
Всю 30 летнюю экосистему Java взяли и по быстрому переписали? Оптимистично.
То что у вас снаружи написано async не значит, что внутри нет большого синхронного куска, не позволяющего переключать контекст.
Есть разница между тем что автор библиотеки написал async но не реализовал, потому что он дурак и тем когда автор ничего не писал и не гарантировал.
Я вообще не рассуждаю о том, что лучше - иметь очень так себе имплементацию сразу или пилить хорошую 11 лет. Я рассуждаю на состояние сегодня, что лучше - заставлять красить методы (и перекрашивать, что самое плохое) или иметь stackfull на стороне рантайма. И на мой вкус, раскраска проигрывает колоссальным образом.
Так Вы и рассуждайте сегодня. А сегодня есть go и java а подавляющее большинство остальных языков раскрашивают функции. Что вы предлагаете, переделать им на виртуальные потоки все? Если нет, то что по Вашему "зло во плоти" то, инструмент который позволил сэкономить 11 лет? Понимаете, если бы Java сейчас выкатила что-то невероятное, инновационное, меняющее подходы кардинальным образом то это еще ладно, но по факту но они просто догнали конкурентов. Поэтому я не понимаю идею про "зло во плоти", есть работающий много лет инструмент а есть может быть чуть более удобное решение(время покажет) которое запоздало на десяток лет. Async/await явно прорывное для своего времени решение которое позволило многим языкам и экосистемам работать удобно и эффективно, в то время как другие десять лет изобретали, так что я бы не стал это называть "зло во плоти" точно.
Не важно что написано в документации библиотеки, виртуальные потоки (stackfull-корутины) работают прозрачно и для вас, и для библиотеки. В любом safe-point может произойти переключение виртуального потока, автор библиотеки (или вы) вообще ничего не должны для этого специально делать.
Ну во-первых. Будут блокироваться вызовы или нет, зависит от контекста. Вот находитесь Вы в произвольном месте кода и знать не знаете как этот код будет работать, потому как это целиком и полностью зависит от вызывающего - изволил он запустить метод, который запустил метод, который запустил метод... из виртуального потока или платформенного. В отличии от Go, где весь рантайм асинхронный или C# где четко видно по функции синхронная она или нет, в Java смотря на код вообще невозможно сделать никаких предположений о том как он выполниться. Тоже и с ошибками, если кто-то ,на верхнем уровне, создаст случайно не виртуальный поток, то все начнет работать не виртуально и никто этого вообще не заметит.
Во-вторых. То что написано в документации и самое главное, как реализована библиотека - критически важно. Чуда не случиться. Если Вы вызываете библиотеку внутри которой создаются платформенные потоки по старой доброй памяти, или она использует свой пулл не виртуальных потоков или например внутри нее нативные вызовы, которые будут блокировать Ваши потоки, то работа с асинхронностью превратиться в тыкву. Самое неприятное что проблемы могут быть даже не у самой библиотеки а у библиотек которых она использует или библиотек библиотек. Причем самое обидное все это будет неявно. Вообще нет четкой границы, где версия n блокирующая а версия m неблокирующая, можно только или верить документации, которая может врать или путешествовать по кишкам библиотеки и всех ее зависимостей. В отличии от тех же раскрашенных функций, где автор явно выражает это в API.
Да, разумеется, сделать поддержку stackfull корутин намного сложнее, чем stackless. Но мы же не о сложностях реализации? И не про 2012й год. Речь всё-таки про пользователя, и пользователя сегодня.
Ну Вы написали что раскраска функций - зло во плоти, а я считаю что пилить фичу 11 лет, заставляя либо тысячи проектов быть отсталыми и не эффективными или разработчиков подвергать мукам работы с реактивным программированием, только ради того чтобы быть похожими на недо-Go 2012 года - вот что настоящее зло. Есть хорошая фраза - "лучшее враг хорошего". B Java может себе позволять такие фортели только из-за своей мега популярности и огромной значимости для энтерпрайза .
На мой взгляд, раскраска функций (когда нужно явно размечать, поддерживает ли функция асинхронный работу) в котлине и шарпе - зло во плоти. Подход go/java в этом смысле куда более комфортный, особенно в большой кодовой базе.
Думаю все-таки не совсем корректно называть что-то злом во плоти, учитывая что в жизни обычно у каждого подхода есть свои плюсы и минусы, а еще есть контекст.
В Go например планировщик зашит в рантайм а все библиотеки спроектированы с учетом этого. В языке все работает асинхронно. Другой вопрос что возможно это мне не нужно. Go выпущен в 2012 году. Также, там где нужно получить данные из одной горутины в другую, вместо лаконичного await появляется куча бойлерплейта с каналами.
А вот для экосистемы Java это уже не родной подход. Более, того не все выполнение асинхронное а только внутри виртуального потока. Вот я подключил библиотеку и я даже не подключаю она вообще поддерживает асинхронное выполнение или нет. Читал в какой-то статье что бывали случаи что в документации отписывались что библиотека работает асинхронно а на деле в блокировке. Более того, вот вызвал я методы библиотеки, а я точно вызвал это все в виртуальном потоке? Или я перепутал и вызвал в обычном и у меня все блокируеться и я об этом и не подозреваю?
В то время как раскрашенные функции вместе с вербозностью добавляют контроль.
Еще нужно учитывать контекст. Раскрашенные функции несколько проще реализовать чем переписывать рантайм. Как результат, async/await изобрели в 2012 году в C#. И подход перекочевал в такие языки как JS, Python, Swift, Rust, Kotlin, Dart. Виртуальные потоки же появились только в 21 версии Java в конце 2023 года и это учитывая что к этому моменту экосистема была так себе готова. Как итог, 11 лет в C# и чуть меньше в других языках был инструмент работы с асинхронностью, в то время Java была в аутсайдерах, писали тысячи проектов где либо нужно было избегать этой проблемы работая с блокирующими вызовами или страдать с реактивщиной, в то время как у конкурентов уже сто лет в обед все работало асинхронно. Дорога ложка к обеду.
Думаю еще предстоит сравнить в опытной эксплуатации на Java все плюсы и минусы подхода. Microsoft к примеру провели свои исследования и признали развитие в сторону виртуальных потоков нецелесообразным. Поживем, увидим.
А как взвешивать плюсы и минусы - это можно по разному, и сильно от области применения зависит. Для меня например "Быть better-java заменителем" - вполне себе аргумент, если он действительно лучше.
Разумеется. Я скорей имел ввиду - почему Kotlin имеет очень скромный успех на backend в борьбе с Java.
Если у вас сложилось обоснованное, "выстраданное" мнение, как что-то в языке должно быть сделано — скорее всего, в Kotlin это сделано именно так.
Но вот с этим я категорически несогласен. Раньше мне Kotlin очень нравился и казалось что у языка большое будущее. Написал несколько проектов, потом лет на пять забыл. И вот буквально недавно на очередном проекте, судьба опять свела на нем поработать.
Через пару месяцев работы, я посмотрел на Kotlin уже другими глазами, другим опытом и в других условиях. Признаться честно опыт был уже разочаровывающий.
Во-первых. Как бы странно это не звучало, у языка нет внятных причин для существования. Главная идея JB была создать единый язык для решения разноплановых задач: desktop, frontend, mobile, backend. К сожалению, идея не выстрелила и по факту Kotlin нужен только для android разработки. В backend, не удалось как то значимо потеснить Java, более того, Kotlin всецело зависит от JVM и выступает догоняющим по многим ключевым моментом, а то немногое что давало преимущество а именно - корутины, было по факту обесценено с выходом виртуальных потоков. По факту, у языка нет внятного ответа на простой вопрос - зачем он нужен на новом проекте? Быть better-java заменителем, это такой себе аргумент.
Во-вторых. Язык отвратительный с точки зрения дизайна во множестве мест и чересчур переусложнённый. Вы правильно пишете что "В синтаксисе языка явное и заметное предпочтительнее скрытого". Вот только Kotlin пестрит этим тут и там. Для однострочных функций можно не писать тип возвращаемого значение, что находиться за скалярным типов, примитив или ссылка, в Kotlin часто загадка, потому что в отличии от той же Java, в Kotlin такие детали скрывают. Когда мы вызываем функцию над коллекцией, трудно догадаться, она изменит коллекцию или создаст новую. Такими нюансами пронизан весь язык, и если предположим мы можем закрыть глаза на эти проблемы в каком то backend, то для приложений где важна производительность - неявность это геморой, точно также это категорически противопоказано для начинающих. Точно также как куча возможностей сделать одно и тоже.
В-третьих. Непрозрачный interop с Java. Большая часть экосистемы Kotlin - это Java экосистема. Экосистема которая знать не знает и не хочет про фишки вроде null безопасности, про закрытые публичные конструкторы и т.д. А следовательно в безопасном по null языке будет null pointer exception, будет проблемы с сериализацией и прочее прочее прочее, что часто нужно будет обходить костылями и плагинами.
В-четвертых. Непрозрачность. Kotlin - это очень сахарный язык, и практически все в нем реализуется с помощью кодогенерации. Написанная в исходном коде конструкция может иметь совершенно иной вид при генерации байткода. Что само по себе не проблема для опытного, но для начинающего это все сильно усложняет.
Ну нужно начинающему все эти проблемы испытывать. Лучше уж тогда Java или C#. Первая - значительно проще и прозрачнее, второй - сильно сложнее но с огромным количеством плюшек и возможностью писать в дальнейшем вообще практически все что угодно. Если есть желание учиться сразу и по серьезному то однозначно Си.
Но то что вы их приводите, желая подтвердить противоположную точку зрения, говорит о разнице в восприятии у, как минимум, нас с вами.
Я не желаю подтвердить противоположную точку зрения, для меня все примеры - одно и тоже. Я оспариваю тезис о том что у Python чудо-синтаксис и благодаря этому он популярен.
func train(model Model) {
for _, item := range model.data {
model.learn(item)
}
}
или даже Kotlin:
fun train(model: Model) {
for (item in model.data) {
model.learn(item)
}
}
Может быть уже хватит тиражировать сказки про простоту и читабельность Python из 90-тых, когда это действительно было так на фоне других языков? Давно уже наштамповали новые языки и прокачали старые и сам Python уже давно не такой простой и читабельный как раньше.
Благодаря этому команды тратят меньше времени на разбор логики и больше на улучшение функциональности. Ошибки выявляются быстрее. Ревью проходят более гладко. А иногда даже люди без опыта программирования могут понять Python‑скрипты без посторонней помощи.
Можно задать себе интересный вопрос, почему если есть такой чудо-синтаксис, который буквально хорош во всем, подавляющее большинство мейнстримных языков как были так и есть сиподобные?
Добавьте к этому поддержку Python нескольких парадигм программирования (процедурное, объектно‑ориентированное и функциональное), и становится понятно, почему он так популярен, правда?
Нет не становиться. Практически все самые популярные яп сейчас мультипарадигменные, Python здесь вообще ничем не выделяется.
Python популярен потому что низкий порог входа, потому что искусственный интеллект и машинное обучение на нем практически монополизировано а оно сейчас нужно и важно везде, плюс огромная экосистема.
Процедурное мышление чем-то напоминает подход code first при проектировании API.
Мышление объектами напоминает подход contract first при проектировании API.
Звучит как: Cамокатное мышление - это езда куда попало, без какой либо ответственности и целей. Велосипедное мышление - это езда с большим философским подтекстом, с подготовкой, ответственностью и решимостью.
Хотя вроде бы наверное, первое это не более чем езда на самокате а второе на велосипеде. Тоже самое с Вашими определениями. Не очень понял как Вы туда приклеили разницу в проектировании и contract first.
Я пришёл к мышлению объектами (сущностями, если быть более точным), когда стал изучать функциональное программирование. По началу, мне оно показалось полным бредом, пока я не начал сквозь боль и неприятие учиться этим пользоваться.
Честно говоря, не очень понятно как Вы пришли к мышлению объектами через функциональное программирование.
Если программист тяготеет к процедурному мышлению. То он вполне естественно испытывает диссонанс, увидев метод из одной строчки кода, т.к. в его категории мышления - группировка кода из одного метода лишена здравого смысла.
Если программист тяготеет к здравому смыслу, то у него возникнет естественный вопрос - если для решения элементарной задачи которая реализуется одной функцией нужно городить городьбу из объектов и их связей, можно ли такой подход считать разумным или это написание кода ради написания кода?
Физически не может или юридически или не может потому что не может быть никогда?
Вуаля. ООП как раз и предлагает модульность. На уровне классов.
Модульность была и есть и без ООП. Что предлагает ООП уникального, связывать данные и методы работы с ними? А часто нам такое нужно? Как показывает практика нет. Признаю, для небольших машин состояний удобно. Как уже писал, умные объекты давно вышли из моды. Что нам еще ООП уникального предложит и полезного?
Базы данных мы тоже сами себе придумали.
Базы данных хранят данные. ORM выполняет работу по перекладыванию данных потому что мы решили что так идеологически правильно.
Это как вообще?
Вы рассуждаете в контексте инструментов а не проблем. Когда Вы говорите что многие как и Вы считают что ООП удобнее и что ORM удобнее Вы забываете упомянуть для чего. Допустим у нас система отчеты строит и статистику собирает, путем выполнения сложных запросов, нам точно нужна ORM и точно нужно придумать объекты реального мира для этой задачи или мы просто можем получить данные и передать их? Или вот у вас высоконагруженная система и очень бы хотелось чтобы она работала быстро но вот незадача, в нашей экосистеме приходиться выбирать: или синхронный ORM или асинхронный доступ без ORM. Вы предпочтете удобство производительности или все-таки исходя из задачи переступите через себя и выберете подходящий инструмент?
Тысячи круд ресурсов в системе не связанных между собой? Это не сложная, а просто объемная система. Даже сложно представить, для чего она может понадобиться?
Просто абстрактный пример для демонстрации что размер не синоним слову сложность
Проблема большого проекта - в том, что он большой. Его тупо трудно удержать в голове и всё сложнее править.
Нет, сам по себе размер это не проблема. У вас может быть backend в котором тысяча ресурсов и все операции для них crud. Никаких проблем и даже надобности все это в голове держать нет. Другое дело сложный и запутанный проект может быть и небольшим но очень проблемным.
Решений проблемы сложных проектов масса, все они в основном сводятся к правильной модульности. ООП не является волшебной таблеткой от этой проблемы, более того, за несколько десятилетий повсеместного доминирования ООП, у нас так и не появилось хорошего массового способа строить приложения. Этим и объясняется тенденция массового сдвига в сторону ФП везде - ООП не дало тех результатов которые люди ожидали. С этим фактом поспорить сложно я думаю.
Не костыль, а инструмент. Для связывания, да.
Инструмент для решения проблемы которую мы сами себе и придумали.
Очень много разрабов считают, что в ООП работать проще, чем с плоскими данными. И я к ним тоже отношусь. И если вы предпочитаете кидаться чистым sql и выгребать каждый раз свой набор полей, то у меня в ORM синтаксис намного короче и я оперирую объектами, а не полями, что уже на одну абстракцию выше. Кроме того, у меня есть возможность одним кликом узнать, в каких частях проекта используется вот это поле.
Звучит как концентрация на решении вместо проблемы.
А давайте нормально разговаривать? Без обвинений в недальновидности
Я Вас ни в чем не обвиняю а указал на то что странно когда преимущество парадигмы в том что они служит базой для подходов на ее основе а не в том что она решает конкретные проблемы.
Если по уму то никого. Есть профессия инженер а есть программист. В большинстве своем, названия типо software engineer и прочее - это странные понты некоторых компаний, которые хотят поставить себя выше остальных, потому что у них не какие то никчемные программисты работают а целые software engineers.
Но если бы ко мне пристали с задачей - "нет ну ты все-таки придумай, хотя бы субъективно, как разделить программистов и инженеров", то я бы наверное поделил так: инженеры, пусть это будут разработчики ОС, драфверов, компиляторов, виртуальных машин, игровых движков, железячники т.д., т.е. специалисты, для работы которым нужны фундаментальные знания, часто научный подход, люди которые строят базу для всех остальных, а вот все остальные - это программисты, по сути пользователи того что сделали инженеры. Наверное так.
Интересно наблюдать, в какое еще говно мокнут и обесценят некогда почетное слово инженер.
Сначала, формошлеперы и json-перекладчики провозгласили что все, они теперь не какие то там веб программисты а целые инженеры. Теперь вот докатились что уже вайбкодеры на себе примеряют.
Правильно, сейчас не модно как раньше расти чтобы соответствовать, сейчас проще обесценить термин и натянуть его на себя.
Тогда, во многом солидарен.
Мне вообще нравиться отчасти перекликающийся подход в Rust в этом плане.
Где трейты, очень похожи внешне на интерфейсы но являются не контрактами а по сути ограничителями для дженериков, и по больше части используются для ограничения параметров функций.
Вы показали примеры где интерфейс используется для сокрытия реальной зависимости и как абстрактное возвращаемое значение, но самое интересное обошли стороной - интерфейс как параметр функции. Хотелось бы услышать Ваше мнение по этому поводу.
Ну, во первых, я специально не привожу это как аргумент из-за субъективной его природы. Но тем не менее, полностью не учитывать связь между творчеством и творцом - нельзя.
То что он разжёваны и то что их вообще нужно толковать - это и есть проблема, у нас вроде бы не теология а программирование. Если у принципа нет однозначной интерпретации то пойдут толкования, различные взгляды и направления. Кто будет определять кто из толкователей самый правильный и какая трактовка самая верная? И мы приходим к тому с чего начали: на МР два разработчика будут спорить каждый со своей колокольни, потому что правильного ответа нет как и методики. Если же ссылается к толкованиям от авторитетов то мы превратиться в подобие религии а должны хоть как то походить на науку.
Когда строят здание то руководствуются не абстрактными общими принципами а конкретными обоснованными с точки зрения науки и практики нормами.
Проблема в том что такое прокатывает в гуманитарных дисциплинах, когда судья руководствуется внутренним чувством справедливости, к примеру, в отдельных аспекта. И такое абсолютно не применимо в технических.
В том и проблема, что даже между участниками одной команды не будет понимания, потому что эти самые принципы не дают никакой конкретики, они просто хорошо и красиво звучат. А прицип, который для каждого звучит по разному имеет низкую практическую ценность.
Ну тут Вы явно преувеличиваете. Я ни разу не видел что кто-то предлагал выкинуть вообще все. Чаще, одно радикально поперек другого. И оно не удивительно. К примеру, тот же ООП, который захватил огромную часть IT на несколько десятилетий, практически выдавив любое инакомыслие. Чистый код, SOLID и паттерны проектирования, про которые можно было послушать из каждого утюга. Все это в том числе, дичайшим образом догматизировало огромную часть сообщества и остановило в развитии. Огромное число людей стали не искать решение проблем а то как пользоваться инструментом. Ожидаемо было, что после многих лет в таком режиме, оно бомбанет и многие люди, разочаровавшись в старых инструментах, подходах и авторах, пойдут искать радикально другие подходы. И это хорошо, т.к. маятник будет ходить туда сюда балансируя и выверяя эти самые инструменты и подходы. Намного лучше, чем застрять в развитии, заменив прагматизм на веру.
Понимаете, вопрос ни в том какой у кого мнение. Можно было бы сказать что Роберт Мартин и ко, никакие не светилы с олимпа создавшие грандиозные проекты а скорей успешные писатели. Что если посмотреть его проекты то он давно не следует своим же принципам. Что в своем блоге он писал что когда придумывал SOLID не очень понимал принцип подстановки Лисков. Что принципы формировались так чтобы получилось красивое слово а не по соображениям важности. Но я не будет приводить это как аргументы так как это в некоторой мере субъективно. Я приведу объективный аргумент.
На мой взгляд, в каких либо принципах, главное - это точки их приложения а не красивая идея на фоне. И вот здесь главная проблема. Возьмем SRP, вроде бы и звучит красиво и как будто бы о правильном - "хорошо делай - хорошо будет", но говорит ли нам этот принцип о том как делать хорошо или хотя бы о том что такое ответственность, как это все посчитать или распределить? Нет? Возьмите двух разработчиков дайте им одну и ту же задачу и попросите использовать SRP. С огромной долей вероятности Вы получите разные решения, потому что каждый будет интерпретировать SRP по своему.
Выкатил Петя МР, а ему Дима говорит: ты тут нарушаешь SRP, после чего начинается срачь, т.к у каждого свое видение. Потому как SRP не описываем хоть как то детерминированный механизм реализации собственного постулата а получается тотальная субъективщина. Толку от такого принципа, как от совета прохожего: "живите правильно и все у вас будет". Тоже самое с ISP и т.д. Принцип LSP наиболее адекватный и детерминированный но самый редко применимый, да и к примеру, если посмотреть на стандартную библиотеку Java, то там раз через раз он нарушается (видимо разработчики языка программирования забыли сходить к Мартину).
В общем говоря, принципы SOLID по большей части это красивые советы (возможно даже где-то правильные) без определений их приложения (и соответственно большого практического смысла), которые появились потому что пару человек, которые ни разу не гении в IT, по приколу их собрали исходя из своих субъективных взглядов и понятий красоты, при этом вся заслуга популярности принципов это популярность их автора а не ценность или важность для сферы. Не нужно делать из попсы религию.
Завирусившимся можно назвать тренд на возврат к критическому мышлений, когда мы должны во всем сомневаться, переосмысливать, критиковать и требовать доказательств в противовес догматическому мышлению когда миллионы людей поклоняются тому что какой-нибудь дяденька написал в книжке.
Для меня загадка как Вы это видите в YAGNI но в упор не замечаете что SOLID - ровно тоже самое. При этом считаете что сообщество языка, авторы которого активно продвигали философию простоты во всем, обязано наперекор принципам языка, тащить туда неповоротливые чистые архитектуры, с которыми уже и так намучались в других языках.
Наверное - это перестать делать вид что какой-нибудь SOLID - это действительно что-то умное и важное посланное нам
полу-богамивеличайшими светилами IT а не абстрактный, завирусившийся набор практически бесполезных советов в духе "хорошо делай - хорошо будет", придуманных из буков собранных по принципу как красивее в слово собрать, дяденьками которым банально было нечем заняться.Нет. На уровне кода. В любом месте можно задать контекст выполнения.
Всю 30 летнюю экосистему Java взяли и по быстрому переписали? Оптимистично.
Есть разница между тем что автор библиотеки написал async но не реализовал, потому что он дурак и тем когда автор ничего не писал и не гарантировал.
Так Вы и рассуждайте сегодня. А сегодня есть go и java а подавляющее большинство остальных языков раскрашивают функции. Что вы предлагаете, переделать им на виртуальные потоки все? Если нет, то что по Вашему "зло во плоти" то, инструмент который позволил сэкономить 11 лет? Понимаете, если бы Java сейчас выкатила что-то невероятное, инновационное, меняющее подходы кардинальным образом то это еще ладно, но по факту но они просто догнали конкурентов. Поэтому я не понимаю идею про "зло во плоти", есть работающий много лет инструмент а есть может быть чуть более удобное решение(время покажет) которое запоздало на десяток лет. Async/await явно прорывное для своего времени решение которое позволило многим языкам и экосистемам работать удобно и эффективно, в то время как другие десять лет изобретали, так что я бы не стал это называть "зло во плоти" точно.
Ну во-первых. Будут блокироваться вызовы или нет, зависит от контекста. Вот находитесь Вы в произвольном месте кода и знать не знаете как этот код будет работать, потому как это целиком и полностью зависит от вызывающего - изволил он запустить метод, который запустил метод, который запустил метод... из виртуального потока или платформенного. В отличии от Go, где весь рантайм асинхронный или C# где четко видно по функции синхронная она или нет, в Java смотря на код вообще невозможно сделать никаких предположений о том как он выполниться. Тоже и с ошибками, если кто-то ,на верхнем уровне, создаст случайно не виртуальный поток, то все начнет работать не виртуально и никто этого вообще не заметит.
Во-вторых. То что написано в документации и самое главное, как реализована библиотека - критически важно. Чуда не случиться. Если Вы вызываете библиотеку внутри которой создаются платформенные потоки по старой доброй памяти, или она использует свой пулл не виртуальных потоков или например внутри нее нативные вызовы, которые будут блокировать Ваши потоки, то работа с асинхронностью превратиться в тыкву. Самое неприятное что проблемы могут быть даже не у самой библиотеки а у библиотек которых она использует или библиотек библиотек. Причем самое обидное все это будет неявно. Вообще нет четкой границы, где версия n блокирующая а версия m неблокирующая, можно только или верить документации, которая может врать или путешествовать по кишкам библиотеки и всех ее зависимостей. В отличии от тех же раскрашенных функций, где автор явно выражает это в API.
Ну Вы написали что раскраска функций - зло во плоти, а я считаю что пилить фичу 11 лет, заставляя либо тысячи проектов быть отсталыми и не эффективными или разработчиков подвергать мукам работы с реактивным программированием, только ради того чтобы быть похожими на недо-Go 2012 года - вот что настоящее зло. Есть хорошая фраза - "лучшее враг хорошего". B Java может себе позволять такие фортели только из-за своей мега популярности и огромной значимости для энтерпрайза .
Думаю все-таки не совсем корректно называть что-то злом во плоти, учитывая что в жизни обычно у каждого подхода есть свои плюсы и минусы, а еще есть контекст.
В Go например планировщик зашит в рантайм а все библиотеки спроектированы с учетом этого. В языке все работает асинхронно. Другой вопрос что возможно это мне не нужно. Go выпущен в 2012 году. Также, там где нужно получить данные из одной горутины в другую, вместо лаконичного await появляется куча бойлерплейта с каналами.
А вот для экосистемы Java это уже не родной подход. Более, того не все выполнение асинхронное а только внутри виртуального потока. Вот я подключил библиотеку и я даже не подключаю она вообще поддерживает асинхронное выполнение или нет. Читал в какой-то статье что бывали случаи что в документации отписывались что библиотека работает асинхронно а на деле в блокировке. Более того, вот вызвал я методы библиотеки, а я точно вызвал это все в виртуальном потоке? Или я перепутал и вызвал в обычном и у меня все блокируеться и я об этом и не подозреваю?
В то время как раскрашенные функции вместе с вербозностью добавляют контроль.
Еще нужно учитывать контекст. Раскрашенные функции несколько проще реализовать чем переписывать рантайм. Как результат, async/await изобрели в 2012 году в C#. И подход перекочевал в такие языки как JS, Python, Swift, Rust, Kotlin, Dart. Виртуальные потоки же появились только в 21 версии Java в конце 2023 года и это учитывая что к этому моменту экосистема была так себе готова. Как итог, 11 лет в C# и чуть меньше в других языках был инструмент работы с асинхронностью, в то время Java была в аутсайдерах, писали тысячи проектов где либо нужно было избегать этой проблемы работая с блокирующими вызовами или страдать с реактивщиной, в то время как у конкурентов уже сто лет в обед все работало асинхронно. Дорога ложка к обеду.
Думаю еще предстоит сравнить в опытной эксплуатации на Java все плюсы и минусы подхода. Microsoft к примеру провели свои исследования и признали развитие в сторону виртуальных потоков нецелесообразным. Поживем, увидим.
Разумеется. Я скорей имел ввиду - почему Kotlin имеет очень скромный успех на backend в борьбе с Java.
По поводу Python и аргументов согласен.
Но вот с этим я категорически несогласен. Раньше мне Kotlin очень нравился и казалось что у языка большое будущее. Написал несколько проектов, потом лет на пять забыл. И вот буквально недавно на очередном проекте, судьба опять свела на нем поработать.
Через пару месяцев работы, я посмотрел на Kotlin уже другими глазами, другим опытом и в других условиях. Признаться честно опыт был уже разочаровывающий.
Во-первых. Как бы странно это не звучало, у языка нет внятных причин для существования. Главная идея JB была создать единый язык для решения разноплановых задач: desktop, frontend, mobile, backend. К сожалению, идея не выстрелила и по факту Kotlin нужен только для android разработки. В backend, не удалось как то значимо потеснить Java, более того, Kotlin всецело зависит от JVM и выступает догоняющим по многим ключевым моментом, а то немногое что давало преимущество а именно - корутины, было по факту обесценено с выходом виртуальных потоков. По факту, у языка нет внятного ответа на простой вопрос - зачем он нужен на новом проекте? Быть better-java заменителем, это такой себе аргумент.
Во-вторых. Язык отвратительный с точки зрения дизайна во множестве мест и чересчур переусложнённый. Вы правильно пишете что "В синтаксисе языка явное и заметное предпочтительнее скрытого". Вот только Kotlin пестрит этим тут и там. Для однострочных функций можно не писать тип возвращаемого значение, что находиться за скалярным типов, примитив или ссылка, в Kotlin часто загадка, потому что в отличии от той же Java, в Kotlin такие детали скрывают. Когда мы вызываем функцию над коллекцией, трудно догадаться, она изменит коллекцию или создаст новую. Такими нюансами пронизан весь язык, и если предположим мы можем закрыть глаза на эти проблемы в каком то backend, то для приложений где важна производительность - неявность это геморой, точно также это категорически противопоказано для начинающих. Точно также как куча возможностей сделать одно и тоже.
В-третьих. Непрозрачный interop с Java. Большая часть экосистемы Kotlin - это Java экосистема. Экосистема которая знать не знает и не хочет про фишки вроде null безопасности, про закрытые публичные конструкторы и т.д. А следовательно в безопасном по null языке будет null pointer exception, будет проблемы с сериализацией и прочее прочее прочее, что часто нужно будет обходить костылями и плагинами.
В-четвертых. Непрозрачность. Kotlin - это очень сахарный язык, и практически все в нем реализуется с помощью кодогенерации. Написанная в исходном коде конструкция может иметь совершенно иной вид при генерации байткода. Что само по себе не проблема для опытного, но для начинающего это все сильно усложняет.
Ну нужно начинающему все эти проблемы испытывать. Лучше уж тогда Java или C#. Первая - значительно проще и прозрачнее, второй - сильно сложнее но с огромным количеством плюшек и возможностью писать в дальнейшем вообще практически все что угодно.
Если есть желание учиться сразу и по серьезному то однозначно Си.
Я не желаю подтвердить противоположную точку зрения, для меня все примеры - одно и тоже. Я оспариваю тезис о том что у Python чудо-синтаксис и благодаря этому он популярен.
Удивительно читабельный, не то что C#:
Go:
или даже Kotlin:
Может быть уже хватит тиражировать сказки про простоту и читабельность Python из 90-тых, когда это действительно было так на фоне других языков? Давно уже наштамповали новые языки и прокачали старые и сам Python уже давно не такой простой и читабельный как раньше.
Можно задать себе интересный вопрос, почему если есть такой чудо-синтаксис, который буквально хорош во всем, подавляющее большинство мейнстримных языков как были так и есть сиподобные?
Нет не становиться. Практически все самые популярные яп сейчас мультипарадигменные, Python здесь вообще ничем не выделяется.
Python популярен потому что низкий порог входа, потому что искусственный интеллект и машинное обучение на нем практически монополизировано а оно сейчас нужно и важно везде, плюс огромная экосистема.
Звучит как:
Cамокатное мышление - это езда куда попало, без какой либо ответственности и целей.
Велосипедное мышление - это езда с большим философским подтекстом, с подготовкой, ответственностью и решимостью.
Хотя вроде бы наверное, первое это не более чем езда на самокате а второе на велосипеде. Тоже самое с Вашими определениями. Не очень понял как Вы туда приклеили разницу в проектировании и contract first.
Честно говоря, не очень понятно как Вы пришли к мышлению объектами через функциональное программирование.
Если программист тяготеет к здравому смыслу, то у него возникнет естественный вопрос - если для решения элементарной задачи которая реализуется одной функцией нужно городить городьбу из объектов и их связей, можно ли такой подход считать разумным или это написание кода ради написания кода?
Физически не может или юридически или не может потому что не может быть никогда?
Модульность была и есть и без ООП. Что предлагает ООП уникального, связывать данные и методы работы с ними? А часто нам такое нужно? Как показывает практика нет. Признаю, для небольших машин состояний удобно. Как уже писал, умные объекты давно вышли из моды.
Что нам еще ООП уникального предложит и полезного?
Базы данных хранят данные. ORM выполняет работу по перекладыванию данных потому что мы решили что так идеологически правильно.
Вы рассуждаете в контексте инструментов а не проблем. Когда Вы говорите что многие как и Вы считают что ООП удобнее и что ORM удобнее Вы забываете упомянуть для чего. Допустим у нас система отчеты строит и статистику собирает, путем выполнения сложных запросов, нам точно нужна ORM и точно нужно придумать объекты реального мира для этой задачи или мы просто можем получить данные и передать их? Или вот у вас высоконагруженная система и очень бы хотелось чтобы она работала быстро но вот незадача, в нашей экосистеме приходиться выбирать: или синхронный ORM или асинхронный доступ без ORM. Вы предпочтете удобство производительности или все-таки исходя из задачи переступите через себя и выберете подходящий инструмент?
Просто абстрактный пример для демонстрации что размер не синоним слову сложность
Нет, сам по себе размер это не проблема. У вас может быть backend в котором тысяча ресурсов и все операции для них crud. Никаких проблем и даже надобности все это в голове держать нет. Другое дело сложный и запутанный проект может быть и небольшим но очень проблемным.
Решений проблемы сложных проектов масса, все они в основном сводятся к правильной модульности. ООП не является волшебной таблеткой от этой проблемы, более того, за несколько десятилетий повсеместного доминирования ООП, у нас так и не появилось хорошего массового способа строить приложения. Этим и объясняется тенденция массового сдвига в сторону ФП везде - ООП не дало тех результатов которые люди ожидали. С этим фактом поспорить сложно я думаю.
Инструмент для решения проблемы которую мы сами себе и придумали.
Звучит как концентрация на решении вместо проблемы.
Я Вас ни в чем не обвиняю а указал на то что странно когда преимущество парадигмы в том что они служит базой для подходов на ее основе а не в том что она решает конкретные проблемы.