Да мне не очень важна форма, больше содержание. Основные критерии: ключевые слова заголовка (разбор, повестки) и рейтинг статьи. Если они соблюдаются то я зашел бы вне зависимости от уровня кликбейтности
ну откровенно говоря полезная инфа. Я узнал про поправки и то что можно удаленно попробовтаь открепиться. про 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 раз короче. Я бы поспорил про то, что более длинное но "чистокодовое" решение лучше [читаемее, поддерживаемее, понимаемее] более короткого.
Чистокод это книга для джунов, в которой довольно бескомпромиссно высказыаются многие спорные тезисы. Но суть именно в том что она для джунов которые не умеют взвешивать за и против, поэтому лучше их научить всегда делать одно и то же, и когда подрастут смогут более критически относиться к многим советам. В универе мне книга казалась откровением, например пункт "если вы пишете комментарий значит вы не смогли нормально обозвать переменные и функции" был прям разрывом шаблона, особенно на фоне лекций про важность комментариев от нашей профессуры.
Ну я ровно потому и говорю. В таком случае написание чистого кода на всяких там хачкелях или растах получается невозможно — там же нет "ООП как джава". Что выглядит довольно "ООП-центристским" взглядом как ООП как уберпарадигму со снисходительным взглядом на остальных
Так дальше хуже, я о чем говорю. Либо ужасный конец сейчас, либо еще более ужасный через год, либо совсем отвратительный через несколько лет — положительного исхода просто нет. Поэтому хорошо бы "зафиксировать убыток" и двигаться дальше, даже если это означает что станет хуже — чтобы не допустить ещё большее "хуже".
Вы ерунду говорите. Мнемоника это и есть ключ. Каждое слово просто заменяет N байт ключа. вся фраза — весь ключ. Например мнемоника foster knock tail wide glide risk century crunch able must reason burst
Соответствует адресу 0xbe436386252974684c52BfEFD3151916AB33224B с приватным ключом 0x5c62af6f16936473e5fbe570b9e8adeca72e96237a2677994a80432c720f34f0
Никаких простых чисел нигде хранить не нужно.
Вот, сами битки хранятся в блокчейне. И потеряв ключ, вы теряете не сами битки, а доступ к ним. Как в том анекдоте "мы уже разобрались, ваши деньги не пропали, а просто поменяли хозяина".
Это какая-то софистика. Есть деньги в облаке, никто ими воспользоваться не может т.к. нет приватника. Если это не "пропали" то что значит пропали тогда. Сами по себе они офк не самоуничтожатся, но из товарооборота они оказались изьяты.
johnfound регулярно топит за то, что на ассемблере можно писать так же хорошо, как на более других языках, и никто его за язык (или пальцы) не тянул. Кстати, на предложение просто поставить мне задачу, которую я потом решу, он тоже что-то сдулся, но, видимо, это просто не судьба.
Ну он известный оригинал, подобное утверждение делать любит легко. доказывать в силу невозможности — не очень.
Ты про класс в формальном смысле (всякие там Хомские) или как фигура речи?
Фигура речи
Во-первых, про различие в синтаксисе я указал в первом же своём комментарии. Если есть несогласие с этим тезисом, то имело бы смысл, ну, спорить именно с этим тезисом.
Я увидел эту ремарку только когда написал б0льшую часть своего комментария, и решил дописать раз уж начал.
Во-вторых, ключевой тезис моего исходного собеседника — что заточенный под задачу написанный руками парсер будет по каким-то там критериям лучше написанного с абстракциями. Тут про синтаксис вообще ничего нет, аппликативные комбинаторы (включающие в себя подмножество регулярных языков) ничем не менее абстрактны, чем вот эти привычные pcre- и им подобные уродцы.
Насколько я помню, парсер-комбинаторы не очень хорошо умеют в сложные ошибки парсинга. Я-то не эксперт-языковед, у меня грамматики обычно были не сложнее какого-нибудь расписания для cron, но товарищи кто для ЯПов парсеры писал говорили что нормальную обработку ошибок на комбинаторах сделать нереально. Ещё вроде хвалили перф, но тут уж не знаю, хотя не удивился бы.
Да мне не очень важна форма, больше содержание. Основные критерии: ключевые слова заголовка (разбор, повестки) и рейтинг статьи. Если они соблюдаются то я зашел бы вне зависимости от уровня кликбейтности
ну откровенно говоря полезная инфа. Я узнал про поправки и то что можно удаленно попробовтаь открепиться. про 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" ведь "из меньшего нельзя вычитать большее!!". Это был закон. Потом через пару лет оказалось, что на самом деле можно, но вот корень из отрицательных чисел снова оказалось брать нельзя. Ну и так далее.
Почему-то во всех образовательных системах что я знаю предполагается что человеку сначала надо дать простой и понятный императив, а потом про нюансы излагать.
Это от языка зависит. Например:
Я на своей практике в эти "мост эксепшонал кейзес" ни разу не упирался, даже километровые функции в стни строк с кучей логики спокойно инлайнились.
Динамический дисптч — зло, всегда функции должны быть статические.
Это общепринятый биас, тем не менее считаю что с ним нужно бороться)
Чистокод это книга для джунов, в которой довольно бескомпромиссно высказыаются многие спорные тезисы. Но суть именно в том что она для джунов которые не умеют взвешивать за и против, поэтому лучше их научить всегда делать одно и то же, и когда подрастут смогут более критически относиться к многим советам. В универе мне книга казалась откровением, например пункт "если вы пишете комментарий значит вы не смогли нормально обозвать переменные и функции" был прям разрывом шаблона, особенно на фоне лекций про важность комментариев от нашей профессуры.
Ну я ровно потому и говорю. В таком случае написание чистого кода на всяких там хачкелях или растах получается невозможно — там же нет "ООП как джава". Что выглядит довольно "ООП-центристским" взглядом как ООП как уберпарадигму со снисходительным взглядом на остальных
Так дальше хуже, я о чем говорю. Либо ужасный конец сейчас, либо еще более ужасный через год, либо совсем отвратительный через несколько лет — положительного исхода просто нет. Поэтому хорошо бы "зафиксировать убыток" и двигаться дальше, даже если это означает что станет хуже — чтобы не допустить ещё большее "хуже".
Да, отвечаю на тег сарказм.
Там в стандарте указано какое слово каким байтам соответствует, так что свою никак.
Откровенно говоря с чтением у меня проблемы)
Вы ерунду говорите. Мнемоника это и есть ключ. Каждое слово просто заменяет N байт ключа. вся фраза — весь ключ. Например мнемоника
foster knock tail wide glide risk century crunch able must reason burstСоответствует адресу
0xbe436386252974684c52BfEFD3151916AB33224Bс приватным ключом0x5c62af6f16936473e5fbe570b9e8adeca72e96237a2677994a80432c720f34f0Никаких простых чисел нигде хранить не нужно.
Это какая-то софистика. Есть деньги в облаке, никто ими воспользоваться не может т.к. нет приватника. Если это не "пропали" то что значит пропали тогда. Сами по себе они офк не самоуничтожатся, но из товарооборота они оказались изьяты.
Ну он известный оригинал, подобное утверждение делать любит легко. доказывать в силу невозможности — не очень.
Фигура речи
Я увидел эту ремарку только когда написал б0льшую часть своего комментария, и решил дописать раз уж начал.
Насколько я помню, парсер-комбинаторы не очень хорошо умеют в сложные ошибки парсинга. Я-то не эксперт-языковед, у меня грамматики обычно были не сложнее какого-нибудь расписания для cron, но товарищи кто для ЯПов парсеры писал говорили что нормальную обработку ошибок на комбинаторах сделать нереально. Ещё вроде хвалили перф, но тут уж не знаю, хотя не удивился бы.