시스템의 복잡성 증가가 프로그래머 세대에 어떤 영향을 미쳤습니까?

"새로운"프로그래머로서 (2009 년에 처음으로 한 줄의 코드를 작성 했음), 오늘날 .NET 프레임 워크와 같은 매우 복잡한 요소를 보여주는 프로그램을 작성하는 것이 상대적으로 쉽다는 것을 알게되었습니다. 시각적 인터페이스를 만들거나 목록을 정렬하는 작업은 이제 몇 가지 명령으로 수행 할 수 있습니다.

프로그래밍을 배우면서 컴퓨팅 이론도 동시에 배우고있었습니다. 정렬 알고리즘, 하드웨어가 함께 작동하는 원리, 부울 대수 및 유한 상태 머신과 같은 것들. 그러나 이론상에서 배운 매우 기본적인 원리를 테스트하고 싶다면 라이브러리, 프레임 워크 및 OS와 같은 기술로 인해 많은 기술이 가려지기 때문에 시작하기가 항상 훨씬 어려웠습니다.

메모리가 충분하지 않고 비용이 많이 들기 때문에 40/50 년 전에 메모리 효율적인 프로그램을 만들어야했습니다. 따라서 대부분의 프로그래머는 데이터 유형과 프로세서가 명령을 처리하는 방법에 세심한주의를 기울였습니다. 오늘날 일부는 처리 능력과 사용 가능한 메모리의 증가로 인해 이러한 우려가 우선 순위가 아니라고 주장 할 수 있습니다.

저의 질문은 나이 든 프로그래머가 이와 같은 혁신을 신의 선물 또는 추상화를위한 추가 계층으로 보는 경우 왜 그렇게 생각할 수 있습니까? 그리고 젊은 프로그래머는 광범위한 라이브러리의 영역을 탐색하기 전에 저수준 프로그래밍을 더 배우는 데 도움이됩니까? 그렇다면 왜?

사용 가능한 처리 능력과 메모리 양이 증가하기 때문에 필요하지 않습니다.

저렴한 메모리, 거대한 디스크 및 빠른 프로세서 만있는 것이 모든 바이트와주기에 집착 할 필요가없는 유일한 사람은 아닙니다. 컴파일러는 이제 중요한 경우 최적화 된 코드를 생성하는 데있어 인간보다 훨씬 뛰어납니다.

또한 우리가 실제로 최적화하려고하는 것을 잊지 마십시오. 이는 주어진 비용으로 생산되는 가치입니다. 프로그래머는 기계보다 훨씬 비쌉니다. 프로그래머가 작업하고 정확하며 강력하고 완전한 기능을 갖춘 프로그램을 더 빠르고 저렴하게 생산할 수있게함으로써 세상에서 더 많은 가치를 창출 할 수 있습니다.

그러나 제 질문은 사람들이 저수준 요소의 "숨김"에 대해 어떻게 느끼는가입니다. 나이 많은 프로그래머는 그것을 신의 선물이나 불필요한 층으로 간주합니까?

모든 작업을 완료해야합니다. 저는 생계를위한 코드 분석기를 작성합니다. 레지스터 할당이나 프로세서 스케줄링 또는 수백만 가지의 다른 세부 사항에 대해 걱정해야한다면 버그 수정, 성능 보고서 검토, 기능 추가 등에 시간을 소비하지 않을 것입니다.

모든 프로그래밍은 그 위에 더 가치있는 레이어를 만들기 위해 아래 레이어를 추상화하는 것입니다. 모든 서브 시스템과 이들이 서로 어떻게 구성되어 있는지 보여주는 "레이어 케이크 다이어그램"을 수행 하면 하드웨어와 사용자 경험 사이에 문자 그대로 수십 개의 계층이있는 것을 알 수 있습니다. Windows 계층 케이크 다이어그램에는 원시 하드웨어와 C #에서 "hello world"를 실행하는 기능 사이에 60 개의 수준의 필요한 하위 시스템이 있다고 생각합니다.

젊은 프로그래머가 광범위한 라이브러리의 영역을 탐색하기 전에 저수준 프로그래밍을 배우는 데 더 도움이 될 것이라고 생각하십니까?

