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? 의 전체 유형 서명이 표시되어서는 안됩니다 . 어떻게 그녀가 고개를 경우에 대해 map에 BitSet그녀 가지고 :

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 주 스칼라 코스에서 개발자를 보내는 것을 정당화 할 수있는 회사는 없습니다.

그 방법의 주요 문제는 (implicit bf : CanBuildFrom[Repr, B, That])설명없이 진행 된다는 것입니다. 암시적인 인수가 무엇인지 알고 있지만 이것이 호출에 미치는 영향을 나타내는 것은 없습니다. scaladoc을 쫓는 것은 나를 더 혼란스럽게 만듭니다 ( CanBuildFrom문서를 가지고 있는 클래스는 거의 없습니다 ).

" 반환 유형 bf으로 유형의 객체에 대한 빌더를 제공하기 위해 범위에 암시 적 객체가 있어야한다"는 간단한 생각이 있지만, 실제로하고 싶은 것은 map 's '에스. 사실, 그 유형이 무엇을 의미 하는지 모르기 때문에 문서가 확실하지 않습니다.BThatABReprTraversable

그래서 두 가지 옵션이 남았습니다.

• 기존지도가 작동하는 방식과 대부분의 다른 언어로지도가 작동하는 방식으로 작동한다고 가정합니다.
• 좀 더 소스 코드를 파고

나는 Scala가 본질적으로 이러한 것들이 어떻게 작동하는지에 대한 장을 드러내고 궁극적으로 이것이 oxbow_lakes가 묘사하는 것을 할 수있는 방법을 제공한다는 것을 알게되었습니다. 그러나 그것은 서명의 산만하다.

나는 스칼라 초보자이며 솔직히 그 유형 서명에 문제가 보이지 않습니다. 매개 변수는 맵핑 할 함수이고 빌더가 올바른 콜렉션을 리턴하기위한 내재적 매개 변수입니다. 명확하고 읽을 수 있습니다.

실제로 모든 것이 매우 우아합니다. 빌더 유형 매개 변수는 컴파일러가 올바른 리턴 유형을 선택할 수 있도록하는 반면 내재적 매개 변수 메커니즘은이 추가 매개 변수를 클래스 사용자로부터 숨 깁니다. 나는 이것을 시도했다 :

Map(1 -> "a", 2 -> "b").map((t) => (t._2) -> (t._1)) // returns Map("a" -> 1, "b" -> 2)
Map(1 -> "a", 2 -> "b").map((t) =>  t._2)            // returns List("a", "b")

다형성이 제대로 이루어졌습니다.

이제는 주류 패러다임이 아니며 많은 사람들을 놀라게 할 것입니다. 그러나 표현력과 우아함을 소중히 여기는 많은 사람들을 끌어들일 것입니다.

안타깝게도 귀하가 제공 한지도의 서명은지도에 대한 서명이 아니며 합법적 인 비판이 있습니다.

첫 번째 비판은 map의 서명을 전복함으로써보다 일반적인 것이 있다는 것입니다. 이것이 기본적으로 미덕이라고 믿는 것은 일반적인 오류입니다. 그렇지 않습니다. 맵 함수는 공변량 펑터 Fx-> (x-> y)-> Fy로 잘 정의되어 있으며 구성과 정체성의 두 가지 법칙을 준수합니다. "지도"에 기여하는 다른 것은 비극입니다.

주어진 서명은 다른 것이지만 맵이 아닙니다. 내가 시도하고 있다고 생각하는 것은 이터레이터 패턴의 정수라는 논문의 "횡단"서명의 특수하고 약간 변경된 버전입니다. 서명은 다음과 같습니다.

traverse :: (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b)

스칼라로 변환합니다.

