내가 가장 좋아하는 언어에서 가장 아쉬운 점!

cleol의 이미지

각자 좋아하는 언어...또는 플랫폼(자바 또는 .NET 같은)에 대해서 "이러이러해서 좋다!" 는 토론은 꽤 많은 것 같습니다. 그런데 반대로 "난 이 녀석을 참 좋아하는데 이거 하나는 아쉽다..."하는 토론은 별로 못본거 같아서요. 한 번 해보면 재미있는 이야기가 되지 않을까요?
여담이지만 사실 루비에 대해 찾아보다가 유니코드 지원이 안된다는 사실을 알고 좀 실망했습니다. http://rubykr.org/ 에 보니까 루비를 사용하고 계신분들도 이걸 많이 아쉬워하는 것 같더군요. 그러다가 다른 언어들도 조금씩 아쉬운 점이 있을텐데하는 생각이 들어서 글을 한번 올려봅니다.

댓글

Fe.head의 이미지

C언어.

1. string 형이 없음.
2. 기본으로 지원되는 bool 형이 없음.
3. api 함수의 통일성이 없음.

고작 블로킹 하나, 고작 25점 중에 1점, 고작 부활동
"만약 그 순간이 온다면 그때가 네가 배구에 빠지는 순간이야"

cppig1995의 이미지

_Bool 형이 있습니다. stdbool.h를 #포함하면 bool/true/false로도 쓸 수 있습니다.
--
임수 서룬뫼 윤 희수 {cppig1995}

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

rainmon의 이미지

제가 가장 좋아하는 프로그래밍 언어는 아니지만 C#의 경우
메소드에 디폴트값을 가지는 인자를 만들 수 없는게 아쉽습니다.
오버로딩으로 해결되긴 하지만 코딩량이 많아지고 메소드 관리도 힘들어지더군요.
하나 바꾸려면 오버로딩 한 모든 메소드를 다 바꿔야 하니 정말 일 많아지던데 이런 문제를 해결하는 방법은 없을지..

plusme의 이미지

내가 가장 좋아하는 프로그래밍 언어 Java
이런점들이 아쉽다.

1. 멀티 프로세스 환경에 대한 지원이 많이 부족하다. (IPC등..)

2. Bit field 선언이 C에서 만큼 직관적이지 못하다

3. 아직도 느린 VM Initializing 속도

4. Java를 잘모르는 사람들을 설득해야 하는 현실..-_-;;

ㅂㅂ의 이미지

세월이 참 무섭네요.. ㅎㅎ

cjh의 이미지

perl:

if ($i == 0)
  print "hello world";

가 안되어서

if ($i == 0) {
  print "hello world";
}

해야 하는 점.

그리고 switch... case가 없다는것 정도 (perl6에는 있다지만).

(물론 print "hello world" if ($i == 0); 해도 된다는건 압니다)

--
익스펙토 페트로눔

creativeidler의 이미지

정말 재밌는 주제군요! 저도 좋아하는 언어가 아쉬움이 느껴질 때마다 확 내가 만들어? 하는 충동이 일곤 합니다-_- 시간이 좀 나면 장난 삼아 한 번 만들어볼 생각을 하고 있죠.

전 파이썬, 자바를 가장 좋아합니다. 둘 중 파이썬을 더 좋아하지만 파이썬에 싫어하는 것들이 더 많죠. 파이썬에 대해 아쉬운 것이 대부분 자바의 장점이고 자바에서 아쉬운 것은 또 파이썬의 장점이죠. 구체적으로 본다면..

1. 파이썬의 지저분한 네이밍 컨벤션 vs 자바의 일관성 있는 컨벤션
파이썬의 네이밍 컨벤션은 참 악명이 높지만 레거시를 존중하지 않는 파이썬의 관습 덕에-_- 점차 바뀌어 가고 있습니다. 점차 나아질 꺼라 기대.

2. 파이썬의 모듈 써치 패스 vs 자바의 classpath + jar
자바 초보들이 다들 classpath로 고생을 하지만-_- 알고 나면 너무 쉽고 유연성이 높은 것이 또 자바의 classpath죠. 파이썬은 이에 비하면 2% 부족. 여러 버전을 한 머신에, 혹은 심지어 한 jvm 위에서도 돌릴 수 있는 자바의 기능을 가져왔으면..

3. 파이썬 모듈 vs 자바 패키지
비슷하지만 자바 패키지 쪽을 더 선호합니다. 복잡한 프로그램을 만들수록 자바의 패키지 개념이 부러울 때가 많죠.

4. 파이썬의 다이나믹 타이핑 vs 자바의 스태틱 타이핑
자바도 C++에 비하면 드라마틱한 dynamic을 보여주는 언어이지만 파이썬의 다이나믹이 필요할 때가 있습니다. 리플렉션도 파이썬이 훨씬 쉽고 편하죠. 이 점이 위에 열거한 파이썬의 사소한 단점들을 다 커버한다는...

머, 파이썬과 자바의 차이는 수도 없이 많겠지만 저 정도가 저에게 장점/단점으로 다가왔던 부분들입니다.

purewell의 이미지

* 대한민국어 2005년판.

아름다운 표현이 하도 할샨데 무분별한 외국어가 덕지덕지 지져분하게 붙은 것이 불만입니다.

* 미국식영어 2005년판.

있는 한 껏 꼬아 쉽게 귀에 들어오지 않고 정규보단 예외가 많아 외울 문법이 상당하다는 것이 불만입니다.

_____________________________
언제나 맑고픈 샘이가...
http://purewell.biz

카二리의 이미지

C#의 override와 virtual keyword
C# 문법을 보면서 가장 맘에 안드는 것들이다.

C#의 class명 method명 표기법
java랑 비슷한대 대문자로 시작하다니-_- 이렇게 짜증 날수가;;

언어 자체는 아니지만..
JAVA의 기본 j2SE기본 API에 USB나 시리얼 포트 관련 API가 없는것도 짜증-_-;
공개프로젝트가 있긴 하지만 그래도 기본으로 들어간거랑은 차이가....
프로그래밍 할때 쓸만한 거의 모든것이 있다고 생각 했는대 뭔가 하려할때 없으면 왠지 화난다-_-; ... (화낼 이유는 없지만;)

새 생각 :)

익명사용자의 이미지

전 C#에서 메소드명을 대문자로 시작하는게 싫어요.
함수도 변수로 보는 버릇해서..

moonzoo의 이미지

C언어.

1. api함수 리턴값의 비 일관성.
2. structure가 메서드를 지원치 않음 --
3. string type의 enum이나 switch가 지원이 안됨..

chadr의 이미지

C++

