Вы ерунду говорите. Мнемоника это и есть ключ. Каждое слово просто заменяет N байт ключа. вся фраза — весь ключ. Например мнемоника foster knock tail wide glide risk century crunch able must reason burst
Соответствует адресу 0xbe436386252974684c52BfEFD3151916AB33224B с приватным ключом 0x5c62af6f16936473e5fbe570b9e8adeca72e96237a2677994a80432c720f34f0
Никаких простых чисел нигде хранить не нужно.
Вот, сами битки хранятся в блокчейне. И потеряв ключ, вы теряете не сами битки, а доступ к ним. Как в том анекдоте "мы уже разобрались, ваши деньги не пропали, а просто поменяли хозяина".
Это какая-то софистика. Есть деньги в облаке, никто ими воспользоваться не может т.к. нет приватника. Если это не "пропали" то что значит пропали тогда. Сами по себе они офк не самоуничтожатся, но из товарооборота они оказались изьяты.
johnfound регулярно топит за то, что на ассемблере можно писать так же хорошо, как на более других языках, и никто его за язык (или пальцы) не тянул. Кстати, на предложение просто поставить мне задачу, которую я потом решу, он тоже что-то сдулся, но, видимо, это просто не судьба.
Ну он известный оригинал, подобное утверждение делать любит легко. доказывать в силу невозможности — не очень.
Ты про класс в формальном смысле (всякие там Хомские) или как фигура речи?
Фигура речи
Во-первых, про различие в синтаксисе я указал в первом же своём комментарии. Если есть несогласие с этим тезисом, то имело бы смысл, ну, спорить именно с этим тезисом.
Я увидел эту ремарку только когда написал б0льшую часть своего комментария, и решил дописать раз уж начал.
Во-вторых, ключевой тезис моего исходного собеседника — что заточенный под задачу написанный руками парсер будет по каким-то там критериям лучше написанного с абстракциями. Тут про синтаксис вообще ничего нет, аппликативные комбинаторы (включающие в себя подмножество регулярных языков) ничем не менее абстрактны, чем вот эти привычные pcre- и им подобные уродцы.
Насколько я помню, парсер-комбинаторы не очень хорошо умеют в сложные ошибки парсинга. Я-то не эксперт-языковед, у меня грамматики обычно были не сложнее какого-нибудь расписания для cron, но товарищи кто для ЯПов парсеры писал говорили что нормальную обработку ошибок на комбинаторах сделать нереально. Ещё вроде хвалили перф, но тут уж не знаю, хотя не удивился бы.
Знаете, есть поговорка, что лучше ужасный конец, чем ужас без конца. Тем более что альтернатива еще хуже: тут как с гангреной, хоть ногу и жалко, но лучше рубануть по щиколотку пока можно, а то чем дальше тем хуже.
Зависит от обьемов торгов. Средняя комиссия обмена колеблется в пределах 10-30 баксов. Соответственно нет профит от операции должен быть не ниже этого. Если автор так переживает за 3000 баксов которые исчезли то он мог 3млн обьемов набарыжить торгуя эти самые 3000 долларов туда-сюда. Биржа делает это бесплатно, циферки в базе легко переписать (как мы видим). Сделать это в реальной сети — уже стоит денюжек. К этому правда идут плюсы что никто не сможет сказать "да не было такого никогда".
Если сразу сделать "нормально", нам надо тратить время очень высококвалифицированного спеца, и мы получим 100% слабоподдерживаемого процедурного кода.
Это скажем так неправда. Писать хороший код и плохой код почти всегда примерно одинаково по времени, нужно только знать как писать хороший.
Вторая ошибка — процедурный код значит быстрый — это тоже неверно. ООП в стиле "как в джава" — медленный, никто не спорит, только проблема не в отсутствие процедур, а в динамическом диспатче. Пишите любое ООП без динамического диспатча (хотя бы как пример стд:: вариант выше) и будет все белым, пушистым и бенчмарки будут биться.
И итоговый код как можно посмотреть ничуть не сложнее ни медленного "чистого" кода, ни процедурной портянки.
И? Зато при необходимости добавить ещё одну функцию (скажем посчитать периметр) можно написать 1 функцию, а в варианте с иерархией добавлять функцию в интерфейс/базовый класс и потом менять всех наследников.
С чего вы вызяли что добавление ещё одного наследника более важная задача чем добавление функционала в существующую иерархию? Это может быть верным, а может быть и нет, в зависимости от задачи. В общем-то известная проблема.
Не стоит так снисходительно посмеиваться, не будучи на 100% правым в своем поинте, некрасиво выглядит.
А "Чистый код" и "ООП" связаны положительно? Выпиливание динамического диспатча не делает код менее чистым, зачастую даже наоборот. Поэтому ваш пример никак не доказывает/опровергает упомянутые тезисы.
В современных языках можно иметь статический диспатч для открытого множества типов который часто будет даже лучше свитча, если бранчинг известен на топлевеле (ну или хотя бы на 1 левел выше текущего). А что может быть лучше бранча? Его отсутствие.
Да меня с одного заголовка вынесло. Что разбиение на функции что-то там автору замедляет. То что атрибут inline изобрели ещё 50 лет назад он видимо не слышал.
Пишу радостно маленькие функции, почти все приложение склеивается в один большой main (и нет, я не идиот который развесил кучу инлайнов, компилятор просто думает что так выгоднее).
Все эти срачи "чистый код зло" каждый раз умиляют. Чистый код может и зло, но с ним есть время на то чтобы побенчить профайлером и потюнить узкие места. А фанат "пили быстро" мало что пилить неподдерживаемую фигню, так ещё и фигарит 2 недели суперфункцию по эффективному парсингу структурки из файла, только чтобы потом на отвали написать запрос в базу (который надо было делать ещё вчера, но он слишком замотался оффсеты считать и отлаживать, и времени думать тут нет), которая будет в мульон раз больше жрать на каждый запрос чем суммарная выгода от его реализации парсинга за всю свою жизнь. Которую причем придется выкинуть когда изменятся требования.
Популистская статья с фальшивым сбрасыванием покровов.
Честно говоря подход выше едва ли можно назвать хорошим примером, таки ассемблер это вещь специфичная. Но твой код больше похож на парсер-комбинаторный, чем регулярный, а это совсем иной класс. Может быть проблема регулярок в том, что они просто так записываются, но тем не менее под регуляркой подразумевают обычно "стринга по правилам рфц/исо/...". Например вот эта — я уверен что почти любой код доработать/изменить проще чем эту регулярку.
Регекспы — это класс языков, а не конкретный синтаксис со всеми этими |*?
Все верно, регкэспы это этот конкретный синтаксис. Так же как RJ45 это конкретно 8P8C а не что-то ещё, а копировальная машина — исключительно "ксерокс".
10% гарантированных годовых звучит нереалистично, честно скажу. Сколько там по сверхнадежным бондам процент был, от котороых SVB развалился? Сильно меньше процента емнип. Соответственно отсюда вся остальная математика немного хромает.
А ещё добавим что до штатов нужно доехать, для чего нужно быть неплохим сениором или хотя бы очень крутым миддлом. Предполагая что человек после универа лет за 5 (очень маленький срок) получит достаточную квалификацию чтобы его захантили с релоком то миниальный срок когда он может начать этим заниматься — 27-28 лет. А до тех пор кое-как работая в РФ получится хорошо если сводить концы с концами.
Звучит вполне реально, не правда ли?
Примерно так же реально как "каждый день делать несколько задачек на литкоде и ходить 2 раза в неделю в зал на протяжении 13 лет" имхо. Иными словами невероятно сложно для абсолютного большинства людей.
1.5 млн это все же дофига в том числе для программиста. Если взять какого-нибудь ФААНГ-товарища нехилой квалификации то он может получать ну типа 250 гросс. Порядка 50 я так понимаю уйдет на налоги, ещё столько же на скромную жизнь. Откладываем по 150, это 10 лет работы. Без непредвиденных расходов, любых путешествий. и из трат только покушать, будучи на хорошей позиции в топ богатых компаний.
Если же мы возьмем что-то более среднее (гугл подсказывает The average senior java developer salary in the USA is $126,785 per year), то вместо 10 лет работы у нас появляются все 30+.
Я не обвиняю никого в элитизме, но это обьективно "не для всех". Ну не могут все быть л77 сениорами в фейсбуке.
Нанесшие такой удар могут ни на что не надеятьс потому что получат ответочку, и надеяться будет уже некому. Давайте заниматься более-менее реалистичным думингом на тему того как нас ИИ разберет на скрепки, а не фантастическое "и они взяли и разбомбили всё и всех, и стали самыми большими молодцами".
Там в стандарте указано какое слово каким байтам соответствует, так что свою никак.
Откровенно говоря с чтением у меня проблемы)
Вы ерунду говорите. Мнемоника это и есть ключ. Каждое слово просто заменяет N байт ключа. вся фраза — весь ключ. Например мнемоника
foster knock tail wide glide risk century crunch able must reason burstСоответствует адресу
0xbe436386252974684c52BfEFD3151916AB33224Bс приватным ключом0x5c62af6f16936473e5fbe570b9e8adeca72e96237a2677994a80432c720f34f0Никаких простых чисел нигде хранить не нужно.
Это какая-то софистика. Есть деньги в облаке, никто ими воспользоваться не может т.к. нет приватника. Если это не "пропали" то что значит пропали тогда. Сами по себе они офк не самоуничтожатся, но из товарооборота они оказались изьяты.
Ну он известный оригинал, подобное утверждение делать любит легко. доказывать в силу невозможности — не очень.
Фигура речи
Я увидел эту ремарку только когда написал б0льшую часть своего комментария, и решил дописать раз уж начал.
Насколько я помню, парсер-комбинаторы не очень хорошо умеют в сложные ошибки парсинга. Я-то не эксперт-языковед, у меня грамматики обычно были не сложнее какого-нибудь расписания для cron, но товарищи кто для ЯПов парсеры писал говорили что нормальную обработку ошибок на комбинаторах сделать нереально. Ещё вроде хвалили перф, но тут уж не знаю, хотя не удивился бы.
Знаете, есть поговорка, что лучше ужасный конец, чем ужас без конца. Тем более что альтернатива еще хуже: тут как с гангреной, хоть ногу и жалко, но лучше рубануть по щиколотку пока можно, а то чем дальше тем хуже.
Зависит от обьемов торгов. Средняя комиссия обмена колеблется в пределах 10-30 баксов. Соответственно нет профит от операции должен быть не ниже этого. Если автор так переживает за 3000 баксов которые исчезли то он мог 3млн обьемов набарыжить торгуя эти самые 3000 долларов туда-сюда. Биржа делает это бесплатно, циферки в базе легко переписать (как мы видим). Сделать это в реальной сети — уже стоит денюжек. К этому правда идут плюсы что никто не сможет сказать "да не было такого никогда".
Aave/Compound/...? Тысячи их.
Зато многие могут сдохнуть. И не только с голоду. Что несколько добавляет мотивации помимо прочих.
Почему неудачный? Его достаточно чтобы опровергнуть "или\или".
У меня например быстрый и красивый проект есть, но вы наверняка мне не поверите :)
Это скажем так неправда. Писать хороший код и плохой код почти всегда примерно одинаково по времени, нужно только знать как писать хороший.
Вторая ошибка — процедурный код значит быстрый — это тоже неверно. ООП в стиле "как в джава" — медленный, никто не спорит, только проблема не в отсутствие процедур, а в динамическом диспатче. Пишите любое ООП без динамического диспатча (хотя бы как пример стд:: вариант выше) и будет все белым, пушистым и бенчмарки будут биться.
И итоговый код как можно посмотреть ничуть не сложнее ни медленного "чистого" кода, ни процедурной портянки.
И? Зато при необходимости добавить ещё одну функцию (скажем посчитать периметр) можно написать 1 функцию, а в варианте с иерархией добавлять функцию в интерфейс/базовый класс и потом менять всех наследников.
С чего вы вызяли что добавление ещё одного наследника более важная задача чем добавление функционала в существующую иерархию? Это может быть верным, а может быть и нет, в зависимости от задачи. В общем-то известная проблема.
Не стоит так снисходительно посмеиваться, не будучи на 100% правым в своем поинте, некрасиво выглядит.
А "Чистый код" и "ООП" связаны положительно? Выпиливание динамического диспатча не делает код менее чистым, зачастую даже наоборот. Поэтому ваш пример никак не доказывает/опровергает упомянутые тезисы.
В современных языках можно иметь статический диспатч для открытого множества типов который часто будет даже лучше свитча, если бранчинг известен на топлевеле (ну или хотя бы на 1 левел выше текущего). А что может быть лучше бранча? Его отсутствие.
Да меня с одного заголовка вынесло. Что разбиение на функции что-то там автору замедляет. То что атрибут inline изобрели ещё 50 лет назад он видимо не слышал.
Пишу радостно маленькие функции, почти все приложение склеивается в один большой main (и нет, я не идиот который развесил кучу инлайнов, компилятор просто думает что так выгоднее).
Все эти срачи "чистый код зло" каждый раз умиляют. Чистый код может и зло, но с ним есть время на то чтобы побенчить профайлером и потюнить узкие места. А фанат "пили быстро" мало что пилить неподдерживаемую фигню, так ещё и фигарит 2 недели суперфункцию по эффективному парсингу структурки из файла, только чтобы потом на отвали написать запрос в базу (который надо было делать ещё вчера, но он слишком замотался оффсеты считать и отлаживать, и времени думать тут нет), которая будет в мульон раз больше жрать на каждый запрос чем суммарная выгода от его реализации парсинга за всю свою жизнь. Которую причем придется выкинуть когда изменятся требования.
Популистская статья с фальшивым сбрасыванием покровов.
Честно говоря подход выше едва ли можно назвать хорошим примером, таки ассемблер это вещь специфичная. Но твой код больше похож на парсер-комбинаторный, чем регулярный, а это совсем иной класс. Может быть проблема регулярок в том, что они просто так записываются, но тем не менее под регуляркой подразумевают обычно "стринга по правилам рфц/исо/...". Например вот эта — я уверен что почти любой код доработать/изменить проще чем эту регулярку.
Все верно, регкэспы это этот конкретный синтаксис. Так же как RJ45 это конкретно 8P8C а не что-то ещё, а копировальная машина — исключительно "ксерокс".
А был ли мальчик? В смысле, компания? Может это три развеселых друга, которым вывеску сменить куда дешевле чем платить целых полновесных 750 баксов?
И да, они улетели в ридонли и спустя почти неделю от них ни слуху ни духу. Сильный опыт.
10% гарантированных годовых звучит нереалистично, честно скажу. Сколько там по сверхнадежным бондам процент был, от котороых SVB развалился? Сильно меньше процента емнип. Соответственно отсюда вся остальная математика немного хромает.
А ещё добавим что до штатов нужно доехать, для чего нужно быть неплохим сениором или хотя бы очень крутым миддлом. Предполагая что человек после универа лет за 5 (очень маленький срок) получит достаточную квалификацию чтобы его захантили с релоком то миниальный срок когда он может начать этим заниматься — 27-28 лет. А до тех пор кое-как работая в РФ получится хорошо если сводить концы с концами.
Примерно так же реально как "каждый день делать несколько задачек на литкоде и ходить 2 раза в неделю в зал на протяжении 13 лет" имхо. Иными словами невероятно сложно для абсолютного большинства людей.
1.5 млн это все же дофига в том числе для программиста. Если взять какого-нибудь ФААНГ-товарища нехилой квалификации то он может получать ну типа 250 гросс. Порядка 50 я так понимаю уйдет на налоги, ещё столько же на скромную жизнь. Откладываем по 150, это 10 лет работы. Без непредвиденных расходов, любых путешествий. и из трат только покушать, будучи на хорошей позиции в топ богатых компаний.
Если же мы возьмем что-то более среднее (гугл подсказывает The average senior java developer salary in the USA is $126,785 per year), то вместо 10 лет работы у нас появляются все 30+.
Я не обвиняю никого в элитизме, но это обьективно "не для всех". Ну не могут все быть л77 сениорами в фейсбуке.
Нанесшие такой удар могут ни на что не надеятьс потому что получат ответочку, и надеяться будет уже некому. Давайте заниматься более-менее реалистичным думингом на тему того как нас ИИ разберет на скрепки, а не фантастическое "и они взяли и разбомбили всё и всех, и стали самыми большими молодцами".