İki kültür: Lisp ve Un*x

misafir
11 Temmuz 2006 , 3 dakika okuma süresi

Bu yazıda epey bir spekülasyon yapacağım. Bazı olguları es geçersem ya da hafifçe saptırırsam, hemen sinirlenmeyin. Sakince yazıyı bitirmeyi bekleyin. Amacım "flame war" çıkarmak değil, bazı gözlemlerimi paylaşmak.

Bir programlama dili ile bir işletim sistemini karşılaştırarak, elmalarla armutları kıyasladığımı düşünebilirsiniz. Ancak unutmayın ki, Un*x C dili ile içiçe geçmiştir. Lisp camiasının en çok övündüğü şeylerden biri ise Lisp makinalarıdır. Bu makinaların kendilerine özgü donanımlarının yanında, elbette işletim sistemleri de vardı. Ayrıca kıyaslamayı düşündüğüm şey, Lisp'in ve Un*x'in kendileri değil, çevrelerinde gelişen kültür.

Un*x'in çevresinde gelişen kültür C dili ile yakından bağlantılı. C alt seviye bir dil olduğundan karakter dizilerini (string) işlemesi zordur. Bu yüzden düzenli ifadeler (regular expressions) ve bunları kullanan programlar; ed, sed ve awk, bir süre sonra Un*x'in ayrılmaz parçaları haline gelmiştir. Bu gelişmeye son noktayı ise Perl koyar. Perl; sed, awk ve sh'yi içinde barındırmakla kalmaz onların da ötesine geçer. Perl'in neden karakter dizilerine bu kadar önem verdiği sorusunun cevabı ise bence açık. Çünkü Perl -tıpkı sed ve awk gibi- C'nin tamamlayıcısıdır. Birinin zayıf olduğu alanda diğeri güçlüdür. Perl Un*x kültürünün tam bir üyesidir. Un*x ile en az C kadar entegre olmuştur.

Peki Lisp çevresinde nasıl bir kültür gelişmiştir? Yabancısı olduğum bir kültür olduğu için buna cevap vermekte biraz zorlanacağım. Ancak bu kültürü takdir ettiğimi de belirtmeliyim. Lisp kültürünün bence en ilginç yönü makinadan bağımsız düşünme alışkanlığı. Belki de Lisp bu sayede yarım yüzyıldır canlılığını koruyor. Bu sayede hangi makina verilirse verilsin dilde herhangi bir değişiklik yapmak gerekmiyor.Peki Lisp kültürü makina yerine neye dayanıyor? Tabii ki matematiğe. Umarım sevgili Lisp'çiler yorumlarıyla bu paragrafa katkıda bulunurlar.

Bu noktada belki kimi okurlara ters gelecek bir yorum yapacağım. Bence Lisp kültürünün tipik temsilcisi rms'tir. Kendine ait bir Lisp enplamantasyonu (Emacs Lisp) olması bile yeterli kanıt olabilir. Ancak GNU işletim sisteminin çekirdeğini (Hurd) bir türlü yazamaması da bence ikinci bir kanıt oluşturuyor. Dediğim gibi Lisp kültüründe makinadan bağımsız düşünmek bir erdemdir. İşletim sistemi çekirdeği ise makinayla en içli dışlı olan şey.

Emacs - vi kavgasına da değinmeden geçemeyeceğim. Tahmin edilebileceği gibi emacs Lisp kültürünün ayrılmaz bir parçasıdır. Yalnız Lisp'i kullanması yüzünden değil, aynı zamanda bütün Lisp programcılarının emacs kullanması yüzünden. vi ise Un*x'in öz evladıdır.

Biraz da ilgisiz görünen dillerden sözedelim. Örneğin, Python sizce Lisp kültürüne mi yoksa Un*x kültürüne mi aittir? Bence açık bir şekilde Lisp kültürüne ait. Düzenli ifadeler ve Un*x entegrasyonu konusunda Perl ile karşılaştırılabilir mi bilmem? Peter Norvig, ünlü yazısında zaten Python ile Lisp'in ne kadar birbirine benzediğini anlatmıştı -evet, Python closure'ları desteklemediği halde-.

Peki ya Ruby? Perl'in pek çok özelliğini bünyesine katarak Un*x kültüründe sağlam bir yer edinmeye aday. Öte yandan, Lisp-vari özellikleri ile Lisp kültürünün takdirlerini de toplamayı başardı. Kimbilir belki de Ruby bu iki kültür arasında bir köprü olur...

Hacking

Görüşler

bm
18 yıl önce

Pekiyi, ben de insanlar ne diyecek merak ediyorum. Bu Unix kulturu/Lisp kulturu konusunda Gabriel'in "Worse is Better" yazilari ile "Unix Haters Handbook" filani da tavsiye ederim.

