PHP는 최악의 프로그래밍 언어인가?

저는 거의 20년 동안 프로그래밍 경험을 갖고 있으며 다양한 프로그래밍 언어로 개발해 왔습니다. 제가 겪었던 많은 일과 지금 하고 있는 일에서 저는 PHP를 핵심 프로그래밍 언어로 사용하게 되어 매우 기쁩니다. PHP를 처음 접했을 때부터 PHP에 대한 온갖 불만을 들었지만 동시에 PHP의 위력도 보았습니다.

PHP는 적어도 흥미로운 프로그래밍 언어입니다. 언어와 이를 기반으로 구축된 프로그램은 일반적으로 두 가지 디자인 철학으로 나뉩니다. 여기서는 Waterfall이나 Agile과 같은 소프트웨어 개발 수명주기에 대해 말하는 것이 아니라 소프트웨어가 무엇이어야 하는지에 대한 기본 아이디어를 말하는 것입니다. 이러한 아이디어를 "올바른 길"과 "나쁠수록 좋다"라고 합니다.

PHP는 또 다른 다소 이상한 프로그래밍 언어입니다. 사람들이 언어가 "형편없다"고 불평하는 것은 틀린 것이 아닙니다. 실제로 이 언어에는 나쁜 점이 많이 있습니다. 옛날에는 언어에 더 심각한 문제가 있었습니다. PHP를 조롱하는 블로그 게시물 "PHP: 나쁜 디자인의 프랙탈"은 9년 전에 게시되었을 당시에는 오래되었지만 몇 가지 유효한 요점을 담고 있습니다.

그러나 동시에 개발자는 PHP를 사용하여 구조적으로 "올바른" 소프트웨어를 만들고 모범 사례로 간주되는 다른 언어의 철학을 가져올 수 있습니다. Laminas 및 Symfony와 같은 프레임워크는 객체 지향 프로그래밍의 모범 사례를 사용하므로 개발자는 이러한 프레임워크를 사용하여 구조적으로 올바른 코드를 작성할 수 있습니다.

PHP는 이를 어떻게 수행하나요? PHP는 최악의 프로그래밍 언어이기 때문입니다.

디자인 소프트웨어

1991년 Richard P. Gabriel은 "Lisp: Good News, Bad News, How to Win Big"(Lisp: Good News, Bad News, How to Win Big)이라는 기사를 발표했습니다. 이 기사에서는 소프트웨어 설계와 수명 측면에서 "나쁠수록 좋다"는 철학이 더 나은 선택이라는 주장을 펼치고 있습니다. 그는 "MIT/스탠포드 스타일" 또는 "올바른 방식"과 "뉴저지 스타일" 또는 "나쁠수록 좋다"라는 두 가지 프로그래밍 학교의 출현을 인식했기 때문에 이러한 결론에 도달했습니다.

두 가지 철학은 비슷한 목표를 가지고 있지만 핵심 영역이 다릅니다. 두 스타일 모두 철학 철학의 네 가지 주요 영역인 단순성, 정확성, 일관성 및 완전성에 중점을 둡니다.

MIT 스타일은 다음과 같이 설명됩니다.

• 단순성: 디자인은 구현이나 인터페이스에 관계없이 단순해야 합니다. 이에 비해 인터페이스를 단순하게 유지하는 것이 더 중요합니다.

• 정확성: 디자인은 관찰 가능한 모든 측면에서 정확해야 합니다. 잘못된 디자인을 만들려고 하지 마세요.

• 일관성: 디자인이 일관되지 않아야 합니다. 일관성을 보장하기 위해 단순성과 완전성을 약간 희생할 수 있습니다. 일관성과 정확성도 똑같이 중요합니다.

• 완전성: 디자인은 가능한 많은 중요한 상황을 다루어야 합니다. 예상되는 모든 상황을 다루어야 합니다. 단순함보다 완성도가 우선되어야 합니다.

뉴저지 스타일의 경우 Gabriel은 목표를 다음과 같이 정의한다고 말했습니다.

• 단순성: 구현이든 인터페이스이든 디자인은 단순해야 합니다. 이에 비해 구현을 단순하게 유지하는 것이 더 중요합니다. 단순함이 가장 중요하며 단순함을 유지하는 것만큼 중요한 기능은 없습니다.

