C를 아는 것이 실제로 당신이 더 높은 수준의 언어로 쓰는 코드를 해칠 수 있습니까?

C를 아는 것이 실제로 당신이 더 높은 수준의 언어로 쓰는 코드를 해칠 수 있습니까?

그 문제는 이미 해결된 것 같고, 두들겨 맞아 죽을 지경입니다.똑똑한 사람들은 그 주제에 대해 똑똑한 말을 했습니다.정말 좋은 프로그래머가 되기 위해서는 C를 알아야 합니다.

아니면 당신은?

저는 이번 주에 두 번 깨달음을 얻었습니다.첫 번째 사례는 제 가정이 제가 알고 있는 것 이상으로 나아가지 않는다는 것을 깨닫게 해주었습니다. 그리고 제 기계에서 실행되는 소프트웨어의 복잡성을 고려할 때, 그것은 거의 존재하지 않는 것입니다.하지만 실제로 이를 현실로 이끈 것은 이 Slashdot의 코멘트입니다.

결국 기존의 C "베어 메탈" 프로그래머들이 더 높은 수준의 언어를 구현한다고 가정하는 많은 순진한 방법들을 알게 되었습니다.컴파일러가 어떻게 작동하는지 또는 좋은 런타임 시스템이 자신이 이해하는 순진한 매크로 어셈블러 모델과 얼마나 다를지 모르기 때문에 자신이 영향을 미치는 프로젝트에서 잘못된 "최적화" 결정을 내립니다.

그때 생각이 났습니다. C는 다른 모든 것들처럼 그저 하나의 추상화일 뿐입니다.CPU 자체도 추상일 뿐!저는 그것이 부서지는 것을 본 적이 없습니다. 왜냐하면 그것을 측정할 도구가 없기 때문입니다.

저는 혼란스러워요.베이직에 대한 Dijkstra의 말처럼 나의 마음은 회복할 수 없을 정도로 훼손된 것일까요?저는 지속적으로 조기 최적화 상태에 살고 있습니까?내가 아무것도 모른다는 것을 깨달았으니, 나에게 희망이 있습니까?알만한 게 있나요?그리고 지난 5년간 제가 쓴 모든 것이 근본적으로 틀렸을지도 모른다는 것이 왜 그렇게 매력적일까요?

요약하자면 API 문서가 알려주는 것 이상으로 아는 것이 가치가 있습니까?

편집: 메이드 CW.물론 이것은 이제 통역사/런타임 최적화 예제를 우리보다 더 잘 게시해야 한다는 것을 의미합니다. :)

C를 알지도 못하고, 구현의 낮은 수준의 세부사항을 알지도 못하는 것 자체가 당신에게 상처가 됩니다.부적절한 경우에도 낮은 수준의 세부적인 측면에서 일관되게 생각하고 노력한다면 여러분에게 상처를 줄 수 있고 또 줄 것입니다.

오래된 속담은 "진짜 프로그래머는 어떤 언어로도 포트란을 쓸 수 있다"는 것이었습니다.C를 사용해서 똑같이 하면 개선이 되지 않습니다.Lisp를 쓰는 사람은 Lisp를 씁니다.Python을 쓰고 있다면 Python을 쓰시오.C에 적절하고 합리적인 것은 이들(또는 다른 많은 것들) 중 어느 것에도 적합하지 않습니다.

훌륭한 프로그래머는 다양한 추상화 수준에서 생각할 수 있어야 하며, 당면한 작업에 적절한 추상화 수준을 인식하고 적용할 수 있어야 합니다.

C의 추상화 수준에 대한 지식은 나쁘지 않습니다.대안에 대한 무지는 (그리고) 할 수 있습니다.

지식은 해가 되지 않습니다.지금까지. 상위 언어로 나쁜 코드를 쓴 사람들은 상위 언어, 나쁜 개발자들을 제대로 마스터하지 못했기 때문입니다.

나쁜 개발자에게는 어떤 종류의 지식이든 위험할 수 있습니다.

훌륭한 개발자에게는 어떤 유형의 지식이든 자산입니다.

언어를 사용하는 것은 - 자연적인 (구어) 또는 인공적인 (프로그래밍) - 특정한 방식으로 적응하는 마음을 요구합니다.각 언어에는 고유한 문법, 고유한 어휘(API) 등이 있습니다.대부분 자바 프로그래머이고 루비로 바꾼다면 기본적으로 자바 코드를 루비로 쓰지 않는다면 적어도 자바 프로그래머의 사고 패턴을 따를 것입니다.새로운 환경(Ruby grammar, Ruby APIs)에서 편안함을 느끼고 Ruby 코드 작성을 시작할 때까지 약간의 노력과 연습이 필요합니다.