bm
18 yıl önce

Belki niye bunlara atifta bulundum anlasilmaz filan diye bir de alinti yapayim Ingilizce bilenler icin. Bu Gabriel'in ilk Worse is Better yazisindan:

2.1 The Rise of Worse is Better I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase the right thing. To such a designer it is important to get all of the following characteristics right: * Simplicity -- the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation. * Correctness -- the design must be correct in all observable aspects. Incorrectness is simply not allowed. * Consistency -- the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness. * Completeness -- the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness. I believe most people would agree that these are good characteristics. I will call the use of this philosophy of design the MIT approach Common Lisp (with CLOS) and Scheme represent the MIT approach to design and implementation. The worse-is-better philosophy is only slightly different: * Simplicity -- the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design. * Correctness -- the design must be correct in all observable aspects. It is slightly better to be simple than correct. * Consistency -- the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency. * Completeness -- the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface. Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the New Jersey approach I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach. However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach.

FZ
18 yıl önce

Ruby'nin yaratıcısının feyz aldığı dillerden biri Lisp ise diğeri de en düzgün nesneye yönelik programlama dillerinden biri olan Smalltalk'tur ve burada bunu görmek mümkündür:

Take a true object-oriented language, such as Smalltalk. Drop the unfamiliar syntax and move to more conventional, file-based source code. Now add in a good measure of the flexibility and convenience of languages such as Python and Perl.

Matz'in şu lafı da üzerinde durulması gereken bir laf:

Tools change very easily as time passes. If you focus too much on present-day tools, your efforts will give you only short-term returns. If you want benefits that will endure, you need to focus more on fundamentals. Focus on mathematics and human psychology. Focus on established sciences and established ways of thinking.

Meraklısı modern bir Smalltalk geliştirme ortamının neye benzediğini görmek için buraya bakabilir.

newman
18 yıl önce

RMS gcc'yi de yazmamis miydi? Hurd ile ilgili sorun baska: Linux... Sonra Hurd'un icinde Lisp'le ilgili ne var? Lisp ile mi yaziliyor?

bm
18 yıl önce

Suradan bir alinti yapayim:

GNU will be able to run Unix programs, but will not be identical to Unix. We will make all improvements that are convenient, based on our experience with other operating systems. In particular, we plan to have longer filenames, file version numbers, a crashproof file system, filename completion perhaps, terminal-independent display support, and eventually a Lisp-based window system through which several Lisp programs and ordinary Unix programs can share a screen. Both C and Lisp will be available as system programming languages.

exalted
18 yıl önce

Hurd'un tamamlanması konusunda "Linux" bir sorun olarak görülmemelidir. RMS ile elektronik posta aracılığıyla yaptığım konuşmaların sonucunda doğru olduğuna inandığım bir sonuç çıkardım: Esas olan özgür GNU İşletim Sistemi'nin çalışır olmasıdır, bu noktada çekirdeğin kim tarafından ne şartlarda yazıldığı, adının ne olduğu ya da teknolojisi ve tasarımının nasıl olduğu önemli değildir. RMS Hurd'un henüz bitmemiş olmasından dolayı üzgündür, ancak bu üzüntü yıllardır arslanlar gibi çalışan özgür bir işletim sisteminin verdiği sevinçten daha büyük değildir. RMS Hurd'un tasarımının "üstün" bir tasarım olduğuna inanmaktadır ve bunun hala hayata geçirilememiş olmasından dolayı üzgündür, ancak kendisinin de belirttiği gibi onun davası artık işletim sistemini birincil elden yazmak yerine, özgürlük adına politik ve yasal alanda savaş vermektir. Hurd ile ilgili olarak bu bağlantının güzel olduğunu düşünüyorum.

Sevecenlikler,
Ali Servet Dönmez

newman
18 yıl önce

Ben sorun derken cabalarin linux uzerinde yogunlasmasinin ana neden oldugunu, meselenin lisp veya lisp kulturu ile ilgisi oldugunu sanmadigimi soylemek istedim. Bunu aciklamak isterim. Bu linki daha once merak edip ben de bulmustum.
Politik yonu hassas bir konu. Herkes diledigi gibi dusunmekte serbest. Ben isin o yonuyle ilgili konusmaya istekli degilim. Fakat her turlu yaniltici olmayan ve insanlarin genel yararina cabanin basariya ulasmasini cani gonulden dilerim. Sadece teknik ve isin research ile ilgili yonunden bahsediyordum. Ve acikcasi Hurd vs. Linux gibi bir tartismayi kasdetmedim: onun nereye gidecegi malum.
Saygilar sunarim.

exalted
18 yıl önce

