도구에 대한 과도한 의존은 게으르다는 것을 의미합니까? [닫은]

uni에서 C ++로 프로그래밍을 시작하고 좋아했습니다. 다음 학기에는 VB6로 바뀌었고 싫어했습니다.

나는 무슨 일이 있었는지 말할 수 없었습니다. 버튼을 폼으로 드래그하면 ide가 코드를 작성합니다.

VB가 작동하는 방식을 싫어했지만 C ++에서 동일한 작업을 수행하는 것보다 빠르고 쉽다고 주장 할 수 없으므로 왜 인기있는 언어인지 알 수 있습니다.

이제 VB 개발자에게 C ++보다 쉽다고 말하는 게으르지 않고 많은 최신 언어가 C #과 같은이 추세를 따르고 있음을 알았습니다.

이것은 더 많은 비즈니스가 빠른 결과를 원할수록 더 많은 사람들이 이런 식으로 프로그래밍 할 것이며, 조만간 우리가 지금 프로그래밍이라고하는 것은 없을 것이라고 생각하게되었습니다. 미래의 프로그래머는 컴퓨터에 원하는 것을 알려주고 컴파일러는 스타 트렉처럼 프로그램을 작성합니다.

이것은 주니어 프로그래머에 대한 충분한 정보가없는 의견입니까?

편집 : 많은 답변에 왜 바퀴를 발명하고 나는 이것에 동의하지만 바퀴가있을 때 사람들은 바퀴를 만드는 방법을 배우고 귀찮게하지 않습니다. 나는 어떤 언어로든 거의 모든 일을 수행하는 방법을 Google에 알릴 수 있으며 언어의 절반은 디버깅을 할 때 오류를 해결하는 방법에 대한 코드가 무엇인지 전혀 모른다.

그것이 프로그래머가 게으르고 덜 유능 해지고 있다는 이론을 따라 잡는 방법입니다.

아니요, 개발자는 더 적거나 유능하지 않습니다. 그렇습니다. 알고 계신다는 점에서 실제 개발에 대한 요구는 꾸준히 감소하고 있습니다. 기업이 빠른 결과를 원하고 왜 그렇게하지 말아야합니까?

그러나 끝 점이 있습니다. 일부 개발자에게는 항상 필요합니다.

여러 프로젝트에서 많은 요구 사항이 동일합니다. 당신이 말하는 것은 UI 코드입니다. 대부분의 UI는 텍스트 상자, 확인란, 라디오, 선택 등의 특정 필드 집합으로 구성되며 처음부터 끝까지 개발할 필요가 없습니다. 따라서 추상화 코드는 모든 상용구 코드를 제거하기 위해 사용됩니다.

마찬가지로 데이터 레이어는 일반적으로 Insert This, Delete This, Replace This 및 동일한 데이터에 대한 수많은 다른보기에 불과합니다. 왜 계속해서 써야합니까? ORM을 발명합시다.

개발해야하는 유일한 것은 개발하려는 비즈니스에 고유 한 코드입니다.

그러나 항상 그 고유성이있을 것입니다. 비즈니스 기회가없는 곳에서 사람들은 항상 코드를 작성해야합니다.

또한 코드 작성보다 개발자가되는 것이 더 많다는 것을 명심하십시오. 순수한 어셈블리로 코딩하거나 Drupal 구성 요소를 결합하여 컨텐츠 중심 사이트를 만들 때 비즈니스 요구 사항을 컴퓨터가 이해하는 것으로 변환하고 있습니다.

소프트웨어 개발자가되는 가장 중요한 부분은 비즈니스 요구 사항을 컴퓨터에 충분히 설명 할 수있을만큼 충분히 이해하는 것입니다.

컴퓨터에 물건을 설명하는 데 사용하는 언어는 중요하지 않으며 가능한 한 중요합니다. 그리고 이것은 힘든 일이며, 게으른 게 없습니다.

유압 렌치를 사용하기 때문에 정비공이 게으르고 능력이 떨어 집니까?

이미지 두 사람, 브래드와 피트라고합시다. 그들은 매일 타이어를 교체하는 두 개의 차고에서 일합니다. 브래드는 똑똑한 사람입니다. 그는 더 나은 도구를 사용하면 자신의 업무를 더 빠르고 더 빨리 수행 할 수 있다는 것을 알고 있습니다. 유압 렌치를 사용하면 타이어를 더 많이 교체 할 수 있습니다. 고객은 더 짧은 대기열에서 기다리고 있습니다. 모두가 행복합니다. Bard는이 렌치가 때때로 너무 커서 다른 종류의 나사로는 그를 도울 수 없다는 것을 알고 있습니다.

한편, 피트는 유압 렌치는 신성 모독이며 브래드는 "진정한 정비사"가 아니라고 말합니다. 물론 피트는 브래드보다 절반 만 할 수 있지만 "올바른 방법"으로한다.

이제 어떤 차고 고객이 선택할 것이라고 생각하십니까? 하나는 20 분이 걸리거나 하나는 40 분이 걸립니다.

프로그래밍과 매우 비슷합니다. C ++은 좋은 언어이며 그 목적이 있습니다 (주로 성능). C #과 같은 언어에서 내가 좋아하는 것은 문제에 집중할 수 있고 C ++이 모호한 컴파일러 경고, 정의되지 않은 동작 등과 같은 모든 소음없이 알고리즘에 대해 생각할 수 있다는 것입니다. 오래된 메인 프레임과 최초의 PC에서는 인간의 두뇌가 여전히 멍청한 상태를 유지한다는 점에서 개발이 점점 더 복잡해지고 있습니다. 하나의 앱은 클라우드, 모바일, 데스크톱에서 실행될 수 있으며 많은 종속성, 보안 문제 및 기타 문제가 있습니다. 더 복잡한 문제에 초점을 맞추고 해결할 수있는 더 나은 도구를 원합니다.

