g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Bir programcı olarak yazılım dünyasının yaklaşan sonuyla nasıl başa çıkılır?

Yazılım gittikçe daha karmaşık hale geliyor, insan programcılar gittikçe daha güçsüz hale geliyor, yazılım hataları gittikçe daha fazla ve daha ölümcül hale geliyor: 911 alarmlı telefon sistemi böcekler yüzünden çöküyor ve insanların canları ve malları ciddi tehditlerle karşı karşıya; arabalar böcekler nedeniyle otomatik oluyor İntihar ivmesi.

Bu makalede, 55 milyon satır Microsoft Visual Studio kodu; Airbus üzerinde 30 milyon satır kod; Tesla gibi üst düzey arabalar için 100 milyon satırlık kod, programcıların nasıl harika bir geliştirme yapma düşüncesini uyandırması gerekiyor. Araçlar, kod karmaşıklığını daha iyi kontrol edebilir, geliştirmeyi kolaylaştırabilir ve hataları en aza indirebilir.

10 Nisan 2014'te Washington Eyaleti, altı saat boyunca hiçbir 911 hizmeti yaşamadı. İnsanlar sadece yardım için aradıklarında meşgul tonu alacaklardır. Bunlardan biri, bir yabancı odasına girmeye çalıştığında en az 37911 yardım çağrısı yapan Seattle'lı bir kadındı, ancak yabancı oturma odasına son camdan girdiğinde, onu mutfaktan aldı. Bir bıçak adamı korkuttu ve sonunda panik içinde kaçtı.

Peki 911 çağrı sistemi neden çöküyor? O zamanki soruşturmaya göre, olayın kaynağı Colorado, Englewood şehrinde bir sunucuda çalışan bir yazılım parçasına kadar izlendi. Yazılım sistemi Intrado adlı bir tedarikçi tarafından sağlanır Bu yazılım, ülkenin her yerinden gelen 911 çağrılarının sayısını kaydetmek için sürekli olarak bir değişken sayar. Intrado programcıları bu değişken için bir üst sınır belirler. Bir milyonu seçtiler.

10 Nisan gece yarısından kısa bir süre önce, sayaç ayarlanan üst sınırı aşarak bir hataya neden oldu. Bu sayaç, gelen her arama için benzersiz bir kimlik kodu ürettiğinden, sayaç limiti aştığında, yeni arama reddedilir. Aynı zamanda, programcılar bu sorunu tahmin etmediler ve bunun için bir hatırlatıcı ayarlamadılar. Yani o zamanlar insanlar ne olduğunu bilmiyordu. Washington, California, Carolina, Florida ve Minnesota'daki sevk merkezlerinde, 11 milyon Amerikalıya hizmet veren bu 911, meşgul sinyali karşısında şaşkına döndü. Ertesi sabaha kadar Englewood City'de çalışan yazılımın neden olduğu sorun keşfedildi.Bu hatayı düzeltmek sadece bir sayıyı değiştirdi.

Kısa bir süre önce, acil aramalar yerel olarak ele alındı. Kesinti süresi olasılığı çok düşüktür ve teşhis ve onarımı kolaydır. Cep telefonlarının yükselişi ve yeni özelliklerin ortaya çıkması - 911'i SMS ile aramak mümkün mü? Veya sevk merkezine ses mi gönderiyorsunuz? İnternete dayanan daha karmaşık bir sistem geliştirin. İlk kez bir 911 arıza süresiyle karşılaşabilirsiniz, ancak şimdiye kadar bu tür bir durum dört kez meydana geldi.

Yazılım yavaş yavaş dünyayı tüketiyor. Giderek daha önemli sistemler, makineler veya kod kullanan kişiler tarafından kontrol edilmektedir. Bu kadar açık bir durum, 2015 yazında United Airlines, kalkış yönetim sistemindeki bir sorun nedeniyle uçuşları yerde ertelemek zorunda kaldı; bir sistem güncellemesinden sonra, New York Borsası sistemi bir işlem askıya alma sorunu yaşadı; "Wall Street Daily News web sitesinin ana sayfası çöktü; Seattleın 911 sistemi bu sefer başka bir yönlendirme hatası nedeniyle tekrar çöktü. Bu kadar çok yazılım sisteminin aynı anda arızalanması, insanlara bir siber saldırının kokusunu hissettiriyor. Daha da korkutucu olan, bu böceklerin hepsinin aynı gece meydana gelmesi.

Massachusetts Institute of Technology'de 35 yıldır yazılım güvenliği üzerine çalışan havacılık profesörü Nancy Leveson, "Elektromekanik sistemleri kullandığımızda, genellikle ayrıntılı olarak test ediyoruz." Dedi. Therac-25 raporu Therac-25 ile ünlüdür. Yazılım hatalarından dolayı 6 kişinin ölümüne neden olan bir tür radyoterapi cihazıdır. "Olabilecek her şeyi, girebileceği tüm durumları genellikle düşünebiliriz." Örneğin, bir demiryolu kavşağında trenin çalışmasını kontrol eden elektromekanik kilit çok fazla yapılandırma seçeneğine sahiptir; birkaç sayfa tüm sistemi açıklayabilir. Nasıl çalıştığını gözlemlemek için her konfigürasyonda gerçek bir tren çalıştırabilirsiniz. Oluşturup test ettikten sonra, tam olarak neyle uğraştığınız konusunda size rehberlik edeceksiniz.

