Mức độ trừu tượng tiếp theo là gì? [đóng cửa]

Do các ngôn ngữ lập trình ban đầu chỉ sử dụng các dòng mã được thực thi tuần tự và nó đã phát triển thành các hàm là một trong những mức trừu tượng đầu tiên, sau đó các lớp và các đối tượng được tạo ra để trừu tượng hóa hơn nữa; mức độ trừu tượng tiếp theo là gì?

Điều gì thậm chí còn trừu tượng hơn các lớp học hoặc chưa có?

Tôi nghĩ rằng bạn có một số quan niệm sai lầm về lịch sử của máy tính.

Sự trừu tượng đầu tiên (vào năm 1936), trên thực tế, Lambda Compus của Alonzo Church, là nền tảng cho khái niệm về các hàm bậc cao và tất cả các ngôn ngữ chức năng tiếp theo. Nó trực tiếp truyền cảm hứng cho Lisp (ngôn ngữ lập trình cấp cao lâu đời thứ hai, được tạo ra vào năm 1959), từ đó truyền cảm hứng cho mọi thứ từ ML đến Haskell và Clojure.

Sự trừu tượng thứ hai là lập trình thủ tục. Nó ra đời từ các kiến ​​trúc máy tính von Neumann nơi các chương trình tuần tự được viết, mỗi lần một hướng dẫn. FORTRAN (ngôn ngữ lập trình cấp cao lâu đời nhất, 1958) là ngôn ngữ cấp cao đầu tiên ra khỏi mô hình thủ tục.

Sự trừu tượng thứ ba có lẽ thực sự là lập trình khai báo, lần đầu tiên được minh họa bởi absys (1967), và sau đó là Prolog (1972). Nó là nền tảng của lập trình logic, trong đó các biểu thức được đánh giá bằng cách khớp một loạt các khai báo hoặc quy tắc, thay vì thực hiện một loạt các hướng dẫn.

Sự trừu tượng thứ tư sau đó là lập trình hướng đối tượng, xuất hiện lần đầu tiên trong các chương trình Lisp vào những năm 60, nhưng sau đó đã được Smalltalk minh họa vào năm 1972. (Mặc dù dường như có một số tranh luận về việc liệu kiểu truyền tin của Smalltalk có phải là sự trừu tượng hướng đối tượng One True. Tôi sẽ không chạm vào điều đó.)

Tất cả các khái niệm trừu tượng khác, đặc biệt là trên kiến ​​trúc máy tính von Neumann truyền thống, là các biến thể của bốn chủ đề đó. Tôi không tin rằng có một sự trừu tượng khác ngoài bốn thứ đó không chỉ đơn thuần là một biến thể hay sự kết hợp của chúng.

Nhưng một sự trừu tượng về bản chất chỉ là một cách để mô hình hóa và mô tả một thuật toán. Bạn có thể mô tả các thuật toán như một chuỗi các bước riêng biệt, như một tập hợp các quy tắc phải được tuân theo, như một tập hợp các hàm toán học hoặc như các đối tượng tương tác. Rất khó để nghĩ ra bất kỳ cách nào khác để mô tả hoặc mô hình thuật toán, và ngay cả khi có, tôi không bị thuyết phục về tiện ích của nó.

Tuy nhiên, có mô hình điện toán lượng tử. Trong điện toán lượng tử, sự trừu tượng mới là cần thiết để mô hình hóa các thuật toán lượng tử. Là một người mới trong lĩnh vực này, tôi không thể nhận xét về nó.

Đối với nhiều người, hình thức trừu tượng mã thuần túy nhất trong kỷ nguyên lập trình nhị phân hiện nay là "hàm bậc cao hơn". Về cơ bản, chính hàm được coi là dữ liệu và các hàm của hàm được xác định, giống như bạn thấy chúng trong các phương trình toán học với các toán tử xác định kết quả của toán hạng của chúng và một thứ tự các hoạt động được xác định trước xác định "lồng" của các hoạt động này. Toán học có rất ít "mệnh lệnh bắt buộc" trong cấu trúc của nó; hai ví dụ tôi có thể nghĩ đến là "let x có một số giá trị hoặc là bất kỳ giá trị nào tuân theo một số ràng buộc" và "các hàm piecewise" trong đó đầu vào xác định biểu thức cần thiết để tạo đầu ra. Các cấu trúc này có thể dễ dàng biểu diễn như các chức năng riêng của chúng; "hàm" x luôn trả về 1 và "quá tải" của các hàm được định nghĩa theo những gì được truyền cho chúng (không giống như quá tải hướng đối tượng có thể được xác định dựa trên giá trị đầu vào) cho phép đánh giá "từng phần" của một nhóm hàm được đặt tên, ngay cả về mặt chính chúng. Như vậy, chương trình loại bỏ khái niệm mệnh lệnh ở mức thấp, và thay vào đó tập trung vào "đánh giá chính nó" cho dữ liệu đầu vào.