• 정확성: 디자인은 관찰 가능한 모든 측면에서 정확해야 합니다. 그러나 단순성을 위해 정확성이 약간 희생될 수 있습니다.

• 일관성: 디자인이 너무 일관성이 없어야 합니다. 어떤 경우에는 단순성을 위해 일관성이 희생될 수 있습니다. 디자인에 비정상적인 상황을 도입하면 구현이 복잡하거나 일관성이 없게 될 수 있으므로 고려하지 마세요.

• 완전성: 디자인은 가능한 많은 중요한 상황을 다루어야 합니다. 예상되는 모든 상황을 다루어야 합니다. 성실성은 다른 특성에도 영향을 미칠 수 있습니다. 실제로 구현 단순성이 위협받으면 완전성은 희생되어야 합니다. 일을 단순하게 유지하려면 완전성을 위해 일관성을 희생할 수 있습니다. 특히 인터페이스 일관성을 희생할 수 있습니다.

이 논쟁의 핵심은 "나쁜 것이 더 나은" 이유에 대한 예로 LISP와 C를 사용하는 것입니다. LISP 프로그래머 Gabriel에게 LISP는 C보다 빠르고 C만큼 빠른 언어이며 Common LISP는 설계, 개발 및 표준화하는 데 수년이 걸렸습니다. 언어를 정의하는 사양은 다양한 LISP 중 최고를 활용하며 최신 개발 환경은 LISP 개발자에게 가장 적합합니다.

LISP가 올바른 방법입니다

LISP는 소프트웨어 개발의 "올바른 방법"을 나타냅니다. LISP는 상호작용하기 쉽고 다양한 방식으로 상호작용할 수 있습니다. Fortran에서 LISP를 호출하고 싶으신가요? Fortran에서 LISP를 호출하여 데이터를 전달할 수 있으며 그 반대의 경우도 마찬가지입니다. 레거시 코드로 작업할 때 LISP의 최신 "고급" 기능을 모두 즐겁게 사용할 수 있습니다.

LISP는 사양 덕분에 일관된 디자인을 가지고 있습니다. Python과 같은 최신 언어를 살펴보면 사양은 여러 백엔드와 컴파일러를 제공하는 데 큰 도움이 되며 모두 동일한 방식으로 코드를 해석하거나 컴파일합니다. 도구는 최고 수준이었고, 1991년의 LISP는 단계 디버깅, 데이터 검사, 고급 편집기 등 오늘날 우리가 여전히 누리고 있는 모든 편의 기능을 갖추고 있었습니다.

언어로서 LISP는 완성되었습니다. 고급 객체 지향 프로그래밍 계층, 다중 상속, 일류 객체, 함수 및 유형이 특징입니다. LISP는 프로그래밍 언어 개발자가 염두에 두고 있는 것 같습니다.

1991년에는 LISP와 같은 프로그래밍 언어가 아마도 역대 최고의 형태였을 것입니다. 이러한 기술적 정확성은 실제 사용을 통해 입증되지 않았습니다. LISP 개발자가 감소하고 있습니다. LISP의 외부 평판은 수년간의 부정적인 언론과 잘못된 포지셔닝으로 인해 훼손되었습니다. 사람들은 더 이상 이를 최종 사용자에게 소프트웨어를 전달하는 방법으로 생각하지 않습니다.

개발 측면에서 LISP는 BDUF(Big Design Up Front)와 동일한 이상을 나타내는 경우가 많습니다. 폭포 모델과 같은 설계 방법을 사용해 본 적이 있다면 몇 가지 문제를 발견했을 것입니다. "올바른 방법"은 일관성, 정확성 및 생각할 수 있는 모든 문제를 고려하는 데 중점을 둡니다.

LISP 자체는 단일 언어가 아니라 언어 계열입니다. Common LISP는 표준으로 설계되었지만 수행해야 할 다양한 작업을 기반으로 LISP 자체의 구현이 존재합니다. Lockless Inc 웹사이트의 기사에서는 이 "조각화"가 LISP의 최종 실패를 결정하는 요인 중 하나로 지적합니다. LISP는 소프트웨어 설계의 "올바른 방식"을 고수하지만 이러한 단편화로 인해 코드 유지 관리 및 이식성이 손상됩니다.

