Bjarne Stroustrup bilan intervyu

Source: http://www.eptacom.net/pubblicazioni/pub_eng/stroustr.html

Dr. Carlo Pescio


Bu Bjarne Stroustrup bilan keyinchalik italyancha tarjima qilingan va 50-sonli Kompyuter dasturlash dasturida chop etilgan intervyusining asl ingliz tilidagi matnidir.

Quyidagi matnda CP Carlo Pescio uchun va BS Bjarne Stroustrup ni anglatadi.

CP: C++ standartlashtirish ishlarining natijalari va sur’atidan qoniqasizmi? Ya’ni, bir tomondan, bu tilning muvaffaqiyatli ekanligining isboti, biroq boshqa tomondan u ko’plab byurokratiyani qo’shmoqda; Siz asosiy til masalalarida dastlabki erkinlikni sog’indingizmi?

BS: Tabiiyki, mening sabr-toqatim sinovdan o’tgan, lekin katta va ko’p jihatdan C++ standartlashtirish ishlarining natijalari bilan mamnunman. Bir ozgina istisnolarsiz, ISO o’zimga kerakli his-tuyg’ularga ega bo’ladi va hech kim zararli emas. ISO C++ – C++ ning dastlabki versiyalariga qaraganda ancha kuchli va izchil til bo’lib, men ishlamagan va tasdiqlamagan hech qanday muhim xususiyatlar qo’shilmagan. ISO C++ ning ba’zi tafsilotlari “komitet tomonidan dizayn” belgilarini ko’rsatishi mumkin, ammo umumiy imkoniyatlar majmui mening C++ tilining avvalgi versiyalariga qaraganda qanday bo’lishi kerakligi haqidagi asl ko’rinishim uchun yaxshi mos keladi.

Men me’yorlar bilan ishlashni boshlaganimning asosiy sababi, men tilni tugatmasimdan oldin qo’mitaning yig’ilishi edi. Shablonlar va istisnolarsiz C++ qabul qilinishi mumkin bo’lmagan bo’lardi va C++ nomlari va ish vaqti ma’lumoti bo’lmagan ma’lumot bizni bugungi kunga qaraganda ancha kambag’al qoldirdi.

“Boshlang’ich erkinligimni” bo’rttirib yuborish oson. Men erta tongda tilimni C ga mos kelishi va haqiqiy foydalanuvchilarni qo’llab-quvvatlashni xohlaganimga qaror qildim. Bu men qiladigan narsalarga cheklovlar qo’ydi. O’ylaymanki muqobil boshqa bir ibodat tilini loyihalash uchun edi. Standartning to’liq bo’lishini kuta olmayman. C++ hamjamiyati mustahkam standartga muhtoj va men so’nggi 6 yil ichida standartlarga rioya qilishga sarflanadigan vaqt kerak. Menimcha, til menejment bo’yicha komissiya faoliyatimdan sezilarli darajada foydalandi. Men kengaytma va boshqa muhim o’zgarishlarni so’rovlarni qayta ko’rib chiqadigan kengaytirilgan sub-komissiya raisi bo’lib, odatda standartlar kutubxonasini loyihalash kabi ko’plab asosiy masalalarda ishtirok etdi. C++ foydalanuvchilari soni bilan til uchun standartlashtirish talab qilinadi. Biroq men standartlashtirish funktsiyasini chaqirmasdim. Ko’p kredit – odatda “soxta qo’mitalar” ga qaraganda ko’proq kredit – o’z vaqtini va yiliga va yiliga juda katta kuch sarflagan o’nlab odamlarga murojaat qilish kerak. Mening “C++ ning dizayni va evolyutsiyasi” (odatda D&E deb nomlangan) kitobimda ularning ism-shariflari va harakatlarining ko’pini hujjatladim.

CP: O’quvchilarning ko’pchiligi “c++ til – 3-nashr” va/yoki ARM ning 2 nashri mavjudligini bilishni xohlaydi.

BS: Men 3-nashrda ishlayapman va ARMni almashtirish uchun nimadir o’ylayman. Biroq, yangi narsalar haqida ko’p gapirmagunimcha, yangi kitobni yozishni istamayman, shuning uchun ham rivojlanish sekinlashadi. Maqsadim 2-chi darajadan 2-chi bahsda 3-nashrni yaxshilashdir. Boshqacha qilib aytganda, 2-chi yangi ma’lumotni o’z ichiga olgan va aslida har bir C++ dasturchisiga chiqadigan ma’lumotni yanada qulayroq qilishni xohlayman. Men tugatgandan so’ng taxmin qila olmayman, lekin yaxshi kitobga muhtoj bo’lmagan 3-nashrni kutish kerak. 2-nashr hali ham eng dolzarb, to’liq va dolzarb darsliklardan biridir. Tabiiyki, izoh berish uchun standart mavjud bo’lmaguncha, ARM-ni almashtirolmayman. Men ushbu kitoblarni olgunga qadar D&E ayniqsa, yangi xususiyatlar va umuman C++ dizayni ortida turgan sabablar haqida ma’lumot olish uchun eng yaxshi manba hisoblanadi.

CP: C++ da siz o’zingiz o’zgartirishni istamagan narsalarni emas, balki sizning qabul qilishingiz mumkin bo’lmagan narsalarni emas, balki keyingi tajriba sizni noto’g’ri tanqid qilgan narsa va siz o’zingiz o’zgartirishingiz kerak bo’lgan biron bir texnik qarorlar mavjudmi? (hatto bugungi kunda muvofiqlik sabablari bilan bo’lmasa ham).