따라서 공정은 완벽하게 정상적이며 이전 패턴의 부작용은 수명이 매우 짧습니다.더 중요한 것은, 여러분이 배우는 모든 언어는 여러분의 시야를 넓히고 다음 언어를 더 쉽게 배울 수 있게 한다는 것입니다.즐거운 여행 되시기 바랍니다. :]

프로그래밍은 언어를 프로그래밍하는 것이 아닙니다.그것은 문제를 해결하는 것입니다.문제를 해결하는 데 사용되는 도구는 프로그래밍 언어입니다.코드를 쓰기 위해 코드를 쓰는 것이 아니라 코드를 쓰고 실행해서 문제를 해결하는 것입니다.

도구에 대해 더 잘 알수록 문제를 더 잘 해결하고 빠르게 해결할 수 있습니다.그러나 망치를 사용하여 나무에 나사를 박으려고 하면 심각한 문제가 발생하지만 소프트웨어는 좋은 특성을 가지고 있습니다.주어진 문제에 대해서는 터무니없이 많은 다른 해결책이 있습니다.

따라서 나사를 맞추는 망치를 쓰는 것은 완벽하게 가능합니다. 나무에 나사가 들어가도록 구멍을 내라고 나사가 지시하는 각도로 말이죠.그러면 버튼 뒤에 숨길 수 있습니다. 사용자는 실제로 망치가 무엇인지 알 필요도 없습니다.

가장 효율적인 솔루션은 아니지만 여전히 유효하고 효과적인 솔루션입니다.사용한 툴이 좋아지면 API에서 드라이버를 제공하지 않을 때 어떻게 드라이버를 작성할 수 있는지 알게 됩니다.

도구를 더 많이 알고 문제를 해결하는 방법을 더 많이 알고 있을수록 선택의 폭이 넓어지며 어떤 솔루션을 사용할지에 대한 결정이 더 좋아집니다.작업에 적합한 도구를 선택했습니다.하지만 툴과 가능한 해결책을 모르는데 어떻게 할 수 있겠습니까?

다른 사용자의 의견을 확대하려면...http://en.wikipedia.org/wiki/Whorfian_hypothesis 을 믿을 수는 없지만 말입니다.">자연어에 관한 한, 프로그래밍에 관한 한 꽤 확실한 사실입니다.당신이 아는 언어는 당신이 문제를 해결하는 방법에 영향을 미칩니다.두 가지 예:

1) 오래전에 제가 가졌던 교수님으로부터:그는 자신의 줄에 중복되는 것이 있는지 알아보려고 했습니다.이것은 70년대에 FORTRAN에서 작성한 것입니다. 그의 무력 n^2 구현은 너무 오래 걸렸습니다.그래서 그는 친구에게 말을 걸었습니다.그의 친구는 분류 연산자가 있는 PL1을 알고 있었습니다.그래서, 그 언어로, 여러분은 물건들을 분류하는 것을 배웁니다. 그리고 그것이 얼마나 유용할 수 있는지는 간단하기 때문입니다.친구가 먼저 명백한 정렬을 생각해 낸 다음 인접 요소 알고리즘을 살펴봅니다.훨씬 더 빨랐고, FORTRAN에서 완벽하게 구현이 가능했더라도 FORTRAN 글쓰기 교수님에게는 발생하지 않았을 것입니다.

2) 제가 대학원에 다닐 때 룸메이트로 물리학과 대학원생이 있었습니다.그는 MIT에 다녔고, 프로그래밍 수업을 한 번만 들었는데, 당연히 Scheme에 속해 있었습니다.어느 날, 제가 그의 사무실에 들렀는데, 그가 말하길, "이봐, 브라이언, 이 코드를 보고 작동해야 하는지 말해줄래요?"그것은 분류 작업이었습니다.나는 그것을 힐끗 보았는데, 그것은 분명히 버블 정렬이었기 때문에, 그것은 작동할 수 없다고 말했지만, 그것은 단지 하나의 루프만을 가지고 있었습니다(아니요, 그것은 여러분이 아프고 뒤틀릴 때 버블 정렬을 쓸 수 있는 유일한 펑키 루프가 아니었습니다).그래서 제가.그는 "아, 하지만 그것은 아래에 재귀적인 부름이 있습니다!"라고 대답했습니다.나는 재귀적인 거품 정렬을 쓸 생각을 하지 못했을 것입니다.하지만 더 중요한 것은, 그가 비재귀적 함수를 쓴다는 것은 결코 생각하지 못했을 것이라는 것입니다!

중요한 것은 당신이 알고 있는 언어들이 당신이 작성할 코드의 종류를 크게 결정한다는 것입니다.언어를 더 많이 알면 알수록 더 많은 도구를 갖게 되고, 각각의 도구를 언제 사용해야 하는지만 알면 더 많은 도구는 결코 나쁘지 않습니다.

