프로그래밍 언어가 자연 언어처럼되어 가고 있습니까?


27

언어학의 맥락에서 프로그래밍 언어를 공부할 수 있습니까? 프로그래밍 언어는 자연 언어와 비슷한 방식으로 자연스럽게 진화합니까?

프로그래밍 언어에는 완전한 합리성과 수학적 일관성이 필수적이지만, 사람들이 읽기 쉽고 편안한 언어로 만들 필요가 있습니다 (특히 현대 언어).

프로그래밍 언어가 더욱 언어적이고 자연스럽게 발전하고 있습니까? 예를 들어 기계 코드, 펀치 카드 및 어셈블리 언어는 Ruby 및 Python 등과 같은 더 읽기 쉬운 언어에 적용되었습니다

컴퓨터 언어가 더욱 자연스럽게 변한다고 할 때, 더 많은 단어가 '영어로 된 단어'를 포함하고 있다는 의미는 아닙니다. 문법의 복잡성과 의미를 표현할 수있는 능력면에서 자연 언어와 비슷해 보이는 것 같습니다. (예를 들어, 합리적이고 사람이 이해할 수있는 방식으로 데이터베이스의 쿼리를 웅변 적으로 설명 할 수 있음).

당신은 어떻게 생각하세요? 프로그래밍 언어가 자연어처럼되어 언어학의 법칙에 적용되고 있습니까?

또는 언어는 스펙트럼에 살며 한쪽에는 극단적 인 합리적인 언어가 있고 다른쪽에는 더 창의적인 언어가 있습니다. 어쩌면 프로그래밍과 자연 언어는 동일하고 둘 다이 언어 스펙트럼에만 있습니다 (그들의 차이점 만, 아마도 그들이 의미를 부여하려는 '것'일 것입니다).

인간 언어와 컴퓨터 언어의 (바벨탑 효과) 분리 사이에 연결이 있습니까? 같은 이유로 더 다양해 지나요 (즉, 끊임없이 진화하는 컴퓨터 시스템 / 문화 시스템 등에서 다른 문제를 해결하기 위해)?


3
짧은 대답 : 예, 그렇습니다.

17
짧은 대답 : 아니요, 아닙니다.

이 질문은 메타에 대해 논의되고 있습니다.
Robert Harvey

3
컴퓨터 언어는 수학 표기법과 같이 간결함과 정확성으로 잘 작동하는 경향이 있으며, 지난 몇 천년 동안 자연어 (내가 알고있는)로 진화 할 특별한 성향은 보이지 않았습니다. 또한 당신이 생후 처음 몇 년간 하스켈에서 독점적으로 당신의 아기와 의사 소통을한다면 자연 언어를 유창하게 할 수있을 것입니다. 따라서 자연어와 컴퓨터 언어 사이에는 뚜렷한 대조가 있다고 생각합니다. 아마도 언어 구성 기술의 광범위한 확산은 시간이 지남에 따라 "자연"을 약간 개선했다고 생각합니다.

@ ryanOptini : C #, JavaScript, Python 또는 SQL이 자연어처럼 보입니까? 모두 영어의 키워드를 사용하지만 그 중 어느 것도 자연어 형식으로 수렴하지 않습니다. COBOL이 가장 근접했을 수도 있지만 많은 사람들이 COBOL을 그린 필드 프로젝트에 사용하고 있다고 생각하지 않습니다.
Jim G.

답변:


32

아니, 아니 프로그래밍 언어는“우리가 영어로 가지고있는 단어”( sic ) 라는 의미에서만 자연 언어와 비슷해 졌습니다.

프로그래밍 언어의 주요 특징은 모호하지 않다는 것입니다. 프로그램을 작성하고 실행할 때 잘 정의 된 의미를 가지며 동작입니다. 의도 한대로 작동하는 (어려운 목표) 프로그램을 작성하려면 가능한 한 프로그램의 동작 ¹을 예측할 수 있어야합니다. 프로그래밍 언어는 자연 언어와의 큰 차이에서 큰 차이를 만들지 않았습니다.

