자바에 대해 한마디 해주세요

기존 언어 중 좋은 추천이 무엇인지 묻는 분들이 계셨습니다. 나는 "자바"라고 말했습니다. 그들은 "뭐? 자바!"라고 말했습니다. 이제 설명하겠습니다.

Java는 자신을 저주했던 "동적 언어"를 모두 능가했습니다

아마도 젊은이들의 반항심 때문에 사람들은 입문 언어를 진지하게 받아들이지 않습니다. 아주 초기에는 컴퓨터 과학 학생들이 Scheme이나 Pascal을 사용하여 시작했습니다. 이제 대부분의 학교에서는 Java를 사용합니다. 이것이 바로 많은 사람들이 Java를 싫어하고 Java를 사용하는 사람들을 무시하는 이유일 것입니다. 자바라고 하면 할아버지 세대에서 쓰던 것 같은 느낌이 듭니다. 그들은 자바가 구식이고, 크고, 복잡하고, 비대하다고 말합니다.

어떤 Python 프로그래머는 포럼에서 Python의 이점을 초보자에게 설명합니다. 그 이유 중 하나는 다음과 같습니다. "Python은 Java가 아니기 때문입니다!" 타입을 작성할 필요가 없습니다..." Java에 대한 그들의 부당한 증오와 맹목적인 거부로 인해 Java의 중요한 이점을 보지 못하고 길을 잃었습니다. 추진력 측면에서는 우위에 있지만 실제로 프로그래밍 언어로서 Python은 Java와 완전히 경쟁할 수 없습니다.

성능면에서 Python은 Java보다 수십 배 느립니다. 정적 타이핑과 같은 중요한 기능이 부족하기 때문에 Python 코드에서는 버그를 감지하기 어렵고, 일단 감지되면 디버깅도 어렵습니다. 따라서 대규모의 복잡한 시스템을 구축하는 데 Python을 사용할 수는 없습니다. 일부 스타트업 기업의 메인 코드가 Python으로 작성되어 있는 것을 볼 수 있지만 이들 기업의 소프트웨어 품질은 실제로 상당히 낮습니다. 성숙한 회사에서 Python은 기껏해야 도구와 유사한 것 또는 시스템 안정성에 영향을 주지 않는 작은 스크립트를 작성하는 데에만 사용됩니다.

또한 정적 유형이 부족하여 Python에서 우수한 IDE 지원이 불가능하고 Python 코드를 완전히 안정적으로 리팩터링할 수 없습니다. PyCharm은 초기 Python 프로그래밍 환경에 비해 크게 개선되었습니다. 그러나 이론에 따르면 "변수 이름 변경"과 같은 기본 리팩터링 작업을 완전히 안정적으로 수행할 수는 없습니다.

디자인 측면에서 Python과 Ruby는 실제로 Java보다 훨씬 더 복잡합니다. 많은 중요한 기능이 누락되었으며 버그가 있는 "강력한 기능"이 훨씬 더 많습니다. 소위 "진정한 객체 지향" 접근 방식, 소위 "후기 바인딩"에 대한 맹목적인 찬사로 인해 이러한 언어에는 의미론으로 "오버로드"될 수 있는 곳이 너무 많습니다. 모든 것이 재정의될 수 있으므로 코드가 매우 복잡해집니다. Python 및 Ruby 코드는 쉽게 오용되고, 이해하기 어렵고, 지저분하고, 문제가 발생하기 쉽습니다.

많은 JavaScript 프로그래머들도 Java를 맹목적으로 경멸하지만 사실 JavaScript는 Python이나 Ruby보다 나쁩니다. 모든 단점이 있을 뿐만 아니라 기본 클래스 정의와 같은 필요하고 편리한 기능도 많이 부족합니다. JavaScript의 다양한 "WEB 프레임워크"가 속속 등장하고 있으며, 끊임없이 새로운 것을 선보이고 있는 것처럼 보이지만 사실은 모두 어둠 속에서 어슬렁거리고 있습니다. JavaScript 커뮤니티는 순진하기로 악명이 높습니다. JavaScript "전문가"가 컨퍼런스에서 마치 대단한 발견인 것처럼 설교하는 매우 기본적인 상식을 종종 발견할 수 있습니다. 저는 JavaScript 커뮤니티에서 이러한 회의를 개최하는 것이 의미가 없다고 생각합니다. 왜냐하면 이러한 회의는 단지 연결을 구축하고 일자리를 찾기 위한 것이기 때문입니다.

Java의 '후계자'는 이를 능가하지 못했습니다