더 나은 도구를 사용하여 작업을 완료하십시오. 그것은 아무 문제가 없습니다.

이제 우리는 무엇을 프로그래밍이라고 부릅니까?

당신은 말한다 :

미래의 프로그래머는 컴퓨터에 원하는 것을 알려주고 컴파일러는 스타 트렉처럼 프로그램을 작성합니다.

실험을 해보자. 스타 트렉을보고, 컴퓨터가 '미묘한'행동을 취하도록 명령 한 것을 해석해보십시오.

• 차, 얼 그레이, 뜨거운-> 많은 증기.
• 차, 얼 그레이, 섭씨 60도-> 웅덩이 및 증기 구름
• 얼 그레이, 섭씨 60도-> 웅덩이
• 얼그레이, 섭씨 60도, 컵에 담긴 컵
• 얼 그레이, 컵에 섭씨 60도, 0.2 리터. -> 마지막으로 (더보기

프로그래밍 : '메모리 사용, 포인터 등에 대해 알기'를 호출하면 그렇습니다 .'http, openid, unicode에 대해 알면 더 중요합니다. '

그러나 모든 사람은 '사고의 복잡성'이라고 생각하며 프로그래머로서의 실제 직업은 '빌드 머신으로 인해 문제를 해결하여 우연히 문제를 충분히 이해하여 작업을 수행하도록하는 것'과 그 정의에 따라 대화하는 사람이라고 생각합니다. 스타 트렉 컴퓨터를 사용하는 프로그래머는 프로그래머 여야합니다 (즉, 지금과 같은 장점이 있습니다).

프로그래머는 게으르지 않습니다. 프로그래머는 항상 게으르다. 게으르다는 것은 직업의 근본적인 특성의 일부입니다. 문제는 사람들이 게으르다는 것이 부정적인 것이라고 가정한다는 것입니다. "게으른"프로그래머가되는 것이 미덕입니다.

"더 똑똑하지 않고 더 똑똑하게 일하라"는 옛 속담을 기억하십시오. 이것이 프로그래머의 근본적인 원동력입니다.

내장하고 열심히 일을 좋아했기 때문에 최초의 컴퓨터가 그것을하지 않았다 프로그램 된 사람, 그들은 그것을했다 피해야 도 열심히 일을. (손으로 계산 페이지를 수행)

'게으른'것은 프로그래머가 프로그래밍하는 근본적인 이유 중 하나입니다. 우리가 새롭고 더 높은 수준의 언어, 더 나은 디버거 및 IDE, 쉘 및 빌드 스크립트 등을 작성하는 이유는 무엇입니까?

프로그래머는 문제, 자신이하고 생각하는 모든 것을 살펴 본다.

"이것을 자동화 할 수 있습니까?" , "얼마나 많은 시간 것이라고 걸릴?" , "얼마나 많은 시간을 절약 할 수 있을까요?"

우리는 게으 르기 때문에이 작업을 수행합니다. 훨씬 더 재미있는 일을 할 수있을 때 반복적이고 지루한 작업을하고 싶지 않습니다.

프로그래머가 게으르지 않았다면 어떤 프로그래머도 새로운 언어 나 컴파일러를 작성해야 할 필요성을 본 적이 없을 것입니다.

프로그래머가 "게으르다"는 개념까지는 "일을 찾아보아야"하기 때문에 누가 신경 써야하는지. 특정 언어의 모든 뉘앙스를 배우는 것이 더 효과적이라는 가정 (그리고 무언가를 찾지 않아도 됨)은 필요할 때 필요한 것을 찾아 사용하는 것입니다. 또한, 물건을 찾는 과정은 학습 과정이며 이와 같은 사이트가 존재하는 바로 그 이유입니다.

누군가가 어려운 프로그래밍 작업을 원한다면 원시 코드를 16 진수로 직접 코딩하도록 지시합니다. 그거 요? 더 어려운 것을 원하십니까? 이제 디버깅하십시오.

가비지 컬렉터가 게으른 언어와 같은 언어를 사용하는 사람들은 우선 자동 변속기가 게으른 자동차를 운전하는 사람들에게 전화를 겁니다. IMO 그것은 어리 석다.

역량에 관해서는, 프로그래밍은 예전보다 훨씬 인기 있고 평등 한 직업입니다. 그렇습니다. 지식이 부족한 많은 새로운 사람들이 있습니다. 그러나 유능한 프로그래머가 갑자기 줄어드는 것은 아닙니다. 실제로 더 있습니다. 벨 커브의 잘못된면을보고 계십니다.

"그렇다, 정보에 구애받지 않은 주니어 프로그래머는 게으르고 능력이 떨어졌다"고 말하고 싶은 마음이 들지만, 진지한 대답을 해보자.

많은 것들이 쉬워졌지만 우리에게는 더 많은 것이 기대됩니다. 현재 잘 만들어진 GUI 응용 프로그램 (탭 뷰, 편집 가능 및 정렬 가능한 그리드, Excel 내보내기 등)에서 일반적으로 제공되는 많은 기능을 갖춘 웹 응용 프로그램을 만들고 있습니다. 내가 사용하는 도구 (ExtJS 등)는 그러한 앱을 만드는 데 합리적으로 저렴합니다.

10 년 전에는 그러한 앱을 만드는 것이 거의 불가능했을 것입니다. 그러나 10 년 전에는 고객에게 HTML 테이블이있는 간단한 HTML 양식으로 충분했을 것입니다. 오늘날에도 같은 노력으로 더 나은 (적어도 더 아름다운) 결과가 가능하며 고객은 그 결과를 기대합니다!

일반적으로 오늘날의 소프트웨어 개발자는 20 년 전의 소프트웨어 개발자보다 더 많은 언어를 알아야합니다. 당시에는 C 나 SQL과 같은 것으로 충분했습니다. 현재는 동일한 프로젝트에서 JavaScript, HTML, Groovy, Java, SQL을 모두 사용하고 있습니다.

C ++ / VB 나누기가 내 마음의 이유 또는 증상이 아니지만 프로그래머는 어떤면에서는 덜 유능하고 게으르지 만 다른 분야에서는 더 유능합니다.

GUI 빌더를 사용하는 것은 게으르지 않으며 단지 다릅니다. 작업에 필요한 도구에 관한 것입니다. 어셈블러 프로그래머가 C ++ 프로그래머를 게으른 것으로 불렀다면 헛소리라고 부르며 C ++ 및 VB도 마찬가지입니다. VB를 사용하면 일부 제어 비용을 들이지 않고 빠르게 무언가를 수행 할 수 있습니다. 코딩 시작의 장벽은 확실히 낮지 만 게으름과는 매우 다릅니다. 당신은 다른 것을 배우고 다른 방식으로 적용합니다. VB 프로그래머는 C ++ 프로그래머가 비생산적이기 때문에 게으르지 않으며 단지 다른 방식으로 작동하고 생산합니다.

더 넓은 관점에서, 일반적으로 프로그래머 교육은 그 어느 때보 다 나아졌습니다. 예를 들어 소스 컨트롤을 사용하지 않는다는 아이디어는 10 년에서 20 년 전에는 사실이 아니었던 지금은 거의 모든 사람들에게 매우 끔찍한 일입니다. 마찬가지로 자동화 된 단위 테스트, 지속적인 통합 등을 이해하고 사용하기를 원하기 때문에 이전보다 더 유능합니다.

그러나 내가 생각한 것은 사람들이 더 이상 문제를 해결하는 방법을 더 이상 알지 못하고 거의 모든 주류 언어에 해당된다는 것입니다. 현재 모든 문제에 대한 즉각적인 반응은 Google이며 시간의 95 %가 훌륭하지만 작동하지 않을 때 어떻게해야할지 모르는 프로그래머가 너무 많습니다.

기본을 이해하지 못한다는 것이 아니라 (실제로 큰 문제는 아닙니다.) 문제를 해결할 수있는 방식으로 문제를 해결할 수없는 것입니다. 움켜 쥐고 있습니다.

Google 이전에는 선택의 여지가 없었습니다. 당신의 자원은 당신의 팀이었고, 당신이 접근 할 수있는 수십 권의 실제 책과 두뇌였습니다. 그것은 당신이 문제를 발견하면 첫 번째 교장과 가까운 곳에서 스스로 문제를 해결할 가능성이 있다는 것을 의미합니다.

그리고 이것은 당신이 사용하는 언어에 관계없이 사실이었습니다. VB는 수준이 높고 많이 숨겨져 있지만 문제 해결과 관련하여 실제로 해결해야 할 것이 더 많음을 의미합니다. 무언가가 효과가 없다면 통제력이 떨어질수록 창의력을 발휘하고 열심히 일해야합니다. VB 프로그래머 (그리고 경험에서 말하면)는 C ++ 사람보다 잘 알지 못했지만 다른 것을 알았지 만 문제를 해결하는 방법을 모두 알고있었습니다.

그러나 요즘 프로그래머에 대한 비판으로 볼 때 가혹한 일이지만, 필요하지 않기 때문에 기술을 개발하지는 않지만 필요할 때 기술을 선택한 사람들과 비교할 때 약점입니다.

나는 당신의 프로필에서 당신이 23 살이라는 것을 알고 있습니다. 내 치아를 넣고 아주 오랫동안이 일을하고있는 나이의 약 두 배 정도의 누군가의 관점을 알려 드리겠습니다.

네트워크가 있다면 컴퓨팅 성능, 스토리지 및 네트워크 대역폭으로 시작하여 모든 것이 훨씬 적었습니다. 이러한 희소성은 합리적으로 수행 할 수있는 작업에 제한을 두어 모든 것을 머리로 감싸기가 훨씬 쉽습니다. 오늘날 우리가 운영하는 소프트웨어는 25 년 또는 30 년 전에 작업했던 것보다 훨씬 더 능력이 있으며, 이러한 기능은 훨씬 더 많은 것을 의미합니다. 따라서 한 사람이하기에는 모든 것에 대한 세밀한 이해가 훨씬 어려워집니다. 그중 일부는 사물이 계속 복잡해지고 계속 증가한다는 사실과 관련이 있으며 그중 일부는 연령의 부작용과 관련이 있습니다.

컴퓨팅 생태계는 생물학적 시스템과 매우 유사 해지고 있습니다. 인간은 단일 세포 유기체보다 더 복잡하며, 우리 중 일부는 무언가를 잘 수행하려면 전문화해야합니다. 내 뇌 세포는 끔찍한 일에 능숙하지만 신장에 들어간 경우 신장에 걸리면 사라질 것입니다. 마찬가지로, 디지털 신호 프로세서 작성에 능숙한 사람은 전문 지식이 아니기 때문에 전체 텍스트 인덱싱이 어떻게 작동하는지 전혀 모를 수도 있습니다. 그러나 둘 다 조금 진화하고 필요한 경우 이해하는 법을 배울 수는 있지만, 얼마나 멀리 자신을 퍼 뜨리고 여전히 자신이하는 일에 효과적 일 수 있는지에는 한계가 있습니다.

... 아무것도 작동하지 않을 때까지 물건이 어떻게 작동하는지 신경 쓰지 않습니다.

해야 할 일이있을 때, 사용하는 도구 (라이브러리, RDBMS, 전체 서브 시스템 등)가 제대로 작동한다는 믿음을 가져야합니다. 경험으로 얻을 수있는 것 중 하나는 도구에서 장애를 제거하고 문제를 해결 한 다음 다시하고 있던 토끼 구멍을 고르는 기능입니다.

이제 VB 개발자에게 C ++보다 쉽다고 말하는 게으르지 않고 많은 최신 언어가 C #과 같은이 추세를 따르고 있음을 알았습니다.

그것은 모두 관점의 문제입니다. 나는 C ++가 존재하는 것을 보려고 왔으며 그 추세도 따릅니다. C ++는 C보다 훨씬 쉽게 작업을 수행하고 C는 어셈블리보다 훨씬 쉽게 작업을 수행하고 어셈블리는 직접 opcode를 작성하는 것보다 훨씬 쉽습니다. 많은 어셈블리를 작성하고 처음부터 수동으로 몇 가지를 조립 한 사람으로서 C ++ 프로그래머는 "쉬운"경로로 3 단계 내려 가게됩니다.

내가 오랫동안 오랫동안 유지해온 것은 :

Visual Basic Language 의 가장 큰 장점 중 하나는 초보자가 많은 유용한 작업을 상당히 빠르게 수행 할 수 있다는 것입니다.

Visual Basic Programmers 의 가장 큰 약점 중 하나는 많은 유용한 것들을 상당히 빨리 배우는 법을 배우고 더 이상 아무것도 배우지 않는다는 것입니다.

첫 번째 연습을 프로그래밍하는 것을 가르 칠 때 수업 첫 날은 NOTEPAD에서 응용 프로그램을 작성하고 VCC 또는 VBC를 사용하여 컴파일하는 방법이었습니다. 그렇습니다. 이들은 프로그래머로서 일상적으로하지 않지만 "F6"을 눌렀을 때 일어나는 일을 이해해야합니다.

프로그래머가 툴을 최대한 활용하기를 기대하는 것만 큼 (일반적으로) 더 게으르지 않습니다. 하루에 10,000 번씩 "get / set"을 입력 할 필요가 없습니다. Visual Studio 및 Code Smith 및 Resharper와 같은 다른 도구를 사용하여 이미 알고있는 작업을 수행하여 계산에 노력을 기울일 수 있습니다. "새로운"일을하는 방법. 그것은 나를 더 화려하게 만들지 않으며, 그것은 나를 "혁신적"으로 만든다.

전문 개발자로서 우리는 바퀴를 재창조하는 '시간 낭비'가 아니라 바퀴를 만드는 데 무엇이 필요한지 명확하게 이해해야합니다. 이것들은 우리가 학생 개발자로서 배워야 할 것들입니다 (그러나 불행히도 종종 그렇지 않습니다). 개발자가 일부 "블랙 박스"기술을 이해하지 못하면 실제로 "유능한"기술을 덜 사용하게됩니다. 대부분의 개발자는 ODBC 드라이버의 작동 방식을 '기본적으로 이해'하는 것뿐입니다. 유능한 운전자가되기 위해 변속기가 어떻게 작동하는지 알아야합니까? 나는 말하지 않을 것입니다. 저를 좀 더 유능한 자동차 소유자로 만들 수 있습니까?

신속한 애플리케이션 개발 의 필요성 (필수 위키 링크 : http://en.wikipedia.org/wiki/Rapid_application_development )는 개발자가 그들이 구현하는 방법을 이해 할 필요가 없기 때문에 적은 코드와 새로운 개발자가 덜 이해하고 작성하는 것이 의미있다 집중할만한 수준이 높기 때문에 연결된 목록입니다.

고기를 잡거나 죽이고 껍질을 벗기고 살육하고 치료할 수는 없지만 아래층 카페에서 그 사람이 할 수 있을지는 의심하지만 비즈니스맨이 모르는 개발자로부터 앱을 얻는 것처럼 여전히 그에게서 베이컨 샌드위치를 ​​얻습니다. 포인터 (나처럼!)

위대한 과학 분야는 다른 거인의 어깨에 서있는 거인의 예라고합니다. 또한 소프트웨어 산업은 다른 난쟁이의 발가락에 서있는 난쟁이의 예라고도합니다.
— 앨런 쿠퍼

훌륭한 소프트웨어 개발자는 바퀴를 재발 명하는 사람이 아닙니다. 그는 자신보다 먼저 만들어진 도구를 사용할 수 있습니다. 그는 수백 번이나 쓴 지루한 것들을 재 작성하는 데 시간을 허비하지 않으며, 너무 지루 해져 이미 이미 높은 품질의 버전으로 존재합니다.
이미 둥근 돌 디스크가 번들로 제공되는 언어를 제공하면 바퀴를 재발 명하는 데 너무 많은 시간을 소비하지 않을 가능성이 높습니다. C로 작성된 모든 문자열 복사 루틴에 대해 센트를 얻은 경우 전체 소프트웨어 산업을 구입할 수 있습니다.

게으름은 실제로 프로그래머 의 세 가지 큰 미덕 중 하나입니다 . 당신이 말하는 도구는 좋은 프로그래머를 위해 좋은 프로그래머를 위해 만들어 져서 중복성과 지루함을 줄이고 생산성과 동기를 증가시킵니다. 이러한 도구 는 실제로 초보자가 프로그래밍 측면을 더 깊이 이해하지 못하므로 초보자에게 부정적인 영향을 줄 수 있습니다 .

아뇨. 당신은 나이가 들었습니다.

농담이 아니라, 당신이 겪고있는 것은 개발자들에게 일종의 통행권입니다. 최초의 고급 언어가 집회를 대체 한 이래. 그 당시에는 모든 ASM 프로그래머가 같은 것에 대해 불평하는 것을 들었습니다. 5 년 후, 모든 Ruby on Rails 개발자들은 새로운 도구가 얼마나 게으른 지 사람들이 얼마나 게 으르는지에 대해 불평 할 것입니다.

이 기술은 기계가 우리 모두를 파괴 할 때까지 반복 될 것이다. "기술 X가 개발자들이 내가 항상 사용했던 기술 Z보다 더 느리고 더 나쁘게 만드는 것처럼 보입니까?"

좋은 소식은 컴파일러가 먼 길을 왔지만 사람들은 여전히 ​​첨단 기술 혁신의 대부분이 아니라 많은 것들에 대해 어셈블리와 C 및 다른 모든 오래된 기둥이 필요하다는 것입니다. 당신이 그 최첨단에 있고 싶다면 기술 세트를 업데이트하는 것이 좋습니다.

내 경험에 비추어 볼 때, 언어의 결함이 아닙니다. 개발자 자신의 잘못입니다. 나는 일을 제대로하고, 스스로를 향상 시키거나, 몇 년 동안 해왔 던 것과 같은 쓰레기를 버리는 것 외에는 아무것도하지 않는 많은 개발자들과 함께 일해 왔습니다. 이 사람들을 개선 시키려고 노력하는 것은 벽돌 벽과 대화하는 것과 같습니다. 절반은 과거에 사용하지 않았거나 생산성을 향상시킬 수있는 것으로 "기회를 취하지"않는 것에 대해 전혀 무지합니다. .

보다 진보 된 언어는 문제가 아니며,이 직업을 끊임없이 발전하는 공예로 취급하지 않는 프로그래머입니다. 새로운 것을 모두 알고 있거나 모든 새로운 악 대차에 뛰어들 필요는 없지만 최소한 자신이하는 일을 더 잘 하려고 노력해야합니다 .

구체적인 예를 들면 : 저는 무역 분야의 .NET 개발자입니다. 유능한 .NET 개발자가 LINQ, Entity Framework, WPF, MVC 등과 같은 것들을 알고 있을 것으로 기대합니다 . 그들은 그것을 사용하거나 직장에서 그것을 밀어 낼 필요는 없지만, 적어도 "이것이 존재한다"는 것에 대한 지속적인 이해는 내가 너무 자주 보는 절대적인 우둔보다 낫습니다.

나는 현재 약 4 년 동안 코딩을 해 왔으며 거의 ​​전적으로 C #입니다. 나는 College와 Uni에있을 때 C ++을 배웠지 만 지금은 많은 것을 할 수 없었습니다.

따라서 GUI 개발의 경우 게으른 것으로 보일 수 있지만 해당 부분을 코딩하는 데 덜 집중하고 응용 프로그램 자체의 논리를 개발하는 데 더 집중할 수 있음을 다시 알 수 없습니다.

따라서 경쟁력이 떨어지기보다는 초점을 옮기고있을 것입니다. 클라우드 컴퓨팅 및 SOA와 같은 통신 및 분산 시스템에 많은 관심을 기울일 것입니다. 이것은 중급 프로그래머의 생각과 비슷할 수 있습니다.

프로그래밍 작업에 대한 진입 장벽이 해마다 낮아지고있는 것은 사실입니다. 예를 들어, 소프트웨어 및 아티스트가 주로 전문 기술자가 아닌 엔지니어는 스크립팅 언어를 사용하여 코드를 작성할 수 있습니다.

이는 폭을 고려할 경우 역량 수준이 실제로 증가했음을 의미합니다. 아티스트가 프로그래밍 할 수 있다는 것은 이제 예술적 기술을 가진 프로그래머가 더 많다는 것을 의미합니다.

"프로그래머"와 "실제 프로그래머"사이에는 차이가 있습니다. HTML을 프로그래밍 언어라고 부르지 말고 많은 "HTML 프로그래머"가 있습니다. 여러분 (프로그래머 / 개발자)은 동료들과 경험을 쌓을 수 있습니다. "인터넷을 끄십시오 (실제로는 검색 엔진을 사용하지 못하도록하십시오"). 그러면 다양한 "프로그래머"가 직업없이 그들이 할 수있는 것은, 예를 들어 텍스트 검색이 필요하다면 "% language_name %에서 텍스트 검색"을 검색해야한다는 것을 알고 있습니다. Boyer-Moore와 Knuth-Morris-Pratt 알고리즘의 차이점은 무엇입니까?

따라서 IMO, 프로그래밍은 문제를 해결하는 것을 의미하며 'STL'및 기타 중요한 것들을 갖춘 최소 하나의 프로그래밍 언어로 잘 알고 있습니다. 프로그래밍은 예술이며 일종의 삶입니다. 모든 사람이 할 수있는 것은 아닙니다.

필요한 것보다 풍자에 대해 죄송하지만 이 기사 가 나보다 더 나은 것으로 생각 합니다 .

내가 잘못?

UPD : 가장 중요하고 중요한 것은 알고리즘, 데이터 구조 등과 같은 기본 사항에 대한 지식입니다. 오늘 실수로 제거 될 경우 라이브러리 / 표준 함수 등을 구현할 수있는 사람은 몇 명입니까? IMO, 프로그래머는 개발 / 잘 알려진 '외국인'코드 (라이브러리 / 프레임 워크 / 등)를 사용해야하지만 항상 바퀴를 재발 명 할 수 있어야합니다!

VB는 사용하기 쉬우 며 게으른 프로그래머는 VB를 선택합니다.

VB는 사용하기 쉽다는 큰 신화로 둘러싸여 있다고 생각합니다. 이 신화는 원래 어느 정도 사실이었다. 공룡이 지구를 걸었던 1991-1994 년 경 VB와 델파이에는 실제 RAD 툴이 두 개 밖에 없었다. 그것들은 상당히 비슷하지만, 참고 : 델파이와 VB는 똑같이 사용하기 쉽습니다! 그들 사이의 유일한 차이점은 VB가 완전히 비논리적 인 구문을 가지고 있으며 엄청나게 느린 프로그램을 생성했다는 것입니다.

C / C ++ GUI는 MFC 또는 원시 Win API로 작성되었습니다. 따라서 VB는 Microsoft 대안보다 사용하기가 훨씬 쉽습니다. 그런 다음 소문 공장은 다음과 같이 진행되었습니다.

• VB는 Microsoft C / C ++ / Win API보다 사용하기 쉽습니다. ->
• VB가 더 사용하기 쉽습니다. ->
• VB는 사용하기 쉽습니다. ->
• VB가 가장 쉽습니다.

파스칼은 제정신이며 논리적 인 언어이기 때문에 델파이가 항상 쉽지만은 않더라도이 소문은 계속되었습니다.

그런 다음 90 년대 후반 Borland는 Delphi : C ++ Builder에 해당하는 C ++를 출시했습니다. 이제 똑같이 쉬운 도구가 3 개있었습니다. 이시기에 VB를 사용하는 몇 가지 합리적 논쟁이 사라졌다. 그러나 신화는 여전히 살아있었습니다. "VB가 가장 쉽다".

그런 다음 Java가 등장했으며 JAD라는 Microsoft fiasco 버전에도 여러 RAD 도구가있었습니다. 그러나 VB 신화는 계속되었습니다.

그런 다음 Microsoft는 C ++에 대한 RAD 지원도 제공했으며 C #을 개발하여 .NET이라는 하나의 큰 조직으로 만들었습니다. VB 신화는 여전히 살아남 았기 때문에 오래된 VB 개발자가 C ++ 또는 C # 대신 VB.NET을 사용하도록 속일 수있었습니다. VB.NET은 이전 VB 버전과 호환되지 않았지만

오늘날 VB는 완전히 중복 된 언어입니다. RAD 도구는 다른 RAD 도구보다 쉽지 않습니다. 언어 구문은 끔찍하기 때문에 실제로 나쁜 프로그램 디자인과 나쁜 프로그래밍 연습을 장려합니다.

"프로그래밍"이라는 기치 아래 함께 모여있는 다양한 활동과 규모의 "기술자"와 관련된 훨씬 더 많은 노동자들이 있습니다. PHP로 웹 사이트를 구성하기 위해 특정 문제를 해결하기 위해 컴파일러를 작성하거나 알고리즘 세트 중에서 선택할 필요가 없습니다. 산업 / 사회는 웹 사이트를 제작하는 많은 사람들 (명백히)과 더 어려운 문제를 다루는 특정 프로그래머도 필요합니다. 그 두 번째 그룹은 전체적으로 게 으르거나 무능하지 않거나 비행기가 화염에 빠질 것입니다. 임의의 현금을 제공하는 ATM, 치명적인 양의 방사선을 제공하는 X 레이 기계, 광란의 금융 시장 등. 그 마지막에 대해 :-)