당신은 강조하기 전에 당신의 질문에 부정적인 대답을해야합니다. 12 살짜리 친구가 지금 프로그램을 배우는 것을 돕고 있으며 x86 어셈블러가 아닌 Processing.js 에서 시작한다고 생각하는 것이 좋습니다 . 젊은 프로그래머를 시작하면 Processing.js약 8 시간 만에 자체 촬영 게임을 작성하게됩니다. 어셈블러에서 시작하면 약 8 시간 안에 3 개의 숫자가 곱해집니다. 젊은 프로그래머의 관심을 끌 가능성이 어느 정도라고 생각하십니까?

이제 질문이 "케이크의 레이어 n을 이해하는 프로그래머가 레이어 n-1을 이해하면 도움이됩니까?" 대답은 그렇습니다. 그러나 그것은 나이나 경험과 무관합니다. 기본 추상화를 더 잘 이해함으로써 더 높은 수준의 프로그래밍을 향상시킬 수있는 경우가 항상 있습니다.

나는이 주제에 관한 아이디어를 가지고 있었고 20 년 전에 책에 넣었습니다 . 오래 인쇄되지 않았지만 여전히 Amazon에서 사본을 사용할 수 있습니다 .

귀하의 질문에 대한 하나의 간단한 답변은 Aristotle만큼 오래되었습니다. 자연은 진공을 싫어합니다 . 기계가 점점 더 빨라질수록 소프트웨어는 더 느리고 커졌습니다.

좀 더 건설적인 것으로, 내가 제안한 것은 정보 이론과 소프트웨어와의 직접적인 관련성은 컴퓨터 과학 교육의 일부라는 것입니다. 그것은 지금 아주 접선적인 방식으로 만 가르쳐지고 있습니다.

예를 들어, 프로그램이 입력 심볼, 출력 심볼, 노이즈, 리던던시 및 대역폭이있는 Shannon 유형 정보 채널로 생각하면 알고리즘의 큰 O 동작을 매우 깔끔하고 직관적으로 이해할 수 있습니다.

반면 프로그래머의 생산성은 Kolmogorov 정보 이론을 사용하여 유사한 용어로 이해 될 수 있습니다. 입력은 머리에 상징적 인 개념적 구조이며 출력은 손끝으로 나오는 프로그램 텍스트입니다. 프로그래밍 프로세스는 둘 사이의 채널입니다. 프로세스에 노이즈가 들어 오면 일관되지 않은 프로그램 (버그)이 생성됩니다. 출력 프로그램 텍스트에 중복성이 충분하면 버그를 발견하여 수정할 수 있습니다 (오류 감지 및 수정). 그러나 너무 중복 되면 너무 커서 크기가 오류 비율과 결합되어 버그가 발생 합니다. 이 추론의 결과로, 나는이 책에서 프로그래밍을 언어 디자인 프로세스로 취급하는 방법을 보여주는 데 많은 부분을 보냈다, 필요에 적합한 도메인 별 언어를 정의 할 수 있도록합니다. 우리는 CS 교육에서 도메인 별 언어에 입술 서비스를 지불하지만 다시 접선입니다.

언어를 만드는 것은 쉽습니다. 함수, 클래스 또는 변수를 정의 할 때마다 시작한 언어에 어휘를 추가하여 작동 할 새 언어를 만듭니다. 일반적으로 이해하지 못하는 것은 새로운 언어를 문제의 개념적 구조에 더 가깝게 만드는 것이 목표라는 것입니다. 이 작업을 수행하면 개념과 코드 사이에 1-1 매핑이 이상적이므로 코드 를 단축 하고 버그 를 줄이는 효과가 있습니다. 매핑이 1-1 인 경우 실수로 다른 개념으로 개념을 잘못 코딩 할 수 있지만 프로그램이 충돌하지 않습니다. 이는 일관된 요구 사항을 인코딩 하지 않을 때 발생하는 현상 입니다.

우리는 이것을 얻지 못했습니다. 소프트웨어 시스템 설계에 대한 우리의 용감한 이야기에서 요구에 대한 코드의 비율이 점점 커지고 있습니다.

