Sử dụng Lý thuyết tính toán quy trình và PL để phát triển ngôn ngữ lập trình hiện đại

Trong một thời gian bây giờ, tôi đã rất quan tâm đến lý thuyết ngôn ngữ lập trình và tính toán quy trình và đã bắt đầu nghiên cứu chúng. Thành thật mà nói, đó là điều mà tôi không bận tâm cho sự nghiệp. Tôi thấy lý thuyết là vô cùng hấp dẫn. Một câu hỏi liên tục tôi tiếp tục gặp phải là liệu Lý thuyết PL hay Tính toán quy trình có bất kỳ tầm quan trọng nào trong phát triển ngôn ngữ lập trình hiện đại hay không. Tôi thấy rất nhiều biến thể trên máy tính Pi ngoài kia và có rất nhiều nghiên cứu tích cực, nhưng liệu chúng có cần thiết hay có những ứng dụng quan trọng không? Lý do tại sao tôi hỏi là vì tôi thích phát triển ngôn ngữ lập trình và mục tiêu cuối cùng thực sự sẽ là sử dụng lý thuyết để thực sự xây dựng PL. Đối với những thứ tôi đã viết, thực sự không có bất kỳ mối tương quan nào với lý thuyết cả.

Câu trả lời của tôi thực sự chỉ là một công phu của Gilles ', mà tôi đã không đọc trước khi tôi viết. Có lẽ nó vẫn hữu ích.

Hãy để tôi bắt đầu nỗ lực trả lời câu hỏi của bạn với sự khác biệt giữa hai chiều của ngôn ngữ lập trình hoạt động hoàn toàn khác với lý thuyết ngôn ngữ lập trình nói chung và quá trình tính toán nói riêng.

• Nghiên cứu thuần túy.

• Sản phẩm tập trung nghiên cứu và phát triển.

Sau này thường diễn ra trong công nghiệp với mục đích cung cấp các ngôn ngữ lập trình như một sản phẩm. Các nhóm phát triển Java tại Oracle và C # tại Microsoft là những ví dụ. Ngược lại, nghiên cứu thuần túy không gắn liền với sản phẩm. Mục đích của nó là để hiểu các ngôn ngữ lập trình như là các đối tượng quan tâm nội tại và khám phá các cấu trúc toán học bên dưới tất cả các ngôn ngữ lập trình.

Do các mục tiêu khác nhau, các khía cạnh khác nhau của lý thuyết ngôn ngữ lập trình có liên quan trong nghiên cứu thuần túy và R & D tập trung vào sản phẩm Hình ảnh dưới đây có thể cho thấy điều gì quan trọng ở đâu.

Người ta có thể hỏi tại thời điểm này tại sao hai chiều dường như rất khác nhau và tuy nhiên chúng có liên quan như thế nào.

Cái nhìn sâu sắc quan trọng là nghiên cứu và phát triển ngôn ngữ lập trình có nhiều khía cạnh: kỹ thuật, xã hội và kinh tế. Hầu như theo định nghĩa, ngành công nghiệp quan tâm đến sự hoàn trả kinh tế của các ngôn ngữ lập trình. Microsoft et al không phát triển ngôn ngữ từ lòng tốt của họ nhưng vì họ tin rằng ngôn ngữ lập trình mang lại cho họ lợi thế kinh tế. Và họ đã điều tra sâu sắc tại sao một số ngôn ngữ lập trình thành công, và những ngôn ngữ khác, dường như tương tự hoặc với các tính năng nâng cao hơn, thì không. Và họ thấy rằng không có một lý do duy nhất. Ngôn ngữ lập trình và môi trường của chúng rất phức tạp và đó là lý do để chấp nhận hoặc bỏ qua bất kỳ ngôn ngữ cụ thể nào. Nhưng yếu tố lớn nhất cho sự thành công của ngôn ngữ lập trình là sự gắn bó ưu tiên của các lập trình viên với các ngôn ngữ đã được sử dụng rộng rãi: càng nhiều người sử dụng ngôn ngữ, càng có nhiều thư viện, công cụ, tài liệu giảng dạy và lập trình viên càng hiệu quả có thể sử dụng ngôn ngữ đó Đây cũng được gọi là hiệu ứng mạng. Một lý do khác là các ngôn ngữ chuyển đổi chi phí cao cho các cá nhân và tổ chức: thông thạo ngôn ngữ, đặc biệt là đối với một lập trình viên không có kinh nghiệm và khi khoảng cách ngữ nghĩa với các ngôn ngữ quen thuộc là lớn, là một nỗ lực nghiêm túc, tốn thời gian. Với những sự thật này, người ta có thể hỏi tại sao các ngôn ngữ mới có được lực kéo ở tất cả? Tại sao các công ty phát triển ngôn ngữ mới cả? Tại sao chúng ta không ở lại với Java hoặc Cobol? Tôi nghĩ rằng có một số lý do chính để whey một ngôn ngữ thành công,

