tư duy hình thức

Nhân một tranh luận gần đây trên báo chí: “trẻ em như tờ giấy trắng là một suy nghĩ sai hoàn toàn”… nhân chuyện này bàn về kiểu tư duy máy móc, hình thức của người Việt! “Trẻ em như tờ giấy trắng”, câu cũng có phần đúng, chúng nó chưa biết gì và chỉ tiếp thu, tiêm nhiễm những gì được dạy, được thấy! Nhưng câu đó cũng không đúng hoàn toàn, trẻ em như một hạt giống mang thông tin di truyền, và biết đâu đó, có thể được thừa hưởng cả những “duyên nghiệp” từ kiếp trước (từ ngữ hơi duy tâm một tí)! Nên hành trình phát triển của một đứa bé, rất thường khi là nằm ngoài tiên liệu của phụ huynh và giáo viên! Trẻ em vừa là tờ giấy trắng, vừa không phải là tờ giấy trắng, đó đơn giản chỉ là những cách diễn đạt khác nhau, hình thức lý luận nhị nguyên, một điểm yếu cố hữu của tư duy con người!

Nhưng 99% người Việt (có khi là nhiều hơn) chấp vào cái hình thức nhị nguyên thô thiển, sơ khai đó! Họ chấp vào đó như “gà mắc tóc”, điều đó dẫn đến sự “đối kháng” giữa những “suy nghĩ” khác nhau! Theo tôi, ai còn mắc vào những lỗi “tư duy hình thức” như vậy là chỉ cho thấy tầm tư duy nông cạn, hời hợt trên bề mặt, không nghĩ ra được những nội dung sâu xa hơn, không thể đi hết độ phức tạp của vấn đề, nên đành đứng trên bề mặt trắng đen như thế. Bao nhiêu “học hỏi, tư duy”, lên mạng đọc này kia, biết được một vài “ngôn từ lảm nhảm” là đã tự cho mình giỏi, nghĩ rằng bao nhiêu đó là đủ rồi! Sự việc trở nên tồi tệ hơn khi họ ngày càng “chấp ngã”, bám vào những cái lý lẽ đó theo kiểu “take position” – giữ vị trí y như trong quân sự vậy, bên này là “ta”, bên kia là “địch”!

Các tranh luận ở VN đều mang tính “đối kháng”, “chiếm lĩnh vị trí” như thế, kiểu tư duy bên kia là “địch”, bên này là “ta”, trắng đen rõ ràng! Nhưng tiếc thay, kiến thức không phải 3D hay 4D như quân sự, nó là không gian phức tạp nhiều chiều kích, thay vì đối kháng, cần gợi mở để cùng phát triển, đó mới là tranh luận thực sự. Trong giáo dục, “giữ vị trí”, cố sống chết bám vào một điểm thì cũng chẳng khác nào tự giới hạn mình! Chuyện này cũng như khác biệt giữa cờ vây và cờ vua vậy! Cờ vua có tính đối kháng rõ ràng, mục tiêu là ăn “hậu” của đối phương! Nhưng cờ vây không có tính “đối kháng, ăn quân” rõ ràng, mục tiêu là chiếm lĩnh càng nhiều “dư địa”, tạo ra càng nhiều “không gian phát triển” càng tốt, nói theo ngôn ngữ cờ vây là tạo ra nhiều “khí” để “thở”.

Tôi rất sợ những kiểu người bám víu vào lý luận hình thức… Họ “take position, hold the line, take the side”, ngôn ngữ của họ cứ “điểm, tuyến & diện” như thế! Mọi cách diễn đạt đều tương đối, đều không chính xác hoàn toàn, dùng nó như thế nào là cả một sự cân nhắc! Phải bước qua được rào cản của ngôn ngữ thì mới hiểu được những nội dung khác truyền tải bên dưới! Nhưng không, họ bám víu vào mớ ngôn từ chết ấy, tìm cách “tranh tiên”, chiếm lấy một lợi thế nho nhỏ bằng ngôn từ, rồi mắc cứng luôn ở đó, sau đó bằng những kiểu: do đó, cho nên, vì vậy, suy ra… tìm cách chứng minh chỉ có tôi đúng và đối phương là sai! Tranh đấu với đối phương thực chất chỉ thể hiện những mâu thuẫn, lúng túng, hạn chế nội tại mà thôi, vẫn là kiểu “tôi đúng anh sai” chứ chưa phải là khai mở kiến thức!