İlginiz için teşekkür ederim. Aynı şeylerden bahsettiğimizden emin sayılırım. Kısaca yazdıklarımın ve verdiğim bağlantının faydalı olmasını dilerim.

Sevecenlikler,
Ali Servet Dönmez

rickdangerous
18 yıl önce

Güzel ve ilginç bir yazı. Devamının gelmesini dilerim :-)
Günümüzde ve gelecekte ne yenilik olacaksa (GNU/)Linux ve *BSD platformlarında olacağını sanıyorum. Bunca gelişmeden sonra tekerleği yeniden keşfetmek hem zahmetli hem de anlamsız olur. AMD 64'den sonra Intel ve AMD mimarisinin de daha uzun süre burada olacağı belli oldu. Artık Lisp makinesi gibi donanımların vakti geçti. Ama yazılım açısından ders alınacak çok şey var hala...
Ruby konusunda ise çok olumlu şeyler düşünüyorum. Ruby elbette bir son nokta değil ama yazılım dünyasına çok şeyler kazandıracak bir özgür yazılım değeri. Gelecek yıllarda Ruby'nin de facto standart olacağını sanıyorum. Yeni dil öğreneceklerin dikkatine...

newman
18 yıl önce

Lisp makinasi filan bakimindan degil, prensip olarak soyluyorum, sizin su soylediginiz:
Günümüzde ve gelecekte ne yenilik olacaksa (GNU/)Linux ve *BSD platformlarında olacağını sanıyorum. Bunca gelişmeden sonra tekerleği yeniden keşfetmek hem zahmetli hem de anlamsız olur.
seye benim katilmam imkansiz. Yani yenilik olacaksa ve eger ozellikle bu yenilik OS dizayni baglaminda olacaksa bu nasil Linux'un dizayni icinde olacak? Linux herseyden once monolitik eski tip, 30 - 40 yil oncesinin dizayn anlayisina sahip bir sistem. Free'ydi bilmem neydi bunun muhendislik dizaynin ust kalite olmasiyla hicbir ilgisi yok. Bu mantikla bir OSX olamazdi herhalde.
Ustelik, eger buyuk bir yenilik olacaksa, bu tip isleri basaranlar genelde pek kimseye sormazlar "hangi cercevede kalacaklarini". Onlar yapar, digerleri "klonlar" ;).
Ben ruby ile ilgili yeterli bilgi sahibi degilim, ama sizin bu soylediginizi ciddiye almamiz icin, mesela Java, C++,C#,Python,vs. propagandacilarinin soylediklerinden daha ciddiye almamizi gerektirecek, bir veya birkac sebep siralayabilir misiniz?
Soyledikleriniz icinde katildigim bir yer var ama: "Tekerlegi yeniden icad etmenin yersiz oldugu"! Ama simdi sormak lazim, Linux'a bir omur harcayanlar bunun icin mi Unix tekerlegini yeniden icad ettiler? Insan hic degilse 1.0 dan 2.0'a gecerken veya arada bir yerde "yahu bu monolitik dizayn sonunda basimizi agritacak" diye bir durup dusunmez mi en azindan... Linux ve Unix bugun olabilir, ama yarini temsil ettiklerine inanmak istemiyorum. Daha iyi bir yol olmali. Ama insanlari arastirmaya ve genis ufuklu olmaya tesvik etmek gerek bunun icin, belli bir cerceveye hapsetmeye calismak degil.

rickdangerous
18 yıl önce

Tam aklımdan geçenleri dile getirmişsiniz. Linux çekirdeği sınıflandırmaya göre monolitik bir çekirdek olmasına karşın öyle ilginç yeniliklerin uygulama haline geldi ki. Örneğin daha geçen gün FUSE yani user level'da dosya sistemi mount etme özelliği ile ilgili bir sunum gördüm. Sunumda "mikrokernel gibi" gibi bir tanımlama vardı. Bu aşamadan sonra Hurd ve başka alternatif teknolojiler elbette çıkacak ve güzel olacak ama Linux çekirdeği üzerinde her türlü melez ve evrimsel gelişme ve ilerleme de olacaktır. Kısacası Linux klasik anlamda bir Unix çekirdeği değil artık ne de GNU/Linux platformu klasik bir Unix. Linux'un gelecekte gittikçe özel amaçlara daha da uygun hale geleceği belki çatallanacağı ve farklı kollardan yoluna devam edeceği aşikar.
Ruby konusunda ise şu saatte ayrıntıya girmek istemiyorum ama pek çok güzel özelliği çekinmeden bünyesinde birleştirmiş camia olarak da yeniliklere açık ve ilerici bir dil ayrıca önyargıları yenip deneyen pek çok kişiden oldukça olumlu yorumlar geliyor. Tabii ben Ruby geleceğin "tek ve birick" dili olacak demiyorum sadece önemli bir konuma geleceğine inanıyorum.

