Düşünme Aracı Olarak Notation (1979)

 (jsoftware.com)
1 puan yazan GN⁺ 2025-04-26 | 1 yorum | WhatsApp'ta paylaş
  • Notation (Gösterim), düşünmeye yardımcı olan önemli bir araçtır ve hem matematikte hem de programlama dillerinde merkezi bir rol oynar
  • APL dili, matematiksel gösterimin avantajlarını programlama dilinin çalıştırılabilirliği ve evrenselliğiyle birleştirme girişimi olarak geliştirildi
  • İyi bir gösterimin özellikleri arasında yalınlık, açıklık, çağrışımsallık, ayrıntıların alt düzeye indirgenmesi ve biçimsel olarak ispatlanabilirlik yer alır
  • Çeşitli matematiksel yapılar (polinomlar, dönüşümler, grafikler vb.) APL ile verimli biçimde ifade edilip dönüştürülebilir
  • Gösterimin tanıtılması ve öğrenilmesi, bağlam içinde doğal biçimde gerçekleşmelidir; gösterimin yapısallığı ve genelliği de önemlidir

Düşünme Aracı Olarak Gösterim

  • Kimya, botanik gibi bilim alanlarında da sistematik adlandırma, disiplinlerin gelişimini hızlandırır
  • George Boole, dilin kendisinin bir düşünme aracı olduğunu vurgulamıştır
  • Matematiksel gösterim, düşünmeyi destekleyen dilin temsilî örneklerinden biridir; düşünme yükünü azaltır ve düşünme gücünü artırır
  • A.N. Whitehead ve Charles Babbage, matematiksel gösterimin önemini vurgulamıştır

Programlama Dillerinin Düşünme Aracı Olarak Potansiyeli

  • Programlama dilleri, genellik ve açıklık gibi güçlü yönlere sahiptir
  • Bilgisayar aracılığıyla fikirleri denemek ve açık düşünce deneyleri yapmak mümkündür
  • Ancak çoğu programlama dili, matematiksel gösterime kıyasla düşünme aracı olarak daha zayıf kalır
  • APL, açıklık ve kesinliği hedefleyerek düşünmeyi destekleyen bir gösterim olarak tasarlanmıştır

İyi Bir Gösterimin Başlıca Özellikleri

  • Problemi ifade etme kolaylığı: Problemin doğrudan türettiği yapılar kolayca ifade edilebilmelidir
  • Çağrışımsallık: İfade edilen biçim, benzer ya da genişletilmiş problemleri ima edebilmelidir
  • Ayrıntıların alt düzeye indirgenmesi: Karmaşık ayrıntıları sadeleştirerek düşünmeyi destekleyen bir yapı sağlamalıdır
  • Yalınlık: En az sayıda sembol ve kuralla geniş bir ifade alanı sunabilmelidir
  • Biçimsel olarak ispatlanabilirlik: Gösterim, biçimsel ispat ve tümdengelimli akıl yürütmeye elverişli olmalıdır

APL'nin Temel Gösterim Tekniklerine Giriş

  • Vektör, matris gibi dizi tabanlı yapıları doğal biçimde kullanır
  • Fonksiyonlar ve işleçler, vektör/matrislere öğe bazında otomatik uygulanır
  • Redüksiyon(/), scan(\) ve iç çarpım(.) gibi işleçlerle fonksiyon bileşimleri ifade edilir
  • ⍳, ⌽, ⍴, +, ×, * gibi temel sembollerle zengin ifadeler kurulabilir
  • Tüm fonksiyonlar sağ öncelik kuralını izler; böylece parantezsiz doğal ifadeler yazılabilir

Problem Çözme ve Düşünmeyi Teşvik Eden Örnekler

  • Üçgensel sayılar, faktöriyel gibi matematiksel diziler basit formüllerle ifade edilebilir
  • Polinomların gösterimi ile çarpma, türev alma gibi işlemler tutarlı kurallarla özlü biçimde ele alınabilir
  • Grafik kuramı (ağaçlar, geçiş kapanışı, kapsayan ağaç) da dizi işlemleriyle açık biçimde ifade edilebilir
  • Permütasyonlar, Boole cebiri, sayı sistemleri dönüşümü (asal çarpanlara ayırma) gibi çeşitli alanlara genişletilebilir