C와 Unix는 잘못된 길입니다

동시에 Unix의 등장으로 인해 C 언어는 점차 소프트웨어 개발에 선호되는 방법이 되었습니다. C는 유닉스용으로 설계되었고, 유닉스는 C로 설계되었습니다. 개발자는 MIT의 LISP 및 작성자와 디자인 입장이 달랐습니다.

1972년에 C는 간단한 언어로 설계되었습니다. 1991년에는 약간의 변화가 있었지만 C 언어의 기본은 그대로였습니다. 개발자와 Unix의 요구를 충족하기 위해 일부 기능이 추가되었습니다. 언어가 단순하기 때문에 컴파일러와 프로그램을 작성하는 것은 쉽습니다. 언어가 복잡한 프로그래밍을 수행하는 데 방해가 되지는 않지만 C는 LISP에 비해 프로그래머에게 필요한 기능의 약 50-80%를 가지고 있습니다.

그러나 C 언어는 이식성이 매우 뛰어납니다. 또한 LISP 소프트웨어 및 환경에서 일반적으로 사용되는 것보다 저전력 하드웨어에서도 실행될 수 있습니다. 이 요소 덕분에 더 넓은 범위의 컴퓨터에서 소프트웨어를 컴파일하고 실행할 수 있습니다. C와 Unix는 사용하기 쉬우며 Gabriel은 Unix와 C가 널리 퍼질 것이라고 생각합니다.

C 언어는 Dennis Ritchie가 Unix를 설계하고 구축하는 동안 발전했습니다. 벨연구소는 공식적으로 컴퓨터 분야에 진출할 수 없었기 때문에 유닉스 역시 다양한 사용자에게 쉽게 배포될 수 있었다. 이러한 사용자는 자신의 필요에 맞게 Unix를 패치하는 데 도움을 줍니다. Dennis Ritchie는 이러한 요구 사항을 미리 생각할 필요 없이 필요에 따라 이러한 패치를 통합할 수 있었습니다.

LISP와 달리 C는 오늘날에도 여전히 많이 사용됩니다. PHP, JavaScript, Python과 같은 고급 해석 언어가 많은 개발자의 첫 번째 선택이지만 이러한 고급 언어 중 상당수는 C로 개발됩니다. Rust와 같은 경쟁자가 등장하기 시작하더라도 소형 저전력 장치에서 실행되는 능력은 여전히 ​​C 언어의 강점입니다.

PHP는 최악입니다

따라서 첫째, "나쁠수록 좋다"는 소프트웨어가 허용되고, 둘째, 사용자의 기대가 낮아지며, 셋째, 이러한 소프트웨어는 "최악의 상태에 가까워질 때까지 지속적으로 개선될 것입니다." 오른쪽 길로."

- Richard Gabriel

이 사실이 밝혀진 지 몇 년 후 Rasmus Lerdorf는 현재 PHP로 알려진 개인 홈페이지/양식 해석기 작업을 시작했습니다. PHP/FI는 홈페이지를 유지하고 양식 및 데이터베이스와 상호 작용해야 하는 Lerdorf의 요구에 따라 탄생했습니다. PHP/FI는 실제 프로그래밍 언어로 설계된 것이 아니라 C 언어 위에 스크립트와 함수의 레이어로 설계되었습니다.

PHP는 매우 간단합니다

구현이든 인터페이스이든 디자인은 단순해야 합니다.

PHP는 내부적으로 C 언어를 사용하는데, 우리는 이 부분이 "최악"이라고 이전에 말했습니다. 그러나 이는 또한 몇 가지 이점을 제공하며, 가장 중요하게는 확장을 더 쉽게 만드는 더 간단한 기본 언어입니다. Hack/HHVM은 C++에 더 가까운 접근 방식을 취하지만 PHP 자체는 여전히 C 언어입니다.