1. foreach가 없음
2. 언어에서 제공하는 try~catch가 그다지 효용성이 없음
3. 헤더와 소스를 분리하는 구조.. 자바나 cs같이 소스와 헤더의 구별이 없었으면 하는 바램..
4. 컴파일러 자체의 문제인가 언어 자체의 문제인가는 모르겠지만 너무나도 느린 컴파일 속도!

-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.

익명사용자의 이미지

3. 헤더와 소스를 분리하는 구조.. 자바나 cs같이 소스와 헤더의 구별이 없었으면 하는 바램..

이거... 버쳘머신이나 인터프리터없이도 현존하는 OS의 수정 없이 깨끗한 바이너리를 생성할 수 있을까요?

violino의 이미지

딱 원하시는건 아니겠지만,
STL 에 정의된 macro 중에 for_each 가 있죠.

nohmad의 이미지

cleol wrote:
각자 좋아하는 언어...또는 플랫폼(자바 또는 .NET 같은)에 대해서 "이러이러해서 좋다!" 는 토론은 꽤 많은 것 같습니다. 그런데 반대로 "난 이 녀석을 참 좋아하는데 이거 하나는 아쉽다..."하는 토론은 별로 못본거 같아서요. 한 번 해보면 재미있는 이야기가 되지 않을까요?
여담이지만 사실 루비에 대해 찾아보다가 유니코드 지원이 안된다는 사실을 알고 좀 실망했습니다. http://rubykr.org/ 에 보니까 루비를 사용하고 계신분들도 이걸 많이 아쉬워하는 것 같더군요. 그러다가 다른 언어들도 조금씩 아쉬운 점이 있을텐데하는 생각이 들어서 글을 한번 올려봅니다.

'실망'이란 표현에 오해의 소지가 있을 수 있어 약간의 설명을 하겠습니다.

루비의 유니코드 지원이 부족한 것은 사실입니다. 하지만 이 말이 루비에서 유니코드를 쓸 수 없다는 말은 아닙니다. 적어도 UTF-8 문자열을 인식하고, 정규표현식 내에서 사용할 수 있고, 유니코드 포인트와 상호변환할 수 있고, iconv로 인코딩간 변환을 하는 등 기본적인 사용에는 큰 문제가 없습니다. 물론 유니코드가 아닌 바이트를 다룬다는 점에서 근본적인 한계가 있습니다만 부족한 부분은 라이브러리로 해결할 수 있습니다.

유니코드는 상당히 방대한 표준이라서, 언어 차원에서 유니코드의 모든 기능을 제공하기는 힘듭니다. 다른 언어에서 제공하는 유니코드의 어떤 기능을 사용하지 못해 실망하셨는지 모르겠지만, 유니코드 지원이 된다, 안된다, 이런 식으로 잘라서 말하는 것은 잘 모르는 사람들에게 일종의 FUD가 될 수 있으므로 짧게 설명해보았습니다.

picxenk의 이미지

Smalltalk.

- 국내 사용자가 너무 없다. :)

onion의 이미지

정답... 그리고...
한글입력 도와주세욧....(물끄럼)

-----새벽녘의 흡혈양파-----

-----새벽녘의 흡혈양파-----

prolinko의 이미지

python:

루비가 smaltalk, python, perl 등의 여러 장점을 따와서 만들었다는데, 다른 여러가지 syntactic sugar 들은 부럽지 않지만, smal talk 에서 따온 완전한 OO적인 설계가 부럽습니다.(타입에 있어서나 문법에 있어서나)

스크립트 형태의 길지않은 프로그램에서는 참 깔끔해 보이는 python이지만, object 기반으로 큰 프로그램을 짜보면 문법적으로 지저분해 보이는 부분이 많습니다. (물론 ruby에 비해서 입니다.. )

7339989b62a014c4ce6e31b3540bc7b5f06455024f22753f6235c935e8e5의 이미지

PHP:

구현이 이상합니다.
call_user_func_array("foo", func_get_args());는 작동하지 않는데 $args=func_get_args();call_user_func_array("foo", $args);는 작동하더군요.

또 PHP4에서는 new Foo()->asdf(); 같은 것도 작동하지 않았습니다. 마지막으로 최근에 foreach의 작동 방법이 마음대로 바뀌어서 혼란이... :x

hongminhee의 이미지

(new Foo)->method(); # X
 
$a = new Foo;
$a->method(); # O
 
echo get_array()[0]; # X
 
$a = get_array();
echo $a[0]; # O
ydhoney의 이미지

델파이 :

델파이 자체가 언어가 아니다. -_-(오브젝트 파스칼)
사람들한테 무시받는다. (비베같은 것이라면서..실제로는 훨씬 좋은데..=ㅅ=)
콘솔로 작업하기가 껄끄럽고 거시깽이하다.

onion의 이미지

fpc써야죠.....
fpc쓰면 콘솔도 잘돼요...vi쓰기도 편하고..
하지만 delphi의 RAD도구들은 당체 버릴수가 없는물건..(중얼중얼)

그리고 무시하는사람은 없어요...
다들 관심을 안가져서 그렇지..-.-;

-----새벽녘의 흡혈양파-----

-----새벽녘의 흡혈양파-----

happyjun의 이미지

많은 사람들이 아쉬워 하지만 고쳐지지 않는 이유는

- 귀찮다.

- 고치지 않는 이유가 더 그럴 듯 하다.

일 것 같습니다.

rainmon wrote:
제가 가장 좋아하는 프로그래밍 언어는 아니지만 C#의 경우
메소드에 디폴트값을 가지는 인자를 만들 수 없는게 아쉽습니다.
오버로딩으로 해결되긴 하지만 코딩량이 많아지고 메소드 관리도 힘들어지더군요.
하나 바꾸려면 오버로딩 한 모든 메소드를 다 바꿔야 하니 정말 일 많아지던데 이런 문제를 해결하는 방법은 없을지..

메소드의 디폴트 값 문제는 C++에서 부터 상속에서 많은 문제를 야기하는 것으로 알려져 있습니다. C# 아키텍트? 의 블로그를 보면 왜 디폴트 값을 C#에서 제거 했는지 주저리 주저리 써 있습니다.

저도 C#에서 귀찮기는 하지만 상속에서 생기는 문제점을 생각해보면 어쩔 수 없다 봅니다.

----------------------------------------
http://moim.at
http://mkhq.co.kr

happyjun의 이미지

chadr wrote:
C++

1. foreach가 없음
2. 언어에서 제공하는 try~catch가 그다지 효용성이 없음
3. 헤더와 소스를 분리하는 구조.. 자바나 cs같이 소스와 헤더의 구별이 없었으면 하는 바램..
4. 컴파일러 자체의 문제인가 언어 자체의 문제인가는 모르겠지만 너무나도 느린 컴파일 속도!

1. 길어서 귀찮지만 ( _가 하나 더 있으므로 ==; ) std::for_each

