İdarəetmə fəlsəfəsi
1. İstifadəçi üçün proqramlaşdırma dilləri
Proqramlaşdırma dilləri insanların kompüterlərlə ünsiyyətinin bir yoludur. Kompüter, mənasız olmayan hər hansı bir dildə danışmağa hazırdır. Yüksək səviyyəli dillərin niyə olduğu, insanların maşın dilini başa düşə bilməməsi ilə bağlıdır. Proqramlaşdırma dillərinin mahiyyəti, zəif və həssas insan beyinlərimizi çoxsaylı detalların yükündən qorumaqdır.
Mimarlıqda, bəzi layihələndirmə problemlərinin digərlərindən daha konkret olduğunu bilirlər. Layihələndirmək üçün ən aydın və abstrakt problemlərdən biri körpülərin layihələndirilməsidir. Bu halda işiniz mümkün qədər az materialla tələb olunan məsafəni əhatə etməkdir. Digər tərəfdən isə, stul layihələndirməkdir. Stul dizaynerləri insan anatomiyasını düşünməklə vaxt sərf etməlidirlər.
Proqram təminatının inkişafı da oxşar bir fərqə malikdir. Məlumatların şəbəkə vasitəsilə yönləndirilməsi üçün alqoritmlərin layihələndirilməsi — körpü layihələndirilməsinə bənzər yaxşı, abstrakt bir problemdir. Proqramlaşdırma dillərinin layihələndirilməsi isə stul layihələndirilməsinə bənzəyir: burada insan zəiflikləri ilə başa çıxmaq lazımdır.
Bizim əksəriyyətimiz bunun fərqində olmağı çətin hesab edir. Zərif riyazi sistemlərin layihələndirilməsi, insanların zəifliklərinə qarşı gəlməkdən daha cəlbedici görünür. Riyazi zərifliyin rolu, müəyyən bir dərəcədə gözəl olan sistemlərin proqramları anlamağı asanlaşdırmasıdır. Lakin zəriflik bütün məsələlər deyil.
Və mən proqramlaşdırma dillərinin insan zəifliklərini nəzərə alaraq layihələndirilməli olduğunu söyləyəndə, bunun pis proqramçılar üçün layihələndirilməsi demək olmadığını deyirəm. Əslində siz proqramləri ən yaxşı proqramçılar üçün layihələndirməlisiniz, amma hətta ən yaxşı proqramçılar belə öz sərhədlərinə malikdirlər. Mən inanmıram ki, insanların ‘x’ hərfi ilə bütün dəyişənləri təmsil edən bir dildə proqram yazmayı sevsinlər.
2. Özünüz və dostlarınız üçün layihələndirin
Proqramlaşdırma dilləri tarixinə baxdığınız zaman, ən yaxşı dillərin əksəriyyətinin yaradıcıları tərəfindən istifadə üçün layihələndirildiyini görəcəksiniz, ən pis dillərin isə başqaları üçün layihələndirildiyini.
Dillərin başqaları üçün layihələndirildiyi zaman, bu həmişə nisbətən konkret bir insan qrupu olur: insanlar, dilin yaradıcıları ilə müqayisədə daha ağıllı deyillər. Beləliklə, sizinlə patronluq edəcək bir dil ortaya çıxır. Cobol ən parlaq nümunədir, amma əksər dillər bu ruhla doludur.
Bu dilin ne kadar yüksek seviyeli olduğu ile ilgili değildir. C yeterince düşük seviyeli bir dil, ancak yazarları tarafından kullanılmak üzere tasarlanmıştır, bu nedenle hackerlar onu sever.
Kötü programcılar için diller tasarlamanın bir avantajı, kötü programcıların iyi programcılardan daha fazla olmasıdır. Belki de öyledir. Ancak iyi programcılar orantısız bir şekilde daha fazla yazılım yazıyor.
En iyi hackerlara hitap edecek bir dil nasıl oluşturulur? Bu sorunun iyi bir programlama dili oluşturma sorusuyla aynı olduğunu düşünüyorum; ancak, bu böyle olmasa bile en azından ilginç bir soru.
3. Programcıya mümkün olduğunca fazla kontrol verin
Birçok dil (özellikle başkaları için oluşturulmuş olanlar) birer bebek bakıcısı gibi davranır: sizin için yararsız olduğunu düşündükleri şeylerden sizi korumaya çalışırlar. Ben ise zıt bir görüşe sahibim: programcıya verebileceğiniz kadar kontrol verin.
İlk kez Lisp öğrendiğimde, en çok hoşuma giden şey, eşitler düzeyinde sohbet etmemizdi. O dönemde öğrendiğim diğer dillerde, bir dil ve o dilde yazılmış bir program vardı ve bu ikisi oldukça ayrıydı. Ama Lisp'te yazdığım fonksiyonlar ve makrolar, dili oluşturanlar ile aynıydı. İstediğimde dili yeniden yazabilirdim. Açık kaynak yazılımı kadar çekici bir özellikti.
4. Kısa olmak yetenek kardeşidir
Kısalık genellikle günah sayılır ve hatta küçümsenir. Ancak hackerların kalplerine baktığınızda, kısalığı çok sevdiklerini görürsünüz. APL'de sadece birkaç satır kodla muhteşem şeyler yapabildiğini söyleyen hackerların kaç kez bu konudan heyecanla bahsettiğini duydunuz? Gerçekten zeki insanların bunun üzerinde yoğunlaşmayı sevdiğini düşünüyorum.
Bence programların daha kısa olmasına olanak tanıyan her şey iyidir. Çok sayıda kitaplık fonksiyonu olmalı, her neyin örtük olabileceği örtük olmalıdır; sözdizimi daha kısaca olmalıdır; hatta varlık isimleri de kısa olmalıdır.
Ve yalnızca programlar değil, kılavuzlar da kısa olmalıdır. Kılavuzların büyük bir kısmı açıklamalar, uyarılar, istisnalar ve özel durumlarla doludur. Kılavuzu kısaltmak zorunda kalırsanız, en iyi seçenek, bu kadar çok açıklama gerektiren dili düzeltmektir.
5. Hackerlığın ne olduğunu kabul edin
Bir çox insan, hakerliyin riyaziyyat və ya ən azından təbii elmlərə bənzədiyini arzulayır. Məncə hakerlik daha çox memarlıq kimidir. Memarlıq fizikaya bağlıdır, çünki memar, dağılmayan bir bina layihələndirməlidir, amma memarın əsas məqsədi böyuk bir bina yaratmaqdır, statikada kəşflər etmək deyil.
Hakerlərin sevdiyi, əla proqramlar yaratmaqdır. Və düşünürəm ki, ən azından öz düşüncələrimizdə, mükəmməl proqramlar yazmağın əla olduğunu unutmağıg lazım deyil, hətta bu iş adi elmi işlərə çevrilməsə də. İntellektual cəhətdən, proqramçıların sevdiyi bir dili inkişaf etdirmək və bu ideyanı əks etdirən bir şeyi yaratmaq, elə də vacibdir ki, bu haqda bir məqalə yayımlaya bilərsiniz.
Açıq problemlər
1. Böyük kitabxanaları necə təşkil etmək olar?
Kitabxanalar proqramlaşdırma dillərinin mühüm bir hissəsi halına gəlir. Onlar çox genişləndikcə, bu təhlükəli ola bilər. Əgər kitabxanada lazım olan funksiyanı tapmaq üçün daha çox vaxt lazımdırsa, özünüz bu funksiyanı yazmaqdan daha çox, o zaman bütün kod yalnızca təlimatınızı qabartmaqdan başqa bir şey etməz. (Symbolics təlimatları bunun bir nümunəsi idi.) Beləliklə, kitabxanaların təşkilati problemini həll etməliyik. İdeal olaraq, onları layihələndirmək lazımdır ki, proqramçı hansı kitabxana funksiyasının uyğun olduğunu anlaya bilsin.
2. İnsanlar həqiqətən prefiks sintaksisindən qorxurlar?
Bu açıq bir problemdir, çünki mən bu barədə bir neçə il düşündüm və hələ də cavabını bilmirəm. Prefiks sintaksisi, matematikada istifadə edilməsindən başqa, mənə tamamilə təbii görünür. Amma ola bilər ki, Lisp-lərin populyarsızlığının çoxu, sadəcə tanış olmayan sintaksisdən asılıdır... Əgər bu doğrudursa, bununla bağlı bir şey etmək lazımdırmı, bu isə başqa bir sualdır.
3. Server proqram təminatı üçün nəyə ehtiyacınız var?
Düşünürəm ki, gələcək iyirmi ildə yazılacaq əksər tətbiqlər veb tətbiqləri olacaq, yəni proqramlar serverdə yerləşəcək və sizinlə veb brauzeri vasitəsilə ünsiyyət quracaq. Və belə tətbiqləri yazmaq üçün bizə yeni şeylər lazımdır.
Bunlardan biri, server tətbiqlərinin yeni bir buraxılış üsulunu dəstəkləməkdir. İl ərzində bir və ya iki böyük buraxılış yerinə, desktop proqramlarında olduğu kimi, server proqramları bir sıra kiçik dəyişikliklər ilə buraxılacaq. Gündə beş və ya on buraxılışınız ola bilər. Və hər kəs hər zaman son versiyaya sahib olacaq.
Proqramları dəstəklənə biləcək şəkildə necə layihələndirməyi bilirsinizmi? Server proqram təminatı dəyişikliklərə uyğun şəkildə layihələndirilməlidir. Onu asanlıqla dəyişmək imkanı olmalıdır, ya da ən azından kiçik bir dəyişikliyin nə olduğunu və nəyin vacib olduğunu bilmək lazımdır.
Server proqram təminatında faydalı ola biləcək başqa bir şey isə, gözlənilməz şəkildə, davamlı çatdırılmadır. Veb tətbiqində bunu istifadə edə bilərsiniz, məsələn, , veb sessiyaları dünyasında alt proqramların təsirini əldə etmək üçün. Əgər bu imkan çox bahalı olmasa, davamlı çatdırılma dəyərli ola bilər.
4. Hələ kəşf edilməmiş yeni abstraksiyalar hansılardır?
Bu ümidin nə qədər məqbul olduğunu bilmirəm, amma şəxsən mən yeni bir abstraksiyanın – birinci dərəcəli funksiyalar və ya rekursiya, ya da ən azından standart parametrlər qədər əhəmiyyətli ola biləcək bir şeyin kəşf edilməsini çox istərdim. Bu, mümkünsüz bir xəyal ola bilər. Belə şeylər tez-tez kəşf edilmir. Amma ümidimi itirmirəm.
Az bilinən sirrlər
1. İstədiyiniz hər hansı bir dili istifadə edə bilərsiniz
Əvvəllər tətbiq yaratmaq, masaüstü proqram təminatı yaratmaq mənasını verirdi. Və masaüstü proqram təminatında əməliyyat sisteminin eyni dilində tətbiq yazmağa böyük meyl var idi. Beləliklə, on il əvvəl proqram təminatını yaratmaq, ümumilikdə C dilində proqram yazmaq demək idi. Nəhayət, ənənə inkişaf etdi: tətbiqlər qeyri-adi dillərdə yazılmalıdır. Və bu ənənə o qədər inkişaf etdi ki, texniki olmayan insanlar, məsələn, menecerlər və investisiya kapitalçıları da bunu öyrəndilər.
Server proqram təminatı bu modeli tamamilə dağıdır. Server proqram təminatı ilə istədiyiniz hər hansı bir dili seçə bilərsiniz. Demək olar ki, hələ bunun fərqində olan heç kim yoxdur (xüsusilə menecerlər və investisiya kapitalçıları). Amma bəzi hakerlər bunu başa düşür, buna görə də Perl və Python kimi müstəqil dillərdən danışırıq. Biz Perl və Python-dan danışmırıq, çünki insanlar onları Windows üçün tətbiqlər yazmaq məqsədilə istifadə edirlər.
Bu bizim üçün – proqramlaşdırma dillərinin layihələndirilməsi ilə maraqlanan insanlar üçün nə deməkdir, bunun üçün işimiz üçün potensial bir auditoriyanın olduğunu göstərir.
2. Sürət profaylçılardan gəlir
Dil inkişaf etdiriciləri və ya ən azından onun yerinə yetiriciləri, sürətli kod yaradan kompilatorlar yazmağı sevirlər. Amma düşünürəm ki, bu, dillərin istifadəçilər üçün sürətli olmasını təmin etmir. Knuth uzun müddət əvvəl qeyd etmişdi ki, sürət bir neçə dar boğazdan asılıdır. Və proqramı sürətləndirməyə cəhd edən hər kəs bilir ki, dar boğazın harada olduğunu proqnozlaşdıra bilməzsiniz. Profayler bu cür bir cavabdır.
Dil inkişaf etdiriciləri səhv bir problemi həll edirlər. İstifadəçilərin tez bənçmarklar işləməyə ehtiyacı yoxdur. Onların ehtiyacı olan şey, proqramlarının hansı hissələrinin yenidən yazılması lazım olduğunu göstərən bir dildir. Bu an praktiki sürətə ehtiyac var. Beləliklə, bəlkə də dilin implementatorları kompilatorun optimizasiyasına sərf etdikləri vaxtın yarısını yaxşı bir profilaktor yazmağa sərf etsələr daha yaxşı olar.
3. Sizin dilin inkişaf etməsini təmin edən bir tətbiqə ehtiyacınız var
Bu, son instansiya həqiqəti olmaya bilər, lakin görünür ki, ən yaxşı dillər istifadə edildikləri tətbiqlərlə birlikdə inkişaf etmişdir. C dili, sistem proqramlaşdırmasına ehtiyacı olan insanlar tərəfindən yazılmışdır. Lisp bir hissədən simvolik diferensiallaşdırma üçün hazırlanmışdır, McCarthy buğdaya başlamaq üçün o qədər səbirsiz idi ki, 1960-cı ildə Lisp haqqında yazdığı ilk sənəddə diferensiallaşdırma proqramlarını yazmağa başlayıb.
Bu, xüsusilə yaxşıdır, əgər tətbiqiniz bəzi yeni problemləri həll edirsə. Bu, dilinizin proqramçılara lazım olan yeni imkanlarına sahib olmasına təşviq edir. Şəxsən, server tətbiqləri üçün yaxşı olacaq bir dil yazmaq maraqlıdır.
[Müzakirə zamanı Guy Steele bu fikri də irəliləyərək dedi ki, tətbiqiniz diliniz üçün bir kompilator yazmaqdan ibarət olmamalıdır, əgər diliniz kompilator yazmaq üçün nəzərdə tutulmayıbsa.]
4. Dil, bir dəfəlik proqramların yazılması üçün uyğun olmalıdır.
Bir dəfəlik proqramın nə olduğunu bilirsiniz: bu, sizə məhdud bir problemi tez bir zamanda həll etmək lazım olanda baş verir. Əminəm ki, ətrafınıza baxsanız, bir çox ciddi proqramların bir dəfəlik proqramlar olaraq başladığını görəcəksiniz. Əgər böyük əksəriyyət proqramların bir dəfəlik başlanğıçdan başladığını görsəm, təəccüblənməyəcəyəm. Beləliklə, əgər siz, ümumi proqram yazmaq üçün uyğun olan bir dil yaratmaq istəyirsinizsə, bu dilin də bir dəfəlik proqramlar yazılması üçün uyğun olması lazım, çünki bu, bir çox proqramın başlanğıc mərhələsidir.
5. Sintaksis semantika ilə əlaqəlidir
Adətən sintaksis və semantikanın bir-birindən çox fərqli şeylər olduğu düşünülür. Bu, şok edici səslənə bilər, amma belə deyil. Düşünürəm ki, proqramınızda əldə etmək istədiyiniz şey, onu necə ifadə etdiyinizlə bağlıdır.
Yaxınlarda Robert Morris ilə söhbət etdim və o, operatorların yüklənməsinin infiks sintaksisli dillərin qələbəsində böyük üstünlük olduğunu qeyd etdi. Prefiks sintaksisli dillərdə təyin etdiyiniz hər hansı bir funksiya əslində bir operator olur. Əgər yaratdığınız yeni növ ədədi toplamaq istəyirsinizsə, onun üçün yeni bir toplama funksiyası sadəcə təyin edə bilərsiniz. Əgər bunu infiks sintaksisli dildə etsəniz, yüklənmiş operatorun istifadəsi ilə funksiyanın çağırılması arasında böyük bir fərq olduğunu görəcəksiniz.
Vaxt keçdikcə geri qayıdan fikirlər
1. Yeni proqramlaşdırma dilləri
1970-ci illərə baxanda yeni proqramlaşdırma dilləri yaratmaq dəbdə idi. İndi bunun əksi baş verir. Ancaq düşünürəm ki, server proqram təminatı yenidən yeni dillərin yaradılması dəbini qaytaracaq. Server proqram təminatında istədiyiniz hər hansı bir dildən istifadə edə bilərsiniz, buna görə də kiminsə qalanlarından daha yaxşı görünən bir dil yaratması halında, onu istifadə etməyə cəsarət edən insanlar olacaq.
2. İndiki zamanın bölünməsi
Richard Kelsey bu fikri irəli sürdü, indi bu fikrin yenidən vaxtı gəlib və mən onu tam dəstəkləyirəm. Mənim təxminim (həmçinin Microsoft-un da) çoxlu hesablamalar masaüstündən uzaq serverlərə köçəcək. Yəni, vaxtın bölünməsi geri qayıdır. Düşünürəm ki, bunun dil səviyyəsində dəstəyi lazım olacaq. Məsələn, Richard və Jonathan Reeves proseslərin planlaşdırılması üçün Scheme 48-də çox iş görüblər.
3. Effektivlik
Son zamanlarda kompüterlərin artıq kifayət qədər sürətli olduğu görünürdü. Daha da çox, byte-koddan bəhs edən xəbərlər eşidirik, bu, ən azı mənim üçün, aramızda güc olduğunu göstərir. Ancaq düşünürəm ki, server proqram təminatında bu belə deyil. Birisi ödəniş etməlidir serverlər, proqramın icra edildiyi serverlər üçün və bir maşına görə serverin çəkə biləcəyi istifadəçi sayı onların kapital xərclərinin böləni olacaq.
Düşünürəm ki, effektivlik xüsusən hesablamaların dar yerlərində əhəmiyyətli olacaq. Xüsusilə giriş-çıxış əməliyyatları üçün bu, əhəmiyyətli olacaq, çünki server tətbiqləri çox sayda belə əməliyyatlar yaradır.
Nəhayət, byte-kodun çıxış yolu olmadığını aşkar edə bilərik. Sun və Microsoft hal-hazırda byte-kod müharibəsində üz-üzə görünürlər. Ancaq bunlar byte-kodun prosesə daxil olması üçün rahat bir yer olması səbəbindən baş verir, byte-kodun öz-özlüyündə yaxşı bir fikir olması səbəbindən deyil. Bu bütün mübarizənin nəzərə alınmadan baş verməsi də ola bilər. Bu, əyləncəli olardı.
Təhlükələr və tələlər
1. Müştərilər
Bu yalnızca bir varsayım, ancak tamamen sunucu tabanlı uygulamaların kazanacağını düşünüyorum. Herkesin sizin istemciniz olacağını varsayarak yazılım tasarlamak, herkesin dürüst olacağı varsayımına dayalı bir toplum oluşturmak gibidir. Bu kesinlikle kullanışlı olurdu, ama bunun asla olmayacağını kabul etmeniz gerekebilir.
Bence web erişimi olan cihazların hızlı bir artışı olacak ve bunların temel HTML ve formları desteklemesi gerektiği varsayılabilir. Telefonunuzda tarayıcı var mı? PalmPilot'ınızda telefon olacak mı? Blackberry'nizde daha büyük bir ekran olacak mı? Gameboy'unuzdan internete çıkma imkanınız olacak mı? Saatlerinizden? Bilmiyorum. Eğer her şeyin sunucuda olacağına bahse girersem bunu öğrenmeme gerek kalmayacak. Tüm zekayı sunucuda tutmak çok daha güvenilir.
2. Nesne yönelimli programlama
Bunun çelişkili bir ifade olduğunu anlıyorum, ancak nesne yönelimli programlamanın önemli bir şey olduğunu düşünmüyorum. Bence bu, pencere sistemleri, simülasyonlar, CAD sistemleri gibi belirli uygulamalar için uygun bir paradigma. Ama neden herkes için uygun olması gerektiğini anlamıyorum.
Büyük şirketlerdeki insanların OOP'yi sevmesinin bir nedeni, bu yaklaşımın işi yapıyormuş gibi görünen birçok şeyi sağlamasıdır. Doğal olarak, örneğin, bir tam sayı listesi olarak temsil edilebilecek bir şey artık tüm türden iskeleler ve gürültüle doldurulmuş bir sınıf olarak temsil edilebilir.
OOP'nin diğer çekici yönü, yöntemlerin size birinci sınıf işlevler etkisi sağlamasıdır. Ancak bu, Lisp programcıları için yeni bir şey değil. Gerçek birinci sınıf işlevleriniz olduğunda, bunları, oluşturulan göreve uygun herhangi bir şekilde kullanabilirsiniz, sınıflar ve yöntemlerin şablonuna zorlamak yerine.
Bu, dil tasarımı için, OOP'yi içerisine derinlemesine yerleştirmemeniz gerektiği anlamına geldiğini düşünüyorum. Belki de cevap, daha genel, temel şeyler sunmak ve insanların herhangi bir nesne tabanlı sistemi kütüphaneler halinde tasarlamalarına izin vermektir.
3. Komite ile tasarım
Eğer diliniz bir komite tarafından tasarlanıyorsa, bir çıkmazdasınız ve bu herkesin bildiği nedenlerden dolayı değil. Komitelerin genellikle karmaşık ve tutarsız bir dil tasarımı ürettiği herkesçe biliniyor. Ama bence büyük bir tehlike, riskleri üstlenmemeleridir. Eğer bir kişi başta ise, o kişi, komitenin asla üstlenmeyecekleri riskleri alır.
Yaxşı bir dil yaratmaq üçün riskə getmək gərəkdirmi? Bir çox insanlar dilin layihələndirilməsinin ənənəvi müdrikliyə yaxın qalmalı olduğuna şübhə ilə yanaşa bilərlər. Mən mübahisə edə bilərəm ki, bu, belə deyil. İnsanların etdikləri bütün digər sahələrdə, mükafat riskə mütənasibdir. Bəs niyə dillərin layihələndirilməsi başqa cür olmalıdır?
Mənbə: habr.com
