Programowanie metodą „przeciągnij i upuść” - czy będzie latać? [Zamknięte]

Wszystkie języki programowania, które znam, są napisane - tzn. Wpisane w taki czy inny sposób jako fragmenty tekstu. Ale zastanawiam się, czy jest jakiś język programowania, w którym można po prostu przeciągnąć i upuścić cały program; aby uzyskać pętlę, zaznacz to pole tutaj i przeciągnij je do tej sekcji „kodu” i tak dalej. A jeśli nie ma takiego takiego, to czy leciałby, gdyby został wymyślony?

Osobiście nie wierzę, że byłby to dobry pomysł, ale chciałbym usłyszeć, co myślisz.

Wiele zestawów stworzyło systemy programowania typu „przeciągnij i upuść”.

„Labview” firmy National Instruments jest prawdopodobnie najbardziej znany i najlepszy.

Podstawowym problemem, z którym wszyscy się spotykają, jest to, że nie ma znanego sposobu na przekształcenie Flying Code Monkey w eksperta programistę i inżyniera. Jako JEDEN przykład, nie ma różnicy w Flying Flying Monkey między procesem O (N ^ 2) lub O (N ^ 3) a procesem O (N log N), co oznacza, że ​​muszą być dostarczane z procedurami standardowymi dla algorytmy O (N log N), które można dopasować do tworzonych przez nich szybkich graficznych kludges.

Drugim problemem, z którym wszyscy się spotykają, jest to, że kiedy dostarczasz bloki specjalnego przeznaczenia wymagane przez pierwszy problem, narzut związany z przenoszeniem danych między blokami zaczyna być drogi. Pracowałem z jednym bardzo fajnym takim systemem o nazwie Rippen. Kiedy profilowałem, aby zobaczyć, gdzie boli nas aplikacja do przetwarzania czujników o WYSOKIEJ WYDAJNOŚCI, byłem raczej zaniepokojony, widząc, że około 20% mojego czasu procesora idzie na przenoszenie danych. (Odkąd zajmowałem się przetwarzaniem obrazu LADAR, przetwarzając zmiennoprzecinkowe dane na każdym pikselu obrazu wejściowego, 20% procesora stanowiło DUŻO ruchu danych.)

Prawdopodobnie możesz obejść część 2, przechodząc do systemu opartego na kompilatorze: podajesz mu swoje zdjęcie i kompiluje się ono w mocno zoptymalizowanym programie wykonywalnym, ale nie jestem pewien, czy naprawiłoby to problemy, a to mogłoby zaszkodzić interaktywny charakter narzędzia.

Prostą odpowiedzią jest: nie.

Jeśli chodzi o programowanie, wprowadzanie tekstu znacznie przewyższa pod względem określonych informacji niż część wizualna.

LabVIEW jest dość graficzny.

Ze strony LabVIEW :

Wieśniak! Rury to prawdopodobnie doskonały przykład języka graficznego opisywanego typu; przeciągasz i upuszczasz prymitywy (wszystko, od źródeł danych, na których działasz, po pętle i warunki warunkowe), aby wytworzyć przepływ informacji przez system.

Jest bardzo specyficzny dla domeny, ale o to głównie chodzi; Pipe koncentruje się na danych, dlatego najważniejsza jest wizualizacja (a nie wyrażenie). Podobnie środowiska samouczków, takie jak Scratch lub Sprog! podkreśl wizualizację tego, nad czym pracujesz jako pomoc w nauce; wydajność wprowadzania danych jest w tej dziedzinie znacznie niższym priorytetem.

Od czasu do czasu ktoś wymyśla język programowania „przeciągnij i upuść” lub narzędzie do projektowania, które „położy kres programowaniu, jakie znamy” i sprawi, że każdy, kto go użyje, stanie się programistą.

Powodem, dla którego żaden z nich nie wykonał jeszcze tej pracy i nie wyłączył nas wszystkich z pracy, jest to, że tak naprawdę, bez względu na to, ile tworzysz funkcji przeciągnij i upuść, i bez względu na to, jak przyjazny dla użytkownika jest, to prosty fakt, że programowanie jest trudne.

Prawdziwe dyscypliny programowania polegają na wiedzy na temat rozwiązywania problemów, na tym, jak modelować procesy i organizować dane, aby były przydatne. Nawet zrozumienie, co w ogóle jest możliwe z komputerem.

Istnieją dowody (jeśli są kontrowersyjne) sugerujące, że niektórych ludzi nie można nauczyć tak myśleć, co prowadzi mnie do kilku interesujących i istotnych myśli. Na początek, jeśli nie możesz myśleć w ten sposób, to jest wielu programistów, więc zawsze możesz zatrudnić kogoś do realizacji pomysłu, jeśli go masz, i uważasz, że warto za to zapłacić. Jeśli potrafisz wystarczająco dobrze pracować z logiką programowania, równie dobrze możesz nauczyć się prawdziwego języka, zamiast bawić się w stosunkowo proste środowisko przeciągnij i upuść.

Mam tu na myśli ogólne programowanie. To samo niekoniecznie ma zastosowanie w bardziej ograniczonym scenariuszu typu DSL, w którym przeciąganie i upuszczanie może być naprawdę przydatnym procesem użytkowników, którzy są specjalistami w tej dziedzinie, a nie specjalistami IT.