Biçimsel İspat ve Yapılandırılmış Düşünce

  • Tüm işlemler ve ifadeler açıkça çalıştırılabilir biçimde yazıldığından bilgisayar aracılığıyla otomatik doğrulama mümkündür
  • Matematiksel tümevarım, tam arama ve özdeşliklerin listelenmesi yoluyla çeşitli biçimsel ispat örnekleri sunulur
  • Redüksiyon ve scan'in bölünme özelliği (identity) ile iç çarpım işleminin birleşme ve dağılma özellikleri biçimsel olarak ispatlanır
  • Newton simetrik fonksiyonları ile polinom çarpımı ve türev formülleri doğrudan ispatlanır

APL ile Geleneksel Matematiksel Gösterimin Karşılaştırılması

  • APL, fonksiyonların açık tanımını, tutarlı dizi işlemlerini ve zengin bir sembol sistemini sunar
  • Tüm işlemlerde öncelik kuralları yerine sağdan sola yürütme kuralı uygulanır
  • Matematiksel sembol kullanımındaki karmaşıklığı azaltır ve biçimsel işleme (formal manipulation) destek sağlar
  • Sözdizimi yalındır, kurallar tutarlıdır; bu da hem yeni başlayanlar hem de uzmanlar için avantaj sağlar

Gösterimin Tanıtılması ve Öğrenilme Yöntemi

  • Ayrı bir "dil dersi" olmadan, bağlam içinde gerekli gösterimlerin doğal biçimde tanıtılması yaklaşımı vurgulanır
  • Yeni semboller somut problem bağlamlarında sezgisel olarak öğrenilir
  • Önemli olan, gösterimin zorluğundan çok onun ima ettiği farklı olanakları ve genişletilebilirliğini fark etmektir

APL'nin Genişletilebilirliği ve Öneriler

  • Karmaşık sayı işlemlerini kapsayacak fonksiyon genişletmeleri önerilir
  • Unique elements ve summary fonksiyonlarının standartlaştırılmasına ihtiyaç vardır
  • Daha genelleştirilmiş işleçlerin eklenmesiyle vektör hesabı gibi ek konular da desteklenebilir
  • Hedef, dil tasarımında açıklığı ve akıl yürütme kapasitesini artırmaktır

Verimlilik ve Açıklık Arasında Denge

  • Önce açık ve analiz edilebilir bir gösterim tanımlanıp ardından optimizasyonla verimliliğin artırılması önerilir
  • Algoritmanın berraklaştırılması, daha sonraki optimizasyon ve derleyici iyileştirmelerine de yardımcı olur
  • APL ile yazılan temel ifadeler, hem akademik araştırmaya hem de endüstriyel uygulamalara katkı sağlayabilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-04-26