BS: Ko’p tafsilotlar bor, men buni istamoqchiman, lekin men o’chirishni istagan asosiy xususiyatlar yo’q (hatto bo’lsa ham) yoki men qo’shgan narsalarni bilaman va biladigan asosiy funktsiyalar yo’q. Odamlar bu kabi savolni so’rashganda odatda MI yoki RTTI kabi ba’zi bir xususiyatlarga ega, shuning uchun C++, ulardan biri bo’lmasa, kambag’al til bo’lishi mumkin. Ikkala tomondan ham foydalanishim kerak, agar ular juda qiziqarli joylar bo’lmasa, men foydalanishim kerak bo’lgan vaqtinchalik echimlarni. D&E da albatta misollar va tushuntirishlar mavjud.

CP: Aslida men asosan virtual funktsiyalarni o’zgartirgan edim: masalan, virtual xususiy funktsiyani *alohida* sinfdan olingan sinfda qayta aniqlash mumkinligi haqida men juda xursandman. Funktsiya mavjud emas – qayta aniqlanadigan; bu xususiy merosning foydasi va xavfsizligiga biroz jozibali bo’ladi.

Katta miqyosda siz Sakkinenning “C++” ning meros qonun-qoidalariga oid hujjatlarini eslab qolishingiz mumkin: u bir nechta ajoyib fikrlarni aytdi va men [cheklovli qoidalar ostida] konstruktorni chaqirishga javobgarlikni kuchaytirish kerak emasligini juda yaxshi ko’rganman meros grafasida “zarur” dan ko’ra ko’proq virtual bazasi klassi. Aslida, VBC uchun mavjud bo’lgan qoidalarni C++ da tushunsam ham, ba’zi ma’noda VBC konstruktoriga murojaat qilish o’rta sinflar tomonidan taqdim etilgan inkassatsiyani zaiflashtiradi deb tan olishim kerak. Boshqa tarafdan, biz C++ ning kuchli va zaif nuqtalarini yillar mobaynida ishlatish orqali bilamiz – va ehtimol Sakkinenning takliflari boshqa “zaif nuqtalarga” olib kelishi mumkin edi, garchi ular kabi “dasturlash uslubi” ga o’xshash bo’lsam.

BS: Asosan men ushbu muammolarni faqat ilmiy va dasturiy dasturlarga qiziqtirmayman deb hisoblayman. Ma’lumotni noto’g’ri ishlatish uchun konstruktorni loyihalash mumkin, lekin o’z ma’lumotlarini ishga tushirish uchun yozilgan konstruktor asosan zararsizdir. Bundan tashqari, agar virtual bazasi klassik bo’lsa, men doimo tavsiya qilsam – hamma mashg’ulotlar uning mavjudligini bilishi kerak va uning konstruktorini chaqirishini kutishlari kerak. Bunda virtual bazaviy sinflar boshqa asoslardan farq qilmaydi. Virtual bazalar bir joyda va boshqa joylarda omma e’lon qilinadigan bo’lsa, va agar eng quyi sinf uni virtual virtual bazaning yozuvchisini kutib oladigan tarzda boshlasa, “qidiruv sinflar tomonidan taqdim etilgan inkassatsiya” zaiflashgan. Ammo, agar bu kimdir haqiqatan ham chinakamiga muhtoj bo’lgan eng yomon muammo bo’lsa.

Virtual funktsiyani maxsus funktsiyadan yoki bazaning xususiy bo’lgan bazasidan o’chirib tashlash bilan hech qanday muammo ko’rmayapman. Agar siz asosiy sinf interfeysi deb hisoblasangiz, ushbu interfeys foydalanuvchilarni (uning toifadagi klasslari) o’z ilovalarini qanday ta’minlayotganidan tashvishlanmaydi. Boshlang’ich sinfning interfeysidan tashqari va boshqa derivatsiyani inhibe qilish uchun, boshlang’ich sinfdan foydalanishni oldini olish uchun, uni bekor funktsiyalarini shaxsiy sifatida yaratadigan tulik sinfni tasavvur qilish oson. Agar bazaning o’ziga xos bo’lsa, u hali ham do’stlar uchun ochiq bo’lishi mumkin, yoki boshlang’ich sinf spam ustiga maxsus (maxsus) bazaga ko’rsatma berishi mumkin. Misol uchun, boshlang’ich sinf o’zining tizim darajasida hisob-kitoblarni tekshirishni amalga oshiradigan operatsiya natijasida asosiy sinf interfeysini qaytarishi mumkin.

class A
  {
  virtual void f() ;
  } ;

class B : private A
  {
  void f(); // implementation 
  A* get_A(Rights& r) { /* check rights */ return (*A)this; }
  } ;

CP: Boshqa tomondan, xususiy meros o’tuvchi emas, shunga o’xshash vaziyatda:

class A
  {
  virtual void f() ;
  } ; 

class B : private A
  {
  void h() { f() ; }
  } ; 

class C : public B
  {
  virtual void f() ;
  } 

sinf A sinf uchun interfeys emas C, A :: f() C sinfida mavjud emas, ammo sinfda qayta tanlanadigan C deb atash mumkin. Aytish mumkinki, jinoyatchi B sinfining dastur detaliga asoslangan (B klassi qo’llanilgan-A sinfidan foydalanilgan). Ba’zilar tildan man etilgan bo’lishi mumkin…

BS: Ha, bu juda yomon misol. Biroq, har bir iflos misolni buzadigan qoidalar to’plamini tuzish oson emas, ayrimlari esa buzilgan deb hisoblaydigan misollarni buzishadi, boshqalari esa ish uchun muhimdir. Umuman olganda men cheklovlarga qarshi emasman. Ortogonallashtirishni asosiy loyihalash maqsadini nazarda tutmayman, lekin hech qanday ortogonallik uchun birinchi darajali sabablar bo’lmaganda, men buni afzal ko’raman. C++ ning erkin foydalanish qoidalari juda ko’p dikkatli (nomlash qoidalari, qoidalarni bekor qilish va hokazolar bilan) va men ularni bo’lmasliklari uchun hech qanday sabab yo’q. Odamlar qoidalar bilan hayron bo’lishi mumkin, ammo ular shunchaki kamroq diktatura qoidalari bilan foydalanishlari mumkin.

