neolith의 방
![[레벨:13]](http://old.lameproof.com/modules/point/icons/default/13.gif "포인트:16257point (43%), 레벨:13/30"){kind=icon}
neolith![[레벨:0]](http://old.lameproof.com/modules/point/icons/default/0.gif "포인트:0point (0%), 레벨:0/30"){kind=icon}
2SPEC: Significantly Prettier and Easier C++ Syntax
http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html
지원되는 컴파일러 혹은 c++ 로 컨버전해주는 툴 있으면 시도해볼만 할지도..
http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html
지원되는 컴파일러 혹은 c++ 로 컨버전해주는 툴 있으면 시도해볼만 할지도..
imcgames 의 김학규입니다
2008.02.10 14:30:46 (*.42.84.23)
꽤 그럴싸하긴 한데, 이렇게 문법을 싸그리 바꿔놓을 거면, 패러다임 자체를 바꿔서 functional language를 주류로 하는 변화를 시도하는게 나을 수도 있을 것 같네요. 제안한 문법을 보니 consistency를 유지하려고 한 때문이겠지만 굉장히 functional language의 폼과 많이 닮아 있는 것 같아서요.
2008.02.10 14:50:16 (*.29.235.123)
neolith functional language 의 형태를 갖고 있으면서 c++ 로 직접 매칭가능한 코드라는게 가장 큰 장점이겠죠. 요즘에 erlang 이나 lisp 같은 언어들 공부하면서 함수형 언어의 장점들이 조금씩 눈에 들어오네요.
2008.02.11 11:32:15 (*.233.209.91)
c++은 어차피 functional language가 아니니, 생긴 것만 바꾼다고 프로그래밍 방식이나 사고 방식 자체가 달라질거 같지는 않거든요. 문법을 새로 배워야 되니 혼란이 가중될 수도 있을 것 같고요. 개인적으로는 귀납적 추론의 수학적인 토대에서 확립된 lisp이나 ML, haskell 같은 언어를 좋아하는 터라 아예 패러다임 쉬프트가 일어나서 주류 언어 자체가 c++이나 java에서 고급 언어로 넘어 갔으면 좋겠네요.
2008.02.11 12:55:49 (*.36.230.142)
neolith 패러다임쉬프트는 이미 일어나고 있죠. CPU의 클럭속도가 높아지는 것이 한계에 다다르고, 클럭속도 증가 대신 코어 갯수의 증가로 대체되면서, 기존 주류 언어의 싱글쓰레드기반의 프로그래밍 방식에 비해 concurrency 적응이 이미 언어의 본질로 들어있는 함수형 언어들이 근래에 들어 각광받게 된것이니까요. erlang 이 가장 대표적 사례라고 할 수 있겠습니다.
2008.02.11 14:18:44 (*.233.209.91)
헐 erlang 은 다른 fuctional language랑은 다르게 spawn을 할 수 있네요. 고급 언어의 의미가 퇴색되는게 아닌가 싶은데 -_-. 기본적으로 functional language는 로직 구상이 주가 되어야 할 텐데, 저렇게 프로세스를 spawn 할 수 있게 해버리면 수학적 로직에만 집중하지 못하는 결과가 나올 수 있지 않을까 하는 걱정이네요. 아직 자세히 못살펴 봤으니 좀 더 살펴봐야 겠습니다.
2008.02.11 14:35:43 (*.36.230.142)
neolith 수학적 로직에 집중하는 것보다는 functional programming 의 장점을 활용해서, 만드는대로 저절로 concurrency 가 보장되는 환경을 만드는 것이 erlang 의 가장 큰 목표이자 장점이지요. argument matching 을 이용해서 로직을 간단하게 풀어내는 것도 볼만하고요
2008.02.11 14:38:57 (*.36.230.142)
neolith 고급언어의 정의가 딱 뭐라고 정할 수 있을지 모르겠지만, 하급언어에서 필요로 하는 반복적인 문구를 상위개념으로 추상화해서 기능을 제공해준다라고 봤을때 erlang 은 그 일을 충실하게 해줍니다. c++ 로 멀티 프로세스, 통신, 고가용성을 위한 라이브러리와 스크립트를 만들다보면 다다르게 되는 한가지(shared memory 와 explicit lock 을 피하다 보면 필연적으로 만나게 될) 결론 중 하나라고 볼 수 있겠죠
2008.02.11 14:51:06 (*.233.209.91)
lambda calculus와 수학적 귀납법에 기초를 둬서 예외를 인정하지 않는 다른 functional lanauges와 비교해 보면 오히려 루아나 파이썬 같은 스크립트 언어에 functional 을 추가한 듯한 느낌이네요. concurrency에 집중하고 있어서 그런지 모르겠지만, inter-process communication이나 네트워크에 특화되어 있지 않은가 하는 생각도 들고요. 공부해 볼만한 가치는 있는 것 같네요.
2008.02.11 17:52:34 (*.12.196.12)
![[레벨:2]](http://old.lameproof.com/modules/point/icons/default/2.gif "포인트:610point (55%), 레벨:2/30"){kind=icon}
지구정복 음..// 파이썬이나 루비같은 언어에 functional 요소가 추가된것이지, erlang같은 functional language에 그런 요소가 추가된거라고 보시면 안되죠;;; 주객이 전도된 느낌이랄까요... 멀티쓰레딩이 가능하다고 해서 FL의 장점이 사라진다고는 생각할 수 없죠;
2008.02.11 18:37:42 (*.78.64.79)
erlang이 처음부터 네트워크 스위칭 장비에 사용하기 위해 만든 언어라 process spawn이 가능한 FL형태를 띄게 된거 같은데, 완벽하지 않은 수학적 귀납법 사용이 가능한 ( 논리적 허점을 허용하는 ) erlang의 특징 자체가 다른 FL들 ( ML, Haskell, Scheme 등등 )과는 다르게 오히려 dynamic type binding만을 지원하는 스크립트 언어와 닮은 것 같다는 뜻이었습니다. 그리고 파이썬이나 루비의 프로그래밍 방식을 functional 이라고 부를 수 있는지도 의문이네요. functional은 없이 dynamic type binding 정도만 지원하니까요. ( 파이썬은 절차지향적 언어지만 functional 하게 '사용'할 수도 있는 것 같네요. 그치만 역시 태생은 functional이 아니죠. )
결론은, FL에 스크립트적인 요소가 추가된 것이든. 그 반대든, erlang은 정통 functional language와는 좀 다른 것 같다는거죠. 굳이 분류하자면, 스크립트와 정통 FL의 중간 정도. -_-
FL로는 로직의 작성은 굉장히 훌륭하게 해낼 수 있고, 논리적 허점이 없으면 프로그램 실행도 완벽히 보장되며 디버깅도 쉽다는 장점이 있지만, 너무 strict 하기 때문에 functional로는 모든 것을 다 표현하기에는 아직 한계가 있고, 저 수준을 FL을 이용해 제어하기에는 거의 불가능하기 때문에 적당히 중간자적인 입장을 취하고 있는 erlang이 나쁘지는 않을 것 같습니다.
결론은, FL에 스크립트적인 요소가 추가된 것이든. 그 반대든, erlang은 정통 functional language와는 좀 다른 것 같다는거죠. 굳이 분류하자면, 스크립트와 정통 FL의 중간 정도. -_-
FL로는 로직의 작성은 굉장히 훌륭하게 해낼 수 있고, 논리적 허점이 없으면 프로그램 실행도 완벽히 보장되며 디버깅도 쉽다는 장점이 있지만, 너무 strict 하기 때문에 functional로는 모든 것을 다 표현하기에는 아직 한계가 있고, 저 수준을 FL을 이용해 제어하기에는 거의 불가능하기 때문에 적당히 중간자적인 입장을 취하고 있는 erlang이 나쁘지는 않을 것 같습니다.
2008.02.11 20:22:40 (*.12.196.12)
지구정복 음..// 전 지금까지 Erlang을 위에 언급하신 ML, Haskell과 같이 pure functional language라고 생각해왔고, 제 주위의 다른 분들도 그렇게 생각하시는데요. 완벽하지 않은 수학적 귀납법 사용이 가능하다는것이 어떤 내용인지 궁금합니다. ^^; concurrent 개념때문이라면 concurrent Haskell이나 concurrent ML같은것도 같이 문제가 되는건가요?
2008.02.12 09:41:57 (*.233.209.91)
제가 의미한 완벽하지 않은 수학적 귀납법이라 함은
-module(tut2).
-export([convert/2]).
convert(M, inch) ->
M / 2.54;
convert(N, centimeter) ->
N * 2.54.
이런게 예제에 있네요. 제가 기억하기로는 ML이나 기타 등등에서 논리적 허점이 보이면 정의가 되지 않은 영역이 있다고 컴파일 자체가 되지 않았던 걸로 기억하는데.
erlang에서는
12> tut2:convert(3, miles).
** exception error: no function clause matching tut2:convert(3,miles)
컴파일 타임이 아니라 런타임에 에러를 내뱉내요. 컴파일타임에 비어있는 논리를 허용하는 면에서 완벽하지 않은 수학적 귀납법이라고 얘기를 했습니다. ML 같으면
convert( N, _ ) -> error
식의 문장을 더 추가해서 빈 논리를 채워줘야 했거든요. 물론 채워넣지 않으면 당연히 에러라고 정의해도 되고 erlang은 이걸 의도한 것 같지만 이렇게 되면 비어있는 논리가 사용자가 의도한 것인지 실수로 빼먹은 것인지를 알 수 없게 되잖아요. 모든 논리를 채워넣어야 하는 게 코딩 시간은 좀 더 걸리지만, 사용자의 의도를 명확히 전달할 수 있고, 이에 따라서 디버깅시간을 줄여준다는 측면에서 굉장히 좋은 방법이라고 생각했었거든요.
erlang을 잘 몰라서 하는 얘긴가요 ;ㅁ; FL을 잘 몰라서 하는 얘긴가요 ;ㅁ;
-module(tut2).
-export([convert/2]).
convert(M, inch) ->
M / 2.54;
convert(N, centimeter) ->
N * 2.54.
이런게 예제에 있네요. 제가 기억하기로는 ML이나 기타 등등에서 논리적 허점이 보이면 정의가 되지 않은 영역이 있다고 컴파일 자체가 되지 않았던 걸로 기억하는데.
erlang에서는
12> tut2:convert(3, miles).
** exception error: no function clause matching tut2:convert(3,miles)
컴파일 타임이 아니라 런타임에 에러를 내뱉내요. 컴파일타임에 비어있는 논리를 허용하는 면에서 완벽하지 않은 수학적 귀납법이라고 얘기를 했습니다. ML 같으면
convert( N, _ ) -> error
식의 문장을 더 추가해서 빈 논리를 채워줘야 했거든요. 물론 채워넣지 않으면 당연히 에러라고 정의해도 되고 erlang은 이걸 의도한 것 같지만 이렇게 되면 비어있는 논리가 사용자가 의도한 것인지 실수로 빼먹은 것인지를 알 수 없게 되잖아요. 모든 논리를 채워넣어야 하는 게 코딩 시간은 좀 더 걸리지만, 사용자의 의도를 명확히 전달할 수 있고, 이에 따라서 디버깅시간을 줄여준다는 측면에서 굉장히 좋은 방법이라고 생각했었거든요.
erlang을 잘 몰라서 하는 얘긴가요 ;ㅁ; FL을 잘 몰라서 하는 얘긴가요 ;ㅁ;
2008.02.12 12:29:18 (*.12.196.12)
지구정복 음// 아항. 의미의 혼동이 있으셨던것 같습니다. ^^; 말씀하신건 언어의 typing이 stric냐 dynamic이냐의 차이이구요. ML은 strict type 형식이므로 컴파일 타임에 에러를 낼 수 있는 겁니다. 그리고 위 사항은 C언어에 비유하면 case구분에서 default를 넣느냐 아니냐의 차이일 뿐이죠. 예외처리 구문을 통해서 해결 할 수 있습니다. 예외처리를 넣고 안넣고를 컴파일러나 그 옵션에 따라서 에러를 낼 수도 있고 안낼 수도 있는거죠. 그리고 제가 생각하는 수학적 귀납법의 진짜 의미는 X+Y=3일떄 X=1이면 Y=2임을 증명할 수 있느냐 아니냐의 차이 같습니다. 이게 가능하려면 single assignment가 지원되어야 하는데요. ML은 Haskell이나 Erlang과는 달리 이부분을 지원하지 않기 때문에 Pure Functional Language라고는 불릴 수 없습니다. 그래도 큰 의미의 FL에서는 모두다 FL이죠뭐... 엄격하게 따지면 Lisp도 FL이 아니라는 말도 있습니다;
2008.02.12 14:01:47 (*.233.209.91)
제가 중요하게 생각한 예외처리는 그냥 곁다리 같은 느낌이네요. 흠.. single assignment의 정의가 뭔지는 알았고 왜 쓰는지도 알았는데, ML이 single assignment가 지원되지 않는다는건 아직 잘 이해가 안되네요. (실제 적용이 어떻게 되는지를 이해 못하는 걸수도 -_-) erlang 이랑 비교해서 예제를 좀 들어주실 수 있나요?
2008.02.12 19:22:03 (*.12.196.12)
지구정복 음// 이해가 덜 되신듯 합니다. 수학문제를 생각해보세요. Y=X+1 이고 X가 1일때 Y의 값을 묻는 문제일때, 가정되는 것은 X에 1이 대입되었고, 절대 변하지 않는다는 것이죠. single assignment가 바로 이거에요. X에 1이 한번 딱 대입되는순간, 다시는 X에 다른 값이 들어갈 수 없다는겁니다. ML이나 Ocaml같은 경우를 보시면 변수에 값을 여러번 대입할 수가 있어요. 이런 상황을 side effect가 발생한다고 하고요. bug를 더 많이 만들고 디버깅을 어렵게 하는 요소입니다. 디버깅 하면서 변수값 tracing 해본 경험많죠? 이런 상황자체를 만들지 않는겁니다. 딴 이야기를 너무 많이 이어가는듯 하니 이 이야기는 여기까지하져 ^^;
2008.02.12 20:02:48 (*.233.209.91)
그냥 단순히 그거군요. x = 1, x = 2가 안된다는.. -_- 설명에 x0 =1, x1 = 2 식으로 표현해 놨길래 언어 내부적으로 처리해주는 건줄 알았는데 그런건 아닌가보네요. 좋은거 배우고 갑니다~
2008.02.13 11:43:25 (*.36.230.142)
neolith single assignment 는 맘먹고 짜면 c++ 에서도 구현을 할 수 있습니다. 방법은 클래스의 모든 멤버변수를 const 로 만드는거죠. 그럼 값을 어떻게 넣느냐 하면 copy constructor 나 = operator 를 통해서 넣는겁니다.
이렇게 짜면 불편하기만 하지 이득이 없지 않을까 싶은데, 그렇게 만든 클래스들은 쓰레드 안정성이 확실히 보장되거든요. 당연하죠. 값이 안 바뀌고 읽기만 하니까. 서로 다른 두개의 값이 필요하다면 두개의 인스턴스가 더 copy 되는 식이죠.
옛날에 single core 에서 프로그래밍을 할 때에는 최대한 copy 를 피하는 것이 최적화의 방법이었는데, 멀티코어에서는 쓰레드간 동기화때문에 성능에 대한 제약이 더 커지게 되면서 copy 가 생활화된 프로그래밍 방식이 오히려 더 효율적인 디자인이 되고 있습니다.
이렇게 짜면 불편하기만 하지 이득이 없지 않을까 싶은데, 그렇게 만든 클래스들은 쓰레드 안정성이 확실히 보장되거든요. 당연하죠. 값이 안 바뀌고 읽기만 하니까. 서로 다른 두개의 값이 필요하다면 두개의 인스턴스가 더 copy 되는 식이죠.
옛날에 single core 에서 프로그래밍을 할 때에는 최대한 copy 를 피하는 것이 최적화의 방법이었는데, 멀티코어에서는 쓰레드간 동기화때문에 성능에 대한 제약이 더 커지게 되면서 copy 가 생활화된 프로그래밍 방식이 오히려 더 효율적인 디자인이 되고 있습니다.
2008.02.13 11:49:43 (*.36.230.142)
neolith 그렇다면 루프 안에서 계속 값을 바꿔가면서 처리해야 할 일은 어떻게 하느냐? 라는 질문에는 재귀호출이 답입니다. 루프로 풀어져 있는 것에 비해 재귀호출을 하는 것은 더 효율이 떨어질 수도 있지만 tail-call 최적화를 하면 많이 보충이 가능합니다.
2008.02.13 14:11:00 (*.12.196.12)
지구정복 neolith// 이론적으로는 그래두 실제로 적용하라고 한다면 일반적인 c++ 코드에 비해서 코드량이 꽤나 증가할것 같습니다. 개념도 잘 안잡힐테구요. c++에서 재귀호출로 함수 몇번 만들다 보면 머리 터집니다. -_-;
2008.02.13 21:35:01 (*.36.230.142)
neolith 재귀호출을 어렵게 생각할 필요 없습니다. 어차피 패턴이 몇가지라서 그냥 손에 익을때까지 반복해서 문제를 풀어보면 숙달됩니다
맨처음 stl iterator 를 쓸 때도 이거 뭐 이렇게 복잡해 하다가도 익숙해지니까 그냥 쓰게 되던 것을 생각하면..
맨처음 stl iterator 를 쓸 때도 이거 뭐 이렇게 복잡해 하다가도 익숙해지니까 그냥 쓰게 되던 것을 생각하면..
![[레벨:1]](http://old.lameproof.com/modules/point/icons/default/1.gif "포인트:209point (44%), 레벨:1/30"){kind=icon}
코스모스