1. Clojure philosophy

The Clojure way

(엉터리 요약.. 2014.07.25, joony)

나중에 스터디가 끝날때 재번역하면 좋을것 같습니다

클로저는 완고한 언어 모든 패러다임을 커버하거나, 모든 기능을 제공하는 것은 아님 대신, 클로저의 방식으로 모든 종류의 실세계의 문제들을 해결하는데 필요한 기능을 제공

클로저에서 제일의 혜택을 얻으려면, 언어가 가진 비전과 동일한 비전을 가지고 코드를 작성하는 것이 좋음 기능 뿐 아니라, 왜 그게 제일 좋은지 책 나머지 부분에서 알게 될것. 그전에, 높은 수준의 철학적 토대에 대해 알아봅시다.

Figure 1.1 - 클로저의 기초가 되는 컨셉, 그것들이 어떻게 교차하는지. 클로저의 목적에 대해 앞으로 다룰 것

Simplicity (단순함)

• 복잡한 문제에 대해 간단한 해결법을 쓰기는 어렵다
• 경험 많은 프로그래머는 필요이상으로 복잡하게 만든다.(Moseley 2006)
• 클로저는 다양한 데이터 요구사항,
• 여러개의 동시 스레드, 독립적인 개발라이브러리 등의 부수적인 복잡함을 추가하지 않고, 복잡한 문제를 해결할 수 있게 도와줌
• 처음 보기엔 필수적으로 복잡해 보이는 것도 낮춰줄, 툴도 제공
• 클로저는 강력하고 단순한 추상화와 블록생성이라는 키 세트를 기반으로 함 (!todo)
• 기능들의 결과 집합이 항상 쉬워보이거나 익숙하지는 않을 것
• 하지만 이책을 읽으면서, 클로저가 복잡한 문제을 해결하는데 얼마나 도움을 주는지 알게 될 것
• 부수적인 복잡함의 예는, 클래스 정의, 상속, 타입선언의 계층을 통해 실행가능한 모든 코드 조각이 패키지되기를 요구하는 현대 객체지향언어들의 성향
• 클로저는 우수한 순수 함수들을 통해, 이 모든 것 사이로 길을 냅니다.
• (todo!)which takes a few arguments and produces a return value based solely on those arguments
• 클로저의 광대함은 함수로부터 내장된다. 모든 응용프로그램도 마찬가지(?) 문제를 해결할때, 덜 생각하게 도와준다.

Freedom to focus (자유에 중점)

• 코드를 작성하는 것은 때로, 혼란에 대한 지속적인 투쟁, 그리고 언어는 항상 우리에게 구문, 연산자 우선순위, 상송게층에 대해 생각하게 만듦 -> (문제를 악화시킴)
• 클로저는 가능하면 간단하게 하려는 유지하려는 우리의 방식에 대해 관여하지 않으려고 노력한다. 아이디어로 부터, 컴파일하고 실행하는 사이클을 요구하지 않는다. 타입선언을 하는 것을 요구하지 않는다.
• 매크로 / 언어 스스로를 정립할수있는(?) 툴을 제공한다. 그래서 단어,문법이 가능한 우리 문제에 맞게.
• 클로져는 풍부함
• 이해하는데에 (노력하는)희생 없이, 고차원의 문제들을 간단하게..
• 이 자유를 전달하는 하나의 키는 동적시스템에 대한 약속
• 심지어 프로그램이 실행되는 동안에도 클로저안의 정의된 모든 것은 모두 재정의 가능.: 함수, multimethods, 타입, 타입계층, 심지어 자바 메소드 구현.
• 생산된 시스템 위에서 그때 그때, 재정의하는 것이 무서울 수도 있지만, 프로그램을 작성하면서 생각하는 것에 놀라운 가능성의 세계가 펼쳐짐
• 친숙하지 않은 API에 대해 더 많은 실험과 탐구를 허용
• and it adds an element of fun that can sometimes be impeded by more static languages and long compilation cycles.
• 하지만, 클로저는 그냥 재미만 추구하는 것은 아니다.재미있는건 프로그래머에게 이제까지 상상했던 것보다 생산적이게 하는 힘을 줌으로써 생기는 부산물이다.

Empowerment (권한)

• 일부 프로그래밍 언어는 학계의 특정 문제를 해결하기 위해 또는 전산의 특정 이론을 탐구하기 위해 주로 만들어졌다.
• 클로저는 그런 부류는 아니다.
• Rich Hickey- 클로저는 재미있고, 유용한 어플리케이션을 구축할 수 있게한다고 많이 말해왔다.
• 이 목표를 제공하기 위해, 클로저는 작업이 이루어지기 위한 실용적 툴이되려 노력한다.