def traverse[A, B](f: A => F[B], a: T[A])(implicit t: Traversable[T], ap: Applicative[F]): F[T[B]

물론 실패합니다-그것은 일반적이지 않습니다! 또한 약간 다릅니다 (ID functor를 통해 트래버스를 실행하여 맵을 얻을 수 있음). 그러나 라이브러리 작성자가 잘 문서화 된 라이브러리 일반화에 대해 더 많이 알고 있다면 (효과가있는 응용 프로그래밍이 앞에서 언급 한 것)이 오류가 표시되지 않습니다.

둘째,지도 기능은 이해를 위해 사용하기 때문에 스칼라에서 특별한 경우입니다. 불행히도 더 잘 갖추어 진 도서관 디자이너는 이해의 구문 설탕을 희생하지 않으면 서이 오류를 무시할 수 없다는 것을 의미합니다. 다시 말해서, Scala 라이브러리 디자이너가 메소드를 파괴해야한다면, 이것은 쉽게 무시되지만 맵핑하지 마십시오!

누군가가 그것에 대해 이야기하기를 바랍니다. 왜냐하면 스칼라가 주장하는 오류를 해결하기가 더 어려워 질 것입니다. 즉, "일반 프로그래머의 무책임한 이의 제기 (즉, 너무 어렵다!")에 대한 해결책은 "쉽게 만들기 위해 그들을 진정시킨다"는 것이 아니라,보다 나은 프로그래머가되기위한 지침과 도움을 제공하는 것입니다. 나 자신과 스칼라의 목표는이 문제에 대해 논쟁 중이지만, 당신의 요점으로 돌아갑니다.

당신은 아마도 "평균 프로그래머"로부터 특정 응답을 예측하면서 당신의 주장을했을 것입니다. 즉, "하지만 너무 복잡하다"고 주장 할 사람들입니다. 또는 그러한 것들. 이들은 당신이 말하는 Yegges 또는 Blochs입니다. 이러한 반지 능주의 / 실용주의 운동에 대한 나의 반응은 매우 가혹하며 이미 반응의 포효를 기대하고 있으므로 생략하겠습니다.

스칼라 라이브러리가 개선되기를 바랍니다. 최소한 오류가 안전하게 사라질 수 있기를 바랍니다. Java는 "유용한 작업을 수행하려고 시도하는"작업이 매우 비용이 많이 드는 언어이므로 압도적 인 오류를 피할 수 없기 때문에 종종 가치가 없습니다. 나는 스칼라가 같은 길로 가지 않도록 간청합니다.

나는 질문과 Martin의 대답에 완전히 동의합니다 :). Java에서도 제네릭으로 javadoc을 읽는 것은 추가 노이즈로 인한 것보다 훨씬 어렵습니다. 이것은 질문의 예제 코드에서와 같이 암시 적 매개 변수가 사용되는 스칼라에서 합성됩니다 (암시 적은 매우 유용한 컬렉션 모핑 작업을 수행함).

언어 자체에 문제가 있다고 생각하지 않습니다. 도구 관련 문제가 더 있다고 생각합니다. 그리고 Jörg W Mittag가 말한 것에 동의하지만 scaladoc (또는 IDE의 유형 문서)을보고 있다고 생각합니다. 메서드가 무엇인지, 무엇이 걸리고 반환되는지 파악하는 데 가능한 적은 두뇌 능력이 필요합니다. 그것을 얻기 위해 약간의 종이에 약간의 대수학을 해킹 할 필요가 없습니다 :)

확실히 IDE는 변수 / 표현식 / 유형에 대한 모든 메소드를 표시 할 수있는 좋은 방법이 필요합니다 (마틴의 예제와 마찬가지로 모든 제네릭에 인라인을 적용 할 수 있으므로 멋지고 쉽게 사용할 수 있습니다). 나는 기본적으로 암시 적을 숨기려는 Martin의 아이디어를 좋아합니다.

scaladoc에서 예를 들자면 ...

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