반대로 프로그래밍 언어와 동일한 도구를 사용하여 자연어를 분석하는 다른 측면과의 차이를 메우는 작업이 진행되었습니다. 이 필드를 자연어 처리 라고 합니다. 이러한 접근 방식은 머신 러닝 을 위해 거의 폐기되었습니다 . Wikipedia 기사 에서 다음 과 직접 관련된 관련 구절을 인용 하겠습니다.

1980 년대까지 대부분의 NLP 시스템은 복잡한 필기 규칙 세트를 기반으로했습니다. 그러나 1980 년대 후반부터 언어 처리를위한 기계 학습 알고리즘을 도입하여 NLP에 혁명이 일어났습니다. 이것은 무어의 법칙으로 인한 계산 능력의 꾸준한 증가와 언어학에 대한 촘스키 언 이론 (예 : 변환 문법)의 지배력이 점진적으로 축소 되었기 때문입니다. 언어 처리.

프로그래밍이 발전하는 한 가지 방법은 더 큰 시스템을 설계 할 때 소스 코드가 항상 시스템을 이해하는 좋은 방법은 아닙니다. 예를 들어, Intel CPU는 Man이 설계 한 가장 복잡한 개체 중 하나이며 "소스 코드"는 텍스트 파일의 모음이 아닙니다. 그러나 완전한 디자인은 인간의 언어와 유사한 것으로 발전하지 않습니다. 나는 적절한인지 도구 나 은유가 무엇인지 모른다. 아무도 아직 아무도 모른다고 생각한다. 몇 세기 후에 다시 묻습니다.

¹ 또는 발생할 수있는 상황에 주석이 달린 일련의 가능한 동작이 있지만 모델링에 한 단계의 간접적 인 단계 만 추가하기 때문에 여기에는 실제로 관련이 없습니다.


프로그래밍 언어와 유사한 "자연"언어를 만들려는 시도는 그다지 성공하지 못했다는 점은 주목할 가치가 있습니다. 가장 개발 된 예로 Lojban 을 참조하십시오 .
Dougal

CPU 아키텍처와 프로그래밍의 비교는 다소 어리석은 일이며, 하드웨어 설계는 2D 배치 및 라우팅 문제를 해결하기 위해 완전히 다른 문제가 있기 때문에 항상 텍스트 기반이 아닙니다. (하드웨어 디자인이 HDL을 사용하여 더 많은 텍스트 기반 디자인으로 이동하는 경우)
jk.

2

컴퓨터 언어는 수학 표기법과 같은 간결함과 정밀함을 유지하는 경향이 있으며, 지난 수 천년 동안 자연 언어 (내가 알고있는)로 진화 할 특별한 성향은 보이지 않았습니다.

또한 당신이 생후 처음 몇 년간 하스켈에서 독점적으로 당신의 아기와 의사 소통을한다면 그는 자연어를 유창하게 할 것이라고 의심합니다. 따라서 자연어와 컴퓨터 언어 사이에는 뚜렷한 대조가 있다고 생각합니다.

아마도 언어 구성 기술의 광범위한 확산은 시간이 지남에 따라 "자연"을 약간 개선했을 것입니다. 프로그래머가 자신에게 더 쉬운 것처럼 보이는 언어를 사용하여 "발로 투표"하고 언어를 만들 수있는 사람의 수가 더 많이 증가했기 때문에 실무자 및 더 나은 도구, 그러나 이것은 가장자리 주위에 작은 영향이며 프로그래밍 언어를 인간 언어로 근본적으로 변환하지 않습니다.


2

이 분야에서 흥미로운 사례 연구는 Perl vs Ruby (및 Python )입니다. Perl은 90 년대 초에 개발 된 스크립팅 언어로, 기존 Unix 기반 스크립팅 언어 (예 : bash)에 비해 많은 기능을 추가했습니다. 작가 Larry Wall 은 언어학에 대한 그의 배경이 일부 언어 기능에 영감을 주었다고 기록되어 있습니다.