CP: Sizning fikringizni tushunaman va men katta darajada roziman. Shuning uchun men bunday “qoidalar” “dasturlash uslubi” ga nisbatan yaxshi bo’lishi mumkinligini aytdim. Albatta, bunday narsalar foydali bo’lishi mumkin (masalan, manba kodisiz kutubxonani qayta ishlatishda) va bu holda “qoidalarni buzish” mumkin va buni amalga oshirishi mumkin, chunki C++ – ona, cheklovchi til emas.

BS: Men C++ dasturchilarining mantiqiy xatolaridan qochishga qodir bo’lardim. Axir, C++ xususiyatlarining aksariyati, xuddi shunday operatsiyani bajarish uchun Cga yozish kerak bo’lgan narsalarga nisbatan, bu ta’sirga ega. Biroq, xavfsizlikni hayotiy muammolarga yaxshi yechimlarni ifodalashni murakkablashtirish uchun sotib olish kerak deb o’ylamayman. Bu – va muvofiqlik masalalari – tilni toza qilish uchun nima qilish kerakligini cheklaydi. Maxsus ilovalar uchun C++ ilovasidan foydalanish uchun kutubxonalardan foydalanishni tavsiya etaman. Misol uchun, agar kimdir C qatorlari oralig’i tekshirilmaganligi to’g’risida xavotirda bo’lsa, ular qatorli vektor sinfidan foydalanishi kerak. Ayniqsa, disk raskadrovka uchun men o’zimning ko’pchiligimni qilaman.

CP: C++ da retrospektivaga qaytaylik…

BS: Yaxshilik va yomonlik uchun C++ ning eng qadimgi kunlaridan beri yuqori darajali S muvofiqligini saqladim va standartlar bo’yicha qo’mita mening “iloji boricha yaqinroq, lekin yaqinroq” siyosatimga rioya qildilar. C++ da ko’p narsalar til-texnik nuqtai nazardan yaxshiroq bo’lishi mumkin, ammo bu haqiqat emas. Men boshlaganimda uyumliroqlikni qaror qildim va ikkinchi darajali kamchiliklar bilan yashashim mumkin bo’lgan eng yaxshi ishni qildim. Shu bilan bir qatorda, boshqa bir ibodat tilini qurish mumkin edi: uning tarafdorlari oldida go’zal va deyarli barchadan natijalarni olishni rejalashtiruvchi hech narsa emas. Agar u mos kelmasa edi, men unga mos keladigan boshqa tilni tanlagan bo’lardim. Men o’zimning vaqtimni loop yozishning yana bir usulini ixtiro qilmagan bo’lardim, deb o’ylayman.

Muntazamlik – bu keladigan muammo. Aksariyat odamlar o’zaro o’xshashlik kabi va uni C++ da bevosita qo’llab-quvvatlashni istashadi. Biroq, C++ dasturchilarining kichik bir qismini juda yaxshi bir vaqtda bajarish uchun xizmat qiladigan, bir biriga o’xshashlik shakli yo’q. OS yozuvchilari o’zaro o’xshashlikning bitta formasi, ma’lumotlar bazasi foydalanuvchilari va boshqa tarmoq dasturlarini bajaruvchilariga kerak. Shunday qilib, men C++ da bir vaqtda kelishuvni qo’llab-quvvatlovchi xususiyatlarni kiritmaslikka qaror qildim. Ba’zi bir parallellik shaklini talab qiladigan kishilar uni (afzal) kutubxonalarning til kengaytmalari orqali qo’llab-quvvatlaydi. Menga ushbu masala bo’yicha standart komitet ham yordam berdi; biz C++ foydalanuvchilarining ko’pchiligiga xizmat qiladigan juda ko’p jozibali parallellik tizimini bilardik. C++ ishlatiladigan joylar oralig’i bu juda ajoyib.

Dasturlash tillari tarixi bo’yicha ACMning ikkinchi konferentsiyasi uchun C++ maqolasini yozishni so’radim (ular har 15 yilda bir bor!). Ushbu maqola uchun menga eng katta xatoni C++ bilan ko’rib chiqqanman. Mening fikrimcha, “eng yomon xat” deb nom olgan bittagina nomzod mavjud edi: 1985-yilda qabul qilingan vaqf kutubxonasini ishlab chiqolmadim va uni 1-chi versiyani 1.0-versiyadan chiqarib berolmadim. Uzr, men yaxshi kutubxonani qanday yozishni bilmaganman va men samarali, moslashuvchan va tipga xavfsiz konteynerlarni taqdim qilish uchun shablonlarga muhtojman. Ushbu xatoning natijasi – keng tarqalgan falsafalar va fazilatlarning bir-biriga mos kelmaydigan asosiy kutubxonalari.

Yaxshiyamki, standartlar bo’yicha komissiya mukammal standart kutubxonada kelisha oldi. Keling, o’n yil burun ishlab chiqarib bo’lmaydigan narsani va qanday qilib dizayn va amalga oshirishni bilmagan narsam bor. Standart kutubxonaning asosiy qismi bo’lgan konteynerlar va asosiy algoritmlar asoslari Aleks Stepanovning asarlari edi. Darhaqiqat, kutish kutubxonalari uchun yaxshi tamoyillar va texnikani qidirishda ba’zi ildizlar mavjud, bu 1,0 dan oldin va keyin chiqarilganidan keyin, shuning uchun kechikish butunlay yo’qotilgan.

CP: Ma’lum bo’lganingizdek, ba’zi C++ xususiyatlarini C9x ga qo’shib olish mumkin, masalan, sinflarga cheklangan yordam. Men sodda yondashuv, masalan, ular qurilishchilarni, yukni ortiqcha yuklamasdan va hokazo. “Yangi ANSI C” da sizning o’rningiz qanday?