2. java처럼 method에 발생하는 exception이 적혀 있지 않기 때문인가요?

3. 찬성!

4. macro, template 등 preprocessor와 optimizer 때문인거 같습니다.

----------------------------------------
http://moim.at
http://mkhq.co.kr

hardline의 이미지

primitive type도 모두 오브젝트였으면 좋겠습니다.
모든것이 오브젝트였으면 좋겠는데 코딩할때마다 primitive type들이 걸리적 거립니다.

auto boxing으로는 만족하지못합니다.

chadr의 이미지

happyjun wrote:

1. 길어서 귀찮지만 ( _가 하나 더 있으므로 ==; ) std::for_each

2. java처럼 method에 발생하는 exception이 적혀 있지 않기 때문인가요?

3. 찬성!

4. macro, template 등 preprocessor와 optimizer 때문인거 같습니다.

1. stl의 for_each를 쓰기 위해서 펑터도 만들어야하기 때문에 귀찮거드요;;

2. 그런것도 있지만 C#이나 Java와 같이 finally가 없어서이기 때문이기도 합니다 :)

4. ㅜㅜ

ps. 이곳에서 논의된 각 언어의 장점과 단점들을 정리해서 새로운 언어를 만들면 어떨까 하는 생각이 갑자기 들었습니다. :twisted:

-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.

happyjun의 이미지

chadr wrote:
ps. 이곳에서 논의된 각 언어의 장점과 단점들을 정리해서 새로운 언어를 만들면 어떨까 하는 생각이 갑자기 들었습니다. :twisted:

저는 새로운 언어를 만드는 작업을 바퀴의 재발명이라는 관점에서 부정적으로 생각했습니다.

하지만 python이나 일본에서 만든 ruby의 성공을 보면 삽질만으로 끝나는 작업은 아닌것 같습니다.

----------------------------------------
http://moim.at
http://mkhq.co.kr

mykldp의 이미지

가장 좋아하는 언어는 아니지만 가장 많이 사용하는 언어가 java입니다. 고로 아쉬운 점이 가장 크게 느껴지는 것도 java입니다. 가장 아쉬운 점을 들라면 간결한 closure가 없다는 것. 물론 anonymous inner class가 있지만 타이핑 양이 많습니다. 문법적으로 보다 간결한 방법이 있으면 좋겠습니다.

꼬마앙마의 이미지

Python

* 불편한 Tkinter
파이썬의 표준 GUI가 Tkinter인데, 이것이 Tcl/Tk에서 따온것이라서 구식이고 느리며 불편합니다.
리눅스에서는 한글입력도 안되죠.Mac에선 모르겠구요.
그래서 나온게 WXPython인데 개인적으로 이게 훨씬 더 좋은것 같습니다. 왜 기본으로 포함되지 않는지 모르겠지만요...

* 파이썬 설치 디렉토리명에 공백이 포함되어 있을때 에러가 남...가끔씩... 귀도씨는 별로 고칠 생각이 없다고 들었습니다.

* 제대로된 GUI RAD 툴이 없음...
제가 군대가기전에 2년만 기다리면 좋은게 나오겠지..(당시에는 ActiveState사가 Visual Python .NET 을 개발한다고 했음.)
라고 기다렸는데 아직도 제대로된 GUI툴은 없음... 어쩔수 없이 불편한 VisualWX를 사용하는데 버그가 많아요.

* 한글로된 문서나 번역서를 찾기가 너무 어려움... 일본쪽에는 공식 문서도 전부 번역되어 있더군요.
그걸 볼때마다 진짜 부럽다는 생각이 들기도 하고, 가끔씩 내가 해볼까?
라는 생각이 들기도 하는데 능력은 없고...

* 클래스 내부의 메소드를 생성할때 항상 인자의 첫번째는 self를 붙여야 할때.
KLDP 에서 루비의 단점?(http://bbs.kldp.org/viewtopic.php?t=60295)에서도 나왔던것이지만,
가끔씩 불편하다는 생각도 들고 문법에러도 주로 이부분에서 발생합니다. 타이핑 하기도 귀찮고...

* 쓰레드 문제... 파이썬으로 처음 쓰레드 만들때는 진짜 감동해서 눈물을 흘렸는데... 요거이 상당히 문제더군요.;;;

* 상수가 없음... 이건 원래 몰랐었던 겁니다...프로그래밍 언어론 시간에 갑자기 생각이 났습니다.
왜 파이썬은 상수가 없지? 하구요. 생각해보니 전혀 필요 없을것 같기도 합니다.

* 변수나 객체이름을 한글로쓸 수 없음... 이강성님께서 패치하신걸 보니까 의도적으로 막아놓은 것 같더군요.
가끔씩 이강성님이 한글 변수를 쓸수 있게 만들어둔걸로 파이썬 프로그래밍을 하면 재밌습니다...

if 버그:
    토해내(데이타)
else: 
    계속해()

물론 어느게 효율적인지는 생각해보아야 할 문제이죠.

참... 파이썬이란 언어는 억지로 단점을 끄집어내기 정말 어렵네요.;;[/code]

monpetit의 이미지

꼬마앙마 wrote:
* 불편한 Tkinter
파이썬의 표준 GUI가 Tkinter인데, 이것이 Tcl/Tk에서 따온것이라서 구식이고 느리며 불편합니다.
리눅스에서는 한글입력도 안되죠.Mac에선 모르겠구요.
그래서 나온게 WXPython인데 개인적으로 이게 훨씬 더 좋은것 같습니다. 왜 기본으로 포함되지 않는지 모르겠지만요...

예전에 perky님이 잠깐 CJK Python에 wxPython을 넣어서 배포하다가 다시 Tcl/Tk로 되돌아가신 적이 있습니다. 그 때 얼핏 듣기로 라이센스 문제 때문에 그만두신다더군요.
Kroisse의 이미지

C++에서 동적 바인딩을 써먹기가 무지 귀찮습니다 :?
포인터 남발이 되니까 소스가 엄청나게 지저분해져요. OTL

Java나 Smalltalk처럼 가비지 컬렉션까지 해주면 얼마나 고마울까요.
........느려지겠지만 :twisted:

그리고, 인터페이스가 없으니까 이것도 나름대로 껄끄럽더라고요.
다중상속으로 커버는 할 수 있지만 이것도 지저분해서리 :?

zzaratra의 이미지

cjh wrote:
perl:

if ($i == 0)
  print "hello world";

가 안되어서

if ($i == 0) {
  print "hello world";
}

해야 하는 점.

그리고 switch... case가 없다는것 정도 (perl6에는 있다지만).

(물론 print "hello world" if ($i == 0); 해도 된다는건 압니다)

처음 배울때.. 이것 때문에 많이 헷갈렸죠...--;;

근데.. 지금도 모르는건데요.. 1개 이상의 라인 주석 처리 어떻게 하나요 ?
그냥 #인가요 ... 주석은 # 밖에 안된다면.. 이것도 불편한점..
펄은 재밌고...가장 좋아하긴 하지만.. 몇일 사용 안하면 잊어버림...--;;

aero의 이미지

zzaratra wrote:
cjh wrote:
perl:

if ($i == 0)
  print "hello world";

가 안되어서

if ($i == 0) {
  print "hello world";
}

해야 하는 점.

그리고 switch... case가 없다는것 정도 (perl6에는 있다지만).

(물론 print "hello world" if ($i == 0); 해도 된다는건 압니다)

처음 배울때.. 이것 때문에 많이 헷갈렸죠...--;;

근데.. 지금도 모르는건데요.. 1개 이상의 라인 주석 처리 어떻게 하나요 ?
그냥 #인가요 ... 주석은 # 밖에 안된다면.. 이것도 불편한점..
펄은 재밌고...가장 좋아하긴 하지만.. 몇일 사용 안하면 잊어버림...--;;

저도 perl을 좋아합니다. perl이 간단한것 같으면서도 고급의 테크닉을
구사하려면 좀 난해해지는면도 있긴하지만...

저도 처음 perl할때 if 뒤에 {} 빼먹고 왜 안되지 하는적도 있었죠:)
switch 없는건 찾아보면 몇가지 편법이 있고 Switch라는 모듈을
사용하면 기타 언어의 switch문법과 유사하게 사용가능합니다.
http://search.cpan.org/~rgarcia/Switch-2.10/Switch.pm

