ภาษาการเขียนโปรแกรมด้วยภาพ

พวกเราส่วนใหญ่เรียนรู้การเขียนโปรแกรมโดยใช้ภาษาการเขียนโปรแกรม "ใจความ" เช่น Basic, C / C ++ และ Java ฉันเชื่อว่ามันเป็นธรรมชาติและมีประสิทธิภาพมากขึ้นสำหรับมนุษย์ที่จะคิดด้วยสายตา การเขียนโปรแกรมภาพช่วยให้นักพัฒนาสามารถเขียนโปรแกรมโดยจัดการองค์ประกอบกราฟิก ฉันเดาว่าการใช้การเขียนโปรแกรมด้วยภาพควรปรับปรุงคุณภาพของรหัสและลดข้อบกพร่องในการเขียนโปรแกรม ฉันรู้ภาษาภาพไม่กี่เช่นApp Inventor , รอยขีดข่วนและLabView

เหตุใดจึงไม่มีภาษาภาพทั่วไปที่ใช้งานทั่วไปสำหรับนักพัฒนาซอฟต์แวร์ อะไรคือข้อดีและข้อเสียของการเขียนโปรแกรมด้วยภาพ?

โดยทั่วไปมีการแลกเปลี่ยนในการออกแบบภาษาโปรแกรมระหว่างการใช้งานง่ายและการแสดงออก (พลังงาน) การเขียนโปรแกรม "Hello, world" แบบง่ายในภาษาเริ่มต้นเช่น Scratch หรือ App Inventor นั้นง่ายกว่าการเขียนในภาษาการเขียนโปรแกรมทั่วไปเช่น Java หรือ C ++ ซึ่งคุณสามารถเลือกสตรีมได้หลายแบบ เอาต์พุตไปยังชุดอักขระที่แตกต่างกันโอกาสในการเปลี่ยนไวยากรณ์ชนิดไดนามิก ฯลฯ

ในระหว่างการสร้าง App Inventor (ซึ่งฉันเป็นส่วนหนึ่ง) ปรัชญาการออกแบบของเราคือการทำให้การเขียนโปรแกรมง่ายสำหรับผู้เริ่มต้น ตัวอย่างเล็ก ๆ น้อย ๆ นั้นใช้ดัชนีอาเรย์ของเราที่ 1 แทนที่จะเป็น 0 แม้ว่ามันจะทำให้การคำนวณมีแนวโน้มที่จะดำเนินการโดยโปรแกรมเมอร์ขั้นสูงที่ซับซ้อนกว่าเล็กน้อย

อย่างไรก็ตามวิธีหลักที่ภาษาการเขียนโปรแกรมแบบเห็นภาพมีแนวโน้มที่จะได้รับการออกแบบสำหรับผู้เริ่มต้นคือการกำจัดความเป็นไปได้ของข้อผิดพลาดทางไวยากรณ์โดยทำให้มันเป็นไปไม่ได้ที่จะสร้างโปรแกรมที่ไม่ถูกต้อง ตัวอย่างเช่นภาษาบล็อกไม่อนุญาตให้คุณประเมินค่าปลายทางของคำสั่งกำหนดค่าอีกครั้ง ปรัชญานี้มีแนวโน้มที่จะให้ไวยากรณ์และภาษาที่ง่ายขึ้น

เมื่อผู้ใช้เริ่มสร้างโปรแกรมที่ซับซ้อนมากขึ้นในภาษาบล็อกพวกเขาพบว่าการลากและวางบล็อกช้ากว่าการพิมพ์ คุณต้องการพิมพ์ "a * x ^ 2 + b * x + c" หรือสร้างด้วยบล็อก?

ความยุติธรรมไม่สามารถมอบให้กับหัวข้อนี้ (อย่างน้อยฉัน) ในสองสามย่อหน้า แต่เหตุผลหลักบางประการคือ:

1. ภาษาบล็อกมีแนวโน้มที่จะได้รับการออกแบบสำหรับผู้เริ่มต้นดังนั้นจึงไม่ทรงพลังตามการออกแบบ
2. ไม่มีวิธีที่ดีในการแสดงแนวคิดที่ซับซ้อนบางอย่างเช่นระบบชนิดที่คุณพบในภาษาการเขียนโปรแกรมที่ใช้งานทั่วไป
3. การใช้บล๊อกเป็นเรื่องยากสำหรับโปรแกรมที่ซับซ้อน

