За 52 не слышал, но за теории струн с 21 измерением было дело. Проблема в том, что у них практически нет предсказательной способности, чтобы проверить их экспериментально. Обычно они объясняют какой-то проблемный аспект (вроде ускоренного расширения вселенной), но дальнейших выводов из теории не следует ибо вариантов которые могли бы сработать становится невообразимо много и параметризировать теорию так, чтобы она становилась похожа на наблюдения пока не удаётся.
managed - это как раз языки с gc - кто-то управляет (manages) памятью в противовес ручному управлению (manual). вы просто пишите var x = blabla() и не думаете почистится ли память или нет. C#, Java, D, Python, Haskell - как раз из этой оперы. Можно включать /выключать всякие фичи языка и даже Java можно компилировать в aot/no gc, но зачем, если я могу не делая приседаний иметь все то же самое поведение по-умолчанию в C++/Rust/Odin/Zig. V на худой конец.
не стал сильно заморачиваться со ссылками ради упрощения. Так-то там и каких-нибудь конструкторов перемещающих дорисовать и концептов может каких, а то и в unique_ptr обернуть, чтобы время жизни ограничить.
Скажем, я не слишком фанат managed языков. Отдельное фе к именованию/code style, которое мне сильно напоминает Java. Можно ещё немножко поурчать про обманутые ожидания от флага -betterC. С другой стороны язык смог впитать заметное количество модных-молодёжных фич из других языков, так что разработчикам языка можно поаплодировать. В проде я это использовать конечно же не буду.
Я бы сказал пример крайне неудачен, ибо с большой вероятностью можно было б инкапсулировать половину этих методов и вообще не давать пользователю их вызывать.
Что-нибудь типа
using Shader = /* */;
ShaderRegistry{ /* */ };
class ShaderCompiler final{
std::vector<Shader> names;
friend ShaderRegistry Compile(ShaderCompiler&& compiler);
ShaderRegistry compile();
public:
// единственный доступный метод. Возвращает ссылку на себя,
// чтобы можно было вызывать цепочкой .add("asd").add("qwe")
ShaderCompiler& add(std::string_view name);
};
// можно поменять сигнатуру на какой-нибудь unique_ptr
ShaderRegistry Compile(ShaderCompiler&& compiler) {
// доступ к приватному методу есть только тут
return compiler.compile();
};
Ну, а проверку borrow checker пока ещё в процессе запиливания/стандартизации, так что пока не дожили.
Ну, он его уже примерно 10 лет копит т.к. 1.0 в 2015 вышел. Просто у него механизм резолва легаси несколько отличается от тех же плюсов. Примерно столько же времени у плюсов ушло от первоначального выпуска до выпуска ISO стандарта.
cppfront фактически делает апгрейд плюсов зашивая все механизмы GSL в язык, добавляя модули, обратную совместимость с плюсами и избавляя его от всякой дичи, типа спирали типов. В итоге всё это транспилируется в какой-то свежий С++ и в таком виде компилируется уже как обычно.
Про carbon не расскажу ибо у них компилятор не везде работает, но выглядит он в среднем не лучше какого-нибудь D.
Так исторически сложилось. Когда Тьюринг занимался разработкой теории он пришёл к тому, что любую программу можно выразить сначала в виде лямбда исчисления, а потом уже доказал, что тьюринг машина фактически этому тождественна, ну а там уже и свой ломатель Энигмы поставил на эти рельсы.
В питоне типы работают из под палки и просят много тестов, чтобы оказаться действительно эффективными. Что-то отлавливается в LSP/линтерах, что-то не особо. Так что пока все эти аннотации жёстко не приколотят к какой-нибудь фиче языка пользы от них не прям сказать чтобы много в сравнении с Java.
XPath has been adopted by a number of XML processing libraries and tools, many of which also offer CSS Selectors, another W3C standard, as a simpler alternative to XPath.
Идея XPath была использовать его для навигации по DOM, но когда усложнился CSS оно фактически зажило немного собственной жизнью и уже имело назначением делать запросы к DOM, а не просто обращаться по пути. Ну и встроенные функции реинкарнировали в отдельные псевдоклассы и прочие псевдоаттрибуты. Ну и буквально по вашей ссылке оно зовётся CSS Selectors - чем не имя?
объясните такой TIME PARADOX
не знаю чем оно вам time paradox, учитывая что сейчас фактически существует два консорциума по стандартизации - W3C и WHATWG. W3C принимает стандарты довольно неспешно - 3.0 и 3.1 различаются на 4 года, 3.0 от 2.0 - все 7 - а c 2019 W3C и вовсе импотент и вся работа по веб стандартам, исключая HTML, ведётся в рамках рабочих групп WHATWG. Да и ваша ссылка ссылается на черновик, которые тоже пока ещё неизвестно когда устаканится.
Задача-то собственно сделать код на Си, то есть сначала надо написать интерпрептатор кода на Си и каким-то образом скормить литерал с пробелами без зачёта этого литерала в размер программы.
Фронтенд clang генерирует тоже весьма неоптимизированный IR код
Там довольно немало подсказок имеется касательно данных, позволяя делать иногда не самые очевидные оптимизации - где-то автовекторизация срабатывает, где-то constexpr вычисляется, где-то память остаётся на месте (move семантика и return value optimization). Не знаю насколько это поддеживается в U, но с большой долей вероятности их может и не оказаться.
только если обращаться к произвольному индексу через оператор [].
ну вот по крайней мере в Rust если точно известно, что индекс никогда не превысит размер массива, то он вроде осиливает убрать проверку границ. Что-то вроде
let mut vec= Vec::with_capacity(sz);
/*
...
массив как-то заполняется до sz
...
*/
for i in 0..sz {
...
let blabla = vec[i]; // граница проверяется ровно
// 1 раз при входе в массив
...
}
Но собственно идею с инвариантами вы поняли - ограничения типов позволяют статически проверять все эти границы и динамически проверок уже не требуется. Обычно такого рода штуки проверяются со стороны фронтенда.
Я могу конечно ошибаться и U всё это могёт умеет, но и изначальный комментарий это скорее камень в ваш огород кастательно сравнения перформанса "на дцать процентов" на глазок без бенчмарок.
Средств выразительности языка вполне хватило для осуществления этого проекта.
Оно конечно хорошо, но киллер-фичей пока не замечено, учитывая большую вербозность языка в сравнении с тем же C++.
Производительность тоже весьма неплоха — на уровне других компилируемых языков, вроде C++
Вот тут press X doubt . Производительность скорее на уровне, который позволяет наоптимизировать LLVM из того наивного IR, который делает U. Да и снижение производительности на 10 процентов означает, что проверка границ происходит не при помощи инвариантов типа (как в том же Rust), которые выоптимизировываются, а наивными проверками.
С тем же эффектом "для примера" можно было сравнить print("hello world") с enterprise level hello world. Если ваш код не делает то же самое, то смысла сравнивать его по прочим параметрам смысла особо нет.
В веб станадартах оно зовётся XPath. Оно и в CSS и в JS и в XML/HTML используется. В среднем оно довольно универсально в плане API, но конкретно ваши примеры работают с HTML.
В примерах в статье предлагалось выносить if за пределы метода. Опять же внутри filter я так понимаю сидит оператор условия, который и предлагается вынести.
собственно использование filter и есть вынос - условие оказывается выше, а обработка в цикле ниже.
Именно поэтому я и написал, что bc в процессе запиливания/стандартизации. Также как и кучка прочих safety пропозалов разной степени ароматности.
За 52 не слышал, но за теории струн с 21 измерением было дело. Проблема в том, что у них практически нет предсказательной способности, чтобы проверить их экспериментально. Обычно они объясняют какой-то проблемный аспект (вроде ускоренного расширения вселенной), но дальнейших выводов из теории не следует ибо вариантов которые могли бы сработать становится невообразимо много и параметризировать теорию так, чтобы она становилась похожа на наблюдения пока не удаётся.
managed - это как раз языки с gc - кто-то управляет (manages) памятью в противовес ручному управлению (manual). вы просто пишите var x = blabla() и не думаете почистится ли память или нет. C#, Java, D, Python, Haskell - как раз из этой оперы. Можно включать /выключать всякие фичи языка и даже Java можно компилировать в aot/no gc, но зачем, если я могу не делая приседаний иметь все то же самое поведение по-умолчанию в C++/Rust/Odin/Zig. V на худой конец.
не стал сильно заморачиваться со ссылками ради упрощения. Так-то там и каких-нибудь конструкторов перемещающих дорисовать и концептов может каких, а то и в unique_ptr обернуть, чтобы время жизни ограничить.
Скажем, я не слишком фанат managed языков. Отдельное фе к именованию/code style, которое мне сильно напоминает Java. Можно ещё немножко поурчать про обманутые ожидания от флага -betterC. С другой стороны язык смог впитать заметное количество модных-молодёжных фич из других языков, так что разработчикам языка можно поаплодировать. В проде я это использовать конечно же не буду.
Я бы сказал пример крайне неудачен, ибо с большой вероятностью можно было б инкапсулировать половину этих методов и вообще не давать пользователю их вызывать.
Что-нибудь типа
Ну, а проверку borrow checker пока ещё в процессе запиливания/стандартизации, так что пока не дожили.
Ну, он его уже примерно 10 лет копит т.к. 1.0 в 2015 вышел. Просто у него механизм резолва легаси несколько отличается от тех же плюсов. Примерно столько же времени у плюсов ушло от первоначального выпуска до выпуска ISO стандарта.
cppfront и carbon как раз про это.
cppfront фактически делает апгрейд плюсов зашивая все механизмы GSL в язык, добавляя модули, обратную совместимость с плюсами и избавляя его от всякой дичи, типа спирали типов. В итоге всё это транспилируется в какой-то свежий С++ и в таком виде компилируется уже как обычно.
Про carbon не расскажу ибо у них компилятор не везде работает, но выглядит он в среднем не лучше какого-нибудь D.
Так исторически сложилось. Когда Тьюринг занимался разработкой теории он пришёл к тому, что любую программу можно выразить сначала в виде лямбда исчисления, а потом уже доказал, что тьюринг машина фактически этому тождественна, ну а там уже и свой ломатель Энигмы поставил на эти рельсы.
В питоне типы работают из под палки и просят много тестов, чтобы оказаться действительно эффективными. Что-то отлавливается в LSP/линтерах, что-то не особо. Так что пока все эти аннотации жёстко не приколотят к какой-нибудь фиче языка пользы от них не прям сказать чтобы много в сравнении с Java.
Идея XPath была использовать его для навигации по DOM, но когда усложнился CSS оно фактически зажило немного собственной жизнью и уже имело назначением делать запросы к DOM, а не просто обращаться по пути. Ну и встроенные функции реинкарнировали в отдельные псевдоклассы и прочие псевдоаттрибуты. Ну и буквально по вашей ссылке оно зовётся CSS Selectors - чем не имя?
не знаю чем оно вам time paradox, учитывая что сейчас фактически существует два консорциума по стандартизации - W3C и WHATWG. W3C принимает стандарты довольно неспешно - 3.0 и 3.1 различаются на 4 года, 3.0 от 2.0 - все 7 - а c 2019 W3C и вовсе импотент и вся работа по веб стандартам, исключая HTML, ведётся в рамках рабочих групп WHATWG. Да и ваша ссылка ссылается на черновик, которые тоже пока ещё неизвестно когда устаканится.
Для полного счастья не хватает Ü в compiler explorer.
Задача-то собственно сделать код на Си, то есть сначала надо написать интерпрептатор кода на Си и каким-то образом скормить литерал с пробелами без зачёта этого литерала в размер программы.
Там довольно немало подсказок имеется касательно данных, позволяя делать иногда не самые очевидные оптимизации - где-то автовекторизация срабатывает, где-то constexpr вычисляется, где-то память остаётся на месте (move семантика и return value optimization). Не знаю насколько это поддеживается в U, но с большой долей вероятности их может и не оказаться.
ну вот по крайней мере в Rust если точно известно, что индекс никогда не превысит размер массива, то он вроде осиливает убрать проверку границ. Что-то вроде
Но собственно идею с инвариантами вы поняли - ограничения типов позволяют статически проверять все эти границы и динамически проверок уже не требуется. Обычно такого рода штуки проверяются со стороны фронтенда.
Я могу конечно ошибаться и U всё это могёт умеет, но и изначальный комментарий это скорее камень в ваш огород кастательно сравнения перформанса "на дцать процентов" на глазок без бенчмарок.
пардон, веткой промахнулся.
Оно конечно хорошо, но киллер-фичей пока не замечено, учитывая большую вербозность языка в сравнении с тем же C++.
Вот тут
press X doubt. Производительность скорее на уровне, который позволяет наоптимизировать LLVM из того наивного IR, который делает U. Да и снижение производительности на 10 процентов означает, что проверка границ происходит не при помощи инвариантов типа (как в том же Rust), которые выоптимизировываются, а наивными проверками.Если ограничений на количество бутылок нет, то кажется проблем с этим возникнуть не должно. Пончик же завелся
С тем же эффектом "для примера" можно было сравнить
print("hello world")с enterprise level hello world. Если ваш код не делает то же самое, то смысла сравнивать его по прочим параметрам смысла особо нет.В веб станадартах оно зовётся XPath. Оно и в CSS и в JS и в XML/HTML используется. В среднем оно довольно универсально в плане API, но конкретно ваши примеры работают с HTML.
собственно использование filter и есть вынос - условие оказывается выше, а обработка в цикле ниже.
Так это он по сути и есть, просто выведеный через одно место.