for… loop

For…loop… ăn, ngủ, code, đạp xe, chơi với mèo… và cứ thế lặp lại! Nhàm chán, đơn điệu, nhưng cũng phải tập lại tính kỷ luật một tí! Ku Tom có chỗ nằm mới, cứ thế leo lên nằm ngủ, đôi khi lười biếng và lơ đãng nhìn xuống xem mình coding! Chút suy nghĩ về vòng “for”… theo tôi, luôn có cái gọi là “khoảng cách thế hệ – generation gap” bên trong thế giới coder, chiều sâu suy nghĩ, độ chính chắn hoàn toàn khác xa nhau! Từ xưa, như với ngôn ngữ C, người ta điều khiển “for” bằng một biến số nguyên “i”, chỉ đơn giản là như thế!

Nhiều phép toán số học có thể làm được với “i”, đây mới là điều quan trọng nhất! Thế nhưng các ngôn ngữ mới không chịu, cứ phải đẻ ra cái “for in stride”, rồi những thao tác lặp phức tạp trở nên rất khó thực hiện! Chỉ đọc spec một ngôn ngữ, ví dụ như Swift, tôi có thể hiểu được khá rõ độ sâu, độ chính chắn trong suy nghĩ của tác giả! Mấy người “chế” ra các ngôn ngữ mới này cũng chỉ là những coder bình thường như chúng ta mà thôi, chưa đạt đến tầm như của Donald Knuth, Edsger W. Dijkstra, Robert Sedgewick… ngày xưa đâu!

Planimeter

Mấy chục năm KHMT và CNTT, đôi khi tôi cảm thấy cần phải cho đi lại từ đầu, chưa đi vội về sau, đôi khi cần phải hiểu lại những điều rất rất cơ bản! Ví dụ như vẫn có nhiều người có thể đã học hết 12 năm phổ thông nhưng chưa chắc đã hiểu một “phép nhân” đơn giản!

Dưới đây là ví dụ vế Planimeter, một cái “máy” rất chi là “hấp dẫn và kích thích suy nghĩ”, máy tính “cơ học”, máy tính “analog”, dùng để tính diện tích của một hình bất kỳ, đó là thời đại trước khi máy tính, với tất cả những phần mềm CAD, CAM xuất hiện…

apps

Con đường đau khổ sẽ còn dài… cứ trậm trầy trậm trật thế này, nhiều năm không giải quyết được, cuối cùng có khi phải bỏ đi làm app khác, rồi vẫn tiếp tục lặp lại vết xe đổ như thế! Nguyên nhân từ đâu? Làm trong ngành CNTT nên em là em nói thẳng: nguyên nhân từ cấp 2, cấp 3 đọc nhưng không hiểu chữ, hoặc có hiểu nhưng hiểu không sâu, chỉ lơ mơ ngôn từ bề mặt! Lên ĐH, khái niệm cơ bản đọc mãi không thông, toán đơn giản vector, ma trận làm không được, thiết kế CSDL cũng y vậy, viết câu lệnh SELECT 3 cấp lồng nhau vô tư…

Không biết “INNER JOIN” là cái gì, làm sao tạo “VIEW”… Không nói quá đâu vì đã thấy nhiều rồi, tất cả đều quay về cơ bản mà thôi! Nên đừng trách, em mà bắt bẻ cái gì là bẻ từng từ một! Nói thì hay lắm, lúc nào cũng Trí tuệ nhân tạo, Máy học này kia, nhưng coding căn bản không làm được, sợ có khi cài đặt thuật toán QuickSort còn không được! Nên kiểu giống như học võ ngày xưa các ông thầy bắt tấn “mã bộ” suốt mấy tháng là có lý do! Vẫn phải quay về những điều căn bản nhất, mà căn bản nhất của giáo dục chính là… làm người!

PKC

Nôm na về mã hoá khoá công khai (public-key cryptography) cho nhiều người dễ hiểu, cái này chỉ cần toán cấp 2, 3 thôi! Lấy hai số nguyên tố rất lớn: p1 và p2 nhân với nhau, kết quả được một số nguyên siêu lớn: n = p1 x p2, n được gọi là khoá công khai (public key), còn bộ (p1, p2) được gọi là khoá bí mật (private key)! Như hai mặt của một đồng xu, nếu biết trước (p1, p2) thì tính ra n rất dễ (chỉ một phép nhân), nhưng ngược lại, khai triển luỹ thừa, từ n lần ngược trở lại (p1, p2) rất khó, siêu máy tính cũng có thể mất nhiều triệu năm mới giải mã được! Về bản chất toán học, vấn đề chỉ đơn giản là như thế!

