- 2009/10/12 12:23
- purluno.egloos.com/2455278
- 덧글수 : 0
- 2009/08/22 01:12
- purluno.egloos.com/2422300
- 덧글수 : 0
몇번이고 꾸준히 일기를 쓰려고 했었지만 좀처럼 오래 지속하지 못했다.
고 김대중 전 대통령의 일기를 보니 다시 일기를 쓰고 싶은 욕구가 생긴다.
과거의 나를 기억하고 되돌아보는 좋은 도구가 될텐데 습관이 들지 않으니 뭔가 좋은 방법이 없을까?
태그 : 일기
- 2009/08/02 23:42
- purluno.egloos.com/2408705
- 덧글수 : 0
토론은 상대방 또는 제3자를 설득하기 위해서 또는 그들에게서 자신의 의견에 대해 동의를 얻기 위해 하는 것이다. 이러한 목적을 이루기 위해 토론을 할 때 지켜야 할 점에 대해서 생각해봤다.
1. 서로 주제를 명확히 하기
가끔 비슷하긴 하지만 서로 다른 주제를 가지고 토론을 하는 경우가 있다. 주제를 명확히 하는 것은 발의자(토론을 시작하는 사람)의 책임이다. 참여자는 주제를 바꾸지 않는다. 그리고 혹시 토론 상대방이 주제를 다른 것으로 오해하거나 또는 고의로 다른 주제로 슬그머니 넘어가려 하면 바로 잡아줘야 한다.
2. 한번에 한가지
토론을 진행하다 보면 주제와 관련한 다른 주제가 파생되기도 한다. 그럴 때는 별도로 진행하는 것이 바람직하다. 파생된 주제가 원래 주제의 이치를 따지는 데 꼭 필요하지 않다면 파생된 주제에서 시간을 끌지 않고 원래 주제를 계속 진행하는 것이 바람직하다.
3. 배려
토론 내용 외적인 면에서는 토론 상대방과 제3자를 배려할 필요가 있다. 특히 논쟁을 할 때는 상대방의 의견을 반박해야지, 상대방의 인격이나 행동을 반박하는 것은 삼가야 한다. 그것은 상대방은 물론 제3자의 기분을 상하게 할 수 있으므로 토론을 원활히 지속시키기 어렵게 만든다. 비속어, 은어를 쓰지 않고 정중하게 토론에 임하는 것도 주위 사람들을 위한 배려다.
글로 토론을 하는 경우 논의에 집중하기 위해 높임말을 생략하기도 하는데 어떤 사람들은 이런 것에 불쾌함을 느끼기도 한다. 이러한 것은 상대방과 공감을 할 수 있는 선에서 결정을 하는 것이 좋을 것이다.
4. 교착
말이나 채팅으로 하는 토론은 생각하는 시간에 제한이 있기 때문에 자신이나 상대방의 논리를 충분히 분석하지 못하고 자기 주장만 하는 것을 반복하게 될 때가 있다. 이러한 교착 상태에 빠지면 잠시 휴식 시간을 갖고 자신과 상대방의 논리를 분석한 후에 다시 임하는 것이 바람직하다.
5. 논리가 통하지 않는 사람
토론은 논리적인 판단을 할 수 있는 사람들끼리 하는 것이다. 논리가 통하지 않는 사람과 무리하게 토론을 하는 것은 시간 낭비이다. (다만 제3자를 설득할 목적으로 지속하는 것은 효과가 있을 수도 있다.)
토론 당사자 간에 서로 상하 관계에 있거나 상대방의 약점을 쥐고 있는 등의 경우, 유리한 입지에 있는 사람이 이를 악용하여 논리 외의 것을 토론에 끌어들일 수도 있다. 여기까지 오면 처세의 영역으로, 당하는 사람이 어떻게 대처할지는 상황에 따라 다르겠지만 부적절한 토론의 대표적인 예이다.
6. 인용
토론 주제 분야의 전문가가 아닌 사람들 간에 논쟁을 할 때는 서로가 인정하는 전문가의 말이나 글을 인용하는 것이 효과적일 수 있다. 그러나 어느 한쪽이 인정하지 않는다면 그를 인정하는 제3자를 설득하는 것 이상의 효과는 얻지 못할 것이다. 또한 자신이 제3자의 입장에 있을 경우 전문가의 말이나 글을 인용하는 것을 여과 없이 받아들이면 안된다. 정말로 자기가 그 사람을 전문가로 인정하는지, 그 전문가가 진짜로 그러한 말을 하거나 글을 쓴 적이 있는지를 확인한 후에 판단해야 한다.
7. 중단
의사 결정을 해야하는 경우가 아니라면 반드시 토론에 결론이 나와야 하는 것은 아니다. 긴 교착 상태가 예상되는 논의는 중단하는 것이 시간 낭비를 막는 길일 수 있다.
8. 결단
의사 결정을 해야하는 경우에는 어떻게든 결론을 내려야 한다. 이것은 의사 결정을 하는 사람, 그리고 그 의사 결정에 영향을 받는 사람의 호불호를 적절히 고려하여 결정을 내려야 할 것이다. 이 부분은 리더십의 영역이다.
1. 서로 주제를 명확히 하기
가끔 비슷하긴 하지만 서로 다른 주제를 가지고 토론을 하는 경우가 있다. 주제를 명확히 하는 것은 발의자(토론을 시작하는 사람)의 책임이다. 참여자는 주제를 바꾸지 않는다. 그리고 혹시 토론 상대방이 주제를 다른 것으로 오해하거나 또는 고의로 다른 주제로 슬그머니 넘어가려 하면 바로 잡아줘야 한다.
2. 한번에 한가지
토론을 진행하다 보면 주제와 관련한 다른 주제가 파생되기도 한다. 그럴 때는 별도로 진행하는 것이 바람직하다. 파생된 주제가 원래 주제의 이치를 따지는 데 꼭 필요하지 않다면 파생된 주제에서 시간을 끌지 않고 원래 주제를 계속 진행하는 것이 바람직하다.
3. 배려
토론 내용 외적인 면에서는 토론 상대방과 제3자를 배려할 필요가 있다. 특히 논쟁을 할 때는 상대방의 의견을 반박해야지, 상대방의 인격이나 행동을 반박하는 것은 삼가야 한다. 그것은 상대방은 물론 제3자의 기분을 상하게 할 수 있으므로 토론을 원활히 지속시키기 어렵게 만든다. 비속어, 은어를 쓰지 않고 정중하게 토론에 임하는 것도 주위 사람들을 위한 배려다.
글로 토론을 하는 경우 논의에 집중하기 위해 높임말을 생략하기도 하는데 어떤 사람들은 이런 것에 불쾌함을 느끼기도 한다. 이러한 것은 상대방과 공감을 할 수 있는 선에서 결정을 하는 것이 좋을 것이다.
4. 교착
말이나 채팅으로 하는 토론은 생각하는 시간에 제한이 있기 때문에 자신이나 상대방의 논리를 충분히 분석하지 못하고 자기 주장만 하는 것을 반복하게 될 때가 있다. 이러한 교착 상태에 빠지면 잠시 휴식 시간을 갖고 자신과 상대방의 논리를 분석한 후에 다시 임하는 것이 바람직하다.
5. 논리가 통하지 않는 사람
토론은 논리적인 판단을 할 수 있는 사람들끼리 하는 것이다. 논리가 통하지 않는 사람과 무리하게 토론을 하는 것은 시간 낭비이다. (다만 제3자를 설득할 목적으로 지속하는 것은 효과가 있을 수도 있다.)
토론 당사자 간에 서로 상하 관계에 있거나 상대방의 약점을 쥐고 있는 등의 경우, 유리한 입지에 있는 사람이 이를 악용하여 논리 외의 것을 토론에 끌어들일 수도 있다. 여기까지 오면 처세의 영역으로, 당하는 사람이 어떻게 대처할지는 상황에 따라 다르겠지만 부적절한 토론의 대표적인 예이다.
6. 인용
토론 주제 분야의 전문가가 아닌 사람들 간에 논쟁을 할 때는 서로가 인정하는 전문가의 말이나 글을 인용하는 것이 효과적일 수 있다. 그러나 어느 한쪽이 인정하지 않는다면 그를 인정하는 제3자를 설득하는 것 이상의 효과는 얻지 못할 것이다. 또한 자신이 제3자의 입장에 있을 경우 전문가의 말이나 글을 인용하는 것을 여과 없이 받아들이면 안된다. 정말로 자기가 그 사람을 전문가로 인정하는지, 그 전문가가 진짜로 그러한 말을 하거나 글을 쓴 적이 있는지를 확인한 후에 판단해야 한다.
7. 중단
의사 결정을 해야하는 경우가 아니라면 반드시 토론에 결론이 나와야 하는 것은 아니다. 긴 교착 상태가 예상되는 논의는 중단하는 것이 시간 낭비를 막는 길일 수 있다.
8. 결단
의사 결정을 해야하는 경우에는 어떻게든 결론을 내려야 한다. 이것은 의사 결정을 하는 사람, 그리고 그 의사 결정에 영향을 받는 사람의 호불호를 적절히 고려하여 결정을 내려야 할 것이다. 이 부분은 리더십의 영역이다.
- 2009/07/30 02:52
- purluno.egloos.com/2406179
- 덧글수 : 0
Scala는 JVM 위에서 돌아가는 언어들 중 하나로 객체지향 패러다임과 함수형 패러다임의 여러 장점을 잘 활용한데다 Java 코드를 투명하게 활용할 수 있으니 실용성까지 갖추어 급부상하고 있는 언어입니다.
다만 복잡하다는 이야기가 자주 언급되는 것 같습니다. 그러나 창시자 Martin Odersky의 이야기로는, 언어 명세로만 보면 Java와 비슷한 수준으로 그리 복잡하지 않은 언어라고 합니다. 하지만 그 속에 담겨있는 이론, 권장요소(functional, immutable), break/continue의 부재와 같은 것이 전통적인 imperative-style 프로그래머에게 복잡하게 다가올 수 있겠습니다. 한편, functional-style 프로그래머에겐 Java background와 OOP가 낯설은 모양입니다. 유머글 A Brief, Incomplete, and Mostly Wrong History of Programming Languages에 이런 재미있는 표현이 있습니다.
"2003 - A drunken Martin Odersky sees a Reese's Peanut Butter Cup ad featuring somebody's peanut butter getting on somebody else's chocolate and has an idea. He creates Scala, a language that unifies constructs from both object oriented and functional languages. This pisses off both groups and each promptly declares jihad."
제가 보는 Scala의 약점은 아직 부족한 개발환경입니다. Eclipse, NetBeans의 플러그인을 써봤는데 시스템 요구사양이 높거나, 불안정하기도 하고, Java 쓰다 Scala 쓰니 없어서 아쉬운 IDE 기능도 많았습니다. 하지만 차차 해결 될 문제. 다른 뛰어난 언어가 등장해서 인기를 독차지하지 않는다면 길지 않은 시간 내에 Python, Ruby 못지 않은 주류 언어로 부상할 것으로 기대하고 있습니다. 어쩌면 언젠가는 지금 Java가 가진 위상을 얻을 수 있을지도 모릅니다.
다만 복잡하다는 이야기가 자주 언급되는 것 같습니다. 그러나 창시자 Martin Odersky의 이야기로는, 언어 명세로만 보면 Java와 비슷한 수준으로 그리 복잡하지 않은 언어라고 합니다. 하지만 그 속에 담겨있는 이론, 권장요소(functional, immutable), break/continue의 부재와 같은 것이 전통적인 imperative-style 프로그래머에게 복잡하게 다가올 수 있겠습니다. 한편, functional-style 프로그래머에겐 Java background와 OOP가 낯설은 모양입니다. 유머글 A Brief, Incomplete, and Mostly Wrong History of Programming Languages에 이런 재미있는 표현이 있습니다.
"2003 - A drunken Martin Odersky sees a Reese's Peanut Butter Cup ad featuring somebody's peanut butter getting on somebody else's chocolate and has an idea. He creates Scala, a language that unifies constructs from both object oriented and functional languages. This pisses off both groups and each promptly declares jihad."
제가 보는 Scala의 약점은 아직 부족한 개발환경입니다. Eclipse, NetBeans의 플러그인을 써봤는데 시스템 요구사양이 높거나, 불안정하기도 하고, Java 쓰다 Scala 쓰니 없어서 아쉬운 IDE 기능도 많았습니다. 하지만 차차 해결 될 문제. 다른 뛰어난 언어가 등장해서 인기를 독차지하지 않는다면 길지 않은 시간 내에 Python, Ruby 못지 않은 주류 언어로 부상할 것으로 기대하고 있습니다. 어쩌면 언젠가는 지금 Java가 가진 위상을 얻을 수 있을지도 모릅니다.
- 2009/07/30 01:58
- purluno.egloos.com/2406150
- 덧글수 : 1
관련 링크:
10만 팩토리얼 계산 속도
위 링크의 글타래를 보고 Scala로 100000!을 구해보았다.
참고: Scala는 Java Virtual Machine 위에서 동작하는 객체지향+함수형 프로그래밍 언어다. (.NET Framework 위에서도 동작한다.)
코드는 위 글타래에 있다.
총 4개를 올렸는데 각각 속도의 차이가 크다. 테스트 환경은 Athlon64 3800+ (1-core 2.4GHz), Ubuntu Linux 64-bit인 서버컴퓨터.
1. Tail recursion을 이용한 내림차순 단순 곱셈 (100000 * 99999 * 99998 * ... * 2 * 1)
2. Folding을 이용한 오름차순 단순 곱셈 (1 * 2 * 3 * ... * 99998 * 99999 * 100000)
3. Actor를 이용한 2단 병렬 곱셈 (1 * 2 * ... * 49999 * 50000) * (50001 * 50002 * ... * 99999 * 100000)
4. Actor를 이용한 256단 병렬 곱셈 (1 * 257 * ...) * (2 * 258 * ...) * (3 * 259 * ...) * ... * (256 * 512 * ...)
결과값은 10진수 기준 자리수가 무려 456,574 자리나 되는 것으로 적어봐야 무의미할 것이다.
아래로 갈수록 속도가 빨랐다. (순서대로 약 43초, 37초, 27초, 4초)
3, 4번의 경우 병렬이어서 빠른 영향보단 곱셈을 하는 두 수 중 큰 수의 자리수를 최소화시키는 영향이 더 큰 것으로 생각된다. 아무래도 싱글코어이니만큼 2단은 몰라도 256단의 병렬은 그리 도움은 안될 것이기 때문이다. 다만 actor 없이 단일스레드로 같은 방식으로 연산해본 결과 500ms~1s정도 미세하게 더 느렸다. 즉, actor 256개를 사용하면 미미하긴 하지만 오버헤드보다는 성능 향상이 더 크다는 이야기다. Actor 256개 돌리는데 사용한 thread가 몇개였는지는 확인해보지 못했다.
또 한가지 특이했던 것은, 서버컴퓨터가 Athlon64-X2 4800+인 데스크탑(2-core 2.5GHz; Windows XP 32-bit)보다 빠른 속도로 100000!을 구하는 것이었다. 64비트의 위력이 실감된다. 반면 10000!(1만 팩토리얼)은 데스크탑이 더 빨랐는데 자리수가 커지면 커질수록 64비트가 유리해지는 모양이다.
10만 팩토리얼 계산 속도
위 링크의 글타래를 보고 Scala로 100000!을 구해보았다.
참고: Scala는 Java Virtual Machine 위에서 동작하는 객체지향+함수형 프로그래밍 언어다. (.NET Framework 위에서도 동작한다.)
코드는 위 글타래에 있다.
총 4개를 올렸는데 각각 속도의 차이가 크다. 테스트 환경은 Athlon64 3800+ (1-core 2.4GHz), Ubuntu Linux 64-bit인 서버컴퓨터.
1. Tail recursion을 이용한 내림차순 단순 곱셈 (100000 * 99999 * 99998 * ... * 2 * 1)
2. Folding을 이용한 오름차순 단순 곱셈 (1 * 2 * 3 * ... * 99998 * 99999 * 100000)
3. Actor를 이용한 2단 병렬 곱셈 (1 * 2 * ... * 49999 * 50000) * (50001 * 50002 * ... * 99999 * 100000)
4. Actor를 이용한 256단 병렬 곱셈 (1 * 257 * ...) * (2 * 258 * ...) * (3 * 259 * ...) * ... * (256 * 512 * ...)
결과값은 10진수 기준 자리수가 무려 456,574 자리나 되는 것으로 적어봐야 무의미할 것이다.
아래로 갈수록 속도가 빨랐다. (순서대로 약 43초, 37초, 27초, 4초)
3, 4번의 경우 병렬이어서 빠른 영향보단 곱셈을 하는 두 수 중 큰 수의 자리수를 최소화시키는 영향이 더 큰 것으로 생각된다. 아무래도 싱글코어이니만큼 2단은 몰라도 256단의 병렬은 그리 도움은 안될 것이기 때문이다. 다만 actor 없이 단일스레드로 같은 방식으로 연산해본 결과 500ms~1s정도 미세하게 더 느렸다. 즉, actor 256개를 사용하면 미미하긴 하지만 오버헤드보다는 성능 향상이 더 크다는 이야기다. Actor 256개 돌리는데 사용한 thread가 몇개였는지는 확인해보지 못했다.
또 한가지 특이했던 것은, 서버컴퓨터가 Athlon64-X2 4800+인 데스크탑(2-core 2.5GHz; Windows XP 32-bit)보다 빠른 속도로 100000!을 구하는 것이었다. 64비트의 위력이 실감된다. 반면 10000!(1만 팩토리얼)은 데스크탑이 더 빨랐는데 자리수가 커지면 커질수록 64비트가 유리해지는 모양이다.
최근 덧글