Coders được quản lý so với Coders bản địa

Tôi là một lập trình viên và có kinh nghiệm với cả mã gốc và mã được quản lý. Tôi bắt đầu với Pascal và C, sau đó chuyển sang C ++ và cuối cùng thành C #.

Trong khoảng một năm qua, tôi đã mã hóa gần như độc quyền trong C # và đã mất rất nhiều thứ đã từng xuất hiện một cách tự nhiên khi tôi là một lập trình viên C ++.

Vài tuần trước khi tôi ngồi viết một số mã C ++ bản địa, tôi thấy mình lóng ngóng khi dần dần làm quen với sự phức tạp, kỳ quặc và sự bình dị của tất cả. Tôi gần như lúng túng khi nói rằng tôi đã hoàn toàn quên rằng việc truyền một mảng được phân bổ động cho một hàm mà không vượt qua kích thước của nó có nghĩa là hàm nhận sẽ không có cách nào để biết mảng đó dài bao nhiêu.

Có vô số bài báo và tài liệu so sánh và đối chiếu được quản lý so với mã không được quản lý. Chúng ta đều biết rằng mã gốc, nếu được tối ưu hóa tốt, có thể chạy nhanh hơn và nhẹ hơn đáng kể so với mã được quản lý. Mặt khác, mã được quản lý có bộ thu gom rác và tối ưu hóa cụ thể cho CPU và hệ điều hành thời gian chạy, có thể giúp mã gốc chạy được tiền của nó.

Hoàn toàn từ góc độ kỹ thuật, không có người chiến thắng rõ ràng.

Không có nghi ngờ rằng mã được quản lý là các đơn đặt hàng có cường độ đơn giản hơn để mã hóa và hiểu. Chỉ cần nhìn vào sự khác biệt về số lượng dòng cần thiết để xây dựng GUI đơn giản trong Win32 C ++ so với C #.

Quay trở lại những ngày mã hóa bản địa của tôi, tôi chủ yếu viết các mô phỏng toán học chạy trên siêu máy tính. Họ có CLI xấu xí và chủ yếu tập trung vào thuật toán. Ngày nay tôi viết bằng C # và tạo ra các ứng dụng GUI đẹp mắt, nhưng sẽ bị mất nếu tôi phải tạo ra một thứ gì đó có tầm cỡ tương tự trên ngôn ngữ bản địa. Ngay cả với một khung như QT, vẫn sẽ mất gấp đôi thời gian để tạo ra thứ gì đó trong C ++ / QT so với C #.

Bất cứ khi nào tôi thấy ai đó đã viết một ứng dụng GUI có quy mô lớn, đầy đủ tính năng trong C / C ++, tôi không thể không cảm thấy sợ hãi và một chút ghen tị.

Tôi tò mò làm thế nào các lập trình viên có kinh nghiệm khác nhìn thấy các ngôn ngữ được quản lý và không được quản lý. Bạn có thấy mã được quản lý là nghiệp dư không? Bạn có thấy lập trình bản địa như nhiều Hardcore ?

Công việc hàng ngày của tôi hiện đang ở C ++, nhưng tôi đã lập trình bằng một số ngôn ngữ đủ lâu mà tôi hầu như không nhận thấy sự khác biệt nữa. Dưới đây là những quan sát của tôi:

