Lựa chọn ngôn ngữ
Software Engineering
36
White

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

Dưới đây là trích đoạn bài viết Choosing languages của Steve Yegge, cựu nhân viên của Amazon và đương kim nhân viên của Google. Mặc dù bài này viết năm 2005, đã lâu, nhưng chứa một số ý tưởng có lẽ vẫn còn đúng tại thời điểm hiện tại.

Giải quyết vấn đề chi phí rắc rối đó

Our "little" tech detour was a lot longer than I expected it to be. Oh well. My main point today is supposed to be about choosing languages with an eye towards optimizing cost, so let's talk about that a bit.

Chuyến du lịch kỹ thuật "nho nhỏ" của chúng ta dài hơn một đống so với dự tính của tôi. Ôi trời. Luận điểm chính của tôi hôm nay là lựa chọn ngôn ngữ hướng về việc tối ưu chi phí, vậy chúng ta hãy nói về điều này một tý.

For the record, I agree 100% with the many folks who argue (sometimes coming awfully close to spitting on me in their passion about it) that using too many languages, or obscure languages, has a high cost. Yep. It sure does. Thank you for not spitting.

Trước tiên, tôi đồng ý 100% với nhiều nguời tranh cãi (thỉnh thỏang nhiệt tình lại gần tôi đến nỗi văng nước miếng vào người tôi) rằng sử dụng quá nhiều ngôn ngữ, hay ngôn ngữ ít thông dụng, gây chi phí cao. Chẹp. Chắc chắn là thế. Cám ơn đã không văng nuớc miếng vào người tôi.

When discussing cost optimization, I tend to classify programming languages four broad categories:

Khi bàn về tối ưu chi phí, tôi thiên về phân loại ngôn ngữ lập trình vào 4 mục sau:

  1. Production Languages - languages that you use for building robust, scalable production systems. It's a pretty short list: C, C++, Java, and maybe C-sharp or Objective-C (but only maybe). They have to be popular, they should be statically typed, they need to perform well, they need great tools and documentation, etc. Not many options in this category.

    Ngôn ngữ để xây dựng hệ thống lớn - ngôn ngữ bạn sử dụng để xây dựng các hệ thống mạnh, có khả năng mở rộng. Danh sách này khá ngắn: C, C++, Java, và có thể C# hay Objective-C (chỉ là "có thể" thôi). Chúng phải thông dụng, chúng nên định kiểu tĩnh, chúng cần chạy nhanh, chúng cần công cụ và tài liệu thật tốt, v.v. Không có nhiều lựa chọn trong mục này.

  2. Scripting Languages - languages you use for doing things that C, C++ and Java totally suck at, like string processing, OS automation, data munging, backfills, that kind of thing. Again, you want to use popular ones, so you're stuck with Perl, Ruby, Python, or the built-in Unix-y ones like shell-script and awk (although if you're gonna do that, you almost always want to use Perl/Python/Ruby because they have more expressive power and more libraries.)

    Ngôn ngữ kịch bản - ngôn ngữ bạn dùng làm những việc mà C, C++ và Java làm dở ẹc, như xử lý chuỗi, tự động hóa tác vụ của hệ điều hành, chọc ngoáy dữ liệu (ví dụ chuyển đổi định dạng log), backfill (là cái gì nhỉ?), đại loại thế. Một lần nữa, bạn muốn sử dụng những cái thông dụng, nên bạn chắc chắn sẽ sử dụng Perl, Ruby, Python, hay những cái có sẵn trên những hệ điều hành họ Unix như shell-script và awk (mặc dù nếu bạn làm thế, hầu như bạn luôn muốn sử dụng Perl/Python/Ruby vì chúng có khả năng diễn đạt cao hơn và nhiều thư viện hơn.)

    Yeah, I know, people who love scripting languages want to believe they're great for building giant scalable systems. I wish they were. They're certainly awesome for prototyping, and they seem to work well for user-interface creation (e.g. with Mason). But I'm a bit skeptical about building a large production system in a weakly-typed language, for lots of reasons: refactoring tool support, general code readability, performance, blah blah blah. I hope someday someone proves me wrong here, but for now, I think you want to use dynamically-typed languages only in certain niches.

    Ừ, tôi biết, những nguời yêu ngôn ngữ kịch bản muốn tin rằng chúng tuyệt vời để xây dựng những hệ thống lớn có khả năng mở rộng. Tôi uớc chúng như thế. Chúng chắc chắn tuyệt vời để xây dựng bản nháp thử trước khi xây dựng hệ thống thật, và chúng có vẻ tốt để tạo giao diện nguời dùng (ví dụ với Mason). Nhưng tôi hơi nghi ngờ việc xây dựng hệ thống lớn bằng ngôn ngữ định kiểu yếu, bởi rất nhiều lý do: công cụ refactor, độ dễ hiểu của mã nguồn nói chung, tốc độ, blah blah blah. Tôi hi vọng ngày nào đó có người chứng minh là tôi sai chỗ này, nhưng bây giờ, tôi nghĩ bạn muốn sử dụng các ngôn ngữ định kiểu động chỉ trong một số lĩnh vực nhất định.

    If you feel I'm wrong, please don't mail me with a long rant; publish your thoughts as a blog somewhere!

    Nếu bạn cảm thấy tôi sai, làm ơn đừng gửi thư tru tréo tôi; hãy đăng suy nghĩ của bạn thành bài blog ở đâu đó!

  3. Studyable Languages - languages like Lisp, Scheme, OCaml, Haskell, Eiffel, Erlang, etc., that have cool features that you'd love to use, if only these languages were actually popular. But I wouldn't use any of them in production. (Lisp is a special case that I'm still trying to figure out, so let's leave it as a "maybe/sometimes" for now.)

    Ngôn ngữ có thể học được - các ngôn ngữ như Lisp, Scheme, OCaml, Haskell, Eifel, Erlang, v.v., chúng có các các tính năng độc đáo mà bạn rất thích sử dụng, chỉ nếu các ngôn ngữ này thật sự thông dụng. Nhưng tôi sẽ không sử dụng bất kỳ cái nào trong số đó xây dựng phần mềm lớn. (Lisp là một truờng hợp đặc biệt mà tôi vẫn cố tìm hiểu, vì thế tạm thời hãy để chúng là "có thể/thỉnh thoảng".)

  4. Languages you're stuck with - e.g., JavaScript for client-side browser automation, Tcl for automating TotalView, Emacs-Lisp for Emacs, or any other language that you have to use because you depend on a product that requires it. There's no help for you here - you just have to know them if you want to be maximally productive with that product, and sometimes you don't have a choice.

    Ngôn ngữ mà bạn bị mắc kẹt không thể không sử dụng - ví dụ, phải sử dụng JavaScript khi viết chương trình chạy trên trình duyệt, Tcl để tự động hóa TotalView, Emacs-Lisp cho Emacs, và bất kỳ ngôn ngữ nào khác mà bạn phải sử dụng vì bạn phải sử dụng sản phẩm cần có nó. Không có cách nào khác - bạn phải biết chúng nếu bạn muốn có năng suất làm việc cao nhất khi sử dụng sản phẩm đó, và thỉnh thỏang bạn không có quyền lựa chọn.

So where does that leave us?

Vậy điều đó dẫn ta đến đâu?

I think when you're deciding what language to use for "real" work, you want to choose as follows:

Tôi nghĩ khi quyết định ngôn ngữ để dùng cho công việc "thật sự", bạn hãy chọn như sau:

  1. Only consider popular languages. Veeeeeery important. Critical, even.

    Hãy chỉ xem xét những ngôn ngữ thông dụng. Râââââất quan trọng. Cực quan trọng, chấm hết.

  2. Pick the right language category for your problem. For systems up to a certain size, you probably want a good dynamic/scripting language, and beyond that point, use C++, Java or maybe C#.

    Hãy chọn mục ngôn ngữ đúng cho vấn đề của bạn. Với các hệ thống có kĩch cỡ đến mức độ nhất định nào đó, bạn có thể muốn sử dụng ngôn ngữ động/kịch bản tốt, và to hơn mức độ đó, sử dụng C++, Java hay có thể là C#.

  3. Once you've decided the category, always use the highest-level language in the list. Use the one that's the most modern, expressive, and the least prone to errors when placed in the hands of busy/stressed programmers. If there's a tie, pick the one that's easiest to learn.

    Một khi bạn đã quyết định mục ngôn ngữ, hãy luôn sử dụng ngôn ngữ cấp cao nhất trong danh sách. Hãy sử dụng cái hiện đại nhất, khả năng diễn đạt tốt nhất, và dẫn đến ít lỗi nhất khi nằm trong tay những lập trình viên bận rộn/căng thẳng. Nếu có nhiều ngôn ngữ tính năng ngang nhau không biết chọn cái nào, hãy chọn cái dễ học nhất.

You shouldn't worry about language performance - that's a premature optimization. Remember that we're writing server-side software, and it doesn't need to run on our customers' desktops. Programmer time is very expensive, so pick a language that makes the best use of programmer time. Your profiler will take care of the rest.

Không nên lo lắng về tốc độ chạy của ngôn ngữ - đó là tối ưu vội. Hãy nhớ chúng ta đang viết phần mềm phía server, và nó không cần chạy trên máy tính cá nhân của khách hàng. Thời gian của lập trình viên rất đắt (chi phí của công ty phần mềm chủ yếu là lương trả cho lập trình viên), vì vậy hãy chọn ngôn ngữ tối ưu thời gian của lập trình viên. Chương trình profiler (để đo tốc độ từng thành phần của chương trình) sẽ lo phần còn lại (cho biết chỗ nào chạy chậm cần tối ưu để tăng tốc độ).

You shouldn't worry about whether you or your team know the language or not. That's being short-sighted. You may see more progress initially, but over time, you're losing out on the gains they'd get from having switched to a more productive language environment.

Bạn không nên lo lắng việc liệu bạn hay nhóm của bạn có biết ngôn ngữ đó hay không. Điều đó là thiển cận. Bạn có thể thấy tốc độ làm việc lúc đầu nhanh, nhưng rồi bạn sẽ thấy bạn cái lợi này chẳng là gì so với việc ngay từ đầu đã chuyển qua môi truờng ngôn ngữ mang lại năng suất cao hơn.

I realize all this flies in the face of the conventional wisdom that you should put performance first. Our industry is still largely slave to performance (and to running on the client desktop). C and C++ are still the only options for most companies, and performance is more important for them than "human" factors like code maintainability, build times, development speed, and so on.

Tôi thấy rõ vấn đề này nổi lên là do kiến thức thông thường là bạn nên đặt tốc độ lên hàng đầu. Ngành công nghiệp của chúng ta phần lớn vẫn đang là nô lệ của tốc độ (và nô lệ của việc chạy trên máy tính cá nhân). C và C++ vẫn là những lựa chọn duy nhất cho hầu hết các công ty, và tốc độ với họ hơn những yếu tố "con nguời" như tính dễ bảo trì, số lần biên dịch, tốc độ phát triển dự án, v.v.

But for Amazon and other web-based companies, the landscape has changed significantly. C++ and Perl may have been the only viable options in the late 90's, but that's simply not true anymore. And I think that unless we re-examine our options, and try to optimize for human cost instead of hardware cost, we're actually spending more money to do the same amount of work. A lot more.

Nhưng với Amazon và các công ty chuyên làm web khác, tình hình đã thay đổi rất nhiều. C++ và Perl có thể là lựa chọn duy nhất ở thời điểm cuối thập niên 90, nhưng dĩ nhiên điều đó không còn đúng nữa. Và tôi nghĩ trừ khi chúng ta xem lại các lựa chọn, và cố chú trọng tối ưu chi phí con nguời thay vì chí phí phần cứng, chúng ta thật sự đang tốn nhiều tiền hơn để làm cùng một luợng công việc. Tốn tiền hơn rất nhiều.

I know there are plenty of smart people at Amazon who, at this point in the article, are ready to lynch me, but hey, this is just a magazine. They're welcome to write up their opinions too!

