댓글 검색 목록

[php] PHP를 싫어하는 멍청한 이유

페이지 정보

작성자 운영자 작성일 20-06-12 15:44 조회 905 댓글 0

PHP는 최근에 처음 소개 된 이래 25 주년을 맞았습니다. 오늘날에도 여전히 많은 인터넷 조각을 사용하고 있다는 점에서 상당히 큰 성과입니다. 

나는 새롭고 다른 것들로 옮겨 가면서 더 이상 많은 PHP를 직접 작성하지는 않지만 PHP에 대단히 감사합니다. 프로그래밍을 배우고 배우기 위해 실제로 투자 한 최초의 "실제"프로그래밍 언어 중 하나였습니다. 

나는 실제 사물과 함께 웹 사이트를 만들었고, 한동안 커뮤니티에 참여했습니다. Composer와 Packagist의 등장이 노화 된 PEAR을 대체하는 것을 보았습니다. 나는 PHP 7의 출시와 그 이전의 PHP 7과 관련된 모든 작업을 보았습니다.


https://stephencoakley.com/2020/06/10/dumb-reasons-to-hate-php 


인터넷에서 PHP에 관해 이야기 할 때마다 사람들은 빠르게 갈퀴를 잡고 만트라처럼 반복해서 PHP에 대한 동일한 고전적인 비판을 되풀이합니다. 

기분이 우수합니까? 그들은 공공 서비스를 하고 있다고 생각합니까? 모르겠어요 내가 아는 것은 그들이 어느 정도 옳다는 것입니다. PHP는 시간이 지남에 따라 유기적이고 점진적으로 변화했기 때문에 어떤 방법으로도 가장 잘 설계된 언어가 아닙니다. PHP가 그 어느 때보다 인기를 끌지 못하게 막지는 못했습니다.


PHP가 많은 유스 케이스에 가장 적합한 언어가 아닌 많은 이유와 다른 언어가 우수한 이유가 있습니다. 나는 나 자신이 그것에 대해 매우 경험이 있다고 생각하므로 경험에서 말합니다. 다음은 메모리에서 가져온 몇 가지 예입니다.


  • 표준 라이브러리는 상당히 완벽하지만, PHP가 네임 스페이스 나 클래스와 같은 것들을 갖기 전에 만들어 졌기 때문에 API 디자인에 대한 현대식 PHP의 모범 사례를 실제로 따르지 않습니다. 결과적으로 현대적인 패키지와의 연결이 끊어지고 이상한 스타일의 조합이 사라지지 않습니다.
  • 표준 라이브러리는 또한 이전 버전과의 호환성을 중요하게 생각합니다. 이는 좋은 일이지만 양날의 칼이기도 합니다. 더 이상 사용되지 않거나 일반적으로 고품질 타사 패키지를 위해 사용되지 않는 많은 API 및 확장이 있습니다.
  • 모든 클래스 파일이 <? php로 시작한다는 사실은 PHP가 원래 HTML 전 처리기였으며 항상 다른 파일 형식의 컨텍스트 내에서 실행됨을 상기시킵니다. 의미가 있지만, PHP에 HTML을 포함 시키는 것이 전용 템플릿 언어를 대신하는 많은 프레임 워크에서 전혀 수행되지 않기 때문에 특이하고 이상합니다.

아마도 다른 것들이 있을 수 있지만 이것들은 상자에서 즉시 작동하고 웹 개발을 위한 편리한 기능을 많이 갖춘 것으로 좋아하는 PHP를 기억하지 못하게 합니다.


그러나 이상한 점은 사람들이 이와 같은 합리적인 불만 대신 사람들이 이해하지 못하거나 사실이 아니거나 단순히 어리석은 불만을 제시한다는 점입니다. 내가 본 커플을 보자.


문법은 이상하고 구식입니다! 


이 불만은 실제로 의미가 없습니다. PHP의 구문은 C (작성된 C)에서 많은 영향을 받고 많은 것들을 빌려옵니다. 

