반응형
반응형

내기와 규칙 바꾸기로 꽉 막힌 협상 뚫어라

http://www.seri.org/ic/icDBRV.html?pubkey=ic20121119001&menu_gbn=1&pgsj=&pgno=1&pgor=

상대를 내가 원하는 대로 행동하게 하려면 그가 ‘왜’ 그것을 주장하는지 알아야 한다. 이를 협상학에선 요구(Position)가 아닌 욕구(Needs)에 주목하라고 설명한다. 포지션은 니즈의 대리인일 뿐 꼭 그것을 받아내야만 하는 것은 아니기 때문이다.

그럼 협상을 잘하기 위해서는 상대의 니즈만 찾으면 될까? 아니다. 한방이 더 필요하다. 그건 바로 ‘협상의 꽃’이라고 불리는 창조적 대안, 즉 ‘크리에이티브 옵션(Creative Option)’이다. 이번 글에서는 창조적 대안이 무엇인지, 그리고 창조적 대안을 만들기 위해선 어떤 방법이 필요한지 알아본다.

창조적 대안(Creative Option)이란?

창조적 대안이란 양측의 욕구를 동시에 만족시키는 제3의 대안을 말한다. 정의만 놓고 보면 대단히 어려운 것처럼 느껴질 수도 있다. 쉬운 예를 들어보자.

주말에 조용히 책을 보기 위해 도서관을 찾은 당신. 볕이 잘 드는 창가 쪽에 자리를 잡고 책을 읽기 시작했다. 그런데 잠시 후 한 청년이 당신 건너편에 자리를 잡더니 창문을 활짝 연다. 밖에서 들리는 아이들의 시끄러운 소리 때문에 조용하게 책을 읽는 평화를 잃게 된 당신. 창문을 닫고 다시 책 읽기에 집중한다. 하지만 다시 그 청년이 창문을 연다. 살짝 화가 났지만 꾹 눌러 참고 다시 창을 닫는 당신. 그러자 상대도 얼굴을 붉히며 창문을 연다. 창을 닫고 싶은 당신과 창문을 열고 싶은 청년. 둘 사이에 무언의 협상이 시작됐다.

이 협상을 풀려면 어떤 창조적 대안이 필요할까? 일단 양측의 욕구, 즉 니즈를 알아보자. 당신의 니즈는 뭔가? 조용한 분위기에서 책을 읽는 것이다. 그럼 상대의 니즈는? 너무 더워서 시원한 바람을 쐬며 공부하고 싶은 것이다. 그럼 ‘조용한 상태로 시원한 환경을 만드는 방법’이 바로 이 협상의 창조적 대안이다. 방법은? 창문을 닫고 에어컨을 켜면 된다. 창문을 열겠다와 닫겠다는 포지션이 부딪힌 상황에서 ‘조용함’과 ‘시원함’이라는 양측의 니즈에 집중하면 ‘에어컨 켜기’라는 새로운 해결책이 나온다.

어떤가? 너무 시시한가? 하지만 이러한 창조적 대안은 세계의 역사를 뒤바꾸기도 한다. 역사 속의 사례를 살펴보자. 1978년에 있었던 이집트와 이스라엘 사이의 평화 협상이다.

이집트와 이스라엘은 시나이반도 반환 문제를 놓고 10년 넘게 지루한 공방을 벌이고 있었다. 상황은 이랬다. 1967년, 이스라엘은 유명한 ‘6일 전쟁’을 통해 이집트 영토의 일부인 시나이반도를 빼앗았다. 뺏은 자와 빼앗긴 자 간의 대립은 갈수록 격화됐다. 이 때문에 중동에서의 평화는 너무 먼 일처럼 보였다. 보다 못한 미국이 중재에 나섰다.

캠프 데이비드로 이집트와 이스라엘의 협상 대표를 부른 미국의 카터 대통령. 먼저 이집트의 협상 대표인 사다트 대통령에게 물었다. “시나이반도와 관련해 이집트가 이스라엘에 원하는 것이 뭡니까?” 이집트의 요구는 간단했다. “무슨 일이 있어도 뺏긴 땅 전부를 돌려받아야만 합니다.”

다음, 이스라엘의 협상 대표를 맡은 베긴 총리에게 물었다. “시나이반도를 이집트에 돌려주실 수 없습니까?” 베긴 총리가 냉정하게 답했다. “돌려 드릴 생각은 있습니다. 하지만 100% 반환은 불가능합니다. 일부만 돌려 드리겠습니다.”

