Rabin

johnfound

LabView-то е само за визуализации на технологични процеси и не мисля, че е много "език". А иначе отзад работи автоматиката написана на нещо съвсем друго.

Поне бегла идея да имаше от туй нещо. У завода имате ли такова? Напълно работещ програмен език си е, дори компилатор има написан на него.

Представите ми са реално бегли. Ние използваме главно технологиите на Сименс. LabView съм виждал само за обща култура.

Някакъв скриптов език в него със сигурност има, така че да - може да се напише всичко, защото е пълен по Тюринг.

Силно ме съмнява обаче всичко да е графично. Но дори и да е така - не мисля, че това е някакъв плюс. Подобни концепции бяха в тренда около нулевите. Напоследък гледам визуалните езици не се развиват много-много, а даже и известен регрес се наблюдава.

Някакъв скриптов език в него със сигурност има, така че да - може да се напише всичко, защото е пълен по Тюринг.

Силно ме съмнява обаче всичко да е графично. Но дори и да е така - не мисля, че това е някакъв плюс. Подобни концепции бяха в тренда около нулевите. Напоследък гледам визуалните езици не се развиват много-много, а даже и известен регрес се наблюдава.

Стига глупости бе хора, в графичен език няма скриптове.

И да, регрес, хората го ползват да изстрелват хора в Космоса, и да ги връщат живи. Преди се молеха на рашките за което, докато в същото време им се зъбят и плашат с ядрен апокалипсис.

Rabin

Някакъв скриптов език в него със сигурност има, така че да - може да се напише всичко, защото е пълен по Тюринг.

Силно ме съмнява обаче всичко да е графично. Но дори и да е така - не мисля, че това е някакъв плюс. Подобни концепции бяха в тренда около нулевите. Напоследък гледам визуалните езици не се развиват много-много, а даже и известен регрес се наблюдава.

Стига глупости бе хора, в графичен език няма скриптове.

И да, регрес, хората го ползват да изстрелват хора в Космоса, и да ги връщат живи. Преди се молеха на рашките за което, докато в същото време им се зъбят и плашат с ядрен апокалипсис.

Ще останеш учуден, но всеки, ти дето му викаш "графичен език", е всъщност само визуализация на някакви текстови сорс файлове. Които при желание можеш да си редактираш и с текстов редактор. И което програмистите редовно практикуват, защото графичните редактори не се справят добре с някои от задачите.

Да, примерно средата на Сименс Step7 използва вместо текстови файлове, таблици от Paradox база данни (това чувал ли си го?) с което ефективно създава толкова главоболия, че го псуваш само като си помислиш, че трябва да правиш нещо с него.

Например не може да се използват системи за контрол на версиите. И като се скапе нещо в някой от милионите файлове, които никой не знае какво точно съдържат, единствената опция е да триеш и да започваш отново, защото средата изкарва съобщение "Проекта е счупен" и толкова.

Добре, че има импорт-експорт от текстови файлове, което частично, но спасява положението.

Добре, че в новите версии (TIA Portal) минаха на текстови файлове, което си е прогрес.

Ще останеш учуден, но всеки, ти дето му викаш "графичен език", е всъщност само визуализация на някакви текстови сорс файлове. Които при желание можеш да си редактираш и с текстов редактор. И което програмистите редовно практикуват, защото графичните редактори не се справят добре с някои от задачите.

Мой, аз съм писал на LabVIEW. По-скоро е рисуване, тъй се имплементират алгоритмите. Естествено, има визуализация отгоре. Скриптов език с текст отдолу НЯМА!

Айде да приключим с глупостите, става ли?

Сега е интересно да видим дали визуалните среди като Power Builder, Access или UML редакторите и генератори на код са графични езици.

Евлампи

Dr.Who

Динамичните езици нали са много мощни и всичко става много лесно.

Това не предразполага ли и към по-дълбоко затъване ако нагазим в нещо меко и рядко?

