Некоторые производители умеют делать металлизацию на торце. Установить микросхемы с ножками должно быть можно и без этого, если отразить footprint, оставив его на top, либо просто переместив площадки на bot без отражения, и подогнав площадки как можно ближе к дырке (или даже оставив всё как есть, но сделав дырку и очень аккуратно отогнув ножки). А вот для конденсаторов (кроме танталовых, у них контакты отгибаются) и резисторов такой способ не подойдёт, только торцы. Но установить в металлизацию на торцах такую мелочь, скорее всего, будет проблематично (Резонит, к примеру, вроде умеет делать металлизацию на торце платы, но они мне говорили, что у них фреза 3 мм, если я правильно помню), так что их, возможно, придётся заменить на что‐то побольше.
Или, другой вариант, раздвинуть площадки, сделать отверстие для конденсаторов/… без металлизации на торцах и установить их туда на медную фольгу (или на проволочки, но аккуратно вырезанная фольга будет выглядеть лучше).
Если появится действительно существенно лучший разъём, то можно просто взять и поставить второй разъём. Это даже не новая идея — мой старый смартфон на Symbian может заряжаться как от какого‐то нокиевского круглого разъёма, так и от MicroUSB. Будет даже хорошо, если в один разъём можно вставить зарядку, а в другой — наушники, а то разъём 3,5 мм чего‐то куда‐то убирают.
Компоненты SMD удобнее, но прочности разъёмов без чего‐то, запаивающегося в дырку, я не доверяю — отлично знаю, насколько хорошо иногда отлетают площадки. А с прогревом проблем с нормальным паяльником нет, даже если всё совсем плохо, адекватный индукционник нагреет жало с нуля до 300 ℃ за десяток секунд. (С нуля — потому что не хочется перегревать нормальные жала, а массивные ноги спокойно паяются хоть чем.)
Генератор псевдослучайных чисел тут не нужен. Просто если бы разработчики стандарта сказали, что результат сравнения — любое ненулевое число, то разработчики компилятора могли бы начать экономить такты, к примеру, вместо использования единицы копируя указатель на вершину стека — просто потому, что компилятор знает, что здесь он не ноль, а на данной архитектуре копирование указателя на вершину стека быстрее.
Подозреваю, что конфиги zsh и mc тут ни при чём, просто у одного пользователя в passwd оболочка zsh, а у другого — bash. Если это так (т.е. если mc берёт оболочку именно оттуда), то вам нужно использовать chsh. Ещё посмотрите, что находится в $SHELL в обоих случаях.
У меня на работе просто кладут антистатический коврик, а на него фанеру из Резонита — они иногда присылают вместе с платами частично (не насквозь) продырявленные куски фанеры, явно использовавшиеся для того, чтобы просверлить ваши платы, не просверлив стол под ними. Не знаю, что за фанера¹, но и фен (настроен на температуру где‐то до 350 ℃, конечно до фанеры столько не долетит), и плавление олова паяльником (обычно настроен на 260 ℃, но я и на 320 ℃ вроде что‐то на ней плавил) прямо на ней она отлично держит.
¹ Вообще она у них разная — то обычный картонный цвет и одинаковая текстура с двух сторон, то белый более прочный материал с одной стороны, намекающий на что‐то для облицовки.
Микроконтроллеры вроде на Си программируют, а на чем программируют FPGA? К тому же, Си — всего лишь одна из целевых платформ, можно для разных платформ, не совместимых с Си, сделать свои трансляторы.
То, на чём программируют FPGA, коллективно называется HDL (Hardware Description Language). Наиболее известные — VHDL и VeriLog. G компилируется в VHDL (потому что ПЛИС и компиляторы для них делает не National Instruments). Насколько я помню, LabVIEW позволяет вставлять код на VHDL при разработке для FPGA.
Метапрог с открытым кодом, даже начиная с прототипа. Можно добавлять нужные конкретно вам фичи и слать патчи в главный проект. Так, собственно, и работает опенсорс.
Добавить/изменить код, даже без принятия в upstream — гораздо сложнее, чем просто поменять редактор на более соответствующий нуждам. И, как я сказал, графические редакторы сложнее текстовых.
Что добавило необходимость знать C, когда в этих библиотеках обнаружится ошибка. Или когда в метапрог протечёт какая‐та абстракция. Ну и при использовании библиотек на C в более безопасных языках кому‐то придётся писать безопасные binding’и — или программисты будут «радостно» ловить SEGV.
Если вы действительно претендуете на универсальность, то напомню ещё про такие вещи, как Web и FPGA. Со вторым, кстати, LabVIEW, неплохо справляется. Но библиотек на C ни там, ни там, вы не получите (с Web ещё есть шансы из‐за emscripten, с FPGA — никаких).
Иконки рисовать не обязательно, в Лабвью-схемах Метапрога я их почти не рисовал (правда изначально я и не думал открывать код лабвьюшного прототипа).
Тогда у вас меню с кучей похожих иконок. По моему мнению, когда иконки слишком похожи, вытащить VI из окна проекта проще, чем из меню. По крайней мере, там нужно сканировать список только в одном направлении.
Программы на языке G можно редактировать только в LabVIEW, программы на metaprog наверняка можно редактировать только в вашей среде
Метапрог, в отличие от Лабвью, претендует на универсальность. Вам не понадобится учить другие языки, зная Метапрог, когда он обрастет библиотеками на все случаи жизни.
Вы уверены, что ответили на правильный абзац здесь?
В любом случае, у меня там объяснение, что мешает графическим языкам стать популярными. Если вы отвечали на
Кстати, про курицу и яйцо: изучение одного текстового языка делает изучение другого намного легче, особенно если они схожи. Изучение графического языка… Если не считать небольшой пачки DSL вроде графических HDL для FPGA, то там есть LabVIEW, что‐то для обучения и на этом примерно всё. При нужде работу сменить будет сложнее.
, то «универсальность» тут не ответ от слова «совсем». Во‐первых, даже если у вас удастся создать универсальный язык (ни у кого пока не получилось), абзац о том, что многие его не будут выбирать, так как с него сложно уйти. Это не проблема, если есть много компаний с вакансиями на метапрог, но их нет. И эта проблема делает вероятность убеждения кого‐либо ещё ниже.
Во‐вторых, если у меня есть какой‐нибудь Altium и я хочу написать к нему дополнение, то как мне поможет метапрог? Программа закрытая, а дополнения на pascal. Открытые программы также ещё долго не будут добавлять возможность написания дополнений на другом языке, если будут вообще — мало где сейчас есть возможность писать дополнения на нескольких языках.
В Лабвью мне много чего не хватает, поэтому я и задумал Метапрог.
Это не ответ. В вашем редакторе будет то, чего не хватает вам. Но все остальные программисты — не вы. У текстовых языков есть выбор, про графические с альтернативными редакторами я не слышал.
Развитие сдерживают огромная сложность создания чего‐то для редактирования визуальных языков, сопоставимого по удобству хотя бы с *vim, а также отсутствие каких‐либо внятных преимуществ, кроме «некоторым людям читать диаграммы легче». Кривая обучения в качестве преимущества не подойдёт — работа над уменьшением сложности обучения дальше определённого предела полезна, только если вы создаёте язык не для программистов (а LabVIEW, вообще‐то, делается для инженеров), при обучении разработке ПО вы всё равно больше потратите на паттерны проектирования, техники разработки, алгоритмы; а также знакомство со стандартной библиотекой, характерными для конкретного языка шаблонами, чем на собственно синтаксис.
Ни первую, более общую группу, ни вторую, применимую к языку, графическое программирование не удаляет, и вряд ли сокращает что‐либо, кроме знакомства с библиотекой. К тому же, менюшки (сокращающие время на знакомство со стандартной библиотекой), из которых можно вытащить функции, не являются чем‐то таким, что нельзя реализовать для текстового языка. Я вроде это даже видел в какой‐то IDE для VHDL. Просто в том же LabVIEW функций мало, но у них есть иконки (доставать что‐то из меню без иконок будет сложновато) — а в текстовом языке вы, скорее всего, напишете гораздо больше функций — в том числе и из‐за того, что придумать только название функции в любом случае гораздо быстрее, чем и название, и иконку.
И ещё, не забывайте про проблему «курицы и яйца», которая всё усугубляет дальше: к языку должна прилагаться хорошая экосистема, но для её создания и поддержания язык должен быть достаточно популярным, для чего нужна хорошая экосистема. Проблему можно обойти, если у вас есть спонсоры, которые помогут её создать, но их ещё надо как‐то убедить.
Кстати, про курицу и яйцо: изучение одного текстового языка делает изучение другого намного легче, особенно если они схожи. Изучение графического языка… Если не считать небольшой пачки DSL вроде графических HDL для FPGA, то там есть LabVIEW, что‐то для обучения и на этом примерно всё. При нужде работу сменить будет сложнее.
Я тут подумал ещё об одной сложности: я одним освоенным Vim могу редактировать программы на куче разных языков. Кто другой программы на тех же языках может редактировать в Sublime Text. Программы на языке G можно редактировать только в LabVIEW, программы на metaprog наверняка можно редактировать только в вашей среде, у других графических языков тоже у каждого своя единственная среда. Так что если мне что‐то не нравится в редакторе графического языка, то я могу либо молча терпеть, либо попытаться изменить код редактора (что сложнее, чем попытаться перейти на другой, практически невозможно, если язык ещё и проприетарный), либо уйти с языка. И я не могу перейти на другой графический язык, сохранив редактор и связанные с ним привычки.
Тест — это что? Вызвать функцию, подать параметры и сравнить результат с ождаемым? С графическими блоками диаграмма теста будет напоминать испытательный стенд для физических микросхем.
Плохой вид тестов — это минус графических языков, а никак не тестов. Я, правда, ничего такого плохого в тестах данного вида не замечал, за исключением проблем с их рефакторингом.
Метапрог, так же как и Метапрог-проекты и диагарммы, будет мультиязычным. Ведь логика здесь не прописывается (за исключением сишных вставок), а собирается из блоков и тут английский будет использовать необязательно. Но, чтобы англичане понимали, можно делать и английскую локализацию названий.
Английский использовать необязательно для разработциков на метапроге. Разработчику метапрога его использовать обязательно, иначе сам метапрог будут использовать только те, кто говорит на языке автора. А локализация… вам очень нужно делать двойную работу? Особенно если вы будете принимать исправления.
В том, что не прописываешь, а вытягиваешь в виде блока из меню. Ладно, синус прописывать недолго, пропиши-ка, например, bufferevent_read(struct bufferevent bufev, void data, size_t size);, не допустив ни одной ошибки, помня все названия нужных типов, не забыв ни одной запятой и скобки — и это только заголовок!
Для этого есть автодополнение. Подсказывать идентификаторы, которые уже встречались в тексте умеет практически любой редактор, что сложнее блокнота. Куча редакторов ещё и подтянут тип идентификатора и покажут его в подсказке (а для функций тип содержит и возвращаемое значение, и аргументы). Для часто встречающихся конструкций можно создавать snippet’ы — целые блоки кода, вставляющиеся по одной команде (в LabVIEW, кстати, такое тоже можно). Если вы пишете вызов функции, то в хорошее автодополнение вполне себе умеет и показывать название и тип того аргумента, который вы сейчас пишете, и дополнять только совместимые типы. IDE по слухам могут ещё больше, но я предпочитаю использовать *vim.
Кроме того, я замечу, что заголовок нужно написать один раз. Имени функции в автодополнении, конечно, не будет, но типы будут. И имена переменных могут быть тоже, особенно если вы не создаёте функцию, которая имеет дело с совсем новой сущностью.
В Метапроге (даже прототипе) вытащил блок функции — и типы прописывать не надо, какими сложными они б ни были. Вытягиваешь константы, входы или выходы нужного типа по клику на подсказку, соединяешь все проводками. Не нужно задавать и помнить имена локальных переменных, все в проводках.
При вызове функций типы ни в одном современном текстовом языке прописывать в бо́льшинстве случаев не надо. Меньшинство — это когда вывод типов не сработал.
Про имена локальных переменных: если у вас есть хотя бы три провода одного типа, идущих в параллель, то без подписывания, что это такое, понять схему становится намного сложнее. Когда я пишу на LabVIEW, то я всегда держу контекстную помощь включённой, а она показывает вещи вида «это массив array, состоящий из элементов value типа f64». Как не сложно догадаться, если в подсказке идентификаторы будут именно «array» и «value», то толку с неё будет не очень. Поэтому в моём коде вы можете увидеть, к примеру, что есть case structure, в котором в одном случае пришедший по очереди variant превращается в массив булев, и в соседнем случае он делает то же самое. А при наведении курсора на эти массивы вы увидите, что в одном случае это массив «oes» из элементов «oe», а в другом — массив «clk_enables» из «clk_enable» (на диаграмме не видно, поскольку это трата места и всё понятно и так из названия case, если нет — то я включаю отображение метки константы с типом верхнего уровня (т.е. самого массива), но всё ещё скрываю название элемента). И в результате протянутые по циклу провода называются нормально, хотя без контекстной подсказки выполненной работы не видно вообще.
И это весьма раздражает: в текстовом языке мне нужно придумать имя переменной и написать его примерно один раз, если оно большое (потом автодополнение). В LabVIEW мне нужно придумать имя переменной (не только потому что подсказки, но ещё и потому, что терминалы SubVI должны иметь нормальное название) и писать его на порядок чаще — потому что нет автодополнения и потому что в текстовом языке мне не нужно называть элементы массива. Иногда спасает копирование — вставка.
А, и насколько я знаю, обычно в LabVIEW принято не полагаться на подсказку, а подписывать провода с помощью label на диаграмме, если они длинные и/или их много в параллель. Но в этом случае не только опять нет автодополнения, но ещё и вы даже не можете получить название провода автоматически из названия терминала, который является для него источником — одна из причин использовать именно подсказку заключается в том, что если я подпишу все терминалы и все константы, то она будет автоматически показывать что‐то адекватное в бо́льшинстве случаев и мне не нужно будет думать, насколько оправдана трата времени на создание label у провода (и я их всё равно иногда подписываю, просто реже).
В моей практике он не особо усложняется — достаточно отладить один раз и включить встраивание потом. Кроме того, есть два особых случая:
Если цель — FPGA, то встраивается всё и всегда. И в качестве отладки вам доступны только что‐то вроде «отладочного printf» (в гораздо менее удобной форме, чем если бы это действительно был отладочный printf) и попытки понять, что не так, потыкав осциллографом. И ещё тесты на хосте для SubVI, если SubVI не используют чего‐то, специфичного для FPGA. (Ну и метод «пристального взгляда», куда же без него.)
LabVIEW’шный вариант дженериков (они же mallable VI) можно иметь только если эта самая VI настроена на встраивание.
Чего я не могу понять при этом всём встраивании — почему авторы LabVIEW не позволяют настроить два варианта запуска — один используется, когда вы открыли VI и запустили сами, другой — когда VI — это SubVI. Весьма неудобно.
Кстати, насколько я знаю, не выключение отладки всегда создаёт overhead.
Merge так избежать можно — я сам бью VI на довольное мелкие, потому что мне нужно таскать изменения из ветки в ветку (проект разрабатывается так, что у меня есть ветка с «шаблоном» проекта и есть по ветке на каждое конкретное испытываемое изделие). Diff — нет, он для того, чтобы посмотреть, что реально изменилось.
Посмотри на код прототипа Метапрога. Я редко делаю тесты как отдельные сущности, дебажу прямо на диаграммах пробами и брейкпоинтами на проводках.
Тесты — они как бы не для отладки, они для того, чтобы показать наличие ошибок. Откуда вы узнаёте, что надо «дебажить»?
В Лабвью при ошибке жмешь на «разбитую стрелочку» и оно тебе «пальцем тыкает» где что не так.
А в текстовых языках не так? Тот же Rust не только покажет, где ошибка (с точностью до символа), но зачастую ещё и исправление предложит. Но обычно во всех достаточно развитых языках есть указание на символ с ошибкой, а также IDE, которые умеют как минимум туда прыгать (если не вообще показывать ошибки во время набора). А почти во всех текстовых языках есть указание на ошибку с точностью до строки.
В прототипе Метапрога уже реализовано слияние, даже сравнение диаграмм (старой и новой версии). Есть даже репозиторий и система контроля версий (Метапрог онлайн). Есть Лабвью — попробуй потыкать.
Вопрос в первую очередь про понятный diff. Замечу, что diff применяется к проекту, не к одной диаграмме. Это особенно актуально, если вы используете ту же идею «один файл — одна функция».
Со слиянием примерно то же — какое‐то слияние сделать не так уж сложно. А вот чтобы после слияния диаграмма выглядела не сильно хуже, чем до…
Кстати, увидел в аннотации «Открывать и запускать! метапрог.vi и! метапрог онлайн.vi». Напомню, что для получения хоть какой‐то популярности вам придётся использовать английский, и лучше начинать это делать сразу. Ну и при использовании английского нужно использовать исключительно ASCII: LabVIEW даже в 2019 году не умеет в Unicode. Впрочем, судя по требованию «с кириллической локализацией», вы об этом знаете.
По поводу опыта: можете ответить, как часто вам приходилось заниматься рефакторингом кода в текстовых языках и в LabVIEW? У вас есть опыт реализации тестов в текстовых языках и в LabVIEW? А рефакторинга тестов вслед за кодом? Этот «секс с ошибками в синтаксисе» вполне себе оправдан и гораздо лучше того, что вы в LabVIEW можете взять и не указать индекс при получении элемента из массива и LabVIEW это сожрёт, посчитав, что вы решили взять первый элемент (изначально это даже удобно, а вот при рефакторинге куча подобных нюансов заставляет желать бо́льшей строгости).
Мне приходится писать на LabVIEW и приходится заниматься рефакторингом. И процесс рефакторинга в LabVIEW мне совершенно не нравится, даже несмотря на то, что специфика работы предполагает, что я работаю над проектом один. По моему мнению, при разработке ПО вам никак не избежать рефакторинга, а конкретно у LabVIEW с этим всё плохо.
Ещё при разработке больших проектов вам не избежать совместной разработки и тут, по моему мнению, у графических языков (уже не «конкретно у LabVIEW») всё будет ещё хуже: понятный diff сам по себе сделать нелегко, а ещё вам нужно как‐то сделать процедуру слияния, которая не будет ни постоянно превращать код в нечитаемое месиво, ни переставлять абсолютно все элементы схемы при малейших изменениях. Ни то, ни другое, мне не кажется совсем невозможным, но это намного сложнее реализовать для графических языков.
У нас в компании используют гравёр для открытия кристалла — удаляют бо́льшую часть материала (обычно пластик), пока между кристаллом и гравёром не остаётся несколько (десятков) микрометров (которые убирают уже другими методами). Микросхемы, что характерно, не ломаются. Вы же хотите всего лишь сделать надпись, а не удалить почти весь пластик перед кристаллом? Можете смело этим заниматься.
Могу, правда, отметить, что я слышал, что некоторые микросхемы‐таки ломаются при использовании лазера — то ли пластик такой, что гравёр прошивает его до кристалла, то ли ещё чего. Но это редкость.
И? Проверку синтаксиса ваш пример вполне переживает, код с синтаксическими ошибками просто не запустится. В вашем примере Python выдаёт ошибку даже не на отсутствующей стадии проверки типов, ошибка появляется, когда код уже скомпилирован и запущен, но реализация операции индексирования обнаруживает, что данная операция не реализована для типа int.
Вообще‐то синтаксисindexvar[arrayvar] корректен в любых языках, где корректен синтаксис arrayvar[indexvar]. Если ошибка будет, то она будет на этапе проверки типов, а не на этапе синтаксического анализа. А такие нюансы имеет смысл спрашивать либо потому что от этого что‐то действительно зависит, либо потому что они разжёваны в половине учебников, статей о том, как пройти интервью/… и на них просто нельзя не натолкнуться… если, конечно, вы читаете статьи по своей специальности. Код как в вашем примере, конечно, вряд ли кто пишет. Но вот знать это нужно, потому что в коде на C я не раз видел как конструкции вида func(&arr[n]), так и конструкции вида func(arr + n). Если вы не знаете про то, что &arr[n] — это &(*(arr + n)), то вы не сможете понять, почему приведённые мною вызовы эквивалентны и, возможно, некорректно прочитаете код.
Интересно, а в OctoLingua можно добавить LabVIEW? Всё‐таки у языка G сжатые бинарные файлы. И что‐то мне подсказывает, не только у него — G не единственный графический язык программирования и вряд ли единственный, чьи разработчики выбрали сериализацию в свой формат, а не какой‐нибудь XML (что тоже оставляет вопросы: если что‐то является отдельным ЯП, но сериализуется в XML, OctoLingua можно научить такую ситуацию обрабатывать?).
Мне почему‐то кажется, что если задачу определения файлов на языке G поставят, к OctoLingua сбоку приляпают что‐то вроде file.
От нас Резонит, кстати, спокойно переваривает срочные и сверхсрочные заказы на небольшое (<100, обычно даже <10) количество плат и также делает их оперативно. И запускают их в производство до оплаты (есть такая опция для доверенных партнёров). Нам даже как‐то поправили КЗ в плате (оказывается, DRC в Altium не так уж и хорош, возможно, из‐за того, что я все углы в той плате разводил дугами). При этом, насколько мне известно, мы никогда не заказываем большое количество плат в партии, хотя и генерируем довольно много заказов на небольшое.
Некоторые производители умеют делать металлизацию на торце. Установить микросхемы с ножками должно быть можно и без этого, если отразить footprint, оставив его на top, либо просто переместив площадки на bot без отражения, и подогнав площадки как можно ближе к дырке (или даже оставив всё как есть, но сделав дырку и очень аккуратно отогнув ножки). А вот для конденсаторов (кроме танталовых, у них контакты отгибаются) и резисторов такой способ не подойдёт, только торцы. Но установить в металлизацию на торцах такую мелочь, скорее всего, будет проблематично (Резонит, к примеру, вроде умеет делать металлизацию на торце платы, но они мне говорили, что у них фреза 3 мм, если я правильно помню), так что их, возможно, придётся заменить на что‐то побольше.
Или, другой вариант, раздвинуть площадки, сделать отверстие для конденсаторов/… без металлизации на торцах и установить их туда на медную фольгу (или на проволочки, но аккуратно вырезанная фольга будет выглядеть лучше).
Если появится действительно существенно лучший разъём, то можно просто взять и поставить второй разъём. Это даже не новая идея — мой старый смартфон на Symbian может заряжаться как от какого‐то нокиевского круглого разъёма, так и от MicroUSB. Будет даже хорошо, если в один разъём можно вставить зарядку, а в другой — наушники, а то разъём 3,5 мм чего‐то куда‐то убирают.
Компоненты SMD удобнее, но прочности разъёмов без чего‐то, запаивающегося в дырку, я не доверяю — отлично знаю, насколько хорошо иногда отлетают площадки. А с прогревом проблем с нормальным паяльником нет, даже если всё совсем плохо, адекватный индукционник нагреет жало с нуля до 300 ℃ за десяток секунд. (С нуля — потому что не хочется перегревать нормальные жала, а массивные ноги спокойно паяются хоть чем.)
Генератор псевдослучайных чисел тут не нужен. Просто если бы разработчики стандарта сказали, что результат сравнения — любое ненулевое число, то разработчики компилятора могли бы начать экономить такты, к примеру, вместо использования единицы копируя указатель на вершину стека — просто потому, что компилятор знает, что здесь он не ноль, а на данной архитектуре копирование указателя на вершину стека быстрее.
Подозреваю, что конфиги zsh и mc тут ни при чём, просто у одного пользователя в passwd оболочка zsh, а у другого — bash. Если это так (т.е. если mc берёт оболочку именно оттуда), то вам нужно использовать
chsh. Ещё посмотрите, что находится в$SHELLв обоих случаях.У меня на работе просто кладут антистатический коврик, а на него фанеру из Резонита — они иногда присылают вместе с платами частично (не насквозь) продырявленные куски фанеры, явно использовавшиеся для того, чтобы просверлить ваши платы, не просверлив стол под ними. Не знаю, что за фанера¹, но и фен (настроен на температуру где‐то до 350 ℃, конечно до фанеры столько не долетит), и плавление олова паяльником (обычно настроен на 260 ℃, но я и на 320 ℃ вроде что‐то на ней плавил) прямо на ней она отлично держит.
¹ Вообще она у них разная — то обычный картонный цвет и одинаковая текстура с двух сторон, то белый более прочный материал с одной стороны, намекающий на что‐то для облицовки.
То, на чём программируют FPGA, коллективно называется HDL (Hardware Description Language). Наиболее известные — VHDL и VeriLog. G компилируется в VHDL (потому что ПЛИС и компиляторы для них делает не National Instruments). Насколько я помню, LabVIEW позволяет вставлять код на VHDL при разработке для FPGA.
Добавить/изменить код, даже без принятия в upstream — гораздо сложнее, чем просто поменять редактор на более соответствующий нуждам. И, как я сказал, графические редакторы сложнее текстовых.
Что добавило необходимость знать C, когда в этих библиотеках обнаружится ошибка. Или когда в метапрог протечёт какая‐та абстракция. Ну и при использовании библиотек на C в более безопасных языках кому‐то придётся писать безопасные binding’и — или программисты будут «радостно» ловить SEGV.
Если вы действительно претендуете на универсальность, то напомню ещё про такие вещи, как Web и FPGA. Со вторым, кстати, LabVIEW, неплохо справляется. Но библиотек на C ни там, ни там, вы не получите (с Web ещё есть шансы из‐за emscripten, с FPGA — никаких).
Тогда у вас меню с кучей похожих иконок. По моему мнению, когда иконки слишком похожи, вытащить VI из окна проекта проще, чем из меню. По крайней мере, там нужно сканировать список только в одном направлении.
Вы уверены, что ответили на правильный абзац здесь?
В любом случае, у меня там объяснение, что мешает графическим языкам стать популярными. Если вы отвечали на
, то «универсальность» тут не ответ от слова «совсем». Во‐первых, даже если у вас удастся создать универсальный язык (ни у кого пока не получилось), абзац о том, что многие его не будут выбирать, так как с него сложно уйти. Это не проблема, если есть много компаний с вакансиями на метапрог, но их нет. И эта проблема делает вероятность убеждения кого‐либо ещё ниже.
Во‐вторых, если у меня есть какой‐нибудь Altium и я хочу написать к нему дополнение, то как мне поможет метапрог? Программа закрытая, а дополнения на pascal. Открытые программы также ещё долго не будут добавлять возможность написания дополнений на другом языке, если будут вообще — мало где сейчас есть возможность писать дополнения на нескольких языках.
Это не ответ. В вашем редакторе будет то, чего не хватает вам. Но все остальные программисты — не вы. У текстовых языков есть выбор, про графические с альтернативными редакторами я не слышал.
Развитие сдерживают огромная сложность создания чего‐то для редактирования визуальных языков, сопоставимого по удобству хотя бы с *vim, а также отсутствие каких‐либо внятных преимуществ, кроме «некоторым людям читать диаграммы легче». Кривая обучения в качестве преимущества не подойдёт — работа над уменьшением сложности обучения дальше определённого предела полезна, только если вы создаёте язык не для программистов (а LabVIEW, вообще‐то, делается для инженеров), при обучении разработке ПО вы всё равно больше потратите на паттерны проектирования, техники разработки, алгоритмы; а также знакомство со стандартной библиотекой, характерными для конкретного языка шаблонами, чем на собственно синтаксис.
Ни первую, более общую группу, ни вторую, применимую к языку, графическое программирование не удаляет, и вряд ли сокращает что‐либо, кроме знакомства с библиотекой. К тому же, менюшки (сокращающие время на знакомство со стандартной библиотекой), из которых можно вытащить функции, не являются чем‐то таким, что нельзя реализовать для текстового языка. Я вроде это даже видел в какой‐то IDE для VHDL. Просто в том же LabVIEW функций мало, но у них есть иконки (доставать что‐то из меню без иконок будет сложновато) — а в текстовом языке вы, скорее всего, напишете гораздо больше функций — в том числе и из‐за того, что придумать только название функции в любом случае гораздо быстрее, чем и название, и иконку.
И ещё, не забывайте про проблему «курицы и яйца», которая всё усугубляет дальше: к языку должна прилагаться хорошая экосистема, но для её создания и поддержания язык должен быть достаточно популярным, для чего нужна хорошая экосистема. Проблему можно обойти, если у вас есть спонсоры, которые помогут её создать, но их ещё надо как‐то убедить.
Кстати, про курицу и яйцо: изучение одного текстового языка делает изучение другого намного легче, особенно если они схожи. Изучение графического языка… Если не считать небольшой пачки DSL вроде графических HDL для FPGA, то там есть LabVIEW, что‐то для обучения и на этом примерно всё. При нужде работу сменить будет сложнее.
Я тут подумал ещё об одной сложности: я одним освоенным Vim могу редактировать программы на куче разных языков. Кто другой программы на тех же языках может редактировать в Sublime Text. Программы на языке G можно редактировать только в LabVIEW, программы на metaprog наверняка можно редактировать только в вашей среде, у других графических языков тоже у каждого своя единственная среда. Так что если мне что‐то не нравится в редакторе графического языка, то я могу либо молча терпеть, либо попытаться изменить код редактора (что сложнее, чем попытаться перейти на другой, практически невозможно, если язык ещё и проприетарный), либо уйти с языка. И я не могу перейти на другой графический язык, сохранив редактор и связанные с ним привычки.
Плохой вид тестов — это минус графических языков, а никак не тестов. Я, правда, ничего такого плохого в тестах данного вида не замечал, за исключением проблем с их рефакторингом.
Английский использовать необязательно для разработциков на метапроге. Разработчику метапрога его использовать обязательно, иначе сам метапрог будут использовать только те, кто говорит на языке автора. А локализация… вам очень нужно делать двойную работу? Особенно если вы будете принимать исправления.
Для этого есть автодополнение. Подсказывать идентификаторы, которые уже встречались в тексте умеет практически любой редактор, что сложнее блокнота. Куча редакторов ещё и подтянут тип идентификатора и покажут его в подсказке (а для функций тип содержит и возвращаемое значение, и аргументы). Для часто встречающихся конструкций можно создавать snippet’ы — целые блоки кода, вставляющиеся по одной команде (в LabVIEW, кстати, такое тоже можно). Если вы пишете вызов функции, то в хорошее автодополнение вполне себе умеет и показывать название и тип того аргумента, который вы сейчас пишете, и дополнять только совместимые типы. IDE по слухам могут ещё больше, но я предпочитаю использовать *vim.
Кроме того, я замечу, что заголовок нужно написать один раз. Имени функции в автодополнении, конечно, не будет, но типы будут. И имена переменных могут быть тоже, особенно если вы не создаёте функцию, которая имеет дело с совсем новой сущностью.
При вызове функций типы ни в одном современном текстовом языке прописывать в бо́льшинстве случаев не надо. Меньшинство — это когда вывод типов не сработал.
Про имена локальных переменных: если у вас есть хотя бы три провода одного типа, идущих в параллель, то без подписывания, что это такое, понять схему становится намного сложнее. Когда я пишу на LabVIEW, то я всегда держу контекстную помощь включённой, а она показывает вещи вида «это массив array, состоящий из элементов value типа f64». Как не сложно догадаться, если в подсказке идентификаторы будут именно «array» и «value», то толку с неё будет не очень. Поэтому в моём коде вы можете увидеть, к примеру, что есть case structure, в котором в одном случае пришедший по очереди variant превращается в массив булев, и в соседнем случае он делает то же самое. А при наведении курсора на эти массивы вы увидите, что в одном случае это массив «oes» из элементов «oe», а в другом — массив «clk_enables» из «clk_enable» (на диаграмме не видно, поскольку это трата места и всё понятно и так из названия case, если нет — то я включаю отображение метки константы с типом верхнего уровня (т.е. самого массива), но всё ещё скрываю название элемента). И в результате протянутые по циклу провода называются нормально, хотя без контекстной подсказки выполненной работы не видно вообще.
И это весьма раздражает: в текстовом языке мне нужно придумать имя переменной и написать его примерно один раз, если оно большое (потом автодополнение). В LabVIEW мне нужно придумать имя переменной (не только потому что подсказки, но ещё и потому, что терминалы SubVI должны иметь нормальное название) и писать его на порядок чаще — потому что нет автодополнения и потому что в текстовом языке мне не нужно называть элементы массива. Иногда спасает копирование — вставка.
А, и насколько я знаю, обычно в LabVIEW принято не полагаться на подсказку, а подписывать провода с помощью label на диаграмме, если они длинные и/или их много в параллель. Но в этом случае не только опять нет автодополнения, но ещё и вы даже не можете получить название провода автоматически из названия терминала, который является для него источником — одна из причин использовать именно подсказку заключается в том, что если я подпишу все терминалы и все константы, то она будет автоматически показывать что‐то адекватное в бо́льшинстве случаев и мне не нужно будет думать, насколько оправдана трата времени на создание label у провода (и я их всё равно иногда подписываю, просто реже).
В моей практике он не особо усложняется — достаточно отладить один раз и включить встраивание потом. Кроме того, есть два особых случая:
Чего я не могу понять при этом всём встраивании — почему авторы LabVIEW не позволяют настроить два варианта запуска — один используется, когда вы открыли VI и запустили сами, другой — когда VI — это SubVI. Весьма неудобно.
Кстати, насколько я знаю, не выключение отладки всегда создаёт overhead.
Merge так избежать можно — я сам бью VI на довольное мелкие, потому что мне нужно таскать изменения из ветки в ветку (проект разрабатывается так, что у меня есть ветка с «шаблоном» проекта и есть по ветке на каждое конкретное испытываемое изделие). Diff — нет, он для того, чтобы посмотреть, что реально изменилось.
Тесты — они как бы не для отладки, они для того, чтобы показать наличие ошибок. Откуда вы узнаёте, что надо «дебажить»?
А в текстовых языках не так? Тот же Rust не только покажет, где ошибка (с точностью до символа), но зачастую ещё и исправление предложит. Но обычно во всех достаточно развитых языках есть указание на символ с ошибкой, а также IDE, которые умеют как минимум туда прыгать (если не вообще показывать ошибки во время набора). А почти во всех текстовых языках есть указание на ошибку с точностью до строки.
Вопрос в первую очередь про понятный diff. Замечу, что
diffприменяется к проекту, не к одной диаграмме. Это особенно актуально, если вы используете ту же идею «один файл — одна функция».Со слиянием примерно то же — какое‐то слияние сделать не так уж сложно. А вот чтобы после слияния диаграмма выглядела не сильно хуже, чем до…
Кстати, увидел в аннотации «Открывать и запускать! метапрог.vi и! метапрог онлайн.vi». Напомню, что для получения хоть какой‐то популярности вам придётся использовать английский, и лучше начинать это делать сразу. Ну и при использовании английского нужно использовать исключительно ASCII: LabVIEW даже в 2019 году не умеет в Unicode. Впрочем, судя по требованию «с кириллической локализацией», вы об этом знаете.
По поводу опыта: можете ответить, как часто вам приходилось заниматься рефакторингом кода в текстовых языках и в LabVIEW? У вас есть опыт реализации тестов в текстовых языках и в LabVIEW? А рефакторинга тестов вслед за кодом? Этот «секс с ошибками в синтаксисе» вполне себе оправдан и гораздо лучше того, что вы в LabVIEW можете взять и не указать индекс при получении элемента из массива и LabVIEW это сожрёт, посчитав, что вы решили взять первый элемент (изначально это даже удобно, а вот при рефакторинге куча подобных нюансов заставляет желать бо́льшей строгости).
Мне приходится писать на LabVIEW и приходится заниматься рефакторингом. И процесс рефакторинга в LabVIEW мне совершенно не нравится, даже несмотря на то, что специфика работы предполагает, что я работаю над проектом один. По моему мнению, при разработке ПО вам никак не избежать рефакторинга, а конкретно у LabVIEW с этим всё плохо.
Ещё при разработке больших проектов вам не избежать совместной разработки и тут, по моему мнению, у графических языков (уже не «конкретно у LabVIEW») всё будет ещё хуже: понятный diff сам по себе сделать нелегко, а ещё вам нужно как‐то сделать процедуру слияния, которая не будет ни постоянно превращать код в нечитаемое месиво, ни переставлять абсолютно все элементы схемы при малейших изменениях. Ни то, ни другое, мне не кажется совсем невозможным, но это намного сложнее реализовать для графических языков.
У нас в компании используют гравёр для открытия кристалла — удаляют бо́льшую часть материала (обычно пластик), пока между кристаллом и гравёром не остаётся несколько (десятков) микрометров (которые убирают уже другими методами). Микросхемы, что характерно, не ломаются. Вы же хотите всего лишь сделать надпись, а не удалить почти весь пластик перед кристаллом? Можете смело этим заниматься.
Могу, правда, отметить, что я слышал, что некоторые микросхемы‐таки ломаются при использовании лазера — то ли пластик такой, что гравёр прошивает его до кристалла, то ли ещё чего. Но это редкость.
И? Проверку синтаксиса ваш пример вполне переживает, код с синтаксическими ошибками просто не запустится. В вашем примере Python выдаёт ошибку даже не на отсутствующей стадии проверки типов, ошибка появляется, когда код уже скомпилирован и запущен, но реализация операции индексирования обнаруживает, что данная операция не реализована для типа
int.Вообще‐то синтаксис
indexvar[arrayvar]корректен в любых языках, где корректен синтаксисarrayvar[indexvar]. Если ошибка будет, то она будет на этапе проверки типов, а не на этапе синтаксического анализа. А такие нюансы имеет смысл спрашивать либо потому что от этого что‐то действительно зависит, либо потому что они разжёваны в половине учебников, статей о том, как пройти интервью/… и на них просто нельзя не натолкнуться… если, конечно, вы читаете статьи по своей специальности. Код как в вашем примере, конечно, вряд ли кто пишет. Но вот знать это нужно, потому что в коде на C я не раз видел как конструкции видаfunc(&arr[n]), так и конструкции видаfunc(arr + n). Если вы не знаете про то, что&arr[n]— это&(*(arr + n)), то вы не сможете понять, почему приведённые мною вызовы эквивалентны и, возможно, некорректно прочитаете код.Интересно, а в OctoLingua можно добавить LabVIEW? Всё‐таки у языка G сжатые бинарные файлы. И что‐то мне подсказывает, не только у него — G не единственный графический язык программирования и вряд ли единственный, чьи разработчики выбрали сериализацию в свой формат, а не какой‐нибудь XML (что тоже оставляет вопросы: если что‐то является отдельным ЯП, но сериализуется в XML, OctoLingua можно научить такую ситуацию обрабатывать?).
Мне почему‐то кажется, что если задачу определения файлов на языке G поставят, к OctoLingua сбоку приляпают что‐то вроде
file.От нас Резонит, кстати, спокойно переваривает срочные и сверхсрочные заказы на небольшое (<100, обычно даже <10) количество плат и также делает их оперативно. И запускают их в производство до оплаты (есть такая опция для доверенных партнёров). Нам даже как‐то поправили КЗ в плате (оказывается, DRC в Altium не так уж и хорош, возможно, из‐за того, что я все углы в той плате разводил дугами). При этом, насколько мне известно, мы никогда не заказываем большое количество плат в партии, хотя и генерируем довольно много заказов на небольшое.