• Rất nhiều sự thiếu hiệu quả được cho là với các ngôn ngữ khác thường được các lập trình viên C ++ thực hiện lại như là cách thực hành tốt nhất. Chúng tôi thêm đủ kiểm tra null, kiểm tra giới hạn mảng, kiểm tra kiểu, xác thực đầu vào, v.v. để phủ nhận phần lớn bất kỳ lợi thế tốc độ thực hiện nào mà ngôn ngữ không tự động làm những việc đó, ít nhất là đối với mã không xử lý dữ liệu chuyên sâu.
• Sau đó, nồi hơi thêm đó trở thành một thói quen ăn sâu, do đó nó không thực sự cảm thấy như là một công việc làm thêm, và thò ra như ngón tay cái đau khi mất tích.
• Khi tôi lập trình bằng ngôn ngữ "được quản lý", tôi vẫn nghĩ về việc cấp phát bộ nhớ, để đảm bảo rằng tôi không tạo ra rò rỉ bộ nhớ. Tôi có thể không nói rõ ràng delete, nhưng tôi vẫn nhận thức được trong suy nghĩ của mình về điểm mà người thu gom rác coi nó đủ điều kiện để xóa. Tôi gặp khó khăn hơn trong việc giải quyết các vấn đề bộ nhớ thấp bắt đầu bằng Java so với trước đây tôi từng làm trong C ++, có lẽ vì trong C ++, chúng khó bỏ qua hơn rất lâu.
• Tương tự với kiểu gõ động. Tôi vẫn phải theo dõi trong đầu xem tham số hàm là một mảng, hay int hay chuỗi. Trên thực tế, nó đòi hỏi nhiều nỗ lực tinh thần hơn vì loại hình này không được liệt kê rõ ràng ngay tại đó đối với tôi.
• Phong cách C ++ hiện đại rất khác so với thời kỳ tiền C #. Thay vì thay đổi ngôn ngữ, mọi người "khám phá" cách sử dụng các tính năng C ++ hiện có theo những cách độc đáo để tránh phần lớn việc quản lý bộ nhớ của người đàn ông trong quá khứ. Các mẫu thiết kế mà bộ nhớ miễn phí tự động rất phổ biến hiện nay.
• Theo như tôi biết, mặc dù có thể tạo các ứng dụng GUI chỉ bằng cách viết mã, các nhà thiết kế đồ họa như nhà thiết kế QT là phương pháp được ưa thích rộng rãi, với mã chủ yếu chỉ được sử dụng cho trình xử lý sự kiện hoặc tùy chỉnh thời gian chạy.
• Các ngôn ngữ bạn đã không sử dụng rộng rãi trong một thời gian luôn cảm thấy hơi vụng về, ngay cả khi bạn chủ yếu nhớ cú pháp. Nếu tôi không viết python trong một năm, có rất nhiều điều bình dị mà tôi đã quên, và nó cảm thấy khó xử hơn C ++ trong một thời gian, mặc dù hầu hết mọi người đều coi python là ngôn ngữ "dễ dàng" hơn.

Với sự kết hợp của tất cả các yếu tố đó, mô hình tinh thần của tôi khá nhất quán giữa khi tôi lập trình bằng C ++ và các ngôn ngữ khác, và sự khác biệt cảm thấy chủ yếu chỉ là cú pháp. Cấp, rất nhiều trong số đó là kết quả của đào tạo, thói quen, tiêu chuẩn mã hóa và các mẫu thiết kế hiện đại thay vì các tính năng nội tại của chính ngôn ngữ C ++, nhưng sự so sánh vẫn còn tồn tại.

Tôi đoán điều tôi đang cố nói là theo kinh nghiệm của tôi, việc đào tạo lập trình viên tạo ra nhiều sự khác biệt hơn so với ngôn ngữ mà anh ta đang sử dụng.

Bạn có thấy mã được quản lý là nghiệp dư không? Bạn có thấy lập trình viên bản địa càng khó tính không?

Không.

Tôi thấy sự khác biệt giữa một kỹ sư và lập trình viên. Các Hardcore kỹ sư sẽ luôn chọn chồng ngôn ngữ / công nghệ đó là thích hợp để hoàn thành công việc trong thời gian ít nhất tại một tiêu chuẩn thời gian chạy có thể chấp nhận.

