Bài viết này được đăng lên Usenet bởi chính tác giả của nó, Ed Nather (utastro!nather), vào ngày 21 tháng 5 năm 1983.

Một bài viết gần đây chuyên bàn về khía cạnh nam tính của lập trình đã đưa ra một nhận định trần trụi và không rào đón:

Lập trình viên thực thụ viết bằng FORTRAN.

Có lẽ bây giờ họ làm vậy,

trong kỷ nguyên suy đồi này của

bia nhạt, máy tính cầm tay, và phần mềm "thân thiện với người dùng",

nhưng vào những Ngày Xưa Tươi Đẹp ấy,

khi thuật ngữ "phần mềm" hãy còn nghe kỳ cục

và Máy Tính Thực Thụ được làm từ trống từ và đèn điện tử,

Lập trình viên thực thụ viết bằng mã máy.

Không phải FORTRAN. Không phải RATFOR. Thậm chí không phải hợp ngữ.

Mã máy.

Những con số hệ thập lục phân thô mộc, trần trụi, khó hiểu.

Một cách trực tiếp.

Sợ rằng cả một thế hệ lập trình viên mới tinh

sẽ lớn lên trong sự thiếu hiểu biết về quá khứ hào hùng này,

tôi thấy mình có bổn phận phải mô tả lại,

trong khả năng tốt nhất qua khoảng cách thế hệ,

cách mà một Lập trình viên thực thụ đã viết mã.

Tôi sẽ gọi anh ấy là Mel,

vì đó chính là tên của anh.

Tôi lần đầu gặp Mel khi vào làm việc tại Công ty Máy tính Royal McBee,

một công ty con nay đã giải thể của hãng máy điều khiển.

Hãng này sản xuất dòng LGP-30,

một loại máy tính dùng bộ nhớ trống từ

nhỏ gọn và rẻ tiền (theo tiêu chuẩn thời đó),

và vừa bắt đầu chế tạo

RPC-4000, một chiếc máy tính dùng bộ nhớ trống từ

lớn hơn, tốt hơn, nhanh hơn và được cải tiến rất nhiều.

Lõi từ đắt quá,

mà dù sao thì cũng chẳng gắn bó lâu dài.

({Đó là lý do vì sao bạn chưa từng nghe đến công ty này,

hay chiếc máy tính đó.})

Tôi được thuê để viết một trình biên dịch FORTRAN

cho kỳ quan mới này và Mel chính là người dẫn đường cho tôi khám phá những điều kỳ diệu của nó.

Mel không có thiện cảm với các trình biên dịch.

"Nếu một chương trình không thể tự viết lại mã của chính mình,"

anh hỏi, "thì nó có ích gì chứ?"

Mel đã viết,

bằng hệ thập lục phân,

chương trình máy tính phổ biến nhất mà công ty sở hữu.

Nó chạy trên chiếc LGP-30

và chơi xì dách với các khách hàng tiềm năng

tại các buổi triển lãm máy tính.

Hiệu ứng của nó luôn rất ấn tượng.

Gian hàng LGP-30 luôn chật cứng người ở mọi buổi triển lãm,

còn các nhân viên bán hàng của IBM thì đứng quanh

và trò chuyện với nhau.

Việc này có thực sự bán được máy tính hay không

lại là một câu hỏi mà chúng tôi không bao giờ bàn tới.

Công việc của Mel là viết lại

chương trình xì dách cho dòng RPC-4000.

({Chuyển mã? Điều đó có nghĩa là gì?})

Chiếc máy tính mới có cơ chế định địa chỉ

một-cộng-một,

trong đó mỗi lệnh máy,

ngoài mã vận hành

và địa chỉ của toán hạng cần thiết,

còn có một địa chỉ thứ hai chỉ rõ vị trí trên trống từ đang quay,

nơi câu lệnh tiếp theo được đặt.

Theo thuật ngữ hiện đại,

mỗi câu lệnh đơn lẻ đều được theo sau bởi một lệnh ĐẾN (GO TO)!

