Bạn có thể là Blub
Software Engineering
36
White

Ngoc Dao viết ngày 21/03/2016

In Beating the Averages, Paul Graham formulated the Blub paradox. In short a programmer who only knows a language called Blub looks down on all languages that don't support features that Blub has. At the same time, he1 is incapable of understanding why he would want to use some weird language that has features that Blub doesn't have. The Blub programmer is so used to thinking in Blub that he can't get his head around anything non-Blub.The question is, how do you know if you or somebody else is a Blub programmer? Of course it goes without saying that anybody who reads this blog is kind, highly intelligent, open minded, and motivated to learn.

Trong Đánh bại những Công ty Làng nhàng, Paul Graham đã trình bày về mâu thuẫn Blub. Nói ngắn gọn là, một lập trình viên chỉ biết duy nhất một ngôn ngữ gọi là Blub coi thuờng tất cả các ngôn ngữ không hỗ trợ các tính năng mà Blub có. Cùng lúc đó, anh ta [1] không có khả năng hiểu tại sao anh ta lại cần sử dụng các ngôn ngữ quái đản có các tính năng mà Blub không có. Lập trình viên Blub quá quen suy nghĩ theo Blub đến nỗi anh ta không thể nghĩ đến cái gì khác ngoài Blub. Câu hỏi là, làm sao bạn biết đuợc nếu bạn hay một nguời nào đó là một lập trình viên Blub? Dĩ nhiên ở đây cho rằng ai đọc blog này đều là nguời tử tế, trí tuệ cao, đầu óc cởi mở, và năng động học hỏi.

The comedian Jeff Foxworthy had about five minutes of fame with a schtick of starting each joke with "you might be a redneck if..." Five minutes is a lot more fame than the average blog entry gets, so I thought I'd steal his formula for success.

Diễn viên hài Jeff Foxworthy có năm phút nổi tiếng với một chuỗi hài huớc là bắt đầu mỗi chuyện cuời bằng "bạn có thể là một gã da trắng nghèo nếu..." Năm phút đó nổi tiếng hơn nhiều so với một bài blog làng nhàng, vì vậy tôi nghĩ tôi sẽ lấy trộm công thức thành công của ông ấy.

Here, with a slight modification of the formula, I present

Đây, sau khi sửa đổi chút ít công thức, tôi xin giới thiệu cùng quí vị

That Jerk on the Internet Might be a Blub Programmer If... (Thằng Ngốc trên Internet Có thể là Lập trình viên Blub nếu...)

He dismisses other language features as "mere syntactic sugar" (Anh ta bỏ qua các tính năng ngôn ngữ khác vì coi chúng "chỉ là cách viết tắt")

Of course its syntactic sugar. Anything above raw machine code is syntactic sugar. Syntactic sugar is what helps programmers think and work at higher levels. Look at it this way: C and C++ have "goto" and "if". But they also have "while" which is really just syntactic sugar for the right combination of "goto" and "if." C, C++, C# and Java have "for", but it's just syntactic sugar for a certain kind of "while" loop. C++ has object oriented programming, but C++ type OO can be created in C using the right combination of structs and pointers.

Dĩ nhiên việc viết tắt của ngôn ngữ rất quan trọng. Bất kỳ thứ gì cao hơn mã máy thô đều là cách viết tắt. Viết tắt là cái giúp các lập trình viên nghĩ và làm việc ở các cấp độ cao. Hãy nhìn nhận vấn đề này như sau: C và C++ có "goto" và "if". Nhưng chúng cũng có "while", thật ra chỉ là cách viết tắt kết hợp "goto" và "if". C, C++, C# và Java có "for", nhưng nó chỉ là cách viết tắt cho một kiểu vòng lặp "while" nào đó. C++ có lập trình huớng đối tuợng, nhưng kiểu huớng đối tuợng của C++ có thể tạo trong C bằng cách sử dụng kết hợp struct và con trỏ.