เหตุใดจึงไม่มีภาษาภาพทั่วไปที่ใช้งานทั่วไปสำหรับนักพัฒนาซอฟต์แวร์ อะไรคือข้อดีและข้อเสียของการเขียนโปรแกรมด้วยภาพ?

ภาษาภาพมีแนวโน้มที่จะแบ่งออกเป็นสามหมวดหมู่กว้าง ๆ :

1. เครื่องมือที่ไม่ใช่โปรแกรมเมอร์เพื่อทำงานอัตโนมัติขั้นพื้นฐาน Think Automator บนเครื่อง Mac
2. สภาพแวดล้อมการเรียนรู้ที่ไม่สามารถพิมพ์ได้จำนวนมากหรือโครงสร้างของโปรแกรมที่แสดงการไหลของตรรกะเป็นสิ่งสำคัญ คิดว่าเกา, อลิซ, ฯลฯ
3. ปัญหาที่ได้รับการแก้ไขเป็นปัญหาการไหลของข้อมูลและวิธีการแก้ปัญหานั้นเป็นแบบอย่างที่ดีโดยการจัดเรียงข้อมูลบางอย่างระหว่างกล่องที่มีอยู่ในตัวเองซึ่งเลียนแบบโลกทางกายภาพ LabView และ Ableton ต่างก็นึกถึง

ข้อดีของการเขียนโปรแกรมด้วยภาพคือคุณจะได้รับภาพรวมระดับสูงของโครงสร้างระบบ นำไปสู่ปัญหาที่เกิดขึ้นทันทีที่เมื่อคุณได้รับรายละเอียดนี้รหัสปาเก็ตตี้ของคุณจริงๆดูเหมือนปาเก็ตตี้ องค์ประกอบทั่วไปของภาษาที่เห็นคือการเรียงลำดับของรหัสบล็อกหรือองค์ประกอบการกำหนดค่าสำหรับองค์ประกอบภาพ ปัญหาคือโปรแกรมเมอร์ต้องการให้บล็อกโค้ดที่ไม่ได้เชื่อมต่อซึ่งอาจเชื่อมโยงกันในรูปแบบแปลก ๆ

ในขณะที่ไม่มีอะไรผิดปกติกับการเขียนโปรแกรมภาพอาจเป็นกรณีที่มันไม่ได้เป็นวิธีที่ดีสำหรับงานส่วนใหญ่

มีจำนวนมากได้รับการเขียนโปรแกรมภาษาภาพเป็นสองต่อไปนี้จะแสดงรายชื่อหนังสือ: vlib.orgและoregonstate.edu

IMHO พวกเขาล้มเหลวในการรับแรงฉุดเพราะในขณะที่พวกเขาดีสำหรับตัวอย่างของเล่นพวกเขาล้มเหลวในการจัดการหลายระดับของนามธรรมการเป็นตัวแทนและความละเอียดที่โครงการขนาดใหญ่ต้องการ คุณจะต้องดูระบบเช่น AutoDesk Revit (ระบบจัดการข้อมูลอาคารที่สถาปนิกและวิศวกรใช้) เพื่อดูว่าการจัดการข้อมูลภาพที่ซับซ้อนสามารถกลายเป็นอย่างไร

แทนที่จะมองไปที่การเขียนโปรแกรมวัตถุประสงค์ทั่วไปการเขียนโปรแกรมด้วยภาพมักจะประสบความสำเร็จในฐานะเครื่องมือการกำหนดค่าในโดเมนเฉพาะ

ข้อความเป็นภาพ

เราใช้ตัวชี้นำภาพทุกชนิดในรหัสของเรา การใช้ช่องว่างทุกครั้ง (เยื้อง, บรรทัดใหม่, บรรทัดว่าง, ระยะห่างระหว่าง Intraline) จะถูกนำไปใช้ในการจัดเตรียมคิวภาพสำหรับการทำงานของโค้ด เราใช้ไวยากรณ์ที่แตกต่างกันทุกชนิดเพื่อให้ข้อมูลภาพในสิ่งที่รหัสกำลังทำอยู่ บรรณาธิการของเราให้สีรหัสของเราเพื่อให้โดดเด่น

คณิตศาสตร์เป็นข้อความ มีสัญกรณ์ทุกชนิด แต่ในที่สุดมันก็ลงมาที่ข้อความ พวกเขาทำมาหลายร้อยปีแล้ว

