Języki programowania wizualnego

Większość z nas uczyła się programowania przy użyciu „tekstowych” języków programowania, takich jak Basic, C / C ++ i Java. Uważam, że myślenie wizualne jest bardziej naturalne i wydajne dla ludzi. Programowanie wizualne pozwala programistom pisać programy, manipulując elementami graficznymi. Myślę, że użycie programowania wizualnego powinno poprawić jakość kodu i zmniejszyć błędy programistyczne. Znam kilka języków wizualnych, takich jak App Inventor , Scratch i LabView .

Dlaczego nie ma głównych, uniwersalnych języków wizualnych dla programistów? Jakie są zalety i wady programowania wizualnego?

Ogólnie rzecz biorąc, w projektowaniu języka programowania występuje kompromis między łatwością użycia a ekspresją (mocą). Pisanie prostego programu „Witaj, świecie” w języku dla początkujących, takim jak Scratch lub App Inventor, jest na ogół łatwiejsze niż pisanie go w języku programowania ogólnego przeznaczenia, takim jak Java lub C ++, w którym możesz mieć do wyboru kilka strumieni dane wyjściowe, różne zestawy znaków, możliwość zmiany składni, typy dynamiczne itp.

Podczas tworzenia App Inventor (którego byłem częścią) naszą filozofią projektowania było uproszczenie programowania dla początkujących. Trywialnym przykładem było oparcie naszych indeksów tablic na 1, a nie na 0, mimo że obliczenia mogą być wykonywane przez zaawansowanych programistów nieco bardziej skomplikowane.

Jednak głównym sposobem, w jaki wizualne języki programowania są zaprojektowane dla początkujących, jest wyeliminowanie możliwości błędów składniowych, uniemożliwiając tworzenie programów nieważnych pod względem składniowym. Na przykład języki blokowe nie pozwalają na zmianę wartości miejsca docelowego instrukcji przypisania. Ta filozofia ma tendencję do uzyskiwania prostszych gramatyk i języków.

Kiedy użytkownicy zaczynają budować bardziej złożone programy w języku bloków, zauważają, że przeciąganie i upuszczanie bloków jest wolniejsze niż pisanie. Wolisz wpisać „a * x ^ 2 + b * x + c” lub utworzyć go z bloków?

Nie można dać sprawiedliwości temu tematowi (przynajmniej przeze mnie) w kilku akapitach, ale niektóre z głównych powodów to:

1. Języki bloków są zwykle zaprojektowane dla początkujących, więc nie są tak rozbudowane z założenia.
2. Nie ma przyjemnego wizualnego sposobu wyrażenia niektórych złożonych pojęć, takich jak systemy typów, które można znaleźć w językach programowania ogólnego przeznaczenia.
3. Używanie bloków jest niewygodne w przypadku złożonych programów.

Dlaczego nie ma głównych, uniwersalnych języków wizualnych dla programistów? Jakie są zalety i wady programowania wizualnego?

Języki wizualne dzielą na trzy główne kategorie:

1. Narzędzia nieprogramiści do wykonywania podstawowych zadań automatyzacji. Pomyśl Automator na Macu.
2. Środowiska uczenia się, w których pisanie na klawiaturze nie jest praktyczne lub w których ważna jest struktura programu pokazująca logiczny przepływ. Pomyśl o zarysowaniu, Alice itp.
3. Rozwiązany problem to problem z przepływem danych, a rozwiązanie problemu jest dobrze modelowane przez pewien rodzaj przepływów danych między niezależnymi skrzynkami, które naśladują świat fizyczny. Przychodzą mi na myśl LabView i Ableton.

Zaletą programowania wizualnego jest to, że masz ogólny przegląd struktury systemu. Prowadzi to do bezpośredniego problemu, że kiedy stajesz się szczegółowy, twój kod spaghetti naprawdę wygląda jak spaghetti . Wspólnym składnikiem języków wizualnych jest blok kodu lub element konfiguracji elementu wizualnego. Problem polega na tym, że programista musi zrozumieć odłączone bloki kodu, które mogą być powiązane w dziwny sposób.

