컴퓨터 프로그래머로서의 능력에 대한 자신감이 위기에 처해 있습니다.

어제 나는 그래프에 대한 가장 짧은 경로 알고리즘을 생각해 보았고 몇 시간 후에 나는 수건에 던져서 Dijkstra의 알고리즘을 배웠습니다.

이것은 좋은 프로그래머가 몇 시간 안에 "재발 명"할 수있는 것입니까, 아니면 비현실적입니까?

글쎄, 적어도 나는 거품 종류를 재발견 할 수 있었다 : D

좋은 프로그래머는 문제를 해결하기 위해 이미 훌륭한 알고리즘이 작성되었으며 바퀴를 재발 명하는 데 시간을 낭비하지 않는다는 것을 알아야합니다.

Dijkstra가 몇 시간 만에 최단 경로 알고리즘을 생각해 냈기 때문에 누군가가 '좋은 프로그래머'인지 판단하는 데 사용하는 표준이 될 것 같습니다.

이것은 좋은 프로그래머가 몇 시간 안에 "재발 명"할 수있는 것입니까, 아니면 비현실적입니까?

첫째, 당신은 아마도 이론적 인 컴퓨터 과학과 프로그래밍을 혼동하고있을 것입니다. 환상적인 프로그래머는 컴퓨터 과학에 좋은 기초가 필요하지만 환상적 일 필요는 없습니다. Dijkstra는 컴퓨터 과학에 환상적이었습니다.

두 번째로, 나는 그래프를 잘 이해 한 사람은 약간의 생각 후에 자신의 그래프 순회를 개발할 것으로 기대합니다. 그러나 최단 경로 알고리즘은 아닙니다 . Dijkstra의 알고리즘은 특히 매우 정교합니다. 일단 이해하면 맹목적으로 명백합니다. 그러나 대부분의 방법입니다.

당신은 아마 파생 수있는 어떤 종류의 물건을 시도하고 생각에게 시간을주고 나서 최단 경로 알고리즘을. 그러나 몇 시간 또는 며칠이 걸리더라도 실망하지 마십시오. 이것은 완전히 정상입니다.

(주의 : 글쎄, 몇 시간 만에 문제를 무력화 할 수 있어야하지만, 상당히 작은 그래프에서도 작동하는 알고리즘을 생성하지는 않습니다.)

이것은 좋은 프로그래머가 몇 시간 안에 "재발 명"할 수있는 것입니까, 아니면 비현실적입니까?

비현실적입니다. 사람들은 몇 시간 만에 알고리즘을 사용하지 않습니다. 많은 노력과 노력이 필요합니다. 이 블로그 를 인용하려면 :

도널드 크 누스 (Donald Knuth)의 말을 인용 한 벤틀리는 Programming Pearls에서 "1 진 바이너리 검색이 1946 년에 출판되었지만, n의 모든 값에 대해 올바르게 작동하는 최초의 바이너리 검색은 1962 년까지 나타나지 않았다"고 말했다.

Bentley의 버전도 큰 세트로 구현할 때 문제가있었습니다.

또한 훌륭한 프로그래머는 어떤 도구를 사용할 수 있는지, 언제 사용할 것인지 알고 있습니다. 독창성이나 다른 일을하는 데있어 추가 포인트를 얻지 못합니다. 제대로 작동하고 잘 작동하기를 원합니다.

선택할 수있는 것보다 더 나은 솔루션을 찾을 수 없을 것입니다.

"최고"(귀하의 경우 가장 짧은) 것으로 생각되는 것보다 더 나은 알고리즘으로 나오는 것은 모든 사람이 할 수있는 일이 아닙니다. 아마도 불가능할 수도 있습니다.

훌륭한 프로그래머는 알고리즘의 배후에있는 논리를 이해하고 동일한 문제를 해결하려고 시도하는 다른 알고리즘보다 왜 나쁘거나 나쁘거나 (특정 문제에 부적합한지) 이해해야합니다.

그는 또한 특정 문제를 해결하기위한 최선의 방법인지 알 수 있어야합니다.

어쨌든 연습하고 싶다면 여전히 알고리즘을 직접 구현하여 마음을 사용하여 문제를 해결하려고 시도 할 수 있습니다. 최선이 아닐 수도 있지만 문제를 해결하는 것이 좋습니다.

이것은 "소프트웨어 엔지니어링"(프로그래밍이라고 부르는 것)과 다른 엔지니어링 분야의 차이점에 대해 읽은 것을 상기시킵니다. 생각해 보면 원래 디자인 패턴 책인 것 같습니다. 나는 여기 누군가가 그의 머리 꼭대기에서 그것을 인용 할 수 있다고 확신합니다.