실제로 C 구문의 언어에 있는 대부분의 언어와 잘 맞습니다. 점 연산자를-> ((* struct_ptr) .field와 같은 C에서 해제)로 바꾸고 모든 변수 앞에 $sigil을 붙이십시오. JavaScript조차도 닫히고 현대적인 편의를 제공하는 지루한 전통적인 클래스 구문이 있습니다.


물론, sigils는 아마도 Perl을 생각 나게 할 것이지만 걱정하지 마십시오. Perl과 같은 데이터 유형에 미친 영향은 없습니다. 변수 이름의 일부로 생각하면 괜찮을 것입니다.


@ 연산자와 같은 \와 네임 스페이스 구분 기호로 \를 사용하는 것과 같은 구문에는 PHP 고유의 이상한 점이 있지만 실제로 나에게 작은 사소한 것처럼 보입니다.


모듈식이 아닙니다! 


이런 종류의 불만은 정말 성가시며, 분명한 질문이 있을 수 있습니다. 일반적으로 사람들은 두 가지 중 하나를 의미합니다.

  1. 모든 것은 모듈 식 분리 없이 글로벌 네임 스페이스에 있습니다.
  2. 코드를 패키징하는 모듈 방식은 없습니다.

이제 두 가지 모두 뻔뻔하게 거짓입니다. 첫 번째는 쉽다 : PHP는 자바, C #, 또는 당신과 같은 네임 스페이스를 가지고 있다. 그리고 2009 년에 릴리스 된 버전 5.3의 언어에 추가되었습니다! 공평하게 말하면, 이전에 네임 스페이스를 사용하지 않는 WordPress와 같은 초기에 설계된 많은 코드베이스가 여전히 존재하며 여기에는 표준 라이브러리 자체가 포함됩니다. 그러나 일반적으로 네임 스페이스는 한동안 채택되어 왔으며 최신 PHP 코드베이스는 잘 사용합니다.


두 번째 불만도 거짓이지만 그 안에 진실의 씨앗이 있습니다. 오늘날, PHP는 앞서 언급 한 Packagist를 가지고 있으며, 재사용 가능한 모듈 식 패키지의 톤이 많습니다. 자신도 게시하기가 매우 쉽습니다! 그러나 Packagist와 Composer가 PEAR를 사용하기 전에는 사용이 좌절되었고 사람들이 타사 구성 요소를 만들거나 사용하지 못하게 할 수 있었습니다. 따라서 이 불만은 아마도 2012 년에 집으로 돌아 갔을 것입니다. 그러나 오늘날에는 실제로 잘못된 정보가 있습니다.


제쳐두고, 나는 Composer가 존재하는 것뿐만 아니라 사용하기에 좋은 잘 디자인 된 패키지 관리자라고 언급하고 싶다. 필자가 사용한 대부분의 언어에 대한 사실상의 패키지 관리자보다 더 의미가 있습니다. 내가 더 좋아한다고 생각한 것은 Cargo뿐입니다.


정말 느립니다! 


이것은 아마도 진실의 커널을 기반으로 하는 뿌리 깊은 것입니다. 원래 PHP는 공통 게이트웨이 인터페이스 (Common Gateway Interface) 또는 CGI를 통해 작동했습니다. CGI는 기본적으로 하위 프로세스를 호출하고 표준 출력을 HTTP 응답으로 사용하는 표준화 된 방법입니다.


CGI는 매 요청마다 완전히 새로운 프로세스를 생성하기 때문에 속도가 느립니다. 처음 소개되었을 때 큰 문제는 아니었고 솔직히 CGI의 단순성과 이식성을 그리워했습니다. 현대 IPC에 해당하는 것은 표준 파이프보다 JSON-RPC를 사용하고 있다고 생각합니다. 어쨌든 성능의 주제로 돌아갑니다.


CGI의 속도 저하를 해결하기 위해 채택되어 매우 인기를 얻은 한 가지 접근 방식은 스크립트를 실행하기 위해 하나 이상의 PHP 인터프리터 인스턴스를 항상 초기화 된 상태로 유지할 수 있는 방식으로 PHP를 웹 서버에 통합하는 것입니다. 새로운 프로세스를 생성하거나 각 요청에 대해 인터프리터를 초기화 할 필요가 없습니다. Apache HTTP Server는 이를 수행하는 mod_php 모듈에 매우 인기가 있습니다.


