ပရိုဂရမ်းမင်းဘာသာစကား ဒီဇိုင်းအကြောင်း မေးခွန်းငါးခု

လမ်းညွှန်အတွေးအခေါ်

1. လူများအတွက် ပရိုဂရမ်ဘာသာစကားများ

ပရိုဂရမ်းမင်းဘာသာစကားများသည် လူများကို ကွန်ပျူတာများနှင့် စကားပြောဆိုပုံဖြစ်သည်။ ကွန်ပြူတာသည် ရှင်းရှင်းလင်းလင်းမရှိသော မည်သည့်ဘာသာစကားကိုမဆို ကျေနပ်စွာပြောဆိုနိုင်မည်ဖြစ်သည်။ ကျွန်ုပ်တို့တွင် အဆင့်မြင့်ဘာသာစကားများ ရှိနေရခြင်းမှာ လူများသည် စက်ဘာသာစကားကို မကိုင်တွယ်နိုင်သောကြောင့် ဖြစ်သည်။ ပရိုဂရမ်းမင်းဘာသာစကားများ၏ အဓိကအချက်မှာ ကျွန်ုပ်တို့၏ ညံ့ဖျင်းသော၊ နုနယ်သော လူ့ဦးနှောက်များကို အသေးစိတ်အချက်များစွာဖြင့် လွှမ်းမိုးခြင်းမှ တားဆီးရန်ဖြစ်သည်။

ဗိသုကာပညာရှင်များသည် အချို့သော ဒီဇိုင်းပြဿနာများသည် အခြားအရာများထက် သာလွန်ကောင်းမွန်ကြောင်း သိကြသည်။ အရှင်းဆုံးနှင့် အထင်ရှားဆုံး ဒီဇိုင်းပြဿနာအချို့မှာ တံတားဒီဇိုင်းများဖြစ်သည်။ ဤအခြေအနေမျိုးတွင် သင့်အလုပ်မှာ လိုအပ်သောအကွာအဝေးကို တတ်နိုင်သမျှ ပစ္စည်းနည်းနည်းဖြင့် ကာရန်ဖြစ်သည်။ ရောင်စဉ်၏အခြားအဆုံးတွင်ကုလားထိုင်ဒီဇိုင်းဖြစ်သည်။ သဘာပတိ ဒီဇိုင်နာများသည် လူတို့၏ တင်ပါးများအကြောင်းကို အချိန်ဖြုန်းသင့်သည်။

ဆော့ဖ်ဝဲ ဖွံ့ဖြိုးတိုးတက်မှုတွင် အလားတူ ခြားနားချက်ရှိသည်။ ကွန်ရက်တစ်ခုမှတဆင့် ဒေတာလမ်းကြောင်းပေးရန်အတွက် အယ်လဂိုရီသမ်များကို ဒီဇိုင်းဆွဲခြင်းသည် တံတားများကို ဒီဇိုင်းထုတ်ခြင်းကဲ့သို့ ကောင်းသော၊ စိတ္တဇပြဿနာတစ်ခုဖြစ်သည်။ ပရိုဂရမ်းမင်းဘာသာစကားများကို ဒီဇိုင်းဆွဲခြင်းသည် ကုလားထိုင်များကို ဒီဇိုင်းဆွဲခြင်းနှင့်တူသော်လည်း၊ သင်သည် လူသားတို့၏ အားနည်းချက်များကို ကိုင်တွယ်ဖြေရှင်းရမည်ဖြစ်သည်။

ဒါက ကျွန်တော်တို့ အများစု နားလည်ရခက်ပါတယ်။ အံဝင်ခွင်ကျရှိသော သင်္ချာစနစ်များကို ဒီဇိုင်းဆွဲခြင်းသည် လူသားများ၏ အားနည်းချက်များကို လှည့်စားခြင်းထက် ကျွန်ုပ်တို့အများစုအတွက် ပိုမိုဆွဲဆောင်မှုရှိသည်။ သင်္ချာဆိုင်ရာ ကျက်သရေရှိမှု၏ အခန်းကဏ္ဍမှာ အချို့သော ကျက်သရေရှိမှုတို့သည် ပရိုဂရမ်များကို နားလည်ရန် ပိုမိုလွယ်ကူစေသည်။ ဒါပေမယ့် အဲဒါတွေအားလုံးက ကျက်သရေရှိမှု မဟုတ်ဘူး။

လူသားတွေရဲ့ အားနည်းချက်တွေကို လိုက်လျောညီထွေဖြစ်အောင် ဘာသာစကားတွေကို ဒီဇိုင်းထုတ်သင့်တယ်လို့ ပြောတဲ့အခါ၊ ဘာသာစကားတွေကို မကောင်းတဲ့ ပရိုဂရမ်မာတွေအတွက် ဒီဇိုင်းထုတ်ရမယ်လို့ မဆိုလိုပါဘူး။ လက်တွေ့တွင်၊ အကောင်းဆုံး ပရိုဂရမ်မာများအတွက် ဆော့ဖ်ဝဲကို ဒီဇိုင်းဆွဲသင့်သော်လည်း အကောင်းဆုံး ပရိုဂရမ်မာများပင်လျှင် ၎င်းတို့၏ အကန့်အသတ်များရှိသည်။ အက္ခရာ "x" ဖြင့် ကိန်းပြည့် subscripts များဖြင့် ကိန်းရှင်အားလုံးကို ဖော်ပြသည့် ဘာသာစကားဖြင့် ပရိုဂရမ်ရေးဆွဲခြင်းကို မည်သူမျှ နှစ်သက်လိမ့်မည်မထင်ပါ။

2. သင်ကိုယ်တိုင်နှင့် သင့်သူငယ်ချင်းများအတွက် ဒီဇိုင်းဆွဲပါ။

