Обновить
195
0.8

Программист

Отправить сообщение

На хабре можно голосовать и в плюс и в минус, а в некоторых других платформах — только лайкать. В итоге провокационный контент, вызвавший сильную положительную реакцию у 10% пользователей и при этом не нравящийся остальным 90%, в инстаграмме взлетит, а на хабре нет.

Маленький вопрос: насколько это распознавание устойчиво к повороту баркода? Например, на 20 или 45 градусов.

Но тем не менее minecraft остаётся всё таким же квадратным. Я думал, что иначе нельзя, пока не увидел графику в portal knights:


картинка

image


видео
Из коробки в игре есть хорошие освещение и тени, отражения в воде. Кроме того, в мире активно используются элементы неквадратной формы (некоторые занимают по несколько блоков) — деревья, заборчики, трава и прочие декорации, благодаря которым картинка выглядит намного более живой. А ещё есть киллер фича — текстура блока зависит от того, какие блоки располагаются рядом. На картинке это видно как более яркую плитку по краям или обрамление вокруг окон/дверей и на углах зданий.


К сожалению, разработчики игры свернули куда-то не туда и убийцы майнкрафта не получилось, но по графике она далеко впереди.

Я не пишу на Dart, но почему бы добавить метод, который будет принимать две лямбды (для left и right частей) и вызывать одну из них?
Чтобы выглядело не так:


if (either.isRight) {
    final contact = either.right;
    yield ContactIsShowingState(contact);
} else {
    final failure = either.left;
    if (failure is NetworkFailure) yield NetworkFailureState(failure);
    if (failure is UnknownFailure) yield UnknownFailureState(failure);
}

А как-то так:


either.foreach(
    contact => { yield ContactIsShowingState(contact) },
    failure => {
        if (failure is NetworkFailure) yield NetworkFailureState(failure);
        if (failure is UnknownFailure) yield UnknownFailureState(failure);
    }
)

Ага, когда читал, подумал, что можно было бы сделать хитрое пубичное поле с переопределёнными операторами присваивания для установки/чтения значения, но статья как-то внезапно закончилась.


Я так не пробовал, просто пришедшая в голову идея:


struct Person{
    Property<std::string> name("");
    Property<int, private_setter=true> id(0, setter=[](int value){ assert(value >= 0); return value;});
}

Самое важное не написали: фишка B-дерева в том, что жёсткий диск читает/пишет данные большими кусочками зараз (например, по 4кб), и количество потомков в вершине подбирается под это ограничение. Получается очень "невысокое" дерево, хорошо подходящее для хранения на диске. Диск сильно медленнее процессора, поэтому мы можем себе позволить хранить потомков в массиве и поддерживать их упорядоченность при вставке/удалении — всё равно перезапись делается кусками по 4кб (или сколько там в новых)

Теоретически, статическая типизация котлина должна давать преимущества, но я попробовал перевести код на котлин и мне совсем не понравилось: код стал более нагруженным, динамическая суть происходящего лезет отовсюду и появляются разные костыли для её обхода. Надеюсь, в будущем доведут до ума.

Мне вообще кажется, что предпочитаемая скорость движения и безопасность вождения очень слабо связаны друг с другом. Достаточно посмотреть, как некоторые "аккуратные, медленные" водители резко дёргают руль прямо в повороте/при перестроении/объезде маленькой кочки или резко жмут на тормоз без причины, как начинаешь сомневаться в безопасности.
Да, я привык в тот же поворот заходить на условных 80 вместо 60, но если я окажусь там в дождь/гололёд/ночью, то сбавлю скорость и пройду его так же плавно, как и на большой скорости, только потихоньку. Если в гололёд начнёт заносить машину, я опять же без проблем выйду из заноса (возможно, это заслуга электроники, а не меня, но суть в том, что я привык чувствовать грань сноса и знаю, что делать дальше). Неторопливые водители, которым небольшая скорость прощает кривое управление, просто не привыкли к таким ситуациям и в сложных условиях оказываются не способны правильно среагировать.

