щенок щенком, но мало кто может внятно ответить на вопрос, что из себя в js представляет this
Контекст выполенения? Разве нет?
А почему нет то?
Потому что контекст невозможно отследить нормально и он теряется проще, чем девственность 11 летней девочки в арабских эмиратах.
Это не меняет того факта, что this - всегда конктекст выполнения. Другое дело что ты не всегда знаешь какой именно
затем, чтобы можно было писать var self = this;
Но ведь тупо надо было решить сраный FizzBuzz, нахуя ты все это сделал?
PS: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
PS: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
ну вот и "иди пиши на js" отсюдова
Но ведь можно писать простой и расширяемый код без ООП. Например, на Haskell. Да, это далеко не мейнстрим, и хаскель и просто в одном предложении - это странно. Но ФП языки (не все, тысячи их) предлагают концепции, которые действительно позволяют писать код более простой и более расширяемый, чем с помощью ООП.
Расширяемость - это про композируемость. Чем проще вам создавать маленькие кусочки, которые потом - вжух - и композируются вместе, тем проще писать расширяемый код. А ФП - это почти целиком про композицию.
Из математики в Haskell пришло несколько "интерфейсов", которые оказались очень удобные, чтоб писать дохуя обобщенные компоненты. Монада, функтор, аппликатив - за страшными словами скрывается банально интерфейс на несколько функций, Но такой удобный, что с ними умеют работать куча стандартных и сторонних модулей.
Что общего у списка, nullable и асинков? Это все монады. И когда в шарпе, жс и даже расте для них мутят какие-то отдельные никак не связанные методы и кейворды, в хаскелле это все монада, с которой можно работать одинаковым образом. Например, функция map (в мейнстримных языках известная как "применить функцию к каждому элементу в списке").
Наследование? Нахуй наследование. Используй композицию, потому что композиция - твой бро (так ещё GoF говорили). Композируй функции и типы.
А ещё у нас есть тайпелассы/трейты. Это как интерфейсы, только круче. Интерфейс в жавах/сишарпах/плюсах итп ты добавляешь к типу при объявлении. В хаскелле/расте есть отдельно определение типа, отдельно добавление к нему каждого тайпкласса (т.е. имплементация его методов). А ещё ничего не мешает тебе имплементировать интерфейс для стороннего типа. Все, кто страдал и наследовал классы, чтоб привести к нужному типу, должны оценить. Нет иерархии, множественного наследования и прочего говна. А есть мономорфизация, когда компилятор не будет генерировать динамическую диспатчеризацию и вызов виртуальных методов, а все будет статическое и даст тебе немного производительности.
Для вдохновения: https://habr.com/ru/post/490112/
Там в конце статьи круто написано.
Расширяемость - это про композируемость. Чем проще вам создавать маленькие кусочки, которые потом - вжух - и композируются вместе, тем проще писать расширяемый код. А ФП - это почти целиком про композицию.
Из математики в Haskell пришло несколько "интерфейсов", которые оказались очень удобные, чтоб писать дохуя обобщенные компоненты. Монада, функтор, аппликатив - за страшными словами скрывается банально интерфейс на несколько функций, Но такой удобный, что с ними умеют работать куча стандартных и сторонних модулей.
Что общего у списка, nullable и асинков? Это все монады. И когда в шарпе, жс и даже расте для них мутят какие-то отдельные никак не связанные методы и кейворды, в хаскелле это все монада, с которой можно работать одинаковым образом. Например, функция map (в мейнстримных языках известная как "применить функцию к каждому элементу в списке").
Наследование? Нахуй наследование. Используй композицию, потому что композиция - твой бро (так ещё GoF говорили). Композируй функции и типы.
А ещё у нас есть тайпелассы/трейты. Это как интерфейсы, только круче. Интерфейс в жавах/сишарпах/плюсах итп ты добавляешь к типу при объявлении. В хаскелле/расте есть отдельно определение типа, отдельно добавление к нему каждого тайпкласса (т.е. имплементация его методов). А ещё ничего не мешает тебе имплементировать интерфейс для стороннего типа. Все, кто страдал и наследовал классы, чтоб привести к нужному типу, должны оценить. Нет иерархии, множественного наследования и прочего говна. А есть мономорфизация, когда компилятор не будет генерировать динамическую диспатчеризацию и вызов виртуальных методов, а все будет статическое и даст тебе немного производительности.
Для вдохновения: https://habr.com/ru/post/490112/
Там в конце статьи круто написано.
Композиция против наследования - это древнейшая война. Лично мне композиция кажется хорошим решением только для последнего потомка или когда нужно объединить по какой-то (чаще всего очень всратой) причине несколько классов.
Что же до Хаскеля, то любой язык делают его фреймворки. Я уверен, что когда на Хаскеле выйдет что-то приличное для веба, то он сразу станет мейнстримом на час, как им был, например, руби с его рельсами.
Что же до Хаскеля, то любой язык делают его фреймворки. Я уверен, что когда на Хаскеле выйдет что-то приличное для веба, то он сразу станет мейнстримом на час, как им был, например, руби с его рельсами.
Согласен, древняя. Я предпочитаю не использовать наследование или использовать не более одного уровня.
На хаскелле есть веб фреймворки, хз, насколько приличные. Ну и на вебе мир клином не сошелся. Проблема хаскелля в том, что он, сука, пиздец конченный, не похожий ни на что другое их мейнстримных языков. Он имеет очень крутую кривую обучения. Он сложный.
Сейчас наоборот тенденция иметь простые языки, на которых могут писать кто угодно. Поэтому golang и выстрелил. В голанг даже дженерики не завезли (сейчас только завозят), ибо сложно и не его нахуй, а тут в хаскелле есть Higher Kinded Types, Algebraic Data Types, монады и прочие страшные слова, о которых я не знаю.
Да и сама функциональная парадигма очень ломает мозг, да и не нужна. Проблема в том , что функциональщина позволяет осуществлять всякие проверки над кодом, которые нереально (либо очень сложно на хаках и костылях) для императивщины, поэтому все мощные выразительные средства для императивных яп запилить, видимо, трудно. В том же расте, который во многом вдохновлён хаскелем, HKT и, следовательно, монад и, следовательно, половины красоты не завезли.
На хаскелле есть веб фреймворки, хз, насколько приличные. Ну и на вебе мир клином не сошелся. Проблема хаскелля в том, что он, сука, пиздец конченный, не похожий ни на что другое их мейнстримных языков. Он имеет очень крутую кривую обучения. Он сложный.
Сейчас наоборот тенденция иметь простые языки, на которых могут писать кто угодно. Поэтому golang и выстрелил. В голанг даже дженерики не завезли (сейчас только завозят), ибо сложно и не его нахуй, а тут в хаскелле есть Higher Kinded Types, Algebraic Data Types, монады и прочие страшные слова, о которых я не знаю.
Да и сама функциональная парадигма очень ломает мозг, да и не нужна. Проблема в том , что функциональщина позволяет осуществлять всякие проверки над кодом, которые нереально (либо очень сложно на хаках и костылях) для императивщины, поэтому все мощные выразительные средства для императивных яп запилить, видимо, трудно. В том же расте, который во многом вдохновлён хаскелем, HKT и, следовательно, монад и, следовательно, половины красоты не завезли.
Что скажешь о F#?
К сожалению, не знаком.
То чувство, когда ты из того поколения, для которого аббревиатура ООП в первую очередь значит "Организация освобождения Палестины"
То чувство, когда ты из того поколения, для которого "Palestine" звучит, как название нового никому неизвестного фреймворка на JS.
Чтобы написать коммент, необходимо залогиниться