'프로그래밍' 검색 결과 1건

  1. 2012.06.11 시각적 프로그래밍 언어에 대한 생각 (9)

부연: 글을 다시 읽어보니 부연할 부분들이 있는 것 같아서 추가합니다(승범아 고마워).

  • Squeak을 시각적 언어라고 하였는데 이는 잘못입니다. Squeak Etoys가 시각적 언어입니다.
  • 시각적 프로그래밍 언어에 대하여 "배우기 쉽게"라는 측면만 지나치게 강조되고 있는 것 같은데, 인지적 능력을 향상시켜주는 수단이라는 측면에서도 생각해보면 좋겠습니다. 예를 들어 데이터 시각화를 "통계를 모르는 초보자들이 숫자를 쉽게 이해하기 위한 것"으로만 보는 견해는 단견이라는 느낌과 비슷하게요. 이런 주장도 하고 싶었는데 글에 잘 드러나지 않은 것 같아요.


...


시각적 프로그래밍 언어라는 글을 읽고 이런저런 생각이 나서 의견을 적습니다.

요약하자면 1) 문법(syntax) 측면에서 기존 언어에 비해 크게 쉽다고 할 수 없고 2) 의미론(semantics) 측면에서도 개선점이 딱히 없으므로, 3) 특정 도메인에 특화된 언어(DSL)를 쉽게 익힐 수 있도록 하는 용도로 쓰는 것이 좋겠다는 내용입니다.

지금까지 나와있는 시각적 프로그래밍 언어들(Blocky, Squeak Squeak Etoys)에 대한 평가로서는 위 주장에 동의하고(시각적 언어에는 "문법이 존재하지 않는다"는 표현이나 몇몇 부분에는 동의하지 않지만 글의 전체적인 맥락에 동의), 앞으로의 가능성에 대한 평가로서는 동의하지 않습니다. 저는 시각적 프로그래밍 언어에 큰 가능성이 있다고 생각합니다.

일단 "시각적"이라는 말이 무엇인지 생각해보는게 중요하다고 봅니다. "눈을 통해 들어오는 자극"은 시각적이고 그렇지 않으면 비시각적이라고는 할 수는 없는게 그렇게 나누면 모든 언어가 시각적 언어이기 때문입니다. "비언어적 기호(사각형, 마름모, 직소퍼즐모양 등)의 공간상 배치를 적극적으로 활용하는 언어"가 시각적 언어라고 정의하면 현존하는 시각적 언어들을 대충 걸러낼 수 있지만, 이 정의에 기반해서 따져보면 앞으로 나올 시각적 언어들에 대해서도 별 기대를 안하게 됩니다(위 글의 전체적인 맥락에 동의하는 이유).

하지만 정의를 아래와 같이 바꿔보면 어떨까요?

"시각적 언어란 시지각의 특성을 잘 활용하는 언어이다"

시지각의 특성이란 2차원 평면으로부터 3차원을 구성해내는 능력, 특정 시각적 특성(visual features)을 선택적으로 뽑아내는 능력(tunable processing), 동일한 특성을 갖는 대상을 빠르게 뽑아내는 병렬처리 능력, 외각선 등 시각적 특성의 차이에 기반하여 사물 간의 경계를 찾아내는 능력 등을 잘 활용해야 한다는 것이죠.

이 관점에서  아래 Blocky 예시를 봅시다.

 

변수 접근은 붉은 색, 상수는 파란색, 제어문은 녹색 식으로 색상 부여(color coding)가 되어 있는데, "코드 상에 존재하는 변수를 전부 찾아내기"가 목적이라면 "빨간색을 모두 찾기"라는 시각적 질의를 수행하면 됩니다. 이런 질의를 뇌(Primary Visual Cortex)에서 병렬처리되므로 굉장히 효율적으로 수행됩니다. 하지만 별 의미가 없죠. 필요한건 "Count라는 변수만 모두 찾아내기"인데, 이런 의미 있는 작업은 시각적으로 잘 지원되지 않습니다.

조건문과 관련된 코드가 하나의 if 블럭 안에 들어 있기 때문에 코드를 단위로 묶어서 볼 수 있다는 점이 장점이라고 생각할 수도 있지만 아주 기괴한 언어가 아니라면 대부분의 프로그래밍 언어에서도 들여쓰기나 띄어쓰기를 통해 관련 코드 블럭을 시각적으로 묶어줄 수 있으므로 별 큰 차이가 없습니다(그런 의미에서 시각적 언어와 비시각적 언어를 가르는 경계는 모호합니다).

결국 어떤 시각적 질의를 잘 지원할 것인가(유사한 제어흐름을 갖는 코드블럭은 시각적으로 유사하다거나), 코드의 어떤 부분이 자동적으로 눈에 띄게(pop-out) 만들 것인가(대입문과 비교문이 확연히 달라보인다거나 등) 등을 좀 더 고민해보면 다양한 발전 가능성이 있지 않을까요.

에 또, 시각적 표현이 포함 관계(A가 B에 포함되어 있다), 관련성(A가 B에 연결되어 있다) 등을 보여주기엔 좋지만(이를테면 UML의 Class Diagram), 조건(if, but, maybe, perhaps)을 표현하기가 힘들다는 단점이 있습니다. 복잡한 로직이 들어가기 시작하면 언어적 표현이 따라오거나(UML의 주석이나 OCL), 애초에 언어적 표현은 그대로 남은채로 시각적 표현은 양념으로만 쓰이고 있었거나(Blocky를 보세요. 블럭을 몽땅 드러내도 정보가 거의 유지됩니다. 시각적 표현에 담긴 정보는 거의 redundent 하다는 것을 보여주죠). 하지만 이런 단점도 일부 해결할 수 있다고 생각합니다. 예를 들어 조건에 따른 분기를 정적인 포함관계로 변형한다거나 하는 식으로 의미에 대한 표상을 바꿀 수 있겠죠.

또, 문법과 의미론을 일치시키는 방향도 생각해볼만 합니다. 예를 들어 3+5 보다 xxx+xxxxx 등.

기타 등등 여러가지 가능성들이 있겠지만 일단 여기까지 끗. ^^;

저작자 표시
신고
< Newer     Older >

티스토리 툴바