Görsel Programlama dilleri

Çoğumuz, Basic, C / C ++ ve Java gibi "textual" programlama dillerini kullanarak programlama öğrendik. İnsanların görsel olarak düşünmesinin daha doğal ve verimli olduğuna inanıyorum. Görsel programlama, geliştiricilerin grafiksel öğeleri işleyerek programlar yazmasını sağlar. Ben görsel programlama kullanarak kod kalitesini artırmak ve programlama hataları azaltmak gerektiğini düşünüyorum. App Inventor , Scratch ve LabView gibi birkaç görsel dilin farkındayım .

Geliştiriciler için neden genel amaçlı, genel amaçlı görsel diller yok? Görsel programlamanın avantajları ve dezavantajları nelerdir?

Genel olarak, programlama dili tasarımında kullanım kolaylığı ile ifade (güç) arasında bir denge vardır. Scratch veya App Inventor gibi başlangıç ​​dillerinde basit bir "Merhaba dünya" programı yazmak, genellikle Java veya C ++ gibi genel amaçlı bir programlama dilinde yazmaktan çok daha fazla akış seçeneğiniz olabilir. çıktı, farklı karakter kümeleri, sentaksı değiştirme, dinamik tipler vb.

App Inventor'ın (parçası olduğum) oluşturulması sırasında tasarım felsefemiz, yeni başlayanlar için programlamayı basitleştirmekti. Önemsiz bir örnek, gelişmiş programcılar tarafından gerçekleştirilmesi muhtemel hesaplamaları biraz daha karmaşık hale getirmesine rağmen, dizi endekslerimizi 0 yerine 1'e dayandırıyordu.

Bununla birlikte, görsel programlama dillerinin yeni başlayanlar için tasarlanma eğiliminde olmasının asıl yolu, sözdizimsel olarak geçersiz programlar oluşturmayı imkansız kılarak sözdizimi hatası olasılığını ortadan kaldırmaktır. Örneğin, blok dilleri bir atama ifadesinin hedefinde bir değer oluşturmanıza izin vermez. Bu felsefe daha basit gramer ve diller üretme eğilimindedir.

Kullanıcılar bir blok dilde daha karmaşık programlar oluşturmaya başladığında, blokları sürükleyip bırakmanın blokların yazmaktan daha yavaş olduğunu fark ederler. "A * x ^ 2 + b * x + c" yazmayı mı yoksa bloklarla oluşturmayı mı tercih edersiniz?

Adalet bu konuya (en azından benim tarafımdan) birkaç paragrafta verilemez, ancak temel sebeplerden bazıları şunlardır:

1. Blok dilleri yeni başlayanlar için tasarlanma eğilimindedir, bu nedenle tasarım açısından güçlü değildir.
2. Genel amaçlı programlama dillerinde bulduğunuz tip sistemleri gibi bazı karmaşık kavramları ifade etmenin güzel bir görsel yolu yoktur.
3. Blok kullanmak karmaşık programlar için hantaldır.

Geliştiriciler için neden genel amaçlı, genel amaçlı görsel diller yok? Görsel programlamanın avantajları ve dezavantajları nelerdir?

Görsel diller onu üç geniş kategoriye ayırma eğilimindedir:

1. Programcı olmayanları temel otomasyon görevlerini yerine getirmek için araçlar. Mac üzerindeki Automator'ı düşünün.
2. Çok fazla yazma işleminin pratik olmadığı veya programın mantıksal akışı gösteren yapısının önemli olduğu ortamları öğrenme. Scratch, Alice, vb düşünün.
3. Ele alınan problem bir veri akışı problemidir ve problemin çözümü, fiziksel dünyayı taklit eden bağımsız kutular arasında bir tür veri akışı ile iyi modellenmiştir. LabView ve Ableton hem akla geliyor.