사실, 우리는 매우 유용한 라이브러리를 가지고 있습니다. 그러나 나는 추상화에 대해 매우 신중해야한다고 생각합니다. 우리는 B가 A를 기반으로하고 그것이 좋은지, C가 B를 기반으로하면 더 좋다고 가정해서는 안됩니다. 나는 이것을 "공주와 완두콩"현상이라고 부릅니다. 귀찮은 것 위에 층을 쌓는 것이 반드시 그것을 고치는 것은 아닙니다.

긴 게시물을 끝내기 위해 필자가 때때로 문제가되는 스타일의 프로그래밍을 개발했습니다.

• 발명은 나쁘지 않습니다. 다른 엔지니어링 분야와 마찬가지로 좋은 것입니다. 물론 다른 사람들을위한 학습 곡선을 만들 수도 있지만 전반적인 결과가 더 나은 생산성이라면 그만한 가치가 있습니다.
• 하이쿠 스타일의 미니멀리스트 코드. 이는 특히 데이터 구조 설계에 적용됩니다. 내 경험상 요즘 소프트웨어의 가장 큰 문제는 부풀어 오른 데이터 구조입니다.

컴퓨팅의 지속적인 발전을 위해서는 높은 수준의 추상화가 필수적입니다.

왜? 인간은 주어진 순간에 머리에만 많은 지식을 가질 수 있기 때문입니다. 현대의 대규모 시스템은 오늘날 이러한 추상화를 활용할 수 있기 때문에 가능합니다. 이러한 추상화가 없다면 소프트웨어 시스템은 단순히 자체 무게로 붕괴 될 것입니다.

메소드를 작성할 때마다 추상화를 작성합니다. 메서드 호출 뒤에 숨겨져있는 약간의 기능을 만들고 있습니다. 왜 쓰시나요? 메소드를 테스트하고 작동하는지 검증 한 다음 메소드 호출만으로 원하는 때에 언제든지 해당 기능을 호출 할 수 있으므로 해당 메소드 내부의 코드에 대해 더 이상 생각할 필요가 없습니다.

컴퓨팅 초기에는 기계 언어를 사용했습니다. 우리는 우리가 작성한 하드웨어에 대한 친밀한 지식으로 매우 작고 베어 메탈 프로그램을 작성했습니다. 힘든 과정이었습니다. 디버거는 없었습니다. 프로그램이 정상적으로 작동하거나 충돌했습니다. GUI는 없었습니다. 모든 것은 명령 행 또는 배치 프로세스였습니다. 작성한 코드는 해당 특정 머신에서만 작동합니다. 다른 프로세서 나 운영 체제가있는 시스템에서는 작동하지 않습니다.

그래서 우리는 모든 세부 사항을 추상화하기 위해 고급 언어를 썼습니다. 프로그램을 다른 컴퓨터로 이식 할 수 있도록 가상 컴퓨터를 만들었습니다. 우리는 가비지 수집을 만들어 프로그래머가 메모리 관리에 대해 부지런히 신경 쓸 필요가 없었기 때문에 모든 종류의 어려운 버그를 제거했습니다. 해커가 버퍼 오버런으로 악용 할 수 없도록 언어에 범위 검사를 추가했습니다. 우리는 프로그램에 대해 다른 방식으로 추론 할 수 있도록 Functional Programming을 발명했으며 최근에 동시성을 더 잘 활용하기 위해 프로그램을 재발견했습니다.

이 모든 추상화가 하드웨어에서 당신을 격리합니까? 물론입니다. 텐트를 치지 않고 집에 사는 것이 자연으로부터 당신을 격리 시키는가? 물론. 그러나 모두가 왜 그들이 텐트 대신에 집에 살고 있는지 알고 있으며, 집을 짓는 것은 텐트를 던지는 것과는 완전히 다른 볼 게임입니다.

그러나 필요한 경우에도 여전히 텐트를 던질 수 있으며 프로그래밍에서는 하드웨어에 더 가까운 수준으로 내려 가서 성능이나 메모리 이점을 얻지 못할 수도 있습니다. 그렇지 않으면 고급 언어로 달성하십시오.

