비주얼 프로그래밍 언어

우리 대부분은 Basic, C / C ++, Java와 같은 "텍스트"프로그래밍 언어를 사용하여 프로그래밍을 배웠습니다. 인간이 시각적으로 생각하는 것이 더 자연스럽고 효율적이라고 생각합니다. 비주얼 프로그래밍을 통해 개발자는 그래픽 요소를 조작하여 프로그램을 작성할 수 있습니다. 비주얼 프로그래밍을 사용하면 코드 품질이 향상되고 프로그래밍 버그가 줄어 듭니다. App Inventor , Scratch 및 LabView 와 같은 몇 가지 시각적 언어를 알고 있습니다 .

개발자를위한 주류 범용 비주얼 언어가없는 이유는 무엇입니까? 비주얼 프로그래밍의 장단점은 무엇입니까?

일반적으로, 사용 편의성과 표현력 (power) 사이의 프로그래밍 언어 설계에는 상충 관계가 있습니다. 스크래치 또는 App Inventor와 같은 초보자 언어로 간단한 "Hello, world"프로그램을 작성하는 것은 일반적으로 Java 또는 C ++와 같은 범용 프로그래밍 언어로 작성하는 것보다 쉽습니다. 다른 문자 집합에 대한 출력, 구문을 변경할 수있는 기회, 동적 유형 등

App Inventor (나의 일부)를 만들 때 우리의 디자인 철학은 초보자를 위해 간단한 프로그래밍을하는 것이 었습니다. 간단한 예제는 배열 프로그래머가 0이 아닌 1을 기준으로하는 것이 었습니다. 비록 고급 프로그래머가 계산을 약간 더 복잡하게 만들 수 있지만.

그러나 비주얼 프로그래밍 언어가 초보자를 위해 설계되는 주된 방법은 구문 상 잘못된 프로그램을 만들 수 없도록하여 구문 오류 가능성을 제거하는 것입니다. 예를 들어, 블록 언어를 사용하면 rvalue를 대입 문의 대상으로 만들 수 없습니다. 이 철학은 더 간단한 문법과 언어를 만들어내는 경향이 있습니다.

사용자가 블록 언어로 더 복잡한 프로그램을 구축하기 시작하면 블록을 끌어다 놓는 것이 입력하는 것보다 느립니다. "a * x ^ 2 + b * x + c"를 입력하거나 블록으로 작성 하시겠습니까?

몇 마디로이 주제에 대한 정의를 줄 수는 없지만 (적어도 나에 의해) 몇 가지 주요 이유는 다음과 같습니다.

1. 블록 언어는 초보자를 위해 설계된 경향이 있으므로 의도적으로 강력하지는 않습니다.
2. 범용 프로그래밍 언어에서 찾을 수있는 유형 시스템과 같은 복잡한 개념을 시각적으로 표현할 수있는 좋은 방법은 없습니다.
3. 복잡한 프로그램에는 블록을 사용하기가 까다 롭습니다.

개발자를위한 주류 범용 비주얼 언어가없는 이유는 무엇입니까? 비주얼 프로그래밍의 장단점은 무엇입니까?

시각적 언어는 크게 세 가지 범주로 분류됩니다.

1. 프로그래머가 아닌 사람이 기본 자동화 작업을 수행하도록 도구. Mac에서 Automator를 생각하십시오.
2. 타이핑을 많이하는 것이 실용적이지 않거나 논리적 인 흐름을 보여주는 프로그램의 구조가 중요한 학습 환경. 스크래치, 앨리스 등을 생각하십시오.
3. 해결해야 할 문제는 데이터 흐름 문제이며, 문제에 대한 해결책은 물리적 세계를 모방 한 독립된 상자 사이의 일종의 데이터 흐름으로 잘 모델링됩니다. LabView와 Ableton이 모두 떠 오릅니다.