BS: Xususiyatlar mening nuqtai nazarimdan sodda ko’rinib turdi va ularga qo’shilaman degan tushuntirishlar, geribildirimga javoban C++ qanday rivojlanganligini qadrlashning kamligini aks ettiradi. Tilim nima qilish kerakligi haqida umumiy fikrga ega bo’ldim (lekin hali ham bor edi), lekin umumiy nuqtai nazardan men o’z xususiyatlarini haqiqiy tajriba va ehtiyojlarga moslashtirish uchun rivojlangani uchun til haqida mulohaza yuritishga diqqatli bo’ldim.

“C++” ning deyarli barcha kuchlari bilan ancha soddalashtirilgan tilni ta’minlash uchun “C++” dan kichik funktsiyalarni tanlashga harakat qilish, mening fikrimcha, muvaffaqiyatsizlikka uchraydi. Agar haqiqiy tajriba asosida juda ehtiyotkorlik bilan tanlanmasa, funksiyalar faqatgina izchil dasturlash uslublarini qisman qo’llab-quvvatlaydi va bir xususiyat boshqa biriga olib keladi – faqat dizayn va dasturlash jihozlarining to’g’ridan-to’g’ri qo’llab-quvvatlanishi kerak bo’lgan umumiy qarashga asoslanib, qo’shimchalar izchil til.

C jamoasiga ularning tilini qanday standartlashtirish kerakligini aytib berishga harakat qilish men uchun oqilona bo’lmaydi. Agar men buni qilsam, maslahatim yaxshi bo’lmasligi kerak, chunki mening tavsiyamni juda qadrlaydigan odamlar C++ dasturida bo’lishadi. C qo’mitasi C bilan istagan narsalarni qiladi va ehtimol ular o’zlarining asosiy jamoalari uchun eng yaxshi biladi. C++ bilan mos keladigan kengaytmalar imkon qadar. Dasturlashtirish jamiyatiga yana bir mos kelmaydigan S dialektiga ehtiyoj qolmaydi. K&R C hali o’lik emas, yangi ANSI C yangi standart ochilgach, uzoq vaqt davom etadi va C++ standartining rasmiylashtirilishi ortidan C++ ning turli xil vintages ham mavjud bo’ladi. Vaziyatlarimiz doimo bizdan ko’ra ko’proq vaqt talab etadi va biz xohlaymiz. C9x da yangi xususiyatlar C va C++ jamoalarida qo’shimcha ravishda beqarorlikning qo’shimcha manbai bo’lib qoladi.

CP: C++ ning o’g’illari haqida gapirganda, men Java haqida gapirishdan qochib ketolmayman… sizning fikringizcha, guruhning ta’siri qanchalik katta bo’lsa va (agar biron bir joyda) Java-ning haqiqiy kuchlarini ko’rsangiz edi. Bilaman, tilni ishlab chiquvchi sifatida siz tillarni tanqid qilishda juda ehtiyot bo’lishingiz mumkin – “har qanday tilning o’rni bor” – sizning ichak tuyg’ularingiz qanday?

BS: Java-da C++ kabi sintaksisi bor, lekin turli xil madaniyatni va boshqa (juda tor) dasturlash uslublarini qo’llab-quvvatlaydigan asosli boshqa tildir. Java, albatta, C++ – mos keluvchi cheklovlar bo’lmagan holda ishlab chiqadigan til emas. Hozirgi kunda Java-ning kutilgandagi yuksakligi, Sun-marketing pullari va Internet bilan integratsiyalashuvi juda yuqori. Vaqt umumiy maqsadlardagi til sifatida qanday ishlashini tushuntiradi va dasturchilar va boshqaruvchilarning aksariyati Java-ning va ayniqsa, Javascriptning “xavfsizligini” istagan narsalarni aniqlayotganlarida qanday munosabatda bo’lishlarini bilib oladi. Odamlar xavfsizlik bilan dasturlash tili turini xavfsizligini (to’g’ri Java dasturini ta’minlaydi) aralashtirib yubordi; ya’ni sistema yaxlitligini va maxfiyligini saqlab qolish (Java yordamida jiddiy ravishda buzilgan bo’lishi mumkin). Bizning xavfsizligimiz odamlar Java-ni “virusni amalga oshirish tili” deb atashadi va biz Java-va Javascript-da nogironlar bilan ishlashni tavsiya qilamiz. Dasturiy til masalalariga qaytish:

C++

– yaxshiroqdir

– ma’lumotlar uzatishni qo’llab-quvvatlaydi

– ob’ektga asoslangan dasturlashni qo’llab-quvvatlaydi

– umumiy dasturlashni qo’llab-quvvatlaydi

Ulardan Java faqat ob’ektga yo’naltirilgan qismni o’z ichiga oladi va bu C++ dan sezilarli darajada farq qiluvchi usullar bilan amalga oshiriladi.

CP: Yangi C++ qo’shimchalaridan ba’zilari foydali bo’ldi, ammo kichik tafsilotlar – aniq, o’zgaruvchan yoki yangi uslublar kabi “C” dan chiqish. Tilga ko’proq dizaynga qaratilgan xususiyatlar uchun kelajakni ko’rasizmi? Masalan, Annotated C++ yoki Larch-C++ kabi loyihalarda ba’zi bir qimmatbaho ilhomlar mavjud bo’lib, ular spetsifikatsiyalarga ko’proq mos keladi va kodlash darajasida kamroq bo’ladi, yoki ba’zi bir semantik usullarni kiritish uchun, masalan ob’ekt almashish qarorlarini yanada aniqroq qilish. Yoki siz tilni mustahkamlash niyatingiz allaqachon kuchli – ko’milgan/tizim dasturlari/ishlashning muhim sohalarida bormi?