이것의 한 가지 측면은 다른 모든 대답이 희미하게 보일 뿐이라고 생각합니다. 이것이 저수준 언어에서 고급 언어로가는 일반화 된 추세라는 것입니다.

그렇습니다. 소프트웨어 산업은 저수준 언어에서 고수준 언어로 옮겨 가고 있으며, 더 나은 도구를 개발하는 한 항상 그럴 것입니다. 그렇습니다. 오늘날 표준에 따라 기본적인 작업을 수행하기 위해 열심히 노력해야했기 때문에 이는 게으른 것으로 간주 될 수 있습니다. 그러나 나는 덜 유능한 말을하지 않을 것입니다. 역량은 단순히 구현에서 디자인으로 이동하고 있습니다.

낮은 수준 다소 주관적이지만 낮은 수준에서는 하드웨어에 더 가까이 다가 가고 있습니다. 손 잡기와 의도에 대한 가정이 적습니다. 기본 도구가 제공되고 작업을 수행하는 것은 프로그래머에게 맡겨져 있습니다. 낮은 수준의 언어가 가장 먼저 나 왔으며, 일반적으로 높은 수준의 언어가 시작될 때 존재하지 않았기 때문에 구식 경비원의 도구입니다. 항상 저수준 개발이있을 것입니다. 그러나 나는 웹 사이트를 조립하지 않을 것이다.

