- 1990’ların başında metin tabanlı IDE’ler kısıtlı donanımda bile etkileyici özellikler sunuyordu
- Dönemin önde gelen IDE’leri olan Borland Turbo serisi, sözdizimi vurgulama, derleyici entegrasyonu, hata ayıklama, yardım gibi modern IDE’lerle boy ölçüşebilecek bir ortam sağlıyordu
- Linux’taki Vim ve Emacs özelleştirilebilir olsa da, öğrenmesi zor ve yeni başlayanlar için sezgisel olmamaları önemli bir sınırlamaydı
- Son dönemde TUI’ler (metin arayüzleri) ve IDE işlevleri LSP gibi yeni teknolojilerle yavaş yavaş geri dönüyor, ancak hâlâ 90’lardaki bütünleşik yapının gerisindeler
- TUI IDE’lerin avantajları arasında uzaktan erişim, düşük kaynak tüketimi ve açık kaynak özgürlüğü yer alırken, modern IDE’lerde özellik eklendikçe şişme sorunu belirginleşiyor
Giriş: 1990’ların başındaki metin tabanlı IDE’lerin hatırası
- 1980’lerin sonu ile 1990’ların başını DOSBox üzerinden yeniden deneyimleyen yazar, eski geliştirme ortamlarını bugünle karşılaştırmanın keyfini yaşadığını anlatıyor
- O dönemin metin tabanlı IDE’leri, donanım kısıtlarına rağmen pek çok özelliğe sahipti
- Sonraki yıllarda bu işlevlerin büyük bölümü pencereli işletim sistemlerinin yükselişiyle uzun süre ortadan kayboldu; ancak bazıları ancak yakın zamanda geri dönmeye başladı
İlk editörler ve TUI ortamı
- 1990’larda DOS programlarının çoğu, metin tabanlı pencereleri, renkleri, gölgeleri hatta fareyi destekleyen tam ekran Text User Interface (TUI) kullanıyordu
- Her programın tasarımı farklı olsa da, benzer çalışma biçimleri sayesinde kısa sürede öğrenilebiliyordu
- MS-DOS, sürüm 5’ten itibaren (1991) yerleşik bir TUI editörü sundu; ancak derlemek/çalıştırmak için editörden çıkmak gerekiyordu ve yeniden açıldığında çalışılan yeri tekrar bulmak zahmetliydi
- SideKick Plus (1984) gibi TSR (bellekte yerleşik program) tabanlı araçlar da vardı; bunlar, çoklu görevin olmadığı işletim sistemlerinde verimli kod düzenleme ve derleme imkânı sağlıyordu
- Daha 1980’lerin ortası ve sonlarında bile Turbo Pascal, QuickBASIC gibi ilk IDE’ler ortaya çıkmış ve bütünleşik bir geliştirme deneyimi sunmuştu
Borland Turbo serisi: bütünleşik IDE’nin zirvesi
- Borland Turbo C++, Turbo Assembler, Turbo Pascal gibi ürünler belirli dillere özel olsalar da tam ekran TUI ve güçlü özellikler sunuyordu
- Başlıca özellikler:
- Sözdizimi vurgulama ile kod okunabilirliğini artırma
- Derleyici entegrasyonu ve uyarı/tanı mekanizması
- Proje/derleme sistemi ve çoklu pencere desteği
- Hata ayıklayıcı (kesme noktaları, çağrı yığını vb.)
- Yerleşik yardım/referans kılavuzu
- Tüm bu özellikler, 90’ların başında internet olmadan bile kendi kendine yeten ve sezgisel bir ortam sağlıyordu
O dönem Linux ortamıyla karşılaştırma
- Linux tarafında da metin tabanlı araçlar yaygındı, ancak tam ekran TUI pek sık görülmüyordu
- Kitaplar ve topluluklar tarafından önerilen Vim, Emacs işlevsel olarak genişletilebilse de, yeni başlayanlar açısından kullanıcı dostu değildi ve sezgisellikten uzaktı
- Örneğin Emacs’ta sade bir pencere yapısı, sınırlı renk kullanımı, kararsız fare desteği ve zorlayıcı, alışılmadık menü arayüzü sorun olarak öne çıkıyordu
- Borland Turbo C++ gibi IDE’lerde ise ön bilgi olmadan bile birkaç dakika içinde “Hello World” programı yazıp ortamı keşfetmek mümkündü
Günümüzde metin tabanlı IDE’ler
- Bugün geçmişteki TUI IDE’lere en çok benzeyen ortamlar arasında RHIDE, Free Pascal, QB64 bulunuyor
- RHIDE, Turbo C++ ile neredeyse aynı ama yalnızca DOS için ve geliştirilmesi durdurulmuş
- Free Pascal, Unix ortamını destekliyor ve yerleşik hesap makinesi, ASCII tablosu vb. ile güçlü bir bütünleşik ortam sunuyor
- QB64, TUI gibi görünse de aslında bir GUI simülasyonu ve terminalde çalıştırılamıyor
- Free Pascal ve QB64 bugünlere kadar geliştirilmeye devam etse de, eski dillerle özdeşleşmeleri nedeniyle geniş kitlelerde popüler değiller
Gerçek anlamda modern konsol IDE’leri
- Güncel metin tabanlı bütünleşik geliştirme ortamları arasında Neovim, Doom Emacs, Helix öne çıkıyor
- Bunlar çeşitli eklentiler sayesinde IDE seviyesinde bir deneyim sunuyor; ancak Borland ürünlerindeki gibi dile özgü bütünleşiklik ve sezgisellikten yoksunlar
- Son dönemde GNU Nano gibi araçlar basit TUI editörleri olarak ilgi görse de, IDE özellikleri bulunmadığı için daha çok WordStar benzeri bir his veriyorlar
- Sonuç olarak bugünün konsol editörleri ya 90’lardaki deneyim düzeyine ulaşamıyor ya da ancak 30 yıl önceki özellikleri yeniden kazanabiliyor
TUI IDE’lere neden ihtiyaç var?
- VSCode’un uzaktan çalışma özellikleri güçlü olsa da, TUI IDE’ler uzak makinede SSH bağlantısı kurar kurmaz kullanılabildiği için avantaj sağlıyor
- Üstelik VSCode’un uzak eklentileri açık kaynak değil ve bazı işletim sistemlerinde (FreeBSD gibi) çalışmadıkları için kısıtlar var
- TUI IDE’ler daha az kaynak tüketiyor ve özellikle uzak ortamlarda daha kullanışlı oluyor
Şişme ve "Bloat" sorunu
- Borland Turbo C++, tüm özellikleriyle birlikte kurulumda 9MB’tan küçük olup 640KB RAM içinde çalışabiliyordu
- Güncel Doom Emacs 500MB’ın üzerine çıkarken, modern IDE’ler birkaç GB’a ulaşarak ciddi bir şişme problemi yaratıyor
- VSCode 350MB ile nispeten hafif görünse de Electron tabanlı olduğu için gerçek sistem kaynağı tüketimi yüksek
- Özellikler, refactoring gibi alanlarda bazı ilerlemeler olsa da, 30 yıl öncesiyle kıyaslandığında yenilik sınırlı kalıyor
- Yapay zeka kod yardımcıları son dönemin değişimi olarak öne çıksa da, gerçekte çoğu uzaktan servis olarak sunuluyor
Sonuç
- Yazar, duruma göre Doom Emacs, Vim, VSCode, IntelliJ gibi farklı geliştirme ortamlarını kullandığını belirtiyor
- 30 yıl önceki TUI IDE’lerin sunduğu tek parça geliştirme deneyimi ve verimlilik, modern IDE’lerin şişkinliği ve parçalanmış yapısıyla keskin bir tezat oluşturuyor
- Metin tabanlı IDE’lerin taşıdığı değer ve potansiyel hâlâ geçerli; bunların evrilip gerçekten geri dönüp dönmeyeceğini ise zaman gösterecek
1 yorum
Hacker News görüşü
Visual Basic'in grafik programlama alanında zirve olması beni çok şaşırtıyor. Eskiden bir gün içinde orta düzey bir GUI uygulamasını çok hızlı geliştirmek mümkündü. Buna en çok yaklaşan şey C# WinForms'tu, ama ondan sonraki araçların hiçbiri bireysel geliştiriciyi dikkate almadı; bu da üzücü. Yeni ve güçlü bir geliştirme paradigması olarak ses/konuşma tabanlı geliştirme (SDD/VDD) öneriliyor. Çok fazla yazı yazmanın yükünden kurtulup yapay zeka ile etkileşimin bir iş arkadaşıyla konuşmak kadar doğal hale gelmesi isteniyor. Ancak bunun gerçekten gerçekleşmesi için yapay zeka modellerinin çok daha hızlı olması gerekiyor
Delphi o zaman da Visual Basic'ten üstündü ve hâlâ kullanılabiliyor. Lazarus da yaşamaya devam ediyor. Aslında C# WinForms, Delphi deneyimine en yakın şey
Qt Creator'ın VB6'ya benzer bir deneyim sunduğunu hissetmiştim. Acaba hiç kullandınız mı?
Emacs'in hâlâ tüm bu özellikleri sunduğunu düşünüyorum. Ancak yazarın "geleneksel olmayan" diye tanımladığı şey, sadece kendi alışık olmadığı kurallar. Emacs tamamen kendi kendini belgeleyen ve etkileşimli bir araç. Şimdiye kadar kullandığım en iyi metin tabanlı arayüz, Emacs içindeki Magit'ti (https://magit.vc/). Keşke Emacs'in daha fazla kısmı Magit gibi olsa. IDE ne olursa olsun, git istemcisi olarak Emacs kullanıyorum
Emacs, Apple cmd-z/x/c/v kısayollarını geliştirmeden önce de vardı; tarihi çok eski bir araç. O zamanlar programcı editör kısayollarında Wordstar türevi şemalar (ör. çoğu Borland ürünü) baskındı. Bugün artık pek bilinmeyen, 30-40 yıl önceki olağanüstü IDE'ler vardı. Örneğin Apple MPW (1986), bütün pencereleri birer Unix shell yapan bir GUI editördü; shell script'lerle pencereleri ve düzenleme işlerini kontrol edebiliyor, ayrıca yerleşik bir kaynak kod yönetim sistemi sunuyordu. Bir komut yazıp option-Return'a basınca tüm seçenekleri seçebildiğiniz GUI tabanlı bir 'Commando' penceresi açılıyordu. Apple Dylan (1992-1995), Lisp/Smalltalk tarzı güçlü bir IDE'ydi; THINK Pascal ve C (1986), Metrowerks Codewarrior (1993), Macintosh Allegro Common Lisp gibi araçlar da yenilikçiydi. 80'ler ile 90'ların başındaki 8-40MHz M68000 ve 2-32MB RAM ortamında bu kadar rafine IDE'lerin yapılmış olması hayranlık verici
Emacs'in kendi kendini belgeleyen ve etkileşimli olduğu yorumuna katılmıyorum; ilk kez kullandığımda dosya nasıl kaydedilir, onu bile kolayca anlayamamıştım. vi'dan iyi olabilir ama bir aceminin açıklama olmadan hemen kullanabilmesi için yeterli değil
Magit gerçekten inanılmaz. Böyle bir veri modelini nasıl düşündüklerini merak ediyorum. Sanki git'in veri modelinin de ötesine geçen bir şey uygulanmış gibi. git porcelain'in dağınık yapısına kıyasla Magit sistematik bir yapıya sahip
Turbo-Vision tarzı IDE'lerde Alt, Tab, Return, Esc ve yön tuşları gibi birkaç şeyi bilmek çoğu özelliği anlamak için yeterliyken, Emacs bu tür birleşik bir kullanım düzenine sahip değil
25 yılı aşkın süredir Emacs kullanıyorum; artık tamamen içselleştirdim
Turbo Pascal gerçekten olağanüstüydü. İlk başta standart dışı bir Pascal uygulaması olduğu için kullanmaya çekinmiştim ama rakip araçlar çok pahalıydı ve daha az güçlüydü. Bizzat deneyince tamamen hayran kaldım. IBM PC'de hızlı ve sezgisel bir IDE deneyimi yaşattı. Modern IDE'ler arasında Intellij, 25 yılı aşkın süredir rakiplerinden açık ara daha iyi. Microsoft ürünlerini uzun zamandır kullanmadığım için VSCode deneyimim yok. Eclipse hem yavaştı hem sezgisel değildi hem de bol hatalıydı. JetBrains, misyonuna sadık kalıp mükemmelliğini koruyan ender şirketlerden biri. Bu kadar farklı dil, standart ve aracı sürekli desteklerken böylesine yüksek kaliteyi koruması etkileyici
Visual Studio hâlâ WinForms ve grafik form tasarımcısını destekliyor; bu da 90'ların sonundaki Delphi deneyimine çok benziyor. Çünkü WinForms, VCL'yi açıkça taklit etti
Ama kaynak kullanımı büyük sorun. Bulut masaüstünde neovim kullanamadığım için ideavim kullanmaya başladım, fakat 4 çekirdek ve 16GB RAM'e rağmen birkaç proje açınca sistem teklemeye başlıyor. Şirketin güvenlik yazılımının etkisi de olabilir ama VSCode o kadar zorlamıyor
Turbo Pascal IDE zamanının ötesindeydi ve CP/M'de (özellikle Z-80'da) bile sihir gibi iyiydi. Kendi dönemindeki her şeyden üstündü
Yazı 2023 tarihli olduğuna göre başlıktaki yılın 32 yıl önce olarak güncellenmesi daha doğru olur. Bugünün TUI'larında en can sıkıcı şey, asenkron framework'lerin tuş girişlerini bazen yok sayması. 2000 öncesi TUI'lar, sistem hazır olmasa bile tuş girişlerini bekletirdi. Buna karşılık modern "web tabanlı" TUI framework'lerinde event listener kaydolmadan önce tuşa basarsanız giriş tamamen kaybolabiliyor. Bunun dışındaki sorunları saymazsak TUI hâlâ oldukça iyi durumda. Neovim, LSP ve eklentileri sayesinde şimdiye kadarki en zengin özellik setine sahip. Fare tabanlı bir TUI değil ama üretkenlik açısından son derece güçlü
DOS döneminde gerçek terminallerde tuş giriş tamponu vardı ve arayüze alışkın kullanıcılar, birden fazla tuşa önceden basarak UI'ın önüne geçerdi. Girişler tampona birikir, sonra ekranda bir anda belirip kaybolurdu. Bu yapı modern framework'lerle de kurulabilir ama dikkatli yapılmalı
Ben bunu 1984'te de yaşadım; yani kapsam 41 yıl öncesine kadar gidiyor. Visual Studio 1.0 veya NetBeans gibi GUI ürünleri çıkana kadar ilk dönem projeler baskındı. vim'den (1991) önceydi ama ncurses yerine floating windows isteyen bir hissi vardı
Tuş girişlerinin böyle yok sayılması delirtici derecede rahatsız edici. Eskiden hızlı kısayol kombinasyonlarıyla bilgisayarı inanılmaz hızda kullanabiliyordum; şimdi ise sanki yapış yapış pekmezin içinde yürüyormuşum gibi geliyor
30 yıl öncenin tam olarak ne zamana denk geldiğini kestirememiştim; GUI Smalltalk sistem tarayıcısının geleceğini umuyordum ama karşıma DOS TUI çıktı ve hayal kırıklığı yaşamıştım. Yine de Turbo C/Pascal, MS C 4.0 ve CodeView'i anınca keyfim yerine geldi. Bu araçlar 43 satır ve 50 satır modlarında da kullanılabiliyordu
Belirli bir IDE'ye aşırı bağımlı olmanın hem rekabet gücünüze hem kodunuza zarar verebileceğini düşünüyorum. Terminal IDE'leri açısından konuşursak, GNU/Linux terminali zaten başlı başına en iyi uygulama. Döşemeli pencere yöneticisinde birden fazla terminal açıp kullanınca üretkenlik zirve yapıyor. Büyük ekranlardaki modern ölçeklendirme de geliştirici ergonomisi açısından mükemmel
Hâlâ kendi yaptığım metin tabanlı editör/IDE'yi geliştirip kullanıyorum (https://github.com/alefore/edge). 10 yıllık geliştirmenin sonucunda vardığım noktayı yakın zamanda yazdım (https://github.com/alefore/weblog/blob/master/edge/README.md)
DOS'un altın çağında karakterler bir byte dizisi olarak, öznitelikler de (arka plan, ön plan rengi vb.) ayrı bir dizi olarak tutuluyordu. Belli bir konuma 'A' yazmak istiyorsanız, ilgili bellek adresine sadece 0x41 yazmanız yeterliydi. Biraz wait state vardı ama 9600 baud terminalde ANSI komutlarıyla çıktı vermekten çok daha hızlıydı. Emacs yavaş seri terminallerde veya Sun iş istasyonlarının terminal emülatörlerinde kullanılabiliyordu; shell tabanlı TUI'nın ortadan kaybolmasının arkasındaki neden de buydu
Bu yazı metin tabanlı IDE'lere odaklanıyor ama bence Visual Basic veya Delphi gibi geleneksel IDE'ler için de geçerli. Yeni başlayanlar için Python'a gerçekten bir IDE gerektiğini düşünüyorum. Metin tabanlı değil, Visual Basic tarzında; her şeyin entegre olduğu, keşfetmesi kolay bir yapı olmalı (önemli!). GUI oluşturucu ve debugger da yerleşik olursa iyi olur. Kod editöründe syntax highlighting, autocompletion ve kolay kod gezintisi olması yeterli. Örneğin pencereye bir buton koyup GUI editöründe ona çift tıklayınca doğrudan o butonun handler koduna gitmek gibi. Geçmişte buna benzer bir fikir etrafında insanlar toplanıp konuşmuştu ama hangi GUI framework'ünün kullanılacağı konusunda (Pyside, Dear PyGui, web tabanlı vb.) çok büyük fikir ayrılıkları çıkınca konu dağıldı. Free Pascal'dan söz edilmişken, Delphi'nin klonu olan Lazarus'tan da bahsetmek gerekir (https://www.lazarus-ide.org/). Çok iyi ve hâlâ aktif biçimde geliştiriliyor. Yalnız Object Pascal bugünlerde çok kullanılmadığı için biraz eski hissettiriyor
Yeni başlayanlar için Python'da Visual Basic tarzı, GUI oluşturuculu, yerleşik debugger'lı entegre bir IDE gerektiği fikrine tamamen katılıyorum. 2000 yılında Boa Constructor (https://boa-constructor.sourceforge.net/) diye bir Python IDE'si vardı ama yaygınlaşmadı
Ben de yakın zamanda Windows 3.11 üzerinde VB3 ile oyuncak bir uygulama yapma sürecimi videoya çektim ve o tweet "viral" oldu. Sonuçta önemli olan şey TUI değil, bütünleşik kullanıcı deneyimi
Benim için Lazarus gerçek IDE'nin ölçütü. Lazarus, Lazarus ile yapıldı ve yazarı kendi ürününü yoğun biçimde kullanıyor; örnekler ve eğitimler de sunuyor. Çocuklara programlama öğretmek için de harika. Microsoft Visual Studio'daki gibi etiketleme, arama, yardım, API dokümantasyonu, widget örnekleri ve kütüphaneler entegre geliyor. Diğer IDE'lerde bu tür bir bütünlük yok; Xcode'a da IDE deniyor ama Lazarus'la kıyaslandığında zayıf kalıyor. O kadar inatçıyım ki 6 aydır JS yerine Go ile kendi UI frontend framework'ümü yazıyorum; bir gün bir IDE de yapabilmeyi umuyorum
Borland'ın IDE'leri gerçek bir zevkti. Hâlâ o seviyede bir deneyim veren modern bir araç bulabilmiş değilim. Elbette biraz nostalji payı var ama sırf o arayüzü açmak için kendime Free Pascal kullanacak bahaneler uydurmak bile keyif veriyor. Pascal'ı da seviyorum. Bazen Plan 9'ın Sam ve Acme araçlarını kullanıyorum ama bunlar IDE değil, editör. Beni engellemeyen ve düşünmeye alan açan araçları seviyorum. Eski TUI'lardan öğrenilecek çok şey var. Örneğin File menüsünden shell açıp bir şey çalıştırdıktan sonra geri dönmek tamamen kabul gören, hatta kahramanca bir hareketti. Bir de keybinding'ler! Eski TUI'lar WordStar'ın kısayol düzenini bolca ödünç almıştı; o kadar vücuda işlemiş ki Emacs bana fırın eldiveniyle yazı yazmak gibi geliyor. Uzun süre joe'yu (jstar takma adıyla) severek kullandım. Artık Dr. DOS VM'i açıp Advent of Code da çözerek bilerek verimsiz bir nostalji partisi yapma zamanı
DOS döneminin "profesyonel" yazılımları (Emacs vb.), kullanıcının o yazılımın içinde tam anlamıyla yaşaması için tasarlanıyordu. Makineyle bütünleşip bir org sanatçısı gibi kısayolları ustalıkla kullanabiliyordunuz. Fry’s Electronics çalışanlarının TUI'ları öyle hızlı kullandığını, ekran daha gelmeden işlerini bitirip çıktıyı aldıklarını izlediğimi hatırlıyorum
WordStar kısayollarının tam olarak ne olduğunu ve neden iyi görüldüğünü merak ediyorum. Bu tür düzenlerin tarihini ve farklı yaklaşımların avantajlarını incelemek ilgimi çekiyor
Harika bir yazı, ben de çok katılıyorum. Ben de boş zamanlarımda Turbo Pascal tarzı bir TUI kod editörü geliştiriyorum. İleride make ve lldb'yi de içine gömmeyi planlıyorum
Plan 9'ın birçok yönünü seviyorum ama Acme'nin fare ağırlıklı UI'ına bir türlü alışamadım. Hassas fare hedeflemesi isteyen arayüzler, uzun süreli kullanımda veya bir engel durumunda çok rahatsız edici olabiliyor
djgpp ve vi for dos 1991 ikilisi mükemmeldi
Visix Vibe adlı Java IDE'sini ve Delphi'yi kullandım; her ikisi de üretkenliğimi inanılmaz artırdı. Müşteriye UI geliştirme, iş mantığı bağlantıları ve dağıtıma hazırlık için takvimi rahatça öngörebiliyordum. Özellikle bu iki IDE'de en çok özlediğim şey entegrasyon seviyesi. Veritabanını bağlayıp form oluşturduğunuzda hemen veri girişi ve doğrulama yapılabiliyordu; birkaç gün içinde proje gereksinimlerini karşılayan bir UI'ya ulaşmak mümkündü. Günümüzdeyse UI, API ve backend'in gerçekten düzgün bağlanıp bağlanmayacağını çok daha dikkatli tasarlamak ve düşünmek gerekiyor. Yapay zekanın UI kodu üretmesinden ziyade, kodu hâlâ görsel olarak çizip UI üzerinden program inşa etmeyi sağlayan araçlara ihtiyaç var gibi geliyor. Biri JUCE için düzgün bir WYSIWYG aracı çıkarırsa altın çağın geri döneceğini düşünüyorum
DOS döneminde karakterleri temsil eden bir byte dizisi ve renk öznitelikleri için ayrı bir dizi vardı; donanım bunları doğrudan ekrana çiziyordu. Bellek adresine bir değer yazdığınız anda ekrana yansıyordu, bu yüzden yavaş seri terminallerden veya ANSI komut tabanlı yapılardan çok daha hızlıydı. Emacs'i Sun iş istasyonlarının terminallerinde kullandığınızda doğal olarak yavaş kalıyordu; TUI'nın kaybolmasının nedeni buydu