• Một miền mới của lập trình mở ra mà không có đương nhiệm để thay thế. Ví dụ chính là web với sự gia tăng đồng thời của Javascript.

• Ngôn ngữ dính. Điều này có nghĩa là giá cao của việc thay đổi ngôn ngữ. Nhưng đôi khi các lập trình viên chuyển sang các lĩnh vực khác nhau, mang theo ngôn ngữ lập trình với họ và thành công với ngôn ngữ cũ trong lĩnh vực mới.

• Một ngôn ngữ được thúc đẩy bởi một công ty lớn với hỏa lực tài chính nghiêm trọng. Sự ủng hộ này làm giảm rủi ro chấp nhận, bởi vì những người chấp nhận sớm có thể chắc chắn chắc chắn rằng ngôn ngữ sẽ vẫn được hỗ trợ trong một vài năm. Một ví dụ điển hình của việc này là C #.

• Một ngôn ngữ có thể đi kèm với các công cụ hấp dẫn và hệ sinh thái. Ở đây cũng có C # và đó là hệ sinh thái .Net và Visual Studio có thể được đề cập làm ví dụ.

• Ngôn ngữ cũ nhận các tính năng mới. Java xuất hiện trong tâm trí, trong mỗi lần lặp lại, tiếp thu thêm nhiều ý tưởng hay từ truyền thống lập trình chức năng.

• Cuối cùng, một ngôn ngữ mới có thể có những lợi thế kỹ thuật nội tại, ví dụ như biểu cảm hơn, có cú pháp đẹp hơn, hệ thống gõ có nhiều lỗi hơn, v.v.

Với nền tảng này, không có gì đáng ngạc nhiên khi có một chút bất đồng giữa nghiên cứu ngôn ngữ lập trình thuần túy và phát triển ngôn ngữ lập trình thương mại. Mặc dù cả hai đều nhằm mục đích làm cho việc xây dựng và phát triển phần mềm hiệu quả hơn, đặc biệt là đối với phần mềm quy mô lớn, công việc ngôn ngữ lập trình công nghiệp phải được quan tâm nhiều hơn trong việc tạo điều kiện cho việc áp dụng nhanh chóng để đạt được khối lượng quan trọng và đạt được hiệu quả mạng. Điều này dẫn đến một nghiên cứu tập trung vào những điều mà các lập trình viên làm việc quan tâm. Và đó có xu hướng là những thứ như thư viện sẵn có, tốc độ trình biên dịch, chất lượng mã được biên dịch, tính di động, v.v. Tính toán quy trình khi chúng ta thực hành nó ngày nay ít được sử dụng cho các lập trình viên làm việc trong các dự án chính thống (mặc dù tôi tin rằng điều đó sẽ thay đổi trong tương lai).

$\lambda$$\pi$$\beta$-Giảm giá cho lập trình chức năng, phân giải / thống nhất cho lập trình logic, chuyển tên cho tính toán đồng thời). Để hiểu nếu một ngôn ngữ như Scala có thể có suy luận kiểu đầy đủ khả thi, chúng ta không cần phải lo lắng về JVM. Thật vậy, suy nghĩ về JVM sẽ làm mất đi sự hiểu biết tốt hơn về suy luận kiểu. Đó là lý do tại sao sự trừu tượng của tính toán thành các phép tính cốt lõi nhỏ là quan trọng và mạnh mẽ.

Vì vậy, bạn có thể nghĩ về nghiên cứu ngôn ngữ lập trình như một hộp cát khổng lồ nơi mọi người chơi với đồ chơi và nếu họ tìm thấy thứ gì đó thú vị khi chơi với một món đồ chơi cụ thể và đã điều tra kỹ về món đồ chơi đó, thì món đồ chơi thú vị đó bắt đầu tiến tới sự chấp nhận công nghiệp chính thống . Tôi nói diễu hành dài vì các tính năng ngôn ngữ được phát minh đầu tiên bởi nhà nghiên cứu ngôn ngữ lập trình có xu hướng mất nhiều thập kỷ trước khi được chấp nhận rộng rãi. Ví dụ, bộ sưu tập rác được hình thành vào những năm 1950 và trở nên phổ biến rộng rãi với Java vào những năm 1990. Mô hình phù hợp với cá mập trở lại năm 1970 và chỉ được sử dụng rộng rãi kể từ Scala.

