C/C++언어가 널리 쓰이는 이유는?
글쓴이: noblepylon / 작성시간: 화, 2008/07/22 - 10:42오전
우리가 사용하는 프로그램의 거의 대부분이 C/C++언어로 만들어집니다. 오피스, 브라우저, 게임, 수치해석, 커널 등등 C/C++언어가 쓰이는 분야가 정말 다양합니다. 한 예로 파이어폭스, 오픈오피스, 리눅스 커널 모두 C/C++언어로 되어 있지요.
저는 C/C++언어가 프로그래밍계의 '먼치킨'에 거의 근접했다고 생각합니다.
여러 분야에서 고루고루 뛰어난 팔방미인이라고 해야 하나요?
제가 생각하는 C/C++의 장점은
- 저급 기능에서 고급 기능까지
- 여러가지 프로그래밍 패러다임 지원
(절차적 프로그래밍, 객체지향적 프로그래밍, 제네릭 프로그래밍, 템플릿 메타 프로그래밍)
- 풍부한 내부 및 외부 라이브러리
- 그럭저럭 뛰어난 성능
그래서 제가 궁금한 것은,
1. 제가 모르는 C/C++의 단점이 어떤것이 있을까요? 다른 언어가 C/C++에 비해 뛰어난 분야에는 어떤 것이 있을까요?
2. C/C++가 다양한 분야에서 널리쓰이는 이유에는 또 어떤것이 있을까요?
Forums:
언급하신 C/C++의
언급하신 C/C++의 장점은 C/C++이라고 묶어 말할것도 안됩니다.
- 여러가지 프로그래밍 패러다임 지원
(절차적 프로그래밍, 객체지향적 프로그래밍, 제네릭 프로그래밍, 템플릿 메타 프로그래밍)
이건 뭐 말할것도 없이 C++에만 해당하는 얘기구요.
- 그럭저럭 뛰어난 성능
아마도 C++이 C에 비해 느리다는 생각에 '그럭저럭'이라고 하신거 같은데, 차라리 위의 것과 묶어서 C++은 C와 따로 생각하는게 좋겠죠.
게다가 이미 시작부터 C++이 널리 쓰인다고 정해버리고, 왜 널리쓰이느냐고 하셨는데, 생각만큼 C++은 널리쓰이고 있지 않습니다.
C야 부동의 1위라고 할만하지만, C++같은 경우는 (기준에 따라 다르겠지만)언어순위에서 자바에게 밀리는 경우도 많습니다.
데스크탑용 어플리케이션이야 C++이 많지만, 서버로 들어가면 자바가 압도적으로 많으니까요.
이래저래 C/C++이라고 묶어 말하기엔 무리가 있을듯합니다. 장점 나열하신걸 보면 C++에 관심이 있으신거 같은데, 주제를 C++의 활용등으로 바꿔보심이 어떨까요?
뭐 논란이
뭐 논란이 있겠지만,
2006년부터는 JAVA 가 1위를 탈환하여 계속 자리를 지키고 있습니다.
C는 임베디드에서 일반 CPU ( 자바 VM 이나 chip 이 이식되기 힘든 곳 ) 에게 일반성을 거의 절대적으로 보장하기 때문에 그 설자리를 잃는 일은 없을것이라고 생각합니다.
C++ 은 제가 일하는 게임분야에선 아직까지는 '절대자'의 자리에 군림하고 있습니다. JAVA가 이제 슬금슬금 파고 들고 있는 형국이지요.
즉 C의 부동의 1위 자리는 이미 사라진것 같습니다...
40년간 그래도 군림해왔었으니 부동의 1위였긴 했지요....
Neogeo - Future is Now.
Neogeo - Future is Now.
낮은 표현력이 있겠죠.
1.
-> 낮은 표현력
-> 높은 진입장벽(C++)
2.
-> 이미 자바가 C/C++을 넘어셨죠,
그래도 하나 들어보자면 역시 퍼포먼스겠죠. 속도는 언제나 중요하니까요.
C/C++둘을 같은 것으로 보시면 안됩니다. 엄연히 분야가 다르니까요.
C는 유닉스같은
C는 유닉스같은 운영체제 등의 시스템 프로그램을 C로 많이 짜 놓아서 많이 쓰는 거고, C++는 C를 불러 쓰기가 아주 편하기 때문에 (원래 그걸 노리고 만든 거죠) 많이 쓰는 겁니다.
C++의 단점은 C언어와의 호환성을 고려했다는 겁니다. 그게 많이 쓰이게 된 배경이 되는 장점이기도 하지만 동시에 매우 치명적인 단점입니다. 자동 메모리 관리도 안되고, 동강난 메모리 때문에 죽을 위험에 항상 노출되어 있죠.
그리고 C 건 C++ 이건 Java 건 간에 물건 중심 언어들은 태생적으로 메모리에 뭘 덮어쓴다는 저급한 기계 중심의 설계를 했다는 근본적인 단점을 갖고 있습니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
메모리 단편화
동강난 메모리가 메모리 단편화 문제를 언급하신거라는 가정하에...
메모리 단편화 문제를 근본적으로 피해갈 수 있는 언어가 존재 하기는 하는 겁니까? 전 상당히 궁금하군요.
그리고 메모리 단편화 때문에 죽지는 않지요(한참 느리게 돌아갈 지언정.. 혹은 할당이 실질적으론 가능한데도 할당이 불가능하다고 할 사태가 있다고 상상은 됩니다만 이건 일상적 위험과는 굉장히 거리가 멉니다. VM 단위수준이 할당 불가를 뱉을 정도로 메모리를 덩어리와 조각을 번갈아 쓰는 케이스는 아직까지 거의 겪어보지 못했습니다. )
차라리 메모리의 잘못된 참조나 사용에 의한 버그 양산의 가능성이 매우 높아서 죽을 위험에 노출 되어 있는 것이지요.
C++ 의 boost 같은 녀석은 그래서 mem pool 과 shared pointer 등등을 사용해 이러한것을 피해보려고 하고 실질적으로 많은 성과를 이루었다고 생각합니다만...
메모리에 뭘 덮어쓴다는 기계중심의 설계는 폰 노인만 아키텍쳐 상태의 컴퓨터에선 피하기 어려운 것 아닙니까? 언어가 높은 추상화 위에 이를 피했다고해도,
어차피 바닥레벨에선 결국 같은 일을 할 수 밖에 없으니까요.
왠지 C/C++ 만의 문제가 아닌걸 C/C++ 만의 문제로 치부한 경향이 있는거 같아서 글을 남깁니다.
Neogeo - Future is Now.
Neogeo - Future is Now.
동강난 메모리란
동강난 메모리란 dangling pointer 를 말한 것입니다.
물건 중심 언어라도 자동 메모리 관리만 잘 하면 메모리 헛다리 짚는 건 피할 수 있죠.
형식언어 설계와 기계의 구현은 별개의 문제입니다.
고급언어는 기계에 얽매인 설계를 할 필요가 없습니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
동강난이라길래
동강난이라길래 두동강나다 처럼 조각이 나뉘다 라는 의미로 해석했습니다. 죄송합니다.
이런것에 대한 표준 용어도 정립이 제대로 되어야 할텐데 하는 생각이 듭니다.
혹은 이미 있었다면 -ㅅ- ... 공부를 좀 더 해야겠군요.
현대에서 기계에 얽매인 설계를 전혀 고민할 필요없이 완벽하게 추상화가 된 언어가 있나 궁금하군요.
제가 학부에서 배울땐 적어도 아무리 함수형언어던 뭐던간에라도 결국은 컴파일러로 기계어로 바뀌는 것이고 이러한 컴파일링 , 변환하는 것에 대한 언어 자체의 표준이 있는한,
"수학적으로 똑같은 표현이 제각기 다른 성능을 도출 할 수 있다" 라는 명제를 궁극적으로 피할 수 없다고 생각하는데...
"어떻게 짜던 수학적으로 같은 형태이면 성능은 빠르게 혹은 그 언어가 낼 수 있는 최대한의 속도를 항상 보장한다"
이러한 명제가 성립된다면 C/C++ 같은 기계레벨을 직접 알아야 성능을 꾸릴 수 있는 언어는 도태되는것이 옳다는 결론이 나오겠지요.
그런게 정말로 가능한것인지 궁금합니다.
( 컴파일러 문제만 하더라도 이론상으로는 NPC 문제이기 때문에, 이를 추상화로 아무리 덮어도 현대의 폰노인만 아키텍쳐에 대해서는 결국 C/C++ 의 문제를
가린것이지 피한것은 아니라고 보입니다. )
실질적으로 함수형 언어는 현대 컴퓨터에서는 완벽하게 구현이 되기도 힘든걸로 알구요. ( 컴파일러 라고 말 붙이는 것도 좀 요상하지만, 제대로 된 컴파일러가 없다지요.. )
고급언어는 기계에 얽매인 설계를 할 필요가 없다는 이야기는 어떻게 해석을 해야하는가 궁금합니다.
예를 든 명제는 이미 다 정복이 되고 이론적으로 검증이 된것입니까?
Neogeo - Future is Now.
Neogeo - Future is Now.
공부를 조금 더
공부를 조금 더 하셔야겠습니다.
"완벽한" 추상화는 아니더라도 폰 노이만 구조를 의식하지 않아도 되는 언어는 많습니다.
속도나 성능은 추상과는 관계없습니다. 현재 상태에서 굳이 따지자면 반비례에 가깝습니다.
고급 언어는 사람이 쓰기 쉬워서 프로그램을 빨리 만들 수 있는 도구이지, 기계가 쓰기 쉽도록 빠른 코드를 제공하는 언어가 아닙니다.
예를 든 명제가 무엇인지는 모르겠지만, 함수형 언어 등은 지금도 수많은 사람들이 많은 분야에서 아무런 문제없이 쓰고 있고, 앞으로도 그럴 겁니다.
------------------------------
How many legs does a dog have?
------------------------------
How many legs does a dog have?
논지가 정확하지
논지가 정확하지 않아 다시 수정합니다.
우선 하신말씀은 '함수형 언어 같은 언어에서는 폰노인만 아키텍쳐를 몰라도 된다 -> 성능에 중요한 프로그래밍을 할 때 이야기는 다른 언어를 쓰면 되니까' 라는 의미로 해석이 됩니다.
제가 겪었던 문제는 똑같은 함수형 언어 ( 예를 들어 헤스켈 )를 사용한 두 프로그램이 수학적으로는 완전히 동치이지만, 속도의 차이를 낸다던가 할 때
이 차이가 나는 이유라던가, recursive 의 값이 무한정 커질때 프로그램이 뻗는다던가 ( haskell 은 언어적으로는 stack call 이 없다고 추상화 하지만 내부적으로는 사용한다고 알 고 있습니다. ) 왜 tail call 이 좋은지, laziness add 가 왜 나쁜지 를 이해하기 위해 기계구조를 공부할 필요가 없느냐라는게 제 의문의 근본입니다.
프로그램이란 것은 결국 속도를 아예 배제하고 살 수는 없다고 생각합니다.( 그건 언어의 상업적 이용이 아닌 이론적 이용일 뿐이라고 생각합니다. )
함수형언어의 추상화바탕으로 프로그래머가 완벽하게 기계구조를 파악할 필요가 없다고 가정하고 언어를 사용하려 했을때 저같은 필드에서 일하는 사람은
수학수식적으로 같은 녀석이 결국 왜 속도차이가 나나 근본적으로 파고들지 않을수가 없습니다.
결국 이녀석을 돌리는 기계가 폰노인만 구조니까 이런이런경우 속도차이가 나는구나 라고 공부를 안할 방법이 없다는 것이죠. ( 실행속도 뿐만아니라 굉장히 큰 녀석을 돌릴때 recursive 가 엄청나게 들어가면 뻗는 이유라던가.. 오래걸려서라도 수식적으로는 가능해야 하죠. )
애초에 C 언어를 쓰는게 차라리 더 저급하게 이유를 파악하기엔 훨씬 쉬웠다는 결론을 얻었습니다 스스로.
아무리 헤스켈을 쓰거나 Lisp , 얼랭 등을 공부해봐도 저 근본적 문제는 해결이 불가능하다고 생각합니다.
그래서 위와같은 이야기를 한 것입니다.
포인터 때문에 모든게 문제가 생겨났다고 주장하지만, 결국 폰노인만 구조에서는 어쨌거나 저급한 녀석을 공부하지 않고는 필드에서 살아갈 수 없으니까요
전 C/C++ 이 많이 쓰이는 이유는, 차라리 저급한 녀석을 더 공부하게 만든게 오히려 상업적으로는 개발이나 구현이 더 명확하다는 이유때문이라고 생각합니다.
즉 언어가 숨기려 하는 부분이 많으면 많을수록 이해할 수 없는 결과를 얻을 수 있는 확률이 높으니까요.
차라리 어떤 코드가 왜 안도는가 연구가 많이된 C/C++ 같은 녀석이 상업적 표준으로 굉장히 많이 쓰이는 이유가 결국은 저급한 기계의 한계를 아무리 추상화 해도
발목을 잡히기 때문이랄까요...
헤스켈이나 Lisp 보다 더 완벽하게 구현되어 함수형 언어의 모든 능력을 펼칠 수 있다! 라고 할만한 언어가 따로 있다면 공부해보고 싶습니다.
Neogeo - Future is Now.
이야기를 듣고보니
이야기를 듣고보니 공부를 더 하셔야하는 게 아니라 마음가짐부터 바꾸셔야할 것 같습니다. 성능이 중요하다는 전제를 깔아놓고 보면 네오지오님이 하고자 하는 말은 틀리지 않습니다. 하지만 상황에 따라서 성능이 중요하다는 전제는 언제든지 바뀔 수 있습니다. 이 전제를 깨트리지 않으시면 저나 다른 분들이 드리는 글에서 배우실 게 없을 겁니다.
이런 저런 곁가지 말이 많지만, 그냥 단순하게 말하자면, 성능에 밀접한 프로그래밍을 한다면 하드웨어에 맞춰서 프로그래밍을 해야하므로 당연히 저급언어를 선택하면 되는 것이고, 성능보다는 사용성에 초점을 맞춘 유틸리티나 어플리케이션이라면 사람에 맞춰서 프로그래밍 해야하므로 고급언어가 유리하다는 걸 말하는 것 뿐입니다. 둘 다 필요하다면 언어를 섞어서 쓰면 되는 문제입니다. 추상에 대해서 확실히 이해를 하고 계시다면 이런 설명 조차도 필요없겠지요.
그리고 확실히 잘못이해하고 계신 부분을 말씀드리자면, 함수형 언어나 논리형 언어는 그 자체로 증명 가능하기 때문에 이해할 수 없는 결과가 나올리가 없고, 숨겨진 부분이 폰 노이만 언어보다 더 복잡할 이유도 없습니다. 그저 폰 노이만이 아닌 가상 기계위에서 돌아가는 차이점 밖에는 없습니다. 그리고, tail recursion의 순수한 메모리 사용량은 while과 다르지 않습니다. 단순히 tail recursion만 보자면 while보다 성능이 나쁘게 나올 이유도 없습니다.
일단 함수형 언어나 논리형 언어에 대해서 공부를 해야겠다는 마음이 드신다면 공부를 더 하시기를 권합니다. 그럴 마음이 없다면 그냥 공부를 안하셨으면 합니다. 괜히 공부해서 나쁜 편견만 생길듯 하네요.
------------------------------
How many legs does a dog have?
------------------------------
How many legs does a dog have?
역시 제가 바라보는
역시 제가 바라보는 관점은 함수형 언어를 사용하거나 배우기엔 무리였군요..
사실 처음 접근한 의도도 AI 프로그래밍에 매우 편리하고 좋으며 확장성 , 생산성이 끝내준다 였습니다.
MMO GAME 들의 이슈도 결국 유저를 계속 붙잡으려면 몬스터들의 AI를 지속적으로 발전시키거나 추가해주어야 한다로 귀결되기 때문에, ( 물론 더 많은 내용이 추가 되어야 하지만 .. )
LISP 같은 녀석으로 AI를 빠른시간안에 추가시켜보자라는게 목표였습니다.
다만 이 AI 는 서버환경에서 multi thread 로 돌기에 언젠간 성능이 주요 issue 가 되기도 하지요. 애초에 성능을 바라면서 이러한 언어를 접근한 패러다임 자체가 실수군요. ( 그렇다고 함수형 언어가 느리다! 는 아닙니다. 속도를 빠르게 하려면 결국 C 언어가 하는 짓과 비슷하게 가상 머신이 돌아가는 원리와 기계 원리를 이해해야 한다는 의미입니다. )
개발하는 입장에서는
- 디버깅 ( -_- 어떻게 할지 제일 궁금합니다. step by step 으로 값을 꺼내볼 변수 자체가 없어버리니 -ㅅ-, 라지만 디버깅 할 필요도 없이 간단하게 버그가 (거의) 없는 코드작성이 가능하다는 패러다임에서 사고하면 또 무의미하기도 하군요. )
- 성능차가 나거나 뻗을 경우 그 원인과 대책
- 자체적으로 성능을 높이는 법 ( 언어의 스펙을 넘어서서 )
이런게 사실 중요하다보니..
애초에 쓰레드를 연 이유가 고도의 추상화 언어에서도 결국 하드웨어 특성을 공부해야한다고 주장하고 싶었습니다만, 패러다임 자체를 다르게 접근해야 한다면 제 주장은 이미 의미조차 없는 이야기 였던것 같습니다.
여하튼 좋은 이야기는 감사하고, 애초에 편견은 없었습니다. 다만 위의 문제를 겪었을 때 결국은 C 언어랑 다른점이 무어냐. 하드웨어에 대해 모른다고 다 되지 않느냐 였을뿐, 제가 의도한 용도로 사용하지 말아야 한다는 점을 제대로 배웠습니다 :)
Neogeo - Future is Now.
Neogeo - Future is Now.
절차형(비함수형)
절차형(비함수형) 언어에 너무 익숙하신듯합니다... ^^;
반박이라고 하기엔 좀 그렇고, 아는 것들을 대충 써봅니다.
디버거는 요즘은 다들 내장하고 있는듯합니다. 그리고 REPL을 활용해서 프로그래밍하면, 디버거 이용안하고 간단히 코드 조각을 실행해봄으로써 자연스럽게 테스트를 자주 하게 됩니다. 또한, call stack을 덤프해서 어떤 순서로, 어떤 인자로 불렸는지 확인가능합니다.
성능차이는 요즘은 많이 줄어든 것으로 압니다. 공개 lisp(SBCL등)이라도 설치해서 디스어셈블한 코드를 보시면 대충 감이 잡히실겁니다.
성능 높이는 법은 프로파일링입니다. 고성능의 프로파일러로 면밀한 프로파일링 후에 최적화를 수행합니다.
또한 뻗는 경우는, 어디에서나 생길 가능성이 있지않을까요? 제1원인은 프로그래밍 미숙이라고 보입니다만 그래도 만약에 그런 경우가 생긴다면, run time에 함수 본체를 재작성해서 컴파일해주면 그 다음 진입부터는 제대로 돕니다. 인공위성을 REPL을 이용 디버깅한 사례도 있고요.
한마디만 더 하자면,
erlang은 함수형언어라서(!) 멀티코어/멀티프로세서 환경에 적합하게 최적화할 수 있다고 합니다.
공유 객체가 (거의) 없습니다. 프로세스 간에는 모든 것을 message passing으로 해결합니다.
current programming을 하는데는 아주 이상적인 구조라고 보입니다.
erlang으로 구축된 프로젝트들 중에는 9가 아홉개인(99.9999999%) 가동율(?)을 자랑하는 무슨 교환기쪽 프로젝트가 있습니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
Erlang은
Erlang은 오픈소스화되었기 때문에 다른 회사에서도 씁니다. 대표적으로 아마존도 높은 서비스 가동률을 위해위해 Erlang을 사용하는 것으로 알고 있습니다.
그리고 계속되는 논의로 거슬러 올라가자면, C가 숨겨진 게 없다 이런 이야에 대해서는 특히나 요즘같은 세상에선 약간 황당하다고밖에 할 수 없는데요, 얼마 전에 슬래시닷에 gcc 의 최적화 옵션 및 최적화 단계 등을 인공지능 기법을 이용해서 (아마도 머신 러닝이었던 걸로 기억합니다) 많이 향상시켰다는 기사까지 났습니다. C도 어셈블리로 일대일 대응이 되는 것은 아니고 컴파일러 최적화 여지가 많고, 그것도 사람이 조정하는 게 너무 복잡해서 인공지능 기법을 이용해야 충분히 최적화가 된다는 이야기입니다. 얼마 전에도 KLDP에 올라온 이야기입니다만, 포트란 컴파일러가 아직까지도 수치해석에서 C보다 다중 루프가 빠르게 컴파일된다고 하는데, 이게 포트란 언어가 C보다 더 기계에 가까워서 그런 겁니까? 기계랑 가깝다. 그런 걸 따지려면 그냥 0과 1만 있는 키보드로 코딩을 해야 할 겁니다. 그리고 기계랑 가깝다는 것이 반드시 효율이랑 직결되지 않고 컴파일러 최적화를 얼마나 열심히 구현했느냐의 정도에 따라 달라집니다.
그리고 이론 쪽 논문을 찾아보시면 아시겠지만, 재미있는 것은 명령 중심 언어로 코딩했을 때 함수 중심 언어보다 이론적으로 더 적은 시간이나 공간을 사용하는 문제가 있다는 것은 알려져 있었는데 누군가 반대로 함수 중심 언어로 코딩했을 때 명령 중심 언어로 했을 때 시간이나 공간을 더 적게 차지하는 문제들도 있다는 연구 결과를 냈습니다. 그러니 절차형 언어가 근본적으로 모든 문제에 효율적이라는 생각은 확실히 잘못된 것입니다. 이건 이미 이론적으로 증명된 연구결과입니다.
덧붙여, tail call 이 좋은지, laziness add 가 왜 나쁜지 를 이해하기 위해 기계구조를 공부할 필요는 "전혀" 없습니다. 손으로 식의 줄임(reduction) 과정 혹은 다시쓰기(rewriting) 과정을 유도해 보면 그 중간식의 길이를 보면서 알 수 있습니다. 이런 단순한 문제를 놓고 메모리나 스택 레지스터를 생각한다는 것은 우리가 너무 기계환경에 오염(?)되어 있지 않은가 생각합니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
뭔가 내용을
뭔가 내용을 곡해하시는 군요 위의 글 어디를 봐도 C 가 숨겨진게 없다 라고 한적은 없습니다만... C 보다 다른 함수형 언어가 더 추상화가 되었다는 의도를 다르게 해석하신듯 합니다. 따라서 황당하시다는 이유조차 잘 모르겠습니다. 이 논의는 C가 다른 언어보다 빠르다를 주장하는 내용이 아닙니다. 최적화 이야기는 더더욱 아닙니다. 다만 고도의 추상화된 언어라면 기계에 대해 전혀 몰라도 된다라는 의견을 믿기 힘들어서 논의를 꺼낸겁니다.
컴파일러의 최적화에 따라 성능차가 난다고 하셨는데... 컴파일러의 최적화는 다시 기계의 구조를 모르고는 절대 일어날 수 없습니다.
포트란 예제는 논의와 전혀 관계도 없고, 추상화가 프로그램을 느리게 한다라고 구체적으로 언급한적도 없습니다. 추상화의 개념은 어딘가 오류( 혹은 이론적으로 이해가 갈 수 없는 행동)가 있을 수 있고 그 오류를 메꾸려면 다시 기계를 들여다 봐야 하므로 결국 기계 공부를 해야한다는게 제 논리입니다.
( 또한 널리,오래 쓰인 언어일수록 최적화의 기법이 더욱 많이 연구되었기때문에 저같은 사람은 자료 구하기도 쉽고 공부하기도 오히려 쉽다는 것입니다. )
결국 헤스켈이라는 언어를 현대의 머신 위에 구상,구현 실행,최적화하기 위해 기계를 공부해야한다는 것을 피할 수 없다는걸 다시 한번 드러내는것이지요. ( 다른 함수형 언어도 마찬가지 일것으로 생각합니다. )
그것은 언어를 구현하는 사람의 몫이지 언어를 사용하는 사람은 전혀 관계없다! 라고 주장하시진 않을 것이라고 생각합니다.
사용하는 가상머신이 어떻게 구현되고 최적화되는가를 몰라서는 프로그래밍은 그저 수학 수식일 뿐이지요.
덧붙여 함수형 언어의 가상머신은 무슨 언어로 작성하는가도 궁금합니다.
http://functional.or.kr/haskell/stack-overflow
언급 하신 내용에 비추어 이 내용을 stack 머신에 대한 이해가 전혀 없이 100% 이해가능하다면 정말 놀라운이야기 입니다. 저는 다른 방법을 잘 모르겠군요.
단순히 쓰기 과정을 유도해서 알아낼 수 있다니 놀랍습니다. 다만 이러한 사고 방식을 오염(?)으로 표현하실 필요는 없다고 생각합니다. 다른 방식으로 세상을 이해하는 시선도 얼마든지 있고 그것을 상호 이해해야하니까요.
제 생각은 딱 그렇습니다.
컴공에서 기계의 원리를 배우는 것은 우리가 물리나 화학에서 원자 구조( 혹은 더 안의 구조)를 공부하는 이유와 같다고 생각합니다.
결국 깊게 들어가면 그 내용을 모르고선 재료 화학이니 유기 화학이니 하는것은 사상누각에 불과하게 된다는 생각입니다.
고도의 추상화를 통해 더 높은 발전의 토대도 당연히 훨씬 중요합니다. 그러나 추상화에 만에하나 오류가 생겼을때, 이해할 수 없는 행동이 생겼을때에는
기계의 내부를 들여다 보지 않고 무슨 방법으로 그 오류를 해결하며 정정할 것입니까? 이론만으로 해결되는 경우도 물론 있겠지요. 아닌 경우는 없다고 100% 보장이 되는 것입니까?
여하튼 현대의 컴퓨터로 구현된 녀석들에서 전혀 기계공부 없이 프로그램만 생각하면 된다라는 의견은 아직은 저에겐 공허한 메아리로 여겨집니다.
모르겠습니다. 이론을 학부까지만 공부한 저의 한계일런지도요.
Neogeo - Future is Now.
Neogeo - Future is Now.
인용: 추상화의
전적으로 동의합니다. 결국에 추상화란 우리가 해야할일의 일부 또는 전체를 black box 화하고
interface를 제공함으로써 복잡성을 탈피하는 개념이고 지금까지 컴퓨터 사이언스에서 너무나도 많이
쓰여왔습니다. 그래서 CS에서는 Layer 를 추가하면 해결할 수 없는 일이 없다는 말까지 나온거겠죠.
중요한건 항상 새로운 Abstraction이 추가될때마다 Performance Customizing이 이슈화 되어왔고,
현재도 이 흐름(ex: Multi-core programming 의 추세)은 계속되고 있습니다.
Customizing을 하려면 당연히 Black 안을 봐야하고 컴퓨터는 결국
Abstraction interface가 아니라 CPU Instruction Set으로 동작합니다.
Dig it.
Dig it.
논의에 약간 벗어난
논의에 약간 벗어난 부분이 있는데
디버깅을 위해 디스어셈블이라면 결국 기계를 다시 공부해야한다는 모순이 아닙니까?
디버깅 까지는 추상화가 되지는 못 한 겁니까?
call stack을 dump 한다는건 결국 stack 구조를 이해하지 않고는 왜 저렇게 구현이 되었나는 알기 힘들다는 것입니까? ( 메모리가 쌓이는지 아닌지.. )
그렇다는건 임예진님의 기계를 공부하지 않아도 된다라는 말과 대치되는 이야기 같습니다만...
결국 사용하려면 저급한 내용을 꺼내보아야 하는 수 밖에 없는것인가가 궁금했습니다.
역시 다른 방법은 특별히 없나 보군요.
Neogeo - Future is Now.
Neogeo - Future is Now.
어디에 디버깅을 위해 디스어셈블해야 한다는 이야기가 있죠?
아마 M.W.Park님의 글 중에 성능차이에 대한 단락에서 '디스어셈블'이란 단어가 나오는 것을 말하는 것인가요?
Source 수준의 debugging이 C에서도 가능한데 함수형 언어에서 불가능할리가 없죠.
디스어셈블해보라는 말은 함수형 언어로 제작하고 compile할 때 얼마나 효율적으로 기계어로 변환되었는지
알기 위해 디스어셈블해서 보라는 뜻으로 보입니다.
Stack 구조를 기계 위에서만 이해할 수 있다고 보는 것은 너무 기계에 묶인 사고 방식이 아닐런지요.
함수형 언어에서도 분명 자료구조가 있습니다.
호출 stack을 dump한다고 GDB같은 것을 상상하신다면 동상이몽이라고 할 수 있습니다.
Game programming을 하시는 것 같은데 game 쪽도 최근 고급언어의 바람이 불고 있지 않습니까?
전부는 아니더라도 미래의 game programming의 대세가 과연 C/C++일지는 의문입니다.
제 답변을 대신
제 답변을 대신 써주셨군요.
감사 ^^;
위의 neogeo님의 글에 답변으로 단 '디스어셈블'이라는 단어를 포함한 제 글은 neogeo님의 글에서 '-'로 표기된 항목들에 대응되는 제 생각을 순서대로 단락으로 나누어 쓴 글입니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
성능(performace)이나저
성능(performace)이나저급 언어, 고급 언어에 대한 말씀은 동감합니다. 그런데 "숨겨진 부분(?)"에 대해서는 조금 생각이 다릅니다.
전형적인 예이므로 이미 알고 계실 거 같지만,
http://en.wikibooks.org/wiki/Haskell/Performance_Introduction#Space
이 예에 대해서는 어떻게 생각하실지 궁금합니다. haskell 이 메모리 사용에 대해 특별히 뭘 숨기고 있는 것은 아니지만, lazy evaluation 을 하는 경우에 메모리 사용에 대해서 C 같은 녀석과는 다른 방식으로 신경을 써야할 필요가 있는 것은 사실인 것 같습니다. 별 신경 안쓰고 프로그램을 짤 때 lazy evaluation 이 필요 없는 메모리 사용을 억제해주는 경우가 많지만, 위의 간단한 예를 이해하기 위해서도 haskell 의 "추상적" 계산(evaluation) 방식을 알고 있는 것과는 별도로 그 밑에 있는(말하자면 semmal 님께서 가상 기계라고 표현하신) 것의 구조 또는 폰 노이만 컴퓨터에 대한 이해가 필요합니다. 언어가 추상적으로 노이만 컴퓨터와 다른 계산 모델을 가지고 있더라도, 프로그래머가 "폰 노이만 컴퓨터의 구조를 의식하지 않아도 되는" 것은 아니라고 생각합니다.
그리고, semmal 님 말투를 흉내내서 쓰자면, "말하는 법을 좀 배우셔야겠습니다." 토론을 시작하자마자 다짜고짜 상대를 무시하는 듯한 언어를 사용하시니 보기에 안좋습니다. 굳이 문장들을 예로 들어가면서 말씀드릴 필요는 없겠지요.
누군가를
누군가를 깔아뭉게려고 그랬던건 아닙니다만, 제가 뭐라고 해봤자 변명으로 밖에 들리지 않을 것 같군요.
제 글을 보고 기분이 나쁘셨다면 사과드리겠습니다.
다만 내용에 대해서만 덧 하겠습니다.
Haskell을 쓰면서 성능을 신경쓴다면 당연히 가상기계에 대한 이해가 필요할겁니다. 하지만 확실히 폰 노이만 컴퓨터의 구조는 의식하지 않아도 됩니다. 그리고 g-machine이나 tim같은 계열의 가상기계 명령은 x86 명령보다 훨씬 간단합니다. 즉, 기계에 대해서 알아야하는 부분이 훨씬 적다는 겁니다. 다시 기분나쁘게 들으실까 염려되지만, 가상기계 아래쪽은 언어와 딱히 관계없는 부분인데도 착각하고 계신 것 같습니다.
------------------------------
How many legs does a dog have?
------------------------------
How many legs does a dog have?
[code] 함수형 언어나
폰 노이만 언어가 덜 복잡할 수 밖에 없는 이유는 현존하는 대부분의 아키택쳐가 모두 폰노이만 아키텍처를 따르고 있기 때문일 수도 있습니다. 함수형 언어나 논리형 언어는 그 언어를 해석해서 무엇인가를 하는 기계를 따로 구성해야 하고, 그 기계를 컴퓨터로 다시 구현해야 합니다.
간단하게 말해서 C나 C++ 코드는 코드만 봐도 어떻게 컴퓨터에서 돌아갈 지 대충 감이 옵니다. 메모리에 무엇이 올라가고 내려가고, 어떤 씨피유 인스트럭션이 쓰일 것 같고 등등. 그런데 함수형, 논리형 언어는 그렇지가 않습니다. 그 만큼 더 많은 추상화가 들어가고, "사용자 입장에서 컴퓨터가 어떻게 동작하는 지가 숨겨져 있습니다". 그리고 이해할 수 없는 결과라는 것은 "대체 컴퓨터가 어떻게 돌아가는지가 이해 안간다"는 뜻이겠죠.
네오지오님께서 제시하는 의견도 충분히 납득이 갈만한 부분이 있음에도, 첫머리부터 "넌 잘못 생각하고 있어"라고 못 박고 시작하시는 semmal님께서 오히려 편견에 사로 잡혀 계신 것 같습니다.
위에도
위에도 말씀드렸지만, 언어와 가상기계는 별개의 문제입니다.
Java는 C++보다 단순한 언어입니다만, Java가 복잡하다는 것을 말하기 위해 JVM을 끌어다 놓는 것 같은 "의견"이군요.
------------------------------
How many legs does a dog have?
------------------------------
How many legs does a dog have?
인용: 숨겨진 부분이
제가 "덜 복잡하다"고 이야기 한 것은 "숨겨진 부분이 덜 복잡하다"는 뜻 이었습니다. 글을 모호하게 썼던 것 같습니다만, 제 글이 답글이라는 점을 감안해주셨으면 합니다. 굳이 가상 기계를 이야기에 넣자면 씨/씨++ 은 컴퓨터라는 기계를 직접 조작하는 언어이니 가상 기계가 필요 없고, 고급 언어들은 그렇지 않으니 가상 기계가 필요하므로 당연히 추상화 레벨이 높아지고 "숨겨진 부분이 더 복잡해" 지겠죠.
그리고 저는 언어 자체에 대한 복잡성에 대한 이야기를 할 생각이 없었습니다.
제가 무엇이 복잡한지를 고려해주신다면 이하의 말씀이
제가 말씀드리고자 한 바와는 전혀 다른다는 것을 알 수 있으실 겁니다.
가상기계는 "숨겨진
가상기계는 "숨겨진 부분"이 아니라 "다른 하드웨어"일 뿐입니다.
폰 노이만 언어의 하드웨어는 그냥 하드웨어고, 비 폰 노이만 언어에서는 "숨겨진 부분"입니까?
폰 노이만 언어를 효율적으로 작성하려면 하드웨어를 알아야 하듯이, 비 폰 노이만 언어를 효율적으로 작성하려면 역시 하드웨어를 알아야 합니다.
그렇다고 비 폰 노이만 언어를 위한 하드웨어만 알면되지 폰 노이만 하드웨어까지는 알 필요 없다는 겁니다.
앞에서 밝혔지만 함수형 언어 등의 가상 기계가 x86보다 훨씬 간단합니다. TIM이라는 가상기계는 Three Instruction Machine입니다. 실제로 따져보면 3개는 아니지만 그정도로 명령이 적습니다.
말씀대로 하드웨어를 숨겨진 부분이라고 치자면, x86이 훨씬 숨겨진 부분이 많습니다.
우리가 x86을 설계를 어떻게 했는지 알 필요 없이 어떻게 동작하는지 알면 되듯이, 가상기계를 어떻게 설계했는지 알 필요 없이 어떻게 동작하는 지만 알면 됩니다. 계속 반복하지만 가상기계의 동작방식이 훨씬 간결합니다.
기계와 언어를 정확히 구분하지 못하면 대화자체가 안됩니다. 그래서 공부를 좀 더 해보시라고 굳이 말씀드리는겁니다.
------------------------------
How many legs does a dog have?
------------------------------
How many legs does a dog have?
오히려 제가
오히려 제가 답답하네요 ;
예 그렇습니다. 폰 노이만 언어는 "가상 기계" 필요 없이, 실제 컴퓨터에 직접 적용할 수 있습니다. 따라서 언어와 물리적 기계 사이에 숨겨진 부분이 적다는 겁니다.
"비 폰 노이만 언어를 위한 하드웨어"의 물리적 실현체가 있나요? 대부분의 경우 결국 폰 노이만 아키텍쳐로 그 "비 폰 노이만 언어를 위한 하드웨어"를 다시 구현해야 되기 때문에 많은 부분을 숨길 수 밖에 없다는 말씀을 드리고 있는 겁니다.
TIM 이라는 가상기계가 결국엔 무엇으로 실현되나요? 그 가상기계를 위해서 하드웨어 디자인을 다시 하지 않는 한, 결국엔 우리가 광범위하게 사용되는 폰 노이만 아키텍쳐의 머신 랭귀지로 실현되어야 합니다. TIM이라는 가상 기계어를 그대로 해석할 수 있는 프로세서가 있나요?
전 가상 기계가 실제 기계보다 복잡하다고 주장하고 있지 않습니다. 제가 주장하는 바는
1) 씨/씨++ 코드 -> 해석 -> 실제 기계 언어
2) 함수형 언어 -> 해석 -> 가상 기계 언어 -> 해석 -> 실제 기계 언어
이렇게 되기 때문에 함수형 언어가 숨겨진 부분이 많다고 말씀 드리는 겁니다. 리스프 코드보고 실제 기계가 어떻게 돌아가는지 떠 올리는 것과 씨 코드 보면서 떠올리는 것 중 어느 게 더 쉬울 것 같나요? 그런 의미에서 숨겨진 부분이 많아라고 계속 말씀 드리고 있는 겁니다.
꼭 이렇게 한 줄 덧붙이셔야 속이 시원하신가요? 제 입장에서는 오히려 님께서 더 답답하신데, 가능한한 소통할 수 있는 범위까지 이야기를 하려고 노력합니다만. 도대체 마지막 줄을 덧붙여서 의사소통에 무슨 도움이 되나요? 차라리 제가 기계와 언어를 정확히 구분하지 못하는 부분을 인용해서 이게 잘못됐다라고 하시든지.
다시 한번 말씀드리지만 "함수형 언어 -> 해석 -> 가상 기계어" 과정에서 숨겨진 부분이 씨/씨++ 언어에 비해 적다고 말씀드리는 것이 아니라, 실제 현재 사용중인 대부분의 컴퓨터에서 사용할 때의 이야기입니다 ;; 애시 당초 상대방을 무시하고 이야기를 하시려니 이렇게 되는 겁니다. 가상 기계가 실제 기계보다 더 복잡하다는 주장을 하는 사람이 과연 있을까요? ㅡㅡ;;;
정말 이해를
정말 이해를 못하시는 건지 이해를 안하려고 하시는 건지 모르겠습니다. 지금 말씀하시는 내용을 제가 몰라서 이런 말을 하는 것 같습니까? 저는 기계와 언어 사이에 어떤 단계가 있는지도 모르는 사람이군요.
"비 폰 노이만 언어를 위한 하드웨어"의 물리적 실현체는 당연히 있습니다. 이런 사실을 아신다면, 아니 추상에 대해서라도 제대로 이해하고 계시다면 말을 섞을 이유조차도 없었겠지요.
공부하라는 말씀이 기분이 나쁘시다면 그 말은 취소하지요. 공부하지 마세요. 제가 잘못했습니다. 사과드리겠습니다.
어쨌든 앞으로 더 이상 대화할 일은 없겠군요.
------------------------------
How many legs does a dog have?
------------------------------
How many legs does a dog have?
궁금해서 그러는데
"비 폰 노이만 언어를 위한 하드웨어"의 물리적 실현체에 대해 좀 더 알려주실 수 있으신가요?
글 쭉 보고 있는데 솔깃하네요 ^^
lisp machine으로 구글링
lisp machine으로 구글링 해보시면 많이 나옵니다.
------------------------------
How many legs does a dog have?
------------------------------
How many legs does a dog have?
뻥셔널이
뻥셔널이 킹왕짱!!
이라고 제목과는 다른 논의가 한창 진행중이었군요.
그런데 가만 살펴보니 처음 발단부터 뭔가 약간 이상한 느낌입니다.
"C는 유닉스같은 운영체제 등의 시스템 프로그램을 C로 많이 짜 놓아서 많이 쓰는 거고"
"태생적으로 메모리에 뭘 덮어쓴다는 저급한 기계 중심의 설계를 했다는 근본적인 단점"
이라는 두 논의가 서로 모순인듯합니다.
시스템 프로그래밍을 염두에 두었으니 그런 구조인 것이죠 ^^
뻥셔널의 경우 뭘 덮어쓴다는 개념을 저급하게 생각하기 때문에
아주 기계적인 작업이면서도 흔한 작업인 입출력 부분에 가면
뭘 덮어쓴다는 개념을 억지로 도입해야하죠. ^^
모순이 아닙니다.
모순이 아닙니다. 잘못 이해하신 듯 합니다. C가 아니라 다른 프로그래밍 언어로 작성된, 지금의 유닉스보다 많이 쓰이는 운영체제가 보편화되면 시스템 프로그래밍 영역에서 C를 대체하겠죠. 함수 중심 언어로 시스템 프로그래밍 언어를 만들지 못할 근본적인 이유는 없습니다. 함수 중심 언어를 연구하는 사람들이 시스템 프로그램을 적게 염두하고 있어 시스템 프로그래밍을 위한 기능이라던가 컴파일러 구현 기술이라든가 하는 것을 등이 그쪽에 맞춰 설계하고 구현하지 않았기 때문입니다. 시스템 프로그래밍을 위한 기능은 근본적으로 물건 중심 언어인가 함수 중심 언어인가와는 별개의 개념입니다. 요즘은 파이썬이나 루비같은 스크립팅 언어는 물론이고 C#등의 컴파일 언어도 기본 패러다임이 함수 중심은 아니지만 함수 중심 패러다임을 언어에 도입하는 추세입니다.
임베디드 머신에 자동 메모리 관리를 하는 Java VM을 올린다고 썬이 자바를 만들고 있을 때 말도 안되는 이야기라고 생각하는 사람들도 있었지만, 결과적으로 불가능한 것이 아니었죠. 그 VM위에 자바가 아니라 뻥셔널 프로그램을 돌릴 수도 있는 겁니다. 자바가 대중화된 이후로 메모리 자동 관리가 비효율적이라는 미신을 믿는 사람은 이제 거의 없어졌습니다.
다른 분이 말씀해 주신 바와 같이 대부분의 경우 언어 자체가 효율을 결정한다기보다는 컴파일러 구현 기술이나 프로파일링을 통한 최적화가 효율을 결정합니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
lisp을 가지고
lisp을 가지고 얘기하자면 입출력을 위해선 set을 도입해야 합니다만...
그렇게 하면 그것이 lisp소스이긴 합니다만
그것을 두고 뻥셔널하다고 할 순없죠.
"요즘은 파이썬이나 루비같은 스크립팅 언어는 물론이고"
이후에 나오는 얘기들은 제가 말하는 주제와 관계없는 논의들이군요.
뻥셔널에서 입출력은
뻥셔널에서 입출력은 어떻게 하는 것이 깨끗한가에 대한 대답은 이미 알고 계실 것 같은데, 순수 함수형 언어에서는 여러가지 다른 방법으로 입출력을 다룹니다만, 리습이 순수 함수형 언어가 아니라서 마음에 들지 않으면 입출력 등의 side effect를 추상화하는 언어도 얼마든지 있죠.
오해하시는 분들이 있는데, 함수 중심 언어는 메모리 덮어쓰기 기능을 사용할 수 없거나 거부하는 것이 아니라 아니라 절차 중심 언어처럼 그것에 얽매여 처음부터 메모리 덮어쓰기를 생각하지 않고서는 프로그래밍 자체를 해 나갈 수 없는 문제에서 벗어난 더 유연한 언어들을 말합니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
흠... 언제나 미래는 새로운 이들에게...
함수형 언어의 대세가 언제쯤 올려나?...
하지만 저는 여전히, 적어도 C는 그 때도 살아있으리라고 봅니다.
단순한 도구를 활용하는 장인이 요구되는 곳이 있잖아요.
어떻게 보면 이런 논란은 '은총알'의 의견과 비슷한 문제가 아닌가 싶습니다.
Hardware의 발전을 software가 못따라잡는 것에 대한 이야기겠죠.
즉 hardware를 효율적으로 활용하기 위한 언어 software가 발전을 못해서 사람들이
직접 세세히 작업을 하고 있는 것이 아닌가 싶습니다.
제가 보기에 CPU의 성능발전은 이제 무어의 법칙까지는 못맞추리라고 보고,
software가 어느정도 hardware의 발전을 따라 잡을 수 있지 않을까 싶기도 합니다.
특히 언어 software의 발전이 hardware의 발전보다 보다 큰 효과를 가지지 않을까 추측합니다.
만일 제 추측이 옳다면 사회의 많은 여력과 천재적인 인력이 이쪽을 주시할테니
은총알에 가까운 뭔가가 나오지 않을까요? ^_^
그런데 말이죠. 질문이 있습니다만...
저는 꼬리재귀와 while을 비교하면 while이 좋아보입니다.
꼬리재귀의 장점이 어떤 것이 있죠?
효율성을 위해 만들어진 꼬리재귀를 보면 왠지 어거지로 바꾸는 것 같더군요.
예를 들어 계승의 경우도 꼬리재귀는 수학적 정의와 표현기법이 약간 달라지잖아요.
while이 좋아 보이는
while이 좋아 보이는 것은 모국어인 한국어가 외국어에 비해 더 이해하기 쉬운 것과 마찬가지 일 것입니다.
만약 절차형 언어보다 함수형 언어를 먼저 배웠다면 tail call 또는 tail recursion으로 불리는 방식이 훨씬 더 자연스럽게 보였을 것입니다.
함수형 언어에서의 (tail) recursion은 아름답지 않나요? ^^;
어떤 면에서 어거지처럼 보이는지 예제를 들어주시면 다시 답글 달겠습니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
예, 제가 while에 익숙하긴 하죠.
앞에 예를 든 계승은 어떤가요?
식의 전개과정이 앞의 과정의 상태정도가 필요없어 다시 쓰기 과정으로 바뀐다는 것이 아름답다는 것인가요?
예, 확실히 그건 재미있기는 했습니다.
아름다움이란 취향문제이긴 한데 저는 보다 간결한 기술방식이 아름다운 것이 아닌가 싶습니다.
보다
을 선호해야 하는 이유가 성능말고 있나요?
밑의 꼬리 재귀가
r = 1; while (n == 0) { r = r * n; n = n - 1; } return r;와 다른 근본적인 사항은 없어보입니다.
보다 자연스럽다면 그것은 결과를 도출하는 방식을 말할 겁니다.
수학적인 다시 쓰기과정이 사람들이 보통 생각하는 반복보다 자연스럽다고 주장하는 근거는 무엇인가요?
수학은 일종의 모델링 아닌가요?
너무 추상화만 강조하는 것이 꼭 좋은 것은 아니라고 생각합니다.
그래서 현재로서 꼬리재귀는 문법의 간결성을 만족시키면서 성능문제를 해결하기 위한 기법이라고만 생각하고 있습니다.
위의 Scheme code는 오류가 다수 포함되어 있을 수 있습니다... 잘 쓰지 않으니 이거 힘드네요. ^_^
tail recursion에서
tail recursion에서 도대체 뭘 문제삼으려는 건지 모르겠습니다만, 대관절 뻥셔널 프로그래밍을 할 때는 시간 공간 등의 성능을 고려하면 안된다는 전제는 어디서 나온거죠? 여기서부터 논의가 헛도는 것 같군요.
그리고 while 문과 같은 것들이 아름답지 못한 이유는 메모리 덮어쓰기를 계산이 바탕으로 삼기 때문입니다. 되돌기는 수학의 기본인데 되돌기(recursion)를 사용하면 어째서 수학적이냐고 질문하는 것 자체가 이해가 가지 않습니다. 가장 기본적인 수의 구조인 정수도 되도는(recersive) 정의로 되어 있습니다. 수학적 정의를 하는 데 보편적으로 쓰이는 가장 기본적인 개념을 쓰는 게 왜 수학적이냐고 묻는 질문 자체가 우문이 아닌가요?
그리고 식을 줄이고(reduction) 다시 쓰는(rewrting) 것이 어째서 기계 중심으로 생각하는 것보다 자연스러우냐고 물어보시는데, 초딩 때 사칙연산으로 이루어진 식을 줄이는 걸 먼저 배웠습니까 스택 레지스터와 2진수 표현 덧셈을 먼저 배웠습니까? 아니 쉽고 자연스럽고 기본적인 것을 버려두고 왜 복잡한 기계상태를 갖고 야단법석을 떨면서 그게 더 자연스럽다고 우기는지 다만 어안이 벙벙할 따름입니다.
덮어쓰기를 계산의 바탕으로 삼으면 값을 갖는 식(expression)과 값을 갖지 않는 명령(command)으로 구분해야 합니다. 물론 C처럼 모든 게 다 식이다 이런 엽기적으로 나갈 수도 있지만 곁따르는 반응(side effect)가 있는 식을 남용하는 것이 문제가 많다는 건 뻥셔널을 쓰든 아니든 공감하실 겁니다.
되돌기로 정의하면 뻥셔널에서는 모든 것이 다 식입니다. 식을 갖고 덮어쓰기를 갖는 명령을 만들고, 그걸 다시 식 속에다 넣어서 이게 곁따르는 반응 때문에 문제가 생길까 안 생길까 이런 쓸데없는 걱정을 하지 않아도 되는 깨끗한 디자인이 아름다운 것입니다.
좋은 디자인이란 더 뺄 것이 없어야 한다는 이야기는 들어보셨죠? 식 하나만 있으면 되는데 식과 명령을 아무렇게나 섞어 쓰는 것은 디자인에 결함이 있다고 볼 수 있습니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
헉, 고치기 전에 답글을....
위 C code 중 while 조건 틀린 것 문제삼지 말아주면 감사... -_-.
이야기가 다른 곳으로 빠질 수 있으니까요. 부탁. 굽신..
근데 이거 제가 생각해도 개그군요.
혹여 너 지능적 안티 아니냐고 해도 할 말 없을 듯... ^_^
음.. 제가 머리가 안 돌아서 그런지 용어들이 이렇게 쓰이고, 저렇게 쓰이는 느낌이군요.
저처럼 머리 나쁘면 오해의 소지가 있을 수 있을 것 같습니다.
논쟁이 심화될 때는 퇴고를 부탁드립니다.
저는 반복이 단지 기계에서 동작하는 방식이라고 생각하지 않습니다.
다시 쓰기과정과 반복적으로 사고하는 과정 두가지 속에서 제게는 다른 것이 보이지 않는다는 뜻입니다.
만일 제 생각에 동의한다면 초딩 전 어떤 식으로 사고했었는지는 사람마다 다를 것이라고 생각합니다.
Programming을 하는 전체적인 맥락에서 식 하나만을 제공하여 부작용 남발의 문제점이 없어진다는 것은
저도 인정하는 바입니다. 하지만 어떤 것 하나를 놓고 자연스러우냐 하는 문제는 다른 결론이 도출될 수도 있겠죠.
저는 단지 지엽적인 문제 하나를 물어보았을 뿐입니다.
모든 문제를 항상 전체적인 맥락에서 봐야한다고 주장한다면 확실히 제 질문은 우문입니다.
인용: 그리고 식을
"사칙연산으로 이루어진 식을 줄이는 것"을 배울 때 어떻게 배우셨나요?
이렇게 한 다음에 요렇게 한 다음에 저렇게 해야 한다는 "과정"을 배워야 하지 않나요?
함수형 언어 논쟁을 떠나서 사람에게 가장 자연스러운 사고방식은 "절차적"입니다. 지금 인용한 부분은 비교 대상이 잘못되어 있습니다. 복잡한 기계상태 이진수가 본질이 아니라 imperative 한 사고 방식이 declarative 한 사고 방식보다 더 자연스럽냐가 문제의 핵심 아닐까요? 5살짜리 꼬마한테 1부터 10까지 더하는데 식 줄이고 다시 쓰는 방법으로 설명하는게 절차적인 방법으로 설명하는 것보다 과연 쉬울까요? 어디까지나 "자연스러운 사고방식"에 대한 이야기입니다.
함수형 언어적 사고가 사람의 자연스러운 사고방식이라는 주장은 받아들이기 힘들다고 봅니다. 다만 조금 부자연스럽더라도 문제의 "정형화"를 함수형으로 하면 오류가 근본적으로 적은 프로그래밍을 할 수 있고, "아름다운" 프로그래밍을 할 수 있겠죠.
그리고 자기 생각이랑 다르다고 인신공격 좀 하지 맙시다. 왜 날도 더운데 좋은 토론 거리 놓고 인신 공격을 섞는지. ' "논리적 반박"만 있으면 되는데 "논리적 반박"과 "인신공격"을 섞어 쓰는 것은 "글"에 결함이 있다고 볼 수 있습니다' 라고 생각합니다.
절차적이라는 것이
절차적이라는 것이 무슨 뜻으로 하시는 말씀인지 잘 파악이 되지 않습니다.
전 여러 수자를 더할 때 식을 줄이는 방식으로 배웠던 것으로 기억하는데요,
계속해서 두 수를 더해 가며 식을 줄여 나가는 것으로 말이죠.
그것이 등식의 기본개념 아닌가요? 오른쪽과 왼쪽이 같은 값이라는 거요.
그리고 계산한다는 거 값을 구한다는 거는 오른쪽에서 왼쪽으로 점점 더
간단한 형태로 식을 줄여서 더 이상 줄일 수 없는 값을 구하는 것입니다.
덧셈식의 경우는 더하기가 다 없어질 때까지 줄이는 거죠.
이렇게 배우셨을 것이고, 그리고 그렇게 설명하는 것이 아이에게나
어른에게나 알아듣기에도 훨씬 쉽습니다. 그렇게 가르치지 않는다면
가장 중요한 등식의 기본 개념과 식의 계산에 대해서는 가르치지 않고
기계적인 기술만 가르치는 뭔가 큰 그림을 놓친 교육방식이라고 생각합니다.
학년이 올라가면서 더 큰 여러 자리 수를 두 개 더하는 "십진계산법"은
기계적으로 몸으로 익혀 활용할 수 있도록 절차적으로 설명하겠지만,
일반적인 식의 값을 구하는 계산은 식을 줄여 나가는 것으로 배웁니다.
영어 단어도 많이 나오기 시작하고 무슨 말씀을 하시려는지 핵심이 파악이 되지 않으니,.
그냥 아주 간단하게 한가지만 생각해 봅시다.
초등학교 때 산수나 수학 시간에 메모리나 주소 혹은 변수에 덮어쓰기 배웠나요?
혹시 그런 분 있으면 손 한번 들어주세요 !!!!
무엇이 더 자연스럽고 간단하고 기본적인지는
너무나 뻔해서 사실상 논의가 거의 필요 없는 문제라고 생각합니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
이런 것을 허수아비 논리라고 하나요?
제가 실력이 있지는 않지만 programming을 시작한지는 어느정도 세월이 흘렀습니다.
그래서인지 C 언어를 바라볼 때 어느정도 추상성을 깔아놓고 보는 것 같습니다.
Pointer도 주소로 보지 않고, 객체 지시자 내지는 이름의 문제로 보고 있게 되었으니까요.
처음 programming을 하는 사람에게 어떤 형태로 교육하는 것이 옳은 가 문제는 제가 물어 본 바가 아닙니다.
아직 거기에 대해 논리적 설명을 듣고 이해할만한 능력이 제게는 없습니다.
하여간 제가 메모리나 주소 혹은 변수에 덮어쓰기를 물어보지는 않았습니다.
위에 적은 C code의 대입연산이 정 그렇게 맘에 안 드신다면 할 수 없습니다.
제가 아직 함수형 언어에 푹 빠져 있지 못해서 이해하지 못하는 바가 있다고 생각하겠습니다.
절차적라는 것은 특별한 뜻이 있다고 생각하지는 않습니다.
imyejin씨가 말씀하신 식을 줄이는 과정과 표리부동이라고 생각됩니다.
SICP 3.1.3을
SICP 3.1.3을 읽어보시고나서 대화를 진행하는 것이 조금 더 나을 듯 싶은데요.
------------------------------
How many legs does a dog have?
------------------------------
How many legs does a dog have?
아마 읽었던 것으로 기억합니다만 기억나는 구절이 딱히 없군요.
다시 읽어보도록 하겠습니다.
SICP는 읽어보고는 있습니다만 좀 천천히 읽을 계획입니다.
원래 책 읽는게 느리기도 하거니와...
3.1.3은 제목이 인상깊어서 대충 미리 봤던 것으로 기억합니다만
이 상황에서 적절한 말이 떠오르지가 않군요.
Web의 원서를 읽었습니다.
저는 꼬리재귀 최적화는 반복과 동일할 거라고 생각했는데
꼬리재귀의 치환형태는 병렬대입형태와 동일한 효과를 가지고 있군요.
제가 질문했던 글에서 꼬리재귀와 반복은 근본적인 차이가 없어보인다고 했는데
확실히 이 생각은 수정해야겠습니다.
제가 잘못 알고 있는 점으로 인하여 생긴 소모적 논쟁에 대해서 우선 사과드리겠습니다.
단지 꼬리재귀만이 아니라 무엇이 자연스럽고, 쉬우냐하는 문제는 다른 문제입니다만...
이건 수학적 표현을 가능한 살리려고 하는 FP vs. OOP & IP의 전체의 문제이니
현재의 저로서는 아직 이해할 수 있는 능력이 없군요.
그나저나 SICP는 무엇하나 버릴데가 없군요. 각주조차도 이렇게 알차니 원...
인용: 초등학교 때
초등학교 다닐때 1+1 = 2 인걸 애들한테 이해 시킬때 "식 줄여쓰기"로 이해시키나요?
결국엔 설명하다 보면
1) 사과 한개가 있는데
2) 사과 한개를 더 가져다 놓으면
3) 사과가 두개가 된다
이렇게 설명할 수 밖에 없습니다. 이런 과정을 몇 번 거쳐야, 식 줄여쓰기도 이해시킬 수 있습니다. 변수, 주소 이런게 핵심이 아닙니다. 문제를 풀 때 가장 자연스러운 방식은 푸는 방법을 "절차적으로" 즉 순서대로 늘여 놓는 게 아닐까요? 하고 말씀 드린 겁니다.
물론 절차적으로 늘여 놓는게 비효율적인 경우가 매우 많고, 아름답지 않은 것은 누구나 인정하는 바입니다. 그래서 함수형 언어의 무결성, 표현력, 심미성 등에 대해서는 언급하지 않았습니다. 다만 자연스러운 "사고방식"에 대해서 만큼은 "절차적"이라는 거죠.
말씀하신 "절차적"은,
말씀하신 "절차적"은, imperative 언어와 functional 언어를 구분할 때 말하는 절차적이라는 말과는 다른 뜻이라는 것은 물론 알고계시겠지요? 함수형 언어에서도 함수 만들 때 절차적으로 만듭니다.
당연히 아시고 계시겠지만, 글에서는 그 둘을 구분하지 않으니 논리가 이상하군요.
마치 abstraction을 추상적으로 말하는 것 같습니다.
------------------------------
How many legs does a dog have?
------------------------------
How many legs does a dog have?
제가 "절차적"이라고
제가 "절차적"이라고 한 건 문제를 풀기 위해서 기계가 해야 할 일을 순서대로 적어 늘어 놓는 방식이었습니다. 함수형 언어에서 함수를 만들 때 여기 적은 의미에서 "절차적으로" 만드는 것은 아니라고 알고 있습니다. "둘을 구분하지 않으니 논리가 이상하다고" 하셨는데, 저는 그 둘이 정확하게 무엇인지 잘 모르겠습니다. 그리고 마지막 문장도 잘 모르겠습니다. "둘을 구분하지 않아서 논리가 이상하다고" 하셨으니, 그 둘의 명확한 구분은 semmal 님께서 하셔야 된다고 생각합니다.
기계가 해야 할 일을
기계가 해야 할 일을 순서대로 적어 늘어 놓는 방식이 "절차적"이라는 말씀이시군요. 그럼 제가 잘못 이해했네요.
wish님 주장은 그 절차적인 것이 함수형보다 쉽다는 말씀이시죠?
그런데 저승에 계신 John Backus씨가 그 말을 듣고 울고 있을 것 같습니다. 어쩌면 내가 왜 그 따위 Fortran을 만들었지? 하고 자책하실지도 모르겠네요.
http://www.stanford.edu/class/cs242/readings/backus.pdf
알고계시면서도 이런 말씀을 하신다면 Backus씨가 말씀하신 말에는 확실히 동의 안하시는 것 같군요.
------------------------------
How many legs does a dog have?
------------------------------
How many legs does a dog have?
함수를 배우기전의
함수를 배우기전의 수학 모델은 추상화 레벨이 좀 떨어지는 것 아닌가요?
결국은 약간 미학적인 문제로 돌아오는 듯하군요.
tail recursion은 함수를 평가하는 방식을 최적화하기 위한 테크닉이고요.
다른 근본적인 것(간결함)에관해 이야기해보겠습니다.
라는 함수 정의를 구현하는 코드를 만들때 함수형 vs. 절차적 언어의 비교를 해보면 어떨까요?
함수형 언어는 정의를 그대로 1:1로 매핑하는 수준입니다.
반면에 절차적 언어는 어떤가요? 임시변수를 만들어서 저장하고 복사하거나 덮어쓰거나 하는 이상한 모델이 개입되어야하지 않나요? (물론 사칙연산을 처음배우는 사람에게는 임시결과를 저장하는 방식이 학습시키기에 더 좋을 수도 있을겁니다)
lisp에서는 변수에 덮어쓰는 방식을 나쁜 스타일이라 해서 특수한 경우 아니면 쓰지 않는 것이 좋다고 하고,
erlang에서는 변수에 덮어쓰는 것이 언어레벨에서 금지되어있습니다.
위의 함수를 erlang으로 구현하면,
간결하고 아름답지 않습니까?
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
제가 물어본 내용은 아닙니다만...
마지막 code의 아름다움은 전적으로 동의하는 바입니다.
하지만 또한 그래서 C의 재귀 표현도 그렇게 미워 보이지만은 않습니다. ^_^
저는 추상화라는 것, 혹은 일반화라는 것, SICP 번역서에 요약이라는 말을 쓴 그것이
사람이 이해하기 쉽게 하기 위해서 사용되었다고 생각하는 것은 중간과정이 생략된 결론이 아닌가 싶습니다.
SICP 1장 서문의 '인간오성론'의 발췌글을 읽어보더라도 abstraction이라는 것은 사람이
일반화된 아이디어를 얻기 위한 과정이라고 말합니다.
즉 일반화된 아이디어를 이해하기 편한 것이 추상화된 서술방식이지 무엇 하나를 표현하기 위한 최적은
아니지 않을까 하는 이야기입니다.
우리는 항상 추상화된 바탕 위에서 이야기해야만 하는 것은 아닙니다.
객체지향이 주장했던 것 중에 하나가 domain 언어로 이야기 하자는 것 아닌가요?
저는 응용환경을 수학으로 모델링하지 못하는 사람도 답답합니다만(제가 그렇습니다.... -_-.)
수학을 응용환경에 맞게 설명하지 못하는 사람이 더 짜증입니다.
대게 이런 사람들은 직관적인 능력이 부족해서 새로운 개념을 제대로 못 만들고,
수학을 기계적으로만 하죠.
추상화할 수 있는
추상화할 수 있는 것들은 최대한 추상화해야한다고 생각합니다.
아추 특수한 경우(성능 이슈등)를 제외하고는 굳이 추상화 수준을 낮추어야할 이유가 없을 것같은데요?
객체지향도 일종의 추상화 레벨의 상승이라고 이해하고 있습니다.
제가 파악하는 언어들의 추상화 레벨 또는 표현 능력은 다음 처럼 표기될 수 있을 것같군요.
(이 글타래에서 언급된 언어들만 따졌습니다.)
함수형언어에서의 high order function이나 macro를 절차적 언어로 표현 가능할까요?
기능적으로 동일한 것은 좀 어렵긴해도 만들 수는 있겠지만, 의미적으로 동치인 것을 만들기는 거의 불가능에 가까울 것입니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
추상화가 오히려 부담이 될 때도 있지 않나요?
지나친 상속계층같은 것이 비슷한 예일 겁니다.
추상화를 반대하는 것은 물론 아닙니다.
추상화를 했을 때 이득이 없는 경우를 말하는 것이죠.
원래 객체지향에서 domain 언어로 이야기하자는 것은 추상화를 통해
programming 서술 방식을 domain에 가깝게 표현하자는 것인데
그 이상 추상화하려고 하는 경우가 있을 수 있다는 이야기일 뿐입니다.
간단한 덧셈에서까지 수학적인 원리하에 식을 줄이는 과정으로 설명할 수 있다지만
그것을 꼭 수학이라는 맥락 하에 이야기해야 하며, 그것을 온전히 표현하는데
꼭 함수형 언어를 도입해야 하는가에 대한 물음입니다.
수학이라는 것이 꼭 현실세계를 위해 존재하는 것만 연구되어져야 한다고 주장하는 것은 아닙니다만
이미 존재하는 다른 표현이 있는데 충분한 이득을 설명하지 못한 상태에서
다른 표현으로 꼭 대체해야 한다고 강력히 주장하는 것을 납득하지 못하는 것입니다.
이쯤되면 언어가 아니라 교리에 가까운 것이 되는거죠.
추상을 했는데
추상을 했는데 이득이 없으면 추상을 잘못한 것 아닐까요?
잘못 프로그래밍한 것까지 따질 필요는 없을 것 같습니다.
편하자고 한 짓인데 불편하다면 말이 안되는 거죠.
------------------------------
How many legs does a dog have?
------------------------------
How many legs does a dog have?
추상화가 왜 부담이
추상화가 왜 부담이 되는지 이해하기 힘들군요.
원래 이해를 돕기위해 추상화의 개념이 도입되었는데 그게 어찌 부담이 될까요?
저급하게 표현하는 것도 표현이지만 더 고급스럽게 표현하는 것을 추구해야하지 않을까요?
다른 표현이라고 말씀하시는 것(함수형 표현)이 제가 생각하는 좀더 고급스런, 아름다운 표현이라 생각하기때문에 대체를 주장하는 것입니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
제가 이야기한
제가 이야기한 언어의 표현능력에 관해서는 언급이 없으시군요.
CL의 macro와 같은 것을 CL보다 더 편리하게, 아름답게 제공하는 다른 언어가 있다면 그 언어를 종교로 삼아줄 수도 있습니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
언어의 표현능력은 제가 물어보고 있는 사항은 아니잖아요.
시작이 처음 제가 물어본 것에서 시작했으니까 거기에서 비롯된 글을 중심적으로 보았을 뿐입니다.
언어의 표현능력에 대해서는 동감입니다.
한 20년 쯤 지나면...
plain text로 작성된 문서가
자동으로 클래스 다이어그램으로 전환되고,
이 단계에서 1차적인 검토후,
자동적으로 이 다이어그램에서 코드가 생성된 후,
다시 한번 최종적으로 검토하는 시대가 도래할 것입니다.
제 생각에는 고로 어떠한 언어든지 '먼치킨'이 될 수는 없으리라 보입니다.
진정한 '먼치킨'은 rational rose 같은 회사에서 만들고 있는 개발툴이 되겠죠.
There is no spoon. Neo from the Matrix 1999.
There is no spoon. Neo from the Matrix 1999.
GUI vs. CLI 논쟁이 생각나는군요.
개발도구와 programming 언어는 강한 상관관계를 가지지만 독립성 또한 갖고 있는 관계라고 생각합니다.
거꾸로 뛰어난 programming 언어는 개발도구의 필요성을 줄이기도 하죠.
또한 뛰어난 programming 언어가 뛰어난 개발도구를 만들기 위한 밑바탕이기도 하고요.
그런데 이거, 제목과는 너무 먼데까지 온 거 같군요. ^_^
이 논쟁도 읽는사이에 보니까 참 길군요
잼있네요.
그럼 즐거운 토론
뭔가...
결국 댓글을 쓰는 분 끼리의 논쟁이 되어 버렸죠 =_=;;
적당한 선에서 끊어 져야 할텐데 말이죠 ㅎ;