Làm thế nào gần chúng ta đã nhận được để tự động viết mã? [đóng cửa]

Và tôi không có nghĩa là đoạn mã tự động hoàn thành hoặc tự động được chèn bởi các trình soạn thảo hiện đại hoặc mã đa hình. Nhưng đâu là công nghệ tiên tiến trong các chương trình có thể đi qua các đầu vào, loại và thông tin của đầu ra mong muốn và xuất ra một đoạn mã hợp lệ theo ngôn ngữ được lựa chọn. Tôi biết về lập trình di truyền, lập trình biểu hiện gen nhưng tôi không biết về bất kỳ nỗ lực nào khác. Ngoài ra googling không bật lên nhiều.

Có ai biết bất kỳ tiến bộ trên mặt trận này?

Chỉnh sửa: Khi tôi nói "xuất ra một đoạn mã hợp lệ", ý tôi là AI hoặc thứ gì đó tương tự đang xử lý logic và luồng điều khiển và thực hiện nó bằng ngôn ngữ bắt buộc. Chỉ ngôn ngữ bắt buộc, vì đó là phần khó khăn. Tuy nhiên, nếu bạn biết bất kỳ ngôn ngữ mới nào đang được phát triển để hỗ trợ loại ý tưởng này, xin vui lòng đề cập, vì có thể bộ ngôn ngữ hiện tại của chúng tôi không phù hợp với loại AI đầu tiên chúng ta có thể có cơ hội đầu tiên.

Ngôn ngữ dành riêng cho tên miền gần như chúng ta sẽ có.

Bạn sẽ luôn phải cung cấp cho máy tính một số quy tắc để làm việc. Nhưng càng nhiều quy tắc được xác định theo cách cụ thể cho miền của họ, thì càng ít đầu vào.

Các ngôn ngữ dành riêng cho tên miền nhắm mục tiêu phát triển web yêu cầu ít mã hóa hơn các ngôn ngữ chung chung hơn. Các ngôn ngữ dành riêng cho tên miền mà kiểm tra mục tiêu yêu cầu mã hóa ít hơn các ngôn ngữ không. Các ngôn ngữ dành riêng cho miền mà mục tiêu di truyền yêu cầu ít mã hóa hơn các ngôn ngữ không có. Và như thế.

Bây giờ, đây là câu hỏi lớn: Khi nào một tên miền trở nên đủ lớn để biện minh cho việc viết một ngôn ngữ dành riêng cho tên miền đó? Phát triển và thử nghiệm web là những thứ mà ít nhất một nửa thế giới phát triển đang làm việc. Không thể tránh khỏi các khung công tác sẽ xuất hiện, làm giảm số lượng mã soạn sẵn cho những thứ này (về cơ bản, là một ngôn ngữ dành riêng cho tên miền).

Nhưng làm thế nào về lĩnh vực kinh doanh của công ty bạn? Có đáng để tập trung vào những điều thường được đề cập trong công ty của bạn và làm cho nó để bạn có thể tham khảo những điều đó một cách dễ dàng trong mã? Tôi không nghĩ rằng chúng tôi thực sự đã tìm thấy sự cân bằng đó, mặc dù thiết kế hướng tên miền là về việc trả lời câu hỏi đó.

Trong những năm 80 và 90, có rất nhiều tiếng vang về cái gọi là ngôn ngữ thế hệ thứ 4 . Từ bài viết Wikipedia:

Tất cả các 4GL được thiết kế để giảm nỗ lực lập trình, thời gian cần thiết để phát triển phần mềm và chi phí phát triển phần mềm. Họ không phải lúc nào cũng thành công trong nhiệm vụ này, đôi khi dẫn đến mã không phù hợp và không thể nhầm lẫn. Tuy nhiên, với một vấn đề phù hợp, việc sử dụng 4GL phù hợp có thể thành công ngoạn mục

...

Một số loại 4GL khác nhau tồn tại:

