Yazılımın Emacs’laşması

 (sockpuppet.org)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Yapay zeka ajanları sayesinde birkaç saat içinde kişisel yerel uygulamalar yapılabilir hale geldikçe, yazılım Emacs tarzı özelleştirmenin alanına kayıyor
  • MDV.app, macOS için bir Markdown görüntüleyicisi; arama, SQLite FTS indeksleme, yer imleri, içindekiler ve konum hatırlamayı birkaç saat içinde hayata geçiriyor
  • Her Electron uygulamasının kendi Chromium kopyasını taşıması sorunu ve yerel UI geliştirmenin zorluğu büyük engellerdi, ancak Claude SwiftUI’yi ustalıkla kullanıyor
  • Emacs kültüründeki gibi, herkesin kendi sıkıntısını çözen aşırı spesifik araçlar artıyor; bitmiş üründen çok fikirlerin, gözlemlerin ve prompt’ların değeri büyüyor
  • Ajan destekli kodlama, yan projelere ve terminal araçlarına kullanışlı bir UI eklemeyi kolaylaştırıyor ve yerel UI üretimini eğlenceli bir işe dönüştürüyor

Markdown görüntüleyicisini neden kendim yaptım

  • Yazılım geliştirmede Markdown, LLM’lerden önce de ortak dil gibi kullanılıyordu; ajanlardan sonra TUI araçları yeniden çoğalınca terminalde Markdown’u durmadan kaydırarak okuma deneyimine katlanmak daha da zorlaştı
  • TUI Markdown görüntüleyicileri arasında Charm’ın glow ve Josh’un yaptığı Markless var; Markless içindekiler arasında gezinmeyi de destekliyor ama terminaller genelde eş genişlikli yazı tipi kullandığından uzun süreli okumada yorucu oluyor
  • macOS’ta Obsidian, Typora, Bear gibi grafik arayüzlü Markdown düzenleyicileri var ve okuması rahat, ancak hepsi birer düzenleyici olduğu için .md dosyasını açar açmaz mevcut düzenleme ortamı ve pencere yerleşimi bozuluyor
  • App Store’daki Markdown görüntüleyicileri ilk bakışta fena görünmese de pratikte aramanın olmaması, uygulama içi satın alma bulunması ya da seçilen metni panoya kopyalayamama gibi sorunlar ortaya çıkıyor
  • 2026’da uygun bir görüntüleyici aramayı sürdürmek yerine, istenen Markdown görüntüleyicisini yapay zeka ajanıyla üretmenin daha mantıklı olduğuna karar veriliyor

Claude ile yapılan MDV.app

  • MDV.app, App Store’da bulunan özel Markdown görüntüleyicilerinden daha iyi bir seviyeye birkaç saat içinde ulaştı; gerçek etkileşim süresi ise yaklaşık 30 dakikaydı
  • Eski bir MacBook’ta Xcode ve git kuruldu, Claude ortamı hazırlandı; Swift ve macOS tasarımıyla ilgili yardımcı kaynakları toplama hazırlığı ise haftalar öncesinden başlamıştı
  • MDV en iyi macOS uygulaması ya da olağanüstü yetenekli bir yazılım değil, ancak özel bir macOS Markdown görüntüleyicisi olarak fazlasıyla yeterli ve yaşam kalitesini ciddi biçimde artırıyor
  • MDV’nin başlıca özellikleri; belgede metin seçip kopyalama, sabit dizge araması, düzenlenebilir geçmişteki tüm Markdown dosyaları için SQLite FTS indeksleme, kısayol yer imleri ve içindekiler arasında gezinme
  • Belgeler arasında geçerken konumu hatırlıyor, yeniden başlatmadan sonra da kaldığı yerden devam ediyor; renk temaları ve rahat okunur tipografi sunuyor, böylece .md dosyasına tıklayınca istenen okuma ortamı hemen açılıyor