Quá trình tính toán là một đồ chơi đặc biệt thú vị. Nhưng nó quá mới để được điều tra kỹ lưỡng. Điều đó sẽ mất một thập kỷ nghiên cứu thuần túy. Những gì hiện đang diễn ra trong nghiên cứu lý thuyết quá trình là lấy câu chuyện thành công lớn nhất về nghiên cứu ngôn ngữ lập trình, lý thuyết về các loại (tuần tự) và phát triển lý thuyết về các loại để truyền thông điệp đồng thời. Hệ thống gõ có độ biểu cảm vừa phải để lập trình tuần tự, theo Hindley-Milner, giờ đây đã được hiểu rõ, có mặt khắp nơi và được các lập trình viên làm việc chấp nhận. Chúng tôi muốn có các loại biểu cảm vừa phải để lập trình đồng thời. Nghiên cứu về điều này bắt đầu từ những năm 1980 bởi những người tiên phong như Milner, Sangiorgi, Turner, Kobayashi, Honda và những người khác, thường dựa trên, rõ ràng hoặc ngầm định, về ý tưởng tuyến tính xuất phát từ logic tuyến tính. Vài năm gần đây đã chứng kiến ​​sự gia tăng lớn trong hoạt động và tôi hy vọng quỹ đạo đi lên này sẽ tiếp tục trong tương lai gần. Tôi cũng hy vọng công việc này sẽ bắt đầu rò rỉ vào R & D tập trung vào sản phẩm, vì những lý do thực tế mà các nhà nghiên cứu trẻ đã được đào tạo về tính toán quy trình sẽ đi và làm việc trong các phòng thí nghiệm R & D công nghiệp, nhưng cũng vì sự phát triển của CPU và kiến ​​trúc máy tính từ các hình thức tính toán liên tiếp.

Tóm lại, tôi sẽ không lo lắng rằng bạn không thấy lý thuyết ngôn ngữ lập trình tiên tiến như tính toán quy trình hữu ích trong công việc xây dựng ngôn ngữ của riêng bạn. Điều đó đơn giản là vì lý thuyết tiên tiến không giải quyết được mối quan tâm của các ngôn ngữ lập trình hiện tại. Đó là về ngôn ngữ trong tương lai. Sẽ mất một lúc để 'thế giới thực' bắt kịp. Kiến thức bạn sử dụng để xây dựng ngôn ngữ cho ngày hôm nay là lý thuyết ngôn ngữ lập trình của quá khứ. Tôi khuyến khích bạn tìm hiểu thêm về tính toán quy trình vì đây là một trong những lĩnh vực xuất sắc nhất của tất cả các ngành khoa học máy tính lý thuyết.

Khoa học về thiết kế ngôn ngữ lập trình còn rất nhiều. Lý thuyết (nghiên cứu về ý nghĩa của chương trình và tính biểu cảm của ngôn ngữ) và chủ nghĩa kinh nghiệm (những gì lập trình viên quản lý hoặc không quản lý để làm) đưa ra rất nhiều lập luận định tính để cân nhắc cách này hay cách khác khi thiết kế ngôn ngữ. Nhưng chúng tôi hiếm khi có bất kỳ lý do định lượng để quyết định.

Có một độ trễ giữa thời gian một số lý thuyết ổn định đủ để một sự đổi mới có thể sử dụng được trong ngôn ngữ lập trình thực tế và thời điểm sự đổi mới này bắt đầu xuất hiện trong các ngôn ngữ chính thống của Hồi giáo. Ví dụ, quản lý bộ nhớ tự động với bộ sưu tập rác có thể được nói là đã hoàn thiện cho sử dụng công nghiệp vào giữa những năm 1960, nhưng chỉ đạt được xu hướng chính với Java vào năm 1995. Đa hình tham số đã được hiểu rõ vào cuối những năm 1970 và đã làm cho nó trở nên phổ biến vào Java vào giữa những năm 200. Trên quy mô của sự nghiệp của một nhà nghiên cứu, 30 năm là một thời gian dài.