정말 좋은 프로그래머가 되기 위해서는 C를 알아야 합니다.

저는 이에 동의합니다.

하지만 정말 훌륭한 프로그래머가 되려면 다른 언어로 코드를 작성하는 방법(다른 언어로 C 코드를 작성하는 방법이 아니라)을 정말로 알아야 한다는 것에도 동의합니다.

C를 아는 것은 코드의 품질을 해치지는 않지만, "유일한 C"를 아는 것은 확실히 당신의 코드의 품질을 해칠 것입니다.

아니요.

자신이 피해를 입었음에도 불구하고 알고자 하는 욕구와 향상을 잃는다면.

소프트웨어 엔지니어링은 추상화를 이해하고 추상화를 사용하여 문제를 효율적으로 해결하는 방법을 이해하는 것입니다(효율적으로 비용이 절감되거나 성능이 향상되거나 기능을 제공하는 데 걸리는 일정이 단축되는지 여부).C를 이해하는 것은 우리가 매일 사용하는 추상화 계층에 대한 또 다른 통찰력일 뿐이며, 필요할 때 '줌아웃'하는 기술을 개발하는 한, 이 수준의 세부 사항으로 '줌인'하는 데 필요한 기술은 가치가 있습니다.이 스킬 세트는 객체 모델을 설계하거나, 깨끗한 기능 구성을 설정하거나, 심지어 명확성과 유지보수성을 위해 개별적인 방법을 구성하는 등 학문의 모든 측면에서 유용하게 사용할 수 있습니다.

서로 다른 언어를 아는 것은 자산입니다.컴파일러와 인터프리터가 어떻게 구축되는지를 아는 것도 하나의 자산입니다.마지막으로, 모든 프로그래머는 상위 언어를 감상하기 위해 어셈블리 언어로 시간을 보내야 합니다. :-)

저희 대학에서는 '프로그래밍 랭귀지'라는 수업을 들었는데, 거기서 LISP, SNOBOL, ADA를 배웠습니다.이 언어들은 프로그래밍 문제를 해결하는데 있어서 여러분의 마음을 다른 개념적 사고에 열어줍니다.요약은 문제에 가장 적합한 언어를 선택하는 것이었습니다.

프로그래밍 언어를 아는 것은 기초일 뿐입니다.제가 데이터 구조, 알고리즘, 선형 대수, 부울 대수, 마이크로프로세서 설계 및 커뮤니케이션(사람들 간의 통신)과 같은 다른 관련 주제를 몰랐다면 제 직업에서 그리 멀지 않았을 것입니다.누구나 책을 집어 들고, 언어를 배우고, 스스로 프로그래머라고 부를 수 있습니다.이것은 숙련된 개발자와 길거리에서 일하는 개발자를 구별해주는 다른 기술입니다.

프로그래밍 언어를 배웁니다.그것을 잘 배우세요, 그러면 여러분이 당면한 다른 일들에 더 많은 두뇌 파워를 집중할 수 있습니다.프로그래밍 매뉴얼을 자주 참조하면 안 됩니다.대부분의 집중은 최소 시간 내에 정확하게 구현하기 위한 작업 요구사항과 알고리즘 및 데이터 구조에 있습니다.

짧고 달콤함:

훌륭한 프로그래머가 되기 위해서는 체계적인 사고를 할 수 있어야 합니다.코나 LUA든 자바든 뭐든.

그런 지식을 필요 없는 고급 언어에 적용할 경우에만 마음이 아플 뿐입니다.물론이죠, 저만의 컬렉션 클래스를 작성한 C 레벨이 낮은 경험이 있기 때문에 자바에서도 그렇게 할 수 있습니다.그러나 기존의 컬렉션 라이브러리(Commons Collections extrus로 Java API 둘 다 있음)를 대체하는 것이 더 나을까요?아마도요.

실제로는 투자한 시간이 가치가 있는지 계산해야 합니다.

사실, 당신은 당신의 코드를 해킹하기 전에 단순히 조사를 해야 합니다.기본 제공 툴이나 타사 툴을 사용하여 원하는 작업을 수행할 수 있는지 확인합니다.가능하다면 내장형 또는 타사 툴이 원하는 대로 작동하는지, 성능이 양호한지 확인해 보십시오.만약 그렇지 않다면, 왜 안 되는지 알아보세요.만약 그들이 정말/그렇지 않다면 다시 적으세요.

다른 사람들이 말했듯이, 모든 지식은 가치가 있습니다.여기서 의미하는 것은 /all/ - 둘 다 낮은 레벨의 최적화된 C 코드로서, 잘 개발된 라이브러리에 대한 높은 레벨의 호출입니다.두 가지를 모두 알고 있다면, 어떤 것을 언제, 왜 사용해야 하는지 알 수 있을 것입니다.