‘100% 반환’과 ‘일부 반환’이라는 요구(position)가 맞붙은 상황. 중재자 역할을 맡은 사이러스 벤스 미 국무장관은 양측의 욕구, 즉 니즈를 파악하는 데 주력했다. “모래밖에 없는 시나이반도에 왜 그리 집착합니까?” 양측의 욕구는 의외였다. 이집트는 자존심(주권) 회복을 원했다. 작은 나라인 이스라엘에 6일 만에 국토를 빼앗긴 것에 국민들이 분노하고 있었기 때문이다. 뿐만 아니라 이스라엘과 평화 협정을 맺으면 다른 아랍 국가들에게 미운 털이 박힐 수도 있었기 때문에 이를 무마하기 위한 반대 급부로 시나이반도는 무조건 전부 차지해야만 했다. 반면 이스라엘의 니즈는 ‘안전을 보장받는 것’이었다. 시나이반도라는 완충지대가 있어야만 중동의 적대국으로부터 예루살렘을 지킬 수 있다고 판단한 것. 즉 전쟁 위협에 대한 전초 기지의 역할로 시나이반도가 꼭 필요했다.

양측의 니즈를 파악한 벤스가 창조적 대안을 내놨다. “땅은 100% 이집트에 돌려주되 시나이반도를 비무장지대로 한다. 그리고 이스라엘에 조기 경보 시스템을 제공해 안보를 철저히 지켜준다.” ‘자존심 회복’이라는 이집트의 욕구와 ‘안전 확보’라는 이스라엘의 욕구. 이 둘을 절묘하게 충족시키는 아이디어 덕분에 양국은 전쟁터에서 낭비될 뻔한 젊은이들의 피를 아낄 수 있었다.

이처럼 크리에이티브 옵션은 꽉 막힌 협상을 풀어내는 해답과도 같은 역할을 한다. 그래서 협상 워크숍을 진행할 때마다 ‘창조적 대안을 만들기 위해 노력하라’는 얘기를 많이 한다. 하지만 이럴 때 되묻는 사람이 꼭 있다. “창조적 대안이 좋은 건 알겠는데 그거야 협상장에서 잔뼈가 굵은 사람이나 만들어 낼 수 있는 거 아닌가요? 어떤 사람들은 이렇게 하소연한다. “창조적 대안이라는 건 말 그대로 ‘창조적인 아이디어’가 많은 사람들이나 만들어 낼 수 있겠죠.”

혹시 이 글을 읽고 있는 당신도 그렇게 생각하는가? 협상 전문가들은 이런 생각에 대해 단호하게 “NO”라고 말한다. 창조적 대안을 만드는 데에 협상 경험이나 창의성은 그리 중요하지 않다. 대신 창조적 대안을 만들어 내는 ‘패턴’을 아는 게 중요하다. 수많은 성공적인 협상 사례를 분석해 보면 창조적 대안은 몇 가지 일정한 패턴을 갖고 있다. 창조적 대안을 만드는 비밀을 하나씩 풀어보자.

Bet (내기 걸기)

협상을 하다 보면 나와 상대가 미래를 다르게 예상하고 이로 인해 협상이 교착 상태에 빠질 때가 많다. 이때 자신의 예상이 맞다며 싸우는 사람들은 협상 고수가 아니다. 양측의 서로 다른 예상을 인정하고 거기에 따라 베팅을 하면 문제는 쉽게 풀린다. 다음 상황을 한번 보자.

아버지로부터 물려받은 땅을 갖고 있는 당신. 사업 확장을 위해 땅을 팔기로 결심했다. 부동산 사이트를 통해 주변 시세를 확인해 보니 현재 가치는 3억 원 정도로 나타났다. 하지만 지난 주 언론사에 근무하는 지인으로부터 해당 지역 인근에 5년 내에 지하철역이 들어설 것이라는 정보를 들었다. 몇 군데 확인을 해보니 충분히 믿을 만한 정보다. 그래서 현재는 3억 원이지만 역세권임을 감안해 5억 원을 받아야 한다고 생각한다. 하지만 사려는 사람의 생각은 다르다. 상대는 지하철역이 들어올 가능성은 전혀 없다고 확신한다. 그래서 현재가치인 3억 원이면 충분하다고 주장한다.

이때 협상을 못하는 사람들은 3억 원과 5억 원의 중간선인 4억 원에 대충 합의한다. 하지만 협상 고수는 다르다. ‘현재 가격인 3억 원으로 거래하되 5년 내 지하철역이 개통되면 2억 원을 매수인이 추가로 지불한다’는 조항을 넣는다. 어떤가? 판매자는 5년 안에 2억 원을 더 받을 수 있으리라고 기대하고 있기 때문에 ‘5억 원에 팔았다’고 생각한다. 반대로 매수인은 ‘3억 원에 땅을 샀다’고 생각하며 만족한다. 양측 모두 기분 좋은 결과가 나오는 것이다. 이것이 바로 ‘Bet’을 활용한 협상법이다. 미래 상황에 대해 ‘내기’를 걸어 양측 모두가 만족하는 결과를 얻어낼 수 있다.

