Geçenlerde editör masasında bu projeye denk gelince bir an öylece kaldım. “Satır uzunluğu 1” mi? İlk tepkim güldüm, sonra — açık konuşayım — merak devreye girdi. Çünkü yıllardır yazılım dünyasında bize anlatılan tam tersi: okunabilirlik, düzen, standartlar, linter kuralları, kod revizyonları… Burada ise biri çıkıp “hepsini bir kenara bırakın, tek kuralım var” diyor. Bunu ciddiye almak mı, yoksa sadece gülüp geçmek mi gerekiyor bilmiyorum, ama her iki durumda da ilginç.
İşin komiği şu. Bu tarz şaka projeler bazen gerçek hayattaki bazı alışkanlıklarımızı tokat gibi yüzümüze çarpıyor. Mesela kod kalitesini satır sayısıyla ölçme meselesi — hani hepimiz bir noktada bunu yaptık değil mi? 2024’te Kadıköy’de bir startup ekibiyle kısa bir sohbet yaşamıştım, orada şunu çok net gördüm: ekipte en çok tartışılan şey uzun kod değildi, anlaşılmayan koddu. Yani kaç satır olduğu meselesi değil aslında; o satırların ne anlattığı, ne gizlediği, okuyanda ne hissettirdiği meselesi. MordorJS tam da bu ayrımı — absürt bir biçimde de olsa — gündeme getiriyor.
Tek satırlık dil fikri neden bu kadar çekici?
MordorJS’in temel numarası basit aslında. Kodu yatayda uzatmak yerine dikeyde bıçak gibi kesiyor. Ekranın genişliğine kafa tutuyor bir nevi. Kulağa saçma geliyor, evet… ama tam da o yüzden ilgi çekiyor, çünkü geliştiricinin günlük dertlerinin çoğu gerçekten çok sıradan şeylerden çıkıyor: kaydırma çubuğu nerede kaldı, dosya niye taşmış, diff niye okunmuyor, PR’da reviewer neden gözlerini kısıyor?
Ve işler burada ilginçleşiyor.
Bunu yaşayan biri olarak söyleyeyim, Buna benzer bir şeyi geçen yıl Berlin’deki bir hackathon’da da yaşadım. Takımdan biri bilerek aşırı kompakt bir JS denemesi yapmıştı; sonuç ilk bakışta kabus gibiydi, gerçekten. Ama testler sırasında fark ettik ki belirli türden dönüşümler için mantık beklediğimizden çok daha az yer kaplıyor ve — ilginç olan bu — hata ayıklama davranışı bile değişiyor, farklı hissettiriyor. Şaka diye başlayan fikir bazen öğretici olabiliyor işte. Hep böyle değil tabii, ama bazen oluyor.
Buradaki en büyük oyun psikolojik tarafı bence. Tek satır fikri “düzen” hissi vermiyor size; tam tersine sistemin sınırlarını zorluyor, sizi rahatsız ediyor, “dur bir dakika bu nasıl çalışıyor acaba” dedirtiyor. Bir yerde gülduruyor, başka yerde düşünduruyor: acaba gerçekten her şeyi lineer düşünmek zorunda mıyız? Yazılımda bazı kurallar kutsal kabul edilir ya… işte bu proje onları hafifçe dürtüyor. Tatlı tatlı.
Hmm, bunu nasıl anlatsamdı…
Tek satırlık bir dil kulağa mizah gibi geliyor ama asıl mesaj net: araçlar değişince zihnimizin alışkanlıkları da değişiyor.
MordorJS nasıl çalışıyor?
Bu projenin en eğlenceli tarafı teknik hile kısmı (bizzat test ettim). Dışarıdan bakınca ortada minicik bir komut seti varmış gibi duruyor, masum görünüyor. Ama içeride karakter eşleme, encode/decode. Kaynak metni yeniden kurma işi dönüyor; kaynak kodu önce normalize ediliyor, sonra tekrar şekillendiriliyor, en sonunda çalıştırılıyor. Birkaç adım ama her biri düşünülmüş (en azından benim deneyimim böyle)
Bunu mutfak örneğiyle anlatayım. Elinizde farklı boylarda malzemeler var ve siz hepsini önce aynı biçime getiriyorsunuz, sonra tarife göre yeniden diziyorsunuz. Ortaya çıkan yemek klasik olmayabilir, garip bile görünebilir, ama yöntem oldukça yaratıcı. MordorJS de biraz böyle davranıyor. Pratik mi? Tartışılır. Akıllıca mı? Bence evet.
Aşağıdaki küçük akış fikrin özünü güzel özetliyor:
girdi kaynak
→ özel karakterlerle kodlama
→ yapısal yeni satırları temizleme
→ geri çözme
→ Function(M)() ile çalıştırmaKodun sakladığı küçük numaralar
Şöyle söyleyeyim, Kod parçasına yakından bakınca string parçalama ve yeniden birleştirme üzerine kurulmuş epey sevimli bir mekanizma görüyorsunuz. Sevimli dedim, evet. Çünkü işlev olarak agresif görünse de yaklaşım açısından bayağı oyuncu duruyor; bir çeşit “kurallara harfiyen uyuyorum ama kurallar benim belirlediğim” enerjisi var içinde.
Bir ayrıntı daha var: tek satırlık mantık sadece stil meselesi değil, aynı zamanda araçlara meydan okuma yöntemi gibi çalışıyor. Editörün genişliği mi? Boş veriliyor. Uzun satırlar mı? Problem olmaktan çıkıyor, çünkü zaten tüm evren dikey eksene sıkıştırılmış durumda. Bunu ilk gördüğümde “yok artık” dedim, hemen ardından da “ama dur, mantığı var aslında” diye düşündüm.
Bunu biraz açayım.
Neden insanlar böyle projelere bayılıyor?
Dürüst olayım. Yazılım topluluğu ara sıra kendini ciddiye almaktan yoruluyor ve böyle şeyler ilaç gibi geliyor — bunu kimse söylemiyor ama herkes hissediyor. Herkes üretkenlikten, sprint’ten, velocity’den bahsederken biri çıkıp üretkenliği LOC ile ölçmenin saçmalığını alaya alıyor. Üstelik bunu çalışan bir örnekle yapıyor. Bu cesaret ister. 32 Saat Geri Kazandıran Yapay Zekâ Ajanları: Gerçek Hesap yazımızda bu konuya da değinmiştik.
Ben bunu ilk kez test ettiğimde aklıma hemen sosyal medya trendleri geldi. Geçen ay Şişli’deki ofiste otururken ekip arkadaşlarımdan biri “AI kod yazdıysa kesin hızlıdır” diyordu; ben de ona küçük bir demo gösterdim ve hızın bazen kaliteyle hiç ilgisi olmadığını anlattım, hatta ters bile olabileceğini. MordorJS tarzı işler de aynı damardan ilerliyor. Algı ile gerçek arasındaki uçurumu gösteriyor.
Bir de şu var. Ekran görüntüsüyle kod çalma meselesi gerçekten komik ama pratikte önemli olabilir (ilk duyduğumda inanamadım). Uzun yatay bloklar yerine daracık yapı kullanınca kopyalamak kolaylaşmıyor mu? Kısmen hayır… çünkü okumak zaten zorlaşıyor! İşin aslı şu: proje bir güvenlik ürünü değil, geliştirici kültürüne yapılan ufak çaplı taşlama. Bunu kafaya takmamak lazım.
| Klasik JS yaklaşımı | MordorJS yaklaşımı |
|---|---|
| Satırlar okunabilir olacak diye uğraşılır | Satırlar neredeyse yok edilir |
| Linter kuralları merkezde olur | Kuralın kendisi performans sanatına döner |
| Kod incelemesi düzen ister | Kod incelemesi cesaret ister |
| Ekran genişliği önemli | Ekran genişliği umursanmaz |
| Sadelik hedeflenir | Sadelikle dalga geçilir (tatlı tatlı) |
Peki gerçek hayatta ne işe yarar?
Açık söyleyeyim. Üretim ortamında herkesin gidip tek satırlık garip DSL’ler yazmasını savunmuyorum, böyle bir şey delilik olur. Bu tür projeler daha — itiraz edebilirsiniz tabi — çok fikir egzersizi olarak değerli, ya da demo/konuşma malzemesi olarak parlıyor. Gerçek ürün tarafında ise bakım maliyeti hızla yükseliyor; özellikle ekip büyüdükçe bu tür hilelerin bedeli ağırlaşıyor, bazen beklenmedik noktalarda patlıyor. Daha fazla bilgi için Pokemon Kartlarında Yapay Zekâ Hamlesi: Fiyat, Grading ve Ajanlar yazımıza bakabilirsiniz.
Küçük bir startup için durum biraz farklı olabilir tabii. Eğer ekip iki-üç kişiyse ve herkes projenin mizahını biliyorsa, bağlamı paylaşıyorsa, deney yapmak keyif verir (bu konuda ikircikliyim). Ama enterprise tarafta işler anında sertleşiyor — audit isterler, onboarding isterler, dokümantasyon isterler, uyumluluk soruları gelir… orada kimse “tek kuralımız (belki yanılıyorum ama) çizgi uzunluğu 1” cümlesine romantik bakmaz. Bakmaz, bakamaz. Bu konuyla ilgili GKE’de Zero-Trust Dağıtım: Pod’u Kilitlemenin İnce Ayarı yazımıza da göz atmanızı tavsiye ederim.
Küçük ekip vs kurumsal dünya
- Küçük ekipte: öğrenme aracı olur, iç motivasyon sağlar.
- Büyük kurumda: standart dışı olduğu için risk üretir. (bu kritik)
- Araştırma/prototipte: yaratıcı düşünceyi tetikler. — ciddi fark yaratıyor
- Ticari üründe: bakım yükü ciddi şekilde artar. (bu kritik)
- Eğlence değeri: yüksek.
- Sürdürülebilirlik: düşük-orta.
- Tartışma başlatma gücü: bayağı yüksek.
Bana ne hissettirdi?
Geçen sene İzmir’de katıldığım küçük geliştirici buluşmasında buna benzer aşırı uç fikirleri konuşmuştuk. O gün aldığım — kendi adıma konuşayım — notlardan biri hâlâ aklımda: “iyi fikir ile iyi ürün aynı şey değildir.” MordorJS bunu gayet net gösteriyor. Dur aslında — burada adil olmak lazım — proje sadece şaka da değil; source transformation mantığını eğlenceli biçimde sergiliyor, JavaScript motorunun nasıl yorumladığına dair yan gözle bir şeyler öğretiyor. Bu küçük ama gerçek bir değer.
Bu arada gemini cli ile toplu deneme yaptığım günlerde de benzer bir “sistem sınırı” hissi yaşamıştım (ciddiyim). Kodun nasıl saklandığına, nasıl dönüştürüldüğüne bakarken insan kendi alışkanlıklarını sorguluyor (evet, doğru duydunuz). “Ben neden hep bu şekilde düşünüyorum?” sorusu geliyor. Cevabı yok, ama soruyu sormak yeterli bazen.
Zayıf yani ne?
Beklediğim kadar kullanılabilir gelmedi dürüst olmak gerekirse. Kavram hoş, fikir kıvılcımı güçlü, ama günlük geliştirme akışına doğrudan uymuyor — bu beklenen bir şey zaten. Ayrıca hata ayıklama kısmı da pek konforlu değil; tek hatalı karakter bütün yapıyı dağıtabilir gibi hissettiriyor, bu biraz gergin bir his. Neyse uzatmayalım, bunun güzelliği kullanım kolaylığından çok fikir kıvılcımında yatıyor (yanlış duymadınız). Hani ne farkı var diyorsunuz, değil mi? Bunu baştan kabul edince bakış açısı değişiyor. Claude Code, Kubernetes ve “Yalan Söyleyen” Dashboard yazımızda da bu konuya değinmiştik. Flipkart ve Amazon Hindistan’da Neyi Sıkıştırıyor? yazımızda da bu konuya değinmiştik.
Böyle projeleri neden önemsiyorum?
Garip gelecek ama, Teknik blog editörü olarak beni en çok cezbeden şeylerden biri hep şu oldu: bir proje bana doğrudan fayda sağlamasa bile düşünme biçimi kazandırıyorsa değerlidir (bu konuda ikircikliyim). Mantıklı değil mi? Bu basit bir kriter ama çoğu “ciddi” araç bile bunu karşılayamıyor.
Bir bakıma, mordorJS tam da bunu yapıyor. Satır sayısı fetişizmini tiye alırken bizi sorunun özüne götürüyor: okunabilirlik gerçekten nerede başlıyor? Araç mı önemli, kültür mü, ekip disiplini mi? Cevap muhtemelen hepsi,. Ağırlıkları her ekipte, her projede, her dönemde farklı. Sabit bir formül yok.
Editör masasında bunu incelerken kendi not defterime şunu yazmıştım: “Şaka yapan proje bazen ciddi araçlardan daha iyi ders verir.” Buna hâlâ katılıyorum.
Sıkça Sorulan Sorular
,
MordorJS gerçek hayatta kullanılacak bir araç mı?
,
Pek sayılmaz.
Daha çok deneysel ve mizahi bir çalışma olarak öne çıkıyor.
Üretim ortamında kullanmak bakım açısından risk yaratır;
,
Neden çizgi uzunluğu 1 yapılmış?
,
Cevap basit:
mevcut kod standartlarıyla dalga geçmek ve neredeyse tamamen farklı düşünmeyi göstermek için.
Projenin esprisi buradan geliyor.
,
Böyle tek satırlık yapı okunabilir mi?
,
İşin garibi, Dürüst cevap:
pek okunabilir sayılmaz.
Ama amaç. Klasik okunabilirlik standardını bozup tartışma açmak;
,
Dil dönüşümü nasıl sağlanıyor?
,
Tamamen karakter eşleme,
split/join zinciri
ve son aşamada Function(M) ile yürütme üzerinden ilerliyor.
Kaynaklar ve İleri Okuma”
“
Proje GitHub Sayfası — mordorjs
”
“
npm Paket Sayfası — mordorjs”>
”
“
Anlatının ilham aldığı orijinal çalışma için ayrıca M||D||JS = MorDorJS makalesine göz atabilirsiniz>.
“
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