• Lập trình dựa trên bảng (không mã hóa), thường chạy với khung thời gian chạy và thư viện. Thay vì sử dụng mã, nhà phát triển xác định logic của mình bằng cách chọn một thao tác trong danh sách được xác định trước của các lệnh thao tác bộ nhớ hoặc bảng dữ liệu. Nói cách khác, thay vì mã hóa, nhà phát triển sử dụng lập trình thuật toán dựa trên Bảng (Xem thêm các bảng điều khiển có thể được sử dụng cho mục đích này). Một ví dụ điển hình của loại ngôn ngữ 4GL này là PowerBuilder. Các loại công cụ này có thể được sử dụng để phát triển ứng dụng kinh doanh thường bao gồm một gói cho phép cả thao tác và báo cáo dữ liệu kinh doanh, do đó chúng đi kèm với màn hình GUI và trình chỉnh sửa báo cáo. Họ thường cung cấp tích hợp với các DLL cấp thấp hơn được tạo từ 3GL điển hình khi có nhu cầu cho các hoạt động cụ thể hơn về phần cứng / hệ điều hành.
• Các ngôn ngữ lập trình trình tạo báo cáo lấy một mô tả về định dạng dữ liệu và báo cáo để tạo và từ đó chúng tạo ra báo cáo được yêu cầu trực tiếp hoặc chúng tạo ra một chương trình để tạo báo cáo. Xem thêm RPG
• Tương tự, các trình tạo biểu mẫu quản lý các tương tác trực tuyến với người dùng hệ thống ứng dụng hoặc tạo các chương trình để làm như vậy.
• Các 4GL tham vọng hơn (đôi khi được gọi là môi trường thế hệ thứ tư) cố gắng tự động tạo toàn bộ hệ thống từ đầu ra của các công cụ CASE, thông số kỹ thuật của màn hình và báo cáo và có thể cả đặc điểm kỹ thuật của một số logic xử lý bổ sung.
• Quản lý dữ liệu 4GL như SAS, SPSS và Stata cung cấp các lệnh mã hóa tinh vi để thao tác dữ liệu, định hình lại tệp, chọn trường hợp và tài liệu dữ liệu để chuẩn bị dữ liệu cho phân tích và báo cáo thống kê.

Thật thú vị khi đối chiếu 4GL với các ngôn ngữ lập trình thế hệ thứ năm :

Ngôn ngữ lập trình thế hệ thứ năm (viết tắt 5GL) là ngôn ngữ lập trình dựa trên việc giải quyết các vấn đề bằng cách sử dụng các ràng buộc được đưa ra cho chương trình, thay vì sử dụng thuật toán được viết bởi một lập trình viên. Hầu hết các ngôn ngữ lập trình dựa trên logic và ràng buộc và một số ngôn ngữ khai báo là ngôn ngữ thế hệ thứ năm.

Trong khi các ngôn ngữ lập trình thế hệ thứ tư được thiết kế để xây dựng các chương trình cụ thể, các ngôn ngữ thế hệ thứ năm được thiết kế để làm cho máy tính giải quyết một vấn đề nhất định mà không cần lập trình viên. Bằng cách này, lập trình viên chỉ cần lo lắng về những vấn đề cần giải quyết và những điều kiện cần phải được đáp ứng, mà không cần lo lắng về cách thực hiện một thói quen hoặc thuật toán để giải quyết chúng. Ngôn ngữ thế hệ thứ năm được sử dụng chủ yếu trong nghiên cứu trí tuệ nhân tạo. Prolog, OPS5 và Mercury là những ví dụ về ngôn ngữ thế hệ thứ năm.

Cuối cùng, ngay cả khi bạn không 'lập trình' máy tính, vẫn có người phải giải thích các yêu cầu của bạn với máy tính.

Một trong những cách tiếp cận được thảo luận nhiều nhất để tạo mã tự động là "MDA" hay còn gọi là Kiến trúc hướng mô hình. Hầu hết (nhưng không nhất thiết) người ta đưa lên UML thông qua trình soạn thảo GUI trực quan từ đó các lớp có liên quan được tạo.

Trong khi, tôi nghĩ rằng sự biểu hiện của mã chức năng đầy đủ có thể vẫn còn xa, có những hệ thống khá đủ tốt để tạo ra bộ xương hoàn chỉnh.

Kiểm tra: http://www.actifsource.com/actifsource/index.html

Ngoài ra: http://www.win.tue.nl/~mchaudro/cbse2007/programgenerators.pdf

http://proglang.informatik.uni-freiburg.de/teaching/mda/2006ss/09-code-gen.pdf

Tôi đã viết nhiều trình tạo mã cho Java và C # để tạo mã làm việc cho các tác vụ khác nhau. Có các gói như JAXB, phân tích một tài liệu XML và tạo ra các lớp Java tương ứng và mã sắp xếp / sắp xếp thứ tự để thực hiện dịch và Entity Framework tạo ra các lớp DTO để sắp xếp dữ liệu đến / từ cơ sở dữ liệu. Ngoài ra còn có các công cụ như Rational XDE (bất cứ thứ gì nó được gọi là bây giờ) thực hiện việc tạo mã chuyến đi khứ hồi giữa một sơ đồ lớp và Java.

Nếu bạn đang tìm kiếm thứ gì đó có thể yêu cầu kinh doanh hoặc thông số chức năng và biến nó thành mã, tôi đã không thấy nhiều tiến bộ trong lĩnh vực đó. Tôi biết OMG đang làm việc trên một số loại "UML thực thi", nhưng ngoài một số nguyên mẫu DoD tôi không biết về bất kỳ triển khai thực tế nào.