이 언어의 내부 구조를 배우는 데는 몇 시간 밖에 걸리지 않습니다. Elizabeth Smith는 PHP의 내부 작동에 대해 많은 내용을 다루는 PHP 확장에 대한 훌륭한 강연을 했습니다. 언어 자체는 읽기 쉬울 뿐만 아니라 다른 C 스타일 언어로 변환할 수도 있는 다른 C 스타일 언어를 사용합니다.

대부분의 PHP 인터페이스 또는 표준 라이브러리는 매우 간단합니다. 왜냐하면 대부분의 핵심 기능은 다양한 C 언어 라이브러리의 래퍼일 뿐이며 거의 변경되지 않은 상태로 노출되기 때문입니다. 이렇게 하면 인터페이스에 일부 불일치가 발생하기는 하지만 C 또는 C++를 사용하는 개발자에게는 친숙한 환경을 제공합니다.

PHP 언어는 웹 개발에 매우 ​​중점을 두고 있습니다. HTTP에서 개념을 추출하고 언어에서 유사한 개념을 찾는 것은 매우 간단한 경우가 많습니다. 요청의 헤더 정보를 알고 싶으십니까? get_headers()가 당신을 만족시킬 것입니다. 요청 정보를 얻는 것은 $_GET 및 $_POST 전역 변수를 읽는 것만큼 간단합니다.

PHP는 간단한 개발자 인터페이스를 유지하고 내부 구조를 최대한 단순하게 유지합니다.

PHP는 (거의) 맞습니다

관찰 가능한 모든 측면에서 디자인은 정확해야 합니다. 그러나 단순성을 위해 정확성이 약간 희생될 수 있습니다.

여기서 PHP는 올바른 것보다 "단순한 것"을 선택하는 경향이 있습니다. HHVM이 등장하기 전에는 언어의 모양과 기능이 표준화되지 않았습니다. Zend 인터프리터는 사양 자체이며 언어가 작동하는 방식은 항상 "올바릅니다"(실제 오류 제외). PHP 엔진을 다른 것으로 교체하려면 기존 엔진의 모든 기능을 구현해야 합니다.

LAX 함수 매개변수와 다양한 핵심 함수에 대한 반환 유형은 시스템 작업을 더 쉽게 만듭니다. strpos()와 같은 함수는 정수 또는 부울 값을 반환할 수 있는데, 이는 정수를 반환하거나 예외를 발생시키도록 엄격하게 설계된 메서드보다 처리하기가 약간 더 쉽습니다.

PHP 언어의 발전 과정을 보면 거의 모든 새로운 기능이 "잘못됐으니 고쳐야 한다"는 심각한 생각보다는 개발자가 필요로 하는 것에 기반을 두고 있습니다. 이러한 엄격한 유형 및 예외 오류에 더 중점을 두는 것이 작업을 수행하는 더 올바른 방법입니다. 그러나 개발자가 코드를 단순화하기 위해 사용하려는 짧은 화살표 함수, 속성 및 열거형과 같은 것들도 있습니다.

PHP에는 일관성이 필요하지 않습니다.

디자인이 너무 일관성이 없어야 합니다. 어떤 경우에는 단순성을 위해 일관성이 희생될 수 있습니다.

PHP가 일관성이 있다고 주장할 생각은 없지만, 충분히 일관성이 있습니다. 사람들은 배열 함수와 문자열 함수의 경우 needle/haystack 인수 순서에 대해 불평할 수 있습니다. 그러나 일반적으로 배열 함수는 일관성이 있고 문자열 함수도 일관성이 있습니다. 언어 내에서보다 기본 C 라이브러리와 일관성을 유지하는 것이 훨씬 간단합니다.

PHP는 다른 측면에서도 충분히 일관성이 있습니다. strpos()에서 언급한 것처럼, PHP는 오류가 발생한 함수에 대해 상당히 일관되게 FALSE를 반환하는 경향이 있습니다. 이는 반드시 정확하지는 않지만 일관성이 있습니다. 밑줄이 있는 함수 이름과 밑줄이 없는 함수 이름은 일반적으로 기본 라이브러리와 일치합니다.

PHP 언어는 단순성을 위해 일관성을 희생하지만, 이 사양이 없더라도 합리적인 부분에서는 여전히 일관성을 유지하려고 노력합니다.

PHP는 필요한 만큼 완벽합니다.