그리고 multiline comment는 코딩할때 설명넣고 나중에 문서로도
뽑아낼 수 있는 pod tag를 사용하는 방법 몇가지 편법 그리고
나름대로의 주석스타일을 지정해줄 수 있는 모듈인 Acme::Comment를
쓰는 방법이 있습니다.

자세한것은
http://www.perl.com/lpt/a/2002/08/13/comment.html

jj의 이미지

역시 단점없는 언어는 없군요. 이런 단점을 모두 커버하는 언어를 만들면 참 쓰레기 같을겁니다. :P

--
Life is short. damn short...

죠커의 이미지

ydhoney wrote:
델파이 :

델파이 자체가 언어가 아니다. -_-(오브젝트 파스칼)
사람들한테 무시받는다. (비베같은 것이라면서..실제로는 훨씬 좋은데..=ㅅ=)
콘솔로 작업하기가 껄끄럽고 거시깽이하다.

델파이 자체는 언어를 뜻하기도 합니다. 공식적으로 볼랜드는 오브젝트 파스칼이란 이름을 포기하고 델파이 랭귀지를 사용하고 있습니다.

죠커의 이미지

chadr wrote:
happyjun wrote:

1. 길어서 귀찮지만 ( _가 하나 더 있으므로 ==; ) std::for_each

2. java처럼 method에 발생하는 exception이 적혀 있지 않기 때문인가요?

3. 찬성!

4. macro, template 등 preprocessor와 optimizer 때문인거 같습니다.

1. stl의 for_each를 쓰기 위해서 펑터도 만들어야하기 때문에 귀찮거드요;;

2. 그런것도 있지만 C#이나 Java와 같이 finally가 없어서이기 때문이기도 합니다 :)

4. ㅜㅜ

ps. 이곳에서 논의된 각 언어의 장점과 단점들을 정리해서 새로운 언어를 만들면 어떨까 하는 생각이 갑자기 들었습니다. :twisted:

나는 for_each 키워드의 도입을 반대합니다. 언어외적인 방법으로 가능한 것에 대해서 언어의 키워드로 도입한다는 것은 개인적으로는 이해가 안됩니다. (C#에서도 언어자체의 키워드로서 타당한것인지 논란이 있었다고 알고 있습니다.)

쿠크다스의 이미지

jj wrote:
역시 단점없는 언어는 없군요. 이런 단점을 모두 커버하는 언어를 만들면 참 쓰레기 같을겁니다. :P

PL/1?

과자가 아닙니다.
cuckoo dozen, 즉.12마리의 뻐꾸기란 뜻입니다.

죠커의 이미지

쿠크다스 wrote:
jj wrote:
역시 단점없는 언어는 없군요. 이런 단점을 모두 커버하는 언어를 만들면 참 쓰레기 같을겁니다. :P

PL/1?

Ada?

행복한고니의 이미지

PHP....
thread가 있었으면...

C++...
with 문 됐으면 좋겠어요.
일부러 구체적으로 짓는다고 변수명이랑 클래스 이름이랑 조금 길게 지었다가 다 칠려고 하니까 귀찮아 죽겠습니다.

__________________________________
나는 세상에서 가장 중요한 사람이다.

onion의 이미지

.....그건 이미 웹 스크립트를 넘어서버리는....
thread는 lib의 형태로 제공되는게 제일 낫지 않을까요?..ㅎㅎㅎ

아..그러고보니.. php-gtk는..... thread에 대한 고려가 전혀 안되어있을라나요?..-.-;

-----새벽녘의 흡혈양파-----

-----새벽녘의 흡혈양파-----

keedi의 이미지

저도 펄 매니아입니다만...

초보자 입장에서 한글 문서가 많이 없다는 것이 가장 마음에 안드는 점입니다.
더군다나 한빛 미디어에서는 앞으로 펄 관련 서적 번역 계획이 *전혀* 없다는
점도 마음 많이 상하게 하는 부분입니다... __;;;

의외로 많은 표현 방법으로 인해 에디터기에서 신택스 칼라링시 가끔씩
오류가 있다는 점도 아쉬운 점입니다.

그리고 내부적으로 자체 유니코드를 사용하는데 역시 초보자 입장에서
겪게 되는 애로 사항도 아쉬운점입니다. 조금 더 완벽하게 유니코드를
지원했으면 좋겠는데 펄 6를 기대 해봅니다.

----
use perl;

Keedi Kim

corba의 이미지

ydhoney wrote:
콘솔로 작업하기가 껄끄럽고 거시깽이하다.

터보파스칼 쓰는 느낌으로 하니 별 애로사항은 없던데요. :)
kane의 이미지

CN wrote:
chadr wrote:
happyjun wrote:

1. 길어서 귀찮지만 ( _가 하나 더 있으므로 ==; ) std::for_each

2. java처럼 method에 발생하는 exception이 적혀 있지 않기 때문인가요?

3. 찬성!

4. macro, template 등 preprocessor와 optimizer 때문인거 같습니다.

1. stl의 for_each를 쓰기 위해서 펑터도 만들어야하기 때문에 귀찮거드요;;

2. 그런것도 있지만 C#이나 Java와 같이 finally가 없어서이기 때문이기도 합니다 :)

4. ㅜㅜ