너무 추상화 할 수 있습니까? 스코티 가 말한 것처럼 "배관을 따라 잡으 세요 " ? 물론 당신은 할 수. 좋은 API를 작성하는 것은 어렵습니다. 직관적이고 발견 가능한 방식으로 문제 영역을 정확하고 포괄적으로 구현하는 좋은 API를 작성하는 것은 훨씬 더 어렵습니다. 새로운 계층의 소프트웨어를 사용하는 것이 항상 최상의 솔루션은 아닙니다. 소프트웨어 디자인 패턴 은 경험이 부족한 개발자가 더 날카 롭고 간결한 도구가 더 적합 할 때 때때로 도달하기 때문에 이러한 상황을 어느 정도 악화 시켰습니다.

정말 좋은 훈련은 극단뿐만 아니라 사이의 다리를 포함합니다.

저수준 측면에서 : 어셈블리 언어에 대한 지식과 컴파일러의 작업을 포함하여 컴퓨터가 처음부터 코드를 실행하는 방법 *.

상위 레벨 : 일반 개념, 예를 들어 연관 배열, 클로저 등을 사용하여 후드 아래에서 작동하는 방식에 대해 걱정하지 않고 시간을 낭비하지 않아도됩니다.

IMHO는 모두 자신의 결점을 포함하여 저수준 개념에서 고수준 개념에 이르는 방법에 대한 경험을 가지고 있어야합니다. 연관 배열을 좋아합니까? 이제 1kB의 RAM이있는 50 센트 임베디드 프로세서에서 사용하십시오. C를 사용하여 빠른 코드를 작성하는 것처럼? 좋습니다. 이제 웹 앱을 작성하는 데 3 주가 걸립니다. C를 사용하여 데이터 구조 및 메모리 관리에 시간을 소비하거나 새로운 웹 프레임 워크를 배우고 며칠 안에 웹앱을 구현하는 데 시간을 할애 할 수 있습니다.

복잡성 측면에서 볼 때 : 요즘 복잡한 시스템을 만드는 비용을 명확하게 이해하지 않고 복잡한 시스템을 만드는 것은 너무 쉽다고 생각 합니다 . 결과적으로, 우리는 사회로서 때때로 우리를 물리 치는 막대한 양의 기술 부채 를 쌓았습니다 . 지진과 같지만 (지리적 결함 근처에 사는 데 드는 비용, 맞습니까?) 점차적으로 악화되고 있습니다. 그리고 나는 그것에 대해 무엇을 해야할지 모르겠습니다. 이상적으로 우리는 복잡성을 관리하는 방법을 배우고 더 잘할 것이지만, 나는 그것이 일어날 것이라고 생각하지 않습니다. 책임있는 공학 교육에는 현재 대부분의 대학에서 제공하는 것보다 복잡성의 결과에 대해 훨씬 더 많은 논의가 포함되어야합니다.

그리고 어쨌든 컴퓨터가 코드를 실행하는 방법의 "접지"는 어디에 있습니까? 어셈블리 언어입니까? 아니면 컴퓨터 아키텍처? 아니면 디지털 논리? 아니면 트랜지스터? 아니면 장치 물리학?

고급 프로그래밍에는 많은 장점이 있으며 프로그래밍 언어의 필수 요소라고 생각합니다. Java가 성공한 이유 중 하나는 포괄적 인 라이브러리가 있기 때문입니다. 적은 코드로 더 많은 것을 달성 할 수 있습니다. 미리 정의 된 함수를 호출하면됩니다.

이제 프로그래밍 언어 사용자와 프로그래밍 언어 작성자 (컴파일러 작성자)를 구별 할 수 있습니다. 우리는 최적화를 컴파일러 작성자에게 맡깁니다. 유지 보수, 재사용 등에 중점을 둡니다.

시스템의 복잡성 증가는 끊임없는 압박과 궁극적으로 치명적인 영향을 미칩니다. 나이든 프로그래머라면 저에게도 실망 스럽습니다.

