- Trong các tác vụ dữ liệu không phải deep learning như phân tích, trực quan hóa và tóm tắt dữ liệu, Python tuy đủ chức năng nhưng trải nghiệm sử dụng dễ trở nên phức tạp và kém hiệu quả
- Qua nhiều trường hợp trong phòng thí nghiệm, người ta liên tục xác nhận xu hướng rằng so với R, Python đòi hỏi nhiều mã và thời gian hơn ngay cả cho các phép biến đổi đồ thị đơn giản hay tính toán thống kê
- Ngay cả khi dùng pandas, matplotlib, NumPy..., người dùng vẫn thường bị cuốn vào chi tiết triển khai (logistics) hơn là logic, do cú pháp, indexing, dấu ngoặc và cấu trúc method chain
- Ngược lại, tidyverse của R có thể biểu đạt luồng xử lý dữ liệu ở mức gần với ngôn ngữ tự nhiên, nên dễ chuyển trực tiếp logic công việc thành mã hơn
- Với vai trò là ngôn ngữ khoa học dữ liệu, Python có giới hạn mang tính cấu trúc trong việc tách logic và logistics, và đây là vấn đề bắt nguồn từ thiết kế của ngôn ngữ cũng như hệ sinh thái
So sánh trải nghiệm sử dụng thực tế giữa Python và R
- Các thành viên trong phòng thí nghiệm được tự do chọn ngôn ngữ, nhưng có nhiều người dùng Python hơn, và một mô thức nhất quán xuất hiện là họ không thể xử lý nhanh các yêu cầu phân tích bổ sung đơn giản
- Ngay cả việc chuyển đổi trực quan hóa như boxplot → violin plot, histogram → density plot, hay line chart → heatmap cũng khó thực hiện ngay lập tức
- Công việc chỉ mất vài dòng trong R lại thường được cảm nhận trong Python như kiểu “phải quay về chỗ rồi code lại từ đầu”
- Ngay cả khi cùng giảng dạy với các chuyên gia Python, sự khác biệt lớn về độ dài và độ phức tạp của mã so với R vẫn lộ rõ
- Phản ứng kiểu “Tại sao lại phải phức tạp đến thế này?” lặp đi lặp lại trong nhiều tình huống, và điều này có vẻ là khác biệt mang tính cấu trúc của kiến trúc ngôn ngữ và thư viện, chứ không phải do kỹ năng cá nhân
- Ngay cả với cùng một logic, Python thường cần indexing, tách dữ liệu, lắp ghép lại và kết hợp nhiều method nên cấu trúc trở nên dài dòng
- Với R tidyverse, có thể biểu đạt trực tiếp bằng chuỗi tự nhiên như
filter → group_by → summarize
Vì sao Python được dùng rộng rãi và giới hạn của nó
- Vị thế của Python trong khoa học dữ liệu dựa trên sự phổ biến về mặt lịch sử, tính đa dụng và quy mô hệ sinh thái hơn là vì nó thực sự phù hợp một cách độc đáo
- Trong lĩnh vực deep learning, Python đúng là trung tâm nhờ PyTorch và hệ sinh thái AI
- Nhưng trong làm sạch dữ liệu, khám phá dữ liệu, trực quan hóa và mô hình hóa thống kê, nó vẫn còn nhiều bất tiện
- Đây là một mức độ phổ biến “gần như tai nạn lịch sử (historical accident)”, và cấu trúc ngôn ngữ nặng nề hơn R liên tục lộ ra qua nhiều ví dụ
Điều kiện của một ngôn ngữ khoa học dữ liệu tốt
- Với các công việc xoay quanh khám phá dữ liệu, tóm tắt, khớp mô hình và trực quan hóa, điều quan trọng nhất là môi trường tương tác, chi phí thiết lập thấp và lặp lại nhanh
- So với ngôn ngữ biên dịch, ngôn ngữ thông dịch kiểu script phù hợp hơn
- So với hiệu năng, độ đơn giản của mã, giảm rủi ro lỗi và tối thiểu hóa gánh nặng tư duy mới là ưu tiên
- Nếu cần, chỉ cần viết lại một phần phép toán bằng ngôn ngữ hiệu năng cao hơn (như Rust), chứ không phải toàn bộ
- Trên thực tế, các ngôn ngữ có thể cân nhắc là R và Python
- Matlab, Mathematica... hoặc là phần mềm thương mại hoặc có hệ sinh thái hạn chế
- Julia thường được nhắc đến, nhưng tác giả chưa dùng đủ nhiều nên tạm hoãn đánh giá
Vấn đề “logic vs logistics”
- Một ngôn ngữ phân tích dữ liệu cần phải tách biệt cần tính cái gì (logic) và tính bằng cách nào (logistics)
- Nếu còn phải bận tâm tới kiểu dữ liệu, chỉ mục, vòng lặp hay lắp ráp thủ công, thì bạn đã bị mắc vào logistics
- Trong ví dụ Palmer Penguins, tidyverse của R biểu đạt việc tính trung bình và độ lệch chuẩn bằng một luồng gần với ngôn ngữ tự nhiên
- Không cần quá trình tháo rời luồng dữ liệu rồi ghép lại lần nữa
- pandas cũng cung cấp chức năng tương tự, nhưng do có nhiều việc phụ như chỉ định chuỗi, dấu ngoặc, method chain,
reset_index..., nên tính dễ đọc và sự đơn giản bị giảm đi
- Nếu triển khai cùng công việc chỉ bằng Python thuần
- Cấu trúc vòng lặp → tạo khóa nhóm → phân tách → tính trung bình → tính phương sai → tính độ lệch chuẩn → ghép lại → sắp xếp...
- Tất cả đều phải xử lý thủ công, trở thành ví dụ điển hình nơi mã logistics lấn át logic
Kết luận và gợi mở nội dung tiếp theo
- Trong phân tích dữ liệu, Python liên tục bộc lộ vấn đề mang tính cấu trúc khiến người dùng tập trung vào chi tiết triển khai hơn là logic
- Điều này có vẻ là kết quả của sự kết hợp giữa đặc tính của chính ngôn ngữ, giới hạn trong thiết kế thư viện và tập quán của toàn bộ hệ sinh thái
- Trong bài viết tiếp theo, tác giả sẽ bàn về các nguyên nhân kỹ thuật cụ thể khiến Python làm việc phân tích dữ liệu khó hơn R
Góc nhìn thảo luận và so sánh bổ sung (bao gồm phản hồi độc giả)
- Có ý kiến cho rằng tidyverse có thể dài dòng hơn R cơ bản, nhưng lại mạnh về khả năng biểu đạt, tính nhất quán và mức độ trừu tượng hóa xử lý dữ liệu
- Ngược lại, cũng có phản biện rằng R gây nhiều bất tiện ở khía cạnh phát triển phần mềm như modular hóa, kiểm thử, triển khai CLI
- Python có trải nghiệm lập trình viên tốt hơn ở các mặt như logging, môi trường ảo, packaging, cấu trúc class, nhưng
- matplotlib có thiết kế thiếu trực quan,
- pandas có cú pháp thiếu nhất quán,
- scikit-learn thường bị nhắc đến vì các vấn đề trong thiết kế
- Một số ý kiến xem Python là “ngôn ngữ giúp sản xuất nhanh mã thiếu ổn định và chất lượng thấp”, và cho rằng với phát triển bền vững, ngôn ngữ kiểu tĩnh sẽ tốt hơn
2 bình luận
Khi độ phức tạp và khối lượng dữ liệu tăng lên, cần xử lý phân chia theo từng giai đoạn, đồng thời phải xử lý cả dữ liệu phi cấu trúc, mô hình có cấu trúc và cả gia công thông qua LLM, thì vì có rất nhiều use case nên chẳng phải đây lại là ngôn ngữ phù hợp nhất sao.
Ý kiến trên Hacker News
Đã đưa ra nhiều ví dụ chuyển đổi như đổi boxplot sang violin plot, hoặc line plot sang heatmap
Thực ra thảo luận này nói về matplotlib nhiều hơn là Python
Nếu muốn thiết kế kiểu ggplot trong Python thì có thể dùng plotnine
Lý do mã R trông ngắn gọn hơn là nhờ đánh giá phi tiêu chuẩn (non-standard evaluation) của R
Python không cho phép kiểu mở rộng này ở cấp độ ngôn ngữ
Có thể tham khảo thêm tại Computing on the language
Đánh giá phi tiêu chuẩn tiện trong môi trường tương tác, nhưng khi viết mã phân tích phức tạp thì lại trở thành nhược điểm
Có những việc đơn giản cũng phải đi đường vòng
Tôi nghĩ đặt toán tử pipe ở phía trước như Elixir sẽ tốt hơn
Python cũng có thể bắt chước cú pháp tương tự bằng các mẹo như getattr, nhưng suy cho cùng đây là vấn đề thiết kế API thư viện hơn là vấn đề ngôn ngữ
R chỉ dễ khi có thư viện và recipe, còn không thì thực sự rất khó, và đa số mọi người đơn giản là không làm
Nó trừu tượng hóa những điểm bất tiện của matplotlib nhưng vẫn cung cấp nhiều tính năng
Hướng dẫn Seaborn
Tôi thắc mắc vì sao trong ngôn ngữ lập trình, bảng không phải đối tượng hạng nhất
Phần lớn ngôn ngữ buộc phải học thêm API riêng như pandas hay polars để xử lý bảng
Trong R, data.frame gần như là đối tượng hạng nhất, nhưng trên thực tế người ta dùng tibble của dplyr nhiều hơn
Vẫn chưa có một ngôn ngữ biểu đạt chuẩn hóa để xử lý dữ liệu dạng bảng
Polars và dplyr có triết lý khá giống nhau, nhưng rốt cuộc SQL dường như là nền tảng chung duy nhất
Python chưa hoàn hảo, nhưng tôi nghĩ R cũng vậy
Những cấu trúc như bảng, ma trận, đồ thị, máy trạng thái không được hỗ trợ ở cấp độ ngôn ngữ nên việc sử dụng bị hạn chế
Các công cụ được tích hợp sẵn trong ngôn ngữ sẽ quyết định “con đường đẹp” của ngôn ngữ đó
Trước đây key-value store cũng là thư viện ngoài, nhưng giờ gần như đã thành tiêu chuẩn
Tôi đoán rồi một ngày nào đó các ngôn ngữ chủ lưu cũng sẽ hấp thụ kiểu lập trình dựa trên bảng này
Ngôn ngữ Q, bài so sánh Rye, công cụ thử nghiệm Lil
Việc chuyển đổi giữa ba đối tượng này cũng rất đơn giản
Thiết kế một API tiêu chuẩn có thể xử lý thanh lịch những khác biệt về quy mô như vậy không hề dễ
Chỉ là dplyr đã thắng ở phần tài liệu và onboarding nên được ngành công nghiệp chấp nhận rộng rãi hơn
Ý chính của bài viết ổn, nhưng tiếc là tác giả đã để lộ cơ sở lập luận quá sớm
R mạnh về xử lý data frame, nhưng yếu ở quản lý tệp và bảo trì
Nếu phải làm nhiều việc kiểu đó thì Python tốt hơn, còn nếu tốc độ cũng quan trọng thì sẽ nghiêng sang Julia
Việc chọn ngôn ngữ thay đổi tùy theo ưu tiên
Tôi thường thấy sinh viên cố giải các bài toán phi bảng như đồ thị bằng pandas, và trong trường hợp đó nên xem lại việc chọn công cụ
Dùng numpy thì việc tính trung bình và phương sai đã có sẵn
Python và R đều có độ khó học tương tự nhau, nhưng Python mạnh ở khả năng tích hợp với các ứng dụng khác
Khi xử lý tệp lớn thì Python hiệu quả hơn, còn khi phân tích dữ liệu tóm tắt thì R hiệu quả hơn
Mỗi ngôn ngữ nên được dùng như một công cụ đúng chỗ
Với tư cách là một lập trình viên Python, tôi cũng đã dùng R, và Python là một “ngôn ngữ làm được gần như mọi thứ khá tốt nhưng không hoàn hảo”
Nếu bạn làm phân tích dữ liệu cả ngày thì nên học R
R là ngôn ngữ được thiết kế theo cách tư duy của nhà thống kê
Ban đầu sẽ thấy lạ, nhưng chính sự chuyển đổi tư duy đó lại hữu ích
Dù vậy tôi vẫn làm phần lớn công việc bằng Python
Làm khoa học dữ liệu với pandas thì được, nhưng thô và phức tạp
Với polars thì đỡ hơn một chút, nhưng khi dùng duckdb thì mọi thứ thay đổi hẳn
Tôi chạy truy vấn SQL trực tiếp trong notebook và phân tích các tệp parquet
Trộn cell SQL với cell Python làm mã sạch hơn
Nhìn phần so sánh Python với R ở cuối bài, tôi đã nghĩ “viết bằng SQL có phải tốt hơn nhiều không?”
Ví dụ Python ở cuối dài dòng một cách không cần thiết
Dùng
defaultdictvàstatistics.stddevsẽ ngắn gọn hơn nhiềuNhiều trường hợp người ta triển khai mà không cân nhắc liệu hiệu chỉnh đó có ý nghĩa hay không
Thực ra chỗ này nên gọi là sample_std_dev thì chính xác hơn
itertools.groupbyMã không hẳn ngắn hơn nhưng có thể thể hiện ý định rõ ràng hơn
Cố viết ngắn mà hy sinh khả năng đọc hiểu thì không hay
Tôi đã thử triển khai cùng ví dụ bằng TidierData.jl của Julia, và kết quả gần như giống hệt phiên bản R
Cú pháp macro như
@chain,@group_by,@summarizekhá giống tidyverse của RTôi không hiểu rõ sự bất mãn của tác giả
Việc Python không được tối ưu cho khoa học dữ liệu là điều hiển nhiên
Python không phải DSL, và ngay cả MATLAB cũng được thiết kế cho tính toán khoa học nhưng lại không phải ngôn ngữ phổ biến
Một ngôn ngữ tốt giống một thành phố đáng sống hơn là thời tiết hoàn hảo
Python giống như “một thành phố Bắc Âu phát triển mạnh dù thời tiết không đẹp”
Chủ đề bài viết hơi mang tính câu view nên tôi không nghĩ đây là một cuộc thảo luận thật sự hiệu quả
Tôi ước gì Julia được dùng nhiều hơn
Trước đây tôi từng triển khai lại một thuật toán cho bài báo về psychometrics bằng Julia, và nó chạy nhanh gấp ba lần MATLAB
Liên kết bài báo liên quan
Ví dụ Python cuối cùng trông giống một màn châm biếm phản Python hơn là mã Python thực tế
Tự cài đặt độ lệch chuẩn là bài tập ở bậc đại học
Trên thực tế cả R và Python đều chạy các vòng lặp như vậy ở bên trong
Nhưng trong môi trường công nghiệp thực tế, Python dễ cộng tác với đội ngũ kỹ thuật hơn nhiều
Tôi từng triển khai mã R vào production và nó rất thiếu ổn định
R rất tuyệt cho phân tích khám phá (EDA), nhưng không phù hợp với phát triển phần mềm quy mô lớn