Các hàm bậc cao này tạo thành xương sống của "ngôn ngữ chức năng"; những gì một chương trình làm được định nghĩa theo "các hàm thuần túy" (một hoặc nhiều đầu vào, một hoặc nhiều đầu ra, không có tác dụng phụ hoặc "trạng thái ẩn"), được lồng vào nhau và được đánh giá là cần thiết. Trong những trường hợp như vậy, hầu hết "logic bắt buộc" được trừu tượng hóa; bộ thực thi xử lý việc gọi các hàm thực tế và bất kỳ điều kiện nào trong đó một hoặc quá tải khác của hàm có thể cần được gọi. Trong một chương trình như vậy, mã không được coi là "làm" một cái gì đó, nó được coi là "là" một cái gì đó, và chính xác nó được xác định là gì khi chương trình chạy đầu vào ban đầu.

Các hàm bậc cao hiện cũng là một phần chính của nhiều ngôn ngữ bắt buộc; Các câu lệnh lambda của .NET về cơ bản cho phép đầu vào chức năng "ẩn danh" vào một "chức năng" khác (được triển khai một cách bắt buộc nhưng về mặt lý thuyết thì không phải như vậy), do đó cho phép "xâu chuỗi" các chức năng "có mục đích rất chung" để đạt được kết quả mong muốn.

Một sự trừu tượng khác thường thấy trong vòng ngôn ngữ lập trình mới nhất là gõ biến động dựa trên khái niệm "gõ vịt"; Nếu nó trông giống như một con vịt, bơi như vịt, bay như vịt và quạ như vịt, bạn có thể gọi nó là vịt. Không quan trọng nếu nó thực sự là một con vịt trời hay một tấm vải bố. Nó có thể có vấn đề nếu nó thực sự là một con ngỗng hoặc một con thiên nga, nhưng sau đó một lần nữa nó có thể không quan trọng nếu tất cả các bạn quan tâm là nó bơi và ruồi, và kinda trông giống như một con vịt. Đây được coi là cuối cùng trong kế thừa đối tượng; bạn không quan tâm nó là gì , ngoại trừ đặt tên cho nó; những gì quan trọng hơn là những gì nó làm. Trong các ngôn ngữ như vậy về cơ bản chỉ có hai loại; "nguyên tử", một yếu tố thông tin duy nhất (một "giá trị"; số, ký tự, hàm, bất cứ thứ gì) và "tuple", bao gồm một nguyên tử và "con trỏ" cho mọi thứ khác trong bộ dữ liệu. Chính xác làm thế nào các loại này được thực hiện trong nhị phân bởi thời gian chạy là không liên quan; bằng cách sử dụng chúng, bạn có thể đạt được chức năng của hầu hết mọi loại bạn có thể nghĩ đến, từ các loại giá trị đơn giản đến chuỗi cho đến các bộ sưu tập (do giá trị có thể thuộc các "loại" khác nhau, cho phép "các loại phức tạp" hay còn gọi là "đối tượng").

Người ta có thể coi các ngôn ngữ cụ thể miền như SQL như một thứ tự trừu tượng cao hơn. SQL là một ngôn ngữ được nhắm mục tiêu rất trừu tượng hóa các hoạt động như lưu trữ và cung cấp các hàm cấp cao hơn dựa trên lý thuyết tập hợp. Cũng xem xét có bao nhiêu ngôn ngữ chính hiện nay không nhắm mục tiêu vào một kiến ​​trúc cụ thể mà là Máy ảo (như JVM hoặc .NET CLR). Đối với một ví dụ, C # được biên dịch sang IL, được diễn giải (hoặc thường xuyên hơn là JIT'd --Just In Time Compiled-- cho một triển khai riêng) bởi công cụ thời gian chạy gốc.