높은 수준 높은 수준 의 목표는 기본 기능을 자동화하고 프로그래밍을 단순화하는 것입니다. 새로운 프로그래머를위한 진입 기준을 낮추고, 더 빠르게 작업을 수행하며, 종종 오버 헤드로 데이터를 표현하고 처리하는 방식을 표준화합니다. 문자열을 고려하십시오. 초기에는 누군가 az에 1-26을 사용했고 5 비트 만 사용했으며 단어의 크기를 알아야했습니다. 그런 다음 ascii 표준이 개발되었으며 종료 문자가있는 C 문자열이있었습니다. 이제 버퍼 오버플로를 피하기 위해 처리하는 객체와 이스케이프 문자를 허용하지 않는 특수 하위 유형이 있습니다. 또는 루프. "for"루프는 "while"루프보다 약간 높은 레벨입니다. "while"루프는 실제로 GOTO를 호출하는 구조화 된 방식을 나타냅니다.

또한,

미래의 프로그래머는 컴퓨터에 원하는 것을 알려주고 컴파일러는 스타 트렉처럼 프로그램을 작성합니다.

미래에 오신 것을 환영합니다! 이것이 바로 컴파일러가하는 일입니다. 예전에는 사람들이 기계 코드를 직접 작성해야했습니다. 이제 우리는 그것을 자동화하고 컴퓨터에 기계 코드를 작성하는 방법을 간단히 알려줍니다.