Yazılım farklıdır. Sadece bir yerde bir metin dosyasını düzenleyerek, aynı modül bir otopilot veya envanter yönetim sistemi haline gelebilir. Bu esneklik sadece bir yazılım mucizesi değil, aynı zamanda bir lanettir. Yazılım her zaman değişiyor, çünkü diğer fiziğe göre daha güvenilmezdir.Bir program, aynı alanı kullanan diğer içeriklerden binlerce kat daha karmaşıktır ve karmaşıklığı sınırlar olmaksızın artmaktadır. Leveson bir kitapta şöyle yazdı: "Sorun şu ki, entelektüel yönetim yeteneklerimizi aşan sistemler kurmaya çalışıyoruz."

Yazılım tam olarak istediğimiz şeyi yaptı ve hatanın nedeni, ona yanlış şeyi yapması söylendi.

Mühendislik hataları-geribildirim için standart çerçeve. Örneğin, tıbbi cihazlarla ilgili düzenlemeler II.Dünya Savaşı'ndan sonra geliştirilmiştir.Yazılımın ortaya çıkmasından önce, sadece elektromekanik sistemler vardı. Buradaki fikir, kısmi güvenilirlik yoluyla genel güvenilirlik elde etmektir (örneğin, uçak motoru 40.000 kalkış ve inişi destekler) ve bu kırık parçaları (iki motor) durdurup değiştirmeyi planlamaktadır. Ancak yazılım kesintiye uğramayacaktır. Yazılımın yaptığı, biz ona yapmasını söylediğimiz şeydir. Aslında, bu mükemmel bir şekilde yapılıyor ve hatanın nedeni, onları yanlış yapmamızdır. . Yazılım hatası, anlama ve hayal gücünün başarısızlığıdır. Intrado'nun aslında otomatik olarak değiştirilebilen bir yedekleme rotası vardır ve 911 hizmetini hemen geri yükleyebilir, ancak FCC raporu "bu senaryo yalnızca uygulamanın belirli noktalarında gerçekleşir. Bu yerlerde tasarım yoktur. Otomatik düzeltici önlemler. "

Bazı fiziksel şeylerin aksine, bu kodun dışında şeyler yaratmanın sıkıntısıdır. Leveson'un da bahsettiği gibi, "Karmaşıklık insan gözümüzle görünmez."

Şimdi, yazılım yapma şeklimizi değiştirmeye yönelik bu girişimler aynı öncüle dayanıyor gibi görünüyor: Kodun anlaşılması çok zor. Bu yöntemleri anlamaya çalışmadan önce, bunu neden yaptıklarını anlamak mantıklıdır: kodlama, daha önce hiçbir şeyden farklı olarak, onu zihin için çok farklı kılar.

Teknik işleme genellikle dünyanın durumunu değiştirir ve yol daha düzgün hale gelir. Artık bir şeyin yenilenip yenilenmediğini söyleyemezsiniz, çünkü genellikle kod tarafından yeniden şekillendirilir. Örneğin, ayaklarınızın altındaki bir arabanın gaz pedalına bastığınızda artık her şeyi doğrudan kontrol etmiyorsunuz; pedaldan gaza mekanik bir bağlantı yok. Bunun yerine, motora ne kadar hava verileceğini belirlemek için yazılıma bir komut verirsiniz. Bu araba, oturabileceğiniz bir bilgisayar. Direksiyon simidi ve pedallar klavyedeki tuşlara benzer.

Her şey gibi, arabalar da yeni özellikleri desteklemek için bilgisayarlaştırıldı. Gaz kelebeği ve frenleme için bir program kullanıldığında, öndeki araca çok yaklaştığınızda otomatik olarak yavaşlayabilir veya yakıttan tasarruf etmenize yardımcı olmak için yakıt enjeksiyonunu hassas bir şekilde kontrol edebilir. Direksiyon simidini kontrol ettiğinde, yönü kapattığınızda sizi şeridinizde tutabilir veya sizi park alanına yönlendirebilir. Bu işlevleri kod olmadan yapamazsınız.

Yazılım, karmaşık bilinen makinelerin çoğunu yapmamıza izin verdi. Aynı zamanda, tüm bu karmaşık şeyler küçük silikon çipler halinde paketlendiğinden ve içinde on binlerce kod çalıştığından, pek fark etmedik. Ancak bu karmaşıklıkların bizim için görünmez olması, onların var olmadığı anlamına gelmez.

Ünlü Hollandalı programcı Edsger Dijkstra 1988'de bir pasaj yazdı: "Düşünme kavramsal düzeyde yapılmalıdır ki bu, tek bir düşünceyle eskisinden daha derin." Dijkstra bunu bir uyarı olarak aldı. Programcılar, yazılımı önemli sistemlere hevesle uygularken, dünyayı inşa etmenin kahramanları olacaklar, ancak Dijkstra, programcıların kendilerini abartabileceğine inanıyor.

Yazılım mühendisleri çözdükleri sorunu anlamıyor ve umursamıyor