Hãy nhét điều đó vào tẩu thuốc của Pascal mà ngẫm nghĩ đi.

Mel mê mẩn chiếc RPC-4000

vì anh có thể tối ưu hóa mã nguồn của mình:

nghĩa là, định vị các câu lệnh trên trống từ

sao cho ngay khi câu lệnh này hoàn thành công việc của nó,

câu lệnh tiếp theo sẽ vừa vặn cập bến "từ đầu đọc"

và sẵn sàng để thực thi ngay lập tức.

Đã có sẵn một chương trình để làm công việc đó,

một "trình hợp ngữ tối ưu hóa",

nhưng Mel từ chối sử dụng nó.

"Cậu chẳng bao giờ biết chắc nó sẽ đặt mọi thứ ở đâu,"

anh giải thích, "nên cậu sẽ phải dùng các hằng số riêng biệt."

Phải mất một thời gian dài tôi mới hiểu được câu nói đó.

Vì Mel nắm rõ giá trị bằng số

của mọi mã vận hành,

và tự gán địa chỉ trống từ cho riêng mình,

nên bất kỳ câu lệnh nào anh viết cũng có thể được xem xét

như một hằng số bằng số.

Anh có thể nhặt một câu lệnh "cộng" trước đó chẳng hạn,

và dùng nó để nhân lên,

nếu nó có giá trị số phù hợp.

Mã nguồn của anh quả thực không dễ gì cho người khác sửa đổi.

Tôi đã so sánh các chương trình do Mel tự tay tối ưu hóa

với chính đoạn mã đó được nhào nặn qua chương trình hợp ngữ tối ưu hóa,

và mã của Mel lúc nào cũng chạy nhanh hơn.

Đó là vì phương pháp thiết kế chương trình "từ trên xuống"

vẫn chưa được phát minh ra vào thời điểm đó,

và dù có rồi thì Mel cũng chẳng thèm dùng.

Anh viết các phần bên trong cùng của các vòng lặp chương trình trước,

nhờ đó chúng sẽ giành được quyền ưu tiên lựa chọn

các vị trí địa chỉ tối ưu trên trống từ.

Trình hợp ngữ tối ưu hóa lại không đủ thông minh để làm theo cách đó.

Mel cũng không bao giờ viết các vòng lặp tạo độ trễ thời gian,

ngay cả khi chiếc máy Flexowriter ương bướng

đòi hỏi phải có độ trễ giữa các ký tự đầu ra để hoạt động trơn tru.

Anh chỉ đơn giản là định vị các câu lệnh trên trống từ

sao cho mỗi câu lệnh kế tiếp vừa lướt qua đầu đọc

đúng vào lúc cần đến;

chiếc trống buộc phải thực hiện thêm một vòng quay trọn vẹn nữa

mới tìm thấy câu lệnh tiếp theo.

Anh đã sáng ra một thuật ngữ khó quên cho quy trình này.

Mặc dù "tối ưu" là một từ tuyệt đối,

giống như từ "độc nhất", nhưng trong thói quen ngôn từ hàng ngày,

người ta lại biến nó thành dạng so sánh:

"chưa hẳn tối ưu" hoặc "ít tối ưu hơn"

hoặc "không tối ưu cho lắm".

Mel gọi những vị trí có độ trễ thời gian lớn nhất

là "tồi tệ nhất" (most pessimum).

Sau khi anh hoàn thành chương trình xì dách

và làm cho nó chạy được

({Ngay cả phần khởi tạo cũng được tối ưu hóa rồi,"

anh tự hào nói}),

anh nhận được một Yêu cầu Thay đổi từ phòng kinh doanh.

Chương trình sử dụng một bộ sinh số ngẫu nhiên

tinh tế (đã được tối ưu hóa)

để xào "bài" và chia từ "bộ bài",

và một số nhân viên bán hàng cảm thấy nó quá công bằng,

bởi vì đôi khi khách hàng lại là người thua cuộc.

Họ muốn Mel chỉnh sửa chương trình

để chỉ cần gạt một công tắc cảm biến trên bảng điều khiển,