Đi sâu vào sẽ có nhiều điều phức tạp hơn! Nếu anh X được cấp bộ 2 khoá, thứ nhất là khoá công khai: n, và thứ nhì là khoá bí mật: (p1, p2), anh ta sẽ bỏ cái khoá công khai n đó lên internet hay ở nơi nào đó ai cũng đọc được, và giữ bí mật cặp (p1, p2). Nếu Y muốn gởi mật thư cho X, Y sẽ mã hoá dùng khoá công khai n (của X), và thông điệp đã mã hoá đó chỉ có thể được giải bằng (p1, p2)! Điều ngược lại cũng đúng, nếu X gởi đi một thông điệp có thể giải mã thành công nhờ n, thì điều đó có nghĩa là: chắc chắn nó đã được mã hoá bằng (p1, p2), xác nhận được gởi đúng từ anh X, đây chính là xác thực chữ ký số!

Ưu điểm của mã hoá khoá công khai chính là… nó công khai, không mất công phân phối, chuyển giao “khoá” như các phương pháp khác, và khoá bí mật chỉ giữ riêng cho chủ nhân của nó! Ưu điểm cũng là khuyết điểm, cần có một tổ chức đứng ra xác thực khoá công khai này đúng là thuộc về ai đó! Ngoài ra, mã hoá khoá công khai có thể được dùng để bổ trợ cho mã hoá khoá bí mật (như cách dùng trong quân sự): dùng phương pháp công khai để truyền tải khoá bí mật, rồi dùng khoá bí mật để mã hoá / giải mã tài liệu, như thế có thể đổi khoá bí mật định kỳ một cách dễ dàng, nhanh chóng và an toàn!

Quốc phòng vẫn chuộng sử dụng các phương pháp mã hoá khoá bí mật, đơn giản vì tốc độ xử lý! Khoá công khai dùng những số nguyên cực lớn nên tính toán mất thời gian, nhất là với dữ liệu lớn như âm thanh, hình ảnh! Có người lo ngại những thế hệ máy tính lượng tử mới có thể giải các loại khoá này, điều đó là có thật, nhất là với các khoá có sẵn! Nhưng nếu ta tăng p1 & p2 lên, dùng những số nguyên tố lớn hơn, thì tính toán lượng tử cũng sẽ bó tay! Năng lực “lượng tử” dùng để phá mã cũng có thể được dùng để tìm những số nguyên tố lớn hơn, “ma cao một thước thì đạo vẫn có thể cao lên một trượng”!

chatgpt

Nhân chuyện ChatGPT và các thể loại AI xôn xao dư luận gần đây. Có nhiều cách nhận định khác nhau, đương nhiên không nên đánh giá thấp vai trò của trí tuệ nhân tạo và ứng dụng của nó, nhưng bảo máy móc có trí tuệ thì chắc chắn là không! Nói ngắn gọn thế này: sáng tạo là đặc quyền của con người (hay đúng hơn là của một số người), là khả năng đi vào những vùng chưa biết, những lỗ đen kiến thức, khai phá, lập thuyết, chứng minh, etc… Chừng nào mà AI nó chứng minh được Bổ đề cơ bản, ví dụ như thế, thì tôi mới tin là máy có trí tuệ. Còn lại, máy nó chỉ lặp lại những kiến thức thu thập được, càng ngày càng nhiều, dùng khả năng siêu tốc độ của mình để xử lý, tối ưu, và trình bày ra dưới một dạng khôn khéo mà thôi! Mấy ông già “biết tuốt” VN chắc khoái con ChatGPT này lắm, cái gì cũng biết…