จุดของฉัน: การแสดงข้อความของรหัสคือการใช้ความสามารถในการมองเห็นที่มนุษย์มี เราอาจจะใช้มันได้ดีกว่า แต่ไม่ใช่โดยการละทิ้งข้อความ

[สำหรับเวอร์ชัน PDF ของคำตอบนี้ตัวเลขหรือไดอะแกรมนั้นเป็นแบบโต้ตอบและแบบไดนามิก]

องค์ประกอบสุทธิและคำอธิบายประกอบ: ภาษาโปรแกรม Visual วัตถุประสงค์ทั่วไป

ฉันใช้กราฟิกเพื่อจัดระเบียบโปรแกรม JavaScript ™ที่ใช้Acrobat® / JavaScript API วัตถุกราฟิกแต่ละรายการแสดงถึงองค์ประกอบของ Petri Net (สถานที่การเปลี่ยนแปลงการนำเข้าหรือส่งออก) หรือแสดงมากกว่าหนึ่งองค์ประกอบของ Petri Net แต่ละวัตถุกราฟิกเป็นบันทึกย่อขององค์ประกอบสุทธิที่สอดคล้องกัน อย่างไรก็ตามหากวัตถุกราฟิกทุกรายการจับคู่กับองค์ประกอบสุทธิหนึ่งเดียวเท่านั้นมันอาจถูกใช้เพื่อสร้างองค์ประกอบสุทธิ และถ้าวัตถุกราฟิกจับคู่กับองค์ประกอบสุทธิมากกว่าหนึ่งรายการและการทำแผนที่กำหนดไว้อย่างดีแล้วก็อาจใช้เพื่อสร้างองค์ประกอบสุทธิได้ องค์ประกอบ Petri Net มาตรฐานแสดงด้วยกราฟิกบางประเภท: วงกลมคือสถานที่สี่เหลี่ยมจัตุรัสหรือสี่เหลี่ยมผืนผ้าหรือเส้นคือช่วงการเปลี่ยนภาพลูกศรจากวงกลมหนึ่งสี่เหลี่ยมไปยังสี่เหลี่ยมจัตุรัสคืออินพุตและลูกศรจากสี่เหลี่ยมจัตุรัสถึงวงกลมคือ เอาท์พุต นอกจากนี้

[ประเภทคำอธิบายประกอบใน "Standard Petri Net" พบได้ในเวอร์ชัน PDF ของการตอบกลับนี้]