Với sức mạnh của bộ xử lý ngày nay, tần suất thực sự cần phải lấy càng nhiều càng tốt từ máy bằng cách sử dụng mức thấp hơn, ngôn ngữ bản địa ngày càng ít đi. Thường thì thực sự không phải là một trường hợp kinh doanh cho nó. Năng suất sẽ luôn tạo ra sự khác biệt vài mili giây trong thời gian thực hiện.

Đáng buồn thay, Microsoft đã dẫn chúng tôi kết hợp "Mã được quản lý" với các thư viện lớp C # /. Net.

Có hai thứ riêng biệt và gần như không liên quan khi chơi ở đây.

1. Thư viện .Net mát mẻ.

2. Mã được quản lý.

C # cung cấp cả hai trong một gói gọn gàng, được hỗ trợ, dễ sử dụng cho một mức giá.

C ++ có rất nhiều thư viện thú vị làm hầu hết mọi thứ .Net. Thay vì đổ lỗi cho mã "C ++ bản địa" có nhiều "phức tạp, quirks và idiosyncrasies" hơn mã C # /. Net, bạn có thể tìm kiếm các thư viện C ++ tốt hơn.

Thư viện tốt hơn cho phép bạn viết mã C ++ đẹp.

Bất cứ khi nào tôi thấy ai đó đã viết một ứng dụng GUI có quy mô lớn, đầy đủ tính năng trong C / C ++, tôi không thể không cảm thấy sợ hãi và một chút ghen tị

Chính sách tồi. Thay vào đó, bạn nên tìm hiểu những thư viện định nghĩa lớp mà họ đã sử dụng. Bạn cũng có thể sử dụng các thư viện đó.

Đó là tất cả về các công cụ. Không có công cụ, chúng ta chỉ là động vật trong quần.

"C ++ bản địa" không có nghĩa là bạn nên vứt bỏ tất cả các công cụ của mình. Nó có nghĩa là bạn phải tìm công cụ tốt. Microsoft không còn giúp bạn nữa, vì vậy bạn cần dành thời gian để tìm ra công cụ kết hợp phù hợp.

Vấn đề ở đây không phải là về lập trình khó hay bất cứ điều gì tương tự, đó là về kiểm soát. Thực tế là C # cung cấp năng suất với chi phí kiểm soát. Nếu bạn đang viết một chương trình cần số lượng điều khiển cao (bộ nhớ này được giải quyết chính xác ngay bây giờ), thì bạn không có lựa chọn nào khác ngoài sử dụng C ++. Nếu bạn cần hoàn thành nhanh chóng, thì bạn có thể cần sử dụng C #. Vấn đề là các thư viện hỗ trợ cho C # tốt hơn và gần đây hơn nhiều so với cung cấp cho C ++. Ví dụ, MFC rất, rất cũ và thực tiễn của nó được biết đến là khủng khiếp, nó chủ yếu được viết từ lâu trước khi Tiêu chuẩn hóa. Ví dụ, nếu Microsoft nỗ lực cung cấp các thư viện C ++ mới, hãy kiểm tra PPL mới trong Visual Studio 2010, thì thật kỳ lạ, nhiệm vụ đó trở nên dễ dàng trong C ++. Và tôi nghĩ rằng họ đang di chuyển theo cách đó,

Mặt khác, mã được quản lý có các trình thu gom rác và tối ưu hóa cụ thể cho CPU và hệ điều hành trong thời gian chạy, có thể giúp mã gốc chạy theo tiền của nó.

Tôi đã nghe nhiều người đề xướng ngôn ngữ được quản lý nói điều này, nhưng tôi gần như chưa bao giờ thấy nó là sự thật. Thực tế là các hướng dẫn CPU mới có sẵn trong các CPU mới hơn đơn giản là không mang lại nhiều lợi thế trừ khi bạn đang làm toán rất khó, trong trường hợp đó bạn không đủ khả năng để biên dịch hoặc giải thích nó khi chạy -time và bạn chỉ có thể sử dụng trình biên dịch C ++ của Intel để sử dụng SSE mới nhất và tốt nhất trong mọi trường hợp. Phạm vi tối ưu hóa trình biên dịch của C ++ là rất lớn so với những gì JIT có thể làm, bởi vì JIT phải thực thi trong một phần nhỏ thời gian trong khi chương trình đang chạy, trong khi trình biên dịch C ++ là huyền thoại để dành thời gian ngọt ngào để biên dịch.