이 방법은 주로 M&A 협상에서 많이 사용된다. 파는 입장에서는 자산 건전성 자료 등을 제시하며 최대한 높은 가격을 요구한다. 반면 사는 입장에서는 잠재된 부실 자산이 있을 수 있다며 최대한 낮은 가격으로 사려고 한다. 이 문제가 ‘Bet’, 즉, ‘내기를 거는 것’으로 많이 해결된다. 인수 계약이 끝난 후에 숨겨졌던 부실 자산이 발견됐을 때 그 금액을 추가로 지불하는 조건을 넣는 식(풋백옵션)이다. 양측이 서로 주장하는 내용에 자신이 있다면 이런 조항을 통해 협상의 돌파구가 생긴다.

Bet은 나와 상대가 다른 정보를 갖고 있을 때 큰 힘을 발휘한다. 이와 함께 Bet이 유용할 때가 또 있다. 바로 상대가 믿을 만한 사람인지 ‘신뢰도’를 확인해야 할 때다. 예를 들면 이런 상황이다. 영업사원을 뽑는 당신. 한 후보자가 호기롭게 말한다. “저를 뽑아 주시면 1년에 저 혼자 3억 원 정도의 매출은 올릴 수 있습니다. 그러니 매출액의 3분의 1인 1억 원을 제 연봉으로 주십시오.” 하지만 당신 생각은 다르다. 아무리 해봤자 연 1억 원 이상은 힘들 것 같다. 그래서 이렇게 제안한다. “매출액의 3분의 1을 주는 건 합리적이라고 생각해요. 하지만 내 생각에 개인이 할 수 있는 매출액은 연 1억 원 정도가 최대한일 것 같으니 연봉은 3300만 원 정도로 하죠. 만약 정말 당신이 말한 것처럼 연말에 매출 3억 원을 달성한다면 인센티브를 포함해 전체 연봉을 ‘1억 원 + @’로 맞춰 드리죠. 어떻습니까?”

만약 이 제안에 상대가 응하면 당신은 그 직원을 뽑으면 된다. 하지만 만약 “안 됩니다. 차라리 연봉 5000만 원 정도로 하시죠”라는 식의 ‘어중간한’ 타협안을 제시한다면 상대 주장의 신뢰성을 의심해 볼 필요가 있다. ‘연 3억 원 매출’이라는 주장이 공수표일 확률이 높기 때문이다.

실제 협상에선 이런 창의적 아이디어가 잘 떠오르지 않는다. 1969년부터 10년이 넘게 계속되다 결국 결렬된 협상이 있다. 바로 미국 법무부와 IBM 간의 협상1)이다. 미 법무부는 컴퓨터 시장에서 IBM의 점유율이 점점 커지는 것을 우려해 더 이상의 시장 확장을 자제하라고 했다. 하지만 IBM의 입장은 달랐다. 조만간 컴퓨터 업계가 초경쟁 시장이 돼 점유율이 떨어질 것이라고 전망했다. 그렇기에 현재의 생산 계획을 바꿀 수 없다고 맞섰다. 결국 미 법무부는 IBM의 반독점 제한 위반에 대해 소송했고 IBM은 항소했다. 지루한 싸움은 13년 동안 이어졌다. 이를 위해 자그마치 6500만 페이지 이상의 문서가 제출됐다.

지루하게 계속된 협상의 승자는? 수백만 달러를 받으며 양측에서 변호를 맡았던 변호사들이었다. 이 협상은 시장 환경이 바뀌며 둘 다 상처만 잔뜩 입은 채 흐지부지돼 버렸다. 이 협상이 깨진 이유는 뭐였을까? ‘미래 컴퓨터 시장의 점유율에 대한 예측’이 달랐기 때문이다. 만약 IBM이 ‘5년 후 IBM 점유율이 50%가 넘지 않으면 소송 취하’라는 조건을 제시했다면 어땠을까? 혹은 미국 법무부에서 ‘5년 후 IBM 점유율이 75% 이상 될 경우 벌금과 함께 일정 부분 시장 철수’라는 조건을 제시했다면? 이렇게 미래 상황에 내기를 걸었다면 서로 만족하며 해결할 수 있었을 것이다.

협상에서 Bet을 활용한 협상법이 항상 양측 모두에게 좋은 결과를 가져다주는 건 아니다. 어느 한쪽이 주장한 대로 결과가 나왔을 때 반대 주장을 한 측은 엄청난 손해를 볼 수도 있다. 대표적인 사례가 1999년 12월, 제일은행을 매각할 때 뉴브릿지캐피탈과의 협상이다. 당시 제일은행은 5000억 원에 매각됐다. 그리고 향후 2∼3년간 제일은행에 추가로 부실이 발생하면 예금보험공사가 책임을 지겠다는 ‘풋백옵션’을 걸었다. 그런데 이 부실 규모가 눈덩이처럼 불어나 3조6000억 원에 달했다.2) 잘못된 협상 하나로 국민들의 세금이 애꿎은 데로 새어 나간 것이다. 지난 2006년엔 금호아시아나그룹이 대우건설을 인수할 때 투자자들에게 약속한 풋백옵션 때문에 그룹 전체가 위기를 맞기도 했다.3) 결국 Bet을 활용할 때에는 확실한 자료와 근거에 기반해 접근해야만 한다.