그러나 Perl은 어색한 구문과 다양한 특수한 사례를 가지고 있으며, 모든 수준의 비판불러 일으키는 모든 미묘한 특질에서 언어를 영어와 다소 비슷하게 만듭니다 . 나중에 컴퓨터 과학자가 개발 한 Ruby 및 Python과 같은 스크립팅 언어는 구문의 일관성이 훨씬 뛰어납니다. 가장 큰 문제는 자연 언어가 많은 모호성을 가지고 있다는 것입니다 (언어학 분야에서 연구됩니다). 따라서 자연 언어는 Siri 와 같은 미래의 인간-컴퓨터 인터페이스에서 중요한 위치를 차지할 것이지만 이러한 인터페이스는 본질적으로 모호성 문제의 대상이 될 것입니다.

따라서 컴퓨터 언어의 진화가 자연어 개념에서 벗어난 경우 입니다. 또한 컴퓨터 프로그래밍 언어의 일반적인 역사는 모호성 을 제거 하기 위해 개발되고 변경되었다는 것입니다 (자연 언어에 고유함). 이것은 컴파일러의 역사 초기 (아마 1970 년대)에서 이해되지 않았으며, 예를 들어, 포트란 언어 의 초기 버전은 컴파일러 구현에 의존하는 모호한 의미를 가진 진술을 가졌다. 구문 분석과 관련된 CS 언어 이론 중 일부는 언어 구문 분석에서 모호함을 발견 한 것에 따라 부분적으로 개발되었습니다.


날짜가 잘못되었습니다. Perl은 1987 년에 출시되었고 1989 년에는 Bash가 출시되었습니다. 대문자 오류로 인해 게시물을 읽는 데 어려움을 겪고 있습니다.
tchrist

1

기계 언어는 매우 정확하지만 사람이 작성한 텍스트는 일반적으로 여러 가지 방식으로 해석 될 수 있습니다 (예 : 일부 시적 텍스트).

점점 더 진화 한 것은 패턴 일치입니다. 예를 들어 못생긴 코드를 작성할 때 컴파일러는 여러 가지 가능한 솔루션을 제안하고 경고 나 오류를 발생시켜 자신을 익히 게 도와줍니다. (예를 들어 일반적인 코드 패턴을 기반으로)

상호 작용 / 디자인 패턴에 대한 특정 연구가 있으며 T9 및 SWYPE조차도 많은 패턴을 인식하는 패턴 인식기입니다 (음성을 녹음하고 텍스트로 변환하는 프로그램도 패턴 인식기 임).

물론 프로그램은 정확한 메커니즘에 의존하는 것이므로 정확한 언어 (자연스럽지 않은)가 필요합니다 .Google에서 간단한 웹 검색은 매우 자연 스럽지만 단어를 몇 개 입력하면 원하는 것을 얻을 수 있습니다.

모든 다른 작업과 목표에는 고유 한 언어가 있습니다. 이는 단순한 "단일 언어 진화"가 아닙니다. 더 많은 언어가 있습니다. 정확한 작업에는 정확한 언어가 필요하고 편안한 작업에는 편안한 언어가 필요합니다

동일한 C 코드 조각을 작성한 다음 여러 다른 컴파일러로 컴파일 할 수 있으며 (컴파일러가 버그가 아닌 한) 다른 어셈블리가 생성 된 경우에도 코드 결과는 동일하지만 웹 검색의 경우 동일합니다 다른 검색 엔진에 대한 키워드는 다른 결과를 제공합니다.


1