newman
18 yıl önce

Belki farkli dusunuyoruz cogu konuda (belki de sandigimdan daha cok ortak gorusumuz vardir, bilmiyorum) ama medeni bir fikir alisverisi yapabildigimizi gormekten cok memnun oldum. Tesekkur ederim.

FZ
18 yıl önce

Zamanında Tarih Tekerrürden İbaret Değildir: Tanenbaum vs. Linus (ya da Monolitik Canavar Mikroçekirgeye Karşı) başlıklı bir şey yazmıştım. O yazıya bakacak olursanız konu üzerinde çalışan insanların kaygılarını, vizyonlarını orada verilen belgeleri okumak sureti ile kıyaslama imkanına kavuşursunuz.

Ruby ile ilgili de aklıma şöyle bir soru geldi: Ruby'nin yaratıcısı Matz için 21. yüzyılın Larry Wall'u diyebilir miyiz?

newman
18 yıl önce

FZ, aslinda ben "monolithic" ve "large sytem" kelimelerini yanyana getirmenin neredeyse a priori bir oxymoron oldugunu dusunuyorum (tarzanca icin kusura bakmayin :). Yani aslinda biraz onyargili oldugumu itiraf etmeliyim. Bununla birlikte koru korune inat edecek de degilim. Bu yuzden ben tam da bu tip birsey ariyordum, konu hakkinda uzmanligi olan insanlarin goruslerine bir bakmak icin. Cok iyi oldu, tesekkurler.

rickdangerous
18 yıl önce

"Ruby'nin yaratıcısı Matz için 21. yüzyılın Larry Wall'u diyebilir miyiz?"
Uhm, Larry Wall daha ölmedi :)
Ayrıca ikisinin yaklaşımları da farklı, Matz baştan beri kafasında bir belirli yaklaşım taşıyor, hedeflediği belirli kriterler var. Örneğin Ruby'i tasarlarken öğrenme eğrisinin düz olmasını yani programcının önüne öğrenirken engeller çıkarmamasını istediğini söylüyor.

belfagor
18 yıl önce

ilk kez bu gün rubyi inceleme fikri aklıma geldi. gittim internetten aradım buldum rubyi kurdum. sonra internetten türkçe döküman buldum okumaya başladım. veee gerçektence çok eğlenceli bir dil. oldukçada kullanışlı geldi. rubyi öğrenmek belki bana o kadar büyük katkılar sağlamaz ama en azından eğlenceli zaman geçirmeme faydalı olur ( faydasız bir demiyorum. belki benim işime yaramaz diyorum :)) ) ruby ile ilgili daha çok haber görmek beni memnun eder :D

rickdangerous
18 yıl önce

Bir script dili öğrenmek herkesin işine yarar. Hatta bildiğiniz bir script dili olması, arada sırada onla oynamak sadece entellektüel bir eğlence olmaktan öte gün gelir faydalı olur.
Ruby öğrenmekle, farklı dillerden aldığı güzel özellikler sayesinde pek çok temel kavramla tanışmış olursunuz. Bu sayede ileride başka dilleri öğrenmeniz kolaylaşır. Benzeri olan diller (php, perl, python) daha çok kendilerine özgü diller olmalarından ötürü bu eğitsel avantajı Ruby kadar taşımazlar.

skoylu
18 yıl önce

>>> Linux herseyden once monolitik eski tip, 30 - 40 yil oncesinin dizayn anlayisina sahip bir sistem.

30-40 yıl öncenin microkernel anlayışına sahip bir sistem olsa, daha mı iyi olacaktı? 30-40 yıl öncesinin LISP gibi fikirleri hala güzel güzel iş yapıyor. Bir fikrin 30-40 yıl önce söylenmiş olması fikri kötü kılar mı? 30-40 yıl içinde, mimari alanda ne değişti. Linux çekrideği saf bir monolitik kernel değildir. Microkernel'de değildir. Kendine özgü bir yapısı vardır, bazı açılardan microkernele, bazı açılardan monolithic kernele benzer. Ama ikiside de değildir. Fakat, mimarilerde 30-40 yıldan beri herhangi bir gelişme yok. 30-40 yıl önce monolit kernel seçmek için geçerli olan argümanlar aslında hala yerli yerinde duruyor. Linux'un dizaynıyla alakalı ben herhangi bir sorun göremiyorum. İmplementasyon ile alakalı bir takım sorunlar var ve günde güne gideriliyor. Mesela aio_* gibi, mesela futex gibi. Fakat, dizayna dair herhangi bir sorun görmüyorum. Elbette birileri arada çıkıp şöyle de ondan böyle diyorlar, ama bunlar öyle yapsak çıkacak başka sorunları atlayanlar oluyor genelde..

