출처: http://thread.gmane.org/gmane.comp.version-control.git/57918
From: Linus Torvalds <[email protected]>
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-06 17:50:28 GMT (2 years, 14 weeks, 16 hours and 36 minutes ago)
On Wed, 5 Sep 2007, Dmitry Kakurin wrote:
When I first looked at Git source code two things struck me as odd
1. Pure C as opposed to C++. No idea why. Please don’t talk about portability, it’s BS.제가 Git 소스 코드를 처음 봤을때 이상하다고 느낀 점이 두 가지 있었습니다.
1. C++가 아닌 순수 C인 점. 왜인지 모르겠네요. 이식성같은 개소리는 하지 말아주세요.
YOU are full of bullshit.
개소리는 네가 하고 있다.
C++ is a horrible language.
It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it.
Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.
C++는 끔찍한 언어다.
더욱 끔찍한 것은, 표준을 따르지 않는 많은 프로그래머들이 C++를 사용하면서 쓰레기를 더 쉽게 만들어내고 있다는 것이다.
솔직히 말해서, C++ 프로그래머들을 접근하지 못하게 할 수 있다는 것만으로도 C를 선택할 이유가 충분하다.
In other words: the choice of C is the only sane choice.
I know Miles Bader jokingly said “to piss you off”, but it’s actually true.
I’ve come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really would prefer to piss off, so that he doesn’t come and screw up any project I’m involved with.
다시 말하지만, C만이 유일한 정상적인 선택이다.
Miles Bader가 농담처럼 “너 열받으라고” 라고 했었지. 하지만 그게 사실이다.
난 누구든 프로젝트가 C 대신 C++로 진행되기를 원하는 프로그래머를 열받게 해서 내가 관련된 프로젝트를 그가 망치는것을 막고 싶다는 결론에 도달했다.
C++ leads to really really bad design choices.
You invariably start using the “nice” library features of the language like STL and Boost and other total and utter crap, that may “help” you program, but causes:
C++는 설계적으로 매우 나쁜 선택을 하도록 만든다.
넌 언제나 STL, Boost나 기타 쓰레기같은 “대단한” 라이브러리 기능들을 사용하는것으로 시작할 것이다.
그것은 아마 네가 프로그래밍 하는 것을 “도울” 수도 있겠지만 다음 문제들을 야기할 것이다:
- infinite amounts of pain when they don’t work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it’s not even funny)
- inefficient abstracted programming models where two years down the road you notice that some abstraction wasn’t very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.
- 그것들이 동작하지 않을 때의 무한한 고통 (STL 그리고 특히 Boost가 안정적이고 이식성이 좋다고 하는 사람은 웃기지도 않는 병신이다.)
- 비효율적이고 추상적인 프로그래밍 모델: 2년쯤 뒤에 몇몇 추상화가 그다지 효과적이지 않지만 모든 코드가 그와 관련된 멋진 객체 모델들에 완전히 종속되어 있고, 처음부터 다시 짜지 않는 이상 절대로 고칠수 없다는 것을 깨달았을 때 같은 경우.
In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C.
다시말해서 좋고, 효과적이고, 시스템 수준이며 이식성 높으신 C++는 C에서 가능한 모든 것들로부터 널 방해할 뿐이다.
And limiting your project to C means that people don’t screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don’t screw things up with any idiotic “object model” crap.
그리고 네 프로젝트에서 C만 사용할 수 있도록 하는 것은 사람들이 그렇게 망치지 못하게 할 뿐만 아니라, 바보같은 “객체 모델” 헛짓거리로 모든걸 망쳐버리지 않는데다가 저수준 문제들을 실제로 이해하는 많은 프로그래머들을 얻을수 있게 된다는 뜻이다.
So I’m sorry, but for something like git, where efficiency was a primary objective, the “advantages” of C++ is just a huge mistake. The fact that we also piss off people who cannot see that is just a big additional advantage.
애석하게도 Git같은, 효율이 주된 목표인 프로젝트에는 C++의 “장점” 들은 그저 큰 실수일 뿐이다.
그것을 알지 못하는 사람들을 열받게 하는것이 큰 추가적인 장점이란것 또한 사실이다.
If you want a VCS that is written in C++, go play with Monotone. Really.
They use a “real database”. They use “nice object-oriented libraries”. They use “nice C++ abstractions”.
And quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess.
C++로 짜인 버전 관리 시스템을 원한다면 Monotone이나 가지고 놀아라.
걔네는 “진짜 데이터베이스”, “멋진 객체지향 라이브러리”, “대단한 C++ 추상화"를 쓴댄다.
솔직히, 그런 몇몇 컴퓨터과학 애호가들이나 멋지다고 생각할 설계적 결정은 끔찍하고 유지보수 불가능한 쓰레기를 내놓게 될 것이다.
But I’m sure you’d like it more than git.
넌 Git보다는 Monotone을 좋아할 것 같네.
- linus
From: Linus Torvalds
Subject: Re: Compiling C++ kernel module + Makefile
Date: Mon, 19 Jan 2004 22:46:23 -0800 (PST)
On Tue, 20 Jan 2004, Robin Rosenberg wrote:
This is the “We’ve always used COBOL^H^H^H^H” argument.
이게 “이때까지 항상 COBOL를 써왔잖아” 라는 거구만.
In fact, in Linux we did try C++ once already, back in 1992.
사실 1992년에 이미 리눅스에 C++를 시도해보았다.
It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
구리더라. 커널을 C++로 짜는 것은 정말 개 멍청한 생각이다.
The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven’t changed:
사실 C++ 컴파일러는 신뢰할 만한 것이 못 된다. 1992년에는 더 심각했지만 몇몇 핵심적인 사실은 변하지 않았다:
the whole C++ exception handling thing is fundamentally broken. It’s especially broken for kernels.
C++ 예외 처리는 그냥 처음부터 글러먹었다. 특히 커널을 위해서는 더 그렇다.
any compiler or language that likes to hide things like memory allocations behind your back just isn’t a good choice for a kernel.
메모리 할당같은 것들을 네가 모르게 숨기려 드는 컴파일러나 언어는 커널을 위해선 좋은 선택은 아니다.
you can write object-oriented code (useful for filesystems etc) in C, without the crap that is C++.
C++같은 쓰레기 없이도 C에서 (파일 시스템이나 기타 등등에 유용한) 객체지향적인 코드를 짤 수 있다.
In general, I’d say that anybody who designs his kernel modules for C++ is either
난 자기 커널 모듈을 C++로 만드는 사람은 보통
(a) looking for problems
(b) a C++ bigot that can’t see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.
(a) 문제 일으키기를 좋아함
(b) 자신이 사실 C를 사용하고 있다는 것도 모르고 C++만 고집함
(c) 컴퓨터과학 수업에서 C++로 커널 모듈 만드는 과제를 시켰음
Feel free to make up (d).
(d)는 네 얘기로 채우세요.
- linus