ပရိုဂရမ်းမင်းဘာသာစကားများ၏သမိုင်းကြောင်းကို လေ့လာကြည့်လျှင် အကောင်းဆုံးဘာသာစကားအများစုကို ၎င်းတို့၏စာရေးဆရာများက အသုံးပြုရန် ဒီဇိုင်းထုတ်ထားပြီး အဆိုးဆုံးအများစုကို အခြားသူများအသုံးပြုရန် ဒီဇိုင်းထုတ်ထားသည်။

ဘာသာစကားများကို အခြားလူများအတွက် ဒီဇိုင်းထုတ်သောအခါ၊ ၎င်းသည် အမြဲတမ်း သီးခြားလူအုပ်စုတစ်ခုဖြစ်သည်- လူများသည် ဘာသာစကားဖန်တီးသူများကဲ့သို့ စမတ်ကျခြင်းမရှိပါ။ ဤနည်းဖြင့် သင်သည် သင့်အား ပြောဆိုသော လျှာကို ရရှိစေပါသည်။ Cobol သည် အထင်ရှားဆုံး ဥပမာဖြစ်သော်လည်း ဘာသာစကားအများစုသည် ဤစိတ်ဓာတ်ဖြင့် လှောင်ပိတ်နေကြသည်။

ဘာသာစကား ဘယ်လောက်အဆင့်မြင့်တယ်ဆိုတာနဲ့ ဘာမှမဆိုင်ပါဘူး။ C သည် အဆင့်နိမ့်သော်လည်း ၎င်းကို စာရေးဆရာများက အသုံးပြုရန် ဖန်တီးထားသောကြောင့် ဟက်ကာများက ၎င်းကို နှစ်သက်ကြသည်။

မကောင်းသော ပရိုဂရမ်မာများအတွက် ဘာသာစကားများကို ဒီဇိုင်းဆွဲခြင်း၏ အကြောင်းပြချက်မှာ ကောင်းသောပရိုဂရမ်မာများထက် ဆိုးရွားသော ပရိုဂရမ်မာများ ပိုများနေခြင်းဖြစ်သည်။ ဒါပြောထားတာ။ ဒါပေမယ့် ဒီပရိုဂရမ်မာကောင်းကောင်းလေးတွေက ဆော့ဖ်ဝဲလ်ကို အချိုးမညီစွာ ရေးကြပါတယ်။

ကျွန်တော့်မေးခွန်းကတော့ အကောင်းဆုံးဟက်ကာတွေအတွက် ဆွဲဆောင်မှုရှိတဲ့ ဘာသာစကားတစ်ခုကို သင်ဘယ်လိုဖန်တီးမလဲ။ ဒီမေးခွန်းဟာ ကောင်းမွန်တဲ့ ပရိုဂရမ်းမင်းဘာသာစကားကို ဘယ်လိုဖန်တီးရမလဲဆိုတဲ့ မေးခွန်းနဲ့ ထပ်တူကျတယ်လို့ ထင်ရပေမယ့် အဲဒါမဟုတ်ရင်တောင် အနည်းဆုံးတော့ စိတ်ဝင်စားစရာကောင်းတဲ့ မေးခွန်းတစ်ခုပါပဲ။

3. ပရိုဂရမ်မာကို တတ်နိုင်သမျှ ထိန်းချုပ်ပေးပါ။

ဘာသာစကားများစွာ (အထူးသဖြင့် အခြားလူများအတွက် ဒီဇိုင်းထုတ်ထားသော) သည် nannies များကဲ့သို့ ပြုမူကြသည်- သူတို့သည် သင့်အတွက် အသုံးမဝင်ဟု ထင်သည့်အရာများမှ သင့်ကို သတိပေးရန် ကြိုးစားကြသည်။ ကျွန်တော်ကတော့ ဆန့်ကျင်ဘက်အမြင်ကို ယူပါတယ်။ ပရိုဂရမ်မာကို တတ်နိုင်သမျှ ထိန်းချုပ်ပေးလိုက်ပါ။

Lisp ကို စလေ့လာတုန်းက ကျွန်တော် အကြိုက်ဆုံးက ညီတူမျှတူ စကားပြောတာ ပါ။ အဲဒီ့အချိန်က ကျွန်တော် သင်ယူခဲ့တဲ့ အခြားဘာသာစကားတွေမှာ ဘာသာစကားတစ်ခုရှိတယ်၊ အဲဒီဘာသာစကားမှာ ကျွန်တော့်ရဲ့ ပရိုဂရမ်လည်း ရှိတယ်၊ အဲဒါတွေက သီးခြားစီ တည်ရှိနေတယ်။ ဒါပေမယ့် Lisp မှာ၊ ကျွန်တော်ရေးတဲ့ functions နဲ့ macro တွေဟာ language ကိုယ်တိုင်ရေးထားတဲ့ အတူတူပါပဲ။ ဘာသာစကားကို လိုချင်ရင် ကျွန်တော်ကိုယ်တိုင် ပြန်ရေးနိုင်တယ်။ ၎င်းတွင် open source ဆော့ဖ်ဝဲကဲ့သို့ တူညီသော ဆွဲဆောင်မှုရှိသည်။

4. Brevity သည် ပင်ကိုယ်စွမ်းရည်၏ ညီမဖြစ်သည်။

Brevity ကို အဆင့်သတ်မှတ်ထားပြီး မထီမဲ့မြင်ပြုခြင်းပင်။ ဒါပေမယ့် ဟက်ကာတွေရဲ့ နှလုံးသားထဲကို ကြည့်လိုက်ရင် သူတို့ဟာ အတိုချုံးကို တကယ်ကြိုက်တာကို တွေ့လိမ့်မယ်။ ဟက်ကာများက APL ကုဒ်မျဉ်းနှစ်ကြောင်းမျှဖြင့် အံ့သြဖွယ်အရာများကို မည်သို့လုပ်ဆောင်နိုင်သည်ကို ဟက်ကာများက နှစ်သက်စွာပြောဆိုကြသည်ကို ဘယ်နှစ်ကြိမ်ကြားဖူးပါသလဲ။ တကယ်ကို ဉာဏ်ကောင်းတဲ့လူတွေက ဒါကို အာရုံစိုက်တာကို သဘောကျတယ်လို့ ထင်ပါတယ်။