협상가들은 나와 다른 주장을 하는 상대의 생각을 바꿀 수 있을 것이라고 기대한다. 하지만 사람의 생각은 쉽게 바뀌지 않는다. 더구나 상대가 충분한 근거를 갖고 있다면 더더욱 그렇다. 상대의 생각을 바꾸기 위해 애쓰지 마라. 자신이 믿는 쪽으로 ‘내기를 거는 것’, 그것이 해답이다.

Rule Change (규칙 바꾸기)

탁자 위에 동그란 달걀을 세울 방법은? 다들 알다시피 ‘깨면’ 된다. 콜럼버스가 그랬던 것처럼. 여기서 중요한 점은 ‘달걀을 깨선 안 된다’는 룰을 바꾼 사실이다. 협상에서도 마찬가지다. 정해진 틀 속에서는 새로운 해결책을 찾기 쉽지 않다. 그래서 프로 협상가들은 협상의 룰을 바꿀 방법은 없을지 고민한다.

아주 쉬운 예를 보자. 두 아이가 케이크 하나를 두고 서로 자기가 나누겠다며 다투고 있다. 다른 친구가 나누게 되면 자신이 손해를 볼 것이라고 생각하기 때문. 이 다툼을 해결할 방법은 뭘까? 그렇다. 한 명이 케이크를 나누고 다른 한 명이 고르면 된다. 이를 통해 두 사람 모두 만족할 만한 결과를 얻을 수 있다. 너무 쉬운가? 하지만 실전 협상에선 이처럼 당연해 보이는 원리도 잘 적용시키지 못할 때가 많다. 다음 사례를 한번 보자.

1973년 시작된 해저 광물 채굴권 협상4)은 10년째 유엔의 큰 골칫거리였다. 태평양 등 공해상의 심해에 묻혀 있는 희귀 광물 개발권에 대한 협상이 제자리걸음을 하고 있었기 때문이다. 광물 채굴을 하려면 어떤 나라가 어느 지역을 개발할 것인지 결정해야 하는데 각 나라마다 이해관계가 얽혀 쉽사리 결론이 나지 않았다.

우여곡절 끝에 대상 해역의 절반은 미국, 영국 등 선진국 기업의 컨소시엄이, 나머지 절반은 후진국들이 컨소시엄을 구성한 ‘엔터프라이즈’에서 갖는 것까지는 정했다. 하지만 구역을 어떻게 나눌 것인가라는 문제에서 협상은 다시 교착 상태에 빠졌다. 지역 선택의 우선권을 가진 엔터프라이즈가 지도 위에 선을 그었다, 지웠다만을 반복하고 있었던 것. 채굴 해역에 대한 충분한 정보 없이 섣불리 지역을 선택했다가 선진국들이 가치 있는 광물이 묻혀 있을 만한 지역을 독식할 것을 염려하고 있었다.

사업 구역을 놓고 협상이 꽉 막힌 상황. 이때 제시된 해결책이 ‘선진국 기업 컨소시엄이 구역을 반으로 나누고 엔터프라이즈가 고르는 것’이었다. 이렇게 되면 선진국들은 최대한 공정하게 구역을 나눌 수밖에 없다. 자칫 잘못하다간 엔터프라이즈에 노른자위 땅을 다 내어줄 수도 있기 때문이다. 이 방법으로 10년간 속을 썩이던 유엔해양법 협상이 성공적으로 마무리됐다.

룰을 바꿔 협상을 타결한 또 다른 사례5)가 있다. 다국적 호텔 체인이 한 개발도상국에 진출하게 됐다. 그런데 적극 환영하던 정부와의 최종 계약 상황에서 문제가 생겼다. 호텔 측은 ‘총수익의 30%를 달러로 자국에 송금해야 한다’고 했다. 회사 정책상 송금 비율을 낮추는 건 불가능했다. 하지만 정부는 ‘어떤 외국계 기업도 수익의 10% 이상의 달러 송금은 안 된다’며 맞섰다. 개도국의 정부가 외국계 기업을 유치하는 이유는 달러를 확보하기 위함인데 달러 송금 비율이 높아지면 목적 달성이 어려워지기 때문이다.

