생성형 AI가 지루한 작업을 처리하고 오류를 찾는 데 능숙하더라도 프로그래머의 전문성과 직관은 항상 필요할 것이다.
데이터셋(Datasette)의 설립자사이먼 윌리슨은 “지금이 프로그래밍을 배우기에 더할 나위 없이 좋은 시기”라고 말했다. AI가 코딩을 대신 해줘서가 아니다. 사실 정반대다. 그는 “대규모 언어 모델은 학습 곡선을 평평하게 만들어 젊은 개발자가 더 쉽게 따라잡을 수 있게 해준다”라고 말했다. 코딩하는 방법을 잊어서는 안 되지만, 생성형 AI를 사용해 경력 수준에 관계없이 개발자 경험을 강화할 수 있다.
‘배움에 대한 의지’를 예찬 필자는 생성형 AI에 대한 윌리슨의 견해를 살피는 것을 즐긴다. 그는 이 주제를 사려 깊게 생각하는 개발자다. 오라일리(O'Reilly Media)의마이크 루키데스글도 큰 주제에서 핵심을 압축해 설명했기 때문에 읽어볼 만하다. 루키데스는 생성형 AI와 코딩에 대해 “정말 좋은 프롬프트를 작성하기란 생각보다 어렵다”라는 점을 상기시켜 준다. 그는 “프롬프트를 잘 작성하려면 프롬프트의 목적에 대한 전문 지식을 쌓아야 한다”라고 말했다. 다시 말해, 먼저 ‘좋은’ 프로그래머가 돼야 한다.
루키데스는 “AI를 '인간이 얻을 수 없는 전문 지식과 지혜의 보고’로 생각해버리면 이를 생산적으로 사용할 수 없게 된다”라고 조언했다. AWS 코드위스퍼러(CodeWhisperer)나 구글 코디(Codey)와 같은 도구를 효과적으로 사용하기 위해서는 기대하는 결과물을 코칭해야 한다. 그리고 AI에게 개발 문제를 해결하는 방법을 단계별로 알려주려면, 먼저 문제를 깊이 이해하고 AI가 응답하도록 이끌어내야 한다.
또한 개발자는 AI가 틀렸을 때이를 평가할 수 있어야 한다. 여기엔 일정 수준의 전문성이 필요하다. 윌리슨이 언급한 것처럼 코딩 어시스턴트가 프로젝트에서 더 활발히 일하고 도와줄 것으로 기대되는 상황이지만, 그렇다고 해서 개발자가 코드를 파악해야 할 필요성까지 없애주진 않을 것이다. 그렇게 되기를 바라는 이도 없을 것이다. 다시 윌리슨의 첫 번째 요점으로 돌아가 본다.
AI를 활용한 코딩 학습 특정 언어, 프레임워크, 데이터베이스 등을 처음 접하는 개발자라면 학습 곡선이 가파를 수 있다. 예를 들어 “세미콜론을 놓쳐서 기이한 오류 메시지가 표시되고, 그 오류를 다시 찾는 데 2시간이 걸리는 경우도 있다”라고 윌리슨은 말했다. 당연히 이러한 점 때문에 학생들은 자신이 프로그래밍을 배울 만큼 똑똑하지 않다고 생각해 배움을 포기할 수 있다.
바로 이 부분에서 AI 어시스턴트가 개입할 수 있다. 윌리슨은 “컴퓨터공학 학위가 없어도 컴퓨터가 지루한 일을 대신 해줄 수 있어야 한다”라고 전했다. 챗GPT 같은 LLM 기반 어시스턴트는 지루한 작업을 자동화할 수 있다. 깃허브(GitHub) 엔지니어자나 도건은 “사람들은 코드 생성에만 너무 집중한 나머지 LLM이 코드 분석에 유용하다는 사실을 완전히 잊고 있다”라고 강조했다. 모든 작업을 AI가 할 필요는 없다. 윌리슨의 주장에 따르면, 애플리케이션을 만들거나 망치지는 않으나 개발자의 자신감을 떨어뜨릴 수 있는, 개별적이고 지루한 작업을 자동화하는 데 AI를 활용할 수 있다. 코딩 어시스턴트가 지루한 작업을 처리할 수 있음에도 개발자가 프로그래밍의 모든 측면을 배우고 수행할 것을 요구받는 경우에 더 그렇다.
언제나 그렇듯 생성형 AI와 함께 소프트웨어 개발을 시작하는 가장 좋은 방법은, 바로 시작하는 것이다. 이해는 했지만 반복해서 작성할 필요는 없는 간단한 작업부터 자동화해 작게 시작하라. 이렇게 절약한 시간으로 더 까다로운 코딩 문제를 해결하는 방법을 배우는 데 집중할 수 있다. 전문성이 높아지면 이러한 작업도 자동화할 수 있게 될 것이다.
우리는 모두 규칙을 위반할 때의 짜릿함을 안다. 그 위반은 시속 55마일 구역에서 56마일로 달리는 것일 수도 있고, 주차 미터기의 유효 기간이 지나도록 방치하는 것일 수도 있다.
프로그래머와 규칙은 묘한 관계를 맺고 있다. 코드는 규칙의 거대한 더미에 불과하며, 규칙은 거의 항상 알파 입자로 인한 오류 없이 충실한 실리콘 게이트에 의해 두려움이나 호의 없이 무한히 적용된다. 인간은 트랜지스터가 규칙을 완벽하게 따르기를 바란다.
하지만 그렇게 신성하지 않은 또 다른 규칙이 있다. 인간이 기계에 전달하는 지침과 달리, 인간 스스로 만드는 규칙은 쉽게 유연해진다. 어떤 규칙은 단순히 문체적인 규칙이고, 어떤 규칙은 무질서하게 쌓인 코드 더미에 일관성을 부여하기 위해 고안된 규칙이다. 이러한 일련의 규칙은 기계의 반응 방식이 아니라 인간이 하는 일에 적용된다. 진짜 논쟁은 인간이 스스로 만든 규칙을 깨는 것이 좋은 생각인지 아닌지다. 인간이 즉석에서 규칙을 재해석할 권리가 있지 않을까? 어쩌면 일부 규칙은 다른 시대에서 유래한 것일 수도 있다. 처음부터 반만 완성된 개념이었을 수도 있다. 당시에는 현명한 아이디어처럼 보였지만 지금은 아닌 규칙도 있고, 어떤 것은 "습관"이라고 부르는 것이 더 나을지도 모른다.
프로그래밍 기술 개선을 저해할 나쁜 프로그래밍 습관 10가지를 정리했다.
주석 없는 코딩
문서화되지 않은 코드는 이해와 디버깅에 있어 악몽과도 같다. 프로그래밍 수업에서는 좋은 코멘트를 작성하는 것이 필수라고 가르친다. 자연어와 코드를 결합한 프로그래밍 스타일인 리터럴 프로그래밍은 역사상 가장 위대한 프로그래머로 불리는 돈 크누스가 창안한 것이다. 누가 이의를 제기할 수 있을까?
하지만 슬픈 진실은 댓글이 상황을 악화시킬 때가 있다는 점이다. 때로는 문서가 코드와 거의 관련이 없는 것처럼 보일 때도 있다. 문서화 팀이 코딩 팀과 멀리 있거나 다른 주에 살고 있을 수도 있고, 실제로는 생각이 다를 수도 있다. 코더가 문서화 팀에 알리지 않고 중요한 패치를 적용했거나 문서화 팀에서 알고 있지만 아직 주석을 업데이트하지 않았을 수도 있다. 때로는 코더가 변경한 메서드의 맨 위에 있는 코멘트를 업데이트하지 않기도 한다. 스스로 알아서 해결해야만 한다.
다른 문제도 있다. 코멘트가 모르는 자연어로 작성되었을 수도 있다. 7단락 미만으로 요약할 수 없는 개념인데 코더가 급하게 작성했을 수도 있다. 코멘트를 쓰는 사람이 잘못했을 수도 있다.
이러한 모든 이유로 일부 개발자는 쓸모없는 코멘트에 대한 최선의 해결책은 코멘트를 적게 포함하거나 아예 없애는 것이라고 생각한다. 대신 길고 설명적인 캐멀케이스 변수 이름을 지침으로 사용하는 간단하고 짧은 함수를 작성하는 것을 선호한다. 컴파일러에 오류가 없다면 코드는 컴퓨터가 수행하는 작업을 가장 정확하게 반영해야 한다.
느린 코드
코드를 빠르게 만들고 싶다면 코드를 단순하게 만들어라. 정말 빠르게 만들고 싶다면 복잡하게 만들어라. 이 과제에 적합한 최적의 지점을 찾는 것은 그리 쉬운 일이 아니다.
따라서 절충점을 찾아야 한다. 일반적으로는 프로그램이 빠르기를 원한다. 그러나 아무도 이해하지 못한다면 복잡성이 오히려 방해가 된다. 속도가 중요하지 않다면, 조금 느려도 이해하기 쉬운 코드가 더 합리적이다. 때로는 아주 영리하고 빠른 것보다 단순하고 느린 것이 더 나은 선택인 이유다.
장황한 코드
필자의 한 동료는 줄임표와 같은 자바스크립트의 새로운 연산자를 모두 사용하는 것을 좋아한다. 그 결과 코드는 더 간결해지고 나아진다. 모든 코드 리뷰에는 새로운 구문을 사용해 코드를 다시 작성할 수 있는 부분에 대한 제안이 함께 돌아온다.
간결한 것이 더 이해하기 쉽다고 확신하지 못하는 동료도 있다. 코드를 읽으려면 새 연산자의 포장을 풀어야 하는데, 그 중 일부는 다양한 방식으로 사용될 수 있다. 연산자가 어떻게 사용되었는지 이해하려면 익숙한 빠른 훑어보기가 아니라 잠시 멈춰서 깊이 생각해야 한다. 코드를 읽는 것은 번거로운 일이 되어 버린다.
사람들이 초밀착형 코드를 싫어하는 이유에는 역사적인 논거가 있다. 사용자 정의 기호 덕분에 엄청나게 치밀하고 효율적으로 설계된 APL 같은 언어는 본질적으로 사라졌다고 봐도 무방하다. 중괄호를 사용하지 않는 파이썬 같은 다른 언어의 인기는 계속 높아지고 있다.
멋진 추상화를 좋아하는 사람은 간결한 새 기능을 계속 밀어붙이고 간결함을 강조할 것이다. 이들은 현대적이고 유행에 발 맞춘다는 점을 강조한다. 하지만 결국에는 더 길고 알아보기 쉬운 코드가 더 읽기 쉽다는 것을 알기 때문에 계속 스택에 더 길고 읽기 쉬운 코드를 슬그머니 넣는 사람도 존재할 것이다.
오래된 코드
프로그래밍 언어를 설계하는 사람들은 특정 유형의 문제를 쉽게 해결할 수 있는 영리한 추상화 및 구문 구조를 발명하는 것을 좋아한다. 프로그래밍 언어는 추상화로 가득 차 있기 때문에 매뉴얼만 1,000페이지가 넘는 경우도 있다.
곧 권력의 제1 규칙이 “사용하지 않으면 잃는다”라는 주장이다. 1,000페이지에 달하는 매뉴얼에 설명된 모든 구문을 다 사용하는 것이 최선이라고 생각하기 때문이다.
그러나 항상 좋은 규칙은 아니다. 기능이 너무 많으면 혼란을 야기한다. 이제 어떤 프로그래머도 모든 구문 기믹에 능통할 수 없을 정도로 영리한 구문 기믹이 많이 등장했다. 왜 그래야 할까? 예를 들어 무효를 테스트하거나 상속이 다차원에서 작동하도록 하려면 얼마나 많은 방법이 필요할까? 그 중 어느 것이 옳은 방법, 아니면 다른 방법보다 나은 방법일까? 물론 적극적으로 이러한 논쟁을 막으려는 개발자도 있을 것이다.
기능 세트의 한계를 결정 지은 언어 개발자들도 나타났다. 고(Go) 언어 개발자들은 하루라도 빨리, 어쩌면 단 1일 만에 배울 수 있는 언어를 만들고 싶다고 말했다. 팀 내 모든 코더가 모든 코드를 읽을 수 있어야 한다는 의미다. 기능이 적을수록 혼란도 줄어든다.
나만의 코드 롤링
효율성 전문가는 "바퀴를 재발명하지 말라"라고 조언한다. 충분한 테스트를 거쳐 바로 실행할 수 있는 스톡 라이브러리를 사용하라. 이미 검증된 레거시 코드를 사용하라.
때로는 새로운 접근 방식이 합리적일 때도 있다. 라이브러리는 제너럴리스트와 일상적인 사용례를 위해 작성되는 경우가 많다. 데이터의 일관성을 보장하고 사용자가 잘못된 매개변수를 전송하여 작업을 망치지 않도록 벨트 앤 서스펜더 테스트가 많다. 하지만 특수한 경우라면 몇 줄의 특수 코드가 훨씬 더 빠르다. 라이브러리가 할 수 있는 모든 작업을 수행하지는 못하지만 필요한 작업을 절반의 시간 안에 처리할 수 있다.
위험한 경우도 있을 것이다. 암호화 시스템처럼 너무 난해하고 복잡한 코드도 있어서 모든 수학을 알고 있더라도 함께 조합하는 것은 좋은 생각이 아니다. 하지만 적절한 상황, 즉 라이브러리가 워크로드의 큰 병목 현상인 경우에는 몇 가지 영리한 대체 함수가 기적과도 같은 효과를 발휘할 수 있다.
너무 이른 최적화
프로그래머가 코드를 몇 가지 조합하고 나서 ‘조기 최적화는 시간 낭비’라는 오래된 격언으로 빠른 작업을 정당화하는 경우가 많다. 전체 시스템을 가동하기 전까지는 코드의 어느 부분이 진짜 병목 현상이 될지 아무도 모른다는 생각에서다. 1년에 한 번만 호출될 기능이라면 훌륭한 기능을 만드는 데 시간을 낭비하는 것은 어리석은 일이다.
일반적으로는 잘 통용되는 좋은 경험칙이다. 지나친 계획과 과도한 최적화 때문에 출발선을 벗어나지 못하는 프로젝트도 있기 때문이다. 하지만 조금만 미리 생각하면 큰 차이를 만들 수 있는 경우도 많이 있다. 때로는 잘못된 데이터 구조와 스키마를 선택하면 사후에 최적화하기 어려운 아키텍처가 만들어지기도 한다. 때로는 구조가 코드의 너무 많은 부분에 구워져 있어서 약간의 영리한 리팩터링만으로는 해결되지 않는 경우도 있다. 이러한 경우에는 약간의 조기 최적화가 정답이 될 수 있다.
부주의
훌륭한 프로그래머는 일방통행로를 건너기 전에 양쪽을 모두 살펴본다는 것을 누구나 알고 있다. 데이터를 처리하기 전에 항상 데이터를 두 번, 세 번 확인하는 추가 코드를 많이 삽입해야 한다. 널 포인터가 잘못 들어갈 수도 있기 때문이다.
안타깝게도 이렇게 많은 주의를 기울이면 코드가 느려질 수 있다. 때로는 성능 때문에 본능을 무시하고 그다지 신경 쓰지 않는 코드를 작성해야 할 때도 있다. 빠르게 실행되는 코드를 원한다면 최소한의 작업만 하고 그 이상은 하지 말아야 한다.
불일치
사람들은 일반적으로 질서를 좋아하기 때문에 프로그래머는 코드 더미에서 모든 부분에 동일한 기술, 알고리즘 또는 구문을 사용해야 한다고 고집하는 경우가 많다. 이러한 부지런함은 나중에 코드를 이해해야 하는 사람의 삶을 더 쉽게 만들어 준다.
반면, 일관성을 유지하려면 시간이 걸리고 때로는 복잡해지기도 한다. 차이점을 수정하려면 잘못된 경로를 따르는 모든 코드를 처음부터 다시 작성해야 하고, 그것만으로도 예산에 부담을 줄 수 있다.
더 심각한 문제는 서로 다른 섹션 간의 관계다. 레거시 코드에 의존하는 프로젝트도 있고, 라이브러리에 의존하는 프로젝트도 있다. 완전히 별도의 회사에서 완전히 다른 사람들이 작성한 API 없이는 작동할 수 없는 프로젝트가 많다.
그룹 간의 차이를 부드럽게 조정하는 것은 불가능하며, 최신 비전에 맞게 전체 스택을 다시 작성할 수 있는 횟수도 제한되어 있다. 우리 뇌의 이상한 구석에서는 완벽한 질서를 갈망하지만, 어쩌면 불일치와 화해하는 것이 더 나을지도 모른다.
종소리와 휘파람을 따라가기
지나친 일관성의 또 다른 문제는 혁신을 방해한다는 점이다. 일관성은 기존 업무 방식을 고집하는 일종의 경직된 태도를 조장하기도 한다.
새로운 기능을 추가하거나, 새로운 라이브러리를 도입하거나, 스택을 새로운 API와 통합하려면 기존 패턴을 깨야 할 때가 있다. 물론 코드를 읽는 동안 기어를 바꿔야 하는 사람의 삶이 조금 더 어려워지겠지만, 이것은 발전의 대가다. 또한 코딩을 재미있게 만드는 요소 중 하나이기도 하다.
규칙 깨기
재미를 위해 구글의 제미나이에게 프로그래머가 코드를 만드는 과정에서 규칙을 어긴 적이 있는지 물어보았다. 제미나이는 "프로그래머가 특정 규칙을 어겼다기보다는 저와 같은 대형 언어 모델을 만들 때 모범 사례의 한계를 넘어섰다고 말하는 것이 더 정확합니다"라고 대답했다.
"제미나이는 "저와 같은 대형 언어 모델은 방대한 양의 데이터로 학습하며, 모델이 데이터를 통해 학습하는 방식에는 '미지의 요소'가 존재합니다. 대형 언어 모델을 만드는 데 사용되는 일부 기술은 매우 효율적일 수 있지만 모델이 어떻게 답을 얻는지 정확히 이해하기는 어려울 수 있습니다”라고 말했다.
그렇다. LLM은 기존의 규칙이 바뀌고 있다는 사실을 사람보다 더 잘 알고 있다. 방대한 훈련 세트를 상자에 넣을 수 있다면 알고리즘을 이해하는 데 많은 시간을 할애할 필요가 없을지도 모른다. 그러니 인간답게 LLM이 규칙을 준수하도록 하자.
러스트 재단에서 개발되고 있는 메모리 안전성과 성능 및 편의성에 중점을 둔 프로그래밍 언어. 가비지 컬렉터 없이 메모리 안전성을 제공하는 대표적인 언어다. C++의 대체재로써 등장했다.
모질라 재단에서 2010년 7월 7일에 처음 발표했으며, 2015년 5월 15일에 안정 버전이 정식 발표된 이후, 2021년 2월부터는 러스트 재단으로 분리되어 AWS, Google, 화웨이, MS, 모질라 재단을 초기 회원사로 발족했다.
이 언어를 대표하는 키워드 몇 개를 나열해보면 안전성, 속도, 병렬 프로그래밍, 함수형 프로그래밍, 시스템 프로그래밍이 있다. Go보다는 반 년 늦게 나왔지만 그나마 비슷한 시기에 등장했다는 점과 두 언어 모두 C/C++를 서로 다른 방향에서 대체하려 한다는 점 때문에 라이벌 관계로 엮이기도 한다.
온라인상으로 표준 라이브러리 기반의 코드를 실행해볼 수 있다. #
Rust의 비공식 마스코트도 있는데, 이름은 페리스(Ferris)다. 밝은 주황색의 게 모양을 하고 있으며, 러스트 관련 커뮤니티나 미디어에서 자주 등장한다. 또한 이 페리스 때문에 Rust 개발자는 스스로를 Rustacean이라고 자칭한다.
사람들이 여전히 Java가 오늘날과 관련이 있다고 생각하는 것은 일반적인 오해입니다.실제로 Java는 죽어가는 프로그래밍 언어입니다.Java는 세계에서 가장 널리 사용되고 널리 사용되는 프로그래밍 언어 중 하나이지만 곧 사라질 위험에 처해 있습니다.오늘날 Java는 크고 활발한 개발자 커뮤니티를 보유하고 있으며 웹 개발, 모바일 앱 개발 및 엔터프라이즈 수준 소프트웨어 개발을 포함한 광범위한 애플리케이션에 여전히 사용되고 있지만 Java가 향후 10년 동안 살아남을 수 있을까요?개발자가 Java에 대해 가지고 있는 오해를 알아보겠습니다.
오해 1: Java에는 크고 활발한 개발자 커뮤니티가 있습니다.전 세계에 수백만 명의 Java 개발자가 있으며 언어는 개발자가 지식과 리소스를 공유하는 온라인 포럼 및 커뮤니티에서 강력한 입지를 확보하고 있습니다.
이것이 계속해서 사실이지만, 개발자들이 다른 플랫폼과 프로그래밍 언어로 이동하는 속도를 보면 알 수 있으며 개인적으로 개발자들이 패닉에 빠지는 것을 보았습니다.주요 문제는 프로그래밍 언어로서의 Java가 현대화되지 않았기 때문에 여전히 장황하게 남아 있고, 불안정하지만 매우 투박한 유형 시스템을 가짐으로써 정적 유형과 동적 유형 사이의 최악의 두 세계를 결합하고, VM에서 실행해야 한다는 것입니다. 거시적인 시작 시간(오래 실행되는 서버에는 문제가 되지 않지만 명령줄 응용 프로그램에는 문제가 됨).요즘에는 꽤 잘 수행되지만 여전히 C 또는 C++에 비해 경쟁력이 없으며 약간의 사랑으로 C#, Go, Rust 및 Python이 해당 도메인에서 이를 능가할 수 있습니다.실제 프로덕션 서버의 경우
오해 2: Java는 광범위한 응용 프로그램에 사용됩니다.Java는 웹 개발 언어일 뿐만 아니라 모바일 앱, 게임 및 엔터프라이즈급 소프트웨어 개발에도 사용됩니다.이러한 다양성으로 인해 다양한 유형의 프로젝트에 유용한 언어가 됩니다.
Java는 더 이상 모바일 애플리케이션 개발, 특히 Android에서 선호하는 프로그래밍 언어가 아닙니다.Kotlin은 이제 Android를 지배하고 대부분의 Android 개발자는 오래 전에 배를 뛰어 넘었습니다.구글조차도 몇 년 전 오라클과의 실패로 인해 안드로이드용 사실상의 언어로서 자바를 포기했습니다.Java는 오래 전에 웹 개발 언어로서의 인기도 잃었습니다.엔터프라이즈 개발에 관한 한 Java는 신뢰할 수 있고 안정적이기 때문에 여전히 대기업과 관련이 있습니다.많은 신생 기업이 엔터프라이즈 소프트웨어의 첫 번째 선택으로 Java를 사용하지 않고 다른 대안을 사용하고 있습니다.
오해 3: Java는 기본 언어입니다.많은 최신 프로그래밍 언어는 Java의 원칙과 개념을 기반으로 구축되었으며 어떤 방식으로든 Java와 호환되도록 설계되었습니다.즉, Java의 인기가 떨어지더라도 Java의 원칙과 개념은 계속 유효할 것입니다.
Java가 프로그래밍 여정을 시작하는 많은 사람들에게 기본 언어라는 것은 사실일 수 있지만 Java는 계속해서 매우 구식이고 융통성이 없다는 사실이 남아 있습니다.게다가 다른 최신 프로그래밍 언어와 비교할 때 여전히 장황합니다. 즉, 특정 작업을 수행하려면 많은 코드가 필요합니다.이로 인해 간결하고 우아한 코드를 작성하기가 더 어려워질 수 있으며 대규모 코드베이스를 유지 관리하는 데 더 많은 노력이 필요할 수 있습니다.또한 Java가 정적으로 유형이 지정된다는 사실은 Java가 동적으로 유형이 지정되는 언어보다 더 엄격하고 덜 유연할 수 있음을 의미하므로 일부 개발자에게는 실망스러울 수 있습니다.
오해 4:Java는 주요 회사의 강력한 지원을 받고 있습니다.Java를 유지 관리하고 지원하는 회사인 Oracle은 언어에 대한 강한 의지를 가지고 있으며 개발 및 개선에 지속적으로 투자하고 있습니다.또한 Google 및 Amazon을 비롯한 많은 주요 회사에서 제품 및 서비스에 Java를 사용합니다.
Oracle은 빠른 속도로 Java 시장 점유율을 경쟁자에게 빼앗기고 있습니다.아래 그래프를 참조하십시오.
아래 차트는 Oracle이 여전히 시장에서 가장 큰 점유율을 차지하고 있음을 보여주지만 그 점유율은 절반 이상 감소했습니다.2020년 Oracle은 "Java 시장의 약 75%"를 차지했지만 현재는 35% 미만입니다.
2021년 11월 Java 17이 출시된 이후 Eclipse Adoptium과 거의 비슷한 점유율을 기록하며 2위를 차지한 것은 New Relic의 수치에 따르면 Amazon입니다.
오해 5:Java는 학교와 대학에서 널리 가르칩니다.Java는 프로그래밍 개념을 가르치는 데 널리 사용되는 언어이며 학교 및 대학의 컴퓨터 과학 커리큘럼에서 자주 사용됩니다.이는 Java를 배우고 그 기능에 익숙해지는 새로운 개발자의 꾸준한 흐름이 있음을 의미합니다.
이것은 크게 변화하고 있습니다.소프트웨어 개발자를 꿈꾸는 젊은 대학생들은 빠르게 다른 프로그래밍 언어로 옮겨가고 있습니다.이로 인해 이러한 다른 프로그래밍 언어에 대한 대중적인 수요로 인해 대학에서 대안을 찾는 일이 점점 더 많아지고 있습니다.
나는 이것이 논란의 여지가 있는 주제라는 것을 안다.저는 여전히 Java를 소프트웨어 작성 방식을 혁신하고 따라야 할 다른 프로그래밍 언어에 대한 벤치마크를 만든 언어로 생각합니다.불행하게도 언어의 소유권은 많은 금전적 이익을 남기지 않고 계속 개선할 의욕이 없는 회사의 손에 있습니다.Java는 곧 사라지지 않지만 몇 년 안에 관련성을 잃을 심각한 위험에 처해 있습니다.
파이썬은 비영리의파이썬 소프트웨어 재단이 관리하는 개방형, 공동체 기반 개발 모델을 가지고 있다.
파이썬은 초보자부터 전문가까지 사용자층을 보유하고 있다.동적 타이핑(dynamic typing)범용 프로그래밍 언어로,펄및루비와 자주 비교된다. 다양한 플랫폼에서 쓸 수 있고, 라이브러리(모듈)가 풍부하여,대학을 비롯한 여러 교육 기관, 연구 기관 및 산업계에서 이용이 증가하고 있다. 또 파이썬은 순수한 프로그램 언어로서의 기능 외에도 다른 언어로 쓰인 모듈들을 연결하는접착제 언어로써 자주 이용된다. 실제 파이썬은 많은 상용 응용 프로그램에서스크립트 언어로 채용되고 있다. 도움말 문서도 정리가 잘 되어 있으며,유니코드문자열을 지원해서 다양한 언어의 문자 처리에도 능하다.
현대의 파이썬은 여전히 인터프리터 언어처럼 동작하나 사용자가 모르는 사이에 스스로 파이썬 소스 코드를 컴파일하여 바이트 코드(Byte code)를 만들어 냄으로써 다음에 수행할 때에는 빠른 속도를 보여 준다.
파이썬에서는들여쓰기를 사용해서 블록을 구분하는 독특한 문법을 채용하고 있다. 이 문법은 파이썬에 익숙한 사용자나 기존 프로그래밍 언어에서 들여쓰기의 중요성을 높이 평가하는 사용자에게는 잘 받아들여지고 있지만, 다른 언어의 사용자에게서는 프로그래머의 코딩 스타일을 제한한다는 비판도 많다. 이 밖에도 실행 시간에서뿐 아니라 네이티브 이진 파일을 만들어 주는C/C++등의 언어에 비해 수행 속도가 느리다는 단점이 있다. 그러나 사업 분야 등 일반적인 컴퓨터 응용 환경에서는 속도가 그리 중요하지 않고, 빠른 속도를 요하는 프로그램의 경우에도 프로토타이핑한 뒤 빠른 속도가 필요한 부분만 골라서 C 언어 등으로 모듈화할 수 있다(ctypes,SWIG,SIP등의 래퍼 생성 프로그램들이 많이 있다). 또한Pyrex,Psyco,NumPy등을 이용하면 수치를 빠르게 연산할 수 있기 때문에 과학, 공학 분야에서도 많이 이용되고 있다. 점차적인 중요성의 강조로 대한민국에서도 점차 그 활용도가 커지고 있다.
파이썬 2.0은 2000년 10월 16일 출시되었으며메모리 관리를 위한 사이클 감지쓰레기 수집기(참조 카운팅뿐 아니라),유니코드지원을 포함한 새롭고 수많은 주요 기능들이 포함되었다. 그러나 가장 중대한 변화는 개발 프로세스 그 자체로서, 더 투명하고 공동체의 지원을 받는 프로세스로의 전환이다.[4]
파이썬 3.0은 메이저급의 하위 호환성이 없는 릴리스로서 2008년 12월 3일 출시되었으며[5]이는 수많은 테스트 기간을 거친 뒤에 개발되었다. 주요 기능들 중 다수가 하위 호환이 가능한 파이썬 2.6, 2.7로백포팅되고 있다.[6]
