프로그래밍 입문서의 문제점

모바일앱, 웹서비스 등을 스스로 만들어보려는 사람이 늘면서 코딩을 배우는 사람들도 늘고 있습니다. 페이스북 그룹 “생활 코딩”에 가입자가 4만명 이상 있고, 여러 온오프라인 행사들을 개최하는 것을 보면 코딩을 배우고자 하는 열기가 느껴지기도 합니다.

하지만 입문자들에게 코딩을 가르치는 방식을 보면 우려가 되는 부분이 있습니다. 많은 분들이 우려하는 전산 전공 지식이 아닌 “코딩”만 가르친다는 문제 제기를 하려는 것은 아닙니다. 코딩만 놓고 봐도 나쁜 습관을 가르치고 있는 것이 문제입니다.

가장 큰 문제는 변수를 값을 담을 수 있는 용기로, 변수 값의 변경(mutation)을 계산 방법으로 설명하는 것입니다. 다음의 생활코딩 JavaScript 강의 변수 편에서 인용한 변수에 대한 설명입니다.

변수(Variable)는 (문자나 숫자 같은) 값을 담는 컨테이너로 값을 유지할 필요가 있을 때 사용한다. 여기에 담겨진 값은 다른 값으로 바꿀 수 있다.

이 설명이 기술적으로 틀렸다는 뜻은 아닙니다. 컴퓨터 프로그램은 결국 메모리를 읽고 쓰면서 계산을 수행하기 때문입니다. 문제는 입문자들에게 프로그래밍을 “풀고자 하는 문제에 대한 답을 컴퓨터가 알아들을 수 있게 메모리 읽기/쓰기로 표현하라”고 가르치는 것입니다. 반복문에 대한 설명을 보면 이런 경향이 명확해 집니다.

다음은 생활 코드 JavaScript 강의 반복문 편에서 인용한 “coding everybody”라는 문장을 10번 출력하는 코드입니다.