프로그래머가 지불해야 할 일에 대한 시야를 잃어 버린 길을 어딘가에 생각합니다.

우리의 결과물은 코드가 아니며 작동하는 소프트웨어입니다.

우리는 손으로 자른 도브테일이 들어간 모든 수동 "기술"때문에 부가 가치를 부여하는 가구를 만들고 있지 않습니다.

우리는 컴퓨터의 비즈니스 문제를 해결하기 위해 돈을받습니다). 적은 비용으로 동일한 제품을 더 적은 시간에 제공 할 수 있다면 C ++ 프로그램이 더 복잡하기 때문에 우수하다는 주장을 포기하는 것이 우리의 의무라고 생각합니다.

다음과 같은 이유로 (핵심 프로그램 개발자 / 개발자 수) 비율이 감소하고 있습니다.

• 도구가 쉬워지고 있습니다. 같은 문제에 더 적은 인재가 필요하다는 의미입니다

• 사람들은 IT 기술에 익숙해지고 있으며, 맞춤형 도구에 더 많은 돈을 투자 할 의향이 있습니다.

• 컴퓨터 과학 문학은 기하 급수적으로 성장하고 있으며 전문화와 노동 분업이 증가하고 있으므로 모든 것에 대해 이야기하는 "아리스토텔레스"사람들이 더 이상 없습니다 (실제로 추상화 계층으로 인해 모든 것을 알 필요는 없습니다)