In other language families I could go on and on about list comprehensions, pattern matching, type inference, regular expressions, function composition, currying, etc. But one in particular deserves mention: Lisp's most powerful feature is all about syntactic sugar. Lisp macro facilities (including quasiquotes, @ splices, etc) are syntactic sugar that make it easy for a programmer to create new syntactic sugar. If you understand macros then you'll think they're damned cool or damned scary (or both), but you won't dismiss them as "mere" anything. In On Lisp , Paul Graham creates an entire embedded Prolog in Common Lisp. Or take a look at Qi. It creates an incredibly powerful, statically typed, Haskell like language on top of the dynamically typed Common Lisp using a whole lot of macro black magic.

Trong các họ ngôn ngữ khác tôi có thể kể không chán về list comprehension, pattern matching, type inference, regular expression, function composition, currying, v.v. Nhưng có một cái riêng biệt đáng đề cập: tính năng mạnh nhất của Lisp là viết tắt. Công cụ marco của Lisp (bao gồm quasiquote, @ splice, v.v.) là cách viết tắt giúp lập trình viên tạo cách viết tắt mới dễ hơn. Nếu bạn hiểu macro bạn sẽ nghĩ chúng ngầu vãi hay đáng sợ vãi (hay cả hai), nhưng bạn sẽ không coi chúng như "chỉ là" bất cứ cái gì hết. Trong quyển On Lisp, Paul Graham tạo một phiên bản nhúng của Prolog bằng Common Lisp. Hay hãy xem xét Qi. Nó tạo ra ngôn ngữ định kiểu tĩnh cực mạnh, giống Haskell trên nền ngôn ngữ định kiểu động là Common Lisp bằng cách sử dụng rất nhiều tính năng ảo diệu của macro [2].

He dismisses most examples as "toys" that don't show a feature is useful (Anh ta coi hầu hết các ví dụ đều là "đồ chơi" và chẳng cho thấy tính năng nào là hữu dụng

Face it, most teaching examples are going to be a toys. Real world code is frequently complicated with error conditions, domain specific logic, and adherence to proprietary code standards. None of these things help demonstrate the feature being demonstrated, so examples tend to be small and focused on something that most people are familiar with or can learn in a few minutes. Refusing to try to grok a feature because the example given isn't immediately pertinent to you is a failure of one's imagination.

Hãy đối mặt với sự thật, hầu hết các ví dụ giảng dạy đều là đồ chơi. Thế giới mã lệnh thật thuờng phức tạp với các điều kiện kiểm tra lỗi, logic chuyên ngành, và tuân theo các tiêu chuẩn của mã nguồn đóng. Không có cái nào trong số đó giúp thể hiện cái tính năng đang đuợc thể hiện, vì thế các ví dụ thuờng có khuynh hướng nhỏ và chú trọng vào một số thứ hầu hết mọi nguời đã quen thuộc, hay có thể học trong vài phút. Không thử sức tính năng vì cái ví dụ đuợc đưa không quen thuộc ngay với bạn chứng tỏ bạn thiếu óc liên tượng.

