E D R , A S I H C RSS

Not Tools But Concepts

임��� 위키 항해를 하�중 xper seminar wiki�서 다�과 같� 글� 보았다.
{{|
최근 파�� 뉴스그룹� "파��� 배우는 것� 가치가 있나"하는 질문� 올렸다. 다�� 거기� 올�온 답변 중 하나.

Raphael Ribeiro wrote:
I wanna start learning some real programming language (I know now only
Visual Basic , but i don't find it interesting, sorry for the vb
programmers, but this is my opinion).

Understandable :-)

And I was reading some docs, which were talking about lots of programming
languages, I saw there Python, and took a look at some python sites. I
saw some snippets and read some docs and liked the language a lot. But I
don't know if this language is well-accepted in the market and if having
a good python knowledge would give me a good job.

As for the job market, Python isn't among the buzzwords that you'll find in
job descriptions most of the time. But software development isn't that much
about particular technologies, the important part is learning concepts. If
you learn Python, you won't be able to avoid learning (at least):

- Object Oriented Programming (OOP)
- Procedural Programming

There's a lot more concepts that you can learn while using Python, as you
advance a little more:

- Functional Programming
- Test Driven Development
- Dividing software into components

I am only 17 and I'm only making plans, so if you have any suggestions
tell me.

Ok, I'll try :-)

Learn concepts, not tools. At least in the long run, this will make you
more attractive to employers who have a clue about what's important in the
software industry.

There are some more skills that are especially important:

- Team work: dividing up tasks. Defining the interfaces up front to avoid
blocking other team members who wait for you. Using a source code control
system 1

- Communication/efficient problem solving: not trying yourself for days to
solve a problem that could be solved a lot more efficiently by calling
the client or writing an email - I've had problems with this myself in
the past, I guess that's not an uncommon problem for developers.

- Software reliability: that's a difficult one. IMO experience,
concentration, unit tests, and always trying to improve on yourself help
you achieve it.

1 If you have some spare time you can learn that by joining an Open
Source project.
--
Gerhard Häring
OPUS GmbH München
Tel.: +49 89 - 889 49 7 - 32
http://www.opus-gmbh.net/

|}}
임��� 1학년때� 수업시간� 보는 책� 어�정� 보았다고 ��하고 난 후, 형들한테 �런것� 많� 질문했� 기억� 난다.
- 형, � 책 다 보면 뭘 �야 할까요?
- � 언어 보고 난 다��는 무얼 보아야 좋�까요?
지금 � 순간� 후배들� 같� 질문� 한다면 NotToolsButConcepts �는 대답� 해주고 싶다(단, 언어� 하나� 툴��고 가정할 경우). 1, 2년 후배를 받� 때까지는 잘 몰�지만, �블스캠프나 새내기가 참가하는 세미나를 찾아갈 때마다 매번 들리는 소리였다.

툴� 아닌 개�

SICP를 책� 보면 예제 코드가 SchemeLanguage로 나온다. SchemeLanguage� 대해서는 잘 모르지만, � 언어를 사용하면 개� 전달� 쉽게 할수 있어서�듯 싶다. 툴�야 몇번 쓰면 ���으로 �혀지게 �지만(�군다나 요즈�� 나오는 툴들� �하다) 하나� 개�, 패러다임� �기 것으로 만드는 ��는 얼마나 오랜 시간� 걸리는가. (ToyProblems 때�, 간단한 문제를 가지고 여러 가지 방법으로 접근하였� 기억� 난다). 밥� 짓는 법� 안다면, 가스불로 만들�, 전기밥솥� 하� �관� 없다.

예

  • STL, Container, 등등ì�´ 아닌 GenericProgramming
  • MFC, VB 등ì�´ 아닌 EventDrivenProgramming + 그외ì—� 녹아있는 패러다임들.
  • Java, C#ì�´ 아닌 OOP(ObjectOrientedProgramming),AOP(AspectOrientedProgramming)
  • Goto ì“°ì§€ 마ë�¼! ê°€ 아닌 GotoConsideredHarmful ê°™ì�€ ì�´ì•¼ê¸°
    ...

Thread

1002 가 Windows Programming � 오래 하다가 EventDrivenProgramming � 개�� 나름대로 제대로 받아들였다는 �낌� 들었�때는 해당 플랫��서 1년 �� 작업했� 때 였다.(여기서 '받아들였다'는 실제 EventDriven Model로 디��해서 구현해보는 정�) 사람들� 공부 스타�� 따� 차�가 있지만, 해당 개�� 대해 제대로 �해하기 위해선 구현레벨�서� 경험� 필요하다. 위� '예' �서 '아닌 - Not' �란 단어대신 '넘어서 - Beyond' �는 단어로 바꿔서 �어보면 어떨까.