Có người đưa các ví dụ AI có thể tối ưu hoá những đoạn code, rồi vẽ ra viễn cảnh máy có thể code được! Chuyện này theo tôi vẫn còn xa, xa lắm! Máy nó chỉ lặp lại một số “bài” được học thôi, vì học quá nhiều nên đôi khi còn có vẻ “giỏi” hơn cả coder – con người! Và thực ra cũng có một số coder giống như thế (giống máy): rất giỏi logic, test IQ, giỏi xử lý các “câu đố” được đưa ra, nhưng kỳ lạ thay, không code được, hoặc code nhưng không giỏi, tại sao thế? Tại vì cái anh chàng “thông minh” đó thực ra chỉ “thuộc bài”, phỏng vấn các vòng đều rất ấn tượng, và cũng đôi khi là “thông minh” thật, giỏi “làm tính, giỏi logic”! Nhưng code, hiểu theo nghĩa rộng, là đi giải một bài toán thực tế, mà giải quyết vấn đề thực tế thì đôi khi “thông minh” chưa đủ, như trên đã nói, “phát minh, sáng tạo” là đặc quyền của con người.

Việc lặp lại “như vẹt” một số kiến thức đã biết chỉ tạo ra được sự “thông minh”, hay “có vẻ thông minh”, chứ không tạo ra được “phát minh, sáng kiến”, không tìm ra hướng đi mới, cách tiếp cận đúng, tìm ra giải pháp hữu ích giữa những cái “hỗn mang, vô tri, bất định”. Cuộc đời của mỗi con người đều giống như “Miếng da lừa” (tiểu thuyết của Honoré de Balzac), có bao nhiêu sinh lực dành để nhớ những kiến thức không thực sự cần thiết, những thông tin vụn vặt cốt chỉ để “loè người” hay để theo đuổi những mục đích “bất chính, bất thiện” thì đương nhiên không còn năng lực để theo đuổi những tri thức hữu ích đích thực. Thông tin thì càng ngày càng nhiều, “Hằng hà sa số” như thế, làm sao mà nhớ hết nổi?! Chuyện học “nhồi nhét kiến thức” đã nói rồi, chuyện “trọc phú tri thức” cũng bàn rồi…

Nhưng tiếc thay, lại sa đà vào mớ trừu tượng “kiến thức nguyên bản” một cách vô bổ, không đưa ra được kết luận gì hữu ích. Nhưng không ai nói cho rõ “kiến thức thật sự, kiến thức có thể sáng tạo” nó là như thế nào, bắt nguồn từ đâu, làm sao để có. Tôi cũng không hiểu lắm, nhưng cho rằng nó liên quan mật thiết đến cảm hứng sống, đến động cơ, mục đích của con người, đến sự can đảm đối diện với bản thân, và có lẽ là, từ trong sâu thẳm, liên quan đến bản chất “hướng thiện” của mỗi người! Trở lại chuyện ứng dụng ChatGPT, chuyện chẳng có gì to tát, các bác cứ làm quá lên! Chỉ là một cỗ máy thuộc bài, lặp lại như vẹt mà thôi! Nói cho đúng là một phần lớn báo chí và cư dân MXH VN về dân trí cũng cỡ đó, như cái thùng rỗng vọng lại những thứ người ta dội vào, viết tiếng Việt thì trúc trắc đọc không được…

Dịch tiếng Anh thì ngô nghê, tối nghĩa, trình ngôn ngữ e là chưa bằng máy! Và chính vì dân trí đang là như thế… nên ChatGPT rồi cũng là công cụ như Wikipedia mà thôi, ý tôi tức là một công cụ… nô dịch tư tưởng! Ví như đám lưu manh trên mạng, mỗi lần có tranh cãi gì là chăm chăm đi sửa Wiki theo hướng có lợi cho mình! Không thể phủ nhận Wiki cũng là nguồn thông tin hữu ích, nhưng nó cũng chỉ là “cái chợ” của con người, có đủ thứ “thượng vàng hạ cám” ở trên đó. ChatGPT rồi cũng sẽ được dùng như một công cụ “nô dịch tư tưởng”, dùng cho những loại óc “bã đậu”, chuyển giao “thông tin” dưới dạng “mì ăn liền”, cái “thông tin” đó được nguỵ trang là “kiến thức”, “tri thức”, là “chân lý”. Nếu có sợ là sợ cho những thành phần dân trí quá thấp, nói gì cũng nghe, chứ ai lại đi sợ cái máy!?