ပရိုဂရမ်တွေကို တိုတိုလေးဖြစ်စေတဲ့ အရာအားလုံးနီးပါးက ကောင်းတဲ့အရာလို့ ကျွန်တော်ယုံကြည်ပါတယ်။ စာကြည့်တိုက်လုပ်ငန်းဆောင်တာများစွာရှိသင့်သည်၊ သွယ်ဝိုက်ဖော်ပြနိုင်သော အရာအားလုံးသည် ထိုကဲ့သို့ဖြစ်သင့်သည်။ syntax သည် ပိုတိုသင့်သည်။ အဖွဲ့အစည်းအမည်များပင် တိုစေရမည်။

ထိုမျှမက ပရိုဂရမ်များသည် တိုတောင်းသင့်သည်။ လက်စွဲစာအုပ်များလည်း တိုတောင်းသင့်သည်။ လက်စွဲစာအုပ်၏ ကောင်းမွန်သော အစိတ်အပိုင်းတစ်ခုတွင် ရှင်းလင်းချက်များ၊ ငြင်းဆိုချက်များ၊ သတိပေးချက်များနှင့် အထူးကိစ္စများ ပါဝင်သည်။ အကယ်၍ သင်သည် လက်စွဲစာအုပ်ကို အတိုချုံ့ရန် လိုအပ်ပါက၊ ရှင်းလင်းချက်များစွာလိုအပ်သော ဘာသာစကားကို ပြင်ရန် အကောင်းဆုံးရွေးချယ်မှုဖြစ်သည်။

5. Hacking ဆိုတာဘာလဲ အသိအမှတ်ပြုပါ။

လူအတော်များများသည် သင်္ချာ သို့မဟုတ် အနည်းဆုံး သိပ္ပံပညာကဲ့သို့ တစ်ခုခုကို ဟက်ကာလုပ်လိုကြသည်။ Hacking က Architecture နဲ့ ပိုတူတယ်လို့ ထင်ပါတယ်။ ဗိသုကာပညာရပ်သည် ဗိသုကာတစ်ဦး ပြိုလဲမသွားသော အဆောက်အအုံကို ဒီဇိုင်းဆွဲရန် လိုအပ်သော်လည်း ဗိသုကာပညာရှင်တစ်ဦး၏ စစ်မှန်သော ရည်မှန်းချက်မှာ statics နယ်ပယ်တွင် ရှာဖွေတွေ့ရှိမှုများ ပြုလုပ်ရန်မဟုတ်ဘဲ ကြီးကျယ်သော အဆောက်အအုံကို ဖန်တီးရန်ဖြစ်သည်။

ဟက်ကာများ နှစ်သက်သည်မှာ ကောင်းမွန်သော ပရိုဂရမ်များကို ဖန်တီးရန်ဖြစ်သည်။ အနည်းဆုံးတော့ ကျွန်ုပ်တို့ရဲ့ကိုယ်ပိုင်အတွေးထဲမှာ၊ ဒီအလုပ်က သိပ္ပံနည်းကျစာတမ်းတွေရဲ့ သာမာန်ဉာဏငွေကြေးအဖြစ် လွယ်လွယ်ကူကူ ဘာသာမပြန်နိုင်ရင်တောင် ကောင်းမွန်တဲ့ ပရိုဂရမ်တွေရေးတာဟာ အံ့သြစရာကောင်းတဲ့ အရာတစ်ခုလို့ မှတ်သားထားသင့်တယ်လို့ ကျွန်တော်ထင်ပါတယ်။ ဉာဏရှုထောင့်မှကြည့်လျှင် ပရိုဂရမ်မာများ နှစ်သက်မည့် ဘာသာစကားတစ်ခုကို ဒီဇိုင်းဆွဲရန်မှာ အရေးကြီးသည်မှာ စာရွက်တစ်ရွက်ကို ထုတ်ဝေနိုင်သည့် အိုင်ဒီယာတစ်ခုနှင့် ပေါင်းစပ်ထားသည့် ကြောက်မက်ဖွယ်ကောင်းသော ဒီဇိုင်းတစ်ခုဖြစ်သည်။

ပြဿနာများကို ဖွင့်ပါ။

1. စာကြည့်တိုက်ကြီးတွေကို ဘယ်လိုစုစည်းမလဲ။

စာကြည့်တိုက်များသည် ပရိုဂရမ်းမင်းဘာသာစကားများ၏ အရေးပါသော အစိတ်အပိုင်းတစ်ခု ဖြစ်လာပါသည်။ ၎င်းတို့သည် အလွန်ကြီးမားသောကြောင့် အန္တရာယ်ရှိနိုင်သည်။ ၎င်းလုပ်ဆောင်ချက်ကို ကိုယ်တိုင်ရေးရန်ထက် သင်လိုအပ်သည့်အရာများကို လုပ်ဆောင်နိုင်သည့် စာကြည့်တိုက်တစ်ခုတွင် လုပ်ဆောင်ချက်တစ်ခုကို ရှာတွေ့ရန် အချိန်ပိုကြာပါက၊ ကုဒ်အားလုံးသည် သင့်လက်စွဲစာအုပ်ကို ပိုထူအောင်ပြုလုပ်ရုံမှတပါး အခြားဘာမျှ မလုပ်နိုင်ပါ။ (Symbolics လက်စွဲများသည် ဤအရာ၏ ဥပမာတစ်ခုဖြစ်သည်။) ထို့ကြောင့် စာကြည့်တိုက်အဖွဲ့အစည်းပြဿနာကို ဖြေရှင်းရမည်ဖြစ်ပါသည်။ အကောင်းဆုံးအားဖြင့်၊ ပရိုဂရမ်မာသည် မည်သည့်စာကြည့်တိုက်လုပ်ဆောင်ချက်ကို သင့်လျော်ကြောင်း ခန့်မှန်းနိုင်စေရန် ၎င်းတို့ကို ဒီဇိုင်းဆွဲပါ။

