2007년 05월 18일
프로그래밍 언어의 막
가끔 뭔가 아니다 싶을때가 있삼. 자바, C++, 루비, 파이썬... 기만당하고 있다고 생각하는건 나뿐인가;;; 내가 멍청하고 능력이 없어 그렇겠지만 이런 언어들로 코딩을 할때면 뭔가 한꺼풀 나와 기계 사이에 희끄므레하고 질긴 막이 존재한다고 생각이 들때가 많다. 그 느낌은 '내가 왜 꼭 이런 방법을 선택해야 하는거지? 여기에 이러이러한 것이 없거나 조금 더 유연했다면 더 멋진 방법을 쓸수도 있을텐데...'같은 생각이 드는거 말이삼.
예를 들어, 어떤 그래픽 라이브러리를 사용한다고 해보자, 이 라이브러리는 유구한 전통을 자랑하는데-_-, 너무도 전통적인 나머지 배경색/전경색을 변경하는 방법이 오직 setBgBlue, setFgRed...와 같이 함수의 이름으로 지어져 있다. 각각 16개색을 사용하여 총 32개의 함수가 있다-_-;;; 이들에 대해서 랜덤하게 전경과 배경색을 선택하는 루틴을 작성해본다고 가정해보자.
C/C++이라면 함수포인터를 이용할것이다. 각각 색상에 대응하는 함수들을 함수포인터의 배열등에 넣고 이에 대해 인덱스로 접근하며, 이 인덱스를 난수로 얻어 결정할 수 있겠지.
파이썬이라면 C/C++와 유사하게 함수객체를 담은 시퀀스에 대해서 random.choose 같은걸 사용하면 역시나 "included battery"을 이용해 편하게 할 수 있겠지.
루비라면 위의 모든 방법을 써도 될테고, eval 등을 사용하여 색상의 인덱스에 대응하는 문자열로 메시지를 만들어서 날리면 되겠지...
자바라면? 이들이 메서드로서 곧 죽어도 클래스에 속할테니까 이 클래스에 대해서 리플렉션을 이용해 해당 메서드 이름을 매칭하여 사용하면 되겠지-_-;;
물론, 이러한 멍청한 짓을 하지 않기 위해서 API을 어떻게 잘 설계할 것인가에 대한 좋은 이야기들이 충분이 많겠지. 하지만 실제로 뭔가를 하려면 거의 대부분 기존의 API나 플랫폼을 사용하지 않는다는 것은 지금에서는 너무 힘든 일이될 것이삼. 그리고 그러한 것들이 매번 완벽히 내 요구에 맞다거나 내가 그것들을 잘 사용할만큼 뛰어나지는 않았던거 같삼.
프로그래밍 언어로서의 평가기준이 오직 객체지향뿐인 것 같은 공기삼. 어디를 가도, 누구를 만나도 소프트웨어를 한다는 사람들은 다들 한 단어를 말하삼.-_-;;; 그런데 정작 객체로 모든 것을 만들면 다 해결될 것처럼 말하지만, 그들이 편향적으로 설계된 인터페이스를 갖거나 외부에서의 확장을 통해 이를 접근하는 것에는 그 이전보다 훨씬 더 많은 논란이 있는거 같삼... (소프트웨어 공학의 설계단계에서의 대부분의 이야기는 결국 인터페이스를 어떻게 결정하고 선택하는가에 따른 이야기가 아닌가?) 그런데 어째서 (적어도 '이 나라, 이 바닥'에서는) 그다지 이런 '접합'에 대해서 관심있게 생각하는 사람이 적을까?
그리고 정말 웃기는게 객체지향을 배척하지도 않고, 객체지향과 양립하거나 더 발전적인 개념에 대해 이야기하면 흔히 '객체지향'한다는 사람들은 배척하기 바쁜거 같은 느낌만 드삼... 특히 객체지향과 functional-programming이 서로 대치되는 관계도 아닌거 같은데. (그리고 정말 자바코드 같은걸 보고 있으면 그저 객체지향이라는 패러다임의 또 다른 스파게티 코드라고 생각해본적은 없삼? 우리회사 프로그램만 그런가?-_-;;)
내가 생각하기로 functional-programming의 가장 큰 목적중 하나는 이러한 glue을 제공하는데 있다고 생각하는데...
* "why functional programming matters?" -- John Hughes
예를 들어, 어떤 그래픽 라이브러리를 사용한다고 해보자, 이 라이브러리는 유구한 전통을 자랑하는데-_-, 너무도 전통적인 나머지 배경색/전경색을 변경하는 방법이 오직 setBgBlue, setFgRed...와 같이 함수의 이름으로 지어져 있다. 각각 16개색을 사용하여 총 32개의 함수가 있다-_-;;; 이들에 대해서 랜덤하게 전경과 배경색을 선택하는 루틴을 작성해본다고 가정해보자.
C/C++이라면 함수포인터를 이용할것이다. 각각 색상에 대응하는 함수들을 함수포인터의 배열등에 넣고 이에 대해 인덱스로 접근하며, 이 인덱스를 난수로 얻어 결정할 수 있겠지.
파이썬이라면 C/C++와 유사하게 함수객체를 담은 시퀀스에 대해서 random.choose 같은걸 사용하면 역시나 "included battery"을 이용해 편하게 할 수 있겠지.
루비라면 위의 모든 방법을 써도 될테고, eval 등을 사용하여 색상의 인덱스에 대응하는 문자열로 메시지를 만들어서 날리면 되겠지...
자바라면? 이들이 메서드로서 곧 죽어도 클래스에 속할테니까 이 클래스에 대해서 리플렉션을 이용해 해당 메서드 이름을 매칭하여 사용하면 되겠지-_-;;
물론, 이러한 멍청한 짓을 하지 않기 위해서 API을 어떻게 잘 설계할 것인가에 대한 좋은 이야기들이 충분이 많겠지. 하지만 실제로 뭔가를 하려면 거의 대부분 기존의 API나 플랫폼을 사용하지 않는다는 것은 지금에서는 너무 힘든 일이될 것이삼. 그리고 그러한 것들이 매번 완벽히 내 요구에 맞다거나 내가 그것들을 잘 사용할만큼 뛰어나지는 않았던거 같삼.
프로그래밍 언어로서의 평가기준이 오직 객체지향뿐인 것 같은 공기삼. 어디를 가도, 누구를 만나도 소프트웨어를 한다는 사람들은 다들 한 단어를 말하삼.-_-;;; 그런데 정작 객체로 모든 것을 만들면 다 해결될 것처럼 말하지만, 그들이 편향적으로 설계된 인터페이스를 갖거나 외부에서의 확장을 통해 이를 접근하는 것에는 그 이전보다 훨씬 더 많은 논란이 있는거 같삼... (소프트웨어 공학의 설계단계에서의 대부분의 이야기는 결국 인터페이스를 어떻게 결정하고 선택하는가에 따른 이야기가 아닌가?) 그런데 어째서 (적어도 '이 나라, 이 바닥'에서는) 그다지 이런 '접합'에 대해서 관심있게 생각하는 사람이 적을까?
그리고 정말 웃기는게 객체지향을 배척하지도 않고, 객체지향과 양립하거나 더 발전적인 개념에 대해 이야기하면 흔히 '객체지향'한다는 사람들은 배척하기 바쁜거 같은 느낌만 드삼... 특히 객체지향과 functional-programming이 서로 대치되는 관계도 아닌거 같은데. (그리고 정말 자바코드 같은걸 보고 있으면 그저 객체지향이라는 패러다임의 또 다른 스파게티 코드라고 생각해본적은 없삼? 우리회사 프로그램만 그런가?-_-;;)
내가 생각하기로 functional-programming의 가장 큰 목적중 하나는 이러한 glue을 제공하는데 있다고 생각하는데...
* "why functional programming matters?" -- John Hughes
이 글과 관련있는 글을 자동검색한 결과입니다 [?]
- 인터페이스의 이해와 활용 by 써니
- ............ by Andy
- OOP(Object Oriented Programming) by 하늘
- 프로그래밍 언어 그리고 JAVA - 객체지향 프로그래밍. by 엘로이드
- 부드러운 재사용(soft reuse) 시대의 도래 by 써니
# by | 2007/05/18 15:12 | 삽질+돈되는짓 | 트랙백 | 덧글(4)




☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
답글 ㄱㅅ~ 킁~