В общем и целом тема в принципе лежит на опасной грани к философствованиям, и точно в области субъективных оценок. Я рассказал, что подразумеваю под аугментами, дальше конструктивный спор как построить не вижу если честно, т.к. могу как согласиться с вашими замечаниями, так и спорить:) Все мои субъективные оценки говорят, что кодовую базу написанную не в IDE(хотя бы ядро) читать и вообще поддерживать приятней, может это просто так попадалось, или приятней лично мне.
Единственное чего может добавить контекста к моим высказываниям это:
Я году в 2008-м тоже думал (и кое-где громко говорил), что интеллисенс для моего кода на плюсах — не нужен и от лукавого, и вот я сижу в виме и мне норм. А потом оказалось, что интеллисенс — это удобно. Автоматическая вставка нужного #include — удобно. Переход к определению символа или поиск всех его использований — это удобно (особенно со всякими там перегрузками, когда грепа не хватает). Это всё повышает мою продуктивность. Стал ли я от этого хуже как специалист? Вряд ли.
Я тут скорее с обратной стороны заходил, в том плане что как раз лет 5 назад ещё активно хвалил интелисенс и говорил старшим разработчикам(не в одной команде и не в одной компании) — вот вы дураки в своих блокнотах сидите:) На что они говорили — "ого, и правда крутая штука", однако — почему-то продолжали сидеть в блокнотах. Потом и я как-то плавно пересел — мне просто стало влом сначала настраивать, потом запускать(иногда), а потом и ставить ide, тем более к тому моменту мой вимовский конфиг стал более менее работоспособным после адаптаций на конфигах и одноразовых скриптах. Сейчас я иногда и части своего конфига перестаю использовать. Т.е. у меня какая-то обратная деградация происходит :) Стал ли я как специалист лучше? Хочется верить...
Смотрел месяца 3 назад обзор на тему dex-подобных конвергенций, пока лидером выглядит как ни странно решение от huawei, несмотря на то, что его пиарят гораздо меньше чем решение от samsung.
Вообще мне нравится движуха которая сейчас происходит в проекте UBports. Похоже ребятки отошли от того, что canonical их выгнала на мороз. Так-что не исключенно, что всякие pinephones неожиданно быстрее окажутся для этого сценария использования более привлекательными. Это с прицелом на то, что гугл портировал flutter под gnu/linux, а snap по функционалу уже практически догнал андроидовские песочницы. Ну и другие мобильнориентированные проекты типа MaruOS и KDE Mobile тоже вполне себе живут поживают и даже продаются уже на реальных, и что важно — новых устройствах.
Вообще — сам в предвкушении когда вместо ноута можно будет мобилку полноценно прицепить. Хотя применительно к хедпосту это тот ещё оффтоп всё.
Хм, я точно не в том ключе понял вашу изначальную мысль.
Я вот как на это смотрю — есть код, есть штуки которые к нему дорисовывают и докидывают дополнительную инфу. Код написанный тем кто видит всю эту "дополненную реальность" — зачастую читать намного сложнее без неё, чем код не полагающийся на инструменты отличные от текста и выразительных средств языка.
Это разница примерно такого уровня, как когда читаешь текст и видишь в нём ошибки, по сравнению с тем, когда пишешь текст в текстовом процессоре и ошибки подсвечиваются. С одной стороны — количество ошибок в тексте написанном в процессоре будет ниже, но это про ошибки контекста 1-2 абзаца. С другой стороны, грамотный человек со знанием языка — избежит большую часть локальных ошибок, и скорее всего — построит текст ощутимо лучше за границами контекста доступного инструментам, т.к. протезы пока-что не настолько совершенны.
Т.е. под аугментами я подразумеваю именно те инструменты и технологии, которые "позволяют неподготовленному человеку под 300кг веса бежать со скоростью хорошего спринтера".
Правда — тут непонятно где провести грань, например можно считать, что подсветка синтаксиса это такой же аугмент, как и интерактивные текстовые редакторы. Лично я для себя разграничиваю так — если мне сложно назвать незаброшенный авторами инструмент, где этот уровень поддержки не обеспечен — это можно уже принимать как данность, в противном случае это протез в стиле киберпанка.
Не все среды что-то дорисовывают. Атавизм ли это, или упражнение на подумать(и как записать и как почитать) это вопрос философский. По себе могу сказать, что последние n раз лазил по незнакомым кодовым базам даже не прикручивая к виму ни семантических подсветок (та самая автодорисовка буковки I) ни даже навигации по коду, хотя, оно всё есть и даже более чем сносно работает. А иногда и ужос ужос, прямо на житхабе получалось всё что нужно высмотреть:)
Учитывая, что код тех проектов писался профессионалами, я практически не заметил разницу, дискомфорта — точно не испытал. А если какой-то код на знакомом языке(что зачастую нынче редкость для многих представителей), плохо читается в таком виде, то он и в IDE хорошо читаться не будет особо долго.
Очевидно — чтобы смотреть код в сплитах и sbs диффах в шрифтах от которых не вытекают глазки. Про 3-way merge я уже молчу, тут всё равно дисплей меньше 27" подходит плохо если хочется ещё какой-то контекст наблюдать.
Я сказал — погодь, но это же пережиток прошлого — времени, когда IDE не умела их подсвечивать. Теперь умеет, префикс летит на свалку истории
Прям вижу как вас поддержали пользователи vim'ов, и прочие товарищи которым не нужны аугменты для понимания чего творится в их собственном коде. Не задумывались, что лид потому и лид, что понимает код без IDE смотря его с телефона?
Предлагаю заодно избавиться от ограничений текста по ширине, ведь IDE умеет его рисовать красиво даже в таком случае.
О, точно, я даже не знал что его нет. Но, вообще можно накостылить по идее с тем же termux + x11sdl. Так же, мобильный клиент конечно есть, под kde mobile или ubports, вот устройств поддерживаемых этими ОС в полной мере практически нет:(
Учитывая, что речь про дистрибутивы gnu/linux — крайне рекомендую попробовать x2go, его обычно достаточно в электричке с lte для вещей использующих ускорение(например QtCreator, glxgears e.t.c.).
p.s. Про переоценку частных случаев больше даже относится к комментарию maydjin выше, исходя из комментария которого выходит что все кто не работает над кодовой базой сравнимой по объёмом с базой хромиума «не очень квалифицированные кадры».
Во-первых никого не хотел задеть вышеуказанной фразой. И уж тем более не считаю, что разработка небольших и шустрых проектов требует меньше квалификации, чем разработка больших (в случае хромого, я бы даже сказал монструозных) кодовых баз.
Во-вторых — ничто не истина в последней инстанции, более того — органы у всех находятся в разном состоянии, я вот например много играл в очень динамичные игрушки с минимальным пингом 5ms и видимо это заставило меня уметь различать разницу между 5ms и 10ms rtt на глаз при наличии тактильного отклика, я считаю, что это скорее плохо чем хорошо для моего душевного состояния если честно. К примеру — иногда ловлю лаг своей bluetooth клавиатуры, когда она подключенна не по проводу(к слову, в 2.4Ггц решениях такого не замечал, точнее замечал только на мышках и только в играх).
В третьих — vim можно настроить до состояния "лагает", и даже не очень сложно. А можно и не настраивать. Вот с настройкой ide обычно выходит сложнее, есть вещи которые решили за вас и их объективно больше, и это приятно с одной стороны, люблю когда кто-то что-то делает вместо меня. Но при этом — нет свободы отключить или заменить что-то, а коробка может не радовать. Тот же CLion кажется тормозом даже после QtCreator, примерно таким же, как Eclipse на фоне всех их. Я потрудился в 5-7 ide, во многих по несколько лет, поэтому, хочется верить, что мои замечания могут быть хоть от части объективными. К слову — тот же QtCreator единственный не вызывал у меня отторжений по времени отклика, пока я не начал перезжать на удалённый конфиг. Разница в том, что qtc начинает выдавать видимые для меня фризы на пинге 40 до целевого хоста, а vte-based терминал + ssh + vim на 80(а это уже даже для lte много).
Потому, что не изобрели ещё мощных ноутов которые держат батарейку хотя бы 8 часов и весят так, что бы не нужно было бы быть атлетом для их регулярного перемещения и комфортной работы. При этом получаемая производительность на выходе всё равно остаётся намного ниже. Это к вопросу о мобильности, нужна она не всем и не всегда. Но тем не менее, почему-то куча народу таскает с собой эти коробочки с микросхемами.
Второй момент сборный, это шум, пыль, занимаемое свободное место. Если вас шум вентилятора не отвлекает — окей. Я вот когда слышу этот чудный звук — ищу виновника и причиняю ему -9 и прочие радости доставляю. Можно взять рабочую станцию с водянкой например — это вполне себе вариант, но он ощутимо дороже, не мобильный и занимает непозволительно много свободного места, при условии, что этого можно было бы и избежать. Мы же не в 90ых живём в конце концов, я вот планирую в этом году переехать на разработку со своего телефона полностью, ноут большой и тяжёлый же.
Третий момент самый тонкий, спорный и низкоприоритетный — время отклика. Казалось бы сети должны его повысить, но, как показывает практика, многие GUI решения локально оказываются в этом плане тупее, чем терминал по ssh с пингом 60 например до свободного железа. Ноги у этого феномена растут понятно откуда — в условиях вытесняющей многозадачности, на клиентском терминале за ресурсы дерутся куда больше приложений и служб, чем на выделенном удалённом и когда в игру вступает такая сложная система как IDE — мы видим нестыковки в процессах планирования и артефакты борьбы за ресурсы. Когда я вижу фриз в каком нить VisualStudio PRO за многоденег, на свежей рабочей станции от какого нить HP тоже за многоденег, меня это расстраивает. Не сильно, но достаточно, что бы я написал об этом параграф приведённого размера. И достаточно, что бы моё душевное спокойствие вернулось в норму при открытии того же кода в другом решении.
Хм с помощью boost::python например, я делал в обе стороны интеграции (плюсы в python и python в плюсы), не помню, что бы встретил какие-то трудности на этом пути, разницы с lua я практически не увидел, а бустовый сахар сделал процесс даже проще. Но у меня требования об ограничении доступа в стандартную библиотеку не стояли, вполне допускаю что это может быть нетривиально, т.к. обширная стандартная библиотека это один из основных критериев выбора обычно.
Что касается JS — там API чуть сложнее(ну и реализаций минимум 2), но зато стандартной библиотеки — практически просто нет, а потоки хотя бы упоминаются в документации (в том плане что есть re-entrant, что есть thread-safe и какой ценой). По эффективности итогового решения, с включенным jit оно сравнимо или лучше lua (python тут в уверенном хвосте плетётся). Т.е. для конкурентных высоконагруженных приложений я бы несколько раз тщательно взвесил сравнения lua/js и произвёл бы бенчмарки для типовых случаев. Думаю цена интеграции реализаций рассчитанных на встраивание была бы тут ничтожно малой.
Lua — конечно чемпион в плане простоты интеграции и быстрого старта, но это практически единственное его достоинство. Очень узкие комьюнити владеющих этим языком профессионально, поэтому вынести значительную часть бизнесс логики туда — часто выглядит сомнительным решением, даже на фоне чуть более высокой технической сложности для более распостранёныйх технологий. Я не говорю что это совсем не кейс, кейс и ещё какой, т.к. комьюнити имеют место быть, но подумать надо n, а лучше n+1 раз :)
Итого, для себя я сформировал такой чеклист:
Есть комьюнити, клиент ожидает увидеть lua — берём lua, при условии, что нет необходимости иметь более широкие возможности быстрого прототипирования
Основная цель быстрое прототипирование и лёгкий вход небольшой и обученной группы, целевая аудитория не связанна с web-frontend, нет высоких нефункциональных требований — берём python
Есть web-oriented комьюнити, есть высокие нефункциональные требования, требуется широкая аудитория — берём ecma script
Когда я говорю про высоконагруженные решения, я не имею ввиду i/o-bound решения. Там лучше выбирать то, на чём удобней будет писать скрипты конечному пользователю, остальное, в основном, это единоразовые затраты, хотя кейс с запретом импорта стандартной библиотеки таковым не кажется, и может потребовать поддержки.
Могу перефразировать вас немного, тогда поинт выше возможно станет более понятным:
Довольно больно разрабатывать средний или крупный проект без разбиения на подпроекты и тестов интерфейсов этих подпроектов. Так же — в нём сложно искать ошибки реализаций без хорошей подсистемы логгирования и/или трассировки.
Когда требования выше соблюдаются — отладчиком приходится пользоваться крайне редко, и обычно это какой то изощрённый кейс (типа написать скрипт, который проанализирует в какой точке испортили память которая создавалась в другой точке, но ещё не удалялась в третьей, руками такие сессии могут занимать часы и требовать недюжей внимательности), эти варианты обычно либо не доступны через UI IDE, либо сводятся к обращению к командному интерфейсу отладчика, который и в терминале имеется. В основном как ни странно баги находятся даже не в разрабатываемых продуктах зачастую :)
Это основное заблуждение тех кто трогает vim по минимуму :) Там только возможности редактирования представлены на эти 80-90% и то, обычно в лучшем случае. Т.е. ощущение "я это по-любому сделаю/прикручу" — пропадает, а те 10% в которые втыкаешься из нереализованных или плохореализованных фич слегка сбивают.
В vim8 есть из коробки для gdb, разумеется в стилистике редактора.
Но отладчики тоже переоцененны на мой взгляд :) Хотя это наверное тема для отдельной дискуссии. В кратце моя точка зрения тут такая — простые вещи ловятся тестами, в худшем случае логами, при этом отладочная сессия не попадает в /dev/null, а остаётся в виде артефакта в кодовой базе. А для сложных вещей всё равно приходится открывать терминал этого самого отладчика, а то и скрипт писать, так какая разница делать это в IDE, или в другом терминале?
Работа на удалённой машине так же реализуема в некоторых IDE. Польза от работы на удалённой машине в том, что вы можете трудиться с лёгкого и сравнительно дешёвого терминала, утилизируя мощное серверное железо, без шума пыли. Я вот например сильно не уверен, что вы прямо сейчас сходу сможете начать работать с кодовой базой chromium на своём текущем конфиге без его апргрейда по железу :)
Нисколько он никогда не начнёт выигрывать в том смысле который вы(и куча людей включая меня в прошлом) рисуете у себя в голове :) Но сами по себе IDE — переоценены, это просто способ посадить не очень квалифицированные кадры выполнять типовые рутинные задачи максимально быстро(и посадить и выполнять).
Раньше я дивился с того, что очень технически крутые люди польюзуются для разработки каким нить notepad++ или vim без плагинов. Мне казалось, что я умнее и я им говорил что-то в духе — блин, ну тут даже интеграции с отладчиком нет, ты таааак долго делаешь эту хрень, смотри как у меня в <idename> всё круто. Они соглашались — круто, прикольно, так держать :) Но продолжали пилить код в текстовом редакторе, иногда даже без подсветки синтаксиса. И выполняли задачи, особенно сложные, в разы быстрее чем я…
На данный момент — поймал себя на том, что у меня уже пару месяцев как сломалось автодополнение, но меня это чет как то даже и не парит, вот думаю — может пора начать удалять плагины? Когда по большому счёту используешь только редактор, а те миллисекунды которые выскакивает комплит начинают тебя напрягать а и сбивать с мысли, а инфа в этом комплите выглядит как "да ладно, спасибо кэп", это видимо первые звоночки.
Я это к чему? Когда знаешь чего написать и как отладить — ты просто это записываешь и всё, с тем же усилием, как и документацию, просто на другом я зыке. Потом берёшь и отлаживаешь. А свистелки помогают пока не очень точно уверен, как ты собираешься сделать то, что собрался делать.
Чем хорош конкретно vim? Тем что с ним просто работать на удалённой машине, и он позволяет достаточно просто(так что можно хоть под каждый ишью писать скриптец) и вешать их на горячие клавиши или просто держать близко в истории. Ну и руки с хоумроу можно не убирать практически никогда (не для всех это плюс, помахать мышкой — тоже своя развлекуха имеется). Ну, ещё конфиг сравнительно просто утаскивается и размножается.
В общем и целом тема в принципе лежит на опасной грани к философствованиям, и точно в области субъективных оценок. Я рассказал, что подразумеваю под аугментами, дальше конструктивный спор как построить не вижу если честно, т.к. могу как согласиться с вашими замечаниями, так и спорить:) Все мои субъективные оценки говорят, что кодовую базу написанную не в IDE(хотя бы ядро) читать и вообще поддерживать приятней, может это просто так попадалось, или приятней лично мне.
Единственное чего может добавить контекста к моим высказываниям это:
Я тут скорее с обратной стороны заходил, в том плане что как раз лет 5 назад ещё активно хвалил интелисенс и говорил старшим разработчикам(не в одной команде и не в одной компании) — вот вы дураки в своих блокнотах сидите:) На что они говорили — "ого, и правда крутая штука", однако — почему-то продолжали сидеть в блокнотах. Потом и я как-то плавно пересел — мне просто стало влом сначала настраивать, потом запускать(иногда), а потом и ставить ide, тем более к тому моменту мой вимовский конфиг стал более менее работоспособным после адаптаций на конфигах и одноразовых скриптах. Сейчас я иногда и части своего конфига перестаю использовать. Т.е. у меня какая-то обратная деградация происходит :) Стал ли я как специалист лучше? Хочется верить...
Смотрел месяца 3 назад обзор на тему dex-подобных конвергенций, пока лидером выглядит как ни странно решение от huawei, несмотря на то, что его пиарят гораздо меньше чем решение от samsung.
Вообще мне нравится движуха которая сейчас происходит в проекте UBports. Похоже ребятки отошли от того, что canonical их выгнала на мороз. Так-что не исключенно, что всякие pinephones неожиданно быстрее окажутся для этого сценария использования более привлекательными. Это с прицелом на то, что гугл портировал flutter под gnu/linux, а snap по функционалу уже практически догнал андроидовские песочницы. Ну и другие мобильнориентированные проекты типа MaruOS и KDE Mobile тоже вполне себе живут поживают и даже продаются уже на реальных, и что важно — новых устройствах.
Вообще — сам в предвкушении когда вместо ноута можно будет мобилку полноценно прицепить. Хотя применительно к хедпосту это тот ещё оффтоп всё.
Хм, я точно не в том ключе понял вашу изначальную мысль.
Я вот как на это смотрю — есть код, есть штуки которые к нему дорисовывают и докидывают дополнительную инфу. Код написанный тем кто видит всю эту "дополненную реальность" — зачастую читать намного сложнее без неё, чем код не полагающийся на инструменты отличные от текста и выразительных средств языка.
Это разница примерно такого уровня, как когда читаешь текст и видишь в нём ошибки, по сравнению с тем, когда пишешь текст в текстовом процессоре и ошибки подсвечиваются. С одной стороны — количество ошибок в тексте написанном в процессоре будет ниже, но это про ошибки контекста 1-2 абзаца. С другой стороны, грамотный человек со знанием языка — избежит большую часть локальных ошибок, и скорее всего — построит текст ощутимо лучше за границами контекста доступного инструментам, т.к. протезы пока-что не настолько совершенны.
Т.е. под аугментами я подразумеваю именно те инструменты и технологии, которые "позволяют неподготовленному человеку под 300кг веса бежать со скоростью хорошего спринтера".
Правда — тут непонятно где провести грань, например можно считать, что подсветка синтаксиса это такой же аугмент, как и интерактивные текстовые редакторы. Лично я для себя разграничиваю так — если мне сложно назвать незаброшенный авторами инструмент, где этот уровень поддержки не обеспечен — это можно уже принимать как данность, в противном случае это протез в стиле киберпанка.
Не все среды что-то дорисовывают. Атавизм ли это, или упражнение на подумать(и как записать и как почитать) это вопрос философский. По себе могу сказать, что последние n раз лазил по незнакомым кодовым базам даже не прикручивая к виму ни семантических подсветок (та самая автодорисовка буковки I) ни даже навигации по коду, хотя, оно всё есть и даже более чем сносно работает. А иногда и ужос ужос, прямо на житхабе получалось всё что нужно высмотреть:)
Учитывая, что код тех проектов писался профессионалами, я практически не заметил разницу, дискомфорта — точно не испытал. А если какой-то код на знакомом языке(что зачастую нынче редкость для многих представителей), плохо читается в таком виде, то он и в IDE хорошо читаться не будет особо долго.
Очевидно — чтобы смотреть код в сплитах и sbs диффах в шрифтах от которых не вытекают глазки. Про 3-way merge я уже молчу, тут всё равно дисплей меньше 27" подходит плохо если хочется ещё какой-то контекст наблюдать.
Прям вижу как вас поддержали пользователи vim'ов, и прочие товарищи которым не нужны аугменты для понимания чего творится в их собственном коде. Не задумывались, что лид потому и лид, что понимает код без IDE смотря его с телефона?
Предлагаю заодно избавиться от ограничений текста по ширине, ведь IDE умеет его рисовать красиво даже в таком случае.
Тайп цэ док! Он работает! Ничоси!!!
Ммм… кто-то ставит себя выше других соучастников. Интересно, автор опуса способен вообще внятно пояснить, откуда берутся задачи на доске?:)
А пост-квантовые сертификаты вы в каком-то виде уже поддерживаете или планируете поддержку?
О, точно, я даже не знал что его нет. Но, вообще можно накостылить по идее с тем же termux + x11sdl. Так же, мобильный клиент конечно есть, под kde mobile или ubports, вот устройств поддерживаемых этими ОС в полной мере практически нет:(
Учитывая, что речь про дистрибутивы gnu/linux — крайне рекомендую попробовать x2go, его обычно достаточно в электричке с lte для вещей использующих ускорение(например QtCreator, glxgears e.t.c.).
Это часть инициативы HTTPS Everywhere, ребята про безопасность вашего решения заботятся, а вы на них тут кляузы на хабре строчите:)
Во-первых никого не хотел задеть вышеуказанной фразой. И уж тем более не считаю, что разработка небольших и шустрых проектов требует меньше квалификации, чем разработка больших (в случае хромого, я бы даже сказал монструозных) кодовых баз.
Во-вторых — ничто не истина в последней инстанции, более того — органы у всех находятся в разном состоянии, я вот например много играл в очень динамичные игрушки с минимальным пингом 5ms и видимо это заставило меня уметь различать разницу между 5ms и 10ms rtt на глаз при наличии тактильного отклика, я считаю, что это скорее плохо чем хорошо для моего душевного состояния если честно. К примеру — иногда ловлю лаг своей bluetooth клавиатуры, когда она подключенна не по проводу(к слову, в 2.4Ггц решениях такого не замечал, точнее замечал только на мышках и только в играх).
В третьих — vim можно настроить до состояния "лагает", и даже не очень сложно. А можно и не настраивать. Вот с настройкой ide обычно выходит сложнее, есть вещи которые решили за вас и их объективно больше, и это приятно с одной стороны, люблю когда кто-то что-то делает вместо меня. Но при этом — нет свободы отключить или заменить что-то, а коробка может не радовать. Тот же CLion кажется тормозом даже после QtCreator, примерно таким же, как Eclipse на фоне всех их. Я потрудился в 5-7 ide, во многих по несколько лет, поэтому, хочется верить, что мои замечания могут быть хоть от части объективными. К слову — тот же QtCreator единственный не вызывал у меня отторжений по времени отклика, пока я не начал перезжать на удалённый конфиг. Разница в том, что qtc начинает выдавать видимые для меня фризы на пинге 40 до целевого хоста, а vte-based терминал + ssh + vim на 80(а это уже даже для lte много).
Потому, что не изобрели ещё мощных ноутов которые держат батарейку хотя бы 8 часов и весят так, что бы не нужно было бы быть атлетом для их регулярного перемещения и комфортной работы. При этом получаемая производительность на выходе всё равно остаётся намного ниже. Это к вопросу о мобильности, нужна она не всем и не всегда. Но тем не менее, почему-то куча народу таскает с собой эти коробочки с микросхемами.
Второй момент сборный, это шум, пыль, занимаемое свободное место. Если вас шум вентилятора не отвлекает — окей. Я вот когда слышу этот чудный звук — ищу виновника и причиняю ему -9 и прочие радости доставляю. Можно взять рабочую станцию с водянкой например — это вполне себе вариант, но он ощутимо дороже, не мобильный и занимает непозволительно много свободного места, при условии, что этого можно было бы и избежать. Мы же не в 90ых живём в конце концов, я вот планирую в этом году переехать на разработку со своего телефона полностью, ноут большой и тяжёлый же.
Третий момент самый тонкий, спорный и низкоприоритетный — время отклика. Казалось бы сети должны его повысить, но, как показывает практика, многие GUI решения локально оказываются в этом плане тупее, чем терминал по ssh с пингом 60 например до свободного железа. Ноги у этого феномена растут понятно откуда — в условиях вытесняющей многозадачности, на клиентском терминале за ресурсы дерутся куда больше приложений и служб, чем на выделенном удалённом и когда в игру вступает такая сложная система как IDE — мы видим нестыковки в процессах планирования и артефакты борьбы за ресурсы. Когда я вижу фриз в каком нить VisualStudio PRO за многоденег, на свежей рабочей станции от какого нить HP тоже за многоденег, меня это расстраивает. Не сильно, но достаточно, что бы я написал об этом параграф приведённого размера. И достаточно, что бы моё душевное спокойствие вернулось в норму при открытии того же кода в другом решении.
Хм с помощью boost::python например, я делал в обе стороны интеграции (плюсы в python и python в плюсы), не помню, что бы встретил какие-то трудности на этом пути, разницы с lua я практически не увидел, а бустовый сахар сделал процесс даже проще. Но у меня требования об ограничении доступа в стандартную библиотеку не стояли, вполне допускаю что это может быть нетривиально, т.к. обширная стандартная библиотека это один из основных критериев выбора обычно.
Что касается JS — там API чуть сложнее(ну и реализаций минимум 2), но зато стандартной библиотеки — практически просто нет, а потоки хотя бы упоминаются в документации (в том плане что есть re-entrant, что есть thread-safe и какой ценой). По эффективности итогового решения, с включенным jit оно сравнимо или лучше lua (python тут в уверенном хвосте плетётся). Т.е. для конкурентных высоконагруженных приложений я бы несколько раз тщательно взвесил сравнения lua/js и произвёл бы бенчмарки для типовых случаев. Думаю цена интеграции реализаций рассчитанных на встраивание была бы тут ничтожно малой.
Lua — конечно чемпион в плане простоты интеграции и быстрого старта, но это практически единственное его достоинство. Очень узкие комьюнити владеющих этим языком профессионально, поэтому вынести значительную часть бизнесс логики туда — часто выглядит сомнительным решением, даже на фоне чуть более высокой технической сложности для более распостранёныйх технологий. Я не говорю что это совсем не кейс, кейс и ещё какой, т.к. комьюнити имеют место быть, но подумать надо n, а лучше n+1 раз :)
Итого, для себя я сформировал такой чеклист:
Когда я говорю про высоконагруженные решения, я не имею ввиду i/o-bound решения. Там лучше выбирать то, на чём удобней будет писать скрипты конечному пользователю, остальное, в основном, это единоразовые затраты, хотя кейс с запретом импорта стандартной библиотеки таковым не кажется, и может потребовать поддержки.
Могу перефразировать вас немного, тогда поинт выше возможно станет более понятным:
Довольно больно разрабатывать средний или крупный проект без разбиения на подпроекты и тестов интерфейсов этих подпроектов. Так же — в нём сложно искать ошибки реализаций без хорошей подсистемы логгирования и/или трассировки.
Когда требования выше соблюдаются — отладчиком приходится пользоваться крайне редко, и обычно это какой то изощрённый кейс (типа написать скрипт, который проанализирует в какой точке испортили память которая создавалась в другой точке, но ещё не удалялась в третьей, руками такие сессии могут занимать часы и требовать недюжей внимательности), эти варианты обычно либо не доступны через UI IDE, либо сводятся к обращению к командному интерфейсу отладчика, который и в терминале имеется. В основном как ни странно баги находятся даже не в разрабатываемых продуктах зачастую :)
Это основное заблуждение тех кто трогает vim по минимуму :) Там только возможности редактирования представлены на эти 80-90% и то, обычно в лучшем случае. Т.е. ощущение "я это по-любому сделаю/прикручу" — пропадает, а те 10% в которые втыкаешься из нереализованных или плохореализованных фич слегка сбивают.
В vim8 есть из коробки для gdb, разумеется в стилистике редактора.
Но отладчики тоже переоцененны на мой взгляд :) Хотя это наверное тема для отдельной дискуссии. В кратце моя точка зрения тут такая — простые вещи ловятся тестами, в худшем случае логами, при этом отладочная сессия не попадает в /dev/null, а остаётся в виде артефакта в кодовой базе. А для сложных вещей всё равно приходится открывать терминал этого самого отладчика, а то и скрипт писать, так какая разница делать это в IDE, или в другом терминале?
Работа на удалённой машине так же реализуема в некоторых IDE. Польза от работы на удалённой машине в том, что вы можете трудиться с лёгкого и сравнительно дешёвого терминала, утилизируя мощное серверное железо, без шума пыли. Я вот например сильно не уверен, что вы прямо сейчас сходу сможете начать работать с кодовой базой chromium на своём текущем конфиге без его апргрейда по железу :)
Нисколько он никогда не начнёт выигрывать в том смысле который вы(и куча людей включая меня в прошлом) рисуете у себя в голове :) Но сами по себе IDE — переоценены, это просто способ посадить не очень квалифицированные кадры выполнять типовые рутинные задачи максимально быстро(и посадить и выполнять).
Раньше я дивился с того, что очень технически крутые люди польюзуются для разработки каким нить notepad++ или vim без плагинов. Мне казалось, что я умнее и я им говорил что-то в духе — блин, ну тут даже интеграции с отладчиком нет, ты таааак долго делаешь эту хрень, смотри как у меня в <idename> всё круто. Они соглашались — круто, прикольно, так держать :) Но продолжали пилить код в текстовом редакторе, иногда даже без подсветки синтаксиса. И выполняли задачи, особенно сложные, в разы быстрее чем я…
На данный момент — поймал себя на том, что у меня уже пару месяцев как сломалось автодополнение, но меня это чет как то даже и не парит, вот думаю — может пора начать удалять плагины? Когда по большому счёту используешь только редактор, а те миллисекунды которые выскакивает комплит начинают тебя напрягать а и сбивать с мысли, а инфа в этом комплите выглядит как "да ладно, спасибо кэп", это видимо первые звоночки.
Я это к чему? Когда знаешь чего написать и как отладить — ты просто это записываешь и всё, с тем же усилием, как и документацию, просто на другом я зыке. Потом берёшь и отлаживаешь. А свистелки помогают пока не очень точно уверен, как ты собираешься сделать то, что собрался делать.
Чем хорош конкретно vim? Тем что с ним просто работать на удалённой машине, и он позволяет достаточно просто(так что можно хоть под каждый ишью писать скриптец) и вешать их на горячие клавиши или просто держать близко в истории. Ну и руки с хоумроу можно не убирать практически никогда (не для всех это плюс, помахать мышкой — тоже своя развлекуха имеется). Ну, ещё конфиг сравнительно просто утаскивается и размножается.