저는 40 년 넘게 프로그래밍을 해왔고 50-100 개의 다른 언어 나 방언으로 코드를 작성했으며 5-10 명의 전문가가되었습니다. 내가 너무 많은 것을 주장 할 수있는 이유는 대부분 같은 언어 일 뿐이고 비틀기 때문입니다. 조정은 복잡성을 추가하여 모든 언어를 조금 다르게 만듭니다.

수집, 변환, 정렬 및 검색, 인코딩 / 디코딩, 형식 / 파싱, 버퍼 및 문자열, 산술, 메모리, I / O와 같은 알고리즘을 셀 수없이 여러 번 구현했습니다. 모든 새로운 구현은 복잡성이 더해집니다. 왜냐하면 모든 것이 조금씩 다르기 때문입니다.

나는 웹 프레임 워크와 모바일 앱의 높은 공중 그네 예술가들이 만들어 낸 마법이 어떻게 짧은 시간에 그렇게 아름다운 무언가를 생산할 수 있는지 궁금합니다. 그런 다음 나는 그들이 모르는 정도, 데이터, 통신, 테스트 또는 스레드에 대해 얼마나 많이 알아야하는지 또는 그들이하는 일이 유용하기 전에 무엇이든 알고 있습니다.

나는 4 세대 언어 시대에 나의 기술을 배웠다. 거기서 우리는 소프트웨어 작성의 점점 더 많은 부분을 점진적으로 포착하기 위해 더 높은 수준의 더 높은 수준의 언어를 생산할 것이라고 믿었다. 정확히 어떻게 나타 났습니까?

마이크로 소프트와 IBM은 dBase / Foxpro와 심지어 델파이도 말을하지 않고 Windows와 OS / 2 용 앱을 작성하기 위해 C로 돌아가서 그 아이디어를 없애 버렸다. 그런 다음 웹은 HTML, CSS 및 JavaScript / DOM과 같은 최고의 어셈블리 언어 트리오로 다시 수행했습니다. 거기에서 내리막 길이 다되었습니다. 항상 더 많은 언어와 더 많은 라이브러리와 더 많은 프레임 워크와 더 복잡한.

우리는 다르게 행동해야한다는 것을 알고 있습니다. HTML을 작성하지 않아도되는 CoffeeScript와 Dart, Less와 Sass, 템플릿에 대해 알고 있습니다. 우리는 알고 있고 어쨌든 그렇게합니다. 우리는 누수가있는 추상화로 가득 찬 프레임 워크를 가지고 있으며, 신비한 주문을 배우는 소수의 선택된 사람들이 어떤 놀라운 일을 할 수 있는지 알고 있지만, 우리와 우리의 프로그램은 과거의 결정에 갇혀 있습니다. 변경하거나 다시 시작하기에는 너무 복잡합니다.

그 결과 복잡해야하기 때문에 쉬워야하는 것은 쉽지 않으며, 가능해야하는 것은 거의 불가능합니다. 기존 코드 기반에서 새로운 기능을 구현하기 위해 변경하는 비용을 추정 할 수 있으며 자신이 옳다는 확신을 가질 수 있습니다. 추정 할 수는 있지만 정당화하거나 설명 할 수는 없습니다. 너무 복잡합니다.

마지막 질문에 대한 답변으로, 나는 젊은 프로그래머에게 가능한 한 레이어 케이크에서 시작하여 필요와 욕구가 자극을 줄 때 하위 레이어로 뛰어들 것을 강력히 권합니다. 루프가 없거나 분기가 적거나 명시 적 인 상태가 아닌 언어를 선호합니다. 리스프와 하스켈이 떠 오릅니다. 실제로 커뮤니티는 항상 C # / Java, Ruby, Javascript, Python 및 SQL로 마무리합니다.

마지막 단어 : 복잡성은 궁극적 인 적입니다! 이길 때 인생은 간단 해집니다.

그러나 제 질문은 사람들이 저수준 요소의 "숨김"에 대해 어떻게 느끼는가입니다. 나이 많은 프로그래머는 그것을 신의 선물이나 불필요한 층으로 간주합니까?

둘 다 아닙니다.