คาร์ลอดัม Petri อธิบายความคิดเหล่านี้ส่วนใหญ่ (รวมถึงประเภทของคำอธิบายประกอบใน "Standard Petri Net" ในวิทยานิพนธ์ปริญญาเอกของเขา (Petri, 1966) นอกจากนี้เขายังใช้องค์ประกอบสุทธิและคำอธิบายประกอบกับคำอธิบายของวงจรตรรกะต่างๆเช่นรูป 6

ประโยชน์และความท้าทาย

ภาษาโปรแกรมเชิงภาพอาจช่วยโปรแกรมเมอร์คอมพิวเตอร์ในการพัฒนาโปรแกรมคอมพิวเตอร์ (Menzies, 2002)

ฉันมีเหตุผลอย่างน้อยสามข้อว่าทำไมฉันจึงพบว่าองค์ประกอบสุทธิและหมายเหตุประกอบมีประโยชน์ (ข้อดี?)

เหตุผลแรก ตรรกะกระบวนการสามารถสร้างได้ทีละองค์ประกอบ ซึ่งหมายความว่าเน็ตสามารถขยายได้โดยการเพิ่มองค์ประกอบให้กับสุทธิที่มีอยู่ (Petri, 1966) ตัวอย่างเช่นรูปแบบของตัวควบคุมสามารถแบ่งออกเป็นองค์ประกอบภายในและภายนอก ส่วนประกอบภายในควบคุมระบบ คอมโพเนนต์ภายนอกอินเตอร์เฟสกับสภาพแวดล้อมโดยการรับอินพุตจากสภาพแวดล้อม รูปที่ 1 เป็นแบบ Petri Net ของส่วนประกอบภายใน เป็นไปได้ที่จะเพิ่มโมเดล Petri Net ของส่วนประกอบภายนอกเข้ากับโมเดล Petri Net ของส่วนประกอบภายในโดยเพิ่มสถานที่และการเปลี่ยนผ่านที่เหมาะสม (รูปที่ 2)

รูปที่ 1 Petri Net Model ของชิ้นส่วนภายในของคอนโทรลเลอร์ (Halloway, Krogh and Giua, 1997)

รูปที่ 2 Petri Net Model ของส่วนประกอบภายในและภายนอกของคอนโทรลเลอร์ (Halloway, Krogh and Giua, 1997)

เหตุผลที่สอง รหัสที่เกี่ยวข้องกับองค์ประกอบสุทธิแต่ละอย่างอาจมาจาก“ ภาษาการเขียนโปรแกรม” มากกว่าหนึ่งภาษา (Petri, 1973) สามารถมาจากภาษาคอมพิวเตอร์เช่น JavaScript, COBOL, ADA และภาษาแอสเซมบลี พวกเขาสามารถมาจากภาษาคณิตศาสตร์เช่นสัญลักษณ์เกี่ยวกับพีชคณิต พวกเขาอาจมาจากร้อยแก้วที่เข้ารหัสเป็นภาษาอังกฤษเยอรมันฝรั่งเศสกรีกตากาล็อกจีน ฯลฯ ดังนั้นจึงอาจใช้เป็นพื้นฐานสำหรับการสื่อสารและการทำงานร่วมกันตลอดวงจรการพัฒนาซอฟต์แวร์หรือระบบ และในหมู่ผู้ใช้ผู้พัฒนาและผู้มีส่วนได้ส่วนเสียต่าง ๆ (Petri, 1973)

เหตุผลที่สาม เป็นไปได้ที่จะมุ่งเน้นไปที่วัตถุกราฟิกบางอย่างในเน็ตและสามารถเขียนรหัสหรือคำอธิบายประกอบแบบลอจิกสำหรับวัตถุกราฟิกที่เกี่ยวข้อง พิจารณารูปแบบ Petri Net ของการ์ดเกมในรูปที่ 3 ถ้าลูกศรสำหรับอินพุต P7  T4 เป็นกราฟิกมาตรฐานสำหรับอินพุตใน Place / Transition Net และหาก m_7 เป็นเครื่องหมายสำหรับตำแหน่ง P7 ดังนั้นคำอธิบายประกอบแบบลอจิกสำหรับ การอัพเดตเครื่องหมายของตำแหน่งอินพุตคือ m_7 = m_7-1 หาก s_9 ^ - เป็นสถานะของอินพุตดังนั้นหมายเหตุประกอบตรรกะสำหรับการอัพเดตสถานะของอินพุตคือ s_9 ^ - = ((m_7 <1)? false: true)

รูปที่ 3 เกมไพ่ Pet Pet Net

ฉันมีเหตุผลอย่างน้อยสามข้อว่าทำไมฉันถึงพบว่าการประยุกต์ใช้ Petri Nets มีความท้าทาย (ข้อเสีย)

หากมีวัตถุกราฟิกมากเกินไปมันจะยากที่จะสร้างหรืออ่านเน็ต ความยากลำบากอาจลดลงได้ด้วยการใช้ส่วนย่อยของกราฟิกและแสดงโดยใช้สัญลักษณ์กราฟิกหนึ่ง, สองหรือสามตัว (Noe, 1973; Petri, 1966) ตัวอย่างเช่นหากโมเดล Petri Net ของการ์ดเกมในรูปที่ 3 ถือว่ามีวัตถุกราฟิกจำนวนมากเกินไปในไดอะแกรมเป็นไปได้ที่จะรวมกราฟิกบางส่วนและยังคงมีข้อมูลเพียงพอที่จะแมปไดอะแกรมในโปรแกรมคอมพิวเตอร์ พิจารณารูปที่ 4 รูปแบบ Petri Net ของเกมเดียวกันที่พบในรูปที่ 3 พร้อมกราฟิกระดับสูง (Chionglo, 2016a)

รูปที่ 4 Petri Net Model ของเกมการ์ดโดยใช้กราฟิกระดับสูง (Chionglo, 2016a)

ในตัวอย่างอื่นส่วนประกอบภายนอกของคอนโทรลเลอร์ในรูปที่ 2 สามารถรวมกันเพื่อสร้างการแสดงกราฟิกที่กระชับยิ่งขึ้นดังแสดงในรูปที่ 5

รูปที่ 5 Petri Net Model ของคอนโทรลเลอร์ที่มีกราฟิกระดับสูงสำหรับส่วนประกอบภายนอก

ในที่สุดชุดของสถานที่ที่ไม่เกิดร่วมกันหรือชุดของช่วงการเปลี่ยนภาพที่ไม่เกิดร่วมกันอาจถูกแสดงโดยใช้วัตถุกราฟิกระดับสูง (Chionglo, 2015)

เหตุผลที่สอง ถึงแม้จะใช้กราฟิกมาตรฐานก็สามารถท้าทายในการวาดและวางตำแหน่งกราฟิกโดยเฉพาะอย่างยิ่งหากคาดว่าไดอะแกรมสุดท้ายจะเป็นมิตรต่อผู้ใช้หรือผู้อ่าน การตัดสินใจบางอย่างสำหรับการสร้างไดอะแกรมที่เป็นมิตรกับผู้ใช้หรือผู้อ่านรวมถึง: เค้าโครงที่เหมาะสมของวัตถุกราฟิก, ขนาดที่เหมาะสมของผืนผ้าใบและรูปร่าง, ความโค้งของลูกศร, ประเภทของหัวลูกศร, ขนาดและแบบอักษรของข้อความ, และตัวเลือกสีสำหรับกราฟิกและข้อความ

เหตุผลที่สาม มันเป็นเรื่องง่ายที่จะสร้างคำอธิบายประกอบขององค์ประกอบสุทธิในลักษณะที่เป็นระเบียบเพราะทุกคำอธิบายประกอบนั้นเกี่ยวข้องโดยตรงหรือโดยอ้อมกับองค์ประกอบสุทธิ อย่างไรก็ตามการแสดงคำอธิบายประกอบทั้งหมดพร้อมกับกราฟิกของทุกองค์ประกอบสุทธิอาจไม่ใช่ความคิดที่ดีเพราะอาจมีข้อมูลมากเกินไปที่แสดงในแผนภาพ ตัวอย่างเช่นพิจารณาไดอะแกรมของแบบจำลอง Petri Net ของวงจรลอจิกซึ่งรวมถึงการอ้างอิงถึงคำอธิบายประกอบคุณสมบัติและตรรกะทั้งหมด (รูปที่ 6) [รุ่นดั้งเดิมมีเงื่อนไขการทดสอบสำหรับสถานะของเอาต์พุตทุกตัว (รูปที่ 31 ในหน้า 78 ของ (Petri, 1966)) เงื่อนไขการทดสอบถูกตัดทิ้งที่นี่เนื่องจากเทียบเท่ากับรุ่นดั้งเดิมสำหรับการทำเครื่องหมายเริ่มต้นที่กำหนด ดังนั้นเอาต์พุตทุกอันจะมีบันทึกย่อแบบลอจิกเดียวสำหรับการคำนวณเครื่องหมายของตำแหน่งเอาต์พุต]

รูปที่ 6 สถานที่ / การเปลี่ยนผ่านสุทธิพร้อมคำอธิบายประกอบ - จากภาพที่ 31 หน้า 78 ของคำแปลภาษาอังกฤษของวิทยานิพนธ์ของ Petri (1966)

วิธีหนึ่งในการลดความท้าทายนี้คือการระบุประเภทของคำอธิบายประกอบที่ใช้ในแบบจำลองและเพื่อกำหนดวัตถุกราฟิกที่มีคำอธิบายประกอบประเภทเหล่านี้ (Petri, 1966) ดังนั้นเมื่อไดอะแกรม Petri Net ประกอบด้วยวัตถุกราฟิกจากคำจำกัดความการตีความวัตถุเหล่านี้ควรรวมคำอธิบายประกอบที่ "มองไม่เห็น" รูปที่ 7 ควรตีความเป็น Standard Petri Net (ดูหมายเหตุประกอบของ Standard Petri Net สำหรับคำจำกัดความ); ดังนั้นคำอธิบายประกอบตรรกะอาจถูกมองข้ามจากแผนภาพ

รูปที่ 7 สถานที่ / การเปลี่ยนแปลงสุทธิ - ตามรูปที่ 31 หน้า 78 ของการแปลภาษาอังกฤษของวิทยานิพนธ์ของ Petri (1966)

อีกวิธีหนึ่งในการลดความท้าทายนี้คือใช้มุมมองฟอร์มของคำอธิบายประกอบเพื่อเติมเต็มหรือเสริมไดอะแกรม (Chionglo, 2016b; 2014) มุมมองอาจแบ่งออกเป็นมุมมองที่เล็กลงและแต่ละมุมมองสามารถแสดงและซ่อน

อ้างอิง

Chionglo, JF (2016a) ตอบกลับไปที่ "วิธีการออกแบบการไหลของสถานะสำหรับเกมตอบสนอง / redux flashcard?" ที่ Stack ล้น มีจำหน่ายที่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) มุมมองสองรูปแบบของ Petri Net มีจำหน่ายที่http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf

Chionglo, JF (2015) การลดจำนวนองค์ประกอบกราฟิกสุทธิในไดอะแกรม Petri Net โดยใช้กราฟิกระดับสูง มีจำหน่ายที่http://www.aespen.ca/AEnswers/WjTpY1429533268

Chionglo, JF (2014) องค์ประกอบสุทธิและคำอธิบายประกอบสำหรับการเขียนโปรแกรมคอมพิวเตอร์: การคำนวณและการโต้ตอบใน PDF มีจำหน่ายที่https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF

ฮัลโลเวย์, LE; Krogh, BH และ Giua, A. (1997) การสำรวจวิธี Petri Net สำหรับระบบเหตุการณ์ไม่ต่อเนื่องแบบควบคุม [รุ่นอิเล็กทรอนิกส์] ระบบไดนามิกเหตุการณ์ไม่ต่อเนื่อง: ทฤษฎีและการประยุกต์ใช้ฉบับ 7. บอสตัน: สำนักพิมพ์ Kluwer Academic, หน้า 151 - 190

Menzies, T. (2002) ปัญหาการประเมินสำหรับภาษาการเขียนโปรแกรมด้วยภาพ ใน SK Chang (Ed) คู่มือวิศวกรรมซอฟต์แวร์และวิศวกรรมความรู้ฉบับที่ 5 2 Emerging Technologies บริษัท World Scientific Publishing Pte จำกัด , หน้า 93 - 101

