Кажется найден первоисточник.
Выше я привёл хороший пример и даже угадал, вот наш автор. Он пытался решить проблему java.nio.BufferOverflowException при вызове getBytes(), когда строка имеет определенную длину (от 16777216 символов).
Есть ещё кое-что интересное, но не об этом.
Небольшая заметочка по теме…
К сожалению, у меня на i7 (предыдущего поколения) с build 1.8.0_144 баг не повторяется (ни со строкой, ни с последними примерами). Но и java без изменения не даёт собрать ваш код: по умолчанию все дробные числа имеют тип double, поэтому строчка из последних примеров
float result = 1.0;
собирается только с явным указанием типа (без преобразования самим компилятором, иначе ошибка: «incompatible types: possible lossy conversion from double to float»). То есть так:
float result = 1.0f;
Влияет ли это как-то на генерацию дальнейшего асм-кода ещё не смотрел.
P.S. Об этом даже в вики сказано и есть аналогичные примеры:
float pi = 3.14f; // При использовании типа float требуется указывать суффикс f или F
float anotherPi = (float) 3.14; // Можно привести явно
Где вы видели random, возвращающий именно случайное число?
Хорошо, пусть это псевдослучайное число или даже другая функция, которая при каждом вызове возвращает следующее значение некой последовательности чисел (вспоминаем python, его yield, итераторы и генераторы). Передавая одни и те же входные данные, будем получать разные результаты. Правильно ли я понял, эти функции не чистые по определению выше и не могут быть использованы в ФП?
P.S. Немного промахнулся в ответе на сообщение s-kozlov
Функциональное программирование — это парадигма использования чистых функций в качестве неделимых единиц композиции, с избеганием общего изменяемого состояния и побочных эффектов.
Чистая функция:
Получая одни и те же входные данные, всегда возвращает один и тот же результат
Как быть с random? Эта функция получает одинаковые данные (интервал чисел), но всегда возвращает случайное число из заданного интервала. Получается она не чистая и не может быть использована в ФП по определению выше.
Здорово!
Тоже сталкивался и теперь я знаю, что это было и как я тупил… Давно, когда я учился и писал на ассемблере под голое железо, не мог понять почему код вылетал на не выполняемых инструкциях (даже после явного перескока этих инструкций с помощью jmp). Как только я убирал те строки всё становилось ОК. Тогда я тоже пришёл к выводу, что они выполняются, но почему и как я не додумался. На вопросы знатоки объясняли, что кэш с предсказателем только кэширует наперёд и ничего выполнять не может. Поверил в кривой код и свои ошибки, а дело то было в железе и недостатке знаний… =)
Статья интересная, но на превьюшке для затравки алгоритм отработал странно. Вместо ожидаемого одного треугольника, видим два.
Кого это заинтересует + найдётся время изучить предложенные алгоритмы генерации (с текущими исходниками) — думаю там есть что улучшить и написать хорошую статью.
Хорошая попытка пиара в не самое лучшее время. Считаю абсолютная ложь, цитата из статьи:
3
Лишь три компании поинтересовались опытом работы.
Три компании сразу выдвинули условия оффера.
2
Две компании проводят вступительные тестовые испытания кандидатов.
Всего две компании попросили рассказать о дополнительном образовании.
1
Только одна компания проводит специальное вступительное техническое собеседование длительностью в несколько часов.
Одна компания проводит очное вступительное испытание кандидатов.
Одна компания интересуется рекомендациями с предыдущих мест работы.
Одна компания придает значение высшему образованию кандидата.
Одна компания проводит собеседования на заявленных кандидатом иностранных языках.
Одна компания-гигант согласилась принять нашего кандидата на работу!
Если рассматривать позицию программиста (даже начинающего джуна на Руси), то из 40 компаний более 20 выдадут вступительное тестовое задание, посмотрят портфолио. Примерно 5 из 40 заинтересуются иностранным языком кандидата. Все проведут собеседование. И только у Вас в статье кидают фантастические офферы сразу. Не смешите!
По степени важности: реклама, графика, музыкальное сопровождение — такие ошибки видятся по трейлеру в посте.
Больше всего меня заинтересовал пункт 4. Продвигать игру в процессе разработки это верно и правильно, но тут и основная нераскрытая проблема. Как пишет автор, тематические сайты, специальные сообщества и темы в соц.сетях, раскрутка и обзоры не помогают маленьким проектам. Часто привлечение составляет около десятка человек.
Есть ли на хабре статьи под этот случай с рекомендациями (для маленьких команд)? Как заинтересовать людей на этапе разработки? Как получить отзывчивую аудиторию и первых фанатов? и т.д.
Не буду оригинален, сказав:
Игровой движок, как и любой другой инструмент, нужно выбирать исходя из задач продукта и навыков-знаний команды. Потребовалось что-то необычное или команда не смогла использовать, доработать купленный движок (странно почему, но такое тоже бывает) — прямой путь к разработке своего (или скорее гибели проекта).
Поэтому опрос несколько некорректен. Например, для простых 2D игр и мизерной команды (или одиночки) я с удовольствием возьму Corona SDK. Но 3D на ней я не сделаю, и тут уже будем выбирать серьёзней по планируемым задачам.
Статья большая, странная…
Хороший исторический срез, это полезно знать. В некоторых местах не помешало бы добавить примеров и побольше подробностей.
Спасибо за интересную статью!
В ответе на Ваш вопрос, я поддержу критику против моей же идеи. Наборы немного лучше объектов и дают больше свободы. Как писали выше, сейчас есть сложность их применения.
Наборы глубже пронизывают весь язык, чем объекты в Java или C#. В последних языках есть базовые типы (например, byte), посмотреть и контролировать реализацию которых Вы не можете (обычно это не минус, когда речь об одной архитектуре). Все числа преобразуются к этим типам в процессе компиляции. Нередко отдельно рассказывают устройство стандартного массива в языке. В Сигма стремимся убрать эти чёрные ящики, есть числа и наборы. Вместе они описывают всё — от самого приложения до самого базового типа интересующей нас архитектуры.
В теории появляются новые возможности. Например, применяя аспектно-ориентированное программирование прямо в процессе работы приложения возможно убирать и добавлять инструкции в специальных точках соединения (определённых срезом). На практике всех интересует как это будет реализовано на определённой архитектуре, чтобы после оптимизации не выглядело хуже уже существующих решений. Выполнить такие оптимизации возможно, но тогда наборы для людей выглядят тем чёрным ящиком, стыкующим логику и железо. Этого можно избежать, позволив описывать архитектурный код в языке.
Продолжаем Вас вербовать.
Это будет аналог and, теперь начинайте кричать «пропал or». Уже жду.
Так как же решается проблема с использование bit в if?
В bit реализовано сравнение с числом, с состоянием и с bit'ом. Лучший существующий аналог это перегрузка оператора в С++.
Про последний пример кода: а чего Вы ожидаете от сравнения наборов, тем более разных типов? Если нужна булева алгебра, сделайте a, b и c наборами типа bit и тогда сравнивайте их между собой.
Вы же в других языках не сравниваете строку и число напрямую?
Темы затронуты хорошие, но я же в самом верху статьи написал, что не преуспел в этом вопросе. Есть вопросы, на которые я пока тоже не знаю ответа, но это не повод говорить стоп для исследователя. Концепция отличная от всего имеющегося есть, базис есть, я поделился идеей с комьюнити. Зря большинство, вместо развития, подводит к мысли выкинь и забудь.
Где другие могут видеть дорогу, у Вас полная шляпа.
Всё не так плохо, на крайний случай if может принимать несколько множеств. Выглядеть это может примерно так: if ( a == b, c == d ) {}
До конца ещё не проработал, но проблемы нет. Приведённый вариант не самый лучший.
Это операция, она может быть переопределена программистом. Если a и b — наборы одного пользовательского типа, то и результат набор пользовательского типа.
Вместо bool теперь будет использоваться bit для работы с двоичной архитектурой. Для набора bit определены булевы операции (подобно операциям присвоения, то есть можно будет код посмотреть). Аналогично для других архитектур.
Можно оставить для состояний только is и добавить какое-либо ключевое слово для перевода набора в нужное состояние. Например, in. Как на Ваш взгляд это повлияет на читаемость?
Можете предложить и свои варианты реализации наборов и операций над ними.
На мой взгляд это направление перспективно для развития языка программирования. Как минимум что-то новое и не топтаться на месте.
Вы перепутали сравнение наборов со сравнением состояний.
a == b сравнивает наборы одного пользовательского типа
a == Invalid сравнивает состояние в рамках набора а
По второму случаю я где-то уже писал текущий минус: пока описываются только тождественные условия в состояниях. То есть неравенства сейчас не принимаются. Я над этим работаю.
Я за хорошую документацию и хорошую реализацию (соответствующую документации), но повышение прозрачности кода и самодокументирующиеся конструкции Вам в помощь. Идея в том, чтобы Вы смогли заглянуть ниже (в момент, когда будет интересно или когда понадобится) и понять это устройство, даже если документации нет.
Да, это редко нужно. Об этом не хотят говорить, что я отметил в статье.
Видимо Вы не сталкивались с упомянутыми проблемами. Сейчас не найду подходящего примера, но как пример рекомендую послушать это с 16:50. Миф документации чуточку развеется.
Интересует вопрос лицензии распространения? Будут ли исходные коды Open Source? И если да, то когда (или где уже сейчас) их можно увидеть?
Выше я привёл хороший пример и даже угадал, вот наш автор. Он пытался решить проблему java.nio.BufferOverflowException при вызове getBytes(), когда строка имеет определенную длину (от 16777216 символов).
Есть ещё кое-что интересное, но не об этом.
К сожалению, у меня на i7 (предыдущего поколения) с build 1.8.0_144 баг не повторяется (ни со строкой, ни с последними примерами). Но и java без изменения не даёт собрать ваш код: по умолчанию все дробные числа имеют тип double, поэтому строчка из последних примеров собирается только с явным указанием типа (без преобразования самим компилятором, иначе ошибка: «incompatible types: possible lossy conversion from double to float»). То есть так: Влияет ли это как-то на генерацию дальнейшего асм-кода ещё не смотрел.
P.S. Об этом даже в вики сказано и есть аналогичные примеры:
Хорошо, пусть это псевдослучайное число или даже другая функция, которая при каждом вызове возвращает следующее значение некой последовательности чисел (вспоминаем python, его yield, итераторы и генераторы). Передавая одни и те же входные данные, будем получать разные результаты. Правильно ли я понял, эти функции не чистые по определению выше и не могут быть использованы в ФП?
P.S. Немного промахнулся в ответе на сообщение s-kozlov
Как быть с random? Эта функция получает одинаковые данные (интервал чисел), но всегда возвращает случайное число из заданного интервала. Получается она не чистая и не может быть использована в ФП по определению выше.
Тоже сталкивался и теперь я знаю, что это было и как я тупил… Давно, когда я учился и писал на ассемблере под голое железо, не мог понять почему код вылетал на не выполняемых инструкциях (даже после явного перескока этих инструкций с помощью jmp). Как только я убирал те строки всё становилось ОК. Тогда я тоже пришёл к выводу, что они выполняются, но почему и как я не додумался. На вопросы знатоки объясняли, что кэш с предсказателем только кэширует наперёд и ничего выполнять не может. Поверил в кривой код и свои ошибки, а дело то было в железе и недостатке знаний… =)
Кого это заинтересует + найдётся время изучить предложенные алгоритмы генерации (с текущими исходниками) — думаю там есть что улучшить и написать хорошую статью.
Если рассматривать позицию программиста (даже начинающего джуна на Руси), то из 40 компаний более 20 выдадут вступительное тестовое задание, посмотрят портфолио. Примерно 5 из 40 заинтересуются иностранным языком кандидата. Все проведут собеседование. И только у Вас в статье кидают фантастические офферы сразу. Не смешите!
Больше всего меня заинтересовал пункт 4. Продвигать игру в процессе разработки это верно и правильно, но тут и основная нераскрытая проблема. Как пишет автор, тематические сайты, специальные сообщества и темы в соц.сетях, раскрутка и обзоры не помогают маленьким проектам. Часто привлечение составляет около десятка человек.
Есть ли на хабре статьи под этот случай с рекомендациями (для маленьких команд)? Как заинтересовать людей на этапе разработки? Как получить отзывчивую аудиторию и первых фанатов? и т.д.
Игровой движок, как и любой другой инструмент, нужно выбирать исходя из задач продукта и навыков-знаний команды. Потребовалось что-то необычное или команда не смогла использовать, доработать купленный движок (странно почему, но такое тоже бывает) — прямой путь к разработке своего (или скорее гибели проекта).
Поэтому опрос несколько некорректен. Например, для простых 2D игр и мизерной команды (или одиночки) я с удовольствием возьму Corona SDK. Но 3D на ней я не сделаю, и тут уже будем выбирать серьёзней по планируемым задачам.
Статья большая, странная…
Спасибо за интересную статью!
В ответе на Ваш вопрос, я поддержу критику против моей же идеи. Наборы немного лучше объектов и дают больше свободы. Как писали выше, сейчас есть сложность их применения.
Наборы глубже пронизывают весь язык, чем объекты в Java или C#. В последних языках есть базовые типы (например, byte), посмотреть и контролировать реализацию которых Вы не можете (обычно это не минус, когда речь об одной архитектуре). Все числа преобразуются к этим типам в процессе компиляции. Нередко отдельно рассказывают устройство стандартного массива в языке. В Сигма стремимся убрать эти чёрные ящики, есть числа и наборы. Вместе они описывают всё — от самого приложения до самого базового типа интересующей нас архитектуры.
В теории появляются новые возможности. Например, применяя аспектно-ориентированное программирование прямо в процессе работы приложения возможно убирать и добавлять инструкции в специальных точках соединения (определённых срезом). На практике всех интересует как это будет реализовано на определённой архитектуре, чтобы после оптимизации не выглядело хуже уже существующих решений. Выполнить такие оптимизации возможно, но тогда наборы для людей выглядят тем чёрным ящиком, стыкующим логику и железо. Этого можно избежать, позволив описывать архитектурный код в языке.
Это будет аналог and, теперь начинайте кричать «пропал or». Уже жду.
В bit реализовано сравнение с числом, с состоянием и с bit'ом. Лучший существующий аналог это перегрузка оператора в С++.
Про последний пример кода: а чего Вы ожидаете от сравнения наборов, тем более разных типов? Если нужна булева алгебра, сделайте a, b и c наборами типа bit и тогда сравнивайте их между собой.
Вы же в других языках не сравниваете строку и число напрямую?
Темы затронуты хорошие, но я же в самом верху статьи написал, что не преуспел в этом вопросе. Есть вопросы, на которые я пока тоже не знаю ответа, но это не повод говорить стоп для исследователя. Концепция отличная от всего имеющегося есть, базис есть, я поделился идеей с комьюнити. Зря большинство, вместо развития, подводит к мысли выкинь и забудь.
Всё не так плохо, на крайний случай if может принимать несколько множеств. Выглядеть это может примерно так:
if ( a == b, c == d ) {}
До конца ещё не проработал, но проблемы нет. Приведённый вариант не самый лучший.
Можно оставить для состояний только is и добавить какое-либо ключевое слово для перевода набора в нужное состояние. Например, in. Как на Ваш взгляд это повлияет на читаемость?
Можете предложить и свои варианты реализации наборов и операций над ними.
На мой взгляд это направление перспективно для развития языка программирования. Как минимум что-то новое и не топтаться на месте.
a == b сравнивает наборы одного пользовательского типа
a == Invalid сравнивает состояние в рамках набора а
По второму случаю я где-то уже писал текущий минус: пока описываются только тождественные условия в состояниях. То есть неравенства сейчас не принимаются. Я над этим работаю.
Да, это редко нужно. Об этом не хотят говорить, что я отметил в статье.
Видимо Вы не сталкивались с упомянутыми проблемами. Сейчас не найду подходящего примера, но как пример рекомендую послушать это с 16:50. Миф документации чуточку развеется.