Có phải thư viện bộ sưu tập Scala 2.8 là một trường hợp của thư tử tự tử dài nhất trong lịch sử? [đóng cửa]

Tôi mới bắt đầu xem xét triển khai lại thư viện bộ sưu tập Scala sắp ra mắt trong phiên bản 2.8 sắp xảy ra . Những người quen thuộc với thư viện từ 2.7 sẽ nhận thấy rằng thư viện, từ góc độ sử dụng, đã thay đổi rất ít. Ví dụ...

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

... sẽ hoạt động trong cả hai phiên bản. Thư viện có thể sử dụng một cách rõ ràng : trên thực tế, nó thật tuyệt vời. Tuy nhiên, những người trước đây không quen thuộc với Scala và chọc ngoáy để cảm nhận ngôn ngữ giờ phải hiểu ý nghĩa của chữ ký phương thức như:

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

Đối với chức năng đơn giản như vậy, đây là một chữ ký đáng ngại và tôi thấy mình phải vật lộn để hiểu. Không phải tôi nghĩ Scala đã từng là Java tiếp theo (hoặc / C / C ++ / C #) - Tôi không tin rằng những người tạo ra nó đã nhắm nó vào thị trường đó - nhưng tôi nghĩ Scala chắc chắn sẽ trở nên khả thi. Ruby hoặc Python tiếp theo (nghĩa là để có được cơ sở người dùng thương mại quan trọng)

• Đây có phải là sẽ đưa mọi người đến Scala?
• Đây có phải sẽ mang lại cho Scala một tên xấu trong thế giới thương mại như một thứ đồ chơi hàn lâm mà chỉ những sinh viên tiến sĩ tận tâm mới có thể hiểu được? Có phải CTO và người đứng đầu phần mềm sẽ sợ hãi?
• Là thư viện thiết kế lại một ý tưởng hợp lý?
• Nếu bạn đang sử dụng Scala thương mại, bạn có lo lắng về điều này? Bạn đang có kế hoạch áp dụng 2.8 ngay lập tức hoặc chờ xem điều gì sẽ xảy ra?

Steve Yegge đã từng tấn công Scala (theo ý kiến ​​của tôi) vì cái mà anh ta xem là hệ thống kiểu quá phức tạp của nó. Tôi lo lắng rằng ai đó sẽ có một ngày thực địa lan truyền FUD với API này (tương tự như cách Josh Bloch sợ JCP khi thêm các lần đóng vào Java).

Lưu ý - Tôi nên nói rõ rằng, trong khi tôi tin rằng Joshua Bloch có ảnh hưởng trong việc từ chối đề xuất đóng cửa BGGA, tôi không gán điều này cho bất cứ điều gì khác ngoài niềm tin được giữ vững của anh ta rằng đề xuất đó là một sai lầm.

Mặc dù vợ và đồng nghiệp của tôi nói với tôi bất cứ điều gì, tôi không nghĩ tôi là một thằng ngốc: Tôi có bằng cấp tốt về toán học của Đại học Oxford , và tôi đã lập trình thương mại trong gần 12 năm và ở Scala trong khoảng một năm (cũng thương mại).

Lưu ý tiêu đề chủ đề gây viêm là một trích dẫn được đưa ra về tuyên ngôn của một đảng chính trị ở Anh vào đầu những năm 1980 . Câu hỏi này mang tính chủ quan nhưng đây là một câu hỏi thực sự, tôi đã đưa ra CW và tôi muốn có một số ý kiến ​​về vấn đề này.

Tôi hy vọng nó không phải là "thư tuyệt mệnh", nhưng tôi có thể thấy quan điểm của bạn. Bạn đánh vào những gì đồng thời là cả một điểm mạnh và một vấn đề của Scala: khả năng mở rộng của nó . Điều này cho phép chúng tôi thực hiện hầu hết các chức năng chính trong thư viện. Trong một số ngôn ngữ khác, các chuỗi có nội dung giống maphoặc collectsẽ được xây dựng và không ai phải xem tất cả các vòng mà trình biên dịch phải trải qua để làm cho chúng hoạt động trơn tru. Trong Scala, tất cả nằm trong một thư viện, và do đó mở ra.

Trong thực tế, chức năng của loại mapđược hỗ trợ bởi loại phức tạp của nó khá tiên tiến. Xem xét điều này:

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!)

Xem làm thế nào bạn luôn có được loại tốt nhất có thể? Nếu bạn ánh xạ Ints thành Ints, bạn sẽ nhận lại a BitSet, nhưng nếu bạn ánh xạ Ints thành Strings, bạn sẽ có một vị tướng Set. Cả kiểu tĩnh và biểu diễn thời gian chạy của kết quả bản đồ đều phụ thuộc vào loại kết quả của hàm được truyền cho nó. Và điều này hoạt động ngay cả khi tập hợp trống, vì vậy chức năng không bao giờ được áp dụng! Theo như tôi biết thì không có bộ sưu tập nào khác có chức năng tương đương. Tuy nhiên, từ góc độ người dùng, đây là cách mọi thứ được cho là hoạt động.

Vấn đề chúng ta có là tất cả các công nghệ thông minh làm cho điều này xảy ra rò rỉ vào các chữ ký loại trở nên lớn và đáng sợ. Nhưng có lẽ người dùng không nên được hiển thị theo mặc định chữ ký đầy đủ của map? Sẽ thế nào nếu cô ấy nhìn lên maptrong BitSetcô ấy:

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

Các tài liệu sẽ không nằm trong trường hợp đó, bởi vì từ góc độ người dùng thực sự bản đồ có loại (Int => Int) => BitSet. Nhưng mapcũng có một loại tổng quát hơn có thể được kiểm tra bằng cách nhấp vào một liên kết khác.

Chúng tôi chưa thực hiện chức năng như thế này trong các công cụ của chúng tôi. Nhưng tôi tin rằng chúng ta cần phải làm điều này, để tránh làm mọi người sợ hãi và cung cấp thêm thông tin hữu ích. Với các công cụ như vậy, hy vọng các khung và thư viện thông minh sẽ không trở thành ghi chú tự tử.