몇 년 전 제 아들과 저는 다음 질문에 답하기 위해 평범한 영어 프로그래밍 및 개발 시스템을 개발했습니다.

  1. 컴파일러와 같은 저수준 프로그램을 영어와 같은 고급 언어로 편리하고 효율적으로 작성할 수 있습니까?

  2. 자연 언어를 상대적으로 "느슨한"방식으로 구문 분석하고 생산적인 프로그래밍을위한 안정적인 환경을 제공 할 수 있습니까?

  3. 자연어 생각을 다른 구문으로 번역 할 필요가 없을 때 프로그래밍하기가 더 쉬워 집니까?

이제 직접 경험을 통해이 세 가지 질문에 각각 "예"라고 대답 할 수 있습니다.

우리의 파서는 인간의 뇌와 같은 것으로 작동합니다. 치다. 아버지는 자기 아들에게 이렇게 말합니다.

"이 병을 빨고 싶니, 꼬마 야?"

그리고 그 아이는

"blah, blah, SUCK, blah, blah, BOTTLE, blah, blah."

그러나 그는 머리 오른쪽에 병의 "그림"이 왼쪽에있는 "병"이라는 단어에 연결되어 있고 목 뒤쪽에 이미 존재하는 "기술"이 "빨리"라는 용어. 다시 말해, 아이는 자신이 쌓은 그림 (유형) 및 기술 (일상)과 일치하고 나머지는 무시합니다. 우리의 컴파일러는 새로운 그림 (유형)과 기술 (루틴)을 우리가 아니라 프로그래머가 새로운 응용 프로그램 코드를 작성할 때 정의하는 것과 거의 같은 일을합니다.

일반적인 유형 정의는 다음과 같습니다.

다각형은 꼭짓점이있는 것입니다.

내부적으로 이름 "polygon"은 이제 이중 연결 정점 목록을 포함하는 동적으로 할당 된 구조 유형과 연결됩니다. "정점 (Vertex)"은 다른 방식으로 (이 정의 이전 또는 이후) 유사한 방식으로 정의됩니다. 복수는 자동적으로 이해된다.

일반적인 루틴은 다음과 같습니다.

x 좌표와 ay 좌표를 다각형에 추가하려면 : x와 y가 주어진 정점을 만듭니다. 정점을 다각형의 정점에 추가합니다.

매개 변수 및 변수에는 공식 이름 (적절한 명사)이 필요하지 않습니다. 우리는 이것이 중요한 통찰력이라고 생각합니다. 내 실제 의자와 테이블은 "정상적인 대화"에서 "c"또는 "myTable"이라고 결코 말하지 않습니다. 나는 단순히 "의자"와 "테이블"이라고합니다. 마찬가지로 "정점"과 "다각형"은 그런 것들의 자연스러운 이름입니다.

또한 공백은 "x coord"와 같이 변수 및 "names"변수에 허용됩니다. 이게 21 세기예요? 그리고 "닉네임"도 허용됩니다 (예 : "x coord"의 경우 "x"). 그리고 그 소유물 ( "폴리곤 정점")은 "레코드"내의 "필드"를 참조하기 위해 매우 자연스럽게 사용됩니다.

또한 우리가 조잡한 파싱이 이해하는 데 필요한 그림 (유형)과 기술 (일상)에 초점을 맞추고 무시하기 때문에 "주어진"이라는 단어는 "사용 중"또는 "함께"또는 이와 동등한 단어 일 수 있습니다. 가능한 나머지.

가장 낮은 수준의 상황은 다음과 같습니다.

다른 번호에 숫자를 추가하려면 : Intel $ 8B85080000008B008B9D0C0000000103.

이 경우 단일 루틴에서 영어 및 기계어 코드 (16 진수 임)는 가장 높은 언어와 가장 낮은 언어가 있습니다. 여기서 통찰력은 (일반적인 수학 서적과 마찬가지로) 프로그램은 주로 자연 언어로 작성되어야하며, 필요한 편리한 구문 (보다 편리한 구문)으로 적절한 스 니펫을 작성해야합니다.