Görsel programlamanın avantajı, sistem yapısına üst düzey bir genel bakış elde etmektir. Bu, ayrıntılı bir sorun olduğunda, spagetti kodunuzun gerçekten spagetti gibi göründüğü için hemen soruna yol açar . Görsel dillerin ortak bir bileşeni, görsel öğe için bir tür kod bloğu veya yapılandırma bileşenidir. Sorun, programcının garip şekillerde birbirine bağlanabilecek bağlantısız kod bloklarını anlaması gerektiğidir.

Görsel programlamada yanlış bir şey olmamasına rağmen, çoğu görev için iyi bir yaklaşım olmadığı durum olabilir.

Aşağıdaki iki kaynakça göstereceği gibi, çok sayıda görsel programlama dili olmuştur: vlib.org ve oregonstate.edu .

IMHO, çekiş kazanamadılar, çünkü oyuncak örnekleri için iyi olsalar da, büyük projelerin ihtiyaç duyduğu çoklu soyutlama, temsil ve ayrıntı düzeyini yönetemediler. Görsel bilgileri yönetmenin ne kadar karmaşık olabileceğini görmek için AutoDesk Revit (mimarlar ve mühendisler tarafından kullanılan bir bina bilgi yönetimi sistemi) gibi bir sisteme bakmanız gerekir.

Genel amaçlı programlamaya bakmak yerine, görsel programlamanın uzmanlık alanlarındaki bir yapılandırma aracı olarak başarılı olması muhtemeldir.

Metin ise görsel.

Kodumuzda her türlü görsel ipucunu kullanıyoruz. Beyaz alanın her kullanımı (girintiler, yeni çizgiler, boş çizgiler, satır içi boşluklar), kodun işlevselliği için görsel ipuçları sağlamaya yöneliktir. Hangi kodun yapıldığı hakkında görsel bilgi sağlamak için her türlü farklı sözdizimini kullanıyoruz. Editörlerimiz kodlarımızı göze çarpmak için renklendiriyor.

Matematik metinseldir. Her türlü gösterim var, ama sonunda temel olarak metne iniyor. Yüzlerce yıldır yapıyorlar.

Demek istediğim: kodun metinsel gösterimi, insanların sahip olduğu görsel yeteneklerden faydalanıyor. Muhtemelen daha iyi bir şekilde faydalanabiliriz, ancak metni terk ederek değil.

[Bu cevabın PDF versiyonu için , şekiller veya diyagramlar etkileşimli ve dinamiktir.]

Net Öğeler ve Açıklamalar: Genel Amaçlı Bir Görsel Programlama Dili

Acrobat® / JavaScript API'sini kullanan JavaScript ™ programlarını düzenlemek için grafikler kullanıyorum. Her grafik nesnesi bir Petri Net öğesini (yer, geçiş, giriş veya çıkış) temsil eder veya birden fazla Petri Net öğesini temsil eder. Her grafik nesnesi aslında karşılık gelen net elemanın bir açıklamasıdır. Bununla birlikte, eğer her grafik nesnesi bir ve sadece bir net eleman ile eşleşirse, net eleman üretmek için kullanılabilir. Bir grafik nesnesi birden fazla net elemanla eşleşiyorsa ve haritalama iyi tanımlanmışsa, net elemanların üretilmesi için de kullanılabilir. Standart Petri Net elemanları belirli grafik türleri ile temsil edilir: bir daire bir yer, bir kare veya dikdörtgen veya çizgi bir geçiş, bir daire bir kareden bir ok bir giriştir ve bir kare bir daireden bir ok bir çıktı. Ayrıca,

["Standart Petri Ağı" ndaki ek açıklama türleri bu yanıtın PDF sürümünde bulunur.]

Carl Adam Petri, bu düşüncelerin çoğunu (doktora tezinde "Standart Petri Ağı" ndaki ek açıklama türleri dahil) açıklamıştır (Petri, 1966). Net elemanları ve ek açıklamaları Şekil gibi çeşitli mantık devrelerinin tanımına da uygulamıştır. 6.

Avantajlar ve Zorluklar

Görsel bir programlama dili, bir bilgisayar programcısının bilgisayar programları geliştirmesine yardımcı olabilir (Menzies, 2002).

Net unsurları ve ek açıklamaları faydalı bulmam için en az üç nedenim var (avantajlar?).

