Мир фрагментируется. Специализированные языки для своих ниш будут на порядок лучше решать задачи, чем универсальный язык. Они будут его оттуда вытеснять. Сферы применения специализированных языков будет все меньше и меньше, но конечно же останутся.
Беря ваш форум таксистов: на заре автомобилестроения были только легковые, грузовые и трактора. Сейчас легковые делятся на классы А, B, C и т.д. Грузоые по грузоподьемности и конструкции. А спецтехники вообще море необъятное. И никакие универсальные вещи их оттуда не вытеснят, потому что специализированная техника умеет лучше решать поставленные для ее ниши задачи.
Летняя и зимняя резины решают поставленные им задачи гораздо лучше чем демисезонная. Демисезонную покупает сейчас только ленивый.
Со временем универсальные языки будут находить все меньшее применение. Это мое мнение.
Но не об этом была речь. Дискуссию то вы развели. Я просто искренне поблагодарил автора за интересную статью, и указал ему что в нише где он находится, еще поле особо не копанное. Да и в целом о том что в статье не указан целый класс языков (можно это рассматривать как класс) которые будут постоянно появляться и теснить основные. Эволюцонно думаю останутся только программы поддерживающие систему локализации, они просто вытеснят конкурентов. Все более-менее крупные компании работающие в гибких бизнес нишах обзаведутся специализированными средствами локализации для своих программ.
Меня же вы пытаетесь убедить что все это ерунда и надо встараивать везде стандартный язык и это круче нет. Нет, это не круче, и это не будет работать. Почему я уже много раз описал.
Если говорить эволюционно, то попрут во всех нишах стандартные языки рано или поздно, они со специализированными не будут выдерживать конкуренции.
можете покапаться тут по разделам (ссылка), тут сотни проектов, и это только в России и только о том что написали.
А вообще можете просто погуглить.
В чем я участвовал уж извиняйте, не буду описывать. Повторюсь только что можно писать программы любой сложности и у меня никаких проблем никогда не возникало. Если что-то понадобилось, то просто берешь и делаешь.
Для универстетов National Instruments свое ПО кстати бесплатно предоставляет насколько я знаю (хотя может что уже и изменилось). Решили что пусть студенты учатся. Так что уже выросло и еще вырастет поколение которое знает что такое LabView.
Хех. Для «секретарши» — «НИАСИЛИЛ», не для «секретарши» — «НИАСИЛИЛ». Вы определитесь что ли.
Не, вполне возможно что и «НИАСИЛИЛ» пользуясь вашей терминологией, но понимаете, нет цели «АСИЛИЛ». Такие языки создаются для определенных вещей и никто не планирует на них захватывать и заставлять работать весь мир. Они сделаны для своих ниш, как и ваши «шаровые шарниры», которые сделаны для автомобилей, а не самолетов. Но в своих нишах они «короли» и универсальные языки там явно проигрывают.
PS: кстати, например трактор «Кировец» может поворачивать без использования ваших шаровых шарниров. Они ему просто не нужны. И это гораздо проще и надежнее.
О чем вы вообще? На LabView реализуются крупнейшие проекты. Создаются программы любой сложности. А National Instruments, создатель языка G, одна их крупнейших международных корпораций с многомиллиардными активами и имеющая представительства в большинстве стран мира.
Когда у вас разных видов обьектов в программе — десятки, если не сотни, тысяч? Причём большая часть — это всевозможные контейнеры? Хотел бы я на это посмотреть.
Да хоть миллионы, это будет в 100 раз удобнее чем в тексте. Там все продумано, вы можете убирать код в блоки (можно обозвать их процедурами) и направлять и выводить из них потоки данных, вы можете группировать различные потоки данных в кластеры, причем даже подписывать каждый поток, вы можете делать «Stacked Sequence Structure» и писать поддиаграмы в последовательных закладках. Просто вы об этих вещах не знаете, ибо такого в «текстовых» языках просто нет.
Вещи, которые в каком-нибудь Android'е — этот малозаметная деталька реализации — тут вынесены в качестве отдельного, чуть ли не центрального, элемента языка.
Об этом, мы, кстати, спорили и раньше (правда с другим автором),.
Ну это что-то прояснило ) Зачем вы на OPCSenator так наехали то? Он кстати хорошую статью написал. Я до вашей ссылки и не знал что некто FBD есть. Кстати он LabView мне напомнил, правда он намного примитивней LabView конечно.
Вы просто совсем не понимаете визуального программирования. Для вас это «безумные схемы». Я кстати вас могу понять. В далеком 2005 году, когда я заканчивал МАИ, я устроился работать на нашу кафедру. Попал в команду которая занималась разработкой программы вибрационной диагностики воздушно-реактивного двигателя в полете. Можно было по анализу сигнатур вибраций определить в каком элементе двигателя поломка (или скоро будет поломка) и что произошло (скоро произойдет). Все это естесвенно делалось на LabView. До этого я все делал в основном на Delphi и честно скажу, первые дня 3 я от LabView плевался, но когда на меня снизошло озарение и я понял как это работает, я забыл Delphi как страшный сон, и кстати по сей день к нему не возвращался ни разу. Именно поэтому могу вас понять, вспомнив те первые ощущения.
Визуальное программирование, это просто офигенская вещь, там все наглядно, там потрясающие системы отладки кода, вы просто визуально можете посмотреть куда какие данные перемещаются и как преобразуются. Вы просто этого не поймете пока вас жизнь не заставит реально на этом поработать. Я до сих пор многие вещи на LabView делаю, это очень удобно.
А FBD я думаю для техников офигенская вещь, и она реально будет популярна в своей нише.
То есть ваш язык — настолько прост, что ему «можно обучить секретаршу»?
Тут вы сразили просто наповал! Я просто даже не думал что нужны какие-то подробности. Главное требование, хорошее знание процедурного SQL, если человек это знает, ему не составит труда освоить язык программирования в ERP-Плтаформе. Причем даже все равно с какими базами человек работал, SQL он везде SQL. Отличия минимальные. Все остальное мимо. Ну желательно конечно чтобы на html и php не смотрел человек как баран на новые ворота, но это не столь критично.
Как вы думаете, много в мире людей работающих с процедурным SQL? Море.
А «секретарша» знаете, у нее задача владеть языком без приставки «программироания» ;)
Именно компилятор. Вернее даже немного сложнее: интерпретаторо-компилятор. Сначала конфигурация интерпретатором переводится в понятный формат для компилятора, потом уже компилируется. Иначе вы не получите приемлемую скорость работы, если на ходу будите все составлять из конфигурации. Это касается логики работы.
Еще есть внешний интерпретатор, который располагает элементы в окне и дергает именно нужные в текущий момент для работы процедуры (тоже экономя ресурсы), процедуры для скрытых закладок он будет опускать.
Я написал что есть ниша для языков необжитая. Она будет в будущем перспективно развиваться.
Дискуссия развилась потому что люди не понимаю до конца этой темы и считают что можно обойтись стандартными вещами. Я попытался это все это аргументировано развеять, ибо проходил уже через все это и участвую в разработках ERP систем уже около 10 лет и знаю о чем говорю. Я видел разные способы и просто уже знаю как надо делать оптимально и почему. Но люди разные, кто-то понимает, кто-то нет, кто-то думает и пишет какие-то аргументы, у кого-то аргументов нет и просто минусует. Кто понял — я рад, кто нет — ну нет так нет.
Для вас напишу еще раз преимущества:
а) Скорость разработки системы на своей платформе. Вы можете сделать удобный редактор и типовые блоки для типовых и частых действий.
б) Безопасность системы. Давая стандартные языки, затруднительно обеспечить безопасность и защиту кода, при этом давая доступ к любому элементу.
с) Дать свободное редактирование любого существующего элемента (а не только новое) в рамках аккаунта
г) Деление системы на элементарные блоки дает большие преимущества. Можно сделать ту же систему назначения прав, можно делать типовые блоки упрощая разработку, можно вводить всякие интересные свойства элементов.
И т.д. нюансов миллионы. Все не описать.
Минусы:
а) Сложность разработки движка
б) Стоимость тестирования безопасности
Обучение новых сотрудников сюда не ставлю, ибо это не так сложно на самом деле и разово. А клиентов никто не заставляет учить, разве что сами не захотят. Они пользуются в первую очередь самим продуктом, а не средствами его разработки. Для них это просто бонус и гарантия что это не черный ящик.
Но если компания хочет развиваться в будущем, она должна будет это сделать, ибо ее в перспективе вытеснят те кто это сделал (ИХМО)
Интересный разговор получается. Постараюсь все таки отстоять свое мнение :)
Во-первых, SAP система существует только одна
Это всем понятно, я просто воспользовался вашей терминологией.
Элементарно как делают всякие SAP'ы пользовательский код имеет доступ только к API
Это не вариант. Вернее очень плохой вариант. Вы опять же ограничиваете пользователей рамками ваших API. Если брать опять же пример ERP-Платформы — там пользователь может создавать свой API, т.е. он может делать прямо в триггерах специальные элементы (называются позиции API) на любые таблицы, которые по любому выбранному событию по вашим правилам, передадут указанные вами данные на указанный вами внешний сервер. А на прием данных вы можете придумать свой формат и создать свою процедуру приема информации. Вы не ограничены придуманными кем-то API…
пользователь может использовать функцию чтения из файла и записи в лог файл в ВАШЕМ СОБСТВЕННОМ ЯЗЫКЕ, чтобы прочитать все php файлы и скопировать их содержимое?
Такие вещи должны решаться на уровне архитектуры языка. И кстати на стандартном языке их решить будет затруднительно. Извиняюсь, опять же приведу пример ERP-Платформы: там есть внешний (логический) и внутренний (физический) уровни, пользователь делает изменения только на внешнем (составляет конфигурацию), а на внутренний они попадают через компилятор. На физическом уровне он в принципе не сможет ничего сделать, а компилятор не даст сделать того что не разрешено, там жесткие уровни проверки корректности. Плюс логика делается не в вебе, а в базе данных. Базы данных естественно не на веб сервере, а в распределенной сети. Файлы естественно тоже никто на веб серверах не хранит…
Я конечно не утверждаю что возможна идеальная безопасность, наверное такого не бывает. Но ее можно приблизить к этому архитектурно.
Там кстати это уже 3-я версия языка, 2 предыдущих были забракованы и с высоты их опыта уже появилась третья с правильным архитектурным решением, которая выстрелила.
То же SAP (огромная часть рынка) позволяет писать код на Java и до сих пор не разорился
Он позволяет писать свой код? Или переписывать их в рамках вашего аккаунта? Это принципиально разные вещи.
По 1С-никам. Я имел дело с некоторыми, и такого насмотрелся, что если честно не очень их уважаю и сам принципиально в 1С лезть не хочу. А конторы реально только и мечтают избавиться бы от 1С, но особо нет альтернатив. И да, за рубежом они не продадут свой опыт. И вы правы что по сути они волею случая стали монополистами (а может что и стоит за этой волей случая...)
На самом деле свой язык нужен тем разрабатывает ERP системы только затем чтобы подсадить клиентов на свой продукт, как делает 1С
Вы тут не правы (хотя с 1С правы). Вам не надо всем навязывать и толкать SaaS язык. Глупо всех заставлять его учить и толкать в массы. Сам по себе он применим только в вашей платформе. Суть его создания:
1) Упростить своей компании дальнейшую разработку, разрабатывать в 3-5 раз быстрее конкурентов пользуясь своими средствами автоматизации и блочной архитектурой. Сложность его создания достаточно быстро окупается. Я тут знаю о чем говорю.
2) Дать клиентам ВОЗМОЖНОСТЬ доработки под их ниши. Это не значит заставить клиента, он берет продукт какой есть, но если ВДРУГ ему понадобиться доработать, он имеет ВОЗМОЖНОСТЬ это сделать. А это далеко не везде так.
Вам не надо учить всех людей вашему языку. Клиент должен в первую очередь пользоваться вашим продуктом, а язык это можно назвать бонусом.
Вам тут надо:
1) написать хороший мануал, на случай если кто-то захочет его заюзать
2) обучать своих сотрудников, благо это не сложно если человек знает что такое PLSQL. Вам там даже php то не нужен, конфигурация окон составляется мышкой…
или рассматривают систему как черный ящик
Черный ящик это как раз таки системы без встроенного языка, а тут вы как раз знаете, что даже в самом плохом случае, вы прочтете мануал и сможете сделать необходимые вам изменения.
Почитал про Spring Security. Оно предназначено для аутентификации (я не прав?). Система разграничения доступа должна быть намного сложнее, с детализацией вплоть до каждого отдельного элемента страницы. Например одной роли надо дать доступ к кнопке на веб странице на изменение, другой на удаление, т.е. в зависимости от того что делает кнопка он должна или быть активна, или деактивироваться у того или иного пользователя. Кому то надо отображать информацию, а кому то пустой элемент. Права должны наследоваться, т.е. права областей старницы должны наследовать права роли на страницу если не задано иное, права элементов областей должны наследвать права области (если иное не задано). Должны задаваться прав по умолчанию, перекрывающиеся если иное принудительно указано в роли пользователя. Все намного сложнее. Вот если интересно, можете почитать как реализована система настройки прав в приведенном мной выше примере системы ссылка.
А как вы будите давать доступ к элементам страницы если не можете их построить как индивидуальные сущности? При помощи чего можно их строить? Такие возможности дает только встроенный в SAP язык программирования. Иначе никак. А система без удобной системы настройки прав (одним-двумя кликами) и возможности настройки прав вплоть до каждого элемента, она просто ущербна.
Потом посмотрите на систему с точки зрения разработчика. Вот вы сделали свою SAP систему и решили сделать встроенный язык программирования для того чтобы дать возможность гибкой настройки системы пользователям. Ваш подход с использованием стандартного языка априоре обречен на провал. Я поясню: например система написана на php. По вашему, чтобы дать возможность редактирования каждого элемента системы, вы должны сделать пользователю изолированный контейнер с системой, поставить туда php и дать доступ к коду, причем вы даже не сможете обфусцировать код, ибо как дать доступ к редактированию каждого элемента, если пользователь просто не сможет найти данный элемент. Т.е. вы всем в свободный доступ дате код многолетней разработки своей компании… Ваш бизнес просто долго не просуществует.
вы предлагаете КАЖДОЙ SAP системе придумывать свой язык?
К сожалению именно так. Почему я выше описал. Да, это сложно, да это дорого. Но если вы хотите заниматься этим бизнесом и дать пользователям сервис универсального редактирования, вам придется это сделать, придется для СВОЕЙ SAP разработать СВОЙ язык программирования. Иначе бизнеса не будет.
Именно поэтому 99% SAP систем своего языка программирования не имеют. Я знаю попытки встроить php код, но именно отдельным индивидуальным новым модулем, но не в коем случае не редактор существующего кода. Никакая компания в здравом уме пускать в свой исходный код не будет (если вы не open source конечно).
По поводу обучения и опыта который нельзя продать.
1С программисты не могут продать опыт свой? Да они очень неплохо зарабатывают, гораздо больше чем большинство программистов популярных языков. И все потому, что их не так много и они ценятся. Они нужны, ибо система распространена.
Обучение: да, проводите обучение. Включите в свои тарифы определенный объем ежемесячного бесплатного обслуживания своими программистами клиента (чтобы он мог не ведя большие расходы доработать свои мелкие нюансы). Если клиенту необходимо разработать крупный модуль и он не шарит в языке этом, да это будет за деньги, как и в случае любого другого языка.
В любом деле производя продукт вы будите нести какие-то издержки.
К структуре базы тоже надо дать доступ, в том числе к служебной информации, что явно не хорошо. Молчу уж удобстве редактирования базы, о CURD, снапшетах процедур, автоматических логов, автоматической структуре прав доступа к элементам и т.п. что реализуемо в качестве функций встроенного языка.
В общем обобщая, свой язык в платформе решает проблему защиты кода смой платформы, проблему безопасности, проблему удобства доработки аккаунта, можно реализовывать свои нужные функции этого языка, которых нет в штатных. Понадобилось, сел, доделал и все пользователи радостно пользуются.
Пока правда не уверен что это может иметь практическое применение к облаку. Надо тут подумать.
Каждый контейнер будет иметь веб сервер и свой IP, надо как-то авторизировать пользователя и пробрасывать его за НАТ в нужный контейнер. Мне кажется это еще та задачка, особенно с двухфактороной авторизацией. Плюс есть файловые сервера где хранятся БД (это не веб сервер, он не резиновый), т.е. из контейнера надо туда давать доступ, причем базы тогда должны быть тоже изолированы в контейнерах. Как то не давать доступ из контейнера с вебом к файлам чужих контейнеров по IP (что проблематично давая доступ к php коду в контейнере).
Плюс вся эта инфростуктура должна создаваться автоматически при регистрации аккаунта.
В общем на мой взгляд это довольно сложная логистическая задача. Но повторюсь, надо подумать, так сходу не могу сказать что не имеет права на жизнь.
Плюс встает вопрос защиты ПО, т.е. код вашей системы будет в конейнере, и вы даете доступ к этому коду и средства программирования. Ничего не помешает его получить. Обфускация не сильно помогает в этом случае. Нужен хотя бы ionCube. SaaS тем и хороша, что код защищен.
В общем решение с контейнерами и доступом к штатному языку программирования на мой взгляд имеют свои минусы. Хотя не скажу что не имеют права на жизнь. Надо переварить поглубже.
А вот свой внутренний язык с пользовательским уровнем абстракции и интерпритатором, решает все эти проблемы. Напрямую доступа нет, но при этом есть возможность произвольного редактирования своего аккаунта.
На самом деле тут еще глубже. Нельзя именно «расширить».
Чтобы дать пользователю управление любым элементом, все эти элементы уже должны быть созданы при помощи внутреннего языка. В общем надо сначала сделать платформу с движком языка, а потом на нем уже написать существующую систему управления проектами.
Просто доработать то что есть, вряд ли возможно.
Свой язык в платформе, это глобальная и очень сложная задача.
Масштаб мешает.
Вы не можете «взять» песочницу, вам надо «сделать свою» песочницу. Вот вы возьмете тот же AppEngine. Максимум что вы там сделаете, это аля интернет магазин. Вот представим что вы там сделали свою платформу управления проектами, дает аккаунты пользователям, они заходят и пользуются теми алгоритмами что вы сделали. И вот вы этим пользователей пустите в свой аккаунт на котором у вас написана платформа чтобы они могли что-то редактировать? Они вам там такое наредактируют… Чтобы пользователю управляли аккаунтом на вашей платформе (которую вы создали в AppEngine) вам опять же надо сделать свою песочницу внутри той песочницы.
Если я не прав, приведите пример. Вот имея сервер, на нем имея сайт с платформой управления проектами, что я могу на этот сервер поставить, чтобы дать пользователю возможность произвольно менять алгоритмы работы именно его аккаунта, не затрагивая всех остальных пользователей?
С чего вы взяли? Чем это отличается от требований того же AppEngine?
Да всем отличается. Это принципиально разные продукты. AppEngine это по сути хостинг с возможностью разработки. Вы можете стем же успехом арендовать сервер и там разворачивать свои приложения.
SaaS система управления проектами — это готовый продукт с определенной функциональностью, и вот этот продукт дает возможность управлять собой при помощи встроенного языка. Вы можете подредактировать и автоматизировать нюансы работы вашей компании. Такой тип языков — своя отдельная ниша.
Еще отдельная интересная ниша, это LabView. И SaaS программирование и LabView (визуальное программирование) имеют немного непривычную логику с точки зрения привычных языков. Это отпечатки своих специфических ниш. И у них там пока мало конкурентов.
Есть большая и не обжитая ниша, совсем не упоминаемая в статье. Можно их назвать «веб ориентированными 1С подобными языками». Поясню: 1С — это программа позволяющая себя произвольно редактировать изнутри. Не просто добавить поле, как в том же Wrike, или подредактировать интерфейс. А задать сложную логику работы по событиям, написать новый модуль, сделать сложный интерфейс.
Тот же подход применим к системе управления проектами по SaaS концепции. Это очень круто. За этим будущее. И этого практически нет. Вот ваш Wrike, по сути позволяет только добавлять новые поля и менять внешний вид интерфейса аккаунта (насколько я понял и справки). А чтобы клиент мог не выходя из аккаунта САМ разработать какой-то модуль, создать таблицу в базе данных, поставить какой-то триггер, написать хранимую процедуру, модернизировать любой элемент интерфейса, добавить новые поля ввода вывода?
Ведь в Wrike, да и во всех аналогичных системах: как сделано — так сделано. И бизнес должен подстраиваться под существующие структуры. Пользователь например не может дописать какие-то автоматические действия по событию изменения тех или иных данных. Или разработать необходимый компании модуль.
Будущее за SaaS системами, которые имеют встроенные языки программирования позволяющие это делать. Они обладают фантастически гибкими возможностями и на мой взгляд они буду вне конкуренции.
Вот пример пока единственной подобной системы: https://erp-platforma.com/. Здесь можно почитать как устроен сам язык: справка (Главы 3 и 4).
И эта ниша слабо развита ввиду очень большой сложности создания такого языка. Основная сложность — безопасность. Пуская в SaaS аккаунт — вы пускаете на свой сервер. И нельзя просто так давать программировать на вашем сервере. Это должна быть очень продуманная с точки зрения безопасности система, иначе вас просто сломают.
В ERP-Платформе например применены очень нестандартные схемы реализации языка, с внешним (пользовательским) и внутренним (системным) уровнями, общающиеся между собой через компилятор. А так же реализация пользовательской логики не в интерфейсе, а в базе данных. Интерфейс там служит только для вывода и редактирования данных, а вся логика обработки всего и вся задается в БД на аналоге PLSQL. Этим он как раз кардинально отличается от 1С, где логика реализуется в интерфейсе, а в БД только хранятся данные (насколько я в курсе, хотя не специалист по 1С).
Такого насколько я знаю нигде больше нет, и никто больше не делал. И это на мой взгляд единственный пусть для SaaS языка.
На практике благодаря взаимоинтеграции программирования интерфейса и базы, а так же встроенной CURD у меня получалось создать рабочий модуль раз в 5 быстрее, чем если это делать на PHP+SQL. Интерфейс вы можете разметить как в экселе, в ячейки накидать элементы форм управления, а к формам подцепить элементы базы данных. Очень удобно и быстро.
Но конечно это надо уметь. Как любой язык, его сначала надо изучить.
Да, вы оказались правы. пЭП нельзя использовать для счет-фактуры. Можно для чего угодно, кроме нее.
Комментарий юриста по этому поводу: "По счету-фактуре установлены жесткие требования — подпись либо живая, либо эцп у оператора.
Была даже в свое время практика, можно ли подписывать сф факсимиле, вроде как примерно то де что и живая подпись.
Суды сказали нельзя.
С эцп будет то же самое. Слишком много бюджет теряет из за сф."
Я в статье сделал дописал, что нельзя использовать для счет-фактуры.
Беря ваш форум таксистов: на заре автомобилестроения были только легковые, грузовые и трактора. Сейчас легковые делятся на классы А, B, C и т.д. Грузоые по грузоподьемности и конструкции. А спецтехники вообще море необъятное. И никакие универсальные вещи их оттуда не вытеснят, потому что специализированная техника умеет лучше решать поставленные для ее ниши задачи.
Летняя и зимняя резины решают поставленные им задачи гораздо лучше чем демисезонная. Демисезонную покупает сейчас только ленивый.
Со временем универсальные языки будут находить все меньшее применение. Это мое мнение.
Но не об этом была речь. Дискуссию то вы развели. Я просто искренне поблагодарил автора за интересную статью, и указал ему что в нише где он находится, еще поле особо не копанное. Да и в целом о том что в статье не указан целый класс языков (можно это рассматривать как класс) которые будут постоянно появляться и теснить основные. Эволюцонно думаю останутся только программы поддерживающие систему локализации, они просто вытеснят конкурентов. Все более-менее крупные компании работающие в гибких бизнес нишах обзаведутся специализированными средствами локализации для своих программ.
Меня же вы пытаетесь убедить что все это ерунда и надо встараивать везде стандартный язык и это круче нет. Нет, это не круче, и это не будет работать. Почему я уже много раз описал.
Если говорить эволюционно, то попрут во всех нишах стандартные языки рано или поздно, они со специализированными не будут выдерживать конкуренции.
1) Имитационный стенд для тестирования алгоритмов управления объектов нефтегазовой отрасли
2) Автоматезированная информационно-измерительная система испытания элементов авиационной техники на удар посторонними предметами
3) Создание испытательного стенда для тестирования атомного реактора нового поколения
4) Разработка имитатора паровой турбины для отладки системы управления
5) Разработка инструментальных средств для исследования алгоритмов поиска маршрута передвижения мобильного робота в условиях частичной неопределенности
и т.д.
можете покапаться тут по разделам (ссылка), тут сотни проектов, и это только в России и только о том что написали.
А вообще можете просто погуглить.
В чем я участвовал уж извиняйте, не буду описывать. Повторюсь только что можно писать программы любой сложности и у меня никаких проблем никогда не возникало. Если что-то понадобилось, то просто берешь и делаешь.
Для универстетов National Instruments свое ПО кстати бесплатно предоставляет насколько я знаю (хотя может что уже и изменилось). Решили что пусть студенты учатся. Так что уже выросло и еще вырастет поколение которое знает что такое LabView.
Не, вполне возможно что и «НИАСИЛИЛ» пользуясь вашей терминологией, но понимаете, нет цели «АСИЛИЛ». Такие языки создаются для определенных вещей и никто не планирует на них захватывать и заставлять работать весь мир. Они сделаны для своих ниш, как и ваши «шаровые шарниры», которые сделаны для автомобилей, а не самолетов. Но в своих нишах они «короли» и универсальные языки там явно проигрывают.
PS: кстати, например трактор «Кировец» может поворачивать без использования ваших шаровых шарниров. Они ему просто не нужны. И это гораздо проще и надежнее.
О чем вы вообще? На LabView реализуются крупнейшие проекты. Создаются программы любой сложности. А National Instruments, создатель языка G, одна их крупнейших международных корпораций с многомиллиардными активами и имеющая представительства в большинстве стран мира.
Да хоть миллионы, это будет в 100 раз удобнее чем в тексте. Там все продумано, вы можете убирать код в блоки (можно обозвать их процедурами) и направлять и выводить из них потоки данных, вы можете группировать различные потоки данных в кластеры, причем даже подписывать каждый поток, вы можете делать «Stacked Sequence Structure» и писать поддиаграмы в последовательных закладках. Просто вы об этих вещах не знаете, ибо такого в «текстовых» языках просто нет.
Скажите это разработчикам ядра андройда.
Ну это что-то прояснило ) Зачем вы на OPCSenator так наехали то? Он кстати хорошую статью написал. Я до вашей ссылки и не знал что некто FBD есть. Кстати он LabView мне напомнил, правда он намного примитивней LabView конечно.
Вы просто совсем не понимаете визуального программирования. Для вас это «безумные схемы». Я кстати вас могу понять. В далеком 2005 году, когда я заканчивал МАИ, я устроился работать на нашу кафедру. Попал в команду которая занималась разработкой программы вибрационной диагностики воздушно-реактивного двигателя в полете. Можно было по анализу сигнатур вибраций определить в каком элементе двигателя поломка (или скоро будет поломка) и что произошло (скоро произойдет). Все это естесвенно делалось на LabView. До этого я все делал в основном на Delphi и честно скажу, первые дня 3 я от LabView плевался, но когда на меня снизошло озарение и я понял как это работает, я забыл Delphi как страшный сон, и кстати по сей день к нему не возвращался ни разу. Именно поэтому могу вас понять, вспомнив те первые ощущения.
Визуальное программирование, это просто офигенская вещь, там все наглядно, там потрясающие системы отладки кода, вы просто визуально можете посмотреть куда какие данные перемещаются и как преобразуются. Вы просто этого не поймете пока вас жизнь не заставит реально на этом поработать. Я до сих пор многие вещи на LabView делаю, это очень удобно.
А FBD я думаю для техников офигенская вещь, и она реально будет популярна в своей нише.
Тут вы сразили просто наповал! Я просто даже не думал что нужны какие-то подробности. Главное требование, хорошее знание процедурного SQL, если человек это знает, ему не составит труда освоить язык программирования в ERP-Плтаформе. Причем даже все равно с какими базами человек работал, SQL он везде SQL. Отличия минимальные. Все остальное мимо. Ну желательно конечно чтобы на html и php не смотрел человек как баран на новые ворота, но это не столь критично.
Как вы думаете, много в мире людей работающих с процедурным SQL? Море.
А «секретарша» знаете, у нее задача владеть языком без приставки «программироания» ;)
Именно компилятор. Вернее даже немного сложнее: интерпретаторо-компилятор. Сначала конфигурация интерпретатором переводится в понятный формат для компилятора, потом уже компилируется. Иначе вы не получите приемлемую скорость работы, если на ходу будите все составлять из конфигурации. Это касается логики работы.
Еще есть внешний интерпретатор, который располагает элементы в окне и дергает именно нужные в текущий момент для работы процедуры (тоже экономя ресурсы), процедуры для скрытых закладок он будет опускать.
Дискуссия развилась потому что люди не понимаю до конца этой темы и считают что можно обойтись стандартными вещами. Я попытался это все это аргументировано развеять, ибо проходил уже через все это и участвую в разработках ERP систем уже около 10 лет и знаю о чем говорю. Я видел разные способы и просто уже знаю как надо делать оптимально и почему. Но люди разные, кто-то понимает, кто-то нет, кто-то думает и пишет какие-то аргументы, у кого-то аргументов нет и просто минусует. Кто понял — я рад, кто нет — ну нет так нет.
Для вас напишу еще раз преимущества:
а) Скорость разработки системы на своей платформе. Вы можете сделать удобный редактор и типовые блоки для типовых и частых действий.
б) Безопасность системы. Давая стандартные языки, затруднительно обеспечить безопасность и защиту кода, при этом давая доступ к любому элементу.
с) Дать свободное редактирование любого существующего элемента (а не только новое) в рамках аккаунта
г) Деление системы на элементарные блоки дает большие преимущества. Можно сделать ту же систему назначения прав, можно делать типовые блоки упрощая разработку, можно вводить всякие интересные свойства элементов.
И т.д. нюансов миллионы. Все не описать.
Минусы:
а) Сложность разработки движка
б) Стоимость тестирования безопасности
Обучение новых сотрудников сюда не ставлю, ибо это не так сложно на самом деле и разово. А клиентов никто не заставляет учить, разве что сами не захотят. Они пользуются в первую очередь самим продуктом, а не средствами его разработки. Для них это просто бонус и гарантия что это не черный ящик.
Но если компания хочет развиваться в будущем, она должна будет это сделать, ибо ее в перспективе вытеснят те кто это сделал (ИХМО)
Это всем понятно, я просто воспользовался вашей терминологией.
Это не вариант. Вернее очень плохой вариант. Вы опять же ограничиваете пользователей рамками ваших API. Если брать опять же пример ERP-Платформы — там пользователь может создавать свой API, т.е. он может делать прямо в триггерах специальные элементы (называются позиции API) на любые таблицы, которые по любому выбранному событию по вашим правилам, передадут указанные вами данные на указанный вами внешний сервер. А на прием данных вы можете придумать свой формат и создать свою процедуру приема информации. Вы не ограничены придуманными кем-то API…
Такие вещи должны решаться на уровне архитектуры языка. И кстати на стандартном языке их решить будет затруднительно. Извиняюсь, опять же приведу пример ERP-Платформы: там есть внешний (логический) и внутренний (физический) уровни, пользователь делает изменения только на внешнем (составляет конфигурацию), а на внутренний они попадают через компилятор. На физическом уровне он в принципе не сможет ничего сделать, а компилятор не даст сделать того что не разрешено, там жесткие уровни проверки корректности. Плюс логика делается не в вебе, а в базе данных. Базы данных естественно не на веб сервере, а в распределенной сети. Файлы естественно тоже никто на веб серверах не хранит…
Я конечно не утверждаю что возможна идеальная безопасность, наверное такого не бывает. Но ее можно приблизить к этому архитектурно.
Там кстати это уже 3-я версия языка, 2 предыдущих были забракованы и с высоты их опыта уже появилась третья с правильным архитектурным решением, которая выстрелила.
Он позволяет писать свой код? Или переписывать их в рамках вашего аккаунта? Это принципиально разные вещи.
По 1С-никам. Я имел дело с некоторыми, и такого насмотрелся, что если честно не очень их уважаю и сам принципиально в 1С лезть не хочу. А конторы реально только и мечтают избавиться бы от 1С, но особо нет альтернатив. И да, за рубежом они не продадут свой опыт. И вы правы что по сути они волею случая стали монополистами (а может что и стоит за этой волей случая...)
Вы тут не правы (хотя с 1С правы). Вам не надо всем навязывать и толкать SaaS язык. Глупо всех заставлять его учить и толкать в массы. Сам по себе он применим только в вашей платформе. Суть его создания:
1) Упростить своей компании дальнейшую разработку, разрабатывать в 3-5 раз быстрее конкурентов пользуясь своими средствами автоматизации и блочной архитектурой. Сложность его создания достаточно быстро окупается. Я тут знаю о чем говорю.
2) Дать клиентам ВОЗМОЖНОСТЬ доработки под их ниши. Это не значит заставить клиента, он берет продукт какой есть, но если ВДРУГ ему понадобиться доработать, он имеет ВОЗМОЖНОСТЬ это сделать. А это далеко не везде так.
Вам не надо учить всех людей вашему языку. Клиент должен в первую очередь пользоваться вашим продуктом, а язык это можно назвать бонусом.
Вам тут надо:
1) написать хороший мануал, на случай если кто-то захочет его заюзать
2) обучать своих сотрудников, благо это не сложно если человек знает что такое PLSQL. Вам там даже php то не нужен, конфигурация окон составляется мышкой…
Черный ящик это как раз таки системы без встроенного языка, а тут вы как раз знаете, что даже в самом плохом случае, вы прочтете мануал и сможете сделать необходимые вам изменения.
А как вы будите давать доступ к элементам страницы если не можете их построить как индивидуальные сущности? При помощи чего можно их строить? Такие возможности дает только встроенный в SAP язык программирования. Иначе никак. А система без удобной системы настройки прав (одним-двумя кликами) и возможности настройки прав вплоть до каждого элемента, она просто ущербна.
Потом посмотрите на систему с точки зрения разработчика. Вот вы сделали свою SAP систему и решили сделать встроенный язык программирования для того чтобы дать возможность гибкой настройки системы пользователям. Ваш подход с использованием стандартного языка априоре обречен на провал. Я поясню: например система написана на php. По вашему, чтобы дать возможность редактирования каждого элемента системы, вы должны сделать пользователю изолированный контейнер с системой, поставить туда php и дать доступ к коду, причем вы даже не сможете обфусцировать код, ибо как дать доступ к редактированию каждого элемента, если пользователь просто не сможет найти данный элемент. Т.е. вы всем в свободный доступ дате код многолетней разработки своей компании… Ваш бизнес просто долго не просуществует.
К сожалению именно так. Почему я выше описал. Да, это сложно, да это дорого. Но если вы хотите заниматься этим бизнесом и дать пользователям сервис универсального редактирования, вам придется это сделать, придется для СВОЕЙ SAP разработать СВОЙ язык программирования. Иначе бизнеса не будет.
Именно поэтому 99% SAP систем своего языка программирования не имеют. Я знаю попытки встроить php код, но именно отдельным индивидуальным новым модулем, но не в коем случае не редактор существующего кода. Никакая компания в здравом уме пускать в свой исходный код не будет (если вы не open source конечно).
По поводу обучения и опыта который нельзя продать.
1С программисты не могут продать опыт свой? Да они очень неплохо зарабатывают, гораздо больше чем большинство программистов популярных языков. И все потому, что их не так много и они ценятся. Они нужны, ибо система распространена.
Обучение: да, проводите обучение. Включите в свои тарифы определенный объем ежемесячного бесплатного обслуживания своими программистами клиента (чтобы он мог не ведя большие расходы доработать свои мелкие нюансы). Если клиенту необходимо разработать крупный модуль и он не шарит в языке этом, да это будет за деньги, как и в случае любого другого языка.
В любом деле производя продукт вы будите нести какие-то издержки.
В общем обобщая, свой язык в платформе решает проблему защиты кода смой платформы, проблему безопасности, проблему удобства доработки аккаунта, можно реализовывать свои нужные функции этого языка, которых нет в штатных. Понадобилось, сел, доделал и все пользователи радостно пользуются.
Пока правда не уверен что это может иметь практическое применение к облаку. Надо тут подумать.
Каждый контейнер будет иметь веб сервер и свой IP, надо как-то авторизировать пользователя и пробрасывать его за НАТ в нужный контейнер. Мне кажется это еще та задачка, особенно с двухфактороной авторизацией. Плюс есть файловые сервера где хранятся БД (это не веб сервер, он не резиновый), т.е. из контейнера надо туда давать доступ, причем базы тогда должны быть тоже изолированы в контейнерах. Как то не давать доступ из контейнера с вебом к файлам чужих контейнеров по IP (что проблематично давая доступ к php коду в контейнере).
Плюс вся эта инфростуктура должна создаваться автоматически при регистрации аккаунта.
В общем на мой взгляд это довольно сложная логистическая задача. Но повторюсь, надо подумать, так сходу не могу сказать что не имеет права на жизнь.
Плюс встает вопрос защиты ПО, т.е. код вашей системы будет в конейнере, и вы даете доступ к этому коду и средства программирования. Ничего не помешает его получить. Обфускация не сильно помогает в этом случае. Нужен хотя бы ionCube. SaaS тем и хороша, что код защищен.
В общем решение с контейнерами и доступом к штатному языку программирования на мой взгляд имеют свои минусы. Хотя не скажу что не имеют права на жизнь. Надо переварить поглубже.
А вот свой внутренний язык с пользовательским уровнем абстракции и интерпритатором, решает все эти проблемы. Напрямую доступа нет, но при этом есть возможность произвольного редактирования своего аккаунта.
1) Эта технология от microsoft, т.е. для linux скорее всего не подойдет.
2) Как вы дадите пользователю аккаунта работать с базой данных?
Чтобы дать пользователю управление любым элементом, все эти элементы уже должны быть созданы при помощи внутреннего языка. В общем надо сначала сделать платформу с движком языка, а потом на нем уже написать существующую систему управления проектами.
Просто доработать то что есть, вряд ли возможно.
Свой язык в платформе, это глобальная и очень сложная задача.
Вы не можете «взять» песочницу, вам надо «сделать свою» песочницу. Вот вы возьмете тот же AppEngine. Максимум что вы там сделаете, это аля интернет магазин. Вот представим что вы там сделали свою платформу управления проектами, дает аккаунты пользователям, они заходят и пользуются теми алгоритмами что вы сделали. И вот вы этим пользователей пустите в свой аккаунт на котором у вас написана платформа чтобы они могли что-то редактировать? Они вам там такое наредактируют… Чтобы пользователю управляли аккаунтом на вашей платформе (которую вы создали в AppEngine) вам опять же надо сделать свою песочницу внутри той песочницы.
Если я не прав, приведите пример. Вот имея сервер, на нем имея сайт с платформой управления проектами, что я могу на этот сервер поставить, чтобы дать пользователю возможность произвольно менять алгоритмы работы именно его аккаунта, не затрагивая всех остальных пользователей?
Да всем отличается. Это принципиально разные продукты. AppEngine это по сути хостинг с возможностью разработки. Вы можете стем же успехом арендовать сервер и там разворачивать свои приложения.
SaaS система управления проектами — это готовый продукт с определенной функциональностью, и вот этот продукт дает возможность управлять собой при помощи встроенного языка. Вы можете подредактировать и автоматизировать нюансы работы вашей компании. Такой тип языков — своя отдельная ниша.
Есть большая и не обжитая ниша, совсем не упоминаемая в статье. Можно их назвать «веб ориентированными 1С подобными языками». Поясню: 1С — это программа позволяющая себя произвольно редактировать изнутри. Не просто добавить поле, как в том же Wrike, или подредактировать интерфейс. А задать сложную логику работы по событиям, написать новый модуль, сделать сложный интерфейс.
Тот же подход применим к системе управления проектами по SaaS концепции. Это очень круто. За этим будущее. И этого практически нет. Вот ваш Wrike, по сути позволяет только добавлять новые поля и менять внешний вид интерфейса аккаунта (насколько я понял и справки). А чтобы клиент мог не выходя из аккаунта САМ разработать какой-то модуль, создать таблицу в базе данных, поставить какой-то триггер, написать хранимую процедуру, модернизировать любой элемент интерфейса, добавить новые поля ввода вывода?
Ведь в Wrike, да и во всех аналогичных системах: как сделано — так сделано. И бизнес должен подстраиваться под существующие структуры. Пользователь например не может дописать какие-то автоматические действия по событию изменения тех или иных данных. Или разработать необходимый компании модуль.
Будущее за SaaS системами, которые имеют встроенные языки программирования позволяющие это делать. Они обладают фантастически гибкими возможностями и на мой взгляд они буду вне конкуренции.
Вот пример пока единственной подобной системы: https://erp-platforma.com/. Здесь можно почитать как устроен сам язык: справка (Главы 3 и 4).
И эта ниша слабо развита ввиду очень большой сложности создания такого языка. Основная сложность — безопасность. Пуская в SaaS аккаунт — вы пускаете на свой сервер. И нельзя просто так давать программировать на вашем сервере. Это должна быть очень продуманная с точки зрения безопасности система, иначе вас просто сломают.
В ERP-Платформе например применены очень нестандартные схемы реализации языка, с внешним (пользовательским) и внутренним (системным) уровнями, общающиеся между собой через компилятор. А так же реализация пользовательской логики не в интерфейсе, а в базе данных. Интерфейс там служит только для вывода и редактирования данных, а вся логика обработки всего и вся задается в БД на аналоге PLSQL. Этим он как раз кардинально отличается от 1С, где логика реализуется в интерфейсе, а в БД только хранятся данные (насколько я в курсе, хотя не специалист по 1С).
Такого насколько я знаю нигде больше нет, и никто больше не делал. И это на мой взгляд единственный пусть для SaaS языка.
На практике благодаря взаимоинтеграции программирования интерфейса и базы, а так же встроенной CURD у меня получалось создать рабочий модуль раз в 5 быстрее, чем если это делать на PHP+SQL. Интерфейс вы можете разметить как в экселе, в ячейки накидать элементы форм управления, а к формам подцепить элементы базы данных. Очень удобно и быстро.
Но конечно это надо уметь. Как любой язык, его сначала надо изучить.
Я в статье сделал дописал, что нельзя использовать для счет-фактуры.