types.markdown

Types

A type is a collection of possible values. An integer can have values 0, 1, 2, 3, etc.; a boolean can have values true and false. We can imagine any type we like: for example, a HighFive type that allows the values "hi" or 5, but nothing else. It's not a string and it's not an integer; it's its own, separate type.

Type ဆိုသည်မှာဖြစ်နိုင်ခြေရှိသော တန်ဖိုးအစုအဝေးတစ်ခုဖြစ်သည်။ integer တစ်လုံးသည် ၀, ၁, ၂, ၃ အစရှိသည့်တန်ဖိုးများရှိနိုင်သည်။ Boolean တစ်လုံးသည် true နှင့် false ဟူသည့် တန်ဖိုးနှစ်မျိုးဖြစ်နိုင်သည်။ ကျွန်ုပ်တို့သည်ကျွန်ုပ်တို့ နှစ်သက်ရာ Type တစ်ခုကိုစိတ်ကူးကြည့်နိုင်သည်။ ဥပမာ တန်ဖိုး "hi" နှင့် 5 ဟူသည့်နှစ်မျိုးမှအပ အခြားတန်ဖိုးများကိုခွင့်မပြုသည့် Type တစ်ခုကိုစိတ်ကူးကြည့်မည်ဆိုပါစို့။ အဆိုပါ type သည် string တစ်ခုမဟုတ်သလို integer တစ်ခုလည်းမဟုတ်ပေ။၄င်းကိုယ်တိုင်က သီးခြား type တစ်ခုဖြစ်လေသည်။

Statically typed languages constrain variables' types: the programming language might know, for example, that x is an Integer. In that case, the programmer isn't allowed to say x = true; that would be an invalid program. The compiler will refuse to compile it, so we can't even run it. Different static type systems have different expressive power, and no popular type system can actually express our HighFive type above (though many can express other, much more subtle ideas).

Statically typed language များသည် ၄င်းတို့၏ variable များ၏ type များကိုထိန်းချုပ်သည်။ ဥပမာ variable x သည် integer ဖြစ်ကြောင်းကို Programming Language အနေနှင့်သိရှိနိုင်သည်။ ထို့အတွက် Program ရေးသားသူသည် x = trueဟူ၍ ရေးသားခွင့်မရှိပေ။ ထိုသို့ရေးသားပါက ၄င်း Program သည် မှားယွင်းသော Program တစ်ခုဖြစ်ပေလိမ့်မည်။ Compiler ကလည်း compile လုပ်ပေးရန်ငြင်းဆိုလိမ့်မည်ဖြစ်ပြီး ထို program အား run လို့ပင်ရမည်မဟုတ်ချေ။ static type system အမျိုးမျိုးတွင် ကွဲပြားခြားနးသောဖော်ညွှန်းစွမ်းဆောင်ရည်(expressive power)များရှိကြသော်လည်း မည်သည့်လူသိများသော type system မှအထက်ဖော်ပြပါ "HighFive" typeကိုဖော်ညွှန်းနိုင်ခြင်းမရှိပေ။ အချို့ကတော့ပိုမိုသိမ်မွေ့သောအတွေးအခေါ်များကို ဖော်ညွှန်းနိုင်စွမ်းရှိကြသည်။

Dynamically typed languages tag values with types: the language knows that 1 is an integer and that 2 is an integer, but it can't know that the variable x will always hold integers. The language runtime will check these tags at various points. If we try to add two values, it might check that they're both numbers, or strings, or arrays. Then it will add the values, concatenate them, or error, depending on the values' type tags.

Dynamically typed language များသည်လည်း တန်ဖိုးများအား type များနှင့်တွဲဖက်ကြသည်။ ဥပမာ language အနေဖြင့် ၁ သည် integer ဖြစ်သည်၊ ၂ သည် integer ဖြစ်သည် စသဖြင့်သိရှိသည်။ သို့ရာတွင် ၄င်းအနေနှင့် variable x သည် integer တန်ဖိုးများသာပါဝင်နေလိမ့်မည်ဟု ကံသေကံမ မပြောနိုင်ပေ။ language ၏ runtime က အမျိုးမျိုးသော နေရာများတွင် အထက်ပါ တွဲဖက်မှုများကို စစ်ဆေးရသည်။ အကယ်၍ ကျွန်ုပ်တို့က တန်ဖိုးနှစ်ကိုပေါင်းမည်ဆိုလျှင် ၄င်းက ထိုတန်ဖိုးနှစ်ခုသည် number များပေလော၊ string များပေလော၊ array များပေလောဟု စစ်ဆေးကာ သက်ဆိုင်ရာ type အလိုက်တန်ဖိုးများကို ပေါင်းခြင်း၊ တွဲဆက်ခြင်း သို့မဟုတ် error ထုတ်ပေးခြင်းစသဖြင့်ပြုလုပ်ပေးရလေသည်။

Statically typed languages

Static langauges check a program's types at compile time without executing the program. Any program whose types don't follow the type system's rules is rejected. For example, most static languages will reject the expression "a" + 1 (with C being a notable exception that allows it). The compiler knows that "a" is a string and 1 is an integer, and that + only works when the left and right hand sides are of the same type, so it doesn't need to run the program to know that there's a problem. Every expression in a statically typed language has a definite type that can be determined without executing the code.

Static langauge များသည် program တစ်ပုဒ်၏ type များကို program အားအမှန်တကယ် execute လုပ်စရာမလိုပဲ compile time မှာတင်စစ်ဆေးပေးနိုင်ကြသည်။ စနစ်ကသတ်မှတ်ထားသော typeစည်းမျဉ်းများကို မလိုက်နာသည့် မည်သည့် program ကိုမဆို စနစ်ကငြင်းပယ်သည်။ ဥပမာ static langauge အများစုက "a" + 1ဟူသောဖော်ပြချက်ကို ငြင်းပယ်ကြလိမ့်မည်ဖြစ်သည်။(ဤတွင် C language သည် ၄င်းကိုခွင့်ပြုသော မှတ်သားဖွယ်ရာ ချွင်းချက်တစ်ခုဖြစ်သည်။)"a"သည် string တစ်ခုဖြစ်ပြီး 1 သည် integer တစ်လုံးဖြစ်သည်ကို compiler နားလည်သည်။ ထို့ပြင် +သည် လက်ဝဲဘက်ရော လက်ယာဘက်ပါတူညီသော type ဖြစ်မှ အလုပ်လုပ်သည်ကိုလည်း ၄င်းကနားလည်ထားသည်။ ထို့အတွက် program ကို အမှန်တကယ် run စရာမလိုပဲ သူ့မှာ ပြသနာရှိနေသည်ကို သိနိုင်လေသည်။ statically typed language တစ်ခု၏ ဖော်ပြချက်တိုင်းတွင် ကုတ်ကို အမှန်တကယ် execute လုပ်စရာမလိုပဲ တွက်ထုတ်နိုင်သည့် တိကျသော type တစ်ခုရှိလေသည်။