레이어링이 없으면 시스템이 유지 보수가 불가능한 스파게티가되는 지점에 도달하기 때문에 레이어링이 필요합니다. 또한 재사용 가능성의 신조 중 하나입니다. 라이브러리 개발자가 잘 해냈다면 라이브러리를 사용하는 사람들은 구현의 세부 사항에 신경 쓸 필요가 없습니다. 우리 시스템에서 사용하는 통조림 코드의 양은 35 년 전 첫 프로그램을 작성했을 때와 비교하여 엄청나게 증가했습니다. 이러한 성장은 시간이 지남에 따라 더 강력한 일을 할 수 있다는 것을 의미합니다. 이거 좋다

그것이 문제가 된 곳은 전적으로 문화적입니다. 내 실용적 절반은 더 이상 모든 마지막 세부 사항에 대해 내 마음을 감싸고 내가하고 싶은 일을 끝내는 것이 불가능하다는 것을 이해합니다. (나이가 커져도 도움이되지 않습니다.) 내 끔찍한 회색 수염 반은 수년 동안 내가 일한 모든 것을 세밀하게 이해하는 데 어려움을 겪었습니다.

젊은 프로그래머가 광범위한 라이브러리의 영역을 탐색하기 전에 저수준 프로그래밍을 배우는 데 더 도움이 될 것이라고 생각하십니까?

다른 답변에서 지적했듯이, 신생 생물의 관심을 끌고 유지하는 것과 그들에게 이상적인 교육을 제공하는 것 사이에는 균형이 맞아야합니다. 전자를 할 수 없다면 후자는 일어날 수 없습니다.

나는 우리 사회에서 다른 사회와 비슷한 것들을 봅니다. 예전에는 거의 모든 사람들이 자신의 음식을 키우고 많은 시간을 보냈습니다. 그 이후로, 우리는 그 일을하는 농부라고 불리는 전문가들을 발육 시켰고, 다른 사람들이 사회에 기여하는 다른 일을 할 수있게 해주었습니다. 나는 식료품 점에서 음식을 사는데, 필요한 경우 대부분 자체적으로 음식을 생산할 수 없을 것입니다. 우리는 훨씬 더 압축 된 시간 규모에도 불구하고 비슷한 일을하고 있습니다. 프로그래머는 다른 계층이 아닌 일부 계층을 전문으로합니다. GUI를 작성하는 평범한 사람은 스왑 공간과 같은 것이 있지만 운영 체제가 그것을 관리하는 방법에 대해 많이 알지 못하거나 신경 쓰지 않을 것입니다.

이 모든 결론은 더 이상 개발에 관한 것이 아니라는 것입니다. 지속적인 전문화 란 개발자가 커뮤니케이션 및 통합 기술을 지속적으로 개선해야한다는 것을 의미합니다.

모든 것과 마찬가지로, 당신은 조금 좋지만 너무 아파요. 문제는 너무 많은 시스템이 언제 멈출지를 모르는 것입니다-추상화를 한 번만 더하면 더 빨리 프로그램을 작성할 수 있습니다. 그러나 실제 상황에서 원하는만큼 간단하지 않은 코딩을 할 수 있습니다. 덜 특징적인 추상화로 보았던 것보다 가장자리에서 일하는 데 더 많은 시간을 할애하십시오.

여기에 설명되어 있습니다

또는 여기 - "한 줄의 코드로 500 명의 사용자를 도메인에 추가 할 수 있습니다"...

추상화는 복잡성을 숨기려고하지만 실제로는 복잡성을 숨기는 것입니다. 복잡성은 여전히 ​​여기서 제어력이 훨씬 적기 때문에 이러한 상황에 처하게됩니다.

젊은 프로그래머는 광범위한 라이브러리의 영역을 탐색하기 전에 저수준 프로그래밍을 더 배우는 데 도움이됩니까? 그렇다면 왜?

나는 그렇게 생각하지 않습니다. '아래의 계층'작업을 잘 아는 것이 유리한 상황이 여전히 많습니다. 예 :

• layer n에서 문제를 디버깅 할 때 layer 에서 발생하는 일 n-1(예 : 아래 레이어) 을 고려하여 설명 할 수 있습니다 . 레이어 0은 "트랜지스터"라고 생각하지만 트랜지스터 관련 문제를 설명하려면 물리학 (예 : 열)에 대해 이야기 할 것이므로 물리학은 실제로 레벨 0입니다.