Najlepszy system programowania metodą przeciągnij i upuść, jaki widziałem, jest dla robotów Lego Mindstorms NXT.

Pozwala to robić niesamowite rzeczy, kontrolując dość skomplikowane funkcje.

Jednak w pewnym momencie się psuje i musisz wrócić do innego systemu.
Zobacz ten artykuł: http://www.wired.com/geekdad/2007/11/the-best-progra/

Możliwe jest jednak, że jeśli to zostanie poprawione, a różne scenariusze zostaną zaspokojone, potrzeba tego będzie coraz mniejsza.

Programowanie przepływu danych (inaczej programowanie oparte na przepływie) może być swego rodzaju. Chociaż programowanie przepływu danych nie jest kompletne w Turingu.

Programowanie przepływu danych to metoda tworzenia aplikacji, gdy umieszczasz instancje komponentów na scenie i łączysz ich porty, aby tworzyły sieć przetwarzania komunikatów. Komponenty można wybierać z biblioteki, mają porty odbiorcze (wejściowe) i produkcyjne (wyjściowe), które są gotowe do połączenia z portami innych komponentów.

Oto ładny przykład, w którym nawet mysz nie została użyta do zbudowania aplikacji syntezatora, ale gołe ręce i małe kostki: http://www.youtube.com/watch?v=0h-RhyopUmc

Artykuły w Wikipedii są dobrym punktem wyjścia: http://en.wikipedia.org/wiki/Flow-based_programming http://en.wikipedia.org/wiki/Dataflow_programming

Generowanie dźwięku jest typowym obszarem programowania przepływu danych. Istnieje kilka systemów syntezatorów typu open source: http://www.synthedit.com/ http://alsamodular.sourceforge.net/

Jeśli masz komputer Mac, możesz mieć fabrycznie zainstalowany program Quartz Composer: http://developer.apple.com/graphicsimaging/quartz/quartzcomposer.html

Ja również system DF z moim przyjacielem, ale nie mamy wizualny edytor jeszcze , tylko skryptu wizualizera.

System programowania Scratch MIT jest prawie całkowicie metodą „przeciągnij i upuść”.

Wygląda na to, że Google App Inventor jest podobny (i przypisuje Scratch).

Nie chciałbym kodować w sobie niczego wielkiego, ale do nauczania „myślenia programisty” Scratch jest znakomity. To jest prawdziwe programowanie, ale z natychmiastową satysfakcją wizualną i blokowaniem zatrzasków unika się dużej części frustracji związanej z „błędem składni”, która zniechęca przybyszów (pogląd, który widzę powtórzony w tym artykule ). Próba oczarowania małych dzieci za pomocą wiersza polecenia w języku Python nie kończy tego dnia.

To już istnieje, choć być może nie w formie, o której myślisz. Dwa przykłady to Simulink i Alice.

Simulink to graficzny sposób składania dynamicznych symulacji systemowych. Podczas gdy większość konstrukcji jest bardziej złożona niż to, co zwykle uważa się za programowanie, rzeczy takie jak for i jeśli instrukcje mogą być nadal tworzone graficznie. Simulink jest czymś wielkim w aplikacjach lotniczych i kosmicznych, ponieważ rząd i wiele dużych firm wykonuje swoje wstępne projekty w Simulink, a następnie stosuje pewien rodzaj dowodu twierdzenia do „kodu” Simulink.

Alice, to narzędzie do przeciągania i upuszczania, programujące dla dzieci. Pozwala dzieciom bawić się budowaniem opowieści poprzez przeciąganie i upuszczanie akcji i obiektów na rodzaj planszy do programowania.

Prograph to fajny język, w którym wszystko przeciągało się i upuszczało. Ponadto Wikipedia ma artykuł z dobrą listą języków wizualnych .

Istnieje wiele wizualnych języków programowania. System telefoniczny, którym zarządzałem dla dużego centrum telefonicznego, został zaprogramowany za pomocą modułów przeciągnij i upuść. Mój wujek opracował system Just-In-Time do projektowania linii produkcyjnych, który był całkowicie przeciągany i upuszczany i to było 20 lat temu.

Grałem nawet w grę walki robotów na PS1, która używała języka programowania typu przeciągnij i upuść.

Programowanie tekstowe trwa 50 lat, ale inżynieria oprogramowania musi przejść do dziedziny graficznej, aby poradzić sobie z kolejnym poziomem złożoności. Na przykład pojawienie się procesorów manycore i wyzwania związane z programowaniem równoległym przesuwają model wątków do granic możliwości. Szczerze mówiąc, myślę, że społeczność programistów jest po prostu arogancka, myśląc, że w programowaniu jest coś zupełnie innego i specjalnego, co nie byłoby możliwe do wizualizacji, jak każda inna domena. Podobnie jak operatorzy telefoniczni i wiele innych zawodów, odpowiednia technologia automatyzacji pozwoli ekspertom w dziedzinie wkrótce współpracować w bogatych przestrzeniach symulacyjnych systemów opartych na wiedzy. Branża oprogramowania od dawna spóźnia się ze zmianą paradygmatu.