newman
18 yıl önce

>>>30-40 yıl öncenin microkernel anlayışına sahip bir sistem olsa, daha mı iyi olacaktı?

Oyle birsey demedim. Modern bir microkernel dizayna sahip olsun bile demedim. Linux neyse o. Ne olacagina biz burada konusarak karar veremeyiz. Benim soyledigim su: yenilik arayisina eski dizayn kriterlerine bagli kalacagim, kesinlikle her ne yapilacaksa Linux/BSD cercevesinde yapilmalidir, vs. gibi bir arguman dogru degildir. Zaten yenilik pesinde kosan kimseler de biz boyle dedik diye kendilerini o kaliplara hapsetmezler. Yeninin adinin veya dizayninin Linux veya BSD veya herhangi bir Unix olmasi da gerekmez.
Linux cekirdegi buyuk olcude monolitik. Siz bunda bir dizayn problemi gormuyor olabilirsiniz, ama ben de onumuzdeki yuzyilda yapilacak hicbir yeni OS projesinin monolitik bir cekirdek uzerine kurulacagina ihtimal vermiyorum. Daha iyi bilenlere konuyu birakmayi tercih ediyorum. Ancak prensip olarak monolitik bir cozumun *hicbir* buyuk sisteme uygun olmadigini dusunuyorum.

LISP'in hala guzel is yaptigini dusunmenize sasirdim. Demek ki ben sizi yanlis anlamisim daha once. Ama ben Linux'u ve daha once orijinal Unix'i yazanlarin LISP'i yazanlar gibi temel matematik prensipler ve bilimsel teoriler uzerine sistemi sistemi kurduklarini sanmiyorum: bunlar daha cok gune ait muhendislik projelerdi. Belki yaniliyorumdur, oyleyse her turlu aydinlatici bilgi ve belgeye acigim.

Tekrar edeyim: Linux icin degil, ama linux cercevesinde kalmayi secmeyen ve evrilme yetenegine sahip herhengi bir OS projesi sozkonusu oldugunda a) ben sizin aksinize monolitik cekirdegin bir secenek olmadigina, b) "30 - 40 yil oncenin monolitik cekirdegi" ifadesinin olumsuzunun "30 - 40 yil oncenin mikrokernel'i" olmadigina inaniyorum. Modern bir mikrokernel'i kasdetmistim ben. Hem de Linux icin degil: yaparlarsa ne iyi, ama onlarin yapmamasi neden soruma cozum arayanlara ayak bagi olacakmis? Yapilabilirligi hickimse degilse Apple gosterdi. Onlardan da daha iyisi yapilabilir, eminim.

misafir
18 yıl önce

>Ama ben Linux'u ve daha once orijinal Unix'i yazanlarin LISP'i yazanlar gibi temel matematik prensipler ve bilimsel teoriler uzerine sistemi sistemi kurduklarini sanmiyorum: bunlar daha cok gune ait muhendislik projelerdi. Belki yaniliyorumdur, oyleyse her turlu aydinlatici bilgi ve belgeye acigim.

Kültür farkı ile ben de bunu kastediyordum. Tabii ben de yanılıyor olabilirim. Ancak Un*xçiler de bilimden ve matematikten tamamen uzak değildi. Örneğin düzenli ifadeler, ed(1)'e dahil edilmeden önce matematiksel bir buluştu.

FZ
18 yıl önce

Evet uzak değildiler, doğrudur. Düzenli ifade sözdizimindeki meşhur * sembolü, Kleene yıldızı diye geçer ve ismini de meşhur matematikçi Stephen Kleene'den alır.

newman
18 yıl önce

Ben daha cok sistemin temel dizayn prensiplerini kasdetmistim. Ama daha cok muhendislik projesi olmak kotu birsey degil. Unix yazildigi donemde bir ilkti. Linux yazildigi donemde bir taklitti. Linux'un temel erdemi insanlarin paylasma ve yardimlasma arzusunun bir sonucu olmasi. Bazilari (bir propaganda soylemi bence -- ama gercekten boyle hissedenler de olabilir, itirazim yok) ozgurluk vurgusunu ekliyor. Fakat acikcasi bunun teknik ustunlukle ilgisi yok. Tum bunlarla birlikte is zamanla degisebilir, ama bu buyukluge erismis bir proje icin bu ne kadar kolaydir? Bunu bilmiyorum.
Ama gunumuzde is gorebilir olmak ayri birsey, yeniliklerin sarti ve temeli olmak ayri. Bu konuda birinin beni ikna etmesi veya birseyi yanlis anladiysam beni aydinlatmasi gerek. Problem yok ki, diyen varsa zaten konusacak birseyimiz de yok.
Lisp'te hem muhendislik ve hem matematik ve diger bilimsel prensipler var. Bunlarin ikincisi dogal olarak cok uzun omurlu oluyor. Simdi tutup o sinifin omru uzun diye digeri de tamamen ayni olacaktir diyemeyiz. Cok uzun omurlu muhendislik prensipleri de olacaktir elbette, ama "buyuk sistemleri monolitik olarak idare etmek bir muhendislik temel prensibidir" diyen olursa bana cok iyi bir arguman vermeli. Su anda millet ne demis, ona bakiyorum. Ama sonucta aklimizi kimsenin cebine koyacak degiliz, degil mi :)?
Esasen benim simdilik bu konuyla ilgili soylemek istedigim baska birsey yok :).