비주얼 프로그래밍의 장점은 시스템 구조를 개괄적으로 살펴볼 수 있다는 것입니다. 이것은 세부 사항을 얻을 때 스파게티 코드가 실제로 스파게티 처럼 보이는 즉각적인 문제로 이어집니다 . 시각적 언어의 일반적인 구성 요소는 시각적 요소에 대한 일종의 코드 블록 또는 구성 구성 요소입니다. 문제는 프로그래머가 이상한 방식으로 서로 연결될 수있는 연결이 끊어진 코드 블록을 이해해야한다는 것입니다.

시각적 프로그래밍에는 아무런 문제가 없지만 대부분의 작업에 적합하지 않은 경우 일 수 있습니다.

vlib.org 와 oregonstate.edu의 두 가지 참고 문헌이 보여 주듯이 수많은 시각적 프로그래밍 언어가 있습니다 .

IMHO 그들은 장난감 예제에 적합하지만 큰 프로젝트에 필요한 여러 수준의 추상화, 표현 및 세분성을 관리하지 못하기 때문에 견인력을 얻지 못했습니다. 시각적 정보 관리가 얼마나 복잡한 지 보려면 AutoDesk Revit (건축가 및 엔지니어가 사용하는 빌딩 정보 관리 시스템)과 같은 시스템을 살펴 봐야합니다.

비주얼 프로그래밍은 범용 프로그래밍을 보지 않고 전문화 된 도메인의 구성 도구로 성공할 가능성이 높습니다.

텍스트 는 시각적입니다.

우리는 코드에서 모든 종류의 시각적 단서를 사용합니다. 공백 (인 덴트, 줄 바꿈, 공백 줄, 줄 간격)을 사용할 때마다 코드 기능에 대한 시각적 신호를 제공해야합니다. 우리는 모든 종류의 다른 구문을 사용하여 코드가 수행하는 작업에 대한 시각적 정보를 제공합니다. 우리 편집자들은 코드를 색칠하여 눈에 띄게 만듭니다.

수학은 텍스트입니다. 모든 종류의 표기법이 있지만 결국 기본적으로 텍스트가됩니다. 그들은 수백 년 동안 일해 왔습니다.

요점 : 코드의 텍스트 표현은 인간의 시각 능력을 활용하는 것입니다. 우리는 아마도 그것을 더 잘 활용할 수는 있지만 텍스트를 버리는 것은 아닙니다.

[이 회신의 PDF 버전의 경우 그림 또는 다이어그램은 대화식이며 동적입니다.]

넷 요소와 주석 : 범용 비주얼 프로그래밍 언어

그래픽을 사용하여 Acrobat® / JavaScript API를 사용하는 JavaScript ™ 프로그램을 구성합니다. 각 그래픽 개체는 Petri Net 요소 (장소, 전환, 입력 또는 출력)를 나타내거나 둘 ​​이상의 Petri Net 요소를 나타냅니다. 각 그래픽 객체는 실제로 해당 네트 요소의 주석입니다. 그러나 모든 그래픽 객체가 하나의 네트 요소에만 매핑되는 경우 네트 요소를 생성하는 데 사용될 수 있습니다. 그리고 그래픽 객체가 둘 이상의 네트 요소에 매핑되고 매핑이 잘 정의되어 있으면 네트 요소를 생성하는 데 사용될 수도 있습니다. 표준 Petri Net 요소는 특정 유형의 그래픽으로 표시됩니다 : 원은 장소, 정사각형 또는 직사각형 또는 선은 전환, 원에서 사각형으로의 화살표는 입력이며, 정사각형에서 원으로의 화살표는 산출. 더욱이,

[ "표준 페트리 넷"의 주석 유형은이 회신의 PDF 버전에 있습니다.]

Carl Adam Petri는 박사 학위 논문 (Petri, 1966)에서 "Standard Petri Net"의 주석 유형을 포함하여 이러한 아이디어의 대부분을 설명했으며, 그림과 같은 여러 논리 회로의 설명에 순 요소 및 주석을 적용했습니다. 6.

장점과 도전

시각적 프로그래밍 언어는 컴퓨터 프로그래머가 컴퓨터 프로그램을 개발하는 데 도움이 될 수 있습니다 (Menzies, 2002).

넷 요소와 주석이 유용한 이유는 적어도 세 가지가 있습니다 (이점).

