As a co-designer of one of the world's most popular programming languages, one
of the more frustrating behaviours I regularly see (both in the Python community
and in others) is influential people trying to tap into fears of "losing" to
other open source communities as a motivating force for community contributions.
(I'm occasionally guilty of this misbehaviour myself, which makes it even
easier to spot when others are falling into the same trap).
세계에서 가장 유명한 프로그래밍언어의 co-designer로서, 주기적으로 (Python community나 다른 프로그래밍 관련된 곳에서) 볼 수 있는 힘빠지는 광경은, 다른 커뮤니티가 더 잘나갈 수 있수도 있다고 겁을 주어 커뮤니티 기여자가 커뮤니티에 기여할 수 있도록 만들려고 하는 것 이다.(때때로 나도 이런짓을 했습니다, 다른사람이 쉽게 기여하지 않을 때 쉽게 사용할 수 있기 때문입니다.)
While learning from the experiences of other programming language communities
is a good thing, fear based approaches to motivating action are seriously
problematic, as they encourage community members to see members of those
other communities as enemies in a competition for contributor attention, rather
than as potential allies in the larger challenge of advancing the state of the
art in software development. It also has the effect of telling folks that enjoy
those other languages that they're not welcome in a community that views them
and their peers as "hostile competitors".
다른 프로그래밍 언어의 커뮤니티에서의 경험으로 배우는 것은 좋은 것인데, 커뮤니티 멤버들로 하여금 다른 커뮤니티의 사람들을 소프트웨어 개발의 수준을 예술의 수준까지 끌어올리는 발전을 위한 잠재적인동맹의 관계로 생각하는 것이 아니라, 경쟁에서의 적으로 삼고 그 두려움을 기반으로 동기부여로 하는 것은 문제가 있어 보인다.
In truth, we want there to be a rich smorgasboard of cross platform open
source programming languages to choose from, as programming languages are first
and foremost tools for thinking - they make it possible for us to convey our
ideas in terms so explicit that even a computer can understand them. If someone
has found a language to use that fits their brain and solves their immediate
problems, that's great, regardless of the specific language (or languages)
they choose.
실제로, 우리는 선택이 풍부한 뷔페와 같이 서로다른 환경에서도 잘 돌아가는 여러가지 언어가 존재하기를 바란다. 프로그래밍 언어는 생각을 도와주는 도구이기 때문이다. - 프로그래밍 언어는 우리가 아이디어를 잘 표현할 수 있도록 하여 결국 컴퓨터 까지도 이해할 수 있도록 해준다. 만약 어떤 사람이 자신에게 주어진 문제를 잘 풀 수 있는, 자신에게 맞는 언어를 찾았다고 한다면 그 언어가 무엇이었든, 그건 엄청난 것이다..
So I have three specific requests for the Python community, and one broader
suggestion. First, the specific requests:
그래서 난 Pyhon 커뮤니티에 구체적인 3가지의 요청사항과 하나의 큰 제안이 있다.
3가지의 구체적인 요청사항은
1. If we find it necessary to appeal to tribal instincts to motivate action, we should avoid using tribal fear, and instead aim to use tribal pride. When we use fear as a motivator, as in phrasings like "If we don't do X, we're going to lose developer mindshare to language Y", we're deliberately creating negative emotions in folks freely contributing the results of their work to the world at large. Relying on tribal pride instead leads to phrasings like "It's currently really unclear how to solve problem X in Python. If we look to ecosystem Y, we can see they have a really nice approach to solving problem X that we can potentially adapt to provide a similarly nice user experience in Python". Actively emphasising taking pride in our own efforts, rather than denigrating the efforts of others, helps promote a culture of continuous learning within the Python community and also encourages the development of ever improving collaborative relationships with other communities.
1. 만약 커뮤니티에 동기부여가 필요하다고 생각되면, 커뮤니티에 대한 두려움을 사용하는 것은 피해야 한다. 대신에 커뮤니티의 자부심을 이용해야 한다. "만약에 우리가 뭘 하지 않는다면 다른 언어인 'y'에 개발자들의 마음을 빼앗기고 말 것이다." 와 같은 말을 통하여 두려움을 자극 한다면, 그것은 부정적인 감정을 유발하게 될 것이다. "지금은 X 라는 Python의 문제를 어떻게 풀 것인지를 모르지만 Y라는 환경을 보면 X 문제 해결을 위한 정말 훌륭한 방법을 발견할 수 있을 것이며 이것은 Python에 그와 비슷한 좋은 경험을 제공할 수 있을 것이다." 와 같이 다른 사람들의 노력을 폄하 하는 것이 아니라 능동적으로 우리의 노력에 자부심을 가지게 된다면, Python 커뮤니티 안에서는 지속적인 배움과 같은 문화를 퍼트리는데 도움이 되고 다른 커뮤니티와의 협업관계도 발전시킬 수 있을 것이다.
2. Refrain from adopting attitudes of contempt towards other open source
programming language communities, especially if those communities have
empowered people to solve their own problems rather than having to wait for
commercial software vendors to design to address them. Most of the important
problems in the world aren't profitable to solve (as the folks afflicted by
them aren't personally wealthy and don't control institutional funding
decisions), so we should be encouraging and applauding the folks stepping up
to try to solve them, regardless of what we may think of their technology
choices.
2. 다른 언어의 오픈소스 커뮤니티에서 배우는 것을 경멸하는 것을 삼가해 달라, 그리고 그 문제를 푸는것에 대해 상용 소프트웨어를 기다리게 하지 말고 자율권을 주어라. 많은 중요한 문제들은 해결한다고 해서 이익이 주어지는 것이 아니다(그 문제를 겪고 있는 사람들은 부자가 아니다.) 그래서 우리는 어떤 방법을 선택 하든지 간에 직접 해결하고 즐거워 하기를 바란다.
3. If someone we know is learning to program for the first time, and they
choose to learn a language we don't personally like, we should support them
in their choice anyway. They know what fits their brain better than we do,
so the right language for us may not be the right language for them. If
they start getting frustrated with their original choice, to the point where
it's demotivating them from learning to program at all, then it makes sense
to start recommending alternatives. This advice applies even for those of us
involved in improving the tragically bad state of network security: the way
we solve the problem with inherently insecure languages is by improving
operating system sandboxing capabilities, progressively knocking down
barriers to adoption for languages with better native security properties,
and improving the default behaviours of existing languages, not by confusing
beginners with arguments about why their chosen language is a poor choice
from an application security perspective. (If folks are deploying unaudited
software written by beginners to handle security sensitive tasks, it isn't
the folks writing the software that are the problem, it's the folks
deploying it without performing appropriate due diligence on the provenance
and security properties of that software)
3. 만약에 우리가 아는 누군가가 처음으로 프로그램을 배우려고 한다면, 그리고 그들이 우리가 좋아하지 않는 언어를 선택했다고 할 지라도, 우리는 그들의 선택을 있는 그대로 지지해 주어야 한다. 그들은 그들 자신에게 어떠한 언어가 더 적절한지 더 잘알고 있다. 그러므로 우리에게 적절한 언어는 그들에게는 적절하지 않을 수 있다. 만약 그들이 그들 자신의 선택에 좌절하게 되고 그로 인해 프로그래밍을 배우려는 의지가 꺽이게 된다면, 그 때 다른 적절한 것을 추천하는 것은 의미가 있다. 이런 조언은 네트워크 보안에 적절치 않다는 것을 발견하고 나서 바꾸는 것과 비슷하다. 본질적으로 안전하지 않은 언어를 OS를 가지고 감싼다던가, 안전한 다른 언어를 가지고 온다던가로 해결할 수 있다. (만약 초보자가 사용한 확인되지 않은 소프트웨어가 배포되었다고 하면 사용하는 사람이 문제가 아니라 제대로 확인하지 않고 배포한 사람이 문제이다.)
My broader suggestion is aimed at folks that are starting to encounter the
limits of the core procedural subset of Python and would hence like to start
exploring more of Python's own available "tools for thinking".
나는 사람들이 Python의 한계를 만나도록 하여 Python 을 더 발전시킬 가능성을 찾았으면 한다(?)
One of the things we do as part of the Python core development process is to
look at features we appreciate having available in other languages we have
experience with, and see whether or not there is a way to adapt them to be
useful in making Python code easier to both read and write. This means that
learning another programming language that focuses more specifically on a
given style of software development can help improve anyone's understanding
of that style of programming in the context of Python.
Python의 개발에 있어서 중요한 과정의 하나는, 다른 언어들을 배우고 그 특징을 Python 에 적용하여 사용하기 쉽게 만드는 것이다. 이것은 다른 언어를 배운다는 것은 Python 프로그래밍을 더욱 잘 이해하게 만드는 것이다.
To aid in such efforts, I've provided a list below of some possible areas for
exploration, and other languages which may provide additional insight into
those areas. Where possible, I've linked to Wikipedia pages rather than
directly to the relevant home pages, as Wikipedia often provides interesting
historical context that's worth exploring when picking up a new programming
language as an educational exercise rather than for immediate practical use.
그런 노력을 돕기 위하여, 탐험해볼 몇가지의 영역들을 리스트 해 보았다, 그리고 그것들은 추가적인 통찰을 제공해 줄 것이다. 가능하면 직접적인 해당 언어의 홈페이지가 아니라 위키피디아의 페이지들을 소개함으로서, 실질적인 프로그래밍에 바로 들어가는 것이 아니라 위키피디아가 제공하는 역사적인 것을 경험해 봄으로 인한 교육적인 효과를 줄 수 있도록 하였다.
While I do know many of these languages personally (and have used several of
them in developing production systems), the full list of recommendations
includes additional languages that I only know indirectly (usually by either
reading tutorials and design documentation, or by talking to folks that I trust
to provide good insight into a language's strengths and weaknesses).
이 언어들을 개인적으로 사용했지만(실제 생산에 참여해 보았다), 간접적으로만 체험해 본것들도 있다. (튜토리얼을 읽었거나 디자인 문서를 읽었거나 통찰을 가졌다고 하는 사람들과 얘기해서 들은것들)
There are a lot of other languages that could have gone on this list, so the
specific ones listed are a somewhat arbitrary subset based on my own interests
(for example, I'm mainly interested in the dominant Linux, Android and Windows
ecosystems, so I left out the niche-but-profitable Apple-centric Objective-C
and Swift programming languages, and I'm not familiar enough with art-focused
environments like Processing to even guess at what learning them might teach
a Python developer). For a more complete list that takes into account factors
beyond what a language might teach you as a developer, IEEE Spectrum's
annual ranking of programming language popularity and growth is well worth a
look.
여러 다른 언어들이 여기의 리스트에서 빠져 있다. 여기에 나열되어 있는 것은 내가 관심이 있었던 것들 위주이다.(나는 주로 Linux, Android, Windows 에 관심이 있다. 그래서 애플중심의 C나 Swift언어나 Processing과 같은 것은 잘 모른다.) 도움이 되는 더욱 완벽한 리스트를 찾는다면 IEEE의 연간 프로그래밍 언어 순위를 확인해 보는것도 좋을 것 같다.
* 이 글은 Python 언어의 공동 설계자인
* reference
http://www.curiousefficiency.org/posts/2015/10/languages-to-improve-your-python.html
댓글 없음:
댓글 쓰기