Firs nedeni. İşlem mantığı, bir defada bir eleman yaratılabilir. Bu, mevcut ağa eleman ekleyerek bir ağın genişletilebileceği anlamına gelir (Petri, 1966). Örneğin, bir denetleyici modeli iç ve dış bileşenlere ayrılabilir. Dahili bileşen sistemi düzenler. Dış bileşen, çevreden girdi kabul ederek çevre ile etkileşime girer. Şekil 1, iç bileşenin bir Petri Net modelidir. Uygun komponentleri ve geçişi ekleyerek, dış komponentin Petri Net modelini, iç komponentin Petri Net modeline eklemek mümkündür (Şekil 2).

Şekil 1 Bir Kontrolörün Dahili Bileşeninin Petri Net Modeli (Halloway, Krogh ve Giua, 1997)

Şekil 2 Kontrolörün İç ve Dış Bileşenlerinin Petri Net Modeli (Halloway, Krogh ve Giua, 1997)

İkinci sebep. Her bir ağ elemanı ile ilgili kodlar birden fazla “programlama dilinden” gelebilir (Petri, 1973). JavaScript, COBOL, ADA ve assembly dili gibi bir bilgisayar dilinden gelebilirler. Cebirsel semboller gibi bir Matematiksel dilden gelebilirler. İngilizce, Almanca, Fransızca, Yunanca, Tagalogca, Çince vb. Kodlanmış nesirlerden gelebilirler. Bu nedenle, yazılım veya sistem geliştirme yaşam döngüsü boyunca iletişim ve işbirliği için bir temel olarak kullanılabilir; ve farklı kullanıcılar, geliştiriciler ve paydaşlar arasındadır (Petri, 1973).

Üçüncü sebep Ağdaki bazı grafik nesnelerine odaklanmak ve ilgili grafik nesnelerinin kodunu veya mantık ek açıklamalarını yazmak mümkündür. Şekil 3'teki bir kart oyununun bir Petri Net modelini göz önünde bulundurun. P7  T4 girişindeki ok bir Yer / Geçiş Ağındaki bir giriş için standart bir grafik ise ve m_7 P7 için bir işaret ise, bunun için mantık eki giriş yeri işaretinin güncellenmesi m_7 = m_7-1'dir. S_9 ^ - girişin durumu ise, girişin durumunu güncellemek için mantık ek açıklaması s_9 ^ - = ((m_7 <1)? False: true).

Şekil 3 Bir kart oyununun Petri Net modeli

Petri Ağları uygulamasını zorlayıcı bulmamın neden en az üç nedenim var (dezavantajlar?)

Çok fazla grafik nesnesi varsa, net oluşturmak veya okumak zor olabilir. Zorluk, grafiklerin bir alt kümesi alınarak hafifletilebilir ve bir, iki veya üç grafik sembolü kullanılarak gösterilebilir (Noe, 1973; Petri, 1966). Örneğin, Şekil 3'teki bir kart oyununun Petri Net modelinin şemada çok fazla grafik nesnesi olduğu düşünülürse, bazı grafiklerin kombine edilmesi ve şemayı bir bilgisayar programına eşlemek için yeterli bilgiyi sürdürmesi mümkündür. Şekil 3'te, Şekil 3'te bulunan aynı oyunun bir Petri Net modeli olan yüksek seviye grafikleri göz önünde bulundurun (Chionglo, 2016a).

Şekil 4 Üst Düzey Grafik Kullanarak Bir Kart Oyununun Petri Net Modeli (Chionglo, 2016a)

Başka bir örnekte, Şekil 2'deki kontrolörün harici bileşenleri, Şekil 5'te gösterildiği gibi daha özlü bir grafik gösterimi oluşturmak için birleştirilebilir.

Şekil 5 Harici Bileşenler için Üst Düzey Grafiklere Sahip Bir Denetleyicinin Petri Net Modeli

Son olarak, karşılıklı olarak ayrılan bir dizi yer veya karşılıklı olarak ayrılan bir dizi geçiş de üst düzey bir grafik nesnesi kullanılarak gösterilebilir (Chionglo, 2015).