rickdangerous
18 yıl önce

"kesinlikle her ne yapilacaksa Linux/BSD cercevesinde yapilmalidir, vs. gibi bir arguman dogru degildir."
Ben bunu kast etmemiştim. Tek kültürlülüğe en başta ben karşıyım alternatif teknolojilerin yaşam hakkı çok önemli. Benim yaklaşımım Linux çekirdeği ile bu kadar çok yenilik mümkünken kimsenin tekerleği yeniden keşfemekle uğraşmayacağı ve var olanı değiştirmeyi tercih edeceğiydi. Önümüzde örnekler mevcut mesela FUSE örneği. Geçmişte mikrokernelin avantajlarına örnek olarak verilen bir uygulama işte Linux ile de yapılabiliyor. Tabii çok daha radikal fikirler olacak ve umarım ilerde ciddi atılımlara neden olacaktır ancak kısa vadede bunların şu anki ortamı sil baştan değiştirmesi pek olası görünmüyor bana çünkü Linux bugün her yerde ve hemen her maksatla kullanılıyor (Süper biligisayar, gömülü, real time, virtualization, güvenlik açısında geliştirilmiş, masaüstü, server, cluster, NUMA, vd.). Esnekliğini ve pratik gereksinimlerin hemen hemen tümünü karşıladığı denenmiş ve biliniyor.
Donanım konusunda zaten itiraz gelmedi ama yine de biraz daha açayım. Lisp makinelerinin devri geçti derken tamamen ekonomik koşullardan bahsediyorum. Bildiğim kadarı ile o yıllarda bile ki o zamanlar bilgisayar satmak demek işletim sisteminden ek donanımlarına kadar dizayn etmenizi ve ürününüzü farklılaştırmanızı mümkün kılan yıllardı, Lisp makineleri pek fazla satmamışlar. PC donanımı günümüzde çok geniş bir alanı hegamonyasına aldı. Server, masaüstü derken iş istasyonlarının da yerine geçti.
Son olarak Ruby'nin de facto yani zorlama olmadan kendiliğinden standart olmasını beklediğimi söylemiştim. Buna inanmamın sebebi kısa zamanda diğer örneklerin yapamadığını yapabilmiş olması, web programlama konusunda iddiası (ki bu sayede yayılacaktır) ve yeni başlayandan uzmanına kadar, Java kullandan Perl kullanana kadar hemen her kesimin kullanınca "sevdiği" bir dil olması. Bu sevilme faktörü çok önemli programcıların kalbini kazanmış olması ve web programlamaya uygunluğu ona de facto standart olma yolunu açacaktır diye tahmin ediyorum.

rickdangerous
18 yıl önce

"... Bu sevilme faktörü çok önemli programcıların kalbini kazanmış olması ve web programlamaya uygunluğu ona de facto standart olma yolunu açacaktır diye tahmin ediyorum."

Tabii eklemem lazım Ruby, php gibi dillerin tersine genel amaçlı bir dil. Web programlama kesinlikle uygun olduğu tek alan değil. Zaten mevcut kütüphane desteğine bir göz atılırsa bu açıkça ortaya çıkıyor.

bm
18 yıl önce

Bildiğim kadarı ile o yıllarda bile ki o zamanlar bilgisayar satmak demek işletim sisteminden ek donanımlarına kadar dizayn etmenizi ve ürününüzü farklılaştırmanızı mümkün kılan yıllardı, Lisp makineleri pek fazla satmamışlar.

O gunun olculerine gore o sirketlerin iyi fikir gibi gozuktugu zamanlar da olmus. O zaman mesele suydu: insanlar lisp kullanmak istiyorlardi ve mevcut makineler ne lisp makinelerindeki ortami ne de performansi saglayabiliyordu. Zaman icinde once is istasyonlari sonra PCler performans acisindan yeterli hala geldiler, ve cok sattiklari icin ozel donanim bunlarla ekonomik acidan bas edemedi (bu bir bakis acisi, ozellikle Symbolics ve Xerox makineleri icin beceriksizlik, TI makineleri icin ilgisizlik filan gibi sebeplerden giderek alternatif teoriler gelistirenler de var). Gelistirme ortami acisindan bunlari yakalayan filan olmadi demek cok da abarti sayilmaz, sadece o kultur unutuldu yerine 'worse is better' prensibini destekler sekilde baska kulturler yerlesti.