Many statically typed languages require type declarations. The Java function public int add(int x, int y) takes two integers and returns a third integer. Other statically typed languages can infer types automatically. That same add function is written add x y = x + y in Haskell. We don't tell it the types, but it can infer them because it knows that + only works on numbers, so x and y must be numbers, so the function add must take two numbers as arguments. This doesn't decrease the "staticness" of the type system; Haskell's type system is notoriously static, strict, and powerful, and is more so than Java's on all three fronts.

Statically typed language တော်တော်များများတွင် type ကြေညာခြင်းအား မဖြစ်မနေလိုအပ်ချက် အဖြစ်သတ်မှတ်လေ့ရှိသည်။ Java function public int add(int x, int y) သည် integer နှစ်လုံး လက်ခံ၍ တတိယ integer တစ်လုံးကိုပြန်ထုတ်ပေးလေသည်။ အချို့သော statically typed language များကမူ type များကို အလိုအလျောက်တွက်ချက်ယူနိုင်ကြသည်။ အထက်ပါ Java function ကိုပင် Hskell ဖြင့် add x y = x + y ဟူ၍ရေးနိုင်သည်။ ကျွန်ုပ်တို့အနေနှင့် ၄င်းကို မည်သည့် type များဖြစ်သည် ဟု ကြေညာပေးစရမလိုပေ။အဘယ့်ကြောင့်ဆိုသော် Haskell compiler သည် + သည် number များနှင့်သာ အလုပ်လုပ်သည်ကို သိပြီးသားဖြစ်သည်။ ထို့ကြောင့် x နှင့် y သည် number များသာဖြစ်ရပေမည်။ ထို့ကြောင့် function add သည် number နှစ်လုံးကို argument အဖြစ်ယူရမည်ဟု တွက်ချက်နိုင်လေသည်။ ထို့ကြောင့် type များကို မကြေညာခြင်းသည် စနစ်တစ်ခု static ဖြစ်မဖြစ်ကို လျှော့ချနိုင်စွမ်းမရှိပေ။ Haskell ၏ type system သည် staticဖြစ်ခြင်း, strictဖြစ်ခြင်း, powerful ဖြစ်ခြင်းဟူသော သုံးမျက်နှာလုံးတွင် Java ထက်သာလွန်ကြောင်းလူသိများလေသည်။

Dynamically typed languages

Dynamically typed languages don't require type declarations, but also don't infer types. The types of variables aren't known at all until they have concrete values at runtime. For example, the Python function

def f(x, y):
    return x + y

can add integers, concatenate strings, concatenate lists, etc., and we can't tell which will happen without running the program. Maybe f will be called with strings at one point and integers at another point, in which case x and y hold values of different types at different times. This is why we say that values in dynamic languages have types, but variables and functions don't. The value 1 is definitely an integer, but x and y above might be anything.

Dynamically typed language များသည် type ကြေညာခြင်းအား မရှိမဖြစ်လိုအပ်ချက်အဖြစ် သတ်မှတ်ထားခြင်းမရှိပေ။ ထို့အပြင် ၄င်းတို့သည် typeများကို ကြိုတင်တွက်ယူခြင်းလည်းမရှိပေ။ variable များ၏ type များကို runtime တွင်အမှန်တကယ်တန်ဖိုးများ ရလာသည့်အချိန်မတိုင်ခင်ထိ ကြိုမသိနိုင်ပေ။ ဥပမာအားဖြင့် python function

def f(x, y):
    return x + y

သည် integer များကို ပေါင်းခြင်း၊ string များကိုချိတ်ဆက်ခြင်း၊ list များကို ချိတ်ဆက်ခြင်း အစရှိသဖြင့် ပြုလုပ်နိုင်သည်။ထို့ပြင် program ကိုတကယ် run မကြည့်ဘဲ ဘာဖြစ်လာမည်ဟု ကျွန်ုပ်တို့ မခန့်မှန်းနိုင်ပေ။ ၄င်း function f ကို တစ်ချိန်ချိန်၌ string များဖြင့် ခေါ်နိုင်သလို့ အခြားတစ်ချိန်၌ integer များဖြင့်ခေါ်နိုင်လေသည်။ဤတွင် x နှင့် y သည် ကွဲပြားသောအချိန်များ၌ ကွဲပြားသော တန်ဖိုးများ ရှိနိုင်လေသည်။ ထို့ကြောင့် dynamic langauge များ၌ တန်ဖိုးများတွင် type ရှိပြီး variable နှင့် function တွင် type မရှိဟု ပြောနိုင်ပေသည်။ ဤသဘောအရ တန်ဖိုး ၁ သည် သေချာပေါက် integer တစ်လုံးဖြစ်သော်လည်း variable x နှင့် y သည် ဘာမဆိုဖြစ်နိုင်လေသည်။

Static and dynamic languages compared

Most dynamic languages will error at runtime when types are used in incorrect ways (JavaScript is a notable exception; it tries to return a value for any expression, even when that value in nonsensical). When using dynamic languages, even a simple type error like "a" + 1 can occur in production. Static languages will prevent many such problems, though the degree of prevention depends on the power of the type system.

Dynamic language များတွင် type များကို မမှန်မကန် အသုံးပြုမိပါက runtime တွင် error တက်လိမ့်မည်ဖြစ်သည်။(ဤတွင် Javascript မှာမှတ်သားလောက်သောချွင်းချက်တစ်ခုဖြစ်သည်။ ၄င်းသည် မည်သည့်ဖော်ပြချက်အတွက်မဆို မည်မျှပင်အဓိပ္ပာယ်ကင်းမဲ့သော တန်ဖိုးပင်ဖြစ်ပါစေ တန်ဖိုးတစ်ခုခု ပြန်ထုတ်ပေးရန်ကြိုးစားလေ့ရှိသည်။) Dynamic Language များကိုအသုံးပြုရာတွင် "a" + 1ကဲ့သို့သော အလွန်ရိုးရှင်းသော type error မျိုးပင်လျှင် တကယ်အသုံးပြုသော ကုတ်တွင်ကြုံရလေ့ရှိတတ်လေသည်။ Static language များကမူ အဆိုပါပြသနာများကို ကာကွယ်ပေးနိုင်လေသည်။ သို့ရာတွင် မည်၍မည်မျှအထိ ကာကွယ်ပေးနိုင်မလဲ ဟူသောအချက်ကတော့ type system ၏ စွမ်းဆောင်နိုင်စွမ်းအပေါ် မူတည်ပေသည်။

Static and dynamic languages have fundamentally different ideas about what it means for programs to be valid. In a dynamic language, "a" + 1 is a valid program: it will begin execution, then throw an error at runtime. However, in most static languages, "a" + 1 is not a program: it won't be compiled and it won't run. It's invalid code, just as the random string of punctuation !&%^@*&%^@* is invalid code. This extra notion of validity and invalidity has no equivalent in dynamic languages.