최근 스칼라, 클로저, Go 등 신흥 언어에 열광하는 사람들이 많습니다. Java 언어보다 현대적이고 발전된 언어로, 결국 Java를 대체할 것이라고 생각합니다. 그러나 이러한 열광적인 지지자들은 Scala, Clojure 및 Go가 실제로 자신들이 해결한다고 주장한 문제를 해결한 것이 아니라 그들만의 문제를 가져왔다는 사실을 점차 발견했습니다. 이러한 문제 중 상당수는 Java에서는 발견되지 않습니다.

제가 Go에 관해 많은 댓글을 남겼습니다. 관심 있는 분들은 여기서 읽어보세요. 간단히 말해서 Go는 민간 과학과 오만의 산물이므로 여기서는 이에 대해 많이 언급하지 않겠습니다.

처음에는 스칼라를 일종의 구원자처럼 존경했던 사람들도 있습니다. 나는 그들에게 호들갑 떨지 말고 그냥 자바를 사용하라고 제안합니다. 그는 내 말을 듣지 않았고, 결국 온갖 문제로 스칼라를 하루 종일 꾸짖었습니다. 하지만 방법이 없습니다. 해당 프로젝트는 불법 복제되었으며 계속 사용해야 합니다. 나는 인신공격을 하는 것을 좋아하지 않지만, 언어의 질은 종종 그 언어를 설계한 사람의 수준, 성격, 동기에 달려 있다는 것을 알게 되었습니다. 사람에 대한 나의 직관은 언어 디자이너에 대한 첫인상을 토대로 앞으로 언어가 어떻게 발전할지 예측할 수 있을 정도로 정확합니다. 여기서는 Scala와 Clojure의 디자이너에 대한 나의 견해를 이야기하고 싶습니다.

스칼라의 디자이너 마틴 오데르스키(Martin Odersky)는 프로그래밍 언어 분야에서 큰 성과를 거두고 심오해 보이는 많은 학술 논문을 발표했지만(사실 그 중 상당수는 말도 안되는 내용임) 특별히 특별하지는 않습니다. 언어의 "디자인"에 대해. 그래서 저는 Scala가 아주 기본적인 몇 가지 사항을 잘못 알고 있다는 사실에 놀랐습니다. Odersky는 평판이 좋은 대학 교수이기 때문에 많은 사람들이 그에게서 박사 학위를 받기를 원하기 때문에 그는 그것에 대해 이야기하고 Scala에 불명확하고 잠재적으로 문제가 있는 "기능"을 추가하는 것을 좋아합니다. 목적은 논문을 출판하고 혼합하는 것입니다. 졸업. 이로 인해 Scala는 지나치게 복잡해지고 나중에 거의 사용되지 않는 것으로 판명된 많은 기능을 추가하고 대신 문제를 일으켰습니다. 학생들은 Scala 컴파일러에 코드 구현을 추가하고 졸업 후에는 그대로 두므로 Scala 컴파일러에는 역사적 쓰레기와 버그 더미가 남습니다.

클로저에 대해 이야기해보겠습니다. Clojure가 처음 나왔을 때 몇몇 사람들이 나에게 열광적으로 추천해주었다. 그래서 디자이너 리치 히키(Rich Hickey)의 홍보강연 영상을 봤습니다. 당시 나는 그의 가슴 뛰는 실력에 대해 막연하게만 알고 있었고, 매우 감동받았다. Rich Hickey는 실제로 CS 학위도 없이 중간에 승려가 되었습니다. 그러나 그의 추진력은 다른 언어 디자이너들이 아무것도 이해하지 못하는 것처럼 보였고 진실을 본 유일한 사람이었습니다. 하지만 그런 사람만이 '종교'를 만들 수 있지 않습니까? Clojure가 적극적으로 장려하는 "기능"(게으른 메모리, 순수 메모리, 트랜잭션 메모리 등)은 모두 다른 언어의 소문에서 복사되었지만 그 본질을 깊이 이해하지 못합니다. "기능적 언어"의 일부 기능은 본질적으로 문제가 있지만 "교리의 정확성"을 위해 무분별하게 복사되었습니다. 그래서 결국 이 언어는 양머리로 개고기를 파는 것이라는 것을 알게 됩니다. 명확하고 논리적으로 말하지만 사용하면 너무 형편없습니다.

