Khi lập trình với JavaScript, có nhiều bạn khá thú vị với toán tử so trùng (===) , và thường ưu tiên hơn toán tử so sánh tương đương (==) .
Đây cũng là 1 điều được đề cập sớm trong quyển “JavaScript: The Good Parts” , cũng là 1 mục dễ gây hiểu lầm khi coding. Nó cũng gần như so sánh == và equals() trong ngôn ngữ Java.
Tuy vậy, có những trường hợp mà kết quả của === có thể khác với expectation theo logic kể trên. Hãy xem thử đoạn JavaScript sau:
var n = "Anh"; console.log("Co phai la anh? n==n " + (n=="Anh")); console.log("Anh that dung la anh? n===n " + (n==="Anh")); console.log("Anh moi? == " + (n==new String("Anh")) + " GiaTri? " + (n==String.valueOf("Anh"))); console.log("Anh moi dung? === " + (n===new String("Anh")) + " GiaTriDung? " + (n===String.valueOf("Anh"))); var m = NaN; console.log("Co phai la em? m==m " + (m==m)); console.log("Em co dung la em? m===m " + (m===m)); console.log("Khong phai anh a? " + (NaN==NaN)); console.log("Khong phai la anh, co phai la em? " + (NaN===NaN));
.
.
Nếu bạn biết coding, hãy dự đoán 1 chút trước khi cuộn xuống…
.
.
.
.
.
.
.
OK, nhẹ nhàng scroll down cái nào :)
.
.
.
.
Kết quả so sánh NaN==NaN là false,
và so sánh NaN===NaN lại là false!
Ít nhất là trong JavaScript là như thế … (nói chung là ECMAScript – ES).
.
Anh không phải anh ? Em không phải là em?
.
Liệu có gì đó sai sai về mặt logic không?
Sau một hồi suy nghĩ , tôi cảm thấy cái này cũng hợp lý, không phải vấn đề ở biến “em” hay biến “Anh” .
Mà về mặt ký hiệu lập trình, NaN là pre-defined tượng trưng cho “Not A Number” , 1 giá trị không phải là số .
Nên “không phải số” có thể là 1 chuỗi (“m”), và khi so với 1 “không phải số” khác, thì có thể là chuỗi khác (“n” or “someArbitraryFunction”), hoặc thậm chí là hàm (function), vì thế kết quả so sánh giữa 2 cái sẽ không trùng nhau, hoặc không tương đương.
Nếu như vậy thì kết quả trên là hợp lý, có thể có rất nhiều giá trị ứng với NaN , cũng như khi đi từ A tới B có thể có rất nhiều con đường.
Một cách nói khác, khi ta nói về ngôn ngữ lập trình nói chung, nó có thể là Java, nó có thể là JavaScript, còn khi nói “không phải Java” thì ko có nghĩa là “phải là JavaScript” hoặc “phải là Ruby”, và tương ứng ngược lại.
Những cuộc thảo luận về ngôn ngữ lập trình thường khá hứng thú với nhiều coder/programmer , nhưng không nhất thiết dẫn tới sự đồng ý về “the next big language” or “the next big thing” .
Có lúc tôi nghĩ JavaScript là ngôn ngữ lập trình dẫn đầu, nhưng bây giờ thì có thể không là như vậy nữa. Thì điều này không có nghĩa là sự phê phán JavaScript, hay sự trách móc Java, C# , … có thể đó chỉ là những ngôn ngữ triển vọng nào đó (Python, Erlang?) hoặc tốt về mặt performance như Scala, Clojure,… hoặc thậm chí là Go, Elixir, …
.
Who knows?
The logic of a language design is just a thing in life. We may remember some particular cases, and bear in mind the general approach if that helps our work/life, that’s sufficient I guess.
.
./.
Các trường đại học khoa/ngành CS đã chuyển từ C/C++ sang Java/Python để giới thiệu ngôn ngữ lập trình cho sinh viên mới. Tuy nhiên xu hướng mới nhất thì Java đã mất đi sự hấp dẫn và JavaScript cũng như các ngôn ngữ thông dịch như Go/Python được chọn.
Chẳng hạn trường Standford cũng đã thí điểm JS thay cho Java là ngôn ngữ giới thiệu lập trình cho SV:
https://computinged.wordpress.com/2017/04/21/cs-department-updates-introductory-courses-java-is-gone/
Cá nhân tôi nghĩ đó là quyết định hợp lý.
Pingback: Nghiet Nga 30 T20 | DucQuoc's Blog
Pingback: Brand Ambassador Effectiveness | DucQuoc's Blog
Pingback: Vietnam Coast Guard rehearsal | DucQuoc's Blog