Tôi không có bằng tiến sĩ, cũng không có loại bằng cấp nào khác về CS cũng không phải toán cũng như bất kỳ lĩnh vực nào khác. Tôi không có kinh nghiệm trước với Scala cũng như bất kỳ ngôn ngữ tương tự nào khác. Tôi không có kinh nghiệm với các hệ thống loại so sánh từ xa. Trong thực tế, ngôn ngữ duy nhất mà tôi có nhiều hơn là một kiến ​​thức hời hợt trong đó thậm chí có một hệ thống loại là Pascal, không được biết đến chính xác với hệ thống loại tinh vi của nó. (Mặc dù nó không có các loại phạm vi, mà AFAIK khá nhiều ngôn ngữ không khác có, nhưng đó không phải là thực sự liên quan ở đây.) Ba ngôn ngữ khác mà tôi biết là BASIC, Smalltalk và Ruby, không ai trong số đó thậm chí còn có một hệ thống kiểu.

Tuy nhiên, tôi không gặp khó khăn gì trong việc hiểu chữ ký của mapchức năng bạn đã đăng. Dường như với tôi khá giống chữ ký mapcó trong mọi ngôn ngữ khác mà tôi từng thấy. Sự khác biệt là phiên bản này là chung chung hơn. Nó trông giống như một thứ C ++ STL hơn là, nói, Haskell. Cụ thể, nó trừu tượng ra khỏi loại bộ sưu tập cụ thể bằng cách chỉ yêu cầu đối số đó IterableLikevà cũng trừu tượng khỏi loại trả về cụ thể bằng cách chỉ yêu cầu tồn tại một hàm chuyển đổi ẩn có thể tạo ra thứ gì đó từ tập hợp các giá trị kết quả đó. Vâng, điều đó khá phức tạp, nhưng nó thực sự chỉ là một biểu hiện của mô hình chung về lập trình chung: đừng cho rằng bất cứ điều gì bạn không thực sự phải làm.

Trong trường hợp này, mapthực sự không cần bộ sưu tập là một danh sách, hoặc được sắp xếp hoặc có thể sắp xếp hoặc bất cứ thứ gì tương tự. Điều duy nhất mapquan tâm là nó có thể có quyền truy cập vào tất cả các yếu tố của bộ sưu tập, từng cái một, nhưng không theo thứ tự cụ thể. Và nó không cần biết bộ sưu tập kết quả là gì, nó chỉ cần biết cách xây dựng nó. Vì vậy, đó là những gì chữ ký loại của nó yêu cầu.

Vì vậy, thay vì

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

Chữ ký kiểu truyền thống maplà gì, nó được khái quát hóa để không yêu cầu cụ thể Listmà chỉ là một IterableLikecấu trúc dữ liệu

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

mà sau đó được khái quát hóa thêm bằng cách chỉ yêu cầu một hàm tồn tại có thể chuyển đổi kết quả thành bất kỳ cấu trúc dữ liệu nào mà người dùng muốn:

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

Tôi thừa nhận rằng cú pháp là một chút vụng về, nhưng ngữ nghĩa là như nhau. Về cơ bản, nó bắt đầu từ

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

đó là chữ ký truyền thống cho map. (Lưu ý làm thế nào do tính chất hướng đối tượng của Scala, tham số danh sách đầu vào biến mất, bởi vì giờ đây nó là tham số máy thu ngầm mà mọi phương thức trong một hệ thống OO gửi đơn có.) Sau đó, nó khái quát từ cụ thể Listsang tổng quát hơnIterableLike

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

Bây giờ, nó thay thế IterableLikebộ sưu tập kết quả bằng một hàm tạo ra , tốt, thực sự là về bất cứ thứ gì.

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

Mà tôi thực sự tin rằng không phải là điều đó khó có thể hiểu được. Thực sự chỉ có một vài công cụ trí tuệ mà bạn cần:

1. Bạn cần biết (đại khái) maplà gì . Nếu bạn chỉ đưa ra chữ ký loại mà không có tên của phương thức, tôi thừa nhận, sẽ khó hơn rất nhiều để tìm hiểu điều gì đang xảy ra. Nhưng vì bạn đã biết những gì mapcần phải làm và bạn biết chữ ký loại của nó là gì, bạn có thể nhanh chóng quét chữ ký và tập trung vào sự bất thường, như "tại sao điều này lại maplấy hai chức năng làm đối số chứ không phải một?"
2. Bạn cần phải có khả năng thực sự đọc chữ ký loại. Nhưng ngay cả khi bạn chưa bao giờ thấy Scala trước đây, điều này khá dễ dàng, vì nó thực sự chỉ là một hỗn hợp các cú pháp loại mà bạn đã biết từ các ngôn ngữ khác: VB.NET sử dụng dấu ngoặc vuông cho đa hình tham số và sử dụng một mũi tên để biểu thị Kiểu trả về và dấu hai chấm để phân tách tên và loại, thực sự là chuẩn.
3. Bạn cần biết đại khái về lập trình chung là gì. (Mà không phải là điều đó khó có thể tìm ra, vì nó về cơ bản tất cả các giải thích rõ ràng trong tên: nó theo nghĩa đen chỉ lập trình một cách chung chung).

Không ai trong số ba người này nên làm cho bất kỳ lập trình viên chuyên nghiệp hoặc thậm chí sở thích đau đầu nghiêm trọng. maplà một chức năng tiêu chuẩn trong hầu hết mọi ngôn ngữ được thiết kế trong 50 năm qua, thực tế là các ngôn ngữ khác nhau có cú pháp khác nhau nên rõ ràng đối với bất kỳ ai đã thiết kế trang web với HTML và CSS và bạn không thể đăng ký chương trình thậm chí từ xa danh sách gửi thư liên quan mà không có một số fanboy C ++ khó chịu từ nhà thờ St. Stepanov giải thích những ưu điểm của lập trình chung.

Vâng, Scala rất phức tạp. Vâng, Scala có một trong những hệ thống loại tinh vi nhất mà con người biết đến, cạnh tranh và thậm chí vượt qua các ngôn ngữ như Haskell, Miranda, Clean hoặc Cyclone. Nhưng nếu sự phức tạp là một lập luận chống lại sự thành công của ngôn ngữ lập trình, C ++ sẽ chết từ lâu và tất cả chúng ta sẽ viết Scheme. Có rất nhiều lý do khiến Scala rất có thể sẽ không thành công, nhưng thực tế là các lập trình viên không thể bận tâm để bật bộ não của họ trước khi ngồi xuống trước bàn phím có lẽ sẽ không phải là chính.

Điều tương tự trong 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;
}

Chà, tôi có thể hiểu nỗi đau của bạn, nhưng, thật lòng mà nói, những người như bạn và tôi - hoặc gần như bất kỳ người dùng Stack Overflow thông thường nào - không phải là quy tắc.

Điều tôi muốn nói là ... hầu hết các lập trình viên sẽ không quan tâm đến chữ ký loại đó, bởi vì họ sẽ không bao giờ nhìn thấy chúng ! Họ không đọc tài liệu.