If a decision about some design point in Clojure had to weigh the trade-offs between the practical solution and a clever, fancy, or theoretically pure solution, usually the practical solution won out.

• 프로그래머와 라이브러리사이에서 이해가능한 API를 삽입함으로써 자바로 부터 보호(보장)해주려 노력함.
• 하지만 이것은 불편하게 서드파티 자바라이브러리를 사용하게 함
• 그래서 클로저는 다른 길을 간다. : direct, wrapper-free, 자바의 클래스와 메소드에 대해 같은 바이트코드를 컴파일.
• 클로저의 스트링은 자바의 스트링이고 ,클로저스크립트의 스트링은 자바스크립트 스트링이다.
• 클로저와 클로저 스크립트의 함수 호출은 원시적 메소드 호출이다
• 이것은 간단하고 직접적이고,실용적이다.
• Java 가상머신을 (JVM)사용하고 자바스크립트를대상으로 하는 결정은 실용성의 명확한 예이다.
• 예를 들어 JVM은 놀랍게 실용적인 플랫폼이다
  • 성숙하고 빠르고 널리 배포된다.
• 다양한 하드웨어와 OS를 지원하고, 막대한 라이브러리를 가진다. 클로저는 상자를 열자마자 바로 활용 가능한 장점을 다 갖는듯?
• 마찬가지로 자바스크립트를 대상으로 하는 클로저 스크립트는 브라우저, 서버, 모바일 디바이스, db 처리 스크립트까지..유비쿼터스에 가까운 장점을 같는다.
• 직접 메소드를 호출, 프록시, gen-class, gen-interface, 구체화,reify, definterface, deftype, and defrecord (see section 9.3)..와 함께, 클로저는 막대한 상호 운용의 옵션을 제공하기 위해 빡세게 일한다. 너의 작업을 끝내기 하려 도움을 주기위해.
• 실용적인 것은 클로저에서 중요하지만, 다른많은 언어들도 실용적이다.
• 뒤죽박죽을 피하능..

도메인 특성적인 언어가 아니라 강력한 언어.

Clarity (명료성)

When beetles battle beetles in a puddle paddle battle and the beetle battle puddle is a puddle in a bottle ... they call this a tweetle beetle bottle puddle paddle battle muddle. —Dr. Seuss2

python코드

# This is Python code
x = [5]
process(x)
x[0] = x[0] + 1

이코드를 실행한 후 x의 값은? process가 x의 값을 변경하지 않는다고 가정하면, 이것은 6이다. 하지만 어떻게 그런가정을 할까? process가 무엇을할지 정확히 알지 않고서는, 저 함수가 불렸을 때 확신할 수 없다.

심지어 process가 x의 값을 바꾸지 않는다고 확신했다하더라도, 멀티스레딩을 추가하면 다른 문제를 만난다. 일부 다른 쓰레드가 첫째줄과 셋째줄 사이에서 x값을 바꾼다면? 아직 나쁘진 않지만, 세번째 라인이 실행되는 중에 무언가가 x값을 정한다면 플랫폼이 atomic하게 변수에 값을 쓰는 것을 보장하는 것을 확신할 수 있나? 또는 다중 쓰기로 섞는것이 (?) 가능한가 우리는 명확성을 얻기위한 희망하며 생각을 지속할수 있다. 하지만, 명료해질수 없다는 결론은 같을 것이다.

클로저는 수많은 다른 종류의 복잡함을 피하는 툴을 제공함으로써 코드의 명료성을 위해 노력함 방금 코드의 경우는, 바꿀수 없고 지속가능한 콜렉션을 제공해서 싱글&멀티 스레드 이슈를 없앰 사용하는 언어가 서로다른 행위들을 하나의 구조체안에 합칠때,우리는 다른 복잡한 것들도 찾을 수 있다. 클로저는 concern 분리에 대한 경계를 늦추지 않고 이에 대항한다.

When things start off separated, it clarifies your thinking and allows you to recombine them only when and to the extent that doing so is useful for a particular problem.

표 1.1을 봅시다!

AOP

(Aspect Oriented Programming: AOP) : 관점분리 횡단 관심사 cross cutting concern / 횡적 코딩 공통괴는 건 함수로 뺄수 있지 추상클래스를 만들어서 동작을 뺌.

합쳐진 | 분리된 변경가능한 필드를 가진 오브젝트 | 동일한 값 메소드를 위한 네임스페이스로 행하는 클래스

