Sistemlerin karmaşıklığındaki artış, art arda gelen programcı nesillerini nasıl etkiledi?

"Yeni" bir programcı olarak (ilk olarak 2009'da bir kod satırı yazdım), örneğin bugün .NET Framework gibi şeyler içeren oldukça karmaşık öğeler gösteren bir program oluşturmanın nispeten kolay olduğunu fark ettim. Görsel bir arayüz oluşturmak veya bir listeyi sıralamak şimdi çok az komutla yapılabilir.

Programlamayı öğrenirken, paralel olarak bilgisayar teorisini de öğreniyordum. Sıralama algoritmaları, donanımın birlikte çalışma prensipleri, boolean cebiri ve sonlu durumlu makineler gibi şeyler. Fakat teoride öğrendiğim çok temel bir prensibi denemek isteyip istemediğimi fark edersem, kitaplık, çerçeve ve işletim sistemi gibi şeyler tarafından çok fazla teknoloji engellendiğinden, başlamak her zaman çok daha zor oldu.

Hafıza açısından verimli bir program yapmak 40/50 yıl önce gerekliydi, çünkü yeterli hafıza yoktu ve pahalıydı, bu nedenle çoğu programcı veri türlerine ve talimatların işlemci tarafından nasıl ele alınacağına çok dikkat ediyordu. Günümüzde, bazıları artan işlem gücü ve kullanılabilir hafıza nedeniyle bu endişelerin bir öncelik olmadığını iddia edebilir.

Sorum şu ki, eski programcılar bu gibi yenilikleri bir nimettir veya soyutlanacak ek bir katman olarak görüyorsa ve neden böyle düşünebilirler? Genç programcılar, geniş kapsamlı kütüphanelerin alanlarını keşfetmeden önce düşük seviyeli programlama öğrenmek için daha fazla yarar sağlıyor mu? Eğer öyleyse neden?

Artan işlem gücü ve mevcut bellek miktarı nedeniyle bu gerekli değildir.

Ucuz belleğe, devasa disklere ve hızlı işlemcilere sahip olmak, insanları her bayt ve döngüye takıntı yapmaktan kurtaran tek şey değil. Derleyiciler, önemli olduğu zaman yüksek düzeyde optimize edilmiş kod üretmede insanlardan çok daha iyidir.

Ayrıca, gerçekte ne için optimize etmeye çalıştığımızı, belirli bir maliyet için üretilen değeri unutmayalım. Programcılar makinelerden çok daha pahalıdır. Yaptığımız her şey, programcıların çalışma, doğru, sağlam, tam özellikli programlar daha hızlı üretmesini sağlar ve daha ucuzdur, dünyada daha fazla değer yaratılmasına yol açar.

Bununla birlikte sorum şu ki, insanlar düşük seviyeli elementlerin bu "gizlenmesi" hakkında ne hissediyorlar. Daha yaşlı programcılar bunu bir nimettir veya aşılması gereken gereksiz bir katman olarak görüyor musunuz?

Herhangi bir işin yapılması kesinlikle gereklidir. Bir yaşam için kod analiz edicileri yazıyorum; Kayıt tahsisi veya işlemci zamanlaması veya milyonlarca başka ayrıntıdan herhangi biri hakkında endişelenmek zorunda olsaydım, zamanımı hataları düzeltmek, performans raporlarını incelemek, özellikler eklemek vb. için harcama yapmazdım.

Tüm programlama, daha değerli bir katman oluşturmak için altındaki katmanı çıkarmakla ilgilidir. Tüm alt sistemleri ve bunların birbirleri üzerine nasıl oluşturulduğunu gösteren bir "katman pastası şeması" yaparsanız , donanım ve kullanıcı deneyimi arasında kelimenin tam anlamıyla düzinelerce katman olduğunu göreceksiniz . Windows katman pastası şemasında, ham donanım ile C # da "merhaba dünya" yürütme yeteneği arasında 60 alt seviye gerekli bir alt sistem olduğunu düşünüyorum.

Genç programcıların, geniş kütüphanelerin alanlarını keşfetmeden ÖNCE düşük seviyeli programlamayı öğrenmenin faydası olacağını düşünüyor musunuz?

ÖNCE önem veriyorsun, bu yüzden soruna olumsuz cevap vermeliyim. Şu anda 12 yaşında bir arkadaşın programlamayı öğrenmesine yardımcı oluyorum ve bunları, x86 assembler değil Processing Processing'de başlattığımı inansanız iyi edersiniz . Genç bir programcıya böyle bir şeyle başlarsanız Processing.js, yaklaşık 8 saat içinde kendi ateş etme oyunlarını yazacaklar. Bunları bir araya getirici ile başlatırsanız, yaklaşık sekiz saat içinde üç sayıyı çarpacaklar. Daha genç bir programcının ilgisini çekmek için hangisinin daha muhtemel olduğunu düşünüyorsunuz?

Şimdi eğer soru "pastanın n katmanını anlayan programcılar n - 1 katmanını anlamaktan faydalanıyor mu?" Cevap evet, ancak yaş veya deneyimlerden bağımsız; Her zaman bu, altta yatan soyutlamaları daha iyi anlayarak daha yüksek seviye programlamanızı geliştirebilmenizdir.

Bu konuda fikirlerim vardı ve 20 yıl önce bir kitap haline getirdim . Baskısı çok uzun, ama Amazon'da hala kullanılmış kopyalarını alabilirsiniz .

Sorunuza basit bir cevap Aristoteles kadar eski: Doğa bir boşluktan nefret ediyor . Makinelerin daha hızlı ve daha büyüdüğü gibi, yazılım daha da yavaşladı.

Daha yapıcı olmak için önerdiğim şey bilgi teorisi ve yazılımla doğrudan ilgisi bilgisayar bilimi eğitiminin bir parçasıydı. Sadece şimdi, eğer hiç teğet bir şekilde teğet bir şekilde öğretilir.

Örneğin, algoritmalardaki büyük O davranışı, bir girdi tipini, çıktı sembolünü, gürültüyü, artıklığı ve bant genişliğini içeren bir Shannon tipi bilgi kanalı olarak düşünürseniz, çok net ve sezgisel olarak anlaşılabilir.

Diğer taraftan, bir programcının üretkenliği, Kolmogorov bilgi teorisi kullanılarak benzer terimlerle anlaşılabilir. Giriş, kafanızdaki sembolik bir kavramsal yapıdır ve çıktı, parmak uçlarınızdan çıkan program metnidir. Programlama işlemi ikisi arasındaki kanaldır. Gürültü işleme girdiğinde tutarsız programlar (hatalar) yaratır. Çıktı programı metni yeterli fazlalığa sahipse, böceklerin yakalanmasına ve düzeltilmesine izin verebilir (hata algılama ve düzeltme). Ancak, çok fazla yedekli ise, çok büyüktür ve büyüklüğü, hata oranıyla birlikte, hataların ortaya çıkmasına neden olur . Bu akıl yürütmenin bir sonucu olarak, programlamanın bir dil tasarım süreci olarak nasıl ele alınacağını gösteren kitabın iyi bir bölümünü harcadım, bir ihtiyaç için uygun alana özgü dilleri tanımlayabilmek amacıyla. CS eğitiminde etki alanına özgü dillere sözde hizmet veriyoruz, ancak yine teğetsel.

Dil oluşturmak kolaydır. Bir işlevi, sınıfı veya değişkeni her tanımladığınızda, başladığınız dile bir kelime ekleyerek çalışacak yeni bir dil oluşturursunuz. Genel olarak takdir edilmeyen şey, amacın yeni dili problemin kavramsal yapısına daha yakın bir hale getirmektir. Bu yapılırsa, kodu kısaltma ve daha az para kazanma etkisi yaratır, çünkü ideal olarak, kavramlar ve kod arasında 1-1 eşlemesi vardır. Haritalama 1-1 ise, bir hata yapmak ve farklı bir kavram olarak yanlış bir kavram kod, ancak program bu kodlar ne olur ki, çökmesine asla belki hiçbir tutarlı gereksinimi .

Bunu alamıyoruz. Yazılım sistem tasarımı hakkındaki tüm cesur konuşmalarımız için, kodun gereksinimlere oranı daha da büyüyor.

Doğru, çok faydalı kütüphanelerimiz var. Ancak, soyutlama konusunda çok dikkatli olmamız gerektiğini düşünüyorum. B'nin A'yı oluşturup oluşturmadığını ve bunun iyi olduğunu, C'nin B'yi oluşturması halinde daha iyi olduğunu varsaymamalıyız. Ben buna "prenses ve bezelye" fenomeni diyorum. Sorunlu bir şeyin üstüne katmanlar koymak mutlaka onu düzeltmez.

Uzun bir yazıyı sonlandırmak için (bazen başımı belaya sokan) bir programlama stili geliştirdim.

• Buluş kötü bir şey değil. Diğer mühendislik dallarında olduğu gibi iyi bir şey. Elbette diğerleri için bir öğrenme eğrisi yaratıyor olabilir, ancak genel sonuç daha iyi verimlilik ise, buna değer.
• Haiku tarzı minimalist kod. Bu özellikle veri yapı tasarımı için geçerlidir. Tecrübelerime göre, bugünlerde yazılımdaki en büyük sorun şişirilmiş veri yapısıdır.

Yüksek düzeyde soyutlama, bilgisayar alanında devam eden ilerlemeye ulaşmak için şarttır.

Neden? Çünkü insanlar herhangi bir anda sadece kafalarında çok fazla bilgi tutabilirler. Modern, büyük ölçekli sistemler bugün sadece mümkün, çünkü bu tür soyutlamaları kaldırabilirsin. Bu soyutlamalar olmadan, yazılım sistemleri basitçe kendi ağırlıkları altında çökecektir.

Ne zaman bir yöntem yazarsan, bir soyutlama yaratıyorsun. Bir yöntem çağrısının arkasına gizlenmiş biraz işlevsellik yaratıyorsunuz. Neden onları yazıyorsun? Çünkü metodu test edebilir, çalıştığını ispatlayabilir ve istediğiniz zaman sadece metot çağrısı yaparak bu fonksiyonu çağırırsınız ve bu metodun içindeki kod hakkında daha fazla düşünmenize gerek yoktur.

Hesaplamanın ilk günlerinde makine dilini kullandık. Çok küçük, çıplak metal programlar yazdık. Çok zor bir süreçti. Hata ayıklayıcı yoktu; programın genellikle çalıştı veya çöktü. GUI yoktu; her şey ya komut satırı ya da toplu işlemdi. Yazdığınız kod yalnızca o makinede çalışır; farklı bir işlemciye veya işletim sistemine sahip bir makinede çalışmaz.

Bu yüzden, tüm bu detayları soyutlamak için üst düzey diller yazdık. Programlarımızı diğer makinelere taşınabilir hale getirmek için sanal makineler yarattık. Çöp toplama işlemi oluşturduk, böylece programcıların tüm zorlukları ortadan kaldıran hafıza yönetimi konusunda çok çalışkan olmaları gerekmeyecekti. Dillere sınır denetimi ekledik, böylece bilgisayar korsanlarının arabellek taşmasıyla onlardan yararlanamamalarını sağladık. İşlevsel Programlamayı, programlarımız hakkında farklı bir nedenden ötürü sebep olabilmemiz için icat ettik ve eşzamanlılıktan daha iyi yararlanmak için yakın zamanda yeniden keşfettik.

Bütün bu soyutlamalar sizi donanımdan izole ediyor mu? Tabii ki öyle. Çadır yapmak yerine bir evde yaşamak sizi doğadan izole ediyor mu? Kesinlikle. Fakat herkes neden çadır yerine bir evde yaşadığını biliyor ve bir ev inşa etmek çadır kurmaktan tamamen farklı bir top oyunudur.

Ancak, bunu yapmanız gerektiğinde hala bir çadır oluşturabilirsiniz ve programlamada (çok eğimli iseniz) hala donanıma ulaşamayacağınız performans veya hafıza avantajlarını elde etmek için donanıma daha yakın bir seviyeye düşebilirsiniz. Aksi halde, yüksek seviyeli dilinizde elde edin.

Çok fazla soyutlayabilir misin? Scotty'nin dediği gibi "sıhhi tesisat sollama " ? Tabi ki yapabilirsin. İyi API'ler yazmak zor. Sorunlu alanı doğru ve kapsamlı bir şekilde sezgisel ve keşfedilebilecek şekilde somutlaştıran iyi API'ler yazmak daha zordur. Yeni yazılım katmanlarına yığmak her zaman en iyi çözüm değildir. Yazılım Tasarım Kalıpları , bir dereceye kadar, bu durumu daha da kötüleştirmiştir, çünkü deneyimsiz geliştiriciler daha keskin ve daha yalın bir araç daha uygun olduğunda bazen onlara ulaşmaktadır.

Gerçekten iyi bir eğitim hem aşırılıkları hem de aralarında bir köprü var.

Alt kısımda: bir bilgisayar, montaj dili bilgisi ve bir derleyicinin ne yaptığı da dahil olmak üzere, sıfırdan * bir kodu nasıl yürütür.

Üst kısımda: genel kavramlar, örneğin kaputun altında nasıl çalıştığı konusunda endişelenmekle zaman kaybetmeden ortak diziler, kapaklar vb. Kullanma.

IMHO herkes dezavantajları da dahil olmak üzere her ikisiyle de deneyime sahip olmalı ve düşük seviye konseptlerden yüksek seviye konseptlere nasıl ulaşılacağının tadına bakmalıdır. İlişkisel dizileri seviyorum? Harika, şimdi bunları 1kB RAM'e sahip 50 cent'lik bir gömülü işlemcide kullanmayı deneyin. C kullanarak hızlı kod yazmak gibi mi? Harika, şimdi bir web uygulaması yazmak için üç haftanız var; zamanınızı C kullanarak veri yapıları ve bellek yönetimi ile uğraşarak geçirebilir veya zamanınızı yeni bir web çerçevesi öğrenerek geçirebilir ve birkaç gün içinde web uygulamasını uygulayabilirsiniz.

Karmaşıklık yönüne değin: Bugünlerde bunu yapmanın maliyetini net bir şekilde anlamadan karmaşık sistemler yapmanın çok kolay olduğunu düşünüyorum . Sonuç olarak, bir toplum olarak, zaman zaman bizi ısıran büyük miktarda teknik borç oluşturduk. Depremler gibi (sadece bir jeolojik fay yakınında yaşamanın bedeli, değil mi?), Sadece giderek daha da kötüleşiyor. Ve bu konuda ne yapacağımı bilmiyorum. İdeal olarak karmaşıklığı yönetmeyi öğrenir ve daha iyi oluruz, ancak bunun olacağını sanmıyorum. Sorumlu bir mühendislik eğitiminin, karmaşıklığın sonuçları hakkında, üniversitelerin çoğunun sağladığından çok daha fazla bir tartışma içermesi gerekmektedir.

* ve neyse, bir bilgisayarın kodu yürütme biçimindeki "toprak" nerededir? Assembly dili mi? Veya bilgisayar mimarisi? Veya dijital mantık? Veya transistörler? Veya cihaz fiziği?

Yüksek seviyeli programlamanın birçok avantaja sahip olduğunu ve programlama dilinin önemli bir parçası olduğunu düşünüyorum. Java'nın başarılı olmasının sebeplerinden biri, kapsamlı bir kütüphaneye sahip olmasıdır. Daha az kodla daha fazlasını elde edersiniz - önceden tanımlanmış bir işlevi çağırın.

Artık programlama dili kullanıcılarını programlama dili yazarlarından (derleyici yazarlar) ayırt edebiliyoruz. Optimizasyonları derleyici yazarlarına bırakıyoruz. Daha fazla bakım, yeniden kullanım, vb.

Sistemlerin karmaşıklığındaki artış amansız, baskıcı ve sonuçta sakattır. Eski nesil bir programcı olarak benim için de hayal kırıklığı yaratıyor.

40 yılı aşkın bir süredir programlama yapıyorum, 50-100 farklı dilde veya lehçede yazılı kod yazdım ve 5-10'da uzman oldum. Bu kadar çok hak iddia edebilmemin sebebi çoğunlukla tweaks ile aynı dilde olmaları. Tweaks, karmaşıklığı artırarak her dili biraz farklı kılıyor.

Aynı algoritmaları sayısız kere uyguladım: koleksiyonlar, dönüşümler, sıralama ve arama, kodlama / kod çözme, format / ayrıştırma, tamponlar ve dizgiler, aritmetik, hafıza, G / Ç. Her yeni uygulama karmaşıklık katar çünkü her biri sadece biraz farklıdır.

Web çerçeveleri ve mobil uygulamaların yüksek uçan trapez sanatçıları tarafından işlenen sihirleri, bu kadar kısa sürede nasıl çok güzel bir şey üretebileceklerini merak ediyorum. Sonra ne kadar bilmediklerini, veri veya iletişim ya da testler ya da iş parçacıkları veya ne işe yaramadıklarından önce ne olursa olsun öğrenmeleri gerekeceğini fark ediyorum.

Mesleğimi dördüncü kuşak diller çağında öğrendim, burada, yazma yazılımının tekrarlayan parçalarının giderek daha fazla ve daha fazlasını yakalamak için üst üste ve daha yüksek dillerin art arda üretileceğine gerçekten inandığımızı düşündüm. Bu tam olarak nasıl oldu?

Microsoft ve IBM, Windows ve OS / 2 için uygulamalar yazmak için C'ye dönerek bu fikri ortadan kaldırırken, dBase / Foxpro ve hatta Delphi ortadan kalktı. Ardından web, en son montaj dili üçlüsü ile tekrar yaptı: HTML, CSS ve JavaScript / DOM. Hepsi oradan yokuş aşağı oldu. Her zaman daha fazla dil ve daha fazla kitaplık ve daha fazla çerçeve ve daha fazla karmaşıklık.

Bunu farklı yapmamız gerektiğini biliyoruz. HTML yazmak zorunda kalmamak için CoffeeScript ve Dart, Less ve Sass hakkında, şablon hakkında bilgimiz var. Biliyoruz ve yine de yapıyoruz. Sızdıran soyutlamalarla dolu çerçevelerimiz var ve eğlenceyi gizlemiş olayları öğrenenlerin seçtiği birkaç kişi tarafından neler yapılabileceğini görüyoruz, ancak biz ve programlarımız geçmişte alınan kararlarla kapana kısıldık. Değiştirmek veya baştan başlamak çok karmaşık.

Sonuç, kolay olması gereken şeylerin kolay olmaması ve mümkün olması gereken şeylerin karmaşıklığı nedeniyle neredeyse imkansız olmasıdır. Belirlenmiş bir kod tabanında yeni bir özellik uygulamak için değişiklik yapmanın maliyetini tahmin edebilir ve haklı olacağımdan emin olabilirim. Tahmin edebilirim ama haklı çıkaramam ya da açıklayamam. Çok karmaşık.

Son sorunuza cevaben, genç programcılara mümkün olduğunca yüksek katman pastasından başlayabilmelerini ve sadece ihtiyaç ve arzuların ivme sağladığı için alt tabakalara dalmalarını şiddetle tavsiye ediyorum. Tercihim, döngüleri olmayan, çok az dallı ya da dalsız ve açık durumlu diller içindir. Lisp ve Haskell akla geldi. Uygulamada her zaman C # / Java, Ruby, Javascript, Python ve SQL ile bitirdim çünkü topluluklar burada.

Son sözler: karmaşıklık en büyük düşmandır! Bunu yendi ve hayat basitleşir.

Bununla birlikte sorum şu ki, insanlar düşük seviyeli elementlerin bu "gizlenmesi" hakkında ne hissediyorlar. Daha yaşlı programcılar bunu bir nimettir veya aşılması gereken gereksiz bir katman olarak görüyor musunuz?

Hiçbiri, gerçekten.

Katmanlama gereklidir, çünkü onsuz, sisteminizin sürdürülemez bir makarna haline geldiği bir noktaya ulaşırsınız. Aynı zamanda tekrar kullanılabilirliğin ilkelerinden biri: eğer bir kütüphanenin geliştiricisi iyi bir iş çıkarsa, kullanan kişilerin uygulamanın detaylarıyla ilgilenmesi gerekmemelidir. Sistemlerimizde kullandığımız korunmuş kod miktarı, 35 yıl önce ilk programımı yazdığımdan beri mangitude emriyle arttı. Bu büyüme, zaman geçtikçe daha güçlü şeyler yapabildiğimiz anlamına geliyor. Bu iyi.

Benim için sorun olduğu yer tamamen kültürel. Pragmatik yarım, artık aklımı her detayın etrafına sarmanın ve yapmak istediklerimi bitirmenin artık mümkün olmadığını anlıyor. (Yaşlanmak da işe yaramıyor.) Canavar bozarı kızıl saçlı yarım, üzerinde çalıştığım her şeyi bu kadar ince bir şekilde anlayabilmenin uzun zamanını bırakmakta zorlanıyordu.

Genç programcıların, geniş kütüphanelerin alanlarını keşfetmeden ÖNCE düşük seviyeli programlamayı öğrenmenin faydası olacağını düşünüyor musunuz?

Diğer cevaplarda da belirtildiği gibi, neofitlerin dikkatini çekmek ve korumak ile onlara en aşağıdan en iyi bir eğitim vermek arasında bir denge vardır. Eski olanı yapamazsanız, ikincisi olamaz.

Sektörümüzde toplumun geri kalanına paralel şeyler görüyorum. Neredeyse herkes kendi yemeğini yetiştirdi ve bunu yapmak için çok zaman harcadı. O zamandan beri, bu işi yapan çiftçiler olarak adlandırılan ve başkalarını topluma katkıda bulunan diğer şeyleri yapmakta özgürleştiren uzmanlar çimlendirdik. Yiyeceklerimi bir markette satın alıyorum ve gerekirse birçoğunu kendi başıma üretemedim. Çok daha sıkıştırılmış bir zaman ölçeğinde de olsa, devam eden benzer bir şeyimiz var. Programcılar bazı katmanlarda uzmanlaşmıştır, diğerlerinde değil. GUI'leri yazan ortalama bir adam, takas alanı gibi bir şey olduğunu biliyor olabilir ancak muhtemelen işletim sisteminin onu nasıl yönettiği hakkında pek bir şey bilmiyor ya da umursamıyor.

Tüm bunların sonucu, artık sadece kalkınma ile ilgili olmadığıdır. Sürekli uzmanlaşma, geliştiricilerin iletişim ve entegrasyon becerilerini geliştirmeye devam etmeleri gerektiği anlamına gelir.

Her şeyde olduğu gibi, biraz iyi olsanız da çok acıtır. Sorun çok fazla sistemin ne zaman duracağını bilmemesidir - sadece 1 soyutlama, daha hızlı programlamanıza yardımcı olmak için ... ama sonra işlerin istediğiniz kadar kolay olmadığı gerçek dünyada kodlama yaparsınız. Daha az özellikli bir soyutlama ile harcadığınızdan daha fazla zaman harcayın.

Ably burada tarif edilir

veya burada - "tek bir kod satırıyla, etki alanına 500 kullanıcı ekleyebilirsiniz" ...

Soyutlamalarınız sizden karmaşıklığı gizlemeye çalışıyor, fakat gerçekten tek yaptıkları o karmaşıklığı gizlemektir. Karmaşıklık hala orada, sadece üzerinde çok daha az kontrol sahibi olmanız - bu yüzden böyle bir durumla karşı karşıya kalıyorsunuz.

Genç programcılar, geniş kapsamlı kütüphanelerin alanlarını keşfetmeden ÖNCE düşük seviyeli programlamayı öğreniyor mu? Eğer öyleyse neden?

Sanmıyorum 'Alt katman' çalışmalarının düşüklüğünden haberdar olmanın faydası olduğu birçok durum var, örneğin;

• Katman üzerinde bir problemin hatalarını ayıklarken n, genellikle katman üzerinde ne olduğu göz önünde bulundurularak açıklanabilir n-1(örneğin, aşağıdaki katman). Bence katman 0 "transistör" olur, ancak transistörlerle ilgili bir sorunu açıklamak istiyorsanız, muhtemelen fizikten (örneğin ısı) bahsedersiniz, belki fizik gerçekten seviye 0'dır.

• Kodu optimize ederken (ne yazık ki) zaman zaman soyutlama seviyesini düşürmeye yardımcı olur, yani bir alt seviye katmanı açısından bir algoritma uygulamak. Ancak, derleyiciler oldu gerçekten senin için yapıyorum iyi eğer onlar aslında katılan tüm kodu bakın. Bu sebep son zamanlarda daha zayıf işlemcilere sahip olan ve "Watt başına performans" ın masaüstü sistemlerden daha alakalı olduğu mobil ve gömülü cihazların patlamasıyla daha popüler hale geldi.

Bununla birlikte, genel olarak, bilgisayarların bir şeyler yapmasını sağlamak (biraz yetersiz şekilde olsa bile), bu daha önce olduğundan çok daha fazla programcı olduğu anlamına gelir. Bu da “insan” faktörünü çok daha önemli hale getirdi: Robert Harvey'in cevabı , “insanlar sadece herhangi bir anda kafasında çok fazla bilgi tutabiliyor” demişti, ve bugünlerde bunun çok alakalı bir yanı olduğunu düşünüyorum.

Programlama dili ve kütüphane (yani API) tasarımında önemli bir motivasyon, insan beyninde işleri kolaylaştırmaktır. Bu güne kadar her şey hala makine koduna göre derlendi. Ancak, bu sadece hataya açık değil, aynı zamanda anlaşılması zor bir şey. Bu yüzden çok arzu edilir

• Yazdığınız programlarda, mantıksal hataları bulmanıza yardımcı olmak için bilgisayarın size yardımcı olmasını sağlayın. Statik tip sistemler veya kaynak kod analizörleri gibi şeyler ( Eric Lippert'in bugünlerde oldukça popüler bir programda çalıştığını duyuyorum ) bu konuda yardımcı oluyor.

• Bir derleyici tarafından verimli bir şekilde işlenebilir bir dile sahip ve iletişim niyet programcının diğer programcılar için daha kolay program üzerinde çalışma yapmak için. Saçma bir uç olarak, ingilizce olarak program yazmanın mümkün olduğunu hayal edin. Diğer programcılar, neler olup bittiğini hayal etmek için daha kolay bir zamana sahip olabilir, ancak yine de, tanımlamanın makine eğitmenlerine derlenmesi çok zor olacak ve bunun adı belirsiz. Yani bir derleyici understan ancak hangi bir dil gerek de anlaşılır.

Birçok (çoğu?) Derleyicinin hala çok genel amaçlı olduğu göz önüne alındığında, çok genel bir komut setine sahiptir. "Bir düğme çiz" talimatı veya "bu filmi oynat" yok. Bu nedenle, soyutlama hiyerarşisini aşağıya çekmek , sizi anlamak ve sürdürmek için çok zor olan programlar (derleme için önemsiz olsa da) ile sonuçlandırır. Tek alternatif, hiyerarşiyi yükseltmek ve daha fazla soyut dile ve kütüphaneye yol açmak.

“eski programcılar bu gibi yenilikleri bir nimettir veya soyutlamak için ek bir katman olarak görüyorsa ve neden böyle düşünebilirler?”

Lisede okuduğumdan beri, yaklaşık 34 yıl, Basic ve Z80 Assembler ile başlayarak, C'ye, çeşitli 4GL dillerine, Scheme, SQL ve şimdi çeşitli Web dillerine geçiyorum. Mesleğin ele aldığı sorunların kapsamı, ölçeği ve derinliği, özellikle 1990'lı yıllarda bu dönemde enflasyonist bir dönem geçirmiştir. Kütüphaneler, çerçeveler ve işletim sistemi hizmetleri gibi yapıların tümü, genişletilmiş sorun alanıyla birlikte gelen karmaşıklığa değinmek üzere olan çelişkilerdir. Onlar bir nimettir, ne de kendileri için bir yük değil - sadece geniş bir çözüm alanının keşfedilmesi.

Ancak, IMHO, "inovasyon", yeni formlar açısından daha iyi anlaşılmakta ve yanlara doğru hareketle yanılmamakta, daha önce de tanıttığımız formları yeniden sunmakla karıştırılmıyor. Bazı açılardan, bir ekosistemin doğası, ilkel biçimler oluşmadığında, evrimde erken alınan kararları belirlediklerinde veya kendi titizliklerini yeniden işleyemediklerinde acı çeker. Odaklı kaldığımız yapıların çoğu olmasa da, uzun vadeli değerlerin önemine dikkat edilmesine öncelik vermeyin. Değişmeye başladı - Servis Yönlendirme ve Etki Alanına Dayalı Tasarım gibi yaklaşımlar, örneğin köprü metni ve grafik tabanlı modellerden bahsetmiyoruz, örneğin manzarayı değiştiriyor. Herhangi bir ekosistem gibi, sonunda baskın formlar yeni formlara yol açacaktır; çeşitliliğe izin vererek en iyi şekilde hizmet ediyoruz,

“Genç programcılar, geniş kapsamlı kütüphanelerin alanlarını keşfetmeden ÖNCE düşük seviyeli programlama öğrenmek için daha fazla yararlanıyor mu? Öyleyse neden?”

İnsan dilinin birçoğunun unutulduğundan beri metaforlara dayandığını, bu nedenle bilimsel / sayısal bir okuryazarlık bakış açısıyla düşük seviyeli programlamayı öğrenmeyi desteklerken, ölçeğini ve kapsamını destekleyecek ilkelleri aramamızın daha önemli olduğunu savunurum. Sorunları, daha düşük ayrıntı seviyesini güvenle göz ardı edebileceğimiz şekilde ele alıyoruz. Bir çerçeve ilkel değildir, ne de bir işletim sistemi ya da bir kütüphane değildir - gerçekten ihtiyaç duyduğumuz bir soyutlamayı yapmakta oldukça fakirdirler. Gerçek ilerleme, (a) neyin önceden gittiğini bilen ve (b) daha önce keşfedilmemiş veya keşfedilmemiş ve unutulmamış bir çözüm alanını keşfedecek kadar farklı bir şey bulabilecek kadar yeni bir roman düşünebileceklerini düşünecektir.

OTOH, amacınız bir teknisyen / mekanik seviye olarak çalışmak olsa bile, bir miktar düşük seviyeli programlama maruziyeti hala problem çözme becerilerinizi geliştirmek için yardımcı olacaktır.

İlk programım (15 yaşında bir genç olarak) 1974'te IBM 370/168 anabilgisayarı için delikli kartlarda PL / 1'de 1974 yılında yapıldı . Babam IBM'de çalışıyordu ve pazar günleri veri merkezine gidebilecek kadar şanslıydım.

O zamanlar, binlerce açıklama içeren bir program (ikipli kartlar) büyük bir programdı (ve ağır bir programdı, çünkü binlerce delikli kartın ağırlığı bir kilogramdı). Görsel arayüzler mevcut değildi ( //GO.SYSIN DD *IIRC ile başlayan delikli bir kart komutunu kullanarak "standart girişinden" okunan tipik bir program , ancak JCL'de ustalaşmadım ). Algoritmalar önemliydi ve IIRC standart kütüphanesi bugünün standardına göre oldukça küçüktü.

Bugün, birkaç bin çizgiden oluşan programlar genellikle küçük kabul edilir. Örneğin, GCC derleyicisinin on milyondan fazla kaynak kodu satırı vardır ve hiç kimse bunları tam olarak anlamıyor.

Benim düşünceme göre bugün programlama, 1970'lerden oldukça farklı, çünkü çok daha fazla kaynak kullanmanız gerekiyor (özellikle mevcut kütüphaneler ve yazılım çerçeveleri). Ancak, veri merkezi yazılımı geliştiren kişilerin (örneğin Google’daki arama motorları) veya bazı gömülü yazılımların, 1970’lerin ortalama programcısından daha fazla algoritma ve verimlilikle ilgilendiğini tahmin ediyorum.

Düşük seviyeli programlamanın anlaşılmasının bugün bile önemli olduğunu düşünüyorum (çoğu programcı kendilerini dengeli ağaçlar, dikotomik olarak erişilmiş sıralı diziler vb.

1970'lerle bugün arasındaki en büyük fark, geliştiricinin (insan) çabaları ile bilgisayar gücü arasındaki maliyet oranıdır.