Clojure 커뮤니티는 Scheme 및 Racket 커뮤니티의 아이디어를 복사하느라 바빴지만 이를 자신들의 발명품이라고 주장하기도 합니다. 예를 들어 Typed Clojure는 Typed Racket을 그대로 표절합니다. 동일한 기본 개념 중 일부는 수십 년 동안 Scheme에 있었으므로 Scheme에 먼저 도입되었다는 사실을 알 수 없도록 다른 이름으로 변경해야 합니다. 어떤 사람들은 SICP, The Little Schemer in Clojure 등 유명한 책의 코드를 모두 다시 작성하기도 했습니다. 그 결과 원작의 단순성과 본질이 완전히 사라졌습니다. 결국 Clojure의 모든 좋은 기능은 이미 Scheme에서 사용할 수 있으며 Clojure의 거의 모든 새로운 기능에는 문제가 있다는 것을 알게 됩니다. 저는 몇몇 Clojure 모임에 참여했지만 나중에 큰 구호를 외치는 온갖 종류의 초보자, 온갖 오만한 시민 과학이 있었고 그들은 극도로 무지하다는 것을 알게 되었습니다.

Scala와 Clojure를 맹목적으로 존경하는 많은 사람들은 결국 이러한 언어의 거의 모든 "새로운 기능"에 결함이 있다는 것을 발견했습니다. 그 중에서 가장 중요하고 유용한 기능은 실제로 이미 Java에 있습니다. 어떤 사람들은 나에게 이렇게 말했습니다: "보세요, Java는 이것을 할 수 없습니다!" 나중에 분석한 후에 나는 그들이 목표를 달성하기 위해 가장 최신의 가장 멋진 언어 기능을 사용해야 한다고 무의식적으로 완고하게 결정했다는 것을 발견했습니다. 자바에는 이런 기능이 없기 때문에 자바가 할 수 없다고 생각하고 다른 언어를 사용해야 합니다. 사실 문제를 다른 각도에서 바라보고, 너무 안주하지 말고, 최신의 멋진 '작성 방법'을 추구하는 대신 문제 해결에 집중한다면 자바로 풀 수 있고, 해결할 수 있다. 깔끔하게.

지금 시스템을 구축하고 싶다면 Scala나 Clojure로 시간을 낭비하기보다는 Java를 사용하는 것이 좋습니다. 잘못된 사람들은 잘못된 언어를 설계했고 그것을 사용함으로써 모든 사람의 시간을 낭비했습니다.

많은 사람들이 Java를 싫어합니다. 이는 실제로 초기 GoF 디자인 패턴이 틀에 박힌 템플릿을 제시하려고 하여 프로그램에 불필요한 복잡성을 가져왔기 때문입니다. 그러나 Java 언어 자체는 실제로 디자인 패턴과 동일하지 않습니다. Java의 디자이너와 Design Pattern의 디자이너는 전혀 다른 사람입니다. 디자인 패턴을 사용하지 않고도 Java로 매우 간단한 코드를 작성할 수 있습니다.

Java는 뛰어난 IDE 지원을 제공합니다

저는 주로 IntelliJ를 사용하여 Java 코드를 작성합니다. 저는 IntelliJ에 매우 좋은 디자인 아이디어가 있다는 것을 발견했습니다. 이러한 기능 중 상당수는 실제로 모든 텍스트 편집기(Emacs, VIM...)를 능가합니다. IntelliJ는 Java를 더욱 강력하게 만들어 개발이 마치 날아가는 듯한 느낌을 줍니다.

IntelliJ를 사용하면 '변수 이름 지정' 같은 것에 대해 걱정할 필요가 없습니다. IntelliJ에는 매우 강력하고 친숙한 리팩터링 기능이 있으므로 변수 이름을 매우 빠르게 바꿀 수 있습니다. 따라서 처음 변수를 생성할 때 완벽한 이름이 나올까 걱정할 필요가 없습니다. 괜찮은 이름을 사용하고 코드를 빠르게 작성하면 실험이 성공합니다. 그런 다음 돌아가서 코드를 살펴보고 이름을 더 적절한 이름으로 변경하세요.

IntelliJ는 또한 매우 빠른 구조적 변형을 수행할 수 있어 마치 조각품을 만드는 예술가처럼 느껴질 수 있습니다. 처음에는 대담하게 코드를 대략적인 모양으로 자르고, 조심스럽게 다듬고 반죽하여 더 좋고, 이해하기 쉽고, 더 매력적인 모양이 될 수 있습니다.

결론

프로그래밍에 어떤 도구를 사용하는지도 중요하지만, 결국 도구는 자신의 기술만큼 중요하지 않습니다. 많은 사람들이 코드 품질이 기적적으로 향상되기를 바라면서 다양한 새로운 언어를 사용하는 데 너무 많은 시간을 소비하지만 결국 아무 성과도 얻지 못합니다. 언어를 선택할 때 가장 중요한 조건은 "사용하기 쉬움"이어야 합니다. 왜냐하면 프로젝트의 성공은 궁극적으로 언어가 아닌 사람에 달려 있기 때문입니다.