어쨌든 (알고리즘 디자인에 정확히 맞지는 않지만) 요점은 엔지니어링 분야가 체계화되어 있다는 점입니다. 토목 기술자는 I- 빔을 재발 명하는 데 시간을 소비하지는 않지만 프로그래머는 항상 그렇게합니다. 문제 (그리고 나는 단지 많은 사람들의 감정을 반향하고 있다는 것을 알고 있습니다)는이 행동이 낭비적이고 오류가 발생하기 쉽고 해결책보다 자아를 제공한다는 것입니다.

컴퓨터 과학으로 인해 프로그래밍이 가능해졌으며 두 가지 모두를 좋아합니다. 그러나 저는 컴퓨터 과학자보다 훨씬 나은 프로그래머입니다. 오후에 Dijkstra의 알고리즘을 다시 만들 수 없기 때문에 무능하다고 비난하지 않습니다. 최단 경로 그래프 알고리즘을 통해 해결할 수있는 문제를 인식하지 못하면 프로그래머로서의 역량에 의문을 제기 할 것 입니다.

즉, 알고리즘에 대해 생각하고 새로운 알고리즘을 디자인하고 구현하려는 것은 (잠재적으로) 재미 있고 (거의) 항상 유익한 것이라고 생각합니다. CS 시간과 프로그래밍 시간을 명확하게 분리하려고합니다. 프로그래머의 경우, 특히 (유급) 시간이 실제 문제를 해결하는 데 더 많은 시간을 소비하는 것이 좋습니다. 게다가 CS 시간은 거의 항상 자신감을 떨어 뜨립니다.

다른 사람들이하는 것과 똑같은 것을 눈치 채지 못할 것입니다. 나는 그것이 우리가 살아야 할 삶의 사실 일 뿐이라고 생각합니다. 많은 부분이 수동 학습과 그 결과로 개발 한 정신 모델에 달려 있습니다.

나는 학교에서 DeMorgan의 법을 가르쳐야 일관되게 수행 할 수있는 매우 지능적이고 유능한 프로그래머를 알고 있습니다. 나는 Dijkstra의 알고리즘을 스스로 알아 냈습니다. (그리고 나는 그것을 자랑스럽게 생각합니다) 거품 정렬을 이해할 수있을 때까지 정말 오랜 시간이 걸렸습니다.

더 유명하게도, 매듭 이론의 전문가가 될 것이라고 생각하는 아인슈타인은 열 살쯤 될 때까지 자신의 신발 끈을 묶을 수 없었습니다.

자신 이 명시 적으로 가르치지 않았다면 다른 사람들이 결코 알지 못했을 많은 것들을 자신도 모르게 재창조했을 가능성이 높습니다 .

나는 대부분의 답변이 말하는 것에 대해달라고 간청합니다. Dijkstra의 알고리즘에서 어떤 수준의 프로그래머도 스스로 올 수 있다고는 생각하지 않지만 문제를 해결하기 위해 어떤 방법 (효율적이든 아니든)을 생각해 낼 것입니다.

예를 들어, 당신은 당신이 스스로 거품 정렬을 만들 수 있다고 사이드 코멘트로 말했다. 나는 정렬 알고리즘 중 가장 악의적 인 것을 알고 있지만 문제를 해결할 수있는 방법을 찾았습니다. 그래서 프로그래머가 할 수있는 것으로 기대합니다. 문제를 해결할 방법을 찾으십시오.

물론 다른 사람들이 수행 한 솔루션을 조사하고 찾는 것도 효과가 있지만 그 시점의 극단은 자신을 생각하지 않는 프로그램이며 Google 검색의 개요 인 프로그램입니다.

나는 실제로 원하는 것보다 더 거칠게 들린다 고 생각하지만 내 요점은 : 솔루션이 버그가 있거나 지저분한 경우에도 프로그래머가 문제에 대한 해결책을 제시 할만 큼 창의적이어야한다고 생각합니다.

따라서 귀하의 사례로 돌아와서 Dijkstra의 알고리즘을 생각해 내야한다고 생각하지는 않지만 무한 루프로 끝나지 않고 여러 가능성을 시도하고 최단 경로를 찾는 알고리즘을 작성할 수 있다면, 그럼 당신은 내 승인을 얻었습니다.

(BTW 승인은 무료 세차 쿠폰과 동일한 순서로 계산됩니다.)

그렇습니다.