Noe, JD และ Nutt, GJ (1973) “ มาโคร E-Nets สำหรับการแทนระบบคู่ขนาน”, ธุรกรรม IEEE บนคอมพิวเตอร์, ฉบับที่ C-22, ลำดับ 8, ส.ค. 1973, pp. 718 - 727

Petri, CA (1973) แนวคิดของทฤษฎีเน็ต ในรากฐานทางคณิตศาสตร์ของวิทยาศาสตร์คอมพิวเตอร์: Proc ของ Symposium และ Summer School, High Tatras, 3 - 8 ก.ย. , 1973, หน้า 137 - 146 Inst ของ Acad สโลวัก ของวิทยาศาสตร์, 1973

Petri, CA (1966) การสื่อสารกับ Automota [trans. CF Greene, Jr. ] ภาคผนวก I ถึงรายงานทางเทคนิค RADC-TR-65-377 (เล่มที่ 1) ฐานทัพอากาศ Griffiss, NY: ศูนย์พัฒนาทางอากาศโรม, ฝ่ายวิจัยและเทคโนโลยี, ระบบบัญชาการกองทัพอากาศ, ฐานทัพอากาศ Griffiss ที่ดึง 31 สิงหาคม 2011 จากhttp://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdf

Johne Percival Hackworth :

ในขณะที่ไม่มีอะไรผิดปกติกับการเขียนโปรแกรมภาพอาจเป็นกรณีที่มันไม่ได้เป็นวิธีที่ดีสำหรับงานส่วนใหญ่

บางทีภาษาการเขียนโปรแกรมเชิงภาพจนถึงปัจจุบันนั้นยังไม่สมบูรณ์เกินไปใช่ไหม ความคิดที่ว่าการสร้างภาพข้อมูลขั้นสูงไม่สามารถนำไปใช้กับสิ่งประดิษฐ์ซอฟต์แวร์ได้และสิ่งเหล่านั้นถูกทิ้งไว้อย่างสมบูรณ์จนถึง 'จินตนาการ' ของนักพัฒนาแต่ละรายเพื่อให้ม้วนตัวของพวกเขาเองอาจเป็นสมมติฐานที่ผิดพลาด การเพิ่มระดับของสิ่งที่เป็นนามธรรมในรูปแบบที่เหมือนกันและแบบอัตโนมัติดูเหมือนจะชัดเจนดังนั้นตราบใดที่ความสามารถในการทำ abstractions ระดับต่ำและประสิทธิภาพการดำเนินการที่สูงนั้นไม่ได้ถูกเสียสละ ท้ายที่สุดสิ่งนี้อาจนำไปสู่ ​​'การเขียนโปรแกรม' ของผู้เชี่ยวชาญโดเมนไม่แตกต่างไปจากวิธีที่สเปรดชีตทำงานของโปรแกรมเมอร์ COBOL โดยอัตโนมัติเพื่อจัดการตัวเลข ความแตกต่างหลักที่นี่คือการแทนที่ตัวเลขด้วยการจัดการ 'ระบบทั่วไป'