www.osmosian.com/cal-3040.zip에서 개발 시스템을 구할 수 있습니다. 크기가 메가 바이트 미만인 작은 Windows 프로그램입니다. "documentation"디렉토리에서 PDF로 시작하는 경우 10 페이지를 가기 전에 전체 Shebang을 자체적으로 다시 컴파일합니다 (Walmart의 최하위 시스템에서 3 초 미만).

질문과 의견은 gerry.rzeppa@pobox.com으로 문의하십시오


tryo.ifi.uzh.ch/site/description controls english에 대해 알고 있습니까? 당신은 그와 Inform7 사이에 앉아있는 것 같다 en.wikipedia.org/wiki/Inform#Example_game_2
피트 Kirkham

나는 그 아이디어를 좋아하지만 여전히 뛰어 넘어야 할 구문이 여전히있는 것 같습니다. 예를 들어, 나나 기하학적 인 물건을 모델링하는 사람이 X와 Y 좌표를 따로 따로 추가한다고 생각하지 않기 때문에 "x 좌표와 y 좌표를 추가하려면 ..."은 정말 이상하게 들립니다. "x와 y가 주어진 정점을 만듭니다"와 마찬가지로. 거의 실제로 용서 읽고 있기 때문에 대부분 영어처럼,하지만 여전히 너무 엄격한 것 같다. 어쩌면 나는 인간처럼 생각하지 않는 데 너무 익숙 할 수도 있습니다.
cHao

1

인간 언어의 분리는 고립 된 공동체의 진화론에서 나온다. 프로그래밍 언어의 분리는 기술적 요구, 기술적 이데올로기, 기술적 및 이론적 이해의 변화, 구현할 기술적 능력의 변화에서 비롯됩니다. 다소 의식적인 과정이라고 생각합니다.

컴퓨터 언어가 자연 언어와 비슷할 수 있습니까? 아마도 어느 정도까지는 말입니다. 자연어 복잡성의 상당 부분은 새로운 동시성이 나타날 때 오래된 불일치가 점진적으로 제거 될 가능성이 있더라도 어느 시점에서든 일관된 결과를 생성 할 이유가없는 다양한 동시 진화 현상에서 비롯된 것으로 추측합니다. . 나는 반음 언어 전문가가 아닙니다. 그러나 우리는 프로그래밍 언어에서 이러한 종류의 복잡성을 원합니까?

모호성 문제는 중요한 문제이지만 대부분의 사람들이 언급 한 것은 아닙니다. 언어는 의사 소통의 수단이며, 그 의사 소통의 맥락에서 (사람-사람, 사람-기계, 장소 간 또는 시간 간, ... 간단하게 말하면) 분석되어야합니다. 중요한 것은 언어로 모호하지 않은 진술 만 할 수 있는지 여부가 아니라 의도 된 상황에서 의사 소통이 모호하지 않도록 항상 보장 할 수 있는지 여부입니다. 모호한 프로그램을 작성할 수있는 잘 알려져 있고 널리 사용되는 프로그래밍 언어가 있습니다 (물론,하지만 최신 버전은 한동안 보지 않았습니다). 이 경우, 컴파일러는 모호성을 감지하고 명확성을 요구할 정도로 똑똑하며, 모호성을 제거하기 위해 프로그램에 통합 될 수 있습니다. 모호성 감지가 가능한 선택 중 하나만 의미를 갖는다는 것을 의미하지는 않습니다. 문제는 통신 엔터티 중 하나가 모호성을 감지하여 보낸 사람이이를 명확하게 할 수 있는지 여부입니다. 인간은 이것에 좋지 않지만 컴퓨터는 꽤 좋을 수 있습니다.

형식주의와 프로그래밍 언어는보다 풍부하고 유연한 구문을 가질 수 있습니다. 나는 그들이하지 않는 주된 이유는 단순한 보수주의라고 믿는다. 사용 된 구문 도구는 여전히 그 당시 컴퓨터의 한계를 충족시키기 위해 30 년 이상 전에 설계된 도구입니다. 구문 분석 효율성은 더 이상 컴파일에서 중요한 문제가 아니며 더 강력한 기술이 다루기 어렵습니다.