Miễn là họ thấy một số ví dụ về cách mã hoạt động và mã không làm họ thất bại trong việc tạo ra kết quả mà họ mong đợi , họ sẽ không bao giờ nhìn vào tài liệu. Khi thất bại, họ sẽ xem tài liệu và mong đợi để xem các ví dụ sử dụng ở trên cùng.

Với những điều này trong tâm trí, tôi nghĩ rằng:

1. Bất cứ ai (như, hầu hết mọi người) từng gặp chữ ký kiểu đó sẽ chế giễu Scala không có hồi kết nếu họ bị xử lý trước và sẽ coi đó là biểu tượng cho sức mạnh của Scala nếu họ thích Scala.

2. Nếu tài liệu không được cải tiến để cung cấp các ví dụ sử dụng và giải thích rõ ràng phương pháp này là gì và cách sử dụng nó, nó có thể làm mất đi sự chấp nhận của Scala một chút.

3. Về lâu dài, nó sẽ không thành vấn đề. Scala có thể làm những thứ như thế sẽ khiến các thư viện được viết cho Scala mạnh hơn và an toàn hơn để sử dụng. Các thư viện và khung này sẽ thu hút các lập trình viên thu hút các công cụ mạnh mẽ.

4. Các lập trình viên thích sự đơn giản và trực tiếp sẽ tiếp tục sử dụng PHP hoặc các ngôn ngữ tương tự.

Than ôi, các lập trình viên Java rất thích các công cụ mạnh mẽ, vì vậy, để trả lời rằng, tôi vừa sửa đổi kỳ vọng của mình về việc áp dụng Scala chính thống. Tôi không nghi ngờ gì về việc Scala sẽ trở thành ngôn ngữ chính thống. Không phải dòng chính C, mà có lẽ là dòng chính Perl hoặc dòng chính PHP.

Nói về Java, bạn đã bao giờ thay thế trình nạp lớp chưa? Bạn đã bao giờ nhìn vào những gì liên quan? Java có thể đáng sợ, nếu bạn nhìn vào các vị trí mà các nhà văn làm. Chỉ là hầu hết mọi người không. Điều tương tự cũng áp dụng cho Scala, IMHO, nhưng những người chấp nhận sớm có xu hướng nhìn vào từng tảng đá mà họ gặp phải, để xem liệu có thứ gì đó ẩn giấu ở đó không.

Đây có phải là sẽ đưa mọi người đến Scala?

Có, nhưng nó cũng sẽ ngăn mọi người khỏi bị đuổi việc. Tôi đã coi việc thiếu các bộ sưu tập sử dụng các loại loại cao hơn là một điểm yếu lớn kể từ khi Scala có được sự hỗ trợ cho các loại loại cao hơn. Nó làm cho các tài liệu API trở nên phức tạp hơn, nhưng nó thực sự làm cho việc sử dụng trở nên tự nhiên hơn.

Đây có phải sẽ mang lại cho scala một tên xấu trong thế giới thương mại như một thứ đồ chơi hàn lâm mà chỉ những sinh viên tiến sĩ tận tâm mới có thể hiểu được? Có phải CTO và người đứng đầu phần mềm sẽ sợ hãi?

Một số có thể sẽ. Tôi không nghĩ Scala có thể truy cập được đối với nhiều nhà phát triển "chuyên nghiệp", một phần do sự phức tạp của Scala và một phần do sự không sẵn lòng của nhiều nhà phát triển. Các CTO sử dụng các nhà phát triển như vậy sẽ rất sợ hãi.

Là thư viện thiết kế lại một ý tưởng hợp lý?

Chắc chắn rồi. Nó làm cho các bộ sưu tập phù hợp hơn nhiều với phần còn lại của ngôn ngữ và hệ thống loại, ngay cả khi nó vẫn có một số cạnh thô.

Nếu bạn đang sử dụng scala thương mại, bạn có lo lắng về điều này? Bạn đang có kế hoạch áp dụng 2.8 ngay lập tức hoặc chờ xem điều gì sẽ xảy ra?

Tôi không sử dụng nó cho mục đích thương mại. Có lẽ tôi sẽ đợi cho đến khi ít nhất một vài người quay lại loạt 2.8.x trước khi cố gắng giới thiệu nó để các lỗi có thể được xóa sạch. Tôi cũng sẽ chờ xem EPFL có bao nhiêu thành công trong việc cải thiện quá trình phát triển của nó. Những gì tôi thấy có vẻ hy vọng, nhưng tôi làm việc cho một công ty bảo thủ.

Một chủ đề chung hơn về "Scala có quá phức tạp đối với các nhà phát triển chính không?" ...

Hầu hết các nhà phát triển, chính thống hoặc mặt khác, đang duy trì hoặc mở rộng các hệ thống hiện có. Điều này có nghĩa là hầu hết những gì họ sử dụng được quyết định bởi các quyết định được đưa ra từ lâu. Vẫn còn rất nhiều người viết COBOL.

Nhà phát triển chính của ngày mai sẽ làm việc để duy trì và mở rộng các ứng dụng đang được xây dựng ngày hôm nay. Nhiều ứng dụng trong số này không được xây dựng bởi các nhà phát triển chính thống. Các nhà phát triển chính của ngày mai sẽ sử dụng ngôn ngữ đang được sử dụng bởi các nhà phát triển ứng dụng mới thành công nhất hiện nay.

Một cách mà cộng đồng Scala có thể giúp giảm bớt nỗi sợ của các lập trình viên mới đối với Scala là tập trung vào thực hành và dạy bằng ví dụ - rất nhiều ví dụ bắt đầu nhỏ và phát triển dần dần lớn hơn. Dưới đây là một vài trang web thực hiện phương pháp này:

• Scala hàng ngày
• Học Scala trong những vết cắn nhỏ
• Đơn giản là Scala

Sau khi dành một chút thời gian trên các trang web này, người ta nhanh chóng nhận ra rằng Scala và các thư viện của nó, mặc dù có lẽ khó thiết kế và thực hiện, nhưng không quá khó sử dụng, đặc biệt là trong các trường hợp phổ biến.

Tôi có bằng đại học từ một trường đại học "thị trường đại chúng" giá rẻ ở Mỹ, vì vậy tôi nói rằng tôi rơi vào giữa thang đo trí thông minh của người dùng (hoặc ít nhất là giáo dục) :) Tôi đã say mê Scala chỉ trong vài tháng và đã làm việc trên hai hoặc ba ứng dụng không tầm thường.