scaladoc에서 이것을 볼 때 일반 블록 [B, That]이 기본적으로 숨겨져 있고 암시 적 매개 변수 (마우스로 작은 아이콘을 가리키면 표시 될 수 있음)-grok에 추가 항목으로 표시하고 싶습니다. 일반적으로 관련이없는 그것을 읽으십시오. 예를 들어 이것이 어떻게 생겼는지 상상해보십시오.

def map(f: A => B): That

좋고 명확하고 명백한 일. '그것'이 무엇인지 궁금 할 수도 있습니다. 마우스를 올리거나 클릭하면 '그것'을 강조하는 [B, That] 텍스트가 확장 될 수 있습니다.

어쩌면 작은 아이콘이 [] 선언과 (암시 적 ...) 블록에 사용될 수 있으므로 문이 약간 축소 된 것이 분명합니까? 토큰을 사용하기는 어렵지만을 사용할 것입니다. 지금은 ...

def map.(f: A => B).: That

따라서 기본적으로 유형 시스템의 '노이즈'는 사람들이 볼 필요가있는 주요 80 % (메소드 이름, 매개 변수 유형 및 반환 유형)가 간결하고 간결한 방식으로 숨겨져 있습니다. 당신이 정말로 그렇게 많이 걱정한다면.

대부분의 사람들은 유형에 대해 호출 할 수있는 메소드와 전달할 수있는 매개 변수를 찾기 위해 스칼라 독을 읽고 있습니다. 우리는 IMHO 방법에 대해 너무 많은 세부 사항으로 사용자에게 과부하를 가하고 있습니다.

다른 예가 있습니다 ...

def orElse[A1 <: A, B1 >: B](that: PartialFunction[A1, B1]): PartialFunction[A1, B1]

이제 제네릭 선언을 숨기면 쉽게 읽을 수 있습니다.

def orElse(that: PartialFunction[A1, B1]): PartialFunction[A1, B1]

그런 다음 사람들이 A1을 가리키면 A1의 선언을 A1 <: A로 표시 할 수 있습니다. 제네릭의 공변량 및 반 변형 유형은 많은 소음을 추가하여 사용자가 생각하기 쉬운 방식으로 렌더링 할 수 있습니다.

나는 그것을 당신에게 나누는 방법을 모르겠지만, 캠브리지에서 박사 학위를 받았으며 2.8을 잘 사용하고 있습니다.

더 진지하게, 나는 2.7 (내가 사용중인 Java 라이브러리와 상호 작용하지 않을 것)으로 거의 시간을 보냈지 않고 한 달 전에 Scala를 사용하기 시작했다. 나는 Haskell에 대한 경험이 많지 만 (걱정하지는 않지만) 걱정하는 것을 무시하고 Java에 대한 내 경험과 일치하는 메소드를 찾았습니다 (생존에 사용).

그래서 : 나는 "새로운 사용자"이며 연기되지 않았습니다 .Java처럼 작동한다는 사실은 내가 이해하지 못하는 비트를 무시할만큼 충분한 자신감을 얻었습니다.

(그러나, Scala를보고있는 이유는 부분적으로 직장에서 그것을 밀어야하는지 여부를 확인하는 것이 었으므로 아직 그렇게하지는 않을 것입니다. 문서를 덜 협박하는 것은 확실히 도움이 될 것입니다. 변화와 발전 (내가 가장 놀랐던 것이 공평하다는 것이 공평하지만, 그 변화는 두 번째로 다가온 것입니다.) 그래서 나는 말하는 것이 제한된 자원이 그것을 받아들이는 것보다 오히려 선호한다고 생각합니다 최종 상태-나는 그들이 곧이 인기가 될 것이라고 생각하지 않습니다.)

스칼라를 전혀 모르지만 몇 주 전에 Clojure를 읽을 수 없었습니다. 이제 대부분의 내용을 읽을 수 있지만 가장 간단한 예제 이외의 내용은 쓸 수 없습니다 . 스칼라도 다르지 않다고 생각합니다. 배우는 방법에 따라 좋은 책이나 코스가 필요합니다. 그냥 읽기 지도의 위의 선언을, 내가 가지고 어쩌면 그것의 1/3.