디자인은 가능한 한 많은 중요한 상황을 다루어야 합니다.

PHP는 가장 까다로운 디자인 작업인 웹 애플리케이션 작성이 필요할 때마다 완성됩니다. PHP는 프로그래밍 세계의 모든 문제에 적용할 수 있는 언어로 설계되지 않았습니다. 그럼에도 불구하고 그 단순성 덕분에 웹 외부에서도 사용할 수 있습니다. PHP의 원래 목적은 웹 프로그래밍을 위한 가장 기본적인 기능을 제공하는 것이었고 이러한 추세는 오늘날에도 계속되고 있습니다.

핵심 언어에 대한 수정은 종종 개발자의 요구에 따라 이루어집니다. 전체 커뮤니티가 수정 사항을 제안한 다음 커뮤니티는 새 기능을 거부, 변경 또는 승인할지 여부를 투표로 결정합니다. 언어의 많은 혁신은 작업을 신속하게 완료해야 하는 필요성에서 비롯되었습니다. 우리가 다른 언어의 기능을 흡수한다고 해도, 그것이 우리의 개발을 더 쉽게 만들어 주기 때문이고, 다른 언어가 "더 정확하게" 수행하기 때문인 경우는 거의 없습니다.

오늘은 PHP로 웹 애플리케이션을 개발할 수 있습니다. 지금으로부터 5년 후에도 몇 가지 새로운 기능만 추가하면 PHP로 웹 애플리케이션을 개발할 수 있습니다. 그러나 언어 자체의 무결성은 오늘날 필요한 것에 적합합니다. 나중에 필요한 경우 언제든지 언어를 수정하거나 새로운 기능을 추가할 수 있습니다.

더 나쁜 것이 더 좋은가요?

Gabriel은 "나쁠수록 좋다"는 철학이 보기에 좋지 않아 더 나은 선택으로 간주되어서는 안 되는 디자인을 의미한다는 점을 인정합니다. 유일한 문제는 그가 두 철학을 모두 볼 때 "더 나은 생존 특성을 가진" MIT/"올바른 방법" 디자인 철학에 비해 "나쁜 것이 더 낫다"는 것이 여전히 더 유연한 옵션이 된다는 것입니다. PHP를 보면 "나쁠수록 좋다"는 생각을 확인할 수 있습니다.

수년에 걸쳐 Gabriel은 어느 쪽이 더 나은지 고민했음을 인정합니다. PHP 커뮤니티에서는 일을 올바르게 해야 할지 아니면 계속 단순하게 해야 할지 논쟁을 벌여 왔습니다. 고전적인 컴퓨터 과학 방식으로 라이브러리를 구축하는 Laminas와 같은 프레임워크가 있고, 개발자 경험과 속도에 초점을 맞춘 Laravel과 같은 프레임워크가 있습니다. PHP 자체는 둘 다입니다.

다음에 누군가 PHP를 비판하는 소리를 듣게 된다면 그냥 내버려두세요. 언어가 정말 안 좋아요. 그러나 여러 면에서 PHP의 수명과 광범위한 사용은 "올바른 방법"으로 일을 하는 것이 항상 "최악의" 방법보다 나은 것은 아니라는 사실을 입증합니다. 누군가가 당신이 사용하고 있는 프레임워크에 대해 불평한다면 그것이 장기적으로 문제가 되지 않는다는 점을 이해하십시오. 자신에게 적합하다고 생각되는 디자인 철학을 선택하고, 나쁜 것이 실제로는 더 나을 수도 있다는 사실을 받아들이십시오.

원본 링크: https://www.phparch.com/2021/09/education-station-php-is-the-worst/

원작자: Chris Tankersley

저자 소개:

Chris Tankersley는 많은 역할: 남편, 아버지, 작가, 연사, 팟캐스트 진행자, PHP 개발자. Chris는 12년의 프로그래밍 경력 동안 다양한 프레임워크와 언어를 사용해왔지만 대부분의 시간을 PHP와 Python 작업에 보냅니다. 그는 Docker for Developers의 저자이며 회사 및 개발자와 협력하여 컨테이너를 워크플로에 통합합니다.

추천 학습: "PHP 비디오 튜토리얼"