Ngôn ngữ lập trình trực quan

Hầu hết chúng ta đã học lập trình bằng các ngôn ngữ lập trình "văn bản" như Basic, C / C ++ và Java. Tôi tin rằng con người sẽ suy nghĩ trực quan và hiệu quả hơn. Lập trình trực quan cho phép các nhà phát triển viết chương trình bằng cách thao tác các yếu tố đồ họa. Tôi đoán sử dụng lập trình trực quan sẽ cải thiện chất lượng mã và giảm lỗi lập trình. Tôi biết một số ngôn ngữ hình ảnh như Nhà phát minh ứng dụng , Scratch và LabView .

Tại sao không có ngôn ngữ trực quan, mục đích chung cho các nhà phát triển? Những lợi thế và bất lợi của lập trình trực quan là gì?

Nói chung, có một sự đánh đổi trong thiết kế ngôn ngữ lập trình giữa dễ sử dụng và tính biểu cảm (sức mạnh). Viết chương trình "Xin chào, thế giới" đơn giản bằng ngôn ngữ dành cho người mới bắt đầu, chẳng hạn như Scratch hoặc App Inventor, thường dễ hơn viết bằng ngôn ngữ lập trình đa năng như Java hoặc C ++, trong đó bạn có thể có nhiều lựa chọn cho một số luồng đầu ra, các bộ ký tự khác nhau, cơ hội để thay đổi cú pháp, loại động, v.v.

Trong quá trình tạo App Inventor (mà tôi là một phần của), triết lý thiết kế của chúng tôi là làm cho việc lập trình trở nên đơn giản cho người mới bắt đầu. Một ví dụ tầm thường đã dựa trên các chỉ số mảng của chúng tôi là 1, thay vì 0, mặc dù điều đó làm cho các phép tính có thể được thực hiện bởi các lập trình viên tiên tiến phức tạp hơn một chút.

Tuy nhiên, cách chính mà các ngôn ngữ lập trình trực quan có xu hướng được thiết kế cho người mới bắt đầu là bằng cách loại bỏ khả năng lỗi cú pháp bằng cách không thể tạo các chương trình không hợp lệ về mặt cú pháp. Ví dụ: các ngôn ngữ khối không cho phép bạn xác định giá trị đích của câu lệnh gán. Triết lý này có xu hướng mang lại ngữ pháp và ngôn ngữ đơn giản hơn.

Khi người dùng bắt đầu xây dựng các chương trình phức tạp hơn bằng ngôn ngữ khối, họ thấy rằng việc kéo và thả khối chậm hơn so với việc gõ. Bạn có muốn gõ "a * x ^ 2 + b * x + c" hoặc tạo nó với các khối không?

Công lý không thể được trao cho chủ đề này (ít nhất là bởi tôi) trong một vài đoạn, nhưng một số lý do chính là:

1. Các ngôn ngữ khối có xu hướng được thiết kế cho người mới bắt đầu nên không mạnh bằng thiết kế.
2. Không có cách trực quan tốt để diễn đạt một số khái niệm phức tạp, chẳng hạn như các hệ thống kiểu, mà bạn tìm thấy trong các ngôn ngữ lập trình có mục đích chung.
3. Sử dụng các khối là khó sử dụng cho các chương trình phức tạp.

Tại sao không có ngôn ngữ trực quan, mục đích chung cho các nhà phát triển? Những lợi thế và bất lợi của lập trình trực quan là gì?

Ngôn ngữ hình ảnh có xu hướng phá vỡ nó ba loại lớn:

1. Công cụ không lập trình để thực hiện các nhiệm vụ tự động hóa cơ bản. Hãy nghĩ rằng Automator trên Mac.
2. Môi trường học tập không thực tế để có nhiều thao tác gõ hoặc cấu trúc chương trình hiển thị luồng logic là quan trọng. Nghĩ rằng Scratch, Alice, v.v.
3. Vấn đề đang được giải quyết là một vấn đề về luồng dữ liệu và giải pháp cho vấn đề này được mô hình hóa tốt bằng một số loại luồng dữ liệu giữa các hộp độc lập bắt chước thế giới vật lý. LabView và Ableton đều nghĩ đến.

Lợi thế của lập trình trực quan là bạn có được một cái nhìn tổng quan cấp cao về cấu trúc hệ thống. Điều này dẫn đến một vấn đề ngay lập tức là khi bạn nhận được chi tiết, mã spaghetti của bạn thực sự trông giống như spaghetti . Một thành phần phổ biến của ngôn ngữ hình ảnh là một số loại khối mã hoặc thành phần cấu hình cho thành phần trực quan. Vấn đề là lập trình viên cần hiểu ý nghĩa của các khối mã bị ngắt kết nối có thể được liên kết với nhau theo những cách lạ.