BS: C++ – dasturlashning yanada deklarativ uslublariga nisbatan umumiy driftning bir qismi. Shu bilan birga, tilning rasmiy ta’rifi til va standartlarga mos keladigan o’zgartishlar bilan bog’liq bo’lib, amaliyotchilarni, foydalanuvchilarni, asbob quruvchilarni, o’qituvchilarni va h.k.larni qo’lga kiritish uchun to’xtash kerak. Tabiiyki, tajriba davom etadi (garchi, menimcha bo’lmasa ham), lekin mening fikrimcha, C++ rivojlanish jamiyati barqarorlikka ko’proq ehtiyoj sezadi. Endi C++ tugallangan va u nima bilan band. Keyingi ish bir necha yil davomida kichik jamoalarda (akademiya kabi) qolish kerak bo’ladi.

Menimcha, aksariyat insonlar shablon mexanizmining kuch-qudratini har tomonlama aniqlashtirishi kerak. Misol uchun, ro’yxatni belgilashning asosiy bosqichi quyidagichadir: bitta dasturni ko’rsatuvchi barcha ro’yxatlar bilan taqsimlanadi:

// general list<T>:

template<class T> class list { /* ... */ }; 

// specialization for lists of void*:

template<> class list<void*> { /* ... */ }; 

// general list of pointers (implemented using list<void*>):

template<class T> class list<T*> : list<void*> { /* ... */ };

Bu erda qo’llaniladigan ixtisoslashuv mexanizmi foydalanuvchi uchun yagona umumiy interfeys bilan ta’minlangan holda turli xil tanlovlarni (turdagi chegirmalar yordamida) tanlab olish imkonini beradi. Buning muhim jihati shundaki, u C++ dasturining deklarativ tabiatini mustahkamlaydi va foydalanuvchi interfeysi soddalashtiriladi va ish vaqti samaradorligini oshiradi. Standart kutubxonadagi bunday metodlar bizga bitta umumiy ma’lumotni taqdim etish imkonini beradi sort() haqiqiy misollar uchun C standart kutubxonasidan yaxshiroq bajarilgani muntazamdir qsort() ettita omil bilan!

CP: IEEE Computer-da, 95-fevral kuni, Prof. Wirth C++-ni “tuzilgan fikrlash va intizomli dasturiy ta’minotni qurishga to’sqinlik qiladigan til” deb ta’riflagan. Men buni qabul qila olmayman yoki Oberonni C++ dan ko’ra ko’proq tuzilish va intizomni rag’batlantirayotganini topolmayman, lekin u yerda o’qituvchilarga/akademiklar bilan gaplashmoqchi bo’lgan narsa bor, bu C++ o’qitish o’rtasida qaror qabul qilishi kerak, chunki haqiqiy dunyoda foydali va uni o’qitmaslik, chunki u tez-tez CS ta’limi uchun ishlatiladigan rasmiy, spetsifikatsiyaga asoslangan yondoshuvdan juda uzoqda… shuning uchun Eiffelni barcha “dasturlash bo’yicha dasturlash “sofdir OO”…

BS: Professor Wirth o’zini o’zi yaratmagan tillarni maqtash uchun saxiy bo’lgani uchun taniqli emas, shuning uchun men uni uyg’otishidan hayratlanaman deb aytolmayman. Boshqa tomondan, menimcha, u noto’g’ri. C++ – bu yaxshi dizayni, sanoatning miqyosda dasturlashi va jiddiy muammolarni aniq tasavvur qilish uchun ko’proq moslashuvchan vosita. O’ylaymanki, bu Simula va C dizaynerlariga C++ ni qurish va shu kabi chiroyli odamlar bo’lish uchun mustahkam asos yaratib bergan minnatdorchiligimni bildirish uchun yaxshi joy edi. Men ko’plab boshqa tillardan ham adolatli bir narsa o’rgandim. Agar qaerga qarashni bilsangiz, C++ da Algol68, ML, Ada va BCPL izlarini topishingiz mumkin. Turli tillarda juda ko’p tillar mavjud. Har bir inson dasturiy tillarni ham, tabiiy tillarni ham qamrab olgan bir nechta tilda malakali bo’lishni maqsadga muvofiq bo’lishi kerak. Boshqa til esa dunyoqarashi va qobiliyatini sezilarli darajada oshiradi. C++ da yaxshiroq bo’lishi mumkin bo’lgan ko’p narsalar mavjud. Biroq, bu har bir til uchun haqiqiy foydalanish uchun amal qiladi. Hatto “toza” deb da’vo qilayotganlar ham. Mening tajribamda C++ bilan bog’liq muammolar ta’lim uchun ham, haqiqiy foydalanish uchun ham jiddiy emas. Tabiiyki, talaba o’rgana olmaydi va o’qituvchi keraksiz ravishda og’rig’ini o’rganishga undaydi. Ammo bu har bir tilda yuz berishi mumkin. C++ ning afzalliklari ko’plab turli sohalarda ishlatilishi haqiqiy dunyo muammolariga ko’maklashadi. Pok/yangi tillarni o’rganish qulayligi ko’pchiligi “toza” tilni oqilona tanlash bo’lgan domen hududidan tashqaridagi dasturni urganida foydalanuvchilarni tildan voz kechishga majburlaydigan soddalashtiradilar. Tabiiyki, bu C++ foydalanuvchilari uchun ham bo’lishi mumkin, ammo tizimlarning dasturlashiga qandaydir ta’sir ko’rsatadigan har qanday sohada kamdan-kam hollarda. C++-ning toza subkratlariga ega va murakkablik, odamlar kengroq tushunishni talab qiladigan xususiyatlar va dasturlash uslublari (“paradigmalar”) bilan o’ynashni boshlaganda keladi. Bu erda “tozalovchi” tillarda foydalanuvchilar odatda muqobil, past darajadagi va “nopok” tillarga, odatda C yoki C++ ga murojaat qilishlari kerak. Menimcha, C++ dasturlarini bosqichma-bosqich va kontseptsiyaga katta e’tibor berish kerak.