2. လူတွေက ရှေ့ဆက်အထားအသိုကို တကယ်ကြောက်နေသလား။

နှစ်အတော်ကြာအောင် စဉ်းစားပြီး အဖြေကို မသိသေးသည့် သဘောဖြင့် ဤသည်မှာ ပွင့်ပွင့်လင်းလင်း ပြဿနာဖြစ်သည်။ Prefix syntax ကို သင်္ချာမှာသုံးတာကလွဲရင် ကျွန်တော့်အတွက် လုံးဝသဘာဝကျပုံရတယ်။ ဒါပေမယ့် Lisp ရဲ့ လူကြိုက်များမှု အများစုဟာ မရင်းနှီးတဲ့ အထားအသိုကြောင့် ဖြစ်နိုင်ပါတယ်။

3. ဆာဗာဆော့ဖ်ဝဲအတွက် သင်ဘာလိုအပ်ပါသလဲ။

နောင်အနှစ်နှစ်ဆယ်တွင် ရေးသားမည့် application အများစုသည် ဝဘ်အက်ပလီကေးရှင်းများဖြစ်မည်ဟု ကျွန်တော်ထင်သည်၊ ပရိုဂရမ်များသည် ဆာဗာတစ်ခုပေါ်တွင် တည်ရှိပြီး ဝဘ်ဘရောက်ဆာမှတစ်ဆင့် သင်နှင့် ဆက်သွယ်မည်ဟု ယူဆပါသည်။ ထိုကဲ့သို့သော အသုံးချပရိုဂရမ်များကို ရေးသားရန်အတွက် ကျွန်ုပ်တို့သည် အသစ်သောအရာများ လိုအပ်ပါသည်။

ထိုအရာများထဲမှတစ်ခုမှာ ဆာဗာအက်ပ်လီကေးရှင်းများကို ထုတ်လွှတ်ရန် နည်းလမ်းအသစ်အတွက် ပံ့ပိုးမှုဖြစ်သည်။ ဒက်စ်တော့ဆော့ဖ်ဝဲလ်ကဲ့သို့ တစ်နှစ်လျှင် အကြီးကြီးတစ်ခု သို့မဟုတ် နှစ်ခုထုတ်မည့်အစား၊ ဆာဗာဆော့ဖ်ဝဲသည် သေးငယ်သောပြောင်းလဲမှုများ ဆက်တိုက်ထွက်ရှိလာမည်ဖြစ်သည်။ တစ်နေ့လျှင် ထုတ်ဝေမှု ငါးကြိမ် သို့မဟုတ် ဆယ်ကြိမ် ရှိနိုင်သည်။ ပြီးတော့ လူတိုင်းမှာ နောက်ဆုံးထွက်ဗားရှင်း အမြဲရှိနေမှာပါ။

ထိန်းသိမ်းနိုင်စေရန် ပရိုဂရမ်များကို ဒီဇိုင်းရေးဆွဲနည်း သင်သိပါသလား။ ပြောင်းလဲနိုင်သော ဆာဗာဆော့ဖ်ဝဲကို ဒီဇိုင်းထုတ်ရပါမည်။ ၎င်းကို အလွယ်တကူ ပြောင်းလဲနိုင်သင့်သည် သို့မဟုတ် အနည်းဆုံး ပြောင်းလဲမှုအသေးစားတစ်ခု၏ အဓိပ္ပါယ်နှင့် အရေးကြီးသောအရာကို သိသင့်သည်။

ဆာဗာဆော့ဖ်ဝဲလ်တွင် အသုံးဝင်နိုင်သည့် နောက်ထပ်အရာတစ်ခုမှာ၊ ရုတ်တရက် ပေးပို့ခြင်း၏ အဆက်မပြတ်ဖြစ်သည်။ ဝဘ်အက်ပလီကေးရှင်းတစ်ခုတွင် သင်ကဲ့သို့ တစ်ခုခုကို အသုံးပြုနိုင်သည်။ CPSဝဘ်အစည်းအဝေးများ၏ နိုင်ငံမဲ့ကမ္ဘာရှိ လုပ်ရိုးလုပ်စဉ်များ၏ အကျိုးသက်ရောက်မှုကို ရယူရန်။ လုပ်ဆောင်ချက်သည် အလွန်စျေးမကြီးပါက ထောက်ပံ့မှုအဆက်မပြတ်ရှိနေခြင်းသည် ထိုက်တန်ပါသည်။

4. မည်ကဲ့သို့သော စိတ်ကူးစိတ်သန်းအသစ်များကို ရှာဖွေတွေ့ရှိရန် ကျန်နေသေးသနည်း။

ထိုမျှော်လင့်ချက်သည် မည်မျှ ကျိုးကြောင်းဆီလျော်သည်ကို ကျွန်ုပ်မသိပါ၊ သို့သော် ကျွန်ုပ်သည် ပထမတန်းစားလုပ်ဆောင်ချက်များ သို့မဟုတ် ထပ်ခါတလဲလဲ သို့မဟုတ် အနည်းဆုံး ပုံသေဘောင်များကဲ့သို့ အဓိပ္ပာယ်ရှိနိုင်သည့် စိတ်ကူးသစ်တစ်ခုကို ကိုယ်တိုင်ရှာဖွေတွေ့ရှိလိုပါသည်။ ဒါက မဖြစ်နိုင်တဲ့ အိပ်မက်တစ်ခု ဖြစ်နိုင်တယ်။ ထိုသို့သော အရာများကို မကြာခဏ ဖော်ထုတ်လေ့မရှိပါ။ ဒါပေမယ့် ငါမျှော်လင့်ချက် မဆုံးရှုံးဘူး။

လူသိနည်းသောလျှို့ဝှက်ချက်များ

1. သင်အလိုရှိသော မည်သည့်ဘာသာစကားကိုမဆို အသုံးပြုနိုင်ပါသည်။

