:: 게시판
:: 이전 게시판
|
- 자유 주제로 사용할 수 있는 게시판입니다.
- 토론 게시판의 용도를 겸합니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
19/06/18 20:43
생산성이라는 측면에서 정말 좋은 언어죠.
다만, 본문에 쓰신 거처럼 만든 사람의 손을 좀 많이 타는 거 같아요. 잘하는 개발자들은 심플하고 정갈하게 잘 만드는데, 반대로 스파게티 반죽이 되는 경우도 많더군요.
19/06/18 20:46
만들때 생각 잘하고 만들어야 하긴 합니다. 예전에 생겼던 악평에는 이것도 한몫했을것 같긴 해요. 어디 기관이나 학원에서 속성교육 받고 온 사람이 건들면 십중팔구 개판될 가능성이 크긴 했으니깐요. 입출력관리부터 안되죠. 그러면 그 유명하고 보편적이고 개나소나 다하는 3대 해킹으로 그냥 해먹는...
19/06/18 23:13
생산성 좋은 언어 인정
개발자들 사이에서 php까기가 유행 했고, 일관성 없이 막 만든느낌이지만 생산성이 높아 가치 있는 언어라 생각합니다. 저는 집에서 개인프로젝트로 빠르게 막 만드는데 쓰고 있네요.
19/06/18 23:51
소수정예로 (특히) 웹을 제작할때는 최고의 언어 중 하나라고 생각합니다.
다만, 개발자의 질이 균일하지 않은 대규모 프로젝트에서는 아무래도 불안한 면이 많은 언어이기도 하구요.
19/06/18 20:52
말단 초보개발자(개발자는 커녕 코더수준)라 회사에서 주는데로 하는 입장이지만, 라라벨로 되어있는 프로젝트 진행중인데 웹상에서 그렇게 욕먹는 이유는 잘 모르겠습니다.
파이썬으로 입문해서 변수라든가 이거저거 치는게 조금 귀찮긴 한데 결국 하는건 똑같으니까요. 경력 쌓이고 설계하는 입장이면 또 모르겠네요...
19/06/18 20:55
그런건 있습니다. 인터프리터가 해석단계에서 빡빡하게 강제하고 오류뿜어대는게 별로 없어서, 실력 부족한 사람은 잘못짜놓고도 오류를 감지 못하는건 있어요. 그게 쌓이고 쌓이면 프로그램이 개판되긴 합니다.
19/06/18 20:53
php가 한물 간 이유는 npm이나 pip같은 서브파티를 끌어쓰는 면 때문이었던거 같은데
요즘은 좀 개선되었나요? 한때 code igniter로 개발 많이했었는데..
19/06/18 21:00
저는 처음부터 서드파티의 필요성을 못느껴서 상관 없었지만, 요즘 php에는 노드의 npm에 대응하는물건이 composer라는게 있습니다. 저도 사용은 안해봐서 자세히는 모르지만, xe3에서 라라벨프레임웤하고 이 컴포저를 같이 쓰더군요. 아니 라라벨 프레임웤 자체가 컴포저 쓰는걸 전제로 되어있던가... 기억이좀 가물하네요.
19/06/18 20:59
보통 이런분들이 코드로 예술을 하는 분들이던데.. 남들이 절대 이해할수 없는 예술..
인클루드 리콰이어의 '예술'이라고 하는 순간 느낌이 팍 오네요
19/06/18 21:06
이게 약간 파이프연결 게임 같은겁니다. 파이프 잘 연결해서 최소한의 파이프로 최대한 안전하고 최대한 효율적인 물길만들기 같은거요. 파이프 관리자도 번거거롭지 않고 최대한 편하게 관리할 수 있는.
19/06/18 21:11
PHP가 욕 먹는 이유는 아직도 옛날 코드에 안주하고 있는 (2019년에 PHP 5 환경에 맞춰서 만든 프로젝트를 누가 주면 솔직히 화가 납니다...) 발전하지 못하고 있는 다수의 양산형 코더들 탓이 크다고 봅니다. PHP로 누가 만든 프로젝트 유지보수를 좀 해달라고 해서 아는 사람이라 거절하기도 뭣해서 봤더니... 한 10년 전 쯤에서 타임머신 타고 온 듯한 코드에 사용자 패스워드 암호화는 밥 말아먹었거나 MD5를 쓰는 데 그치고... PHP 7.3에선 (패스워드 암호화를 위한 함수로 몇년 전부터 부상한) Argon2도 이제 내장으로 지원하는 시대가 되었는데 MD5라니!
각설하고, 프레임워크의 파편화야 Laravel (우리나라에선 코드이그나이터가 인기가 꽤 있어 보이지만) 부터는 많이 개선이 된 거 같고... 저도 PHP가 쓸데없이 저평가되었다고 생각합니다. 충분히 좋은 물건입니다. 다만, 일단 본문과는 별개로... 저는 프로그래밍 언어에서 이거야말로 내가 찾던 그것이라는 감동(?)을 받은 건 Go를 접했을 때입니다. 지금은 주로 쓰는 게 완전히 Go로 넘어왔네요. 현실적으론 자바스크립트(node.js 포함)도 많이 쓰기는 합니다만...
19/06/18 21:15
아마 php5 환경 자체보단, 2000년대초의 무개념한 시절 구조와 코드가 그대로 있어서 문제일겁니다. 모르긴 몰라도 십중팔구 입출력 관리부터 안되는 상태일 거에요.
19/06/18 21:14
다른 언어도 쓰시나요?? PHp 쓰다가 다른 언어로 넘어온 뒤에서야 아~ 이래서 php가 욕 먹었구나라고 개닫게 되었습니다.
19/06/18 21:16
자바(순수 자바와 안드로이드 모두)도 하고 노드도 합니다. 요새는 안드로이드가 코틀린으로 갈아탄다고 해서 그거 익힌다고 고생 중입니다. ASP클래식(닷넷 말고)도 했었는데...
그래도 게중에 php를 제일 많이 알고 제일 많이 익숙합니다. 그래서 이런 개똥철학도 늘어놓을 수 있죠.
19/06/18 21:21
몇년 전에 조금 맛만 봤었는데, 사용할 기회가 없어서 잊혀졌습니다. 아마 필요할 때가 오면 또 익혀서 써야겠죠. 흐흐.
당시에 제가 루비, 파이선, 펄 이런거 쫘악 학습할 계획도 세워놓고 그랬었는데, 살다보니 흐지부지 되었네요. 항참 웹표준, 웹 호환성, 웹접근성, 가장 적합한 언어... 이런거 관심있을때라...
19/06/18 21:27
개발 속도의 (좋은 방향으로의)위엄과 동시에 개발 유지보수의 (나쁜 방향으로의)위엄이 양 극단적이라 평이 유독 안 좋은것 같습니다... ㅠㅠ
장고 추천드려요! 장고도 굉장히 개발속도가 빠르답니다.
19/06/18 21:32
개발속도낸답시고 냅다 만들면 십중팔구 망하는 언어이긴 하죠. 급할수록 오히려 최소한의 입출력 구조라도 생각 많이 해서 설계해 놓으면 결국 코드는 굉장히 적게 쓰고 앞으로가 편해지는데 그렇게 하기까지가 쉽지 않죠.
장고 고려리스트에 올려놓겠습니다. 어디선가 한번 보긴 했는데, 드장고라고 읽었던 기억이 있네요. 흐흐
19/06/18 22:59
해당 프레임웤들의 유명세를 보니, 제가 앞으로 파이썬하고 루비를 손대야 할 때가 오면 그때는 싫든 좋든 찾아보게 될것 같긴 합니다. 흐흐
19/06/18 21:56
저는 PHP가 참 싫습니다. 왜 흥했는지는 알겠지만, php config 파일에 따라 함수 행동도 바뀌고 뭔가 컨트롤 해서 짜기도 힘들고... 간단한 사이트는 프레임워크 따로 설치할 필요 없이 쉽게 민들 수 있어서 좋은건 알겠지만, 저는 그런 경우에도 차라리 flask에 jinja2로 하는게 더 편하더라고요. 뭐 사실 웹쪽을 주로 하는건 아니라 그럴 경우도 전혀 없지만.
19/06/18 22:06
업데이트 안되고 있던 잃어버린 십년동안 말씀하신 동작이 일관되지 못한 것도 상당히 감점요소가 되었을것 같긴 합니다. 프로그램은 짜야되는데 서버 설정을 못건드리는 상황이면 뭣같죠. 코드 다바꿔야되고.
19/06/18 22:36
제가 알아서 구조짜고 컨트롤 할 줄 안다는 가정 하에 저는 좋아합니다. 물론 절대 아이고 쉽다 하면서 냅다짜면 안되는 언어죠. 당장 다루기가 쉬운거지, 프로그래밍 방법론이 쉬운게 아니니깐요. 사용자입력을 아예 안받을거면 모르지만.
그나저나 제이쿼리는 프론트엔드용 자바스크립트로 만든 프레임웤으로 아는데, PHP와는 비교대상이 아닌것 같습니다.
19/06/18 22:44
그러한 강제로 통제해주는 편의성이 없는것을 많이들 싫어하시긴 해요. 그런데 저는 좋아합니다. 프로그래밍 방법론에 충실하게 구조를 만들고 구현 한다면, 결국 별 상관 없거든요.
19/06/18 23:12
강제해주는게 없다면 결국 스스로 해야되는 부분이 많다는 뜻인데, 그게 좋게 말하면 자유도가 높다는 거지만 바꿔말하면
남의 코드를 유지보수해야되는 입장에서는 헬일수 밖에 없습니다. 유지보수 하려면 먼저 짠사람의 코딩스타일부터 마음속까지 들여다 볼 수밖에 없거든요.. 근데 그게 다른 언어 쓴다고 안되는것도 아니구요..
19/06/18 23:21
예. 저는 좋아합니다. 어디까지나 제 경우인데요.
어차피 남의 코드는 천천히 역추적 해가며 신중하게 읽어야 하는데, 그렇게 해보니 저는 결국 분석 자체는 별 상관은 없었습니다. 관심법으로 넘겨집지만 않으면 되죠. 물론 프로그램 스타일 따라 쉽고 어렵고는 있었지만, 어차피 변수 이름을 뭘 쓰든 함수 이름을 뭘 쓰든 그런것까지 강제하는 언어는 없는걸로 압니다. 결국 차이 없다고 생각해요. 자바(안드로이드 포함)나 자바스크립트(노드 포함)에서 남의 코드 본 경험으로도 그렇고. 또 직접 이런 저런 스타일 시도해본 경험으로도 그렇고. 오히려 분석 후에 개조할때 문제인 경우가 많았는데, 이건 프로그래밍 방법론에 상관없이 그때그때 눈앞의 결론만 도출하려고 막 짜놓은 옛날식 양산형 코드때문이었습니다. 이런건 재수없음 고칠때 일이 한 열배로 늘어날 수도 있으니깐요. 입출력이 기능마다 다로 논다든지... 일관된 변수 하나만 써도 될텐데 굳이 거기서 또 새로운 중복 연산과 변수를 만들어서 거기서만 쓰고 치운다든 난무하는 전역변수 때문에 교란이 심하고... 뭐 이런경우요.
19/06/18 23:03
아직 php로 회사 다닌지 2년도 안되었지만, 심플하고 정갈한 코드를 만들고 싶은 꿈은 있습니다.
php 이야기 하면 안좋은 이야기가 많은데 좋다는 이야기를 보고 더 많이 접하고 공부를 많이 해야겠다는 생각을 다짐하게 되었습니다. 짧은 글이지만 저에게 동기부여를 해주셔서 감사합니다!
19/06/18 23:26
현직 php4~php7 모두 다루고있는 개발자입니다..
php4까지는 사실 프로그래밍언어라고 불리기에도 민망할정도고, 클래스에 게터 세터도 못 만드는 언어로 유지보수하느라 아직도 고통받고 있습니다. 앞으로도 평생 이걸로 밥벌이하고 살아야하지만 여전히 저는 php를 매우 싫어합니다. 왜냐하면 적어도 php5까지는 협업이 매우 불편한 언어이기 때문이거든요. 만든사람이 아니면 도저히 파악이 힘든 require구조, get,post, 전역변수가 마구 뒤섞여 예측이 불가능한 변수구조, 같은이름의 함수임에도 버전별로 작동이 다른 내장함수들.... 그럼에도 불구하고 당장은 잘 작동하니까, 일시키는 사람 입장에서는 제정신박힌 개발자를 마치 공수나 늘려 편하게 일하려하는 나쁜놈으로 보이게해서 팀웍을 해치고.. php7이 나오고 이제서야 타 언어들처럼 일할수 있게 되었지만 이미 php를 전사적으로 도입했던 회사들은 과거의 방식과 관념에 사로잡혀 개발자가 이를 개선하기 위해선 자기 밥줄까지 걸거나 아님 실력없는 개발자로 낙인찍혀 쫒겨나거나 할 수 밖에 없는 상황이 php를 비난하게 만드는 요인이죠. 저도 현직장에 입사한지 얼마 안되었지만 서비스규모에 비해서 실력있는 개발자도 아무도 안남아있고(도망가고) 그나마도 들어왔던 사람들 코드보고 기겁해서 다음날 도망간 사람이 수두룩합니다. 나름 업계 빅3인데도 불구하구요.
19/06/18 23:32
아 흥미가 생깁니다. 다른건 무슨 말인지 알 것 같은데, "만든사람이 아니면 도저히 파악이 힘든 require구조"는 어떤 경우를 말씀하시는지 좀 들어봐도 될까요?
19/06/18 23:37
타 언어가 외부 파일에 선언된 함수나 클래스, 변수사용을
위해서는 최소한 import문에 명시적 선언이 '가능'한 반면, php의 require는 해당 파일에 뭐가 있는지, 어떤게 내가 새로 짠 코드에 영향을 미칠지 예측가능하게 할 수 있는 방법이 없죠. 자바를 예로 들면 제가 학부에서 자바를 배울 땐 import에 * 로 모듈들 로드하는 것을 지양해라와 같은 규칙(성능문제도 있겠습니다만)을 학습시켰습니다만, php를 배워오는 사람은 그런 학습이 없고, 또 가능하지도 않으니까요. 이게 만들땐 못느끼지만, 나중에 협업할 땐 오히려 개발속도를 더디게하는 일종의 기술적 부채가 됩니다.
19/06/18 23:48
같은 스크립트 언어인 파이썬의 경우 생각해보면 이해가 쉬우실 듯 합니다. 파이썬은 다른파일의 변수, 함수, 클래스를 사용하려면 명시적으로 임포트해줘야하고 그렇지않으면 서로 영향을 안미치니 규모가 커짐에 따라 발생하는 사이드이펙트도 선형적으로 증가하죠. 그러나 php의 경우에는 일단 require된 모든 부분을 새로운 로직작성할 때 마다 다시 검토해줘야하고, 규모가 개인이 이해할 수 없을 정도로 커지면 이 예측마저 불가능해집니다. 그러니 임시방편으로 function_exist가 난무하고, 변수에는 내가 넣지 않은 값이 들어가있고.. 코드짜기보다 xdebug 돌리고 에코찍는 시간이 더 길어지는 기술적부채가 쌓인다는 의미입니다.
19/06/18 23:51
그렇죠. 맞아요. 그렇게 개념없이 만들어진 프로그램이 많긴 해요. 뭔이야긴지 이해했습니다. 파일에 있는 내용은 무조건 통째로 가져오기때문에 구조 잘못짜면 그렇게 되죠.
19/06/18 23:52
맞습니다. 파일 내용 다가져 옵니다.
애초에 PHP는 HTML이나 자바스크립트 다루듯 시작한 물건이라서요. 이게 php 프로그래밍 방법론이 정립되고 나서는 처음부터 구조를 저렇게 안짜기도 하고, 좋은 프레임웤도 나와서 괜찮은데, 예전 웹프로그램 초창기부터 아무런 개념도 없이 막만든 물건이 엑티브 엑스처럼 넘쳐나는게 현실이죠.
19/06/18 23:55
흠 그런거면 방법론이 아니라 언어에 문제가 있는거 맞는 것 같은데요.
자바스크립트 진영도 이걸 모듈화 하려고 babel 까지 나왔으니까요. php7 에서는 해결이 되었나보군요..
19/06/19 00:01
컴파일러나 인터프리터가 어디까지 케어해줄거냐 하는거라 그것대로 품질평가할 일이고, 프로그래밍 방법론하고는 다른 문제니깐요. "이거는 컴파일러가 안잡으니까 이렇게 짜도 된다" 이런건 없죠.
그런데 저는 이런 자유도가 좋습니다. 흐흐. 어디까지나 지금까지 제가 커버 가능했기 떄문에 그런거겠죠.
19/06/19 00:10
닭장군 님//
우선 php를 모르는제가 잘못이해한거면 미리 죄송하다는 말씀을 드리면서... 저도 스크립트 언어로 먹고살아서 컴파일러가 캐어 안해주는건 특징이라고 생각을 해요. 근데 모듈화가 안되서 전역변수명을 다 체크해야한다면 잘못된거 맞다고 생각해요. 요즘은 특히 복잡한 모듈은 가져다 쓰는 시대인데, 가져다 쓸때 전역변수명 겹치면 안되잖아요.
19/06/19 00:16
keke 님// 그게 php5.4부터 네임스페이스 까지 지원되면서 지금은 해결됬긴 합니다. 라라벨도 그래서 php 5.4부터 지원하죠. 패키지 관리해야되는데 5.3까지는 네임스페이스가 안되서 클래스명에 어거지로 언더바넣어서 구분한다거나 했으니깐요. 솔직히 너무 늦은건 맞아요. 저는 별 영향 안받았지만...
19/06/19 00:02
제가 현재 있는 직장의 전임개발자가 코드이그나이터 커뮤니티에서 꽤 유명하신 분인데, 그 분 조차도 예전코드들은 클래스나 함수화도 안시키고 무자비하게 require문을 때려넣으셨더라구요. 전 이게 사람의 문제가 아니라 언어가 가진 문제라고 생각해요. 방법론을 떠나서 언어에서 그걸 지원하지 않거나, 너무 유연하게 만들어놓으면 그렇게 만들 수 밖에 없습니다. 개발은 개발자만 하는 것도 아니고 혼자 하는 것도 아니니까요...
과거 php논쟁이 있었을때는 도구쓰는 사람이 문제였다고 생각했습니다만, 지금은 생각이 많이 바뀌었습니다. 맥가이버칼로 작품을 만드는 사람도 있겠지만 결국엔 조각칼로 조각을 깍는게 멋진 작품이 나올 가능성을 훨씬 높혀줍니다. 과거 수십여명이 개발하던 걸 지금 저와 제 부사수 둘이서 유지보수하려니 php의 한계가 더 아쉽게 다가오네요....ㅠㅠ
19/06/19 00:14
프리랜서 입장에서는 일거리가 많아서 자바가 체고시다!
일거리도 많고 개발자도 득실득실하고. ^^; php 접할 기회가 없었는데 많이 좋아졌단 소릴 들으면 한먼 해보고 싶긴 합니다... 만 늙으니 너무 귀찮아지네요. 그냥 하던거 하다가 써주는데 없으면 그만 둬야할듯...
19/06/19 00:20
솔직히 제가 PHP4부터 7까지의 버전별 특성도 익숙하고 대응도 아는지라, 또 혼자 북치고 장구치고가 가능한지라 지금까지 별문제가 안되었지만, PHP7 전의 버전.. 좀 관대하게 잡아도 5.4전의 버전들은 부실하긴 해요. 저는 남이 만든 프로그램 유지보수하게 되면, 제가 전권을 얻어서 프레임웤식 구조 잡으면서 지금 유지보수 작업중인 기능만 그때그때 개조해서 새 프레임에 편입시키는 방법을 씁니다.
그러니까.. 윗분들 증언대로 PHP 옛날 프로그램은 손 안대는걸 추천합니다. 흐흐. 최소한 5.4이상에서 만든 것들이 관리하기 편합니다.
19/06/19 01:15
버전에 따른 차이는 ecma나 php나 개판인건 똑같...
한국은 모르지만, 미국이나 이스라엘 It업계쪽에서 php에 대한 인식은 modern php ok but java... 이런식의 대화였던걸로 기억합니다. 이스라엘에 위치한 미국계 금융사 it 쪽lab이다보니, 더 보수적인 시점을 가지는걸수도 있겠지만요. 흐흐.. 개인 페이지는 php배울겸 라라벨로 db랑 연동해서 해보니 너무 편하고 좋았습니다.
19/06/19 01:52
학교 졸업 후에 회사에서 C만 하다보니 이제 다른 랭귀지 쓰는게 무서워요...
이직생각도 없잖치만 그것도 무서워요... 구해주소서...
19/06/19 09:53
C만 잘하는 사람 뽑는 회사는 아주 많진 않겠지만 C를 잘하는 사람이 더 적을 것 같아서 구직/이직이 오히려 여유있지 않을까 싶은데 어떤가요?
19/06/19 11:29
요즘 잡포스팅을 보면 죄다 C++/Java나 Python/Ruby, js계열 등등.. C 쓰는 사람 구하는데는 정말 손에 꼽을 정도라서요.
뭐 사실 다시 공부하면 못할것까진 없겠지 싶지만.. 타성화가 너무 많이 진행된 것 같습니다 ㅠㅠ
19/06/19 11:27
C 하셨다면 다른 언어 익히는건 일도 아닙니다. 지긋지긋한 메모리 관리 안해도 되는것만 해도 어디인데요...
일단, 자바스크립트나 Go 같은 언어는 C와 문법이 대동소이하니 금새 배워질거에요.
19/06/19 11:31
사실 그건 그렇죠. Go도 잠깐 끄적여 본 적은 있는데 꽤 재미있게 잘 만들어지긴 했더라구요.
Go를 현업에서 많이 쓰나요? 나온지 얼마 안 되었을때 그냥 심심풀이로 잠깐 본 게 전부라..
19/06/19 11:41
아직까지 현업에서 많이 쓰이진 않긴 하는데, 점점 많이 사용될 분위기입니다.
아마 자바스크립트처럼 서드파티 라이브러리들이 활성화가 좀 돼야 쓰이지 않을까 싶네요. Node가 요즘 백엔드쪽에선 제일 핫한데, 자바스크립트 언어 자체의 장점보다는 바다같은 생태계가 주 원인인지라...
19/06/19 02:24
php 5.5 이상 과 그 이전은 다른 언어고 둘은 분리해서 생각해야합니다.
오히려 요즘 문제는 Legacy php의 위치를 Python이 가져간게 아닌가 싶습니다.
19/06/19 10:20
PHP 예찬론은 결국 7로 넘어가고 제대로 된 프레임워크를 쓰면 다른 언어 수준의 개발을 할 수 있어! 정도가 최대치라고 봅니다.
맞는 말이지만, PHP를 계속 쓸 이유는 될지 몰라도 PHP로 넘어갈 이유는 되지 못하다는 근본적인 한계는 있죠.
19/06/19 11:31
세상 어떤 언어든 개발자가 잘하면 다 좋은 언어죠.
저 같은 경우는 C/C++ 로 게임서버, 게임엔진 만드는걸로 개발질(...)을 시작해서, 자바, 파이선, 자바스크립트... 등등 만져본 언어가 제법 되는데, 솔까 세상에 C보다 구린 언어란 없습니다. 물론 진성 C프로그래머라면 시스템의 내장육부(?) 까지 다 헤집을 수 있는 강려크한 언어를 사용하는 프로그래머라는 자부심은 있습니다만...
19/06/19 13:24
굳이 따지자면 C는 어택땅 개념조차 없어서 일일히 하나씩 어택찍어야 하는 듄2나 워크래프트 1정도로 보시면 됩니다 크크
대신 섬세하게 하나하나 적절하게 타겟을 잡아 공격을 해서 최적화를 잘 시키는 경우에는 화력낭비가 거의없다(메모리 낭비가 거의 없다)는 것이 장점이지만 개발자 입장에서 그런 노가다보다는 그냥 어택땅이 더 편한거랑 비스무리한거죠.
19/06/19 13:32
적절하네요. 크크크...
한가지가 더 있죠. 스타 1은 윈도우 XP에 80486 PC에, 640 * 480 해상도에서도 잘 돌아감. 스타 2는 3D 가속카드가 없으면 실행조차 할 수 없음. 요즘 고급언어들이 각광받는 이유 중의 하나가, PC의 CPU/메모리의 비약적인 발전도 한몫 합니다. 파이썬이나 자바스크립트가 꽤 오래된 언어인데도 근래 각광받는 이유가, PC 성능이 언어의 떨어지는 퍼포먼스를 커버해주기 때문이죠.
19/06/19 14:13
뭐 저는 PHP 좋아하는 편이기는 한데,
그 이유가 cafe24 등에 있는 월 500원짜리 동전 웹호스팅에서도 기본 지원하는 언어라는 이유로 좋아합니다 =_= 요새는 C나 Python도 조금씩 지원하는 모양이던데 여전히 오로지 웹 언어로만 특화된 PHP가 그다지 대단한 프로젝트가 아닐 때에는 코드가 짧게 나와서 좋더라고요.
|