• 코드를 최적화 할 때 (아쉽게도) 추상화 수준을 낮추는 데 도움이됩니다 (예 : 하위 수준 레이어로 알고리즘을 구현). 그러나, 컴파일러가되었다 정말 당신을 위해이 일을 잘 하면 실제로 관련된 모든 코드를 참조하십시오. 이러한 이유는 프로세서가 약한 경향이 있고 "와트 당 성능"이 데스크톱 시스템보다 훨씬 관련성이 높은 모바일 및 임베디드 장치의 붐으로 최근에 더 인기를 얻었습니다.

그러나 일반적으로 컴퓨터가 작업을 수행하는 것이 훨씬 쉬워졌습니다 (약간 비효율적 인 경우에도). 이전보다 프로그래머가 훨씬 많았습니다. 이 차례로 "인간"요소가 훨씬 더 중요했다 로버트 하비의 대답은 이미 "인간은 어떤 주어진 순간에 자신의 머리에 너무 많은 지식을 보유 할 수 있습니다"고 언급하고, 나는 요즘 매우 중요한 측면 것 같아요.

프로그래밍 언어 및 라이브러리 (예 : API) 디자인의 주요 동기는 인간의 뇌에서 일을 더 쉽게 만드는 것입니다. 오늘날까지 모든 것이 여전히 머신 코드로 컴파일됩니다. 그러나 이것은 오류가 발생하기 쉬울뿐만 아니라 이해하기도 어렵다. 그래서 그것은 매우 원합니다

• 작성하는 프로그램에서 논리적 오류를 찾는 데 컴퓨터가 도움이되도록하십시오. 정적 유형 시스템이나 소스 코드 분석기 ( Eric Lippert 가 요즘 꽤 인기있는 것으로 작동한다고 들었습니다 )와 같은 것들이 도움이됩니다.

• 컴파일러에 의해 효율적으로 처리 할 수있는 언어를 가지고 와 통신 의도 프로그래머의 다른 프로그래머를 쉽게 프로그램 작업을하려면를. 터무니없는 극단으로, 평범한 영어로 프로그램을 작성하는 것이 가능하다고 상상해보십시오. 동료 프로그래머들은 무슨 일이 일어나고 있는지 상상하기가 더 쉬울 지 모르지만 여전히 설명은 기계 강사로 컴파일러하기가 매우 어려울 것입니다. 그래서 당신은 컴파일러가 understan 수 있지만 어떤 언어 필요 도 이해할 수있다.

많은 (대부분의) 컴파일러가 여전히 매우 범용 적이라는 점을 감안할 때 매우 일반적인 명령어 세트가 있습니다. "버튼 그리기"명령이나 "이 영화 재생"은 없습니다. 따라서 추상화 계층 구조를 아래로 이동 하면 이해하고 유지하기가 매우 어려운 프로그램이 생길 수 있습니다 (컴파일하기는 쉽지만). 유일한 대안은 계층 구조를 위로 올라 가면서 점점 더 추상적 인 언어와 라이브러리를 만드는 것입니다.

"오래된 프로그래머가 이와 같은 혁신을 신의 선물 또는 추상화를위한 추가 계층으로 본다면 왜 그렇게 생각할까요?"

저는 34 년 정도 고등학교에 다니면서 Basic과 Z80 어셈블러로 시작하여 C, 다양한 4GL 언어, Scheme, SQL 및 다양한 웹 언어로 이동했습니다. 직업이 다루는 문제의 범위, 규모 및 깊이는 특히 1990 년대에 그 기간 동안 인플레이션 기간을 경험했습니다. 라이브러리, 프레임 워크 및 OS 서비스와 같은 구조는 모두 확장 된 문제 공간과 관련된 복잡성을 해결하기 위해 고안되었습니다. 그들은 신의 선물이나 그 자체의 부담이 아닙니다. 방대한 솔루션 공간을 지속적으로 탐색합니다.