Áp dụng công nghiệp quy mô rộng của một ngôn ngữ là một vấn đề cho các nhà xã hội học nghiên cứu, và khoa học thậm chí còn nhiều hơn trong giai đoạn trứng nước. Cân nhắc thị trường là một yếu tố quan trọng - nếu Sun, Microsoft hoặc Apple thúc đẩy một ngôn ngữ, điều này có tác động lớn hơn bất kỳ số lượng giấy tờ POPL và PLDI nào. Ngay cả đối với một lập trình viên có sự lựa chọn, tính sẵn có của thư viện thường quan trọng hơn nhiều so với thiết kế ngôn ngữ. Điều đó không có nghĩa là thiết kế ngôn ngữ không quan trọng: có một ngôn ngữ được thiết kế tốt là một sự giải thoát! Nó thường không phải là yếu tố quyết định.

Quá trình tính toán vẫn đang ở giai đoạn mà lý thuyết chưa ổn định. Chúng tôi tin rằng chúng tôi hiểu các tính toán tuần tự - tất cả các mô hình của những thứ mà chúng tôi muốn gọi là tính toán tuần tự là tương đương (đó là luận điểm của Church-Turing). Điều này không đúng với sự tương tranh: các phép tính quy trình khác nhau có xu hướng có sự khác biệt tinh tế trong biểu cảm.

Quá trình tính toán có ý nghĩa thực tế. Rất nhiều tính toán được phân phối - chúng liên quan đến các máy khách nói chuyện với máy chủ, máy chủ nói chuyện với các máy chủ khác, v.v. Ngay cả các tính toán cục bộ cũng rất đa dạng để tận dụng sự song song trên nhiều bộ xử lý và phản ứng với sự tương tranh môi trường (giao tiếp với các chương trình độc lập và với người dùng).

Là những tiến bộ nghiên cứu cần thiết để làm cho phần mềm tốt hơn? Rốt cuộc, có một ngành công nghiệp hàng tỷ đô la ngoài kia không thể nói được phép tính pi từ một chiếc bánh trên bầu trời. Sau đó, một lần nữa, ngành công nghiệp đó chi hàng tỷ đô la để sửa lỗi.

Họ sẽ không bao giờ cần thiết. Đây không bao giờ là một câu hỏi đáng giá trong nghiên cứu. Không thể dự đoán trước những gì sẽ có hậu quả lâu dài. Tôi thậm chí sẽ đi xa hơn và nói rằng đó là một giả định an toàn rằng bất kỳ nghiên cứu nào cũng sẽ có hậu quả vào một ngày nào đó - chúng ta chỉ không biết vào lúc đó liệu ngày đó sẽ đến vào năm tới hay thiên niên kỷ tới.

Tôi thấy rất nhiều biến thể trên máy tính Pi ngoài kia và có rất nhiều nghiên cứu tích cực, nhưng liệu chúng có cần thiết hay có những ứng dụng quan trọng không?

Lý do tại sao tôi hỏi là vì tôi thích phát triển ngôn ngữ lập trình và mục tiêu cuối cùng thực sự sẽ là sử dụng lý thuyết để thực sự xây dựng PL. Đối với những thứ tôi đã viết, thực sự không có bất kỳ mối tương quan nào với lý thuyết cả.

Đây là một câu hỏi mẹo! Tôi sẽ cho bạn biết ý kiến ​​cá nhân của tôi và tôi nhấn mạnh rằng đây là ý kiến của tôi .

Tôi không nghĩ pi-compus phù hợp trực tiếp như một ký hiệu cho lập trình đồng thời. Tuy nhiên, tôi nghĩ bạn chắc chắn nên nghiên cứu nó trước khi thiết kế một ngôn ngữ lập trình đồng thời. Lý do là tính toán pi cho mức độ thấp --- nhưng quan trọng là thành phần! --- tài khoản đồng thời. Kết quả là, nó có thể thể hiện mọi thứ bạn muốn, nhưng không phải lúc nào cũng thuận tiện.

Giải thích nhận xét này đòi hỏi phải suy nghĩ một chút về các loại. Đầu tiên, các ngôn ngữ lập trình hữu ích thường cần một số loại kỷ luật để xây dựng trừu tượng. Cụ thể, bạn cần một số loại chức năng để sử dụng các tóm tắt thủ tục khi xây dựng phần mềm.

Bây giờ, kỷ luật kiểu tự nhiên của pi-compus là một số biến thể của logic tuyến tính cổ điển. Xem, ví dụ, Khả năng thực hiện quy trình giấy của Abramsky , cho thấy cách bạn diễn giải các chương trình đồng thời đơn giản như là bằng chứng của các đề xuất từ ​​logic tuyến tính. (Tài liệu chứa rất nhiều công việc về các loại phiên để gõ các chương trình tính toán pi, nhưng các loại phiên và loại tuyến tính có liên quan rất chặt chẽ với nhau.)

