Можно попрбовать использовать такой плагин https://github.com/ivanesmantovich/xkbswitch.nvim. При переходе в нормальный режим он переключает на английскую раскладку, запоминая текущую. При переходе обратно в режим вставки меняет раскладку обратно на запомненную ранее.
Лучше сделать что-то одно, но хорошо, чем комбайн, в котором всё сделано так себе. Это я про deb пакеты. Почему так никто не делает? Потому что пакетных систем много, зачем их все поддерживать компилятору, если это не его задача? Под каждую систему пакетов уже существуют инструменты для их сборки, которые будут работать лучше. Объясню на примеры, у вас ассемблер. Его на x86 в чистом виде уже давно никто не использует, обычно используют в связке с си/раст/т.п. кодом. Чтобы собрать такой проект нужна система сборки make/ninja/т.п. Чтобы собрать deb пакет нужно, во-первых, отслеживать все зависимости и их версии (код же может зависеть от библиотек), а во-вторых все выходные файлы, т.к. бывает, что это не один бинарник/разделяемая библиотека, а сразу несколько. И вот под это всё уже есть существующие решения, поэтому их в компилятор не интегрируют. Лучше сделать хороший компилятор, чем комбайн из компилятора, системы сборки и системы сборки пакетов, но плохой.
Начинать сегодня с поддержки x86 — это все равно что проектировать автомобиль с карбюратором. Зачем? Чтобы потом героически решать проблемы перехода на 64-битную архитектуру? Нет, спасибо. Мы сразу строим на современном фундаменте
Ну как минимум, чтобы ваш ассемблер можно было использовать в написании операционной системы. Да, если запускать ядро из UEFI, то код должен быть 64-х битным. Однако для запуска остальных ядер нужна поддержка и 16 и 32 битных режимов, потому что после получения прерывания SIPI, ядро начинает исполнение в real mode, потом его надо перевести в protected mode и только потом в long mode.
Разберём подробно вами написанное, just for lulz, конечно же:
Соответствие шаблону: Статья должна быть похожа на другие "успешные" статьи. Она должна использовать общепринятую терминологию, ссылаться на известные технологии (желательно, написанные на C++ или Rust), и решать проблему, которую сообщество уже признало "важной".
Начнём с терминологии. Разумеется, вы должны стараться использовать имеющуюся терминологию, чтобы другие люди вас поняли. Иное допустимо, если вы придумали что-то совершенно новое и доселе невиданное. Впрочем, у вас конкретно с терминологией проблем и не наблюдается. Про c++ и rust - это полный бред, если то, что вы написали действительно интересно и/или решает проблему, многим будет всё равно, на чём ваше программа написана. Другой вопрос, если вы делаете обычный x86 ассемблер на nodejs. Такое никому вообще не нужно. Уже есть nasm, yasm, fasm, gas, которые работают стабильно, есть везде и не тянут nodejs. Насчёт решения проблем: а какие конкретно проблемы решает Asmx?
Глубина в известном: Глубокий разбор уже существующего и понятного алгоритма или фреймворка — это высокий уровень. Создание чего-то нового с нуля и объяснение его философии — это, зачастую, "низкий уровень", потому что оно не вписывается в существующую систему координат.
Это как раз звучит бездоказательно. Если смотреть на Asmx, то он не относится вообще ни к одной из данных категорий. Вы и существующую технологию не разбираете глубоко и новую не создаёте.
Сообщество, как любая сложная система, вырабатывает иммунный ответ. Идеи, которые не похожи на то, что уже циркулирует в системе, воспринимаются как чужеродные тела. И система пытается их уничтожить. "Низкий технический уровень" — это антитела, которые вырабатывает этот коллективный организм.
Иногда это так, а иногда и нет. К вашему случаю не применимо.
Ирония в том, что статьи, которые проходят этот фильтр, часто не несут никакой новой технической ценности.
Тут могу согласится частично. Куча заплюсованных статей представляют собой мусор для продвижения тг каналов и/или курсов. Но не все.
AsmX G3 не похож. Он написан на Nodejs/TypeScript для разработки компилятора, что для многих уже звучит как ересь. Он предлагает свой синтаксис. Он решает проблемы не так, как принято. Поэтому он — идеальная мишень.
Если бы это был компилятор какого-то более менее интересного языка, то претензий бы не было. Да даже, если бы вы просто не писали бы об Asmx как о чём-то прорывном и новом, претензий было бы на порядок меньше.
Раздел про эхо-камеру цитировать не буду, слишком много. В вакууме звучит резонно. К вам же не применимо, потому что Asmx - это не инновация. Попробуйте доказать обратное, но у вас не выйдет. Это в лучшем случае всего лишь очередной ассемблер, написанный на неподходящем для этого языке, не обладающий никакими положительными отличительными особенностями и обладающий непривычным синтаксисом. Назовите хоть одну причину использовать его, а не вышеназванные ассемблеры.
Но вот в чем парадокс: в науке и инженерии именно "выбросы" часто указывают на самые интересные явления.
Даже если и так, то не ваш случай снова.
Они не понимают, что право на творчество — это не привилегия, которую выдает сообщество. Это фундаментальное право. Лишать кого-то этого права через манипуляции рейтингом — это не критика. Это цензура, осуществляемая руками толпы. И самое печальное, что эта толпа часто состоит из тех, кто сам ничего не создал, но узурпировал право судить создателей.
Пишите не на хабр, а сразу в научные журналы, раз вы считаете, что создаёте нечто инновационное. Вы так говорите, как будто на хабре свет клином сошёлся. Да и никто вас не лишает права на творчество, творите себе на здоровье.
Фокус на первых принципах, а не на аналогах. Я не задаю вопрос "Как сделать компилятор, похожий на GCC?". Я спрашиваю: "Что такое компилятор по своей сути? Какую задачу он должен решать? Как это сделать максимально эффективно, используя доступные сегодня инструменты?". Ответ на этот вопрос привел меня к Nodejs/TypeScript, к двум режимам парсера и к собственной реализации всего конвейера.
И вряд ли вышло лучше, чем у GCC. Инженерный подход - это не решать уже решённую проблему с нуля, а посмотреть, как её уже решают и предложить улучшения. В крайнем случае можно предложить фундаментально новый подход, но той же теории компиляции уже не один десяток лет, над ней работало множество талантливых людей. Какова вероятность, что вы сходу придумаете лучше, даже не прочитав ни одной книги по этой самой компиляции и не получив опыт работы над промышленным компилятором?
Антихрупкость. Система, которая становится сильнее от атак. Каждая попытка найти недостаток, каждый едкий комментарий — это бесплатное тестирование. Это стресс-тест не только для кода, но и для меня как инженера. Этот негатив заставляет меня делать продукт еще более надежным, еще более продуманным, чтобы не оставить ни единого шанса для критики по существу.
Вот только никто не тестируют Asmx. Потому что он не интересен сам по себе. Это обычный ассемблер, только хуже существующих, и вряд ли он станет лучше них.
Полностью согласен. Данному товарищу лучше ставить плюсы, чтобы он писал ещё, а нам было весело. Его просто уже несколько раз, к несчастью, удаляли, но он всегда возрождается из пепла, аки феникс, неся с собой удвоенное количество пафоса, заявлений о собственной важности и исключительной полезности и революционности своих разработок, а соответственно и веселья.
У меня, например, другой опыт. Я начинал с Visual Basic: формочки, простые игрушки, никаких указателей. Потом был Javascript. Концепцию указателей понял почти сразу, как прочёл первый учебник по Си, сложности определённые были, но это всегда так, когда что-то новое осваиваешь. Не могу сказать, что стал крутым знатоком си, но что-то умею. При этом не уверен, что было бы также весело начинать с голого си, а не с формочек и простого бейсика, потому что изначально решил программированием заниматься, чтобы игры делать. Пока на чистом си дойдёшь хотя бы до отрисовки текстуры, уже желание может отпасть.
Тут не совсем ФП. Код пишется на haskell, но этот код генерирует код на си. Плюс ivory (библиотека, предназначенная для этого) даёт некоторые гарантии относительно получаемого кода.
Я привёл, как пример того, что и на условно безопасных языках можно написать ПО, которое будет ненадёжным. Ничего против касательно этого проекта и rust в целом не имею. И наоборот на том же си при соблюдении некоторых правил можно писать вполне надёжный софт. В конечном счёте всё зависит от программиста
Тема на самом деле интересная. Я прочитал все 3 статьи из цикла, и у меня сложилось впечатление, что языка, который обеспечивает надёжность нет. Языки из обзора либо слишком непопулярны (D, Ada), либо уже заброшены, либо C++ :) Но я для себя давно пришёл к выводу, что на любом языке можно писать надёжный код, если соблюдать дисциплину и наоборот. Например, недавно была новость про переписывание tmux на rust с 67к си кода на 87к строк unsafe rust кода, что определённо менее надёжно, чем tmux на си, который уже обкатан. Есть ещё языки с завтипами, например, agda, idris и т.д, но даже там никто не застрахован от ошибок, потому что так или иначе дело дойдёт до ввода вывода
Вполне вероятно, что они реальные. Насколько я знаю, школы пересаживают со сферума на Max. Другой вопрос, что это добровольно-прниудительные пользователи.
Он как бы общего назначения, то есть на нём можно сделать что угодно. Меня скорее удивляют новости, мол то и то переписали на раст, хотя куда логичнее было бы пиарить новые проекты, которые не являются простыми аналогами существующих уже 10 летия утилит.
Я вот не очень понимаю, почему постоянно появляются новости по типу: на rust написали аналог %программа-нейм%. Люди любят писать свои аналоги ради получения опыта, это понятно, но в чём смысл это освещать, и почему освещаются в основном аналоги, написанные на rust? Едва ли кому-то захочется менять tmux или что-то ещё проверенное временем на очередной аналог на rust/zig/odin/ваш любимый язык.
Я бы не назвал это стагнацией. Если у вас есть хороший инструмент, который решает ваши проблемы, зачем его менять? Если есть какие-то раздражающие моменты, то их надо устранять, если нет, то зачем пробовать новые/плагины? Насчёт telescope согласен, но о нём я узнал, вбив в гугл что-то вроде vim file search, как раз потому что мне был нужен поиск файлов, то есть была причина искать новый плагин. О treesitter я узнал из новостей, попробовал и выкинул, потому что подсветка стала хуже (возможно, мне просто повезло с используемыми языками)
Кроме того у меня был случай, когда какой-то плагин давно не обновлялся не потому что идеальный, а потому что его давно забросил автор.
В таких случаях спасает гугл. В остальных может помочь просмотр конфигов других разработчиков. Я о некоторых полезных фичах, например об относительной нумерации, так и узнал, посматривая конфиг одного разработчика, который делает интересные мне проекты.
Я нигде не смотрю, один раз настроил и пользуюсь. Если сталкиваюсь с какой-либо проблемой, то гуглю как её решить. Зачем гнаться за трендами и искать новые плагины, если итак всё работает? От awesome-neovim и прочих готовых конфигураций больше вреда, чем пользы. Свою конфигурацию я вдоль и поперёк знаю, потому что каждую строку сам писал, а в готовых ещё и разбираться надо, плюс там куча лишнего. В этом по-моему и есть плюс конструкторов типа вима, емакса и т.п. - вы добавляете только то, что вам нужно и так, как это вам нужно.
Я не могу с вима уже никуда уйти, например. В своё время пользовался им, потому что комп ничего другого не тянул, сейчас пользуюсь, потому что работаю с разными языками, с которыми вим отлично справляется (под большее количество из них впрочем и IDE нет). Но в основном это дело привычки. Я бы не сказал, что работать в IDE лучше, чем в vim и наоборот.
Честно, лучше бы оно осталось. Популярность у ресурса была бы меньше, но меня, как пользователя, больше интересует качество наполнения, а не количество
Можно попрбовать использовать такой плагин https://github.com/ivanesmantovich/xkbswitch.nvim. При переходе в нормальный режим он переключает на английскую раскладку, запоминая текущую. При переходе обратно в режим вставки меняет раскладку обратно на запомненную ранее.
Лучше сделать что-то одно, но хорошо, чем комбайн, в котором всё сделано так себе. Это я про deb пакеты. Почему так никто не делает? Потому что пакетных систем много, зачем их все поддерживать компилятору, если это не его задача? Под каждую систему пакетов уже существуют инструменты для их сборки, которые будут работать лучше. Объясню на примеры, у вас ассемблер. Его на x86 в чистом виде уже давно никто не использует, обычно используют в связке с си/раст/т.п. кодом. Чтобы собрать такой проект нужна система сборки make/ninja/т.п. Чтобы собрать deb пакет нужно, во-первых, отслеживать все зависимости и их версии (код же может зависеть от библиотек), а во-вторых все выходные файлы, т.к. бывает, что это не один бинарник/разделяемая библиотека, а сразу несколько. И вот под это всё уже есть существующие решения, поэтому их в компилятор не интегрируют. Лучше сделать хороший компилятор, чем комбайн из компилятора, системы сборки и системы сборки пакетов, но плохой.
Ну как минимум, чтобы ваш ассемблер можно было использовать в написании операционной системы. Да, если запускать ядро из UEFI, то код должен быть 64-х битным. Однако для запуска остальных ядер нужна поддержка и 16 и 32 битных режимов, потому что после получения прерывания SIPI, ядро начинает исполнение в real mode, потом его надо перевести в protected mode и только потом в long mode.
А ваши статьи говорят об обратном :)
Разберём подробно вами написанное, just for lulz, конечно же:
Начнём с терминологии. Разумеется, вы должны стараться использовать имеющуюся терминологию, чтобы другие люди вас поняли. Иное допустимо, если вы придумали что-то совершенно новое и доселе невиданное. Впрочем, у вас конкретно с терминологией проблем и не наблюдается. Про c++ и rust - это полный бред, если то, что вы написали действительно интересно и/или решает проблему, многим будет всё равно, на чём ваше программа написана. Другой вопрос, если вы делаете обычный x86 ассемблер на nodejs. Такое никому вообще не нужно. Уже есть nasm, yasm, fasm, gas, которые работают стабильно, есть везде и не тянут nodejs. Насчёт решения проблем: а какие конкретно проблемы решает Asmx?
Это как раз звучит бездоказательно. Если смотреть на Asmx, то он не относится вообще ни к одной из данных категорий. Вы и существующую технологию не разбираете глубоко и новую не создаёте.
Иногда это так, а иногда и нет. К вашему случаю не применимо.
Тут могу согласится частично. Куча заплюсованных статей представляют собой мусор для продвижения тг каналов и/или курсов. Но не все.
Если бы это был компилятор какого-то более менее интересного языка, то претензий бы не было. Да даже, если бы вы просто не писали бы об Asmx как о чём-то прорывном и новом, претензий было бы на порядок меньше.
Раздел про эхо-камеру цитировать не буду, слишком много. В вакууме звучит резонно. К вам же не применимо, потому что Asmx - это не инновация. Попробуйте доказать обратное, но у вас не выйдет. Это в лучшем случае всего лишь очередной ассемблер, написанный на неподходящем для этого языке, не обладающий никакими положительными отличительными особенностями и обладающий непривычным синтаксисом. Назовите хоть одну причину использовать его, а не вышеназванные ассемблеры.
Даже если и так, то не ваш случай снова.
Пишите не на хабр, а сразу в научные журналы, раз вы считаете, что создаёте нечто инновационное. Вы так говорите, как будто на хабре свет клином сошёлся. Да и никто вас не лишает права на творчество, творите себе на здоровье.
И вряд ли вышло лучше, чем у GCC. Инженерный подход - это не решать уже решённую проблему с нуля, а посмотреть, как её уже решают и предложить улучшения. В крайнем случае можно предложить фундаментально новый подход, но той же теории компиляции уже не один десяток лет, над ней работало множество талантливых людей. Какова вероятность, что вы сходу придумаете лучше, даже не прочитав ни одной книги по этой самой компиляции и не получив опыт работы над промышленным компилятором?
Вот только никто не тестируют Asmx. Потому что он не интересен сам по себе. Это обычный ассемблер, только хуже существующих, и вряд ли он станет лучше них.
Полностью согласен. Данному товарищу лучше ставить плюсы, чтобы он писал ещё, а нам было весело. Его просто уже несколько раз, к несчастью, удаляли, но он всегда возрождается из пепла, аки феникс, неся с собой удвоенное количество пафоса, заявлений о собственной важности и исключительной полезности и революционности своих разработок, а соответственно и веселья.
А чем лучше обычного gas? Могу сказать чем хуже - написан на javascript, а тащить javascript ради запуска ассемблера - такое себе.
У меня, например, другой опыт. Я начинал с Visual Basic: формочки, простые игрушки, никаких указателей. Потом был Javascript. Концепцию указателей понял почти сразу, как прочёл первый учебник по Си, сложности определённые были, но это всегда так, когда что-то новое осваиваешь. Не могу сказать, что стал крутым знатоком си, но что-то умею. При этом не уверен, что было бы также весело начинать с голого си, а не с формочек и простого бейсика, потому что изначально решил программированием заниматься, чтобы игры делать. Пока на чистом си дойдёшь хотя бы до отрисовки текстуры, уже желание может отпасть.
Тут не совсем ФП. Код пишется на haskell, но этот код генерирует код на си. Плюс ivory (библиотека, предназначенная для этого) даёт некоторые гарантии относительно получаемого кода.
Насколько я понимаю ivory? А есть какие-нибудь хорошие обзорные статьи по нему, а то интересно посмотреть, а руки всё никак не дойдут?
Я привёл, как пример того, что и на условно безопасных языках можно написать ПО, которое будет ненадёжным. Ничего против касательно этого проекта и rust в целом не имею. И наоборот на том же си при соблюдении некоторых правил можно писать вполне надёжный софт. В конечном счёте всё зависит от программиста
Тема на самом деле интересная. Я прочитал все 3 статьи из цикла, и у меня сложилось впечатление, что языка, который обеспечивает надёжность нет. Языки из обзора либо слишком непопулярны (D, Ada), либо уже заброшены, либо C++ :) Но я для себя давно пришёл к выводу, что на любом языке можно писать надёжный код, если соблюдать дисциплину и наоборот. Например, недавно была новость про переписывание tmux на rust с 67к си кода на 87к строк unsafe rust кода, что определённо менее надёжно, чем tmux на си, который уже обкатан. Есть ещё языки с завтипами, например, agda, idris и т.д, но даже там никто не застрахован от ошибок, потому что так или иначе дело дойдёт до ввода вывода
Вполне вероятно, что они реальные. Насколько я знаю, школы пересаживают со сферума на Max. Другой вопрос, что это добровольно-прниудительные пользователи.
Он как бы общего назначения, то есть на нём можно сделать что угодно. Меня скорее удивляют новости, мол то и то переписали на раст, хотя куда логичнее было бы пиарить новые проекты, которые не являются простыми аналогами существующих уже 10 летия утилит.
Я вот не очень понимаю, почему постоянно появляются новости по типу: на rust написали аналог %программа-нейм%. Люди любят писать свои аналоги ради получения опыта, это понятно, но в чём смысл это освещать, и почему освещаются в основном аналоги, написанные на rust? Едва ли кому-то захочется менять tmux или что-то ещё проверенное временем на очередной аналог на rust/zig/odin/ваш любимый язык.
Я бы не назвал это стагнацией. Если у вас есть хороший инструмент, который решает ваши проблемы, зачем его менять? Если есть какие-то раздражающие моменты, то их надо устранять, если нет, то зачем пробовать новые/плагины? Насчёт telescope согласен, но о нём я узнал, вбив в гугл что-то вроде vim file search, как раз потому что мне был нужен поиск файлов, то есть была причина искать новый плагин. О treesitter я узнал из новостей, попробовал и выкинул, потому что подсветка стала хуже (возможно, мне просто повезло с используемыми языками)
В таких случаях спасает гугл. В остальных может помочь просмотр конфигов других разработчиков. Я о некоторых полезных фичах, например об относительной нумерации, так и узнал, посматривая конфиг одного разработчика, который делает интересные мне проекты.
Я нигде не смотрю, один раз настроил и пользуюсь. Если сталкиваюсь с какой-либо проблемой, то гуглю как её решить. Зачем гнаться за трендами и искать новые плагины, если итак всё работает? От awesome-neovim и прочих готовых конфигураций больше вреда, чем пользы. Свою конфигурацию я вдоль и поперёк знаю, потому что каждую строку сам писал, а в готовых ещё и разбираться надо, плюс там куча лишнего. В этом по-моему и есть плюс конструкторов типа вима, емакса и т.п. - вы добавляете только то, что вам нужно и так, как это вам нужно.
Я не могу с вима уже никуда уйти, например. В своё время пользовался им, потому что комп ничего другого не тянул, сейчас пользуюсь, потому что работаю с разными языками, с которыми вим отлично справляется (под большее количество из них впрочем и IDE нет). Но в основном это дело привычки. Я бы не сказал, что работать в IDE лучше, чем в vim и наоборот.
Честно, лучше бы оно осталось. Популярность у ресурса была бы меньше, но меня, как пользователя, больше интересует качество наполнения, а не количество