값지향(value-oriented)과 객체지향(object-oriented)라는 용어는 프로그래밍 언어와 프로그래밍 스타일을 모두 설명하는데 사용됩니다.

이 논문에서는 값과 객체의 차이점을 명확히 밝히고, 적절히 구분하는 것이 프로그램 복잡성을 극복하는데 도움이 될 수 있다고 주장한다.

첫번째 섹션은 값이 업데이트, 공유, 인스턴화 라는 개념이 의미가 없는 시대를 초월한 추상화에 해당한다는 것을 보여준다.

두번째 섹션은 객체가 시간 내에 존재하는 것이며 생성,소멸,복사,공유 및 업데이트가 가능하다는 것을 보여준다.

세번째 섹션은 프로그래밍 언어에서 이러한 개념을 적절히 구분하면 함수형 프로그래밍에서 상태의 역할과 같은 문제를 명확히 할 수 있다고 주장한다.

마지막으로 프로그램 구성(program organization)을 위한 도구로서 값/객체(value/object)를 구분하여 사용하는 것에 대해 논의하며 마무리한다.

값은 적용가능하다(Values are applicative).

value-oriented는 application programming(wiki에 따르면 applicative programming language는 arguments를 적용할 수 있는 functions 로 만들어지는 프로그램을 말한다. applicative langues는 functional하며 종종 applicative는 functional과 동의어로 사용된다. applicative language의 semantics 는 beta reduction을 기반으로 하며, 사이드 이펙트와 상태변경이 허용되지 않는 것을 의미한다.) 에서 자주 사용된다.

이는 assignment(할당)이나 다른 imperative facility(명령형 편의기능)을 쓰지 않고 순수 표현식(pure expression) 만을 사용하는 것을 말한다.

이러한 프로그래밍의 장점은 간단한 대수적 표현식들을 이용할 수 있다는 이점이 있다. 즉, 표현식을 구성하는 구성요소들을 이해하면 표현식을 이해할 수 있고,

하위 표현식의 의미가 문맥과 무관하다 (이는 실행 중에 표현식을 그 표현식의 값으로 대체해도 프로그램의 동작에 영향을 미치지 않는다는 것이다. 모든 함수가 대수처럼 순수함수로 이루어져있기 때문에 외부상태에 의존하지 않고, 외부 상태를 변경하지도 않는다),

표현식의 구문에서 분명 표현식 부분간의 간단한 인터페이가 있다는 점 때문이다.

즉, 값을 표현하는 표현식의 각 부분은 다른 모든 부분과 독립적이다. 그 이유 중 하나는 값의 읽기 전용, 즉 해당 구성 요소를 업데이트할 수 없기 때문이다. 값을 ㅂ녀경할 수 없으므로 공유하는 것이 항상 안전하다. 즉, 참조 투명성을 나타내므로 한 표현식이 다른 표현식에서 사용하는 것을 변경할 위험이 전혀 없다.

모든 공유는 프로그래머에게 숨겨져 있으며, 보다 효율적인 스토리지 활용을 위해 시스템에 의해 수행된다.

값이란 정확히 무엇일까요? 값의 가장 좋은 예는 정수, 실수, 복소수와 같은 수학적 실체이므로 이러한 수학적 실체를 더 잘 이해하면 값을 더 잘 이해할 수 있습니다.

수학적 실체의 특징 중 하나는 이것들은 시간을 초월한다는 의미로서 영원적이다.(One characteristic of mathematical entities is that they are atemporal, in the literal sense of being timeless.) 다시 말해, 시간이나 지속 시간이라는 개념은 이런 수학적 실체에는 적용되지 않는다. 마치 이런 수학적 실체에 색상이라는 개념을 적용해보려는 시도처럼. 우리가 2 + 3을 쓸 때 5가 방금 생겨났고 2와 3이 소비되었다는 의미를 가지지 않는다.

숫자에 이러한 속성(시간을 초월하는 속성)을 부여하는 것은 무엇인가?