또 다른 방법은 FastCGI라는 것을 사용하는 것입니다. FastCGI는 CGI와 관련이 있는 것은 응용 프로그램과 웹 서버를 통합하는 것입니다. 하위 프로세스 대신 FastCGI는 웹 서버가 데몬 화 된 응용 프로그램과 통신하여 요청을 처리 할 수 있는 빠른 이진 프로토콜입니다. 이 접근 방식은 응용 프로그램을 웹 서버로 만드는 일반적인 최신 솔루션과 거의 유사하며 (또한 PHP에서도 가능) php-fpm을 통해 PHP를 배포하는 일반적인 방법이기도 합니다.


이 두 가지 방법 모두 새로운 프로세스 생성 및 요청마다 PHP 초기화와 같은 낭비적인 단계를 제거하여 성능을 향상 시켰습니다. 말할 필요도 없이, 일반 CGI는 이러한 대안을 위해 대부분 버려졌습니다. 그러나 이 두 가지 모델 모두에서 PHP 스크립트는 여전히 수명이 짧기 때문에 모든 것이 이것으로 해결되는 것은 아닙니다. 요청하는 동안 생성 한 모든 변수 또는 리소스는 요청이 끝날 때 정리됩니다. 사소한 코드의 경우 각 요청마다 많은 중복 작업이 발생합니다. 이는 특히 프레임 워크가 큰 경우 속도 저하의 원인입니다.


놀랍게도, 이것은 항상 중요하지 않습니다. PHP는 빠르기 때문에 믿거나 말거나 하지 않기 때문입니다. 통역 되는 언어의 본질을 고려할 때 비즈니스보다 훨씬 빠릅니다. PHP 7의 큰 부분 중 하나는 핵심 언어의 성능을 크게 향상 시킨 내부 Zend 엔진의 리팩토링이었습니다. 일반적으로 Python 및 Ruby와 같은 언어보다 성능이 뛰어납니다. PHP 7이 처음 릴리스되었을 때 Node.js는 일부 벤치 마크에서 Node.js보다 성능이 뛰어 났지만 그 이후 Node.js는 Google이 V8 엔진에서 수행하는 모든 지속적인 최적화로 PHP를 통과했습니다.


전반적인 성능을 향상 시키기 위해 PHP는 요청에 걸쳐 지속되는 영구 데이터베이스 연결을 제공합니다. 데이터베이스에 연결하는 것은 스크립트 속도가 느린 시간의 99 %입니다. 그리고 스크립트를 반복해서 파싱하는 것을 피하기 위해 PHP는 각 스크립트의 "컴파일 된"opcode를 캐시하는 opcache와 함께 제공되어 후속 요청에서 직접 실행될 수 있습니다.


Amp와 같은 흥미로운 프로젝트도 있습니다. 놀랍게도 잘 수행되는 Node.js 모델과 유사하게 PHP 응용 프로그램에서 중개인을 제거하고 웹 서버를 직접 실행하여 PHP의 핵심 인터프리터 성능을 활용합니다.


파이썬과 루비는 어떤 식으로든 블록에서 가장 빠른 아이들은 아니지만 일반적으로 그로 인해 낙담하지는 않습니다. 따라서 파이썬의 성능이 당신을 귀찮게 하지 않으면 PHP는 반드시 그렇게 해서는 안됩니다.


이 의견들 중 어느 것도 실제로 PHP에 대한 주장이 아닙니다. 앞서 언급 했듯이, Rust와 C #, 개인적으로 그리고 Java와 같은 다른 것들에 찬성하여 더 이상 PHP를 쓰지 않습니다. 이것은 바보 같은 주장을 해부하고 악마의 옹호자를 하는 것이 었습니다.






댓글목록 0

등록된 댓글이 없습니다.

웹학교 로고

온라인 코딩학교

코리아뉴스 2001 - , All right reserved.