Mặc dù không có gì sai với lập trình trực quan, nhưng có thể đơn giản đó không phải là một cách tiếp cận tốt cho hầu hết các nhiệm vụ.

Đã có nhiều ngôn ngữ lập trình trực quan, vì hai thư mục sau đây sẽ hiển thị: vlib.org và oregonstate.edu .

IMHO họ đã không đạt được lực kéo, bởi vì trong khi chúng tốt cho các ví dụ về đồ chơi, họ không thể quản lý nhiều mức độ trừu tượng, đại diện và độ chi tiết mà các dự án lớn yêu cầu. Bạn sẽ cần xem xét một hệ thống như AutoDesk Revit (một hệ thống quản lý thông tin tòa nhà được sử dụng bởi các kiến ​​trúc sư và kỹ sư) để xem cách quản lý thông tin hình ảnh phức tạp có thể trở nên như thế nào.

Thay vì nhìn vào lập trình mục đích chung, lập trình trực quan rất có thể thành công như một công cụ cấu hình trong các lĩnh vực chuyên ngành.

Văn bản là trực quan.

Chúng tôi sử dụng tất cả các loại tín hiệu trực quan trong mã của chúng tôi. Mỗi lần sử dụng khoảng trắng (thụt lề, dòng mới, dòng trống, khoảng cách nội tâm) đều hướng đến việc cung cấp tín hiệu trực quan cho chức năng của mã. Chúng tôi sử dụng tất cả các loại cú pháp khác nhau để cung cấp thông tin trực quan về mã đang làm gì. Biên tập viên của chúng tôi tô màu mã của chúng tôi để làm cho nó nổi bật.

Toán học là văn bản. Có tất cả các loại ký hiệu, nhưng cuối cùng nó đi xuống cơ bản là văn bản. Họ đã làm hàng trăm năm.

Quan điểm của tôi: sự thể hiện bằng văn bản của mã đang sử dụng các khả năng thị giác mà con người có. Chúng ta có thể sử dụng nó tốt hơn, nhưng không phải bằng cách từ bỏ văn bản.

[Đối với phiên bản PDF của câu trả lời này , các số liệu hoặc sơ đồ là tương tác và động.]

Các yếu tố và chú thích ròng: Một ngôn ngữ lập trình trực quan có mục đích chung

Tôi sử dụng đồ họa để tổ chức các chương trình JavaScript ™ sử dụng API Acrobat® / JavaScript. Mỗi đối tượng đồ họa đại diện cho một yếu tố Petri Net (địa điểm, chuyển tiếp, đầu vào hoặc đầu ra) hoặc đại diện cho nhiều hơn một yếu tố Petri Net. Mỗi đối tượng đồ họa thực sự là một chú thích của phần tử mạng tương ứng. Tuy nhiên, nếu mọi đối tượng đồ họa ánh xạ tới một và chỉ một phần tử thuần thì nó có thể được sử dụng để tạo phần tử thuần. Và nếu một đối tượng đồ họa ánh xạ tới nhiều phần tử thuần và ánh xạ được xác định rõ thì nó cũng có thể được sử dụng để tạo các phần tử mạng. Các phần tử Petri Net tiêu chuẩn được biểu thị bằng một số loại đồ họa nhất định: hình tròn là một vị trí, hình vuông hoặc hình chữ nhật hoặc đường thẳng là một chuyển tiếp, một mũi tên từ hình tròn sang hình vuông là một đầu vào và một mũi tên từ hình vuông sang hình tròn là một đầu ra. Hơn nữa,

[Các loại chú thích trong "Mạng Petri tiêu chuẩn" được tìm thấy trong phiên bản PDF của câu trả lời này.]