Herneyse onemli olan su, bugun PC sinifi makineler lisp icin yeterli, ustelik GC filan gibi ihtiyaclar diger diller icin de gecerli oldugundan donanim/mimari tarafindan bunlari hizlandiracak (en azindan yavaslatmayacak) ozellikler dikkate aliniyor/alinacak. Lispi cok hizlandirmak icin gerekli destek de cok buyutulecek birsey degil, Franz'dan Duane Rettig ara sira comp/arch'da izah eder bunu (ilgilenenler googlayabilir). Tabii alternatif olarak Python/Ruby filan konusulacaksa zaten performanstan bahsetmek komik.

Bu sevilme faktörü çok önemli programcıların kalbini kazanmış olması ve web programlamaya uygunluğu ona de facto standart olma yolunu açacaktır diye tahmin ediyorum.

Bu o kadar da onemli degil aslinda. VB de bir takim insanlara evvelce yapamadiklarini yaptirttigi icin populer oldu mesela. Diller lisplestikce kalabaligi kendilerine cekmeleri ilginc tabii, ama benim icin asil ilginc haber kalabaligi degil Lispcileri ceken bir yeni dilin ortaya cikmasi olur.

bm
18 yıl önce

Havada kalmasin diye aklima gelen bir MS tezini aradim, bir suru kaynak olan bir yerde buldum. Ingilizce bilenler icin, AI ve onunla beraber Lisp makinesi satanlarin inis cikisina bakan bir tez: If It Works, It's Not AI: A Commercial Look at Artificial Intelligence Startups.

newman
18 yıl önce

Ben bunu kast etmemiştim.
Sizin bunu kasdettiginizi iddia etmiyorum. Daha cok benim sizin ilk mesajinizi nasil anladigimin ifadesi... Benim itiraz ettigim noktayi belirginlestirmeye calistim.
kısa vadede bunların şu anki ortamı sil baştan değiştirmesi pek olası görünmüyor O kadar emin olmayin. Zaten onemli olan mevcut ortami gun icin nasil degistirdigi degil, paradigmayi degistirmesi ve boylece gelecegi sekillendirmesi. Ozellikle bilgi-islem gibi hizli bir alanda bu surpriz olacak derecede hizli gelisebilir: Mesela, bol parali bir kurumun canina tak edip konuyla ilgili ustun teknik bilgiye ve yenilikci vizyona, dogru teshislere sahip, mevcut projelere din gibi bagli olmayan bir kadroya finasman ve koordinasyon saglamasiyla bu mumkun. Bunun getirecegi ekonomik avantaji dusunursek, bu uzak bir ihtimal degil. Buna gore hazirlik yapmak gerekli. Zira aslinda en buyuk problem, problemi gormezden gelmektir.
Son olarak "bir seyin yapilabilir" olmasi degil onemli olan, "surdurulebilir ve optimal olarak sistemin esnekligi". Yoksa insan kasinca hersey yapilabilir. Mesela eger ozel ihtiyaciniz mevcut sistemin sadece belli bir yonden modifikasyonunu gerektiriyorsa, gidip de oyle uzun boylu sistemin dizayni ile oynamiyorsunuz. Ama bohcada yamalar arttikca, gun gelir yeni yama tutmaz olur. Iste buna dair dusunmek OS yazan ve satanlarin, bu konuyu arastiranlarin isi. Elbette ki mevcut ihtiyaclar icin ne varsa onu kullanacagiz. En azindan ben bundan bahsetmiyorum.
Ruby'yi bilmiyorum. Standard olmak oyle kolay degil. Ama belli bir kesimi hedeflerlerse onlar arasinda belki ilk tercih olabilirler. Ben en cok Lisp'ten hoslaniyorum, ama standard olacak demiyorum :). Mevcut cozumlerden hepsinden acikca ustun yonlerinin oldugunu goruyorum, umarim daha az yetenekli bir sistem *standart* olmaz: 50 yildir olmamis... Gunumuz script dillerinden hicbirinin 10 yil, 15 yil sonra standard olacagina dair ikna edici bir gerekce goremiyorum ben hala.

rickdangerous
18 yıl önce

Eh, sadece Muad Dib geleceği görebilir (O da görmek istemezdi).

newman
18 yıl önce