값은 추상화이다. 수학적 실체와 다른 값에 속성을 부여하는 근본적인 사실(fact)은 그들이 추상화(보편 혹은 개념)라는 것이다. 수학적 실체에 대한 자세한 설명은 이 백서의 범위를 벗어나지만, 숫자 2가 모든 특정 쌍(pair)를 포괄하는 추상화는 확실하다. 추상화의 이런 보편적 특성은 영원적(atemporal), 즉 시대를 초월하는 것으로 만든다. 사실, 일반적인 의미에서 존재라는 개념은 숫자 2에 적용되지 않는다(??!!) 모든 값은 추상화에 해당하기 때문에 모든 값도 마찬가지다. 그렇기에 이것들을 생성하거나 파괴할 수 없다.

추상화, 즉 값은 불변이라는 것도 마찬가지다. 값을 연산할 수는 있지만, 값을 다른 값과 연관시킨다는 프로그래밍 언어에서 x에 값2를 할당하고(x := 2) 나중에 x에 1을 더하면(x := x +1) 값인 숫자는 변경되지 않는가? 아니다 숫자 2는 그대로 유지된다. 우리가 변경한 것은 'x' 라는 이름이 가리키는 숫자이다.

값에 이름을 붙일 수도 있고 값에 붙인 이름을 변경할 수도 있지만 값은 변경되지 않는다.

값은 계산할 수 없습니다. 값의 '복사본'과 같은 것은 존재하지 않는다는 것입니다. 수학에서 이 2 또는 저 2라고 말하는 것은 의미가 없으며, 단지 2가 있을 뿐입니다. 즉, 숫자 2는 그 값에 의해 고유하게 결정됩니다. 왜냐하면 추상화는 그것이 포함하는 것들에 의해 고유하게 결정되기 때문에 가능한 모든 쌍을 포함하는 모든 것이 추상화 2입니다. 따라서 추상화에는 '수'라는 개념이 적용되지 않으며, 2가 몇 개인지 묻는 것은 의미가 없습니다. 프로그래밍 언어에서 값의 다른 복사본을 만드는 것은 무의미하며, 그런 것은 존재하지 않습니다. 또한 값은 불변이므로 그러한 복사본을 만들 이유도 없습니다. (물론 값의 표현을 복사하는 것은 가능하지만 이에 대해서는 나중에 설명합니다.)

값의 공유에 대해 이야기하는 것도 무의미합니다. 값은 불변이고 계산할 수 없으며 복사할 수 없기 때문에 서로 다른 프로그램 세그먼트가 같은 값을 공유하든, 다른 '값의 복사본'을 공유하든 상관없습니다. 물론 구현상 차이가 있을 수 있습니다. 긴 문자열 값을 변수에 할당하는 경우 새 복사본을 만들어야 하는지 아니면 원본 복사본에 대한 포인터를 저장할 수 있는지 여부에 따라 큰 차이가 있습니다. 이는 구현상 중요한 문제이기는 하지만 값의 의미와는 무관합니다.

값은 추상화를 모델링하는 데 사용됩니다. 지금까지 값의 여러 가지 특성에 대해 논의했지만 프로그래밍 언어에 값을 포함해야 하는지, 포함한다면 어떤 용도로 사용해야 하는지에 대해서는 논의하지 않았습니다. 이 질문에 대한 답은 앞서 설명한 값과 추상화 사이의 관계에 있습니다. 값은 추상화에 해당하는 프로그래밍 언어입니다. 따라서 값은 풀어야 할 문제에서 추상화를 모델링하는 데 사용할 때 가장 효과적입니다.

실제로 정수 및 실수 데이터 값은 정수 및 실수로 표현되는 양을 모델링하는데 사용되기 때문에 이것이 일반적인 용도로 사용됩니다. 마찬가지로 추상화 '색상'은 파스칼 또는 Ada 열거형(빨간색, 파란색, 녹색)의 값으로 모델링할 수 있습니다.

반면에 복소수나 수열과 같은 복합 데이터 값을 값으로 처리하는 것은 일반적이지 않습니다. 이렇게 하면 무의식적으로 공유되는 데이터 구조를 업데이트하는 오류의 한가지 원인을 제거할 수 있습니다[3].

