Комментарии 36
Проблема: программисты не умеют программировать. Решение: они больше не пишут код.
PS
Вы не правильно используете слово "помпезный", подходящим словом будет "желчный", или даже кальный.
Вы неправильно используете слово "неправильно" - это одно слово, пишется слитно.
Возможно, я не смог ясно донести свою мысль, но проблема совсем в другом: львиная доля современных задач либо практически не требует серьёзного программирования (и закрывается условно любым фрилансером), либо требует настолько жёсткого программирования, что отвлекаться на код становится недопустимо. Вот где проходит деление оптимальных методик.
развитие LowCode подходов для более широкого круга проектов позволит значительно оздоровить и перебалансировать рынок SoftWare-разработки
Ничего подобного не случится и не надейтесь.
Сложность предметной области проекта никуда не денется, просто частично перенесется на уровень "заранее заготовленных кусков идеального кода", которые еще кто-то должен спроектировать, предусмотрев все краевые условия, ограничения и возможные сценарии использования (что требует гораздо большей квалификации).
Как вы сами отмечаете, low-code подход давно известен, но не получил широкого распространения, и это как бы намекает...
Это намекает на то, что у всякой задачи свои методы решения.
При написании программ для PLC я быстро пришел к необходимости использовать Sequential Function Chart (он же SFC). Участок программы, который при использовании "чистого" ST быстро превратился в "спагетти-код", был на удивление лаконичен и понятен в терминах SFC.
Это намекает на то, что у всякой задачи свои методы решения.
Так и есть. SFC хороший пример адекватного инструмента для своей предметной области. Для "широкого круга проектов" он не подходит.
А "спагетти" можно и с помощью визуальных языков наворотить. Только вот языки общего назначения обычно дают способы борьбы со спагетти-кодом, а low-code далеко не всегда...
Вот это я понимаю визуальное программирование — "спагетти" выглядит как спагетти )
Что-то мне кажется если весь код какого-нибудь типичного проекта в один файл запихнуть - также будет.
Только вот "типичный проект" на файлы разбивается спокойно, а тут как ни разбивай — будет спагетти.
Посмотрите на левый-верхний угол. Как вообще разбивать это на файлы?
Я никогда не программировал на таком (хотя меня звали такие платформы создавать), но если было бы нужно - я бы левый верхний угол сделал бы несколькими большими квадратами куда входило бы всего пара жгутиков. А вот когда их открываешь, в отдельном окне - внутри уже множество более малых со своими жгутами. Ну и не позволял бы разрастаться схемам, всегда укрупняя их, либо вообще сначала программировал бы крупные узлы, а внутри детализацию. По факту - то же разбиение на файлы.
Именно так. Создание выверенных типовых паттернов всегда требует намного бОльшей квалификации, однако это делается условно один раз.
Думаю, расцвет LowCode настанет лет через 5, когда начнут массово взрослеть дети, родившиеся уже "в интернете" и "в приложениях", а не в командной строке с прописываемыми каждый раз вручную директориями файлов :)
В Low-Code средах программисту отводится самая ответственная роль - грамотно разработать прозрачную программу, используя заранее заготовленные куски идеального кода.
Всё становится печально когда оказывается что для вашего случая нет заранее "заготовленного куска идеального кода".
Как всегда: "компьютер этого не умеет" :-)
Да, соглашусь, это проблема. Более того, мой коллега однажды выловил даже ошибку в одном и заранее заготовленных кусков (справедливости ради, это был тулбокс с каким-то мега-специфическим именным дифуром).
Однако невероятная редкость таких случаев как раз указывает на высокую эффективность и стабильность подхода в целом.
А как отлаживать практически нечитаемый код? Что советуют гуру low code?
Мне кажется: noCoder, lowCoder, coder суть одно и тоже -- издержки индустрии.
Меня всегда учили, что "программиста на языке" не бывает... как и без языка (звучит, с моей точки зрения, как "кузнец, английским типом молотка, весом 530 грамм")
Ну почему же. Есть middle водитель категории B, C, D, есть senior driver со всеми категориями, но это редкость. Кузнец бывает с ручным молотом, с электрическим станком. Из более высококвалифицированного - лётчик, который учится даже не под класс, а под конкретную модель самолёта, а под другие ему нужно переучиваться (хоть и, конечно, не с нуля - теория-то общая). Так и с программистами: общие базовые знания, но практические навыки под каждый рабочий инструмент свои.
Насколько усложнен code review такого low-code, относительно обычного кода?
такой подход полностью избавляет от ошибок на уровне синтаксиса и механической работоспособности кода
Подавляющее большинство ошибок, возникающих в ПО — логические, и обнаруживаются только дотошным тестированием
Совершенно верно! Отчасти поэтому ultra-relieble код почти всегда пишется именно в визуальных средах - чтобы логические ошибки были точно идентифицируемы со всеми взаимосвязями.
Вот я знаю MISRA C, это как раз для ultra-reliable, какие стандарты и практики существуют для не-код решений?
Если человек пишет код и не видит в нем взаимосвязий без "визуализации", возможно ему стоит писать его проще или вообще не писать
Это далеко не так или точнее не везде так. В вашем примере Fadec- блок управления с уровнем гарантии проектирования (DAL) A. Как правило, DAL A блоки имеют очень маленький функционал ( и Фадек не исключение), что вполне позволяет набрать его вручную. Визуальное (модельное) программирование авиационных и автомобильных систем предполагает применение квалифицированных инструментов (уточню: квалифицированных для применения в конкретно этом проекте а не вообще), поэтому отладка сгенерированного кода и тем более его правка в таком процессе в принципе исключена
Не думал что где-то встречу VisSim после универа. Занимался Low-Code до того как это стало мейнстримом: учился на специальности "Управление в технических системах" (ТАУ, САУ, АСУТП и прочие динозавры), в процессе обучения использовали эти две программы (включая SimuLink) для построения матмоделей систем и их исследвания, всякие передаточные функции, П- И- Д- звенья и их комбинации, ЛАЧХ, ЛФЧХ и т.д.
Вопрос не в отображении элементов, а в формализуемости языка. Допустим, Haskell позволяет доказать корректность программы не выполняя саму программу. Есть еще Рефал, и суперкомпиляция, созданные как раз для формальных доказательств корректности. Вообще, для моделирования систем лучше использовать что-то типа Maude System или Coq.
Весь no-code это одна большая подмена понятий.То, что код "пишется" на xml в визуальным инструменте не означает что код куда-то пропал. Просто теперь он непривычный, слабее документированный и без средст работы с кодом наработанными за последние 30 лет. Делает ли это его автоматически лучше? Как по мне ответ не будет однозначным
Вот почему мой канал в Ютубчике называется #кодеротбога )) Сложность технологий нарастает по экспоненте. Применение абстракций - профит, очевидно.
в жизни почти каждого программиста однажды наступает момент когда ему срочно нужно доказать что его область/язык/стэк является круче других. как можно убедительнее и как можно большему количеству людей.
и тогда он начинает писать статьи, спорить про настоящих и ненастоящих программистов, про романтику, сложность работы и необходимость диффуров в повседневной жизни.
и лишь пройдя этот этап до конца, осознав Главную Истину, и успокоившись, мальчик становится мужчиной.
поэтому отвечу на статью кратко и банально: И это пройдет.
Я (автор статьи) программирую с 1997-го года: сначала были Basic и Pascal, потом Delphi, Assembler и C, потом конечно новомодные Python и тд. Победитель различных олимпиад и тд. Как говорится: "уж поверьте, прошёл через многое".
В статье нет ни единого слова про какой-либо язык или стек. Статья - чтобы показать Low-Code под не самым стандартным углом и обьяснить границы оптимальной применимости подходов. Жаль, если не получилось.
под каким углом? визуальное блочное программирование? с какого бока к этому абстракции и "уровни" языков?
даже не так, зачем в статье 50% контента рассуждения про кодирование и программирование? и ещё 30% делят между собой рассуждения об абстракциях, рынке, деньгах и странные выводы?
для кого этот материал? просто подумайте кого вы видите читателем, для кого писали, а потом перечитайте, зачеркните ненужное и посмотрите что осталось. а потом набросайте что нужно. и вот тогда может и получится.
а пока это выглядит как странный выпендреж "мой язык программирования лучше остальных и сейчас я вам расскажу почему, давайте начнем с долгого выяснения что такое программирование а что всего лишь кодирование".
P.S. вы бы хотя бы упомянули а проблемах поддержки, модификации и особенно кастомизации. любой конструктор от блочных языков до CMS удобен ровно до тех пор пока вам не приходится вытачивать новые детальки напильником. впрочем подгонять тем же напильником существующие не лучше. поэтому начинать надо было не с философии а с областей применения. хотя тут даже не понятно что применять. язык? лишь примеры. подход? какой? фреймворк? паттерн? процесс? в стать кучу раз упоминается слово Low code, вот только что оно значит?
Субъективно - никогда не получалось в визуальное программирование. По итогу это превращается в "найди 7 отличий между картинками", то есть между тем что было и тем что сломалось. Если умеешь читать код, то с этим все так проще. Хоть иногда он и сложносочиненный
«Настоящий» Low-Code: деградация программирования, или назад в будущее?