전나무 이유. 프로세스 로직은 한 번에 하나의 요소를 만들 수 있습니다. 이는 기존 네트에 요소를 추가하여 네트를 확장 할 수 있음을 의미합니다 (Petri, 1966). 예를 들어, 컨트롤러 모델은 내부 구성 요소와 외부 구성 요소로 나눌 수 있습니다. 내부 구성 요소가 시스템을 조정합니다. 외부 구성 요소는 환경의 입력을 승인하여 환경과 인터페이스합니다. 그림 1은 내부 구성 요소의 Petri Net 모델입니다. 적절한 위치와 전환을 추가하여 외부 구성 요소의 Petri Net 모델을 내부 구성 요소의 Petri Net 모델에 추가 할 수 있습니다 (그림 2).

그림 1 컨트롤러 내부 구성 요소의 페트리 넷 모델 (Halloway, Krogh and Giua, 1997)

그림 2 컨트롤러 내부 및 외부 구성 요소의 페트리 넷 모델 (Halloway, Krogh and Giua, 1997)

두 번째 이유. 각 순 요소와 관련된 코드는 둘 이상의 "프로그래밍 언어"(Petri, 1973)에서 제공 될 수 있습니다. JavaScript, COBOL, ADA와 같은 컴퓨터 언어 및 어셈블리 언어에서 제공 될 수 있습니다. 대수 기호와 같은 수학 언어에서 나올 수 있습니다. 영어, 독일어, 프랑스어, 그리스어, 타갈로그어, 중국어 등으로 인코딩 된 산문에서 나올 수 있습니다. 따라서 소프트웨어 또는 시스템 개발 수명주기 전반에 걸쳐 커뮤니케이션 및 협업의 기초로 사용될 수 있습니다. 그리고 다른 사용자, 개발자 및 이해 관계자들 사이에서 (Petri, 1973).

세 번째 이유. 넷에서 특정 그래픽스 객체에 집중하고 관련 그래픽스 객체에 대한 코드 또는 로직 주석을 작성할 수 있습니다. 그림 3에서 카드 게임의 Petri Net 모델을 고려하십시오. 입력 P7  T4의 화살표가 Place / Transition Net의 입력에 대한 표준 그래픽이고 m_7이 P7의 마크인 경우 논리 주석은 다음과 같습니다. 입력 장소의 마크를 업데이트하는 것은 m_7 = m_7-1입니다. s_9 ^-가 입력 상태 인 경우 입력 상태를 업데이트하기위한 논리 주석은 s_9 ^-= ((m_7 <1)? false : true)입니다.

그림 3 카드 게임의 Petri Net 모델

Petri Nets의 적용이 어려운 이유는 세 가지가 있습니다 (불이익?).

그래픽 객체가 너무 많으면 네트를 생성하거나 읽기가 어렵습니다. 어려움은 그래픽의 서브셋을 취함으로써 완화 될 수 있고 하나, 둘 또는 세 개의 그래픽 심볼을 사용하여 표현할 수있다 (Noe, 1973; Petri, 1966). 예를 들어, 그림 3의 카드 게임의 Petri Net 모델이 다이어그램에 너무 많은 그래픽 객체를 갖는 것으로 간주되는 경우 일부 그래픽을 결합하고 다이어그램을 컴퓨터 프로그램에 매핑하기에 충분한 정보를 유지할 수 있습니다. 높은 수준의 그래픽 (Chionglo, 2016a)이있는 그림 3과 동일한 게임의 Petri Net 모델 인 그림 4를 고려하십시오.

그림 4 고급 그래픽을 사용한 카드 게임의 Petri Net 모델 (Chionglo, 2016a)

다른 예에서,도 2의 제어기의 외부 구성 요소는도 5에 도시 된 바와 같이보다 간결한 그래픽 표현을 생성하기 위해 결합 될 수있다.

그림 5 외부 구성 요소를위한 고급 그래픽이있는 컨트롤러의 페트리 넷 모델

마지막으로, 상호 배타적 인 장소 집합 또는 상호 배타적 인 전이 세트는 고급 그래픽 객체를 사용하여 표현 될 수도 있습니다 (Chionglo, 2015).

