잘 쓴 글들을 유심히 보니,

느끼는 바가 있는데

단어 하나하나 허투루 쓰인 게 없습니다.
그래서 글의 의미적 밀도가 무척 높아요.

나는 왜 그렇게 쓰지 못한걸까 곰곰이 생각해보니
여태껏 생각이라는 풍요로운 환경에서 벗어나려고 하질 않았기 때문에
현실의 부족한 자원에 굶주려본 적이 없었고,
살아남기 위해 비정하게 단어를 골라내본 적이 없었던 겁니다.
최적화 경험의 부재랄까요?

저번에 친구가 저를 보고

넌 생각하고 대화를 구분 안하는것 같다

라고 했는데,
여러 번 생각해봐도 참 맞는 말입니다.
( 이것저것 때려박고 상호작용에도 불친절 )

이제 다음 스텝은, 어떻게 이 버릇을 떨쳐내고 좋은 버릇을 들이느냐네요.

단어를 정교하게 가다듬는 건 시작을 했는데
어찌하면 그걸 멋지게 엮을 수 있을까가 궁금한 부분 : )

4 Likes

생각의 자원은 풍족하고,
현실의 자원은 부족하다는 본문 내용은
위 글에서 context hooking 한것이와요~

밥아저씨가 좋은 코드는 더이상 바꿀수 없을만큼 생각하면서 써서 수정해도 달라지는게 없는게 좋은코드라구 했죠…사람말이나 프로그래밍 언어나 거기서 거기니깐 그런거같네요

1 Like

재능 있는 소설 초보들이 많이 하는 실수가, 소설에 심오한 철학을 줄줄이 써버려서 머리 아프게 만든다죠.
그리고, 이공계 사람들이 일반인에게 설명할 때 어렵게 설명하는 이유가 100% 진실을 담은 설명을 해서라네요.
상대방 머리에 제 생각을 전달하는 게 중요할 때는 문장의 실제 뜻에 주목하지 말고, 상대방이 어떻게 받아들이냐 그것만이 중요한가봅니다.

그러면 소설은 어떻게 심오한 세계를 전달하나? 하면 소설 자체가 정교한 화두가 되어서 독자가 주제에 대해 생각하게 하죠. 다른 논의가 나올 수도 있고 다른 결론을 내릴 수도 있지만 읽기 힘든 소설과 같은 무언가보단 낫습니다.
그렇다면 교양 과학서는 어떻게 써져야 하냐? 하면 과장이나 단순화를 통해 과학적 진실에 가깝지만 이해하기 쉬운 형태로 바꿉니다. “75%만 진실이면 오히려 나쁜 것이 아닌가!” 하지만 100% 진실을 무턱대고 설명했다간 이해도 못하고 정작 중요한 물리적 법칙에 대해서는 정반대의 추론을 하게 되죠. 사실 물리학 전공책도 그렇습니다. 간단한 뉴턴 역학에서 시작해서 나중에 가면 더욱 진실에 가까운 상대성 이론이나 양자역학에 대해 설명하죠. “사실 뉴턴 역학은 틀렸어! 미안해!” 한다고 저자를 비난하지 않습니다. 배울 수록 진실에 가까워지니까요.

3 Likes

저도 비슷한 생각을 해왔었읍니다.
항상 저도 말을 하면서 생각과 대화 의 구분이 안 된다던지의 문제가 있는데,
그런 상황이 생길 때마다 들었던 말이 상대방에게 말을 할 때 상대방을 고려하지 않고 일방적으로 이야기를 한다고 자주 듣기는 했었습니다.
그리고 항상 남들과 같이 이야기나 프로젝트를 할 때에도, 제가 나간 진도(말이라던지, 학습, 생각 등) 에 다른 사람을 맞추려고 들어서 항상 다른 사람들이 당황하고는 했었죠.
글에 관해서도 비슷합니다.
제가 쓰고 싶은 글만 우다다 쓰다보니, 다른 사람들이 보기에 친절하고 재밌는 글이 나오기 힘든 거 같습니다.
제가 보기에는 재밌고 친절할 수 있지만요.
항상 저도 이런 점 때문에 말 통하는 사람 찾기 힘들더군요:joy_cat:

1 Like

구분과 구별을 구별 못하는 경우가 많죠

2 Likes

저도 쓰면서 ‘음 이건 구별에 가까운디…
근데 남이 한 말 맘대로 바꾸진 말자’ 한 부분입니다

후후. 상호작용 위주로 이야길 해주셨네요.

그런데 단어를 골라낸다는 본문 내용은 오컴의 면도날에 가까운 것 같아요. ( 최적화 )

“너 그 얘긴 왜 한거야? 그것까지 말할 필욘 없잖아?”
하는거쥬.

대화 상대와의 상호작용을 위해 information hiding 하는 거하곤 약간 다르죠.
논리적으로 동일한 말을 하고 빼먹은 내용도 없는데 쓸데없는 것들을 가지치기하는 느낌?

물론 본문 내용이 그뿐만이 아니지만요.
댓글 감사합니다 : )

본질적으로 구별을 할 수 있는 사람과 할 수 없는 사람으로 나뉘는게 아니라
할 수 있는 경우와 할 수 없는 경우로 나뉘더군요

어차피 그런게 사소해 보일정도의 오해의 바다속을 헤엄치고 사는게 인간입니다만

1 Like

세워진 날은 본질적으로 이내 무뎌질 수 밖에 없음을.

1 Like

https://blog.naver.com/rhdnfka94/221734887274

님들 제 글도 평가 좀

:smirk:

제 머릿속에서

추상 = 일반 = parameters = top
구체 = 특수 = arguments = bottom
입니다.

추상화는 구체에서 추상을 향하는 것을 말하고
bottom-up 이지요. ( 귀납 )

구체화는 추상에서 구체를 향하는 것을 말하고
top-down 입니다. ( 연역 )

위의 관점에서 추상의 의의는
긴 말을 길게 하지 않기 위함이고
복잡도를 낮추기 위함입니다.

추상은 구체에 대해 메타적이고,
그 거리감만큼 현실적 ‘힘’ 이 없습니다.
추상만으로 문제를 풀어갈 수 없다는 것을 의미합니다.
그러니 science와 potence가 각각 추상과 구체의 한 모습이겠지요. ( 지 / 능 )

츄럴님의 포스트에서
“추상화는 ‘이름을 짓는 것’ 과 ‘세부사항을 숨기는 것’ 으로 이루어진다” 고 하셨는데,

이름을 짓는 것은 네이밍이고,
세부사항을 숨기는 것은 encapsulation에 가까운 information hiding 이겠죠.

무엇을 말씀하려고 하신 건지 알 것 같습니다만
추상화의 보편적 성질에 대해 논하기에는 단어들이 다소 특수 목적적이지 않나 싶습니다.

오버로딩 같은 것도 추상화의 예시겠지요.
그거 좀 주라. 할때 그거라는 대명사도 추상이겠지요.

캡슐화와 오버로딩의 차이랄까요?
쉬운 접근을 위한다는 공통점이 있지만
캡슐화는 오버로딩처럼 확장성을 의도하는 개념은 아니니까요.
오버로딩이 캡슐화처럼 숨김에 포커스가 맞춰진 것도 아니고요.

재밌는 점은,
외적 간명성 덕에 쓰는 입장에선 편하지만
내적 포괄성 탓에 듣는 입장에선 머리를 굴려야 한다는 것이죠. ( ‘그거’ 가 뭔데? )
본질적으로 손실압축이란 것이고,
책임전가 라는 것입니다.
물론 맥락을 제공하는게 발화자의 또 다른 책임이겠지요.

또다른 재밌는 점은 ‘내적 포괄성’ 이라는 단어가 재사용성을 함의하고 있다는 점이죠.

아마 이 말씀도 어느정도 그런 관점이 아닐까 짐작하는데,
encapsulation의 반대인 ( 합침 )
modularization이 추상을 향하는 한 방법이겠지요. ( 쪼갬 )

캡슐화는 단순함을 추구하지만 확장성은 추구하지 않기에 추상화와는 거리가 있다고 생각합니다.

흔히 일상회화에서는 추상을
‘대충 뭉뚱그림’ 정도로 쓰는 듯한데
( 너무 추상적이네, 뜬구름 잡는 소리 하네 등등 )
추상이란 단어가 오버로딩 되어 있는 거죠 : )

