ЕХ
Надо локализовать тогда источники этих проблем и предложить решение, чтобы устранить их
ну проблем хватает. Та же экспрешен проблем 😊
Size: a a a
2020 May 24
DS
так я поэтому и спрашиваю не про C#
Ну смотри трейты в скале
DS
И path-dependent типы в них
ЕХ
Ну смотри трейты в скале
На сколько я знаю они из себя и представляют дикообраза, потому что тайп классы с наследованием хорошо не сочетаются. Т. е. это попытка сделать гибрид между парадигмами не то чтобы очень красивая. А мне как раз хотелось бы найти вещи которые именно хорошо на ООП ложатся
SP
Defined and enforced by LLVM plugins and presubmit checks. In particular, we feel it may be necessary to ban raw pointers from C++.
S
ну проблем хватает. Та же экспрешен проблем 😊
А в в чём премис?
DS
На сколько я знаю они из себя и представляют дикообраза, потому что тайп классы с наследованием хорошо не сочетаются. Т. е. это попытка сделать гибрид между парадигмами не то чтобы очень красивая. А мне как раз хотелось бы найти вещи которые именно хорошо на ООП ложатся
В скале трейты - это не тайпклассы
DS
В скале трейты - это именно ООП фигня
ЕХ
А в в чём премис?
Что-то мы действительно не туда ушли. Изначальный вопрос вытекал из противостояния ФП и ООП. И последнее время приводится куча примеров высокоуровневых абстракций (типа монад, семейств типов и т. п.) которые можно строить в ФП. И соотвественно можно делать очень гибкие библиотеки и условно меньше писать в пользовательском коде. Что этому может противопоставить ООП парадигма?
A
Scala зависит, Kotlin, TS, C++, ...
а от чего зависят?
S
Что-то мы действительно не туда ушли. Изначальный вопрос вытекал из противостояния ФП и ООП. И последнее время приводится куча примеров высокоуровневых абстракций (типа монад, семейств типов и т. п.) которые можно строить в ФП. И соотвественно можно делать очень гибкие библиотеки и условно меньше писать в пользовательском коде. Что этому может противопоставить ООП парадигма?
class cat extends table
G
От других платформ/языков, с ними имеют тесный контакт
S
Because it has four legs
DS
Что-то мы действительно не туда ушли. Изначальный вопрос вытекал из противостояния ФП и ООП. И последнее время приводится куча примеров высокоуровневых абстракций (типа монад, семейств типов и т. п.) которые можно строить в ФП. И соотвественно можно делать очень гибкие библиотеки и условно меньше писать в пользовательском коде. Что этому может противопоставить ООП парадигма?
Нет противостояния ФП и ООП.
ЕХ
Нет противостояния ФП и ООП.
И поэтому обычно говорят "generic'и это изначально ФП-шная концепция и она плохо дружит с наследованием"?
NL
Because it has four legs
(Я немного подчистил твои стикеры, они честно говоря утомляют слегка. Не обессудь)
ЕХ
или там при добавлении наследования в какой-нибудь язык у него сразу резко ухуджаются возможности по выводу типов, нужны будут конструкторы как фича язык и кто его знает что еще
S
(Я немного подчистил твои стикеры, они честно говоря утомляют слегка. Не обессудь)
NL
Лев Толстой написал 4 тома текста, переполненного множеством разных чувств и эмоций и при этом не использовал ни единого смайлика. Интересно, как это у него получилось?