CP: Yaxshi nuqta, albatta. Shunga qaramasdan, masalan, “C++” talabasi, agar foydalanuvchi so’ramasdan turib, bir qator ko’rsatgichga ega bo’lmasa va bir xil ruhga cheklovli boshqa omillar kirsa, unda yana toza subkafratni tasavvur qilish mumkin. Buning foydali vositasi bo’lishi mumkinmi (va ehtimol, odamlar uchun C moslashuvi bilan bog’liq bo’lmagan ishlab chiqarish vositasi) yoki faqat chalkashlik manbai bo’lishi mumkinmi?

BS: Darhaqiqat, men “C++” o’quvchisini ko’rmoqchi edim, unda o’rnatilgan qatorlar ishlatilmadi. Buning o’rniga o’quvchilar o’qituvchi tomonidan taqdim etilgan kutubxonadan vektor, ro’yxat va magistral sinflarini ishlatishadi (shubhasiz, standart kutubxona asosida). Bu osonlik bilan amalga oshiriladi va o’quv sharoitida osonlik bilan amalga oshiriladi – hatto kompilyator o’zgarishsiz (faqat ichki majmuada berilgan bahoni qisqartirish uchun ishlatilgan). Xuddi shu tarzda, o’qituvchi aniq tushunchalarni taqiqlashni osonlashtiradi; boshlang’ich talaba yozishi kerak bo’lgan kod tipidagi joy yo’q. C++ tilini yoki boshqa tilni o’rganishning murakkab qismi – ularni ifodalash uchun ishlatiladigan til xususiyatlarini emas, balki yangi dasturiy va dizayn texnikasini o’rganishdir.

Ko’pincha, odamlar til xususiyatlariga duch kelishadi. Ko’pincha programlovchilar boy tilning barcha jihatlarini etarli fon bilmagan holda yo’qotib qo’yadilar. Shuni ta’kidlash kerakki, hatto C++ – buyuk buyurtmalar, muhitlar, ramkalar va yirik ilovalarga qaraganda oddiyroq

Biz haqiqiy dunyo ilovalarini ishlab chiqish bilan ishlaymiz.

Ta’lim berishda C++ C bilan yaqin va qimmatbaho munosabatlariga zarar etkazdi. C++ (deyarli) C ning yuqori nuqtasi bo’lgani sabab, ko’pchilik C++ ga yaqinlashmasdan oldin barcha S funktsiyalarini va texnikalarini o’rganish kerak, deb hisoblaydi. Bu shuni anglatadiki, C++ ko’p jihatdan Cdan ko’ra yaxshiroq ishlaydi va kutubxonalar o’quvchining talablarga ega bo’lishini oldini olish uchun ishlatilishi mumkin, shuning uchun ham asoslar tegishli muhitda o’rganilgunga qadar C ko’rsatkichini manipulyatsiya, to’qimalar, massivlar va boshqalar. Vektor, strings va boshqalar. C++ – dasturlash, dasturlashtirish uslublari, dizayn va hokazolarni o’qitish uchun mukammal bir til bo’lishi mumkin. Ammo dasturlash tilini ta’lim dasturidan ajratish kerak. Shunday qilib, biz bir oz muvaffaqiyatga erisha olamiz va ko’p vaqtimizni behuda sarflaydigan ko’p tillardagi urushlardan qochishimiz mumkin.

C++ tilining ta’lim tili sifatida qo’llanilishining kuchli kuchi, u turli dizayn va dasturiy metodlarni o’rgatishdan iborat. Shu bilan bir qatorda bir xil texnikani namoyish qilish uchun turli “toza” tillarni o’rgatishdir. To’g’ri noto’g’ri deb hisoblagan narsa, hozirgi kunda bitta dizayn va dasturlash uslubi bo’lib, odatda bitta dasturlash tilida – bir va yagona haqiqiy uslub sifatida qo’llaniladi. Professional dasturchi yoki kompyuter mutaxassisi oxirida C++, Smalltalk, ML, Lisp va Eyfel bilan qulay bo’lishi kerak. Tabiiyki, kam sonli odamlar bir yoki ikki kishi yoki bir vaqtning o’zida haqiqiy ekspert bo’lishi mumkin, lekin ideal hamma bilan va vaqt o’tib, har qanday haqiqiy loyihada sinash uchun bo’lishi kerak.

CP: C++ istisnolarini to’g’ri ishlatish qiyin deb tanqid qilindi – Cargillning C++ hisobotidagi maqolasi, istisnolardan foydalanib, ko’rsatgichlarni yanada boshqarilishi uchun standartlar kutubxonasida auto_ptr ni joriy qilish uchun “kerak”, shablonlar va istisno xususiyatlarining mos kelmasligi. Bundan tashqari, amalga oshirish qiyin bo’lgan kabi ko’rinadi: Borland, DLL’leri istisnosiz ishlash bilan birga va bir-biriga bog’lovchi jiddiy muammolarga duch kelgan. “Qayta sinash” deb ataladigan bahs-munozarani eslatib o’tmaslik, sizning D&E tizimingizda yaxshi ishtirok etganingiz. Xullas, istisno C++ ga nisbatan o’rganishning egri chizig’ini yaratadi, deb hisoblaysizmi – ular C++-da – istisnolar uzaytiriladi?