Bộ sưu tập rác không phải là một thứ kỳ diệu hay đại loại như thế - đó là một sự lựa chọn thuật toán. Có phù hợp với mọi tình huống không? Không phải là nhìn xa vào mớ hỗn độn IDis trong C # và cách Java thậm chí không bận tâm đến vấn đề đó, trong khi đó, các hàm hủy của C ++ sẽ đóng các tệp của bạn và giải phóng bộ nhớ của bạn và đóng ổ cắm của bạn, v.v. , và không cho một số người khác.

Theo ý kiến ​​của tôi, C / C ++ bản địa, so với C #, trông giống như trình biên dịch với chính C / C ++. Một lớp trừu tượng phức tạp khác (không hoàn toàn đúng, nhưng hãy nói như vậy) như mọi khi, giúp bạn phát triển dễ dàng hơn, nhưng giảm một số tốc độ và sử dụng bộ nhớ quá mức. Vì vậy, như tôi thấy, nó chỉ phân chia thành các loại khác nhau, do đó tạo ra các kiểu con mới của lập trình viên.

Btw cho mức độ trừu tượng của C # là cực kỳ nhanh, microsoft đã làm một công việc tuyệt vời.

Có những lập trình viên nghiệp dư, không phải ngôn ngữ nghiệp dư. Ngôn ngữ họ có tất cả (tốt, hầu hết trong số họ ít nhất) mục đích của họ.

Tôi hiện đang hợp tác trên một công cụ tính toán bảo hiểm được sử dụng để kiểm tra hệ thống sản xuất. Hệ thống sản xuất đã được tạo ra bằng C, công cụ của chúng tôi được thực hiện bằng Java và vì thời gian dài hơn chúng tôi vượt trội hơn công cụ C, đồng thời có năng suất cao hơn nhiều. Không phải vì Java per se nhanh hơn C, nó chỉ đủ nhanh và thuật toán của chúng tôi tốt hơn, chúng tôi đã triển khai chúng dễ dàng hơn, chúng tôi có thể kiểm tra và tái cấu trúc mã nhanh hơn và tốt hơn.

Tôi cũng đã viết mã thử nghiệm để so sánh kết quả tính toán với nội dung của cơ sở dữ liệu sản xuất: không phải bằng C, không phải ở Java mà là ở Ruby. Một lần nữa, nó đủ nhanh và cần ít mã hơn nên dễ thực hiện hơn, dễ kiểm tra hơn, dễ mở rộng hơn.

Và tôi không cảm thấy nghiệp dư cho dù tôi sử dụng ngôn ngữ nào, tôi chỉ cảm thấy như vậy nếu tôi tạo ra một lỗi ngu ngốc không nên xảy ra.

Năm ngoái, công ty tôi làm việc đã thiết kế ngược mã CRC truyền thông bằng vũ lực (cuối cùng chúng tôi đã nhận được). 3 Nhà phát triển từng có phiên bản riêng, Borland C, C # .Net 2008, VB6. VB6 rõ ràng là chậm, Borland C rất nhanh nhưng C # .net chỉ tăng tốc gấp 12 lần tốc độ. Không phải là những gì chúng ta mong đợi ở tất cả.

Nó phụ thuộc vào sự pha trộn của nhiều thứ, nhưng về cơ bản, tất cả những thứ khác đều bằng nhau, vâng, mã gốc là "khó tính" hơn mã được quản lý.

Tôi đoán đó thường là một điều tồi tệ đối với một ứng dụng kinh doanh thông thường, bởi vì điều đó có nghĩa là nhà phát triển trung bình phải đặt nhiều năng lượng tinh thần hơn vào các khía cạnh phi kinh doanh trong mã của họ.