họ có thể thay đổi tỷ lệ cược và để cho khách hàng thắng.

Mel chần chừ.

Anh cảm thấy điều này rõ ràng là gian lận,

mà đúng là như vậy,

và nó làm tổn hại đến phẩm giá cá nhân của anh với tư cách là một lập trình viên,

điều đó cũng đúng nốt,

nên anh từ chối làm việc đó.

Trưởng phòng kinh doanh đã nói chuyện với Mel,

Sếp Lớn cũng vậy, và theo lời giục giã của sếp,

cả một vài Đồng nghiệp Lập trình viên nữa.

Cuối cùng Mel cũng chịu khuất phục và viết đoạn mã đó,

nhưng anh lại làm ngược bài kiểm tra,

và thế là khi công tắc cảm biến được bật lên,

chương trình thay vì thế lại gian lận, và giành chiến thắng mọi ván.

Mel vô cùng thích thú vì điều này,

cho rằng tiềm thức của mình có đạo đức không thể kiểm soát nổi,

và nhất quyết từ chối sửa lại nó.

Sau khi Mel rời công ty để tìm những chân trời mới màu mỡ hơn,

Sếp Lớn đã yêu cầu tôi xem xét đoạn mã

để xem tôi có tìm ra bài kiểm tra đó và đảo ngược nó lại được không.

Hơi miễn cưỡng một chút, tôi đồng ý xem thử.

Lần theo dấu vết mã nguồn của Mel thực sự là một cuộc phiêu lưu đích thực.

Tôi vẫn thường cảm thấy lập trình là một loại hình nghệ thuật,

mà giá trị thực sự của nó chỉ có thể được cảm nhận bởi một người khác am hiểu thứ nghệ thuật huyền bí ấy;

có những viên ngọc tuyệt đẹp và những cú lội ngược dòng xuất thần

bị che khuất khỏi tầm mắt và sự ngưỡng mộ của con người, đôi khi là vĩnh viễn,

chính bởi bản chất của quá trình đó.

Bạn có thể học hỏi được rất nhiều điều về một cá nhân

chỉ bằng cách đọc qua mã nguồn do anh ta viết,

ngay cả khi nó ở dạng hệ thập lục phân.

Tôi nghĩ rằng Mel là một thiên tài chưa được ca tụng.

Có lẽ cú sốc lớn nhất của tôi đến khi

tôi tìm thấy một vòng lặp vô hại không hề có chứa bất kỳ bài kiểm tra nào trong đó.

Không có bài kiểm tra nào cả. Hoàn toàn không.

Lẽ thường tình cho thấy đó phải là một vòng lặp kín,

nơi chương trình cứ quay vòng mãi, vĩnh viễn, không có điểm dừng.

Tuy nhiên, luồng điều khiển của chương trình lại chạy thẳng qua nó,

và thoát ra ngoài một cách an toàn ở phía bên kia.

Tôi mất tận hai tuần để tìm ra cơ chế của nó.

Chiếc máy tính RPC-4000 có một tiện ích thực sự hiện đại

gọi là thanh ghi chỉ số.

Nó cho phép lập trình viên viết một vòng lặp chương trình

có sử dụng một câu lệnh được đánh chỉ số ở bên trong;

mỗi lần chạy qua vòng lặp,

con số trong thanh ghi chỉ số

sẽ được cộng vào địa chỉ của câu lệnh đó,

nhờ vậy nó sẽ trỏ tới

dữ liệu tiếp theo trong một chuỗi.

Anh ta chỉ cần tăng giá trị của thanh ghi chỉ số lên

sau mỗi lần lặp.

Mel không bao giờ dùng đến nó.

Thay vào đó, anh sẽ kéo câu lệnh đó vào một thanh ghi của máy,

cộng thêm một vào địa chỉ của nó,

và lưu ngược trở lại.

Sau đó anh sẽ thực thi câu lệnh đã được sửa đổi đó

ngay từ trong thanh ghi.

Vòng lặp được viết sao cho thời gian thực thi bổ sung này

