Основная сложность — наличие имущества и невозможность его переписать (даже генеральная доверенность не дает права дарения если прямо не указано кому можно подарить имущество). Любые серьезные ограничения в этом направлении это большая проблема, которую хочется решить превентивно.
Ну вот ООП в стиле с фабриками декораторов — это то что у меня прочно ассоциируется с джавой, и думаю я не один такой. Прошу прощения если задел.
На джаве можно писать так, чтобы получилось быстро. Но он будет признан "неидиоматичным" почти любым джава-корифеем. А правильный кодес по гайдлайнам будет выглядеть как спринг.
Я сказал "ООП как в джава". В противовес скажем "ООП как в раст" или "ООП как в смоллтолк" или "ООП как в джаваскрипт". Чтобы не спорить о терминах я просто очертил круг языков про которые говорю.
Никто никуда не плевал и презрительно не кивал, не надо искать того чего нет.
Да мне не очень важна форма, больше содержание. Основные критерии: ключевые слова заголовка (разбор, повестки) и рейтинг статьи. Если они соблюдаются то я зашел бы вне зависимости от уровня кликбейтности
ну откровенно говоря полезная инфа. Я узнал про поправки и то что можно удаленно попробовтаь открепиться. про 6 месяцев и тп. Да, это все написано в законах, актах и тп, но тут специально для таких как я собрали все в одно место и подчеркнули нужное.
ну он есть, но компилятор не использует закон исключенного третьего для него. Поэтому после матчей match x if P(x) => ..., x if !P(x) => ...нужно матчитьmatch x if P(X) && !P(X) => ...
Так-то оно нсть с версии раста 1.0, не очень понятно утверждение "когда завезут гварды".
Ну это не комне вопрос) Мой тейк собственно в том что эти требования нигде никогда не описываются и приходится полагаться на "здравый смысл", "ну понятно же что имелось в виду" и прочие формальные критерии. Но господа выше утверждают что где-то это описано, и я хотел бы вот на примере стд одного из крупнейших языков узнать о чем они. Потому как продакшн код любого проекта который я видел куда меньше документирован, соответственно хочется получить оценку сверху на максимальное количество требований, которые можно почерпнуть из описание типа/документации/...
Я такой себе математик, но кажется что "пэ" это "свойства выполняемые для данного Т". К индукции у меня вопросов нет. Вопрос именно откуда брать список требований к типам. Я ниже раписал
Поэтому тут все зависит от того как описан контракт базового класса.
И как? Ну вот возьмем List.Add из стандартой библиотеки C#. Описание
Adds an object to the end of the List<T>.
Можете перечислить предусловия/постусловия? Единственное которое я могу придумать "должно выполняться list.Add(obj); Assert.Equals(list[list.length-1], obj);", но является ли это исчерпывающим списком. Есть ли тут другие пред/пост условия? Как узнать? Скажем я могу написать такую реализацию, которая под это условие подходит:
class WeirdList<T> extends List<T> {
public override Add(T item) {
base.Clear();
base.Add(item);
}
}
Не претендует, потому что нам нужно определиться с тем что такое "поведение", чтобы проверить, изменяется оно или нет. Это в некоторой степени сходно с "чистотой" — что считать сайд эффектом а что нет. Является ли дополнительные аллокации сайдэффектом? А лишние ЦПУ циклы? А принт в лог? Вопросы, вопросы...
Так и тут: количество инвариантов базового типа бесконечно и нигде не описано.
В ооп один из основных столпов это SOLID, к каждой букве которого можно придумать контрпример. в результате которого принцип оказывается, ну, принципом. А не законом.
Одна апелляция к авторитету выбила другую. А прикинь, если б обеих не было?
Почему-то все системы обучения построены по этому принципу. Например в младших классах меня били линейкой по руке за запись "2 — 5" ведь "из меньшего нельзя вычитать большее!!". Это был закон. Потом через пару лет оказалось, что на самом деле можно, но вот корень из отрицательных чисел снова оказалось брать нельзя. Ну и так далее.
Почему-то во всех образовательных системах что я знаю предполагается что человеку сначала надо дать простой и понятный императив, а потом про нюансы излагать.
Да, я сам недавно узнал, что у inline ныне другое значение. Так что inline в 99% случаев автоматический и если он не сам, то он уже никак (я практически не встречал компилятор-specific __force_inline).
Это от языка зависит. Например:
Inline attributes do not guarantee that a function is inlined or not inlined, but in practice, #[inline(always)] will cause inlining in all but the most exceptional cases.
Я на своей практике в эти "мост эксепшонал кейзес" ни разу не упирался, даже километровые функции в стни строк с кучей логики спокойно инлайнились.
Ну и маленькие функции (не виртуальные) прекрасно автоматически инлайнятся, индирекция за счет виртуальных коллов иногда убивает потенциал инлайнинга.
Динамический дисптч — зло, всегда функции должны быть статические.
В любом случае "чистокодовый подход" у меня ассоциируется с ООП-абстрактными-фабриками, которые несколько спорные например: FizzBuzzEnterpriseEdition.
Это общепринятый биас, тем не менее считаю что с ним нужно бороться)
Я кстати недавно почитал "Чистый Код", их абсолютно понятные примеры на Java с листингом на 7 страниц и примечанием, что автор реализовал этот же функционал на pyhon в 5 раз короче. Я бы поспорил про то, что более длинное но "чистокодовое" решение лучше [читаемее, поддерживаемее, понимаемее] более короткого.
Чистокод это книга для джунов, в которой довольно бескомпромиссно высказыаются многие спорные тезисы. Но суть именно в том что она для джунов которые не умеют взвешивать за и против, поэтому лучше их научить всегда делать одно и то же, и когда подрастут смогут более критически относиться к многим советам. В универе мне книга казалась откровением, например пункт "если вы пишете комментарий значит вы не смогли нормально обозвать переменные и функции" был прям разрывом шаблона, особенно на фоне лекций про важность комментариев от нашей профессуры.
Ну я ровно потому и говорю. В таком случае написание чистого кода на всяких там хачкелях или растах получается невозможно — там же нет "ООП как джава". Что выглядит довольно "ООП-центристским" взглядом как ООП как уберпарадигму со снисходительным взглядом на остальных
Так дальше хуже, я о чем говорю. Либо ужасный конец сейчас, либо еще более ужасный через год, либо совсем отвратительный через несколько лет — положительного исхода просто нет. Поэтому хорошо бы "зафиксировать убыток" и двигаться дальше, даже если это означает что станет хуже — чтобы не допустить ещё большее "хуже".
Я не согласен с такой постановкой вопроса. Терять всю жизнь конечно хуже, чем потерять 5-10 лет, тем не менее и последнее это едва ли "черт с ним".
Основная сложность — наличие имущества и невозможность его переписать (даже генеральная доверенность не дает права дарения если прямо не указано кому можно подарить имущество). Любые серьезные ограничения в этом направлении это большая проблема, которую хочется решить превентивно.
Ну вот ООП в стиле с фабриками декораторов — это то что у меня прочно ассоциируется с джавой, и думаю я не один такой. Прошу прощения если задел.
На джаве можно писать так, чтобы получилось быстро. Но он будет признан "неидиоматичным" почти любым джава-корифеем. А правильный кодес по гайдлайнам будет выглядеть как спринг.
Я сказал "ООП как в джава". В противовес скажем "ООП как в раст" или "ООП как в смоллтолк" или "ООП как в джаваскрипт". Чтобы не спорить о терминах я просто очертил круг языков про которые говорю.
Никто никуда не плевал и презрительно не кивал, не надо искать того чего нет.
Спорный вопрос. Для меня большим откровением было что вместо
можно написать
И такой код будет куда лучше смотреться, особенно по месту использования.
Да мне не очень важна форма, больше содержание. Основные критерии: ключевые слова заголовка (разбор, повестки) и рейтинг статьи. Если они соблюдаются то я зашел бы вне зависимости от уровня кликбейтности
ну откровенно говоря полезная инфа. Я узнал про поправки и то что можно удаленно попробовтаь открепиться. про 6 месяцев и тп. Да, это все написано в законах, актах и тп, но тут специально для таких как я собрали все в одно место и подчеркнули нужное.
ну он есть, но компилятор не использует закон исключенного третьего для него. Поэтому после матчей
match x if P(x) => ..., x if !P(x) => ...нужно матчитьmatch x if P(X) && !P(X) => ...Так-то оно нсть с версии раста 1.0, не очень понятно утверждение "когда завезут гварды".
Какие именно гварды? обычные match x if x>5 имеются, речь про какие-то другие?
На самом деле и тайпскрипт что-то умеет при должном уровне гигиены.
А уж он мейнстримней некуда.
Ну это не комне вопрос) Мой тейк собственно в том что эти требования нигде никогда не описываются и приходится полагаться на "здравый смысл", "ну понятно же что имелось в виду" и прочие формальные критерии. Но господа выше утверждают что где-то это описано, и я хотел бы вот на примере стд одного из крупнейших языков узнать о чем они. Потому как продакшн код любого проекта который я видел куда меньше документирован, соответственно хочется получить оценку сверху на максимальное количество требований, которые можно почерпнуть из описание типа/документации/...
Я такой себе математик, но кажется что "пэ" это "свойства выполняемые для данного Т". К индукции у меня вопросов нет. Вопрос именно откуда брать список требований к типам. Я ниже раписал
И как? Ну вот возьмем List.Add из стандартой библиотеки C#. Описание
Можете перечислить предусловия/постусловия? Единственное которое я могу придумать "должно выполняться
list.Add(obj); Assert.Equals(list[list.length-1], obj);", но является ли это исчерпывающим списком. Есть ли тут другие пред/пост условия? Как узнать? Скажем я могу написать такую реализацию, которая под это условие подходит:Соблюдает ли такая реализация LSP?
Так вопрос что такое "любое Пэ". Как очертить множество этих самых "пэ" которые должны выполняться? Возьмем иерархию:
Этот наш класс нарушает принцип лискова или нет?
Не претендует, потому что нам нужно определиться с тем что такое "поведение", чтобы проверить, изменяется оно или нет. Это в некоторой степени сходно с "чистотой" — что считать сайд эффектом а что нет. Является ли дополнительные аллокации сайдэффектом? А лишние ЦПУ циклы? А принт в лог? Вопросы, вопросы...
Так и тут: количество инвариантов базового типа бесконечно и нигде не описано.
В ооп один из основных столпов это SOLID, к каждой букве которого можно придумать контрпример. в результате которого принцип оказывается, ну, принципом. А не законом.
Почему-то все системы обучения построены по этому принципу. Например в младших классах меня били линейкой по руке за запись "2 — 5" ведь "из меньшего нельзя вычитать большее!!". Это был закон. Потом через пару лет оказалось, что на самом деле можно, но вот корень из отрицательных чисел снова оказалось брать нельзя. Ну и так далее.
Почему-то во всех образовательных системах что я знаю предполагается что человеку сначала надо дать простой и понятный императив, а потом про нюансы излагать.
Это от языка зависит. Например:
Я на своей практике в эти "мост эксепшонал кейзес" ни разу не упирался, даже километровые функции в стни строк с кучей логики спокойно инлайнились.
Динамический дисптч — зло, всегда функции должны быть статические.
Это общепринятый биас, тем не менее считаю что с ним нужно бороться)
Чистокод это книга для джунов, в которой довольно бескомпромиссно высказыаются многие спорные тезисы. Но суть именно в том что она для джунов которые не умеют взвешивать за и против, поэтому лучше их научить всегда делать одно и то же, и когда подрастут смогут более критически относиться к многим советам. В универе мне книга казалась откровением, например пункт "если вы пишете комментарий значит вы не смогли нормально обозвать переменные и функции" был прям разрывом шаблона, особенно на фоне лекций про важность комментариев от нашей профессуры.
Ну я ровно потому и говорю. В таком случае написание чистого кода на всяких там хачкелях или растах получается невозможно — там же нет "ООП как джава". Что выглядит довольно "ООП-центристским" взглядом как ООП как уберпарадигму со снисходительным взглядом на остальных
Так дальше хуже, я о чем говорю. Либо ужасный конец сейчас, либо еще более ужасный через год, либо совсем отвратительный через несколько лет — положительного исхода просто нет. Поэтому хорошо бы "зафиксировать убыток" и двигаться дальше, даже если это означает что станет хуже — чтобы не допустить ещё большее "хуже".
Да, отвечаю на тег сарказм.