- 다양한 주제에 대해 자유롭게 글을 작성하는 게시판입니다.
Date | 22/08/23 00:27:55수정됨 |
Name | 아침커피 |
File #1 | Perl_programming_language.png (36.7 KB), Download : 10 |
Link #1 | https://crmn.tistory.com/151 |
Subject | 펄 쓰던 개발자의 회상 |
십여 년 전, 스크립트 언어를 배워야 할 일이 생겼을 때 비주류 좋아하는 성격 탓에 당시 한창 뜨던 중인 파이썬을 안 하고 슬슬 지기 시작하던 펄을 공부했었다. C로 - 그러고보니 C++도 아니고 - 문자열 처리 코드 짜고 있던 나에게 펄은 신세계였다. 요즘은 당연하게 여겨지는 것이지만 배열 마지막 원소를 arr[-1] 같이 -1이라는 인덱스로 접근할 수 있는 것도 C에서는 상상도 못 했던 일이었다. 펄은 참 재미있는 언어였다. 한국어로 치자면 "거시기"에 해당되는 변수가 자동으로 존재한다. $_ 라는 변수인데, 그 덕에 코드를 듬성듬성 짤 수 있었다. 다른 언어에서는 명확하게 변수와 값을 지정해주었어야 할 상황에서 펄은 "거시기" 변수만 불러와 보면 얼추 필요한 값이 들어있었기 때문에 변수를 생략하는 것이 가능했다. 그리고 if문과 함께 unless 문도 있었다. Unless 문의 작동방식은 if문의 정반대. 즉 if (true)는 unless (false)와 같고... 이런 조건문을 겹쳐서 if ( unless ( if ( true ) ) ) 같은 식으로 볼썽사나운 코드를 짜는 것도 가능했다. 물론 이런 코딩이 가능하다 보니 남이 짠 펄 코드를 이해하는 건 정말 어렵고 어쩔때는 내가 예전에 짠 펄 코드도 이해가 안 가기도 했다. 그래서 펄 사용자가 많이 떨어져 나가기도 했고. 이런 펄의 특성은 "어떤 일을 하는 데에는 하나 이상의 길이 있다 (There's more than one way to do it, TMTOWTDI)" 라는 펄의 슬로건에 잘 나타나 있다. 펄 코드에는 개발자의 개성이 원없이 묻어난다. 어쨌든 나는 펄이 참 좋았고, 펄은 내 석사 연구의 꽤 많은 부분과 함께 했다. 펄과 완전 반대편에 있는 언어가 바로 파이썬이다. 파이썬에서 import this를 치면 파이썬의 철학이 죽 나오는데 그 중에 이런 말이 있다. "어떤 작업을 하기 위한 하나의, 되도록이면 단 하나의 자명한 방법이 존재한다. (There should be one-- and preferably only one --obvious way to do it.)" 그래서 파이썬은 띄어쓰기를 몇 칸으로 할 것인지까지도 한번 정하면 끝까지 지켜야 한다. 펄은? 펄 사용자들끼리 신나서 자주 하는 게 어떻게 하면 한 줄 안에 코드를 잘 구겨넣을까 하는 일이다. 이런 면에서 여러모로 펄은 한국어(와 일본어)를, 파이썬은 영어를 닮았다. 한국어에서는 온갖 생략이 가능하다. "사랑해" 라고 하면 내가 너를 사랑한다는 말인 줄 다 안다. 영어에서는 "Love" 라고 하면 못 알아듣기 때문에 단 둘이 있어도 굳이 "I love you" 라고, I가 you를 love한다고 다 꼬치꼬치 말해줘야 한다. 우리는 사과를 먹었으면 됐는데 영어에서는 굳이 사과를 한 개 (an apple) 먹었는지 두 개 이상 (apples) 먹었는지를 말해줘야 한다. 영화 황산벌에 나오는 계백 장군의 대사인 "그러니께 이번 여그 황산벌 전투에서 우리의 전략 전술적인 거시기는, 한 마디로 뭐시기 할 때꺼정 갑옷을 거시기한다, 바로 요거여. 알겄제?" 는 영어로는 말이 안 되고, 번역해 봐야 억지스럽다. 이런 다양성, 다의성은 인간의 언어에서는 언어를 풍요롭게 하고 문학의 비옥한 토양이 되는 존재이지만 프로그래밍 언어에서는 그다지 환영받지 못한다. 프로그래밍에서는 간단함과 명료함이 미덕이다. 그래서 날이 갈수록 파이썬 사용자는 많아지고 펄 사용자는 줄어만 간다. 예전, 대략 버전 관리 시스템으로 git이 아니라 cvs나 svn을 쓰던 때, 수많은 개발자들의 땀과 눈물이 서려있을 Visual C++ 6.0이 현역이었을 때, 간혹 3.5인치 디스켓 드라이브를 볼 수 있었을 때, 안드로이드는 나왔는데 안드로이드 스튜디오는 없어서 이클립스로 앱 만들던 때, 도스에서 터보C를 쓰던 때의 코딩은 참 자유로웠다. 참조할 수 있는 자료가 제한되어 있으니 다 개발자가 어떻게든 직접 해야 했고, 그러다보면 좀 삐그덕대더라도 분명 내 손에서 나왔다고 자부할 수 있는 프로그램이 생기곤 했다. 홈페이지도 메모장에 직접 html 코드를 쳐 가면서 만들곤 했지. 요즘은 컴퓨터 프로그램이 거대해지면서 많은 부분이 규격화되었다. 이미 남이 만들어놓은 코드를 "라이브러리"라는 이름으로 잘 가져다가 쓰는 게 중요한 시대가 되었다. 예전처럼 내가 다 하려다가는 "왜 바퀴를 재발명하고 있냐?" 라는 핀잔을 듣기 일쑤다. 깃허브에서 여러 코드를 받아오고 스택 오버플로우에서 이것저것 찾아서 어떻게 하다 보면 금세 프로그램 하나를 뚝딱 만들 수 있다. 요즘 간단한 스마트폰 앱은 파워포인트 만들듯이 마우스로도 만들 수 있고. 그런데 그렇게 해서 나온 결과물을 보고 있노라면 마음 속 한 구석이 왠지 허전하다. '이 프로그램에서 내가 만든 부분이 도대체 뭐지?' 하는 생각과 함께. 펄을 마지막으로 써 본 지도 거의 10년이 다 되어 간다. 옛 생각이 나서 인터넷에서 펄을 검색해 보니 5년 안에 사용자가 사라질 언어 중 하나로 펄이 꼽혀 있었다. 바퀴를 재발명하던 때가 그립다. 스택 오버플로우 없이 프로그램을 짜던 때가 그립다. 괜히 커맨드 창에서 perl을 실행시키고 이것저것 눌러보다가 창을 닫았다. 기분이 참 $_ 한 오늘이다. 26
이 게시판에 등록된 아침커피님의 최근 게시물 |
제가 선택할 수 없는 외부적인 이유로 IDE, 개발언어와 VCS 가 동시에 바뀌는 상황을 맞은 적이 있었는데, 그 때 git을 써야 했고 출시까지 일정도 촉박하여 별도로 학습할 수 있는 시간 예산 없이 급하게 쓰다가 고생을 해서 첫인상이 안좋습니다.
github desktop의 gui로는 해결할 수 없는 chery pick fail같은게 하루에도 몇번씩 터지는데 cli에서 해결하려니 그렇잖아도 시간이 부족해서 마음은 급한데 키워드도 낯설고 뭐 되는게 없더군요.
git을 제외하면 실제 업무에서 svn, perforce, alien... 더 보기
github desktop의 gui로는 해결할 수 없는 chery pick fail같은게 하루에도 몇번씩 터지는데 cli에서 해결하려니 그렇잖아도 시간이 부족해서 마음은 급한데 키워드도 낯설고 뭐 되는게 없더군요.
git을 제외하면 실제 업무에서 svn, perforce, alien... 더 보기
제가 선택할 수 없는 외부적인 이유로 IDE, 개발언어와 VCS 가 동시에 바뀌는 상황을 맞은 적이 있었는데, 그 때 git을 써야 했고 출시까지 일정도 촉박하여 별도로 학습할 수 있는 시간 예산 없이 급하게 쓰다가 고생을 해서 첫인상이 안좋습니다.
github desktop의 gui로는 해결할 수 없는 chery pick fail같은게 하루에도 몇번씩 터지는데 cli에서 해결하려니 그렇잖아도 시간이 부족해서 마음은 급한데 키워드도 낯설고 뭐 되는게 없더군요.
git을 제외하면 실제 업무에서 svn, perforce, alien brain을 각각 1년 이상 사용해 봤는데 저에게는 svn이 영어, perforce와 ab가 독일어와 불란서 말이라면 git은 스와힐리어 같았습니다.
baba yetu 노래가 좋은 것 처럼 cvcs와 dvcs가 서로 다르고, 장단점이 있는 건 알고 있습니다만, 제가 일 하는 분야에서는 작업자가 지구 이곳저곳에 흩어져 있는 것도 아니고 구성원 중 프로그래머가 아닌 인원이 더 많은데 학습비용이 많이 들어가는 git을 쓸 필요가 없네요.
github desktop의 gui로는 해결할 수 없는 chery pick fail같은게 하루에도 몇번씩 터지는데 cli에서 해결하려니 그렇잖아도 시간이 부족해서 마음은 급한데 키워드도 낯설고 뭐 되는게 없더군요.
git을 제외하면 실제 업무에서 svn, perforce, alien brain을 각각 1년 이상 사용해 봤는데 저에게는 svn이 영어, perforce와 ab가 독일어와 불란서 말이라면 git은 스와힐리어 같았습니다.
baba yetu 노래가 좋은 것 처럼 cvcs와 dvcs가 서로 다르고, 장단점이 있는 건 알고 있습니다만, 제가 일 하는 분야에서는 작업자가 지구 이곳저곳에 흩어져 있는 것도 아니고 구성원 중 프로그래머가 아닌 인원이 더 많은데 학습비용이 많이 들어가는 git을 쓸 필요가 없네요.
아! 이해했습니다 ㅋ 원래 댓글의 괄호 속에 적어주신 부분은 제 생각에는 파이썬 코드에 더 가까워 보여요. 펄이었으면 아마 '그의' 등의 주어가 생략되고 말도 좀 더 구어체로 바뀌지 않았을까 싶네요 ㅋ
펄을 사용하던 파이썬을 사용하던 그 결과인 프로그램은 명확하게 목표를 전달해야합니다. 다만, 목적이 한번에 보이지 않는 글을 쓰신 그 목적이 어떤 언어에 가깝냐는 의미로 해석을 한다면.. 프로그래밍 언어를 2가지의 문맥적 표현법으로 구분할 수도 있습니다.
1) 플라톤의 이데아론에서 시작된 객체지향언어. 파이썬이 객체지향언어냐고 하면 아니라고 하실 분들이 많겠지만, 이러한 분류에서는 객체지향언어로 보는게 맞지 않을까 싶습니다. 펄은 제가 써본적이 없기때문에 모르겠지만, 이 쪽에 가까울 것이라 예상합니다.
2) 로쉬의 프로토타입 이론에서 시작된 문맥을 중요시 하는 언어. 자바스크립트가 문맥적 해... 더 보기
1) 플라톤의 이데아론에서 시작된 객체지향언어. 파이썬이 객체지향언어냐고 하면 아니라고 하실 분들이 많겠지만, 이러한 분류에서는 객체지향언어로 보는게 맞지 않을까 싶습니다. 펄은 제가 써본적이 없기때문에 모르겠지만, 이 쪽에 가까울 것이라 예상합니다.
2) 로쉬의 프로토타입 이론에서 시작된 문맥을 중요시 하는 언어. 자바스크립트가 문맥적 해... 더 보기
펄을 사용하던 파이썬을 사용하던 그 결과인 프로그램은 명확하게 목표를 전달해야합니다. 다만, 목적이 한번에 보이지 않는 글을 쓰신 그 목적이 어떤 언어에 가깝냐는 의미로 해석을 한다면.. 프로그래밍 언어를 2가지의 문맥적 표현법으로 구분할 수도 있습니다.
1) 플라톤의 이데아론에서 시작된 객체지향언어. 파이썬이 객체지향언어냐고 하면 아니라고 하실 분들이 많겠지만, 이러한 분류에서는 객체지향언어로 보는게 맞지 않을까 싶습니다. 펄은 제가 써본적이 없기때문에 모르겠지만, 이 쪽에 가까울 것이라 예상합니다.
2) 로쉬의 프로토타입 이론에서 시작된 문맥을 중요시 하는 언어. 자바스크립트가 문맥적 해석을 중요시 하는 언어입니다.
따라서, 작성해주신 댓글은 이 글이 있었기에 발생할 수 있었던 것, 그리고 다른 글에서 작성된다면 그 문맥이 달라질 수 있다는 점에서 펄 / 파이썬 보다는 자바스크립트에 더 가깝다고 생각됩니다.
아래에 관련 링크 공유드리니 흥미가 간다면 읽어보셔도 좋습니다 ㅎㅎ 코드는 거의 나오지 않으니 클릭을 두려워하지 않으셔도 됩니다. :D
요게 논문이고
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.56.4713&rep=rep1&type=pdf
요게 논문의 한글 해석입니다.
https://medium.com/@limsungmook/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%EB%8A%94-%EC%99%9C-%ED%94%84%EB%A1%9C%ED%86%A0%ED%83%80%EC%9E%85%EC%9D%84-%EC%84%A0%ED%83%9D%ED%96%88%EC%9D%84%EA%B9%8C-997f985adb42
ps. 아, 그리고 문장의 해석이 얼마나 편하느냐의 관점에서 볼 때, 자바/코틀린을 사용하는 제 기준에서 펄이나 파이썬이나 그게 그거긴한데... 둘 중에 고르라면 펄에 좀 더 가까워보입니다 +_+ㅋㅋㅋ
ps2. 구어라고 해야겠죠 댓글도...? 구어라면 문맥이 생길 수 밖에 없는게 아닐까 싶긴합니다 ㅎㅎ
1) 플라톤의 이데아론에서 시작된 객체지향언어. 파이썬이 객체지향언어냐고 하면 아니라고 하실 분들이 많겠지만, 이러한 분류에서는 객체지향언어로 보는게 맞지 않을까 싶습니다. 펄은 제가 써본적이 없기때문에 모르겠지만, 이 쪽에 가까울 것이라 예상합니다.
2) 로쉬의 프로토타입 이론에서 시작된 문맥을 중요시 하는 언어. 자바스크립트가 문맥적 해석을 중요시 하는 언어입니다.
따라서, 작성해주신 댓글은 이 글이 있었기에 발생할 수 있었던 것, 그리고 다른 글에서 작성된다면 그 문맥이 달라질 수 있다는 점에서 펄 / 파이썬 보다는 자바스크립트에 더 가깝다고 생각됩니다.
아래에 관련 링크 공유드리니 흥미가 간다면 읽어보셔도 좋습니다 ㅎㅎ 코드는 거의 나오지 않으니 클릭을 두려워하지 않으셔도 됩니다. :D
요게 논문이고
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.56.4713&rep=rep1&type=pdf
요게 논문의 한글 해석입니다.
https://medium.com/@limsungmook/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%EB%8A%94-%EC%99%9C-%ED%94%84%EB%A1%9C%ED%86%A0%ED%83%80%EC%9E%85%EC%9D%84-%EC%84%A0%ED%83%9D%ED%96%88%EC%9D%84%EA%B9%8C-997f985adb42
ps. 아, 그리고 문장의 해석이 얼마나 편하느냐의 관점에서 볼 때, 자바/코틀린을 사용하는 제 기준에서 펄이나 파이썬이나 그게 그거긴한데... 둘 중에 고르라면 펄에 좀 더 가까워보입니다 +_+ㅋㅋㅋ
ps2. 구어라고 해야겠죠 댓글도...? 구어라면 문맥이 생길 수 밖에 없는게 아닐까 싶긴합니다 ㅎㅎ
말씀하신 현상에 대해 저도 공감이 됩니다.
저는 웹개발을 일찍 시작했는데 20여년 전에는 문제만 있고 정답은 없어서 어떤 식으로든 문제를 풀면 되었거든요.
그래서 조건하에서 창의적인 답들을 찾아내고 나만의 방식으로 슬기롭게 해결해나가는 재미가 있었지요.
근데 시간이 지나니 그 모든 방식이 부정되고 라이브러리를 통해 개발하는 정형화된 공식을 따라가는게 대세가 되었습니다.
물론 제가 선택한 방법들도 지금 생각해보면 그다지 훌륭한 것들이 아니었기 때문에 그걸 억울해 할 일은 아니지만, 예전과 같이 고민해서 창의적으로 문제를... 더 보기
저는 웹개발을 일찍 시작했는데 20여년 전에는 문제만 있고 정답은 없어서 어떤 식으로든 문제를 풀면 되었거든요.
그래서 조건하에서 창의적인 답들을 찾아내고 나만의 방식으로 슬기롭게 해결해나가는 재미가 있었지요.
근데 시간이 지나니 그 모든 방식이 부정되고 라이브러리를 통해 개발하는 정형화된 공식을 따라가는게 대세가 되었습니다.
물론 제가 선택한 방법들도 지금 생각해보면 그다지 훌륭한 것들이 아니었기 때문에 그걸 억울해 할 일은 아니지만, 예전과 같이 고민해서 창의적으로 문제를... 더 보기
말씀하신 현상에 대해 저도 공감이 됩니다.
저는 웹개발을 일찍 시작했는데 20여년 전에는 문제만 있고 정답은 없어서 어떤 식으로든 문제를 풀면 되었거든요.
그래서 조건하에서 창의적인 답들을 찾아내고 나만의 방식으로 슬기롭게 해결해나가는 재미가 있었지요.
근데 시간이 지나니 그 모든 방식이 부정되고 라이브러리를 통해 개발하는 정형화된 공식을 따라가는게 대세가 되었습니다.
물론 제가 선택한 방법들도 지금 생각해보면 그다지 훌륭한 것들이 아니었기 때문에 그걸 억울해 할 일은 아니지만, 예전과 같이 고민해서 창의적으로 문제를 해결해나가는 방식이 아닌 남들 가는 길을 따라가는 식의 작업으로 사조가 바뀐건 좀 아쉬운 느낌이 있네요.
저는 웹개발을 일찍 시작했는데 20여년 전에는 문제만 있고 정답은 없어서 어떤 식으로든 문제를 풀면 되었거든요.
그래서 조건하에서 창의적인 답들을 찾아내고 나만의 방식으로 슬기롭게 해결해나가는 재미가 있었지요.
근데 시간이 지나니 그 모든 방식이 부정되고 라이브러리를 통해 개발하는 정형화된 공식을 따라가는게 대세가 되었습니다.
물론 제가 선택한 방법들도 지금 생각해보면 그다지 훌륭한 것들이 아니었기 때문에 그걸 억울해 할 일은 아니지만, 예전과 같이 고민해서 창의적으로 문제를 해결해나가는 방식이 아닌 남들 가는 길을 따라가는 식의 작업으로 사조가 바뀐건 좀 아쉬운 느낌이 있네요.
목록 |
|