• 더 많은 일자리 제공, 필터 풀림

• 수명주기마다 더 많은 자동화가 필요하며 수요가 증가하고 공급이 충분하지 않습니다.

• 인구 대비 개발자 비율이 증가하고 있습니다.

  따라서 컴퓨팅이 더 개방 된 영역이기 때문에 사람들은 더 느리고 경쟁력이 떨어지지 않습니다.

많은 대답은 왜 바퀴를 발명했는지에 동의하며 나는 이것에 동의하지만 바퀴가있을 때 사람들은 바퀴를 만드는 법을 배우고 귀찮게하지 않습니다.

당신은 어떻게 든 바퀴가 여전히 만들어 졌다는 사실을 통해 전체 요점을 훼손하고 있습니다. 나는 당신의 요점을 알지만, 어떤 분야에서든지 저수준의 물건에 관심이있는 사람들이 충분하다는 것을 알았습니다. 예를 들어, Qt를 사용하여 GUI를 빌드합니다. 그 도구는 마법으로 도착하지 않았으며 사람들은 저수준 물건과 내가하는 물건 사이의 연결을 개발했습니다. 소수의 사람들이 저수준 물건을 이해하지 마십시오. 소수의 사람들도 자신의 음식을 죽이거나 자신의 차를 수리 할 수 ​​있지만 사회는 살아남을 수 있습니다.