Chociaż w programowaniu wizualnym nie ma nic złego, może się zdarzyć, że w większości zadań nie jest to dobre podejście.

Istnieje wiele wizualnych języków programowania, które pokażą dwie następujące bibliografie: vlib.org i oregonstate.edu .

IMHO nie udało im się zdobyć przyczepności, ponieważ chociaż są dobre dla przykładów zabawek, nie radzą sobie z wieloma poziomami abstrakcji, reprezentacji i szczegółowości wymaganymi przez duże projekty. Musisz spojrzeć na system taki jak AutoDesk Revit (system zarządzania informacjami o budynku używany przez architektów i inżynierów), aby zobaczyć, jak skomplikowane może być zarządzanie informacjami wizualnymi.

Zamiast patrzeć na programowanie ogólnego zastosowania, programowanie wizualne najprawdopodobniej odniesie sukces jako narzędzie konfiguracyjne w wyspecjalizowanych domenach.

Tekst jest wizualny.

W naszym kodzie używamy wszelkiego rodzaju wskazówek wizualnych. Każde użycie białych znaków (wcięcia, nowe linie, puste linie, odstępy między wierszami) ma na celu zapewnienie wizualnych wskazówek dla funkcjonalności kodu. Używamy różnego rodzaju różnych składni, aby zapewnić wizualne informacje o tym, co robi kod. Nasi redaktorzy kolorują nasz kod, aby go wyróżnić.

Matematyka jest tekstowa. Istnieje wiele rodzajów notacji, ale ostatecznie sprowadza się to do tekstu. Działają od setek lat.

Chodzi mi o to, że tekstowa reprezentacja kodu wykorzystuje zdolności wizualne ludzi. Prawdopodobnie możemy go lepiej wykorzystać, ale nie porzucając tekstu.

[W wersji PDF tej odpowiedzi liczby lub diagramy są interaktywne i dynamiczne.]

Elementy sieciowe i adnotacje: wizualny język programowania ogólnego przeznaczenia

Używam grafiki do organizowania programów JavaScript ™, które używają interfejsu Acrobat® / JavaScript API. Każdy obiekt graficzny reprezentuje element sieci Petriego (miejsce, przejście, wejście lub wyjście) lub reprezentuje więcej niż jeden element sieci Petriego. Każdy obiekt graficzny jest w rzeczywistości adnotacją odpowiedniego elementu sieci. Jeśli jednak każdy obiekt graficzny jest odwzorowany na jeden i tylko jeden element sieci, można go użyć do wygenerowania elementu sieci. A jeśli obiekt graficzny odwzorowuje na więcej niż jeden element sieci, a odwzorowanie jest dobrze zdefiniowane, można go również użyć do wygenerowania elementów sieci. Standardowe elementy siatki Petriego są reprezentowane przez pewne typy grafiki: okrąg jest miejscem, kwadrat lub prostokąt lub linia jest przejściem, strzałka z koła do kwadratu jest wejściem, a strzałka z kwadratu do koła jest wydajność. Ponadto,

[Rodzaje adnotacji w „Standardowej sieci Petriego” można znaleźć w wersji PDF tej odpowiedzi.]

