Как это потокобезопасной работы нет?! В C11 добавили поддержку тредов, атомиков и вот этого всего. Осталось только мейнтейнереов уговорить переписать свои C90 поделия на этот свежайший стандарт, и тогда заживём! Да, сарказм. Наполовину.
Так в Firefox помимо JS есть ещё поддержка кучи тегов HTML и свойств CSS, дополнительные протоколы и форматы файлов (что у Dillo с поддержкой HTTP/3, AV1, WebP, да хоть просто SVG?)
Вот, например, stdin вполне себе stream, но умеет только read. А stdout - только write. А TCP сокет может read+write, но всё равно не seek. То есть, если вам в аргумент функции write_hello(IStream writer) положили некий неизвестный stream - вы явно должны проверить его, потому что он может не уметь write.
С другой стороны, в Rust сделано именно так, как вам не нравится: Stdin - только Read, TcpStream - Read+Write, File - Read+Write+Seek, и вроде даже это "API чтобы с ними по отдельности работать" проблем не вызывает, наоборот понятно кто что умеет, безо всяких if(stream.can_write())
Даже без танцев с аллокаторами, простой вынос "числодробильности" в отдельные объекты, выделяющие память (да и просто выполняющие тяжёлые операции вроде создания вспомогательных файлов, соединений, потоков, каких-нибудь fftw_plan , чтения и обработки конфигов, и прочей вспомогательной ерунды) только при создании зачастую уже достаточно. А если не пересоздавать эти объекты-числодробилки с нуля, а переиспользовать старые (те самые worker pool) - так и вовсе красота.
Самое грустное, что на Python уже некоторое время можно накидывать типы, но в доке чёрным по серому написано
Note: The Python runtime does not enforce function and variable type annotations. They can be used by third party tools such as type checkers, IDEs, linters, etc.
Даже без участия голов слишком много вопросов, что нужно автоматически убрать с капота (или перейти в состояние "я стою пока не кожаные мешки это уберут с меня"), а что игнорировать: снег, даже если его 15 сантиметров? кирпич? котейку? пакет или лист бумаги, который принесло ветром? а если это не ветром принесло, а человек засунул под дворник рекламу? а если это не реклама, а штрафная квитанция (или как это там называется)?
... обнаружили, что установка дорожного конуса на капот автомобиля парализует работу машин ... пока сотрудники службы эксплуатации такси или прохожие не уберут конус с капота.
Эм.. То есть по мнению исследователей машины должны продолжать работать как будто этого конуса там нет? Чтобы этот конус на ближайшем повороте прилетел в соседнюю машину? Или нужно чтоб каждая машина оснащалась робо-рукой для снятия предметов с капота?
В случае с машиной с водителем, этот конус снял бы водитель, а в автопилотируемой машине, очевидно, нет водителя, так что и снимать некому (кроме тех самых сотрудников службы эксплуатации или прохожих).
Обычные atomic числа подойдут если у вас переменные никак не зависят друг от друга, а могут и зависеть.
Пример: статистика по вызовам и времени работы функции. С независимыми атомиками может случиться, что на читающей стороне вы получите условные fn_calls_under10ms == 100, fn_calls_under100ms == 10, fn_calls_long == 1, а fn_calls_total == 110 (просто потому что он инкрементируется последним). Иногда это приемлемо, а если нет - придётся или делать atomic<call_stats_struct>, или с мьютексом, с мьютексом как будто бы выглядит проще...
Всё пытался вспомнить, какие слова бесят (или хотя бы раздражают) - и пришёл к выводу, что не столь плохи слова, как их неуместное употребление. У нас в команде устоялось слово "таска" (именно женского рода), но один коллега упорно продолжает использовать в мужском роде, и "сделал таск" в первую очередь воспринимается как "сделал [несколько] таск/тасок", а не "сделал [одну] таску". По уровню раздражения - примерно как комар ночью: вроде и пищит тихо, и не кусает, но ТВОЮ ЖЕ МАТЬ КРОВОСОСУЩУЮ!!
А так иногда используем и совсем уж неграмотные слова, например если опять приходится разбираться в JS-лапше (номинально, у нас в команде нет JS-разработчиков, но влезать в проекты соседних команд всё же иногда приходится), или если Jira опять тормозит и не даёт нормально работать, то они "ЖыЕс" и "Жыра" соответственно. Да, "жи-ши", но нет, в подобные моменты они на "жи" не тянут. А Atlassian - те ещё Атласяны...
Используем AWS. В русскоязычных обсуждениях он простой и понятный "А-Вэ-Эс", а вот если с американцами... Их "Эй-Дабйу-Эс" и длиннее, и сложнее произносить, чем просто "Амазон"/"Эм'зон"
Довольно много времени провожу в англоязычных Дискордах. Заметил, что если человек хоть иногда ошибается в использовании there / they're / their или you're / your - он почти наверняка или из Великобритании, или из Америки. Бывают, конечно, и те, кто просто плохо по-английски говорит, но их сразу видно по напрочь поломанной грамматике.
Моё любимое - это когда кто-то возвращается после отсутствия (или просто стример запускает трансляцию на Твиче), и в чате пишут "Your back!". Что, мать вашу, с его спиной не так, что надо обращать внимание: белая, в огне, вообще отсутствует?
Может быть и так. Основной системой что тогда, что сейчас у меня является Windows (хоть и разрабатываем под Linux, но делаем это удалённо, либо "локально" в WSL). Насколько помню, всякие Thunderbird, LibreOffice, Qt Creator, VS Code имеют одинаковые сочетания клавиш и в Win, и на Linux, и это именно Ctrl+H для замены. ... хотя в Qt Creator может и вообще нет отдельного сочетания для замены, там вроде только Ctrl+F ? Эхх, давно уже им не пользовался...
Как бы то ни было, в моём "везде" это всё равно Ctrl+H , так что для меня CLion был непривычно-неприятной белой вороной. Конечно, были и другие причины, почему он мне не понравился (например, тогда, в 2019, он ещё довольно туго работал с Qt).
Если вам он не подходит, то почему он не должен подходит всем?
Я такого не говорил и даже не подразумевал. Более того, мне вообще без разницы, чем пользуетесь вы или кто-либо другой - старый vi, чуть менее старый vim, neovim, emacs, nano, mcedit, VS Code, IDEA, или вообще LibreOffice Writer, главное чтоб не навязывали свой выбор окружающим.
Не нужно. Плагин, стартует сразу, при старте Vim, а LSP-сервер подгружается в фоне.
Согласен, неверно сформулировал мысль. Хотел сказать что-то вроде " всё равно надо дожидаться LSP для полностью готового окружения". Так-то и в других IDE-редакторах процесс анализа проекта обычно идёт фоном, и можно начинать редактировать файл сильно раньше, чем всё будет готово полностью.
никакой конкретной привязки к прошлому
Логично, что должно быть какое-то разумное ограничение, но речь идёт именно о 80 символах. 80 символов - это примерно треть ширины экрана (обычного, FullHD). Я согласен, что читать текст, размазанный по всей ширине экрана не очень удобно, но ТРЕТЬ? Много проектов перешли на 120 символов в ширину (или требуют их с самого начала), это хотя бы половина экрана получается, спасибо им. Для печати - возможно, около 80 символов в самый раз (хотя опять-таки, почему не 70 и не 90, а именно 80?) Померил только что размер шрифта в "Совершенном коде" Макконнелла от БХВ - там как раз 80 выходит на ширину страницы (20 символов на 3 см). На альбомный же лист спокойно поместились бы все 120...
Что мешает, например, графическим эмуляторам терминалов иметь ширину по умолчанию в те же 120 символов? Но нет, если открыть условный Git Bash или терминал XFCE, то они будут иметь размер 80х24, прям как VT100, прям как перфокарты IBM. Хотя в Windows Terminal, например, осмелились проигнорировать это сомнительное наследие, там размер аж 120х30.
Vim, и тем более vi, теряют популярность из-за форков, того же NeoVim.
А вот почему всё семейство пользуется популярностью (относительной) - нет, не понимаю.
Без супер-конфига (кстати, почему скрипты на vimscript/Lua называют "конфигами", хотя тот же .bashrc - это всё равно скрипт, хоть и настраивающий окружение?) и пачки плагинов сам редактор может выполнять только некоторые... интересные действия, польза которых зачастую сомнительна (типа "прыгнуть на 3 слова вперёд").
С плагинами - это всё равно не "vim такой мощный и удобный", это "плагины такие мощные и удобные, спасибо vim что имеет поддержку плагинов".
Кстати, один из основных аргументов в пользу vi-семейства - "я могу делать то же самое, что и IDE, с помощью LSP". Интересно, что LSP как технологию придумал и реализовал не кто-нибудь из сообщества vim, а ребята из Microsoft для VS Code... Похоже, что vi-сообществу было нормально не уметь подражать IDE, пока не появился другой редактор, который умеет. Вот она, конкуренция, толкающая прогресс.
Аргумент "нужно нажимать меньше клавиш для редактирования" - странный из-за методики подсчёта. В некоторых случаях - да, соглашусь. В некоторых - наоборот. Почему-то vim-пользователи любят считать горячие клавиши современных редакторов/IDE так: "Ctrl+S = два нажатия", а "Ctrl+Shift+S = три", но при этом и d, и D - одно (хотя второе - это явное "Shift+D"), и обычно совсем игнорируют бесконечные Esc.
Скорость работы самого редактора как обычно демонстрируют (например, упомянутый где-то здесь Primeagen)? Правильно - переключаясь между разными файлами, или вовсе между файлом и навигацией по ФС, раз 5 туда-сюда. Разумеется, переключает это всё не сам редактор, а плагин(-ы). Это примерно как демонстрировать комфорт автомобиля открывая и закрывая багажник.
Часто ещё любят хвалить быстрый запуск (по сравнению с IDE). С появлением и распространением LSP, время старта клиента становится несущественным, потому что всё равно надо дожидаться загрузки и готовности этого самого LSP. А замерять время старта только редактора-оболочки... пустые, без проекта, IDE обычно тоже запускаются довольно быстро, особенно нынче, на SSD. Да и обычно этот запуск происходит всего пару раз за день. Это ж за месяц может суммарно накопиться десяток минут разницы, как раз будет время с конфигом поиграться.
В итоге, большинство аргументов в пользу использования vim-семейства как будто бы являются актуальными не столько для разработчиков, сколько для админов, которым и ходить по разным серверам приходится (а там как раз уже стоит vim!), и вносить точечные изменения в произвольные файлы в произвольные моменты времени (тут и может понадобиться та самая "странная навигация" и быстрый запуск).
Несколько другой вопрос про vim-управление в других редакторах/IDE, но это уже больше дело привычки. Я, например, в своё время не подружился с CLion именно потому, что в IDE от JetBrains горячие клавиши, мягко говоря, отличаются от тех, которые можно встретить в большинстве других IDE/редакторах; ключевым отличием для меня стало то, что Replace (в открытом файле) - это почему-то Ctrl+R, хотя везде это Ctrl+H. И нет, я всё равно не понимаю, зачем в современных, графических редакторах может понадобиться модальность.
Ну и наконец нельзя не вспомнить про другие явления, которые "прошли проверку временем". Сколько проектов в своих стандартах форматирования кода до сих пор требуют ширину 80 символов, потому что перфокарты IBM стандарта 1928 года были шириной в 80 символов (а потом "ну так исторически сложилось, значит прошло проверку временем, значит правильно")?
люди там только ради халявы и эксклюзивов, коих нет в стиме
Более чем достаточный аргумент использовать EGS, ведь люди что его, что Steam (что другие лаунчеры) ставят не ради самих лаунчеров, а ради доступных игр.
Как можно путать баш и шелл, если bash и есть shell (один из многих)?
А так, что есть оригинальный sh (который и есть shell), и есть множество потомков-наследников: bash, dash, fish, zsh, и так далее. У них у всех свои собственные фишечки, делающие их не очень совместимыми друг с другом, чего только стоит разное поведение echo в отдельных сценариях.
“консоль гит и консоль гит-баш”.
Git for Windows создаёт ярлык и для Git Bash, и для Git CMD. Они оба откроют консоль, но очень разную.
Как это потокобезопасной работы нет?! В C11 добавили поддержку тредов, атомиков и вот этого всего. Осталось только мейнтейнереов уговорить переписать свои C90 поделия на этот свежайший стандарт, и тогда заживём!
Да, сарказм. Наполовину.
Так в Firefox помимо JS есть ещё поддержка кучи тегов HTML и свойств CSS, дополнительные протоколы и форматы файлов (что у Dillo с поддержкой HTTP/3, AV1, WebP, да хоть просто SVG?)
Это почти как сравнивать Блокнот и Visual Studio
Вот, например, stdin вполне себе stream, но умеет только read. А stdout - только write. А TCP сокет может read+write, но всё равно не seek. То есть, если вам в аргумент функции write_hello(IStream writer) положили некий неизвестный stream - вы явно должны проверить его, потому что он может не уметь write.
С другой стороны, в Rust сделано именно так, как вам не нравится: Stdin - только Read, TcpStream - Read+Write, File - Read+Write+Seek, и вроде даже это "API чтобы с ними по отдельности работать" проблем не вызывает, наоборот понятно кто что умеет, безо всяких
if(stream.can_write())Даже без танцев с аллокаторами, простой вынос "числодробильности" в отдельные объекты, выделяющие память (да и просто выполняющие тяжёлые операции вроде создания вспомогательных файлов, соединений, потоков, каких-нибудь
fftw_plan, чтения и обработки конфигов, и прочей вспомогательной ерунды) только при создании зачастую уже достаточно. А если не пересоздавать эти объекты-числодробилки с нуля, а переиспользовать старые (те самые worker pool) - так и вовсе красота.Самое грустное, что на Python уже некоторое время можно накидывать типы, но в доке чёрным по серому написано
Но это уже будет как в Тулу со своим самоваром :)
Даже без участия голов слишком много вопросов, что нужно автоматически убрать с капота (или перейти в состояние "я стою пока не кожаные мешки это уберут с меня"), а что игнорировать: снег, даже если его 15 сантиметров? кирпич? котейку? пакет или лист бумаги, который принесло ветром? а если это не ветром принесло, а человек засунул под дворник рекламу? а если это не реклама, а штрафная квитанция (или как это там называется)?
Эм.. То есть по мнению исследователей машины должны продолжать работать как будто этого конуса там нет? Чтобы этот конус на ближайшем повороте прилетел в соседнюю машину? Или нужно чтоб каждая машина оснащалась робо-рукой для снятия предметов с капота?
В случае с машиной с водителем, этот конус снял бы водитель, а в автопилотируемой машине, очевидно, нет водителя, так что и снимать некому (кроме тех самых сотрудников службы эксплуатации или прохожих).
Обычные atomic числа подойдут если у вас переменные никак не зависят друг от друга, а могут и зависеть.
Пример: статистика по вызовам и времени работы функции. С независимыми атомиками может случиться, что на читающей стороне вы получите условные
fn_calls_under10ms== 100,fn_calls_under100ms== 10,fn_calls_long== 1, аfn_calls_total== 110 (просто потому что он инкрементируется последним). Иногда это приемлемо, а если нет - придётся или делатьatomic<call_stats_struct>, или с мьютексом, с мьютексом как будто бы выглядит проще...Всё пытался вспомнить, какие слова бесят (или хотя бы раздражают) - и пришёл к выводу, что не столь плохи слова, как их неуместное употребление. У нас в команде устоялось слово "таска" (именно женского рода), но один коллега упорно продолжает использовать в мужском роде, и "сделал таск" в первую очередь воспринимается как "сделал [несколько] таск/тасок", а не "сделал [одну] таску". По уровню раздражения - примерно как комар ночью: вроде и пищит тихо, и не кусает, но ТВОЮ ЖЕ МАТЬ КРОВОСОСУЩУЮ!!
А так иногда используем и совсем уж неграмотные слова, например если опять приходится разбираться в JS-лапше (номинально, у нас в команде нет JS-разработчиков, но влезать в проекты соседних команд всё же иногда приходится), или если Jira опять тормозит и не даёт нормально работать, то они "ЖыЕс" и "Жыра" соответственно. Да, "жи-ши", но нет, в подобные моменты они на "жи" не тянут. А Atlassian - те ещё Атласяны...
Используем AWS. В русскоязычных обсуждениях он простой и понятный "А-Вэ-Эс", а вот если с американцами... Их "Эй-Дабйу-Эс" и длиннее, и сложнее произносить, чем просто "Амазон"/"Эм'зон"
Довольно много времени провожу в англоязычных Дискордах. Заметил, что если человек хоть иногда ошибается в использовании there / they're / their или you're / your - он почти наверняка или из Великобритании, или из Америки. Бывают, конечно, и те, кто просто плохо по-английски говорит, но их сразу видно по напрочь поломанной грамматике.
Моё любимое - это когда кто-то возвращается после отсутствия (или просто стример запускает трансляцию на Твиче), и в чате пишут "Your back!". Что, мать вашу, с его спиной не так, что надо обращать внимание: белая, в огне, вообще отсутствует?
Может быть и так. Основной системой что тогда, что сейчас у меня является Windows (хоть и разрабатываем под Linux, но делаем это удалённо, либо "локально" в WSL). Насколько помню, всякие Thunderbird, LibreOffice, Qt Creator, VS Code имеют одинаковые сочетания клавиш и в Win, и на Linux, и это именно
Ctrl+Hдля замены.... хотя в Qt Creator может и вообще нет отдельного сочетания для замены, там вроде только
Ctrl+F? Эхх, давно уже им не пользовался...Как бы то ни было, в моём "везде" это всё равно
Ctrl+H, так что для меня CLion был непривычно-неприятной белой вороной. Конечно, были и другие причины, почему он мне не понравился (например, тогда, в 2019, он ещё довольно туго работал с Qt).Я такого не говорил и даже не подразумевал. Более того, мне вообще без разницы, чем пользуетесь вы или кто-либо другой - старый vi, чуть менее старый vim, neovim, emacs, nano, mcedit, VS Code, IDEA, или вообще LibreOffice Writer, главное чтоб не навязывали свой выбор окружающим.
Согласен, неверно сформулировал мысль. Хотел сказать что-то вроде " всё равно надо дожидаться LSP для полностью готового окружения". Так-то и в других IDE-редакторах процесс анализа проекта обычно идёт фоном, и можно начинать редактировать файл сильно раньше, чем всё будет готово полностью.
Логично, что должно быть какое-то разумное ограничение, но речь идёт именно о 80 символах. 80 символов - это примерно треть ширины экрана (обычного, FullHD). Я согласен, что читать текст, размазанный по всей ширине экрана не очень удобно, но ТРЕТЬ? Много проектов перешли на 120 символов в ширину (или требуют их с самого начала), это хотя бы половина экрана получается, спасибо им.
Для печати - возможно, около 80 символов в самый раз (хотя опять-таки, почему не 70 и не 90, а именно 80?) Померил только что размер шрифта в "Совершенном коде" Макконнелла от БХВ - там как раз 80 выходит на ширину страницы (20 символов на 3 см). На альбомный же лист спокойно поместились бы все 120...
Что мешает, например, графическим эмуляторам терминалов иметь ширину по умолчанию в те же 120 символов? Но нет, если открыть условный Git Bash или терминал XFCE, то они будут иметь размер 80х24, прям как VT100, прям как перфокарты IBM. Хотя в Windows Terminal, например, осмелились проигнорировать это сомнительное наследие, там размер аж 120х30.
Vim, и тем более vi, теряют популярность из-за форков, того же NeoVim.
А вот почему всё семейство пользуется популярностью (относительной) - нет, не понимаю.
Без супер-конфига (кстати, почему скрипты на vimscript/Lua называют "конфигами", хотя тот же
.bashrc- это всё равно скрипт, хоть и настраивающий окружение?) и пачки плагинов сам редактор может выполнять только некоторые... интересные действия, польза которых зачастую сомнительна (типа "прыгнуть на 3 слова вперёд").С плагинами - это всё равно не "vim такой мощный и удобный", это "плагины такие мощные и удобные, спасибо vim что имеет поддержку плагинов".
Кстати, один из основных аргументов в пользу vi-семейства - "я могу делать то же самое, что и IDE, с помощью LSP". Интересно, что LSP как технологию придумал и реализовал не кто-нибудь из сообщества vim, а ребята из Microsoft для VS Code... Похоже, что vi-сообществу было нормально не уметь подражать IDE, пока не появился другой редактор, который умеет. Вот она, конкуренция, толкающая прогресс.
Аргумент "нужно нажимать меньше клавиш для редактирования" - странный из-за методики подсчёта. В некоторых случаях - да, соглашусь. В некоторых - наоборот. Почему-то vim-пользователи любят считать горячие клавиши современных редакторов/IDE так: "Ctrl+S = два нажатия", а "Ctrl+Shift+S = три", но при этом и d, и D - одно (хотя второе - это явное "Shift+D"), и обычно совсем игнорируют бесконечные Esc.
Скорость работы самого редактора как обычно демонстрируют (например, упомянутый где-то здесь Primeagen)? Правильно - переключаясь между разными файлами, или вовсе между файлом и навигацией по ФС, раз 5 туда-сюда. Разумеется, переключает это всё не сам редактор, а плагин(-ы). Это примерно как демонстрировать комфорт автомобиля открывая и закрывая багажник.
Часто ещё любят хвалить быстрый запуск (по сравнению с IDE). С появлением и распространением LSP, время старта клиента становится несущественным, потому что всё равно надо дожидаться загрузки и готовности этого самого LSP. А замерять время старта только редактора-оболочки... пустые, без проекта, IDE обычно тоже запускаются довольно быстро, особенно нынче, на SSD. Да и обычно этот запуск происходит всего пару раз за день. Это ж за месяц может суммарно накопиться десяток минут разницы, как раз будет время с конфигом поиграться.
В итоге, большинство аргументов в пользу использования vim-семейства как будто бы являются актуальными не столько для разработчиков, сколько для админов, которым и ходить по разным серверам приходится (а там как раз уже стоит vim!), и вносить точечные изменения в произвольные файлы в произвольные моменты времени (тут и может понадобиться та самая "странная навигация" и быстрый запуск).
Несколько другой вопрос про vim-управление в других редакторах/IDE, но это уже больше дело привычки. Я, например, в своё время не подружился с CLion именно потому, что в IDE от JetBrains горячие клавиши, мягко говоря, отличаются от тех, которые можно встретить в большинстве других IDE/редакторах; ключевым отличием для меня стало то, что Replace (в открытом файле) - это почему-то Ctrl+R, хотя везде это Ctrl+H. И нет, я всё равно не понимаю, зачем в современных, графических редакторах может понадобиться модальность.
Ну и наконец нельзя не вспомнить про другие явления, которые "прошли проверку временем". Сколько проектов в своих стандартах форматирования кода до сих пор требуют ширину 80 символов, потому что перфокарты IBM стандарта 1928 года были шириной в 80 символов (а потом "ну так исторически сложилось, значит прошло проверку временем, значит правильно")?
Как вам, нормально на проверенном годами ADM-3A работается в 2023?
Более чем достаточный аргумент использовать EGS, ведь люди что его, что Steam (что другие лаунчеры) ставят не ради самих лаунчеров, а ради доступных игр.
А так, что есть оригинальный sh (который и есть shell), и есть множество потомков-наследников: bash, dash, fish, zsh, и так далее. У них у всех свои собственные фишечки, делающие их не очень совместимыми друг с другом, чего только стоит разное поведение echo в отдельных сценариях.
Git for Windows создаёт ярлык и для Git Bash, и для Git CMD. Они оба откроют консоль, но очень разную.
Профессиональные навыки и навыки общения?
Очевидно же, что в запущенном thread'е открывается stream, а в него пишется stream.