1940 년대 이전의 컴퓨터는 유선 회로였습니다. Von Neuman은 저장된 메모리 위치에 대한 아이디어를 생각해 냈습니다. MIT의 프로그래머들은 자신의 거래를 너무 쉽게 할 수 있다고 생각했습니다. 그런 다음 어셈블리가 나온 다음 FORTRAN, ada, C, c ++, java 등이되었습니다. 요점은 언어의 요점이 점점 더 추상화 될 수 있다는 것입니다. 그것은 항상 목표였으며 그것이 C ++이 그 다음에 잡힌 이유입니다. 저의 가장 큰 소고기는 대학이 더 이상 학생들에게 컴퓨터에 대해 가르치지 않는다는 것입니다. 나는 자신의 손등과 같은 C ++을 모른다면 C # 프로그래머를 고용하지 않습니다. 왜? 나쁜 프로그래머가되기가 너무 쉬우므로 점점 더 추상적 인 언어가됩니다. 포인터, 메모리 관리, 동적 바인딩 등을 이해해야합니다. . 내부 및 외부에서 C #을 이해하여 코드 기반에 기여할 수 있다고 생각합니다. 또한 Visual Studio를 사용하기 전에 파일 만들기로 인해 어려움을 겪습니다. 즉, C #과 좋은 IDE를 좋아하지만 제대로 이해하면 도구처럼 좋습니다. 내 의견으로는, 추상화는 추상화되고있는 세부 사항을 이해할 때 가장 유용합니다. 아주 오래된 아이디어입니다. 추상화와 세부 사항의 관계에 대해서는 Thomas Aquinas를 참조하십시오.

엔트리 레벨 개발자에게는 Windows API를 사용하여 몇 가지 응용 프로그램을 작성하는 것이 좋습니다. 그런 다음 완료 한 후에는 모든 양식이 일반 창 클래스에서 상속되는 위치를 객체 지향으로 만듭니다. 이벤트 루프를 캡슐화하고 함수 포인터를 폼 클래스로 다시 촬영하도록합니다. Microsoft가 이미 System.Windows.Forms라는 이름으로이 작업을 수행했습니다. 즐기세요