Прочитал их аргументы, почему выбрали swift. Убедительным не показалось. Динамическая типизация — ну ок, не подходит (хотя спорно, для каких-то применений это и плюс, python не просто так популярен). JVM языки — ну ок, не все хотят зависеть от JVM и особенностей реализации.
Но аргументы против С++ и Раста какие-то неубедительные. Tensorflow сама по себе написана на плюсах, было бы логично их и дальше использовать, предоставляя сишное api для желающих использовать из какого угодно языка.

современный С++ разделить вообще почти нельзя.

Я думаю, имелись ввиду inline, constexpr и шаблонные функции/классы.

Я читал и жалел, что подобного курса не было у меня. Можно говорить, что российское образование впереди планеты всей и хакеры тоже, но на практике у меня в институте подобного курса в программе не было, да и вообще программа была довольно фиксированной без возможности выбрать курсы по своим хотелкам.


И я почему-то уверен, что если бы такой курс был, мало кто из наших студентов использовал бы немейнстримные языки типа Haskell/Rust/Okaml/Scala.


Что-то похожее по уровню хардкорности было в шаде, но он больше про машинное обучение, построения компиляторов и тому подобных курсов там нет.


  • В шаде на курсе по С++ писал интерпретатор лиспа. Как мне показалось, для подобных штук плюсы не очень удобно использовать, код получается довольно громоздким. Если бы я писал код на скале, было бы в 2-3 раза короче. Меня удивляет, что в статье выше код на плюсах получился не таким уж и большим — видимо, кто-то познал дзен и очень хорошо выбрал уровень абстракций.
  • Ещё (там же в шаде) на курсе по питону была домашка с интерпретатором питоновского байт-кода, написанном на питоне. Но, видимо, мой мозг слишком привык к статической типизации, т.к. динамическими фишками питона я почти не пользуюсь и в большинстве задач код получается таким же или дальше длинее, чем в скале.

P.S. А где вообще есть хорошие хардкорные курсы по классическому CS с построением компиляторов, алгоритмами и прочим? Интересуют как онлайн курсы, так и аспирантура в России/за границей.

Если не ошибаюсь, с каменными постройками вполне работает способ "сложить мини-модельку постройки и проверить её на устойчивость". Избыточная прочность камня на сжатие вполне позволяет такое масштабировать.

Ещё из-за этого вырастет стоимость жилья в центре города, т.к. все офисные центры там, и добираться туда долго. Получится как в Лондоне, где люди ютятся в крохотных квартирках, т.к. денег больше не стало, а жить не в центре сильно неудобно.

Ага. В реальности какая-то отвратительная карикатура получилась по сравнению с эскизом. Как можно настолько не любить автомобиль? И это при том, что у него аккумуляторы/двигатели/подвеска расположены внизу и не накладывают ограничений на дизайн кузова.

Неверно: He's got a beautiful house, that is located in a good neighborhood.
Верно: He's got a beautiful house, which is located in a good neighborhood.

А можно ли короче? "He's got a beautiful house located in a good neighborhood."

для каждой переменной и для каждой операции приходилось писать комментарий — сколько тут знаков до запятой и после:)

В с++ же есть шаблоны и их параметризация целыми числами. Почему бы информацию о положении точки не сделать частью типа? Тогда после компиляции эта информация пропадёт и на производительность не повлияет, но зато во время компиляции будет возможность поймать часть ошибок.

Это не только к F# относится, те же scala/rust/haskell реально круты и удобны, но из-за инерции мышления большинства людей они используются намного реже, чем заслуживают.

Самая дешёвая — это бесплатная — и она как раз была. Нет никакого достижения в том, чтобы начать за то же самое брать дееьги с пользователей.

На грузовиках водородный двигатель с быстрой заправкой и хорошим запасом хода будет явно предпочтительнее аккумуляторов.

Закон есть закон, и он должен соблюдаться одинаково для всех, а то как если невиновные сайты попадают под ковровые блокировки — это типа нормально, а как втентаклик получает жалобы от правообладателей, так его не хотят блокировать, хотя и должны.

Информация

В рейтинге
1 867-й
Откуда
Белград, Сербия
Зарегистрирован
Активность

Специализация

Десктоп разработчик, ML разработчик
Kotlin
Scala
Java
Python
Нейронные сети
Алгоритмы и структуры данных
Разработка под Android
OpenGL