추상은 변변한 예도 하나 못 드는것이 아니라,
수많은 예를 들 수 있는 것입니다.

이 주제에 대해 깊게 생각하다 보면
다형성과 오버로딩의 차이가 무엇일까 에도 닿게 됩니다.

‘동형이상’ 이라는 키워드도 얻게 되구요 : )

내가 글쓰면 왜 거의 항상 ‘비선형적 글쓰기’ 가 되는걸까… :sob:

주제라는 점 하나를 찍으면 물감 번지듯이 미친듯 여기저기 튄단 말이죠.

diffuse형 뇌인감~~

일반적인 문맥에서 추상화의 정의가 제가 말한 거는 좀 거리가 멀 수도 있습니다.

근데 컴퓨터 사이언스에서 추상화
이름짓기 + 자세한 거 숨기기
입니다.

함수를 선언하는 것은 함수 안에 있는 코드를 숨기고 이름을 붙이는 것입니다
어떤 타입을 선언하는 것은 그 자료형 안에 있는 구체적인 자료형들을 숨기고 이름을 붙이는 것입니다.
오버로딩은 여러 타입에 대한 함수를 하나의 함수로 처리하니까
자세한 거(타입)을 숨기고 하나의 이름으로 만든 겁니다.

컴싸에 있는 추상화는 전부 저 간단한 문장으로 설명이 가능합니다.
사실 이리저리 말들이 많지만 본질은 다 비슷해요.
이 분야가 똑같은걸 다른 이름 붙여서 약파는 게 진짜 많습니다.

유진님이 생각하시는 추상화의 정의를 한번 한 문장으로 요약해보세요.

구체적 케이스들에서
공통된 성질을 뽑아
‘간결’ 하게 정리하는 것
이 추상화지요.

이미 전부 말씀드린 내용인걸요 : )

츄럴님이 요약한 문장으로 컴싸의 모든 추상화를 설명할 수 있다면 그건 분명 좋은 거죠. ( 컴싸 한정 )

그런데 제가 보기엔 컴싸의 추상화와 일반적 의미의 추상화를 분리할 필요가 없어보여 말씀드린 거예요.

일반적 의미로는 컴싸의 추상화는 물론이고 컴싸 이외의 추상화도 다 설명이 되는데 굳이 왜 나누냐는 거죠.

두개를 굳이 구분했다기 보다는 다른 분야는 제가 잘 모르니까 아는 거에 대해서만 말한거에염

근데 유진님의 정의로는 공통된 것이 없는 유니크한 타입 하나를 만드는 건 추상화라고 하기 어렵지 않나요?
예를 들어 어떤 학생에 대한 타입을 다음과 같이 정의해봅시다

Student {
    name
    age
    no
}

위 (의사)코드를 제 정의로 생각해보면
자세한 3개의 데이터를 숨기고 학생이라는 이름을 붙인 전형적인 추상화의 예시라고 할 수 있습니다.

저는 유진님의 정의로는 이걸 어떻게 설명해야할지 모르겠습니다.

1 Like

그건 그렇네요.
제 정의에 끼워맞출 수는 있는데 그럼 좀 억지고.

CS에서 저걸 추상화로 부른다니 제가 뭐 어쩔 수 없지만
제 느낌으론 저건 추상화보단 구체화나 아니면 단순히 캡슐화에 가까워 보이네영. 이름이 직관적이지가…

아무튼 CS 추상화의 자치권을 인정합니다. 땅땅땅!

유진님 글 솜씨가 늘어가는진 모르겠으나 생각이 다듬어져 가는건 날로 날로 보이네요.

읽기 좋은 글과 틀림이 적은 글은 다르다는게 함정이겠지요.

1 Like

data abstraction 을 반대로 향하는 느낌입니다.
이름을 붙이는 것은 작위적 구체화 입니다.
이름이 뜻하는 의미로 종속시켜 한정된 용도를 갖게 하겠다는 것이기 때문입니다.

ex) semaphore 의 추상은 int.

클래싱의 예시겠지요. 오히려 구체화 입니다.

1 Like