흥미롭게도 프로그래밍 언어 구문에 가장 널리 사용되는 기초는 자연어 연구, 즉 문맥이없는 문법에서 비롯됩니다. 대부분의 기술 연구는 60 년대 초에 이론적 / 기술적 컴퓨터 과학으로 옮겨졌으며, 80 년대 초 자연 언어 사람들에 의해 다소 재발견되었습니다 (저는 단순화하고 있습니다). 그 이후로 자연 언어로 된 구문은 많은 진전이 이루어졌으며, 컴퓨터 과학은 구식 구문 도구와 크게 달라 붙어있는 것 같습니다. 자연어 진자는 이제 통계 기술로 다시 돌아가고 있지만 구문에 대한 대수적 접근법은 잊혀지지 않습니다. 대수 및 통계 기술의 조합에서 좋은 접근 방식이 올 것입니다.

내 느낌은 중요한 영역이 의미론이며 구문과 의미론 사이의 전환이라는 것입니다. 우리는 프로그래밍 언어와 공식 시스템의 경우 많은 정확한 기술을 가지고 있지만 자연 언어로 공식화하기는 여전히 어렵습니다. 게임이 자연 언어로 재생되는 것과는 거리가 멀기 때문에 향후 프로그래밍 언어에 어떤 영향을 줄 수 있는지 말하기는 어렵습니다.

또 다른 요점은 많은 프로그래밍 언어 설계자들이 무언가를 증명하거나 기술적 이념을 강요하려한다는 것입니다. 따라서 사용자는 의도 된 패러다임을 벗어나지 않도록 설계에 대한 규범을 익히 게됩니다. 이것은 불행히도 창의성에있어 매우 역효과를 낳습니다. 가장 독창적 인 언어는 최초의 Lisp (1958) 중 하나였습니다. 그것이 허용 한 자유와 유연성은 상당한 창의성의 원천이었습니다. 가격은 자기 훈련과 이해가 필요하다는 것이었다. 그러나 Lisp는 실제로 언어 생성을위한 언어 인 금속 언어였습니다.

이제 또 다른 관점을보기 위해 프로그램은 실제로 사양을 수학 진술로 본 증거입니다 (물론 다시 단순화하고 있습니다). 어떤 사람들은 (참고 문헌을 기억하지 못하고, 미안하지만) 이론가들과 함께 수학자가 자연어로 쓴 것처럼 보이는 증거를 만들어 내고있다. 따라서 자연어로 작성된 것처럼 보이는 프로그램을 갖는 아이디어는 완전히 터무니없는 것 같지 않습니다.

그러나 수학자가 비공식적으로 쓰더라도 수학 담론은 평범한 이야기 ​​나 역사 책과는 상당히 다르다는 것을 알 수 있습니다. 이것은 논의되는 의미 론적 영역 인 담론의 우주에서 상당한 차이로 인한 것이다. 따라서 자연어처럼 보이는 프로그래밍 언어를 구상 할 수 있지만 담론의 영역과 바람직한 특성이 자연스럽게 제한됩니다. 대부분 본질적으로 피상적, 즉 대부분 구문론으로 남아있을 것입니다. 수학자는 공식 시스템과 정치에 대해 이야기 할 수 있습니다. 두 담화가 비슷하게 보이지 않기를 바랍니다. 컴퓨터는 아직 정치에 대해 이야기하거나 이해할 수 없습니다. 그들이하는 날은 더 이상 프로그래밍이되지 않을 것입니다.

