Что такое "стандартные акронимы"? Есть просто акронимы, и в разных сферах они могут совпадать. Почему какой-то из них вдруг должен быть стандартным?
Например, для меня для CoW первым в голову приходит Copy-On-Write, да. Но для DAO - без вариантов Decentralized Autonomous Organization. Просто все в разных сферах крутятся и у всех разный лексикон.
А мне lazygit так и не зашел, для каких-то сложных вещей все равно удобнее использовать гуишные тулзы(для меня это JetBrains). А вот для вещей попроще, типа просто посерфить по истории, tig это наше все, точно входит в мой топ-3 tui тулз.
Если речь о высокоуровневых оптимизациях, таких как формы SSA (Static Single Assignment), то на уровне ассемблера они просто неуместны.
SSA - это не оптимизация, а просто популярная форма IR.
А вообще, у меня складывается ощущение, что это какой-то троллинг. Трудно поверить, чтобы кто-то это все делал всерьез. Например, какой смысл уделять время такой нерелавантой тут вещи, как парсер командной строки, зачем тут генерация deb пакета и тд? Это все такое вторичное в контексте проекта компилятора.
Ну и наконец зачем делать сотни пустых коммитов в репозитории:)
Я имел опыт работы с языком Fift (это язык для TON блокчейна), который мало чем отличается от Forth. Так вот это было моим худшим опытом работы с новым языком программирования.
Во-первых, data flow через стек это просто ужасно. Мне много приходилось разбираться в чужом коде, если в обычных языках все данные кладутся в переменные - все наглядно, все можно отследить. То тут они лежат где-то в стеке, и каждая команда может изменить этот стек, поэтому приходится постоянно держать в уме что где лежит.
Во-вторых, (возможно актуально только для Fift) сложно отличить встроенные функции, функции из стандартной библиотеки и команды виртуальной машины. Непонятно, что сколько функция берет со стека, сколько кладет, приходится постоянно смотреть на ее реализацию. А их там сотни.
И неспроста. Внутри тела конструктора класса MapLattice произошло сокрытие нестатического поля с тем же именем, что и у параметра. И в этом фрагменте забыли явно указать this слева от оператора присваивания.
В который раз убеждаюсь: LLVM code style один из самых убогих и ненормальных. Как можно додуматься писать имена классов и всех переменных в одном стиле!
Что такое "стандартные акронимы"? Есть просто акронимы, и в разных сферах они могут совпадать. Почему какой-то из них вдруг должен быть стандартным?
Например, для меня для CoW первым в голову приходит Copy-On-Write, да. Но для DAO - без вариантов Decentralized Autonomous Organization. Просто все в разных сферах крутятся и у всех разный лексикон.
А мне
lazygitтак и не зашел, для каких-то сложных вещей все равно удобнее использовать гуишные тулзы(для меня это JetBrains). А вот для вещей попроще, типа просто посерфить по истории,tigэто наше все, точно входит в мой топ-3 tui тулз.Еще я бы посоветовал
atuinдля просмотра истории https://github.com/atuinsh/atuin Невероятно удобная вещь.SSA- это не оптимизация, а просто популярная форма IR.А вообще, у меня складывается ощущение, что это какой-то троллинг. Трудно поверить, чтобы кто-то это все делал всерьез. Например, какой смысл уделять время такой нерелавантой тут вещи, как парсер командной строки, зачем тут генерация deb пакета и тд? Это все такое вторичное в контексте проекта компилятора.
Ну и наконец зачем делать сотни пустых коммитов в репозитории:)
Я имел опыт работы с языком Fift (это язык для TON блокчейна), который мало чем отличается от Forth. Так вот это было моим худшим опытом работы с новым языком программирования.
Во-первых, data flow через стек это просто ужасно. Мне много приходилось разбираться в чужом коде, если в обычных языках все данные кладутся в переменные - все наглядно, все можно отследить. То тут они лежат где-то в стеке, и каждая команда может изменить этот стек, поэтому приходится постоянно держать в уме что где лежит.
Во-вторых, (возможно актуально только для Fift) сложно отличить встроенные функции, функции из стандартной библиотеки и команды виртуальной машины. Непонятно, что сколько функция берет со стека, сколько кладет, приходится постоянно смотреть на ее реализацию. А их там сотни.
В общем никому не советую :)
В который раз убеждаюсь: LLVM code style один из самых убогих и ненормальных. Как можно додуматься писать имена классов и всех переменных в одном стиле!