Не вижу проблем, почему бы декоратор нельзя было бы задавать динамически.
Можно все функции сделать указателями, тогда бы задание декоратора делалось через присваивание нового значения этому указателю.
А что, если использовать технологию типа электронных чернил? Внутри, насколько я знаю, там тоже просто смена ориентации механических элементов, только они гораздо компактнее.
Проблема 15-го стандарта в том, что нету какого-либо органа, принуждающего соблюдать стандарты. Без него сколько стандарты не принимай, они все будут иметь только рекомендательный характер.
Было бы конечно хорошо такой орган создать, но это уже совсем другая история.
Если разных эффектов много, то переключение шейдеров будет накладным.
такая техника очевидно накладывает ограничение на количество цветов и количество переходов цвета
Спору нет, не для всех изображений вышеизложенный эффект хорошо работает. А на тех изображениях, где это работает, это может даже дать интересный художественный эффект.
Размер текстур частиц-градиентом по 100кб
Тут проблема скорее не в размере, а в переключении текстур или необходимости паковать их в атлас. Для эффектов на основе градиентных треугольников такой проблемы не стоит.
Zero overhead и браузеры — слабо совместимые вещи. Если браузерное приложение упирается в производительность WebGL — стоит задуматься о создании нативной версии приложения. А в нативной версии есть уже знакомый всем Vulkan.
Неэффективность госуправления — миф. Эффективность в госструктурах схожа с аналогичными по размеру и занимаемой доле рынка частными компаниями. Кажущаяся неэффективность происходит от того, что госструктуры как правило являются монополиями, но при этом монополисты-частники являются столь же забюрократизироваными и неповоротливыми.
Но при всей схожести государственных и частных монополий, для обычного гражданина предпочтительна госмонополия. Но её работу можно, в теории, хоть как-то повлиять — через выборы. На частную монополию повлиять можно только отказавшись от её услуг, что практически почти неосуществимо.
То, что в каких-то странах государство по сути неподконтрольно гражданам — отдельная проблема. Жителям этих стран сначала надо будет вернуть контроль над государством, а потом можно уже будет национализировать монополии и управлять ими себе во благо.
Мне, как разработчику конца 10-х годов XXI века, не понятно, а чего в этой игре потребовало 500 часов разработки? Сейчас игры гораздо большего наполнения пишут на сходках игроделов за выходные.
Или тогда процесс разработки был сильно трудозатратен из-за отсутствия вменяемых инструментов?
Чувствуется, автору не хватает опыта промышленной разработки. Имея опыт промышленного программирования, можно было бы не допустить изложенных выше ошибок. Тогда бы компилятор можно было бы написать гораздо быстрее и с меньшими страданиями.
Миллиардерам их бункеры помогут разве что жизнь сохранить, и то не факт. После серьёзных потрясений они могут потерять права собственности (Великая Французская Революция, Великая Октябрьская Социалистическая Революция). После выхода из бункера новые власти могут подвергнуть их преследованию, как старорежимный элемент.
Не помогут, соседние страну закроют границы из-за большого количества беженцев. Пример Венгрии, озаборившей границу, показателен.
Канистры с бензином для машины.
Дороги в случае чего или перекроют, или они забьются. Так что надо или на месте сидеть, или по воздуху убираться.
В целом же вариант уехать есть только у небольшой части населения. У большинства населения России нету средств даже для поездки к родственникам в соседний регион, срочный переезд в другую страну они не потянут. Показателен тут пример Сирии — сколько убежало, а скольким пришлось остаться.
Хотелось бы добавить, что в статье перечислена только малая часть оптимизаций. В LLVM также есть оптимизации, которые могут целый цикл в формулу развернуть или преобразовать сложный набор инструкций в одну машинную, вроде bswap или popcnt.
Очевидно, что halt надо использовать в крайнем случае, а в библиотечном коде так вообще, стараться воздерживаться от его использования.
С исключениями в C++ проблема схожая тоже присутствует, все вызовы к сторонним библиотекам в try-catch мало кто заворачивает, а значит, если оттуда прилетит исключение, его могут и не поймать, что закончится std::abot.
Выше уже отметил, что тип пишется после var, чтобы можно было объявить несколько переменных с одним типом.
Тип возвращаемого значения после описания аргументов функции, как мне кажется, более логичен.
имена фундаментальных типов специально включают разрядность, для наглядности, чтобы не вспоминать, сколько там байт в каких-нибудь shot, long.
Я тут исхожу из принципа, что все значения фундаментальных типов равозначны, а значит нельзя выбрать какое-то значения для умолчательной инициализации. Поэтому программисту явно надо указать, какое начальное значение ему нужно.
На счёт удобства — спорно. ак подсказывает мой опыт, чаще всего переменные объявляются сразу с инициализатором, где инициализатор это не просто какое-то число (вроде нуля) а значение сложного выражения, результат вызова функции и т. д. Случаи, когда мы объявляем переменную и только потом в неё что-то записываем редки, в основном это случай с аккумулятором для цикла.
Чтобы проверить компилятор на больших проектах, нужны большие проекты. Ну хотя бы какие-то проекты. Но таких пока нету.
Самокомпиляции в ближайшее время не будет, т. к. во-первых, для этого надо переписать весь компилятор, а во-вторых, надо будет написать биндинги для llvm.
Я вот 100 лет ждал возможность написать код в стиле
Читать такое бывает сложно.
Это что за зверь?
Ну это когда надо писать impl SomeTrait for SomeStruct{}. Мне больше нравится подход из C++ шаблонов — соответствие требованиям к типу определяются по необходимости, скажем, если вызвали std::sort, то будет использован operator<, и не обязательно наследовать тип от какого-нибудь Ordered.
От наследования реализации обычно больше проблем нежели достоинств
Действительно, можно перемудрить с наследованием. Но мне кажется, достоинства от наличия наследования всё же перекрывают недостатки от возможности его неправильно использовать.
отсутствие ссылок немного смущает
Ссылки есть. Нету ссылочных типов.
странный выбор синтаксиса
В начале разработки так и было, тип аргумента функции указывался после двоеточия. Но потом я пришёл к выводу, что двоиточие тут лишнее и не несёт особой смысловой нагрузки, а если двоеточие убрать, то логичнее будет указывать на первом месте тип аргумента, а имя на втором.
Можно все функции сделать указателями, тогда бы задание декоратора делалось через присваивание нового значения этому указателю.
Было бы конечно хорошо такой орган создать, но это уже совсем другая история.
Если разных эффектов много, то переключение шейдеров будет накладным.
Спору нет, не для всех изображений вышеизложенный эффект хорошо работает. А на тех изображениях, где это работает, это может даже дать интересный художественный эффект.
Тут проблема скорее не в размере, а в переключении текстур или необходимости паковать их в атлас. Для эффектов на основе градиентных треугольников такой проблемы не стоит.
Можно LOD-ы самой геометрии сделать.
Но при всей схожести государственных и частных монополий, для обычного гражданина предпочтительна госмонополия. Но её работу можно, в теории, хоть как-то повлиять — через выборы. На частную монополию повлиять можно только отказавшись от её услуг, что практически почти неосуществимо.
То, что в каких-то странах государство по сути неподконтрольно гражданам — отдельная проблема. Жителям этих стран сначала надо будет вернуть контроль над государством, а потом можно уже будет национализировать монополии и управлять ими себе во благо.
Или тогда процесс разработки был сильно трудозатратен из-за отсутствия вменяемых инструментов?
Не помогут, соседние страну закроют границы из-за большого количества беженцев. Пример Венгрии, озаборившей границу, показателен.
Дороги в случае чего или перекроют, или они забьются. Так что надо или на месте сидеть, или по воздуху убираться.
В целом же вариант уехать есть только у небольшой части населения. У большинства населения России нету средств даже для поездки к родственникам в соседний регион, срочный переезд в другую страну они не потянут. Показателен тут пример Сирии — сколько убежало, а скольким пришлось остаться.
Именно из побуждений создать язык без излишних сложностей C++ я и начал велосипедить свой язык
С исключениями в C++ проблема схожая тоже присутствует, все вызовы к сторонним библиотекам в try-catch мало кто заворачивает, а значит, если оттуда прилетит исключение, его могут и не поймать, что закончится std::abot.
Тип возвращаемого значения после описания аргументов функции, как мне кажется, более логичен.
имена фундаментальных типов специально включают разрядность, для наглядности, чтобы не вспоминать, сколько там байт в каких-нибудь shot, long.
На счёт удобства — спорно. ак подсказывает мой опыт, чаще всего переменные объявляются сразу с инициализатором, где инициализатор это не просто какое-то число (вроде нуля) а значение сложного выражения, результат вызова функции и т. д. Случаи, когда мы объявляем переменную и только потом в неё что-то записываем редки, в основном это случай с аккумулятором для цикла.
Самокомпиляции в ближайшее время не будет, т. к. во-первых, для этого надо переписать весь компилятор, а во-вторых, надо будет написать биндинги для llvm.
Ну это когда надо писать impl SomeTrait for SomeStruct{}. Мне больше нравится подход из C++ шаблонов — соответствие требованиям к типу определяются по необходимости, скажем, если вызвали std::sort, то будет использован operator<, и не обязательно наследовать тип от какого-нибудь Ordered.
Действительно, можно перемудрить с наследованием. Но мне кажется, достоинства от наличия наследования всё же перекрывают недостатки от возможности его неправильно использовать.
Ссылки есть. Нету ссылочных типов.
В начале разработки так и было, тип аргумента функции указывался после двоеточия. Но потом я пришёл к выводу, что двоиточие тут лишнее и не несёт особой смысловой нагрузки, а если двоеточие убрать, то логичнее будет указывать на первом месте тип аргумента, а имя на втором.