Да, поддерживаю — часто сталкиваюсь с тем, что люди обьясняют простые вещи переусложненным языком, вплетают кучу математической терминологии, хотя хороший пример "на пальцах" очень способствует пониманию. Появляется "костяк", на который уже и можно накрутить математику.
Скорей всего, дело в том, что крайний левый бит отвечает за знак. А побитовый сдвиг сдвигает все биты (в том числе и знаковый), и непонятно, что будет в этом крайнем бите после сдвига.
P.S. Я тоже не C++ программист, поэтому это лишь мои догадки
Семантика переменной должна определяться по ее названию, а не по типу (и уж точно не по тому, какой тип коллекции использован для переменной).
Я с вами абсолютно согласен. Но здесь такой момент, что далеко не все программисты обладают достаточной квалификацией (а иногда и желанием) писать такой хороший код. И часто так бывает, что переменным присваивают неподходящие имена. Тогда хотя бы знание типа помогает разобрать такой код. Такой код встречается у многих проектах — например, я использую популярный движок libGDX — он opensource, поэтому я часто заглядываю в кишки, посмотреть как и что делается. Так там много чего попадается, что не попадает под определение «хороший код». Где-то красоту приносят в жертву оптимизации. В общем, надеяться на то, что в переменных всегда будут правильные имена нельзя :)
Если я вижу запись вида a[4] = 5, здесь есть два варианта: Dict или массив. Если я читаю незнакомый мне код, это однозначно заставит меня на секунду задуматься (вспомнить) две вещи: 1) что же такое «a» (какую роль играет эта переменная) 2) Какой тип этой переменной. В зависимости от типа эта переменная может играть разную роль.
UPD: Еще момент — приходится удерживать в памяти лишнюю сущность — знание, что из нескольких вариантов типов «а» является каким-то конкретным типом. Учитывая, что кратковременная память способна удерживать не так уж и много, разумно предположить, что лучше максимально освобождать ее на другие задачи.
Как по мне, лучше пусть язык не заставляет над таким задумываться. В какой-то мере это напоминает ситуацию из JavaScript — там вообще можно что угодно делать, но народ потихоньку пытается отходить на что-то более строгое — TypeScript, CoffeScript.
C# у меня оставил впечатление некой перегруженности (это лишь мое субьективное мнение). Например, в Dict доступ к обьекту можно получить, используя квадратные скобки — a[«key»]. Вроде бы приятно, но если, например, ключами будут числа — то запись вида a[4] уже однозначно нельзя трактовать — a это массив или Dict?
Я понимаю, что это с какой-то стороны мелочи, и это дело привычки, и IDE покажет тип обьекта. Но именно строгость и прямолинейность Java в этих вопросах (ах, программист, хочешь удобную работу с Map — окей, держи — map.put(«key», value"), value = map.get(«key»)) мне нравится. Мне нравится, что в большинстве случаев мне не нужно задумываться про то, что я пишу — я лишь переношу мысли с головы в код. Из C# у меня такого ощущения не возникало.
Опять-таки, я осознаю, что это очень субьективное мнение. Возможно, если бы я еще год-два писал на C#, я бы изменил свою точку зрения.
Простота и логичность. Я писал на Java порядка 5-7 лет (до этого стандартные турбо паскаль, делфи), потом немного писал на C#. Как по мне? Java являет собой именно ту средину между нужными возможностями и ненужными усложнениями языка. На java можно написать мобильную игрушку, и производительный сервер на netty, и в обеих случаях будет ощущение, что язык тебе помогает, а не мешает.
И все же, 5 секунд — это очень много для запуска Android-приложения (разве что относительно тяжелая игра). Что вы имеете в виду под запуском — время от нажатия иконки (и появления черного экрана) до появления какого-то сплеш-скрина?
А зачем вы делаете такой ужасный заголовок, из которого ничего не понятно? Что такое «Мобайл», что такое «Ритейл» (уверен, есть много людей на этом сайте, которые это тоже не знают)?
Такое уже есть — кинг, деберц, и т.д. Принцип один и тот же — брать взятки. А очки считаются по разному. Получились разные игры, в которых разная стратегия игры.
За втюхаем задорого — мы ничего никому не втюхиваем, ваш сарказм неуместен. Игра бесплатна, без in-apps. Есть реклама — я это упомянул в статье. Сейчас мы наращиваем словарь и добавляем новые возможности, когда все будет готово — задумаемся о монетизации. То есть, у нас сначала игра, в которую интересно играть, а потом монетизация.
Есть разница, как подсчитывать очки. В оригинальной Балде за слова одинаковой длины дается одинаковое количество баллов. А здесь можно собрать более короткое слово, но с более ценными буквами, и это даст больше баллов. То есть, здесь сделан уход от «собрать слово подлиннее» до «собрать более ценное слово, но не обязательно более длинное».
Как результат, здесь можно выстраивать определенную стратегию по составлению ценных слов. Например, вы можете один-два хода составлять не слишком ценные слова, готовя почву для действительно ценного слова (где есть «дорогие» буквы). А потом собрать это ценное слово, и окупить затраты на предыдущих не слишком ценных словах.
Вы считаете, что этого недостаточно, чтобы назвать это новой игрой?
Да, открытые исходники — это хорошо. Когда-то я правил баг с клавиатурой на Android, то таки залез в Android бэкенд, и таки поправил баг) Да и иногда просто удобно залезть в реализацию какого-то класса и понять, насколько эффективно делать те или иные вещи.
Да, вы правы — но так сделать может только человек. Я описал алгоритм поиска слова ИИ — увы, он может лишь добавить букву в конец цепочки или же в ее начало.
Почему не использую БД — несколько причин. Во первых, текстовый файл банально проще — его можно открыть в блокноте, поправить, добавить. А работать с БД сложней. Во вторых, нужно искать кросплатформенную БД — поскольку libgdx, то основная часть тестирования идет на десктопе, на Android лишь запускаю, и убеждаюсь, что все окей. И третий момент — я подозреваю, что мой оптимизированный под эту конкретную задачу (поиск «обрубков» слов) алгоритм будет все же быстрее — мне нужно до 10 операций сравнения в худшем случае на поиск слова, а так 5-7 операций.
Вполне возможно, что кто-то раньше уже придумал это — с другой стороны, фактически, вы играли в балду (или вы учитывали вес букв, когда составляли слова)?
Да, поддерживаю — часто сталкиваюсь с тем, что люди обьясняют простые вещи переусложненным языком, вплетают кучу математической терминологии, хотя хороший пример "на пальцах" очень способствует пониманию. Появляется "костяк", на который уже и можно накрутить математику.
Не 95%, а (95/112*100) = 85%
Скорей всего, дело в том, что крайний левый бит отвечает за знак. А побитовый сдвиг сдвигает все биты (в том числе и знаковый), и непонятно, что будет в этом крайнем бите после сдвига.
P.S. Я тоже не C++ программист, поэтому это лишь мои догадки
Я с вами абсолютно согласен. Но здесь такой момент, что далеко не все программисты обладают достаточной квалификацией (а иногда и желанием) писать такой хороший код. И часто так бывает, что переменным присваивают неподходящие имена. Тогда хотя бы знание типа помогает разобрать такой код. Такой код встречается у многих проектах — например, я использую популярный движок libGDX — он opensource, поэтому я часто заглядываю в кишки, посмотреть как и что делается. Так там много чего попадается, что не попадает под определение «хороший код». Где-то красоту приносят в жертву оптимизации. В общем, надеяться на то, что в переменных всегда будут правильные имена нельзя :)
UPD: Еще момент — приходится удерживать в памяти лишнюю сущность — знание, что из нескольких вариантов типов «а» является каким-то конкретным типом. Учитывая, что кратковременная память способна удерживать не так уж и много, разумно предположить, что лучше максимально освобождать ее на другие задачи.
Как по мне, лучше пусть язык не заставляет над таким задумываться. В какой-то мере это напоминает ситуацию из JavaScript — там вообще можно что угодно делать, но народ потихоньку пытается отходить на что-то более строгое — TypeScript, CoffeScript.
Я понимаю, что это с какой-то стороны мелочи, и это дело привычки, и IDE покажет тип обьекта. Но именно строгость и прямолинейность Java в этих вопросах (ах, программист, хочешь удобную работу с Map — окей, держи — map.put(«key», value"), value = map.get(«key»)) мне нравится. Мне нравится, что в большинстве случаев мне не нужно задумываться про то, что я пишу — я лишь переношу мысли с головы в код. Из C# у меня такого ощущения не возникало.
Опять-таки, я осознаю, что это очень субьективное мнение. Возможно, если бы я еще год-два писал на C#, я бы изменил свою точку зрения.
P.S. А еще в Java шикарнейшие enum.
За втюхаем задорого — мы ничего никому не втюхиваем, ваш сарказм неуместен. Игра бесплатна, без in-apps. Есть реклама — я это упомянул в статье. Сейчас мы наращиваем словарь и добавляем новые возможности, когда все будет готово — задумаемся о монетизации. То есть, у нас сначала игра, в которую интересно играть, а потом монетизация.
Как результат, здесь можно выстраивать определенную стратегию по составлению ценных слов. Например, вы можете один-два хода составлять не слишком ценные слова, готовя почву для действительно ценного слова (где есть «дорогие» буквы). А потом собрать это ценное слово, и окупить затраты на предыдущих не слишком ценных словах.
Вы считаете, что этого недостаточно, чтобы назвать это новой игрой?