Static နှင့် dynamic language များတွင် program တစ်ပုဒ်၏မှန်ကန်ခြင်းကို အဓိပ္ပာယ်ဖွင့်ဆိုရာတွင် အရင်းအမြစ်ကအစ ကွဲပြားခြားနားသော ခံယူချက်များရှိကြသည်။ dynamic language တစ်ခုတွင် "a" + 1 သည် မှန်ကန်သော program ဖြစ်သည်။ language သည် ၄င်းကို execute စလုပ်ပြီးမှ runtime တွင် error တက်ပေလိမ့်မည်။ သို့ရာတွင် static langauge အများစုတွင် "a" + 1ကို program တစ်ပုဒ်အဖြစ်မသတ်မှတ်ပေ။၄င်းကို compile လုပ်၍ မရသလို run လို့လည်းမရပေ။ ၄င်းသည်!&%^@*&%^@* ဟူသည့် ကျပန်းရေးထားသော ပုဒ်ဖြတ်ပုဒ်ရပ်များနှင့် အလားတူ တရားမဝင်သော ကုတ်သာဖြစ်လေသည်။ ထိုသို့ တရားဝင်ခြင်း မဝင်ခြင်းဟူသော စဉ်းစားပုံမျိုးသည် dynamic langauge များတွင် ဆင်တူမရှိပေ။

Strong and weak typing

The terms "strong" and "weak" are extremely ambiguous. Here are some ways that the terms are used:

"strong"နှင့် "weak" ဟူသော စကားလုံးများသည် အလွန်ဒွိဟဖြစ်စေသောအသုံးအနှုန်းများဖြစ်သည်။ ၄င်းစကားလုံးများကို အောက်ပါအဓိပ္ပာယ်များအတိုင်း သုံးနှုန်းလေ့ရှိသည်။

• Sometimes, "strong" means "static". That's easy enough, but it's better to say "static" instead because most of us agree on its definition.

• တစ်ခါတစ်ရံ "strong" ဟုဆိုလျှင် "static" ဖြစ်ခြင်းကိုဆိုလိုသည်။ ဤသို့ဆိုလျှင်နားလည်ရလွယ်သည်။ သို့ရာတွင် "static" ဟူသော စကားလုံးကို သုံးခြင်းက ပိုကောင်းပေမည်။ အဘယ့်ကြောင့် ဆိုသော် "static" ဖြစ်ခြင်းဟူသော ဖွင့်ဆိုချက်ကို လူအများပိုသဘောတူညီနိုင်သောကြောင့်ဖြစ်သည်။

• Sometimes, "strong" means "doesn't convert between data types implicitly". For example, JavaScript allows us to say "a" + 1, which we might call "weak typing". But almost all languages provide some level of implicit conversion, allowing automatic integer-to-float conversion like 1 + 1.1. In practice, most people using "strong" in this way have drawn a line between "acceptable" and "unacceptable" conversions. There is no generally accepted line; they're all arbitrary and specific to the person's opinions.

• တစ်ခါတစ်ရံ "strong" ဟုဆိုလျှင် "data type တစ်ခုနှင့်တစ်ခု ကြား အလိုအလျောက် ပြောင်းလဲမပစ်နိုင်ခြင်း"ကိုဆိုလိုသည်။ ဥပမာ Javascript သည် ကျွန်ုပ်တို့အား "a" + 1 ဟူ၍ ဖော်ပြခွင့်ပြုထားသည်။၄င်းကို "weak typing" ဟု ခေါ်ကြသည်။ သို့ရာတွင် langauge အားလုံးနီးပါး အလိုအလျောက် type ပြောင်းလဲမှုကို အတိုင်းအတာတစ်ခုထိတော့ ခွင့်ပြုကြသည်။ ဥပမာ1 + 1.1တွင် အလိုအလျောက် integer-to-float ပြောင်းလဲခြင်းမျိုးဖြစ်သည်။ လက်တွေ့တွင် "strong" ကို ဤသတ်မှတ်ချက်ဖြင့် အသုံးပြုသူတိုင်းနီးပါးတွင် လက်ခံနိုင်သော ပြောင်းလဲမှုနှင့် လက်မခံနိုင်သောပြောင်းလဲမှု စည်း တစ်ခုက တော့ ရှိကြသည်ပင်။ ထိုစည်း သည် အများစု သဘောကိုက်ညီသည့် စည်းမျိုးမဟုတ်ပဲ သတ်မှတ်သူ၏ ထင်မြင်ချက်အတိုင်းလက်ခံထားသော စည်းမျိုးဖြစ်လေသည်။

• Sometimes, "strong" means that there's no way to escape the language's type rules.

• တစ်ခါတစ်ရံ "strong" ဟုဆိုလျှင် langauge မှ သတ်မှတ်ထားသော type စည်းမျဉ်းများကို ကျော်လွှားရန် နည်းလမ်းမရှိဟုဆိုလိုသည်။

• Sometimes, "strong" means memory-safe. C is a notable example of a memory-unsafe language. If xs is an array of four numbers, C will happily allow code that does xs[5] or xs[1000], giving whatever value happens to be in the memory addresses after those used to store xs.

• တစ်ခါတစ်ရံ"strong" ဟုဆိုလျှင် "memory-safe" ဖြစ်ခြင်းကိုဆိုလိုသည်။ C သည် memory-safe မဖြစ်သော ထင်ရှားသည့် language တစ်ခုဖြစ်သည်။အကယ်၍ xs သည် နံပါတ်လေးလုံးပါသော array တစ်ခု ဖြစ်သည်ဆိုပါစို့။ C အနေနှင့် xs[5] သို့ xs[1000] ဟူသောကုတ်မျိုးကို ပျော်ပျော်ကြီးခွင့်ပြုပြီး xs အနောက်တွင်ကပ်ရပ်သိမ်းဆည်းထားသော memory တွင်ရှိသည့် တန်ဖိုးများကို ထုတ်ပေးလိုက်မည်ဖြစ်သည်။

Let's stop here in the name of brevity. Here's where some languages fall on these metrics. As shown, only Haskell is consistently "strong" by all of these definitions. Most languages are ambiguous.

စာရှည်မည်စိုးသဖြင့် ဤမျှနှင့်ပင် သတ်မှတ်ချက်များကို ရပ်ပါမည်။ အောက်ပါ ဇယားသည် language အချို့ကို အထက်ပါ သတ်မှတ်ချက် ဝင်ရိုးများဖြင့်နှိုင်းယှဉ်ပြထားသည်။ မြင်ရသည့်အတိုင်းပင် Haskell တစ်ခုထဲ သာ အထက်ပါ အဓိပ္ပာယ်အားလုံး တွင် "strong" ဖြစ်လေသည်။ကျန်သော langauge များစုမှာ ဒွိဟဖြစ်စရာတွေချည်းဖြစ်သည်။

Language	Static?	Implicit Conversions?	Rules Enforced?	Memory-Safe?
C	Strong	Depends	Weak	Weak
Java	Strong	Depends	Strong	Strong
Haskell	Strong	Strong	Strong	Strong
Python	Weak	Depends	Weak	Strong
JavaScript	Weak	Weak	Weak	Strong