Đặc biệt là bây giờ IntelliJ đã phát hành IDE tốt của họ với những gì IMHO hiện đang là plugin Scala tốt nhất, phát triển Scala tương đối không gây đau đớn:

• Tôi thấy tôi có thể sử dụng Scala như một "Java không có dấu chấm phẩy", tức là tôi viết mã có giao diện tương tự với những gì tôi làm trong Java và hưởng lợi một chút từ sự ngắn gọn cú pháp như suy luận kiểu. Xử lý ngoại lệ, khi tôi làm điều đó, thuận tiện hơn. Định nghĩa lớp ít dài dòng hơn nhiều nếu không có bản tóm tắt getter / setter.

• Thỉnh thoảng tôi quản lý để viết một dòng duy nhất để thực hiện tương đương với nhiều dòng Java. Khi áp dụng, các chuỗi phương thức chức năng như bản đồ, gấp, thu thập, bộ lọc, v.v ... rất thú vị để sáng tác và thanh lịch.

• Chỉ hiếm khi tôi thấy mình được hưởng lợi từ các tính năng mạnh mẽ hơn của Scala: Đóng và các chức năng một phần (hoặc bị uốn cong), khớp mẫu ... đó là điều tương tự.

Là một người mới, tôi tiếp tục đấu tranh với cú pháp ngắn gọn và thành ngữ. Các cuộc gọi phương thức không có tham số không cần dấu ngoặc trừ khi chúng thực hiện; các trường hợp trong câu lệnh khớp cần một mũi tên béo ( =>), nhưng cũng có những nơi bạn cần một mũi tên mỏng ( ->). Nhiều phương thức có các tên ngắn nhưng khá khó hiểu như /:hoặc \:- Tôi có thể hoàn thành công việc của mình nếu tôi lật đủ các trang thủ công, nhưng một số mã của tôi cuối cùng trông giống như tiếng ồn Perl hoặc dòng. Trớ trêu thay, một trong những bit phổ biến nhất của tốc ký cú pháp bị thiếu trong hành động: Tôi tiếp tục bị cắn bởi thực tế là Intkhông định nghĩa một ++phương thức.

Đây chỉ là ý kiến ​​của tôi: Tôi cảm thấy như Scala có sức mạnh của C ++ kết hợp với sự phức tạp và dễ đọc của C ++. Độ phức tạp cú pháp của ngôn ngữ cũng làm cho tài liệu API khó đọc.

Scala rất chu đáo và xuất sắc ở nhiều khía cạnh. Tôi nghi ngờ nhiều học giả sẽ thích lập trình trong đó. Tuy nhiên, nó cũng đầy thông minh và gotchas, nó có đường cong học tập cao hơn nhiều so với Java và khó đọc hơn. Nếu tôi quét các diễn đàn và thấy có bao nhiêu nhà phát triển vẫn đang vật lộn với các điểm tốt hơn của Java, tôi không thể hình dung Scala trở thành ngôn ngữ chính . Không có công ty nào có thể biện minh cho việc gửi các nhà phát triển của mình vào khóa học Scala 3 tuần khi trước đây họ chỉ cần một khóa học Java 1 tuần.

Tôi nghĩ vấn đề chính với phương pháp đó là (implicit bf : CanBuildFrom[Repr, B, That])đi mà không có bất kỳ lời giải thích. Mặc dù tôi biết những đối số ngầm là gì nhưng không có gì cho thấy điều này ảnh hưởng đến cuộc gọi như thế nào. Theo đuổi qua scaladoc chỉ khiến tôi bối rối hơn (một vài trong số các lớp liên quan đến CanBuildFromthậm chí có tài liệu).

Tôi nghĩ đơn giản "có phải là một đối tượng tiềm ẩn trong phạm vi cho bfcung cấp một xây dựng cho các đối tượng của loại Bvào kiểu trả về That" sẽ giúp phần nào, nhưng đó là loại một khái niệm xông lên khi tất cả các bạn thực sự muốn làm là đồ A's để B'S. Trên thực tế, tôi không chắc điều đó đúng, vì tôi không biết ý Reprnghĩa của loại này và tài liệu Traversablechắc chắn không đưa ra manh mối nào cả.

Vì vậy, tôi còn lại hai lựa chọn, cả hai đều không dễ chịu:

• Giả sử nó sẽ hoạt động như thế nào bản đồ cũ hoạt động và cách bản đồ hoạt động trong hầu hết các ngôn ngữ khác
• Đi sâu vào mã nguồn

Tôi hiểu rằng Scala về cơ bản là phơi bày sự can đảm về cách thức những thứ này hoạt động và cuối cùng điều này cung cấp một cách để làm những gì oxbow_lakes đang mô tả. Nhưng đó là một sự xao lãng trong chữ ký.

Tôi là người mới bắt đầu Scala và thực sự tôi không thấy có vấn đề gì với chữ ký loại đó. Tham số là hàm để ánh xạ và tham số ngầm định trình xây dựng để trả về bộ sưu tập chính xác. Rõ ràng và dễ đọc.

Toàn bộ điều này khá thanh lịch, thực sự. Các tham số loại trình xây dựng cho phép trình biên dịch chọn loại trả về chính xác trong khi cơ chế tham số ẩn ẩn tham số bổ sung này khỏi người dùng lớp. Tôi đã thử điều này:

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")

Đó là đa hình được thực hiện đúng.

Bây giờ, được cho phép, nó không phải là một mô hình chính thống và nó sẽ khiến nhiều người sợ hãi. Nhưng, nó cũng sẽ thu hút nhiều người coi trọng tính biểu cảm và sang trọng của nó.

Thật không may, chữ ký cho bản đồ mà bạn đưa ra là không chính xác cho bản đồ và thực sự có sự chỉ trích chính đáng.

Những lời chỉ trích đầu tiên là bằng cách lật đổ chữ ký cho bản đồ, chúng ta có một cái gì đó chung chung hơn. Đó là một lỗi phổ biến để tin rằng đây là một đức tính theo mặc định. Không phải vậy. Hàm bản đồ được xác định rất rõ là hàm functor covariant Fx -> (x -> y) -> Fy tuân thủ hai định luật về thành phần và bản sắc. Bất cứ điều gì khác được quy cho "bản đồ" là một trò hề.

Chữ ký đã cho là một cái gì đó khác, nhưng nó không phải là bản đồ. Những gì tôi nghi ngờ nó đang cố gắng trở thành một phiên bản chuyên biệt và được thay đổi một chút của chữ ký "traverse" từ tờ giấy, Bản chất của mẫu lặp. Đây là chữ ký của nó:

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

