[scala] Scala 2.8 컬렉션 라이브러리는“역사상 가장 긴 자살 기록”의 사례입니까? [닫은]

난 그냥보고 시작했습니다 스칼라 컬렉션 라이브러리를 다시 구현 임박한오고 2.8 릴리스. 2.7의 라이브러리에 익숙한 사용자는 사용 관점에서 라이브러리가 거의 변경되지 않았 음을 알 수 있습니다. 예를 들어 …

> List("Paris", "London").map(_.length)
res0: List[Int] List(5, 6)

… 어느 버전에서나 작동합니다. 도서관은 매우 유용합니다 . 실제로 환상적입니다. 그러나 이전에 스칼라에 익숙하지 않고 언어에 대한 느낌을 얻기 위해 파고 들었던 사람들은 이제 다음과 같은 메소드 서명을 이해해야합니다.

def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That

이러한 간단한 기능을 위해 이것은 어려운 서명이며 이해하기 위해 고군분투하고 있습니다. 스칼라가 차세대 Java (또는 / C / C ++ / C #) 일 가능성은 없다고 생각합니다. 제작자가 해당 시장을 목표로하고 있다고 생각하지는 않습니다. 다음 루비 또는 파이썬 (즉, 상당한 상업적 사용자 기반을 확보하기 위해)

  • 이것이 사람들을 스칼라로 데려다 줄까?
  • 이로 인해 스칼라는 상업계에서 박사 학위 학생들 만 이해할 수 있는 학문적 놀이 로 나쁜 이름을 갖게 될까요? 있습니까 CTO 의 및 소프트웨어의 머리는 겁받을 것?
  • 도서관 재 설계가 현명한 생각 이었습니까?
  • 스칼라를 상업적으로 사용하고 있다면 이것에 대해 걱정하고 있습니까? 2.8을 즉시 채택하거나 어떤 일이 일어나기를 기다릴 계획입니까?

Steve Yegge는 한때 스칼라를 공격 하여 너무 복잡한 유형 시스템으로 본 것을 공격 했습니다. 누군가 가이 API로 FUD 를 퍼뜨리는 현장 하루를 가질 것이라고 걱정합니다 (Josh Bloch 가 Java에 클로저를 추가 하여 JCP를 놀라게 한 것과 비슷합니다 ).

나는 믿고 동안, 분명해야한다 여호수아 블로흐 , 내가 제안이 실수를 표현 그의 정직-신념 이외의 다른이를 돌리는하지 않는 BGGA 클로저 제안의 거부에 영향을 주었다.


나는에서 수학에서 좋은 학위가 내 아내와 동료가 말해 계속 어떤에도 불구하고, 나는 내가 바보라고 생각하지 않는다 옥스퍼드 대학 , 나는 거의 12 년 동안 및 상업적 봤는데 프로그래밍 스칼라 에 대한 위해 1 년 (상업적).

염증 주제 제목은 1980 년대 초 영국 정당의 선언문에 대한 인용 입니다. 이 질문은 주관적이지만 진정한 질문입니다. CW로 만들었고 그 문제에 대한 의견을 갖고 싶습니다.



답변

나는 그것이 “자살 메모”가 아니기를 바란다. 그러나 나는 당신의 요점을 볼 수있다. 스칼라의 강점과 문제점 인 확장 성 이라는 점을 동시에 알게되었습니다 . 이를 통해 라이브러리에서 대부분의 주요 기능을 구현할 수 있습니다. 일부 다른 언어에서는, 유사 map하거나 collect내장 된 시퀀스 가 있으며, 아무도 원활하게 작동하도록 컴파일러가 거쳐야하는 모든 후프를 볼 필요가 없습니다. 스칼라에서는 모든 것이 라이브러리에 있으며 따라서 열려 있습니다.

사실 그것의 기능은 map복잡한 유형에 의해 지원됩니다. 이걸 고려하세요:

scala> import collection.immutable.BitSet
import collection.immutable.BitSet

scala> val bits = BitSet(1, 2, 3)
bits: scala.collection.immutable.BitSet = BitSet(1, 2, 3)

scala> val shifted = bits map { _ + 1 }
shifted: scala.collection.immutable.BitSet = BitSet(2, 3, 4)

scala> val displayed = bits map { _.toString + "!" }
displayed: scala.collection.immutable.Set[java.lang.String] = Set(1!, 2!, 3!)

항상 최상의 유형을 얻는 방법을 참조하십시오. 당신이지도하는 경우 Int에의 Int의를 당신은 다시 얻을 수 BitSet있지만, 당신이지도하는 경우 Int에들 String의, 당신은 일반적으로 얻을 Set. 정적 결과와 맵 결과의 런타임 표현은 모두 전달 된 함수의 결과 유형에 따라 다릅니다. 그리고 이것은 집합이 비어 있어도 작동하므로 기능이 적용되지 않습니다! 내가 아는 한 동등한 기능을 가진 다른 컬렉션 프레임 워크는 없습니다. 그러나 사용자의 관점에서이 일을하는 방법입니다 가정 일에.

우리가 가진 문제는 이것을 가능하게하는 모든 영리한 기술이 유형 서명으로 유출되어 크고 무서워진다는 것입니다. 그러나 사용자에게 기본적으로 map? 의 전체 유형 서명이 표시되어서는 안됩니다 . 어떻게 그녀가 고개를 경우에 대해 mapBitSet그녀 가지고 :

map(f: Int => Int): BitSet     (click here for more general type)

이 경우 문서는 사용자 관점에서 실제로 유형이 있기 때문에 문서에 포함되지 않습니다 (Int => Int) => BitSet. 그러나 map다른 링크를 클릭하여 검사 할 수있는보다 일반적인 유형도 있습니다.

아직 도구에서 이와 같은 기능을 구현하지 않았습니다. 그러나 나는 사람들을 겁내지 않고 더 유용한 정보를 제공하기 위해 이것을해야한다고 생각합니다. 이와 같은 도구를 사용하면 스마트 프레임 워크와 라이브러리가 자살 메모가되지 않기를 바랍니다.


답변

나는 박사 학위가 없으며 CS 나 수학 또는 다른 분야에서도 학위가 없습니다. 스칼라 나 다른 유사한 언어에 대한 사전 경험이 없습니다. 원격으로 비교 가능한 유형의 시스템조차 경험이 없습니다. 사실, 심지어 어느 단지 피상적 인 지식보다 더 가지고있는 유일한 언어 타입 시스템은 정확히 정교한 타입의 시스템에 알려져 있지 파스칼이다. (가 있지만 않습니다 AFAIK 꽤 많이 다른 언어가 범위 유형을 가지고 있지만, 여기서는 정말 관련이 없습니다.) 내가 아는 다른 3 개 국어 심지어 타입 시스템이 어느 것도 BASIC, 스몰 토크와 루비입니다.

그럼에도 불구하고 나는 map당신이 게시 한 기능 의 서명을 전혀 이해하지 못했습니다 . 그것은 map내가 본 모든 다른 언어로 된 것과 거의 동일한 서명처럼 보입니다. 차이점은이 버전이 더 일반적이라는 것입니다. Haskell보다 C ++ STL과 비슷합니다. 특히,이 인수는을 요구하여 콘크리트 수집 유형 IterableLike에서 추상화하고, 결과 값 모음에서 무언가 를 생성 할 수있는 암시 적 변환 함수 만 필요로함으로써 콘크리트 반환 유형에서 추상화 합니다. 예, 그것은 매우 복잡하지만 실제로는 일반 프로그래밍의 일반적인 패러다임의 표현 일뿐입니다. 실제로 필요하지 않은 것은 가정하지 마십시오.

이 경우 map실제로 는 컬렉션이 목록이거나 순서가 있거나 정렬 가능하거나 이와 비슷한 것이 될 필요 는 없습니다 . map관심 이있는 유일한 것은 컬렉션의 모든 요소에 차례로 액세스 할 수 있지만 특별한 순서는 없다는 것입니다. 결과 컬렉션이 무엇인지 알 필요가 없으며 컬렉션을 만드는 방법 만 알면됩니다. 이것이 타입 시그니처에 필요한 것입니다.

그래서 대신

map :: (a → b)[a][b]

있는 전통적인 형태의 서명이다 map, 그것은 콘크리트를 필요로하지에 일반화 List아니라, 단지 IterableLike데이터 구조

map :: (IterableLike i, IterableLike j)(a → b) → i → j

그런 다음 결과를 사용자가 원하는 데이터 구조 로 변환 할 수있는 함수 만 있으면됩니다 .

map :: IterableLike i ⇒ (a → b) → i → ([b] → c) → c

문법이 약간 복잡하지만 시맨틱은 동일합니다. 기본적으로

def map[B](f: (A) ⇒ B): List[B]

에 대한 전통적인 서명입니다 map. (Scala의 객체 지향적 특성으로 인해 입력 목록 매개 변수가 이제 단일 디스패치 OO 시스템의 모든 메소드가 갖는 암시 적 수신자 매개 변수이기 때문에 어떻게 사라지는 지 확인하십시오. 그런 다음 콘크리트 List에서보다 일반적인 것으로 일반화했습니다.IterableLike

def map[B](f: (A) ⇒ B): IterableLike[B]

이제 IterableLike결과 콜렉션을 실제로 거의 모든 것을 생성 하는 함수로 대체합니다 .

def map[B, That](f: A ⇒ B)(implicit bf: CanBuildFrom[Repr, B, That]): That

어떤 정말 생각없는 것을 열심히 이해. 실제로 필요한 몇 가지 지적 도구가 있습니다.

  1. 당신은 (대략) 무엇인지 알아야 map합니다. 메소드의 이름이없는 유형 서명 주면 어떤 일이 일어나고 있는지 파악하기가 훨씬 어려울 것입니다. 하지만 당신은 이미부터 알고 무엇을 map신속, 이상 현상의 서명과 초점을 검색 할 수 있습니다, 어떻게해야한다, 당신은 그 타입의 서명이 있어야하는데 무엇인지와 같은 “왜합니까 map인수로 두 가지 기능이 아니라 하나의 테이크를?”
  2. 실제로 유형 서명을 읽을 수 있어야합니다 . 그러나 이전에 Scala를 본 적이 없어도 실제로 다른 언어에서 이미 알고있는 유형 구문의 혼합이기 때문에 매우 쉽습니다 .VB.NET은 매개 변수 다형성에 대괄호를 사용하고 화살표를 사용하여 이름과 형식을 구분하는 반환 형식과 콜론은 실제로 표준입니다.
  3. 일반적인 프로그래밍이 무엇인지 대략 알아야합니다. (하지 않는 것을 그것은 기본적으로 모든 이름에서 철자 이후 하드는 파악하기 : 말 그대로 그냥 일반적인 방식으로 프로그래밍 것).

이 세 가지 중 어느 것도 전문 또는 취미 애호가 프로그래머에게 심각한 두통을주지 않아야합니다. map지난 50 년 동안 디자인 된 거의 모든 언어에서 표준 기능으로 사용되었습니다. HTML과 CSS를 사용하여 웹 사이트를 디자인 한 사람에게는 다른 언어가 다른 구문을 가지고 있다는 사실이 분명하므로 원격 프로그래밍도 구독 할 수 없습니다. St. Stepanov 교회의 성가신 C ++ 팬 보이가없는 관련 메일 링리스트는 일반 프로그래밍의 장점을 설명합니다.

예, 스칼라 복잡합니다. 예, 스칼라는 Haskell, Miranda, Clean 또는 Cyclone과 같은 언어를 능가하고 심지어 능가하는 사람에게 알려진 가장 정교한 유형 시스템 중 하나입니다. 그러나 프로그래밍 언어의 성공에 대한 복잡성이 논쟁의 여지가 있다면 C ++은 오래 전에 죽었을 것이며 우리는 모두 Scheme을 작성할 것입니다. 스칼라가 성공하지 못하는 데는 여러 가지 이유가 있지만, 키보드 앞에 앉기 전에 프로그래머가 두뇌를 켜는 데 방해가 될 수 없다는 사실은 아마도 주요한 것이 아닐 것입니다.


답변

C ++ 에서 같은 것 :

template <template <class, class> class C,
          class T,
          class A,
          class T_return,
          class T_arg
              >
C<T_return, typename A::rebind<T_return>::other>
map(C<T, A> &c,T_return(*func)(T_arg) )
{
    C<T_return, typename A::rebind<T_return>::other> res;
    for ( C<T,A>::iterator it=c.begin() ; it != c.end(); it++ ){
        res.push_back(func(*it));
    }
    return res;
}


답변

글쎄, 나는 당신의 고통을 이해할 수 있지만, 솔직히 말해서, 당신과 나 같은 사람들 (또는 거의 일반 스택 오버플로 사용자)은 규칙이 아닙니다.

내가 의미하는 바는 … 대부분의 프로그래머는 그 타입 시그니처를 신경 쓰지 않을 것입니다 . 그들은 문서를 읽지 않습니다.

코드 작동 방식에 대한 몇 가지 예를보고 코드가 예상 결과를 생성하는 데 실패하지 않는 한 문서를 보지 않습니다. 실패하면 문서를보고 맨 위에 사용 예가 표시 될 것으로 예상됩니다 .

이러한 점을 염두에두고 다음과 같이 생각합니다.

  1. 해당 유형 서명을 발견 한 사람 (대부분의 사람들과 마찬가지로)은 Scala를 미리 처분하면 끝없이 스칼라를 조롱하고 스칼라를 좋아한다면 스칼라의 힘의 상징으로 간주합니다.

  2. 사용 예제를 제공하고 방법이 무엇인지, 사용법을 명확하게 설명하기 위해 설명서가 향상되지 않은 경우 스칼라 채택을 다소 방해 할 수 있습니다.

  3. 장기적으로는 중요하지 않습니다. Scala Scala 를 위해 작성된 라이브러리를 훨씬 강력하고 안전하게 사용할 수 있도록하는 것과 같은 작업을 수행 할 수 있습니다. 이러한 라이브러리와 프레임 워크는 강력한 도구를 찾는 프로그래머를 끌어들일 것입니다.

  4. 단순성과 직접성을 좋아하는 프로그래머는 PHP 또는 유사한 언어를 계속 사용합니다.

아아, Java 프로그래머는 전력 도구에 많이 익숙하기 때문에 주류 스칼라 채택에 대한 기대를 수정했습니다. 스칼라가 주류 언어가 될 것이라는 데는 의심의 여지가 없습니다. C-mainstream은 아니지만 Perl-mainstream 또는 PHP-mainstream 일 수 있습니다.

Java에 대해 말하면 클래스 로더를 교체 한 적이 있습니까? 그게 무슨 일이 있었는지 본 적이 있습니까? 프레임 워크 작성자가하는 장소를 보면 Java가 무서울 수 있습니다. 대부분의 사람들은 그렇지 않습니다. 스칼라, IMHO에도 동일하게 적용되지만 얼리 어답터는 자신이 직면 한 각 암석을 살펴보고 숨어있는 것이 있는지 확인하는 경향이 있습니다.


답변

이것이 사람들을 스칼라로 데려다 줄까?

그렇습니다. 그러나 사람들이 해고되는 것을 막을 수도 있습니다. 나는 Scala가 더 높은 종류의 유형에 대한 지원을 얻은 이후로 더 높은 종류의 유형을 사용하는 컬렉션의 부족이 주요 약점이라고 생각했습니다. API 문서를 더 복잡하게 만들지 만 실제로 사용을 더 자연스럽게 만듭니다.

이것은 상업계에서 스칼라에게 전념 박사 과정 학생들 만 이해할 수있는 학문적 놀이로 나쁜 이름을 줄 것입니까? CTO와 소프트웨어 책임자가 무서워 질까요?

아마 것입니다. 스칼라가 많은 “전문”개발자들에게 접근 할 수 없다고 생각합니다. 그러한 개발자를 고용하는 CTO는 당황 할 것입니다.

도서관 재 설계가 현명한 생각 이었습니까?

물론. 그래도 가장자리가 거칠더라도 나머지 언어 및 유형 시스템에 더 잘 어울립니다.

스칼라를 상업적으로 사용하고 있다면 이것에 대해 걱정하고 있습니까? 2.8을 즉시 채택하거나 어떤 일이 일어나기를 기다릴 계획입니까?

상업적으로 사용하지 않습니다. 버그를 플러시 할 수 있도록 적어도 몇 개의 2.8.x 시리즈가 나올 때까지 기다릴 것입니다. 또한 EPFL이 개발 프로세스를 개선하는 데 얼마나 많은 성공을 거두 었는지 기다릴 것입니다. 내가보고있는 것은 희망적이지만 보수적 인 회사에서 일하고 있습니다.

“스칼라가 주류 개발자에게는 너무 복잡한가?”의 가장 일반적인 주제 중 하나는 …

주류 또는 그 밖의 대부분의 개발자는 기존 시스템을 유지 관리하거나 확장하고 있습니다. 이것은 그들이 사용하는 대부분이 오래 전에 내려진 결정에 의해 지시됨을 의미합니다. COBOL을 작성하는 사람들은 여전히 ​​많습니다.

내일의 주류 개발자는 현재 구축중인 응용 프로그램을 유지 관리하고 확장 할 것입니다. 이러한 응용 프로그램 중 다수는 주류 개발자가 작성하지 않습니다. 내일의 주류 개발자는 오늘날 가장 성공적인 새로운 응용 프로그램 개발자가 사용하는 언어를 사용합니다.


답변

스칼라 커뮤니티가 스칼라를 처음 접하는 프로그래머들의 두려움을 덜어 줄 수있는 한 가지 방법은 연습에 초점을 맞추고 예를 들어 가르치는 것입니다. 이 접근 방식을 취하는 몇 가지 사이트는 다음과 같습니다.

이 사이트에서 시간을 보낸 후에는 Scala와 라이브러리가 설계 및 구현이 어려울지라도 특히 일반적인 경우에 사용하기가 어렵지 않다는 것을 빨리 알게됩니다.


답변

나는 저렴한 “대량 시장”미국 대학에서 학사 학위를 받았기 때문에 사용자 지능 (또는 최소한 교육) 규모의 중간에 빠졌다고 말하고 싶습니다. 2 ~ 3 개의 사소한 앱에서 작업했습니다.

특히 IntelliJ가 IMHO가 현재 최고의 스칼라 플러그인으로 훌륭한 IDE를 출시했기 때문에 스칼라 개발은 비교적 어려움이 없습니다.

  • 스칼라를 “세미콜론이없는 자바”로 사용할 수 있다는 것을 알았습니다. 즉, Java에서하는 것과 비슷한 모양의 코드를 작성하고 형식 유추로 얻은 것과 같은 구문 간결함에서 약간의 이점을 얻습니다. 예외 처리는 내가 할 때 더 편리합니다. 클래스 정의는 getter / setter 상용구가 없으면 훨씬 덜 장황합니다.

  • 때때로 나는 여러 줄의 Java와 동등한 것을 달성하기 위해 한 줄을 쓸 수 있습니다. 해당되는 경우 맵, 접기, 수집, 필터 등과 같은 기능적 방법의 체인은 작성하기에 재미 있고 우아합니다.

  • 스칼라의보다 강력한 기능인 클로저 및 부분 (또는 커리 기능), 패턴 일치 등의 이점을 얻을 수있는 경우는 거의 없습니다.

초보자로서, 간결하고 관용적 인 구문으로 계속 고심하고 있습니다. 매개 변수가없는 메서드 호출은 필요한 경우를 제외하고 괄호가 필요하지 않습니다. match 구문의 경우에는 굵은 화살표 ( =>)가 필요하지만 얇은 화살표 ( ->) 가 필요한 곳도 있습니다 . 많은 방법과 같은 짧은 아니라 암호 같은 이름이 /:또는 \:내가 충분히 매뉴얼 페이지를 플립 만약 내가 내 물건을 끝낼 수 있지만, 펄 또는 라인 노이즈처럼 보이는까지 내 코드의 끝 부분의 일부 -. 아이러니하게도, 가장 많이 사용되는 구문 속기 중 하나가 실제로 누락되었습니다. 나는 방법을 Int정의하지 않는 사실에 계속 물고 ++있습니다.

스칼라는 C ++의 복잡성과 가독성과 결합 된 C ++의 힘을 가지고 있다고 생각합니다. 언어의 구문상의 복잡성으로 인해 API 문서를 읽기가 어렵습니다.

스칼라는 많은면에서 매우 잘 생각 되고 훌륭합니다. 많은 학자가 프로그램을 만들고 싶어하는 것 같습니다. 그러나 그것은 또한 영리함과 어려움으로 가득 차 있으며 Java보다 훨씬 높은 학습 곡선을 가지고 있으며 읽기가 어렵습니다. 필자가 fora를 스캔하고 여전히 얼마나 많은 개발자들이 Java의 훌륭한 요점으로 어려움을 겪고 있는지 알면 Scala가 주류 언어가되는 것을 상상할 수 없습니다 . 이전에는 1 주일 Java 코스 만 필요했던 3 주 스칼라 코스에서 개발자를 보내는 것을 정당화 할 수있는 회사는 없습니다.