Ama denemek keyifli :). Bu arada "Muad Dib"'in "mueddib" (terbiyecci, ogretmen) kelimesinden geldigini biliyor muydunuz? Ben surada gordum:
http://en.wikipedia.org/wiki/Muad'Dib

anonim
18 yıl önce

PC donanımı günümüzde çok geniş bir alanı hegamonyasına aldı. Server, masaüstü derken iş istasyonlarının da yerine geçti.

Aslında PC bazlı sunucu meselesi hep canımı sıkmıştır benim. İlk gençlik yıllarımda ( gavurlar teenage diyor :) ) Digital in 64 bitlik makinalarının ilanlarını görür ağzımın suları akardı. Bundan 3-5 yıl öncesine kadar iki tane 500 mhz digital 64 bit alpha işlemcili bir makina Karadeniz bölgesinin en büyük hastahanesinin tüm yükünü sırtlıyordu.

Günümüze gelirsek hangi İntel halen aynı anda iki komut işleyebilen çift çekirdekli işlemcileriyle övünedursun hangi PC tabanlı sunucu aynı anda 32 iş parçacığı çalıştırabilen 8 çekirdekli sun t1 in yanına yaklaşabiliyor ? Üstelik fiyatlarıda neredeyse aynı...

bm
18 yıl önce

Bu arada Norvig makalesinde Doug Bagley'nin ilk "shootout"una link veriyor ama Doug birakti bu isi, sayfalari da kaldirdi galiba. Herneyse arsivi surada. Yeni shootoutda o programlar yok.

misafir
18 yıl önce

Unix kültürünün has adamlarından Larry Wall'un geek code'unda şu bölümü görünce, buraya eklemeden edemedim.

GEEK EMACS CODE [!E?] 


I refuse to categorize myself on Emacs. Emacs? I don't even know what that is...

Görüş belirtmek için giriş yapın...

İlgili Yazılar

Floppy Sürücüsünden Turntable

butch
6 Ağustos 2005, 1 dakika okuma süresi

40 yıllık Floppy sürücüsünden Turntable olur mu?. Birileri niyeti bozmuş, sürücüde saklı gücü keşfetmiş ve zoru başarmış. Meraklılarına duyurulur.

/., audioorigami

Klavyede nasıl bir değişiklik istersiniz?

sundance
12 Kasım 2005, 1 dakika okuma süresi

Bir düşünün. Bilgisayarınızla iletişimde en sık kullandığınız arabirimlerden klavyenin nasıl olmasını isterdiniz? Daha fazla multimedya tuşları mı? Daha hızlı yazmaya yarayacak bir düzen mi?

Peki, her tuşun üstündeki simgenin o an çalışan programa göre değişmesine, masaüstünde duran program ikonlarınızın klavyenizde olmasına ne dersiniz?

Bir düşünün, grafik işleme programında neyin kısa yolunun olduğu yazsa, ya da rusça yazmak istediğinizde anında klavye Kril alfabesine dönse... Yapan yapıyor.

Wikipedia'yı Kim Kurcalıyor Öğrenmek İster Misiniz?

FZ
17 Ağustos 2007, 1 dakika okuma süresi

CalTech öğrencilerinden Virgil Griffith'in geliştirdiği Wikipedia Scanner aracı ile Wikipedia'daki isimsiz düzenlemelerin hangi kurumlardan veya şirketlerden geldiğini görmek mümkün.

Acil Durumlar İçin CD Zarfı Tarifleri

butch
25 Kasım 2005, 1 dakika okuma süresi

Son zamanlarda mecburiyet haline gelen toplu CD alımları, beraberinde ciddi nakil sorunları getiriyor. CD hazır, bürodan çıkacaksınız ama zarf bulmak mümkün değil. Bu adreste bulacağınız Origami CD Zarfı tarifleri işinizi görebilir.

Ev Yapımı Klima Sistemi

vst
23 Ağustos 2005, 1 dakika okuma süresi

Türk kurcalayıcıları da kurcalamaların altına imza atmaya devam ediyorlar. http://www.emre.co.uk adresinde Emre Telci'nin evinde 4 günde tamamladığı ve her günü resimlerle belgelediği bir çalışmaya ulaşabilirsiniz.

Bir pervane sistemi, bakır borular, donmuş karbondioksit gibi basit parçalardan oluşturulan ve bir Apple etiketi ile performansı arttırılan (!) ev yapı klima ilginizi çekecek.

Kurcala, kurcala, ... calakur...

Not: Orjinal fikir Geoff Milburn'e ait. Emre, projeye eğlence olsun diye başlıyor ve soğutma kapasitesini de ciddi oranda arttırıyor - 7-8 derecelik bir oda sıcaklığı değişikliğinden bahsediyoruz.