Tôi sẽ chuyển đổi nó sang Scala:

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

Tất nhiên là thất bại - nó không đủ chung! Ngoài ra, nó hơi khác một chút (lưu ý rằng bạn có thể lấy bản đồ bằng cách chạy ngang qua functor Danh tính). Tuy nhiên, tôi nghi ngờ rằng nếu các nhà văn thư viện nhận thức rõ hơn về các khái quát của thư viện được ghi chép tốt (Lập trình ứng dụng với các hiệu ứng trước đã nói ở trên), thì chúng ta sẽ không thấy lỗi này.

Thứ hai, chức năng bản đồ là một trường hợp đặc biệt trong Scala vì nó được sử dụng để hiểu. Thật không may, điều này có nghĩa là một nhà thiết kế thư viện được trang bị tốt hơn không thể bỏ qua lỗi này mà không phải hy sinh đường cú pháp hiểu. Nói cách khác, nếu các nhà thiết kế thư viện Scala phá hủy một phương thức, thì điều này dễ bị bỏ qua, nhưng xin vui lòng không ánh xạ!

Tôi hy vọng ai đó lên tiếng về nó, bởi vì như vậy, nó sẽ trở nên khó khăn hơn để khắc phục các lỗi mà Scala khăng khăng mắc phải, rõ ràng là vì những lý do mà tôi phản đối mạnh mẽ. Đó là, giải pháp cho "sự phản đối vô trách nhiệm từ lập trình viên trung bình (tức là quá khó!)" Không phải là "xoa dịu họ để giúp họ dễ dàng hơn" mà thay vào đó, cung cấp gợi ý và hỗ trợ để trở thành lập trình viên tốt hơn. Mục tiêu của bản thân và Scala đang tranh cãi về vấn đề này, nhưng trở lại quan điểm của bạn.

Bạn có thể đã đưa ra quan điểm của mình, dự đoán các phản hồi cụ thể từ "lập trình viên trung bình". Đó là, những người sẽ tuyên bố "nhưng nó quá phức tạp!" hoặc một số như vậy. Đây là những Yegges hoặc Blochs mà bạn đề cập đến. Phản ứng của tôi với những người thuộc phong trào chống chủ nghĩa trí thức / thực dụng này khá gay gắt và tôi đã lường trước được một loạt các phản ứng, vì vậy tôi sẽ bỏ qua nó.

Tôi thực sự hy vọng các thư viện Scala được cải thiện, hoặc ít nhất, các lỗi có thể được giấu an toàn trong một góc. Java là một ngôn ngữ trong đó "cố gắng làm bất cứ điều gì hữu ích" rất tốn kém, đến mức nó thường không có giá trị vì không thể tránh được số lượng lỗi quá lớn. Tôi cầu xin Scala đừng đi chung con đường.

Tôi hoàn toàn đồng ý với cả câu hỏi và câu trả lời của Martin :). Ngay cả trong Java, việc đọc javadoc bằng generic cũng khó hơn nhiều so với tiếng ồn. Điều này được gộp trong Scala trong đó các tham số ngầm được sử dụng như trong mã ví dụ của câu hỏi (trong khi các hàm ẩn thực hiện công cụ thu thập hình thái rất hữu ích).

Tôi không nghĩ đó là vấn đề với ngôn ngữ - tôi nghĩ đó là vấn đề về công cụ. Và trong khi tôi đồng ý với những gì Jörg W Mittag nói, tôi nghĩ rằng việc xem xét scaladoc (hoặc tài liệu về một loại trong IDE của bạn) - nó cần ít năng lực não nhất có thể để tìm hiểu phương pháp là gì, nó cần và trả về. Không cần phải hack một chút đại số trên một chút giấy để có được nó :)

Để chắc chắn các IDE cần một cách hay để hiển thị tất cả các phương thức cho bất kỳ biến / biểu thức / loại nào (như với ví dụ của Martin có thể có tất cả các tổng quát được căn chỉnh sao cho nó dễ nhìn và dễ hiểu). Tôi cũng thích ý tưởng của Martin về việc che giấu những ẩn ý này.

Lấy ví dụ trong scaladoc ...

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

Khi xem xét điều này trong scaladoc, tôi muốn khối chung [B, That] bị ẩn theo mặc định cũng như tham số ẩn (có thể chúng hiển thị nếu bạn di chuột vào một biểu tượng nhỏ bằng chuột) - như một công cụ bổ sung để dò tìm đọc nó thường không liên quan. ví dụ tưởng tượng nếu điều này trông giống như ...

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

tốt đẹp và rõ ràng và rõ ràng những gì nó làm. Bạn có thể tự hỏi 'Cái đó' là gì, nếu bạn di chuột qua hoặc nhấp vào nó, nó có thể mở rộng văn bản [B, That] làm nổi bật 'Cái đó' chẳng hạn.

Có lẽ một biểu tượng nhỏ có thể được sử dụng cho khai báo [] và khối (ẩn ...) để rõ ràng có một chút của câu lệnh bị sụp đổ? Thật khó để sử dụng mã thông báo cho nó, nhưng tôi sẽ sử dụng a. bây giờ ...

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

Vì vậy, theo mặc định, 'nhiễu' của hệ thống loại được ẩn khỏi 80% chính những gì mọi người cần xem xét - tên phương thức, kiểu tham số và kiểu trả về của nó theo cách ngắn gọn đơn giản - với rất ít liên kết có thể mở rộng đến chi tiết nếu bạn thực sự quan tâm điều đó

Hầu hết mọi người đang đọc scaladoc để tìm ra phương thức nào họ có thể gọi trên một loại và những tham số nào họ có thể vượt qua. Chúng ta đang làm quá tải người dùng với quá nhiều chi tiết đúng cách IMHO.

Đây là một ví dụ khác ...

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

Bây giờ nếu chúng ta ẩn phần khai báo thì dễ đọc hơn

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

Sau đó, nếu mọi người di chuột qua, giả sử, A1, chúng ta có thể hiển thị tuyên bố A1 là A1 <: A. Các loại covariant và contravariant trong generic tạo ra nhiều tiếng ồn, điều này có thể được đưa ra theo cách dễ hiểu hơn đối với người dùng tôi nghĩ.

Tôi không biết làm thế nào để chia nó với bạn, nhưng tôi có bằng tiến sĩ từ Cambridge và tôi đang sử dụng 2.8 tốt.