คุณสามารถดูการเขียนโปรแกรมโดยไม่ใช้เทคโนโลยีการเข้ารหัส (PWCT)

PWCT เป็นภาษาการเขียนโปรแกรมด้วยภาพที่มีวัตถุประสงค์ทั่วไปที่ช่วยให้การพัฒนาระบบและแอพพลิเคชั่นโดยการสร้างขั้นตอนแบบโต้ตอบแทนการเขียนรหัส

ที่นี่เป็นสถานที่ที่ดีที่จะเริ่มต้นและเป็นโอเพนซอร์ส

คำถามที่ยุ่งยาก การเขียนโปรแกรมด้วยภาพหรือโฟลว์นั้นมีการใช้งานมากขึ้น แต่ไม่ได้ใช้กันอย่างแพร่หลายเมื่อเทียบกับภาษาการเขียนโปรแกรมทั้งหมด ปัจจัยสำคัญคือการบำรุงรักษาและมาตรฐาน สามารถพิมพ์รหัสคอมพิวเตอร์ลงบนหน้ากระดาษได้ มันไม่ชัดเจนเสมอไปว่าจะพิมพ์โปรแกรมภาพ

ตรงกันข้ามกับคำตอบยอดนิยมปัจจุบันฉันจะยืนยันว่าไม่มีข้อ จำกัด ทางทฤษฎีโดยธรรมชาติในอำนาจการเขียนโปรแกรมภาพและภาษาต้นฉบับ ในความเป็นจริงการเขียนโปรแกรมภาพอาจจะเห็นเป็นง่ายต่อการรักษาสักวันหนึ่งขึ้นอยู่กับแนวความคิดของมนุษย์ได้เร็วขึ้นในหลายชั้นของนามธรรม ดังนั้นดูเหมือนว่าจะเป็นองค์ประกอบที่ไม่ผิดพลาดของความเฉื่อย / การอนุรักษ์ทางสังคม / วัฒนธรรมในการดูดซึม

โปรแกรมแก้ไขภาพอาจมีความซับซ้อนมากขึ้นในรหัสของพวกเขาและนี่เป็นสิ่งที่น่าเกรงขามเมื่อพิจารณาว่าแม้แต่ IDE ที่ใช้ข้อความสามารถซับซ้อนได้มากเช่นEclipseสังเกตว่ามีปลั๊กอินสำหรับการเขียนโปรแกรมแบบเห็นภาพลงใน IDEs เช่น Eciplse การเขียนโปรแกรมเชิงภาพสำหรับการสร้าง GUI ค่อนข้างแพร่หลายในขณะนี้

สำหรับฉันแล้วดูเหมือนว่าการใช้การเขียนโปรแกรมด้วยภาพนั้นเพิ่มขึ้นในบางพื้นที่และนานต่อจากนี้ไปมันก็อาจจะกลายเป็นเรื่องธรรมดามากขึ้น

อย่าลืมว่าการเขียนโปรแกรมด้วยภาพนั้นมีอยู่จริงในการออกแบบชิป EE มานานหลายทศวรรษซึ่งไม่ใช่สิ่งที่เป็นนามธรรมและระบบ (ย่อย) ถูกวางในรูปแบบ 2d ตามที่ตั้งใจไว้

ชุด Lego mindstormsซึ่งตอนนี้แพร่หลายไปกว่าทศวรรษแล้วมีซอฟต์แวร์พัฒนาอยู่เสมอโดยอิงจากการเขียนโปรแกรมด้วยภาพตอนนี้ปรับปรุงอย่างมีนัยสำคัญในหลาย ๆ เวอร์ชัน

นี่เป็นบทความล่าสุดที่น่าสนใจในการวิเคราะห์ประวัติศาสตร์และโอกาสและแนะนำว่ามันอาจจะกลายเป็นเรื่องธรรมดาสำหรับการเขียนโปรแกรมบนเว็บ การวางการควบคุม / วิดเจ็ตแบบไดนามิกบนหน้าเว็บเป็นตัวแปรหนึ่งของการเขียนโปรแกรมด้วยภาพ