var i = 0;
// 종료조건으로 i의 값이 10보다 작다면 true, 같거나 크다면 false가 된다.
while(i < 10){
    // 반복이 실행될 때마다 coding everybody 
이 출력된다. 
 줄바꿈을 의미하는 HTML 태그
    document.write('coding everybody 
');
    // i의 값이 1씩 증가한다.
    i++
}

요구사항은 그저 같은 문장을 10번 반복해서 출력하는 것인데, 변수 i를 선언하고 while 루프를 돌면서 i를 하나씩 증가시키고 i가 10보다 작은지 판단해서 루프를 빠져나오는 코드를 예로 보이고 있습니다.

이미 이런 스타일에 프로그래밍에 익숙해지신 분들은 입문자들에게 이런 스타일로 프로그래밍을 가르치는 게 얼마나 저수준(기계에 가까운) 사고를 요구하는지 이해하기 힘드실 수도 있습니다. 위 코드를 다시 읽어 봅시다.

  • 변수 i가 가르키는 메모리 공간이 있고 이 공간에 값 0을 초기화합니다.
  • while 루프에서 변수 i가 가르키는 메모리 공간의 값을 읽어 이 값이 10보다 크면 루프를 빠져 나가고 아니면 다음 코드를 수행합니다.
  • 문자열을 출력하고, 변수 i가 가르키는 메모리 공간의 값을 읽어 1을 더한 다음에 이 값을 다시 변수 i가 가르키는 메모리 공간에 씁니다.
  • 다시 while 루프를 반복합니다.

변수 그 자체가 값이 아니라 메모리 공간에 대한 포인터 개념으로 설명을 하고 있고, 실제로 이 메모리 공간의 값을 변경해서 계산을 수행하고 다음 수행될 코드를 결정하기 때문에 얼핏 간단해 보이는 이 코드는 사실상 어셈블리에 가까운 코드인 걸 알 수 있습니다.

어떤 문자열을 10번 출력하는 프로그램은 다음과 같이 요구사항 그대로 말로 옮긴 코드가 되어야 합니다.

_.times(10, function () {
  document.write('coding everybody');
});

저는 입문자에게 변수라는 개념을 가르칠 때 단순히 이름 붙이기(바인딩)로 가르치는 것이 적절하다고 생각합니다. 예를 들어, 아래 코드에서 x는 10, y는 20, z는 10+20입니다. x는 10이라는 값을 담고 있는 메모리 공간, y는 20이라는 값을 담고 있는 메모리 공간, zx 메모리 공간이 담고 있는 값과 y 메모리 공간이 담고 있는 값의 합을 계산하여 그 결과를 담고 있는 메모리 공간으로 생각하는 것과 복잡도 면에서 큰 차이가 있습니다.

var x = 10;
var y = 20;
var z = x + y;

물론 어떤 프로그램이 값의 변경(mutation)이 없이 유용한 일을 할 수는 없습니다. 하지만 mutation은 프로그램이 복잡해지는 가장 큰 이유이고, 프로그래밍에 입문할 때부터 mutation이나 side effect는 꼭 필요한 경우에만 조심스럽게 하도록 가르치는 것이 필요하다고 생각합니다.

케이팝스타 같은 오디션 프로그램을 보면 심사위원들이 가장 큰 문제로 지적하는 것이 “나쁜 습관”입니다. 노래 연습을 열심히 한만큼 나쁜 습관은 더 고치기가 어렵고, 그래서 나이 어린 참가자들에 비해 성인 참가자들의 발전 가능성을 더 낮게 봅니다. 프로그래밍도 마찬가집니다. 사람은 튜링 머신이 아닌데, 모든 문제를 메모리 읽고 쓰는 문제로 보는 습관은 복잡한 소프트웨어를 작성할 때 가장 큰 걸림돌이 됩니다. 그리고 이런 사고 방식은 오래될수록 고치기 어렵습니다. 그래서 처음 프로그래밍에 입문할 때 어떻게 배우느냐가 중요합니다.

Advertisements

24 thoughts on “프로그래밍 입문서의 문제점

  1. 간단히 말해 입문자에게 함수형 프로그래밍 패러다임을 가르치자는 말씀인 것 같네요. 저도 비슷하게 생각하고 요즘엔 함수형 패러다임을 부분적으로 지원하는 환경도 많아져서 좋은 방향이라고 생각해요.

    그런데 저수준 프로그래밍에 익숙하다고해서 함수형 프로그래밍을 배우기 어려울 건 없지 않을까요? 사실 대다수가 C, 자바로 프로그래밍에 입문하고 함수형 프로그래밍은 비교적 덜 알려졌기에 나중에야 관심을 갖게 되지 않나요? 이 때 기존 지식이 특별히 방해가 되는지는 모르겠어요.

    입문자들은 결과가 눈에 보이는 뭔가 기계적인 조작(디스플레이, 네트워크 등등)을 빨리 해보고 싶어하는 경향이 있다고 생각해요. 그런 분들은 함수형 프로그래밍 학습을 따분하게 여기거나 너무 추상적이라고 어려워할 수도 있을 것 같네요. 결국은 부작용을 다뤄야 하므로 저수준 작업도 학습해야 되지 않을까요? 저는 친구들에게 함수형 패러다임을 배우라고 권유하지만 둘 가운데 꼭 무엇이 먼저여야 하는지는 잘 모르겠습니다.

    좋아요

    • 네. 프로그래밍 잘하는 사람이야 명령형 프로그래밍 먼저 배우고 함수형 프로그래밍 배우는 게 큰 문제는 아닐 겁니다.

      근데 생각해보면 코딩 입문자들은 사실 함수형 프로그래밍에 오히려 더 익숙하거든요. 초중고 내내 수학적인 의미의 함수만 배웠으니깐요.

      근데 프로그래밍을 배우면 이런 유용한 함수의 개념을 버리고 기계와 비슷한 방식으로 계산하는 훈련을 하게 되는게 안타깝다고 생각합니다. 나중에 함수형 프로그래밍을 배우려면 다시 기계적이 사고 방식을 버리고 수학 함수로 돌아가야 하니깐요.

      그리고 side effect를 줄이고 될 수 있으면 immutable한 type을 사용하는 건 함수형 프로그래밍만의 스타일이 아니라 어떤 패러다임에서든 프로그래밍을 잘하기 위한 팁이 아닌가 싶습니다.

      Liked by 1명

  2. 변수가 처음 프로그래밍을 배우는 사람에게 어렵다는 내용은 공감합니다. 저 역시 대학교 1학년때 프로그래밍 수업을 듣거나, 동아리 프로그래밍 스터디를 보면서, 공감했던 내용입니다.

    하지만 변수와 side effect를 이용한 프로그래밍을 나쁜 습관이라는 비유를 드신 부분은 잘 이해가 가지 않습니다.
    예를 들어주신 while문을 봤을 때 처음에 배울땐 어렵겠지만, 익숙해지면 단순히 10번을 도는 루프라는 것을 쉽게 알 수 있습니다.

    “모든 문제를 메모리 읽고 쓰는 문제로 보는 습관은 복잡한 소프트웨어를 작성할 때 가장 큰 걸림돌” 이라고 말씀해주셨는데 단순한 루프는 조금 복잡해도 지역적으로 복잡할 뿐인데 가장 큰 걸림돌 수준인지 궁금합니다.

    Liked by 1명

  3. […] 프로그래밍 입문서의 문제점에서 변수의 사용은 나쁜 프로그래밍 습관이니, 프로그래밍 입문서에서 변수 사용을 장려하지 않는 것이 좋겠다는 이야기를 했습니다. 그런데 입문자가 아니라 현업 개발자들조차 변수 사용이 왜 나쁜 습관인지, 왜 복잡한 소프트웨어 작성에 문제가 되는지 잘 모르고 계신 것 같아서 관련 내용을 보강합니다. […]

    좋아요

  4. 학부생인 프로그래머 입문생입니다. 이후에 올리신 변수 사용이 나쁜 이유도 잘 읽었습니다.

    작성자분이 생각하시는 것도 어느정도는 이해한 것 같습니다.
    입문자가 누구(취미로 배우는 사람, 학부생, 독학생)인지 사용하는 언어가 무엇인지에 따라 매우 다르기 때문에 크게 다가오지가 않았습니다.

    분명 불필요한 변수의 사용은 나쁜 습관이지만 C언어였다면 처음부터 변수의 개념을 잘못 아는 것보다는 어쩌면 처음에 변수를 많이 사용하더라도 변수를 사용하는 법을 제대로 배워야 한다는 생각도 듭니다.
    물론 그 동안에 불필요한 변수의 사용 등은 있어선 안 될 일이지요.
    본문의 while문의 대안도 C언어 였다면 다른 방법이 있었을까? 싶은 생각에 글을 남깁니다.

    좋아요

    • 본문 다시 보시면 아시곘지만, 변수를 가르치지 말자거나 엉뚱하게 가르치자고 이야기한 적은 없습니다.

      많은 입문자들이 “변수”라는 개념이 처음에 낯설고 어려운 이유는 그동안 초중고 교육에서 배운 f(x) = x 함수의 x와 달리 직관적이지 않기 때문입니다. “변수”를 배우려면 머리 속에 컴퓨터가 한 대 있어서 메모리 공간을 떠올리고 변수가 가리키는 메모리 주소에 값을 읽고 쓰는 훈련이 필요하게 됩니다.

      그런데 꽤 많은 프로그램은 굳이 이런 모델이 아니어도 계산을 하는데 아무 지장이 없습니다. function (x, y) { return x + y; }라는 함수가 있을 때 x가 굳이 메모리 공간에 들어 있는 값이 아니라 그냥 함수의 인자 x여도 해당 함수의 의미는 똑같기 때문입니다. 마찬가지로 var x =1;의 x를 꼭 1이라는 값이 들어있는 메모리 주소가 아니라 단순히 x=1로 보는 게 자연스럽습니다.

      소프트웨어가 복잡하다는 건 컴퓨터가 아니라 사람이 이해하기 힘들다는 뜻입니다. 변수는 state고, 프로그램에 state가 많을수록 코드를 이해하기 어려워집니다. while 루프에서 루프 카운터 하나 정도야 전혀 복잡해 보이지 않을 수 있지만, 경험상 코드가 커질수록 이 차이는 커지기 때문에 아주 작은 수준에서부터 조심하는 습관을 기르는 게 좋다고 생각합니다.

      좋아요

  5. 저도 이미 익숙해져서 그런지 잊고 있었는데, 생각해 보니 예전에 처음 수업 들을 때 주위에서 x = 1; x = 2;나, x = x + 1과 같은 개념에 혼란스러워하던 친구들이 많았던 것 같네요.

    좋아요

    • 네. 재미있는 건 반대로 일단 “변수”라는 개념에 너무 익숙해지면 x = 1을 단순히 x가 1이라고 보이지 않고 x가 가리키는 메모리 공간에 1이라는 값을 쓰는 것으로만 보이게 됩니다.

      좋아요

  6. 좋은 글입니다.
    고정된 인식과 식견은 쉽게 바뀌지 않는게 현실이지만, 전 이글에 100% 동감합니다.

    항상 좋은 글 감사합니다.

    좋아요

    • 감사합니다.

      state가 프로그램을 복잡하게 만든다는 전제로 쓴 글인데, 꽤 많은 분들이 이 전제 자체에도 의문을 가지고 있으셔서 놀랐습니다.

      좋아요

      • 그러게요. ^^ ㅎㅎ
        “세상은 아는 만큼 보인다”라고 생각하시고.. 너무 연연하지 마시길 바랍니다.
        앞으로도 좋은 글 많이 부탁드립니다. ^^

        좋아요

  7. 자바스크립트 입문자에게 변수 생략을 위해 underscore 라는 라이브러리를 같이 가르치라는 말씀이신가요? _.times 함수 안에는 for (var i = 0; i < n; i++) accum[i] = iteratee(i); 이런 구문이 들어가 있는데 말이죠.

    좋아요

      • 프로그래밍 언어는 각기 다른 철학 하에 만들어졌기 때문에, 학습자에게 각기 다른 사고 방식과 접근 방식을 요합니다. 자바스크립트는 자바스크립에 맞게, C는 C 에 맞게 가르쳐야 합니다. 변수에 대해 쓰신 글을 봤는데요. 변수 사용의 위험성(?)에 일정 부분 동의합니다만, 그렇다고 입문자에게 변수를 쓰지 않도록 가르쳐야 한다는 부분은 동의하기 어렵네요. 언어 자체가 고수준의 추상 언어가 아닌데, 학습자에게 고수준의 추상을 요구할 수 없을 테구요. 그런 점에서 생활코딩의 자바스크립트 변수에 대한 설명 부분에서 underscore 를 사용하여 “요구사항 그대로 말로 옮긴 코드가 되어야”한다고 하신 부분은 부적절하다는 생각이 들어 지적을 한 것입니다. 결론은 입문 교육이라면 언어는 언어대로 가르치고, 피해야할 습관에 대해 추가적으로 가르치는 게 맞지 않나 싶습니다.

        좋아요

  8. 이 글(두 번째 글 포함)의 단편적인 내용 중 하나인 가변 상태와 복잡도의 관계에 대해서는 동의를 하는 편입니다. 하지만 프로그래밍 입문에 대한 얘기들은 솔직히 알아듣기 어려웠습니다. 다시 한 번 읽어보니 동의되지 않습니다. 특히 while문이 입문자들에게 ‘저수준(기계에 가까운) 사고를 요구’한다는 부분은 별 근거 없다고 생각되네요. 정말로 그럴까요? 작년에 프로그래밍과는 전혀 관계가 없는 분에게 재미로 codeschool의 JavaScript 입문 코스를 1시간 정도 실습하게 해본적이 있는데 그 과정에서 ‘기계에 가까운 사고’는 단 한번도 발생하지 않았다고 확신합니다.

    그리고 초중고 교육과정을 거친 분들이 함수에는 익숙하지만 변수에는 익숙하지 않다는 부분 역시 무슨 근거가 바탕이된 주장인지 모르겠습니다.

    댓글에 드러나는 의견들도 마찬가지입니다. “‘변수’라는 개념에 너무 익숙해지면 x = 1을 단순히 x가 1이라고 보이지 않고 x가 가리키는 메모리 공간에 1이라는 값을 쓰는 것으로만 보이게 됩니다.”라고 하셨는데 저와 제 주변을 봤을 때 절대 일반화되지 않습니다. 필요한 경우에만 메모리 모델을 사용하는 것이 보통이고 개개인의 경험에 따라 메모리 공간 개념을 떠올리지 못하는 경우도 많습니다. 특히나 JavaScript 예제를 대상으로 한 공격에서는 더욱 설득력이 떨어진다고 봅니다.

    좋아요

    • “초중고 교육과정을 거친 분들이 함수에는 익숙하지만 변수에는 익숙하지 않다” 라는 말을 저는 좀 오해하셨다고 생각합니다. C계열의 프로시져 기반 언어에서, 변수와 함수라는 단어가 초중고교 시절 수학을 배우면서 알던 의미에서 변형된다는 게 핵심이라고 생각합니다.

      간편하게 위키페디아에서 변수의 정의를 긁어오자면

      “In elementary mathematics, a variable is an alphabetic character representing a number, called the value of the variable, which is either arbitrary or not fully specified or unknown.”

      라고 되어 있습니다. “아직 알려지지 않은 값을 나타내는 문자”라고 요약될 수 있는데 메모리 영역의 mutation을 기반으로 하는 프로시저 기반 언어에서 변수는 알려지지 않은 값을 나타내는 문자가 아니라 값이 저장된 메모리 주소의 이름이 되죠. 그 주소에 들어 있는 값이 변경될 가능성을 유지한 상태로요.

      함수 역시 수학적으로는 정의역에서 치역으로 매핑되는 규칙이라는 것이 수학적으로 우리가 배운 바인데, 프로시저 언어로 가면 리턴값보다 사이드 이펙트에 오히려 무게가 실리는 현상이 발생하죠. 이 역시 의미가 달라지는 것입니다.

      “개개인의 경험에 따라 메모리 공간 개념을 떠올리지 못하는 경우도 많습니다” 라는 말씀에 대해서는, 그렇다면 개개인의 경험에 따라서 i 라는 변수의 값이 계속해서 새로 정의될 수 있다는 사실도 떠올리지 못할지에 대해서 묻게 됩니다. assignment operator가 어떤 값과 이름의 바인딩이 아니라면, 다시 말해서 어떤 이름에 연결된 값이 계속 변형될 수 있는 상황이라면 메모리 공간을 떠올리는 게 차라리 낫다고 봅니다. 프로그래밍 교육을 C로 하자는 주장의 근거는 이런 부분이고요.

      좋아요

      • 저는 프로그래밍의 함수와 수학의 함수를 거의 같은 시기에 공부했는데 둘 사이의 혼란은 전혀 느끼지 않았고 오히려 닮아있는 부분들이 양쪽의 이해를 도와줬다고 생각합니다. 그리고 그 시기 이전에 익힌 서브 루틴이나 이후에 학습한 메시징은 지금의 프로그래밍에 있어서 매우 중요하고 반드시 이해해야하는 개념입니다. 그런데 이것들은 수학의 함수와는 별 상관이 없어요. JavaScript 언어가 가진 function이 수학의 함수와 다른 부분이 문제가 된다고 보지 않고 오히려 이 차이가 의미하는 바를 이해하는 것이 좋습니다. 다시 말해 함수형 프로그래밍 근본주의적 입장은 그들만의 주장이라는 것입니다.

        대입연산에 대해서는 ‘그들’이 저수준 사고를 하지 않는다는 것입니다. 변경되는 값을 담는 공간으로는 당연히 이해를 하죠. 물론 이 가변상태가 가져오는 복잡도 증가는 맨처음 밝혔듯이 동의합니다.

        좋아요

  9. 오랜 시간 개발자들에게 코딩 교육을 하면서 문제라고 생각했던 것을 정리한 것이고, 대학이나 NHN 넥스트 등 교육 기관에 있는 분들의 의견도 참고하였습니다.

    블로그 글에 논문 수준의 통계적 검증을 요구하시는 건 아닐 테고, 하나의 의견이라고 생각해 주셨으면 합니다.

    좋아요

  10. Donghyeok Kang님을 포함하여 많은 분들이 제 글을 오해하고 댓글을 다시는 것 같습니다. 본문 어디에도 변수를 가르치지 말자고 하지 않았습니다. 그저 입문서에서 변수를 너무 일찍 배우고, 많이 쓰도록 장려하는 면이 있으니 조심해서 쓰도록 가르치자고 한 것인데 확대해서 해석하시는 것 같습니다.

    본문을 다시 인용합니다.

    “프로그래밍에 입문할 때부터 mutation이나 side effect는 꼭 필요한 경우에만 조심스럽게 하도록 가르치는 것이 필요하다고 생각합니다.”

    좋아요

  11. Gyuwon님. 당연히 대부분의 프로그래머들은 x = 1을 보고 매번 x라는 메모리 공간에 1이라는 값을 write한다고 생각하지 않습니다. 하지만 자주 봐서 익숙해졌기 때문이지 기계에 가까운 사고를 하지 않기 때문은 아닙니다.

    수학 함수에서 x는 메모리 주소가 아니라 심볼이고, 치환으로 계산하기 때문에 메모리에 읽고 쓰는 방식으로 계산하는 것과는 근본적인 차이가 있습니다. 단순히 코드가 비슷해 보이고, 익숙해졌다고 해서 사고 방식이 같은 것은 아닙니다.

    그리고 어느 한쪽이 항상 우수한 방법이라고 이야기하는 것도 아닙니다. 프로그래밍을 하기 위해서는 두 가지 방식으로 다 생각할 수 있어야 합니다. 다만, 대부분의 입문자들은 이미 수학 함수에 익숙한데, 마치 튜링 머신만 유일한 계산 방식인 것처럼 가르치는 방법의 문제를 제기했을 뿐입니다. 그렇다고 아에 변수를 가르치지 말자고 이야기한 것도 아니고요.

    좋아요

  12. 생활코딩의 대한 예시가 잘못된 것 같습니다.

    “요구사항은 그저 같은 문장을 10번 반복해서 출력하는 것인데”라고 하셨는데 저 예제는 while 조건문에 대해서 가르치기 위한 예제이지 “같은 문장을 10번 출력하는” 코드를 가장 효율적으로 작성하라는 예제가 아닙니다.

    그럼 while문을 통해서 초보자에게 10번 출력하는 것을 가르치려고 하는데 글쓴이 분 말씀대로 while문도 사용하지 않고 아래처럼 가르쳐야 할까요?

    _.times(10, function () {
    document.write(‘coding everybody’);
    });

    해당 예제는 while 조건문과 변수를 통해서 글자를 10번 출력함으로써 초보자에게 while 조건문에 대한 설명을 매우 훌륭하게 가르치고 있으며 변수에 대한 개념을 가르치려는 의도보다는 while 조건문에 대해서 가르치려고 하기 위해 작성한 것입니다.

    그리고 변수에 대해서 설명할 때 해당 예제코드는 메모리 공간이라는 말은 사용하지 않았고 최대한 정말 정말 쉽게 설명하였기 때문에 메모리 공간에 대한 개념없이도 충분히 이해할 수 있습니다.

    메모리 공간이라는 말은 해당 예제에 나와있지 않고 메모리 공간이라는 개념은 글쓴이 분이 저수준이라는 말을 하면서 꺼내든 내용입니다.

    즉, 초보자는 아래처럼 이해할 수 있습니다.

    “i라는 메모리 공간에 0을 넣는게 아니라 그냥 i는 0이라고 생각
    i++; 도 그냥 i가 1증가한다고 생각”

    글쓴이분의 글만 읽어봤을 때에는 생활코딩의 while 루프를 예제 코드를 보여주면서 저런식으로 기계적인 수준으로 가르치는 것은 잘못 되었다라고 주장하는 것처럼 충분히 오해할 수 있습니다.

    해당 예제는 잘못되지 않았으며 추가로 글쓴이님의 생각하신 내용을 예제에 덧붙이거나 ( times를 통한 효율적인 처리방안 및 변수에 대한 생각 ) 하면 더 좋은 프로그래밍 입문서가 될것입니다.

    제가 만약에 생활코딩에서 저런 글을 썼는데 “프로그래밍 입문서의 문제점”이라는 글과 함께 생활코딩의 예제가 올라오면서 잘못되었다라고 한다면 충분한 오해를 살 수 있고 생활코딩의 힘들게 강의를 올리신 분은 기분이 좋지 않을꺼라고 생각합니다.

    결론적으로 생활코딩 예제는 초보자가 이해하기 쉽게 잘 작성되었고, 글쓴이님이 말씀하신 제목으로 지정하신 프로그래밍 입문서의 문제점이라기 보다는 프로그래밍 입문서의 아쉬운 점이라고 하는게 좋지 않을까 합니다.

    좋아요

  13. Ian님 말씀하신 대로 예제가 초보자가 이해하기 쉽게 매우 훌륭하게 작성된 거면 글쓴이의 포스팅은 틀린 내용이지요? 제목의 워딩을 ‘문제점’에서 ‘아쉬운 점’으로 고친다고 틀린 내용이 바른 내용으로 될 수가 없습니다. 하시고 싶은 말이 어느 쪽인가요? 포스팅의 내용이 틀렸다는 건지, 내용은 맞는데 생코 만드신 분의 성의에 대해 문제점을 제기해 기분 좋지 않으시다는 건지 헷갈리네요.

    좋아요

    • 혼란을 주어서 죄송합니다.

      다시 정리하면 다음과 같습니다.

      글쓰신 분께서 “문제는 입문자들에게 프로그래밍을 “풀고자 하는 문제에 대한 답을 컴퓨터가 알아들을 수 있게 메모리 읽기/쓰기로 표현하라”고 가르치는 것입니다.”

      라고 하셨는데 예시로 든 생활코딩 예제는 메모리 읽기/쓰기라고 표현하라라고 가르칠려고 한 의도가 없었고, while 문에 대한 프로그래밍 기본적인 문법에 대해서 가르치고 있습니다. 그리고 이를 응용하여 10번만 문자열을 출력하는 코드를 작성하였고 while 문 활용을 보여주기 위해서 변수를 사용하였으나 생활코딩 예제에서는 변수조차도 메모리 읽기/쓰기가 아니라 컨테이너라는 개념으로 최대한 쉽게 설명하려고 노력하고 있습니다.

      해당 생활코딩 예제는 메모리에 대한 개념이 없어도 이해하는데 전혀 문제가 되지 않고 주석에도 메모리에 대한 내용이 없는데 메모리에 대한 내용은 글쓴이가 추가하였고 글쓴시신분께서 기계적인 방식으로 해석하였습니다.

      저는 저 예제를 보았을 때 컴퓨터가 알아들을 수 있게 메모리 공간에 읽기나 쓰기를 하라라고 가르치는 것으로 보이지 않습니다.
      만약 저 생활코딩 예제에 주석에 메모리 공간이라는 내용이 들어갔다면 오히려 초보자에게 엄청난 혼란을 줄 수 있었겠지요..

      따라서 글쓴이 분이 작성한 예시부분인..

      [“풀고자 하는 문제에 대한 답을 컴퓨터가 알아들을 수 있게 메모리 읽기/쓰기로 표현하라”고 가르치는 것입니다. 반복문에 대한 설명을 보면 이런 경향이 명확해 집니다.

      다음은 생활 코드 JavaScript 강의 반복문 편에서 인용한 “coding everybody”라는 문장을 10번 출력하는 코드입니다.]

      라고 설명하는 부분은 잘못된 예시라는 것입니다.
      왜냐면 “풀고자 하는 문제에 대한 답을 컴퓨터가 알아들을 수 있게 메모리 읽기/쓰기로 표현하라”고 가르칠려고 하는 예제코드가 아니기 때문입니다.

      그래서 글쓴이분이 쓴 글의 내용중 해당 생활코딩 에제에 대한 부분에 대한 설명은 수정이 필요하거나 다른 부분으로 대체해야 된다라는 것입니다.

      차라리 생활코딩 예제를 인용하려면 인용하는 것까지는 좋으나 “해당 코드를 좀 더 효율적(글쓴이분이 말씀하신 나쁜습관이 아닌 좋은 방법)으로 짜려면 다음과 같이 하는 것이 좋습니다.” 라고 설명하고 times 코드를 보여주는 것이 좋지 않았을까합니다. 그래서 생활코딩 예제를 인용 시 제목도 “프로그래밍 입문서의 문제점” 보다는 “프로그래밍 입문서의 아쉬운점”이라고 변경하여 이러한 효율적인 코드를 짜는 방법에 대해서도 추가적으로 설명하면 좋지 않았을까 라는 글이 되었으면 한다라는 것입니다.

      좋아요

댓글이 닫혀있습니다.