두 번째 이유. 표준 그래픽을 사용하더라도 최종 다이어그램이 사용자에게 친숙하거나 독자에게 친숙 할 것으로 예상되는 경우 특히 그래픽을 그리고 배치하는 것이 어려울 수 있습니다. 사용자 친화적이거나 독자 친화적 인 다이어그램을 만들기위한 결정에는 다음과 같은 것들이 포함됩니다 : 그래픽 객체의 적절한 레이아웃, 캔버스와 도형의 적절한 치수, 화살표의 곡률, 화살표 머리의 종류, 텍스트의 크기와 글꼴, 그래픽 및 텍스트의 색상 선택.

세 번째 이유. 모든 주석은 순 요소와 직간접 적으로 관련되어 있기 때문에 순 요소의 주석을 순서대로 쉽게 생성 할 수 있습니다. 그러나 다이어그램에 너무 많은 정보가 표시 될 수 있기 때문에 모든 주석의 그래픽과 함께 모든 주석을 표시하는 것은 좋은 생각이 아닙니다. 예를 들어, 모든 속성 및 로직 주석에 대한 참조를 포함하는 로직 회로의 Petri Net 모델 다이어그램을 고려하십시오 (그림 6). [원래 모델에는 모든 출력의 상태에 대한 테스트 조건이 포함되어 있습니다 (Petri, 1966 년의 78 페이지 그림 31); 테스트 조건은 주어진 초기 마킹에 대한 원래 모델과 동일하므로 여기서 생략되었습니다. 따라서 모든 출력에는 출력 위치의 마크를 계산하기위한 하나의 논리 주석이 있습니다.]

그림 6 주석이있는 장소 / 전이 망 – Petri 논문 논문의 영어 번역의 그림 31-78 페이지

이 문제를 해결하는 한 가지 방법은 모델에 사용 된 주석 유형을 식별하고 이러한 유형의 주석을 포함하는 그래픽 객체를 정의하는 것입니다 (Petri, 1966). 따라서 Petri Net 다이어그램이 정의의 그래픽 객체로 구성된 경우 이러한 객체의 해석에는 "보이지 않는"주석이 포함되어야합니다. 그림 7은 표준 페트리 네트로 해석되어야합니다 (정의는 표준 페트리 네트의 주석 참조). 그러므로, 논리 주석은 다이어그램에서 생략 될 수있다.

그림 7 장소 / 전환 망 – Petri 논문 논문의 영어 번역 그림 31 페이지 78을 기반으로 함 (1966)

이 문제를 완화하는 또 다른 방법은 주석의 양식보기를 사용하여 다이어그램을 보완하거나 보완하는 것입니다 (Chionglo, 2016b; 2014). 뷰들은 더 작은 뷰들로 더 분할 될 수 있고, 각각의 뷰는 디스플레이되고 숨겨 질 수있다.

참고 문헌

JF Chionglo (2016a). Stack Overflow에서 "React / redux 플래시 카드 게임의 상태 흐름을 디자인하는 방법"에 대한 답변. https://www.academia.edu/34059934/A_Reply_to_How_to_design_a_state_flow_for_a_react_redux_flashcard_game_at_Stack_Overflow 에서 사용 가능합니다 .

JF Chionglo (2016b). Petri Net의 두 가지 형태보기. http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf 에서 사용할 수 있습니다.

JF Chionglo (2015). 고급 그래픽을 사용하여 Petri Net 다이어그램의 순 요소 그래픽 수를 줄입니다. http://www.aespen.ca/AEnswers/WjTpY1429533268 에서 사용 가능합니다 .

JF Chionglo (2014). 컴퓨터 프로그래밍을위한 순 요소 및 주석 : PDF의 계산 및 상호 작용. https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF 에서 사용 가능합니다 .

Halloway, LE; Krogh, BH 및 Giua, A. (1997). 제어 된 이산 이벤트 시스템을위한 Petri Net 방법에 대한 조사 [전자 버전]. 개별 이벤트 동적 시스템 : 이론 및 응용, Vol. 7. 보스턴 : Kluwer Academic Publishers, 151 – 190 쪽.