더 큰 문제는 이러한 언어의 구문이 아니라 일상적인 프로덕션 코드에서 사용할 수 있는 패러다임 을 채택하고 내재화하는 것 입니다. 나를 위해 자바 등 파스칼의 모든에서 도약하지 않았다 C,도 기본에서 큰 도약이 아니었다 C ++에서 큰 도약이 아니었다 ...하지만 Clojure에서 같은 기능의 언어로 코딩 이다 (대한 거대한 도약 어쨌든). 스칼라에서는 Java 스타일 또는 Scala 스타일로 코딩 할 수 있다고 생각합니다. 그러나 Clojure에서는 당신의 명령적인 습관을 Java로부터 지키려고 노력하는 엉망이 될 것입니다.

스칼라는 매우 복잡하고 학문적으로 보이지만 물건을 쉽게 사용할 수 있도록 설계된 많은 미친 기능 (특히 암시 적 매개 변수가 관련된 경우)을 가지고 있습니다. 가장 유용한 것들은 구문 설탕을 얻습니다 (예 [A <% B]를 들어 A 유형의 객체가 B 유형의 객체로 암시 적으로 변환됨을 의미합니다). 그러나 대부분 이러한 라이브러리의 클라이언트 인 경우 암시 적 매개 변수를 무시하고 올바른 작업을 수행하도록 신뢰할 수 있습니다.

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

스칼라는 많은 힘을 가지고 있으며 구문이 Haskell, OCaml, SML, Lisps와 같은 Java / C ++ / PHP 프로그래머에게는 외국 적이 지 않기 때문에 스칼라가 인기를 얻는 방법에 영향을 미치는 주요 요인이라고 생각하지 않습니다. 기타..

그러나 스칼라의 인기는 오늘날의 Java보다 적은 수준으로 정체 될 것이라고 생각합니다. 왜냐하면 다음 주류 언어가 훨씬 단순화되어야한다고 생각하기 때문에 HTML을 선언하는 순수한 불변성, 즉 튜링이 완료됩니다. . 그러나 그러한 언어를 개발하고 있기 때문에 편견이 있지만 몇 달 동안 연구를 마친 후에야 Scala가 필요한 것에 충분하지 않다고 생각했습니다.

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

나는 스칼라의 명성이 하스켈 단지로 고통받을 것이라고 생각하지 않습니다. 그러나 일부 프로그래머는 스칼라를 사용하도록 강요하는 유스 케이스를 아직 보지 못했기 때문에 학습을 미룰 것이라고 생각합니다. 확장 성이 뛰어난 서버 쪽이 가장 강력한 사용 사례 일 것입니다.

그리고 주류 시장에서 첫 번째 학습 Scala는 "신선한 공기의 숨결"이 아니며 HTML이나 Python을 사용하는 등의 프로그램을 즉시 작성하는 것입니다. 스칼라는 처음부터 우연히 발견되는 모든 세부 사항을 알게 된 후에 성장하는 경향이 있습니다. 그러나 처음부터 Scala에서 프로그래밍을 읽었다면 학습 곡선에 대한 나의 경험과 의견이 달라졌을 것입니다.

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

명확히.

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

새 언어의 초기 플랫폼으로 스칼라를 사용하고 있습니다. 스칼라를 상업적으로 사용하고 있다면 스칼라 수집 라이브러리에서 코드를 작성하지 않았을 것입니다. 나는 한 번 보았을 때 Scalaz의 유형 서명이 Scala의 수집 라이브러리보다 훨씬 더 장황하고 다루기 힘들다는 것을 알았으므로 나만의 범주 이론 기반 라이브러리를 만들 것입니다. 그 문제의 일부는 아마도 스칼라가 타입 클래스를 구현하는 방법 일 것입니다. 이것이 제가 제 자신의 언어를 만드는 작은 이유입니다.