웹 개발자라면 POST, GET 등을 이해하고 페이지를 스크립팅 할 수 있도록 몇 가지 CGI 프로그램을 작성하게하십시오. ASP.NET과 PHP가 훨씬 더 의미가 있습니다.

그들이 네트워크에서 저수준에서 작업하고 있다면 소켓을 사용하여 몇 가지 응용 프로그램을 작성하여 이미 수행 한 라이브러리에 소개하십시오.

나는 이것이 그들 자신의 문제를 해결하기위한 도구와 올바른 직감을 제공하기 때문에 장기적으로 생산성을 향상 시킨다는 것을 발견했다.

대학은이 일을하기로되어 있지만, 반드시 그런 것은 아닙니다.

즉, 나는 재귀 알고리즘과 링크 된 목록을 작성하여 강탈 당하지 않았기 때문에 대학에서 나올만한 가치가있는 프로그래머를 찾는 것이 점점 어려워지고 있음에 동의합니다. 또한 그들은 일반적으로 Java 또는 .NET 코스 만 있었으므로 작동 방식에 대한 지독한 사실을 이해하지 못합니다. 그래도 추상화는 올바르게 사용될 때 매우 유용합니다.

조만간 우리가 지금 프로그래밍이라고 부르는 것과 같은 것은 없을 것입니다.

나는이 점에 동의하지 않습니다.
의식이 무엇인지 알지 못하면 프로그래머의 직업은 안전합니다.

이것이 바로 "생각하는 기계"의 모습입니다.

-주제 변경을 중지하십시오!
나는 우리의 사랑이 특별하다고 생각했습니다.
-주제 변경을 중지하십시오!
-주제를 바꾸지 않습니다.
-너는! 우리가 말하는 것을 이해하지 못하는 것에 대해 이야기하려고합니다.
-가까이 있지도 않습니다. 내가 가장 좋아하는 비틀즈 노래는 전 세계에 있습니다. 당신은 무엇입니까?

나는이 요점을 모르는 프로그래머들만이 종말이라고 생각합니다.

예 : Dehumanizer의 답변 :

Boyer-Moore와 Knuth-Morris-Pratt 알고리즘의 차이점은 무엇입니까?

그리고 "이 시점"이란 말입니다. 컴퓨터가 최상의 알고리즘을 능가하는 것은 잘못된 일입니다. 대신 프로그래머는 우리가 해결하려는 문제에 대해 이야기하면서 컴퓨터를 상황에 맞게 지원해야합니다.

도구 자체는 문제를 해결하지 않고 프로그래머를보다 효율적으로 만듭니다.

"총은 죽이지 않고 인간은 죽는다"와 같습니다.

절대적으로하지. 내 경험상, 올바른 개발 도구를 사용하면 품질을 저하시키지 않으면 서 빠른 응용 프로그램 개발이 가능합니다. 사실, 나는 "도구에 대한 과도한 의존"으로 인해 품질이 향상되었다고 주장합니다. 또한 개발 도구는 학습 곡선을 줄이고 프로그래밍에 더 많은 사람들을 소개 할 수 있습니다. 물론 초보자 프로그래머가 많을수록 단점이 있지만, 결국에는 창의적인 프로세스를 지원하고 기술을 발전시킵니다.

도구에 대한 과도한 의존은 게으르다는 것을 의미합니까?

일반적으로 '아니오'; 그러나 한 가지 큰 경고가 있습니다.

uni에서 C ++로 프로그래밍을 시작하고 좋아했습니다. 다음 학기에는 VB6로 바뀌었고 싫어했습니다.

나는 무슨 일이 있었는지 말할 수 없었습니다. 버튼을 폼으로 드래그하면 ide가 코드를 작성합니다.

네 확실합니다. uni에서의 경험은 내가 언급 한 바로 그 경고에 대해 이야기합니다.

도구가 어떤 문제를 해결하는지 모르거나 도구 자체에 문제가있을 때 문제를 해결할 수없는 경우 큰 위험입니다. 이 상황이 반드시 게으름을 의미하지는 않지만 아마도 경험이 없음을 의미합니다.

프로그래머에게는 두 가지 맛이 있다고 생각합니다. 마감일 또는 생산성 향상으로 인해 작업을 수행하도록 프로그래밍하는 프로그래머가 있습니다. 나는 그들이 게으른 것이라고 말할 것입니다. 나는 단순히 그들이 컴퓨터가하는 일을 "어떻게"하는지 또는 프로그램이 어떻게 하는지를 "어떻게"하는지에 관심이 없다고 믿는다.

그리고 나 같은 열정적 인 프로그래머가 있습니다. 나와 같은 열정적 인 프로그래머는 CPU에서 무슨 일이 일어나고 있는지 정확히 알고 싶어합니다. 좋은 심리학자가 인간의 머리에서 무슨 일이 일어나고 있는지 알아 내려고했던 것처럼, progchologist도 나처럼 CPU 안에서 무슨 일이 일어나고 있는지 알고 싶어합니다. 그래서 우리는 프로그램을 배우고 분석하고 분석하고 Reflector 및 디스어셈블러와 같은 도구를 사용하여 프로그램 작동 방식을 알아냅니다.

상황이 바뀔 것이라는 침묵의 희망이 있습니다. CPU는 수직으로 확장되지 않고 수평으로 만 확장되며 ARM 등은 가까운 시일 내에 리소스가 제한됩니다.

드래그 앤 드롭이 아닌 프로그래밍에 대한 수요가 감소하고 더 ​​흥미로운 작업을 볼 수 있습니다.