Đã có nhiều hubbub về khái niệm DSL được sử dụng để tạo ra các ngôn ngữ cấp độ cao có thể được sử dụng mà không cần nhiều kinh nghiệm kỹ thuật để tạo ra một chương trình làm việc. Hãy suy nghĩ nếu ai đó có thể mô tả các thực thể và tương tác của họ gần với tiếng Anh đơn giản và môi trường hoạt động đã xử lý mọi thứ từ việc trình bày một UI đơn giản, đến lưu trữ dữ liệu trong một loại cơ sở dữ liệu nào đó. Một khi các hoạt động đó trở nên trừu tượng, bạn có thể tưởng tượng việc lập trình dễ dàng như thế nào.

Ngày nay có một số tồn tại như JetBrains MPS (là bộ công cụ để mô tả DSL hoặc trình tạo ngôn ngữ). Microsoft đã có một bước đột phá ngắn (và rất hứa hẹn tôi có thể thêm) vào không gian này với ngôn ngữ M (ngôn ngữ M hoàn chỉnh đến mức ngôn ngữ được xác định bằng M).

Những chỉ trích về khái niệm chỉ ra những nỗ lực thất bại trước đó đã loại bỏ các lập trình viên khỏi công việc phát triển các chương trình, sự khác biệt với các bàn làm việc DSL (như Fowler gọi họ) là, các nhà phát triển vẫn sẽ tham gia vào việc mã hóa các khái niệm mà các Chuyên gia Miền có thể sử dụng để thể hiện nhu cầu của miền của họ. Giống như các nhà cung cấp hệ điều hành và ngôn ngữ tạo ra các công cụ mà chúng tôi sử dụng để lập trình, chúng tôi sẽ sử dụng DSL để cung cấp các công cụ cho người dùng doanh nghiệp. Người ta có thể tưởng tượng DSL mô tả dữ liệu và logic, trong khi các nhà phát triển tạo ra các trình thông dịch lưu trữ và truy xuất dữ liệu và áp dụng logic được thể hiện trong DSL.

Tôi sẽ lập luận rằng các cấu trúc meta, mô-đun, khung, nền tảng và dịch vụ đều là các nhóm tính năng cấp cao hơn các lớp. Hệ thống phân cấp của tôi về trừu tượng hệ thống lập trình:

• dịch vụ
• nền tảng, ngăn xếp giải pháp
• khung
• mô-đun, gói
• cấu trúc meta: siêu dữ liệu, chức năng bậc cao hơn, tổng quát, mẫu, đặc điểm, khía cạnh, trang trí
• đối tượng, lớp, kiểu dữ liệu
• chức năng, thủ tục, chương trình con
• Cấu trúc điều khiển
• dòng mã

Các cấu trúc meta như siêu dữ liệu , các hàm bậc cao hơn và tổng quát rõ ràng thêm sự trừu tượng hóa cho các lớp cơ bản, hàm, kiểu dữ liệu và trường hợp dữ liệu. Đặc điểm, khía cạnh và trang trí là các cơ chế mới hơn để kết hợp các tính năng mã và tương tự 'tăng tốc' các lớp và chức năng khác.

Ngay cả các ngôn ngữ tiền đối tượng cũng có các mô-đun và gói, vì vậy việc đặt chúng ở trên các lớp có thể gây tranh cãi. Bu chúng chứa các lớp và cấu trúc meta, vì vậy tôi xếp hạng chúng cao hơn.

Các khung là câu trả lời xác thực nhất - chúng phối hợp nhiều lớp, cấu trúc meta, mô-đun, hàm và như vậy để cung cấp các tóm tắt cấp cao tinh vi. Tuy nhiên, các khung công tác vẫn hoạt động gần như hoàn toàn trong lĩnh vực lập trình.

Ngăn xếp giải pháp hoặc nền tảng thường kết hợp nhiều khung, hệ thống con hoặc thành phần vào một môi trường để giải quyết nhiều vấn đề.

Cuối cùng, có các dịch vụ - được triển khai dưới dạng dịch vụ Web hoặc mạng. Đây là các kiến ​​trúc, khung, ngăn xếp giải pháp hoặc khả năng ứng dụng được phân phối dưới dạng các gói hoàn chỉnh. Nội bộ của họ thường mờ đục, chủ yếu phơi bày quản trị viên, lập trình và giao diện người dùng. PaaS và SaaS là những ví dụ phổ biến.