30% 송금’과 ‘10% 송금’이라는 포지션이 맞선 상황. 이때 양측의 니즈에 집중해 룰을 깬 창의적 아이디어가 나왔다. ‘호텔 매출액 중 달러 수입분의 50%까지 달러 송금을 허용한다’는 것. 이렇게 되면 호텔은 기존 ‘30%’보다 더 높은 송금 비율을 얻어낼 수 있었기에 만족한다. 정부는 어떨까? 호텔 입장에선 본사에 송금하는 금액을 늘리기 위해 고객들의 달러 결제를 유도하게 된다. 그 덕분에 정부는 달러 보유액이 늘어나게 돼 만족한다. ‘송금비율’이라는 문제를 ‘달러 수익 중의 송금비율’로 틀을 바꿔 창의적 해결책을 만들어 냈다.

주어진 틀에서만 생각하면 누군가는 손해보고 양보해야만 한다. 답이 보이지 않을 땐 협상의 룰을 바꿔라. 처음에 제시된 협상 조건에서 한발 물러나 룰을 바꿀 때 창의적 협상이 가능해 진다.

협상의 교착 상태를 풀어내기 위한 해결책, 창조적 대안. 이건 하늘에서 떨어지는 것도, 다양한 협상 경험을 통해 갖게 되는 ‘감’을 통해 만들어 지는 것도 아니다. 협상 상황에 따른 패턴을 아는 것, 그것이 핵심이다.

반응형
반응형

행복은 미덕이나 기쁨이 아니라 성장이다. 우리는 성장할 때 행복해진다

 - 윌리엄 버틀러 예이츠 -

 

반응형
반응형
사람들은 집중이란 집중할 것에
예스(yes)라고 말하는 것이라고 생각한다.
하지만 집중은 전혀 그런 게 아니다.
다른 좋은 아이디어 수백 개에 노(no)라고 말하는 게 집중이다.
실제로 내가 이룬 것만큼이나 하지 않은 것도 자랑스럽다.
혁신이란 1천 가지를 퇴짜 놓는 것이다.
-스티브 잡스, ‘CNN 선정 스티브 잡스 10대 명언 중’에서

피터 드러커 교수는 ‘보통 수준 기업들은
수익이 되는 것들을 선택하여 열심히 하려한다.
위대한 기업들은 반대로, 자신이 할 수 있는 최고의 분야에 집중한다.
자신이 최고로 잘할 수 있는 분야가 아니면, 선택하지 않는다.
이들의 비즈니스 생리는 매우 단순하다.
이들은 자신들이 제일 해 보고 싶고,
또한 제일 잘할 수 있는 분야에만 집중한다.’고
포기와 집중의 원리를 설파한 바 있습니다.

반응형
반응형
꿈을 꾸다가
"어, 알겠어, 이건 꿈이야!"
하고 분명하게 느끼게 될 때가 있다.
이런 꿈을 '자각몽'이라고 부른다.
깨어나서야 "아, 그래 꿈이었구나" 하게 되는
보통의 꿈과 달리 자각몽 상태에서 '깨어난'
사람들은 놀라운 통찰을 발휘하고
비상한 창의적인 에너지를
풀어낼 수 있다.


- 제레미 테일러의《사람이 날아다니고 물이 거꾸로 흐르는 곳》중에서 -


* 자각몽.
'꿈 속의 꿈'을 일컫습니다.
저도 이따금 이 자각몽을 꿉니다.
꿈 속에서 '내가 꿈을 꾸고 있다'는 사실을
인식하는 특별한 체험입니다. 꿈에서조차
또 다른 꿈을 선물로 받는 셈입니다.
무의식의 저 깊은 곳에 잠겨 있던
초현실적인 그림 한 조각이
추상화처럼 수면 위로
둥실 떠오릅니다.

반응형

'아침편지' 카테고리의 다른 글

돌풍이 몰아치는 날  (0) 2012.11.23
더 넓은 공간으로  (0) 2012.11.22
두꺼운 허물벗기  (0) 2012.11.20
3,4 킬로미터 활주로  (0) 2012.11.19
나는 괜찮은 사람이다  (0) 2012.11.17
반응형

체조시작하고 입수

 

워밍업 스크롤링 자유형킥 4/ 자 3

스크롤링 자유형킥 넘 빡세다. 하고나서 자유형하면 팔이 돌아가지 않는다.

 

땅콩끼고

접/평/자 4

접/평/자 3

자유형 25m 4

개헤엄 1

땅콩빼고 자유형 4

 

별로 한거 없는거 같은데 시간 금방 갔네.

마치고 배영 1

자유형 1

 

체중감량 들어가야 한다.

반응형

'운동일지 > 수영' 카테고리의 다른 글

2012.11.23 수영일지  (0) 2012.11.23
2012.11.22 수영일지  (0) 2012.11.22
2012.11.20 수영일지  (0) 2012.11.20
수영 대회 연습 스케쥴 3.7km - 25m 레인기준  (0) 2012.11.19
2012.11.17 수영일지  (0) 2012.11.17
반응형