BS: Har bir yangi xususiyatni ishlatish qiyin, qimmatli va ayrimlari birinchi paydo bo’lganida keraksiz hisoblanadi. Ko’p “muammolar” ning ko’rsatilishicha, haqiqiy dasturlarda haqiqiy muammolar kam. Ushbu istisnolar mening kodimni sezilarli darajada soddalashtiradi. Hamma chindan ham qimmatbaho xususiyatlar singari, ular yangi fikrlashni va kodni tashkil qilishning ba’zi yangi usullarini talab qiladilar (agar bo’lmasa, bu xususiyat qanday qilib yaxshilanishi mumkin?), Lekin ular juda qimmatga tushadi deb o’ylayman. Men “istisnolar va shablonlar orasidagi nomuvofiqlikni” soxta deb hisoblayman. Istisnolardan xavfsizlik devorlarini xato holatlariga qarshi qurish mumkin. Boshqacha aytganda, muayyan interfeysni tanlaysiz va faqatgina xato vaziyatlarning pastki qismiga ruxsat berishga qaror qilasiz. Deyarli barcha shablonlar xavfsizlik devorlari uchun yomon nomzodlar. Shablonlar ataylab foydalanuvchi tomonidan aniqlangan turlar bilan juda yaqin hamkorlik qilish uchun mo’ljallangan va agar siz mantiqan to’g’ri bo’lsa, xavfsizlik devorini yaxlit tarzda kodlash orqali tuzishni istamaysiz. Agar bu noto’g’ri bo’lsa, shunday bo’lsin. Biroq, uni faqat tushuncha mustaqilligi deb bilaman. Ular turli narsalarni qiladilar va ular birgalikda ishlatilishi mumkin.

CP: Bir darajaga qadar shablonlar va *istisnosiz spetsifikatsiya* o’rtasida nomuvofiqlik mavjud; chunki shablonlar haqiqiy dalillarni ba’zi usulda qo’llaydilar, hatto beg’ubor ko’rinadigan, oddiy kodda ham (masalan, taqqoslash uchun shablon vazifasi) to’g’ri spetsifikatsiya bilan tugash mumkin emas… Umuman aytganda, istisnolardagi har qanday qorong’i tomon, ular endi aybsiz ko’rinadigan kodni endi begunoh deb hisoblashadi.

BS: Aslida, bunday “begunoh ko’rinadigan kod” ning ko’pi hech qachon aybsiz edi. Bunday oddiy kod ko’pincha belgilanmagan xato sharoitlari bilan to’la va C-uslubi setjmp/longjmp tomonidan bypass qilingan bo’lishi kerak. Shunday qilib, istisnolar e’tiborni e’tiborga olishni afzal ko’rgan bir muammoga qaratadi, ammo murakkablik allaqachon mavjud; istisnosiz ishlash bilan kiritilmagan. Funktsiyalarni shablonga o’tkazish uchun istisno xususiyatlarini qo’shish mantiqan emas – hech bo’lmaganda juda g’alati shablon vazifalariga. Buning sababi – agar siz to’g’ri ishora qilsangiz – potentsial ravishda tashlab yuborilgan istisnolar shabloni va shablon argumentlari tomonidan tashlangan narsalar. Shablonlar, odatda, xavfsizlik devorlari uchun yaxshi nomzodlar emas, deb ayta olmayman. Har bir kichik parcha o’qini o’qqa tutishning mantiqiy ekanligiga ishonmayman. Aksincha, sub-tizimlar uchun tizimlarni ifodalashni va pastki tizim chegaralarini xavfsizlik devorlarini yaratishni afzal ko’raman. Men istisno xususiyatlarini qo’llayman.

CP: C++ ning zaif ko’rinadigan maydoni ob’ektni qotirmaslik… bir nechta kutubxonalar/asboblar mavjud, ammo ko’p hollarda siz odatiy preprocessor yoki ba’zi bir handcoded funktsiyasi kerak bo’ladi. RTTI borishning istiqbolli usuli bo’lib tuyuladi, lekin ba’zi bir standartlar mavjud bo’lmaguncha, bu faqat boshqa nostandart kengaytma bo’lishi mumkin…

BS: Men qat’iylik umumiy maqsadga qaratilgan dasturlash tilida ekanligiga shubha yo’q. Turli xil odamlar har xil qat’iyatli ma’lumotga muhtoj, ishlashi, ishonchliligi, erkin foydalanishni nazorat qilish, quiritsiyalarning tabiati va hokazolar bo’yicha juda ko’p turli xil talablarga ega. Men bu masalani kutubxona sotuvchilari va ma’lumotlar bazasi sotuvchilariga qoldirish to’g’ri deb hisoblayman. Men preprocessorlarni va qo’shimcha tillar vositalarini qo’llashni cheklashni ma’qul ko’raman, lekin ba’zida ular kerak bo’ladi. Menimcha, dasturlash tili hamma narsani qilishga harakat qilmasligi kerak. Yaxshiyamki, hamma narsani yaxshi qila olmaydi. Va ha, RTTI turli qat’iylik va ma’lumotlar bazasi xizmatlarini ishlab chiqaruvchilarga katta yordam berishi mumkin.

CP: Siz eng muvaffaqiyatli tillarning uslubchisi bo’lgansiz – akademiyadagi son-sanoqsiz kishilarga har kuni boshqa tilni tashvishga soladigan har qanday takliflaringiz bormi?

BS: Muammoning echimini toping. Foydali til – dasturlash tili nimaga o’xshash bo’lishi kerakligi haqidagi hozirgi zamonaviy mezonlarga to’liq mos keladigan narsa emas, balki juda yaxshi tushunilgan muammolar to’plamidir. Agar mavjud bo’lgan til bilan oqilona foydalana olmaydigan jiddiy muammo bo’lmasa, boshqa tilni loyihalashtirish haqida o’ylamang. Til dizayni – deyarli 100% lik qobiliyatsiz bo’lgan maydon. Agar muqobil bo’lsa, mantiqiy odam bu sohaga kirmaydi. Ya’ni, qabul qilinadigan echimlarsiz jiddiy dasturiy muammolarni izlang va tilni loyihalashda ishtirok etmaslikka harakat qiling. Agar siz yangi tilni loyihalashingiz kerak bo’lsa, imkon qadar ko’proq qarz olishingiz mumkin – minnatdorchilik bilan – mavjud tildan. Qobiliyatsiz bo’lish uchun tayyor bo’ling va juda katta miqdorda ishni g’alaba qozonish va muvaffaqiyat qozonish kerak.