Electron’un sınırları ve yerel UI’daki değişim

  • Signal’den her mesaj geldiğinde ekran titriyor ve Signal uygulaması açıkça gizlenene kadar bu durmuyor; hafif titreme neredeyse migren öncesi bir seviyeye kadar sürüyor
  • Bunun nedeni Signal’in bir Electron uygulaması olması; dışarıdan yerel bir macOS uygulaması gibi görünse de gerçekte gizli bir web sayfasını işleyen bir Chromium kopyası çalıştırıyor
  • Son 10 yılda çıkan neredeyse tüm UI uygulamaları sanki kendi Chromium kopyasını taşıyor gibi ve Electron iyi olmasa da yeterince kabul edilebilir bir seçenek olarak ayakta kaldı
  • Gerçek anlamda yerel UI yapmak tarihsel olarak zordu; bunu emanet edecek ortalama seviyede insan bulmak bile güçtü ve yetkin macOS yerel UI geliştiricileri nadirdi
  • Claude, ortalama bir SwiftUI geliştiricisinin yerini doldurmanın ötesinde, gerçekten SwiftUI’ye hakim bir geliştirici gibi görünüyor

Emacs kültürünün yazılımın geneline sızma biçimi

  • MDV, kurulup kullanılması önerilen bitmiş bir ürün olmaktan çok, Emacs kullanıcılarının parlak bir .emacs yapılandırmasına bakıp fikir yürüttüğü gibi, fikir çalınıp daha iyisinin yapılacağı bir örnek olarak görülmeli
  • Emacs kültüründe uzun süreli kullanıcılar, metin düzenlemedeki kişisel rahatsızlıklarını çözmek için elisp ile uygulamalar yazar ve bu araçlar, bir metin düzenleyicinin makul sınırlarının ötesine genişler
  • /r/emacs, Product Hunt tarzı ürün tanıtımından çok bir gösterip paylaşma kültürüne benziyor; yaygın kullanılan elisp paketleri var ama Magit dışında çoğu şeyi herkesin kendi daha parlak sürümüyle yeniden yapma eğilimi baskın
  • Emacs kültürünün zayıf yanı, Magit dışındaki paketlerin genelde çirkin ve yavaş olması, ayrıca ancak elisp ile uzun süre uğraştıktan sonra fark edilebilecek kötü kullanıcı deneyimlerine sahip olmasıydı
  • Yapay zeka ajanları bu kültürü Emacs’ın dışına taşıdı; ekrana ve girdiye erişim olduğu sürece artık yerel UI güvenilir biçimde yapılabildiğinden, yerel UI profesyonelce paketlenmiş programların alanından çıkıp kişisel özelleştirme alanına kayıyor