Compile to HTML/CSS/JavaScript

A list of upcoming programming languages that replace HTML/CSS/JavaScript -

  1. Elm (gos.i, homepage) The Elm programming language aims to make web development more pleasant. Elm is a type-safe, functional reactive language that compiles to HTML, CSS, and JavaScript. Elm's major distinguishing features are support for reactive programming and its focus on graphical user interfaces. Elm is also call-by-value and strongly / statically typed with type inference. The language features mentioned above help catch errors in your code at compile time, but there are some errors that are external to your code, such as browser incompatabilities. By using HTML, CSS, and JavaScript as an assembly language, Elm can avoid some of these problems.
  2. mobl (gos.i, homepage) mobl is a new free and open source language designed specially to speed up building mobile applications. Using modern HTML5 technologies, mobl offers you a concise language to build native-feeling web apps in a jiff; great (Eclipse) IDE support (such as as-you-type error reporting, code completion and reference resolving); a rapid save and test cycle. No more lengthy compilations, the mobl IDE compiles your modules whenever you save, ready to be tested in the mobile browser.
  3. fun (gos.i, homepage) A declarative programming language for realtime web applications.

Compile to JavaScript

This is a list of projects tagged as javascript-alternative on getOpenSource.info. If you'd like to add a project to this list, you can always do so by adding it here and then adding javascript-alternative as a tag.
An up to date list can always be found at http://getopensource.info/explore/javascript-alternative/.
  1. CoffeeScript (gos.i, homepage) CoffeeScript is a little language that compiles into JavaScript. Underneath all of those embarrassing braces and semicolons, JavaScript has always had a gorgeous object model at its heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way. The golden rule of CoffeeScript is: “It's just JavaScript”. The code compiles one-to-one into the equivalent JS, and there is no interpretation at runtime. You can use any existing JavaScript library seamlessly (and vice-versa). The compiled output is readable and pretty-printed, passes through JavaScript Lint without warnings, will work in every JavaScript implementation, and tends to run as fast or faster than the equivalent handwritten JavaScript.
  2. LiveScript (gos.i, homepage) LiveScript is a language which compiles down to JavaScript. It is a fork of Coco which is in turn derived from CoffeeScript. Like those two it has a relatively straightforward mapping to JavaScript. LiveScript is Coco but much more compatible with CoffeeScript, more functional, and more feature rich. LiveScript aims for increased expressiveness and code beauty. While adding features to assist in functional style programming, LiveScript also deeply supports imperative and object oriented programming, and has an optional class system with inheritance, calls to super, and more.
  3. Coco (gos.i, homepage) Coco is a CoffeeScript dialect that aims to be more radical and practical. On its way to hide JavaScript's bad parts, CoffeeScript has accumulated own quirks: horrible variable scope, awkward ranges, confusing and/or pointless keywords, verbose file extension, and so on. Coco tries to amend them, entwining good parts of both.
  4. IcedCoffeeScript (gos.i, homepage) IcedCoffeeScript is a superset of CoffeeScript. The iced interpreter is a drop-in replacement for the standard coffee interpreter; it will interpret almost all existing CoffeeScript programs. IcedCoffeeScript (ICS) adds two new keywords: await and defer. These additions simply and powerfully streamline asynchronous control flow, both on the server and on the browser. Say goodbye to callback pyramids; say adios to massive code rewrites when synchronization requirements change slightly. Say hello to clean, readable, maintainable control flow for network and asynchronous operations! The golden rule of CoffeeScript was: “It's just JavaScript”. ICS is doing something deeper. It's selectively running code through a continuation-passing style conversion. Original-style CoffeeScript will compile as before, but code using the new ICS features will be less recognizable. Still, the compiled output is readable and pretty-printed, passes through JavaScript Lint without warnings.
  5. haXe (gos.i, homepage) haXe (pronounced as hex) is an open source programming language. While most other languages are bound to their own platform (Java to the JVM, C# to .Net, ActionScript to the Flash Player), haXe is a multiplatform language.
  6. Opa (gos.i, homepage) Opa is a new generation of web development platform that lets you write distributed web applications using a single technology. Opa is concise, simple, concurrent, dynamically distributed, and secure.
  7. Dart (gos.i, homepage) Dart is a new class-based programming language for creating structured web applications. Developed with the goals of simplicity, efficiency, and scalability, the Dart language combines powerful new language features with familiar language constructs into a clear, readable syntax.
  8. LLJS (gos.i, homepage) LLJS (formerly known as *JS) is a typed dialect of JavaScript that offers a C-like type system with manual memory management. It compiles to JavaScript and lets you write memory-efficient and GC pause-free code less painfully, in short, LLJS is the bastard child of JavaScript and C. LLJS is early research prototype work, so don't expect anything rock solid just yet. The research goal here is to explore low-level statically typed features in a high-level dynamically typed language. Think of it as inline assembly in C, or the unsafe keyword in C#. It's not pretty, but it gets the job done.
  9. heap.coffee (gos.i, homepage) heap.coffee is a dialect of CoffeeScript that offers a C-like type system with manual memory management. It compiles to JavaScript and lets you write memory-efficient and GC pause-free code less painfully. heap.coffee, like its relative *JS, is early research prototype work, so don't expect anything rock solid just yet. The research goal here is to explore low-level statically typed features in a high-level dynamically typed language.
  10. Google Web Toolkit (gos.i, homepage) Google Web Toolkit (GWT) is a development toolkit for building and optimizing complex browser-based applications. Its goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript. GWT is used by many products at Google, including Google Wave and the new version of AdWords. It's open source, completely free, and used by thousands of developers around the world.
  11. Roy (gos.i, homepage) Roy is an experimental programming language that targets JavaScript. It tries to meld JavaScript semantics with some features common in static functional languages.
  12. JS11 (gos.i, homepage) JS11 takes incomplete code and transforms it back into JavaScript. It's smart enough to add in various bits of redundant syntax, and can also transform some common errors and handy shortcuts into working JavaScript code. JS11 is a hybrid dialect that strives for greater readability and programmer effectiveness, whilst maintaining line-number parity with JavaScript. It consists of a language specification and a compiler module. JS11 adds some nice-to-have features that people often use in JavaScript but have to write out the long way. This includes things like default argument values, named parameters in function calls, a nice way to create private variable scopes, and easy numbered loops.
  13. Kaffeine (gos.i, homepage) Kaffeine is a set of extensions to the Javascript syntax that attempt to make it nicer to use. It compiles directly into javascript that is very similar, readable and line for line equivalent to the input (you can beautify if you like).
  14. Jack (gos.i, homepage) Jack is a new language in development that gets translated to pure JavaScript and runs on top of nodeJS.
  15. PogoScript (gos.i, homepage) PogoScript is a programming language that emphasises readability, is friendly to domain specific languages and compiles to regular JavaScript.
  16. moescript (gos.i, homepage) Moe is a new, not-very-little Javascript-targeted language written in JavaScript. Its features are inspired by Scala, Python, Haskell and Coffee. It is aimed to deal with common troubles in JavaScript development. Moe has neatly crafted grammar so that most JavaScript development will be simplified.
  17. JavaScript++ (gos.i, homepage) JavaScript++ provides the same familiar C-style language syntax of JavaScript and brings modern language features such as classes; block scoping and constants; pluggable type systems and type safety; packages and modules; comprehensive standard libraries; enhanced regular expressions and PCRE; and more to JavaScript with almost no learning curve through an extended ES3 grammar. JavaScript++ compiles to ES3-compatible JavaScript. JavaScript++ incorporates features from Python, Perl, Java/C#, ES4, Harmony, Haskell, and more while incorporating its own unique features. The driving philosophy behind JavaScript++ is productivity, and it will make everything from small scripts to large applications easier and faster to write. Take the mundane out of your JavaScript code with JavaScript++!
  18. JSX (gos.i, homepage) JSX is a statically-typed, object-oriented programming language designed to run on modern web browsers. JSX performs optimization while compiling the source code to JavaScript. The generated code runs faster than an equivalent code written directly in JavaScript. The gain may vary, but even the optimized JavaScript libraries like Box2D becomes faster when ported to JSX (we are observing 4% to 27% increase in performance). In contrast to JavaScript, JSX is statically-typed and mostly type-safe. The quality of applications becomes higher when being developed using JSX, since many errors will be caught during the compilation process. It also offers debugging features at the compiler level as well. JSX offers a solid class system much like the Java programming language, freeing the developers from working with the too-primitive prototype-based inheritance system provided by JavaScript. Expressions and Statements are mostly equal to JavaScript, so it is easy to for JavaScript programmers to start using JSX.
  19. mochiscript (gos.i, homepage) Mochiscript is a superset of the JavaScript language that adds more Object-Oriented features such as: methods, inheritance, mixins, etc… What this means is that Mochiscript IS Javascript. Mochiscript currently supports Ruby on Rails 3.1 (via asset pipeline) and Node.js.
  20. Pygmy (gos.i, homepage) Pygmy is a dynamic language that compiles to Javascript, designed to be readable but concise enough to be competitive in code golf.
  21. Pit (gos.i, homepage) PIT is F# to Javascript compiler that leverages the beauty of F# and also JavaScript.
  22. WebSharper (gos.i, homepage) WebSharper is an HTML5-centric web framework that lets you create web and mobile JavaScript apps complete with a server-side backend using a single language, F#. WebSharper is designed to boost your productivity. Reduce complexity with a single language on the client and the server, enjoy code completion in Visual Studio®, and benefit from type inference and other great features of F#.
  23. Amber (gos.i, homepage) Amber is an implementation of the Smalltalk-80 language. It is designed to make client-side development faster and easier. It allows developers to write client-side heavy web applications in Smalltalk. Amber includes an integrated development environment with a class browser, workspace, transcript, object inspector and debugger. Amber is written in itself, including the parser and compiler, and compiles into efficient JavaScript, mapping one-to-one with the JS equivalent.
  24. Haste (gos.i, homepage) A compiler to generate Javascript code from Haskell.
  25. ghcjs (gos.i, homepage) ghcjs is a Haskell to Javascript translator. It aims to provide solution to compile modern Haskell libraries to Javascript files and use them in Ajax applications or develop entire Ajax application in Haskell
  26. Outlet (gos.i, homepage) Outlet is a programming language. It is Lisp-like in nature and compiles to JavaScript.
  27. SibilantJS (gos.i, homepage) Sibilant is a language that is parsed by javascript and compiles to javascript. Sibilant is inspired by lisp and follows many lisp conventions, although it is still relatively close to the underlying javascript. Sibilant is entirely written in sibilant and can recompile itself.
  28. Scriptjure (gos.i, homepage) Scriptjure is a Clojure library for generating javascript from Clojure forms. Its primary goal is to make it simple to embed “glue” javascript in Clojure webapps. Generated Scriptjure javascript is intended to be readable. At the moment, Scriptjure is very simple, but is still under active development.
  29. clojurescript (gos.i, homepage) ClojureScript is a new compiler for Clojure that targets JavaScript. It is designed to emit JavaScript code which is compatible with the advanced compilation mode of the Google Closure optimizing compiler.
  30. BiwaScheme (gos.i, homepage) BiwaScheme is a Scheme interpreter written in JavaScript.
  31. JSIL (gos.i, homepage) JSIL is a compiler that transforms .NET applications and libraries from their native executable format - CIL bytecode - into standards-compliant, cross-browser JavaScript. You can take this JavaScript and run it in a web browser or any other modern JavaScript runtime. Unlike other cross-compiler tools targeting JavaScript, JSIL produces readable, easy-to-debug JavaScript that resembles the code a developer might write by hand, while still maintaining the behavior and structure of the original .NET code. Because JSIL transforms bytecode, it can support most .NET-based languages - C# to JavaScript and VB.NET to JavaScript work right out of the box.
  32. Doppio (gos.i, homepage) Doppio is a project to get Java running in the browser without any plug-ins. Right now it comprises a fairly complete VM and an implementation of the javap bytecode disassembler. (Doppio is also the Italian word for 'double', and is another name for a double espresso). Doppio started out as the mid-term project for a Graduate Systems Seminar. It has since taken on a life of its own, and is complete enough to run implementations of GNU Diff, LZW compression, and the Java 4 compiler.
  33. Skulpt (gos.i, homepage) Skulpt is an entirely in-browser implementation of Python. No preprocessing, plugins, or server-side support required, just write Python and reload.
  34. Pyjs (gos.i, homepage) Pyjs is a port of Google Web Toolkit to Python, and thus enables the development of Rich Media AJAX applications in Python, with no need for special browser plugins. Pyjs contains a stand-alone python-to-javascript compiler, and also a Widget Set API that looks very similar to Desktop Widget Set APIs (such as PyQT4 or PyGTK2). Pyjs also contains a Desktop Widget Set version, running as pure python, with three useable Desktop ports available. With web-engine technology at it's core, HTML, CSS, plugins and other related features work out-of-the-box.
  35. Objective-J (gos.i, homepage) Objective-J is a new programming language based on Objective-C. It is a superset of JavaScript, which means that any valid JavaScript code is also valid Objective-J code. Anyone familiar with JavaScript and object-oriented programming concepts, classical inheritance in particular, should have no difficulty learning Objective-J.
  36. Opal (gos.i, homepage) Opal is a ruby to javascript compiler. Opal aims to take ruby files and generate efficient javascript that maintains rubys features. Opal will, by default, generate fast and efficient code in preference to keeping all ruby features. Opal comes with an implementation of the ruby corelib, written in ruby, that uses a bundled runtime (written in javascript) that tie all the features together. Whenever possible Opal bridges to native javascript features under the hood. The Opal gem includes the compiler used to convert ruby sources into javascript.
  37. Red (gos.i, homepage) Red takes the Ruby you write and turns it into JavaScript for your browser. The all-new Red is a Ruby-to-JavaScript transliterator backed by a custom ruby.js library designed to let your code run in the browser exactly the way Ruby would run on your machine. The JavaScript output is optimized to contain only the fraction of the ruby.js source library needed to run your code. What does this mean for today’s Ruby developer? Simple. You don't need to learn JavaScript.
반응형

+ Recent posts