Programlamayı zorlaştıran nedir? Programlama, programcıların bilgisayar gibi düşünmesini gerektirir. Hesaplamanın ilk günlerinde, kod onu daha da garip temsil etmek için 1 ve 0'ı kullanır. Programcının omzuna bakan biri "100001010011" ve "000010011110" gibi yan yana, programcının çözmesi gereken sorundan ne kadar uzakta olduğunu bilirsiniz; topçunun yörüngesini veya simülasyonunu hesaplamaya mı çalıştıklarını bilemezsiniz Bir tic-tac-toe oyunu. Fortran ve C'ye benzer şekilde, İngilizce gibi dillere ve "entegre geliştirme ortamları" veya IDE'ler olarak bilinen araçlara yönelik bu kısa tanıtımlar, basit hataların (yalnızca kod için yararlı olan Microsoft Word'ün dilbilgisi denetimi gibi) düzeltilmesine yardımcı olur, ancak belirsizdir Açık olmak gerekirse, programcı sorunun gerçekleriyle doğrudan ilgilenmez, ancak makine talimatlarını yazmak için zaman harcar.

MIT'de bir yazılım güvenliği uzmanı olan Leveson, "Şu anda sorun, yazılım problemleri geliştiren ve çözen yazılım mühendislerinin problemi anlamaması ve problemi önemsememesidir." Bunun nedeni, kendi kodlama çalışmalarına kendilerini çok fazla kapatmalarıdır. . Bu IDE'ler hakkında şu yorumu yaptı: "Yazılım mühendisleri, hataları çözmek için çeşitli araçlar ve araçlar sağlamayı severler. Ciddi yazılım sorunları, basit kodlama hataları ile değil, gereksinimlerle ilgilidir." Örneğin, arabayı kontrol etmek için kod yazdığınızda Gaz verdiğinizde, önemli olan gaz kelebeğinin ne zaman ve nasıl açılacağıdır. Ancak bu sistemler o kadar karmaşık hale geldi ki, neredeyse hiç kimse onları sezgisel olarak anlamasını sağlayamıyor. Leveson, "Arabada zaten 10 milyon satır kod var. Ne olacağını tahmin edemezsiniz."

Eylül 2007'de, Jean Bookout ve en iyi arkadaşı, aniden arabasının gaz pedalı sıkıştığı zaman otoyolda bir Toyota Camry sürdüler. Ayağını pedaldan çektiğinde, araba yavaşlamadı. Aynı zamanda tekrar fren yapmaya çalıştı ama frenler de güç kaybediyor gibiydi. Araba kaldırıma girmeden önce 150 metrelik bir kayma önleyici iz bıraktı. Onunla seyahat eden yolcu öldü. Bookout, hastanede ancak bir ay sonra uyandı.

Bu olay, Toyota'nın geçtiğimiz on yıldaki sözde "kazayla hızlanma" konusundaki araştırmalarından sadece bir tanesidir. Toyota, kazayı zayıf paspas tasarımı, yavaş pedallar ve sürücü hatalarına bağladı, ancak dış araştırmalar, hataların nedeninin araç yazılımı sorunları olduğunu ortaya çıkardı. Ulusal Karayolu Güvenliği Yönetim Merkezi, NASA ekibinden yazılım uzmanlarını Toyota'nın kodunu incelemeye davet etti. Yaklaşık 10 ay sonra NASA ekibi, yazılımın başarısızlığa neden olduğuna dair hiçbir kanıt bulamadı, ancak olasılığı göz ardı edemeyeceklerini de söylediler.

Bookout'un dava aşamasına kadar, biri sonunda ikna edici kanıtlar buldu. Davacının bir tanığı olan Michael Barr, Toyota'nın kodunu analiz etmek için 18 ay harcadı ve NASA'nın gözden kaçırdığı yerlerde hatalar buldu. Barr, programcılar tarafından yazılımın kaotik hale gelmesini tanımlamak için kullanılan bir jargon olan "spagetti benzeri kod" u tanımlar. Kod yıllarca biriktiğinde, spagetti haline gelir ve özellikler birbiri ardına eklenir ve işlev çok dağınıktır; nihayet kod, belirli test işlevi kusurlarından bahsetmeden, izlenemez hale gelir.

Barr'ın ekibi kazada aynı Camry modelini kullandı ve çalışan bilgisayarda kontrol edilemeyen hızlanma arızalarına neden olabilecek 10 milyondan fazla olasılık olduğunu gösterdi. Küçük bir veri parçası değiştiği sürece, bilgisayar belleğindeki bir bitin 0 veya 1 olduğunu ve aracın kontrolden çıkabileceğini gösterdiler. Toyota tarafından uygulanan arıza güvenlik kodu henüz otomobilin duracağını garanti etmiyor. Barr testi: "Yazılımı izlemek için yazılımı kullanıyorsun, eğer yazılım başarısız olursa, aynı zamanda bu program veya bu çökmüş uygulama bir günlüğüne kaydedilecek, ancak çalışmadığı için bir günlüğüne kaydedilemez."

Barr'ın davacıya verdiği ifade, Toyota'nın Brookout'a ve arkadaşının ailesine 3 milyon dolar tazminat ödemesine izin verdi. New York Times'a göre, Toyota ilk kez elektronik gaz kelebeği kontrol sorunları içeren benzer bir davadan mahkum edildi ve Toyota'nın beklenmedik hızlanma nedeniyle bir kazadan sorumlu olduğu ilk kez tespit edildi. Her iki taraf da davayı doğrudan tazminat cezasıyla bitirmeye karar verdi. Sonunda, Toyota 9 milyondan fazla aracı geri çağırdı ve beklenmedik hızlanma sorunlarını çözmek için yaklaşık 300 milyon dolar ödedi.

