Представите ми са реално бегли. Ние използваме главно технологиите на Сименс. LabView съм виждал само за обща култура.
Някакъв скриптов език в него със сигурност има, така че да - може да се напише всичко, защото е пълен по Тюринг.
Силно ме съмнява обаче всичко да е графично. Но дори и да е така - не мисля, че това е някакъв плюс. Подобни концепции бяха в тренда около нулевите. Напоследък гледам визуалните езици не се развиват много-много, а даже и известен регрес се наблюдава.
Стига глупости бе хора, в графичен език няма скриптове.
И да, регрес, хората го ползват да изстрелват хора в Космоса, и да ги връщат живи. Преди се молеха на рашките за което, докато в същото време им се зъбят и плашат с ядрен апокалипсис.
Ще останеш учуден, но всеки, ти дето му викаш "графичен език", е всъщност само визуализация на някакви текстови сорс файлове. Които при желание можеш да си редактираш и с текстов редактор. И което програмистите редовно практикуват, защото графичните редактори не се справят добре с някои от задачите.
Да, примерно средата на Сименс Step7 използва вместо текстови файлове, таблици от Paradox база данни (това чувал ли си го?) с което ефективно създава толкова главоболия, че го псуваш само като си помислиш, че трябва да правиш нещо с него.
Например не може да се използват системи за контрол на версиите. И като се скапе нещо в някой от милионите файлове, които никой не знае какво точно съдържат, единствената опция е да триеш и да започваш отново, защото средата изкарва съобщение "Проекта е счупен" и толкова.
Добре, че има импорт-експорт от текстови файлове, което частично, но спасява положението.
Добре, че в новите версии (TIA Portal) минаха на текстови файлове, което си е прогрес.
Мой, аз съм писал на LabVIEW. По-скоро е рисуване, тъй се имплементират алгоритмите. Естествено, има визуализация отгоре. Скриптов език с текст отдолу НЯМА!
Айде да приключим с глупостите, става ли?
Сега е интересно да видим дали визуалните среди като Power Builder, Access или UML редакторите и генератори на код са графични езици.
Точно рефакторинга ми е най-големият проблем.
От тука следва ли, че за по-голям проект с питонья е задължително яко тестване?
Един приятел дето ми промива мозъка за питон се хвали, че покривал всичко с тестове.
Ми, по моя преценка, без тестове, има хора къде могат да счупят и типизирани неща. Под тестове имам предвид юнит тестове и интегрейшън тестове.
Пак по-добре от JS където получаваш
[1,2,10,11].sort()
За мен предимството винаги е било че са безцеремонни (за сметка на статичната верифицируемост и пърформанса), нещо което навлиза и в мейнстрийм статичните точно под влияние на популярността на пърл, вбскрипт, джаваскрипт, питон, руби и луа.
По отношение на иновирането не съм чул никой от съответните сенсеи зад популярните скриптаджийски езици да претендира че е бележит иноватор, даже си казват какво откъде са откраднали въпреки че голямо развитие на практиката на JIT и AOT технологиите (съществуващи отдавна) се случи точно покрай динамичните езици, JVM и CLR покрай имплементирането на питон и руби са задобряли доста по начин който сега активно се ползва от флагманските езици за съответната платформа а върху JVM се ползва популярния във финтека лисп диалект clojure, огромно развитие в jit/aot се случва и покрай джаваскрипта както в браузъра така и ноуд, луа има jit имплементация правена от некъв легендарен jit сенсей и тия уроци със сигурност се ползват и от останалите.
Та бих казал че има един процес на взаимно поникване и влияние, статичните добавят разни удобства и фокуси от динамичните а динамичните се развиват в посока статично верифициране и пърформанс
Айде JIT–овете да речем, ама AOT пък къде за динамични езици, то даже не знам колко е възможно като го нахраниш с един код в стринг успех с това AOT
Тук ме замисли. Не съм ползвал Iron Python, но да разбирам, че не може да е ahead of time?
Е така ще почнем да спорим колко ангела се събират на върха на игла, TypeScript статичен или динамичен език е? Или C# код който ползва яко dynamic?
Това което виждам като тренд в динамичните и ме радва е че лека полека се върви към ефективни имплементации на опционални типове, да може да се кара джаста праста което е супер за разни малки неща и прототипване и сервизни дейности като тестове или автоматизация а с добавянето на нарастващо стриктна информация за типовете пък става нарастващо възможно кодът да се джитва все по-ефективно и в идеалния случай да се комплирира аот в случая на голям проект с много човекочасове инвестиция. Отделно статичната верификация за лесен рефактор и иде съпорт.
С добавянето на всякакакви динамикоподобни сгоди към мейнстрийм статичните идват към същото но от другата посока и разликата все повече ще се размива до разни чисто теоретични спорове кое е 'чист' статичен/динамичен език/фичър както когато спорехме разпалено като лапета коя група какъв точно под-стил е в съответната по-обща категория
Това е част от историческия багаж покрай контекста на създаването на джаваскрипта, по подразбиране се сравняват стринг репрезентациите на елементите.
И не е никъв проблем реално
Статичните типове премахват нуждата от планини тривиални тестове, това е един от недостатъците на динамичните езици който някои динамични зомбита отричат фанатично повтаряйки колко яко тестват. Па то си е недостатък, въпреки че учудващо човек може да изплющи планини напълно бачкащ код така джаста праста обаче когато неминуемо стане фал намирането на грешката може да е доста по-трудно.
От статична гледна точка трябва да се внимава за другата крайност, компилаторът не отменя нуждата от тестове, все пак може да провери че подаваш където се чака инт именно инт а не стринг обаче няма начин да провери че измежду всички интове в програмата подаваш правилния
Буквално съм го шипвал в production и всеки път го бъркам щото забравям колко тъпо работи ама не, не е проблем...
Еми ако ползваш any или dynamic явно пишеш динамично типизиран код. Разбира се тези неща трябва да са забранени. Аз между другото за 10 години откакто има dynamic съм го ползвал единствено за да създавам json обекти.
Не е проблем в смисъл че е много добре известно, правиш си там квато ти трябва сравняваща функция и подаваш нея на сорт, може да е от най-простото изваждане за числа до некви специалитети с отчитане на локали.
А че подразбиращото можеше да е поне малко по-интелигентно за най-честите тривиални случаи (като в руби примерно) спор няма ама джаваскрипта е изплякан за две седмици все пак
По-скоро да може на ниво проект да се контролира кои части от сорса могат да ползват какви фичъри на езика. Така би могло да се шибне церберски default без unsafe и динамични неща а където се прецени да се охлаби контролирано
Майкрософт имаха графичен ETL тул към SQL Server с подобен хорър сюжет. Добре че бях минал казарма преди унито и бях наясно че животът понякога е гадно гаден ей така отникъде при това ужким с идея да е по-хубав и просто требе ги преглъща човек тия неща без да си ги слага на сърце :)