Chương trình của tôi là những gì có thể được mô tả tốt nhất là C ++ như Java. Ý kiến ​​của tôi là bạn có thể đạt được cùng một chương trình cấp thấp trong Java, nhưng nó khó hơn nhiều so với lập trình cấp thấp trong C ++. Tuy nhiên, bạn thường cần lập trình cấp thấp này trong một phần nhỏ mã của bạn và ở nơi không yêu cầu ngôn ngữ được quản lý sẽ hiệu quả hơn.

Các nhà phát triển bản địa thường nổi tiếng là khó tính hơn bởi vì họ cảm thấy khó tính hơn và hành động theo cách đó. Các nhà phát triển bản địa được đào tạo trong một hệ thống không chấp nhận bất kỳ sai lầm nào vì chúng chắc chắn sẽ dẫn đến các sự cố cứng hoặc rò rỉ bộ nhớ không giới hạn. Đặc biệt, .NET cho phép các bản hack lười biếng như đặt thử / bắt xung quanh mọi thứ, giúp nhà phát triển không nghĩ rằng họ phải hiểu vấn đề cốt lõi (" đôi khi, nó chỉ ném UnlimitedOperationException. Tôi không thể giải thích, hãy bắt mọi thứ. mã là rất quan trọng! "). Đây hoàn toàn không phải là màu đen và trắng, nhưng những quan sát của tôi đã lớn lên trong thế giới không được quản lý và hiện đang làm việc trong toàn bộ mã được quản lý.

Ngoài ra, các nhà phát triển được quản lý cũng có xu hướng truy cập vào BCL sạch hơn và có tổ chức hơn. Điều này thường khuyến khích họ khám phá những gì thực sự xảy ra dưới vỏ bọc. Thật vậy, điều tương tự cũng có thể được nói, STL hoặc Boost, nhưng thư viện lớp .NET thường đủ tốt để khiến chúng ta lười biếng về mặt trí tuệ đôi khi.

Điều đó nói rằng, viết một chương trình quản lý tốt, có thể shippable mất rất nhiều công việc. Điều đó có nghĩa là thực hiện cấu hình bộ nhớ và CPU, kiểm tra đơn vị và phân tích mã theo những cách tương tự mà các nhà phát triển không được quản lý thực hiện. Các nhà phát triển không được quản lý có xu hướng hiểu điều này và các nhà phát triển được quản lý có xu hướng bao gồm nhiều hơn những người không tham gia.

Một lần nữa, không phải là màu đen và trắng. Có rất nhiều nhà phát triển lười biếng không có trí tuệ và các nhà phát triển được quản lý khó tính. Không phải theo định nghĩa là ưu tú hơn so với khác.

Bạn có thấy mã được quản lý là nghiệp dư không? Bạn có thấy lập trình viên bản địa càng khó tính không?

Có một khoảng cách giữa hai thế giới và tôi không thể hiểu tại sao: các hệ thống được quản lý ở đâu đó được viết bằng mã gốc (cuối cùng, mọi thứ đều chạy "trong lắp ráp"). Những gì tôi muốn thấy (nhưng trong cuộc sống của tôi) là một hệ thống xây dựng ứng dụng, trong đó tất cả các nhiệm vụ phụ của ứng dụng sẽ được viết theo đúng loại ngôn ngữ.

Mã bản địa trở nên dễ dàng hơn kể từ khi Go được phát hành. Tôi thấy nó dễ đọc và viết hơn cả Java và C #. Mặc dù lập trình GUI với Go, như bây giờ, không được tốt lắm (tôi đã xem nhanh các tùy chọn).
Cố gắng không đánh giá nó vì nó thiếu cộng đồng lớn và nhiều thư viện so với C # (ví dụ), vì nó vẫn được coi là mới.