Có lập trình khai báo đếm, ví dụ Prolog hoặc SQL?

Bạn chỉ cần mô tả những gì chương trình nên hoàn thành, hoặc những điều kiện mà kết quả sẽ đáp ứng. Sau đó, bạn truy vấn hệ thống và nhận kết quả (hoặc "không có giải pháp").

Tất nhiên, dưới mui xe, có một chương trình đang chạy, nhưng bạn không bao giờ thấy mã.

Thật không may, lập trình khai báo không phải là viên đạn bạc: ngoài các trường hợp cơ bản, việc mô tả mục tiêu khai báo đủ chính xác vẫn đòi hỏi nỗ lực và kỹ năng đáng kể, thậm chí không đề cập đến việc để có được hiệu suất tốt, bạn phải tính đến nhiều điểm không hoàn hảo của thực tế, trong triển khai thực hiện (ví dụ: hiểu vai trò của các chỉ mục SQL hoặc lệnh gọi đuôi trong các định nghĩa đệ quy ...)

Tùy thuộc vào loại vấn đề, thực sự có thể dễ dàng giải quyết "cách thức" hơn là mô tả chính xác "cái gì". Đối với con người, hoặc hầu hết các lập trình viên trung bình ít nhất, suy nghĩ về "làm thế nào" dường như đến một cách tự nhiên hơn, và "chính xác" đòi hỏi thể dục dụng cụ tinh thần nhiều hơn.

Tôi không đồng ý với tuyên bố của bạn rằng "Ngôn ngữ bắt buộc ... đó là phần khó khăn". Đó là phần dễ dàng, mặc dù ở một số ngôn ngữ dễ hơn đáng kể so với các ngôn ngữ khác. Tìm hiểu những gì người dùng thực sự muốn, và sắp xếp tất cả thông tin đó là phần khó. Phần "Ngôn ngữ bắt buộc" có vẻ khó vì đó là khi tất cả các công việc thực sự được hoàn thành. Đó là khi các câu hỏi chi tiết về các yêu cầu xuất hiện và khi tất cả các câu trả lời phải được sắp xếp thành một định nghĩa hệ thống thực thi.

Không có lập trình mà không lập trình. Ai đó phải dịch những mong muốn không chính xác của con người thành một đặc điểm chính xác của một tính toán. Đặc tả đó có thể bằng ngôn ngữ lắp ráp, hoặc Java hoặc LISP, một số hệ thống sơ đồ hoặc một ngôn ngữ chưa được phát minh. Nhưng cho đến khi máy tính có khả năng giao tiếp sâu với con người, ai đó sẽ phải nói chuyện với người dùng và xác định chính xác hệ thống.

Chúng tôi đã ở đó! Tất cả những gì chúng ta cần là một ngôn ngữ với ngày nay được gọi là ký tự đồng tính và nhiều thập kỷ trước đó "mã là dữ liệu". Xác định môi trường của riêng bạn bằng cách lập trình từ dưới lên thay vì thiết kế từ trên xuống. Chẳng hạn, bạn có thể xây dựng DSL của riêng mình bên trong Lisp. Với cách tiếp cận Xếp chồng, bạn có thể đặt bao nhiêu DSL (lớp) lên nhau nếu bạn cần cho vấn đề cụ thể của mình. Cách tiếp cận này mang lại cho bạn từ một biểu thức S ở mức rất thấp cho đến sự trừu tượng hóa dữ liệu phức tạp nhất mà bạn có thể nghĩ tới. Vì vậy, viết mã tự động là gì, nếu không xếp chồng ngôn ngữ này lên ngôn ngữ khác?

Tôi đã nghe thấy những lời xì xào về nỗ lực lấy các chương trình từ các thông số kỹ thuật được thể hiện bằng cách sử dụng các loại phụ thuộc trong các hệ thống như Coq. Tôi không biết loại tiến bộ nào đã được thực hiện, mặc dù.

Làm thế nào gần chúng ta đã nhận được để tự động viết mã?

không có nơi nào gần bất cứ điều gì đáng nói.

Tôi cũng mạnh mẽ nói rằng chúng ta sẽ không bao giờ đến đó.

Nhà nước của nghệ thuật tự động viết mã? Không có "trạng thái của nghệ thuật". Nhưng có một trạng thái thất bại vĩnh viễn. Không có nỗ lực thành công cho đến nay. Nhiều khả năng sẽ không bao giờ có bất kỳ triển khai thành công nào khác ngoài một vài ví dụ rất hạn chế về phạm vi.

Đó có thể là một điều tốt vì nó sẽ đưa chúng ta ra khỏi một công việc.

BTW cho mọi người đọc .... Đừng nhầm lẫn việc tạo thuật toán với các trình tạo CRUD tầm thường như Ruby on Rails. Tạo CRUD là việc thực hiện một thuật toán được xác định trước, chứ không phải tạo ra một thuật toán để giải quyết vấn đề.