Nghiêm trọng hơn, tôi hầu như không dành thời gian cho 2.7 (nó sẽ không tương tác với thư viện Java tôi đang sử dụng) và bắt đầu sử dụng Scala chỉ hơn một tháng trước. Tôi có một số kinh nghiệm với Haskell (không nhiều), nhưng chỉ bỏ qua những thứ bạn lo lắng và tìm kiếm các phương thức phù hợp với trải nghiệm của tôi với Java (mà tôi sử dụng để kiếm sống).

Vì vậy: Tôi là một "người dùng mới" và tôi đã không bỏ qua - thực tế là nó hoạt động như Java đã cho tôi đủ tự tin để bỏ qua các bit mà tôi không hiểu.

(Tuy nhiên, lý do tôi nhìn vào Scala là một phần để xem liệu có nên đẩy nó vào công việc hay không và tôi sẽ không làm như vậy. Làm cho tài liệu ít đáng sợ hơn chắc chắn sẽ giúp tôi, nhưng điều làm tôi ngạc nhiên là nó vẫn còn thay đổi và được phát triển (công bằng mà nói, điều làm tôi ngạc nhiên nhất là nó tuyệt vời như thế nào, nhưng những thay đổi đã đến rất gần). Vì vậy, tôi đoán những gì tôi đang nói là tôi thích các nguồn lực hạn chế được đưa vào. một trạng thái cuối cùng - tôi không nghĩ rằng họ đang mong đợi được phổ biến sớm như vậy.)

Không biết Scala chút nào, tuy nhiên vài tuần trước tôi không thể đọc Clojure. Bây giờ tôi có thể đọc hầu hết, nhưng không thể viết bất cứ điều gì ngoài các ví dụ đơn giản nhất . Tôi nghi ngờ Scala không khác. Bạn cần một cuốn sách hay khóa học tốt tùy thuộc vào cách bạn học. Chỉ cần đọc bản khai trên, tôi có thể 1/3 của nó.

Tôi tin rằng những vấn đề lớn hơn không phải là cú pháp của các ngôn ngữ này, mà là việc áp dụng và nội tâm hóa các mô hình khiến chúng có thể sử dụng được trong mã sản xuất hàng ngày. Đối với tôi Java không phải là một bước nhảy vọt từ C ++, mà không phải là một bước nhảy vọt lớn từ C, mà không phải là một bước nhảy vọt từ Pascal, hay Basic, v.v ... Nhưng mã hóa trong một ngôn ngữ chức năng như Clojure là một bước nhảy vọt lớn (đối với dù sao tôi cũng vậy). Tôi đoán trong Scala bạn có thể viết mã theo kiểu Java hoặc kiểu Scala. Nhưng trong Clojure, bạn sẽ tạo ra một mớ hỗn độn cố gắng giữ thói quen bắt buộc của bạn khỏi Java.

Scala có rất nhiều tính năng điên rồ (đặc biệt là các thông số ngầm có liên quan) trông rất phức tạp và mang tính học thuật, nhưng được thiết kế để làm cho mọi thứ dễ sử dụng. Những người hữu ích nhất nhận được đường cú pháp (như [A <% B]điều đó có nghĩa là một đối tượng loại A có một chuyển đổi ngầm định thành một đối tượng của loại B) và một lời giải thích được chứng minh bằng văn bản về những gì họ làm. Nhưng hầu hết thời gian, là một khách hàng của các thư viện này, bạn có thể bỏ qua các tham số ngầm và tin tưởng họ làm điều đúng đắn.

Đây có phải là sẽ đưa mọi người đến Scala?

Tôi không nghĩ rằng đó là yếu tố chính sẽ ảnh hưởng đến mức độ phổ biến của Scala, bởi vì Scala có rất nhiều sức mạnh và cú pháp của nó không xa lạ với một lập trình viên Java / C ++ / PHP như Haskell, OCaml, SML, Lisps, Vân vân..

Nhưng tôi nghĩ rằng sự phổ biến của Scala sẽ cao hơn ít hơn so với Java ngày nay, bởi vì tôi cũng nghĩ rằng ngôn ngữ chính tiếp theo phải được đơn giản hóa nhiều và cách duy nhất tôi thấy để đạt được sự bất biến thuần túy, tức là khai báo như HTML, nhưng Turing hoàn thành . Tuy nhiên, tôi thiên vị vì tôi đang phát triển một ngôn ngữ như vậy, nhưng tôi chỉ làm như vậy sau khi loại trừ một nghiên cứu trong vài tháng rằng Scala không thể đủ cho những gì tôi cần.

Đây có phải sẽ mang lại cho Scala một tên xấu trong thế giới thương mại như một thứ đồ chơi hàn lâm mà chỉ những sinh viên tiến sĩ tận tâm mới có thể hiểu được? Có phải CTO và người đứng đầu phần mềm sẽ sợ hãi?

Tôi không nghĩ rằng danh tiếng của Scala sẽ bị ảnh hưởng bởi khu phức hợp Haskell. Nhưng tôi nghĩ rằng một số người sẽ ngừng học nó, bởi vì đối với hầu hết các lập trình viên, tôi chưa thấy trường hợp sử dụng nào buộc họ sử dụng Scala và họ sẽ trì hoãn việc học về nó. Có lẽ phía máy chủ có khả năng mở rộng cao là trường hợp sử dụng hấp dẫn nhất.

Và, đối với thị trường chính thống, việc học Scala đầu tiên không phải là "hơi thở của không khí trong lành", nơi người ta đang viết chương trình ngay lập tức, chẳng hạn như lần đầu tiên sử dụng HTML hoặc Python. Scala có xu hướng phát triển trên bạn, sau khi tìm hiểu tất cả các chi tiết mà người ta vấp ngã từ đầu. Tuy nhiên, có lẽ nếu tôi đã đọc Lập trình trong Scala ngay từ đầu, kinh nghiệm và quan điểm của tôi về đường cong học tập sẽ khác.

Là thư viện thiết kế lại một ý tưởng hợp lý?

Chắc chắn rồi.

Nếu bạn đang sử dụng Scala thương mại, bạn có lo lắng về điều này? Bạn đang có kế hoạch áp dụng 2.8 ngay lập tức hoặc chờ xem điều gì sẽ xảy ra?

Tôi đang sử dụng Scala làm nền tảng ban đầu cho ngôn ngữ mới của mình. Tôi có thể sẽ không xây dựng mã trên thư viện bộ sưu tập của Scala nếu tôi đang sử dụng Scala về mặt thương mại. Tôi sẽ tạo thư viện dựa trên lý thuyết thể loại của riêng mình, vì một lần tôi nhìn, tôi thấy chữ ký loại của Scalaz thậm chí dài dòng và khó sử dụng hơn thư viện bộ sưu tập của Scala. Một phần của vấn đề đó có lẽ là cách Scala thực hiện các lớp loại và đó là một lý do nhỏ khiến tôi tạo ra ngôn ngữ của riêng mình.