ယခင်က အက်ပ်လီကေးရှင်းများ ဖန်တီးခြင်းသည် desktop ဆော့ဖ်ဝဲလ် ဖန်တီးခြင်းကို ဆိုလိုသည်။ ထို့အပြင် desktop software တွင် operating system ကဲ့သို့တူညီသောဘာသာစကားဖြင့် application များရေးသားခြင်းအပေါ်ကြီးမားသောဘက်လိုက်မှုရှိသည်။ ထို့ကြောင့် လွန်ခဲ့သော ဆယ်နှစ်က ယေဘုယျအားဖြင့် ဆော့ဖ်ဝဲလ်ရေးခြင်းသည် C တွင် ဆော့ဖ်ဝဲလ်ရေးသားခြင်းကို ဆိုလိုပါသည်။ နောက်ဆုံးတွင် အစဉ်အလာသည် ပြောင်းလဲလာသည်- အပလီကေးရှင်းများကို ပုံမှန်မဟုတ်သော ဘာသာစကားများဖြင့် မရေးသင့်ပါ။ မန်နေဂျာများနှင့် အရင်းရှင်အရင်းရှင်များကဲ့သို့ နည်းပညာမဟုတ်သော သူများသည်လည်း ၎င်းကို သင်ယူခဲ့သည်မှာ ကြာရှည်စွာပင် ဤဓလေ့သည် ပြောင်းလဲလာခဲ့သည်။

ဆာဗာဆော့ဖ်ဝဲသည် ဤမော်ဒယ်လ်ကို လုံးဝပျက်စီးစေသည်။ ဆာဗာဆော့ဖ်ဝဲဖြင့် သင်အလိုရှိသော မည်သည့်ဘာသာစကားကိုမဆို အသုံးပြုနိုင်သည်။ ဒါကို ဘယ်သူမှ နားမလည်သေးပါဘူး (အထူးသဖြင့် မန်နေဂျာများနှင့် အရင်းရှင်များ)။ သို့သော် အချို့သောဟက်ကာများက ၎င်းကိုနားလည်သောကြောင့် Perl နှင့် Python ကဲ့သို့သော indy ဘာသာစကားများအကြောင်း ကျွန်ုပ်တို့ကြားနေရသည်။ လူတွေက Windows အပလီကေးရှင်းတွေရေးဖို့ သုံးတဲ့အတွက် Perl နဲ့ Python အကြောင်းမကြားရပါဘူး။

ပရိုဂရမ်းမင်းဘာသာစကား ဒီဇိုင်းကို စိတ်ဝင်စားသူများ၊ ကျွန်ုပ်တို့၏လုပ်ငန်းအတွက် အလားအလာရှိသော ပရိသတ်ရှိနေကြောင်း၊ ၎င်းသည် ကျွန်ုပ်တို့အတွက် ဘာကိုဆိုလိုသနည်း။

2. မြန်နှုန်းသည် profilers မှလာသည်။

ဘာသာစကား developer များ သို့မဟုတ် အနည်းဆုံး language implementers များသည် လျင်မြန်သောကုဒ်ကိုထုတ်ပေးသည့် compilers များကိုရေးလိုကြသည်။ ဒါပေမယ့် အဲဒါက သုံးစွဲသူတွေအတွက် ဘာသာစကားတွေကို မြန်ဆန်စေတယ်လို့ ကျွန်တော်ထင်ပါတယ်။ အရှိန်အဟုန်သည် အနည်းငယ်သော ပိတ်ဆို့မှုများပေါ်တွင်မူတည်ကြောင်း ရှေးရှေးတုန်းက Knut က မှတ်ချက်ချခဲ့သည်။ ပရိုဂရမ်တစ်ခုကို အရှိန်မြှင့်ရန် ကြိုးစားဖူးသူတိုင်းသည် ပိတ်ဆို့မှုသည် မည်သည့်နေရာတွင် ရှိနေသည်ကို သင် ခန့်မှန်း၍မရနိုင်ကြောင်း သိပါသည်။ Profiler က အဖြေပါ။

ဘာသာစကား developer များသည်မှားယွင်းသောပြဿနာကိုဖြေရှင်းနေကြသည်။ အသုံးပြုသူများသည် လျင်မြန်စွာ လုပ်ဆောင်ရန် စံနှုန်းများ မလိုအပ်ပါ။ ၎င်းတို့၏ ပရိုဂရမ်၏ အစိတ်အပိုင်းများကို ပြန်လည်ရေးသားရန် လိုအပ်ကြောင်း ပြသနိုင်သည့် ဘာသာစကားတစ်ခု လိုအပ်သည်။ ဤအချိန်တွင် လက်တွေ့တွင် အရှိန်အဟုန် လိုအပ်သည်။ ထို့ကြောင့် ဘာသာစကား အကောင်အထည်ဖော်သူများသည် compiler ကို optimize လုပ်ကာ ကောင်းသော profiler ရေးရန် အချိန်တစ်ဝက်ကို အသုံးပြုပါက ပိုကောင်းပေမည်။

3. သင့်ဘာသာစကားကို တိုးတက်စေမည့် အက်ပ်တစ်ခု လိုအပ်ပါသည်။

၎င်းသည် အဆုံးစွန်သော အမှန်တရားမဟုတ်သော်လည်း ၎င်းတို့အသုံးပြုခဲ့သည့် အပလီကေးရှင်းများနှင့်အတူ အကောင်းဆုံးဘာသာစကားများ ပြောင်းလဲလာပုံရသည်။ C ကို system programming လိုအပ်သူများမှရေးသားခဲ့သည် ။ Lisp သည် ပုံသဏ္ဍာန်ကွဲပြားခြင်းအတွက် တစ်စိတ်တစ်ပိုင်း ဒီဇိုင်းထုတ်ထားပြီး McCarthy သည် စတင်ရန် စိတ်အားထက်သန်နေသောကြောင့် 1960 ခုနှစ်တွင် ပထမဆုံး Lisp စာတမ်းတွင် ကွဲပြားခြင်းပရိုဂရမ်များကိုပင် စတင်ရေးသားခဲ့သည်။