Carl Adam Petri opisał większość tych pomysłów (w tym rodzaje adnotacji w „Standardowej sieci Petriego” w swojej rozprawie doktorskiej (Petri, 1966). Zastosował również elementy sieciowe i adnotacje do opisu kilku obwodów logicznych, takich jak rysunek 6.

Korzyści i wyzwania

Wizualny język programowania może pomóc programistom opracować programy komputerowe (Menzies, 2002).

Mam co najmniej trzy powody, dla których uważam elementy sieciowe i adnotacje za przydatne (zalety?).

Pierwszy powód. Logikę procesu można utworzyć pojedynczo. Oznacza to, że sieć może zostać przedłużona poprzez dodanie elementów do istniejącej sieci (Petri, 1966). Na przykład model kontrolera można podzielić na komponenty wewnętrzne i zewnętrzne. Wewnętrzny element reguluje system. Komponent zewnętrzny łączy się ze środowiskiem, akceptując dane wejściowe ze środowiska. Ryc. 1 to model sieci wewnętrznej Petriego. Możliwe jest dodanie modelu Petri Net komponentu zewnętrznego do modelu Petri Net komponentu wewnętrznego poprzez dodanie odpowiednich miejsc i przejścia (rysunek 2).

Ryc. 1 Model sieci Petriego elementu wewnętrznego kontrolera (Halloway, Krogh i Giua, 1997)

Ryc. 2 Model sieci Petriego wewnętrznych i zewnętrznych elementów kontrolera (Halloway, Krogh i Giua, 1997)

Drugi powód Kody powiązane z każdym elementem sieci mogą pochodzić z więcej niż jednego „języka programowania” (Petri, 1973). Mogą pochodzić z języka komputerowego, takiego jak JavaScript, COBOL, ADA i język asemblera. Mogą pochodzić z języka matematycznego, takiego jak symbole algebraiczne. Mogą pochodzić z prozy zakodowanej w języku angielskim, niemieckim, francuskim, greckim, tagalog, chińskim itp. W ten sposób można ją wykorzystać jako podstawę komunikacji i współpracy w całym cyklu życia oprogramowania lub systemu; oraz wśród różnych użytkowników, programistów i interesariuszy (Petri, 1973).

Trzeci powód Możliwe jest skupienie się na określonych obiektach graficznych w sieci i napisanie adnotacji kodu lub logiki dla powiązanych obiektów graficznych. Rozważ model gry karcianej Petri Net na rycinie 3. Jeśli strzałka dla wejścia P7  T4 jest standardową grafiką dla wejścia w siatkę miejsca / przejścia i jeśli m_7 jest znakiem dla miejsca P7, to adnotacja logiczna dla aktualizacja znaku miejsca wejściowego to m_7 = m_7-1. Jeśli s_9 ^ - jest statusem wejścia, wówczas adnotacja logiczna do aktualizacji statusu wejścia to s_9 ^ - = ((m_7 <1)? False: true).

Rycina 3 Model gry karcianej Petri Net

Mam co najmniej trzy powody, dla których uważam stosowanie sieci Petriego za trudne (wady?)

Jeśli jest zbyt wiele obiektów graficznych, trudno byłoby utworzyć lub odczytać sieć. Trudność można złagodzić, biorąc podzbiór grafiki i przedstawiając je za pomocą jednego, dwóch lub trzech symboli graficznych (Noe, 1973; Petri, 1966). Na przykład, jeśli uważa się, że model gry karcianej Petri Net na rycinie 3 zawiera zbyt wiele obiektów graficznych na schemacie, możliwe jest połączenie niektórych elementów graficznych i utrzymanie wystarczającej ilości informacji, aby zmapować schemat do programu komputerowego. Rozważmy rysunek 4, model Petri Net tej samej gry znaleziony na rysunku 3 z grafiką wysokiego poziomu (Chionglo, 2016a).

Rysunek 4 Model sieci Petriego w grze karcianej wykorzystującej grafikę wysokiego poziomu (Chionglo, 2016a)

W innym przykładzie zewnętrzne elementy kontrolera na ryc. 2 można połączyć, aby uzyskać bardziej zwięzłą graficzną reprezentację, jak pokazano na ryc. 5.

Rysunek 5 Model sieci Petriego sterownika z grafiką wysokiego poziomu dla komponentów zewnętrznych

Wreszcie wzajemnie wykluczający się zestaw miejsc lub wzajemnie wykluczający się zestaw przejść można również przedstawić za pomocą obiektu graficznego wysokiego poziomu (Chionglo, 2015).

Drugi powód Nawet przy standardowej grafice rysowanie i pozycjonowanie grafiki może być trudne, szczególnie jeśli oczekuje się, że końcowy schemat będzie przyjazny dla użytkownika lub czytelnika. Niektóre decyzje dotyczące tworzenia diagramu przyjaznego dla użytkownika lub czytelnika obejmują: odpowiedni układ obiektów graficznych, odpowiednie wymiary płótna i kształtów, krzywiznę strzałek, rodzaj główek strzałek, rozmiar i czcionkę tekstu, oraz wybór kolorów grafiki i tekstu.

Trzeci powód Łatwo jest tworzyć adnotacje w elementach sieci w uporządkowany sposób, ponieważ każda adnotacja jest bezpośrednio lub pośrednio związana z elementem sieci. Jednak wyświetlanie każdej adnotacji wraz z grafiką każdego elementu sieci może nie być dobrym pomysłem, ponieważ na diagramie może być za dużo informacji. Rozważmy na przykład schemat modelu sieci logicznej Petri Net, który zawiera odniesienia do wszystkich właściwości i adnotacji logicznych (rysunek 6). [Oryginalny model zawiera warunek testowy dla statusu każdego wyjścia (ryc. 31 na stronie 78 (Petri, 1966)); warunek testu został tutaj pominięty, ponieważ jest on równoważny oryginalnemu modelowi dla danego początkowego oznakowania. Zatem każde wyjście ma jedną adnotację logiczną do obliczenia znaku miejsca wyjściowego.]

Ryc. 6 Siatka miejsca / przejścia z adnotacjami - na podstawie ryc. 31 str. 78 angielskiego tłumaczenia rozprawy Petri (1966)

Jednym ze sposobów złagodzenia tego wyzwania byłoby zidentyfikowanie rodzajów adnotacji używanych w modelu i zdefiniowanie obiektów graficznych zawierających adnotacje tych typów (Petri, 1966). Dlatego gdy diagram Petri Net składa się z obiektów graficznych z definicji, interpretacja tych obiektów powinna zawierać adnotacje „niewidoczne”. Ryc. 7 należy interpretować jako standardową sieć Petriego (definicje patrz Adnotacje do standardowej sieci Petriego); dlatego adnotację logiczną można pominąć na schemacie.

Ryc. 7 Siatka miejsca / przejścia - na podstawie ryc. 31 strona 78 angielskiego tłumaczenia rozprawy Petri (1966)

Innym sposobem na złagodzenie tego wyzwania byłoby użycie widoków formularzy adnotacji w celu uzupełnienia lub uzupełnienia diagramu (Chionglo, 2016b; 2014). Widoki można dalej podzielić na mniejsze widoki, a każdy widok można wyświetlić i ukryć.

Referencje

Chionglo, JF (2016a). Odpowiedź na „Jak zaprojektować przepływ stanu dla gry z kartami reagowania / redukcji?” Na Stack Overflow. Dostępne na https://www.academia.edu/34059934/A_Reply_to_How_to_design_a_state_flow_for_a_react_redux_flashcard_game_at_Stack_Overflow .

Chionglo, JF (2016b). Dwie formy widoku sieci Petriego. Dostępne na stronie http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf .

Chionglo, JF (2015). Zmniejszenie liczby grafik elementów sieciowych na diagramie sieci Petriego za pomocą grafiki wysokiego poziomu. Dostępne na stronie http://www.aespen.ca/AEnswers/WjTpY1429533268 .

Chionglo, JF (2014). Elementy sieciowe i adnotacje do programowania komputerowego: obliczenia i interakcje w formacie PDF. Dostępne na https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .

Halloway, LE; Krogh, BH i Giua, A. (1997). Przegląd metod Petri Net dla kontrolowanych systemów zdarzeń dyskretnych [wersja elektroniczna]. Układy dynamiczne zdarzeń dyskretnych: teoria i zastosowania, tom. 7. Boston: Kluwer Academic Publishers, s. 151–190.

Menzies, T. (2002). Problemy z oceną wizualnych języków programowania. W SK Chang (Ed). Podręcznik inżynierii oprogramowania i inżynierii wiedzy, tom. 2 powstające technologie. World Scientific Publishing co. Pte. Ltd., ss. 93–101.

Noe, JD i Nutt, GJ (1973). „Makro-sieci elektroniczne do reprezentacji systemów równoległych”, IEEE Transactions on Computers, vol. C-22, nr 8, 19 sierpnia 1973, s. 718–727.

Petri, CA (1973). Koncepcje teorii sieci. W Matematycznych podstawach informatyki: Proc. Sympozjum i Letnia Szkoła, Wysokie Tatry, 3–8 września 1973 r., strony 137–146. Matematyka. Inst. słowackiego Acada. of Sciences, 1973.

Petri, CA (1966). Komunikacja z Automotą [przeł. CF Greene, Jr.]. Suplement I do sprawozdania technicznego RADC-TR-65-377 (tom I). Baza sił powietrznych Griffiss, Nowy Jork: Rzymskie Centrum Rozwoju Lotnictwa, Dział Badań i Technologii, Dowództwo Systemów Sił Powietrznych, Baza Sił Powietrznych Griffiss. Pobrano 31 sierpnia 2011 r. Z http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdf .

Johne Percival Hackworth :

Chociaż w programowaniu wizualnym nie ma nic złego, może się zdarzyć, że w większości zadań nie jest to dobre podejście.

Być może dotychczas wizualne języki programowania były po prostu zbyt niedojrzałe? Przekonanie, że zaawansowanych wizualizacji nie można zastosować do artefaktów oprogramowania i że są one całkowicie pozostawione „wyobraźni” każdego programisty, aby stworzyć własne. Podnoszenie poziomu abstrakcji w jednolity i zautomatyzowany sposób wydaje się oczywiste, tak długo, jak długo nie jest poświęcana zdolność do wykonywania abstrakcji na niskim poziomie i wysoka wydajność wykonania. Może to ostatecznie doprowadzić do „programowania” ekspertów w dziedzinie, niewiele różniącego się od sposobu, w jaki arkusze kalkulacyjne automatyzują zadanie programistów COBOL w zakresie manipulowania liczbami. Podstawową różnicą jest tutaj zamiana liczb na manipulowanie „systemami ogólnymi”.

Możesz spojrzeć na Programowanie bez technologii kodowania (PWCT)

PWCT to wizualny język programowania ogólnego przeznaczenia, który umożliwia tworzenie systemów i aplikacji poprzez generowanie interaktywnych kroków zamiast pisania kodu.

Oto dobre miejsce do rozpoczęcia i jest to oprogramowanie typu open source .

trudne pytanie. programowanie wizualne lub oparte na przepływach rzeczywiście stało się coraz bardziej popularne, ale nie jest powszechnie stosowane w porównaniu ze wszystkimi językami programowania. znaczącymi czynnikami są utrzymanie i standaryzacja. kod komputerowy można wydrukować na stronach. nie zawsze jest tak jasne, jak wydrukować program wizualny.

w przeciwieństwie do obecnej najlepszej odpowiedzi twierdzę, że zdecydowanie nie ma żadnych teoretycznych ograniczeń mocy programowania wizualnego w porównaniu do języków tekstowych. w rzeczywistości programowanie wizualne może być kiedyś łatwiejsze do utrzymania w oparciu o szybszą konceptualizację przez człowieka wielu warstw abstrakcji . wydaje się więc, że w jego absorpcji występuje niewątpliwy element inercji społecznej / kulturowej / konserwatyzmu .

edytory wizualne są prawdopodobnie znacznie bardziej złożone w kodzie, i jest to przerażające, biorąc pod uwagę, że nawet same IDE oparte na tekście mogą być bardzo złożone, np. Eclipse , zauważ, że istnieją wtyczki zorientowane na programowanie wizualne w niektórych IDE, takich jak eciplse, np. do budowania GUI. programowanie wizualne do budowy GUI jest obecnie dość rozpowszechnione.

wydaje mi się, że użycie wizualnych programów rośnie w wybranych obszarach i że od tego czasu może stać się bardziej powszechne.

nie zapominajmy, że programowanie wizualne jest nieodłącznym elementem projektowania układów EE przez dziesięciolecia, w których nie jest to abstrakcja, a (pod) systemy są rozmieszczone w projektach 2D dokładnie zgodnie z przeznaczeniem.

zestaw Lego Mindstorms , teraz powszechny i mający ponad dekadę, zawsze miał oprogramowanie programistyczne oparte na programowaniu wizualnym, teraz znacznie usprawnione w wielu wersjach.

tutaj jest ciekawy najnowszy artykuł analizujący historię i perspektywy i sugerujący, że może stać się bardziej powszechny w programowaniu internetowym. dynamiczne rozmieszczanie kontrolek / widżetów na stronie jest odmianą programowania wizualnego.

Kolejnym kluczowym / pojawiającym się obszarem, w którym jest szeroko stosowany w wielu narzędziach, jest BPM, modelowanie procesów biznesowych.

• Jak tajemna metoda kodowania z lat 70. Oprogramowanie bankowe może uratować zdrowie psychiczne programistów wszędzie (Fast Company)

• BPM, wikipedia do modelowania procesów biznesowych

Sądzę, że powód, dla którego te rozwiązania nie są tak popularne, ponieważ w większości przypadków mogą być niemożliwe do zarządzania i stać się bałaganem.

Prawie wszystkie dostępne obecnie narzędzia do programowania wizualnego są częścią większych aplikacji i są wykorzystywane do określonego celu (np. Blueprint w UE4).

W każdym razie nowym, do którego ostatnio natknąłem się na ogólne programowanie, jest Korduene, który tak naprawdę nie jest dość ogólny, ponieważ służy raczej do tworzenia aplikacji Windows.

Myślę, że @Raphael i inni mylą się, gdy mówią, że program jest tekstem. To nie jest To wiele rzeczy. Mówi komputerowi, co robić lub jak to zrobić. (imperatywne, deklaratywne programowanie) Powiązanie programowania z edycją tekstu to historyczny i sprzeczny z intuicją dogmat. Który został stworzony przez ograniczone wejścia / wyjścia tekstowe wczesnych komputerów. Ludzie nie są parserami tekstu!

Chociaż myślę, że ludzie mają rację, że w pełni wizualny język (gdzie robisz wszystko wizualnie, łącząc elementy za pomocą myszy i tym podobne) jest niepraktyczny dla języka ogólnego przeznaczenia, myślę, że wszystkie obecne języki mogłyby i powinny zostać przeniesione na język pośredni poziom. Gdzie elementy językowe mają wizualną reprezentację, która jest zapisywana w binarnym pliku językowym. Programista nie pisałby tekstu jak szalony, ani żyłby pod urokiem linii i wcięć.

Ale wstawia elementy za pomocą najbardziej produktywnej kombinacji klawiszy skrótu / poleceń / elementów interfejsu użytkownika. I tylko typy ciągów znaków oraz innych danych i identyfikatorów. Uniemożliwiłoby to błędy składniowe i spowodowałoby, że języki z myślą o bezpieczeństwie i poprawności (np. ADA) byłyby znacznie bardziej produktywne. A także uczyniłoby innych bezpieczniejszymi i mniej problematycznymi, uniemożliwiając całe klasy powszechnych błędów. (Takie jak te, które ADA zapobiega, ponieważ są nieporęczne)

Do pewnego stopnia wszystko szło w tym kierunku. Przez automatyczne wcięcie i kolorowanie składni. Niestety nikt nie zdawał sobie sprawy (ani nie dbał o to wystarczająco), że jest to podstawowa koncepcja „parsera tekstu ludzkiego”, co jest nie tak. Argumenty emacs vs vim są zabawne, ponieważ oba są błędne. Są „rozwiązaniami” sztucznie stworzonego problemu.