đã được tính toán thấu đáo —

ngay khi câu lệnh này kết thúc,

câu lệnh tiếp theo đã nằm ngay bên dưới đầu đọc của trống từ,

sẵn sàng hoạt động.

Nhưng vòng lặp đó hoàn toàn không có bài kiểm tra nào.

Manh mối sống còn chỉ đến khi tôi nhận thấy

bit thanh ghi chỉ số,

cái bit nằm giữa phần địa chỉ

và phần mã vận hành trong từ lệnh,

đang được bật lên —

vậy mà Mel lại chưa bao giờ sử dụng thanh ghi chỉ số,

mà luôn để nó bằng không suốt thời gian đó.

Đến lúc ngọn đèn sáng lên trong đầu thì tôi suýt bị lóa mắt.

Anh đã định vị dữ liệu mà mình đang xử lý

ở gần phần đỉnh của bộ nhớ —

những ô nhớ lớn nhất mà các câu lệnh có thể trỏ tới —

cho nên, sau khi dữ liệu cuối cùng được xử lý xong,

việc tăng địa chỉ câu lệnh lên

sẽ làm cho nó bị tràn bộ nhớ.

Phần nhớ tràn (carry) sẽ cộng thêm một vào mã vận hành,

biến nó thành câu lệnh tiếp theo trong tập lệnh:

một câu lệnh nhảy.

Và quả đúng như vậy, câu lệnh tiếp theo của chương trình lại nằm

ở ô nhớ số không,

và chương trình cứ thế vui vẻ tiếp tục hành trình của mình.

Tôi đã không giữ liên lạc với Mel,

nên tôi không biết liệu anh có bao giờ chịu khuất phục trước dòng thác thay đổi

đã càn quét qua các kỹ thuật lập trình

kể từ những ngày tháng xa xôi ấy hay không.

Tôi thích nghĩ rằng anh đã không khuất phục.

Dù thế nào đi nữa,

tôi đã đủ ấn tượng để từ bỏ việc tìm kiếm câu lệnh kiểm tra gây phiền toái kia,

và nói với Sếp Lớn rằng tôi không thể tìm thấy nó.

Trông ông ấy có vẻ không ngạc nhiên cho lắm.

Khi tôi rời công ty,

chương trình xì dách vẫn sẽ gian lận

nếu bạn bật chiếc công tắc cảm biến phù hợp, và tôi nghĩ điều đó là nên thế.

Tôi không cảm thấy thoải mái chút nào

khi đi chắp vá mã nguồn của một Lập trình viên thực thụ.

Đây là một trong những sử thi anh hùng vĩ đại của giới hacker, dù có là thơ tự do hay không. Chỉ với vài hình ảnh tiết kiệm, nó nắm bắt được nhiều điều về tính thẩm mỹ và tâm lý của việc hack hơn tất cả các tập sách khảo cứu về chủ đề này gộp lại. Để có một góc nhìn đối lập, hãy xem mục dành cho Lập trình viên thực thụ.

Bài bạt năm 1992 -- tác giả viết: "Bài nộp ban đầu lên mạng không phải là thơ tự do, cũng chẳng có điểm gì gần giống với nó -- đó là văn xuôi rặt, với các đoạn không canh lề. Khi lan truyền trên mạng, nó rõ ràng đã bị biến đổi thành dạng 'thơ tự do' phổ biến hiện nay. Nói cách khác, nó đã bị 'hack' ngay trên mạng. Điều đó dường như lại rất phù hợp, theo một cách nào đó." Tác giả nói thêm rằng ông thích phiên bản 'thơ tự do' này hơn...

Cập nhật năm 1999: Họ của Mel giờ đây đã được biết đến. Sách hướng dẫn của LGP-30 có nhắc đến "Mel Kaye thuộc hãng Royal McBee, người đã thực hiện phần lớn công việc lập trình [...] cho hệ thống ACT 1".

Nút: Phụ lục B, Tiếp: Phụ lục C, Trước: Phụ lục A, Lên: Trên cùng