Bây giờ, sự tiến triển này có thể không hoàn toàn thỏa mãn, vì một vài lý do. Đầu tiên, nó tạo ra một sự tiến triển tuyến tính hoặc phân cấp gọn gàng của những thứ không hoàn toàn tuyến tính hoặc phân cấp. Nó bao gồm một số khái niệm trừu tượng như "ngăn xếp" và dịch vụ không hoàn toàn dưới sự kiểm soát của nhà phát triển. Và nó không tạo ra bất kỳ bụi pixie ma thuật mới. (Spoiler: Không có bụi pixie ma thuật. )

Tôi nghĩ rằng đó là một sai lầm khi chỉ tìm kiếm các mức độ trừu tượng mới . Tất cả những cái tôi liệt kê ở trên đã tồn tại trong nhiều năm , ngay cả khi chúng chưa nổi bật hoặc phổ biến như bây giờ. Và trong những năm đó, sự trừu tượng có thể ở mọi cấp độ mã hóa đã được cải thiện. Bây giờ chúng ta có các bộ sưu tập chung, đa mục đích, không chỉ là mảng. Chúng tôi lặp qua các bộ sưu tập, không chỉ phạm vi chỉ mục. Chúng tôi có danh sách hiểu và lọc danh sách và hoạt động bản đồ. Nhiều hàm của ngôn ngữ có thể có số lượng đối số và / hoặc đối số mặc định khác nhau. Và như thế. Chúng tôi đang tăng sự trừu tượng ở mọi cấp độ, vì vậy việc thêm nhiều cấp độ không phải là một yêu cầu để tăng mức độ trừu tượng chung.

Sự trừu tượng tiếp theo sau các lớp là các lớp meta . Nó đơn giản mà ;)

một lớp có phiên bản là các lớp. Giống như một lớp bình thường định nghĩa hành vi của các đối tượng nhất định, siêu dữ liệu định nghĩa hành vi của các lớp nhất định và các thể hiện của chúng. Không phải tất cả các ngôn ngữ lập trình hướng đối tượng đều hỗ trợ siêu dữ liệu. Trong số những người làm điều đó, mức độ mà siêu dữ liệu có thể ghi đè lên bất kỳ khía cạnh nhất định nào của hành vi lớp học khác nhau. Mỗi ngôn ngữ có giao thức metaobject riêng, một bộ quy tắc chi phối cách các đối tượng, lớp và siêu dữ liệu tương tác ...

Tôi ngạc nhiên không ai đã đề cập đến lý thuyết thể loại.

Đơn vị cơ bản nhất của lập trình là hàm dựa trên các loại. Các hàm thường được ký hiệu là f: A -> B, trong đó A và B là các loại. Nếu bạn đặt những thứ này, mà tôi đang gọi các loại và hàm, cùng nhau theo đúng cách bạn sẽ có được một thứ gọi là danh mục. Bạn không phải dừng lại ở thời điểm này.

Lấy những thứ này, danh mục và tự hỏi đâu sẽ là cách chính xác để liên hệ chúng với nhau. Nếu bạn làm đúng, bạn sẽ nhận được một thứ gọi là functor nằm giữa hai loại và thường được ký hiệu là F: C -> B. Một lần nữa, bạn không phải dừng lại.

Bạn có thể lấy tất cả functor và đặt chúng theo đúng cách và nếu bạn làm mọi thứ vừa phải, bạn bắt đầu tự hỏi làm thế nào để liên kết hai functor với nhau. Tại thời điểm này, bạn nhận được một thứ gọi là biến đổi tự nhiên, mu: F -> G, trong đó F và G là functor.

Kiến thức của tôi tại thời điểm này trở nên mờ nhạt nhưng bạn có thể tiếp tục làm điều này và tiếp tục leo lên các bậc thang trừu tượng. Các đối tượng và các lớp thậm chí không đến gần để mô tả mức độ bạn có thể leo lên thang trừu tượng. Có nhiều ngôn ngữ có thể diễn đạt các khái niệm trên một cách tính toán và nổi bật nhất trong số các ngôn ngữ đó là Haskell. Vì vậy, nếu bạn thực sự muốn biết sự trừu tượng thực sự là gì thì hãy tìm hiểu một số Haskell hoặc Agda hoặc HOL hoặc ML.

Tôi nghĩ rằng mô hình diễn viên bị thiếu trong danh sách các ứng cử viên.

Đây là những gì tôi muốn nói bởi các diễn viên:

• thực thể độc lập
• nhận được tin nhắn và khi nhận được tin nhắn, có thể
• tạo diễn viên mới,
• cập nhật một số trạng thái nội bộ cho tin nhắn tiếp theo,
• và gửi tin nhắn

Mô hình này là một cái gì đó vượt ra ngoài các máy Turing xác định và thực sự gần với phần cứng trong thế giới thực của chúng ta khi xem xét các chương trình đồng thời. Trừ khi bạn sử dụng các bước đồng bộ hóa (tốn kém), ngày nay, khi mã của bạn nhận được dữ liệu, giá trị đó có thể đã thay đổi ở phía bên kia của cùng một khuôn, thậm chí có thể nằm trong cùng lõi.

Thảo luận / giới thiệu ngắn: http://youtube.com/watch?v=7erJ1DV_Tlo

Nếu tôi hiểu bạn một cách chính xác, "sự trừu tượng tăng dần" của bạn có thể được coi là sự đóng gói logic ngày càng lớn, chủ yếu liên quan đến việc sử dụng lại mã.

Từ các hướng dẫn cụ thể được thực hiện lần lượt, chúng ta chuyển sang các hàm / chương trình con , gói gọn hoặc trừu tượng, một nhóm các lệnh hợp lý thành một phần tử duy nhất. Sau đó, chúng ta có các đối tượng hoặc mô-đun , đóng gói các chương trình con liên quan đến một thực thể hoặc thể loại logic nhất định, vì vậy tôi có thể nhóm tất cả các hoạt động chuỗi trong Stringlớp hoặc tất cả các hoạt động toán học phổ biến trongMath mô-đun (hoặc lớp tĩnh, bằng các ngôn ngữ như C #) .

Vì vậy, nếu đó là sự tiến bộ của chúng tôi, điều gì tiếp theo? Chà, tôi không nghĩ rằng bạn có một bước tiếp theo rõ ràng. Như những người khác đã trả lời, sự tiến bộ của bạn chỉ áp dụng cho các phong cách lập trình bắt buộc / thủ tục và các mô hình khác không chia sẻ các khái niệm trừu tượng của bạn. Nhưng nếu tôi có thứ gì đó có thể mở rộng một cách hợp lý ẩn dụ của bạn, thì đó là dịch vụ .

Một dịch vụ tương tự như một lớp theo nghĩa là nó là một thực thể phơi bày chức năng, nhưng nó bao hàm sự phân tách các mối quan tâm chặt chẽ hơn nhiều so với các đối tượng mà bạn tự khởi tạo. Chúng phơi bày một tập hợp các thao tác giới hạn, ẩn logic bên trong và thậm chí không nhất thiết phải chạy trên cùng một máy.

Một lần nữa, có một sự phân biệt tốt. Trong hầu hết các trường hợp, bạn sẽ sử dụng một đối tượng hoạt động như một proxy cho một dịch vụ và hai đối tượng sẽ rất giống nhau, nhưng là một kiến ​​trúc, hai đối tượng này là khác biệt.

Các hình thức trừu tượng mới che giấu công việc cấp thấp từ bạn. Các thủ tục và chức năng được đặt tên ẩn địa chỉ chương trình từ bạn. Các đối tượng ẩn quản lý bộ nhớ động và một số câu lệnh "if" phụ thuộc vào loại.

Tôi muốn đề xuất rằng mức độ trừu tượng thực tế tiếp theo sẽ che giấu sự bực bội ở mức độ thấp đối với bạn là những chương trình phản ứng chức năng . Nhìn vào "tín hiệu" trong một cái gì đó như http://elm-lang.org/ để ẩn các cuộc gọi lại và cập nhật phụ thuộc mà bạn sẽ phải quản lý rõ ràng trong javascript. FRP có thể che giấu rất nhiều sự phức tạp của quá trình liên thông và giao tiếp giữa các máy cần thiết trong các ứng dụng internet quy mô lớn và song song hiệu năng cao.

Tôi khá chắc chắn rằng đây là điều mà tất cả chúng ta sẽ phấn khích trong 5 năm tới.

Đặt lý thuyết - như được thực hiện một phần trong cơ sở dữ liệu quan hệ, nhưng cũng bằng các ngôn ngữ thống kê như SAS và R, cung cấp một mức độ trừu tượng khác nhau nhưng cao hơn nhiều so với OO.