나는이 답변을 쓰기로 결정했다. 왜냐하면 나는 스칼라의 컬렉션 클래스 디자인을 내가 사용하는 언어와 비교하여 연구하고 비교하기를 원했기 때문이다. 내 사고 과정을 공유 할 수도 있습니다.

빌더 추상화를 사용하는 2.8 Scala 컬렉션은 건전한 디자인 원칙입니다. 아래의 두 가지 디자인 트레이드 오프를 살펴보고 싶습니다.

1. 쓰기 전용 코드 :이 섹션을 작성한 후, 나는 트레이드 오프가 될 것으로 예상되는 것에 동의하는 Carl Smotricz의 의견 을 읽었습니다 . 제임스 스트라 찬 (James Strachan)과 davetron5000의 의견은 그것의 의미 (그것도 [B]조차 아님)와 암묵의 메커니즘이 직관적으로 이해하기 쉽지 않다고 동의합니다. 아래 이슈 2에서 monoid 사용을 참조하십시오. Derek Mahar의 의견은 스칼라를 작성하는 것에 관한 것이지만 "일반적인 경우"가 아닌 다른 사람들의 스칼라를 읽는 것에 대해서는 어떻습니까.

   스칼라에 대해 읽은 한 가지 비판은 다른 사람들이 작성한 코드를 읽는 것보다 작성하기가 쉽다는 것입니다. 그리고 나는 여러 가지 이유로 (예를 들어 함수를 작성하는 많은 방법, 자동 폐쇄, DSL 용 단위 등) 때때로 이것이 사실이라는 것을 알지만 이것이 주요 요인인지 여부는 미정입니다. 여기서 암시 적 함수 매개 변수 사용에는 장점과 단점이 있습니다. 플러스 측면에서는 상세도를 줄이고 빌더 오브젝트 선택을 자동화합니다. 오더 스키의 예에서BitSet, 즉 Set [Int]에서 Set [String]으로의 변환은 암시 적입니다. 익숙하지 않은 코드를 읽는 사람은 현재 패키지 범위에 존재할 수있는 모든 잠재적 인 보이지 않는 암시 적 빌더 후보에 대해 충분히 추론 할 수 없다면 컬렉션 유형이 무엇인지 쉽게 알지 못할 수 있습니다. 물론 숙련 된 프로그래머와 코드 작성자는 BitSet이 Int로 제한되어 있으므로 String에 대한 맵이 다른 컬렉션 유형으로 변환되어야한다는 것을 알 것입니다. 그러나 어떤 컬렉션 유형입니까? 명시 적으로 지정되지 않았습니다.