(An entry of "Depends" in the "Implicit Conversions" column means that the strong/weak distinction depends on which conversions we consider acceptable.) ("Implicit Conversions" တိုင်တွင် "Depends" ဟုဖော်ပြထားသည်မှာ ကျွန်ုပ်တို့၏ လက်ခံနိုင်စွမ်းအပေါ်မူတည်၍ strong/weak ကွဲပြားသည်ဟုဆိုလိုသည်။)

Often, the terms "strong" and "weak" refer to unspecified combinations of the various definitions above, and other definitions not shown here. All of this confusion renders "strong" and "weak" effectively meaningless. When tempted to use the terms "strong" or "weak", it's better to simply describe the exact, concrete behavior in question. For example, we might say "JavaScript returns a value when we try to add a string to an integer, but Python throws an error". Then, we don't have to spend the effort to carefully agree on one of the many definitions of "strong"; or, worse, end up with an unresolved misunderstanding simply due to terminology. များသောအားဖြင့် "strong" နှင့် "weak"ဟူသော စကားလုံးနှစ်လုံးသည် အထက်ပါဖွင့်ဆိုချက်များနှင့် အခြားဖော်ပြထားခြင်းမရှိသော ဖွင့်ဆိုချက်များအား သတ်မှတ်ချက်မရှိပဲ အဆင်ပြေသလိုတွဲစဉ်းစားပြီး ခေါ်ဆိုထားခြင်းသာ ဖြစ်သည်။ ထိုသို့ ရှုပ်ထွေးနေခြင်းကပင် "storng" နှင့် "weak"ဟူသော ခွဲခြားချက်ကို အဓိပ္ပာယ်မဲ့စေလေသည်။ ထို့ကြောင့် "strong" နှင့် "weak" ဟူသော စကားလုံးများဖြင့် ခွဲခြားတော့မည်ဆိုလျှင် ထိုသို့ခွဲခြားမည့်အစား တိကျသေချာသော လိုအပ်ချက်ကို ရှင်းရှင်းဖော်ပြပြီး သုံးခြင်းကပိုကောင်းလေသည်။ ဥပမာ ကျွန်ုပ်တို့အနေနှင့် "Javascript သည် string ကို integer နှင့်ပေါင်း လျှင် တန်ဖိုးတစ်ခု return ပြန်ပြီး python ကတော့ error ထုတ်ပေးသည်" ဟု ပြောနိုင်သည်။ ဤသို့ဆိုလျှင် ကျန်ုပ်တို့အနေနှင့် "strong" နှင့် "weak" တို့၏နှစ်ဘက်သဘောတူရန် အသည်းအသန် ကြိုးပန်းအားထုတ်နေစရာမလိုပေ။ သို့မဟုတ်ပါက အခေါ်အဝေါ်ကွဲပြားခြင်းကြောင့်ဖြစ်သော နားလည်မှုလွဲခြင်းမျိုးနှင့် အဆုံးသတ်ပေမည်။

Most uses of "strong" and "weak" on the web are vague and ill-defined value judgements: they're used to say that a language is "good" or "bad", with the judgement dressed up in technical jargon. As Chris Smith has written:

Strong typing: A type system that I like and feel comfortable with

Weak typing: A type system that worries me, or makes me feel uncomfortable

အင်တာနက်ပေါ်တွင်တွေ့ရသော "strong" နှင့် "weak" အသုံးအနှုန်းများမှာ ယောင်ဝါးပြီး လိုသလိုဆွဲယူသတ်မှတ်ထားသော သုံးသပ်ချက်များသာဖြစ်သည်။ ၄င်းစကားလုံးများကို အသုံးချပြီး langauge တစ်ခု၏ ကောင်းခြင်း မကောင်းခြင်း ဆုံးဖြတ်ခြင်းသည် နည်းပညာစကားလုံးများဖြင့် အရေခွံခြုံထားသော အရေခြုံဆုံးဖြတ်ချက်များသာ ဖြစ်သည်။ Chirs Smith ရေးသားသကဲ့သို့ပင်

Strong typing။ ။ကျွန်ုပ်နှစ်သက်သဘောကျပြီး ကျွန်ုပ်အတွက် အဆင်ပြေသော type system

Weak typing။ ။ကျွန်ုပ်ကို စိုးရိမ်ပူပန်စေသော သို့မဟုတ် ကျွန်ုပ်ကို အဆင်မပြေဖြစ်စေသော type system

Gradual typing

Can we add static types to a dynamic language? In some cases, we can; in others, it's difficult or impossible.

ကျွန်ုပ်တို့အနေနှင့် static type များကို dynamic language တစ်ခုကို ထည့်သွင်းနိုင်ပါသလား။ အချို့နေရာများတွင် ထည့်သွင်းနိုင်သော်လည်း အချို့နေရာများတွင်မူ မဖြစ်နိုင်သလောက် ခက်ခဲသည်။

The most obvious problem is eval and similar dynamic language features. Evaluating 1 + eval("2") in Python gives us 3. But what does 1 + eval(read_from_the_network()) give us? It depends on what's on the network at runtime. If we get an integer, that expression is fine; if we get a string, it's not. We can't know what we'll get until we actually run, so we can't statically analyze the type.

အထင်ရှားဆုံးပြသနာမှာ eval နှင့် အလားတူ dynamic langauge လုပ်ဆောင်ချက်များဖြစ်သည်။ 1 + eval("2") ဟူသောဖော်ပြချက်အား python ဖြင့် evaluate လုပ်လျှင် 3 ဟူသောအဖြေကိုရသည်။ သို့သော် 1 + eval(read_from_the_network())ဟူသောဖော်ပြချက်တွင် မည်သည့်အဖြေရမည်နည်း။ ထိုအဖြေမှာ runtime တွင် network ပေါ်တွင်ဘာရှိနေမလဲဆိုသည့်အပေါ်မှီတည်နေသည်။ အကယ်၍ integer တစ်လုံးရခဲ့လျှင် ထိုရလဒ်သည် ပြသနာမရှိပေ။ သို့ရာတွင် string ရခဲ့ပါက error တက်ပေမည်။ ထိုဖော်ပြချက်ကို အမှန်တကယ် မ run ကြည့်ပဲ ဘာထွက်လာမည်ကို ကျွန်ပ်တို့ မပြောနိုင်ပေ။ ထို့ကြောင့် static နည်းဖြင့် တွက်ချက်ခန့်မှန်း၍ မရနိုင်ပေ။

The unsatisfying solution used in practice is to give eval() the type Any, which is like Object in some OO languages or interface {} in Go: it's the type that can have any value. Values of type Any aren't constrained in any way, so this effectively removes the type system's ability to help us with code involving eval. Languages with both eval and a type system have to abandon type safety whenever eval is used.

