Есть ещё вопрос производительности: иногда можно вручную написать код, который работает эффективнее, чем результат работы компилятора. Например, существенная часть пакета math/big стандартной библиотеки Go написана на ассемблере, потому что базовые процедуры этой библиотеки гораздо более эффективны, если вы обходите компилятор и реализуете что-то лучше, чем сделал бы он. Иногда ассемблер нужен для работы с новыми и необычными функциями устройств или с возможностями, недоступными для более высокоуровневых языков — например, новыми криптографическими инструкциями современных процессоров.
Вы имеете в виду вот это? Тут нет ничего удивительного, конечно же, стандартную библиотеку оптимизируют вручную для разных архитектур, если есть такая возможность. Но речь шла о компиляторе, который компилирует пользовательский код. В этом случае он тоже сумеет автоматически, без помощи разработчика, использовать расширенный набор инструкций, присущий целевой платформе?
Здесь говорится о более компактном и эффективном коде, но я не вижу ничего касающегося платформозависимых оптимизаций. Полагаю, что компактность и эффективность опять же относится к общим для всех платформ оптимизациям (это хорошо, конечно). Потому что находить возможности для применения векторных инструкций, судя по приведённой мной ссылке на статью, не так-то просто. А если это делается, то смысл уже этой статьи ускользает от меня.
Скажем, если на какой-то платформе отсутствует инструкция умножения или деления (например, на микроконтроллерах), то либо придётся делать для этой платформы хак в виде сложений/сдвигов, либо делать хак в виде одной инструкции умножения для платформ, где оно есть, либо везде использовать сложения/сдвиги. И судя по вот этой статье будет применяться именно последний вариант.
Хмм… всё это хорошо, конечно, но такой код вряд ли будет высокопроизводительным. По сути, универсальный ассемблер — это «наибольший общий делитель» всех архитектур. Но каждая платформа имеет свои особенности, а x86/amd64, в частности, большое количество дополнительных инструкций, позволяющих в разы ускорить вычисления. Взять хотя бы эту статью. Как я понял, Go никак не стремится использовать эти расширения, т.к. они не кроссплатформенны.
Чеки это такая ерунда, учитывая количество и квалификацию персонала который имеет доступ к списку ваших операций по картам в разрезе места покупок и сумм…
Так одно дело, когда продавцы, другое дело — рандомные люди из магазина с праздным любопытством. Не думаю, что стоит вообще оставлять неопределённому кругу лиц триплет «внешность — фамилия/имя — список покупок». Конечно, это просто моя паранойя, скорее всего, но в таких делах лучше перебдеть.
К уже упомянутым плюсам добавлю свои:
— скорость платежа намного выше;
— пин для разблокировки приложения можно ввести заранее, стоя в очереди, а не как с карточкой, на кассе;
— карта от частого использования изнашивается, чип начинает читаться иногда не с первого, а то и не со второго раза; впрочем, обычно к этому моменту уже пора перевыпускать карту, но всё равно неудобства бывают;
— при оплате через приложение Qiwi, например, на чеке не будет вашего имени-фамилии, я по этой причине всегда забираю чеки с собой, незачем кому попало знать, что такой-то человек покупает то-то.
— проще контролировать расходы, уже сказали, что баланс виден непосредственно.
Недавно была атака на банки, так вот Сбербанк Онлайн выдавал пусть и не бектрейсы, но исключения Java с указанием имён пэкейджей и классов. В частности, про невозможность Hibernate подключиться к БД или ошибки рефлексии. Не то чтобы прямо что-то критичное, но я несколько удивился. Ещё раньше на запуске нынешней системы на Java у них и трейсы вылетали целиком, сейчас, вроде, убрали.
Разница очень даже большая. Если комбо забиты заранее, это не только даёт преимущество, но и снижает ценность работы — обучение идёт уже не от условного нуля. А так сеть самостоятельно выясняет выигрышные комбинации, причём, как и человеку, ей нужно связать мощное комбо с конкретными нажатиями клавиш. Конечно, у неё теоретически может быть лучше память, но в остальном я не вижу какого-то несправедливого преимущества перед обычным внимательным игроком (зачем равняться на «среднего»? Наша цель — победить лучших!).
Судя по коду, нет, занесены только возможные нажатия кнопок и их комбинации для получения различных базовых приёмов. Дальше система сама должна обнаружить комбо и их эффективные последовательности.
Вообще, не сильно понятнее стало. Как можно писать код на Java, когда код был на C и Lisp? Он имеет в виду, что писал на C и Lisp в стиле Java (или на Java в стиле C/Lisp)? Или он дописал часть кода на Java в эту сборную солянку, так что теперь она написана на трёх языках?
Хм, кого это — нас? Генерация нужна не только и не столько для ограниченности, а для установления очерёдности транзакций, чтобы можно было гарантировать, что одни транзакции произошли до других, и таким образом предотвратить двойной расход баланса. Ну и конечно же, без генерации нельзя гарантировать общую целостность блокчейна, потому как проверка правильности значения хэша с учётом сложности на момент генерации (а она выводится по таймштампам, количеству блоков за период времени и предыдущей сложности) позволяет доказать, что для генерации были потрачены определённые мощности в хэшах/сек, и что блоки не были созданы злоумышленником в произвольном количестве за малое время с нужными ему транзакциями. Есть же ещё proof-of-stake, не требующий майнинга, но к нему есть вопросы.
А ограниченность биткоина реализуется с помощью спланированной дефляции, но она заложена тоже вручную в алгоритм расчёта вознаграждения за блок, не является ограничением технологии и в целом не связана с блокчейном, за исключением привязки к номеру блока.
Блокчейн в основе своей — это распределённый таймштамп-сервер, его предназначение в установлении времени происхождения события. Транзакции не имеют прямого отношения к блокчейну, это уже пейлоад. Можно ведь сделать тот же биткоин без блокчейна, просто все хранят у себя балансы всех аккаунтов и корректируют их при транзакциях. Но в этом случае возникает проблема доверия к этой системе и проблема двойного расхода средств, нельзя достоверно определить, какая из двух транзакций с одного и того же баланса подлинная, а какая нет. Блокчейн закрепляет порядок операций во времени и гарантирует защиту от манипуляций с этим порядком, поэтому ему и доверяют. Но в целом там можно хранить любые данные, необязательно связанные друг с другом как транзакции, главное, чтобы туда включался таймштамп и чтобы внесение таких данных было защищено ЭЦП (иначе теряется аутентичность данных и весь смысл).
Например, при посещении врача пациент и врач шифруют и подписывают протокол приёма своими ключами, после чего отсылают в блокчейн. Данные сохраняются в блок с текущим временем и датой, после чего могут быть в любое время извлечены, проверены на подлинность и, при наличии ключа шифрования, расшифрованы. Ключ может быть сессионный (одноразовый) и шифроваться в двух экземплярах, ключом пациента и ключом врача (или медучреждения) и класться там же, рядом с данными. Так пациент и медучреждение, и только они, всегда смогут получить доступ к данным. Уже нельзя будет потерять карточку или перепутать порядок посещений или течение болезни (стало ли лучше или хуже после лечения).
Проблема лишь в генерации блоков, кто и с какой мотивацией будет это делать? В финансовых блокчейнах мотивация идёт от вознаграждения за генерацию, а тут… ну не знаю, может, генерировать коды скидок на лекарства. Создавший блок включает в него свой публичный ключ, а в аптеке можно потратить нагенерированное — аптека проверяет баланс предъявленного публичного ключа (число включений публичных ключей в блоки, минус число использований), даёт на подпись текущий таймштамп, после чего отсылает подписанный таймштамп в блокчейн, и он считается как расходная операция. В целом, опять биткоин получился, только без транзакций между участниками, есть только появление баллов и уничтожение.
Когда как. Даёт ложное чувство безопасности, не самая лучшая вещь. Но вообще я к тому, что эти понятия нельзя путать. Комментарий, который всё для меня лично прояснил: https://habrahabr.ru/company/mailru/blog/269337/#comment_8624955
Именно так сделано в Java. Но это более громоздко, зачем создавать экземпляр класса, если от него требуется выполнить всего лишь одну функцию? Лишние накладные расходы. А коллбэки понятно оформляются через std::function. Язык, в конце концов, мультипарадигменный, так что функциональный стиль тоже имеет право на жизнь.
Можно уточнить, что bind нужен не просто для вызова callback'ов, а когда необходимо передать в callback дополнительные параметры. Проблема в том, что сигнатура callback-функции обычно жёстко задана, так что если нужно передать что-то ещё в неё, приходится опираться либо на какие-то переменные в более широком scope (поля класса или даже глобальные переменные, хоть это и фу-фу-фу), либо биндиться. Первый случай имеет ограниченное применение: что если потребуется вызвать два и более одинаковых коллбэка сразу, например, запустить два процесса чтения каких-то данных из сокетов, а по завершении функция чтения вызовет один и тот же коллбэк? Часто нужно как-то различать, откуда именно был вызван коллбэк, чтение какого именно сокета завершено, чтобы отреагировать верно, а переменная у нас лишь одна.
В этом случае bind спасает, мы делаем коллбэк с бо́льшим числом параметров, чем нужно для стандартной/библиотечной/чужой функции, биндим к нашим собственным параметрам некоторые значения, а те, про которые «знает» чужая функция, заменяем placeholder'ами. Получается такая себе rvalue-функция, которая сигнатурно совпадает с ожидаемой, но при вызове подставит наши заранее привязанные значения к нужным параметрам и вызовет уже нашу расширенную функцию.
Короче говоря, это такой сигнатурный адаптер, только не для классов, а для функций. По крайней мере, мне в голову не приходят другие применения.
Вы имеете в виду вот это? Тут нет ничего удивительного, конечно же, стандартную библиотеку оптимизируют вручную для разных архитектур, если есть такая возможность. Но речь шла о компиляторе, который компилирует пользовательский код. В этом случае он тоже сумеет автоматически, без помощи разработчика, использовать расширенный набор инструкций, присущий целевой платформе?
Здесь говорится о более компактном и эффективном коде, но я не вижу ничего касающегося платформозависимых оптимизаций. Полагаю, что компактность и эффективность опять же относится к общим для всех платформ оптимизациям (это хорошо, конечно). Потому что находить возможности для применения векторных инструкций, судя по приведённой мной ссылке на статью, не так-то просто. А если это делается, то смысл уже этой статьи ускользает от меня.
Скажем, если на какой-то платформе отсутствует инструкция умножения или деления (например, на микроконтроллерах), то либо придётся делать для этой платформы хак в виде сложений/сдвигов, либо делать хак в виде одной инструкции умножения для платформ, где оно есть, либо везде использовать сложения/сдвиги. И судя по вот этой статье будет применяться именно последний вариант.
Хмм… всё это хорошо, конечно, но такой код вряд ли будет высокопроизводительным. По сути, универсальный ассемблер — это «наибольший общий делитель» всех архитектур. Но каждая платформа имеет свои особенности, а x86/amd64, в частности, большое количество дополнительных инструкций, позволяющих в разы ускорить вычисления. Взять хотя бы эту статью. Как я понял, Go никак не стремится использовать эти расширения, т.к. они не кроссплатформенны.
ТТК-Север — нативный IPv6 уже не первый год. К сожалению, адрес динамический, хотя при таких-то пулах (по /64 на клиента) могли бы и статику выдать.
Так одно дело, когда продавцы, другое дело — рандомные люди из магазина с праздным любопытством. Не думаю, что стоит вообще оставлять неопределённому кругу лиц триплет «внешность — фамилия/имя — список покупок». Конечно, это просто моя паранойя, скорее всего, но в таких делах лучше перебдеть.
К уже упомянутым плюсам добавлю свои:
— скорость платежа намного выше;
— пин для разблокировки приложения можно ввести заранее, стоя в очереди, а не как с карточкой, на кассе;
— карта от частого использования изнашивается, чип начинает читаться иногда не с первого, а то и не со второго раза; впрочем, обычно к этому моменту уже пора перевыпускать карту, но всё равно неудобства бывают;
— при оплате через приложение Qiwi, например, на чеке не будет вашего имени-фамилии, я по этой причине всегда забираю чеки с собой, незачем кому попало знать, что такой-то человек покупает то-то.
— проще контролировать расходы, уже сказали, что баланс виден непосредственно.
Недавно была атака на банки, так вот Сбербанк Онлайн выдавал пусть и не бектрейсы, но исключения Java с указанием имён пэкейджей и классов. В частности, про невозможность Hibernate подключиться к БД или ошибки рефлексии. Не то чтобы прямо что-то критичное, но я несколько удивился. Ещё раньше на запуске нынешней системы на Java у них и трейсы вылетали целиком, сейчас, вроде, убрали.
Разница очень даже большая. Если комбо забиты заранее, это не только даёт преимущество, но и снижает ценность работы — обучение идёт уже не от условного нуля. А так сеть самостоятельно выясняет выигрышные комбинации, причём, как и человеку, ей нужно связать мощное комбо с конкретными нажатиями клавиш. Конечно, у неё теоретически может быть лучше память, но в остальном я не вижу какого-то несправедливого преимущества перед обычным внимательным игроком (зачем равняться на «среднего»? Наша цель — победить лучших!).
Судя по коду, нет, занесены только возможные нажатия кнопок и их комбинации для получения различных базовых приёмов. Дальше система сама должна обнаружить комбо и их эффективные последовательности.
«Когда у языка нет статической дифференциации типов, то нет цели!»
Мне было совсем не очевидно, спасибо. Как-то остров в голову не пришёл.
Вообще, не сильно понятнее стало. Как можно писать код на Java, когда код был на C и Lisp? Он имеет в виду, что писал на C и Lisp в стиле Java (или на Java в стиле C/Lisp)? Или он дописал часть кода на Java в эту сборную солянку, так что теперь она написана на трёх языках?
Скорее, что эти дистрибутивы не будут навязывать пользователю несвободное ПО с потенциально опасными/недекларированными возможностями.
Уже сделали: https://steem.io/
А ограниченность биткоина реализуется с помощью спланированной дефляции, но она заложена тоже вручную в алгоритм расчёта вознаграждения за блок, не является ограничением технологии и в целом не связана с блокчейном, за исключением привязки к номеру блока.
Например, при посещении врача пациент и врач шифруют и подписывают протокол приёма своими ключами, после чего отсылают в блокчейн. Данные сохраняются в блок с текущим временем и датой, после чего могут быть в любое время извлечены, проверены на подлинность и, при наличии ключа шифрования, расшифрованы. Ключ может быть сессионный (одноразовый) и шифроваться в двух экземплярах, ключом пациента и ключом врача (или медучреждения) и класться там же, рядом с данными. Так пациент и медучреждение, и только они, всегда смогут получить доступ к данным. Уже нельзя будет потерять карточку или перепутать порядок посещений или течение болезни (стало ли лучше или хуже после лечения).
Проблема лишь в генерации блоков, кто и с какой мотивацией будет это делать? В финансовых блокчейнах мотивация идёт от вознаграждения за генерацию, а тут… ну не знаю, может, генерировать коды скидок на лекарства. Создавший блок включает в него свой публичный ключ, а в аптеке можно потратить нагенерированное — аптека проверяет баланс предъявленного публичного ключа (число включений публичных ключей в блоки, минус число использований), даёт на подпись текущий таймштамп, после чего отсылает подписанный таймштамп в блокчейн, и он считается как расходная операция. В целом, опять биткоин получился, только без транзакций между участниками, есть только появление баллов и уничтожение.
В этом случае bind спасает, мы делаем коллбэк с бо́льшим числом параметров, чем нужно для стандартной/библиотечной/чужой функции, биндим к нашим собственным параметрам некоторые значения, а те, про которые «знает» чужая функция, заменяем placeholder'ами. Получается такая себе rvalue-функция, которая сигнатурно совпадает с ожидаемой, но при вызове подставит наши заранее привязанные значения к нужным параметрам и вызовет уже нашу расширенную функцию.
Короче говоря, это такой сигнатурный адаптер, только не для классов, а для функций. По крайней мере, мне в голову не приходят другие применения.