Kişisel yerel araçların imkanı

  • Emacs’laşmış yazılımın çoğu, yalnızca onu yapan kişiye yarayan kişisel yazılımlar olacak ve .emacs içinde kalmış eski elisp programları gibi pek çok araç unutulacak
  • Bazen bu tür programlar kendi sınırlarını aşıp birden fazla kişinin kuracağı kadar yararlı hale gelebilir, ancak o durumda bile en önemli şey dağıtılan çıktı ya da kaynak kod olmayabilir
  • Eğer ajan SwiftUI kodunun tamamını yazdıysa, kaynak koda satır satır bakmaktan çok, “böyle bir şey yapılabiliyor ve iyi çalışıyor” şeklindeki fikir ve gözlem daha önemli hale geliyor
  • Bu tür yazılımlarda prompt kaynak koddan daha değerli olabilir; yazılımı doğrudan çalıştırarak üretmeye alışkın kişiler için her şey yalnızca teknik olarak değil, pratik olarak da programlanabilir hale geliyor
  • Ajanla üretilen yazılıma “inşa edildi” demek bile harcanan çabaya göre fazla iddialı görünüyor; his daha çok, bir anda çok daha yapılandırılabilir hale gelmiş bir platform üzerinde yapılandırma (configuring) yapmaya benziyor
  • Yapay zeka kullanan geliştiriciler, yıllardır biriktirdikleri rastgele yan projeleri sonunda bitiriyor
  • Artık bu kadar aşırı spesifik araçlar sadece tamamlanmakla kalmıyor, aynı zamanda kullanışlı bir UI da edinebiliyor; bu da Emacs’ın hantal arayüzüne katlanma gerekçelerinin bir kısmını zayıflatıyor
  • Terminal uygulamalarını çok daha kolay iyileştirme ihtimali büyüdü; iostat, birden çok host’a yayılan iostat ya da bpftrace gibi araçlar da daha anlaşılır biçimlere dönüştürülebilir
  • Brendan Gregg’in bpftrace terminal görselleştirmesi için katlanmak zorunda kaldığı karmaşıklığa artık eskisi gibi razı olmak gerekmiyor; hatta elle yapılmış bir örnek de var
  • Bir zafiyet araştırmacısı olarak 2026’nın ilk yarısındaki ajan destekli kodlamaya dayalı exploit geliştirme ilerlemeleri ilgi çekiciydi, ancak çoğu insan için bu değişim kaygı vericiydi; buna karşılık yerel UI yapmanın eğlenceli hale gelmesi neredeyse saf anlamda iyi bir haber
  • Kendi sorunlarına göre uyarlanmış aşırı derecede spesifik araçlar yapıp bir süre keyfini çıkarmaları, sonra da bunları paylaşmaları; daha da iyisi ekran görüntülerini ve kullanılan prompt’ları paylaşmaları öneriliyor

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News görüşleri

  • Bence artık ineklerin, bugün çoğunlukla önceden paketlenmiş uzman yazılımlar haline gelmiş alanları geri almasının zamanı geldi: podcast uygulamaları, müzik dinleme uygulamaları, feed okuyucular, Bluesky istemcileri, not uygulamaları, masaüstü yer imi/sonra oku uygulamaları, sohbet ve mesajlaşma, zaman takipçileri, tarif yöneticileri gibi şeyler
    Claude ile, mevcut alternatiflerden daha iyi sonuçları rahatlıkla elde edebilirsiniz. En iyi ya da dünya çapında rekabetçi uygulamalar olmayabilirler ama kendi tuhaf çalışma tarzınıza çok daha iyi uyan uygulamalar yapabilirsiniz
    Music.app kullanması acı verici bir uygulama ama Apple temel işlevleri zaten uzun zaman önce MusicKit’e çıkardı. Artık asıl ürün gerçekten MusicKit, bu yüzden neden hâlâ Music.app kullandığımızı bilmiyorum; bu da yeni bir değişim

    • Ortak nokta, veriye benim sahip olmam ya da en azından erişebilmem gerektiği. Şirketler içeriği sahiplenip erişim yollarını kontrol ettikleri kapalı bahçeler kurmayı seviyor, bu da böyle kişiselleştirilmiş arayüzleri imkânsız kılıyor. Umarım artık daha fazla zorlayıp bunu geri çevirebiliriz
    • Sosyal medya merkezsizleştirilmiş ve yerel öncelikli olmalı; ayrıca her işletim sisteminde özel istemciler yapılabilmeli
      Buna yönelik bir deney https://github.com/dharmatech/9social
      İlk istemciyi plan9 için yazdım; tasarım ancak böyle dürüst kalıyor. plan9/rc/acme üzerinde çalışıyorsa mantıklıdır
      Video demosu https://youtu.be/q6qVnlCjcAI ve mevcut uygulama 3000 satırdan az kod içeriyor
      Emacs demişken, 9social büyük ölçüde bir Emacs projesi olan Org Social’dan ilham aldı: https://github.com/tanrax/org-social
    • Şu anda gerçekten harika olacak şey, bir Mac geliştirici hesabı edinip türlü prosedürlerden geçmeden Claude’un yaptığı kişisel yardımcı uygulamaları telefonuma dağıtmanın bir yolu olması
    • Zaman takipçisi: https://repo.autonoma.ca/repo/timeivy
      Bu, zaman girmek için eksik bir spreadsheet tabanlı arayüz. Danışmanlık için yapmıştım ama veri depolama kısmına kadar gelemedim. İnsanların doğal biçimde zamanı girdiği neredeyse her yolu işleyebilen tatlı bir algoritması var; bunu, mevcut zaman takipçilerinin yapılandırılmış girişi dayatmasından nefret ettiğim için yaptım: https://stackoverflow.com/a/49185071/59087
      Tarif yöneticisi: https://repo.autonoma.ca/repo/recipe-fiddle
      LLM çağında malzemeleri sınıflandırmak ve PDF yayını için TeX’e biçimlendirmek çok daha kolay olacak. Bu projenin fikri, web tariflerini veya el yazısı taramaları neredeyse kopyala/yapıştır ile otomatik biçimlendirmekti
    • Davul çalışma parçalarını dinlemek için tek amaçlı bir Android müzik çalar yaptım. Çünkü ilk kez sık sık geri sarmam, hızı düşürmem, öğretmenimin WhatsApp’tan gönderdiği dosyaları açmam ve son çaldığım 4-5 şeye kolayca erişmem gerekiyordu
      F-Droid’da tüm bu koşulları karşılayan bir uygulama yoktu, ben de APK’yi kendim yaptım

  • LLM çağı sayesinde yazılım üretimi o kadar kolaylaştı ki bence her şey bir .emacs dosyası gibi oldu. Yani her birey tamamen kişisel ve sonsuzca özelleştirilebilir bir yazılım kozasına sahip olacak
    OP’nin ifadesiyle, mevcut bir şeyi kurup öğrenmektense kendi çözümünü yapmak daha kolay hale geldi
    Lisp de iyi bir benzetme. Lisp makrolarına yönelik eski bir eleştiri, her programcının işi kendi özel diline çevirip başkasının okuyamayacağı hale getirmesiydi
    Mark Tarver’ın 2007 tarihli “The Bipolar Lisp Programmer” yazısını da hatırlatıyor: https://hn.algolia.com/?query=comments%3E0%20The%20Bipolar%20Lisp%20Programmer&type=story&dateRange=all&sort=byDate&storyText=none&prefix
    Orada “brilliant bipolar mind” deniyordu; bu, bugün ironik ya da ciddi biçimde sık duyulan AI psychosis ile de ilginç biçimde kesişiyor
    Tarver’ın yazısında https://www.marktarver.com/bipolar.html Lisp topluluğunun “throw-away design” anlayışının BBM’ye tam uyduğu anlatılıyor. Lisp bir şeyleri gelişigüzel ortaya atmayı o kadar kolaylaştırıyor ki herkes kendi çözümünü yapıyor ve kendisine geri dönüyorsa bunun yeterli olduğunu düşünüyor
    Buna karşılık C/C++’ta anlamlı bir şey yapmak çok zor olduğu için bu başlı başına bir başarı oluyor ve belgeler hazırlamakla iş birliği yapma motivasyonu doğuyor. İşveren açısından iletişim kuran, dokümantasyon yapan ve birlikte çalışan 10 kişi; yerine koyması zor bir Lisp hacker’ından daha çekici
    Üretim kolaylaştıkça tüketim darboğaz haline geliyor ve paylaşmak zorlaşıyor. .emacs dosyaları parmak izi kadar kişisel; parçalarını alabilirsiniz ama bir başkasınınkini tümden kullanmak istemezsiniz
    Bu kozalar daha fazla özelleştikçe başkalarının onları anlaması ya da kullanmak istemesi daha da zorlaşıyor. Bilişsel maliyet büyük ama aynı zamanda başkasının kıyafetlerini giymek gibi rahatsız edici. Buna AI psychosis’ten çok AI solipsizmi demek daha doğru olabilir
    Yazılımda asıl zor kısım yapılandırma yönetimi haline geliyor. Kaynağı nasıl paylaşacağız, nasıl sürümleyeceğiz? Kaynak nedir? Prompt mu? OP de sonunda kod yerine ekran görüntüleri ve prompt’ların paylaşılmasından yana kayıyor
    Show HN’de de üretilen kodun artık kaynak olmadığı, bu yüzden prompt’ları paylaşmamız gerektiği yönünde bir deneme balonu uçuruldu ama bilen insanlardan ciddi tepki aldı: https://news.ycombinator.com/item?id=47213630
    GitHub’ın gördüğü baskı da muhtemelen bu akım yüzünden kaçınılmaz. Halefinin neye benzeyeceği belirsiz ama sonunda gerekecek. Şimdilik sessiz giden at arabası aşamasındayız gibi görünüyor
    Daha da önemlisi takım çalışması. Herkes BBM olursa ya da her birimiz sadece kendimiz için 7/24 üretim yapan çılgın BBM ordularına sahip olursak, birlikte nasıl çalışacağız? Kozalar birbirleriyle nasıl iletişim kuracak ve birlikte çalışabilir olacak? AI solipsistlerinden oluşan bir takım kulağa çelişki gibi geliyor
    AI odaklı, ajan tarzı geliştirmenin ön cephesindeki ekipler ve startup’lar bu sorunu şu anda gerçekten yaşıyor olmalı. Benim ürettiğim kodla seninkini nasıl birleştireceğimiz gibi meseleler. Bu sürtünme yüzünden, üretilmiş kodun verimlilik kazancının bir kısmı geri verilebilir
    Bunun henüz açık açık pek konuşulmaması üzücü. Kimse zorunlu ayakta alkış sırasında ilk oturan olmak istemiyor ama bunu bedelsiz bir öğle yemeği gibi göstermek tartışmayı sıkıcılaştırıyor ve evrimi yavaşlatıyor
    Yeni araçlarla en ciddi ve en ileri işi yapan insanlar eksilerini dile getirmezse, AI’ın yazılım geliştirmede değersiz olduğunu düşünen alaycı kesimden başka kimse bu eksilerden söz etmeyecek. İnsanlığın yok oluşundan ziyade hata sayısındaki artışı ya da verimlilikteki duraklamayı konuşmak daha zor bir atmosfer var
    Gerçekte neler olduğunu, insanların nasıl tepki verdiğini ve bunun zamanla nasıl değişeceğini bilmek istiyorum. Galiba meetup’lara gitmem gerekecek
    İlgili makalenin başlığı da “Easier to Write, Harder to Read” idi: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6726702

    • Bu durum, LLM tarafından üretilen düzyazı sorunuyla da benzer bir kader paylaşıyor. GPT 5.5 kötü yazılar yazmıyor olabilir ama bunun GPT 5.5 tarafından yazıldığını fark ettiğiniz anda beyniniz “ben bunu doğrudan GPT 5.5’e sorsam bana daha uygun bir cevap alırım ki” moduna geçiyor
      Neden LLM ile yapılmış belirli bir konuşmanın çıktısını okuyayım? Konuşma konusunu bilirsem, daha iyi bir konuşmayı kendim yapabilirim
      Bu tür yazılımlar da benzer. Biraz zevk farkı olabilir ama çoğu durumda önemli olan fikirler ve tarifler
      Aylık bir “Vibe HN” başlığı güzel olurdu
    • “Mevcut bir şeyi kurup öğrenmektense kendi çözümünü yapmak daha kolay” sözü abartılı görünüyor. WhatsApp birkaç on saniyede kurulabilir; bu yorumu yazmak daha uzun sürmüş olmalı
      Bundan daha kısa sürede özel bir WhatsApp yaptığını gösteren bir video paylaşılabilir mi merak ediyorum. Daha insanları anlık yapılmış bir mesajlaşma uygulamasına çekme sorununa bile gelmedik
    • Takım çalışmasının ne hale geldiği yönündeki tespitle aynı fikirdeyim. Eskiden ekipte pair programming ve grup programlama yapardık, bir de “Zoom office” vardı
      Şimdi ise “bu ticket’ı Claude’a vereceğim, sen de Copilot ile dene de sonuçları karşılaştıralım” ya da “ben kaba bir sonuçla PR açayım, sen kendi aracınla incele” noktasına geldik. Açıkçası bu neredeyse anlamsız hissettiriyor ve pair programming tamamen öldü
      Birden fazla ajan çalıştırıp farklı çalışma ağaçlarında sorun düzelten ve agents.md içindeki tutarsızlıkları onaran birini izlemek kimin hoşuna gider ki
      Kendi kendini işleten tam otonom bulut pipeline’ları kurma yönünde bastırıyoruz ama yönetim bunu sessizce bastırmaya çalışıyor gibi. Bunun gerçekten işe yarayabildiği kanıtlandığı anda bazılarının rahat pozisyonlarını kaybedeceğine dair basit bir farkındalık var sanki
    • Takım çalışmasına örnek olarak, programcılar ve araştırmacıların birlikte UNIX SYSTEM’i geliştirme biçimi verilebilir: https://www.cs.dartmouth.edu/~doug/reader.pdf
      UNIX bir ürün değil, araç yapmak ve gerçek problemleri çözmek için optimize edilmiş bir ortamdı; araçlar C ile yazılıyordu. O sırada BBM’ler Boston’da Lisp ile meşguldü herhalde
      C++ ise bambaşka bir hikâye; orada IDE gerekiyor
    • Lisp’e daha sıcak bakan bu görüşe büyük ölçüde katılıyorum. Okurken aklıma gelen yazı da kısa süre önce paylaşılan şu metindi: https://isene.org/2026/05/Audience-of-One.html

  • Emacs’in böyle bir niteliğe sahip olmasının sebebi Lisp kullanması. Programcıların her şeyi kendilerinin yapmaya başlaması şeklindeki genel eğilim Lisp’te gözlenmişti ve buna The Lisp Curse denmişti
    Buna lanet denmesinin sebebi, programcıların iş birliği yapmayı bırakması. Herkes kendi kulesine kapanmış bir büyücüye dönüşüyor, genel ilerleme duruyor ve karanlık çağ geliyor

    1. <https://www.winestockwebdesign.com/Essays/Lisp_Curse.html#main>

  • LLM çağı sayesinde kişisel yazılım üretildiği doğru
    Ama dürüst olmak gerekirse, Emacs kullanırken geçirdiğim zaman bana kişisel yazılım yapmayı öğretmedi. Emacs yapılandırmam son derece kırılgandı; bunu Windows ve macOS’ta birlikte kullanmaya çalışmak ise tam bir kâbustu
    Üniversite projelerini, org-mode ile bir tür iş akışını karıştırıp güzel LaTeX dosyaları üreten tuhaf bir düzenekle yazmıştım ama bugün bunu tekrar nasıl derleyeceğimi açıklayamam. Denesem muhtemelen LLM’e bunu doğrudan LaTeX’e çevirmesini söylerdim
    Hayatımda mümkün olduğunca az bakım işi olmasını istiyorum ve her şeyi kendim yapmak her zaman bu hedefle uyumlu olmuyor
    Bir NETFX uygulamasını Rust ile yeniden yazmışlığım var. Çünkü kurulumunun 20 dakika sürmesi sinir bozucuydu: https://github.com/bevan-philip/wlan-optimizer

    • 15 yıldır Linux, Windows ve macOS’ta aynı Emacs yapılandırmasını kullanıyorum. Dürüst olmak gerekirse bilgisayar hayatımdaki en iyi şey bu
    • “Hayatımda mümkün olduğunca az bakım işi olsun istiyorum” sözünün ne anlama geldiğini açıkçası pek anlayamıyorum
      Bir programcının gündelik işi; yerel, uzak, bulut veya gömülü bilgisayar sistemlerinin davranışını değiştirmektir. Gereksinimler değişir, kapsam kayar, problem alanı evrilir, birikim kaçınılmazdır
      Dil yığınları, veri türleri, biçimler, CLI ve web araçları, protokoller, paradigmalar, açık kaynak ile kapalı uygulamalar arasında sürekli geçiş yapmak zorundayız
      Bu yüzden sürekli uyum sağlamamız ve kendi kontrol düzlemimizi de değişime göre ayarlamamız gerekir. Buradaki öz otomasyondur. Küçük can sıkıcı şeylerin hepsi otomatikleştirilebilir ve otomatikleştirilmelidir. Bu, iş akışını durmadan dönüştürmek demektir; yani araçların sürekli bakımıdır ama acı veren reaktif bakım değildir
      Programcı olup da kendiniz için sürekli yazılım yapmak istememek bir yanılsamadır. Bu, restoranda ocağı açan ama evde bıçağa bile dokunmayan bir aşçı gibi olur
      Emacs, aşçının evdeki mutfağıdır. Bakımın; arızaları tamir etmek ve değişimi takip etmek gibi reaktif bir yanı, bir de anlayışınız geliştikçe araçları yoğurmak gibi üretken bir yanı vardır. Programcı ilkininkinden nefret etmeli, ikincisine ise çekilmelidir
      Emacs, araçlarla işin aynı mizacı paylaşması sayesinde üretken bakım için neredeyse benzersiz biçimde uygundur
      Emacs için “yapılandırmaya çok iş düşüyor” şikâyeti yaygındır ama bunun anlamı çoğu zaman “değer elde etmeden önce yatırım yapmak istemiyorum”dur. Bu uzun vadede akıllıca bir strateji değil. Emacs’i kariyer boyunca ve yaşam boyu toplam bakım yükünü azaltan genel amaçlı bir araç olarak görmek daha doğru
    • Eğer LLM kişisel yazılım yapmaya yetecek kadar iyiyse, bunu bakımını yapmaya yetecek kadar iyi değil mi demek oluyor?
    • “Araç yapmaya vaktim yok” diyen kişi, aslında araç yapmama lüksüne sahip olmayan kişidir

  • Emacs ya da VIM yapılandırmaları sadece metin dosyalarıdır; sıradan bir editörde açılabilir ve ihtiyaçlara göre düzenlenebilir, ayrıca neyin nerede olduğu bilinir. Benim VIM yapılandırmam 20 yıllık; sadece 1-2 yıl önce elle paket yönetimini bırakıp bir eklenti yöneticisine geçtim
    Burada gatekeeper da yok, bağımlılık da
    Buna karşılık bugünkü yöntem ya üçüncü taraf bir şirkete 20-200 dolar ödemeyi ya da yerelde çalıştırmak için epey güçlü bir GPU gerektiriyor; ayrıca bir metin dosyasına talimatlar yazıp istenen hale gelene kadar tekrar tekrar düzeltmeniz gerekiyor
    Bu da kendi kendine bağımlılık eklemek demek ve eğer insan incelemesinin zorlanacağı kadar dolaşık hale gelirse, bu bağımlılık güçlü bir bağımlılığa dönüşecek. İster pahalı bir GPU olsun, ister verileri hissedar memnun etmek zorunda olan bir şirkete yollamak olsun, fark etmiyor
    Bu ikisinin nasıl farklı olduğunu ve ödediğimiz gerçek bedelin ne olduğunu ayırt etmemiz gerekiyor

    • Yani sınırları çizen UI uygulamaları yapan insanlar dışında gatekeeper yok mu demek istiyorsun?

  • Kişisel yazılım, yani kişinin kendisi için program yazması fikri, 1960’lardaki ev tipi bilişimin asıl vizyonuydu
    PC tam olarak öngörülmemişti ama herkesin evinde bir bilgisayar terminali olacağı ve ihtiyaç duyduğu işleri yapmak için program yazacağı düşünülüyordu. Programlamanın herkesin öğrenebileceği kadar kolaylaşacağı hayal ediliyordu
    Henüz orada değiliz ama LLM sayesinde yaklaşıyoruz

    • Henüz gitmediğimiz yol, HyperCard, Visual Basic, Macromind Director ve Flash gibi şeylerin tam anlamıyla çiçek açtığı yön olurdu
      Yani uzman olmayanların, iyi tasarlanmış bileşenler ve kolay anlaşılır mecazlarla kurulmuş bir üretim ortamında ilginç yazılımlar yapabilmesi fikri. Tesadüfi ya da gereğinden fazla tasarlanmış karmaşıklık katmanları temizlenmiş olmalı
      Bu vizyonda da yazılım dikkatli mantıksal düşünme gerektirir ama bu düşünceyi çalışan koda dönüştürmenin külfeti çok daha azdır. Araç zinciri ve build sistemi kâbusu da yoktur
      Onun yerine çok güçlü modeller inşa edip karmaşık büyüleri bizim yerimize tekrarlayıp yeniden birleştirmelerini sağladık. Ama karmaşıklık hâlâ duruyor ve uzman olmayanlar için hâlâ opak
      Yine de LLM bu karmaşıklığın bir kısmını gidermeye yardımcı olabilir. LLM tarafından üretilen yazılımın, bireyler tarafından kolayca anlaşılabildiği ve doğrudan değiştirilebildiği bir yön hâlâ mümkün ve LLM dünyasıyla da güzel biçimde tamamlayıcı olabilir
    • Bilgisayar kullanmanın bir gün bilgisayarın benim için program üretmesini de içereceğini birçok arkadaşıma söyledim ama alay ettiler
      Bu bir yapılabilirlik meselesi değil; zamanlama meselesi ve bu da en fazla 10 yıl, büyük ihtimalle çok daha kısa. Kod yazmayı bilmeyen akrabalarım bile şimdiden böyle şeyler yapıyor
      Bu gelecekteki bilişim biçimi gerçekten çok güzel ve inanılmaz derecede güçlendirici bir yön
    • Kendimi zaten o noktaya gelmiş gibi hissediyorum. Her sorun çıktığında “bunun için bir uygulamayı vibe coding ile mi yapayım?” diye soruyorum
      Şu anki Swift uygulaması 15 bin satır; bunun 5000 satırı test, 10 bin satırı uygulama kodu. Neredeyse bitti ve ihtiyacım olanı yapıyor. 20 saat sürdü
      Swift’i hiç yapmamıştım; bunu kendim yapsaydım kişisel olarak 500 saat sürerdi diye düşünüyorum
    • Herkesin kendi özel uygulaması ya da dosya sistemi olursa ortak dosya biçimlerinin ortadan kalkmasından endişe ediyorum. Bu olursa taşıma ve iş birliği çok acı verici hale gelir
      Muhtemelen çoğumuz tembel olduğumuz için o kadar ileri gitmeyiz ama yine de düşünmeye değer
    • İleriye dönük olarak herkesin kendi aşırı uzmanlaşmış uygulamalarına sahip olması ya da aynı uygulama içinde farklı UI’lar ve görselleştirmeler kullanması daha büyük bir eğilim olacak gibi görünüyor
      Uygulama kavramının kendisi çok daha akışkan hale gelecek
      Bir uygulama dinamik bir dille yazıldıysa, kullanıcının kodu bizzat yeniden yazıp tamamen yeni özellikler eklememesi için bir sebep yok

  • Makalenin ana metniyle doğrudan ilgili değil ama terminalin neredeyse her zaman sabit genişlikli olması nedeniyle uzun yazıları okumayı yorucu bulma fikrine katılmıyorum. Kişisel olarak eş genişlikli yazı tipleriyle uzun metin okumak bana çok daha rahat geliyor

  • Yazar ilginç bir noktaya parmak basmış. Değişkenler şunlar: araç yapmanın zorluğu, yayımlamanın zorluğu, başkalarına sağladığı fayda, yayımlandığında getirdiği sosyal ödül ve bağımlılık eklemenin olumsuz teşviki
    Hazır bir çözüm bulmanın zorlaşma derecesi, birinin onu yapma maliyetiyle bir başkasının nasıl yayımlanacağını çözme maliyetine göre artar. Tersine, topluluk için ne kadar faydalıysa insanlar o kadar haber verir ve bulmak kolaylaşır
    Yapma zorluğu ile yayımlama zorluğu arasında büyük fark varsa, özellikle de yapmak çok daha zorsa, insanlar genelde bir şeyi yapıp sonra unutmaya eğilimli olur. Yayımlama tarafı düşükse, sorunlar için ortaya daha az çözüm çıkar
    İkisi de düşükse ve başkalarına sağlanan fayda ile sosyal ödül, bağımlılık maliyetinden yüksekse leftpad gibi durumlar yaşanır. NPM’deki birçok paket; yüksek fayda ve ödül, düşük bağımlılık maliyeti kombinasyonundan oluşur
    Emacs Lisp’te eskiden yapma zorluğu yüksekti ama şimdi düştü; öğrenme eğrisi aşıldıktan sonra yayımlama zorluğu da düşüktür. Fayda, ödül ve bağımlılık maliyetleri de hiçbir yönde çok yüksek değildir
    Bu da, bir aracın zaten var olup olmadığına bakmadan oturup onu yapma senaryosunu üretir. VSCode ya da eski Eclipse’te yayımlama zorluğu daha yüksek olduğu için durum farklıydı
    Sanırım benden daha genç biri bunu dünyaya bir makale konusu olarak sunacak

  • Bu yazı, LLM kodlamasının getireceği ama henüz tam gerçekleşmemiş bir değişimi ima ediyor. Acaba artık Electron/React Native’i bırakıp, LLM’in Figma, wireframe ve davranış tanımlarını her platform için gerçek yerel uygulamalara dönüştürmesini sağlayamaz mıyız?
    CRUD uygulamaları için API tanımlarıyla UI mockup’ları, hatta başka bir platformda zaten uygulanmış ekran görüntüleriyle bile epey ileri gidilebilir. Bunlar LLM’lerin iyi olduğu türden iyi tanımlanmış işler. Eşdeğerlik testleri de önemli ölçüde otomatikleştirilebilmeli
    “Belki bir gün Android’i de ekleriz” ya da “Mac/Linux kullanıcıları yeterince fazla değil” gibi bahaneler hâlâ geçerli olacak mı? iOS uygulamasında şifre sıfırlama gibi daha az kullanılan akışları uygulamayıp rastgele bir WebView açmak da hâlâ savunulabilir mi?
    Cihazın içinde azımsanmayacak miktarda mantık barındıran uygulamalarda bile, LLM Go veya Rust gibi cross-compile’ı kolay dillere yeniden yazma konusunda oldukça umut verici göründü

    • Evet, mümkün. Şu anda da mümkün ve gerçekten çok iyi çalışıyor
      Daha kışkırtıcı söylemek gerekirse, bu noktada neden SwiftUI öğrenesiniz ki? Çoğu iş için SwiftUI uzmanlığı, “Microsoft Word’ü çok derinlemesine öğrenmek” ile benzer bir kategoriye girdi
      Buna zaman ayıranlara saygım var ama ayırsanız da ayırmasanız da sonuç farkı milimetre düzeyine yakın
      Programlamanın tamamı için böyle düşündüğümü söylemiyorum. Sadece artık bazı dillerde uzmanlaşmanın gerekçesi çok daha karmaşık hale geldiğini düşünüyorum