CP: Boshqa eng muvaffaqiyatli til ingl. Asosiy hisoblanadi. Ba’zilar, OOP/C++ va’da qilgan joylarni, ya’ni takroran takomillashtiruvchi qismlarni, haqiqiy qayta ishlatishni, ba’zan ba’zi bir ostenizatsiya hisobiga etkazib berishni aytdi. Siz turli xil C++ kompilyatorlari bilan birgalikda ishlashning SOM kabi uchinchi tomon mahsulotlariga qoldirilganligi va standartning bir qismi emasligini to’g’ri deb bilasizmi? Albatta, har qanday ikkilik standart kompilyatorlar yozuvchilarining erkinligini cheklaydi, ammo *bu* standartlashtirilgan har qanday savol uchun to’g’ri. Bir nechta merosni qo’llab-quvvatlashdan voz kechib, ba’zi bir ishlarni qisqartirish mumkin, biroq bu MI ni C++ dan olib tashlash uchun yaxshi sabab emas. Ikki tomonlama standart nima uchun har xil? [tabiiy ravishda ikkilik standart “haqiqiy” dasturiy komponentlariga nisbatan bir qadamdir]

BS: C++ va’da qilgan narsalar. Ob’ektga yo’naltirilgan yoki xohlagan narsalar deb da’vo qiladigan har qanday til va tizimning shriftlarini kutish mumkin emas. C++ – dasturiy til, modulning spetsifikatsiya tili yoki operatsion tizim emas. Bu – har qanday boshqa tilga o’xshash – hamma uchun hamma narsa bo’la olmaydi. Siz “C++” yordamida “pluggable komponentlarini” qurishingiz mumkin, lekin bu C++ ning asosiy maqsadi emas va u ishni talab qiladi. Birgalikda ishlash qiyin muammo. Odamlar, odatda, juda ko’p ish bilan raqobatlashadigan tashkilotlar o’rtasidagi ko’plab kelishuvlar turli kompilyatorlar tomonidan tuzilgan C dasturining qismlari bilan birgalikda ish olib borishi mumkinligini tushunishmaydi. Funktsiyalarni qidirish sekanslari, ma’lumotlarni joylashtirish, suzuvchi nuqta arifmetik tafsilotlari va boshqalar haqida kelishuvga erishish kerak. C++ C dan qiyinroq, lekin ko’p emas, chunki deyarli barcha muammolar texnik jihatdan emas, balki siyosiydir. Bir nechta meros masalasi ikkilangan standartlarning har qanday muammosidan va C++ kompilyatorlari bilan birgalikda ishlashdan to’liq ajralib turadi. Menimcha, SOMning kamida dastlabki versiyalarida MI yo’qligi boshlang’ich SOM dizaynerlari orasida Smallatlk va Objective C ga to’g’ri kelmaydi. C++ kabi interfeyslarni statik tekshirishga asoslangan tilda bir nechta merosning ba’zi shakllari muhimdir. Muqobil muqobillashtirilgan kod, xavfsiz bo’lmagan interfeyslar yoki har ikkalasi.

CP: “Yangi avlod C++” uchun o’ylayotgan va bizni oldindan bilmoqchi bo’lgan yangi kontseptsiyasi, g’oyasi yoki xususiyati bormi? [Men sizning C++-ni bir muddat barqaror bo’lishini xohlayotganingizni tushunaman; O’ylaymanki, bu sizni fikrlarni yaxshilashga xalaqit bermaydi, balki mavjud xususiyatlar uchun ba’zi amaliy masalalarda yaxshilanishlarni keltirib chiqaradi).

BS: Menimcha, dasturlash tillariga kelganda, odamlar liperveritsiyani tajriba uchun to’lashadi va bu sohani matematika yoki falsafa bo’limi deb hisoblashadi. Biroq, kelgusi avlod C++ mavjud tilda spekülasyon va cilalama o’rniga haqiqiy ilovalar va eksperimentlerdeki haqiqiy muammolardan kelib chiqishi kerak deb o’ylayman. Men nima qilganimni va kelajakni oldindan aytib berishga harakat qiladigan narsalarni tushungan narsalarni tasavvur qilishni ancha osonroq deb bilaman. Ilmiy-fantastikni yaxshi ko’raman, ammo texnik maqolalar sifatida maskaragandagina emas. Menimcha, bizning sohada juda ko’p “haqiqiy imonlilar” va juda kam eksperimentalistlarimiz bor. Kompyuter tizimini takomillashtirish uchun ko’plab yaxshi tajribalar va ishonchli ma’lumotlar tonnalari bo’lishi kerak. Shundan kelib chiqib, biz haqiqiy muammolarni va ularni qanday qilib hal qilishni aniqlashga imkon beradigan tushunchalarni bilib olamiz. Juda ham tez-tez, biz haqiqiy taraqqiyot o’rniga, bizning his-tuyg’ularimiz, fikrlarimiz va nazariyalarimiz haqida falsafiy fikr yuritamiz.

Biografiya

Karlo Pescio Kompyuter fanlari doktori ilmiy darajasini oladi va turli Evropa kompaniyalari va korporatsiyalari, jumladan Evropa Komissiyasining Direktsiyasi maslahatchisi va maslahatchisi hisoblanadi. Ob’ektga yo’naltirilgan texnologiyalarga ixtisoslashgan va IEEE Computer Society, ACM va Nyu-York Fanlar Akademiyasining a’zosi. U Savona (Italiya) yashaydi va u bilan bog’lanish mumkin [email protected]