데이터 흐름 기계나 함수형 프로그래밍 언어와 같은 값 지향 언어에는 값만 있습니다. 객체가 전혀 필요하지 않을까요? 이 질문에 대한 답은 다음 섹션에서 확인할 수 있습니다.

computing can be viewed as simulation(컴퓨팅은 시뮬레이션이라고 바라볼 수 있습니다.) 라는 말이 있습니다. [4] 이는 어떤 물리적 상황을 명시적으로 시뮬레이션하거나 모델링하는 프로그램의 경우 분명한 사실입니다. 이 은유는 다른 많은 상황으로 확장될 수 있습니다.

직원 데이터베이스를 생각해 보겠습니다. 데이터베이스의 각 레코드는 직원 한 명에 해당합니다. 이 데이터베이스는 기업의 일부 측면에 대한 시뮬레이션 또는 모델이라고 할 수 있습니다. 마찬가지로 운영 체제의 데이터 구조는 현실 세계의 일부 객체의 상태를 반영하는 경우가 많습니다. 예를 들어, 테이프 드라이브가 되감기 중이거나 패리티(parity) 오류 상태에 있다는 사실을 반영할 수 있습니다. 또한 데이터 구조는 테이프 드라이브가 시스템의 특정 작업에 할당되었다는 사실과 같은 논리적 상황을 반영할 수도 있습니다.

각 엔티티마다 데이터 구조가 필요합니다. (a data structure is needed for each entity) 시뮬레이션할 각 엔티티에 해당하는 데이터 구조가 있으면 관련 정보를 고려하고 캡슐화하기 때문에 시뮬레이션이 단순화됩니다. 이것이 바로 스몰토크와 같은 객체 지향 프로그래밍 언어에서 사용되는 접근 방식이다.

이런 언어에서 프로그램을 구조화하는 일반적인 방법은 모델링 중인 시스템의 각 엔티티에 대한 객체를 생성하는 것이다. 이러한 엔티티는 현실 세계의 객체일 수도 있고 디스플레이 화면의 그림과 같이 애플리케이션에만 존재하는 객체일 수도 있다. 이러한 객체가 응답하는 메시지는 해당 실제 객체에 대해 수행할 수 있는 관련 조작일 뿐이다.

객체란 무엇인가요? 프로그래밍 환경에는 객체가 있고 현실 세계에도 객체가 있습니다. 그렇다면 객체란 무엇일까요? 이 질문에 답하려고 하면 우리는 곧바로 오래된 철학적 문제에 빠져들게 됩니다.

특히 무엇이 하나의 물체를 다른 물체와 다르게 만드는가? 이 질문에 대한 한 가지 철학적 대답은 두 물체가 형태는 같지만 실체는 다르다고 말하는 것입니다. (while the two objects have the same form, they have different substance.) 좀 더 구체적으로 말하자면, 두 물체는 공간의 다른 영역을 차지한다는 점을 제외하면 모든 면에서 비슷하다고 말할 수 있습니다. (we could say that the two objects are alike in every way except that they occupy different regions of space.)

프로그래밍 언어에서도 똑같은 상황이 발생할 수 있습니다. 정확히 동일한 값을 포함하는 두 개의 배열 변수가 있지만 두 변수는 서로 다른 변수일 수 있습니다. 무엇이 다를까요? 서로 다른 위치를 차지하기 때문입니다. 비유하자면, 배열 변수의 형식은 요소의 순서와 값이지만 그 실체는 변수가 차지하는 메모리 영역입니다.

객체는 인스턴스화될 수 있습니다. 현실 세계의 객체를 구별하는 덜 철학적인 방법도 있는데, 바로 고유 이름을 부여하는 것입니다. 프로그래밍 언어에서도 이와 정확히 유사한 상황을 발견할 수 있습니다. 앞서 언급한 배열 변수와 같은 프로그래밍 객체에는 일반적으로 객체에 대한 참조라는 고유한 이름이 있습니다.

