Жетекші философия
1. Адамдарға арналған бағдарламалау тілдері
Бағдарламалау тілдері - бұл адамдардың компьютермен сөйлесу тәсілі. Компьютер екі мағыналы емес кез келген тілде сөйлеуге қуанышты болады. Бізде жоғары деңгейлі тілдердің себебі - адамдар машина тілін басқара алмайды. Бағдарламалау тілдерінің мәні - біздің кедей, нәзік адам миының тым көп бөлшектерге толып кетуіне жол бермеу.
Сәулетшілер кейбір дизайн мәселелері басқаларға қарағанда қарапайым екенін біледі. Ең айқын және абстрактілі дизайн мәселелерінің кейбірі көпірлердің дизайны болып табылады. Бұл жағдайда сіздің міндетіңіз - мүмкіндігінше аз материалмен қажетті қашықтықты еңсеру. Спектрдің екінші жағында орындық дизайны бар. Орындық дизайнерлері уақытын адамдардың бөксесі туралы ойлауға жұмсауы керек.
Бағдарламалық жасақтаманы әзірлеуде ұқсас айырмашылық бар. Желі арқылы деректерді бағыттау үшін алгоритмдерді жобалау - көпірлерді жобалау сияқты жақсы, дерексіз мәселе. Бағдарламалау тілдерін жобалау орындықтарды жобалау сияқты: адамның әлсіз жақтарымен күресу керек.
Мұны көпшілігімізге түсіну қиын. Талғампаз математикалық жүйелерді жобалау көбімізге адамның әлсіз жақтарын сынаудан әлдеқайда тартымды көрінеді. Математикалық талғампаздықтың рөлі мынада: кейбір талғампаздық дәрежесі бағдарламаларды түсінуді жеңілдетеді. Бірақ бәрі талғампаздықта емес.
Мен тілдер адамның әлсіз жақтарын ескере отырып жасалуы керек деп айтсам, мен тілдер нашар бағдарламашыларға арналған болуы керек дегенді білдірмеймін. Шындығында, сіз ең жақсы бағдарламашылар үшін бағдарламалық жасақтаманы жасауыңыз керек, бірақ ең жақсы бағдарламашылардың да өз шегі бар. Менің ойымша, барлық айнымалылар бүтін сандармен «x» әрпімен белгіленген тілде бағдарламалау ешкімге ұнамайды.
2. Өзіңізге және достарыңызға дизайн жасаңыз
Бағдарламалау тілдерінің тарихына қарасаңыз, ең жақсы тілдердің көпшілігі өз авторларымен, ал ең нашарлары басқа адамдар пайдалану үшін жасалған.
Тілдер басқа адамдарға арналған болса, бұл әрқашан белгілі бір адамдар тобы: адамдар тілді жасаушылар сияқты ақылды емес. Осылайша сіз өзіңізге сөйлейтін тілге ие боласыз. Кобол - ең көрнекті мысал, бірақ көптеген тілдер осы рухпен сусындаған.
Бұл тілдің қаншалықты жоғары деңгейде екеніне еш қатысы жоқ. C деңгейі өте төмен, бірақ оны авторлары пайдалану үшін жасаған, сондықтан хакерлер оны жақсы көреді.
Нашар бағдарламашылар үшін тілдерді жобалаудың дәлелі - жақсыларға қарағанда жаман бағдарламашылар көп. Мүмкін бұл солай шығар. Бірақ жақсы бағдарламашылардың бұл аз саны пропорционалды түрде көбірек бағдарламалық жасақтаманы жазады.
Менің сұрағым, ең жақсы хакерлерге ұнайтын тілді қалай жасауға болады? Менің ойымша, бұл сұрақ жақсы бағдарламалау тілін қалай жасауға болады? деген сұраққа ұқсас сияқты, бірақ олай болмаса да, бұл ең болмағанда қызықты сұрақ.
3. Бағдарламалаушыға мүмкіндігінше бақылауды беріңіз
Көптеген тілдер (әсіресе басқа адамдарға арналған) күтуші сияқты әрекет етеді: олар сізге пайдалы емес деп санайтын нәрселерден аулақ болуға тырысады. Мен керісінше көзқарасты ұстанамын: бағдарламашыға мүмкіндігінше көп бақылау беріңіз.
Мен Лиспті алғаш үйренген кезде, маған ең ұнағаны - екеуміздің теңдей сөйлескеніміз. Осы уақытқа дейін мен үйренген басқа тілдерде тіл болды, сол тілде менің бағдарламам болды және олар мүлдем бөлек болды. Бірақ Лиспте мен жазған функциялар мен макростар тілдің өзі жазылған функциялар болды. Мен қаласам, тілдің өзін қайта жаза алар едім. Ол ашық бастапқы бағдарламалық қамтамасыз ету сияқты тартымды болды.
4. Қысқалық – таланттың қарындасы
Қысқалық төмен бағаланады, тіпті менсінбейді. Бірақ егер сіз хакерлердің жүрегіне үңілсеңіз, олардың шынымен қысқалықты жақсы көретінін көресіз. Сіз хакерлердің, айталық, APL-де кодтың бірнеше жолы арқылы таңғажайып нәрселерді қалай жасай алатыны туралы сүйіспеншілікпен сөйлесетінін қанша рет естідіңіз? Менің ойымша, шынымен де ақылды адамдар бұған назар аударғанды ұнатады.
Бағдарламаларды қысқартатын кез келген дерлік жақсы нәрсе деп ойлаймын. Кітапхана функциялары көп болуы керек, жасырын болуы мүмкін барлық нәрсе солай болуы керек; синтаксис неғұрлым қысқа болуы керек; тіпті нысан атаулары да қысқа болуы керек.
Бағдарламалар ғана емес, қысқа болуы керек. Нұсқаулықтар да қысқа болуы керек. Нұсқаулықтардың жақсы бөлігі түсіндірмелермен, бас тартулармен, ескертулермен және ерекше жағдайлармен толтырылған. Нұсқаулықты қысқарту қажет болса, ең жақсы нұсқа - көп түсіндіруді қажет ететін тілді түзету.
5. Бұзушылықтың не екенін түсініңіз
Көптеген адамдар хакерлік математика немесе кем дегенде ғылымға ұқсас нәрсе болғанын қалайды. Менің ойымша, хакерлік архитектура сияқты. Сәулет физикаға қатысты, өйткені сәулетші құламайтын ғимаратты жобалау керек, бірақ сәулетшінің нақты мақсаты - статика саласында жаңалықтар ашу емес, керемет ғимарат жасау.
Хакерлерге ұнайтыны - керемет бағдарламалар жасау. Менің ойымша, ең болмағанда өз ойымызша, бұл жұмыс ғылыми мақалалардың әдеттегі интеллектуалды валютасына оңай ауыспаса да, керемет бағдарламалар жазу керемет нәрсе екенін есте ұстауымыз керек. Зияткерлік тұрғыдан алғанда, бағдарламашыларға ұнайтын тілді жобалау маңызды, ол сіз туралы мақала жариялауға болатын идеяны қамтитын қорқынышты тілді жобалау сияқты маңызды.
Ашық мәселелер
1. Ірі кітапханалар қалай ұйымдастырылады?
Кітапханалар программалау тілдерінің маңызды бөлігіне айналуда. Олар соншалықты үлкен болады, бұл қауіпті болуы мүмкін. Кітапханада өзіңізге қажетті функцияны табу үшін сол функцияны өзіңіз жазудан гөрі көп уақыт қажет болса, онда барлық код нұсқаулықты қалыңдатудан басқа ештеңе етпейді. (Символикалық нұсқаулықтар бұған мысал болды.) Сондықтан біз кітапхананы ұйымдастыру мәселесін шешуіміз керек. Ең дұрысы, оларды бағдарламашы қай кітапхана функциясы қолайлы екенін болжай алатындай етіп жасаңыз.
2. Адамдар префикс синтаксисінен шынымен қорқады ма?
Бұл мен бірнеше жыл бойы ойланып келе жатқан және әлі де жауабын білмегендіктен ашық мәселе. Префикс синтаксисі мен үшін табиғи болып көрінеді, мүмкін оның математикада қолданылуын қоспағанда. Бірақ, мүмкін, Лисптің танымалдылығының көп бөлігі бейтаныс синтаксиске байланысты шығар... Бұл туралы бірдеңе істеу керек пе, егер рас болса, бұл басқа мәселе.
3. Сервердің бағдарламалық жасақтамасы үшін не қажет?
Менің ойымша, алдағы жиырма жылда жазылатын қосымшалардың көпшілігі веб-қосымшалар болады, яғни бағдарламалар серверде орналасады және сізбен веб-шолғыш арқылы байланысады. Ал мұндай қосымшаларды жазу үшін бізге жаңа нәрселер керек.
Олардың бірі серверлік қосымшаларды шығарудың жаңа әдісін қолдау болып табылады. Жұмыс үстеліндегі бағдарламалық құрал сияқты жылына бір немесе екі үлкен шығарылымның орнына серверлік бағдарламалық құрал шағын өзгерістер сериясымен шығарылады. Сізде күніне бес немесе он шығарылым болуы мүмкін. Әркімде әрқашан соңғы нұсқасы болады.
Сіз қолдауға болатын бағдарламаларды қалай жасау керектігін білесіз бе? Сервердің бағдарламалық жасақтамасы өзгермелі етіп жасалуы керек. Сіз оны оңай өзгерте алуыңыз керек немесе ең болмағанда болмашы өзгерістің нені білдіретінін және не маңызды екенін білуіңіз керек.
Серверлік бағдарламалық құралда пайдалы болуы мүмкін тағы бір нәрсе - кенеттен жеткізілімнің үздіксіздігі. Веб-қосымшада сіз осындай нәрсені пайдалана аласыз веб-сеанстардың азаматтығы жоқ әлеміндегі тәртіптердің әсерін алу. Функция тым қымбат болмаса, жеткізудің үздіксіздігіне ие болуы мүмкін.
4. Қандай жаңа абстракцияларды ашу керек?
Мен бұл үміттің қаншалықты орынды екенін білмеймін, бірақ жеке өзім жаңа абстракцияны ашқым келеді - бірінші дәрежелі функциялар немесе рекурсия немесе кем дегенде әдепкі параметрлер сияқты мағыналы болуы мүмкін нәрсе. Мүмкін бұл орындалмайтын арман шығар. Мұндай нәрселер жиі ашылмайды. Бірақ мен үмітімді үзбеймін.
Аз белгілі құпиялар
1. Сіз өзіңіз қалаған кез келген тілді пайдалана аласыз
Бұрын қолданбалы бағдарламаларды жасау жұмыс үстелі бағдарламалық жасақтамасын жасауды білдіреді. Жұмыс үстеліндегі бағдарламалық жасақтамада қолданбаларды операциялық жүйемен бір тілде жазуға үлкен бейімділік бар. Осылайша, он жыл бұрын бағдарламалық жасақтаманы жалпы түрде жазу Си тілінде бағдарламалық жасақтаманы жазуды білдіреді. Ақырында, дәстүр дамыды: қолданбаларды әдеттен тыс тілдерде жазуға болмайды. Бұл дәстүр ұзақ уақыт бойы дамығаны сонша, менеджерлер мен венчурлық капиталистер сияқты техникалық емес адамдар да оны үйренді.
Сервер бағдарламалық құралы бұл модельді толығымен бұзады. Сервер бағдарламалық құралының көмегімен сіз кез келген тілді пайдалана аласыз. Мұны әлі ешкім дерлік түсінбейді (әсіресе менеджерлер мен венчурлық капиталистер). Бірақ кейбір хакерлер мұны түсінеді, сондықтан біз Perl және Python сияқты инди тілдері туралы естиміз. Біз Perl және Python туралы естімейміз, өйткені адамдар оларды Windows қолданбаларын жазу үшін пайдаланады.
Бұл біз үшін, бағдарламалау тілінің дизайнына қызығушылық танытқан адамдар үшін, біздің жұмысымыз үшін әлеуетті аудитория бар дегенді білдіреді.
2. Жылдамдық профильдеушілерден келеді
Тіл әзірлеушілері немесе кем дегенде тілді жүзеге асырушылар жылдам кодты жасайтын компиляторларды жазғанды ұнатады. Бірақ менің ойымша, бұл пайдаланушылар үшін тілдерді жылдам ететін нәрсе емес. Кнут баяғыда жылдамдықтың бірнеше кедергілерге байланысты екенін атап өтті. Бағдарламаны жылдамдатуға тырысқан кез келген адам қай жерде тығырық барын болжай алмайтыныңызды біледі. Профилатор - бұл жауап.
Тіл әзірлеушілер қате мәселені шешуде. Пайдаланушыларға жылдам жұмыс істеу үшін эталондар қажет емес. Оларға өз бағдарламасының қай бөліктерін қайта жазу керектігін көрсететін тіл қажет. Бұл кезде тәжірибеде жылдамдық қажет. Сондықтан тілді енгізушілер компиляторды оңтайландыруға жұмсайтын уақытының жартысын жұмсап, оны жақсы профильді жазуға жұмсаса жақсы болар еді.
3. Тіліңізді дамытатын қолданба қажет
Бұл түпкілікті шындық болмауы мүмкін, бірақ ең жақсы тілдер олар қолданылған қолданбалармен бірге дамыған сияқты. C тілін жүйелік бағдарламалауды қажет ететін адамдар жазған. Лисп ішінара символдық дифференциацияға арналған және МакКарти бастауға соншалықты ынталы болды, ол тіпті 1960 жылы бірінші Lisp қағазында дифференциация бағдарламаларын жаза бастады.
Қолданбаңыз кейбір жаңа мәселелерді шешсе, бұл әсіресе жақсы. Бұл сіздің тіліңізді бағдарламашылар қалаған жаңа мүмкіндіктерге итермелейді. Жеке өзім серверлік қосымшалар үшін жақсы болатын тілді жазуға қызығамын.
[Талқылау барысында Гай Стил де осы ойды айтты, егер сіздің тіліңіз компиляторларды жазуға арналмаған болса, қолданба сіздің тіліңіз үшін компилятор жазудан тұрмауы керек деп қосты.]4. Тіл бір реттік бағдарламаларды жазуға жарамды болуы керек.
Сіз бір реттік бағдарламаның нені білдіретінін білесіз: бұл сізге кейбір шектеулі мәселені жылдам шешу қажет болғанда. Егер сіз айналаңызға қарасаңыз, сіз бір реттік ретінде басталған көптеген маңызды бағдарламаларды таба аласыз деп ойлаймын. Бағдарламалардың көпшілігі бір реттік ретінде басталса, мен таң қалмас едім. Осылайша, егер сіз жалпы бағдарламалық жасақтаманы жазуға қолайлы тілді жасағыңыз келсе, онда ол бір реттік бағдарламаларды жазу үшін де қолайлы болуы керек, өйткені бұл көптеген бағдарламалардың бастапқы кезеңі.
5. Синтаксис семантикамен байланысты
Дәстүрлі түрде синтаксис пен семантика мүлдем басқа нәрсе деп саналады. Бұл таңқаларлық көрінуі мүмкін, бірақ олай емес. Менің ойымша, сіздің бағдарламаңызда қол жеткізгіңіз келетін нәрсе оны қалай білдіретініңізге байланысты.
Мен жақында Роберт Морриспен сөйлестім, ол оператордың шамадан тыс жүктелуі infix синтаксисі бар тілдердің жеңісі үшін үлкен плюс екенін атап өтті. Префикс синтаксисі бар тілдерде сіз анықтаған кез келген функция шын мәнінде оператор болып табылады. Өзіңіз құрастырған санның жаңа түрін қосқыңыз келсе, оны қосу үшін жай ғана жаңа функцияны анықтауға болады. Егер сіз мұны infix синтаксисі бар тілде жасасаңыз, шамадан тыс жүктелген операторды пайдалану мен функцияны шақыру арасында үлкен айырмашылық бар екенін көресіз.
Уақыт өте келе оралатын идеялар
1. Жаңа программалау тілдері
Өткен ғасырдың 1970-жылдарына көз жүгіртсек, жаңа бағдарламалау тілдерін жасау сәнге айналды. Қазір олай емес. Бірақ мен серверлік бағдарламалық қамтамасыз ету жаңа тілдерді жасау сәнін қайтадан қайтарады деп сенемін. Серверлік бағдарламалық жасақтамамен сіз қалаған кез келген тілді пайдалана аласыз, сондықтан біреу басқаларға қарағанда жақсы көрінетін тілді жасаса, оны қолдануды шешетін адамдар болады.
2. Уақытты бөлісу
Бұл идеяны Ричард Келси ойлап тапты, оның уақыты тағы келді және мен оны толығымен қолдаймын. Менің болжауымша (және Microsoft компаниясы да) көптеген есептеуіш жұмыс үстелінен қашықтағы серверлерге ауысады. Басқаша айтқанда, уақытты бөлісу кері қайтарылды. Менің ойымша, бұл тіл деңгейінде қолдауды қажет етеді. Мысалы, Ричард пен Джонатан Ривз 48-схемада процесті жоспарлауды жүзеге асыру үшін көп жұмыс атқарды.
3. Тиімділік
Жақында компьютерлер жеткілікті жылдам болып көрінді. Біз байт-код туралы көбірек естиміз, бұл, кем дегенде, мен үшін резервте біраз қуат бар дегенді білдіреді. Бірақ менің ойымша, серверлік бағдарламалық жасақтамада ол бізде жоқ. Біреу бағдарламалық жасақтаманы іске қосатын серверлер үшін төлеуге мәжбүр болады және сервер бір машинаға қолдау көрсете алатын пайдаланушылар саны олардың капиталдық шығындарының бөлгіші болады.
Менің ойымша, тиімділік, кем дегенде, есептеу қиыншылықтарында маңызды болады. Бұл әсіресе енгізу-шығару операциялары үшін маңызды болады, өйткені серверлік қолданбалар мұндай операциялардың көп бөлігін орындайды.
Ақыр соңында, байт-код жауап емес болып шығуы мүмкін. Қазіргі уақытта Sun және Microsoft байт код өрісінде бетпе-бет келе жатқан сияқты. Бірақ олар мұны байт кодтың өзі жақсы идея болғандықтан емес, процеске ендіруге ыңғайлы орын болғандықтан жасайды. Бұл шайқастың бәрі елеусіз қалатын шығар. Бұл күлкілі болар еді.
Тұзақтар мен тұзақтар
1. Клиенттер
Бұл жай ғана болжам, бірақ тек сервер жағындағы қолданбалар пайда көреді. Әркімнің тұтынушысы болады деген болжаммен жұмыс істейтін бағдарламалық жасақтаманы жобалау бәрі адал болады деген болжамға негізделген қоғамды жобалаумен бірдей. Бұл, әрине, ыңғайлы болар еді, бірақ бұл ешқашан болмайды деп болжауға тура келеді.
Менің ойымша, веб-қосылатын құрылғылардың тез өсуі болады және олар негізгі html және пішіндерді қолдайды деп болжауға болады. Телефоныңызда браузер бар ма? Сіздің PalmPilot телефоныңыз болады ма? Сіздің BlackBerry үлкенірек экран болады ма? Сіз геймбойыңыздан Интернетке қол жеткізе аласыз ба? Сағатыңыздан? Мен білмеймін. Егер мен бәрі серверде болады деп бәс тігемін бе, білуге міндетті емеспін. Серверде барлық мидың болуы әлдеқайда сенімді. .
2. Объектіге бағытталған программалау
Мен бұл даулы мәлімдеме екенін түсінемін, бірақ OOP соншалықты маңызды емес деп ойлаймын. Менің ойымша, бұл терезе жүйелері, модельдеу, CAD жүйелері сияқты нақты деректер құрылымдарын қажет ететін нақты қолданбалар үшін қолайлы парадигма. Бірақ мен түсінбеймін, неге ол барлық бағдарламаларға жарамды болуы керек.
Менің ойымша, ірі компаниялардағы адамдар OOP-ны ішінара жақсы көреді, өйткені ол жұмысқа ұқсайтын көп нәрсені жасайды. Табиғи түрде, айталық, бүтін сандар тізімі ретінде ұсынылуы мүмкін нәрсені енді әр түрлі құрылыстар, қарбаластар мен қарбаластар бар сынып ретінде көрсетуге болады.
OOP-тың тағы бір тартымды ерекшелігі - әдістер сізге бірінші дәрежелі функциялардың кейбір әсерін береді. Бірақ бұл Lisp бағдарламашылары үшін жаңалық емес. Сізде шынайы бірінші дәрежелі функциялар болған кезде, бәрін сыныптар мен әдістердің қазандық тақтасына итермелеудің орнына, оларды тапсырмаға сәйкес келетін кез келген жолмен пайдалануға болады.
Менің ойымша, бұл тіл дизайны үшін нені білдіреді, оған OOP тым терең енгізбеу керек. Мүмкін жауап жалпы, негізді нәрселерді ұсыну және адамдарға кез келген объектілік жүйелерді кітапхана ретінде жобалауға мүмкіндік беру.
3. Жобалау комитетімен
Егер сіздің тіліңізді комитет жасаған болса, онда сіз бәріне белгілі себептермен ғана емес, тұзаққа түсесіз. Әркім комитеттердің біркелкі, сәйкес келмейтін тілдік дизайнды жасауға бейім екенін біледі. Бірақ менің ойымша, олардың тәуекелге бармауы үлкен қауіп. Бір адам басқарғанда, ол комитет ешқашан келіспейтін тәуекелге барады.
Жақсы тіл жасау үшін тәуекелге бару керек пе? Көптеген адамдар тіл дизайны дәстүрлі даналыққа жақын болу керек деп күдіктенуі мүмкін. Мен бұлай емес деп ойлаймын. Адамдар жасайтын барлық нәрседе сыйақы тәуекелге пропорционалды. Неліктен тіл дизайны әртүрлі болуы керек?
Ақпарат көзі: www.habr.com