İkinci sebep. Standart grafiklerde bile, özellikle son diyagramın kullanıcı veya okuyucu dostu olmasını umuyorsa, grafik çizmek ve konumlandırmak zor olabilir. Kullanıcı veya okuyucu dostu bir diyagram oluşturmak için bazı kararlar şunlardır: grafik nesnelerinin uygun yerleşimini, kanvas ve şekillerin uygun boyutlarını, okların eğriliğini, ok başlarının tipini, metnin boyutunu ve yazı tipini, ve grafikler ve metinler için renk seçimi.

Üçüncü sebep Net elemanların sıralı bir şekilde ek açıklamaları oluşturmak kolaydır çünkü her ek açıklama doğrudan veya dolaylı olarak bir net elemanla ilgilidir. Bununla birlikte, her bir açıklamanın her bir net elemanın grafikleriyle birlikte gösterilmesi iyi bir fikir olmayabilir, çünkü şemada sunulan çok fazla bilgi olabilir. Örneğin, tüm özelliklere ve mantık ek açıklamalarına referanslar içeren bir mantık devresinin bir Petri Net modelinin bir diyagramını düşünün (Şekil 6). [Orijinal model, her çıkışın durumu için bir test koşulu içeriyordu (Şekil 31, sayfa 78 (Petri, 1966)); Test koşulu burada atlanmıştır, çünkü verilen ilk işaret için orijinal modele eşdeğerdir. Bu nedenle, her çıkışın, çıkış yerinin işaretini hesaplamak için bir mantık ek açıklaması vardır.

Şekil 6 Ek açıklama içeren bir Yer / Geçiş Ağı - Petri'nin tezinin İngilizce çevirisinin 31. sayfasındaki 78. sayfaya göre (1966)

Bu zorluğu azaltmanın bir yolu, modelde kullanılan ek açıklama türlerini belirlemek ve bu tür ek açıklamaları içeren grafik nesnelerini tanımlamaktır (Petri, 1966). Dolayısıyla, bir Petri Net diyagramı tanımlardaki grafik nesnelerinden oluştuğunda, bu nesnelerin yorumlanmasında “görünmez” ek açıklamalar bulunmalıdır. Şekil 7, Standart Petri Ağ olarak yorumlanmalıdır (tanımlar için bkz. Standart Petri Ağının Açıklamaları); bu nedenle, mantık ek şeması diyagramdan çıkarılabilir.

Şekil 7 Bir Yer / Geçiş Ağı - Petri'nin tezinin İngilizce çevirisinin 31. sayfa 78. sayısına göre (1966)

Bu zorluğu hafifletmenin bir başka yolu da diyagramları tamamlamak veya tamamlamak için ek açıklamaların form görünümlerini kullanmaktır (Chionglo, 2016b; 2014). Görünümler daha küçük görünümlere bölünebilir ve her görünüm görüntülenebilir ve gizlenebilir.

Referanslar

Chionglo, JF (2016a). Stack Overflow'ta “Bir tepki / redux flashcard oyunu için nasıl bir durum akışı tasarlanır?” Şeklinde bir Cevap. Boş 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 Ağının iki görünümü. Boş http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf .

Chionglo, JF (2015). Petri Net diyagramındaki net element grafik sayısının yüksek seviyeli grafikler kullanılarak azaltılması. Boş http://www.aespen.ca/AEnswers/WjTpY1429533268 .

Chionglo, JF (2014). Bilgisayar Programlamada Net Unsurlar ve Açıklamalar: PDF'de Hesaplamalar ve Etkileşimler. Boş https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .

Halloway, LE; Krogh, BH ve Giua, A. (1997). Kontrollü kesikli olay sistemleri için Petri Net metotlarının bir araştırması [elektronik versiyon]. Kesikli Olay Dinamik Sistemler: Teori ve Uygulamalar, Cilt. 7. Boston: Kluwer Academic Publishers, s. 151 - 190.

Menzies, T. (2002). Görsel programlama dilleri için değerlendirme sorunları. SK Chang’de (Ed). Yazılım Mühendisliği ve Bilgi Mühendisliği El Kitabı, Vol. 2 Gelişmekte Olan Teknolojiler. Dünya Bilimsel Yayıncılık co. Pte. Ltd., sf. 93 - 101.

Noe, JD ve Nutt, GJ (1973). “Paralel Sistemlerin Temsiline Yönelik Makro E-Ağlar”, Bilgisayarlarda IEEE İşlemleri, vol. C-22, No. 8, Ağustos 1973, sayfa 718 - 727.

Petri, CA (1973). Net Teori Kavramları. Bilgisayar Biliminin Matematiksel Temellerinde: Proc. Sempozyumu ve Yaz Okulu, Lise Tatras, 3 - 8, 1973, sayfa 137 - 146. Matematik. Öğr. Slovak Acad'ın Fen Bilimleri Fakültesi, 1973.

Petri, CA (1966). Automota ile iletişim [trans. CF Greene, Jr.]. Teknik Rapordaki Ek I RADC-TR-65-377 (Cilt I). Griffiss Hava Kuvvetleri Üssü, NY: Roma Hava Geliştirme Merkezi, Araştırma ve Teknoloji Bölümü, Hava Kuvvetleri Sistemleri Komutanlığı, Griffiss Hava Kuvvetleri Üssü. 31 Ağustos 2011 tarihinde http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdf adresinden alındı .

Johne Percival Hackworth :

Görsel programlamada yanlış bir şey olmamasına rağmen, çoğu görev için iyi bir yaklaşım olmadığı durum olabilir.

Belki de, bugüne kadarki görsel programlama dilleri henüz olgunlaşmamış olabilir mi? Gelişmiş görselleştirmelerin yazılım yapılarına uygulanamayacağı ve tamamen her geliştiricinin kendi hayal gücüne bırakılmış olduğu fikri yanlış bir varsayım olabilir. Soyutlama seviyesini tek tip ve otomatik bir şekilde yükseltmek açık görünmektedir, bu nedenle düşük seviyeli soyutlamalar yapma ve yüksek yürütme performansları feda edilmediği sürece. Bu sonuçta etki alanı uzmanı 'programlama'ya yol açabilir, elektronik tabloların COBOL programcılarının sayıları manipüle etme görevini otomatikleştirmesinden çok farklı değildir. Buradaki en büyük fark, sayıları 'genel sistemler' manipülasyonuyla değiştirmek.

Sen Kodlama Teknolojisi (PWCT) olmadan Programlama bakabilirsiniz

PWCT, kod yazmak yerine etkileşimli adımlar oluşturarak sistemlerin ve uygulamaların geliştirilmesini sağlayan genel amaçlı bir görsel programlama dilidir.

İşte başlamak için iyi bir yer ve açık kaynak .

zor bir soru. görsel veya akış temelli programlama gerçekten daha fazla kullanılmaya başlandı, ancak tüm programlama dilleriyle karşılaştırıldığında yaygın olarak kullanılmıyor. önemli faktörler bakım ve standardizasyondur. sayfalara bilgisayar kodu basılabilir. görsel bir programın nasıl yazdırılacağı her zaman çok net değildir.

Şu anki en iyi cevabın tersine, metinsel dillere karşı görsel programlama gücüne ilişkin doğal bir teorik sınırlamanın kesinlikle olmadığını savunuyorum. Aslında, görsel programlama, bir çok soyutlama katmanının daha hızlı insan kavramsallaştırmasına dayanarak bir gün bakımı daha kolay görülebilir . öyleyse, emrinde açıkça sosyal / kültürel atalet / muhafazakârlık unsuru var gibi görünüyor .

görsel editörler kodlarında muhtemelen çok daha karmaşıktır ve bu sadece metin tabanlı IDE'lerin bile çok karmaşık olabileceği göz önüne alındığında çok karmaşık olabilir , örneğin Eclipse , örneğin, GUI inşası için eciplse gibi bazı IDE'lerde görsel-programlama odaklı eklentiler olduğunu unutmayın. GUI binası için görsel programlama artık oldukça yaygın.

Bana göre, görsel programlama kullanımının belirli alanlarda artmakta olduğu ve bundan çok daha yaygın hale geldiği anlaşılıyor.

Görsel programlamanın, soyutlama olmadığı on yıllardır EE yonga tasarımına özgü olduğunu ve (alt) sistemlerin 2d tasarımlarında tam olarak tasarlandığı şekilde düzenlendiğini unutmayalım .

Günümüzde yaygın olan ve on yıldan daha eski olan Lego zihniyet kitleri , şimdi her zaman birçok sürümde önemli ölçüde geliştirilmiş görsel programlamaya dayalı bir geliştirme yazılımına sahipti.

İşte tarih ve umutları analiz eden ve web tabanlı programlama için daha yaygın hale gelebileceğini öne süren ilginç bir makale. Dinamik olarak bir sayfada kontrolleri / widget'ları yerleştirmek görsel-temelli programlamanın bir çeşididir.

Birçok araçta yaygın olarak kullanıldığı bir başka anahtar / gelişmekte olan alan BPM, iş süreci modellemesidir.

• Bir Arcane Kodlama Yöntemi 1970'lerin Bankacılık Yazılımından Her Yerde Web Geliştiricilerin Akılsızlığını Nasıl Koruyabilir (Hızlı Şirket)

• BPM, İş süreci modellemesi wikipedia

Bu çözümlerin neden bu kadar popüler olmama nedeni olduğunu tahmin ediyorum, çünkü çoğu durumda yönetilemezler ve karışıklık yaratabilirler.

Günümüzde mevcut görsel programlama araçlarının hemen hepsi daha büyük uygulamaların bir parçası ve belirli bir amaç için kullanılıyor (örneğin: UE4'teki Blueprint).

Her neyse, genel programlama için son zamanlarda karşılaştığım yeni bir tanesi , Windows uygulamaları için daha fazla olduğu gibi, gerçekten genel amaçlı olmayan Korduene'dir .

Sanırım @Raphael ve diğerleri programın metin olduğunu söylerken yanılıyorlar. Değil. Çok şey var. Bilgisayara ne yapacağını ya da nasıl yapacağını söylüyor. (etkileyici, bildirimsel programlama) Programlamanın metin düzenleme ile ilişkisi tarihi ve karşı yöneltici dogmadır. Erken bilgisayarların sınırlı metinsel giriş / çıkışları tarafından yaratıldı. İnsanlar metin ayrıştırıcı değil!

İnsanların tamamen görsel bir dilin (görsel olarak bir şey yaptığınız yerde, fare ve benzeri unsurları birbirine bağlayarak) pratik bir dil için pratik olmadığını düşünüyorum. seviyesi. Dil öğelerinin, bir ikili dil dosyasına kaydedilmiş görsel bir temsiline sahip olduğu yer. Programcı deli gibi bir metin yazmaz veya satırların ve girintilerin büyüsü altında yaşamaz.

Ancak, kısayol tuşlarının / komutların / UI öğelerinin en verimli birleşimi ile öğe ekler. Ve sadece dizeleri ve diğer veri ve tanımlayıcıları yazar. Bu, sözdizimi hatalarını imkansız hale getirir ve akılda güvenlik ve doğruluk ile dilleri (örneğin: ADA) çok daha üretken yapar. Ayrıca, tüm yaygın hata sınıflarını imkansız hale getirerek, diğerlerini daha güvenli ve daha az buggy yapacaktır. (ADA'nın hantal olmasını engellediği gibi)

Bir dereceye kadar işler bu tarafa gidiyordu. Otomatik girinti ve sözdizimi renklendirme ile. Ne yazık ki hiç kimse "insan metin çözümleyici" nin temel kavramının yanlış olduğunu anlamadı (ya da yeterince umursamadı). Emacs vs vim argümanları komik, çünkü ikisi de yanlış. Yapay olarak yaratılmış bir problemin "çözümleri" dir.