그러나 IMHO의 "혁신"은 새로운 형태의 관점에서 더 잘 이해되고 옆으로 이동하는 것으로 잘못 인식되지 않습니다. 어떤면에서, 원시 형태가 구성되지 않거나 진화 초기에 내려진 결정을 고치거나 자신의 유해물을 재 처리 할 수없는 경우 생태계의 fecundity는 어려움을 겪습니다. 대부분은 아니지만, 우리가 계속 집중하고있는 일부 구조는 장기 가치 가치를 우선시하지 않습니다. 하이퍼 텍스트 및 그래프 기반 모델은 말할 것도없고 서비스 지향 및 도메인 기반 디자인과 같은 접근 방식은 변화하기 시작했습니다. 다른 생태계와 마찬가지로 결국 지배적 인 형태는 새로운 형태로 나아가게됩니다. 우리는 다양성을 허용함으로써 최선을 다합니다.

"젊은 프로그래머들은 광범위한 라이브러리의 영역을 탐색하기 전에 저수준 프로그래밍을 배우는 데 더 많은 이점을 제공합니까? 그렇다면 왜 그렇습니까?"

나는 대부분의 인간 언어가 잊혀진 이래로 오랫동안 은유에 기초하고 있다고 주장하기 때문에 과학 / 숫자 능력 관점에서 저수준 프로그래밍 학습을 지원할 것이지만, 우리는 규모와 범위를 지원할 기본 체를 찾는 것이 더 중요하다 하위 수준의 세부 사항을 안전하게 무시할 수있는 방식으로 해결해야 할 문제. 프레임 워크는 기본이 아니며 OS 또는 라이브러리도 아닙니다. 실제로 필요한 추상화를 수행하는 데 상당히 취약합니다. 실제 진보는 (a) 이전에 겪었던 일을 알고 (b) 이전에 탐구되지 않았거나 탐구되고 잊혀진 해결책의 공간을 탐구하기에 충분히 다른 무언가를 생각 해낼 수있는 소설로 생각할 수있는 사람들을 필요로한다.

OTOH는 귀하의 목표가 기술자 / 기계 수준으로 일하는 것이더라도 일부 수준의 저수준 프로그래밍 노출이 여전히 문제 해결 능력을 개발하는 데 도움이 될 것입니다.

저의 첫 번째 프로그램 (15 세 십대)은 1974 년에 PL / 1 에서 IBM 370/168 메인 프레임을위한 펀치 카드를 사용했습니다. 아버지는 IBM에서 일하고 있었고 일요일에 데이터 센터에 갈 수있을만큼 운이 좋았습니다.

그 당시 수천 개의 성명서 (예 : 천공 카드) 프로그램은 큰 프로그램이었습니다. 비주얼 인터페이스가 존재하지 않습니다 ( //GO.SYSIN DD *IIRC로 시작하는 펀치 카드 명령을 사용하여 "표준 입력"에서 읽은 일반적인 프로그램 이지만 JCL을 마스터하지 않았습니다 ). 알고리즘이 중요했고, 표준 라이브러리 IIRC는 오늘날의 표준에 의해 상당히 작았습니다.

오늘날 수천 줄의 프로그램은 일반적으로 작은 것으로 간주됩니다. 예를 들어, GCC 컴파일러는 천만 개 이상의 소스 코드 라인을 가지고 있으며 아무도 그것을 완전히 이해 하지 못합니다.

제 생각에는 오늘날 프로그래밍이 1970 년대와 상당히 다르다는 것입니다. 더 많은 리소스 (특히 기존 라이브러리 및 소프트웨어 프레임 워크)를 사용해야하기 때문입니다. 그러나 데이터 센터 소프트웨어 (예 : Google의 검색 엔진) 또는 일부 임베디드 소프트웨어를 개발하는 사람들은 1970 년대의 평균 프로그래머보다 알고리즘과 효율성에 많은 관심을 갖고 있다고 생각합니다.

나는 여전히 전체 수준을 이해하는 것이 여전히 중요하기 때문에 오늘날에도 저수준 프로그래밍을 이해하는 것이 중요하다고 생각합니다.

1970 년대와 오늘날의 주요 차이점은 개발자의 노력과 컴퓨터 성능 간의 비용 비율입니다.