Ai cũng biết, sự học thuộc lòng (dù nhồi nhét) chính là điểm khởi đầu của giáo dục, trẻ con đâu có biết gì nên cứ phải ép nó học thuộc một số “nguyên liệu thô” ban đầu, kiểu như: Nhân chi sơ, tính bản thiện, tính tương cận… ChatGPT, tôi xem như đứa trẻ 3, 4 tuổi, bắt đầu bi bô những kiến thức đầu tiên. Và kệ mịa nó nói gì, lớn lên rồi thì nhiều người sẽ dễ dàng đồng ý là: Nhân chi sơ, tính bản ác! Trở lại với ChatGPT, tôi vẫn xem nó là “con vẹt” học tiếng người, thấy con chuột đến giả tiếng mèo để đuổi chuột đi, thấy con mèo tới giả tiếng người nạt nộ để đuổi mèo đi. Nếu là vẹt thì người ta kêu là nó thông minh, nhưng nếu là người, mà suốt ngày lặp lại mãi một số ngôn từ vay mượn, máy móc, vô nghĩa, chả có tí nội hàm, nội tâm nào, cứ mãi “giả tiếng”… thì người ta kêu bằng: “thiểu năng trí tuệ”.

jacquard loom

Lâu về trước có viết bài nói về công nghiệp dệt may đã là động cơ chủ yếu của Cách mạng Công nghiệp Anh như thế nào, góp phần hình thành nên một xã hội bắt đầu có nhu cầu tiêu dùng, mà tiêu dùng đầu tiên là ăn mặc đẹp đẽ, sang trọng. Nhưng đôi khi nhìn lại, ta sẽ thấy sự phát triển kỳ diệu của các ngành công nghệ khác nhau như những tấm gương lấp lánh phản chiếu lẫn nhau nhiều cấp! Dưới đây nói về sự phát triển của ngành dệt đã góp phần tạo ra công nghệ thông tin hiện đại như thế nào! Trung Quốc phát minh ra các kiểu dệt gấm, Trung Đông có những kiểu dệt thảm rất đẹp! Để tạo ra những hoa văn đầy sắc màu đó, đơn giản là điều chỉnh cách thức các sợi vải ngang, dọc, chéo đan xen vào nhau! Đến năm 1804, thương gia Pháp Joseph Marie Jacquard phát minh ra cái máy dệt mang tên mình!

Nhìn từ trên xuống, có thể hình dung tấm gấm như một ma trận điểm (dot matrix), mà ‘on’ hay ‘off’ là trạng thái nổi hay chìm của các sợi vải đan xen vào nhau! Joseph Jacquard đã dùng các bìa giấy đục lỗ (punched card) để mã hoá các thông tin hoa văn này, cho phép dệt ra những kiểu hoa văn tuỳ ý! Đây xem như là máy dùng bìa đục lỗ đầu tiên, chỉ cần thay một băng giấy khác là có thể dệt ra được kiểu hoa văn tương ứng! Bìa đục lỗ được sử dụng như cách mã hoá đầu vào – input, rồi sau đó được sử dụng để mã hoá đầu ra – output! Đến năm 1888 thì Herman Hollerith người Mỹ sử dụng bìa đục lỗ tương tự để làm ra máy thống kê sử dụng để điều tra dân số, máy chạy nhanh hơn 10 lần so với người tính toán thủ công! Tiền thân của các loại máy tính hiện đại đã ra đời… từ nghề dệt như thế!

games

Thực ra viết con game để chơi là phụ, chính yếu vẫn là muốn thử nghiệm các kỹ thuật khác nhau với “lambda function – anonymous function – hàm không tên”!

Tự viết con game Solitaire này mấy năm trước, nhưng lười, không bỏ lên AppStore. Game mà tôi tự viết để tự chơi thì cũng khá nhiều, viết vì kiếm không được game tương tự đúng ý, cái thì quảng cáo quá nhiều, cái thì đồ hoạ quá xấu, cái thì nặng nề, tốc độ quá chậm, chạy không mượt, mà tôi chơi Solitaire, mấy ngón tay bấm liên hồi như đánh piano vậy! Trò Solitaire chuẩn chơi trên máy Windows tối đa chỉ 24K điểm, nhưng cầm cái iPad mà chơi thì trên 30K điểm là chuyện thường! Game này viết chỉ một source code, chạy trên tất cả các nền Apple (Mac, iPhone, iPad…), làm cái engine sẵn, đọc game rules từ file lên, hiện tại hỗ trợ đến 99 biến thể (variant) Solitaire khác nhau!