Akio Toyoda, Çin konferansında eğildi ve özür diledi

Yazılım için daha kötü günler var. Yazılımı iyi yapmak bizim için gittikçe daha önemli hale geliyor, çünkü yapmazsak, yazılım gittikçe daha karmaşık ve birbirine bağlı hale geldikçe, daha fazla temel işlevi kontrol ettikçe hayat daha da artacaktır. kötü.

Sorun, programcıların yaratıcılıklarını korumalarının zor olmasıdır. 1980'den beri programcıların çalışma şekli ve kullandıkları araçlar pek değişmedi. Bu durumun sürdürülemez olduğuna dair küçük ama büyüyen bir rezonans var. Microsoft'ta Visual Studio için çalışan kıdemli bir programcı olan Chris Granger, "Çok iyi programcılar bile kullandıkları sistemi anlamaya çalışacaklar." Microsoft'ta çalışırken uçtan uca düzenlemeler yaptı. Şimdiye kadar tek yaptığı Visual Studio araştırması yaklaşık bir buçuk ay sürdü ve tek yönlü bir aynanın arkasında kod yazan insanlara baktı. Dedi ki: "Araçları nasıl kullanıyorlar? Nasıl düşünüyorlar? Bilgisayarın önüne nasıl oturuyorlar, fare kullanıyorlar ve ne zaman fare kullanmıyorlar? Tüm bunların sabit kalıpları var, ama aslında onları test etmedik."

Bu keşif onu şaşırttı. Dedi ki: "Visual Studio, dünyanın en büyük bağımsız yazılımı, 55 milyondan fazla kod satırı var. Bu araştırmada bulduğum bir diğer şey de kodun% 98'inden fazlasının alakasız olduğu. Bir keşif, insanların temelde beyinlerinde bilgisayar oynamasıdır. Programcılar, göz bağlarıyla oynamaya çalışan Go oyuncuları gibidir. Enerjilerinin çoğu, her modülün görünümünü tasvir etmek için beyinde tüketilir. Onlar için oyunun kendisi hakkında düşünecek pek bir şey kalmadı.

Bilgisayarların bilgi işlem gücü, son 40 yılda her 18 ayda iki katına çıktı. Ama programlama neden değişmedi?

John Resig, ünlü bir JavaScript programcısıdır ve yazılımı İnternet'in yaklaşık yarısını desteklemektedir.Aynı zamanda çevrimiçi eğitim sitesi Khan Academy'nin teknik direktörüdür. 2012'nin başlarında, web sitesindeki bilgisayar bilimleri dersleriyle mücadele etti. Programlamayı öğrenmek neden bu kadar zor? Temel sorun, kodun çok soyut olması gibi görünüyor. Yazılım yazmak, bir köprüyü onarmak için betonarme kullanmakla aynı şey değildir.Bir köprüyü tamir ederken betonarme görebilirsiniz. Bir program geliştirmek için kelimeleri yazarsınız. Bir programın performansını değiştirmek istediğinizde, bunun bir oyun veya bir web sitesi veya simüle edilmiş bir spor olduğunu ve gerçekte değiştirdiğiniz şeyin metin olduğunu varsayalım. Yani başarılı olan öğrenciler, kalan öğrenciler metin içinde adım adım bilgisayar ortamında sorunları düşünebilen ve her adımda hesaplamaları takip edebilen öğrencilerdir. Granger gibi Resig de bu yöntemin kullanılması gerekip gerekmediğini düşünüyor. Bilgisayarların bilgi işlem gücü, son 40 yılda her 18 ayda iki katına çıktı. O halde kodlama neden değişmedi?

Aslında ikisinin de aynı konuları aynı anda düşünmesi bir tesadüf değildir. İkisi de Bret Victor adlı bir bilgisayar araştırmacısı tarafından Montreal Hotel'de bir grup yazılım mühendisi öğrenciye verilen aynı ikonik dersi izledi. Bu konuşma, Şubat 2012'de web sitesine yüklendikten sonra bir virüs gibi yayılmaya başladı ve iki cesur tartışmaya neden oldu. Birincisi, yazılım geliştirme şeklimizin temelden kırılmış olmasıdır. İkincisi, Victor bunu nasıl çözeceğini biliyor.

Bret Victor kod yazmayı sevmez. Dedi ki: "Kulağa garip geliyor. Bir şey yaratmak istediğimde, özellikle yazılım yoluyla bir şey yaratmak istediğimde, önce iğrenç şeyler katmanı zorlayacağım. İstediğim bunlar değil. Evet, bir metin düzenleyicide çok fazla metin yazmam gereken şey bu. "

"Bunun işleri yapmanın yanlış yolu olduğuna dair çok sağlam bir inanç var."