သင့်အပလီကေးရှင်းမှ ပြဿနာအသစ်အချို့ကို ဖြေရှင်းပေးမည်ဆိုပါက ၎င်းသည် အထူးကောင်းမွန်ပါသည်။ ၎င်းသည် သင့်ဘာသာစကားတွင် ပရိုဂရမ်မာများ လိုချင်သည့် အင်္ဂါရပ်အသစ်များ ရှိစေရန် တွန်းအားပေးသည်။ ကိုယ်တိုင်ကိုယ်ကျ၊ ကျွန်ုပ်သည် server applications များအတွက် ကောင်းမွန်စေမည့် ဘာသာစကားတစ်ခုကို ရေးသားရန် စိတ်ဝင်စားပါသည်။

[ဆွေးနွေးစဉ်တွင်၊ Guy Steele သည် အပလီကေးရှင်းတွင် သင့်ဘာသာစကားအတွက် compiler တစ်ခုရေးသားရန် မပါဝင်သင့်ကြောင်း၊ သင်၏ဘာသာစကားကို compilers ရေးရန် ဒီဇိုင်းထုတ်ထားခြင်းမရှိပါက ဤအချက်ကိုလည်း ထည့်သွင်းပြောကြားခဲ့သည်။]

4. ဘာသာစကားသည် တစ်ကြိမ်တည်း ပရိုဂရမ်ရေးရန်အတွက် သင့်လျော်ရမည်။

တစ်ချက်တည်းရိုက်ချက်ပရိုဂရမ်က ဘာကိုဆိုလိုတယ်ဆိုတာ သင်သိပါတယ်- ကန့်သတ်ပြဿနာအချို့ကို အမြန်ဖြေရှင်းဖို့ လိုအပ်တဲ့အချိန်ဖြစ်ပါတယ်။ လှည့်ကြည့်လိုက်ရင် လေးနက်တဲ့ ပရိုဂရမ်များစွာကို တစ်ကြိမ်တည်းနဲ့ စတင်ခဲ့တာ တွေ့ရလိမ့်မယ်လို့ ယုံကြည်ပါတယ်။ ပရိုဂရမ်အများစုသည် တစ်ကြိမ်တည်းဖြင့် စတင်ပါက အံ့သြမည်မဟုတ်ပါ။ ထို့ကြောင့် ယေဘုယျအားဖြင့် ဆော့ဖ်ဝဲလ်ရေးသားရန် သင့်လျော်မည့် ဘာသာစကားတစ်ခုကို ဖန်တီးလိုပါက၊ ၎င်းသည် ပရိုဂရမ်များစွာ၏ ကနဦးအဆင့်ဖြစ်သောကြောင့် ၎င်းသည် တစ်ခုတည်းသော ပရိုဂရမ်များကို ရေးသားရန်အတွက်လည်း သင့်လျော်မည်ဖြစ်သည်။

5. Syntax သည် semantics နှင့် သက်ဆိုင်သည်။

syntax နှင့် semantics တို့သည် အလွန်ကွဲပြားခြားနားသော အရာများဖြစ်သည်ဟု ရှေးယခင်ကတည်းက ယုံကြည်ကြသည်။ ဒါက ထိတ်လန့်စရာလို့ထင်ရပေမယ့် အဲဒါမဟုတ်ပါဘူး။ မင်းရဲ့ ပရိုဂရမ်မှာ မင်းအောင်မြင်ချင်တဲ့အရာက မင်းဖော်ပြပုံနဲ့ သက်ဆိုင်တယ်လို့ ငါထင်ပါတယ်။

မကြာသေးမီက ကျွန်ုပ်သည် Robert Morris နှင့် စကားပြောခဲ့ပြီး အော်ပရေတာအား အလွန်အကျွံ တင်ခြင်းသည် infix syntax ပါသော ဘာသာစကားများ၏ အောင်ပွဲအတွက် ကြီးမားသော အကျိုးကျေးဇူးဖြစ်ကြောင်း မှတ်ချက်ပြုခဲ့သည်။ prefix syntax ပါသော ဘာသာစကားများတွင် သင်သတ်မှတ်ထားသော မည်သည့် function သည် အမှန်တကယ် အော်ပရေတာတစ်ခုဖြစ်သည်။ သင်ဖန်တီးထားသည့် နံပါတ်အမျိုးအစားအသစ်တစ်ခုကို ထည့်လိုပါက၊ ၎င်းကိုထည့်ရန် လုပ်ဆောင်ချက်အသစ်တစ်ခုကို သင်ရိုးရှင်းစွာ သတ်မှတ်နိုင်သည်။ သင်သည် infix syntax ဖြင့် ၎င်းကို ဘာသာစကားတစ်ခုဖြင့် ပြုလုပ်ပါက၊ overloaded operator ကိုအသုံးပြုခြင်းနှင့် function တစ်ခုခေါ်ဆိုခြင်းကြားတွင် ကြီးမားသော ခြားနားချက်ရှိသည်ကို သင်တွေ့ရပါမည်။

အချိန်နှင့်အမျှ ပြန်ပေါ်လာသော စိတ်ကူးများ

1. ပရိုဂရမ်းမင်းဘာသာစကားအသစ်များ

1970 ခုနှစ်များကို ပြန်ကြည့်လျှင် ပရိုဂရမ်းမင်းဘာသာစကားအသစ်များ တီထွင်ရန် ခေတ်ဆန်ခဲ့သည်။ ဒါက အခုကိစ္စမဟုတ်ဘူး။ ဒါပေမယ့် ဆာဗာဆော့ဖ်ဝဲက ဘာသာစကားအသစ်ဖန်တီးမှုအတွက် ဖက်ရှင်ကို ပြန်ယူဆောင်လာလိမ့်မယ်လို့ ကျွန်တော်ယုံကြည်ပါတယ်။ ဆာဗာဆော့ဖ်ဝဲဖြင့် သင်အလိုရှိသော မည်သည့်ဘာသာစကားကိုမဆို သုံးနိုင်သည်၊ ထို့ကြောင့် တစ်စုံတစ်ဦးသည် အခြားဘာသာစကားထက် ပိုကောင်းသည်ဟု ထင်မြင်ပါက ၎င်းကို အသုံးပြုရန် ဆုံးဖြတ်မည့်သူများ ရှိလိမ့်မည်။