생성, 기능에 대한거이 아니라 좀더 분리

Consistency(일관성)

클로저는 일관성을 제공하기위해 두가지 방법으로 동작한다. - 신택스와 데이터 구조

신택스의 데이터 구조의 일관성 : Clojure의 두 가지 구체적인 방법에 일관성을 제공하도록 작동한다. 구문의 일관성 관련 개념 사이의 형태의 유사성에 ​​관한 것입니다. 이 중 하나는 간단하지만 강력한 예제 및 doseq 매크로의 공유 구문입니다. doseq 사이드 생성하는 반면, 그들은 같은 일을위한 반환 게으른 서열을하지 않는 효과를 -하지만 모두 중첩 ITERA - 기, destructuring 같은 미니 언어를 지원하고 : 언제 : 경비원있다. Clojure의 코드의 다음 예를 비교하면 유사점이 눈에 띄는. 각 예제는 키워드 또는 B 중 하나, 5보다 작은 양의 홀수의 정수를 사용하여 형성 가능한 모든 쌍을 보여줍니다 첫 번째 예는 이해를 위해로 알려진 것을 사용하고 쌍의 데이터 구조를 반환합니다. :          (용 [X의 [A : B], Y (범위 5) : (홀수 Y)]            [X, Y])          ;; => ([: 1] [: 3] [: B 1] [: B 3])

두 번째 예는 쌍을 인쇄 할 doseq를 사용 (doseq [X의 [A : B], Y (범위 5) :시 (홀수 Y)]    (PRN의 x 및 y)) ; : 1 ; : 3 ; : B 1 ; : B 3 ;; => 전무 이 유사성의 값은 하나의 기본적인 두 경우 모두에 대한 구문뿐만 아니라, 필요한 경우 다른 한 형태의 특정 사용을 변환 할 수있는 용이성을 배울 필요가있다. 마찬가지로, 데이터 구조의 일관성은 가능한 한 서로 비슷한뿐만만큼 광범위하게 유용 가능한 그들을 만들기 위해 인터페이스를 제공하기 위해 지속적으로 Clojure의 컬렉션 유형 모두의 의도적 인 디자인이다. 이것은 고전 리스프의 확장 철학 "코드가 데이터입니다"입니다. Clojure의 데이터 구조는 단지 어플리케이션 데이터의 많은 양을 유지하기 위해 사용되는 것이 아니라 어플리케이션 자체의 표현 요소를 유지하도록. 그들은 destructuring 양식을 설명하는 다양한 내장 함수라는 옵션을 제공하는 데 사용하고 있습니다. 다른 객체 지향 언어는 응용 프로그램의 여러 종류의 데이터를 보유하기 위해 여러 호환되지 않는 클래스를 정의하기 위해 응용 프로그램을 권장 수 있습니다 경우, Clojure의 호환지도와 같은 개체의 사용을 권장합니다. 대용량 데이터를 저장, 애플리케이션 코드 및 애플리케이션 데이터 오브젝트 : 이것의 이점은 Clojure의 데이터 구조와 함께 작동하도록 설계된 함수의 동일한 세트가 모든 상황에 적용 할 수 있다는 것이다. 당신은이 앉아 있었던 isfy 그 특정 조건을 그 중 하나의 요소를 선택하는 그들을 통해 도보로 게으른 서열, 필터를 얻기 위해 이러한 유형의 서열을 구축하기로 사용할 수 있습니다. 당신은 어디에서나 사용할 수있는 모든 이러한 기능의 풍요 로움을 갖는 Java 또는 C + + 플리케이션의 개인 또는 주소 클래스 처리에 익숙해 져 일단 구속 느낄 것이다. 단순성, 초점 자유, 권한 부여, 일관성, 그리고 Clojure의 프로그래밍 언어의 명확성 - 거의 모든 요소는 이러한 목표를 촉진하기 위해 설계되었습니다. Clojure의 코드를 작성하는 경우 당신이 염두에 단순, 권한 부여, 손에 진짜 문제에 초점을 맞출 수있는 자유를 극대화하는 욕망을 유지하는 경우에, 우리는 당신이 Clojure의 당신에게 당신이 성공하는 데 필요한 도구를 제공 찾을 수 있습니다 생각합니다.

Why a(nother) Lisp?

Beauty

But what’s with all the parentheses?

Functional programming

A workable definition of functional programming

The implications of functional programming

Why Clojure isn’t especially object-oriented

Defining terms

Imperative “baked in”

OOP gives you, Clojure provides

Summary