Как на уровне байткода будут выглядеть геттеры и сеттеры в Kotlin?
Можно написать пару маленьких программок и декомпилировать.
геттеры и сеттеры будут реализованы как методы getVarName() и setVarName(...)
Но мне синтаксис Scala кажется более простым. В kotlin больше сущностей и ключевых слов.
Например, для переопределения += в scala достаточно создать метод с очевидным названием "+=", причём нет никаких ограничений на тип и количество аргументов — это самый обычный метод, а не какая-то дополнительная сущность.
В kotlin придётся написать в стиле operator fun plusAssign , что не совсем интуитивно (приходится вспоминать, что и как называется), и есть ограничения — метод не может возвращать значение.
Причём в kotlin можно переопределить только небольшой список операторов, а в scala свободы побольше (например, можно определить := или ++=).
На самом деле, scala-метод типа += будет создан с именем "$plus$eq", которое не очень удобно вызывать из java. Было бы идеально, если бы в kotlin стало можно давать методам имена типа "+", которые на самом деле отображались бы в "plus" и.т.п.
Или, например, синтаксис объявления метода:
В scala: def methodName(...) = {...}
В kotlin возможны два варианта — как в scala (со знаком =) и как в java (без него), но эти два способа объявления неэквивалентны друг другу и работают немного по-разному, я однажды кучу времени потратил на поиск такой "особенности" в коде.
Null-safety: интересная штука, но на практике во все публичные методы добавляются проверки для каждого аргумента на null. Мне кажется несколько избыточным — и есть подозрение, что это негативно влияет на производительность. (Там не просто проверка, а вызов статического метода с передачей объекта-параметра и его имени как строки, чтобы можно было кинуть понятное исключение)
Что понравилось в kotlin:
1) inline. Никаких созданий объектов, просто подстановка тела функции.
2) extensions. Тоже удобная штука — и никаких потерь производительности.
В Scala похожая функциональность сделана через implicit-преобразования, из-за чего при вызове создаётся ещё один объект.
У меня нетбук asus 1215n (был куплен около пяти лет назад). Экран 1366*768, тоже 2гб оперативной памяти, внутри нормальный жёсткий диск вместо жалких 32гб. Когда-то прошёл на нём gta san andreas и call of duty. Единственное явное преимущество этого планшета перед нетбуком пятилетней давности — небольшой вес.
Автор очень оптимистичен в подведении итогов. Как на замену ноутбуку на планшет смотреть нельзя:
1) мелкий экран
2) 2 гигабайта памяти это браузер+среда разработки, и среда разработки может тормозить.
3) Про игры лучше вообще не вспоминать. Gta III и call of duty — не то, во что хочется поиграть в 2016 году.
Странная статья. Из описанных двух оптимизаций — отключить смешивание и поменять порядок рисования — ни одна не является чем-то экстраординарным, они никак не связаны с x86 и должны работать везде.
Возможности Graphics Frame Analyzer тоже не раскрыты. Судя по всему, с его помощью многое можно измерить — но в статье даже картинки интерфейса уменьшенные и некликабельные, об особенностях его работы остаётся только догадываться.
В примере на С++ можно было бы не использовать дополнительную память.
Если я правильно понимаю, функция выдаёт независимые биты, и потому не важно, в каком порядке мы их спрашиваем. Можно по аналогии с qSort идти от начала, запрашивая рандомные биты, пока не наткнёмся на 1, а потом двигаться с конца, пока не получим 0.
Не совсем. В ноутбуке может стоять мощное железо, из-за маркетинговых соображений очень плотно размещённое в тонком корпусе. В итоге получается, что некоторые ноутбуки могут выдать максимальную мощность ненадолго (чего достаточно обычному пользователю), но перегреваются при постоянной нагрузке (игры, обработка видео и прочее).
Мне кажется, тема недостаточно раскрыта.
Во-первых, использование batch при рисовании скрывает особенности того, как это всё работает. Для понимания происходящего было бы полезно вручную задать юниформы, атрибуты и вызвать функцию рисования.
Во-вторых, описание вершинного шейдера тоже не способствует понимаю. Я бы посоветовал новичкам написать gl_Position = a_position; и поиграться с разными значениями атрибутов, чтобы хорошо представлять, как это всё работает. (от -1 до 1 по x и y, при этом координаты однородные и на самом деле используются значения x/w, y/w).
В принципе, если кому-то нужно — могу написать небольшую статью.
Всё-таки мне кажется, что переход от индивидуальной разработки к командной — своеобразный level up. Очень круто, что современные технологии и инструменты позволяют создать всё необходимое в одиночку, но задумайтесь: где-то ещё в мире наверняка есть такие же люди, обладающие своими уникальными талантами и создающие свои игры. В каждой технологии есть порог вхождения, необходимы усилия, чтобы поддерживать опыт в актуальном состоянии — делать всё в одиночку не очень рационально по времени. Кажется неплохим вариантом, когда, например, художник и программист создают каждый по «игре своей мечты», но помогают друг другу.
Например, в том, что до применения «Stretch» ландшафт выглядел намного правдоподобнее. Может, это дело вкуса, но однообразные горы с нереально крутыми склонами смотрятся странно.
P.S. Мне кажется, дело не в программе, а в том, кто ей пользуется.
А если пешеход специально выйдет на дорогу, чтобы грузовик улетел в кювет? Я не думаю, что этого «шантажиста»-пешехода потом найдут, а ущерб владельцу грузовика будет большим. Можно провести аналогию с поездами: у них огромный тормозной путь, и если поезд сбивает человека, то машинист не виноват — потерпевший сам должен был думать головой.
Конечно, если есть возможность затормозить, надо ей пользоваться, но не более того.
Метод users.get доступен без авторизации. Когда я делал что-то схожее, грузил данные в 64 потока. Ответ на запрос приходит с задержкой в доли секунды, а время передачи файлика, имхо, намного меньше. Получалось, если меньше 64 потоков — медленнее, больше — упирался в скорость интернета (или мне так казалось).
Не обязательно котиками. Выше в статье приводился пример произвольных замен в тексте. Правда, тут есть косяк: не думаю, что нормальный человек будет этим заниматься. Довольно тяжко подбирать разные слова. Лучше выбирать простейший способ хеширования и передавать в слове бит. Я сейчас попробовал взять чётность количества букв. Ужасно долго:( Куча усилий для передачи даже одного простого слова.
В идеале сжатый и оттого сильно нагревшийся воздух можно охлаждать, отводя и сохраняя тепло, которое пригодится для подогревания газа при его расширении.
В итоге конструкция сильно сложнее получится. (Или можно забить и просто подогревать расширяющийся газ от водоёма).
Мне кажется, википедию как раз блокируют, чтобы отвлечь внимание от дальнобойщиков. Время «исследований» роскомпозора ни от чего не зависит и может быть подогнано к любому нужному моменту.
P.S. Возможно, я не прав.
Последнее утверждение выглядит спорным. На андроиде можно сделать многое. (И даже без рута можно сделать так, чтобы приложения не могли лезть в интернет — во многих случаях этого достаточно)
P.S. Я был очень удивлён, когда декомпилировал одно приложение-фонарик. Весь интерфейс состоял из одной-единственной кнопки, но в коде были какие-то классы от фейсбука.
Не совсем. Обмен «рубли->биткоины» осложняется тем, что вторая сторона, которая получает от Вас рубли, либо нарушает закон, либо должна находиться вне юрисдикции РФ.
Думаю, будет проще менять с использованием промежуточной валюты.
Направление можно проще прикинуть — Луна будет примерно там же, где находится Солнце перед закатом (траектории движения Солнца и Луны по небу почти совпадают, 4 часа — почти утро, а Луна находится прямо противоположно Солнцу, так как полнолуние)
У меня были наполеоновские планы сделать клиент-серверную архитектуру, на сервере считать положение более точными методами, на клиенте (телефоне) экстраполировать положение самолётов других игроков на время пинга вперёд (в зависимости от расстояния до самолёта брать разные шаги по времени). Поэтому расчёт следующего состояния вынесен в отдельный класс, а так же есть интерфейс Avatar для сокрытия того, как и откуда берётся состояние самолёта.
Но свободного времени не очень хватает для всех хотелок, я даже не уверен, что доведу проект до конца. В данный момент простейший способ вполне неплохо работает.
Реализацию Рунге-Кутты я бы в любом случае не стал сюда выкладывать, чтобы не слишком усложнять пример.
Можно написать пару маленьких программок и декомпилировать.
геттеры и сеттеры будут реализованы как методы
getVarName()иsetVarName(...)Но мне синтаксис Scala кажется более простым. В kotlin больше сущностей и ключевых слов.
Например, для переопределения
+=в scala достаточно создать метод с очевидным названием "+=", причём нет никаких ограничений на тип и количество аргументов — это самый обычный метод, а не какая-то дополнительная сущность.В kotlin придётся написать в стиле
operator fun plusAssign, что не совсем интуитивно (приходится вспоминать, что и как называется), и есть ограничения — метод не может возвращать значение.Причём в kotlin можно переопределить только небольшой список операторов, а в scala свободы побольше (например, можно определить := или ++=).
На самом деле, scala-метод типа += будет создан с именем "$plus$eq", которое не очень удобно вызывать из java. Было бы идеально, если бы в kotlin стало можно давать методам имена типа "+", которые на самом деле отображались бы в "plus" и.т.п.
Или, например, синтаксис объявления метода:
В scala:
def methodName(...) = {...}В kotlin возможны два варианта — как в scala (со знаком =) и как в java (без него), но эти два способа объявления неэквивалентны друг другу и работают немного по-разному, я однажды кучу времени потратил на поиск такой "особенности" в коде.
Null-safety: интересная штука, но на практике во все публичные методы добавляются проверки для каждого аргумента на null. Мне кажется несколько избыточным — и есть подозрение, что это негативно влияет на производительность. (Там не просто проверка, а вызов статического метода с передачей объекта-параметра и его имени как строки, чтобы можно было кинуть понятное исключение)
Что понравилось в kotlin:
1) inline. Никаких созданий объектов, просто подстановка тела функции.
2) extensions. Тоже удобная штука — и никаких потерь производительности.
В Scala похожая функциональность сделана через implicit-преобразования, из-за чего при вызове создаётся ещё один объект.
В win7 можно в проводнике в address-bar ввести «cmd», нажать enter и консолька откроется из текущей папки. Или Вы что-то другое имели ввиду?
Автор очень оптимистичен в подведении итогов. Как на замену ноутбуку на планшет смотреть нельзя:
1) мелкий экран
2) 2 гигабайта памяти это браузер+среда разработки, и среда разработки может тормозить.
3) Про игры лучше вообще не вспоминать. Gta III и call of duty — не то, во что хочется поиграть в 2016 году.
Возможности Graphics Frame Analyzer тоже не раскрыты. Судя по всему, с его помощью многое можно измерить — но в статье даже картинки интерфейса уменьшенные и некликабельные, об особенностях его работы остаётся только догадываться.
Если я правильно понимаю, функция выдаёт независимые биты, и потому не важно, в каком порядке мы их спрашиваем. Можно по аналогии с qSort идти от начала, запрашивая рандомные биты, пока не наткнёмся на 1, а потом двигаться с конца, пока не получим 0.
Во-первых, использование batch при рисовании скрывает особенности того, как это всё работает. Для понимания происходящего было бы полезно вручную задать юниформы, атрибуты и вызвать функцию рисования.
Во-вторых, описание вершинного шейдера тоже не способствует понимаю. Я бы посоветовал новичкам написать gl_Position = a_position; и поиграться с разными значениями атрибутов, чтобы хорошо представлять, как это всё работает. (от -1 до 1 по x и y, при этом координаты однородные и на самом деле используются значения x/w, y/w).
В принципе, если кому-то нужно — могу написать небольшую статью.
P.S. Мне кажется, дело не в программе, а в том, кто ей пользуется.
Конечно, если есть возможность затормозить, надо ей пользоваться, но не более того.
В итоге конструкция сильно сложнее получится. (Или можно забить и просто подогревать расширяющийся газ от водоёма).
P.S. Возможно, я не прав.
P.S. Я был очень удивлён, когда декомпилировал одно приложение-фонарик. Весь интерфейс состоял из одной-единственной кнопки, но в коде были какие-то классы от фейсбука.
Думаю, будет проще менять с использованием промежуточной валюты.
Но свободного времени не очень хватает для всех хотелок, я даже не уверен, что доведу проект до конца. В данный момент простейший способ вполне неплохо работает.
Реализацию Рунге-Кутты я бы в любом случае не стал сюда выкладывать, чтобы не слишком усложнять пример.