이 글은 https://www.tokyobranch.net/archives/6693 과 https://www.tokyobranch.net/archives/7066 에 대한 반박글입니다. (네. 떡밥을 물고 말았습니다)
떡밥을 물며
트위터를 하다가 케케묵은 떡밥인 PHP 떡밥을 보았습니다. 보통 때 같았다면, 그냥 그저 그런 떡밥으로 넘겼겠지만 루아에 고통받고 있던 터라 빡치는 김에 떡밥을 물고 결국 이 글을 씁니다.
해당 글에서는 PHP 를 써야 하는 이유로
- PHP 는 언어 정책이 보수적이다
- 보안이나 성능 이슈는 PHP가 알아서 해 줄 것이다.
- PHP 를 세계적으로 많이 쓰는 이유가 뭐겠느냐
- PHP가 ORM과 같은 노가다를 대신 해준다
정도를 들고 있지만, 사실 이것들은 잘못되었습니다.
1. 언어 정책이 보수적이다
음 PHP 의 언어 정책에 정확한 이름을 붙이자면 그건 방임이지 보수적임이 아니겠죠
PHP는 많은 메소드들을 deprecation 시켰지만, 이를 제 때 처리하지 않았습니다. 대표적으로 mysql_* 함수들의 deprecation1 이 있는데, 이는 2012년도에 결정됬음에도, 이를 7.0 에 와서야 치웁니다2.
그리고 많은 수의 PHP개발자들은 Deprecation 경고에 신경을 전혀 쓰지 않았고, 그 결과는 Deprecated 된 함수의 지속적인 사용을 유발했습니다.
2. 보안 이슈를 PHP가 알아서 해 줄 것이다.
PHP는 보안 이슈에 있어서는 쥐약입니다. PHP언어 자체의 일관성이 상실된3 점이 프로그래머의 무관심과 시너지를 일으켜, 정말 골 때리는 문제를 양산하게 됩니다.
지천에 널려 있는 자질 미만의 프로그래머들이 ‘싼’ 코드들이 일으키는 SQLi 문제는 일단 넘어가더라도(SQL 에 $_COOKIE 를 concat 한다던가) 언어 자체에서 의도치 않은 함정들이 있습니다. 대표적 예로 PHP의 $_GET $_POST $_COOKIE 등이 있는데, 대부분의 경우, 이 변수들의 값은 문자열의 어레이입니다.
하지만 아래와 같은 쿼리 스트링이4 들어오면 어떻게 될까요?
http://example.com/vuln.php?query[()%20{%20example;};echo%20\%22Content-type:%20text/plain\%22;%20echo;%20echo;%20/bin/cat%20/etc/shadow%22]=test
이 쿼리 스트링을
print("\$_GET = ");
$foo=array();
print_r($_GET);
print('
');
print_r($_GET['query']);
에 넣어 보면 다음과 같은 결과를 출력합니다
$_GET = Array ( [query] => Array ( [() { example;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/shadow"] => test ) )
Array ( [() { example;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/shadow"] => test )
대부분의 경우, $_GET 과 같은 변수로 문자열이 들어올 것으로 예상하고 코드를 작성하기에 이는 잠재적으로 문제를 일으킬 가능성을 증가시킵니다.
이 부분 이외에도, PHP가 암묵적으로 eval() 을 하는 것과 같은 효과를 내는 부분은 또 있습니다
PHP 에서 다음 코드를 실행시키면 어떻게 될까요
$foo = 'phpinfo'; $foo();
놀랍게도 phpinfo() 가 실행되게 됩니다. 이는 잘못 짜여진 코드에서 Function injection5 과 같은 공격을 허용하게 됩니다.
이러한 공격을 막기 위해서는, 입력을 점검하고 필터링하는 노력이 필요한데, 이는 다른 언어에서는 필요 없는 (입력이 string 인지 object 인지 함수인지 체크하는) 작업입니다.
C 같은 경우는, 문자열을 함수 포인터로 잡아 호출하려 할 경우, SIGSEGV 를 내며 죽을 것입니다.
Javascript 는 “foo is not a function” 이라는 오류를 내며 죽을 것입니다.
Java 는 아예 컴파일이 안 될 것입니다.
또한 대부분의 웹 프레임워크들은 PHP처럼 유저 인풋을 어레이로 취급해서 어레이를 만들어준다던가 하는 미친 짓을 하지 않습니다. 예로, NodeJS 의 대표적인 웹 프레임워크인 ExpressJS 의 경우, req.query[“blah[]”] 와 같은 식으로 유저 인풋을 멋대로 가공하지 않고 그대로 넘겨주게 됩니다. 2017-02-17 갱신: ExpressJS 의 경우, ?foo=1&foo=2 와 같은 경우에 foo = [1, 2] 와 같이 결과를 냅니다6. 이는 프로그램이 예상하지 않은 곳에서 크래시날 수 있게 하는 문제를 유발할 수 있습니다. 하지만 PHP 처럼 eval 에 준하는 오류를 일으키진 않으므로 상대적으로 안전합니다.
결국 PHP를 사용함에 있어, 다른 언어를 사용할 때와 비교해서 더 많은 보일러플레이트 코드가 발생하게 됩니다.
3. PHP를 많이 쓴다
PHP 는 인터넷 붐 초창기에 빠르게 퍼져나갔습니다. 결국 악화가 양화를 구축하게 된 대표적 사례라고 할 수 있을 법한 케이스죠.
언어가 많이 쓰인다고 해서 언어의 구림을 커버칠 순 없습니다.
3-1. WP, FB가 PHP를 쓴다.
네 MOSFET만을 가지고 손으로 CPU를 만들 수도7 있죠. 이쑤시개를 가지고도 건축을 할 수 있을 거고요. 헥사 에디터만 있어도 로버의 라디오를 리프로그램할 수 있겠죠8.
하지만 우리가 고수준 언어를 쓰는 이유는 효율성 때문입니다. 그리고 PHP는 많은 보일러플레이트 생성과, 템플릿과 코드의 혼합으로 이를 해칩니다.
실제로 Automattic 의 Jetpack 코드는 PHP프로젝트 치고는 깔끔한 편입니다. 하지만, 이를 수정하려고 하는 작업은, PHP의 템플릿과 코드의 혼합으로 인해 굉장히 까다롭게 됩니다.
또한 안전을 위한, 혹은 동작에 필수적인 수 많은 보일러플레이트들의 존재는 프로그래머가 실수할 가능성을 증가시킵니다. 이는 결국 효율성 저하로 이어지고요.
Facebook 은 PHP를 견디다 못해 직접 언어를 만든 케이스입니다. HHVM 을 만들면서 PHP와 연동이 가능한 Hacklang9 을 만들어서 사용하고 있죠. Facebook 을 두고 PHP를 사용하는 회사라고 부르기엔 이젠 무리가 있겠네요.
4. PHP는 ORM 같은 노가다를 대신 해 준다.
원 글이 ORM이라 부르는 것을 봅시다
그런데 이 과정에는 최소한 두가지의 노가다 작업이 필요합니다. 유저에게서 입력받은 데이터가 정상인지 체크하는 Server side validation과, DB의 데이터를 프로그램에서 사용할 수 있는 형식으로 변환해 주는(퉁쳐서 ORM이라고 부르기도 하는) 작업입니다. 이 이외에도 수많은 노가다가 존재합니다만(파일 업로드 처리라던가 pagination이라던가 나열하면 끝이 없습니다.) 이 두가지는 작업량도 많은데다 이미 존재하는 사양을 코드로 변환하는 단순한 과정이기에 재미도 없습니다. 이 중에서 Server side validation은 모든 입력을 대상으로 하지 않으면 보안에 구멍이 생기지만, 안해도 어차피 티가 잘 안나는 작업이라서 누구에게도 인기가 없습니다.
DB 의 데이터를 프로그램에서 사용할 수 있는 형식으로 번환해 주는 것은 데이터베이스 드라이버지, ORM 이 아닙니다. ORM은 보통 Getter 와 Setter 를 통해 SQL을 생성하고, 이를 쿼리하고, 이 결과를 프로그래머가 지정한 구조대로 맞추어 주는 것을 말합니다.
결국, 편하게 DB를 액세스하기 위해서는 ORM 라이브러리를 사용해야 하는 것은 변하지 않습니다.
또한, 위에서도 짚었지만, PHP는 보일러플레이트 필요로 인해 오히려 프로그래머의 노가다를 증가시키지, 감소시키진 않습니다. 유지보수성 낮은 PHP에게 정신력을 빼앗기는 꼴이죠.
마무리
다르다와 틀리다는 다릅니다. 하지만 PHP는 틀렸습니다.
물론 모던 PHP가 PHP5.x 시절의 과오를 고치려고 하는 것은 맞습니다. 하지만, 이제 다른 웹 개발 분야에서 뜨는 언어에 비해 PHP가 가지는 장점은 많이 흐려진 상태입니다. Deploy 에서도 버전별로 갈리고, 프로덕션 환경에서는 PHP5.x 와 PHP7 간의 호환성 문제 덕분에 닭장 웹호스팅 (Cafe24 의 PHP호스팅을 생각하시면 됩니다) 같은 상품 중에서 모던 PHP를 제공하는 부류는 소수입니다.
개인적인 생각으로는, 언어 자체에 결점을 많이 가지고 있는 PHP가 이제 디플로이마저 어려우면, PHP의 메리트는 이제 굉장히 낮다고 생각합니다. 차라리 Python 이나 Javascript (NodeJS) 나 다른 좋은(그리고 제정신인) 고수준 언어를 쓰시고 정 안되면 C(libcgi) 로 짜세요(비꼼) 그게 더 정신력 코스트를 아낄 수 있을 겁니다.
덧:
count() 가 7.2 들어서 제 정신을 차리려고 하는 건 좋은데 워드프레스 코드조차 해당 코드에서 터지는군요
PHP 좋아하시는 분들은 count() 에 Countable IF 를 달고 있지 않은 객체가 들어와도 오류가 나지 않고 0을 반환하고 심지어 미정의된 변수가 들어와도 0을 반환하는 이런 API 가 정녕 사람이 제 정신을 가지고 작성한 API 명세라고 생각하십니까?
- https://wiki.php.net/rfc/mysql_deprecation
- https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7
- https://php-a-fractal-of-bad-design-kr.github.io/ 참조
- http://security.stackexchange.com/a/128594
- https://www.owasp.org/index.php?title=Function_Injection
- https://github.com/expressjs/express/issues/1824
- http://monster6502.com/
- 마션의 그 장면
- http://hacklang.org/
정말 우물안 개구리네요
시대가 어느때인데
예전같으면 저도 php 까재꼇겟지만
현실이 그렇지가 못하네요
기존 레거시 프로젝트를 이어가야 한다면 어쩔 수 없지만 신규 프로젝트를 PHP로 하는 건 충분히 미친 짓이라고 생각합니다.
더 좋은 대안이 많은데 안 쓰는 건 생산력만 떨어뜨릴 뿐이죠
너무ㅋㅋ웃기신분이네요
이시대에 다른언어를 까재끼는 분이잇을줄은. . 솔직히 이제까지 개발하면서 java가좋다 asp가좋다 파이썬이 좋다. . 이건아니다 . .하는분들중 개발잘하시는분들은 본적이 없네요ㅋㅋ
솔직히 이러고잇는 님이좀 웃기구요
Php가 이젠 왜까여야 하는지 전혀모르겟어요 정말modern php라는걸 접하고 나면 오히려 혁명적이라고 생각이들죠.
본인도 그렇게 느낀 1인이구요
그리고 이런 글을 적을시간에 정말 저논리를 납득시킬만한 사람이되세요.
님이 그런영향을 줄수잇는 자리에서 저런말을 한다면 누구나 고개를 끄덕이겟지만
현재 듣보의 상태로 저렇게 까재끼는 글만적는다면 나는 모자른놈이다 라고 직접 말하는거 아닌가쉽네요ㅎ 그럼 진짜 실력잇는 개발자가 되길바라며 답을 마칩니다
라라벨은 써보셨어요?
닉에 맞는 답변을 드리죠.
좋은 기반은 더 적은 노력을 통해 더 나은 결과를 도출해냅니다.
개판인 기반을 가지고 개판을 감출 핵을 올리는 것보다는 아예 더 나은 기반으로 가는 게 낫다는 말입니다.
물론 생산성이 좋은 도구는 언재든지
환영이에요.
그러나, 말씀하시는게 너무 과격해서
눈살이 찌푸려지는건 어쩔 수 없네요.
님이 php 뿐만아니라 다른언어로 얼마나 개발을 했는지는 모르겠지만.
분명히 님도 자주 애용하는 메인 언어가 있을거에요.
그런데 그것을 어떤 뭔가 불편하다는 이유로, 기반부터가 개반이니 뭐니 그런 소리를 하면, 기분이 나뻐서라도 그 소리를 외면하지 않겠나요?
분명히 자신이 생각하는게 맞고, 그게 좋으면 남한테 권할 수 도 있지만,
이렇게 과격한 방식으로는
받아들이는 이들은 소수 일것이고,
님의 좋은 의도와는 다르게
다수의 사람들 기분만 나뻐질 뿐입니다.
다음부터는 좀 더 덜 과격하게 전달해보는게
어떨까 합니다.
아무튼 글은 잘 읽었어요.
다른 사람이 본인의 생각을 존중해주길 바란다면
당사자인 자신부터, 다른 사람의 생각을 존중해주시고 최대한
과격하지 않게 했으면 합니다.
-php를 좋아하는 이가-
python이나 node js가 왜 고수준의 언어이지요?
고수준언어가 맞죠
딱 봐도 고수준 저수준을 고품질 저품질로 햇갈리는 사람
닭잡을때 닭잡는 칼을 쓰고
소잡을때 소잡는 칼을 쓰고
프로그래머 자질을 논하다니 @.@
고수준 언어를 쓰래 ㅋㅋㅋㅋㅋ
애초에 엉망인 생태계에서 “나는 이 돼지우리가 좋아” 하고 있는 사람을 “좋은 프로그래머”라고는 부르기 힘들죠
고수준언어가 맞죠
분명한건 언어는 도구
쓰임새에 따라 효율적으로 이것저것 선택 사용하면 그만인걸
쉬운(저급 초보) 언어, 어려운(고급 순련자) 언어
쓰레기 언어, 좋은 언어
구분 짓고 고집 부리는 사람치고 개발능력 좋은 사람은 단 한명도 못봤네요
문제 해결 능력이 부족하면 그 언어에 불편함을 느낍니다
그러나 어떤 언어든 이슈가 있고 공부하고 대응 코딩하여 이슈를 해결하고 그 외 언어를 선택한 목적에 맞게 장점을 살리며 프로그래밍하는게 개발자의 능력이죠
아무리 뛰어난 언어가 탄생한다고 해도 개발자가 능력이 부족하면 그 결과물이 바로 쓰레기이지
언어는 쓰레기가 될 수는 없습니다
java 주력으로 si sm 파견 다니는 일부 인력들이 편견이 심한 경우가 있던데 혹시 글쓴님도 그쪽이신가요?
가볍게 망치가 필요할때 무겁게 해머가 필요할때가 있는 법입니다
진짜 개발자라면 어떤 도구든 아끼고 소중히 다뤄야겠죠
PHP의 문제는 쉬워서가 아니라 추상화 레이어가 정신이 나갔기 때문입니다.
당장 fopen() 콜이 URL을 리졸브해서 외래 리소스를 가져오는 것을 *좋은 아이디어* 라고 생각한 것 자체가 제대로 된 생각이 아닙니다.
더불어 일단 뭔가 이상해도 에러를 대충 씹어먹고 “어 뭔가 이상한데? 근데 아무것도 없는 것보단 뭐라도 있는 게 낫잖아?” 라는 정신으로 일단 돌리다가 신나게 0day 를 양산하는 것도 좋은 생각은 아니죠
덧: 살면서 SI SM 파견근무는 다행히도 가 본적이 없군요. 다만 깔끔하지 않은 설계, 특히 문제가 있어도 대충 문제를 무시하고 실행해서 온갖 보안 취약점을 일으키고 유지보수 지옥을 불러 일으키는 똥을 정말로 혐오하는 개발자일 뿐이죠.
취미로는 C, Rust, NodeJS, Elixir 쓰고 회사에서는 NodeJS, Elixir 씁니다.
웹 프로그래밍을 C언어로 짜는게 PHP 보다 정신력 코스트를 아낄 수 있다는 건 콤바인 대신 낫으로 벼베기를 하라는 것과 같습니다. (정작 C 언어로 웹 프로그래밍을 해 보신적은 있으신지 궁금합니다).
PHP 는 대충만들수도 제대로 만들 수도 있는 언어입니다. 졸작들도 멋진 기능을 수행합니다.
PHP 에 대한 공격은 배우기 쉽기 때문에 초보자도 웹 프로그래밍을 해서 기능을 수행하도록 만들기 쉽다는 점 때문에 발생합니다. 이것은 오히려 장점입니다.
고수의 경지에 이른다면, 난이도는 어느 분야나 비슷해 집니다만, 특별한 이유가 있지 않고서야 PHP를 놔두고 C 언어로 웹 프로그래밍을 하지는 않겠죠?
차라리 C로 짜라는 건 PHP보다 C가 차라리 *더* 일관적이라는 겁니다.
적어도 libc 의 함수들은 에러를 “씹어먹고” 이상하게 돌아가지는 않죠. libc 설정에 allow_url_fopen 같은 미친 플래그가 있지도 않고요
그리고 낮은 진입 장벽이 PHP의 똥을 만드는 데 유일한 원인은 절대 아닙니다. 엉망인 생태계와 엉망인 API 디자인, 그 외 문제들이 함께 시너지를 일으켜서 개판이 된 거죠.
낮은 진입장벽으로 유명한 ECMAScript(aka. JavaScript) 를 쓰는 NodeJS 를 보면, 생태계는 규모가 커짐에 따라 똥코드가 차오르기 시작했지만 복붙 코딩이 아닌(PHP 제대로 짜려는 사람 말고는 composer 안쓰잖아요) 애초부터 NPM 의존성으로 패키지가 관리된다는 점 때문에 공통 취약점 DB를 활용해 손쉽게 외래 코드 유래 문제에 대한 보고를 생성할 수 있으며 ECMAScript 표준 자체가 PHP 표준보다는 훨씬 튼튼하고(예: ECMAScript 의 foo.length 와 PHP count() 의 동작 차이를 보십시오) ES6을 지나 ES7, ESNext로 계속 발전해 나가며 언어 스펙 자체가 가지고 있던 더러운 부분들을 치워나가는 걸 보면 알 수 있죠.
언어는 도구다 님의 라라벨 써보셨나요가 답이네요 🙂
저는 저의 프로그래밍 의식 흐름에 맞질 않는다 생각해서 갈아 탔지만
모던 php와 라라벨의 노력 덕분에 깔 수가 없어요
그리고 당연히 의존성 관리 도구와 패키지 관리가 php도 잘 되고 있지요 🙂
아무래도 글을 수정해 주시면 좋을꺼 같네요
음 그리고 갑자기 궁금해 졌는데 php에도 이제 babel 같은 거 있으려나요 … 궁구밍
지금은 Node 개발자 올림
그런데 dart언어 때문에 구글은 까고 싶네요 ….
방임이라는 말에 공감합니다.
보수적인 정책은 명확한 가이드라인으로 통제하고 같은 처리를 다르게 하는 여러 핵을 암묵적으로 허용하지 않는거죠.
API의 제약사항과 가이드라인을 씹을 수 있는 핵이 많다는 것을 명예로운 뱃지로만 생각하는 사람들이 많으면 언어가 새로운 세대로 트랜지션할 시기를 놓치게 된다는 생각이 많이 듭니다.
우물안 개구리가 아무리 발광해도 우물안을 나오진 못하죠.
백날 설명해야 이해못할게 뻔한데 납득시켜달라니 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 고인물이 이래서 극혐 입니다.
초보개발자가 쓴 글이군요 ㅎ
초보 ㅎㅇ
어그로꾼 껒여
짚으신 부분을 보안해서 코딩하시면 되잖아요 ㅋㅋㅋ 흔히들 요즘말로 장비빨이시군요..
함정 카드 투성이인 정신나간 툴과 그나마 제정신이 박힌 툴이 있다면 후자를 택하는 건 지성이 있고 여건이 허용한다면 당연한 것입니다…
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ별 말도안되는 말을 잘도 씨부리셨네요
대부분 $_GET으로 개발한다고요? ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ웃음밖에 안나오네요 쿼리 방어 로직은 jsp도 해결해야하는 숙제에요
멍청멍청하시네요
도대체 JSP 가 왜 나오는지… 전 이 글에서 Python과 Javascript로 짜라고 한 적은 있어도 JSP 언급한 적 없습니다만.. (아 혹시 Javascript (ECMAScript) 를 Java 와 헷깔리신 건 아니죠? 그 정도로 멍청하신 분은 아니리라 믿습니다 )
그리고 자바 얘기 나와서 말인데, 혹시 JSP 짜시면서 Hibernate 같은 거 안쓰고 JDBC바로 부르시나요? 어지간한 멍청이 짓만 안 하면 Hibernate 가 이스케이프는 해줄텐데 말이죠.
그리고 만약에 식당을 차렸는데
100만원 짜리 칼로 생선을 썰던
10만원 짜리 칼로 생선을 썰던
뭔상관입니까 유저가 느낄수가없는데
왜 10만원 짜리 칼로 써는 요리사를 뭐라고하십니까?
그리고 10만원짜리가 더 잘잘려요
Jsp는 허울뿐이며 개발이 오래걸리며 유지보수가 어렵습니다.
100만원 짜리 식당에는 느리고 비쌉니다
10만원 짜리 식당은 빠르고 쌉니다
어떤걸 선택할거같나요?
https://www.tokyobranch.net/archives/6693
왜 서버사이드에서 PHP가 강자인것같나요?
물론 개발자 만족을 위해서라면 얘기가 다르겠지만
개발자가 모르는 프로젝트 퀄리티라던가
비용, 유지보수
무조건 PHP가 위에있습니다.
ㅋㅋㅋ;; 쿼리스트링 방어가 PHP만의 문제라고 하는거보고 아주그냥 부랄을 탁칩니다
아니 좀 제가 Javascript 로 짜라고 했지 언제 자바로 짜라고 했냐고요 아오
왜이리 다들 서블릿 컨테이너하고 연 깊지도 않은 저를 자바 개발자로 못 몰아가서 안달이신지 모르겠네요. 저 서버사이드 자바스크립트로 밥벌어먹고 삽니다 자바가 아니라요.
자바스크립트하고 자바 헷깔리시는 분은 개발자 자질이 의심되는 분들이나 헷깔리는거고요
글 잘 읽었습니다.
low level lang, high level lang이 무슨 뜻인지도 모르는 분들이 진짜 개발자 맞나….
고생이 많으십니다 ㅋㅋ
트위터에서 보고 왔습니다
고생이 많으십니다
댓글에 화나있는 사람들 하나같이 근거가 없거나 개발자가 아니네요… 이렇게 구체적인 예시를 들고와서 까는글도 흔치않은데
글쓴분께서 제목과 내용이 도발적이라 온갖 사람들이 다 몰려들었네요. ㅋㅋㅋㅋ 사실 딱히 틀린말씀은 없으십니다. 요즘같이 실시간 데이터가 왔다갔다 하는게 중요해지는 시점에서 PHP는 느린게 사실입니다. 뭐 빠르게 하는것도 있겠지만 장고 루비레일즈 nodejs처럼 간편하게 개발할 수 있을 거라곤 생각이 안드네요.
아직 많은 솔루션들이 PHP로 되어있고 역사가 깊다보니 각종 플러그인이나 자료가 많아서 지금도 필요하긴 합니다. 다만, PHP는 미래지향적이라고 보긴 힘들지 않을까 싶네요.
php를 깔수 잇는건 zend엔진이 좀후지다는거 뿐이지
그외에는 깔수잇는게 없어요
언어의 디자인 아키텍쳐가 다른언어랑 다르다는건
깔수잇는 문제가 아닙니다
본인 개발이나 열심히하세요
이것저것 평가하지말구요
님이 무언가를 평가하고싶으면
님이 php보다 좋고 인기잇는 언어를 만드셔서
그때 평가하세요
우물 안에 갇혀 계시는 분이 우물안에서 놀지말자라니 해드릴 말은 이거밖에 없네요
좋은 API가 무엇인지에 대한 공부를 더 하고 오시길 바랍니다.
안 그래도 개발 열심히 하고 있습니다만? 님보다는 제가 개발 열심히 하고 있을 것 같군요.
php8 소식이 있다길래 검색하다 우연히 들어와서 보게 되었네요. 아래의 댓글과
글쓴님들의 댓글들을 읽으면서 중재하는 의미에서 댓글하나 남기고 갑니다.
저도 글쓴님처럼, node, php, java, python, ruby, r 등등 적잖게 다뤄봤습니다.
개발자라는게 경력이 쌓이다보면 다뤄야 하는 언어는 회사를 옮기거나 특정 프로젝트에 따라 케바케로 바뀌는것 같습니다. 물론 내가 공부하고 싶었었던 언어를 더 공부하면서 새롭게 접하기도 하고요.
제가 생각하는 개발자로서의 언어는 특정프로젝트에 가장 어울리는 언어가 있고
그것이 퍼포먼스를 잘 뽑아 낸다면, 그걸로 그 프로젝트는 성공적이고 완성적이라 봅니다.
개발자로서도 역할을 다 했고요.
개발을 배우면서 개발자들이 쉽게 착각하는 부분이 있습니다.,
“좋은 언어를 사용해야 좋은 결과물이 나온다.”
사실 저런 생각은 자기 중심적인 사고에서 나오는 겁니다. 돌려 이야기하면
“내가 힘들게 공부하고 익힌 언어가 좋은 언어다. 혹은 나에게 익숙하고 내가 개발하기 쉬운 언어가 좋은 언어다.”를
좋게 포장하고 있는건 아닌지 조심해야 합니다.
개발자의 역할을 도구로만 생각하면 사용하는 모든 언어를 대하는 태도도 그 범주를 벗어나기 힘듭니다.
언어마다 미묘하게 추구하는 가치나 지향점이 다르듯. 강점도 조금씩 다르구요.
그걸 가지고 이게 좋네 저게 좋네라고 개발자들끼리 언쟁을 하는건 굉장히 소모적인 부분이라 생각합니다.
개발자는 “언어에 대한 학습과 이해가 역할”이 아닙니다.
언어에 대한 학습과 이해는 사람이 숨쉬는 것처럼 너무나 기초적이고 당연한 것이고요.
일본어, 중국어, 영어 등등 그 언어가 중요한게 아니라, 그 문화에서 살아가는 사람들이
중요한 겁니다. 중국이 한글보다 비효율적이라고 중국의 근본이 썩었다고 말하지는 않듯이
글쓰신 분들이나 댓글다신 분들이나.. 자기 언어를 사랑하시는 것은 좋은데 아집에서 벗어나시길 바랍니다.
이 광경이 얼마나 우습냐면…
“난 일본 조리도구 세트로 요리하니까 요리도 맛날꺼야 ”
“아니야 독일제 조리도구 세트로 해야 더 맛좋은 요리가 나올꺼야”
사실 중요한건 결과물인 요리의 맛과, 한정된 자원으로 최고의 결과를 만들줄 아는 그 사람의 실력인거죠.
여러분 모두 냉장고를 부탁해 예능방송을 시청하길 권장합니다.
메인 언어는 파이썬이고, 자바스크립트는 제가 많이
다루지는 않지만 좋아하는 언어입니다.
웹 개발 분야는 전혀 문외한이다가 급작스럽게 pho 기반 사이트 하나를 유지 보수하게 되어 php와 mysql을 간단히 학습하여 구글링과 함께 유지 보수를 하고 있습니다.
웹 개발에 흥미를 느껴 장고와 node.js 둘 중 하나를 학습하려는데 추천해주실 분들 계실까요?? 목적은 자기계발입니다.(그렇다고 이를 활용한 취업을 목적에 두는 것은 아닙니다)
파이썬은 파이썬 철학이나 메커니즘을 포함해서 최신 고수준 라이브러리까지 능숙하게 다루는 수준이고, 데이터 가공, 크롤링, 윈도우 프로그래밍(c와 함께) 등에서 많이 사용했습니다. 자바스크립트는 기본 문법 정도 알고 있는 수준입니다.
*pho -> php
단지 몇줄 코딩으로 프로그램을 판단한다는게 웃기네요. 어떤 언어든지 각각의 장단점이 있는법인데;;
과연 몇 줄이라고 생각하나요? PHP가 잘못한 점을 전부 짚고 넘어가자면 몇날 몇일이 걸려도 다 못 할 겁니다.
프로그래머로써, 2년 이상 된 글은 무시해 줍시다. 부끄럽게 인용 같은 거 하지 말자고요. 잘못된 디자인의 프랙탈을 아직도 들먹이는 분이 계시다니… 무슨, 석기 시대 사람인가요? 거기서 까고 있는 건 이미 해결되었거나, 혹은 좋지 못한 코딩으로 익히 알려진 것들입니다.
PHP 개발하면서 PDO 안쓰는 사람이 설마.. 이젠 없을텐데…??
과연 그럴까요…
그리고 PDO 사용 여부 이외에도 PHP API 자체가 정신 나간 부분이 한둘이 아니라서요.
음 이글을 적을 시간에 소프트웨어 아키텍쳐를 조금더 공부해 보시길 공부가 부족하면 가지만 보는 법입니다.
PHP 자체 추상화 레이어가 끔찍한 것과 애플리케이션의 아키텍쳐는 다르죠….
퀄리티 낮은 댓글이 유입되는 것을 보니 이제 이 글의 코멘트를 닫을 때가 온 것 같군요.
저는 이 글 코멘트를 응대하는 것 이외에도 할 일이 많고, 오만곳에서 PHP옹호자들이 기어올라와서 이 글 다시 끌어올려지는 거도 이제 귀찮군요.
코멘트 닫겠습니다.