2. အချိန်မျှဝေခြင်း။

Richard Kelsey သည် အချိန်ရောက်လာပြီဖြစ်၍ ဤအကြံကို ကျွန်တော် အပြည့်အဝ ထောက်ခံပါသည်။ ကျွန်ုပ်၏ ခန့်မှန်းချက် (နှင့် Microsoft သည်လည်း) တွက်ချက်မှု အများအပြားသည် ဒက်စ်တော့မှ အဝေးထိန်း ဆာဗာများဆီသို့ ရွေ့သွားလိမ့်မည် ဖြစ်သည်။ တစ်နည်းဆိုရသော် အချိန်ခွဲဝေမှု ပြန်ရောက်လာသည်။ ဘာသာစကား အဆင့်မှာ ပံ့ပိုးမှု လိုအပ်မယ်လို့ ထင်ပါတယ်။ ဥပမာအားဖြင့်၊ Richard နှင့် Jonathan Reeves တို့သည် Scheme 48 တွင် လုပ်ငန်းစဉ်အချိန်ဇယားဆွဲခြင်းကို အကောင်အထည်ဖော်ရန် အလုပ်များစွာပြုလုပ်ခဲ့သည်။

3. လုပ်ရည်ကိုင်ရည်

မကြာသေးမီက ကွန်ပျူတာများသည် လုံလောက်စွာ မြန်ဆန်နေပြီဟု ထင်ရသည်။ ဘိုက်ကုဒ်အကြောင်း ပိုပိုပြီးကြားနေရတယ်၊ အဲဒါက အနည်းဆုံးတော့ ကျွန်တော်တို့မှာ အရန်မှာ ပါဝါနည်းနည်းရှိတယ်လို့ ဆိုလိုတာပါ။ ဒါပေမယ့် ဆာဗာဆော့ဖ်ဝဲနဲ့တော့ ကျွန်တော်တို့မှာ မရှိဘူးထင်ပါတယ်။ တစ်စုံတစ်ဦးသည် ဆော့ဖ်ဝဲလ်ကိုလည်ပတ်သည့် ဆာဗာများအတွက် ပေးချေရမည်ဖြစ်ပြီး၊ စက်တစ်ခုစီတွင် ဆာဗာပံ့ပိုးပေးနိုင်သည့် အသုံးပြုသူအရေအတွက်သည် ၎င်းတို့၏ အရင်းအနှီးကုန်ကျစရိတ်၏ ကွဲပြားမည်ဖြစ်သည်။

အနည်းဆုံးတော့ ကွန်ပြူတာ ပိတ်ဆို့မှုတွေမှာ ထိရောက်မှု ရှိမယ် ထင်ပါတယ်။ ဆာဗာ အပလီကေးရှင်းများသည် ထိုသို့သော လုပ်ဆောင်ချက်များစွာကို လုပ်ဆောင်သောကြောင့် ၎င်းသည် I/O လုပ်ဆောင်ချက်များအတွက် အထူးအရေးကြီးပါသည်။

အဆုံးတွင်၊ bytecode သည် အဖြေမဟုတ်ကြောင်း သိနိုင်သည်။ Sun နှင့် Microsoft သည် ယခုအချိန်တွင် bytecode နယ်ပယ်တွင် ဦးထိပ်ထားပုံရသည်။ သို့သော် bytecode သည် bytecode သည် ကောင်းမွန်သော အကြံဥာဏ်ဖြစ်သောကြောင့် မဟုတ်ဘဲ လုပ်ငန်းစဉ်တစ်ခုတွင် သူကိုယ်တိုင်ထည့်သွင်းရန် အဆင်ပြေသောနေရာဖြစ်သောကြောင့် ၎င်းတို့က ထိုသို့လုပ်ဆောင်ခြင်းဖြစ်သည်။ ဒီတိုက်ပွဲတစ်ခုလုံး သတိမပြုမိဘဲ ဖြစ်သွားနိုင်တယ်။ ရယ်စရာဖြစ်မှာပါ။

ကျော့ကွင်းနှင့် ကျော့ကွင်း

1. ဖောက်သည်များ

ဤသည်မှာ ခန့်မှန်းချက်မျှသာဖြစ်သော်လည်း အကျိုးရှိစေမည့် တစ်ခုတည်းသော အသုံးချပရိုဂရမ်များမှာ လုံးဝ server-side ဖြစ်သည် ။ လူတိုင်း ဖောက်သည်ရှိမည်ဟု ယူဆချက်ဖြင့် လုပ်ဆောင်သည့် ဆော့ဖ်ဝဲကို ဒီဇိုင်းဆွဲခြင်းသည် လူတိုင်း ရိုးသားလိမ့်မည်ဟု ယူဆချက်အပေါ် အခြေခံ၍ လူ့အဖွဲ့အစည်းကို ဒီဇိုင်းထုတ်ခြင်းနှင့် တူပါသည်။ သေချာပေါက် အဆင်ပြေလိမ့်မယ်၊ ဒါပေမယ့် ဘယ်တော့မှ ဖြစ်လာမှာ မဟုတ်ဘူးလို့ ယူဆရမယ်။