Menzies, T. (2002). 비주얼 프로그래밍 언어에 대한 평가 문제. SK Chang (Ed)에서. 소프트웨어 공학 및 지식 공학 핸드북, Vol. 2 신흥 기술. 세계 과학 출판사 Pte. Ltd., 93 – 101 쪽.

Noe, JD and Nutt, GJ (1973). "병렬 시스템의 표현을위한 매크로 E-Nets", 컴퓨터의 IEEE 트랜잭션, vol. C-22, No. 8, 1973 년 8 월, pp. 718 – 727.

캘리포니아 페트리 (1973). 순 이론의 개념. 컴퓨터 과학의 수학적 기초 : Proc. 1973 년 9 월 3 일 – 8 일, High Tatras, Symposium and Summer School, 137 – 146 쪽. Inst. 슬로바키아 아카데 과학의 1973.

캘리포니아 페트리 (1966). Automota와의 통신 [trans. CF Greene, Jr.]. 기술 보고서 ​​RADC-TR-65-377 (볼륨 I)에 대한 보충 I. 뉴욕 그리피스 공군 기지 : 로마 공군 기지, 연구 및 기술 부서, 공군 시스템 사령부, 그리피스 공군 기지. http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdf 에서 2011 년 8 월 31 일에 확인 함 .

존 퍼시벌 해크 워스 :

시각적 프로그래밍에는 아무런 문제가 없지만 대부분의 작업에 적합하지 않은 경우 일 수 있습니다.

아마도 지금까지 비주얼 프로그래밍 언어가 너무 미숙했을까요? 고급 시각화는 소프트웨어 아티팩트에 적용 할 수 없으며 각 개발자가 자신의 역할을 수행 할 수있는 '상상력'에 완전히 의존한다는 개념은 잘못된 가정 일 수 있습니다. 낮은 수준의 추상화와 높은 실행 성능을 수행 할 수있는 능력이 희생되지 않는 한, 추상화 수준을 균일하고 자동화 된 방식으로 높이는 것이 명백해 보입니다. 이로 인해 스프레드 시트가 COBOL 프로그래머의 작업을 자동화하여 숫자를 조작하는 방식과 크게 다르지 않은 도메인 전문가 '프로그래밍'으로 이어질 수 있습니다. 여기서 가장 큰 차이점은 숫자를 '일반 시스템'의 조작으로 대체하는 것입니다.

코딩 기술이없는 프로그래밍 (PWCT)을 볼 수 있습니다

PWCT는 코드를 작성하는 대신 대화식 단계를 생성하여 시스템 및 응용 프로그램을 개발할 수있는 범용 비주얼 프로그래밍 언어입니다.

다음은 시작하기에 좋은 장소입니다이며 오픈 소스 .

까다로운 질문. 시각적 또는 흐름 기반 프로그래밍이 실제로 더 많이 사용되었지만 모든 프로그래밍 언어에 비해 널리 사용되지는 않습니다. 중요한 요소는 유지 관리 및 표준화입니다. 컴퓨터 코드는 페이지에 인쇄 할 수 있습니다. 시각적 프로그램을 인쇄하는 방법이 항상 명확하지는 않습니다.

현재의 최고 대답과 달리 나는 시각적 프로그래밍 능력 대 텍스트 언어에 대한 본질적인 이론적 제한이 없다고 주장합니다. 사실 시각적 프로그래밍은 여러 계층의 추상화 에 대한 인간의 빠른 개념화에 기반하여 언젠가 유지하기가 더 쉬울 것으로 보인다 . 따라서 사회 / 문화적 관성 / 보전 주의의 수용 에는 틀림없는 요소가있는 것 같습니다 .

비주얼 에디터는 아마도 코드에서 훨씬 더 복잡 할 것입니다. 이것은 텍스트 기반 IDE조차도 Eclipse 와 같이 매우 복잡 할 수 있다는 점을 고려할 때 강력 합니다. GUI 프로그래밍과 같은 일부 IDE에는 비주얼 프로그래밍 지향 플러그인이 있습니다. GUI 구축을위한 비주얼 프로그래밍은 현재 매우 널리 퍼져 있습니다.