Tôi quyết định viết câu trả lời này, vì tôi muốn buộc bản thân nghiên cứu và so sánh thiết kế lớp sưu tập của Scala với thiết kế mà tôi đang làm cho ngôn ngữ của mình. Cũng có thể chia sẻ quá trình suy nghĩ của tôi.

Các bộ sưu tập 2.8 Scala sử dụng sự trừu tượng của người xây dựng là một nguyên tắc thiết kế âm thanh. Tôi muốn khám phá hai sự đánh đổi thiết kế dưới đây.

1. MÃ CHỈ VIẾT: Sau khi viết phần này, tôi đọc bình luận của Carl Smotricz đồng ý với những gì tôi mong đợi là sự đánh đổi. Ý kiến ​​của James Strachan và davetron5000 đồng tình rằng ý nghĩa của Điều đó (thậm chí không phải là [B]) và cơ chế của ẩn ý không dễ nắm bắt bằng trực giác. Xem việc sử dụng monoid của tôi trong vấn đề # 2 dưới đây, mà tôi nghĩ rõ ràng hơn nhiều. Nhận xét của Derek Mahar là về việc viết Scala, nhưng về việc đọc Scala của những người khác không phải là "trong các trường hợp phổ biến".

   Một lời chỉ trích tôi đã đọc về Scala, đó là viết nó dễ hơn là đọc mã mà người khác đã viết. Và tôi thấy điều này đôi khi đúng vì nhiều lý do (ví dụ: nhiều cách để viết hàm, đóng tự động, Đơn vị cho DSL, v.v.), nhưng tôi không quyết định nếu đây là yếu tố chính. Ở đây việc sử dụng các tham số hàm ẩn có các ưu điểm và nhược điểm. Về mặt tích cực, nó làm giảm tính dài dòng và tự động hóa lựa chọn đối tượng xây dựng. Trong Oderky ví dụviệc chuyển đổi từ Bitset, tức là Đặt [Int], thành Tập [Chuỗi] là ẩn. Người đọc không quen thuộc của mã có thể không dễ dàng biết loại bộ sưu tập là gì, trừ khi họ có thể giải thích rõ về tất cả các ứng cử viên xây dựng ẩn vô hình tiềm năng có thể tồn tại trong phạm vi gói hiện tại. Tất nhiên, lập trình viên có kinh nghiệm và người viết mã sẽ biết rằng BitSet bị giới hạn ở Int, do đó, một bản đồ thành Chuỗi phải chuyển đổi sang một loại bộ sưu tập khác. Nhưng loại bộ sưu tập nào? Nó không được chỉ định rõ ràng.

2. THIẾT KẾ THU THẬP QUẢNG CÁO: Sau khi viết phần này, tôi đã đọc bình luận của Tony Morris và nhận ra tôi đang thực hiện gần như cùng một điểm. Có lẽ giải trình dài dòng hơn của tôi sẽ làm cho quan điểm rõ ràng hơn.

   Trong "Fighting Bit Rot with Type" Oderky & Moors, hai trường hợp sử dụng được trình bày. Chúng là sự hạn chế của các phần tử Bitset thành Int và Map để ghép các phần tử tuple và được cung cấp là lý do mà hàm ánh xạ phần tử chung, A => B, phải có thể xây dựng các loại bộ sưu tập đích thay thế. Tuy nhiên, afaik điều này là thiếu sót từ góc độ lý thuyết thể loại. Để thống nhất trong lý thuyết danh mục và do đó tránh các trường hợp góc, các loại bộ sưu tập này là functor, trong đó mỗi hình thái, A => B, phải ánh xạ giữa các đối tượng trong cùng loại functor, Danh sách [A] => Danh sách [B], Bitset [A] => Bitset [B]. Ví dụ: Tùy chọn là một functor có thể được xem như một tập hợp các tập hợp của một số (đối tượng) và Không có. Không có bản đồ chung từ Không có tùy chọn, hoặc Danh sách của Nil, đến các chức năng khác mà không '

   Có một sự lựa chọn thiết kế đánh đổi được thực hiện ở đây. Trong thiết kế thư viện bộ sưu tập ngôn ngữ mới của tôi, tôi đã chọn biến mọi thứ thành functor, có nghĩa là nếu tôi triển khai Bitset, nó cần hỗ trợ tất cả các loại phần tử, bằng cách sử dụng biểu diễn bên trong trường không bit khi được trình bày không phải là trường tham số kiểu số nguyên và chức năng đó đã có trong Bộ mà nó kế thừa từ trong Scala. Và Bản đồ trong thiết kế của tôi chỉ cần ánh xạ các giá trị của nó và nó có thể cung cấp một phương thức không phải functor riêng để ánh xạ các bộ dữ liệu cặp (khóa, giá trị) của nó. Một lợi thế là mỗi functor sau đó cũng thường là một ứng dụng và có lẽ là một đơn nguyên. Do đó, tất cả các chức năng giữa các loại phần tử, ví dụ A => B => C => D => ..., sẽ tự động được nâng lên các chức năng giữa các loại ứng dụng được nâng, ví dụ: Danh sách [A] => Danh sách [B] => Danh sách [ C] => Danh sách [D] => .... Để ánh xạ từ functor sang một lớp bộ sưu tập khác, tôi đưa ra một tình trạng quá tải bản đồ cần một monoid, ví dụ Nil, none, 0, "", Array (), v.v. Vì vậy, hàm trừu tượng của trình xây dựng là phương thức nối thêm của một monoid và được cung cấp rõ ràng như một tham số đầu vào cần thiết, do đó không có chuyển đổi ngầm ẩn. (Tiếp tuyến: tham số đầu vào này cũng cho phép nối thêm vào các đơn sắc không trống, điều mà thiết kế bản đồ của Scala không thể thực hiện được.) Các chuyển đổi như vậy là một bản đồ và một nếp gấp trong cùng một lần lặp. Ngoài ra, tôi cung cấp một giao dịch, theo nghĩa thể loại, "Lập trình ứng dụng có hiệu ứng" McBride & Patterson, cũng cho phép ánh xạ + gấp trong một lần lặp chuyển từ bất kỳ chuyển đổi nào sang bất kỳ ứng dụng nào, trong đó hầu hết mọi lớp bộ sưu tập đều có.

   Vì vậy, afaics các bộ sưu tập Scala là "ad-hoc" theo nghĩa là nó không có căn cứ trong lý thuyết phạm trù, và lý thuyết phạm trù là tinh hoa của ngữ nghĩa học biểu thị cấp cao hơn. Mặc dù các nhà xây dựng ngầm của Scala thoạt nhìn "khái quát" hơn so với mô hình functor + trình xây dựng đơn hình + truyền tải -> có tính ứng dụng, nhưng chúng không được chứng minh là phù hợp với bất kỳ danh mục nào và do đó chúng tôi không biết họ tuân theo quy tắc nào trong ý nghĩa chung nhất và những gì các trường hợp góc sẽ được đưa ra họ có thể không tuân theo bất kỳ mô hình thể loại nào. Điều đơn giản là không đúng khi thêm nhiều biến làm cho một cái gì đó tổng quát hơn, và đây là một trong những lợi ích to lớn của lý thuyết thể loại là nó cung cấp các quy tắc để duy trì tính tổng quát trong khi nâng lên ngữ nghĩa cấp cao hơn. Một bộ sưu tập là một thể loại.

   Tôi đọc ở đâu đó, tôi nghĩ đó là Oderky, như một lời biện minh khác cho thiết kế thư viện, đó là lập trình theo kiểu chức năng thuần túy có chi phí đệ quy hạn chế và tốc độ mà đệ quy đuôi không được sử dụng. Tôi đã không gặp khó khăn khi sử dụng đệ quy đuôi trong mọi trường hợp mà tôi đã gặp cho đến nay.