Carl Adam Petri đã mô tả hầu hết các ý tưởng này (bao gồm các loại chú thích trong "Mạng Petri tiêu chuẩn" trong luận án tiến sĩ của ông (Petri, 1966). Ông cũng áp dụng các yếu tố và chú thích mạng cho mô tả một số mạch logic, như Hình 6.

Lợi ích và Thách thức

Một ngôn ngữ lập trình trực quan có thể giúp một lập trình viên máy tính phát triển các chương trình máy tính (Menzies, 2002).

Tôi có ít nhất ba lý do tại sao tôi thấy các yếu tố và chú thích ròng hữu ích (lợi thế?).

Linh hồn lý trí. Logic quá trình có thể được tạo ra một yếu tố tại một thời điểm. Điều này có nghĩa là một mạng có thể được mở rộng bằng cách thêm các yếu tố vào mạng hiện có (Petri, 1966). Ví dụ, một mô hình của bộ điều khiển có thể được chia thành các thành phần bên trong và bên ngoài. Các thành phần nội bộ điều chỉnh hệ thống. Các thành phần bên ngoài giao diện với môi trường bằng cách chấp nhận đầu vào từ môi trường. Hình 1 là mô hình Petri Net của thành phần bên trong. Có thể thêm mô hình Petri Net của thành phần bên ngoài vào mô hình Petri Net của thành phần bên trong bằng cách thêm các vị trí và chuyển tiếp thích hợp (Hình 2).

Hình 1 Mô hình mạng Petri của một thành phần bên trong của bộ điều khiển (Halloway, Krogh và Giua, 1997)

Hình 2 Mô hình mạng Petri của các thành phần bên trong và bên ngoài của bộ điều khiển (Halloway, Krogh và Giua, 1997)

Lý do thứ hai. Các mã được liên kết với từng thành phần mạng có thể đến từ nhiều hơn một ngôn ngữ lập trình của Google (Petri, 1973). Chúng có thể đến từ một ngôn ngữ máy tính như JavaScript, COBOL, ADA và ngôn ngữ lắp ráp. Chúng có thể đến từ một ngôn ngữ toán học như các ký hiệu đại số. Chúng có thể đến từ văn xuôi được mã hóa bằng tiếng Anh, tiếng Đức, tiếng Pháp, tiếng Hy Lạp, tiếng Tagalog, tiếng Trung, v.v. Do đó, nó có thể được sử dụng làm cơ sở để giao tiếp và hợp tác trong suốt vòng đời phát triển phần mềm hoặc hệ thống; và trong số những người dùng, nhà phát triển và các bên liên quan khác nhau (Petri, 1973).

Lý do thứ ba. Có thể tập trung vào các đối tượng đồ họa nhất định trong mạng và viết ra các chú thích mã hoặc logic cho các đối tượng đồ họa liên quan. Xem xét mô hình Petri Net của trò chơi bài trong Hình 3. Nếu mũi tên cho đầu vào P7 T4 là đồ họa tiêu chuẩn cho đầu vào trong Địa điểm / Mạng chuyển tiếp và nếu m_7 là dấu cho vị trí P7 thì chú thích logic cho cập nhật dấu của vị trí đầu vào là m_7 = m_7-1. Nếu s_9 ^ - là trạng thái của đầu vào thì chú thích logic để cập nhật trạng thái của đầu vào là s_9 ^ - = ((m_7 <1)? False: true).

Hình 3 Mô hình Petri Net của trò chơi bài

Tôi có ít nhất ba lý do tại sao tôi thấy việc áp dụng Petri Nets đầy thách thức (nhược điểm?)

Nếu có quá nhiều đối tượng đồ họa thì sẽ khó tạo hoặc đọc mạng. Khó khăn có thể được giảm thiểu bằng cách lấy một tập hợp con của đồ họa và biểu diễn chúng bằng một, hai hoặc ba biểu tượng đồ họa (Noe, 1973; Petri, 1966). Ví dụ, nếu mô hình Petri Net của trò chơi bài trong Hình 3 được coi là có quá nhiều đối tượng đồ họa trong sơ đồ, có thể kết hợp một số đồ họa và vẫn duy trì đủ thông tin để ánh xạ sơ đồ vào chương trình máy tính. Hãy xem Hình 4, một mô hình Petri Net của cùng một trò chơi được tìm thấy trong Hình 3 với đồ họa cấp cao (Chionglo, 2016a).

Hình 4 Mô hình mạng Petri của trò chơi bài sử dụng đồ họa cấp cao (Chionglo, 2016a)

Trong một ví dụ khác, các thành phần bên ngoài của bộ điều khiển trong Hình 2 có thể được kết hợp để tạo ra một biểu diễn đồ họa ngắn gọn hơn như trong Hình 5.

Hình 5 Mô hình Petri Net của bộ điều khiển với đồ họa cấp cao cho các thành phần bên ngoài

Cuối cùng, một tập hợp các địa điểm loại trừ lẫn nhau hoặc một bộ chuyển đổi loại trừ lẫn nhau cũng có thể được biểu diễn bằng một đối tượng đồ họa cấp cao (Chionglo, 2015).

Lý do thứ hai. Ngay cả với đồ họa tiêu chuẩn, việc vẽ và định vị đồ họa có thể rất khó khăn, đặc biệt nếu người ta kỳ vọng sơ đồ cuối cùng sẽ thân thiện với người dùng hoặc người đọc. Một số quyết định để tạo một sơ đồ thân thiện với người dùng hoặc người đọc bao gồm: bố cục thích hợp của các đối tượng đồ họa, kích thước phù hợp của khung vẽ và hình dạng, độ cong của mũi tên, loại đầu mũi tên, kích thước và phông chữ của văn bản, và sự lựa chọn màu sắc cho đồ họa và văn bản.

Lý do thứ ba. Thật dễ dàng để tạo các chú thích của các phần tử ròng một cách có trật tự vì mọi chú thích đều liên quan trực tiếp hoặc gián tiếp đến một phần tử thuần. Tuy nhiên, hiển thị mọi chú thích cùng với đồ họa của mọi thành phần mạng có thể không phải là một ý tưởng hay vì có thể có quá nhiều thông tin được trình bày trong sơ đồ. Ví dụ, hãy xem xét một sơ đồ của mô hình Petri Net của mạch logic bao gồm các tham chiếu đến tất cả các chú thích thuộc tính và logic (Hình 6). [Mô hình ban đầu bao gồm một điều kiện thử nghiệm cho trạng thái của mọi đầu ra (hình 31 trên trang 78 của (Petri, 1966)); điều kiện thử nghiệm đã bị bỏ qua ở đây vì nó tương đương với mô hình ban đầu cho lần đánh dấu ban đầu đã cho. Do đó, mỗi đầu ra có một chú thích logic để tính toán dấu của vị trí đầu ra.]

Hình 6 Địa điểm / Mạng chuyển tiếp với các chú thích - dựa trên hình 31 trang 78 của bản dịch tiếng Anh của luận án Petri (1966)

Một cách để giảm thiểu thách thức này là xác định các loại chú thích được sử dụng trong mô hình và xác định các đối tượng đồ họa bao gồm chú thích của các loại này (Petri, 1966). Do đó, khi một sơ đồ Petri Net bao gồm các đối tượng đồ họa từ các định nghĩa, việc giải thích các đối tượng này sẽ bao gồm các chú thích của trò chơi vô hình. Hình 7 nên được hiểu là Standard Petri Net (xem Chú thích của Standard Petri Net cho các định nghĩa); do đó, chú thích logic có thể được bỏ qua khỏi sơ đồ.

Hình 7 Địa điểm / Mạng chuyển tiếp - dựa trên hình 31 trang 78 của bản dịch tiếng Anh của luận án Petri (1966)

Một cách khác để giảm thiểu thách thức này là sử dụng các dạng xem biểu mẫu của các chú thích để bổ sung hoặc bổ sung (các) sơ đồ (Chionglo, 2016b; 2014). Các chế độ xem có thể được chia thành các chế độ xem nhỏ hơn và mỗi chế độ xem có thể được hiển thị và ẩn.

Tài liệu tham khảo

Chionglo, JF (2016a). Trả lời Câu hỏi Làm thế nào để thiết kế một dòng trạng thái cho trò chơi flashcard phản ứng / redux? Tại trò chơi Stack Overflow. Có sẵn tại https://www.academia.edu/34059934/A_Reply_to_How_to_design_a_state_flow_for_a_react_redux_flashcard_game_at_Stack_Overflow .

Chionglo, JF (2016b). Hai dạng xem của Petri Net. Có sẵn tại http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf .

Chionglo, JF (2015). Giảm số lượng đồ họa phần tử mạng trong sơ đồ Petri Net bằng đồ họa cấp cao. Có sẵn tại http://www.aespen.ca/AEnswers/WjTpY1429533268 .

Chionglo, JF (2014). Các yếu tố và chú thích ròng cho lập trình máy tính: Tính toán và tương tác trong PDF. Có sẵn tại https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interilities_in_PDF .

Thánh lễ, LÊ; Krogh, BH và Giua, A. (1997). Một cuộc khảo sát về các phương pháp Petri Net cho các hệ thống sự kiện rời rạc được kiểm soát [phiên bản điện tử]. Các hệ thống động sự kiện rời rạc: Lý thuyết và ứng dụng, Tập. 7. Boston: Nhà xuất bản học thuật Kluwer, trang 151 - 190.

Menzies, T. (2002). Vấn đề đánh giá cho các ngôn ngữ lập trình trực quan. Trong SK Chang (Ed). Sổ tay Kỹ thuật phần mềm & Kỹ thuật tri thức, Tập. 2 Công nghệ mới nổi. Nhà xuất bản khoa học thế giới Pte. Ltd., trang 93 - 101.

Noe, JD và Nutt, GJ (1973). Các mạng điện tử Macro của Đại diện cho các hệ thống song song, các giao dịch của IEEE trên máy tính, tập. C-22, số 8, tháng 8 năm 1973, trang 718 - 727.

Petri, CA (1973). Các khái niệm về lý thuyết mạng. Trong nền tảng toán học của khoa học máy tính: Proc. của Hội nghị chuyên đề và Trường học mùa hè, High Tatras, ngày 3 - 8 tháng 9 năm 1973, trang 137 - 146. Toán. Inst. của Học viện Slovak. Khoa học, năm 1973.

Petri, CA (1966). Giao tiếp với Automota [trans. CF Greene, Jr.]. Bổ sung I vào Báo cáo kỹ thuật RADC-TR-65-377 (Tập I). Căn cứ không quân Griffiss, NY: Trung tâm phát triển không quân Rome, Phòng nghiên cứu và công nghệ, Bộ chỉ huy hệ thống không quân, căn cứ không quân Griffiss. Truy cập ngày 31 tháng 8 năm 2011 từ http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdf .

Johne Percival Hackworth :

Mặc dù không có gì sai với lập trình trực quan, nhưng có thể đơn giản đó không phải là một cách tiếp cận tốt cho hầu hết các nhiệm vụ.

Có lẽ, các ngôn ngữ lập trình trực quan cho đến nay vẫn còn quá non nớt? Khái niệm rằng trực quan hóa nâng cao không thể được áp dụng cho các tạo phẩm phần mềm và chúng hoàn toàn phụ thuộc vào 'trí tưởng tượng' của mỗi nhà phát triển để tự tung ra có thể là một giả định sai. Tăng mức độ trừu tượng theo cách thống nhất và tự động có vẻ rõ ràng, miễn là khả năng thực hiện trừu tượng hóa ở mức độ thấp và hiệu suất thực thi cao không bị hy sinh. Điều này cuối cùng có thể dẫn đến 'lập trình' của chuyên gia tên miền, không khác nhiều so với cách các bảng tính tự động hóa nhiệm vụ của các lập trình viên COBOL để thao túng các con số. Sự khác biệt chính ở đây là thay thế các con số bằng thao tác của 'các hệ thống chung'.

Bạn có thể xem Lập trình không có công nghệ mã hóa (PWCT)

PWCT là ngôn ngữ lập trình trực quan cho mục đích chung cho phép phát triển các hệ thống và ứng dụng bằng cách tạo các bước tương tác thay vì viết mã.

Đây là một nơi tốt để bắt đầu và là nguồn mở .

một câu hỏi khó lập trình trực quan hoặc dựa trên dòng chảy thực sự đã trở nên được sử dụng nhiều hơn nhưng nó không được sử dụng rộng rãi so với tất cả các ngôn ngữ lập trình. yếu tố quan trọng là bảo trì và tiêu chuẩn hóa. mã máy tính có thể được in trên các trang. không phải lúc nào cũng rõ ràng làm thế nào để in một chương trình trực quan.

trái ngược với câu trả lời hàng đầu hiện nay tôi cho rằng chắc chắn không có giới hạn lý thuyết cố hữu về sức mạnh lập trình trực quan so với ngôn ngữ văn bản. trong thực tế lập trình trực quan có thể được coi là dễ dàng hơn để duy trì một ngày nào đó dựa trên khái niệm nhanh hơn của con người về nhiều tầng trừu tượng . vì vậy dường như có một yếu tố không thể nhầm lẫn của quán tính xã hội / văn hóa / chủ nghĩa bảo thủ trong sự hấp thu của nó.

các trình soạn thảo trực quan có lẽ phức tạp hơn nhiều trong mã của chúng và điều này thật ghê gớm khi xem xét các IDE dựa trên văn bản có thể rất phức tạp, ví dụ như Eclipse , lưu ý rằng có các plugin định hướng lập trình trực quan vào một số IDE như eciplse, ví dụ như để xây dựng GUI. lập trình trực quan để xây dựng GUI khá phổ biến hiện nay.

Tôi nhận thấy rằng việc sử dụng lập trình trực quan đang gia tăng trong các khu vực được chọn và từ lâu nó có thể trở nên phổ biến hơn.

đừng quên rằng lập trình trực quan vốn có của thiết kế chip EE trong nhiều thập kỷ, nơi nó không phải là một hệ thống trừu tượng và (phụ) được trình bày trong các thiết kế 2d chính xác như dự định.

bộ công cụ Lego mindstorms , đã phổ biến và đã hơn một thập kỷ, luôn có phần mềm phát triển dựa trên lập trình trực quan, hiện được sắp xếp hợp lý qua nhiều phiên bản.

đây là một bài viết thú vị gần đây phân tích lịch sử và triển vọng và cho thấy nó có thể trở nên phổ biến hơn cho lập trình dựa trên web. tự động đặt ra các điều khiển / widget trên một trang là một biến thể của lập trình dựa trên trực quan.

một lĩnh vực quan trọng / mới nổi khác, nơi nó được sử dụng rộng rãi trong nhiều công cụ là BPM, mô hình hóa quy trình kinh doanh.

• Làm thế nào một phương pháp mã hóa Arcane từ những năm 1970 Phần mềm ngân hàng có thể cứu được sự phát triển của các nhà phát triển web ở mọi nơi (Công ty nhanh)

• BPM, mô hình hóa quy trình kinh doanh wikipedia

Tôi đoán lý do tại sao các giải pháp này không phổ biến, bởi vì trong hầu hết các trường hợp, chúng có thể không thể quản lý được và trở thành một mớ hỗn độn.

Hầu như tất cả các công cụ lập trình trực quan hiện có ngày nay là một phần của các ứng dụng lớn hơn và được sử dụng cho một mục đích cụ thể (ví dụ: Blueprint trong UE4).

Dù sao, một cái mới mà tôi đã bắt gặp gần đây cho lập trình chung là Korduene , đây thực sự không phải là mục đích chung, vì nó là nhiều hơn để tạo các ứng dụng Windows.

Tôi nghĩ rằng @Raphael và những người khác đã sai khi họ nói rằng một chương trình là văn bản. Không phải vậy. Đó là nhiều thứ. Nó đang nói cho máy tính biết phải làm gì hoặc làm như thế nào. (không hoạt động, lập trình khai báo) Sự kết hợp của lập trình với chỉnh sửa văn bản là giáo điều lịch sử và phản trực giác. Được tạo bởi các đầu vào / đầu ra văn bản hạn chế của các máy tính ban đầu. Mọi người không phải là trình phân tích cú pháp văn bản!

Mặc dù tôi nghĩ rằng mọi người nói đúng rằng một ngôn ngữ trực quan hoàn toàn (nơi bạn làm bất cứ điều gì trực quan, bằng cách kết nối các yếu tố qua chuột và như vậy) là không thực tế đối với một ngôn ngữ có mục đích chung, tôi nghĩ rằng tất cả các ngôn ngữ hiện tại có thể và nên được chuyển sang một trung gian cấp độ. Trong đó các yếu tố ngôn ngữ có biểu diễn trực quan, được lưu trong tệp ngôn ngữ nhị phân. Lập trình viên sẽ không gõ văn bản như điên, hoặc sống dưới sự phù phép của các dòng và thụt lề.

Nhưng chèn các phần tử thông qua sự kết hợp hiệu quả nhất của các phím nóng / lệnh / phần tử UI. Và chỉ loại chuỗi và dữ liệu và định danh khác. Điều này sẽ khiến các lỗi cú pháp không thể thực hiện được và khiến cho các ngôn ngữ có tính an toàn và chính xác (ví dụ: ADA) hiệu quả hơn. Và cũng sẽ làm cho những người khác an toàn hơn và ít lỗi hơn, bằng cách làm cho toàn bộ các lớp lỗi phổ biến là không thể. (Chẳng hạn như những thứ mà ADA ngăn chặn bằng cách cồng kềnh)

Ở một mức độ nào đó mọi thứ đang đi theo cách này. Bằng cách thụt lề tự động và tô màu cú pháp. Đáng buồn thay, không ai nhận ra (hoặc quan tâm đủ) rằng đó là khái niệm cốt lõi của "trình phân tích cú pháp văn bản con người" là những gì sai. Các đối số emacs vs vim là buồn cười vì cả hai đều sai. Chúng là "giải pháp" cho một vấn đề được tạo ra một cách giả tạo.