По рекламе ооп: ооп поднялось сперва благодаря хайпонувшему C with classes (далее С++), позднее на массовой рекламе Java, и db-oriented подхода на заре века. Это позволило захватить нишу ращработки для enterprise
И? В энерпрайз идёт только то, что реально полезно, что позволяет сэкономить ресурсы (человекочасы в данном случае). И ООП отлично с этой задачей справляется. Вот уже 50 лет как. А всякая модная .уита (как например когда-то очень хайповый язык Elixir, да и Ruby в ту же копилку) вначале выстреливает, а потом благополучно забывается. Бизнес использует только то, что реально полезно и приносит деньги. Если ФП никаких таких значимых ниш до сих пор не захватил, особенно в России, где обожают использовать только всё самое модное и современное в айти, то это говорит лишь о том, что функциональная парадигма -- раздутая хайповая пустышка и не более того.
@@MasterLid на ФП пишется банковский софт, инвест платформы, компиляторы. Тейк про 50 лет довольно забавен, потому что такой срок жизни разве что smallTalk' у можно приписать. И главным игроком на Энтерпрайз рынке он к тому моменту точно не был. Рынок на тот момент делили, помимо него, Fortran, lisp1 (преимущественно малый бизнес и science), algol и его величество COBOL. Последний является офигительной иллюстрацией того, как Энтерпрайз выбирает только то, что реально полезно (а потом весело и долго пытается выпилить, то, что навыбирал)
@@MasterLid понял, бизнес использует не расхайпленную хуйню а только то, что полезно и позволяет сэкономить человекочасы. Например COBOL. ФП языки расхайпленная хуита и ни где себе ниши не нашли: ни в банковском софте, ни в разработке компиляторов, ни block chain контрактах...
Ну, факт-то остаётся фактом: у ООП коммьюнити намного больше, чем у ФП. Причём у ООП коммьюнити абсолютно адекватное и позитивно настроенное. Чего не скажешь о секте поклонников ФП. 😁 Всех вам благ!
Ахахахаха концовочка прям посмешила, про абстракции и фантазии😁 ну человек явно закончил какие то курсы, послушал умных словечек и пришел написать такой яркий комментарий, ведь на самом деле он писатель и получает удовлетворение от своих метафор и абстракций😁
Добрый день, благодарю за видео. Согласен про низкое качество кода вне зависимости от языка, именно это с моей точки зрения является основной проблемой в решении бизнес задач. Я занимаюсь версткой довольно долго и последнее время вижу что мне этого мало. Некоторые фронтенд задачи начал делать с помощью фреймворков или на чистом js, понял что мне это интереснее. Да, я стал зарабатывать на этом деньги больше чем просто верстальщик, но при это понимаю, что я тот же говнокодер). Буду благодарен за совет как правильно стоит освоить новую профессию (возможно вы посоветуете курсы или книги для самостоятельного изучения). Скорее тут для меня не так важно какой язык (склоняюсь к javascript) или фреймворк изучать, как важно само понимание как правильно строить архитектуру приложений.
Привет. Курсы никакие советовать не буду, потому что не в теме. В основном слышу только негатив по отзывам. А если интересует фронтенд, то рекомендовал бы смотреть в сторону TypeScript и Vue.
Если кому интересно, что это за кейс, с которым React по умолчанию справился бы лучше, чем Angular... Это таблица с биржевыми индексами, обновляемыми в real-time. Каждая ячейка представляла собой ангуляровский компонент, который норовил перерисоваться гораздо чаще, чем происходило реальное изменение котировок. В итоге сделали detach и обновляли ячейки вручную, плюс вынесли всю общую для ячеек информацию в статические свойства и методы. Я понимаю, что тут можно искусственно придумать десяток-другой похожих задач, где ангуляр без дополнительных настроек будет сливать реакту, но в действительности это был всего лишь единичный случай. Все остальные потенциально проблемные места подчищались и подчищаются грамотным UI/UX.
Я не проф. разраб. Идею ООП знал еще 20 лет назад, но не погружался. Тут недавно окунулся, поднял несколько достаточно больших (для одного новичка) проектов на C#. По мере погружения в ООП, первоначальное очарование идеи - чуть ли не прямой трансляции объектов реального мира в архитектуру кода, сменялось недоумением от бесконечно нарастающей сложности конструкций и концепций. Паттерны, типа сиглтона. Нет ну серьезно, надо городить что-то ради единственности порождения? В голове начинает крутиться один вопрос - неужели по-другому никак нельзя? Все это выглядит, как бесконечные костыли, к неправильно поставленной и решаемой задаче. ФП сложнее, и в голову заходит тяжелее. Но идея иммутабельности выглядит концептуально верной, по сравнению с императивной парадигмой, основанной не бесчисленном количество переменных. Лично мне кажется, в ФП - это парадигма будущего, и в итоге к ней и придут. В общем, перехожу на F#, который, кстати, по сути обертка над C#. Учу и удивляюсь, "а что, так можно было?"
Смысл ООП не в том, чтобы использовать все существующие паттерны, а в том, чтобы использовать только то, что нужно. Т.е. если в вашем приложении не нужен синглтон, то вы его не используете. Далее, всё зависит от уровня абстракции. Например, абстракцию двигателя внутреннего сгорания можно описать в виде всего 4 тактов: впуск-сжатие-раб.ход-выпуск, а можно расписать всё до цилиндров, поршней и вплоть до винтиков. Естественно, второй вариант сложнее. Всё зависит от вашей задачи, если ДВС в виде четырех тактов ей достаточен, то совершенно не обязательно углубляться в подробности. Ну и по F#. Ради интереса, посмотрите на хаха.ру вакансии по этому языку. Уверен, что их не так много. Во всяком случае, намного меньше, чем вакансий на C#.
@@MasterLid Я не про использование паттернов везде. Например, вы решаете задачку по математике 7 класса - и получаете уравнение, решать которое надо через поиск экстремумов, пределы, производные - это вам сразу должно подсказать, что подход к решению выбран неправильный (если ошибку исключаем). Вот так и с ООП, слишком уж много наворотов на ровном месте, делающих код непролазной мутью. Паттерны просто лучше всего это иллюстрируют. Но есть и масса других примеров - тема связанная с потокобезопасностью. Все эти пробрасывания, залочивания и прочее. Это всё сильно пахнет плохой концептуальной архитектурой языка, да и выглядит лишним. Вспоминается еще такой пример. Язык Cobol. Его создавали с идеей, что пусть там будут большие и громоздкие стейтменты, зато будет читаться как обычный текст на английском, и типа даже не программист сможет понять, что там написано. Появление и дальнейшее движение в сторону С - напрочь перечеркнуло этот подход. С ООП мне видится тоже самое. В основе идея отражать в коде объекты реального мира с похожим поведением. Идея классная, но, кмк, избыточно трудоемкая и сложная в реализации. Думаю она отомрет, как и Cobol когда-то. Насчет вакансий - я не зарабатываю этим, поэтому мне не критично. Но слышал платят ФП-шникам больше. ФП учу по сути просто, для расширения сознания и надеюсь в последствии писать код быстрее и с большим удовольствием ))
Всё, что вы пишете про ООП, прекрасно описывается фразой "просто вы не умеете это готовить". В ООП в принципе не должно получаться кода в виде непролазной мути. Если у вас получается непролазная муть, то вы что-то делаете не так. : )
@@MasterLid Когда у вас объект класса наследуется от 2-3 абстрактов, еще от 3-4 интерфейсов, на вход принимает 8-10 других объектов классов, еще свою какую-то логику реализует и сам еще какими-то объектами оперирует - вот это я уже мутью называю - чтобы понять как работает небольшой кусочек кода, мне надо пол кодовой базы перелапатить, для меня это перебор как-то, а в реальным библиотеках и больших проектах - норма жизни.
Так не делайте такую громоздкую конструкцию! Вы что-то наговнокодили (ну или прочитали в книжке какого-то говнокодера -- понятия не имею, откуда вы взяли подобную архитектуру), но претензии предъявляете ООП. Вообще лень вас в чем-то убеждать. Нравится ФП -- программируйте в ФП.
На мой взгляд в видео не совсем корректное сравнение реакта и ангуляра. Ангуляр это фреймворк, который предоставляет уже готовые решения, а реакт - библиотека, в которой у разработчика больше свободы в выборе архитектурных подходов и либ(хотя бОльшая часть приложений это cвязка React + Redux). Этим и обусловлена необходимость тратить больше времени на разработку каких-то фич. Плюс разработчик знающий реакт может без особых проблем писать мобильные приложения на нейтиве. Из-за такой гибкости и зп у реакт разрабов выше
Какие готовые решения предоставляет ангуляр? Встроенный роутер? Ngrx? Не спорю, ангуляр гораздо более богатый возможностями фреймворк, чем реакт. Но суть не в этом. Ангуляр -- типично ООП-ориентированный фреймворк (контроллер -- это класс, сервис -- это класс, директива -- это класс и т.д.), в нём очень широко применяются наследование, инкапсуляция, интерфейсы и тому подобное. Реакт -- абсолютно функциональный фреймворк (хотя раньше там можно было использовать парадигму, что контроллер -- это класс, но потом от неё отказались, и теперь всё на функциях). Поэтому в видео я и использовал эти два фреймворка, чтобы было нагляднее. Про з/п у программистов реакта -- тут-то всё понятно. Ковыряться и создавать спагетти-код, который получается на реакте (т.е. JSX/TSX), то ещё удовольствие. Конечно, работа с этим г0вн0м должна оплачиваться выше, иначе желающих будет не так чтобы сильно много.
Реакт отвечает только за рендеринг. Он не нуждается в роутере, стейт менеджере и т.п. из коробки, так как он просто либа. Уже потом, на его основе, делаются фреймворки типа некста и нейтива, которые предоставляют свои решения. Оба эти фреймворка норм, но реакт более гибкий, а ангуляр более надёжный(хотя всё зависит от того, кто пишет код). Что касается функциональщины в реакте, то причина достаточно проста, а именно перфоманс у функциональных компонентов выше чем у классов. Менее трудозатратно просто вызвать функцию, чем наследоваться от класса. Хотя есть жизненные методы в реакте, которые доступны только в классовых компонентах. Спагетти код в jsx это как? Не думаю что за работу с реактом доплачивают
Как фронтенд с опытом разработки коммерческих продуктов на всех трёх фреймворках, могу сказать, что разработка на реакт -- это одно из немногих занятий, к которым мне едва ли когда-нибудь захочется вернуться. Не хочу зарекаться, но, наверное, ни за какие деньги не стал бы снова влезать в эту тему. Надеюсь, на ваш первоначальный вопрос я ответил. : )
Мне кажется ООП избыточен в о фронт приложениях! Ну все приводят примеры с машинами робатами и тп! Ну и много ли задачь где это надо во фронте с этим наследыванием? Ну если надо можно и класс написать не кто не против ну по мне так кажется что избычточность сорее вредна! А если не использовать наследование и просто писать через классы тт в чем преимущество?
За фронт-энд сказать однозначно не могу, не особо вникал, но на десктопе для построения UI есть 2 пути: ООП с базовым классом Widget/Control/etc и плохой. Полагаю, что интерфейс в браузере не очень сильно отличается от десктопа архитектурно.
Три главных слова ООП и правда не требуют ни классов ни даже объектов // инкапсуляиция const Counter = () => { // n инкапсулировано let n = 0 return () => n++ } const c = Counter() console.log(c(), c(), c()) // 1 2 3 // полиморфизм const Sum = (a, b) => a + b const Mult = (a, b) => a * b const ops = [Sum, Mult] // интерфейс один, аргументы одни и те же, а поведение разное console.log(...ops.map(f => f(2, 3))) // 5 6 // наследование const Super = (b, f) => () => f(b) const Foo = () => console.log("foo") const SuperFoo = Super(Foo, (base) => { base() console.log("bar") }) SuperFoo() // foo // bar
Даже то, что было предложено в ООП на PHP ранних версий гораздо лучше и логичнее, чем сборная солянка, которую предложил Одерски в Scala. Кстати, где она? 😁 Та же история: хайпанули, поговорили и забыли.
![เปิดใจ "อาจารย์เบียร์ คนตื่นธรรม" อดีตเคยสุดทุกทาง ถ้าใช้หนี้หมดไปบวชแน่ l [Nickynachat]](http://i.ytimg.com/vi/IxeE0xVhy08/mqdefault.jpg)
По рекламе ооп: ооп поднялось сперва благодаря хайпонувшему C with classes (далее С++), позднее на массовой рекламе Java, и db-oriented подхода на заре века. Это позволило захватить нишу ращработки для enterprise
И?
В энерпрайз идёт только то, что реально полезно, что позволяет сэкономить ресурсы (человекочасы в данном случае). И ООП отлично с этой задачей справляется. Вот уже 50 лет как. А всякая модная .уита (как например когда-то очень хайповый язык Elixir, да и Ruby в ту же копилку) вначале выстреливает, а потом благополучно забывается.
Бизнес использует только то, что реально полезно и приносит деньги. Если ФП никаких таких значимых ниш до сих пор не захватил, особенно в России, где обожают использовать только всё самое модное и современное в айти, то это говорит лишь о том, что функциональная парадигма -- раздутая хайповая пустышка и не более того.
@@MasterLid на ФП пишется банковский софт, инвест платформы, компиляторы.
Тейк про 50 лет довольно забавен, потому что такой срок жизни разве что smallTalk' у можно приписать. И главным игроком на Энтерпрайз рынке он к тому моменту точно не был. Рынок на тот момент делили, помимо него, Fortran, lisp1 (преимущественно малый бизнес и science), algol и его величество COBOL. Последний является офигительной иллюстрацией того, как Энтерпрайз выбирает только то, что реально полезно (а потом весело и долго пытается выпилить, то, что навыбирал)
@@MasterLid понял, бизнес использует не расхайпленную хуйню а только то, что полезно и позволяет сэкономить человекочасы. Например COBOL.
ФП языки расхайпленная хуита и ни где себе ниши не нашли: ни в банковском софте, ни в разработке компиляторов, ни block chain контрактах...
Ну, факт-то остаётся фактом: у ООП коммьюнити намного больше, чем у ФП. Причём у ООП коммьюнити абсолютно адекватное и позитивно настроенное.
Чего не скажешь о секте поклонников ФП. 😁
Всех вам благ!
@@MasterLid приведите пример одного ФП сообщества, недостаточно позитивно к Вам настроенного
Ахахахаха концовочка прям посмешила, про абстракции и фантазии😁 ну человек явно закончил какие то курсы, послушал умных словечек и пришел написать такой яркий комментарий, ведь на самом деле он писатель и получает удовлетворение от своих метафор и абстракций😁
Спасибо за полезные видео, хотелось бы побольше таких каналов как у Вас. Буду признателен, если подскажите аналогичные источники.
Если звёзды зажигают значит это кому-нибудь нужно. Спасибо!
Добрый день, благодарю за видео. Согласен про низкое качество кода вне зависимости от языка, именно это с моей точки зрения является основной проблемой в решении бизнес задач. Я занимаюсь версткой довольно долго и последнее время вижу что мне этого мало. Некоторые фронтенд задачи начал делать с помощью фреймворков или на чистом js, понял что мне это интереснее. Да, я стал зарабатывать на этом деньги больше чем просто верстальщик, но при это понимаю, что я тот же говнокодер). Буду благодарен за совет как правильно стоит освоить новую профессию (возможно вы посоветуете курсы или книги для самостоятельного изучения). Скорее тут для меня не так важно какой язык (склоняюсь к javascript) или фреймворк изучать, как важно само понимание как правильно строить архитектуру приложений.
Привет. Курсы никакие советовать не буду, потому что не в теме. В основном слышу только негатив по отзывам. А если интересует фронтенд, то рекомендовал бы смотреть в сторону TypeScript и Vue.
Если кому интересно, что это за кейс, с которым React по умолчанию справился бы лучше, чем Angular...
Это таблица с биржевыми индексами, обновляемыми в real-time. Каждая ячейка представляла собой ангуляровский компонент, который норовил перерисоваться гораздо чаще, чем происходило реальное изменение котировок. В итоге сделали detach и обновляли ячейки вручную, плюс вынесли всю общую для ячеек информацию в статические свойства и методы.
Я понимаю, что тут можно искусственно придумать десяток-другой похожих задач, где ангуляр без дополнительных настроек будет сливать реакту, но в действительности это был всего лишь единичный случай. Все остальные потенциально проблемные места подчищались и подчищаются грамотным UI/UX.
Я не проф. разраб. Идею ООП знал еще 20 лет назад, но не погружался. Тут недавно окунулся, поднял несколько достаточно больших (для одного новичка) проектов на C#. По мере погружения в ООП, первоначальное очарование идеи - чуть ли не прямой трансляции объектов реального мира в архитектуру кода, сменялось недоумением от бесконечно нарастающей сложности конструкций и концепций. Паттерны, типа сиглтона. Нет ну серьезно, надо городить что-то ради единственности порождения? В голове начинает крутиться один вопрос - неужели по-другому никак нельзя? Все это выглядит, как бесконечные костыли, к неправильно поставленной и решаемой задаче. ФП сложнее, и в голову заходит тяжелее. Но идея иммутабельности выглядит концептуально верной, по сравнению с императивной парадигмой, основанной не бесчисленном количество переменных. Лично мне кажется, в ФП - это парадигма будущего, и в итоге к ней и придут. В общем, перехожу на F#, который, кстати, по сути обертка над C#. Учу и удивляюсь, "а что, так можно было?"
Смысл ООП не в том, чтобы использовать все существующие паттерны, а в том, чтобы использовать только то, что нужно. Т.е. если в вашем приложении не нужен синглтон, то вы его не используете. Далее, всё зависит от уровня абстракции. Например, абстракцию двигателя внутреннего сгорания можно описать в виде всего 4 тактов: впуск-сжатие-раб.ход-выпуск, а можно расписать всё до цилиндров, поршней и вплоть до винтиков. Естественно, второй вариант сложнее. Всё зависит от вашей задачи, если ДВС в виде четырех тактов ей достаточен, то совершенно не обязательно углубляться в подробности.
Ну и по F#. Ради интереса, посмотрите на хаха.ру вакансии по этому языку. Уверен, что их не так много. Во всяком случае, намного меньше, чем вакансий на C#.
@@MasterLid Я не про использование паттернов везде. Например, вы решаете задачку по математике 7 класса - и получаете уравнение, решать которое надо через поиск экстремумов, пределы, производные - это вам сразу должно подсказать, что подход к решению выбран неправильный (если ошибку исключаем). Вот так и с ООП, слишком уж много наворотов на ровном месте, делающих код непролазной мутью. Паттерны просто лучше всего это иллюстрируют. Но есть и масса других примеров - тема связанная с потокобезопасностью. Все эти пробрасывания, залочивания и прочее. Это всё сильно пахнет плохой концептуальной архитектурой языка, да и выглядит лишним. Вспоминается еще такой пример. Язык Cobol. Его создавали с идеей, что пусть там будут большие и громоздкие стейтменты, зато будет читаться как обычный текст на английском, и типа даже не программист сможет понять, что там написано. Появление и дальнейшее движение в сторону С - напрочь перечеркнуло этот подход. С ООП мне видится тоже самое. В основе идея отражать в коде объекты реального мира с похожим поведением. Идея классная, но, кмк, избыточно трудоемкая и сложная в реализации. Думаю она отомрет, как и Cobol когда-то. Насчет вакансий - я не зарабатываю этим, поэтому мне не критично. Но слышал платят ФП-шникам больше. ФП учу по сути просто, для расширения сознания и надеюсь в последствии писать код быстрее и с большим удовольствием ))
Всё, что вы пишете про ООП, прекрасно описывается фразой "просто вы не умеете это готовить". В ООП в принципе не должно получаться кода в виде непролазной мути. Если у вас получается непролазная муть, то вы что-то делаете не так. : )
@@MasterLid Когда у вас объект класса наследуется от 2-3 абстрактов, еще от 3-4 интерфейсов, на вход принимает 8-10 других объектов классов, еще свою какую-то логику реализует и сам еще какими-то объектами оперирует - вот это я уже мутью называю - чтобы понять как работает небольшой кусочек кода, мне надо пол кодовой базы перелапатить, для меня это перебор как-то, а в реальным библиотеках и больших проектах - норма жизни.
Так не делайте такую громоздкую конструкцию! Вы что-то наговнокодили (ну или прочитали в книжке какого-то говнокодера -- понятия не имею, откуда вы взяли подобную архитектуру), но претензии предъявляете ООП. Вообще лень вас в чем-то убеждать. Нравится ФП -- программируйте в ФП.
На мой взгляд в видео не совсем корректное сравнение реакта и ангуляра. Ангуляр это фреймворк, который предоставляет уже готовые решения, а реакт - библиотека, в которой у разработчика больше свободы в выборе архитектурных подходов и либ(хотя бОльшая часть приложений это cвязка React + Redux). Этим и обусловлена необходимость тратить больше времени на разработку каких-то фич. Плюс разработчик знающий реакт может без особых проблем писать мобильные приложения на нейтиве. Из-за такой гибкости и зп у реакт разрабов выше
Какие готовые решения предоставляет ангуляр? Встроенный роутер? Ngrx? Не спорю, ангуляр гораздо более богатый возможностями фреймворк, чем реакт. Но суть не в этом. Ангуляр -- типично ООП-ориентированный фреймворк (контроллер -- это класс, сервис -- это класс, директива -- это класс и т.д.), в нём очень широко применяются наследование, инкапсуляция, интерфейсы и тому подобное. Реакт -- абсолютно функциональный фреймворк (хотя раньше там можно было использовать парадигму, что контроллер -- это класс, но потом от неё отказались, и теперь всё на функциях). Поэтому в видео я и использовал эти два фреймворка, чтобы было нагляднее. Про з/п у программистов реакта -- тут-то всё понятно. Ковыряться и создавать спагетти-код, который получается на реакте (т.е. JSX/TSX), то ещё удовольствие. Конечно, работа с этим г0вн0м должна оплачиваться выше, иначе желающих будет не так чтобы сильно много.
Реакт отвечает только за рендеринг. Он не нуждается в роутере, стейт менеджере и т.п. из коробки, так как он просто либа. Уже потом, на его основе, делаются фреймворки типа некста и нейтива, которые предоставляют свои решения. Оба эти фреймворка норм, но реакт более гибкий, а ангуляр более надёжный(хотя всё зависит от того, кто пишет код). Что касается функциональщины в реакте, то причина достаточно проста, а именно перфоманс у функциональных компонентов выше чем у классов. Менее трудозатратно просто вызвать функцию, чем наследоваться от класса. Хотя есть жизненные методы в реакте, которые доступны только в классовых компонентах. Спагетти код в jsx это как? Не думаю что за работу с реактом доплачивают
Как фронтенд с опытом разработки коммерческих продуктов на всех трёх фреймворках, могу сказать, что разработка на реакт -- это одно из немногих занятий, к которым мне едва ли когда-нибудь захочется вернуться. Не хочу зарекаться, но, наверное, ни за какие деньги не стал бы снова влезать в эту тему.
Надеюсь, на ваш первоначальный вопрос я ответил. : )
Мне кажется ООП избыточен в о фронт приложениях! Ну все приводят примеры с машинами робатами и тп! Ну и много ли задачь где это надо во фронте с этим наследыванием? Ну если надо можно и класс написать не кто не против ну по мне так кажется что избычточность сорее вредна! А если не использовать наследование и просто писать через классы тт в чем преимущество?
За фронт-энд сказать однозначно не могу, не особо вникал, но на десктопе для построения UI есть 2 пути: ООП с базовым классом Widget/Control/etc и плохой. Полагаю, что интерфейс в браузере не очень сильно отличается от десктопа архитектурно.
Ну, наговнокодить сложно на расте, тк чтобы написать что-то рабочее на нем, надо иметь уже хоть какой-то опыт
Три главных слова ООП и правда не требуют ни классов ни даже объектов
// инкапсуляиция
const Counter = () => {
// n инкапсулировано
let n = 0
return () => n++
}
const c = Counter()
console.log(c(), c(), c())
// 1 2 3
// полиморфизм
const Sum = (a, b) => a + b
const Mult = (a, b) => a * b
const ops = [Sum, Mult]
// интерфейс один, аргументы одни и те же, а поведение разное
console.log(...ops.map(f => f(2, 3)))
// 5 6
// наследование
const Super = (b, f) => () => f(b)
const Foo = () => console.log("foo")
const SuperFoo = Super(Foo, (base) => {
base()
console.log("bar")
})
SuperFoo()
// foo
// bar
Даже для меня выглядит кашей, лучше реально переключиться на ООП чем на ФП
@@LetroScript это не пример ФП. Это опровержение того, что классы и ооп имеют какую-то монополию на полиморфизм, инкапсуляцию и наследование.
Объектно-ориентированный php ранних версий.. Ухахахахухуху
Даже то, что было предложено в ООП на PHP ранних версий гораздо лучше и логичнее, чем сборная солянка, которую предложил Одерски в Scala. Кстати, где она? 😁
Та же история: хайпанули, поговорили и забыли.
@@MasterLid так никто скалу более объектно-ориентированной чем php не называл. С ветрянными мельницами боретесь батюшка..