လက်တွေ့တွင်သုံးလေ့ရှိသော ကျေနပ်ဖွယ်မရှိသည့် အဖြေတစ်ခုမှာ eval()၏ ရလဒ်အား ဘာမဆိုဖြစ်နိုင်သည့် Any type ပေးခြင်းဖြစ်သည်။ Any type သည် OO language များတွင် object type နှင့်အလားသဏ္ဍာန်တူပြီး Go တွင် interface {}နှင့် တူသည့် မည်သည့်တန်ဖိုးမဆိုဖြစ်နိုင်သော type ဖြစ်သည်။ Any type ၏တန်ဖိုးများသည် ချုပ်ချယ်ထားသည့်တန်ဖိုးမရှိလေရာ ၄င်းအချက်ကပင် type system ၏ eval နှင့်ပတ်သက်၍ ကူညီနိုင်မည့် စွမ်းရည်ကို ပယ်ဖျက်ပြီးသား ဖြစ်စေလေသည်။ eval ရော type system ရော အသုံးပြုထားသည့် language တိုင်း သည် eval ကိုအသုံးပြုတိုင်း type system ကပေးသည့် type လုံခြုံမှုကို စွန့်လွှတ်ကြရလေသည်။

Some languages have optional or gradual typing: they're dynamic by default, but allow some static annotations to be added. Python has added this feature recently; TypeScript is a superscript of JavaScript that adds optional types; Flow does static type analysis on regular old JavaScript code. These languages provide some benefits of static typing, but they can never provide the absolute guarantees of a truly static language. Some functions will be statically typed and some will be dynamically typed. The programmer always needs to be aware of (and wary of) the difference. အချို့သော language များတွင် potential typing သို့ gradual typing ဟုခေါ်သည့် type system မျိုးရှိသည်။ ၄င်းစနစ်မှာ default အားဖြင့် dynamic ဖြစ်ပြီး အချို့သော static annotation များကို ခွင့်ပြုသောစနစ်မျိုးဖြစ်သည်။ Python တွင် သိပ်မကြာသေးခင်က ယင်းစနစ်ထည့်သွင်းလိုက်သည်။ Typescript သည် Javascript ၏ superset တစ်ခုဖြစ်ပြီး Javascript တွင် optional type သတ်မှတ်ခြင်းကို ထည့်သွင်းထားသည်။ Flow သည် ရိုးရိုးသာမန် Javascript code ကို static type analysis လုပ်ပေးသည်။ ထိုlanguage များသည် static typing ၏ အချို့သော အားသာချက်များကို လက်ခံရရှိသော်လည်း တကယ့် static langauge တစ်ခု၏ အကြွင်းမဲ့ အာမခံချက်မျိုးတော့ ပေးစွမ်းနိုင်ခြင်းမရှိပေ။ အချို့သော function များသည် static type ဖြစ်နေပြီး အချို့မှာ dynamic type ဖြစ်နေဦးမည်သာဖြစ်သည်။ Program ရေးသားသူသည် ထိုကွဲပြားမှုကို အမြဲခေါင်းထဲထည့်ထားဖို့လိုပေသည်။

Compiling statically typed code

When compiling statically typed code, syntax is checked first, as in any compiler. Types are checked second. This means that a static language will sometimes give us one syntax error, but fixing that error leads to 100 type errors. Fixing the syntax error didn't create those 100 type errors; the compiler was just unable to check the types until the syntax was fixed.

static type ဖြင့်ရေးသားသော ကုတ်များကို compile လုပ်လျှင် သာမန် compilerတိုင်းလုပ်ဆောင်သည့်အတိုင်း syntax ကိုအရင်စစ်ဆေးသည်။ ပြီးမှ type များကို စစ်ဆေးသည်။ ဆိုလိုသည်မှာ static lanugage တစ်ခုသည် တစ်ခါတစ်ရံ တွင် ကျွန်ုပ်တို့အား syntax error တစ်ခုကိုပေးပြီး ထို errorကို ပြင်လိုက်တော့ မှ နောက်ထပ် type error အခု ၁၀၀ လောက်ထွက်လာတာမျိုးကြုံစေနိုင်သည်။ သို့ရာတွင် ဤသို့ဖြစ်ရသည်မှာ syntax error ကိုပြင်လိုက်ခြင်းက type error များတက်စေသည်မဟုတ်ပဲ မူလက syntax မမှန်သေးသောကြောင့် compilerက type များကို မစစ်ဆေးနိုင်သေးခြင်းသာဖြစ်လေသည်။

Static language compilers can often generate faster code than dynamic languages. For example, if the compiler knows that the add function takes integers, it can use the CPU's native ADD instruction. A dynamic language would have to check the types at runtime, choosing one of many specific "add" functions depending on the types (is it adding integers, or floats, or is it concatenting strings, or maybe lists?); or, it might have to decide to throw an error if the types don't match. All of that checking takes time.

static langauge compiler များသည် များသောအားဖြင့် dynamic langauge များထက်ပိုမိုမြန်ဆန်သောကုတ်ကို ထုတ်လုပ်ပေးနိုင်ကြသည်။ ဥပမာ add function သည် integer များသာလက်ခံသည်ဟု compiler မှ သိထားပါက ၄င်းအနေနှင့်ပိုမိုမြန်ဆန်သော CPU ၏ native ADD instruction ကိုသုံးလိုက်နိုင်သည်။ dynamic language တစ်ခုတွင်မူ runtime ၌ type များစစ်ဆေးခြင်း၊ စစ်ဆေးသိရှိလာသော type အပေါ်မူတည်၍ အမျိုးမျိုးသော add function များကိုရွေးချယ်ခြင်း(integer များကို ပေါင်းခြင်းလား၊ float များကိုပေါင်းခြင်းလား၊ string များချိတ်ဆက်ခြင်းလား သို့မဟုတ် list များလား စသဖြင့်ရွေးချယ်ခြင်း) သို့မဟုတ် type များလွဲချော်နေခဲ့လျှင် error ထုတ်လွှတ်ခြင်းစသဖြင့် အလုပ်များများလုပ်ရလေသည်။ ထို အလုပ်များအတွက် အချိန်အတိုင်းအတာတစ်ခုလည်း ပိုပေးရပေသည်။

Dynamic languages have tricks to speed this up, like just-in-time (JIT) compilers, where the code is recompiled at runtime after gathering information about the actual types used. However, no dynamic language can match the speed of carefully written static code in a language like Rust.

Dynamic langauge များတွင် ထိုကိစ္စကို ဖြေရှင်းသည့် လမ်းကြောင်းများတော့ရှိသည်။ဥပမာ JIT compiler များတွင် ကုတ်ကို runtime ၌ အမှန်တကယ်အသုံးပြုမည့် typeများကို သိရှိပြီး မှ compile ပြန်လုပ် ခြင်းမျိုးဖြစ်သည်။ မည်သို့ပင်ဆိုစေ Rust လို language တစ်ခုတွင် စနစ်တကျဂရုတစ်စိုက် ရေးသားထားသော static code မျိုး၏မြန်ဆန်မှုကိုတော့ မည်သည့် dynamic language မှယှဥ်နိုင်မည်မဟုတ်ပေ။

Arguments for static and dynamic types

Static type system advocates point out that without a type system, simple typing mistakes may result in failures in production. This is definitely true; anyone who has used a dynamic language has experienced it.