Hacker News yorumları

  • Notasyonu, shell genişletmesi gibi “bir ifadeyi başka bir ifadeyle değiştirmek” düzeyinde görmek kolaydır; ama gerçekte çok daha derindir.
    Hocam, büyük keşiflerin çoğu zaman yeni bir notasyonla birlikte ortaya çıktığını anlatmıştı; yeni notasyon, “bu problemi düşünmenin yeni bir yolu” anlamına gelir.
    Günümüzdeki birçok çözülmemiş problemin de güçlü bir notasyon ortaya çıktığında çözülebileceğini düşünüyorum.

    • DSL/dil odaklı yaklaşım, önce problem alanına doğrudan uyan bir notasyon oluşturur, sonra uygulamayı düşünür.
      Bu gerçekten güçlüdür ama Lisp tarzına daha yakındır; APL ya da Clojure tarzı ise temel tipleri gerçekten kullanışlı hâle getirmeye yöneliktir.
      10 veri yapısının her birine 10’ar fonksiyon koymak yerine, 1 veri yapısına 100 fonksiyon koyma yaklaşımıdır; bu yüzden APL’de DSL oluşturmak yerine veriyi çok dikkatli tasarlayıp yerleştirdiğinizde geri kalanı yerine oturur.
    • Notasyon, fikirleri keşfetme biçimini etkiler.
      Richard Feynman, gençliğinde trigonometri öğrenirken sinüs ve kosinüs notasyonunu beğenmediği için formülleri basitleştirmek ve gürültüyü azaltmak amacıyla kendi matematik sembollerini oluşturmuştu.
      Sonrasında da Feynman diyagramları veya slash notation gibi örneklerle, fiziği düşünme biçimini ve ifade etme biçimini birlikte yeniden kurdu.
    • Düşüncenin ekonomisi ve ergonomisi gibi bir şey var.
      Küçük bir örnek olarak CoffeeScript çıktığında, lambda kısaltmaları ve çeşitli sözdizimi kolaylıkları sayesinde JavaScript kullanma biçimi ciddi ölçüde değişmiş; düşünmesi, okuması ve düzeltmesi daha kolay hâle gelmişti.
      SML/Haskell ve Lisp ailesi de benzer hissettiriyor.
    • Matematik nihayetinde sembolleri oradan oraya manipüle etme işidir.
      Brian Greene ve Barry Mazur’un şu kısa klibi de hoşunuza gidebilir: https://youtu.be/8wQepGg8tHA

  • Tarihsel olarak APL’i gerileten şey, tuhaf klavyelerin yanı sıra IBM’in Lotus 1-2-3’ü ve hemen ardından gelen MS Excel oldu.
    Mühendislerin, akademinin, muhasebecilerin ve MBA’lilerin TI-59 ya da HP-12C’den daha iyi araçlara ihtiyacı vardı; bilgisayar bilimi tarafı ise sembolik işlemeye, yapay zekaya ve LISP’e odaklanmıştı ve sonunda sektör bu boşluğu doldurdu.
    APL’in elektronik tablolardan çok daha büyük bir etkisi olabileceği ve çok daha fazla problemi çözebileceği düşünüldüğünde talihsiz bir tesadüf.

    • APL’in acilen bir Rönesansa ihtiyacı var.
      Asıl vizyon, elle yazılabilen, tutarlı ve çalıştırılabilir bir matematik notasyonuydu; ama bu hiçbir zaman tam olarak başarılamadı.
      İlginizi çekerse şu yazı okunmaya değer: https://mlajtos.mu/posts/new-kind-of-paper
    • Anladığım kadarıyla Dyalog, derleyiciyi bir işletim ortamına koyana kadar ücretsiz sunuyor.
      Para ödemeden problem çözebiliyorsunuz; derlenmiş sonucu ücretli müşterilerin önüne dağıttığınızda maliyet doğuyor.
      Çözüm belirli bir alt kümeye uyuyorsa April’e taşıyıp Common Lisp üzerinden sunma yoluna da gidebilirsiniz.
      Ancak APL tarafındaki insanlar genellikle çok akademik; mühendislik işlerini hızlı ve özlü biçimde çıkarabilirler, ama ortalama bir yazılım şirketinde fonksiyon sıralaması ya da Naperian functor’lardan söz açarsanız, iş arkadaşlarınız tıbbi yardıma ihtiyacınız olup olmadığından şüphelenebilir.
      Yazılım geliştirmenin önemli bir kısmı, müşterilerin ve kullanıcıların konuşma ve düşünme biçimini ifade eden, bir ölçüde biçimsel bir teknik dil icat etmektir; Iverson ailesi dillerde bunu yapmak kolay değildir.
      Java uzun süre her metoda hangi iş terimlerinin girip çıktığını açıkça yazdırdı ve bu bakımdan organizasyonun kavramlarını koda eşlemek kolaydı.
      APL’de de veri ve fonksiyon adları verilebilir; ama uzun adları ve ad alanı yapılarını getirip dış organizasyonu koda eşlemeye başladığınız anda kısalık ve zarafet kaybolur.
      ML ailesinin incelikli tip sistemlerinde bile geliştiriciler, icat edilmiş yarı-dilsel ontolojiyi organizasyon ve süreçlerle doğrudan bağlamakta zorlanır; daha sık matematiksel ya da akademik kavramları seçerler.
      İkisini birden yapabilen biri varsa mümkün olur; ama çoğu zaman müşteri dünyasına çeviri tarafında iyi olmak bile yeterlidir.
    • APL, genel eğitim müfredatında öğrenilen herhangi bir dilden çok farklı bir sembolik dil olduğu için, elektronik tablolara kıyasla benimsenmesi kaçınılmaz olarak sınırlı kalır.
    • İronik biçimde, ilk elektronik tablo olan APLDOT APL ile yazılmıştı.

  • The Array Cast geçen yıl Iverson’ın 1982 tarihli röportajını yeniden yayımladı: https://www.arraycast.com/episodes/episode92-iverson
    Oldukça ilginç ve Turing konuşmasına göre daha erişilebilir sayılır.
    1979’daki APL, bugünkü gibi tuhaf ve uçta kalmış bir dil değildi.
    O zamanlar programlama dilleri bugün olduğu gibi dünya çapında kitlesel bir olgu değildi; neredeyse hepsi tuhaf ve uçtaydı, C de o dönemde oldukça yeniydi.
    Biraz hoşgörülü bakarsanız APL, yoğun C’den çok da uzak olmayan bir soyutlama gibi görünür; diziler üzerinde pointer manipülasyonunu doğrudan uygulamadan bilgisayarı programlamayı sağlıyordu.

    • 1979’da birçok lise matematiği APL ile öğretiyordu.
      Matematiği APL [1] ya da J [2] sözdizimiyle öğreten epey ders kitabı da var.
      Iverson aslında APL’i matematik için daha iyi bir sözdizimi olarak kullanmıştı; programlama uygulaması birkaç yıl sonra geldi.
      [1] https://alexalejandre.com/about/#apl
      [2] https://code.jsoftware.com/wiki/Books#Math_for_the_Layman
    • Dünyada gerçekten tuhaf derecede dar konulu o kadar çok podcast var ki hep şaşırıyorum.
      Eskiden, artık yayında olmayan bir tip teorisi podcast’i dinlemiştim; son derece anlaşılması güç bir içerikti.

  • Temel kavram, başka yararlı kavramlarla bağlantılı
    Sapir-Whorf hipotezi de benzer; tersinden düşününce daha da ilginçleşiyor
    Kusursuz olmayan bir dilde düşünülemeyen ya da düşünmesi zor olan şeyler vardır; öyleyse kullandığımız dille ifade de edemediğimiz, üzerine düşünemediğimiz şeyler olup olmadığını sormaya başlarız
    Burada “dil” ve “düşünce”yi normalden daha geniş anlamda ele almak mümkün
    Örneğin toplumsal etkileşim kuralları, nasıl etkileşime girdiğimizi belirler mi? Zeynep Tufekci, “Twitter and Teargas”ta Twitter’ın flash mob’ları mümkün kıldığını ama kalıcı toplumsal değişimi zorlaştırdığını söyler
    Birini takip etmek, yorum yapmak ya da beğenmek gibi toplumsal mekanizmalar, birbirimizle etkileşme biçimimizi belirler ya da mümkün kılar mı? Başka mekanizmalar daha iyi kolektif düşünmeyi mümkün kılabilir
    Müzik de var. Notasyondan değil; müzik, başka yollarla iyi ifade edilemeyen bir şeyi ifade eder mi?

    • Daha az kusursuz dillerde bazı düşüncelerin zor olması değil, en başta o düşüncenin akla gelmeyebilmesi söz konusu
      Birkaç yabancı dil öğrenmiş biri olarak, yalnızca belirli bir dilde düşünebildiğim ve ana dilim İngilizcede düşünmesi zor olan pek çok şey var
      Örneğin Ukraynaca ve Rusçadaki “гулять”, İngilizcenin yakalayamadığı pek çok anlam taşır; bu dilleri öğrenmeden önce bu anlamları hiç düşünmemiştim
      “Гулять” kelime anlamıyla “yürümek”tir, ama cinsel deneyimler de dahil olmak üzere deneyimlerin peşinden gitmek anlamında da kullanılır
      Birinin çok erken evlendiğinden yakınırken “не нагулялся”, yani “yeterince yürüyemedi” denebilir
      İngilizcede “sow his wild oats” gibi benzer ifadeler olsa da, “yürümek” fiilinin tek başına bu kadar çok anlam taşıması, hayatı yürüyerek kat etme düşüncesini baştan değiştirir
      Arapça öğrendiğimde de yalnızca o dilde ortaya çıkan pek çok anlam ve düşünce vardı; bunları İngilizceyle açıklamak imkânsız olduğundan değil, kısa ve öz ifade edecek bir notasyon olmadığı için uzun metinler gerekir
    • Metaforlar ve analojiler de benzer bir ruha sahip
      Kimi insanlar dil aracılığıyla başka düşüncelere yolculuk etmeyi sever, kimileri ise bu olasılık karşısında donakalır
      Her zaman olduğu gibi başarı denge ve iki tarafın da varlığındadır

  • Matematikçiler ya da bilgisayar bilimciler için son derece bariz bir gerçek olmasına rağmen, bu fikir dilbilimciler ve “eğitimciler” arasında oldukça tartışmalı
    Dilbilimsel benzeri Sapir-Whorf hipotezidir; hangi dili öğrendiğinizin düşünme biçiminizi belirlediğini ileri sürer
    Doğal dil kültürel bir nesnedir ve kültürleri zayıf bir kısmi sıralamayla bile eşlemek akademide neredeyse tabu sayılır
    Eğitim açısından da büyük sonuçları var; öğrenciler, karşılaştıkları problemler üzerinde gerçekten akıl yürütmelerini sağlayacak notasyonları öğrenemeyebiliyor
    Açıkçası bu kısmı pek iyi anlamıyorum

    • Sapir-Whorf, aynı fikri daha ilkel yapı taşlarıyla kurma olasılığını reddetmez
      Herhangi bir dili konuşan kişinin aynı matematiği ya da bilgisayar programını öğrenebilmesi bunu gösterir
      Sözlü ya da yazılı dilin düşünce için mutlaka gerekli olup olmadığı da şüpheli
      En azından dil olmadan da mümkün olan geniş bir düşünce alanı var; insanlar da bir zamanlar hiç konuşmuyordu ya da çok az konuşuyordu ve iletişim kurma düşüncesi ile niyeti sözcükleri ve dili yarattı
      Bu yüzden öğrenilmiş dili düşüncenin temel modeli olarak görmek tuhaf geliyor
    • Sapir-Whorf üzerine tartıştığım olmuştu; ortaya çıktığı bağlamı pek bilmiyorum ama insanlar kodlama fikrini tüm deneyime genişletmiş gibi görünüyor
      Örneğin bir toplum denizin rengiyle otun rengini aynı sözcükle adlandırıyor diye, bu iki rengin farkını deneyimleyemedikleri bile iddia edilebiliyor
      Deneyimi benzer biçimde belleğe kodladıkları anlamında değil, farkı göremedikleri anlamında
      Bir dilde olmayan sesleri hiç duyamadıkları iddiası da buna benzer
      Buradaki notasyon tartışması ise bundan çok, sözcük dağarcığının keşif için kullanılabileceği fikrine daha yakın
      Yalnızca bir ses duyduğunu değil, müzik duyduğunu ve belirli bir akor ilerleyişini vb. duyduğunu söyleyebilmek gibi

  • Şu anda APL ile bir proje geliştiriyorum
    Uzun süredir backlog’da bekleyen bir işti ama artık gerçekten kod yazıyorum
    İlgi duymaya başladığım zamanla tek satırlı ifadelerin ötesinde bir şeyler yazabildiğim zaman arasında epey uzun bir süre vardı
    Bu sürecin başlarında bu makaleyi keşfedip içine çeker gibi okudum; şimdi ise bu kavramlar düşüncemin tam anlamıyla temeli oldu
    Hatta bir mimarlık programında NAATOT öğretiyorum
    Yazılım mimarisinden değil, mimari tasarımdan söz ediyorum
    Iverson’ın özünü koruyacak şekilde düzenlenmiş bir sürüm kullanıyorum; gerçek matematik ve programlama kısmını ise yalnızca ana fikri gösterecek ve öğrencileri tasarım ile ifade araçlarının olanaklarını farklı düşünmeye zorlayacak kadar bıraktım
    Yani fikirleri biçimlendirme süreci, bunları kendine ve başkalarına ifade etme biçimi gibi konuları ele alıyor
    Daha gevşek ve açık uçlu bir programda fırsatım olursa, öğrencilerin mimari tasarım alanına uygulayacakları kendi sembol ve notasyon sistemlerini oluşturdukları bir ders yürütmeyi isterim

  • Eskiden yaptığım Freeform not uygulamasını bitirememiş olmama üzülüyorum
    SVG aracılığıyla bağımsız web sayfalarına derlenen bir uygulamaydı ve STEM alanlarında yaygın olan teknik içerikler için gerçekten harika bir fikir olduğunu düşünüyorum
    Eski kimya notu örneği burada: https://colbyn.github.io/old-school-chem-notes/dev/chemistry-1010---fall-2021/week-14-acids-and-bases.html

  • Birkaç yıl boyunca APL’e bir tür sihir gibi baktıktan sonra bu yılın başında zaman ayırıp öğrendim.
    APL ile tek bir tweet’e sığacak kadar inanılmaz fazla kod yazılabilmesi beni şaşırttı.
    Eğlenceli ama kullanması zordu.

    • Daha düşük ölçekte de olsa, yoğun NumPy kodu yazdığım her seferinde benzer bir şey hissediyorum.
      Yazdıktan sonra neredeyse her zaman “Bunu yazmak gerçekten bu kadar uzun mu sürdü?” diye düşünüyor ve başka bir araç mı kullanmalıydım diye sorguluyorum.
      Ama aslında başka bir aracın çok daha uzun süreceği sezgisel olarak pek oturmuyor.
      Zor ve zaman yiyen gibi hissettiren kısım, aslında problem tanımını daha sıkıştırılmış bir biçimde düzenlemeye zorlanma süreci.
      Daha dik ama çok daha kısa bir yolu tırmanmaya benziyor; daha yorucu hissettiriyor ama gerçekte daha az iş var.
      Bu yüzden APL’i öğrenip kullanmam gerektiğini düşünüyorum.
    • Paylaşılabilecek örnekler var mı merak ediyorum.

  • “Matematiksel gösterim evrensellikten yoksundur ve konuya, yazara ve bağlama göre farklı yorumlanmalıdır” şeklindeki makale öncülüne kişisel olarak katılmıyorum.
    Problemin görselleştirilmesinden ve ergonomiden kopuk gösterimlerin maliyetinin büyük olduğunu düşünüyorum.
    Bazı akademisyenler, karmaşıklığın büyük bölümünü gizleyerek “Eureka” türü kavrayışlar ya da beklenmedik eşdeğerlikler üretebilen gösterimleri tercih ediyor; ancak bazı durumlarda bu tam tersine bulanık ve hataya açık olabiliyor.
    Yine de düşünce sürecini aktarmada önemli bir araç olduğu doğru.
    Bir alan ya da yakın alanlar için yalnızca tek bir standart gösterim bulunmasının, akıl yürütme ve problem çözmenin yaratıcı, sanatsal ve keşifçi yönlerini epey bastırdığını düşünüyorum.
    Terry Tao’nun gösterimle ilgili harika bir açıklaması da var: https://news.ycombinator.com/item?id=23911903

    • Bu bana tipli programlama ile tipsiz programlama tartışmasını hatırlatıyor.
      Matematikte Lean, Coq gibi “enterprise” akıl yürütme sistemleri oluşturmaya yönelik çabalar var ve bu tür durumlarda evrensel bir gösterim sistemi makul.
      Ama kişisel keşif söz konusuysa, elde ne varsa uydurup kullanmak daha iyi olabilir.
      Kişisel olarak eğitimde bunu daha zor buldum.
      Cebir dersleri vb. sırasında, öğretmen gösterimle ilgili kişisel kararlarını ve tercihlerini tutarlı ya da açık sözlü biçimde ele almadığında zorlanıyordum; tip teorisi ve mekanik ispat teorisi çalışırken matematik becerim ciddi ölçüde gelişti.
    • Yazıda ele alınan sorun, bu çeşitli gösterimlerin aslında böyle bir karmaşıklığın hiç gerekmediği son derece temel şeyler için de kullanılması.

  • Makaledeki “ayrıntıların tabi kılınması” kavramının yeterince derinlemesine ele alınmadığını düşünüyorum
    APL uygulamalarını uzun süre okuyup yazdıkça, bu kavramın soyutlamadan temelden farklı bir karmaşıklık yönetimi biçimine işaret ettiğini fark ettim
    API’ler, kütüphaneler, modüller, paketler, arayüzler gibi soyutlama bariyerleriyle çevriliyiz; bunun sonucu da yüksek soyutlama kuleleri, API’leri birbirine yapıştıran geliştiriciler, donanımdan kopuş, performans üzerine akıl yürütmenin zorluğu gibi tanıdık sorunlar
    APL farklı bir yaklaşımı çok rahat hale getiriyor
    Soyutlama tasarlamak yerine, veriyi basit ifadelerle kolayca işlenebilecek şekilde özenle tasarlıyorsunuz
    Genelde kütüphane fonksiyonlarının ya da DSL terimlerinin olacağı yerde ilkel işlemleri doğrudan kullanmak gibi
    Örneğin bir string tablosu, anahtar dizisi ve değer dizisiyle vektör değerleri ve içselleştirilmiş anahtarları olan hashmap benzeri bir yapı kurup ekleme, çıktı alma ve silmeyi doğrudan APL ifadeleriyle ele alabilirsiniz
    Bu yöntemin iyi yanı, her ifadenin bir kara kutu olmaması; belirli ihtiyaçlara göre doğal biçimde ayarlanabilmesi
    Sıradan bir hashmap eklemesinde yeni anahtar ekleme kodu gerekir, ama burada mevcut anahtara yalnızca değer eklenebileceği ortak değişmezi kullanabilirsiniz
    Bir kütüphane API’si olsaydı kullanılmayan kod yolları, birden çok ekleme fonksiyonu varyantı ya da ölü kodu ortadan kaldırmak için incelikli tip çıkarımı gerekirdi
    Böyle bir yaklaşım, alanla ilgisiz kaygıların kod tabanına sızmasına yol açar
    Ayrıntıları gizlemek yerine tabi kılarsanız, gerektiği kadar alana özgü ayrıntıya erişebilir; ilgisiz ayrıntıları da ihtiyaç duyulana kadar arka planda sessizce bırakabilirsiniz
    Elbette APL ifadelerine çok aşina olmak gerekir, ama bunun Python ekosistemi gibi bir şeyi derinlemesine öğrenmekten çok daha büyük bir yük olduğunu sanmıyorum
    Pratikte APL sembolleri arka plana çekiliyor; İngilizce sözcükleri harf harf değil de sözcük ve söz öbeği düzeyinde okur gibi anlamlı söz dizimleri olarak görünmeye başlıyor

    • Kabaca yeniden ifade edersek, “her şeyi inline yapın” demek
      Çoğu dilde bu imkânsızdır, ama dil yeterince özlü ve ifade gücü yüksekse epey geniş bir ölçekte yeniden mümkün hale gelir
      Arthur Whitney’nin kaydırmaktan gerçekten nefret ettiği düşüncesi hep aklıma geliyor
      20 dosya açıp “tanıma git”in peşinden dolaşmaya da gerek yok
      Tüm program tek sayfaya sığdığında bunlar ortadan kalkar ve göz hareketleriyle gezinirsiniz
    • APL’nin tuhaf sözcüklerini seviyorum
      Cidden zaman ayırıp öğrenmem gerektiğini hissediyorum
      Son birkaç haftadır yaşadığım sıkıntılarla da derinden örtüşüyor
      Fazla sıkı bağlanmış legacy Python koduna bakıyorum; önceki tüm “iyileştirme” girişimleri, yanlış veri modelinin üstüne daha fazla soyutlama bindirmekten ibaretmiş
      Kodu doğrusal biçimde okuyarak hangi metodun girdi nesnesini değiştirdiğini anlayamıyorsunuz
      Bazıları değiştiriyor, bazıları değiştirmiyor; bazen de hiçbir değişiklik yapmadan aynı girdi argümanını olduğu gibi döndürüyor
      Aynı arayüzü bile paylaşmayan çeşitli hesaplayıcıları döndüren bir factory’nin oluşturduğu dolambaçlar denizindense, analiz edip anlayabileceğim sihirli string’leri tercih ederim
    • Bu, anlamlı bir açıdan hashmap değil
      Çünkü tüm işlemler O(n)
    • Bunu yapınca soyutlamanın karmaşıklığını fonksiyon kodundan veri yapısına taşımış olmuyor muyuz diye düşünüyorum
      Genel operatörleri kullanabilirsiniz, ama değer çiftlerinin alan mantığında ne anlama geldiğini ve her işlemde doğru yapıyı nasıl koruyacağınızı dikkatle anlamanız gerekir
      Programı ilk kez okuyan biri, ilkel işlemleri değil iş alanı anlamını anlamakta aynı ölçüde zorlanacaktır
      Bir iyileşme varsa, karmaşıklığı başka bir yere koyduğunuz için değil, kod ile gerçek değerlerin aynı anda görülebilmesi yüzündendir diye düşünüyorum
      Karmaşık programlamayı kolaylaştıran şey çalışma zamanı verisi ile kod işlemlerinin yan yana görülebilmesidir; bu yüzden IDE araçları da hata ayıklayıcıları ve inceleyicileri sürekli geliştirip programın her adımda ne yaptığını göstermeye çalışıyor
      Bu bağlamda, işlemlerin bir kısmını soyutlamak da veri yapısının bir kısmını soyutlamak da olsa, iyi ve özlü yeni soyutlamalar oluşturmak hâlâ iyi bir şeydir
    • “Doğrudan erişilebilir” ifadesi abartılı görünüyor
      Örnekteki ekleme kodunun büyük bölümü istenen ek işi değil, yorumlayıcının girdirmeye izin verdiği biçimi gereken biçime dönüştüren veri temizleme işi
      Asıl ekleme ⍪←; ↓⍉↑()()() ise APL’nin ve yorumlayıcı giriş ayrıştırıcısının sınırlarını aşmaya yönelik giriş ayrıştırma ve dönüştürmeye daha yakın
      Silme kodunda da 'buggy'yi iç içe dizinin tek bir öğesi olarak bulmak için sarmak gibi, problem alanıyla ilgisiz Boolean dizileri oluşturmak gerekiyor
      “Vektör değerlerinden oluşan bir hashmap yapmak” ifadesi de gerçek hashing olmadığı için yanıltıcı
      Yinelenen anahtar kontrolü yok, hash seçimi ya da hız ve dağılım ayarı mümkün değil; anahtarlar sırayla eklendiği için arama da yavaşlıyor
      Dyalog APL’de hızlı arama için diziyi dahili hashing hedefi olarak işaretleyen sihirli yorumlayıcı komutu I-Beam 1500 de var, ama dahili soyutlamanın sızdığını sürekli akılda tutmak gerekiyor
      “Başarı çukuru”, “tek bir yol olmalı”, “akla ilk gelen yöntem doğru yöntem olmalı”, “farklı işler farklı görünmeli” gibi dil ve araç tasarımındaki iyi fikirler APL’de eksik
      Python ya da C#’ta kv={'a':1, 'b':2} gibi sözdizimi doğrudan çalışır; parantez ya da iki nokta üst üste unutulursa açıkça yanlış görünür, editör ve derleyici yardımcı olur
      APL uygulaması girdi/çıktıda ⎕NGET, ⎕CSV, ⎕JSON gibi sihirli yorumlayıcı fonksiyonlarına dayanıyor; hata işleme, loglama ve debugging de zayıf
      İfadenin tamamı tek parça halinde çalıştırılıyor; hook ve fork’lar yüzünden kolayca parçalamak da zor
      Sonuçta çeşitli dizi şekillerini, ⊂3ün neden hiçbir şey yapmıyormuş gibi göründüğünü, ⊆ ile ⊂ arasındaki farkı, skaler genişletmeyi vb. doğru bir sezgiyle bilmeden deneme yapmak ve öğrenmek bile mümkün olmuyor
      “Anahtar varsa güncelle, yoksa ekle” gibi hemen erişilebilir bir kalıbı bile APL’de dallanmanın nasıl yapılacağından başlayarak yeniden düşünmek gerekiyor
      Python’da if/else ve key in map, C#’ta if/else ve map.Contains(key) ile geçilecek bir iş, APL’de temel işlevi yeniden uygulamayı düşünmeye dönüşüyor
      Aaron Hsu’nun iddiasına benziyor ama “itfaiye aracı” diyemeyip “yangını durdurma işini yapan kişinin arabası” demek zorunda kalınan Up-Goer 5 ya da Toki Pona gibi hissettiriyor
      [1] https://docs.dyalog.com/latest/CheatSheet%20-%20I-Beams.pdf
      [3] https://aplwiki.com/wiki/Scalar_extension

[4] https://xkcd.com/1133/