선택 영역에서 시각적 프로그래밍 사용이 증가하고 있으며 이제부터 점점 더 일반적이 될 수 있습니다.

비주얼 프로그래밍은 추상화가 아닌 수십 년 동안 EE 칩 디자인 에 내재되어 있으며 서브 시스템은 의도 한대로 2D 디자인으로 배치되어 있습니다.

레고 마인드 스톰 키트 는 현재 널리 사용되고 있으며 10 년이 넘게 항상 비주얼 프로그래밍 기반의 개발 소프트웨어를 보유하고 있으며, 이제는 여러 버전에서 상당히 간소화되었습니다.

다음은 역사와 전망을 분석하고 웹 기반 프로그래밍에 더 일반적이 될 수 있음을 제안하는 흥미로운 최근 기사입니다. 페이지에 컨트롤 / 위젯을 동적으로 배치하는 것은 시각적 기반 프로그래밍의 변형입니다.

많은 도구에서 널리 사용되는 또 다른 핵심 / 신흥 영역은 비즈니스 프로세스 모델링 인 BPM입니다.

• 1970 년대 뱅킹 소프트웨어의 비전 코딩 방법으로 어디서나 웹 개발자의 정신을 구할 수있는 방법 (빠른 회사)

• BPM, 비즈니스 프로세스 모델링 Wikipedia

이러한 솔루션이 그렇게 인기가없는 이유는 대부분의 경우 관리 할 수없고 혼란 스러울 수 있기 때문입니다.

오늘날 사용 가능한 거의 모든 시각적 프로그래밍 도구는 더 큰 응용 프로그램의 일부이며 특정 목적으로 사용됩니다 (예 : UE4의 블루 프린트).

어쨌든 최근에 일반 프로그래밍을 위해 접한 새로운 것은 Korduene입니다. 이것은 Windows 응용 프로그램을 만드는 데 더 적합하기 때문에 실제로는 일반적인 목적이 아닙니다.

나는 프로그램이 텍스트라고 말할 때 @Raphael과 다른 사람들이 잘못 생각합니다. 그렇지 않습니다. 많은 것들입니다. 컴퓨터에게 무엇을해야하는지, 어떻게해야하는지 알려줍니다. (불완전하고 선언적인 프로그래밍) 프로그래밍과 텍스트 편집의 연관은 역사적이고 반 직관적 인 교리입니다. 초기 컴퓨터의 제한된 텍스트 입력 / 출력에 의해 생성되었습니다. 사람들은 텍스트 파서가 아닙니다!

나는 사람들이 완전한 시각적 언어 (마우스를 통해 요소를 연결하여 시각적으로하는 모든 것)가 범용 언어에 비현실적이라고 생각하지만, 현재의 모든 언어는 중간 언어로 옮겨 질 수 있고 움직여야한다고 생각합니다. 수평. 언어 요소에는 시각적 표현이 있으며 이진 언어 파일로 저장됩니다. 프로그래머는 미친 것처럼 텍스트를 입력하거나 줄과 들여 쓰기의 철자에 따라 살지 않을 것입니다.

그러나 가장 생산적인 단축키 / 명령 / UI 요소 조합을 통해 요소를 삽입합니다. 그리고 문자열과 기타 데이터 및 식별자 만 입력하십시오. 이것은 구문 오류를 불가능하게하고 안전하고 정확함을 염두에 둔 언어 (예 : ADA)를보다 생산적으로 만듭니다. 또한 일반적인 오류의 전체 클래스를 불가능하게함으로써 다른 사람들을 더 안전하고 덜 버그없이 만들 것입니다. (ADA가 성가신 것으로 방지하는 것처럼)

어느 정도는 이런 식으로 향하고있었습니다. 자동 들여 쓰기 및 구문 색상 지정 안타깝게도 "인간 텍스트 파서"의 핵심 개념이 잘못되었다는 것을 아는 사람은 아무도 없습니다. emacs vs vim 인수는 둘 다 잘못 되었기 때문에 재미 있습니다. 그것들은 인위적으로 생성 된 문제에 대한 "해결책"입니다.