Tôi biết có hàng tá nguời thông minh ở Amazon sẵn sàng hành hình tôi vì điểm này, nhưng mà này, đây chỉ là bài blog thôi. Họ cũng có thể viết ra quan điểm của mình!

Câu kết

I've spent a very long time trying to find the best solution to this multi-dimensional cost-optimization problem: about 2 years, in fact, part-time at home, studying and learning something like 40 programming languages. I care about this problem a lot, both for my own productivity and for Amazon's, since I plan to be here for a good long while.

Tôi đã dành nhiều thời gian để tìm giải pháp tốt nhất cho vấn đề tối ưu hóa chi phí nhiều chiều này: khoảng 2 năm, thực ra là dành một phần thời gian ở nhà để nghiên cứu và học khỏang 40 ngôn ngữ lập trình. Tôi rất quan tâm vấn đề này, cả vì năng suất làm việc của tôi và của Amazon, bởi vì tôi có kế hoạch làm việc dài hạn tại đây.

I'm fairly convinced that for the foreseeable future (the next 5 years or so), the right languages -- for me anyway -- are Java and Ruby. Java for big stuff, Ruby for small-to-medium stuff.

Tôi khá bị thuyết phục là trong tương lai đoán trước được (có nghĩa khoảng 5 năm nữa), ngôn ngữ phù hợp nhất -- cho tôi -- là Java và Ruby. Java cho những vấn đề lớn, Ruby cho vấn đề nhỏ đến vừa.

I can hear the cries of anger erupting already. My inbox overfloweth, and all that. Remember, I said for me. You can use whatever you like. My only recommendation is that you don't decide by fiat. Give it some thought; don't assume that the language you're most comfortable with today is automatically the right one for your next project.

Tôi có thể nghe thấy những lời kêu la của những kẻ đang tức tối. Hôp thư tôi đầy những thứ đó. Nhớ rằng, tôi nói cho riêng tôi. Bạn có thể dùng bất cứ cái gì mình thích. Lời khuyên duy nhất của tôi là bạn đừng quyết định bởi sự chấp nhận. Hãy suy nghĩ; đừng cho là ngôn ngữ bạn quen thuộc hôm nay sẽ là lựa chọn đúng cho dự án sắp tới.

And don't forget the "Languages You're Stuck With" category. I'd probably rather customize Emacs using Ruby than Emacs-Lisp, but elisp is my only choice for now. If you use VIM or Eclipse, you have more options. But you'll always need to know a few extra languages in order to get the most out of your tools. You can never get away with just two languages, not if you want to be efficient.

Và đừng quên mục "Ngôn ngữ mà bạn bị mắc kẹt”. Tôi có thể thích tùy biến Emacs để dùng Ruby hơn là dùng Emacs-Lisp, nhưng tạm thời Emacs bắt tôi phải dùng elisp. Nếu bạn dùng VIM hoặc Eclipse, bạn có nhiều lựa chọn hơn. Nhưng bạn sẽ luôn cần biết thêm vài ngôn ngữ để có thể sử dụng hiệu quả nhất các công cụ. Bạn không thể đi đâu chỉ với 2 ngôn ngữ, không thể nếu bạn muốn đạt hiệu quả cao trong công việc.

The punch line, then, is this: I'll use Java and Ruby when I can, and other languages when I have to. And I'll keep an eye on all of them, since you never know when some new one's gonna be totally... groovy.

Vậy câu kết là: "Tôi sẽ dùng Java và Ruby khi có thể, và các ngôn ngữ khác khi bị buộc phải làm thế. Và tôi luôn để ý mọi ngôn ngữ, vì không thể biết khi nào cái mới nào đó sắp trở nên thông dụng".

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.
284 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
62 8
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 hơn 2 năm trước
62 8
White
40 1
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 hơn 2 năm trước
40 1
White
34 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 hơn 2 năm trước
34 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 hơn 2 năm trước
1 1
White
7 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 hơn 2 năm trước
7 1
White
5 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 hơn 2 năm trước
5 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

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


White
{{userFollowed ? 'Following' : 'Follow'}}
102 bài viết.
284 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á!