$A \multimap B$$A^\bot ⅋ B$

Điều này chỉ tốt từ lý thuyết loại POV, nhưng thật bất tiện khi lập trình. Lý do là các lập trình viên cuối cùng không chỉ quản lý các cuộc gọi chức năng của họ, mà còn cả ngăn xếp cuộc gọi. (Thật vậy, việc mã hóa lambda tính toán thành phép tính pi thường kết thúc giống như biến đổi CPS.) Bây giờ, gõ đảm bảo rằng họ sẽ không bao giờ làm hỏng việc này, nhưng tuy nhiên, đó là rất nhiều sổ sách kế toán được đưa vào lập trình viên.

Đây không phải là vấn đề duy nhất đối với lý thuyết đồng thời --- tính toán mu cung cấp một tài khoản lý thuyết bằng chứng tốt về các toán tử điều khiển tuần tự như cuộc gọi / cc, nhưng với giá làm cho ngăn xếp rõ ràng, khiến nó trở thành ngôn ngữ lập trình khó xử.

Vì vậy, khi thiết kế một ngôn ngữ lập trình đồng thời, ý kiến ​​của tôi là bạn nên thiết kế ngôn ngữ của mình với mức độ trừu tượng cao hơn so với phép tính pi thô, nhưng bạn nên chắc chắn rằng nó được dịch rõ ràng thành một phép tính quy trình gõ hợp lý. (Một ví dụ điển hình gần đây về điều này là các quy trình, chức năng và phiên thứ tự cao hơn của Tonhino, Caires và Pfenning : Một sự tích hợp đơn nguyên .)

Bạn nói rằng " mục tiêu cuối cùng thực sự sẽ là sử dụng lý thuyết để thực sự xây dựng PL." Vì vậy, bạn có lẽ thừa nhận rằng có những mục tiêu khác?

Theo quan điểm của tôi, mục đích số 1 của lý thuyết là cung cấp sự hiểu biết, có thể là lý luận về các ngôn ngữ lập trình hiện có cũng như các chương trình được viết trong đó. Trong thời gian rảnh rỗi, tôi duy trì một phần mềm lớn, một ứng dụng email, được viết từ lâu ở Lisp. Tất cả các lý thuyết PL mà tôi biết như logic Hoare, Logic tách biệt, trừu tượng hóa dữ liệu, tham số quan hệ và tương đương theo ngữ cảnh, v.v ... đều có ích trong công việc hàng ngày. Ví dụ, nếu tôi mở rộng phần mềm với một tính năng mới, tôi biết rằng nó vẫn phải duy trì chức năng ban đầu, điều đó có nghĩa là nó sẽ hoạt động theo cùng một cách trong tất cả các bối cảnh cũ mặc dù nó sẽ làm điều gì đó mới bối cảnh mới. Nếu tôi không biết gì về sự tương đương theo ngữ cảnh, có lẽ tôi thậm chí sẽ không thể giải quyết vấn đề theo cách đó.

Đến với câu hỏi của bạn về pi-compus, tôi nghĩ rằng pi-compus vẫn còn quá mới để tìm các ứng dụng trong thiết kế ngôn ngữ. Các trang wikipedia trên pi-calculus không đề cập đến BPML và Occam-pi như thiết kế ngôn ngữ sử dụng pi-calculus. Nhưng bạn cũng có thể xem các trang của CCS tiền nhiệm và các tính toán quy trình khác như CSP, tham gia tính toán và các tính toán khác, đã được sử dụng trong nhiều thiết kế ngôn ngữ lập trình. Bạn cũng có thể xem phần "Đối tượng và tính toán pi" của cuốn sách Sangiorgi và Walker để xem cách tính toán pi liên quan đến các ngôn ngữ lập trình hiện có.

Tôi thích tìm kiếm các triển khai thực tế của tính toán quá trình trong tự nhiên :) (bên cạnh việc đọc về lý thuyết).

1. Các kênh async của Clojure dựa trên CSP: http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html
2. Golang cũng có các kênh dựa trên CSP (tôi nghĩ rằng Rich Hickey lấy cảm hứng từ clojure này): http://www.informit.com/articles/printerfriendly/1768317
3. Có một anh chàng đã thực hiện một phần mở rộng dựa trên ACP cho scala (Đăng ký) nhưng tôi không có đủ danh tiếng để đăng liên kết ...

Vân vân.