Статичното верифициране прави рефакторването и комуникацията между повече маймуни в по-голям проект доста по-безпроблемно.

Точно рефакторинга ми е най-големият проблем.

От тука следва ли, че за по-голям проект с питонья е задължително яко тестване?

Един приятел дето ми промива мозъка за питон се хвали, че покривал всичко с тестове.

Ми, по моя преценка, без тестове, има хора къде могат да счупят и типизирани неща. Под тестове имам предвид юнит тестове и интегрейшън тестове.

Дон Реба

искаш да му сложиш функция за сортиране, да може ей така да си напишеш arr.Sort(), да обаче не всеки има дефиниран оператор > , добре карай, за който има бе- да ама не, трябва нещо като hasfunction, имаш ли темплейти, всичко "динамично" може да потрябва и в статичен вид, но го няма.

Пак по-добре от JS където получаваш

[1,2,10,11].sort()

1, 10, 11, 2`

Stilgar

Значи динамичните не само, че нямат предимства ами за капак няма и иновация там освен дето вкарват статично типизиране малко по малко.

За мен предимството винаги е било че са безцеремонни (за сметка на статичната верифицируемост и пърформанса), нещо което навлиза и в мейнстрийм статичните точно под влияние на популярността на пърл, вбскрипт, джаваскрипт, питон, руби и луа.

По отношение на иновирането не съм чул никой от съответните сенсеи зад популярните скриптаджийски езици да претендира че е бележит иноватор, даже си казват какво откъде са откраднали въпреки че голямо развитие на практиката на JIT и AOT технологиите (съществуващи отдавна) се случи точно покрай динамичните езици, JVM и CLR покрай имплементирането на питон и руби са задобряли доста по начин който сега активно се ползва от флагманските езици за съответната платформа а върху JVM се ползва популярния във финтека лисп диалект clojure, огромно развитие в jit/aot се случва и покрай джаваскрипта както в браузъра така и ноуд, луа има jit имплементация правена от некъв легендарен jit сенсей и тия уроци със сигурност се ползват и от останалите.

Та бих казал че има един процес на взаимно поникване и влияние, статичните добавят разни удобства и фокуси от динамичните а динамичните се развиват в посока статично верифициране и пърформанс

Айде JIT–овете да речем, ама AOT пък къде за динамични езици, то даже не знам колко е възможно като го нахраниш с един код в стринг успех с това AOT

Тук ме замисли. Не съм ползвал Iron Python, но да разбирам, че не може да е ahead of time?

Stilgar

Айде JIT–овете да речем, ама AOT пък къде за динамични езици, то даже не знам колко е възможно като го нахраниш с един код в стринг успех с това AOT

Е така ще почнем да спорим колко ангела се събират на върха на игла, TypeScript статичен или динамичен език е? Или C# код който ползва яко dynamic?

Това което виждам като тренд в динамичните и ме радва е че лека полека се върви към ефективни имплементации на опционални типове, да може да се кара джаста праста което е супер за разни малки неща и прототипване и сервизни дейности като тестове или автоматизация а с добавянето на нарастващо стриктна информация за типовете пък става нарастващо възможно кодът да се джитва все по-ефективно и в идеалния случай да се комплирира аот в случая на голям проект с много човекочасове инвестиция. Отделно статичната верификация за лесен рефактор и иде съпорт.

С добавянето на всякакакви динамикоподобни сгоди към мейнстрийм статичните идват към същото но от другата посока и разликата все повече ще се размива до разни чисто теоретични спорове кое е 'чист' статичен/динамичен език/фичър както когато спорехме разпалено като лапета коя група какъв точно под-стил е в съответната по-обща категория

Stilgar

Пак по-добре от JS където получаваш

[1,2,10,11].sort()

1, 10, 11, 2`

Това е част от историческия багаж покрай контекста на създаването на джаваскрипта, по подразбиране се сравняват стринг репрезентациите на елементите.

И не е никъв проблем реално

Dr.Who

