자바는 참 죶같은 점들이 많다고 "사람들" 이 말하죠. 그러면서 자바보다 C#이 좋다는점들을 마구마구 설명해되죠.
제 개인적인 생각으론 그건 그냥 자바를 제대로 써보지도않고 어디서 C#이 좋다고 들은후 말하는것같습니다.
물론 "현제" 자바가 C++이나 C가 안되는점 혹은 버그(?) 로 의심되는 부분도 있지만 그 부분들이 과연 안되거나 버그일까요?.. 셐...
사람들이 자바가 죶병쉰 + 안된다는점 5가지를 뽑아서 함 해봤씁니다 셐..
1. byteArray 2개를 .equal 하면 다르다. hashcode 가 다르기때문에
![bytearray.png]()
그럼 arrays로 묶어서 하면됨ㅋㅋ ㅅㅂ ㅋ 셐
2. Date object 2개를 > operator로 compare가 불가능하다. 버그인가? 셐
![datecompare.png]()
그럼 첫째처럼 하던가 꼭 >하고싶으면 2번쨰처럼하샘 ㅋ
3. 자바는 free() 가없고 garbage collector가 지멋대로 일을 처리한다. 사실이지만 원하면 코더또한 garbage collector를 강재로 실행시킬수있다 햏ㅎ셐
![garbage.png]()
4. 자바에서 string의 각각 char를 읽고 사용하려면 string의 char관련 member method를 죤나많이 써야되고 죤나 코드가 더러워진다.
![stringfunctions.png]()
그럼 캐뤽터 array에 넣어서 쓰샘 ㅋㅋ셐
5 자바는 operator overloading이 없다 + - / *
난 솔직이 + - / * = 들이 그냥 이대로 놔두는게 좋다. 왜냐하면 이 operator들이 프로그램 전채에서 하는일이 간단하게 더하고 빼는거면 기억하기도쉽고 그냥 프로그래밍 자채가 simple해진다. 만약 oparator overaloading이 꼭 필요하면 .jop compiler같이 unofficial 자바 컴파일러로 operator overloading을 하면된다. operator overloading도 사실 옛날 C에는 존재하지않았다. 하지만 bjarn이 c++컴파일러를 만들면서 개발한것이다. 자바또한 충분이 이런 feature들을 업데이트 할수있겠지만 꼭 필요한게 아니니까 구지 할필요가 있는지 모르겠다. 그냥 object.sum(a); 머이런식으로하면 + - / * 와 명백히 구분되고 이해하기도 쉽다
제 개인적인 생각으론 그건 그냥 자바를 제대로 써보지도않고 어디서 C#이 좋다고 들은후 말하는것같습니다.
물론 "현제" 자바가 C++이나 C가 안되는점 혹은 버그(?) 로 의심되는 부분도 있지만 그 부분들이 과연 안되거나 버그일까요?.. 셐...
사람들이 자바가 죶병쉰 + 안된다는점 5가지를 뽑아서 함 해봤씁니다 셐..
1. byteArray 2개를 .equal 하면 다르다. hashcode 가 다르기때문에

그럼 arrays로 묶어서 하면됨ㅋㅋ ㅅㅂ ㅋ 셐
2. Date object 2개를 > operator로 compare가 불가능하다. 버그인가? 셐

그럼 첫째처럼 하던가 꼭 >하고싶으면 2번쨰처럼하샘 ㅋ
3. 자바는 free() 가없고 garbage collector가 지멋대로 일을 처리한다. 사실이지만 원하면 코더또한 garbage collector를 강재로 실행시킬수있다 햏ㅎ셐

4. 자바에서 string의 각각 char를 읽고 사용하려면 string의 char관련 member method를 죤나많이 써야되고 죤나 코드가 더러워진다.

그럼 캐뤽터 array에 넣어서 쓰샘 ㅋㅋ셐
5 자바는 operator overloading이 없다 + - / *
난 솔직이 + - / * = 들이 그냥 이대로 놔두는게 좋다. 왜냐하면 이 operator들이 프로그램 전채에서 하는일이 간단하게 더하고 빼는거면 기억하기도쉽고 그냥 프로그래밍 자채가 simple해진다. 만약 oparator overaloading이 꼭 필요하면 .jop compiler같이 unofficial 자바 컴파일러로 operator overloading을 하면된다. operator overloading도 사실 옛날 C에는 존재하지않았다. 하지만 bjarn이 c++컴파일러를 만들면서 개발한것이다. 자바또한 충분이 이런 feature들을 업데이트 할수있겠지만 꼭 필요한게 아니니까 구지 할필요가 있는지 모르겠다. 그냥 object.sum(a); 머이런식으로하면 + - / * 와 명백히 구분되고 이해하기도 쉽다
틀린 거 강조하는 거 보소 ㅋ
\"현제\"
\"오타\"
지금 매우 졸린상태라서 ㅈㅅ
c#이 좋은거는 Visual studio쓰는거? 인텔리센스?
글 잼있게 읽었다. 잘봤어. ~~~
다만, 5번은 동의하기 힘들어. 가령 벡터를 더할때, vector 2 2 1 + vector 3 2 1 처럼 직관적이고 단순하게 표현가능하고, 리스트의 데이터가 파이프 라인형태로 각각 함수를 거쳐서 처리됨을 표현할때 , input_list >=> funcA >=> funcB >=> funcC 등등..operator overloading 은 실제로 굉장히 유용해
.net김치맨: 탁탁탁..탁탁..탁!! 빌... i love you 꺄악!! 찌익... 하앜... william henry gates
3번은 가비지콜렉터를 부르는 시점을 얘기하는게 아닐껄??? 좀 메모리를 컨트롤하기 좋아하는 횽들이 뭔가 불안해서 그러는거지 횽이 강제로 호출하는게 더 비효율적임 그건 자바머신이 알아서 하게둬
5번은 솔까 자바는 언어적인 정갈함을 위해서 그런거 같은데, 오버로딩하면 표현이 간결해지는 맛이 있지
연산자 오버로딩의 장점은 표현이 간결해진다 이지만 단점은 \"간결한건 좋은데 저놈이 무슨 의도로 이렇게 쓴거지?\" 이지.
C#이 좋은점은 역시 Visual Studio와 쉬운 GUI 개발?? 이 아닐까?
C#이 좋은점 : 자바로 폼UI 밤샘하다 C#으로 1시간만에 만듬
오퍼레이터 오버로딩에 대해서 동감. Serialize 연산자가 무려 \'&\'인 잦같은 MFC 보면. 저렇게 한다고 read랑 write 코드를 따로 짜지 않아도 되는 것도 아니고 (함수 하나에 뭉뚱그려 놓았을 뿐이지 결국 read/write 따로 짜는 거랑 같다)