อีกหนึ่งพื้นที่สำคัญ / ที่เกิดขึ้นใหม่ซึ่งมีการใช้งานอย่างแพร่หลายในเครื่องมือมากมายคือ BPM การสร้างแบบจำลองกระบวนการทางธุรกิจ

• วิธีการเข้ารหัส Arcane จากซอฟท์แวร์การธนาคารยุค 70 สามารถประหยัดสติปัญญาของนักพัฒนาเว็บได้ทุกที่ (บริษัท ที่รวดเร็ว)

• BPM, การสร้างแบบจำลองกระบวนการทางธุรกิจวิกิพีเดีย

ฉันเดาว่าทำไมโซลูชันเหล่านี้จึงไม่เป็นที่นิยมเพราะในกรณีส่วนใหญ่พวกเขาสามารถจัดการไม่ได้และกลายเป็นความยุ่งเหยิง

เครื่องมือการเขียนโปรแกรมเชิงภาพเกือบทั้งหมดที่มีอยู่ในปัจจุบันเป็นส่วนหนึ่งของแอปพลิเคชันขนาดใหญ่และใช้เพื่อวัตถุประสงค์เฉพาะ (เช่น: Blueprint ใน UE4)

อย่างไรก็ตามสิ่งใหม่ที่ฉันได้พบเมื่อไม่นานมานี้สำหรับการเขียนโปรแกรมทั่วไปคือKordueneซึ่งไม่ได้มีวัตถุประสงค์ทั่วไปมากนัก

ฉันคิดว่า @ ราฟาเอลและคนอื่น ๆ ผิดเมื่อพวกเขาพูดว่าโปรแกรมเป็นข้อความ มันไม่ใช่ มันมีหลายสิ่งหลายอย่าง มันกำลังบอกคอมพิวเตอร์ว่าต้องทำอะไรหรือทำอย่างไร (การเขียนโปรแกรมที่ไม่จำเป็น, การประกาศ) การเชื่อมโยงของการเขียนโปรแกรมกับการแก้ไขข้อความเป็นความเชื่อทางประวัติศาสตร์ ซึ่งถูกสร้างขึ้นโดยอินพุต / เอาต์พุตข้อความที่ จำกัด ของคอมพิวเตอร์ยุคแรก คนไม่ใช่ตัวแยกวิเคราะห์ข้อความ!

ในขณะที่ฉันคิดว่าผู้คนมีความถูกต้องว่าเป็นภาษาที่มองเห็นได้อย่างสมบูรณ์ (ที่คุณทำอะไรที่มองเห็นได้โดยการเชื่อมต่อองค์ประกอบผ่านเมาส์และเช่นนั้น) เป็นสิ่งที่ไม่สามารถใช้ได้กับภาษาที่มีวัตถุประสงค์ทั่วไป ชั้น ที่องค์ประกอบภาษามีการแสดงภาพซึ่งถูกบันทึกไว้ในไฟล์ภาษาไบนารี โปรแกรมเมอร์จะไม่พิมพ์ข้อความอย่างบ้าคลั่งหรืออยู่ภายใต้การสะกดของเส้นและการเยื้อง

แต่แทรกองค์ประกอบผ่านการรวมกันมากที่สุดขององค์ประกอบฮอต / คำสั่ง / UI และมีเพียงประเภทสตริงและข้อมูลและตัวระบุอื่น ๆ สิ่งนี้จะทำให้ข้อผิดพลาดทางไวยากรณ์เป็นไปไม่ได้และทำให้ภาษามีความปลอดภัยและถูกต้องในใจ (เช่น: ADA) มีประสิทธิภาพมากขึ้น และจะทำให้คนอื่นปลอดภัยกว่าและเป็นรถบักกี้น้อยลงด้วยการทำผิดพลาดทั่วไปทั้งคลาส (เช่น ADA ป้องกันโดยการยุ่งยาก)

บางสิ่งกำลังมุ่งหน้าไปทางนี้ โดยการเยื้องอัตโนมัติและการระบายสีไวยากรณ์ น่าเศร้าที่ไม่มีใครรู้ (หรือสนใจมากพอ) ว่านี่เป็นแนวคิดหลักของ "ตัวแยกวิเคราะห์ข้อความมนุษย์" เป็นสิ่งที่ผิด อาร์กิวเมนต์ emacs vs vim นั้นตลกเพราะทั้งคู่นั้นผิด พวกเขาคือ "การแก้ปัญหา" เพื่อแก้ไขปัญหาที่สร้างขึ้นเทียม