그것은 버블 정렬과 같은 도덕적 인 것일 수도 있지만, 훌륭한 프로그래머는 적어도 작동하는 무언가를 생각 해낼 수는 있지만 비효율적이라고 생각합니다.

말할 필요도없이, 특정 문제가 발생할 경우, 좋은 프로그래머는 먼저 라이브러리를 만들거나 게시 된 알고리즘을 사용하여 구현하기 쉬운 지 먼저 살펴볼 것입니다.

물론 많은 프로그래밍 작업이 훨씬 덜 어려워서 모든 사람이 그러한 어려운 문제를 해결할 수있는 것은 아닙니다. 그러나 이전의 과학적 연구에 의존 할 수없는 복잡한 프로젝트 관련 문제가있을 수 있기 때문에 팀에 그런 마음을 가진 사람이 필요합니다.

걱정 하지마

Perl Programmer로서 나는 결코 바퀴를 재발 명 하지 않는다 . 이것이 CPAN의 일입니다. 간단하고 잘 지원되는 알고리즘 또는 모듈이있는 경우이를 사용합니다. 좋은 모듈이 없다면 우리 는 바퀴를 발명 합니다. 이것이 Perl의 가장 큰 것 중 하나입니다.

그래서 내가 말하는 것은 이것입니다.

1. 나는 바퀴를 재발 명하지 않지만 당신이 할 때 ...
2. 완전히 재발 명하지 말고 ...
3. 할 수 없어도 걱정하지 마십시오. 이것이 우리에게 프로그래밍 커뮤니티가있는 이유입니다 :-).

그래프 이론과 그에 적용되는 알고리즘은 표면에서 단순 해 보이지만 일반적으로 그리 멀지 않습니다. 비교 차 (평면) 그래프의 형성은 예를 들어 언뜻보기에는 간단하다고 생각할 것입니다. 작년에 나는이 문제 (Kuratowski 하위 그래프 제거를 통한 평면성)를 광범위하게 조사했다. 이 경험을 통해 이러한 알고리즘을 작성하는 사람들은 일반적으로 박사 학위 조사 기간을 보내고 때로는 연구가 팀에서 이루어 졌다는 것을 알 수 있습니다. 그리고 연구원 으로서 , 그것은 그 기간 동안 그들의 유일한 작업 초점입니다. 우리의 지상 엔지니어가 동일한 것을 기대할 수 있다고 생각하는 것은 합리적이지 않습니다. 다른 누군가가 옳게 말했듯이, 일단 해결책이 당신 앞에 있으면 맹목적으로 분명합니다. 항상 그런 것 같습니다!

이것은 좋은 프로그래머가 몇 시간 안에 "재발 명"할 수있는 것입니까, 아니면 비현실적입니까?

최단 경로와 같은 잘 알려진 문제에 대한 알고리즘을 독자적으로 발명 할 수 있다면 나쁜 프로그래머 가 될 것 입니다.

그것은 당신이 무시하고 의미 것 최단 경로 문제에 꽤 역사를 (| V가 | ^ 4) 다 익스트라의이다 (1984 년에 발표 된 O (E + V 로그 V) 알고리즘으로 1955 년에 출판 알고리즘으로하는 O에서 진행 피보나치 나무와 알고리즘). 이미 고안된 알고리즘보다 더 나쁘게 수행된다는 보장이 거의 있습니다. 더 나쁜 것은 알고리즘에 차이가 있거나 잘못되어 알고리즘을 잘못 만들 가능성이 있다는 것입니다. 또한 알고리즘을 생각하고 구현하고 기존 알고리즘을 재사용하는 데 걸리는 시간보다 테스트하는 데 훨씬 더 많은 시간이 소요됩니다.

알고리즘 설계는 알고리즘 설계자에게 맡기십시오. 프로그래머는 결과의 소비자입니다. 프로그래머는 알고리즘을 결합하여 실제 작업을 수행하도록합니다. 경찰관은 일을하거나 법을 잘 지키기 위해 법을 재발 명 할 필요가 없습니다.

또한 약간 복잡한 알고리즘에 대해 알고리즘을 직접 구현하는 대신 전문가가 만든 구현을 사용하는 것이 좋습니다. 그것은 정확할 가능성이 더 높으며, 그들이 당신보다 더 빠르게 만들 가능성이 높으며 많은 시간을 절약 할 수 있습니다. 이는 일반적으로 전문가 만 제공 할 수있는 추가 보안 요구가 있으므로 암호화 알고리즘의 경우 특히 그렇습니다.