역사를 되돌아 보면, 고급 언어는 처음부터 (FORTRAN) 계산 작업을 표현하기 위해보다 자연스러운 형태에 더 가까워지려는 시도 였지만, 이러한 작업은 수학적 또는 논리적으로 이해되었습니다 (Fortran 1957, Algol 1958, Lisp 1958). ) 또는 더 비즈니스 지향적입니다 (Cobol 1959). 10 년 안에 사람들은 문제에 더 가까이 다가가는 언어에 대해 걱정했고 extensible languages구문과 의미를 모두 다루는 소위 중요한 연구가있었습니다 . 보다 자연스럽게 문제를 표현하는 한 가지 주요 경로는 object orientation(때로는 다른 이름으로) 의 등장이었습니다 . 부모를 할당하는 것은 항상 어려운 일이지만, 아마도 인공 지능에 관한 연구, 주로 Lisp와 언어에서 나왔을 것입니다.Simula 67(알골 가족) 그 자체는 컴퓨터에서 시뮬레이트되어야하는 더 자연스럽고 실제적인 문제를 표현하기위한 것입니다. 모든 것이 역사적으로 일관된 것처럼 보입니다.


0

묻는 질문이 비슷하다는 점에서 비슷하지만 복잡성 측면에서 상당히 다릅니다. 가장 큰 차이점은 자연어는 본질적으로 모호합니다 (단어 수준에서도). 단어가 무엇을 의미하는지 명확하지 않습니까? 그러나 프로그래밍 언어의 세계에서는 다양한 정의 장치가 폐기되고 있습니다. 자연어 파싱 문법과 프로그래밍 언어 파싱 문법을 보면 크기의 차이가 놀랍습니다. 문제는 프로그래밍 언어의 문법이 공식적인 시스템이라는 것입니다. 그래서 그들은 수학적 분석을 할 수 있습니다. 모호성을 다루는 것은 프로그래밍 언어 대응의 솔루션이 사소하거나 단순 할 수있는 많은 문제를 일으킨다.

컴퓨터 과학자와 "자연"사람들 사이의 격차가 줄어들면 자연어와 프로그래밍 언어 사이의 간격이 줄어들 것입니다.


0

지난 몇 년 동안 Haskell, 다양한 스크립팅 언어, C #, Java, 심지어 C ++ (오버로드에 대한 생각) 등 다양한 언어로 (E) DSL유창한 인터페이스에 대한 관심 이 꾸준히 증가하고 있습니다. operator<<출력을 위해).

어느 정도까지는 코드를보다 자연스럽게 읽을 수 있습니다. 그루비에서 EDSL 예제로 설명하겠습니다. groovy.time의 패키지를 작성하는 방법을 수 있습니다

use ( TimeCategory ) {
    // application on numbers:
    println 1.minute.from.now
    println 10.days.ago

    // application on dates
    def someDate = new Date()
    println someDate - 3.months 
}

당신은을 통해이 작업을 수행하는 경우 java.util.Calendar의 클래스 첫 번째 예를 들어 이런 식으로 뭔가를 작성해야합니다 :

void demo() {
    Calendar date = new GregorianCalendar();
    date.add(Calendar.MINUTE, 1);
    System.out.println(date);
}

0

컴퓨터 언어 (오래 전의 초보적인 기계 언어) 주로 동료 인간과 의사 소통하기위한 인간 언어이며 인간에 의해 정의되며 기계에 명령을 전달하기 위해 2 차적으로 만 사용됩니다. 따라서 "자연"언어가 진화하는 방식과 거의 같은 방식으로 발전합니다 (예 : 좋아하는 언어에 대한 "이디엄"을 찾아 C가 K & R C에서 현재 ISO-C 2011로 어떻게 진화했는지 확인하십시오. 그러나 다른 환경에 존재합니다. 정확한 의미를 전달해야합니다 (컴퓨터는 여전히 이해하기 어렵고 컴퓨터를 이해하기에는 너무 멍청합니다). 처리 용이성에 대한 프리미엄이 있습니다 (따라서 C ++, PL / 1 또는 APL의 문법과 어휘가 훨씬 단순함) 예를 들어 영어는 자연어가 다소 단순합니다).

수학이나 과학의 형식주의, 심지어 청사진 (다른 것들과는 달리 1D가 아닌 본질적으로 2D)에 대해서도 마찬가지입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.