static type system နှစ်ခြိုက်သူများထောက်ပြလေ့ရှိသော အချက်တစ်ချက်မှာ type system တစ်ခုမရှိလျှင် ရိုးရှင်းသောအမှားများသည် ပင် production တွင်မှားယွင်းမှုများ ဖြစ်စေနိုင်သည် ဟူ၍ ဖြစ်သည်။ ထိုအချက်သည် တကယ်တမ်းလည်းမှန်ကန်သော အချက်ဖြစ်သည်။ dynamic langauge အသုံးပြုဖူးသူတိုင်း ထိုအတွေ့အကြုံကို ခံစားဖူးကြသည်။

Dynamic language advocates point out that dynamic languages seem to be easier to program in. This is definitely true for some kinds of code that we write occasionally, like code that uses eval. It's debatable for everyday code, and depends on the ill-defined term "easy". Rich Hickey did a fantastic talk about the word "easy" and its relationship to the word "simple". Watching that will show that it's not easy to use the word "easy" well. Be wary of "easy".

Dyanmic langauge နှစ်ခြိုက်သူများက ထောက်ပြလေ့ရှိသည်မှာ dynamic language များသုံး၍ program ရေးသားရသည်မှာ ပိုမိုလွယ်ကူသည်ဟူ၍ဖြစ်သည်။ ထိုအချက်သည်လည်း ကျွန်ုပ်တို့ရေးလေ့ရေးထရှိသည့် အချို့သော ကုတ်အမျိုးအစားများအတွက် မှန်ကန်သော အချက်ဖြစ်သည်။ ဥပမာ eval ကိုအသုံးပြုသောကုတ်မျိုးဖြစ်သည်။ ကုတ်အားလုံးအတွက်ဆိုရလျှင်မူ လွယ်ကူသည် ဟူသော အဓိပ္ပာယ်ဖွင့်ဆိုချက်အပေါ်မူတည်ပေလိမ့်မည်။ Rich Hickey ပြောခဲ့ဖူးသော လွယ်ကူမှုနှင့် ရိုးရှင်းမှု၏ ဆက်စပ်ပုံကိုဖော်ပြသည့် အလွန်ကောင်းသော [talk]((https://www.infoq.com/presentations/Simple-Made-Easy)တစ်ခုရှိသည်။ယင်းကို ကြည့်ရှုခြင်းဖြင့် လွယ်ကူဟူသော ဝေါဟာရကိုအလွယ်မသုံးနိုင်ကြောင်း သင်သိလိမ့်မည်။ လွယ်ကူ ဟူသောစကားကို သတိထားဖို့လိုသည်။

The trade-offs between static and dynamic type systems are still poorly understood, but they definitely depend heavily on the language in question and the problem being solved. static နှင့် dynamic langauge များကြားက အားနည်းချက်အားသာချက်များမှာ ယခုချိန်ထိ သေချာနားလည်ကြသေးခြင်းမရှိသေးပေ။ သို့ရာတွင် ထိုအချက်များမှာလည်း language နှင့် ဖြေရှင်းဖို့ကြိုးစားနေသော ပြသနာအပေါ်အများကြီးမှီတည်ပြန်သည်။

JavaScript tries to continue executing even if that means doing data conversions that are nonsensical (like "a" + 1 returning "a1"). Python, on the other hand, tends to be conservative and throw errors often, as it will in the case of "a" + 1. Those are very different approaches with different levels of safety, but Python and JavaScript are both dynamically typed. Javascript သည် အဓိပ္ပာယ်မဲ့သော data ကူးပြောင်းခြင်းများ ပြုလုပ်ရလျှင်တောင် ဆက်လက် execute လုပ်မြဲလုပ်သည်။ (ဥပမာ "a" + 1 မှ "a1"ကို return ပြန်ခြင်း) Python ကမူ အထက်ပါကိစ္စမျိုးတွင် ရှေးမူမပျက် error များသာထုတ်လွှတ်ပေးဖို့ကြိုးစားသည်။နှစ်ခုလုံးသည် dynamic language များပင်ဖြစ်သော်လည်း ကွဲပြားသော လုံခြုံမှုအဆင့်အပေါ်မူတည်၍ ကွဲပြားသော ချဉ်းကပ်နည်းများအသုံးပြုကြလေသည်။

C will happily allow the programmer to read from arbitrary locations in memory, or to treat a value of one type as if it had another type, even if that makes no sense at all and leads to a crash. Haskell, on the other hand, won't even allow an integer and a float to be added together without an explicit conversion step added. C and Haskell are both statically typed, despite being wildly different.

C သည် programရေးသူများကို ကျပန်း memory နေရာများမှ data ဖတ်ပိုင်ခွင့်ပျော်ပျော်ကြီးပေးထားသည်။ ထို့အပြင် type တစ်မျိုးမှ တန်ဖိုးတစ်ခုကို အခြား type တစ်ခုကဲ့သပေးထားသည်။ ထိုသို့ခွင့်ပြုခြင်းသည် အဓိပ္ပာယ်ကင်းမဲ့ပြီး program ကိုcrash သွားစေနိုင်သည်ကိုပင်လျှင် ခွင့်ပြုထားလေသည်။ Haskell ကမူ integer နှင့် float ကိုတောင် တမင်type ပြောင်းလဲခြင်းမရှိပဲ ပေါင်းလို့မရအောင် ကန့်သတ်ထားသည်။ ထိုနှစ်မျိုးသည် statically typed langauge များဖြစ်ပင် ဖြစ်သော်ငြားလည်း လွန်စွာ ကွာခြားလေသည်။

There are wide variations within dynamic languages and within static languages. Any blanket statement of the form "static languages are better at x than dynamic languages" is almost certainly nonsense. It may be true of some particular languages, but in that case it's better to say "Haskell is better at x than Python".

dyanamic langauge များအတွင်း နှင့်static langauge များအတွင်း၌ပင် လွန်စွာကွဲပြားခြားနားမှုများ ရှိကြသည်။ "static language များသည် dynamic language များထက်လုပ်ဆောင်ချက် x ၌ သာလွန်သည်ဟု ဆိုလျှင် အဓိပ္ပာယ်မရှိသလောက်ပင်ဖြစ်သည်။ အချို့သော language များအတွက် မှန်ကောင်းမှန်မည်၊ သို့ရာတွင် ထိုအခါမျိုးတွင်လည်း "Haskell သည် Python ထက်လုပ်ဆောင်ချက် x တွင်သာလွန်သည်"ဟုဆိုခြင်းကသာ ပိုကောင်းပေမည်။

Diversity of static type systems

Consider two well-known statically typed languages: Go and Haskell. Go's type system lacks generics: types that are "parameterized" by other types. For example, we might create our own list type, MyList, that can contain any type of data that we need to store. We want to be able to create a MyList of integers, a MyList of strings, etc., without making any changes to the source code of MyList. The compiler should enforce those types: if we have a MyList of integers, but accidentally try to insert a string into it, then the compiler should reject the program.

ထင်ရှားသော statically typed language နှစ်ခုဖြစ်သော Go နဲ့ Haskell တို့ကိုကြည့်ပါ။ Go ၏type system တွင် generic type များမရှိပေ။(generic type ဆိုသည်မှာ အခြားtype အမျိုးမျိုးဖြင့် parameter ပေးလို့ရသော type မျိုးကိုဆိုလိုသည်။) ဥပမာ ကျွန်ုပ်တို့အနေနှင့် မည်သည့် data type ကိုမဆိုထည့်သွင်းနိုင်သည့် ကျွန်ုပ်တို့ ကိုယ်ပိုင် List type တစ်ခုကို ဖန်တီးနိုင်သည်။ ထို Type ကို MyList ဟုခေါ်မည်ဆိုပါစို့။ကျွန်ုပ်တို့အနေနှင့် မူလ MyList source code ကိုမပြောင်းလဲပဲ integer များထည့်သွင်းနိုင်သော MyList၊ stringများထည့်သွင်းနိုင်သော MyList စသဖြင့် အသုံးပြုချင်မည်ဖြစ်သည်။ထို့အတူ compiler ကလည်း ထို type များကို တိတိကျကျလက်ခံသင့်သည်။ ကျွန်ုပ်တို့တွင် integer များအတွက် MyList တစ်ခုရှိပြီး ၄င်းကို string တစ်ခုထည့်သွင်းရန် ကြိုးစားပါက compiler အနေနှင့် ထို program ကို reject လုပ်ရမည်ဖြစ်သည်။

Go was intentionally designed without the ability to define types like MyList. The best that we can do is to create a MyList of "empty interfaces": the MyList can hold objects, but the compiler simply doesn't know what their types are. When we retrieve objects from a MyList, we have to tell the compiler what its type is. If we say "I'm retrieving a string" but the actual value is an integer, we get a runtime error just like we would in a dynamic language.

Go ကို MyList ကဲ့သို့သော type များဖန်တီးနိုင်မည့် စွမ်းရည်များမပါဝင်စေရန် တမင် ဖန်တီးထားခြင်းဖြစ်သည်။ကျွန်ုပ်တို့တတ်နိုင်သည့် အကောင်းဆုံးလုပ်ဆောင်ချက်မှာ "empty interface" များထည့်သွင်းနိုင်သည့် MyList တစ်ခုဖန်တီးခြင်းဖြစ်သည်။ ၄င်း MyList သည် object များကိုလက်ခံနိုင်မည်ဖြစ်သည်။ သို့ရာတွင် compilerအနေနှင့် ထို object များ၏ type ကို မသိိနိုင်ပေ။ ထို MyList တစ်ခု မှ object များထုတ်ယူမည်ဆိုလျှင် ကျွန်ုပ်တို့က compiler အား ၄င်းတို့၏ type ကို ပြောရမည်ဖြစ်သည်။ထိုအခါတွင် ကျွန်ုပ်တို့ "string တစ်ခုကို ထုတ်ယူမည်"ဟု ပြောပြီးကာ မှ အမှန်တကယ်တန်ဖိုးက integer ဖြစ်နေလျှင် dynamic language တစ်ခုတွင် ကြုံရမည့် runtime error မျိုးကိုကြုံရမည်သာဖြစ်လေသည်။

Go also lacks many other features present in modern static type systems (or even systems from the 1970s). Its designers have reasons for those decisions, though outsiders' opinions on them can be strong.

Go တွင် ခေတ်ပေါ် type system များတွင်ရှိသည့် လုပ်ဆောင်ချက်တော်တော်များများ မပါဝင်ပေ။(ပြောရလျှင် ၁၉၇၀ ပြည့်နှစ်များအတွင်းကဖန်တီးခဲ့သော system များ၏လုပ်ဆောင်ချက်များတောင် မပါဝင်ပေ)။ အပြင်လူများမှ အမျိုးမျိုး ထင်မြင်သုံးသပ်နိုင်သော်လည်း Go ကို ဒီဇိုင်းဆွဲသူများတွင် ထိုဆုံးဖြတ်ချက်များအတွက် အကြောင်းပြချက်များရှိသည်မှာလည်း အမှန်ပင်။

Now, let's compare Haskell, which has a very powerful type system. If we define a MyList type, then the type of "list of ints" is simply MyList Integer. Haskell will now stop us from accidentally putting strings into our list, and it will ensure that we don't put an element of the list into a variable of type string.

ယခု ကျွန်ုပ်တို့အလွန်စွမ်းရည်မြင့်သော type system ကိုပိုင်ဆိုင်ထားသည့် Haskell နှင့် နှိုင်းယှဉ်ကြည့်ကြမည်။ Haskell တွင် MyList type ကိုသတ်မှတ်မည်ဆိုလျှင် integer များအတွက် MyList ကို MyList Integer ဟု Type သတ်မှတ်ပေးရုံပင်။ဤသို့သတ်မှတ်ပေးလိုက်သည်နှင့် ထို list အတွင်းသို့ string များထည့်သွင်းခြင်းကို Haskell ကကာကွယ်ပေးမည်ဖြစ်သည်။ ထို့ပြင် ထိုlist အတွင်းမှ ထုတ်ယူလိုက်သော တန်ဖိုးတစ်ခုကို string variable တစ်လုံးတွင် သွားသိမ်းဖို့ကြိုးစားခြင်းမျိုးကိုလည်းကာကွယ်ပေးမည်ဖြစ်သည်။

Haskell can also express far more complex ideas directly in types. For example, Num a => MyList a means "a MyList of values that are all the same type of number". It might be a list of integers, or floats, or fixed-precision decimal numbers, but it will definitely never be a list of strings, as verified at compile time.

Haskell ဖြင့် ပိုမို ရှုပ်ထွေးသောအကြံဉာဏ်များကိုလည်း type များကိုတိုက်ရိုက်သုံး၍ ဖော်ပြနိုင်သည်။ ဥပမာ Nm a => MyList a ဟုဆိုလျှင် "number နှင့်တူသော type ရှိသည့် တန်ဖိုးများအားလုံး ထည့်သွင်းနိုင်သည့် MyList" ဟု အဓိပ္ပာယ်ရသည်။၄င်းသည် integer list လည်းဖြစ်နိုင်သည်။ float သို့ fixed-precision decimal number များလည်းဖြစ်နိုင်သည်။သို့ရာတွင် string list တော့ဘယ်တော့မှ မဖြစ်နိုင်ပေ။ ဤသည်ကို compile time မှာပင် စစ်ဆေးပြီးသားဖြစ်လေသည်။

We might write an add function that works on any numeric type. That function will have the type Num a => (a -> a -> a). This means:

ကျွန်ုပ်တို့အနေနှင့် မည်သည့် ကိန်းဂဏန်း type ဖြင့်မဆိုအလုပ်လုပ်နိုင်သော function တစ်ခုရေးသားနိုင်သည်။ ထိုfunction သည် Num a => ( a -> a -> a ) ဟူသော type ရှိလိမ့်မည်။ဆိုလိုသည်မှာ

• a can be any type that's numeric (written Num a =>).

• The function takes two arguments of type a and returns type a (written a -> a -> a).

• a သည် ကြိုက်သည့် ကိန်းဂဏန်းtype ဖြစ်နိုင်သည်။ (Num a => ဟုရေးသည်။)

• ပေးထားသည့် function သည် type a ရှိသည့် argument နှစ်ခုရယူ၍ type a ရှိသည့် တန်ဖိုးတစ်ခုပြန်ထုတ်ပေးသည်။ (a -> a -> a ဟုရေးသည်။)

One final example. If a function's type is String -> String, then it takes a string and returns a string; but if it's String -> IO String, then it also does some IO. That IO can be disk access, network access, reading from the terminal, etc.

နောက်ဆုံးဥပမာတစ်ခုဆက်ပြောမည်။ အကယ်၍ function တစ်ခု ၏ type သည် String -> String ဖြစ်လျှင် ၄င်းသည် string တစ်ခုကိုယူ၍ string တစ်ခုကို ပြန်ပေးသည်။သို့ရာတွင် String -> IO -> String ဟုဆိုခဲ့လျှင် IO လုပ်ဆောင်ချက်တစ်ခုပါပြုလုပ်သည်ဟိုသိနိုင်သည်။

If a function does not have IO in its type, then we know that it doesn't do any IO. In a web application, for example, we can tell at a glance whether a function might change the database just by looking at its type.

အကယ်၍ function ၏ type တွင် IO ဟု မပါခဲ့လျှင် ၄င်းသည် IO လုပ်ဆောင်ချက်ပြုလုပ်ခြင်းမရှိဟုသိနိုင်သည်။ ဥပမာအားဖြင့် web application တစ်ခုတွင် type များကိုတစ်ချက်ကြည့်ရုံနှင့် function တစ်ခုသည် database ကို ပြောင်းနိုင်မပြောင်းနိုင် သိရှိနိုင်ပေသည်။

No dynamic languages and few static languages can do this; it's a particularity of the most powerful static languages. In most languages, we'd have to dig down into the function, and all of the functions that it calls, and so on, looking for anything that might change the database. The process would be tedious and error-prone, whereas Haskell's type system can answer this question easily and with certainty.

မည်သည့် dynamic/static language မှ ဤသို့မလုပ်ဆောင်နိုင်ချေ။ ဤစွမ်းဆောင်ချက်သည် စွမ်းအားအကောင်းဆုံး static langauge များ၏ ဝိသေသတစ်ချက်ဖြစ်သည်။ langauge အများစုတွင် ကျွန်ုပ်တို့အနေနှင့် function ၏ကုတ်အတွင်းသို့သက်ဆင်း၍ ၄င်းမှ ခေါ်ယူနိုင်သော fuction အားလုံးနှင့် ထိုfunction တစ်ခုစီအတွက်လည်း အလားတူ database ကိုပြောင်းလဲနိုင်မည့်ကုတ်ရှိမရှိစစ်ဆေးရမည်ဖြစ်သည်။ ထိုသို့စစ်ဆေးရမည်ဆိုလျှင် အချိန်ကုန်လူပန်းဖြစ်ရမည်။ ဤသည်ကို haskell type system ကအလွယ်တကူ တိကျသေချာစွာ အဖြေပေးနိုင်လေသည်။

Compare all of this power with Go, which can't express the simple idea of MyList, let alone "a function that takes two arguments, both of which are numeric and of the same type, and which then does some IO".

Go's approach does make it easier to write tools for programming with Go (most notably, the compiler can be simple), and it also results in fewer concepts to learn. The weighing of those benefits against Go's significant limitations is subjective. However, it's unquestionably true that Haskell is more difficult to learn than Go, that Haskell's type system is more powerful, and that Haskell can prevent far more types of bugs at compile time.

Go and Haskell are so different that lumping them together as "static languages" can be deceiving even though it's a correct use of the term. When comparing on practical safety benefits, Go is closer to dynamic languages than it is to Haskell. On the other hand, some dynamic languages are safer than some static languages (Python is generally considered to be much safer than C). When tempted to make generalizations about static languages or dynamic languages as a group, keep the huge variation between languages in mind.

Concrete examples of type system power differences

With more powerful type systems, we can specify constraints at finer levels of granularity. Here are some examples, but don't get bogged down if the syntax doesn't make sense.

In Go, we can say "the add function takes two integers and returns an integer":

func add(x int, y int) int {
    return x + y
}

In Haskell, we can say "the add function takes any type of numbers, and returns a number of that same type":

f :: Num a => a -> a -> a
add x y = x + y

In Idris, we can say "the add function takes two integers and returns an integer, but its first argument must be smaller than its second argument":

add : (x : Nat) -> (y : Nat) -> {auto smaller : LT x y} -> Nat
add x y = x + y

If we try to call this function as add 2 1, where the first argument is larger than the second, then the compiler will reject the program at compile time. It's impossible to write a program where the first argument to add is larger than the second. Very few languages have this capability. In most languages, this kind of check is done at runtime: we write something like if x >= y: raise SomeError().

Haskell has no equivalent of the Idris type above, and Go has no equivalent of either the Idris type or the Haskell type. As a result, Idris can prevent many bugs that Haskell can't, and Haskell can prevent many bugs that Go can't. In both cases, we need additional type system features, which make the language more complex.

Some static languages' type systems

Here's a very rough list of some languages' type system power in increasing order. This is meant to provide a rough sense of type system power and shouldn't be taken as an absolute. The languages grouped together here can be very different from each other. Each type system has its own quirks and most of them are very complex.

• C (1972), Go (2009): These aren't very powerful at all, with no support for generic types. We can't define a MyList type that can be used as a "list of ints", "list of strings", etc. Instead, it will be a "list of unspecified values". The programmer must manually say "this is a string" each time one is removed from the list, which may fail at runtime.
• Java (1995), C# (2000): These both have generic types, so we can say MyList<String> to get a list of strings, with the compiler being aware of and enforcing that constraint. Items retrieved from the list will have type String, enforced at compile time as usual, so runtime errors are less likely.
• Haskell (1990), Rust (2010), Swift (2014): These all share several advanced features, including generics, algebraic data types (ADTs), and type classes or something similar (respectively: type classes, traits, and protocols). Rust and Swift have more mass appeal than Haskell, with strong organizations pushing them (Mozilla and Apple, respectively).
• Agda (2007), Idris (2011): These support dependent types, allowing types like "a function that takes an integer x, and an integer y, where y is greater than x". Even the "y is greater than x" constraint is enforced at compile time: at runtime, y will never be less than or equal to x, no matter what happens. Very subtle but important properties of systems can be verified statically in these languages. Only a small minority of programmers learn them, but some become very excited about them.

There's a clear trend toward more powerful systems over time, especially when judging by language popularity rather than languages simply existing. The notable exception is Go, which explains why many static language advocates shun it as a step backwards. Group two (Java and C#) are mainstream languages that are mature and widely used. Group three looks poised to enter the mainstream, with big backers like Mozilla (Rust) and Apple (Swift). Group four (Idris and Agda) are nowhere near mainstream use, but that may change eventually; group three wasn't anywhere near mainstream use just ten years ago.