Victor, David Foster Wallace tarzına sahip ve şimşek benzeri zekası inanılmaz. Gelecekteki bilgisayarları incelemek için bir laboratuvar işletiyor ve teknolojiyi kullanan insanlardan daha az ilgileniyor gibi görünüyor. Diğer iyi alet üreticileri gibi, dünyaya bakış açısı da teknolojinin ve beşeri bilimlerin bir kısmının eşit olmasıdır. California Institute of Technology'den elektrik mühendisliği bölümünden mezun oldu ve ardından Berkeley'deki California Üniversitesi'nden mezun olduktan sonra müzik sentezleyicileri geliştiren bir şirkette çalıştı. Bu soru onun ikili kişiliğine mükemmel bir şekilde uyuyor: Ellerinin bir uzantısı olan klavye aracılığıyla müzik çalan oyuncuları düşünmek için yeterince zaman harcayabilir ve ayrıca dijital sinyal işleme hakkında düşünmek için yeterince zaman harcayabilir. Matematik problemi.

Victor, Resig ve Granger'ın 2012'nin başlarında izlediği video olan kendisini ünlü yapan bu konuşmayı yapana kadar, sonunda neredeyse işine nüfuz eden ilkeleri anladı. (Bu dersi "ilke olarak icat" olarak adlandırdı) İlke şudur: "Yaratıcıların yarattıklarıyla anlık bir bağlantıya ihtiyaçları vardır." Programlamayla ilgili sorun, bu ilkeyi ihlal etmesidir. Yazılım sistemlerinin anlaşılmasının bu kadar zor olmasının ve hataların popülaritesinin nedeni budur: programcılar başından beri çok soyuttur.