Nhớ lại đợt Sài Gòn giãn cách XH vì Covid-19, suốt ngày chỉ có chơi game giải trí, hoặc làm mộc, cưa bào, đục đẽo để vận động tay chân! Nói về chơi game, căn bản đó không phải là chuyện gì xấu, nhưng tôi thường chỉ chơi game logic đơn giản, mỗi ngày chơi 15 ~ 30 phút tối đa, không chơi các game có kịch bản hay những game mất quá nhiều thời gian! Tác hại của game đối với giới trẻ không cần phải nói, nhưng lỗi không nằm ở game, lỗi ở xã hội và giáo dục, tạo ra cho chúng nó một môi trường nghèo nàn, một tâm hồn trống rỗng, như cái lỗ đen sâu hoắm, nên ngoài những thứ vớ vẩn, nhảm nhí ra, chúng nó không còn biết điều gì khác, riết rồi thành thần kinh, bệnh hoạn và tệ nạn!

toán

Nối tiếp post trước, minh hoạ bằng một screenshot – chụp màn hình. Đến tận bây giờ vẫn xài khá nhiều toán, không phải là Toán cao cấp (vi phân, tích phân, đạo hàm, xác suất thống kê, etc…) mà chủ yếu là Toán rời rạc (discrete mathematics) và Thuật toán, thuật giải, thêm một chút Hình, Số và Xác suất thống kê… Chính là vì mấy cái này nên code vẫn còn có vài niềm vui, ngoài những chuyện debug phức tạp, nhức đầu và vô số những công việc… trâu bò khác!

Ở một góc nhìn khác, có thể… nhìn code đoán tuổi! Những người viết mã thành khối 80 cột như tôi có nguyên nhân sâu xa từ cái thời còn trên x86 và DOS, lúc đó màn hình text có kích thước 16 (dòng) x 80 (cột), còn màn hình thời bây giờ viết đến 160 cột có khi vẫn chưa xuống hàng! Đến tận giờ tôi vẫn cho rằng bắt đầu từ tầng thấp – low level là một điều nên làm, phần lớn coder bây giờ cái gì cũng biết, công nghệ nào cũng rành, chỉ một điều là không… rành code!

The fallacy of high-level programming

For the last 5 years or so, I’ve stopped writing on technical subjects on this blog. But that doesn’t mean I stop writing completely, in fact, I keep on writing a lot, but keep them to myself instead of posting out. For reasons too numerous to tell, or to be short, just because I’m lazy. Software engineering is a still a relatively – young industry, hence, naivety, untruthfulness, deceptions, myths, lies, and dogmas are… countless. In that environment, writings could be controversial and misleading, so I choose to note down my ideas in private.

I started with Turbo-C on DOS, then move on to different dialects of the C language: Watcom C, Borland C++, C++, glibC, Obj-C… For me, the most important thing in programming is… crashes. It crashes right away to tell you that you’ve done something wrong! It crashes when you access a null pointer, it crashes when you use an API the wrong way, it crashes when you allocate an infeasible amount of memory, it crashes when you access a dangling pointer referencing to an object which has gone out of scope, just because you can’t track on the life-cycle of that object. It doesn’t even throw an exception and try going on until the situation is unmanageable. Simply put, there’s NO exception, you’re punished immediately, as soon as you’ve done something wrong!

I strongly advocate the use of ARC for memory management, in fact, I would call it the most brilliant feature of the Obj-C language for the last 25 years or so, ARC makes life much more easier. But I also advocate the use of crashes as a “graceful” way to tell that you’ve done something wrong with the deallocated blocks. It crashes right away when you allocate an unbearable amount of memory so that you would know that your algorithms and data – structures are not efficient enough, and you will need to improve, to do tuning, optimization! For me, modern languages are good and friendly, the down side is that it’s also too friendly to the developers, without punishments, how can the devs’ skills could be improved!

Thus, by the interacting between you – the coder and the computer & compiler combination, the reward – punishment model will help greatly boost the devs’ skills over time, and help producing good code. There’re huge differences between an experienced programmer who write good code, and foresee possibilities of bugs, and a novice one who only try to make it… just run. I really want to emphasize here, that the “reward – punishment” model of programming is what made a good programmer! Also by learning to handle memory problems by yourself give you opportunities to follow and understand the life cycles of objects, of memory blocks, understand the precise flows of code, understand the cost-and-benefits of each coding approaches.