구현� 하는 사람� 늘 배경 개�들� 대해 사고해야 할것�며, 개�� 공부하는 사람� 구현 레벨�서� 코드와 결과물� 대해서 ��해보아야 할 것�다. 한쪽만으로� 치우침� 위험하다는 ��� 해본다. -- 1002

NeoCoin � �렇게만 ��했지만, 2년 전 즈�� ��� 바꾸었다. 구지 �어로 비슷하게 표현하면 UseToolAndLearnConcepts �랄까? ��켜 보면 �런 �황� � 많� 접하였다. 언어를 떠나 같� 시기 �안� 같� �� 대하여, 같� �구를 사용하는�, 한달뒤� 사용 정�와 �해�가 다른 사람들� �주 보게 �다. �구� 사용 능력 차�가 재미와 맞물려서 �메�� 사용 �� �해� 역시 비슷하게 따�오는 모습� �낄수 있었다. 멋진 �구� �탄하고, 사용하려는 노력 반대로 멋지지 않� �구�서 멋진 면� 찾아내고 사용하려는 노력 �둘� 근본�� Concept� 배우는 것과 멀리 떨어진것� 아닌것 같다.


NotToolsButConcepts�는 �� 수사�� 표현으로 용납할만한 범위� 든다고 봅니다.

{{|
Teach them skepticism about tools, and explain how the state of the software development art (in terms of platforms, techniques, and paradigms) always runs slightly ahead of tool support, so those who aren't dependent on fancy tools have an advantage. --Glenn Vanderburg, see Seminar:AgilityForStudents
|}}

저는 � 페�지가 컴퓨터 과학 �만� 아니고 대학�들� 공부 전반과 관련� 문제�고 ��합니다. 대학�서 무엇� 배워야 하는가? 무엇� 배우려고 노력해야 하는가? 저는 그것� �구�건, 개��건 간�, 그것� 좀� 근본��고, 그것� 만든 사람� 사유� 근접할 수 있는 것�고, 그것� 배우는 과정�서 �신� 사고 근육� 제대로 단련할 수 있는 것�어야 한다고 봅니다.

오�할 위험� 안고 구체�� 예를 한가지 든다면, Sway�는 GUI ��브러리를 공부할 때, �시� Sway를 만든 사람(그리고 그 사람� 아버지, ...)� 머리�과 사고과정� 들여다보고(관련 선구� 논문들� 찾아보고), 그것과 �기화해보고, 다시 그것� 대해 스스로 �단� 내려보는 노력� 하고, �를 다시 간단하게 구현해서 실험해 보고 하는 것� 반복하는 것� 제가 봤� 때�, NotToolsButConcepts� 정신� 맞지 않나 하는 ��� 듭니다. �것� 제가 배운 "제대로 학문하는 법"입니다. 남� 최종 결과물(artifact) ��서만 계� 놀지 �고, 그가 그걸 만들어낸 문제��과 과정� 내 몸으로 �접 체험해 보고 거기� 나 스스로 �단� 내려 보는 것입니다.

가족오�관�서 보면 여러명� �렬로 서서, 맨 �� 한 사람�게만 �담�나 사� 성어를 하나 보여주고, 그걸 몸짓으로 차례로 전달해서 마지막 사람� 맞추는 게임� 있습니다. 최초 몸짓� 하는 사람� ��를 �해하지 않고 그 모션� 그대로 �용할 수는 있습니다. 하지만 그 내면� �미를 꿰뚫고 있지 못하다면, 비� 아무리 잘 관찰� 했다고 해� 나는 분명 모션� �부를 왜곡하거나 빠트린 채 전달� 하겠지요. 그러나 �용� 계� 하다보면 우연히(그러나 꽤 오랜 시간 후�) 그 ��를 깨칠 수� 있겠지요. 하지만 우리는 "���으로" 그 사람� ��를 들여다 보려는 노력� 해야 합니다 -- 그 사람� 사고를 거슬러 올�가기� 하는 등 여러 방법� ��해서 ��죠. 그렇게 �면 우리는 똑같� 사� 성어� 대해 훨씬 � 우아하고 � 단순하며 명료하게 다듬� 모션�, 혹� 전혀 다른 모션� 새로� 창조해서 다� 사람�게 전달할 수� 있지 않겠습니까?

--JuNe


Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2021-02-07 05:23:51
Processing time 0.0096 sec