"Bir bilgisayar programının ne olduğuna dair mevcut konseptimiz 1950'lerde Fortran ve ALGOL'dan türetilmiştir. Bu diller saat ölçümü için tasarlanmıştır." Bu kod artık ekrandaki C ve Java gibi. Bu tür harfler (Fortran ve ALGOL'dan türetilmiştir), bu büyük kart yığınları yerine, canlı ve anlaşılır değildir.

Victor için, bir metin editörü aracılığıyla kanseri anlamaya çalışan insanlar fikri şaşırtıcı.

Kelime işlemeye bir benzetme var. Geçmişte programda gördüğünüz belge metnin kendisiydi. Seviyeyi veya yazı tipini veya sınırı değiştirmek için, bilgisayara ne yapacağını söyleyebilecek özel "kontrol kodları" veya komutlar yazmanız gerekiyordu. Örneğin, "Bu bölümdeki kod italik olmalıdır." Sorun, belgeyi yazdırana kadar bu kodların etkisini görememenizdir. Ne alacağınızı tahmin etmek zor. Bir bilgisayar tarafından işlendikten sonra kodun neye benzediğini hayal etmelisiniz, bu yüzden bilgisayarı her zaman aklınızda tutmalısınız.

Sonra "ne görüyorsan onu alırsın" ortaya çıktı. Bir makaledeki bir paragrafı italik olarak işaretlediğinizde, harf ekranda hemen eğimli hale gelir. Kenarlığı değiştirmek isterseniz cetveli ekranın üst kısmına sürükleyebilir, değişikliği anında görebilirsiniz. Buradaki belge gerçek bir şeye benziyor, istediğiniz zaman halledebileceğiniz bir şey. Sadece bir problem olup olmadığını belirlemek için gözlemlenmesi gerekir. Bu karmaşık sistemin kontrolü, insanların sayfaya tıklayarak erişmesine izin veren belge katmanı ve format motoru ile sağlanır.

Victor, programlamanın kendisinin böyle olması gerektiğidir. Onun için, uyarlanabilir bir yapışkan kontrol sistemi tasarlamak veya kanseri anlamaya çalışmak gibi bu önemli görevler, bir metin düzenleyiciye bakma fikri oldukça korkutucu. Programcıların gelecekte bir gün çözecekleri tam olarak budur.

Bunun çılgınca bir fikir olmadığını kanıtlayacak kadar emsal var. Örneğin Photoshop, algoritmanın ne olduğunu bilmeyenler için güçlü görüntü işleme algoritmaları sağlar. Bu, yazılımın en karmaşık parçasıdır.Karmaşıklık yalnızca sentezleyici için karmaşıktır, ancak yazılımdaki düğmeler ve sürükleme çubukları, kullanıcıya bir enstrüman çalmak gibidir. Muhtemelen en ünlü podcast reklamcısı olan Squarwspace, kullanıcıların HTML ve CSS kodu yazmak yerine sadece birkaç tıklama ile bir web sitesi oluşturmasına olanak tanıyan bir yazılım geliştirdi. Bu yazılım, daha önce profesyonel web sitesi tasarımcıları tarafından yapılacak kadar güçlüdür.

Ancak bunlar sadece birkaç örnektir. En büyük gerçek şudur ki, birisi ilginç bir şey yapmak için bir bilgisayar kullanmak istediğinde, kod yazmalıdır. Victor, bunun bir fırsat olduğunu düşünmeyen, ancak programcıların ahlakının başarısız olduğunu düşünen bir idealist. Onun konuşması bir eylem çağrısıdır.

Konuşmanın özü, devre tasarımı, bilgisayar simülasyonu ve algoritma hata ayıklaması ile başa çıkmak için şu anda mevcut olan araçların ne kadar ilkel olduğunu ve iyi bir aracın nasıl görünmesi gerektiğini göstermeye yönelik bir dizi girişimdi. Örnekleri çok ünlü. İnsanların hayal gücünü çeken şey, ironik bir şekilde, arayüzlerinin önemli olmamasıdır. Kod diğer tarafı kontrol ederken, yüzeyde Mario gibi görünen bölünmüş ekranlı bir oyunu gösterir. Victor kodu değiştirdiğinde, oyundaki ekran buna göre değişecektir: bir sayıyı düşürür ve yerçekimi büyüktür ve Mario yüzer; diğerini arttırır ve oyun hızı Mario'nun ekrandan kaçmasına neden olur.

Bir seviye tasarlamak istediğinizi varsayalım, Mario bir kaplumbağanın üstünden atlayarak onu küçük bir geçit haline getirebilir. Oyun programcıları bu sorunu çözmek için genellikle iki adım kullanır: İlk olarak, kodunuza bakın, Mario'nun ne kadar yüksek zıpladığını, ne kadar hızlı koşabileceğini, kaplumbağanın sırtının ne kadar yüksek olduğunu kontrol eden koda bakın ve ardından bunu düzenleyicide yapın Bazı ayarlamalar, yapacağımız son etkiyi tahmin etmek için hayal gücünüzü kullanın. Daha sonra aslında neye benzediğini görmek için oyunu tekrar oynayabilirsiniz.

Victor daha doğrudan bir şey istedi. Mario'nun rotasından şu sözlerle alıntı yaptı: "Zamanında bir işleminiz varsa ve değişikliğin sonuçlarını gerçek zamanlı olarak görmek istiyorsanız, zamanı mekana eşlemeniz gerekir." Mario'nun istemediği bir düğmeye bastı. Sergilenecek yer, ancak gelecekte gösterilecek yer: Mario'nun gölgesi uzağa çekiliyor. Dahası, bu yansıtma yolu pasiftir: Victor oyunun parametrelerini değiştirdiğinde, artık farenin hızlı sürüklenmesiyle kontrol edilir ve yolun şekli değişecektir. Tanrı'nın bakış açısına sahip olmak gibi. Mario'nun zor görevi tamamlamasına izin vermezseniz, tüm problem stereo alıcıdaki değeri ayarlamak gibi çeşitli parametrelerden oluşan bir oyunda basitleştirilmiştir. Doğru arayüz ile kod yazmadan çalışabilirsiniz; oyunun davranışını doğrudan siz kontrol edersiniz.

Seyirci bu sahneyi ilk gördüğünde nefes alamadı ve şok oldu. Bir çocuk oyununa değil, tüm sektörün geleceğine baktıklarını biliyorlar. Yazılımda yer alan karmaşık davranışların çoğu, zamanla Victor, yeterince hayal gücünüz varsa, gördüklerinizi, sanki alkışınızla oynuyormuş gibi elde edebileceğinizi geliştirebileceğinizi göstermiştir. Bu dersi izleyen bir programcı daha sonra şunları yazdı: "Birdenbire tüm aletlerimin güncelliğini yitirdiğini hissediyorum."

John Resig bu dersi izlediğinde Khan Academy'nin programlama ders planından vazgeçti. Web sitesinin programlama alıştırmalarının Victor'un demoları gibi çalışacağını umuyor. Sol tarafta kodlamayı tamamladınız ve sağ tarafta programı çalıştırabilirsiniz: bir resim veya oyun veya simülasyon. Kodu değiştirirseniz, hemen resmi değiştirir. Resig, bu yaklaşımla ilgili olarak şunları yazdı: "Bu tür gerçek duyarlı bir ortamda, öğrencilerin öğrendiği modeli tamamen değiştirebilirsiniz ... sonuçları görebilir ve temelde yatan sistemin esasen nasıl çalıştığını sezgisel olarak görebilir ve Net bir açıklamaya gerek yok. "Khan Academy, her ay ortalama bir milyon öğrencinin bu programı kullandığı, dünyanın en büyük bilgisayar programlama kursu haline geldi.

Chris Granger, Microsoft'un Visual Studio projesinde çalışmaktan da ilham aldı. Kötü Victor videosunu izledikten birkaç gün sonra, Ocak 2012'de yeni bir programlama ortamının prototipini yarattı. Temel yeteneği, size programın gerçek zamanlı davranış geri bildirimini verebilmesidir. Sistemin onu kontrol eden kod altında ne yaptığını görebilirsiniz. Göz bağını çıkarmak gibi. Granger bu projeye "Işıklı Masa" adını verdi.

Nisan 2012'de Kickstarter'daki Light Table için fon aradı. Bu, programlama dünyasında bir sansasyon haline geldi. Bir aydan kısa bir sürede, bu proje 200.000 ABD dolarından fazla para topladı. Bu düşünce yayıldı. Bu canlı performans şekli, programdaki veri akışını gerçek zamanlı olarak görebilir ve Google ve Apple'ın amiral gemisi yazılımına girebilir. Yeni iPhone ve Mac uygulamaları (Swift olarak adlandırılır) yapmak için varsayılan dil, Playground adı verilen Light Table'dan ilham alan geliştirme ortamını desteklemek için Apple tarafından sıfırdan geliştirilmiştir.

Ancak konuşmasının etkisini gördükten sonra Bret Victor hayal kırıklığına uğradı. Daha sonra şunları söyledi: "Söylediklerimi yanlış yorumlayan pek çok şey var." İnsanlar onu programlama araçlarını tartışmak için toplantılara davet etmeye başladıklarında, bir şeylerin yanlış olduğunu biliyordu. Dedi ki: "Herkes programlama ortamıyla ilgilendiğimi düşünüyor." Dinamik Davranış Görsel Temsilciliğinde dediği gibi, insanların sistemleri nasıl algıladığı ve anladığıyla ilgileniyor. Kod, dinamik davranış oluşturmak için giderek artan bir seçenek haline gelse de, hala anlaşılması en zor araçlardan biridir. "Oluşturma kılavuzlarının" anahtarı, sistemin davranışı ile kodu arasında doğrudan bir bağlantı oluşturarak sorunları azaltabileceğinizi göstermektir.

Programlamanın hala var olup olmayacağından emin değilim

Sonraki iki derste, "Ölü balıkları boyamayı bırak" ve "Resim dinamiklerini görselleştirmek" bir adım daha yaklaşıyor. Biri animatörler için, diğeri verileri görselleştirmek isteyen bilim adamları için geliştirdiği iki programı gösterdi. Her biri kendi kodlamalarının çoğunu içeren bir süreci aldı ve WYSIWYG arayüzü. Victor, kodlamanın ilk günlerinde her sorunun üstesinden gelmek için aynı yaklaşımın kullanılabileceğini öne sürdü. Bana şöyle dedi: "Programlamanın devam edip etmeyeceğinden veya yazılım geliştiricilerin var olup olmayacağından emin değilim." Bir yazılım geliştiricinin doğru rolü, yazılım geliştiricilerin ihtiyaçlarını ortadan kaldırabilecek araçlar yaratmaktır. Ancak bu şekilde, hesaplama problemlerini en acil şekilde çözmesi gerekenler, herhangi bir ara kod olmadan bu problemleri doğrudan kavrayabilirler.

Elbette bunu yapmak için programcıların bunu kendilerinin yapmasına izin vermelisiniz. Yakın tarihli bir makalede Victor, profesyonel yazılım geliştiricilere yeteneklerini Snapchat veya Uber gibi uygulamalar geliştirmek için harcamamalarını söyledi. Şöyle yazdı: "Günlük hayatın rahatsızlığı büyük bir sorun değil." Bunun yerine bilim adamlarına ve mühendislere odaklanmalılar, bana dedikleri gibi, "Bunlar gerçekten çalışan, pratik problemleri çözenler, Önemli sorunları olan insanlar, çok kötü, çok kötü araçlar kullanıyorlar. "Çok heyecan verici bir çalışma olduğunu yazdı, özellikle" model tabanlı tasarım "için bazı araçlar, ancak çoğu Programcılar onları anlamıyor.

"Kullandığınız tüm endüstriyel ürünlere, ne kullandığınıza veya bu şirketlere yakından bakarsanız, endüstriyel olmayan tek ürün koddur." Eric Bantégnie, bir Fransız bina güvenliği şirketi olan Esterel Technologies'in kurucusudur. Önemli yazılım geliştirme aracı. Victor ve Bantégnie, mühendislerin büyük sistemler geliştirmek için IDE'ye milyonlarca satır kod yazmaları gerektiğini düşünmüyor. Dedi ki: "Kimse elle araba yapmaz. Kod hala birçok yerde manueldir. Manuel olarak 10.000 satır kod yazdığınızda kabul edilebilir. Ancak sisteminizde Airbus gibi 30 milyon satır kod var. Veya 1 milyar satır kodlu Tesla veya yüksek kaliteli arabalar çok, çok karmaşık hale geldi. "

Bantégnienin şirketi, kod yazmanıza gerek kalmayan model tabanlı tasarımın kullanımında öncülerden biridir. Bunun yerine, programınızın uyması gereken kuralları açıklayan bir akış şeması oluşturursunuz ve bilgisayar, sizin kurallarınıza göre kod üretir. Örneğin, kural olarak bir asansör geliştirme kontrol sistemi verirseniz, asansör kapısı açıkken, birisi lobide düğmeye basarsa, asansör kapıyı kapatır ve ardından asansörü çalıştırır. Model tabanlı tasarım araçlarında, bu kuralı temsil etmek için küçük bir diyagram kullanabilirsiniz, çünkü beyaz tahtaya bir mantık şeması çizerek, farklı durumlar kapı açık, çalışır ve kapı kapalı gibi farklı kutularla temsil edilir. Çizgiler, bir durumdan diğerine nasıl geçiş yaptığınızı gösterir. Bu şema, sistemin şemasını çok açık hale getirir: Sadece bu şemaya bakarak, asansörün çalışmasının tek yolunun asansör kapılarını kapatmak olduğunu veya asansör kapılarını açmanın tek yolunun asansörü durdurmak olduğunu anlayabilirsiniz.

İnsanlar kod yazmayı bilir, soru ne yazılacağıdır

Bu pek Photoshop değil. Photoshop'un güzelliği elbette sonunda ekranda görüntülenen resimlerdir. Model tabanlı tasarım altında karşılaştırma yaparak. Ekranınızdaki resim daha çok bir plan gibidir. Ve bu yöntemi yazılım geliştirmek için kullanmak, doğası gereği geleneksel programlama yöntemlerinden farklıdır. Geleneksel programlamada, göreviniz karmaşık kuralları bulmak ve bunları koda çevirmektir; enerjinizin çoğu kuralların kendisini düşünmek yerine koda çevirmeye harcanır. Bu model tabanlı yaklaşım için odaklanmanız gereken tek şey kurallar. Yani düşünmek için zaman harcaman gereken şey bu. Bu, makineden ziyade sorunun kendisine odaklanarak sorunu çözmenin bir yoludur.

"Ben de bir programcıyım. Genellikle, yazılım kodlamayla ilgili temel sorun programcının becerisi değildir. İnsanlar kod yazmayı bilir. Sorun hangi kodun yazılacağıdır. Çünkü gereksinimlerin çoğu doğal dildir, belirsizdir ve gereksinimler şunlardır: Kesinlikle çok doğru değil, genellikle programcılar tarafından yanlış anlaşılıyor. "

Bu görüşe göre, yazılımın ne yapması gerektiğini açıklamak için kullanılan ortam, iletişim ve bir kağıda çizilen düz yazı benzeri açıklamalar, yazılımın yapması gerekenden çok farklı olduğundan, yazılım işe yaramaz hale gelir. Birinden diğerine kaybolan çok fazla bilgi var. Model tabanlı tasarımın arkasındaki fikir, boşluğu kapatmaktır. Bu çok benzer model, sistem tasarımcıları tarafından ihtiyaç duyduklarını ifade etmek için de kullanılır ve bilgisayar otomatik olarak kod üretir.

Tabii ki başarılı olmak için proje başlamadan önce bir çok işin yapılması gerekiyor. Her şeyden önce, insanlar için doğal olan bir araç geliştirmek için birisinin bir araç yapması gerekir.Bu araçlar, önceden düşündükleri şeyleri not almak veya çizmek gibidir, ancak bilgisayarlar için o kadar da belirsiz değildir. Bu modelleri gerçek koda dönüştürmek için bir program yapmak zorunda kaldılar. Sonunda, üretilen kodun beklendiği gibi doğru çalışacağını kanıtlamaları gerekiyordu. Bantégnie: "Neyse ki arkasındaki 20 yıllık ön çalışmadan faydalandık."

ANSYS tarafından 2012 yılında satın alınan Esterel Teknolojisi, 1980'lerde Fransız nükleer ve havacılık endüstrilerinin başladığı zaman başladı ve önemli güvenlik kodlarının karmaşıklığının hatalardan kaçınmanın gittikçe daha zor hale gelmesinden endişe duyuyorlardı. Fransız avcı ve ticari hava taşıtı üreticisi Dassault Aviation'ın bilimsel araştırma direktörü Emmanuel Ledinot şunları söyledi: "Askeri aviyonik sistemler üzerinde çalışırken başladım. Sistemleri entegre etmek ve hatalarını ayıklamaktan sorumlu olanlar hataları fark ettiler. Sayı artıyor. "Uçaklardaki yerleşik bilgisayarların sayısı 1980'lerde arttı. Tek bir yerleşik bilgisayar değil, düzinelerce bilgisayar, her biri kontrol, navigasyon ve iletişimle ilgili oldukça özel görevlerden sorumludur. Sensörlerden gelen veri girişi ve pilotun komut verdiğinde mükemmel zamanında yanıt vermesi nedeniyle bu sistemleri uçağı uçuracak şekilde koordine etmek. "Bu yüzlerce veya binlerce olayın doğru sırada ve doğru zamanda işlenmesi, artan arızaların ana nedenidir."

Ledinot, bu tür karmaşık kodların elle yazılmasının sürdürülemez hale geldiğine inanıyor. Ne yaptığını anlamak çok zordur ve doğru çalıştığını doğrulamak imkansızdır. Yeni bir yol bulmaya gitti. Bu konuşmasında şunları söyledi: "Böyle bir süreçte aletleri değiştirmenin çok pahalı olduğunu anlamalısınız ve devam etmek için bu kararı almayacaksınız. Gidecek hiçbir yeriniz yok."

Çoğu programcı kodu sever. En azından anlıyorlar

Fransız Bilişim Araştırma Merkezi'nde INRIA bilgisayar bilimcisi Gerard Berry ile Fransız gerçek zamanlı hibrit bir araç olan Esterel adlı bir araç üzerinde işbirliği yapmaya başladı. Esterel'in arkasındaki fikir Geleneksel programlama dilleri basit süreçleri açıklamak için uygun olduğunda, bunların hepsi bir tarif gibi öngörülebilir bir sırayla gerçekleşir.Bir sistemde kullanmak istiyorsanız, birçok olay her an olabilir. Herhangi bir sırada, bir uçağın kokpitinde olduğu gibi, kaçınılmaz olarak ortalığı dağıtacaksınız. Ancak kontrol yazılımında bir karmaşa yaratırsa tehlikeli olabilir. Bir makalede Berry, düşük seviyeli programlama tekniklerinin büyük güvenlik odaklı programlar tarafından kabul edilmeyeceğini, çünkü davranışların anlaşılmasını ve analizini neredeyse imkansız hale getirdiğini tahmin etti. "

Esterel, bilgisayarın sizin için bu karmaşık sorunu çözmesine izin vermek için tasarlanmıştır. Bu, model tabanlı bir yaklaşımın beklentisidir: basit programlama kodu yazmak yerine, bir sistem davranışı modeli yaratırsınız.Bu durumda, bir model, bireysel olayların nasıl işleneceğine, olayların nasıl önceliklendirileceğine ve hangi olayların bunlara bağlı olduğuna odaklanır. Diğer etkinlikler vb. İçin