ဝဘ်သုံးနိုင်သော စက်များ အရှိန်အဟုန်ဖြင့် တိုးလာမည်ဟု ကျွန်ုပ်ထင်သည်၊ ၎င်းတို့သည် အခြေခံ html နှင့် ပုံစံများကို ပံ့ပိုးပေးလိမ့်မည်ဟု ကျွန်ုပ်တို့ ယူဆနိုင်ပါသည်။ သင့်ဖုန်းတွင် browser တစ်ခုရှိပါသလား။ မင်းရဲ့ PalmPilot မှာ ဖုန်းရှိမှာလား။ သင့်ဘလက်ဘယ်ရီသီးတွင် ပိုကြီးသော မျက်နှာပြင်ရှိမည်လား။ မင်းရဲ့ gameboy ဆီက အင်တာနက်သုံးနိုင်မလား။ သင့်နာရီမှ ကျွန်တော်မသိပါ။ ပြီးတော့ အရာအားလုံးက ဆာဗာပေါ်မှာ ရှိနေမယ်ဆိုတာ ငါ လောင်းကြေးထပ်မလား။ ဆာဗာပေါ်တွင် ဦးနှောက်အားလုံးရှိရန်မှာ ပို၍ယုံကြည်စိတ်ချရပါသည်။ .

2. Object-oriented programming

ဤသည်မှာ အငြင်းပွားဖွယ်ထုတ်ပြန်ချက်တစ်ခုဖြစ်ကြောင်း ကျွန်ုပ်နားလည်သော်လည်း OOP သည် ဤမျှအရေးကြီးသည်ဟု ကျွန်ုပ်မထင်ပါ။ Windowing စနစ်များ၊ သရုပ်ဖော်မှုများ၊ CAD စနစ်များကဲ့သို့ သီးခြားဒေတာဖွဲ့စည်းပုံများ လိုအပ်သည့် သီးခြားအပလီကေးရှင်းများအတွက် သင့်လျော်သော စံနှုန်းတစ်ခုဖြစ်သည်ဟု ကျွန်တော်ထင်ပါတယ်။ ဒါပေမယ့် ပရိုဂရမ်အားလုံးအတွက် ဘာကြောင့် သင့်လျော်သင့်လဲဆိုတာ ကျွန်တော် နားမလည်ပါဘူး။

ကုမ္ပဏီကြီးတွေက လူတွေက OOP ကို ​​တစ်စိတ်တစ်ပိုင်း သဘောကျကြတယ်၊ ဘာကြောင့်လဲဆိုတော့ ဒါက အလုပ်နဲ့တူတဲ့ အရာတွေ အများကြီးကို ဖန်တီးပေးလို့ပါပဲ။ ကိန်းပြည့်များစာရင်းအဖြစ် သဘာဝအားဖြင့် ကိုယ်စားပြုနိုင်သည့်အရာကို ယခုအခါ ငြမ်းများ၊ ရှုပ်ပွနေသော စာသင်ခန်းတစ်ခုအဖြစ် ကိုယ်စားပြုနိုင်ပါပြီ။

OOP ၏နောက်ထပ်ဆွဲဆောင်မှုရှိသောအင်္ဂါရပ်မှာနည်းလမ်းများသည်သင့်အားပထမတန်းစားလုပ်ဆောင်ချက်များ၏အကျိုးသက်ရောက်မှုအချို့ကိုပေးဆောင်သည်။ သို့သော် ၎င်းသည် Lisp ပရိုဂရမ်မာများအတွက် သတင်းမဟုတ်ပါ။ သင့်တွင် စစ်မှန်သော ပထမတန်းစား လုပ်ဆောင်ချက်များ ရှိသောအခါ၊ အရာအားလုံးကို အတန်းများနှင့် နည်းလမ်းများ ၏ boilerplate ထဲသို့ တွန်းချမည့်အစား လက်ထဲတွင်ရှိသော အလုပ်နှင့် ကိုက်ညီသည့် မည်သည့်နည်းဖြင့် ၎င်းတို့ကို ရိုးရှင်းစွာ အသုံးပြုနိုင်သည်။

ဘာသာစကား ဒီဇိုင်းအတွက် ဆိုလိုသည်မှာ OOP ကို ​​၎င်းတွင် အလွန်နက်ရှိုင်းစွာ မထည့်သင့်ဟု ကျွန်တော် ထင်ပါတယ်။ အဖြေမှာ ပို၍ ယေဘူယျအားဖြင့် အခြေခံကျသော အရာများကို ပေးဆောင်ရန်နှင့် လူများ မည်သည့်အရာဝတ္တုစနစ်များကို စာကြည့်တိုက်များအဖြစ် ဒီဇိုင်းထုတ်ခွင့်ပြုခြင်းလည်း ဖြစ်နိုင်သည်။

3. ကော်မတီမှ ဒီဇိုင်းဆွဲခြင်း။

သင့်ဘာသာစကားကို ကော်မတီတစ်ခုက ဒီဇိုင်းထုတ်ထားပါက လူတိုင်းသိသည့် အကြောင်းပြချက်ကြောင့်သာ သင် ပိတ်မိနေပါသည်။ ကော်မတီများသည် တသမတ်တည်း မညီသော ဘာသာစကားပုံစံများကို ဖန်တီးတတ်သည်ကို လူတိုင်းသိသည်။ ဒါပေမယ့် အန္တရာယ် ကြီးကြီးမားမားကတော့ သူတို့ အန္တရာယ်ကို မယူကြလို့ ထင်ပါတယ်။ လူတစ်ဦး တာဝန်ယူသောအခါတွင် ကော်မတီက တာဝန်ယူရန် မည်သည့်အခါမျှ သဘောတူမည်မဟုတ်ကြောင်း စွန့်စားရ၏။

ဘာသာစကားကောင်းတစ်ခုဖန်တီးရန် စွန့်စားလိုပါသလား။ ဘာသာစကား ဒီဇိုင်းသည် မိရိုးဖလာ ဉာဏ်ပညာနှင့် အတော်လေး နီးစပ်နေရန် လိုအပ်သည် ဟု လူအများက သံသယ ဖြစ်နိုင်ပါသည်။ အလောင်းအစားက ဒီလိုမဟုတ်ဘူး။ အခြားသူများလုပ်သမျှတွင်၊ ဆုလာဘ်သည် အန္တရာယ်နှင့် အချိုးကျပါသည်။ ဒါဆို ဘာသာစကား ဒီဇိုင်းက ဘာကြောင့် မတူသင့်တာလဲ။

source: www.habr.com