이는 일반적으로 객체가 차지하는 저장소 영역과 밀접한 관련이 있습니다. 그러나 파일 시스템을 생각해보면 알 수 있듯이 반드시 그럴 필요는 없습니다. 파일은 객체라는 것을 쉽게 알 수 있으며, 동일한 내용을 가진 두 개의 서로 다른 파일이 있는 것은 매우 정상입니다.

물론 파일을 구분하려면 파일에 고유한 이름이 있어야 합니다. 여기서는 객체를 구별하는 데 사용되는 식별 요소가 어떤 것이든, 그것이 어떤 형태의 고유 식별(예: 기능)이든, 아니면 점유하는 저장 영역에 내재되어 있든 크게 신경 쓰지 않고, 동일한 데이터 값을 포함하더라도 각 객체는 다른 모든 객체와 다르다고 가정하겠습니다.

일반적으로 객체의 고유성은 외부 관계에 의해 결정되며 내부 관계 및 속성과는 독립적이라고 말할 수 있습니다. 이는 내부 관계 및 속성에 의해 완전히 결정되는 값과 반대되는 개념입니다(예: 집합은 요소에 의해 완전히 결정됨). 따라서 동일한 객체의 인스턴스가 얼마든지 존재할 수 있습니다. 이는 여러 가지 추가적인 결과로 이어집니다.

객체는 변경될 수 있습니다. 앞서 객체의 정체성은 내부 속성이나 속성과 무관하다고 말씀드렸습니다. 예를들어 배열 변수의 모든 요소가 변경되더라도 동일한 스토리지 영역을 차지하므로 여전히 동일한 변수입니다. 물론 이는 실제 객체와 마찬가지로 객체도 변경할 수 있고 그 정체성을 유지할 수 있습니다. 반면에 값은 절대 변할 수 없습니다.

예를들어 1 + 2i에 5를 더하면 1 + 2i는 변하지 않고 6 + 2i 라는 다른 값이 계산됩니다. 이러한 변경 가능성, 즉 한 객체가 한 가지 속성 집합을 가질 수 있고 다른 속성 집합을 가질 수 있다는 사실은 객체(및 프로그램)의 고유한 특징입니다.

객체에는 상태가 있습니다. 이러한 객체의 변화 가능성은 특정 시점에 객체의 내부 속성과 속성의 총합인 객체의 상태라는 개념으로 이어집니다. 따라서 우리는 물체의 상태가 시간에 따라 바뀔 수 있다고 말할 수 있습니다. 물론 상태는 컴퓨터 과학의 핵심 개념이므로 객체가 컴퓨터 과학의 핵심이라는 것은 놀라운 일이 아닙니다. 객체의 상태가 시간에 따라 변할 수 있기 때문에 객체가 '시간 내에' 존재한다는 것, 즉 값처럼 시간적이지 않다는 것은 분명합니다.

객체는 생성되고 소멸될 수 있습니다. 객체가 시간적이지 않다는 사실은 객체가 생성되고 소멸될 수 있다는 결론으로 이어집니다. 이는 프로그래밍 언어에서 익숙한 개념으로, 예를 들어 특정 블록이 입력될 때마다 변수가 생성되고 종료될 때마다 소멸될 수 있습니다. 또한 많은 언어에서 객체를 생성, 소멸하는 명시적 수단을 제공합니다(파스칼의 new, dispose). 값은 영원적이기(atemporal) 때문에 생성 또는 소멸에 대해 말하는 것은 의미가 없습니다.

객체는 공유할 수 있습니다. 동일한 객체의 인스턴스가 얼마든지 존재할 수 있고 객체의 속성이 시간에 따라 변경될 수 있기 때문에 객체의 공유 여부는 매우 중요한 문제이다. 한 공유자가 객체를 변경하면 다른 공유자가 이를 볼 수 있기 때문이다. 이러한 부작용은 프로그래밍에서 흔히 발생하며, 프로그래머들의 의사소통의 수단으로 자주 사용한다. 사람들도 공유 객체의 의사소통의 수단으로 자주 사용한다. 예를 들어, 두 사람이 칠판의 상태를 변경하여 의사소통을 할 수 있다.