He questions why "anybody would want to do that in the real world" (Anh ta đặt câu hỏi tại sao "không ai muốn thực hiện nó trong thế giới thực"

The phrase "real world" is highly loaded. It depends entirely on the domains you have experience in. You might not see why C's unsafe casts and unions are useful but let me assure you that for extremely low level performance critical code they can be critical. Haskell's concept of monads might seem arbitrary and weird, but monads have been used to statically prove significant aspects of real programs. And Ruby's dynamic metaprogramming facilities really do help create an environment that is extremely productive in non-trivial systems.

Cụm từ "thế giới thực" rất hay bị lạm dụng. Nó phụ thuộc hoàn toàn vào các lĩnh vực mà bạn có trải nghiệm. Bạn có thể không thấy tại sao tính năng cast không an toàn và tính năng union của C lại hữu dụng nhưng tôi chắc chắn với bạn là chúng có thể rất quan trọng khi chương trình bắt buộc phải chạy nhanh. Khái niệm đơn tử của Haskell có thể có nhiều nghĩa và quái đản, nhưng đơn tử đã được sử dụng trong nhiều chương trình thực tế. Và công cụ siêu lập trình động của Ruby thật sự giúp mang lại năng suất lập trình cực cao khi xây dựng các hệ thống phức tạp.

He says his favorite language "can do that" and then creates a giant ball of crufty boilerplate to prove it (Anh ta bảo ngôn ngữ yêu thích của anh ta "cũng làm được" và sau đó viết cả đống mã nguồn dài loằng ngoằng để chứng minh)

Most programming languages are Turing complete. All such languages can perform the same computations somehow. But if you have to create a ball of cruft every time you want to do some particular action, how often are you going to use that feature? If you had to recreate all of number theory every time you wanted to multiply two numbers wouldn't you stop tipping waiters?

Hầu hết các ngôn ngữ lập trình đều là Turing hoàn chỉnh. Như vậy hầu hết các ngôn ngữ đều có khả năng tương đương. Nhưng nếu để "cũng làm được" bạn phải viết một đống mã nguồn mỗi khi muốn vì ngôn ngữ bạn dùng không có cách viết tắt, thì bạn có thường xuyên "làm" hay không? Nếu bạn phải tái tạo tất cả số thuyết mỗi lần bạn muốn nhân hai số, bạn sẽ thôi không boa cho phục vụ bàn nữa phải không?

Again Lisp is special here. Any feature in another language can be implemented in Lisp using a bit of macro cruft; the difference is that in Lisp the cruft only has to be created in one place. Besides that, macros can be surprisingly uncrufty - most look very much like the syntax they're trying to generate.

Một lần nữa Lisp đặc biệt chỗ này. Bất cứ tính năng nào trong một ngôn ngữ khác đều có thể làm đuợc trong Lisp bằng cách sử dụng một nhúm macro hơi phức tạp; điều khác biệt là trong Lisp chỉ cần tạo nhúm này một lần. Bên cạnh đó, macro có thể đơn giản một cách đáng ngạc nhiên - trông hầu như giống y cú pháp mà nhúm sẽ tạo ra [3].

He denies that another language is more powerful than his because "they are all Turing complete" (Anh ta phủ nhận là ngôn ngữ khác mạnh hơn ngôn ngữ của mình vì "chúng đều Turing hoàn chỉnh")

Hmmm, is he writing raw machine code? If not, he's implicitly admitting that some languages are more "powerful" for some sense of the word "powerful". Powerful is a surprisingly tricky concept to pin down, but because our Blub programmer has chosen Blub and not machine code he must have some definition beyond the computational theoretic meaning. Either that or he's splitting hairs about "powerful" vs "expressive" or some other term.

Ừm, anh chàng này đang viết bằng mã máy phải không nhỉ? Nếu không, anh ta đang ngấm ngầm thú nhận là có vài ngôn ngữ "mạnh" hơn trong vài khía cạnh của từ này. Đáng ngạc nhiên là mạnh là khái niệm khó định nghĩa, nhưng vì anh chàng lập trình viên Blub của chúng ta chọn Blub chứ không phải mã máy, anh ta chắc hẳn phải có định nghĩa gì đó vượt ra khỏi ý nghĩa về lý thuyết về tính toán. Chỉ có thể là như thế hoặc anh ta không hiểu được khác biệt giữa "mạnh" và "khả năng diễn đạt" hay thuật ngữ gì đó khác.

He dismisses language feature because the syntax isn't "intuitive" (anh ta không dùng tính năng ngôn ngữ vì cú pháp không "trực quan")

If you think blocks must be denoted using curly braces then you're going to miss out on a very rich set of languages that use some other arbitrary choice. All programming languages are artificial creations and nothing about them is "intuitive" except in the narrow sense of "similar to something you already know." For example, most imperative languages use the single equal sign (=) to mean (re)assignment. It might seem "intuitive," but what's intuitive about using a symmetrical symbol for a fundamentally asymmetrical operation? Before programming languages stole it, that symbol already had a deep history and meaning in mathematics that is completely incompatible. Frankly, Scheme's "set!" and Smalltalk/Pascal's ":=" seem like more reasonable choices, and what could be more intuitive than "<-". But try getting any of them past the Blub lawyers.

Nếu bạn nghĩ rằng các khối lệnh phải được đặt trong các ngoặc xoăn {} thì bạn sẽ bỏ lỡ rất nhiểu ngôn ngữ dùng ngoặc kiểu khác. Tất cả các ngôn ngữ lập trình đều là sản phẩm nhân tạo và không có gì là "trực quan" ngoại trừ nghĩa hẹp là "gần giống cái bạn đã biết". Ví dụ, các ngôn ngữ mệnh lệnh dùng "=" cho phép gán (lại). Nó có thể trông "trực quan", nhưng mà "trực quan" quái gì khi dùng ký hiệu đối xứng cho một phép toán về căn bản không mang nghĩa đối xứng? Trước khi các ngôn ngữ lập trình đánh cắp cách dùng này, dấu "=" có lịch sử sâu xa và có ý nghĩa trong toán, hoàn toàn không tương thích. Nói thẳng ra, "set!" của Scheme và ":=" của Smalltalk/Pascal có vẻ là lựa chọn hợp lí, và còn gì có thể trực quan hơn "<-". Nhưng hãy cố vượt qua mức độ Blub.

This isn't to deny the utility of working on syntax when adding a feature to an existing language. The sense of "intuitive" given above definitely applies here. It's just to say that dismissing a feature in another language because it has a different syntax is pure parochialism.

Nói vậy không phải để phủ nhận việc cải tiến cú pháp khi thêm tính năng vào ngôn ngữ có sẵn. Cảm giác "trực quan" ở trên chắc chắn áp dụng được ở đây. Nói vậy có nghĩa phủ nhận tính năng của ngôn ngữ khác chỉ vì cú pháp khác lạ thì thật là hẹp hòi.

Help Stamp Out Blub Programmers (Giúp Xác Định Lập trình viên Blub)

This post has been unusually strident for this blog. I mostly intend to present my thoughts with more gentleness and good humor. In a sense, though, this entry is all about preventative medicine. In my future posts I intend to talk about several languages and features. In the process I expect to get many poorly thought-out comments from Blub programmers. It's my hope that this post will at least slow some of them down to think, "if I write this, will everybody think I'm that jerk on the Internet?"

Bài viết này quảng cáo cho blog này một cách không bình thường, tôi không thường làm như vậy. Tôi định trình bày suy nghĩ một cách hòa nhã hơn và hài hước. Tuy thế, bài viết này toàn là về phương thuốc phòng tránh. Trong các bài viết tới tôi định nói về một số ngôn ngữ và tính năng. Qua các bài đó, tôi đoán sẽ nhận được nhiều phản hồi thiếu suy nghĩ từ những lập trình viên Blub. Tôi mong rằng ít nhất bài này sẽ làm họ nghĩ, "nếu tôi viết ra, liệu người ta có nghĩ tôi là thằng ngốc trên Internet không nhỉ?".

It probably won't work, but that's never stopped me before.

Nó có thể không có tác dụng, nhưng điều đó chưa bao giờ cản được tôi.

Before I close this out, there are a few things that do not make you a Blub programmer:

Trước khi kết thúc, có vài điều giúp bạn không biến thành lập trình viên Blub:

You probably aren't a Blub programmer if... (Bạn có thể không phải là lập trình viên Blub nếu...)

You can admit ignorance (Bạn có thể thú nhận mình ngu dốt)

While ignorance is a key ingredient for Blubness, it's not the only ingredient. The Blub programmer is willfully ignorant, actively pushing back against anything new. But ignorance itself is just a temporary condition if its joined with an open mind.
Trong khi ngu dốt là yếu tố chính làm nên cái sự Blub, nó không phải là yếu tố duy nhất. Lập trình viên Blub thì sẵn sàng ngu dốt, phủ nhận bất kì cái gì mới một cách hào hứng. Nhưng ngu dốt tự nó chỉ là tình trạng tạm thời, nếu nó đi kèm với đầu óc cởi mở.

You've tried something and just don't like it (Bạn đã thử cái gì đó và sau đó không thích)

Hey, not every feature is all the hype promises it to be. Not liking something that you have tried isn't the same as not liking something you never want to try. Just be open to the possibility that the feature might work well in some other environment, in another language, or with a better implementation.

Này, không phải mọi tính năng đều chỉ là lời hứa rỗng tuếch. Không thích cái gì đó sau khi thử nghiệm không giống với thích cái gì đó bạn chưa thử. Hãy cởi mở vì rất có thể tính năng đó sẽ có tác dụng tốt trong môi trường gì đó khác, trong ngôn ngữ khác, hay khi có hiện thực hóa tốt hơn.

Footnotes (Cước chú)

1. The usual apologies about using "he" instead of "he or she." One Div Zero officially recognizes that women have full and equal rights to be jerks and Blub programmers.

1. Xin lỗi đã dùng từ "anh" thay vì "anh hoặc chị". Blog này xin chính thức xác nhận rằng phụ nữ hòan toàn có quyền bình đẳng trở thành con ngốc và lập trình viên Blub.

2. Liskell does the opposite. It puts a Lisp like syntax, including macros, on top of Haskell.

2. Liskell làm điều ngược lại. Nó dùng cú pháp giống Lisp, bao gồm macro, trên nền Haskell.

3. One complaint that even thoughtful people have leveled against both Common Lisp and Scheme is that they seem more like Language Development Kits than languages. In part this impression is created by the fact that the standard definitions for both are getting a bit crusty with age. Sure, you can build a nice list comprehension macro but wouldn't it be nice if a standard one came in the box? The counter argument is that the language development kit allows you to move your environment into domains that are too specialized for a standard.

3. Có phàn nàn rằng ngay cả những người chín chắn đã phê phán cả Common Lisp và Scheme là chúng trông giống Công cụ để Viết ra Ngôn ngữ hơn là ngôn ngữ. Một phần của ấn tượng này là bởi sự thực là thư viện chuẩn cho cả hai đang rỉ sét dần cùng năm tháng. Chắc chắn rồi, bạn có thể tự xây dựng macro cho tính năng list comprehension nhưng chẳng tốt hơn nếu macro này đã có sẵn trong thư viện chuẩn? Lý lẽ phản bác lại là công cụ để viết ra ngôn ngữ này cho phép bạn tự tạo môi trường phát triển cho miền vấn đề quá đặc biệt đến nỗi không thể chuẩn hóa chung.

Bản gốc ở blog One Div Zero của James Iry

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Ngoc Dao

102 bài viết.
252 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
56 6
Làm thế nào để nâng cấp trang web mà không làm gián đoạn dịch vụ? Đây là câu hỏi phỏng vấn các công ty lớn thường hỏi khi bạn xin vào vị trí làm lậ...
Ngoc Dao viết 2 năm trước
56 6
White
32 0
Bài viết này giải thích sự khác khác nhau giữa hai ngành khoa học máy tính (computer science) và kĩ thuật phần mềm (software engineering), hi vọng ...
Ngoc Dao viết gần 2 năm trước
32 0
White
28 1
Nếu là team leader, giám đốc công ty hay tướng chỉ huy quân đội, vấn đề cơ bản bạn gặp phải là “hướng mọi người đi theo con đường bạn chỉ ra”. Thử...
Ngoc Dao viết gần 2 năm trước
28 1
Bài viết liên quan
White
1 1
Lập trình đôi (pair programming) là hình thức lập trình trong đó 2 người cùng hợp tác làm việc trên cùng màn hình (có thể khác bàn phím v.v.). Bài ...
Ngoc Dao viết gần 2 năm trước
1 1
White
5 1
Trong quyển sách Beyond Java, xuất bản vài năm trước có đoạn:Java has characteristics that many of us take for granted. You can find good Java deve...
Ngoc Dao viết gần 2 năm trước
5 1
White
3 0
Lập trình viên quá cố người Mỹ Phil Karlton có câu nổi tiếng: There are only two hard things in Computer Science: cache invalidation and naming th...
Ngoc Dao viết gần 2 năm trước
3 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
102 bài viết.
252 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!