Có một số công cụ mà bạn có thể thực hiện mọi việc mà không cần viết bất kỳ mã nào (MS Access, Filemaker). Một số tạo mã trong nền có thể được thay đổi. Điều này hoạt động tốt với các ứng dụng kinh doanh và kết thúc cơ sở dữ liệu. Người dùng đập vào tường và cuối cùng thuê một lập trình viên. Logic quá phức tạp. Tôi đã thấy các ứng dụng web tạo một biểu mẫu điền vào bảng. Điều này là tuyệt vời cho đến khi bạn cần một biểu mẫu cha mẹ với một biểu mẫu con xử lý nhiều hồ sơ. Không ai trong số họ cung cấp điều này.

Cố gắng tưởng tượng làm thế nào điều này hoạt động nếu tôi muốn tự động hóa / mã hóa việc thay đổi các tập tin hình ảnh, video hoặc âm thanh. Giống như GUI cơ sở dữ liệu, ai đó có thể tạo chúng cho những cái này tạo mã thay vì chỉ thao tác với tệp.

Bảng tính đang xử lý mọi thứ, từ toán đơn giản đến thống kê khá tốt. Ghi lại một Macro và một kịch bản được tạo ra.

Sự phức tạp thường bắt kịp. Cuối cùng, bạn muốn tạo ra một cái gì đó thực sự mới. Khó khăn để xây dựng một trình tạo mã tạo mã cho một cái gì đó không ai nghĩ đến.

Với câu hỏi của bạn, tôi tin rằng bạn đang hỏi có bao nhiêu sự phát triển trong tương lai sẽ có thể giảm thiểu khối lượng công việc mà một nhà phát triển phần mềm sẽ phải làm. Ngay cả khi bạn có một AI có thể viết toàn bộ chương trình của mình, bạn vẫn phải nói cho nó biết phải làm gì, giống như đối với một người xây dựng ô tô tự động, bạn vẫn phải cung cấp cho nó một kế hoạch chi tiết, và kế hoạch chi tiết đó đòi hỏi một số công việc.

Và nếu bạn có AI, bạn vẫn phải dạy nó và nó sẽ phải học qua một vài dự án. Do đó, tôi không nghĩ rằng AI phù hợp với loại công việc này, mà là một cách tiếp cận mang tính quyết định hơn, sử dụng các trình tạo mã. Các trình tạo mã này có thể trở nên rất phức tạp, nhưng không nhất thiết phải sử dụng máy học.

Điều đó nói rằng, đã có nghiên cứu trong các lĩnh vực được gọi là Thiết kế phần mềm định hướng tính năng và Thiết kế phần mềm hướng theo khía cạnh. Chúng xử lý việc lắp ráp các ứng dụng phần mềm bằng cách chọn một số tính năng cần có và sau đó mã được tạo cho điều đó. Mục tiêu là có các triển khai cho một số tính năng xuất hiện liên tục trong một miền cụ thể và lắp ráp chúng như các khối xây dựng, phù hợp với ứng dụng cụ thể của bạn. Ví dụ, để phát triển web, các tính năng sẽ bao gồm các giao dịch, số liệu thống kê, khả năng mở rộng, ghi nhật ký và bất cứ điều gì bạn có thể nghĩ là đặc điểm định kỳ của các ứng dụng web khác nhau.

Các tính năng và khía cạnh khác nhau so với các thành phần, vì chúng thường là mối quan tâm xuyên suốt. Lấy ví dụ đăng nhập. Bạn không thể lấy một thư viện và đưa nó vào ứng dụng của bạn và nói rằng bạn đã đăng nhập ngay bây giờ. Bạn phải truyền bá các cuộc gọi đăng nhập của mình trên tất cả các mã của bạn và đó là nơi các trình tạo mã tiện dụng. Gần đây tôi đã nghe về tất cả những thứ này từ cuộc phỏng vấn hai phần này trên Radio Engineering Radio .

Có vẻ như loại nghiên cứu này khá hợp thời ở Châu Âu và đặc biệt là Đức, ngay cả trong ngành, như tôi có thể nói từ kinh nghiệm cá nhân. Tạo mã có thể hữu ích để tạo mã cơ sở hạ tầng cần thiết, để nhà phát triển có thể tập trung hoàn toàn vào việc thực hiện hành vi cụ thể của ứng dụng của mình và không bận tâm đến cùng các vấn đề phụ trên mỗi dự án khác nhau.

Vẫn còn phải xem mã đó dành riêng cho ứng dụng có thể thu hẹp bao nhiêu. Nó chắc chắn không thể được loại bỏ hoàn toàn, chỉ giảm xuống một số loại bản thiết kế, như tôi đã đề cập ở phần đầu.