PL시간에 조금 들은 바로는 파스칼을 많이 꼽는 것 같더라구요..
C보다 여러면에서 철저하고..
(변수선언, assign과 equal 의 엄격한 구분 등등)
함수가 nested된 구조로 만들어 질 수 있고.. 뭐 여러가지로 C보다는 훨씬 고급의 언어라고 알고 있습니다..
사실 C는 참 너무 간단하게 구현된 언어이죠..
PL 시간에 배우는 이론들이 거의 적용되지 않는 언어가 바로 C입니다..-_-;
Pascal은 목적이 교육용이라서 그런지 몰라도 과도하게 딱딱합니다.
type checking만 해도 그냥 강하다기보다는 고지식하져...
설계적 측면에서 볼때는 설계패러다임에 가장 잘 맞는 언어가 설계에
강한 언어가 아닐까요?
구조적 설계라면 C도 좋을테고...
객체지향적으로 설계했으면 객체지향언어들...Smalltalk, C++, Java...
함수적이라면...Haskell, Lisp... SQL도 있죠...
경우에 따라서 정말 단순한 일을 하는 내장형 프로그램이라면
어셈블러가 더 편할수도...
어쨋든 설계를 어떤 방식으로 했냐에 따라서...또 여러가지에 따라서
달라질 수 있는...얘기같다는...
가장 훌륭한 이라는 것은 별 의미가 없는것같습니다...
구조적 언어로 C를 꼽기는 좀 어렵지 않을까 싶네요.
C는 low level programming을 위해 나온 언어니까요.
앞 분이 예를 드신 Pascal이 오히려 꼽기엔 더 나은 편이죠.
C는 low level programming이라는 면에서 첫째로 꼽을만하지만,
C++는 좋은 언어는 아닌 것 같습니다.
체계적으로 발전했다기보다는 이런 저런 기능들이 마구잡이로 추가됐죠.
프로그래머의 편의라는 면에서는 못할게 없으니 좋긴 하지만,
잘 설계되었다고 보긴 어렵고요.
그래서 Java나 C#의 경우 언뜻 보기에 C/C++과 유사해보이지만,
실상은 Object Pascal과 더 비슷하게 개발되었죠, 특히 OO면에서.
( 뭐, Delphi 개발자가 C#을 설계했다는 점도 한몫 하고 있긴 하지만요. )
Ada도 Pascal을 기반으로 발전한 언어고요.
사용해보진 않았지만, 괜찮다고들 .. -_-a
( 역시 많이 쓰이지 않는다는게 문제겠죠. )
어떤 사람들은 가장 잘 설계된 언어로 단연 Ada를 꼽더군요.
아, 그리고 컴파일러 제작이라는 측면에서
대개는 체계적으로 구성된 언어들이 파싱이 편한 관계로
컴파일 속도가 빠른 편이죠.
( 뭐, 지원해주는게 많아서 느린 경우도 있겠지만요. )
이런 점에서 Object Pascal이 정말 괜찮은 언어가 아닌가 하는 생각을. -_-;
( 컴파일이 C++ 보다 수십배는 빠르잖을까 하는 생각이 듭니다. -_-; )
설계의 측면에서 C는 결코 잘 만들어진 언어라고 볼 수 없습니다. 여기 글 쓰신 분들도 다 그렇게 생각하시는 것 같지만...
하지만 C는 컴파일러 이론이 생기기도 전에 만들어진 언어란 점은 주목하셔야 될 듯합니다. 컴파일러 이론이 생기기 전이었으니 문법 파싱에 대한 툴이나 이론도 전무했던 시점에서 만들어진 언어인건데, 이건 정말 대단한거죠.
쓰기 불편했든 어쨌든 그래도 UNIX OS를 만들 수 있을 정도의 언어니까요. ^^;
문법 문제를 떠나 위엣 분이 쓰신대로 로우 레벨을 위한 설계라 한다면 C도 잘 만들어진 언어라 할 수 있을겁니다. 막강한(그러나 복잡한) 포인터가 있으니까요.
저에게 언어 하나를 꼽아보란다면, 접해본 언어가 많지 않아서 곤란하긴 하지만 그래도 최근에 나온 언어인 파이썬이 무척 잘 만들어져 있지 않나 생각합니다. 일단 문법 설계도 깔끔하거니와 statement를 라인으로 구분하고 블럭은 탭 갯수로 구분하게 되어있기 때문에 서로 다른 사람이 짜더라도 코딩 컨벤션은 유사해지니까요.
자유스러운 코딩이 가능하면서도 잘 짜여진 신택스를 갖고 있다는 점에서 전 파이썬이 맘에 듭니다.
하지만 말했다시피 제가 접해본 언어가 많지 못하기도 하거니와 언어는 '도구'니까요, 어떤 언어가 '가장' 좋다고 말하는건 역시 어불성설이겠죠.
노루가 사냥꾼의 손에서 벗어나는 것 같이, 새가 그물치는 자의 손에서 벗어나는 것 같이 스스로 구원하라 -잠언 6:5
하지만 C는 컴파일러 이론이 생기기도 전에 만들어진 언어란 점은 주목하셔야 될 듯합니다. 컴파일러 이론이 생기기 전이었으니 문법 파싱에 대한 툴이나 이론도 전무했던 시점에서 만들어진 언어인건데, 이건 정말 대단한거죠.
C 언어에서 block 구조가 엉망이라는 건 용서가 안 됩니다. pascal이나 algol의 begin/end 쌍의 우아함이 C 언어의 {}에는 없습니다. :( 그 단점을 C++도 이어받았고요. 그리고 파싱 이론이 없었다뇨? BNF는 C 언어보다 10년 이상 빠른 ALGOL에서 이미 쓰였습니다.
아! 물론 The US Department of Defence가 '직접' 만든 언어는 아니지만 Ada를 개발하게 된 프로젝트를 시작했죠. 그래서 사람들이 보통 미국방성에 Ada를 개발했다고 하죠..(자바는 우리가 썬에서 개발했다구 하지요?) 미 국방성이 임베디드시스템개발을 위한 적당한 언어를 찾게 된것이 원인이 되었다구 하네요....
(높이깊이, Code Complete 번역서, p520)
"마지막으로, 역사상 가장 세심하게 만들어졌다는 언어인 Ada에다 goto 문이 포함되어 있다는 사실이 goto문의 유용성을 증명한다."
라는 구절이 있더군요.
마침 요즘 goto가 갑자기 화제인지라... ^^
Ada는 구경도 못했는지라 실제로는 어떤지 전혀 모릅니다. ^^;;
C++의 설계에대해서는
"The Design and Evolution of C++"
를 읽어본 후에 이야기하는 게 좋을 듯하네요. Stroustrup 씨도 따로 이런 책도 쓰고... The REAL interview 도 따로 만들어야될 만큼 이런저런 말에 휩싸이는 것이 좀 불쌍하군요. ^^;
사실 C++의 지독한 팬인지라.... C++ 이야기가 나오길래 한번 써봅니다.
이런저런 C++에대한 비판적인 의견은 어디서나 너무 많아서 좀 민감해져서요... ^^;;; C++은 워낙 스스로 자치하는 위치와 실력에비해 이런저런 말이 많아서 말이죠. 보통 그런 것들은 표준도 만들어지기 이전의 불완전한 언어를 조금 만지작 거리다 하는 이야기일 경우가 많은데 말입니다. C++팬들이 이런곳의 논쟁에 자주 참여하지 않아서 한쪽의 잘못된 이야기가 일반화되는 경우가 많은 것 같기도 하구요.
솔직히 말해서는 오브젝트파스칼의 컴파일 속도와 그 문법(똑같은 것을 C++로 쓰면 좀 지저분해 보이지요)에는 저도 참 감탄합니다만, 표준도 아니고 볼랜드툴에서만 쓰이는 것이니 좀 논외가 아닐지요. 그리고 사실 개인적으로는 오브젝트 파스칼은 C++에 비해 재미가 없구요. 로우레벨까지 내려가기가 힘들더군요. ^^;;; 이런 말 하는 것도 프로그램 몇개 대충 짜보고 하는 말이라 아까 이야기한 섯불리 언어에대해 논하지 말자는 저의 주장에 어긋나기는 하는군요. ^^;
그리고 설계에대해서 이야기하자면, 무엇에 중점을 둔 설계인지도 거론이 되어야할 것 같구요. 대략 저의 짧은 소견으로는 현재 각 분야에 쓰이는 언어들은 다들 스스로의 용도에 맞게 잘 설계된 것 같다고 생각하구요.... 사실 무식해서 어려운 이론은 잘 모릅니다만... 아무튼 이런 비교하거나 무엇이 최고다하는 이야기는 각각의 대상의 팬들이 싸우기 쉬워서 좋지 않다고 생각합니다. 사실 읽는 입장에서는 매우 재미있는 것이 이런 쓰레드이기는 하지만 말입니다. ^^;
사실 C는 고급언어라고 보기엔 ..
다소 무리가 있지 않나 싶네요 .. -_-;
전 분류하라고 한다면 Low-level 쪽에 놓고 싶은데요 ..
어셈블리어를 좀 간소화한 정도가 아닐지 .. -_-a
구조적으로 쓰는 사람들에겐 구조적인 언어겠지만 ..
구조적인걸 염두에 두고 만들어진 언어는 아닌것 같네요 ..
여튼 그래서 .. C++가 C보다 아주아주 고급이라는건 너무나 당연하다는 .. ;;
음, C++는 개인적으로 제일 마음에 안드는 요소가 .. OO 던데요 ..
웬만해서 다중상속 쓰는 사람이 있나요 .. -_-;
Object Pascal에서 Java, C# 쪽으로 이어진 interface 개념이 ..
개인적으로 훨씬 편하고 나은 개념이라고 생각해서요 ..
( 물론 다중상속을 이용해서 interface를 구현하는건 가능하겠죠 .. )
다중상속이 컴파일러에 부담도 크다고 알고 있는데 .. -_-;
( 사실 제일 마음에 안드는 요소는 컴파일 시간인듯도 .. -_-;; )
좀 맘에 드는건, Template이 그래도 폼이 나는것 같아서 좋다 싶긴 한데 ..
OO의 상속으로 어느 정도 구현이 가능해서 ..
( Java의 Class Library들을 보면 .. -_-a )
어느 언어든간에 뭔가 다른 구현이 나와주면 좋겠다 싶네요 ..
STL 같은거 너무 무거운-_- 느낌이던데 ..
( C++와 Java의 벤치마크에서 C++ 코드에 STL 류가 들어가면 .. )
( C++도 Java 만만치 않게 느리더군요 .. -_- )
그리고 C++에서 Low-level로 내려갈수는 있지만 ..
그냥 C로서 접근하는게 아닌지요 .. ;;
C++에선 Low-level의 접근은 지양하고 있지 않은지 .. ;;
( Object Pascal도 Low-level 접근이 가능합니다 .. 잘 안하죠 .. ;; )
여튼 .. Java나 C#이 ..
최근에 만들어진 언어이니만큼 ..
구조적으론 제일 괜찮다 싶다는 .. -_-a
( 메모리 Free 안해도 되는게 너무 편하기도 하고요 -_-; .. 흐 ;; )
적당히만 자제하면서(-_-;) 쓰면 다중상속이 얼마나 편리한데요. 저는 애용합니다. 다중상속의 멋짐은 The C++ Lang. 예제코드등 여러 고수들의 코드를 참조해보세요 ^^;
컴파일시간은 특별히 GUI쪽 코드가 아닌 서버측 코드에서는 크게 문제가 안된다고 봅니다. GUI쪽 코드도 볼랜드터보파스칼 컴파일러가 너무 빨라서 느려보이는 것이지... ^^;;
어떤 일을 할 때는 Template이나 OO둘다로 가능할 경우가 있는데, 이부분에대해서는 저도 어느 것이 더 나은지 좀 더 조사가 필요할 것 같습니다. 개인적으로는 타이핑이 좀 더 적은 template을 선호하지만 흠....
Quote:
STL 같은거 너무 무거운-_- 느낌이던데 ..
( C++와 Java의 벤치마크에서 C++ 코드에 STL 류가 들어가면 .. )
( C++도 Java 만만치 않게 느리더군요 .. -_- )
이런... 언제적 이야기인지 어떤 벤치마크인지는 모르겠지만 -_-; STL의 속도는 어셈을 쓴 machine-dependent code가 아닌 C의 속도와 거의 같거나 더 빠릅니다... 스트림을 다량으로 사용해서 그런 일이 벌어졌을 수 도 있는데, IO에 c api를 사용하면, STL 구현이 좋지않기로 유명한 MS VC++6.0 를 써도 그렇습니다. (이론상으로는 런타임에 형을 결정하는 printf계열보다 stream이 더 빠른데 실제로는 좀 느리죠 -_-; 흠 하지만 어떤 컴파일러는 c api IO보다 더 빠른 것도 있다고는 합니다. 스트럽씨가 말하길 -_-;)
여담으로 예전에 알고리즘 수업에서 2차,3차,64차원의 고정된 영역안의 10만개 점 각각의 가장 가까운 점을 찾는 코드를 작성한 적이 있었는데, 속도별로 점수를 주는 수업이라 C로 나름대로 최적의 최적화를 해서 짰던 경험이 있습니다. 2차는 이렇게 하다가 3차 이상이 되면서 너무 C코드가 지저분해 지길래 한번 STL을 도입해서 사용해 보았죠. 제가 짠 C코드랑 ms단위로 똑같은 속도가 나오더군요. (무려 표준전에 나온 VC++6.0으로 짰습니다.)
아 그냥 MMORPG 서버 플밍할때 STL을 쓰는 회사가 엄청 많다는 것이면 더 이상 이야기할 필요가 없군요.
Quote:
C++에선 Low-level의 접근은 지양하고 있지 않은지 .. ;;
C++을 만들 때의 목표중에 하나가 C를 대체하는 system programming 언어였고, 지금도 그 목표는 유효합니다. ^^; 스트럽씨는 system programmer들이 c++을 안쓴다고 불평이 대단하지요. "늙은 개에게 새로운 트릭을 가르키는 것은 힘들다" 라는 말까지 할 정도입니다. ^^;
Quote:
여튼 .. Java나 C#이 ..
최근에 만들어진 언어이니만큼 ..
구조적으론 제일 괜찮다 싶다는 .. -_-a
Java나 C#은 언어구조적으로는 80년대 OOP 일 뿐입니다. C++은 ML등을 참고한 generic programming과 더 많은 OOP지원이 있습니다. (라고 스르럽씨가 말하더군요 ^^) 이런 것은 JAVA가 최근에 GJ어쩌구 하면서 C++의 개념을 도입하려는 시도를 보면 알 수 있습니다.
Quote:
p.s.
아참 제가 Java를 공부하면서 ..
제일 감동했던건 ..
다중 루프를 빠져나가는 break, continue 였던것 같네요 ..
goto의 마지막 용도마저 사라지게 해준 .. ㅠ_ㅠ
break, continue는 C에도 있습니다만... goto에 대한 이야기는 no-smok.net 쪽 사람들이 이번호 마소에 기재하면서 최근 화제인데요. 마소최근호와 Code Complete의 goto관련 내용을 읽어보시면 좋을 것 같습니다. 저는 goto옹호론자 이기도 합니다. ^^;;;
Quote:
개인적으로 현재의 C++의 efficiency를 거의 잃지 않고서
C와의 호환성 등을 위한 지저분한 구석을 제거하고,
문법도 깔끔하게 정리하고,
Thread에 대비한 라이브러리 등 다양한 라이브러리들 제공하고,
기존의 C++코드도 쉽게 연결해서 사용할 수 있는
OS를 만들더라도 성능에 지장이 없는 새로운 언어가 나왔으면 좋겠습니다.
스트럽씨가 2004년으로 기획하시고 있는 C++ 다음 버전에는 thread지원이 포함됩니다. 표준 gui 라이브러리도 생각하시고 있는 것 같구요. 스트럽씨는 C++의 지금 문법에서 쓸데없는 곳은 전혀 없으며, 바꿀 곳도 거의 없다고 생각하시는 것 같습니다. C++로 OS를 만들면 성능에 지장이 있다는 것은 오래된 편견입니다. WindowsXP 2000등등은 무슨 언어로 만들어져있다고 생각하시는지요...
C++로 만들어진 OS관련 리스트입니다. (덤도 있고 ^^)
Apple: OS X is written in a mix of language, but a few important parts are C++. The two most interesting are
Finder
IOKit device drivers. (IOKit is the only place where we use C++ in the kernel, though.)
Also,
AppleWorks
the iPod user interface (uses Pixo application framework written in C++)
"Of the thousands of Macintosh applications that have shipped I estimate that over half were written C++".
Frameworks: There are three major C++ application frame works developed for Macintosh: Apple's MacApp (some MacApp applications), Symantec's Think Class Libraries, and Metrowerks' PowerPlant. There are also a number of smaller (in market share) frameworks that have been developed.
IBM: OS/400.
Microsoft: Literally everything at Microsoft is built using various flavors of Visual C++ - mostly 6.0 and 7.0 but we do have a few holdouts still using 5.0 :-( and some products like Windows XP use more recent builds of the compiler. The list would include major products like:
Windows XP
Windows NT (NT4 and 2000)
Windows 9x (95, 98, Me)
Microsoft Office (Word, Excel, Access, PowerPoint, Outlook)
Internet Explorer (including Outlook Express)
Visual Studio (Visual C++, Visual Basic, Visual FoxPro) (Some parts of Visual Studio like the Base Class Libraries that ship with the .NET Framework were written using C# but the C# compiler itself is written in C++.)
Exchange
SQL
There are also "minor" products like:
FrontPage
Money
Picture It
Project
and all the games.
Sun:
The HotSpot Java Virtual Machine is written in C++ (this is the leading edge, high performance replacement for Sun's "classic JVM" which was written in C).
Sun's compilers have major components written in C++, in particular the C++ front end, parts of the Fortran 95 front end, and the SPARC back end.
Parts of Solaris are written in C++, though the external interface is usually crafted to look like C, for compatibility and stability reasons.
에... 저도 간만에 이목록을 보니 이때까지 한말들이 그냥 필요가 없어지는 군요... -_-; 더 주절 거릴 랬는데 역시 C++로 플밍이나 하러 가야겠습니다. -_-;
high performance replacement for Sun's "classic JVM" which was written in C
허허... 이제보니 c로짠 JVM보다 빠르게하기위해 c++로 새로 JVM을 짠 것이 java책에서 그렇게 자랑하는 HotSpot JVM 이었군요. 이제봤음 ^^;
Ada 이야기가 잠시 나오는 것 같아 경험상 써 봤던 Ada 이야기를 잠시 하겠습니다. Ada는 세계 최초의 여성 프로그래머에서 이름을 따 왔는것으로 알고 있습니다. 미 국방성이 Ada를 채택한 이유는 언어상에서의 ambiguity, 모호함을 최대한 줄인 언어이기 때문입니다. 즉, 괄호 만으로 간단히 이루어질 수 있었던 다른 언어들에 비해 Ada는 이를 비롯하 애매한 것들을 모두 없앴죠.
아마 코드를 보시면 이건 영어인지, 컴퓨터 언어인지 착각을 불러일으킬 정도로 영어 단어들을 그대로 옮겨둔것 같을 것입니다. 물론 영어권에서는 이게 편할 수도 있겠지만, 같이 Ada를 썼던 영국 동료들 또한 '이게 영어지. 컴퓨터언어냐'하는 식이었습니다. :)
역사적으로 Ada83은 더이상 잘 안 쓰는 것으로 알고 있으며 최근에는 Ada95를 기준입니다. 미국방성에서 만들었다는 이야기가 나오듯이, 항공기 제어에 쓰이고 있는 것으로 알고 있으며, 제가 알기론 Boeing 777에 사용되었는 것으로 알고 있습니다. (제 기억으로 확실치 않지만, 컴파일 때인지 런타임상인지 몰라도 코드를 재확인하는 작업이 들어가는 것과 같은 정확도를 기하는 작업을 하는것으로 알고 있습니다.)
현재 컴퓨터 과학적인 측면에서 미국보다는 유럽에서 인기가 더 많은 것으로 알고 있으며, 위에서 말한 항공기의 예처럼 리얼타임 쪽에서 인기를 끌고 있습니다.
마지막으로 한마디는.. 저희학교 학부생들은 Ada 무지 싫어합니다. ;) - 머 다 싫어하지만..
--
개인적으로 경험상, 그리고 들은 것을 바탕으로 올렸습니다. 웬만하면 확인작업을 하고 글을 올리는 성격인데, 최근에 글쓰는데 별로 신경을 안 쓰는 관계로 양해를 부탁드립니다 :) - 그렇다고 그짓말을 쓴거 아닙니다. ^^ 제가 잘못 알고 있었던 점은 지적해주세요 :)
break, continue는 C에도 있습니다만... goto에 대한 이야기는 no-smok.net 쪽 사람들이 이번호 마소에 기재하면서 최근 화제인데요. 마소최근호와 Code Complete의 goto관련 내용을 읽어보시면 좋을 것 같습니다. 저는 goto옹호론자 이기도 합니다. ^^;;;
JAVA에서 제공하는 break, continue는 C/C++의 그것과 같은 기능외에 label을 지정해서 여러 레벨을 뛰어넘게 할 수 있으므로 기존 goto를 정말로 거의 필요없게 해줍니다.
asheep wrote:
스트럽씨가 2004년으로 기획하시고 있는 C++ 다음 버전에는 thread지원이 포함됩니다. 표준 gui 라이브러리도 생각하시고 있는 것 같구요. 스트럽씨는 C++의 지금 문법에서 쓸데없는 곳은 전혀 없으며, 바꿀 곳도 거의 없다고 생각하시는 것 같습니다. C++로 OS를 만들면 성능에 지장이 있다는 것은 오래된 편견입니다.
C++로 OS를 만들면 성능에 지장이 있다는 의미가 아니라 기존의 C++의 efficiency를 거의 잃지 않으면서(즉 OS를 만드는데도 지장이 없으면서) 대체할만한 언어가 나오면 어떨까 하는 생각이었습니다 ^^;
그리고 Stroustrup라도 만약 기존의 호환성문제를 생각하지 않고서 완전히 새로운 언어(기존 C++과 비슷한 성능을 보장하는)를 만들게 된다면 상당부분 수정하게 되지 않을 까 생각합니다.
cdpark wrote:
begin/end 쌍은 statement가 되지만, {} 쌍은 statement가 아닙니다.
이런 상황은 C언어에서 macro 등을 만들 때에도 신경을 쓰이게 만듭니다.
statement라는 게 구체적으로 어떨 때 유용한지 잘 모르겠네요 ^^; #define을 쓰는 macro는 C++에서는 보통 inline함수로 대체하게 됩니다.
적당히만 자제하면서(-_- 쓰면 다중상속이 얼마나 편리한데요. 저는 애용합니다. 다중상속의 멋짐은 The C++ Lang. 예제코드등 여러 고수들의 코드를 참조해보세요 ^^;
object-pascal, java, c#에서도 다중상속이 아주 불가능한 것이 아니죠 ..
단지 '절제된 다중상속'을 interface라는 새로운 개념으로 해결한거구요 ..
C++에서도 다중상속은 대부분 저정도로밖엔 쓰이지 않는 것 같던데요 ..
그러지 않으면 너무 번잡해지지 않는지 .. -_-;
Quote:
이런... 언제적 이야기인지 어떤 벤치마크인지는 모르겠지만 -_-; STL의 속도는 어셈을 쓴 machine-dependent code가 아닌 C의 속도와 거의 같거나 더 빠릅니다... 스트림을 다량으로 사용해서 그런 일이 벌어졌을 수 도 있는데, IO에 c api를 사용하면, STL 구현이 좋지않기로 유명한 MS VC++6.0 를 써도 그렇습니다. (이론상으로는 런타임에 형을 결정하는 printf계열보다 stream이 더 빠른데 실제로는 좀 느리죠 -_-; 흠 하지만 어떤 컴파일러는 c api IO보다 더 빠른 것도 있다고는 합니다. 스트럽씨가 말하길 -_-
여담으로 예전에 알고리즘 수업에서 2차,3차,64차원의 고정된 영역안의 10만개 점 각각의 가장 가까운 점을 찾는 코드를 작성한 적이 있었는데, 속도별로 점수를 주는 수업이라 C로 나름대로 최적의 최적화를 해서 짰던 경험이 있습니다. 2차는 이렇게 하다가 3차 이상이 되면서 너무 C코드가 지저분해 지길래 한번 STL을 도입해서 사용해 보았죠. 제가 짠 C코드랑 ms단위로 똑같은 속도가 나오더군요. (무려 표준전에 나온 VC++6.0으로 짰습니다.)
C++보다 Java가 빠르단 얘길 하려던게 아니구요 ..
C++가 Java나 C#에 대해 속도면에서 메리트가 별로 없단 얘기였습니다 ;;..
사실 Java가 별로 느리지 않다고 해야 할수도 있겠죠 ..
짧은 프로그램이라면 Java가 당연히 느리겠지만 ..
대규모 프로그램에선 JIT 때문에 속도차가 별로 나질 않습니다 ..
오히려 Java가 Run-time Optimization을 해서 ..
Compile-time Optimization을 하는 C/C++보다 빠른 경우도 ..
적지 않다고 하네요 ..
이젠 C++ with STL이 속도면에서 메리트가 떨어지고 있는걸로 압니다 ..
( J2EE가 많이 쓰이고 있는걸 봐도 알수 있죠 .. )
Quote:
Java나 C#은 언어구조적으로는 80년대 OOP 일 뿐입니다. C++은 ML등을 참고한 generic programming과 더 많은 OOP지원이 있습니다. (라고 스르럽씨가 말하더군요 ^^) 이런 것은 JAVA가 최근에 GJ어쩌구 하면서 C++의 개념을 도입하려는 시도를 보면 알 수 있습니다.
80년대 OOP라고 해도 C++보다는 이후에 나왔죠 .. -_-;
더 많은 OOP의 지원이라는 건 다중상속말고 없지 않나요 .. ;;
Template을 사용한 Generic Programming은 편리하긴 하죠 .. 음,
( 이미 이에 대해선 기술한것 같은데 .. -_-; )
Java나 C#정도의 OO에 Template이 가미되는것도 괜찮을듯요 ..
느려지지만 않는다면 .. -_-;
( 그리고 Generic Programming이 C++의 것만은 아니죠 .. -_-a )
Quote:
break, continue는 C에도 있습니다만... goto에 대한 이야기는 no-smok.net 쪽 사람들이 이번호 마소에 기재하면서 최근 화제인데요. 마소최근호와 Code Complete의 goto관련 내용을 읽어보시면 좋을 것 같습니다. 저는 goto옹호론자 이기도 합니다. ^^;;;
C나 Object-Pascal에 있는 break, continue보다 ..
Java에 있는 쪽이 더 진보한 break, continue입니다 ..
기존 break, continue의 경우 다중 루프는 빠져나갈 길이 없었죠 ..
오로지 goto밖에 .. -_-;
goto가 structured programming때부터 지양된 건 ..
나름대로 이유가 있다고 생각하는데요 .. ;;
goto 없이도 충분히 모든 코드가 작성 가능한데 ..
( 다중 루프 빠져나오는 것만 빼고요 .. -_-; 가능하긴한데 효율이 너무 ;; )
( Java에선 그게 해결된거죠 .. )
굳이 goto로 쓰여진 코드로 분석하고 디버깅하고 하려면 ..
정말 피곤하단 생각이 -_-; .. 들더라고요 ..
이리 뛰고 저리 뛰고 .. -_- 분석 흐름을 팍팍 끊어놓는 .. ;;
Quote:
허허... 이제보니 c로짠 JVM보다 빠르게하기위해 c++로 새로 JVM을 짠 것이 java책에서 그렇게 자랑하는 HotSpot JVM 이었군요. 이제봤음 ^^;
뭐, Java로 만들수는 없었겠죠 .. ^^
개인적으로는 C++가 .. 나쁜 언어라기보다는 ..
적당히 다이어트를 좀 해줬으면 좋겠단 생각이 듭니다 ..
( 그래서 나온게 Java, C#이겠죠 .. 생산성 문제에서 나오기도 했겠지만 .. )
스트럽씨는 자기 언어에 자부심이 너무 큰게 아닌가 생각을 .. ;;
그리고 C++가 많이 쓰이는 게 ..
새로운 더 나은 언어의 발전을 막는다는 생각도 들고요 ..
C++가 전 분야에 걸쳐 많이 쓰이는 이유는 ..
C++가 설계가 잘 된 언어라기보다 ..
독보적으로 존재하는 동안 만들어진 코드가 아무래도 많다는 점이 ..
가장 크지 않나 생각해봅니다 .. ;;
뭘좀 찾아볼래도 C++로 된 자료가 대부분이니까요 .. ;;
Code Complete에 보면 배치를 할 때 if 와 같은 line에 {나 begin을 두어야 하느냐 밑의 줄에 두느냐 가지고 복잡하게 설명을 합니다.
또 보통의 경우에는 if, while 등에 { }나 begin, end를 나중에 대비해서 항상 둘 것인가 1줄만 있을때는 뺄 것인가.. 착각하지 않기 위해 항상 둘 것인가 등등을 고민해야 합니다.
해결방법은 Pascal의 제작자인 N.Wirth가 만든 언어인 Modula(70년대 말), Oberon(80년대 말)에서 해결되고 최근에 나온 Ruby 같은 언어에서도 사용되는 방식입니다.
if 조건문 then
...
elsif
...
else
...
end
로 합니다. 이러면 begin이나 {이 아예 없기 때문에 어디에 둘 것인지 고민할 필요도 없고, 1줄만 있는 경우에 begin~end, { }를 둘 것인가 말 것인가도 고민할 필요가 없습니다.
>> 싫다는데 별로 할말이 없군요...
>> 근데 왜싫다는건지... 무작정 싫다는건지...^^;
>> 저는 C,C++, 특히 Pascal 을 알고있는 분이라면 혼자서도 충분히 능히
>> 배울수 있는 쉽고도 깔끔한 꽤 괜찮은 언어라고 생각합니다.
>> 그리고 많은 사람들이 좋아할수 있는
>> 언어라고 생각합니다. 쓸데없는 선입견만 작용하지 않으면 말이죠...
object-pascal, java, c#에서도 다중상속이 아주 불가능한 것이 아니죠 ..
단지 '절제된 다중상속'을 interface라는 새로운 개념으로 해결한거구요 ..
C++에서도 다중상속은 대부분 저정도로밖엔 쓰이지 않는 것 같던데요 ..
그러지 않으면 너무 번잡해지지 않는지 .. -_-;
interface는 단지 다중상속의 subset에 불과하지 않습니까?. public 상속, protected 상속, private 상속 각각이 적절한 용도가 있고... java의 인터페이스는 C++의 다중상속이 행하는 100의 기능 중에서, 약간의 다양성과 복잡성을 싫어하는 일부의 프로그래머들을 위해 기본적인 70의 기능만을 합니다. 70만으로도 충분하지만, 가끔 100의 확장성을 바라는 사람들을 만족시키지 못하는 것이 자바입니다.
Quote:
C++보다 Java가 빠르단 얘길 하려던게 아니구요 ..
C++가 Java나 C#에 대해 속도면에서 메리트가 별로 없단 얘기였습니다 ;;..
사실 Java가 별로 느리지 않다고 해야 할수도 있겠죠 ..
짧은 프로그램이라면 Java가 당연히 느리겠지만 ..
대규모 프로그램에선 JIT 때문에 속도차가 별로 나질 않습니다 ..
오히려 Java가 Run-time Optimization을 해서 ..
Compile-time Optimization을 하는 C/C++보다 빠른 경우도 ..
적지 않다고 하네요 ..
이젠 C++ with STL이 속도면에서 메리트가 떨어지고 있는걸로 압니다 ..
( J2EE가 많이 쓰이고 있는걸 봐도 알수 있죠 .. )
자바에 관한 이야기중에 실제 현업에서 일하는 프로그래머 입장에서 너무 현실과 동떨어진 이야기라고 생각하는 것이 이부분입니다. 대규모 프로그램의 정의를 엔터프라이즈 환경에서 사용하는 어플리케이션이라고 생각하시는 것 같은데, 이부분에 대해서는 경험이 없어서 머라고 말할 수가 없습니다. 하지만, 일반적인 프로그래머가 접하는 환경에서 JAVA로 짠 프로그램은 너무도 느립니다. 클라이언트 쪽은 더이상 언급할 필요가 없다고 생각하구요. 서버측 프로그램으로도 속도가 필요한 작업에서는 C++에 비해 손실이 크더군요. 개발기간이나 규모에서 진정 대규모라 불릴말한 게임이라던지 네트워크응용 어플리케이션 개발에서는 JAVA로는 불가능 하던지, C++에 비해서 장비에대한 투자가 더 필요하다고 생각합니다.
Quote:
80년대 OOP라고 해도 C++보다는 이후에 나왔죠 .. -_-;
더 많은 OOP의 지원이라는 건 다중상속말고 없지 않나요 .. ;;
더 최근에 나온 것이 더 좋다는 의견에는 동의할 수 없지만, 굳이 발표시기를 본다면, 수많은 토론끝에 C++의 표준이 제정된 것은 1998년이고, 자바의 발표 1995년 으로 알고 있습니다. 지금 누구도 K&R C를 가지고 C이야기를 하지 않고 C89 이야기를 하는 것처럼, 비교를 하자면 C++98로 해야할 겁니다. Java는 이후에 여러버전이 추가됐지만, 굳이 언어자체의 기능추가로 보이는 것은 특별히 보이지 않습니다.
Quote:
( 그리고 Generic Programming이 C++의 것만은 아니죠 .. -_-a )
으음 제가 GP가 C++에만 있다고 한 적은 없는 것 같군요. ML등의 언어에서 도입했다고는 이야기 한 것 같은데, 굳이 C++ 독자적인 것이라면, 템플릿에서 파생된 템플릿 메타 프로그래밍입니다. kldp에서도 논의된 외 수치계산 프로그래밍에서는 fotran을 아직 사용하느냐? 에 관련이 있는데, 수치계산 용으로 무지 빠릅니다. 게임 프로그래밍에도 응용하려는 연구가 활발 합니다. 이렇듯 C++을 공부하고 연구하면 새로운 영역이 다시 발견되는 점이 정말 매력적입니다.
Quote:
C나 Object-Pascal에 있는 break, continue보다 ..
Java에 있는 쪽이 더 진보한 break, continue입니다 ..
기존 break, continue의 경우 다중 루프는 빠져나갈 길이 없었죠 ..
오로지 goto밖에 .. -_-;
goto가 structured programming때부터 지양된 건 ..
나름대로 이유가 있다고 생각하는데요 .. ;;
goto 없이도 충분히 모든 코드가 작성 가능한데 ..
( 다중 루프 빠져나오는 것만 빼고요 .. -_-; 가능하긴한데 효율이 너무 ;; )
( Java에선 그게 해결된거죠 .. )
굳이 goto로 쓰여진 코드로 분석하고 디버깅하고 하려면 ..
정말 피곤하단 생각이 -_-; .. 들더라고요 ..
이리 뛰고 저리 뛰고 .. -_- 분석 흐름을 팍팍 끊어놓는 .. ;;
아 Java를 배울때, 그냥 goto가 이름이 바뀌고 다른 모든 기능처럼 기능이 제한 당했군... 이라고 생각하면서 넘어가서 착각을 해버렸군요. 별로 멋지다는 생각이 전혀 들지 않는 기능이라 -_-;; 으음 당연히 왔다갔다 goto는 좋지 않지요. 이부분에대해서 쓰자면 길어지니까, 마소이번호goto관련기사와 code complete의 goto에관한 부분을 좀 참고해주세요...
Quote:
개인적으로는 C++가 .. 나쁜 언어라기보다는 ..
적당히 다이어트를 좀 해줬으면 좋겠단 생각이 듭니다 ..
( 그래서 나온게 Java, C#이겠죠 .. 생산성 문제에서 나오기도 했겠지만 .. )
스트럽씨가 지겹게 말하는 부분입니다. C++의 광대함은 general perpose language 이기 때문이라구요. specific 한 곳에서만 사용될 수 있는 언어가 아닙니다. general 좋냐 specific이 좋냐 라는 부분에 대해서는 논란이 있지만, 저는 왠만하면 general이 좋습니다. 더 많은 곳에, 더 다양하게, 연구하면 할 수록 개선되는 그런 점이 마음에 듭니다. 그리고 C++의 기능이 많다고 해서 그것을 꼭 다 사용할 필요는 전혀 없습니다만, 많은 사람들이 이유없이 C++의 모든 기능을 100% 익힌 다음에 그것들을 한번에 모조리 사용하려고 해서 더 상황을 악화시키는 것은 좀 문제죠.
생산성 문제는 초기에 C++이 제공하는 라이브러리가 너무 없었다는 점에서 나왔구요. (스트럽씨도 후회하는 것중에 하나지요. 표준이전에 너무 라이브러리 제공을 못했다는 점이...) C++ 라이브러리 제공만 많이하면 생산성은 자바랑 비교해도 전혀 밀리지 않죠. C++Builder를 한번 사용해보시면 이해가 될텐데요. 델파이의 생산성의 95%정도는 보여준 다고 생각합니다.
C++가 전 분야에 걸쳐 많이 쓰이는 이유는 ..
C++가 설계가 잘 된 언어라기보다 ..
독보적으로 존재하는 동안 만들어진 코드가 아무래도 많다는 점이 ..
가장 크지 않나 생각해봅니다 .. ;;
뭘좀 찾아볼래도 C++로 된 자료가 대부분이니까요 .. ;;
개인적으로는 동의할 수 없습니다. 분명 좋으니까 쓰는 것이지요.
C++이 독보적인 존재가 되기 까지는 C, 파스칼등의 이미 선점된 언어들의
영역을 뺏어내야만 했고, 많은 객체지향 언어중에서 실제 언어의 실용성이
중요한 상업 소프트웨어 회사들에의해 선택되어 지금에 이른 것 입니다.
지금은 Java나 각종 script언어의 맹공을 받고 있지만
일부 분야(game,client app.,c++로된 os)에서는 가까운 시일안에 다른 언어로의 대체는 거의 불가능하다고 봅니다. 진짜 돈되는 분야의 프로그래밍은 거의 C/C++로 이루어지고 있구요... 차츰차츰 C의 영역도 조금씩 더 차지하리라고 봅니다. (순전히 개인적인 예상+기대입니다. ^^)
그 두개만 보면 그렇겠지만..
sh에서는 loop만 do, done으로 하는 일관적이지 않는 방식을 가지고 있네요.
while/elihw, for/rof, foreach/hcaerof 로 해야 일관성이 있는데..
다 외우기 어려우니.. :) 그냥 end로 하는게 결국 나을 것 같습니다.
물론 개인적인 취향이라고 할 수 있습니다. 단, 많은 경험자들이 생각하는 바를 적은 것입니다. 적어도 제 주변에는 수십명 이상의 Ada 사용자들이 있으니까요.
저는 첫언어를 Scheme과 Ada로 배웠습니다. 특별한 취향상 차이일 수도 있지만, Ada가 프로그래머들이 생각하는 간단명료에 많이 뒤떨어져 있는건 사실입니다. 그리고 이미 인터넷 세상에 살고 있는 프로그래머들에게 특수한 환경에서 쓰이는 언어는 인기도에서 떨어지는 것은 사실이죠.
Quote:
마지막으로 한마디는.. 저희학교 학부생들은 Ada 무지 싫어합니다.
>> 싫다는데 별로 할말이 없군요...
>> 근데 왜싫다는건지... 무작정 싫다는건지...^^;
>> 저는 C,C++, 특히 Pascal 을 알고있는 분이라면 혼자서도 충분히 능히
>> 배울수 있는 쉽고도 깔끔한 꽤 괜찮은 언어라고 생각합니다.
>> 그리고 많은 사람들이 좋아할수 있는
>> 언어라고 생각합니다. 쓸데없는 선입견만 작용하지 않으면 말이죠...
위에 제가 말씀드린 거와 같습니다. Ada에 대한 나쁜 견해 같은건 없습니다. 저도 얼마후에 리얼타임 프로젝트를 Ada로 할 것이고, 이미 마일리지 적립시스템 프로젝트의 코어부분을 Ada로 만들었습니다.
다시 말씀드리지만, 제 경험상을 말씀드린 것입니다. 선입견을 가진다는 이야기는 없는데 제 이야기를 선입견을 가지고 보시는군요.. 즐거운 토론되시길..
개인적으로는 동의할 수 없습니다. 분명 좋으니까 쓰는 것이지요.
C++이 독보적인 존재가 되기 까지는 C, 파스칼등의 이미 선점된 언어들의
영역을 뺏어내야만 했고, 많은 객체지향 언어중에서 실제 언어의 실용성이
중요한 상업 소프트웨어 회사들에의해 선택되어 지금에 이른 것 입니다.
지금은 Java나 각종 script언어의 맹공을 받고 있지만
일부 분야(game,client app.,c++로된 os)에서는 가까운 시일안에 다른 언어로의 대체는 거의 불가능하다고 봅니다. 진짜 돈되는 분야의 프로그래밍은 거의 C/C++로 이루어지고 있구요...
영어가 제일 많이 사용 되니까 최고의 언어인지 의문이고 지구별 최고의 종족은 한족이라는 것도 의문이고 중국과 인도가 지구별 최강이란것도 의문입니다.
단지 지금 많이 사용 된다는 것 만으로 그것의 우수함을 이야기 할수는 없을거 같네요.
한글이 우수하다곤 하더군요. 알파벳 보다 한참 후에 만들어져서 좀더 과학적이라 하네요. 그럼 늦게 나온게 장땡인가? 그것도 좀 이상하네요. 여하튼 단지 지금 널리 퍼졌다는 것이 그것의 성능이 뛰어나기 때문이라는 소리는 너무 이상하게 들립니다.
지구별에서 중국 사람이 제일 많은 것과 비슷한 이치가 아닐까 싶습니다.
중국인이 우수해서가 아니라 이미 충분히 많으니까요.
가까운 시일 내에 c++의 위치를 c#이 먹지 않을까 싶은데요. 얼마전에 pda와 pc sync프로그램을 c#으로 개발 하는걸 보았는데 안정성이나 성능면에서 c++과 비교해서는 어떨지 모르지만 기존의 app보다는 훌륭했습니다.
특별한 취향상 차이일 수도 있지만, Ada가 프로그래머들이 생각하는 간단명료에 많이 뒤떨어져
있는건 사실입니다.
>> 일단 제개인적으로는 C 혹은 C++이 Ada에 비해서 특별히 간단명료하다고 느껴지지는 않네요.
>> 겉으로 드러난 간단명료와 코드의 가독성은 분명 다릅니다.
>> 부정적인 이야기하자면 님의 말씀처럼 간단명료에 많이 뒤떨어져 있다는 식으로
>> 이야기할수도 있지만 긍정적인 측면에서 보자면 뛰어난 코드의 가독성을 위해서
>> 님이 말씀하시는 그런간단명료를 능동적으로 회피했다고 볼수도 있읍니다.
>> 님도 아시다시피 Ada는 분명 가독성면에서는 뛰어난 언어입니다.
>> 실제 Ada추종자들이 다른언어와 비교할때 거의 첫번째 두번째로 내세우는 이유이기도 합니다.
>> 성격이 좀다르지만 Perl과 Python이 이런경우라고 생각합니다.
>> 님이 말씀하시는 그런 간단명료는 Perl코드가 Python보다는 분명 뛰어납니다.
>> 그리고 그런이유때문에 Perl을 좋아하는 프로그래머도 많다고 생각합니다.
>> 반대로 그런 일견 간단명료해 보이는 코드가 겹겹히 쌓여있을때 나타나는 엉터리(?) 가독성때문에
>> Python으로 도망간 프로그래머도 부지기수죠...
>> 그리고 모든프로그래머들이 가독성을 희생한 겉으로 드러난 간단명료함을 선호한다고 생각지도 않습니다.
다시 말씀드리지만, 제 경험상을 말씀드린 것입니다. 선입견을 가진다는 이야기는 없는데 제 이야기를 선입견을 가지고 보시는군요.. 즐거운 토론되시길..
뛰어난 요리사는 모든 부분에서 다 일등급의 요리는 만드는건 아니죠.
자기가 가장 자신있어야하는 요리는 몇가지 꼽을 정도라고 생각합니다.
요리에 따른 재료와 도구 및 첨가물을 얼마나 잘 이해하고 잘 사용하는
냐의 문제가 아닐까요?
프로그래머도 역시 분야와 용도에 따라 그에 맞는 언어와 툴을 잘
사용할 수 있다면 그것으로 충분하지 않을까요?
프로그래밍 언어 역시 그렇지 않을지.
PL에서 가장 중요시 하는건 가장 읽기 쉬운 것이 쓰기 쉬운것보다
우선이라고 보고 있는데 C, C++은 그런점에서 읽기 보다는 쓰기가
더 편하죠. 자연언어에 가까운 언어일수록( Ada 같은) 읽기 쉽다는..
(그렇더라도 영어를 외국어로 가진 우리에게는 여기 쉽지 않다는..)
설계 측면에서 볼땐 아무래도 적당히 자연언어에 가깝고 함축성이
있는 언어가 좋은것일거 같다는.. 그렇다면 C++이나 Java, C# 정도
가 아닐까요? 물론 어떤 목표 분야인지에 따라 틀리다고 생각됩니다.
기반 라이브러리 같은 것들이 많다면야.. 더할 나위 없죠. 장황하게
쓰기 보다는.. 적절히 상위에서 표현가능할 정도의 platform으로
지원해준다면야 더할 나위 없죠. :-)
전에 학교 도서관에서 근로할때 조교님중 한분이 빌려가시면서 "사람들이 세계 최고의 언어라고 부른다"라고 하셔서 무언가 읽어봤는데...
병렬처리용으로 최고라더군요.
그 책에도 미국방성에서 프로젝트를 위해서 만들었다고 나왔어요.
하긴... 컴퓨터 대부분이 연구나 군사 목적으로 만든것들이니...
소프트웨어 시스템 세이프티의 관점에서도 Ada를 제일 선호합니다. 이를테면 록히드 마틴이나 보잉같은 정말정말 안전한 소프트웨어를 만들어야 하는 곳에서 선호한다고 들었습니다. 물론 formal method에 의한 방법론이 더 안전하겠지요.
대신 Ada를 배우고 나서 갈 곳이 몇 개 밖에 없다는 게 문제라면 문제겠죠.
진정한 의미의 subclassing은 c++에서 지원되지 않습니다. 실행시간에 어떤 클래스에 대한 정보를 얻을 수 있나요 c++에서? 안됩니다. operator overloading은 스트럽이 말한 것 처럼 단순한 "편리한 문법"에 지나지 않습니다. 진정한 OO를 위해서는 컴파일 타임 뿐만 아니라 런 타임에서 OO가 지원이 되어야 합니다. C++는 OOP를 위한 언어하기 보담은 그 기원에서 볼 수 있듯이 그냥 더 좋은 C일 뿐입니다. 단지 OO 비슷한 문법을 지원해서 좀 더 나은 C로 사용이 가능하도록 만들었을 뿐입니다.
비록 위와 같다 하더라도 C++는 나쁜 언어니 쓰지 말아야 된다는 당연히 아닙니다. 그러나 OOP에 목적으로 둔다면 C++는 아니라는 거죠. C++의 OO적 문법이 상대적으로 복잡한 이유는 실제 그 언어 자체가 OO를 완전히 지원하지 않기 때문입니다.
그리고 C++로 Collection을 만들때와 Smalltalk, Java 같은 것으로 만들때와의 경우를 비교해 보세요. 다들 일장일단이 있지만 자료구조와 같은 것에 있어서는 C++는 별로 입니다.
또한 NeXTSTEP의 기술을 C++를 이용해서 구현을 하려한다는 것을 상상해 보세요. 거의 불가능에 가깝습니다. MacOSX가 IOKit과 같은 드라이버 레이어를 C++로 바꾼 것은 Objective-C가 안 좋아서가 아니라 Device Driver와 같은 부분은 C/C++만으로 해도 크게 어려움이 없어서 입니다. 물론 유인책의 성격도 있습니다.
빠른 속도가 필요한 부분에 Java나 Smalltalk을 이용해서 작업을 하는 것도 미친 짓이지만 OO가 필요한 부분에 C++를 써서 고생을 하는 것도 마찬가지 입니다.
Pascal
PL시간에 조금 들은 바로는 파스칼을 많이 꼽는 것 같더라구요..
C보다 여러면에서 철저하고..
(변수선언, assign과 equal 의 엄격한 구분 등등)
함수가 nested된 구조로 만들어 질 수 있고.. 뭐 여러가지로 C보다는 훨씬 고급의 언어라고 알고 있습니다..
사실 C는 참 너무 간단하게 구현된 언어이죠..
PL 시간에 배우는 이론들이 거의 적용되지 않는 언어가 바로 C입니다..-_-;
Pascal은...
Pascal은 목적이 교육용이라서 그런지 몰라도 과도하게 딱딱합니다.
type checking만 해도 그냥 강하다기보다는 고지식하져...
설계적 측면에서 볼때는 설계패러다임에 가장 잘 맞는 언어가 설계에
강한 언어가 아닐까요?
구조적 설계라면 C도 좋을테고...
객체지향적으로 설계했으면 객체지향언어들...Smalltalk, C++, Java...
함수적이라면...Haskell, Lisp... SQL도 있죠...
경우에 따라서 정말 단순한 일을 하는 내장형 프로그램이라면
어셈블러가 더 편할수도...
어쨋든 설계를 어떤 방식으로 했냐에 따라서...또 여러가지에 따라서
달라질 수 있는...얘기같다는...
가장 훌륭한 이라는 것은 별 의미가 없는것같습니다...
There is more than one way to do it...
Pascal이...
함수가 네스팅 되는게 마구 함수명을 입력하는 저에겐 좋은것 같더군요... 파스칼을 배우는 용도로 써서 오래 쓰지 못하고 다시 C를 사용하는데... C에서 가끔 임시로 쓰는 함수 이름을 겹치게 해서 에러가 날 땐 파스칼이 좋던데... 라는 생각이 들기도 합니다.
Asche Zu Asche
구조적 언어로 C를 꼽기는 좀 어렵지 않을까 싶네요.C는 low le
구조적 언어로 C를 꼽기는 좀 어렵지 않을까 싶네요.
C는 low level programming을 위해 나온 언어니까요.
앞 분이 예를 드신 Pascal이 오히려 꼽기엔 더 나은 편이죠.
C는 low level programming이라는 면에서 첫째로 꼽을만하지만,
C++는 좋은 언어는 아닌 것 같습니다.
체계적으로 발전했다기보다는 이런 저런 기능들이 마구잡이로 추가됐죠.
프로그래머의 편의라는 면에서는 못할게 없으니 좋긴 하지만,
잘 설계되었다고 보긴 어렵고요.
그래서 Java나 C#의 경우 언뜻 보기에 C/C++과 유사해보이지만,
실상은 Object Pascal과 더 비슷하게 개발되었죠, 특히 OO면에서.
( 뭐, Delphi 개발자가 C#을 설계했다는 점도 한몫 하고 있긴 하지만요. )
Ada도 Pascal을 기반으로 발전한 언어고요.
사용해보진 않았지만, 괜찮다고들 .. -_-a
( 역시 많이 쓰이지 않는다는게 문제겠죠. )
어떤 사람들은 가장 잘 설계된 언어로 단연 Ada를 꼽더군요.
아, 그리고 컴파일러 제작이라는 측면에서
대개는 체계적으로 구성된 언어들이 파싱이 편한 관계로
컴파일 속도가 빠른 편이죠.
( 뭐, 지원해주는게 많아서 느린 경우도 있겠지만요. )
이런 점에서 Object Pascal이 정말 괜찮은 언어가 아닌가 하는 생각을. -_-;
( 컴파일이 C++ 보다 수십배는 빠르잖을까 하는 생각이 듭니다. -_-; )
뭐, 결국은 C++, Java를 쓰게 되긴 하지만요. -_-
이상 잡담이었습니다.
ada
Ada는 미 국방성에서 만든언어라서 그런지 모르겠지만.. 뭐 하나 하려고 하면 "오~ 제발~ 제발 이것좀 하게 해주세요"라고 간청하는 느낌을 받는 언어같습니다. 주제와 약간 벗어나지만 Ada얘기가 나와서리~ :!:
음...
설계의 측면에서 C는 결코 잘 만들어진 언어라고 볼 수 없습니다. 여기 글 쓰신 분들도 다 그렇게 생각하시는 것 같지만...
하지만 C는 컴파일러 이론이 생기기도 전에 만들어진 언어란 점은 주목하셔야 될 듯합니다. 컴파일러 이론이 생기기 전이었으니 문법 파싱에 대한 툴이나 이론도 전무했던 시점에서 만들어진 언어인건데, 이건 정말 대단한거죠.
쓰기 불편했든 어쨌든 그래도 UNIX OS를 만들 수 있을 정도의 언어니까요. ^^;
문법 문제를 떠나 위엣 분이 쓰신대로 로우 레벨을 위한 설계라 한다면 C도 잘 만들어진 언어라 할 수 있을겁니다. 막강한(그러나 복잡한) 포인터가 있으니까요.
저에게 언어 하나를 꼽아보란다면, 접해본 언어가 많지 않아서 곤란하긴 하지만 그래도 최근에 나온 언어인 파이썬이 무척 잘 만들어져 있지 않나 생각합니다. 일단 문법 설계도 깔끔하거니와 statement를 라인으로 구분하고 블럭은 탭 갯수로 구분하게 되어있기 때문에 서로 다른 사람이 짜더라도 코딩 컨벤션은 유사해지니까요.
자유스러운 코딩이 가능하면서도 잘 짜여진 신택스를 갖고 있다는 점에서 전 파이썬이 맘에 듭니다.
하지만 말했다시피 제가 접해본 언어가 많지 못하기도 하거니와 언어는 '도구'니까요, 어떤 언어가 '가장' 좋다고 말하는건 역시 어불성설이겠죠.
노루가 사냥꾼의 손에서 벗어나는 것 같이, 새가 그물치는 자의 손에서 벗어나는 것 같이 스스로 구원하라 -잠언 6:5
...
MasterQ님 Ada는 미국방성에서 만든언어가 아닙니다...
Re: 음...
C 언어에서 block 구조가 엉망이라는 건 용서가 안 됩니다. pascal이나 algol의 begin/end 쌍의 우아함이 C 언어의 {}에는 없습니다. :( 그 단점을 C++도 이어받았고요. 그리고 파싱 이론이 없었다뇨? BNF는 C 언어보다 10년 이상 빠른 ALGOL에서 이미 쓰였습니다.
Re: ...
아! 물론 The US Department of Defence가 '직접' 만든 언어는 아니지만 Ada를 개발하게 된 프로젝트를 시작했죠. 그래서 사람들이 보통 미국방성에 Ada를 개발했다고 하죠..(자바는 우리가 썬에서 개발했다구 하지요?) 미 국방성이 임베디드시스템개발을 위한 적당한 언어를 찾게 된것이 원인이 되었다구 하네요....
틀리다면 고쳐주세요~ ^- ^
8)
...
Ada83은 미국방성이 시스템프로그래밍, 리얼타임, 임베디드시스템등의
목적에 맞는 언어를 찾기위해서 콘테스트를 개최한것이 계기가
되어 탄생했읍니다. 실제 Ada83은 프랑스에 있는 CII-HB( Honeywell-Bull)라는 곳에서 만든걸로 알고있읍니다.
begin~~end가 {~~} 보다 좋다는 근거가 궁금합니다저도
begin~~end가 {~~} 보다 좋다는 근거가 궁금합니다
저도 Pascal, C/C++ 두가지 다 어느정도 코딩해봤지만
글자수도 다른 영어단어 두 개보다는 딱 그림만으로도 시작과 끝을 나타낸다는 것을 유추하기 쉬운 기호문자가 더 보기 좋은 것 같은데요??
Ada, C++
Code Complete 에서는
라는 구절이 있더군요.
마침 요즘 goto가 갑자기 화제인지라... ^^
Ada는 구경도 못했는지라 실제로는 어떤지 전혀 모릅니다. ^^;;
C++의 설계에대해서는
"The Design and Evolution of C++"
를 읽어본 후에 이야기하는 게 좋을 듯하네요. Stroustrup 씨도 따로 이런 책도 쓰고... The REAL interview 도 따로 만들어야될 만큼 이런저런 말에 휩싸이는 것이 좀 불쌍하군요. ^^;
사실 C++의 지독한 팬인지라.... C++ 이야기가 나오길래 한번 써봅니다.
이런저런 C++에대한 비판적인 의견은 어디서나 너무 많아서 좀 민감해져서요... ^^;;; C++은 워낙 스스로 자치하는 위치와 실력에비해 이런저런 말이 많아서 말이죠. 보통 그런 것들은 표준도 만들어지기 이전의 불완전한 언어를 조금 만지작 거리다 하는 이야기일 경우가 많은데 말입니다. C++팬들이 이런곳의 논쟁에 자주 참여하지 않아서 한쪽의 잘못된 이야기가 일반화되는 경우가 많은 것 같기도 하구요.
솔직히 말해서는 오브젝트파스칼의 컴파일 속도와 그 문법(똑같은 것을 C++로 쓰면 좀 지저분해 보이지요)에는 저도 참 감탄합니다만, 표준도 아니고 볼랜드툴에서만 쓰이는 것이니 좀 논외가 아닐지요. 그리고 사실 개인적으로는 오브젝트 파스칼은 C++에 비해 재미가 없구요. 로우레벨까지 내려가기가 힘들더군요. ^^;;; 이런 말 하는 것도 프로그램 몇개 대충 짜보고 하는 말이라 아까 이야기한 섯불리 언어에대해 논하지 말자는 저의 주장에 어긋나기는 하는군요. ^^;
그리고 설계에대해서 이야기하자면, 무엇에 중점을 둔 설계인지도 거론이 되어야할 것 같구요. 대략 저의 짧은 소견으로는 현재 각 분야에 쓰이는 언어들은 다들 스스로의 용도에 맞게 잘 설계된 것 같다고 생각하구요.... 사실 무식해서 어려운 이론은 잘 모릅니다만... 아무튼 이런 비교하거나 무엇이 최고다하는 이야기는 각각의 대상의 팬들이 싸우기 쉬워서 좋지 않다고 생각합니다. 사실 읽는 입장에서는 매우 재미있는 것이 이런 쓰레드이기는 하지만 말입니다. ^^;
오브젝트 파스칼이 왜 로우레벨로 내려가기 힘들죠?
http://delphine.sourceforge.net/
제가 소스를 자세히 보지는 못했습니다만 로우레벨에 오브젝트 파스칼이 로우레벨에 접근하기 힘든 언어같아 보이지는 않았습니다.
Re: 오브젝트 파스칼이 왜 로우레벨로 내려가기 힘들죠?
ㅠㅜ 불어인가요?
C는 강력하지만 설계에선 파스칼이 낫다고 생각합니다.
파스칼은 원래 구조적인 프로그래밍을 가장 구조적이게 만드는게 목적이었다고 하더군요. 그래서인지 파스칼을 쓰다보면 좀 짜증나기도 하지만, 오히려 C보다는 구조적 프로그래밍의 로직이나 여러가지 프로그래밍의 기본기를 다지는데 도움이 많이 될것 같습니다. :roll:
========================================
* The truth will set you free.
지나가다...
개인적 취향이 아니신가 싶네요..
암튼 전 자바라는 언어가 문법 구조상으로는 꽤 괜찮은 언어인듯 싶습니다.
----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com
사실 C는 고급언어라고 보기엔 ..다소 무리가 있지 않나 싶네요 ..
사실 C는 고급언어라고 보기엔 ..
다소 무리가 있지 않나 싶네요 .. -_-;
전 분류하라고 한다면 Low-level 쪽에 놓고 싶은데요 ..
어셈블리어를 좀 간소화한 정도가 아닐지 .. -_-a
구조적으로 쓰는 사람들에겐 구조적인 언어겠지만 ..
구조적인걸 염두에 두고 만들어진 언어는 아닌것 같네요 ..
여튼 그래서 .. C++가 C보다 아주아주 고급이라는건 너무나 당연하다는 .. ;;
음, C++는 개인적으로 제일 마음에 안드는 요소가 .. OO 던데요 ..
웬만해서 다중상속 쓰는 사람이 있나요 .. -_-;
Object Pascal에서 Java, C# 쪽으로 이어진 interface 개념이 ..
개인적으로 훨씬 편하고 나은 개념이라고 생각해서요 ..
( 물론 다중상속을 이용해서 interface를 구현하는건 가능하겠죠 .. )
다중상속이 컴파일러에 부담도 크다고 알고 있는데 .. -_-;
( 사실 제일 마음에 안드는 요소는 컴파일 시간인듯도 .. -_-;; )
좀 맘에 드는건, Template이 그래도 폼이 나는것 같아서 좋다 싶긴 한데 ..
OO의 상속으로 어느 정도 구현이 가능해서 ..
( Java의 Class Library들을 보면 .. -_-a )
어느 언어든간에 뭔가 다른 구현이 나와주면 좋겠다 싶네요 ..
STL 같은거 너무 무거운-_- 느낌이던데 ..
( C++와 Java의 벤치마크에서 C++ 코드에 STL 류가 들어가면 .. )
( C++도 Java 만만치 않게 느리더군요 .. -_- )
그리고 C++에서 Low-level로 내려갈수는 있지만 ..
그냥 C로서 접근하는게 아닌지요 .. ;;
C++에선 Low-level의 접근은 지양하고 있지 않은지 .. ;;
( Object Pascal도 Low-level 접근이 가능합니다 .. 잘 안하죠 .. ;; )
여튼 .. Java나 C#이 ..
최근에 만들어진 언어이니만큼 ..
구조적으론 제일 괜찮다 싶다는 .. -_-a
( 메모리 Free 안해도 되는게 너무 편하기도 하고요 -_-; .. 흐 ;; )
( 그래도 마음은 Object Pascal에 .. -_-; 요즘은 깔지도 않지만요 흑 .. ;; )
p.s.
아참 제가 Java를 공부하면서 ..
제일 감동했던건 ..
다중 루프를 빠져나가는 break, continue 였던것 같네요 ..
goto의 마지막 용도마저 사라지게 해준 .. ㅠ_ㅠ
개인적으로 현재의 C++의 efficiency를 거의 잃지 않고서
개인적으로 현재의 C++의 efficiency를 거의 잃지 않고서
C와의 호환성 등을 위한 지저분한 구석을 제거하고,
문법도 깔끔하게 정리하고,
Thread에 대비한 라이브러리 등 다양한 라이브러리들 제공하고,
기존의 C++코드도 쉽게 연결해서 사용할 수 있는
OS를 만들더라도 성능에 지장이 없는 새로운 언어가 나왔으면 좋겠습니다.
예전에 D언어라고 비슷한 맥락의 언어얘기가 있던 거 같은데 어찌되었나;;
오늘도 부족한 C++옹호자로써의 자세를 다하기 위해서 글을 씁니다. ^
오늘도 부족한 C++옹호자로써의 자세를 다하기 위해서 글을 씁니다. ^^;
적당히만 자제하면서(-_-;) 쓰면 다중상속이 얼마나 편리한데요. 저는 애용합니다. 다중상속의 멋짐은 The C++ Lang. 예제코드등 여러 고수들의 코드를 참조해보세요 ^^;
컴파일시간은 특별히 GUI쪽 코드가 아닌 서버측 코드에서는 크게 문제가 안된다고 봅니다. GUI쪽 코드도 볼랜드터보파스칼 컴파일러가 너무 빨라서 느려보이는 것이지... ^^;;
어떤 일을 할 때는 Template이나 OO둘다로 가능할 경우가 있는데, 이부분에대해서는 저도 어느 것이 더 나은지 좀 더 조사가 필요할 것 같습니다. 개인적으로는 타이핑이 좀 더 적은 template을 선호하지만 흠....
이런... 언제적 이야기인지 어떤 벤치마크인지는 모르겠지만 -_-; STL의 속도는 어셈을 쓴 machine-dependent code가 아닌 C의 속도와 거의 같거나 더 빠릅니다... 스트림을 다량으로 사용해서 그런 일이 벌어졌을 수 도 있는데, IO에 c api를 사용하면, STL 구현이 좋지않기로 유명한 MS VC++6.0 를 써도 그렇습니다. (이론상으로는 런타임에 형을 결정하는 printf계열보다 stream이 더 빠른데 실제로는 좀 느리죠 -_-; 흠 하지만 어떤 컴파일러는 c api IO보다 더 빠른 것도 있다고는 합니다. 스트럽씨가 말하길 -_-;)
여담으로 예전에 알고리즘 수업에서 2차,3차,64차원의 고정된 영역안의 10만개 점 각각의 가장 가까운 점을 찾는 코드를 작성한 적이 있었는데, 속도별로 점수를 주는 수업이라 C로 나름대로 최적의 최적화를 해서 짰던 경험이 있습니다. 2차는 이렇게 하다가 3차 이상이 되면서 너무 C코드가 지저분해 지길래 한번 STL을 도입해서 사용해 보았죠. 제가 짠 C코드랑 ms단위로 똑같은 속도가 나오더군요. (무려 표준전에 나온 VC++6.0으로 짰습니다.)
아 그냥 MMORPG 서버 플밍할때 STL을 쓰는 회사가 엄청 많다는 것이면 더 이상 이야기할 필요가 없군요.
C++을 만들 때의 목표중에 하나가 C를 대체하는 system programming 언어였고, 지금도 그 목표는 유효합니다. ^^; 스트럽씨는 system programmer들이 c++을 안쓴다고 불평이 대단하지요. "늙은 개에게 새로운 트릭을 가르키는 것은 힘들다" 라는 말까지 할 정도입니다. ^^;
Java나 C#은 언어구조적으로는 80년대 OOP 일 뿐입니다. C++은 ML등을 참고한 generic programming과 더 많은 OOP지원이 있습니다. (라고 스르럽씨가 말하더군요 ^^) 이런 것은 JAVA가 최근에 GJ어쩌구 하면서 C++의 개념을 도입하려는 시도를 보면 알 수 있습니다.
break, continue는 C에도 있습니다만... goto에 대한 이야기는 no-smok.net 쪽 사람들이 이번호 마소에 기재하면서 최근 화제인데요. 마소최근호와 Code Complete의 goto관련 내용을 읽어보시면 좋을 것 같습니다. 저는 goto옹호론자 이기도 합니다. ^^;;;
스트럽씨가 2004년으로 기획하시고 있는 C++ 다음 버전에는 thread지원이 포함됩니다. 표준 gui 라이브러리도 생각하시고 있는 것 같구요. 스트럽씨는 C++의 지금 문법에서 쓸데없는 곳은 전혀 없으며, 바꿀 곳도 거의 없다고 생각하시는 것 같습니다. C++로 OS를 만들면 성능에 지장이 있다는 것은 오래된 편견입니다. WindowsXP 2000등등은 무슨 언어로 만들어져있다고 생각하시는지요...
C++로 만들어진 OS관련 리스트입니다. (덤도 있고 ^^)
Apple: OS X is written in a mix of language, but a few important parts are C++. The two most interesting are
Finder
IOKit device drivers. (IOKit is the only place where we use C++ in the kernel, though.)
Also,
AppleWorks
the iPod user interface (uses Pixo application framework written in C++)
"Of the thousands of Macintosh applications that have shipped I estimate that over half were written C++".
Frameworks: There are three major C++ application frame works developed for Macintosh: Apple's MacApp (some MacApp applications), Symantec's Think Class Libraries, and Metrowerks' PowerPlant. There are also a number of smaller (in market share) frameworks that have been developed.
IBM: OS/400.
Microsoft: Literally everything at Microsoft is built using various flavors of Visual C++ - mostly 6.0 and 7.0 but we do have a few holdouts still using 5.0 :-( and some products like Windows XP use more recent builds of the compiler. The list would include major products like:
Windows XP
Windows NT (NT4 and 2000)
Windows 9x (95, 98, Me)
Microsoft Office (Word, Excel, Access, PowerPoint, Outlook)
Internet Explorer (including Outlook Express)
Visual Studio (Visual C++, Visual Basic, Visual FoxPro) (Some parts of Visual Studio like the Base Class Libraries that ship with the .NET Framework were written using C# but the C# compiler itself is written in C++.)
Exchange
SQL
There are also "minor" products like:
FrontPage
Money
Picture It
Project
and all the games.
Sun:
The HotSpot Java Virtual Machine is written in C++ (this is the leading edge, high performance replacement for Sun's "classic JVM" which was written in C).
Sun's compilers have major components written in C++, in particular the C++ front end, parts of the Fortran 95 front end, and the SPARC back end.
Parts of Solaris are written in C++, though the external interface is usually crafted to look like C, for compatibility and stability reasons.
에... 저도 간만에 이목록을 보니 이때까지 한말들이 그냥 필요가 없어지는 군요... -_-; 더 주절 거릴 랬는데 역시 C++로 플밍이나 하러 가야겠습니다. -_-;
high performance replacement for Sun's "classic JVM" which was written in C
허허... 이제보니 c로짠 JVM보다 빠르게하기위해 c++로 새로 JVM을 짠 것이 java책에서 그렇게 자랑하는 HotSpot JVM 이었군요. 이제봤음 ^^;
출처와 더 자세한 내용은 다음 페이지를 참고하세요.
http://www.research.att.com/~bs/applications.html
Ada..
Ada 이야기가 잠시 나오는 것 같아 경험상 써 봤던 Ada 이야기를 잠시 하겠습니다. Ada는 세계 최초의 여성 프로그래머에서 이름을 따 왔는것으로 알고 있습니다. 미 국방성이 Ada를 채택한 이유는 언어상에서의 ambiguity, 모호함을 최대한 줄인 언어이기 때문입니다. 즉, 괄호 만으로 간단히 이루어질 수 있었던 다른 언어들에 비해 Ada는 이를 비롯하 애매한 것들을 모두 없앴죠.
아마 코드를 보시면 이건 영어인지, 컴퓨터 언어인지 착각을 불러일으킬 정도로 영어 단어들을 그대로 옮겨둔것 같을 것입니다. 물론 영어권에서는 이게 편할 수도 있겠지만, 같이 Ada를 썼던 영국 동료들 또한 '이게 영어지. 컴퓨터언어냐'하는 식이었습니다. :)
역사적으로 Ada83은 더이상 잘 안 쓰는 것으로 알고 있으며 최근에는 Ada95를 기준입니다. 미국방성에서 만들었다는 이야기가 나오듯이, 항공기 제어에 쓰이고 있는 것으로 알고 있으며, 제가 알기론 Boeing 777에 사용되었는 것으로 알고 있습니다. (제 기억으로 확실치 않지만, 컴파일 때인지 런타임상인지 몰라도 코드를 재확인하는 작업이 들어가는 것과 같은 정확도를 기하는 작업을 하는것으로 알고 있습니다.)
현재 컴퓨터 과학적인 측면에서 미국보다는 유럽에서 인기가 더 많은 것으로 알고 있으며, 위에서 말한 항공기의 예처럼 리얼타임 쪽에서 인기를 끌고 있습니다.
마지막으로 한마디는.. 저희학교 학부생들은 Ada 무지 싫어합니다. ;) - 머 다 싫어하지만..
--
개인적으로 경험상, 그리고 들은 것을 바탕으로 올렸습니다. 웬만하면 확인작업을 하고 글을 올리는 성격인데, 최근에 글쓰는데 별로 신경을 안 쓰는 관계로 양해를 부탁드립니다 :) - 그렇다고 그짓말을 쓴거 아닙니다. ^^ 제가 잘못 알고 있었던 점은 지적해주세요 :)
[quote="skjk"]begin~~end가 {~~} 보다 좋다는 근거
begin/end 쌍은 statement가 되지만, {} 쌍은 statement가 아닙니다.
이런 상황은 C언어에서 macro 등을 만들 때에도 신경을 쓰이게 만듭니다.
[quote="asheep"]break, continue는 C에도 있
JAVA에서 제공하는 break, continue는 C/C++의 그것과 같은 기능외에 label을 지정해서 여러 레벨을 뛰어넘게 할 수 있으므로 기존 goto를 정말로 거의 필요없게 해줍니다.
C++로 OS를 만들면 성능에 지장이 있다는 의미가 아니라 기존의 C++의 efficiency를 거의 잃지 않으면서(즉 OS를 만드는데도 지장이 없으면서) 대체할만한 언어가 나오면 어떨까 하는 생각이었습니다 ^^;
그리고 Stroustrup라도 만약 기존의 호환성문제를 생각하지 않고서 완전히 새로운 언어(기존 C++과 비슷한 성능을 보장하는)를 만들게 된다면 상당부분 수정하게 되지 않을 까 생각합니다.
statement라는 게 구체적으로 어떨 때 유용한지 잘 모르겠네요 ^^; #define을 쓰는 macro는 C++에서는 보통 inline함수로 대체하게 됩니다.
그외에 또 어떤 예가 있을까요?
[quote]적당히만 자제하면서(-_- 쓰면 다중상속이 얼마나 편리한
object-pascal, java, c#에서도 다중상속이 아주 불가능한 것이 아니죠 ..
단지 '절제된 다중상속'을 interface라는 새로운 개념으로 해결한거구요 ..
C++에서도 다중상속은 대부분 저정도로밖엔 쓰이지 않는 것 같던데요 ..
그러지 않으면 너무 번잡해지지 않는지 .. -_-;
C++보다 Java가 빠르단 얘길 하려던게 아니구요 ..
C++가 Java나 C#에 대해 속도면에서 메리트가 별로 없단 얘기였습니다 ;;..
사실 Java가 별로 느리지 않다고 해야 할수도 있겠죠 ..
짧은 프로그램이라면 Java가 당연히 느리겠지만 ..
대규모 프로그램에선 JIT 때문에 속도차가 별로 나질 않습니다 ..
오히려 Java가 Run-time Optimization을 해서 ..
Compile-time Optimization을 하는 C/C++보다 빠른 경우도 ..
적지 않다고 하네요 ..
이젠 C++ with STL이 속도면에서 메리트가 떨어지고 있는걸로 압니다 ..
( J2EE가 많이 쓰이고 있는걸 봐도 알수 있죠 .. )
80년대 OOP라고 해도 C++보다는 이후에 나왔죠 .. -_-;
더 많은 OOP의 지원이라는 건 다중상속말고 없지 않나요 .. ;;
Template을 사용한 Generic Programming은 편리하긴 하죠 .. 음,
( 이미 이에 대해선 기술한것 같은데 .. -_-; )
Java나 C#정도의 OO에 Template이 가미되는것도 괜찮을듯요 ..
느려지지만 않는다면 .. -_-;
( 그리고 Generic Programming이 C++의 것만은 아니죠 .. -_-a )
C나 Object-Pascal에 있는 break, continue보다 ..
Java에 있는 쪽이 더 진보한 break, continue입니다 ..
기존 break, continue의 경우 다중 루프는 빠져나갈 길이 없었죠 ..
오로지 goto밖에 .. -_-;
goto가 structured programming때부터 지양된 건 ..
나름대로 이유가 있다고 생각하는데요 .. ;;
goto 없이도 충분히 모든 코드가 작성 가능한데 ..
( 다중 루프 빠져나오는 것만 빼고요 .. -_-; 가능하긴한데 효율이 너무 ;; )
( Java에선 그게 해결된거죠 .. )
굳이 goto로 쓰여진 코드로 분석하고 디버깅하고 하려면 ..
정말 피곤하단 생각이 -_-; .. 들더라고요 ..
이리 뛰고 저리 뛰고 .. -_- 분석 흐름을 팍팍 끊어놓는 .. ;;
뭐, Java로 만들수는 없었겠죠 .. ^^
개인적으로는 C++가 .. 나쁜 언어라기보다는 ..
적당히 다이어트를 좀 해줬으면 좋겠단 생각이 듭니다 ..
( 그래서 나온게 Java, C#이겠죠 .. 생산성 문제에서 나오기도 했겠지만 .. )
스트럽씨는 자기 언어에 자부심이 너무 큰게 아닌가 생각을 .. ;;
그리고 C++가 많이 쓰이는 게 ..
새로운 더 나은 언어의 발전을 막는다는 생각도 들고요 ..
C++가 전 분야에 걸쳐 많이 쓰이는 이유는 ..
C++가 설계가 잘 된 언어라기보다 ..
독보적으로 존재하는 동안 만들어진 코드가 아무래도 많다는 점이 ..
가장 크지 않나 생각해봅니다 .. ;;
뭘좀 찾아볼래도 C++로 된 자료가 대부분이니까요 .. ;;
그래서 .. 저도 C++를 쓸수밖에 없더라는 .. -_-;
begin end, { }
begin~end, { } 둘 다 군더더기라고 보면 딱 맞을 것 같습니다.
Code Complete에 보면 배치를 할 때 if 와 같은 line에 {나 begin을 두어야 하느냐 밑의 줄에 두느냐 가지고 복잡하게 설명을 합니다.
또 보통의 경우에는 if, while 등에 { }나 begin, end를 나중에 대비해서 항상 둘 것인가 1줄만 있을때는 뺄 것인가.. 착각하지 않기 위해 항상 둘 것인가 등등을 고민해야 합니다.
해결방법은 Pascal의 제작자인 N.Wirth가 만든 언어인 Modula(70년대 말), Oberon(80년대 말)에서 해결되고 최근에 나온 Ruby 같은 언어에서도 사용되는 방식입니다.
if 조건문 then
...
elsif
...
else
...
end
로 합니다. 이러면 begin이나 {이 아예 없기 때문에 어디에 둘 것인지 고민할 필요도 없고, 1줄만 있는 경우에 begin~end, { }를 둘 것인가 말 것인가도 고민할 필요가 없습니다.
Re : Ada..
아마 코드를 보시면 이건 영어인지, 컴퓨터 언어인지 착각을 불러일으킬 정도로 영어 단어들을 그대로 옮겨둔것 같을 것입니다. 물론 영어권에서는 이게 편할 수도 있겠지만,
같이 Ada를 썼던 영국 동료들 또한 '이게 영어지. 컴퓨터언어냐'하는 식이었습니다
>> 그건 개인적인 취향같군요... 또 앞뒤의 문제일수도 적응의 문제일수도 있읍니다.
>> Ada를 첫언어로 배우고 C나 C++ 혹은 Perl코드를보면 어떻게 느낄까요...
>> http://www.cs.fit.edu/~ryan/ada/programs/
>> 관심있는 분이라면 한번보시길...
마지막으로 한마디는.. 저희학교 학부생들은 Ada 무지 싫어합니다.
>> 싫다는데 별로 할말이 없군요...
>> 근데 왜싫다는건지... 무작정 싫다는건지...^^;
>> 저는 C,C++, 특히 Pascal 을 알고있는 분이라면 혼자서도 충분히 능히
>> 배울수 있는 쉽고도 깔끔한 꽤 괜찮은 언어라고 생각합니다.
>> 그리고 많은 사람들이 좋아할수 있는
>> 언어라고 생각합니다. 쓸데없는 선입견만 작용하지 않으면 말이죠...
[quote]object-pascal, java, c#에서도 다중상속이
interface는 단지 다중상속의 subset에 불과하지 않습니까?. public 상속, protected 상속, private 상속 각각이 적절한 용도가 있고... java의 인터페이스는 C++의 다중상속이 행하는 100의 기능 중에서, 약간의 다양성과 복잡성을 싫어하는 일부의 프로그래머들을 위해 기본적인 70의 기능만을 합니다. 70만으로도 충분하지만, 가끔 100의 확장성을 바라는 사람들을 만족시키지 못하는 것이 자바입니다.
자바에 관한 이야기중에 실제 현업에서 일하는 프로그래머 입장에서 너무 현실과 동떨어진 이야기라고 생각하는 것이 이부분입니다. 대규모 프로그램의 정의를 엔터프라이즈 환경에서 사용하는 어플리케이션이라고 생각하시는 것 같은데, 이부분에 대해서는 경험이 없어서 머라고 말할 수가 없습니다. 하지만, 일반적인 프로그래머가 접하는 환경에서 JAVA로 짠 프로그램은 너무도 느립니다. 클라이언트 쪽은 더이상 언급할 필요가 없다고 생각하구요. 서버측 프로그램으로도 속도가 필요한 작업에서는 C++에 비해 손실이 크더군요. 개발기간이나 규모에서 진정 대규모라 불릴말한 게임이라던지 네트워크응용 어플리케이션 개발에서는 JAVA로는 불가능 하던지, C++에 비해서 장비에대한 투자가 더 필요하다고 생각합니다.
더 최근에 나온 것이 더 좋다는 의견에는 동의할 수 없지만, 굳이 발표시기를 본다면, 수많은 토론끝에 C++의 표준이 제정된 것은 1998년이고, 자바의 발표 1995년 으로 알고 있습니다. 지금 누구도 K&R C를 가지고 C이야기를 하지 않고 C89 이야기를 하는 것처럼, 비교를 하자면 C++98로 해야할 겁니다. Java는 이후에 여러버전이 추가됐지만, 굳이 언어자체의 기능추가로 보이는 것은 특별히 보이지 않습니다.
으음 제가 GP가 C++에만 있다고 한 적은 없는 것 같군요. ML등의 언어에서 도입했다고는 이야기 한 것 같은데, 굳이 C++ 독자적인 것이라면, 템플릿에서 파생된 템플릿 메타 프로그래밍입니다. kldp에서도 논의된 외 수치계산 프로그래밍에서는 fotran을 아직 사용하느냐? 에 관련이 있는데, 수치계산 용으로 무지 빠릅니다. 게임 프로그래밍에도 응용하려는 연구가 활발 합니다. 이렇듯 C++을 공부하고 연구하면 새로운 영역이 다시 발견되는 점이 정말 매력적입니다.
아 Java를 배울때, 그냥 goto가 이름이 바뀌고 다른 모든 기능처럼 기능이 제한 당했군... 이라고 생각하면서 넘어가서 착각을 해버렸군요. 별로 멋지다는 생각이 전혀 들지 않는 기능이라 -_-;; 으음 당연히 왔다갔다 goto는 좋지 않지요. 이부분에대해서 쓰자면 길어지니까, 마소이번호goto관련기사와 code complete의 goto에관한 부분을 좀 참고해주세요...
스트럽씨가 지겹게 말하는 부분입니다. C++의 광대함은 general perpose language 이기 때문이라구요. specific 한 곳에서만 사용될 수 있는 언어가 아닙니다. general 좋냐 specific이 좋냐 라는 부분에 대해서는 논란이 있지만, 저는 왠만하면 general이 좋습니다. 더 많은 곳에, 더 다양하게, 연구하면 할 수록 개선되는 그런 점이 마음에 듭니다. 그리고 C++의 기능이 많다고 해서 그것을 꼭 다 사용할 필요는 전혀 없습니다만, 많은 사람들이 이유없이 C++의 모든 기능을 100% 익힌 다음에 그것들을 한번에 모조리 사용하려고 해서 더 상황을 악화시키는 것은 좀 문제죠.
생산성 문제는 초기에 C++이 제공하는 라이브러리가 너무 없었다는 점에서 나왔구요. (스트럽씨도 후회하는 것중에 하나지요. 표준이전에 너무 라이브러리 제공을 못했다는 점이...) C++ 라이브러리 제공만 많이하면 생산성은 자바랑 비교해도 전혀 밀리지 않죠. C++Builder를 한번 사용해보시면 이해가 될텐데요. 델파이의 생산성의 95%정도는 보여준 다고 생각합니다.
다음 가장 최신의 자료는 아니고, 상용도 아니고, 왠 후진 오픈 컴파일러(농담^^)인 g++의 옛날 버전2.7.2을 사용하고 왠지 미심쩍기는 하지만 그래도 submission to IEEE니 한번쯤은 읽어볼만 합니다.
http://www.ipd.uka.de/~prechelt/Biblio/jccpprt_computer2000.pdf
개인적으로는 동의할 수 없습니다. 분명 좋으니까 쓰는 것이지요.
C++이 독보적인 존재가 되기 까지는 C, 파스칼등의 이미 선점된 언어들의
영역을 뺏어내야만 했고, 많은 객체지향 언어중에서 실제 언어의 실용성이
중요한 상업 소프트웨어 회사들에의해 선택되어 지금에 이른 것 입니다.
지금은 Java나 각종 script언어의 맹공을 받고 있지만
일부 분야(game,client app.,c++로된 os)에서는 가까운 시일안에 다른 언어로의 대체는 거의 불가능하다고 봅니다. 진짜 돈되는 분야의 프로그래밍은 거의 C/C++로 이루어지고 있구요... 차츰차츰 C의 영역도 조금씩 더 차지하리라고 봅니다. (순전히 개인적인 예상+기대입니다. ^^)
Re: begin end, { }
sh에서 쓰이는 if/fi, case/esac 쌍이 더 예쁩니다. :)
Re: begin end, { }
그 두개만 보면 그렇겠지만..
sh에서는 loop만 do, done으로 하는 일관적이지 않는 방식을 가지고 있네요.
while/elihw, for/rof, foreach/hcaerof 로 해야 일관성이 있는데..
다 외우기 어려우니.. :) 그냥 end로 하는게 결국 나을 것 같습니다.
Re: Re : Ada..
물론 개인적인 취향이라고 할 수 있습니다. 단, 많은 경험자들이 생각하는 바를 적은 것입니다. 적어도 제 주변에는 수십명 이상의 Ada 사용자들이 있으니까요.
저는 첫언어를 Scheme과 Ada로 배웠습니다. 특별한 취향상 차이일 수도 있지만, Ada가 프로그래머들이 생각하는 간단명료에 많이 뒤떨어져 있는건 사실입니다. 그리고 이미 인터넷 세상에 살고 있는 프로그래머들에게 특수한 환경에서 쓰이는 언어는 인기도에서 떨어지는 것은 사실이죠.
위에 제가 말씀드린 거와 같습니다. Ada에 대한 나쁜 견해 같은건 없습니다. 저도 얼마후에 리얼타임 프로젝트를 Ada로 할 것이고, 이미 마일리지 적립시스템 프로젝트의 코어부분을 Ada로 만들었습니다.
다시 말씀드리지만, 제 경험상을 말씀드린 것입니다. 선입견을 가진다는 이야기는 없는데 제 이야기를 선입견을 가지고 보시는군요.. 즐거운 토론되시길..
[quote]개인적으로는 동의할 수 없습니다. 분명 좋으니까 쓰는 것
영어가 제일 많이 사용 되니까 최고의 언어인지 의문이고 지구별 최고의 종족은 한족이라는 것도 의문이고 중국과 인도가 지구별 최강이란것도 의문입니다.
단지 지금 많이 사용 된다는 것 만으로 그것의 우수함을 이야기 할수는 없을거 같네요.
한글이 우수하다곤 하더군요. 알파벳 보다 한참 후에 만들어져서 좀더 과학적이라 하네요. 그럼 늦게 나온게 장땡인가? 그것도 좀 이상하네요. 여하튼 단지 지금 널리 퍼졌다는 것이 그것의 성능이 뛰어나기 때문이라는 소리는 너무 이상하게 들립니다.
지구별에서 중국 사람이 제일 많은 것과 비슷한 이치가 아닐까 싶습니다.
중국인이 우수해서가 아니라 이미 충분히 많으니까요.
가까운 시일 내에 c++의 위치를 c#이 먹지 않을까 싶은데요. 얼마전에 pda와 pc sync프로그램을 c#으로 개발 하는걸 보았는데 안정성이나 성능면에서 c++과 비교해서는 어떨지 모르지만 기존의 app보다는 훌륭했습니다.
ADA 어제 교보문고에서 봤을때...
전에 학교 도서관에서 근로할때 조교님중 한분이 빌려가시면서 "사람들이 세계 최고의 언어라고 부른다"라고 하셔서 무언가 읽어봤는데...
병렬처리용으로 최고라더군요.
그 책에도 미국방성에서 프로젝트를 위해서 만들었다고 나왔어요.
하긴... 컴퓨터 대부분이 연구나 군사 목적으로 만든것들이니...
[quote="marzok"]가까운 시일 내에 c++의 위치를 c#이
그 C#이 돌아가는 .NET Framework 가상머신은 대체 뭘로 만들어졌을까요 -_-;;
여기 주제인 설계적인 측면에서 잘 된 언어라는 게 좀 애매한 것 같네요..
성능이나 용도를 생각하지 않고 순전히 사용자가 쓰기 좋은 언어를 따진다면
당연 JAVA, Python, C# 등의 최근의 언어가 C/C++, Fortran 등의 언어들 보다 좋겠지요..
그게 아니라 단순 비교로 C++이 좋으냐, JAVA가 좋으냐 뭐가 좋다 이런식의 비교를 하는 것은 탱크가 좋으냐, 스포츠카가 좋으냐, 대형트럭이 좋으냐 의 비교하고 비슷할 것 같네요..
Re: Re: Re : Ada..
특별한 취향상 차이일 수도 있지만, Ada가 프로그래머들이 생각하는 간단명료에 많이 뒤떨어져
있는건 사실입니다.
>> 일단 제개인적으로는 C 혹은 C++이 Ada에 비해서 특별히 간단명료하다고 느껴지지는 않네요.
>> 겉으로 드러난 간단명료와 코드의 가독성은 분명 다릅니다.
>> 부정적인 이야기하자면 님의 말씀처럼 간단명료에 많이 뒤떨어져 있다는 식으로
>> 이야기할수도 있지만 긍정적인 측면에서 보자면 뛰어난 코드의 가독성을 위해서
>> 님이 말씀하시는 그런간단명료를 능동적으로 회피했다고 볼수도 있읍니다.
>> 님도 아시다시피 Ada는 분명 가독성면에서는 뛰어난 언어입니다.
>> 실제 Ada추종자들이 다른언어와 비교할때 거의 첫번째 두번째로 내세우는 이유이기도 합니다.
>> 성격이 좀다르지만 Perl과 Python이 이런경우라고 생각합니다.
>> 님이 말씀하시는 그런 간단명료는 Perl코드가 Python보다는 분명 뛰어납니다.
>> 그리고 그런이유때문에 Perl을 좋아하는 프로그래머도 많다고 생각합니다.
>> 반대로 그런 일견 간단명료해 보이는 코드가 겹겹히 쌓여있을때 나타나는 엉터리(?) 가독성때문에
>> Python으로 도망간 프로그래머도 부지기수죠...
>> 그리고 모든프로그래머들이 가독성을 희생한 겉으로 드러난 간단명료함을 선호한다고 생각지도 않습니다.
다시 말씀드리지만, 제 경험상을 말씀드린 것입니다. 선입견을 가진다는 이야기는 없는데 제 이야기를 선입견을 가지고 보시는군요.. 즐거운 토론되시길..
>> 그런뜻이 아닌데 오해하셨다면 죄송합니다.
[잡담]
아싸~ 글 많이 올라오네요~ ^- ^
뛰어난 요리사는 모든 부분에서 다 일등급의 요리는 만드는건 아니죠.자
뛰어난 요리사는 모든 부분에서 다 일등급의 요리는 만드는건 아니죠.
자기가 가장 자신있어야하는 요리는 몇가지 꼽을 정도라고 생각합니다.
요리에 따른 재료와 도구 및 첨가물을 얼마나 잘 이해하고 잘 사용하는
냐의 문제가 아닐까요?
프로그래머도 역시 분야와 용도에 따라 그에 맞는 언어와 툴을 잘
사용할 수 있다면 그것으로 충분하지 않을까요?
프로그래밍 언어 역시 그렇지 않을지.
PL에서 가장 중요시 하는건 가장 읽기 쉬운 것이 쓰기 쉬운것보다
우선이라고 보고 있는데 C, C++은 그런점에서 읽기 보다는 쓰기가
더 편하죠. 자연언어에 가까운 언어일수록( Ada 같은) 읽기 쉽다는..
(그렇더라도 영어를 외국어로 가진 우리에게는 여기 쉽지 않다는..)
설계 측면에서 볼땐 아무래도 적당히 자연언어에 가깝고 함축성이
있는 언어가 좋은것일거 같다는.. 그렇다면 C++이나 Java, C# 정도
가 아닐까요? 물론 어떤 목표 분야인지에 따라 틀리다고 생각됩니다.
기반 라이브러리 같은 것들이 많다면야.. 더할 나위 없죠. 장황하게
쓰기 보다는.. 적절히 상위에서 표현가능할 정도의 platform으로
지원해준다면야 더할 나위 없죠. :-)
screen + vim + ctags 좋아요~
[quote]80년대 OOP라고 해도 C++보다는 이후에 나왔죠 ..
?? 더 많은 OOP 의 지원이라는 것이 무슨 의미인지는 모르겠으나..
적어도 Java 와 C++ 의 OOP 의 (C#은 잘 모르겠구..) 대결은 C++
의 승리입니다... Multiple inheritance 만이 있는건 아니지요. 진정한 의미의
subclassing, operator overloading, composition , policy... 등등등..
자바로는 구현할 수 없는 것들이 너무나 많치요.
C/C++이 강력하지만...
꼭 대결의식을 조장하는 것은 아니지만, C++이 자바보다 우수한 언어임은 맞다고 생각합니다. 하지만, 자바는 원래 자체가 웹을 보다 풍요롭게 하기 위한 언어입니다. 따라서 웹쪽에서 보면 오히려 자바가 C++보다야 우수합니다.
다만 범용적인 부분으로 가면 C/C++의 강력함을 따라잡을 언어들이 별로 없어서 어쩔 수 없는 것이겠죠.
언어의 개발과 추세는 두마리의 토끼인 용이함(usability)/성능(performance) 의 사이에서 왔다갔다 하는것 같습니다. 용이함의 추세가 강세일때는 그쪽 언어가 부각되고, 성능의 추세가 강세인 곳에서는 다른 언어가 강세인것입니다.
========================================
* The truth will set you free.
Re: ADA 어제 교보문고에서 봤을때...
소프트웨어 시스템 세이프티의 관점에서도 Ada를 제일 선호합니다. 이를테면 록히드 마틴이나 보잉같은 정말정말 안전한 소프트웨어를 만들어야 하는 곳에서 선호한다고 들었습니다. 물론 formal method에 의한 방법론이 더 안전하겠지요.
대신 Ada를 배우고 나서 갈 곳이 몇 개 밖에 없다는 게 문제라면 문제겠죠.
Re: begin end, { }
Python이나 Lua, Quick Basic에도 이런 형태의 if문이 쓰이고 있습니다.
가끔 C/C++이나 Object Pascal을 쓰다 보면 이 형식이 되게 부러울 때가 있습니다. if문이 정말 보기좋고 간결해 지더라구요.
특히 Pascal쪽은 계속되는 begin..end의 압박이 장난이 아니더군요.
C/C++와 Object Pascal에도 이런 if문이 생겼으면 좋겠습니다. (무리일려나... ;))
...
저는 루비에 한표요. 파이썬도 좋구요.
저도 물론 C++을 제일 많이 쓰게 되지만...
루비는 볼때마다 정말 잘 설계했다는 생각이 드는
언어네요.
from caramis ~ !
자바가 웹을 위해서 생겨났다는 것에는 동의할 수 없군요.^^(네트웍이라는
자바가 웹을 위해서 생겨났다는 것에는 동의할 수 없군요.^^(네트웍이라는 표현이 더 적절하겠죠..)
태생은 셋탑 박스에 쓰이기 위해서 만들어진 언어지요.
물론 지금은 웹쪽에서 많이 쓰이긴 합니다만...
자바가 C++보다 OOP적 특성을 더 많이 지원하느니, 우수한 언어니 하는 토론은 불필요한 것으로 생각됩니다.
각각의 언어를 만든 사람은 객체에 대한 '철학' 자체가 다르니까요.
자바 자체가 넘치는 것보다는 약간 모자르는게 낫다는 주의입니다.
(현재는 점점 복잡해지기 위해!! 열심히 노력하는 중이죠.)
(JCP라는) 사공이 많이 지니, 점점 복잡해지고, 덩치가 커지는 것 같습니다.
우리나라의 현실상 자바 한다면 J2SE, J2EE, J2ME 모두를 다 잘 해야한다는 것을 의미하는지라
덩치가 계속 커지는게 그리 행복하지만은 않습니다.
LeanBlue in CyberWorld!!!
[quote="lunacy"][quote]80년대 OOP라고 해도 C
진정한 의미의 subclassing은 c++에서 지원되지 않습니다. 실행시간에 어떤 클래스에 대한 정보를 얻을 수 있나요 c++에서? 안됩니다. operator overloading은 스트럽이 말한 것 처럼 단순한 "편리한 문법"에 지나지 않습니다. 진정한 OO를 위해서는 컴파일 타임 뿐만 아니라 런 타임에서 OO가 지원이 되어야 합니다. C++는 OOP를 위한 언어하기 보담은 그 기원에서 볼 수 있듯이 그냥 더 좋은 C일 뿐입니다. 단지 OO 비슷한 문법을 지원해서 좀 더 나은 C로 사용이 가능하도록 만들었을 뿐입니다.
비록 위와 같다 하더라도 C++는 나쁜 언어니 쓰지 말아야 된다는 당연히 아닙니다. 그러나 OOP에 목적으로 둔다면 C++는 아니라는 거죠. C++의 OO적 문법이 상대적으로 복잡한 이유는 실제 그 언어 자체가 OO를 완전히 지원하지 않기 때문입니다.
그리고 C++로 Collection을 만들때와 Smalltalk, Java 같은 것으로 만들때와의 경우를 비교해 보세요. 다들 일장일단이 있지만 자료구조와 같은 것에 있어서는 C++는 별로 입니다.
또한 NeXTSTEP의 기술을 C++를 이용해서 구현을 하려한다는 것을 상상해 보세요. 거의 불가능에 가깝습니다. MacOSX가 IOKit과 같은 드라이버 레이어를 C++로 바꾼 것은 Objective-C가 안 좋아서가 아니라 Device Driver와 같은 부분은 C/C++만으로 해도 크게 어려움이 없어서 입니다. 물론 유인책의 성격도 있습니다.
빠른 속도가 필요한 부분에 Java나 Smalltalk을 이용해서 작업을 하는 것도 미친 짓이지만 OO가 필요한 부분에 C++를 써서 고생을 하는 것도 마찬가지 입니다.