아니요, 프로그래밍 언어의 여러 구현을 알면 추상화를 더 잘 이해하는 데 도움이 될 뿐입니다.

문제는 하나를 자신이 덜하다고 생각하는 다른 것들을 사용하여 성공하지 못하게 하는 최고의 추상화로 받아들인다는 것입니다.

각각의 추상화는 특정한 다른 목표를 가지고 설계되므로, 필요에 가장 적합한 추상화를 선택합니다.Linux를 알면 Windows나 Mac OS를 알기가 더 어려워집니까?그것은 그들이 다르다는 것을 받아들이는 것입니다.

여기서 진짜 문제는 가정입니다.다른 개발자들은 그들이 그것이 어떻게 작동하는지 알고 있다고 가정합니다.자신이 모든 것을 파악했다고 생각하는 경험 많은 개발자의 가정이든, 자신이 모든 것을 파악했다고 생각하는 초보자의 가정이든 간에 가정은 악마입니다.

적어도 내가 가정하는 건 그게 다야

C를 배우는 것은 좋은 일입니다.C 코드를 더 높은 수준의 언어로 쓰려고 하는 것은 나쁜 일입니다.

프로그래머에서 C를 배우는 것(또는 그 문제에 대해서는 어떤 언어라도)이 당신을 다치게 할 수 있다는 것은 당신이 C를 배운 후에 아무것도 배울 수 없다는 것에 달려있는 것 같습니다.여기서 교훈은 배움을 멈추지 말라는 것입니다.또한 다른 언어나 기술이 반드시 C(또는 좋아하는 C 컴파일러)처럼 작동한다고 가정하지 마십시오.

그렇기는 하지만, C를 배우는 것은 하드웨어가 어떻게 작동하고 실제로 기계에서 어떤 일이 일어나고 있는지를 배울 수 있는 좋은 방법이 될 수 있다고 생각합니다.어떻게 이런 일이 당신에게 상처가 될 수 있는지 알 수가 없습니다.저는 무지한 것이 (우발적인 것이 아니라면) 어떤 이점도 없다고 생각합니다.저는 C를 배우는 것이 기계에 대해 배우는 유일한 방법이 아니라, 단지 그렇게 하는 하나의 방법이라는 것을 인정합니다.

여러 언어/프레임워크 및 프로그래밍 패러다임을 이해하는 것은 결코 해가 되지 않습니다. 그것은 유익할 것입니다.

중요한 부분은 현재 작업 중인 언어/프레임워크/환경을 파악하여 구현 선택 시의 의미를 파악하는 것입니다.여기서, 다른 언어를 사용하면서 얻은 지식은 더 넓은 범위의 가능성에 눈을 뜨게 할 수 있지만, 현재 환경의 측면에서 그 가능성을 평가해야 합니다.

자신을 진짜 곤경에 빠뜨리는 사람들은 어떤 언어, 예를 들어 C를 배운 사람들이고, 그 언어의 장점, 장점, 단점을 위해 그것을 배우는 것이 아니라 C라는 측면에서 다른 언어를 배운 사람들입니다. (망치를 유일한 도구로 사용하는 핸디맨처럼 - 모든 문제가 그에게는 못처럼 보입니다.)

예를 들어, C를 알고 나서 내가 가장 좋아하는 고급 언어(Python)로 작업하는 것은 왜 C를 아는 것이 도움이 된다고 생각하는지에 대한 예입니다.

C를 알면 파이썬을 사용할 때 여러 가지 면에서 도움이 됩니다.

(a) Python의 목록, 사전 및 내장된 유형에 감사드립니다. 반복적으로 한 줄의 코드에서 어떤 작업을 쉽게 수행할 수 있기 때문에 코드 라이브러리(해시 테이블, 데이터 구조 등)를 선택하고, 이를 통해 링크하고, 자신의 발에 총을 쏘는 것을 피할 수 있기 때문입니다.

(b) 파이썬은 C로 씁니다.C 프로그래머가 된다는 것은 Python이 99%의 경로를 제공하지만 Python에서 추가적인 추상화를 사용하면 Python에서 그 추상화를 작성할 수 있다는 것을 의미합니다.나는 CPython 인터프리터의 소스코드를 알아보고 내부적으로 무슨 일이 일어나고 있는지 이해할 수 있습니다.저는 사실상 파이썬 프로그래머로서 여전히 C 언어 위에 구축된 무언가를 사용하고 있습니다.따라서 언어를 아는 것은 여전히 가치가 있습니다.

위에서 말한 모든 것은 Perl, Ruby, PHP를 사용하는 사람들에게도 해당됩니다.

언급URL : https://stackoverflow.com/questions/2882551/can-knowing-c-actually-hurt-the-code-you-write-in-higher-level-languages