2. AD-HOC COLLECTION DESIGN :이 섹션을 작성한 후, Tony Morris의 의견을 읽고 거의 같은 요점을하고 있음을 깨달았습니다. 아마도 더 장황한 설명이 그 요점을 더 명확하게 만들 것입니다.

   "유형의 파이팅 비트 썩음"Odersky & Moors에는 두 가지 사용 사례가 있습니다. 그것들은 Int 요소에 대한 BitSet 및 튜플 요소 쌍에 대한 맵의 제한 사항이며 일반 요소 맵핑 기능 A => B가 대체 대상 콜렉션 유형을 빌드 할 수 있어야하기 때문에 제공됩니다. 그러나 이것은 카테고리 이론의 관점에서 결함이 있습니다. 범주 이론에서 일관성을 유지하고 모퉁이 사례를 피하기 위해 이러한 수집 유형은 각 모티프, A => B가 동일한 functor 범주 인 List [A] => List [B], BitSet에있는 객체간에 매핑되어야하는 펑터입니다. [A] => 비트 세트 [B]. 예를 들어, Option은 하나의 Some (object)와 None 집합의 집합으로 볼 수있는 functor입니다. Option 's None 또는 List 's Nil에서 그렇지 않은 다른 functors에 대한 일반 맵은 없습니다.

   여기에서 선택된 트레이드 오프 디자인이 있습니다. 새 언어의 컬렉션 라이브러리 디자인에서 모든 것을 functor로 만들었습니다. 즉, BitSet을 구현하면 비트가 아닌 필드 내부 표현을 사용하여 모든 요소 유형을 지원해야합니다. 정수 유형 매개 변수이며 해당 기능은 이미 Scala에서 상속 된 Set에 있습니다. 그리고 내 디자인의 Map은 해당 값만 매핑해야하며 (키, 값) 쌍 튜플을 매핑하기 위해 별도의 비 functor 방법을 제공 할 수 있습니다. 한 가지 장점은 각 functor는 일반적으로 응용 적이며 아마도 모나드라는 것입니다. 따라서 요소 유형 사이의 모든 기능 (예 : A => B => C => D => ...)은 리프팅 된 적용 유형 사이의 함수 (예 : List [A] => List [B] => List [ C] => 목록 [D] => .... functor에서 다른 컬렉션 클래스로 매핑하기 위해 Nil, None, 0, "", Array () 등과 같은 monoid를 사용하는 맵 오버로드를 제공합니다. 따라서 빌더 추상화 함수는 monoid의 append 메소드입니다. 은 필수 입력 매개 변수로 명시 적으로 제공되므로 보이지 않는 암시 적 변환은 없습니다. (탄젠트 :이 입력 매개 변수를 사용하면 스칼라의 맵 디자인에서는 수행 할 수없는 비어 있지 않은 모노 아이디를 추가 할 수 있습니다.) 이러한 변환은 맵과 동일한 반복 패스의 접기입니다. 또한 범주 의미에서 "효과가있는 응용 프로그램 프로그래밍"McBride & Patterson의 트래버스 가능 기능을 제공합니다. McBride & Patterson은 모든 트래버스 블에서 모든 응용 프로그램까지 단일 반복 패스에서 맵 + 접기를 가능하게합니다. 대부분의 모든 컬렉션 클래스는 둘 다입니다.

   그래서 스칼라 컬렉션은 카테고리 이론에 근거하지 않고, 카테고리 이론은 상위 수준의 의미 론적 의미의 본질이라는 의미에서 "임시 (ad-hoc)"이다. Scala의 암시 적 빌더는 처음에는 functor 모델 + monoid builder + traversable-> applicative보다 "일반화 된"것처럼 보이지만 어떤 카테고리와도 일치하지 않는 것으로 판명되었으므로 어떤 규칙을 따르는 지 알 수 없습니다. 가장 일반적인 의미와 코너 사례는 어떤 카테고리 모델에도 적용되지 않을 수 있습니다. 더 많은 변수를 추가하는 것이 더 일반적인 것을 만드는 것은 사실이 아니며, 이것은 범주 이론의 큰 장점 중 하나였습니다. 이는 높은 수준의 의미로 들어 올리면서 일반성을 유지하는 규칙을 제공한다는 것입니다. 컬렉션은 카테고리입니다.

   라이브러리 디자인에 대한 또 다른 정당화로서 Odersky라고 생각합니다. 순수한 기능 스타일로 프로그래밍하는 것은 꼬리 재귀를 사용하지 않는 제한된 재귀 및 속도의 비용이 든다는 것입니다. 지금까지 만난 모든 경우에 꼬리 재귀를 사용하는 것이 어렵다는 것을 알지 못했습니다.

또한 나는 스칼라의 트레이드 오프 중 일부가 예를 들어 Haskell이나 내가 개발중인 언어와 달리 변하기 쉬운 언어와 변하지 않는 언어 둘 다가되어야한다는 불완전한 생각을 떠올리고 있습니다. 이것은 이해에 대한 Tony Morris의 의견과 일치합니다. 내 언어에는 루프와 가변 구성이 없습니다. 내 언어는 스칼라 (현재) 위에 있고 그에 많이 의존해야하며 스칼라에 일반적인 유형 시스템과 가변성이 없다면 불가능합니다. Odersky & Moors ( "Fighting Bit Rot with Types")가 Scala가 유일한 종류의 OOP 언어라고 말하는 것은 틀렸다고 생각하기 때문에 사실이 아닐 수도 있습니다. ML에 있습니다. 또한 SML의 유형 시스템은 1980 년대 이후로 똑같이 융통성이있을 수 있습니다. 구문은 Scala와 같이 Java (및 C ++ / PHP)와 그다지 유사하지 않기 때문에 쉽게 이해할 수 없습니다. 어쨌든 이것은 스칼라에 대한 비판이 아니라 트레이드 오프에 대한 불완전한 분석을 제시하려는 시도입니다. 스칼라와 SML은 하스켈의 무능력으로 고통받지 않습니다.다이아몬드 다중 상속 은 중요하며 Haskell Prelude의 많은 기능이 다른 유형에 대해 반복되는 이유입니다.

정치학 학사와 컴퓨터 과학 학사 학위를 여기에 1 단계로 명시해야합니다.

요점 :

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

스칼라는 기본 프로그래밍 패러다임이 어렵 기 때문에 어렵다. 함수형 프로그래밍은 많은 사람들을 두려워합니다. PHP에서 클로저를 만들 수는 있지만 사람들은 거의하지 않습니다. 따라서이 서명이 아니라 나머지 모든 사람들이 근본적인 패러다임의 힘을 소중히 할 수있는 구체적인 교육을받지 않으면 사람들을 떠나게 할 것입니다.

이 교육이 가능하다면 누구나 할 수 있습니다. 작년에 나는 SCALA에 많은 학교 아이들과 함께 체스 컴퓨터를 만들었습니다! 그들은 문제가 있었지만 결국은 훌륭했습니다.

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

나는 걱정하지 않을 것입니다.

옥스포드에서 수학 학위를 받았습니다! 새로운 컬렉션 자료를 가져 오는 데 시간이 걸렸습니다. 하지만 이제는 내가 좋아하는 것을 많이 좋아합니다. 사실, 'map'의 타이핑은 2.7에서 처음으로 버그를 일으킨 가장 큰 것 중 하나였습니다.

새로운 2.8 모음에 대한 Martin의 논문을 읽으면 암시 적 사용법을 설명하는 데 실제로 도움이되었지만 문서 자체는 핵심 API의 메소드 서명 내에서 다른 종류의 암시 적 역할을 설명하는 더 나은 작업을 수행해야합니다.

나의 주요 관심사는 이것이다 : 2.8은 언제 출시 될까? 버그 리포트는 언제부터 나오지 않습니까? 스칼라 팀이 2.8로 씹을 수있는 것보다 더 많은 물린 상처를 받았습니까?

나는 새로운 것을 추가하기 전에 2.8이 릴리스를 위해 안정화 된 것을 우선적으로보고 싶습니다. 스칼라 컴파일러의 개발 로드맵이 관리되는 방식에 약간의 개선이 이루어질 수 있는지 궁금합니다.

사용 사이트의 오류 메시지는 어떻습니까?

유스 케이스는 기존 유형을 DSL에 맞는 사용자 정의 유형과 통합해야하는 경우는 언제입니까? 연관성, 우선 순위, 암시 적 변환, 암시 적 매개 변수, 더 높은 종류 및 아마도 존재 유형에 관한 교육을 받아야한다.

대부분 단순하지만 충분하지는 않다는 것을 아는 것이 매우 좋습니다. 광범위한 라이브러리를 디자인하려면 최소한이 물건을 알고있는 사람이 있어야합니다.