ps. 이곳에서 논의된 각 언어의 장점과 단점들을 정리해서 새로운 언어를 만들면 어떨까 하는 생각이 갑자기 들었습니다. :twisted:

나는 for_each 키워드의 도입을 반대합니다. 언어외적인 방법으로 가능한 것에 대해서 언어의 키워드로 도입한다는 것은 개인적으로는 이해가 안됩니다. (C#에서도 언어자체의 키워드로서 타당한것인지 논란이 있었다고 알고 있습니다.)


자주 쓰는 구문을 좀 더 편하게, 잘 쓸 수 있는 방법이 있다면 언어 안으로 끌어들이는데 찬성합니다.
serialx의 이미지

rainmon wrote:
제가 가장 좋아하는 프로그래밍 언어는 아니지만 C#의 경우
메소드에 디폴트값을 가지는 인자를 만들 수 없는게 아쉽습니다.
오버로딩으로 해결되긴 하지만 코딩량이 많아지고 메소드 관리도 힘들어지더군요.
하나 바꾸려면 오버로딩 한 모든 메소드를 다 바꿔야 하니 정말 일 많아지던데 이런 문제를 해결하는 방법은 없을지..

function aaa(a, b)  {
...
}

function aaa(a) {
  return aaa(a, 10);
}

제가 C# 문법을 다 까먹어서 그런데, 다음과 같이 하면되지 않나요?

serialx의 이미지

저의 사랑을 듬뿍받는 Delphi..

단점은 역시 사용자층이 별로 없다.

리눅스쪽 지원이 약하다.

라자루스가 gtk 2.0 을 공식 지원하기까지만 기다리는중 :D

rainmon의 이미지

serialx wrote:
rainmon wrote:
제가 가장 좋아하는 프로그래밍 언어는 아니지만 C#의 경우
메소드에 디폴트값을 가지는 인자를 만들 수 없는게 아쉽습니다.
오버로딩으로 해결되긴 하지만 코딩량이 많아지고 메소드 관리도 힘들어지더군요.
하나 바꾸려면 오버로딩 한 모든 메소드를 다 바꿔야 하니 정말 일 많아지던데 이런 문제를 해결하는 방법은 없을지..

function aaa(a, b)  {
...
}

function aaa(a) {
  return aaa(a, 10);
}

제가 C# 문법을 다 까먹어서 그런데, 다음과 같이 하면되지 않나요?

저는 보통 땜질하는 기분으로 그렇게 사용하긴 합니다.
하지만 디폴트 값을 가지는 인자가 없으면 이 방법도 안되는 경우가 종종 있더군요.
말이 나왔으니 하나 더 하자면 break 없이 case문을 연달아 사용할 수 없는 점도 코딩중에 발상의 폭이 제한되는듯 하고 표현의 자유를 침해당하는 기분도 들고.. :lol:
물론 이 역시도 goto문을 사용해서 이래저래 내 생각을 끼워맞추면 됩니다만.. c++을 먼저 해서인지 c#에선 이외에도 조금 갑갑함을 느낄때가 있네요.

perky의 이미지

저는 파이썬을 가장 좋아하는데,
하나 정말 아쉬운 점은 너무 좋아서 파이썬으로 한참 코딩을 하다보면 다른 언어로 코딩을 할 수 없게 돼버리는 문제입니다.
아.. 이거 참 심각해요.. 큰일이네~~

(좀 더 진지하게 덧붙이자면, 파이썬이 너무 프로그래밍의 편이 때문에 성능상 저하가 동반되는 기능을 많이 포함하는 바람에, 파이썬에 익숙해지면 그걸 감수할 수 없는 언어에 적응하기가 쉽지가 않다는 그런 뜻입니다... :) 그 외의 파이썬 개발자인 amk가 직접 말하는 약점들에 대해서는 http://www.amk.ca/python/writing/warts.html 을 참고하세요.)

You need Python

creativeidler의 이미지

Quote:
저는 파이썬을 가장 좋아하는데,
하나 정말 아쉬운 점은 너무 좋아서 파이썬으로 한참 코딩을 하다보면 다른 언어로 코딩을 할 수 없게 돼버리는 문제입니다.
아.. 이거 참 심각해요.. 큰일이네~~

(좀 더 진지하게 덧붙이자면, 파이썬이 너무 프로그래밍의 편이 때문에 성능상 저하가 동반되는 기능을 많이 포함하는 바람에, 파이썬에 익숙해지면 그걸 감수할 수 없는 언어에 적응하기가 쉽지가 않다는 그런 뜻입니다... Smile 그 외의 파이썬 개발자인 amk가 직접 말하는 약점들에 대해서는 http://www.amk.ca/python/writing/warts.html 을 참고하세요.)

아아..절대 공감. 저도 요즘 C/C++을 써야만 하는 상황이 자꾸 생겨서 아주 미쳐가고 있습니다-_- 아직은 C가 아니면 안되는 영역이 너무 많습니다ㅠ.ㅠ

galien의 이미지

mykldp wrote:
가장 좋아하는 언어는 아니지만 가장 많이 사용하는 언어가 java입니다. 고로 아쉬운 점이 가장 크게 느껴지는 것도 java입니다. 가장 아쉬운 점을 들라면 간결한 closure가 없다는 것. 물론 anonymous inner class가 있지만 타이핑 양이 많습니다. 문법적으로 보다 간결한 방법이 있으면 좋겠습니다.

groovy를 추천해드립니다.

http://groovy.codehaus.org/

예전에 atie님이 소개도 하셨고, 저도 위키페이지에 올리려고 하다가
파이썬을 접하게 되어서 제 관심 밖으로 밀려난 불운의 언어입니다.

그루비 10까지 보고 안봐서 요즘은 어떤지 모르겠습니다만,
스크립트형으로도 작성가능하고 인터프리터도 가능하고
실제 자바와도 섞어서 사용할 수 있었습니다.

그루비 자체가 자바로 만들어진 거에요.

Quote:

Features

* Closure support
* Native syntax for Lists and Maps
* Groovy Markup
* Groovy Path expression language
* Groovlets for implementing Servlets easily in simple Groovy scripts
* Groovy SQL for making SQL more Groovy
* Groovy Beans for simpler syntax for working with beans
* Groovy Template Engines which are pluggable, simple to use, integrate GPath and compile to bytecode
* Groovy Categories allow you to add methods to classes with the "use" keyword
* Ant Scripting
* Regex syntax for neater scripting with regular expressions
* Operator Overloading to simplify working with datatypes Collections and Maps
* Polymorphic iteration and autoboxing
* The Swing-based Groovy Console let you start typing code right away.
* Compiles straight to Java bytecode
* Works cleanly with all existing Java objects and libraries

이런게 특징이라네요

mykldp의 이미지

Quote:
groovy를 추천해드립니다.

http://groovy.codehaus.org/

물론 groovy 는 알고 있습니다. 다만 고객을 설득하기 어려울 뿐입니다^^. 자바 개발자라면 조금만 공부하면 다 할 수 있다고 아무리 이야기해도 발주처 쪽에서는 "표준 자바" 를 사용하기 바라더군요. 아무래도 유지 보수를 걱정하는거지요.
그리고 만약에 자바를 사용하지 않아도 된다면 저는 groovy보다는 Nice http://nice.sf.net 를 사용하고 싶습니다. 역시 jvm 위에서 돌아가는 언어입니다. groovy는 자바보다 유연한 타입 시스템을 가지고 있지만 Nice는 반대로 자바보다 더 엄격한 타입 시스템을 가지고 있습니다. 물론 closure 도 지원되구요. 제가 개인적으로 가장 좋아하는 언어입니다.

doogle의 이미지

Delphi

단점

1. Complier는 좋지만 IDE가 잘 죽는다. (특히 쓰레드디버깅시)
2. 컴포넌트가 너무많다! ^^;;
3. 비베같은 걸로 무시하는 사람들이 많다. (막강의 컴파일러를.. )
4. 윗분 누구 말처럼 리눅스용 Object Pascal지원문제
물론 카일릭스가 있지만.. 역시 Free Pascal + 라자루스가
Gtk2.0을 지원해서 현재 추세의 멋진 인터페이스를 만들 수
있으면 좋겠다. ^^

catz의 이미지

ObjectC!!!!!!!
..... 다른 공부하느라 개념만 쫌 안닷;;;

Lisp!!!!!!! 날 좋아하지 않는듯하다.

입니다.;;

세벌사랑,한글사랑
글이 살아야 나라가 산다.

seungje의 이미지

java에서 연산자 오버로드 되나요?

안되는 것으로 알고 있어서 좌절했었는데...

...

cocas의 이미지

physicist wrote:
java에서 연산자 오버로드 되나요?

안되는 것으로 알고 있어서 좌절했었는데...

안됩니다. C++에서 남이 만든 오버로딩 된 오퍼레이터들은 참 쓰기 편한데 막상 만들려고 하면 화가 나더군요. :evil: 그래서 자바 스타일을 더 좋아하게 되었습니다.

IDNed의 이미지

C++ ㅜㅜ

1. new와 new[], delete와 delete[]의 분리...
(Standard C++ Lib에서 auto_ptr이 new[]를 못 없애는 등...)
2. 동적바인딩이라는 특수성 때문에 현실적으로 작성자가 아닌 다른 사람(제3자)이 클래스 코드를 상속하는 게 현실적으로 불가능함
(함수끼리 내부적으로 호출하는 경우 특히 더)
3. 상속이 복잡해지면서 가상상속 때문에 기계어 수준으로 고찰하는 것

nahs777의 이미지

Pascal or Delphi..

단점
1. 오픈소스로 참조하고 혼자 배울만한 자료가 적다...

2. begin end.. 너무 길다.. (많이쓰는데..)

3. 이거빼고 단점이 안보인다.~!

seoleda의 이미지

MatLab

1. Loop 에 대한 오버헤드가 너무 크다
->vectorization이 어려움
2. 사용자가 적어 물어볼곳이 마땅하지 않다.
3. 비슷한 기능의 함수가 많아 무얼 사용해야 할지 잘 모른다.

요즘 이넘만 쓰는데, 단점이 생각보다 많네요^^

ayh1800의 이미지

chadr wrote:
C++

1. foreach가 없음
2. 언어에서 제공하는 try~catch가 그다지 효용성이 없음
3. 헤더와 소스를 분리하는 구조.. 자바나 cs같이 소스와 헤더의 구별이 없었으면 하는 바램..
4. 컴파일러 자체의 문제인가 언어 자체의 문제인가는 모르겠지만 너무나도 느린 컴파일 속도!

3번과 4번에는 깊은 동감을 합니다.

저는 주로 Boland 툴을 사용하는 편입니다만..
때때로 비슷한 소스를 Delphi와 C++ Builder로 각각 짜보는 경우가 생기는 데요, 파스칼과 비교했을 때 C++의 컴파일 속도는 확실히.. 특히나 STL을 사용할 경우에는 precompiled-header를 사용하지 못해서인지 더 컴파일 속도가 느려진다는 느낌이 가아게 듭니다.

ayh1800의 이미지

doogle wrote:
Delphi

단점

1. Complier는 좋지만 IDE가 잘 죽는다. (특히 쓰레드디버깅시)
2. 컴포넌트가 너무많다! ^^;;
3. 비베같은 걸로 무시하는 사람들이 많다. (막강의 컴파일러를.. )
4. 윗분 누구 말처럼 리눅스용 Object Pascal지원문제
물론 카일릭스가 있지만.. 역시 Free Pascal + 라자루스가
Gtk2.0을 지원해서 현재 추세의 멋진 인터페이스를 만들 수
있으면 좋겠다. ^^

전부 다 동의합니다. ㅠㅠ
처음 델파이로 프로젝트 진행하면서 너무 방대하다 못해 너저분한 컴포넌트들에 압사당할 뻔 했던 기억이 있네요.

개인적으로 이렇게 생산성 높고, 쓸만한 언어 및 개발툴을 왜 안 쓰는 지 잘 이해가 안 됩니다. VB, VC 모두 써보았습니다만, 저 같으면 절대 VB, VC 안 쓸거 같습니다만... ^^

라자루스는 처음 듣네요. 열심히 찾아봐야겠습니다.

개인적으로 리눅스가 개인용 PC의 운영체제로서 손색이 없기 위해서는 VB나 Delphi 정도로 생산성 높고 쓰기 쉬운 개발툴이 꼭 필요하다고 생각합니다.
Borland에서 Kylix를 좀 더 발전시킨다면 쓸만한 데스크탑 리눅스가 만들어지는 데 서로 상호보완적인 역할을 할 수 있지 않을까 하는 생각도 듭니다. Pascal이라는 언어가 오픈 소스 진영에서 너무 생소하다면 C++ IDE 만이라도 보편화되기를 기대해봅니다.

IDE 없으면 인제 개발 못 하겠어요. 너무 길들여져 버린듯 하네요ㅠㅠ

bushi의 이미지

가장 좋아하지만 일년에 한두번 만져볼 정도의 델파이.
장점을 나열하자면 한도 끝도 없겠지만, 뭐니뭐니해도 광속에 비견될만한 컴파일 속도.

2년쯤 전인가... 포인터로 도배를 하자 작정하고 뭔가를 만들기 시작했습니다.
포인터의 타잎캐스팅이라는 언덕을 넘지 못해 우회한 끝에 결코 다시 보고 싶지 않은 코드가 만들어져버렸습니다.
아직도 C 처럼 너저분하게 왔다갔다 할 방법을 찾지 못했습니다.

집에 가면 delphi 1 의 license sheet 가 있답니다. win3.1 에서 돌아가죠.
부끄럽지만 1,3,4 를 제외한 나머지 버전은 (kylix 포함) 어둠의 경로로.
(한 두개 만들어서 혼자 즐기는 정도였지만 죄책감은 상당합니다. GNU 가 이 죄책감에 대한 변호를.)

사실, 처음에 잡았던 tp5.5 도 돌아가신 작은아버지 것을 거의 강탈한 것.
(이때부터 컴파일 속도에 광분하고 파스칼에 빠져들어갔습니다.)

netisinfinite의 이미지

java. (=sun jre)
1. 기동시간, 메모리 - 머나먼 java kernel, mvm
2. UI - jre6의 새 애플릿 로딩 화면을 보고 있으면 역시 sun에는 디자이너가 없다는 생각이.
3. 마케팅 - 자바 어플을 잘 안 쓰는 이유야 여럿 되지만, ati catalyst center 쓰면서 20M 가량 되는 닷넷 프레임웍 손수 까는 수고에 cli 띄우느라 윈도 기동시간이 배로 느려지는 것도 마다않는 사람들 보면, 정녕 jre 번들 따위가 문제인지... 참 거시기합니다.

스톨만이 요즘도 소문처럼 컴퓨터 켜면 emacs로 시작해서 emacs로 셧다운하는지 모르겠군요. 저는 eclipse로 그러고 삽니다. orz

anfl의 이미지

- Class가 지원되지 않는다.
- string type이 없다.


hongminhee의 이미지

JavaScript
연산자 재정의를 하고 싶습니다.
Io
내장 객체들이 상태를 갖지 않았으면(stateless, immutable) 좋았을 것 같습니다. 키워드 인자(keyword arguments)도 있으면 하네요.
C++
언어 차원에서 클로져(lexical closure)가 지원되었으면 합니다. (boost lambda도 좋긴 하지만…)
Python
문장(statement)이 사라지고 모두 평가 가능한 표현식(expression)이면 어떨까 합니다.
PHP
갈아엎고 싶은 부분이 참 많네요. 미약하게나마 혼자 만들어 쓰는 라이브러리가 있긴 하지만 역시 표현력의 문제가 커요~
서지원의 이미지

예전에 읽었던 메일링 리스트가 생각이 나서...

http://mail.python.org/pipermail/python-dev/2006-February/060621.html

송효진의 이미지

ruby 는 아직 유니코드를 지원 못하나요?

emerge money

ageldama의 이미지

$KCODE등을 통해서 utf-8정도만을 조금 지원하고 character-encodings 같은 gem을 이용해 거의 완전하게 utf-8을사용할 수 있긴 하지만 파이썬이나 자바만큼 체계적으로 잘 지원하는건 절대 아닌거 같습니다;;;

----
The future is here. It's just not widely distributed yet.
- William Gibson

kalstein의 이미지

C++에서 동적바인드란게 뭘 의미하는지요?

가상함수를 얘기하는 것인지...;;; 사실 C++로만 프로그래밍한다면 포인터는 그다지 안써도 됩니다만...다만 C와의 인터페이스를 위해서라면 레퍼런스보단 포인터가 좋긴하지요.

공부를 하면 공부할수록 C++에 빠져드는군요. GC문제도...tr1의 shared_ptr(boost에서 가져왔죠)를 이용하면 '완벽히' 깔끔하게 구현됩니다. Java의 경우보다 더 깔끔하죠. 소멸시에 실질적으로 메모리에서 삭제되거든요 (Java의 GC는 priority가 좀 낮아서...지우는 즉시 지워지지는 않는걸로 알고있어요~ 아니라면 리플 남겨주세요 ^^)

for_each의 문제는 tr1의 bind를 이용하면 깔끔히 해결됩니다 (더 나아가서는 boost lambda가 있구요)

C++의 가장 큰 문제는...난이도가 어렵다...일것 같네요. 너무 많은 자유도를 주다보니, 프로그래머 간의 레벨 차이가 타 언어보다 조금 더 많이 날 수 있을것 같습니다. (예를들어...나름대로 공부를 많이했다고 생각하지만서도...Meta Programming을 해버린 소스를 보면 (boost MPL 이용) 조용히 GG를 칩니다 ㅎㅎ)

일단...빠른 시일내에 C++ 0x가 확정되었으면 좋겠습니다 ^^ 더 넓은 언어 표현력을 가지게 되니까요. ^____________^


------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/

js의 이미지

공부를 하면 공부할수록 C++에 빠져드는군요. GC문제도...tr1의 shared_ptr(boost에서 가져왔죠)를 이용하면 '완벽히' 깔끔하게 구현됩니다. Java의 경우보다 더 깔끔하죠. 소멸시에 실질적으로 메모리에서 삭제되거든요 (Java의 GC는 priority가 좀 낮아서...지우는 즉시 지워지지는 않는걸로 알고있어요~ 아니라면 리플 남겨주세요 ^^)

(Sorry for writing in English, can't type Korean)
I wouldn't say GC is unclean for not cleaning garbages right away. There is reason why gc cleans garbages in deferred way - for instance, efficiency, de-fragmentation, etc. (Plus, you can just use reference counting method)
Also, I am not an expert on C++, but even though you use shared_ptr, I don't think it can cleanly solve try/catch/exception problem: does shared_ptr method clean away the memory allocated in the inner function when exception occurs and the context moves to the outer function?

kalstein의 이미지

exception에 관해서도 걱정 안하셔도 됩니다 ^^

생성하는 도중(memory allocation)에 exception이 발생한다면 그 객체는 생성된것이 아니기 때문에, 소멸자도 호출되지않지요. 일단 생성이 되고나면, exception이 어디서 발생하던지 그 객체의 소멸은 반드시 보장 됩니다. (제대로 된 C++ 컴파일러라면 말이지요~ exception을 지원하지않는 컴파일러가 아닌 다음에야 저건 기본적으로 지원해야됩니다)

EC++ 3판을 읽어보시면 왜 그토록 그 책에서 스캇마이어스'님' 께서 std::tr1::shared_ptr의 사용을 입에 침이 마르도록 추천하시는지 느끼실수 있을꺼에요 ^^;

물론...조금 자바에 비해...예외처리가 프로그래머들 사이에 익숙치 않은 감이 있습니다. 아무래도 자바는 언제나 예외처리를 쓰는것을 권장하는 반면, C++에서는 가끔 퍼포먼스위주의 세팅을 위해 예외처리를 쓰지않도록 하는 옵션도 컴파일러에서 제공하는 상황이니까요. 사실...100% 완벽한 예외처리라는게 너무도 어렵기도 하구요...

(3rd party library를 사용한다면, exception이 정확히 발생하는지에 대한 정보를 다 알아야되고...그래서 보통은 그냥 적정수준의 예외처리만을 하지요. 더구나 try, catch문은 공짜점심이 아니거든요...상당히 비싼 오퍼레이션입니다.)


------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/

js의 이미지

어떻게 그게 가능한지 궁금합니다. shared_ptr을 찾아보니까 reference counting을 이용해서 구현이 되어 있던데, 그렇다면 memory 가 allocate되고 다른 변수에 대입을 하고 나서 exception이 발생하거나 하면 어떻게 되나요?

try {
   variable = allocation with shared_ptr;
   another_variable = variable;
   // exception 발생
}
catch (... ) {
}  

gimmesilver의 이미지

예외가 발생하면 스택이 해제되면서 관련된 지역 변수도 안전하게 소멸됩니다.
따라서 shared_ptr 이 특별히 문제가 될 부분은 없을텐데요?
구체적으로 어떤 걸 걱정하시는 건가요?

------------------------
http://agbird.egloos.com

예진아씨의 이미지

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

영어만큼 널리 쓰이지 않고 번역 출판업계가 암울하다는 게 가장 아쉽습니다.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

익명사용자의 이미지

기계어를 좋아합니다. 하지만 알아듣기 힘들다는게 아쉽습니다.
아무런 어려움없이 기계어로 의사소통이 가능하다면 프로그래밍언어란건 필요가 없을텐데...

alwaysrainy의 이미지

C언어에서 오버로딩 기능이 없다는 것과 큰 정수형 데이터를 처리할 수 있는
BigInteger 데이터 타입이 없다는 것이 아쉽습니다 ㅡ.ㅜ

------------------------
세계는 넓고, 할일은 많다.

---------------------------------------
세계는 넓고, 할일은 많다.

hogi2271의 이미지

C가 .. 날 별로 좋아 하지 않는다....

^^/

hogi2271의 이미지

C가 .. 날 별로 좋아 하지 않는다....

^^/

hogi2271의 이미지

C가 .. 날 별로 좋아 하지 않는다....

^^/

angpang27의 이미지

setTimeOut() 은 지속적으로 호출하니깐 Refresh 이외에 별쓸모가 없공,,

SLEEP()이 없어서 작업 진행이 안되넹.. 흐미

JAVASCRIPT는 왜 SLEEP()이 없대용?

아.. 이놈 한번 잠재워야 로직이 완성되는뎅..

고통이 지천에 있다한들 어이해 멈출수있더냐

hongminhee의 이미지

Date 객체를 이용하면 어설프게나마 흉내는 낼 수 있습니다.

angpang27의 이미지

date계산해서 로 해서 while문돌려서 5초가 지났으면 call(); 구현해봤는데,

While문돌면서 브라우저가 뻗어버린다는...(5초동안 엄청나게 도나봐용 ㅋ)

JAVASCRIPT를 잠재울수 있는 방법 정말 없는건가용?

고통이 지천에 있다한들 어이해 멈출수있더냐

hongminhee의 이미지

근데 sleep()이 왜 필요하죠? sleep()으로 해결 가능하다면 window.setTimeOut 메서드로도 해결할 수 있을 듯합니다.

beforeOperations();
sleep(5);
afterOperations();

beforeOperations();
window.setTimeOut(afterOperations, 5000);
angpang27의 이미지

ㅎㅎ 일단 관심가져 주셔서 감사합니다.

beforeOperations();
window.setTimeOut(afterOperations, 5000); //5초마다 afterOperations이 지속적으로호출

5초후에 afterOperations(); 가 딱 한번만 호출되야문제가 해결되거든요.

//
사실 자동 프린팅을 JAVASCRIPT단에서 구현중인데, 5초정도의 Gap이 있어야 하거든요.

고통이 지천에 있다한들 어이해 멈출수있더냐

hongminhee의 이미지

window.setTimeOut(afterOperations, 5000)할 경우 afterOperations는 5초 후에 단 한번 호출되고, 그 이후로는 호출되지 않습니다.

지속적으로 호출되게 만들 경우에는 window.setInterval(afterOperations, 5000)이라고 해야겠죠.

angpang27의 이미지

자세히보니 다른데서 리플래쉬를 하고 있었네요..
죄송해용~ setTimeOut()때매 sleep()이 없는게 이해가 되네요..

JAVASCRIPT아쉬운점 없습니다.

고통이 지천에 있다한들 어이해 멈출수있더냐

angpang27의 이미지

자세히보니 다른데서 리플래쉬를 하고 있었네요..
죄송해용~ setTimeOut()때매 sleep()이 없는게 이해가 되네요..

JAVASCRIPT아쉬운점 없습니다.

고통이 지천에 있다한들 어이해 멈출수있더냐

ageldama의 이미지

스레드를 지원하지 않으니 sleep, delay에 대한 지원이 없는거라고 알고 있습니다.

원하시는 것이 아마도 해당 문맥에서 sleep으로 들어가서 브라우져의 다른 스레드가 제어권을 갖도록 하는 것이 의도신거 같은데, 스레드가 없으니 의미가 없습니다. ^^;

훨씬 복잡하겠지만 해당 로직을 여러단계로 나누어 진입점을 분리하셔야 가능할겁니다.

----
The future is here. It's just not widely distributed yet.
- William Gibson

hongminhee의 이미지

웹 브라우저 위에서 돌아가는 JavaScript는 쓰레드는 지원하지 않아도 간단한 동시성 기능은 갖추고 있지 않나요?

ageldama의 이미지

음. 우둔해서 말씀하시는 동시성 기능이 뭔지는 모르겠지만 어떤 코드가 계속해서 실행중인 환경에서 브라우져에 대해서 제어권이 돌아가지 않는다면 의미가 없지 않을까요? (다중스레드 프로그램이라도 한 스레드에서 모든 실행시간을 차지하면 다른 스레드는 있으나 마나 아닌가요?)

----
The future is here. It's just not widely distributed yet.
- William Gibson

hongminhee의 이미지

window.setTimeOut, window.setInterval, 그리고 Ajax로 잘 알려져 있는 XMLHttpRequest 등을 보면 모두 비동기적인 호출을 합니다~

angpang27의 이미지

참고로 OCX가 할일을 다 마칠때까지 기다리는 로직을 구현했거든요.
그래서 Sleep()을 찾은 거였구요..
ㅎㅎ 어찌됐든 오늘 다 마쳤습니다.

근데, 자바스크립트가 쓰레드가 지원되면 엄청 복잡해질것같은데요.
지원안되는편이 좋을듯해서리..ㅎㅎ

고통이 지천에 있다한들 어이해 멈출수있더냐

페이지

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.