Ngoài ra, tôi đang mang trong đầu một ý tưởng không hoàn chỉnh rằng một số sự đánh đổi của Scala là do cố gắng trở thành một ngôn ngữ có thể thay đổi và bất biến, không giống như Haskell hoặc ngôn ngữ tôi đang phát triển. Điều này đồng tình với nhận xét của Tony Morris về sự hiểu biết. Trong ngôn ngữ của tôi, không có vòng lặp và không có cấu trúc có thể thay đổi. Ngôn ngữ của tôi sẽ nằm trên Scala (hiện tại) và nợ rất nhiều, và điều này sẽ không thể xảy ra nếu Scala không có hệ thống loại chung và khả năng biến đổi. Mặc dù điều đó có thể không đúng, bởi vì tôi nghĩ Oderky & Moors ("Fighting Bit Rot with Type") không chính xác khi nói rằng Scala là ngôn ngữ OOP duy nhất có loại cao hơn, bởi vì tôi đã xác minh (bản thân tôi và thông qua Bob Harper) ML có chúng. Cũng xuất hiện hệ thống loại của SML có thể linh hoạt tương đương (từ những năm 1980), có thể không được đánh giá cao vì cú pháp không quá giống với Java (và C ++ / PHP) như Scala. Trong mọi trường hợp, đây không phải là một lời chỉ trích của Scala, mà là một nỗ lực để trình bày một phân tích không đầy đủ về sự đánh đổi, mà tôi hy vọng sẽ phù hợp với câu hỏi. Scala và SML không chịu sự bất lực của Haskellthừa kế nhiều kim cương , điều rất quan trọng và tôi hiểu là tại sao rất nhiều chức năng trong Haskell Prelude được lặp lại cho các loại khác nhau.

Có vẻ như cần phải nêu bằng cấp ở đây: Cử nhân Khoa học Chính trị và Cử nhân Khoa học Máy tính.

Đến điểm:

Đây có phải là sẽ đưa mọi người đến Scala?

Scala là khó khăn, bởi vì mô hình lập trình cơ bản của nó là khó khăn. Lập trình chức năng sợ rất nhiều người. Có thể xây dựng các bao đóng trong PHP nhưng mọi người hiếm khi làm. Vì vậy, không, không phải chữ ký này mà tất cả những người còn lại sẽ khiến mọi người bỏ cuộc, nếu họ không có giáo dục cụ thể để khiến họ coi trọng sức mạnh của mô hình cơ bản.

Nếu giáo dục này có sẵn, tất cả mọi người có thể làm điều đó. Năm ngoái tôi xây dựng một máy tính chơi cờ với một đám học sinh ở SCALA! Họ đã có vấn đề của họ nhưng cuối cùng họ đã làm tốt.

Nếu bạn đang sử dụng Scala thương mại, bạn có lo lắng về điều này? Bạn đang có kế hoạch áp dụng 2.8 ngay lập tức hoặc chờ xem điều gì sẽ xảy ra?

Tôi sẽ không lo lắng.

Tôi cũng có bằng toán từ Oxford! Tôi phải mất một thời gian để 'có được' các bộ sưu tập mới. Nhưng tôi thích nó rất nhiều bây giờ tôi làm. Trên thực tế, việc gõ 'bản đồ' là một trong những điều lớn đầu tiên khiến tôi gặp khó khăn trong 2.7 (có lẽ vì điều đầu tiên tôi làm là phân lớp một trong các lớp sưu tập).

Đọc bài viết của Martin về các bộ sưu tập 2.8 mới thực sự giúp giải thích việc sử dụng các ẩn ý, ​​nhưng vâng, tài liệu chắc chắn cần phải làm tốt hơn việc giải thích vai trò của các loại ẩn ý khác nhau trong các chữ ký phương thức của các API cốt lõi.

Mối quan tâm chính của tôi là nhiều hơn thế này: khi nào 2.8 sẽ được phát hành? Khi nào các báo cáo lỗi sẽ dừng lại cho nó? đội scala đã cắn nhiều hơn mức họ có thể nhai với 2.8 / đã cố gắng thay đổi quá nhiều cùng một lúc?

Tôi thực sự muốn xem 2.8 ổn định để phát hành là ưu tiên trước khi thêm bất kỳ thứ gì mới nào khác, và tự hỏi (trong khi xem từ bên lề) nếu một số cải tiến có thể được thực hiện theo cách quản lý lộ trình phát triển cho trình biên dịch scala.

Điều gì về thông báo lỗi trong trang web sử dụng?

Và về trường hợp sử dụng, người ta cần tích hợp các loại hiện có với một loại tùy chỉnh phù hợp với DSL. Người ta phải được giáo dục tốt về các vấn đề liên kết, ưu tiên, chuyển đổi ngầm định, tham số ngầm, loại cao hơn và có thể loại tồn tại.

Thật tốt khi biết rằng hầu hết là đơn giản nhưng nó không nhất thiết là đủ. Ít nhất phải có một anh chàng biết công cụ này nếu thư viện rộng rãi được thiết kế.