Точно рефакторинга ми е най-големият проблем.

От тука следва ли, че за по-голям проект с питонья е задължително яко тестване?

Един приятел дето ми промива мозъка за питон се хвали, че покривал всичко с тестове.

Статичните типове премахват нуждата от планини тривиални тестове, това е един от недостатъците на динамичните езици който някои динамични зомбита отричат фанатично повтаряйки колко яко тестват. Па то си е недостатък, въпреки че учудващо човек може да изплющи планини напълно бачкащ код така джаста праста обаче когато неминуемо стане фал намирането на грешката може да е доста по-трудно.

От статична гледна точка трябва да се внимава за другата крайност, компилаторът не отменя нуждата от тестове, все пак може да провери че подаваш където се чака инт именно инт а не стринг обаче няма начин да провери че измежду всички интове в програмата подаваш правилния

Евлампи

Stilgar

Пак по-добре от JS където получаваш

[1,2,10,11].sort()

1, 10, 11, 2`

Това е част от историческия багаж покрай контекста на създаването на джаваскрипта, по подразбиране се сравняват стринг репрезентациите на елементите.

И не е никъв проблем реално

Буквално съм го шипвал в production и всеки път го бъркам щото забравям колко тъпо работи ама не, не е проблем...

Евлампи

Е така ще почнем да спорим колко ангела се събират на върха на игла, TypeScript статичен или динамичен език е? Или C# код който ползва яко dynamic?

Еми ако ползваш any или dynamic явно пишеш динамично типизиран код. Разбира се тези неща трябва да са забранени. Аз между другото за 10 години откакто има dynamic съм го ползвал единствено за да създавам json обекти.

Stilgar

Буквално съм го шипвал в production и всеки път го бъркам щото забравям колко тъпо работи ама не, не е проблем...

Не е проблем в смисъл че е много добре известно, правиш си там квато ти трябва сравняваща функция и подаваш нея на сорт, може да е от най-простото изваждане за числа до некви специалитети с отчитане на локали.

А че подразбиращото можеше да е поне малко по-интелигентно за най-честите тривиални случаи (като в руби примерно) спор няма ама джаваскрипта е изплякан за две седмици все пак

Stilgar

Еми ако ползваш any или dynamic явно пишеш динамично типизиран код. Разбира се тези неща трябва да са забранени

По-скоро да може на ниво проект да се контролира кои части от сорса могат да ползват какви фичъри на езика. Така би могло да се шибне церберски default без unsafe и динамични неща а където се прецени да се охлаби контролирано

johnfound

Например не може да се използват системи за контрол на версиите. И като се скапе нещо в някой от милионите файлове, които никой не знае какво точно съдържат, единствената опция е да триеш и да започваш отново, защото средата изкарва съобщение "Проекта е счупен" и толкова.

Добре, че има импорт-експорт от текстови файлове, което частично, но спасява положението.

Майкрософт имаха графичен ETL тул към SQL Server с подобен хорър сюжет. Добре че бях минал казарма преди унито и бях наясно че животът понякога е гадно гаден ей така отникъде при това ужким с идея да е по-хубав и просто требе ги преглъща човек тия неща без да си ги слага на сърце :)

Евлампи

Stilgar

Буквално съм го шипвал в production и всеки път го бъркам щото забравям колко тъпо работи ама не, не е проблем...

Не е проблем в смисъл че е много добре известно, правиш си там квато ти трябва сравняваща функция и подаваш нея на сорт, може да е от най-простото изваждане за числа до некви специалитети с отчитане на локали.

А че подразбиращото можеше да е поне малко по-интелигентно за най-честите тривиални случаи (като в руби примерно) спор няма ама джаваскрипта е изплякан за две седмици все пак

То по тая логика никакво лайно в езика не е проблем щото след някакво време ти става "добре известно". Сега фактът е че съм шипвал бъг в production, това е дефиницията на проблем, целият смисъл на шибаните езици е да няма проблем.