Có quá phụ thuộc vào các công cụ ngụ ý rằng bạn lười biếng? [đóng cửa]

Tôi bắt đầu lập trình trong C ++ tại uni và yêu thích nó. Trong nhiệm kỳ tiếp theo, chúng tôi đã đổi thành VB6 và tôi ghét nó.

Tôi không thể biết chuyện gì đang xảy ra, bạn kéo một nút vào biểu mẫu và ide viết mã cho bạn.

Mặc dù tôi ghét cách VB hoạt động nhưng tôi không thể tranh luận rằng nó nhanh hơn và dễ dàng hơn so với làm điều tương tự trong C ++ để tôi có thể hiểu tại sao nó là ngôn ngữ phổ biến.

Bây giờ tôi không gọi các nhà phát triển VB lười biếng khi chỉ nói nó dễ hơn C ++ và tôi đã nhận thấy rằng rất nhiều ngôn ngữ mới hơn đang theo xu hướng này như C #.

Điều này khiến tôi nghĩ rằng khi nhiều doanh nghiệp muốn có kết quả nhanh chóng, nhiều người sẽ lập trình như thế này và sớm hay muộn sẽ không có thứ gọi là lập trình bây giờ. Các lập trình viên trong tương lai sẽ nói với máy tính những gì họ muốn và trình biên dịch sẽ viết chương trình cho họ như trong trek star.

Đây chỉ là một ý kiến ​​dưới sự hiểu biết của một lập trình viên cơ sở hay là các lập trình viên ngày càng lười biếng và kém năng lực hơn?

EDIT: Rất nhiều câu trả lời cho biết tại sao lại phát minh ra bánh xe và tôi đồng ý với điều này nhưng khi có sẵn bánh xe, mọi người không bận tâm tìm hiểu cách chế tạo bánh xe. Tôi có thể google làm thế nào để thực hiện khá nhiều thứ trong bất kỳ ngôn ngữ nào và một nửa ngôn ngữ làm rất nhiều cho bạn khi nói đến việc gỡ lỗi, họ không biết mã nào làm gì để sửa lỗi.

Đó là cách tôi đưa ra giả thuyết rằng các lập trình viên đang trở nên lười biếng hơn và kém năng lực hơn vì không ai quan tâm đến việc công cụ hoạt động như thế nào cho đến khi nó không hoạt động.

Không, các nhà phát triển đã không lười biếng hoặc kém năng lực hơn. Vâng, có một nhu cầu giảm dần để phát triển thực tế, theo nghĩa là bạn biết điều đó. Và vâng, điều này là rất nhiều bởi vì các doanh nghiệp muốn có kết quả nhanh chóng, và tại sao họ không nên?

Tuy nhiên, có một điểm cuối. Sẽ luôn có một nhu cầu cho một số nhà phát triển.

Rất nhiều yêu cầu giống nhau trên các dự án khác nhau. Cái bạn đang nói đến là mã UI. Hầu hết các UI được tạo thành từ một tập hợp các trường cụ thể - hộp văn bản, hộp kiểm, radio, chọn, v.v. - và thực sự không có điểm nào trong việc phát triển chúng từ đầu, lặp đi lặp lại. Vì vậy, các lớp trừu tượng được đưa vào để lấy đi tất cả các mã soạn sẵn đó.

Tương tự như vậy, lớp dữ liệu, thường không có gì ngoài Chèn cái này, Xóa cái này, Thay thế cái này và một số lượng lớn các khung nhìn khác nhau của cùng một dữ liệu. Tại sao cứ viết đi viết lại? Hãy phát minh ra các ORM.

Điều duy nhất bạn nên phát triển là mã duy nhất cho doanh nghiệp bạn đang phát triển.

Nhưng sẽ luôn có sự độc đáo đó - nơi không có, có cơ hội kinh doanh - và sẽ luôn có nhu cầu mọi người viết mã.

Tất cả những gì đã nói, cũng nhớ rằng có rất nhiều thứ để trở thành một nhà phát triển hơn là viết mã. Cho dù bạn đang mã hóa lắp ráp thuần túy hoặc kết hợp các thành phần Drupal để tạo ra một trang web hướng nội dung, bạn đang chuyển nhu cầu kinh doanh sang thứ gì đó mà máy tính hiểu được.

Phần quan trọng nhất của việc trở thành một nhà phát triển phần mềm là có thể hiểu rõ yêu cầu kinh doanh đủ để giải thích nó với máy tính.

Việc bạn sử dụng ngôn ngữ nào để giải thích mọi thứ với máy tính không thực sự quan trọng, nó chỉ là vấn đề mà bạn có thể. Và đây là công việc khó khăn, không có gì lười biếng về nó.

Là một thợ cơ khí lười biếng và kém năng lực bởi vì anh ta đang sử dụng một cờ lê thủy lực ?

Hình ảnh hai anh chàng, hãy nói Brad và Pete. Cả hai đều làm việc trong hai gara thay lốp hàng ngày. Brad là một chàng trai thông minh, anh ta biết rằng sử dụng các công cụ tốt hơn có thể hoàn thành công việc của mình tốt hơn và nhanh hơn. Sử dụng cờ lê thủy lực giúp anh ta thay lốp nhiều hơn. Khách hàng đang chờ đợi trong một hàng đợi ngắn hơn - mọi người đều vui vẻ. Bard cũng biết rằng cờ lê này đôi khi quá lớn và nó không thể giúp anh ta với các loại ốc vít khác nhau.

Mặt khác, Pete nói rằng cờ lê thủy lực là lộng ngôn và Brad không phải là một "thợ máy thực sự". Chắc chắn Pete chỉ có thể làm một nửa những gì Brad làm, nhưng anh ấy làm điều đó một cách "đúng đắn".

Bây giờ bạn nghĩ gì, khách hàng sẽ chọn nhà để xe nào? Một mất 20 phút hoặc một với 40 phút chờ đợi.

Nó khá giống với lập trình. C ++ là một ngôn ngữ tốt và có mục đích của nó (chủ yếu là hiệu suất). Điều tôi thích ở các ngôn ngữ như C # là tôi có thể tập trung vào một vấn đề, suy nghĩ về thuật toán mà không có tiếng ồn mà C ++ không thích cảnh báo trình biên dịch mơ hồ, hành vi không xác định et cetera. Việc phát triển ngày càng phức tạp hơn khi ngày xưa máy tính lớn và PC đầu tiên, nhưng bộ não con người vẫn giữ nguyên - khá nhiều điều ngớ ngẩn. Một ứng dụng có thể chạy trên đám mây, di động, máy tính để bàn có rất nhiều phụ thuộc, vấn đề bảo mật và các vấn đề khác. Tôi muốn có một công cụ tốt hơn để tập trung vào các vấn đề phức tạp hơn và giải quyết chúng.

Sử dụng các công cụ tốt hơn để hoàn thành công việc - không có gì sai với điều đó.

Vì vậy, những gì chúng ta gọi là lập trình bây giờ

Bạn nói:

Các lập trình viên trong tương lai sẽ nói với máy tính những gì họ muốn và trình biên dịch sẽ viết chương trình cho họ như trong trek star.

chỉ cần thực hiện một thử nghiệm: xem ngôi sao trek và cố gắng diễn giải những điều mà máy tính được yêu cầu để làm một chút 'vô duyên'.

• Trà, bá tước xám, nóng -> nhiều hơi nước.
• Trà, màu xám bá tước, 60 độ C -> vũng nước và đám mây hơi nước
• bá tước màu xám, 60 độ c -> một vũng nước
• bá tước màu xám, 60 độ C, trong một cốc -> một cốc có một giọt trong đó
• bá tước màu xám, 60 độ c, 0,2 lít, trong một cốc. -> cuối cùng (ok, bạn có thể nitt nhiều hơn)

Khi bạn gọi Lập trình: 'Biết về việc sử dụng Bộ nhớ, con trỏ, v.v.', vâng, tôi đoán điều đó sẽ trở nên ít quan trọng hơn (như 'Biết về http, openid, unicode' sẽ trở nên quan trọng hơn).

Nhưng, theo tôi, tất cả chỉ là 'sự phức tạp tình cờ', và công việc thực sự của lập trình viên là 'Tạo ra các cỗ máy xây dựng giải quyết các vấn đề, bằng cách đảm bảo một người hiểu đủ các vấn đề tình cờ để đạt được nhiệm vụ', và theo định nghĩa đó, ai đó đang nói chuyện với một ngôi sao máy tính trek cần phải là một lập trình viên (tức là có những đức tính giống như bây giờ).

Các lập trình viên không được lười biếng hơn. Lập trình viên luôn lười biếng. Lười biếng là một phần của bản chất cơ bản của công việc. Vấn đề là mọi người cho rằng lười biếng là một tiêu cực. Trở thành một lập trình viên "lười biếng" là một đức tính tốt.

Hãy nhớ câu ngạn ngữ cũ, "Làm việc thông minh hơn, không khó hơn". Đây là ổ đĩa cơ bản của các lập trình viên.

Những người chế tạo và lập trình những chiếc máy tính đầu tiên đã không làm điều đó bởi vì họ thích làm việc chăm chỉ, họ đã làm điều đó để TRÁNH công việc thậm chí còn khó hơn. (làm các trang tính toán bằng tay)

Trở nên 'lười biếng' là một trong những lý do cơ bản khiến lập trình viên lập trình. Đó là lý do tại sao chúng tôi viết các ngôn ngữ mới và ngày càng cao hơn, trình gỡ lỗi ngày càng tốt hơn và IDE, trình bao và xây dựng tập lệnh, v.v ...

Một lập trình viên nhìn vào một vấn đề, bất cứ điều gì anh ta hoặc cô ta làm và nghĩ;

"tôi có thể tự động hóa cái này không?" , "mất bao nhiêu thời gian?" , "điều đó sẽ giúp tôi tiết kiệm bao nhiêu thời gian?"

Chúng tôi làm điều này bởi vì chúng tôi lười biếng, chúng tôi không muốn thực hiện một nhiệm vụ lặp đi lặp lại và nhàm chán khi chúng tôi có thể làm những việc thú vị hơn nhiều.

Nếu các lập trình viên không lười biếng thì sẽ không có lập trình viên nào thấy cần phải viết một ngôn ngữ hoặc trình biên dịch mới.

Theo như quan điểm rằng một lập trình viên là "lười biếng" bởi vì anh ta phải "tìm kiếm mọi thứ", vậy thì, ai quan tâm. Giả định rằng việc học mọi sắc thái của một ngôn ngữ cụ thể (và không bao giờ phải tìm kiếm thứ gì đó) sẽ là công việc cần thiết hơn, đó là tìm và sử dụng những gì bạn cần khi bạn cần nó là ngụy biện. Bên cạnh đó, quá trình tìm kiếm mọi thứ là quá trình học hỏi và chính những lý do như thế này tồn tại.

Nếu ai đó muốn lập trình cứng, tôi sẽ bảo họ đi mã tay một số mã máy thô trong hex. Làm xong chưa? Muốn một cái gì đó khó hơn? Bây giờ đi gỡ lỗi nó.

Trước hết, gọi những người sử dụng ngôn ngữ ví dụ với người lười dọn rác, là kiểu gọi những người lái xe ô tô với hộp số tự động lười biếng. IMO nó hơi vô lý.

Về năng lực, lập trình là công việc phổ biến và bình đẳng hơn nhiều so với trước đây. Vì vậy, có, nhiều người mới, những người thiếu kiến ​​thức. Tuy nhiên, tôi không có ý rằng, đột nhiên có những lập trình viên kém năng lực hơn. Trong thực tế có nhiều hơn. Bạn chỉ đang nhìn vào phía sai của đường cong chuông.

Tôi muốn nói, "vâng, các lập trình viên cơ sở thiếu hiểu biết đã trở nên lười biếng và kém năng lực hơn", nhưng hãy thử một câu trả lời nghiêm túc:

Nhiều thứ đã trở nên dễ dàng hơn, nhưng chúng ta mong đợi nhiều hơn. Tôi hiện đang tạo một ứng dụng web có nhiều tính năng thường thấy trong các ứng dụng gui được làm tốt (chế độ xem theo tab, lưới có thể chỉnh sửa và sắp xếp, xuất Excel, v.v.). Các công cụ tôi đang sử dụng (ExtJS, v.v.) khiến cho việc tạo ra một ứng dụng như vậy không tốn kém một cách hợp lý.

Mười năm trước, gần như không thể, ít nhất là rất tốn kém, để tạo ra một ứng dụng như vậy. Nhưng mười năm trước, một hình thức HTML đơn giản với bảng HTML sẽ đủ cho khách hàng. Ngày nay, với cùng một nỗ lực, kết quả tốt hơn (ít nhất là đẹp hơn) là có thể, và khách hàng mong đợi có được chúng!

Nói chung, một nhà phát triển phần mềm ngày nay cần biết nhiều ngôn ngữ hơn một nhà phát triển phần mềm 20 năm trước. Trước đó, một cái gì đó như C và SQL là đủ. Hôm nay, tôi đang sử dụng JavaScript, HTML, Groovy, Java, SQL trong cùng một dự án.

Các lập trình viên đang trở nên ít có năng lực và lười biếng hơn trong một số cách, nhưng có thẩm quyền hơn ở những người khác, mặc dù sự phân chia C ++ / VB không phải là lý do hoặc một triệu chứng trong tâm trí của tôi.

Sử dụng trình xây dựng GUI không phải là lười biếng, nó chỉ khác, đó là về các công cụ cho công việc trong tay. Nếu một lập trình viên biên dịch được gọi là lập trình viên C ++, bạn sẽ gọi nhảm nhí về điều đó (đúng) và điều tương tự cũng đúng với C ++ và VB. VB cho phép bạn thực hiện một số công cụ một cách nhanh chóng với chi phí của một số kiểm soát. Rào cản để bắt đầu mã hóa trong đó chắc chắn là thấp hơn nhưng đó là một điều rất khác với sự lười biếng - bạn chỉ cần học những điều khác nhau và áp dụng chúng theo những cách khác nhau. Các lập trình viên VB không lười biếng hơn các lập trình viên C ++ là không hiệu quả, họ chỉ làm việc và sản xuất theo những cách khác nhau.

Trên quan điểm rộng hơn, nhìn chung giáo dục lập trình viên tốt hơn bao giờ hết. Ý tưởng về việc không sử dụng kiểm soát nguồn chẳng hạn là khá kinh tởm đối với hầu hết mọi người bây giờ, nơi 10 hoặc 20 năm trước, điều đó sẽ không đúng như vậy. Tương tự như vậy, họ có nhiều khả năng hiểu và muốn sử dụng các bài kiểm tra đơn vị tự động, tích hợp liên tục, v.v., theo nghĩa đó, họ có năng lực hơn họ.

Nhưng điều tôi nghĩ đã thay đổi là mọi người không còn biết cách giải quyết vấn đề theo cách họ đã từng sử dụng và điều đó đúng với hầu hết mọi ngôn ngữ chính thống. Phản hồi tức thì cho bất kỳ vấn đề nào hiện nay là Google và mặc dù điều đó rất tốt và hoạt động 95%, tôi thấy quá nhiều lập trình viên không biết phải làm gì khi không có.

Không phải là họ không hiểu các nguyên tắc cơ bản (họ không thực sự không phải là vấn đề lớn), mà là họ không thể phá vỡ các vấn đề theo cách mà họ thậm chí có thể tìm ra những nguyên tắc cơ bản nào họ cần được nắm bắt với.

Trước Google bạn không có sự lựa chọn. Tài nguyên của bạn là nhóm của bạn, vài chục cuốn sách vật lý mà bạn có thể có quyền truy cập và bộ não của bạn. Điều đó được thiết lập có nghĩa là nếu bạn gặp vấn đề, có khả năng bạn đang tự giải quyết vấn đề đó từ một thứ gần với hiệu trưởng đầu tiên để bạn có thể giải quyết vấn đề khá tốt hoặc thất nghiệp nhanh chóng.

Và điều này là đúng bất kể bạn sử dụng ngôn ngữ nào. VB ở cấp độ cao và ẩn giấu rất nhiều nhưng điều đó có nghĩa là khi giải quyết vấn đề thực sự có nghĩa là bạn cần phải làm việc nhiều hơn. Nếu một cái gì đó không hoạt động, bạn phải sáng tạo hơn và làm việc chăm chỉ hơn vì bạn ít kiểm soát hơn. Là một lập trình viên VB (và tôi nói từ kinh nghiệm) bạn không biết ít hơn những người C ++, bạn chỉ biết những điều khác nhau nhưng cả hai bạn đều biết cách giải quyết vấn đề.

Nhưng có lẽ thật khó để xem đó là một sự chỉ trích đáng kể đối với các lập trình viên ngày nay, họ không phát triển các kỹ năng vì họ không cần chúng, nhưng đó là một điểm yếu so với những người nhặt được các kỹ năng khi cần thiết.

Tôi lưu ý từ hồ sơ của bạn rằng bạn 23 tuổi. Hãy để tôi đặt răng vào và cho bạn một góc nhìn từ một người nào đó khoảng hai lần tuổi bạn đang làm việc này trong một thời gian rất dài:

Trước đây, có rất ít thứ, bắt đầu với sức mạnh tính toán, lưu trữ và băng thông mạng, nếu bạn có một mạng lưới. Những sự khan hiếm đó đặt ra giới hạn cho những gì bạn có thể làm một cách hợp lý, làm cho việc quấn đầu quanh mọi thứ dễ dàng hơn nhiều. Phần mềm chúng tôi chạy ngày nay có khả năng hơn nhiều so với những thứ tôi đã làm việc với 25 hoặc 30 năm trước và những khả năng đó có nghĩa là có nhiều hơn thế. Điều đó làm cho việc thu thập một sự hiểu biết chi tiết về mọi thứ khó khăn hơn rất nhiều đối với một người. Một phần trong đó liên quan đến thực tế là mọi thứ sẽ tiếp tục gia tăng về độ phức tạp và một phần liên quan đến các tác dụng phụ của tuổi tác.

Hệ sinh thái điện toán đang trở nên giống như các hệ thống sinh học: con người phức tạp hơn các sinh vật đơn bào và các bộ phận của chúng ta phải chuyên môn hóa nếu chúng ta sẽ làm tốt mọi thứ. Các tế bào não của tôi cực kỳ giỏi trong những thứ có trí tuệ nhưng sẽ bị mất nếu được đưa vào thận và dự kiến ​​sẽ làm những việc về thận. Tương tự, anh chàng giỏi viết bộ xử lý tín hiệu số có thể không biết làm thế nào để lập chỉ mục toàn văn hoạt động, bởi vì đó không phải là chuyên môn của anh ta. Nhưng cả hai có thể tiến hóa một chút và học cách hiểu nó nếu cần, nhưng có những giới hạn về việc bạn có thể tự lan rộng đến đâu mà vẫn hiệu quả với những gì bạn làm.

... không ai quan tâm đến cách thức hoạt động của công cụ cho đến khi nó không hoạt động.

Khi bạn có một công việc phải làm, bạn thường phải có một niềm tin rằng một công cụ bạn đang sử dụng (thư viện, RDBMS, toàn bộ hệ thống con, v.v.) hoạt động như bình thường. Một trong những điều kinh nghiệm mang lại là khả năng chọn lỗ thỏ nào bạn sẽ chạy xuống để khắc phục những thất bại trong công cụ của bạn, khắc phục sự cố và sau đó quay lại với những gì bạn đang làm.

Bây giờ tôi không gọi các nhà phát triển VB lười biếng khi chỉ nói nó dễ hơn C ++ và tôi đã nhận thấy rằng rất nhiều ngôn ngữ mới hơn đang theo xu hướng này như C #.

Đó là tất cả một vấn đề về quan điểm. Tôi đã ở xung quanh để thấy C ++ ra đời và nó cũng đi theo xu hướng đó. C ++ làm cho mọi thứ dễ dàng hơn nhiều so với C, C làm cho mọi thứ dễ dàng hơn nhiều so với lắp ráp và lắp ráp làm cho mọi thứ dễ dàng hơn nhiều so với viết opcodes bằng tay. Là một người đã viết rất nhiều phần lắp ráp và lắp ráp một vài thứ bằng tay từ đầu, điều đó sẽ đưa bạn, với tư cách là một lập trình viên C ++, đi xuống ba bước trên con đường "dễ dàng hơn".

Một cái gì đó tôi đã duy trì trong một thời gian dài bây giờ là:

Một trong những thế mạnh lớn nhất của Ngôn ngữ cơ bản Visual là người mới bắt đầu có thể học cách làm nhiều việc hữu ích khá nhanh.

Một trong những điểm yếu lớn nhất của Lập trình viên Visual Basic là họ sẽ học cách làm nhiều việc hữu ích khá nhanh, và sau đó họ sẽ ngừng học bất cứ điều gì.

Khi tôi dạy lập trình bài tập đầu tiên, ngày đầu tiên đến lớp là làm thế nào để xây dựng một ứng dụng trong NOTEPAD và biên dịch nó bằng cách sử dụng VCC hoặc VBC. Vâng, đây là những điều chúng tôi (với tư cách là lập trình viên) không làm hàng ngày, nhưng nên hiểu những gì đang xảy ra khi chúng tôi nhấn "F6".

Các lập trình viên không (nói chung) nhận được 'lười biếng' nhiều như chúng ta đang mong đợi để có được nhiều hơn từ các công cụ của chúng tôi. Tôi không cần phải gõ "get / set" 10.000 lần một ngày, tôi THÍCH rằng Visual Studio và các công cụ khác như Code Smith và Resharper hoạt động để tôi làm những gì tôi đã biết cách làm để tôi có thể áp dụng nỗ lực của mình vào việc tìm ra làm thế nào để làm những điều "mới". Điều đó không làm tôi lười hơn, điều đó khiến tôi "đổi mới".

Là một nhà phát triển chuyên nghiệp, chúng ta không nên "lãng phí thời gian" khi phát minh lại bánh xe nhưng chúng ta nên hiểu rõ điều gì sẽ tạo ra bánh xe mà chúng ta sẽ sử dụng. Đây là những điều chúng ta nên học với tư cách là nhà phát triển sinh viên (nhưng thật không may, thường là không). Nếu một nhà phát triển không hiểu một số công nghệ "hộp đen" thì điều đó thực sự khiến họ bớt "có năng lực". Hầu hết các nhà phát triển chỉ "về cơ bản hiểu" cách trình điều khiển ODBC hoạt động, họ chỉ hiểu "nó" làm gì. Tôi có phải biết làm thế nào một truyền dẫn làm việc để trở thành một trình điều khiển có thẩm quyền? Tôi sẽ nói không. Liệu nó làm cho tôi một chủ sở hữu xe có thẩm quyền hơn để biết điều này, vâng.

Sự cần thiết phải phát triển ứng dụng nhanh chóng (liên kết wiki bắt buộc: http://en.wikipedia.org/wiki/Rapid_application_development ) có nghĩa là các nhà phát triển viết ít mã hơn và các nhà phát triển mới hơn hiểu ít hơn, vì họ không cần hiểu cách triển khai danh sách được liên kết vì họ có một cái gì đó cao hơn để tập trung vào.

Tôi không thể bắt, giết, lột da, đồ tể và chữa thịt, và tôi nghi ngờ anh chàng trong quán cà phê ở tầng dưới có thể, nhưng tôi vẫn nhận được bánh mì thịt xông khói từ anh ta, giống như những người kinh doanh nhận được ứng dụng của họ từ những nhà phát triển không biết về con trỏ (như tôi!)

Người ta đã nói rằng các ngành khoa học vĩ đại là ví dụ về những người khổng lồ đứng trên vai của những người khổng lồ khác. Người ta cũng đã nói rằng ngành công nghiệp phần mềm là một ví dụ về người lùn đứng trên ngón chân của người lùn khác.
- Alan Cooper

Một nhà phát triển phần mềm tốt không phải là người tái tạo bánh xe. Anh ta có thể sử dụng các công cụ đã được xây dựng trước anh ta. Anh ta không lãng phí thời gian để viết lại những thứ nhàm chán cũ, đã được viết hàng trăm lần, trở nên mệt mỏi nhanh chóng và có lẽ tồn tại trong một phiên bản chất lượng cao hơn hiện có.
Nếu bạn cung cấp cho họ một ngôn ngữ đã có đĩa đá tròn đi kèm, rất có thể họ sẽ không dành quá nhiều thời gian cho việc phát minh lại bánh xe. Nếu tôi có một xu cho mỗi thói quen sao chép chuỗi từng được viết bằng C, tôi có thể mua toàn bộ ngành công nghiệp phần mềm.

Sự lười biếng trong thực tế là một trong ba đức tính tuyệt vời của một lập trình viên. Các công cụ mà bạn nói đến được xây dựng bởi các lập trình viên giỏi cho các lập trình viên giỏi, để giảm sự dư thừa và nhàm chán và do đó tăng năng suất và động lực. Công cụ như vậy có thể trong thực tế có những ảnh hưởng tiêu cực đối với người mới bắt đầu, vì chúng ngăn cản một sự hiểu biết sâu sắc hơn về các khía cạnh lập trình họ đơn giản hóa.

Không. Bạn đang già đi.

Không đùa, những gì bạn đang trải nghiệm là một loại quyền của các nhà phát triển. Đã bao giờ kể từ khi các ngôn ngữ cấp cao đầu tiên thay thế lắp ráp. Trước đó, bạn đã nghe tất cả các lập trình viên ASM phàn nàn về điều tương tự. 5 năm kể từ bây giờ, tất cả các nhà phát triển Ruby on Rails sẽ phàn nàn về việc một công cụ mới đang tạo ra sự lười biếng như thế nào.

Sự kiềm chế này sẽ được lặp đi lặp lại cho đến khi máy móc phá hủy tất cả chúng ta: "Có vẻ như công nghệ X đang khiến các nhà phát triển lười biếng và tồi tệ hơn công nghệ Z mà tôi luôn sử dụng?"

Tin tốt là, mặc dù các trình biên dịch đã đi một chặng đường dài, mọi người vẫn cần lắp ráp và C và tất cả các stalwarts cũ khác cho nhiều thứ ... chỉ không phải là phần lớn của đổi mới công nghệ tiên tiến. Nếu bạn muốn trở thành tiên phong, tôi khuyên bạn nên cập nhật bộ kỹ năng của mình.

Từ kinh nghiệm của tôi, có và không, nhưng đó không phải là lỗi của ngôn ngữ; Đó là lỗi của chính các nhà phát triển. Tôi đã làm việc với nhiều nhà phát triển không quan tâm đến việc làm đúng, cải thiện bản thân hoặc thực sự làm bất cứ điều gì khác ngoài việc tạo ra những thứ nhảm nhí mà họ đã làm trong nhiều năm. Cố gắng làm cho những người này tiến bộ cũng giống như nói chuyện với một bức tường gạch - một nửa thời gian họ không biết gì về những gì họ chưa từng sử dụng trong quá khứ hoặc hoàn toàn không muốn "nắm lấy cơ hội" với thứ gì đó có thể cải thiện năng suất của họ .

Các ngôn ngữ nâng cao hơn không phải là vấn đề, đó là các lập trình viên không coi nghề này là một nghề không ngừng phát triển. Bạn không cần phải nhận thức sâu sắc về mọi thứ mới, hoặc nhảy vào mọi nhóm nhạc mới, nhưng ít nhất bạn nên cố gắng trở nên tốt hơn với những gì bạn làm.

Ví dụ cụ thể: Tôi là một Nhà phát triển .NET bằng thương mại. Tôi mong muốn một nhà phát triển .NET có thẩm quyền nhận thức được những thứ như LINQ, Entity Framework, WPF, MVC và những thứ tương tự; họ không cần phải sử dụng nó, hoặc đang đẩy nó tại nơi làm việc, nhưng ít nhất một sự hiểu biết thoáng qua về "Điều này tồn tại" tốt hơn là sự không biết gì tuyệt đối mà tôi thấy quá thường xuyên.

Tôi mới chỉ viết mã được khoảng 4 năm trong công việc và điều đó gần như hoàn toàn là c #. Tôi đã học C ++ khi ở College và Uni nhưng bây giờ tôi không thể làm được gì nhiều với nó.

Vì vậy, để phát triển GUI, nó có thể được coi là lười biếng, nhưng một lần nữa, không thể thấy rằng bạn có thể tập trung ít hơn vào việc mã hóa phần đó và nhiều hơn nữa vào việc phát triển logic của chính ứng dụng.

vì vậy có lẽ thay vì trở nên kém năng lực hơn, họ đang chuyển trọng tâm, có lẽ rất nhiều sang các hệ thống truyền thông và phân tán, ví dụ như điện toán đám mây và SOA. Mặc dù điều này có thể giống như những suy nghĩ tương tự từ một lập trình viên trung gian.

Có lẽ đúng là rào cản gia nhập công việc lập trình đã giảm dần mỗi năm. Ví dụ, giờ đây các kỹ sư có chuyên môn không phải là phần mềm và nghệ sĩ chủ yếu viết mã bằng các ngôn ngữ kịch bản.

Điều này ngụ ý rằng mức độ năng lực đã thực sự tăng lên, nếu bạn xem xét chiều rộng. Các nghệ sĩ có thể lập trình cũng có nghĩa là bây giờ có nhiều lập trình viên có kỹ năng nghệ thuật.

Có một sự khác biệt giữa "lập trình viên" và "lập trình viên thực sự". Vui lòng không gọi HTML là ngôn ngữ lập trình, nhưng có rất nhiều "lập trình viên HTML". Mỗi bạn (lập trình viên / nhà phát triển) có thể tạo trải nghiệm với các đồng nghiệp - chỉ cần "tắt Internet (thực sự không cho phép họ sử dụng các công cụ tìm kiếm)", và bạn sẽ thấy rằng rất nhiều "lập trình viên" sẽ ngồi không có việc làm. Những gì họ có thể làm, họ chỉ biết rằng nếu họ cần, ví dụ, tìm kiếm trong văn bản, họ nên "tìm kiếm" tìm kiếm văn bản trong% ngôn ngữ_ame% '"? Họ không thể trả lời cho điều này - sự khác biệt trong thuật toán Boyer-Moore và Knuth-Morris-Pratt là gì.

Vì vậy, IMO, lập trình có nghĩa là giải quyết các vấn đề, biết rất tốt là ngôn ngữ lập trình tối thiểu với 'STL' và những điều quan trọng khác. Lập trình là một nghệ thuật, là một loại cuộc sống, đó không phải là điều có thể được thực hiện bởi tất cả mọi người.

Xin lỗi vì mỉa mai nhiều hơn cần thiết, nhưng tôi nghĩ bài viết này nói tốt hơn tôi.

Tôi có lầm không?

CẬP NHẬT: Điều chính và quan trọng là kiến ​​thức về các nguyên tắc cơ bản, chẳng hạn như thuật toán, cấu trúc dữ liệu, v.v ... Bao nhiêu bạn có thể thực hiện các thư viện / hàm chuẩn / vv trong trường hợp nếu hôm nay sẽ vô tình bị xóa? IMO, lập trình viên nên sử dụng mã 'người ngoài hành tinh' được phát triển / sửa lỗi tốt (thư viện / khung / v.v.), nhưng luôn luôn có thể phát minh lại bánh xe!

Về việc VB dễ sử dụng và các lập trình viên lười biếng chọn VB vì nó:

Tôi nghĩ VB được bao quanh bởi một huyền thoại lớn về việc dễ sử dụng. Huyền thoại này ban đầu có phần đúng: trở lại vào khoảng những năm 1991-1994 khi khủng long đi trên trái đất, chỉ có hai công cụ RAD thực sự xung quanh là VB và Delphi. Chúng khá giống nhau, nhưng LƯU Ý NÀY: Delphi và VB đều dễ sử dụng như nhau! Sự khác biệt đáng chú ý duy nhất giữa chúng là VB có cú pháp hoàn toàn phi logic và tạo ra các chương trình chậm chạp đến khó tin.

GUI C / C ++ được viết bằng MFC hoặc API Win thô. Vì vậy, VB chắc chắn dễ sử dụng hơn so với giải pháp thay thế của Microsoft. Sau đó, nhà máy tin đồn đã đi như thế này:

• VB dễ sử dụng hơn Microsoft C / C ++ / Win API. ->
• VB dễ sử dụng hơn. ->
• VB rất dễ sử dụng. ->
• VB là dễ nhất.

Tin đồn này sau đó vẫn tiếp tục, mặc dù Delphi luôn dễ dàng như nhau, nếu không muốn nói là dễ dàng hơn, vì Pascal là một ngôn ngữ logic và lành mạnh.

Sau đó, vào cuối những năm 90, Borland đã phát hành C ++ tương đương với Delphi: C ++ Builder. Bây giờ có 3 công cụ dễ dàng như nhau. Trong khoảng thời gian này, một số đối số hợp lý còn lại để sử dụng VB đã chết. Tuy nhiên, huyền thoại vẫn sống. "VB là dễ nhất".

Sau đó, Java xuất hiện và có một số công cụ RAD cho nó (và cho phiên bản Microsoft fiasco của nó được gọi là J ++). Tuy nhiên, huyền thoại VB vẫn sống.

Sau đó, Microsoft cũng đã hỗ trợ RAD cho C ++ và cũng đã đưa ra C #, biến tất cả thành một goo lớn gọi là .NET. Vì huyền thoại VB vẫn còn tồn tại, họ có thể lừa các nhà phát triển VB cũ sử dụng VB.NET thay vì C ++ hoặc C #. Mặc dù VB.NET không tương thích với các phiên bản VB trước đó.

Ngày nay, VB là một ngôn ngữ hoàn toàn dư thừa. Công cụ RAD không dễ hơn bất kỳ công cụ RAD nào khác. Cú pháp ngôn ngữ hết sức kinh khủng, tệ đến mức nó thực sự khuyến khích thiết kế chương trình tồi và thực hành lập trình xấu.

Có rất nhiều hoạt động được kết hợp lại với nhau dưới biểu ngữ "lập trình", và số lượng công nhân tham gia ở cuối "kỹ thuật viên" ngày càng lớn hơn. Bạn không cần phải có khả năng viết trình biên dịch, hoặc thậm chí chọn trong số một bộ thuật toán để giải quyết một vấn đề cụ thể để kết hợp một trang web trong PHP. Ngành công nghiệp / xã hội cần rất nhiều người sản xuất các trang web nói (rõ ràng), và cũng có một số lập trình viên nhất định làm việc về các vấn đề khó khăn hơn. Nhóm thứ hai đó không phải là lười biếng hay bất tài, nói chung, hoặc máy bay của chúng tôi sẽ bị hạ hỏa, ATM cung cấp một lượng tiền mặt ngẫu nhiên, các máy X Ray cung cấp liều lượng bức xạ gây tử vong, thị trường tài chính sẽ bị vây hãm, v.v. về cái cuối cùng đó :-)

Một mặt của điều này mà tôi nghĩ rằng tất cả các câu trả lời khác chỉ liếc qua là đây chỉ là xu hướng chung chung đi từ ngôn ngữ cấp thấp sang ngôn ngữ cấp cao.

Đúng vậy, ngành công nghiệp phần mềm đang chuyển từ ngôn ngữ cấp thấp sang ngôn ngữ cấp cao, luôn luôn có, và có lẽ sẽ tiếp tục như vậy miễn là chúng ta xây dựng các công cụ tốt hơn. Vâng, điều này có thể được coi là lười biếng, vì bạn phải làm việc rất chăm chỉ để làm những thứ cơ bản theo tiêu chuẩn ngày nay. Nhưng tôi sẽ không nói ít có thẩm quyền. Năng lực chỉ đơn giản là chuyển từ thực hiện sang thiết kế.

Cấp độ thấp Có phần chủ quan, nhưng ở cấp độ thấp, bạn đang làm việc gần hơn với phần cứng. Có ít nắm tay và giả định về ý định. Các công cụ cơ bản được trình bày và hoàn thành công việc được dành cho lập trình viên. Tất nhiên, các ngôn ngữ cấp thấp xuất hiện trước tiên và thường là công cụ của người bảo vệ cũ vì các ngôn ngữ cấp cao hơn không tồn tại khi chúng bắt đầu. Sẽ luôn có một số phát triển cấp thấp. Nhưng tôi sẽ không tạo ra một trang web lắp ráp.

Cấp độ cao Mục tiêu ở cấp độ cao là tự động hóa các chức năng cơ bản và làm cho việc lập trình đơn giản hơn. Nó hạ thấp thanh để nhập cho các lập trình viên mới, hoàn thành công việc nhanh hơn và chuẩn hóa cách chúng tôi biểu diễn và xử lý dữ liệu, thường là với chi phí chung. Hãy xem xét một chuỗi. Trong những ngày đầu, có lẽ ai đó đã sử dụng 1-26 cho az, và chỉ sử dụng 5 bit và chỉ cần biết kích thước của từ đó là bao nhiêu. Sau đó, tiêu chuẩn ascii được phát triển và chúng tôi có các chuỗi C với ký tự terminator. Bây giờ chúng ta có các đối tượng xử lý mọi thứ để tránh tràn bộ đệm và các kiểu con đặc biệt không cho phép các ký tự thoát. Hoặc một vòng lặp. Một vòng lặp "cho" là mức độ cao hơn một chút so với vòng lặp "while". Và một vòng lặp "trong khi" thực sự chỉ là đại diện cho cách gọi GOTO có cấu trúc.

Cũng thế,

Các lập trình viên trong tương lai sẽ nói với máy tính những gì họ muốn và trình biên dịch sẽ viết chương trình cho họ như trong trek star.

Chào mừng đến với tương lai! Đó chính xác là những gì trình biên dịch làm. Ngày xưa người ta phải viết mã máy bằng tay. Bây giờ chúng tôi đã tự động hóa điều đó và chỉ cần cho máy tính biết cách viết mã máy cho chúng tôi.

Tôi nghĩ ở đâu đó trên đường bạn mất tầm nhìn về những gì lập trình viên được trả tiền để làm.

Giao hàng của chúng tôi không phải là Mã, nó là phần mềm làm việc.

Chúng tôi không xây dựng đồ nội thất trong đó bằng cách nào đó cắt bằng tay bằng cách nào đó mang lại giá trị cao hơn bởi vì tất cả các "thủ công" thủ công đã đi vào nó.

Chúng tôi được trả tiền để giải quyết các vấn đề kinh doanh trên máy tính). Nếu bạn có thể cung cấp cùng một sản phẩm trong thời gian ngắn hơn với ít tiền hơn thì tôi nghĩ rằng đó là NGH OBA VỤ của chúng tôi để giả vờ rằng các chương trình C ++ vượt trội chỉ đơn giản vì chúng phức tạp hơn để xây dựng.

Tỷ lệ (số lượng nhà phát triển / số lượng nhà phát triển chương trình cốt lõi) đang giảm vì:

• Các công cụ ngày càng dễ dàng hơn, điều này có nghĩa là cần có tài năng nhỏ hơn cho cùng một vấn đề

• Mọi người đang làm quen với các công nghệ CNTT, điều này có sẵn sàng chi tiền cho các công cụ tùy chỉnh

• Tài liệu Khoa học Máy tính đang phát triển theo cấp số nhân, chuyên môn hóa và phân công lao động ngày càng tăng nên không còn người "Aristoteles" nào nói về mọi thứ (thực ra họ không cần biết mọi thứ vì các lớp trừu tượng)

• Nhiều công việc được cung cấp, bộ lọc được nới lỏng

• Cần tự động hóa nhiều hơn ở mỗi chu kỳ của cuộc sống, nhu cầu ngày càng tăng và cung không đủ

• Tỷ lệ nhà phát triển trên dân số ngày càng tăng.

  Vì vậy, mọi người không trở nên lười biếng hơn và kém năng lực hơn, trung bình giảm vì điện toán là một lĩnh vực cởi mở hơn bây giờ.

Rất nhiều câu trả lời cho biết tại sao lại phát minh ra bánh xe và tôi đồng ý với điều này nhưng khi có sẵn bánh xe, mọi người không bận tâm tìm hiểu cách chế tạo bánh xe.

Bạn đang làm suy yếu toàn bộ quan điểm của mình thông qua thực tế là bằng cách nào đó, bánh xe vẫn được chế tạo. Tôi thấy quan điểm của bạn, nhưng tôi nhận thấy rằng trong bất kỳ ngành học nào, có đủ những người quan tâm đến những thứ cấp thấp để tiếp tục phát triển. Chẳng hạn, tôi sử dụng Qt để xây dựng GUI. Công cụ đó không đến bằng phép thuật, mọi người đã phát triển mối liên kết giữa những thứ cấp thấp và những thứ tôi làm. Có ít người hiểu những thứ cấp thấp, vâng. Ít người hơn cũng có thể tự giết chết thức ăn hoặc tự sửa xe, nhưng xã hội vẫn sống sót.

Trước những năm 1940, máy tính là những mạch cứng. Sau đó, Von Neuman đã đưa ra ý tưởng cho các vị trí bộ nhớ được lưu trữ. Tôi chắc chắn rằng những lập trình viên tại MIT nghĩ rằng anh ta sẽ làm suy giảm giao dịch của họ thành một thứ quá dễ dàng. Sau đó đến lắp ráp, rồi đến FORTRAN, rồi ada, rồi C, rồi c ++, rồi java, v.v. Vấn đề là, điểm của một ngôn ngữ là cho phép trừu tượng hơn và xa hơn. Đó luôn luôn là mục tiêu và đó là lý do mà c ++ bắt được và sau đó là java. Thịt bò lớn nhất của tôi là các trường đại học không dạy sinh viên bất cứ điều gì về máy tính nữa. Tôi không thuê lập trình viên c # nếu họ không biết c ++ như mu bàn tay của chính họ. Tại sao? Bởi vì quá dễ để trở thành một lập trình viên tồi, ngôn ngữ càng trở nên trừu tượng. Họ cần hiểu con trỏ, quản lý bộ nhớ, ràng buộc động, v.v. . trong và ngoài trước khi họ có thể hiểu C # đến mức mà tôi tin tưởng họ đóng góp cho cơ sở mã của chúng tôi. Tôi cũng khiến họ phải vật lộn để tạo các tập tin trước khi tôi cho phép họ sử dụng Visual Studio. Điều đó nói rằng, tôi yêu C # và một IDE tốt, nhưng chúng là công cụ tốt khi chúng được hiểu đúng. Theo tôi, một sự trừu tượng là hữu ích nhất khi bạn hiểu các chi tiết đang được trừu tượng hóa - đó là một ý tưởng rất cũ, xem Thomas Aquinas về mối quan hệ của Trừu tượng với các chi tiết.

Tôi nghĩ một bài tập tốt khác cho các nhà phát triển cấp nhập cảnh là làm cho họ viết một vài ứng dụng bằng API Windows. Sau đó, sau khi họ hoàn thành nó, hãy để họ làm cho nó hướng đối tượng nơi mọi hình thức kế thừa từ lớp cửa sổ chung của bạn. Yêu cầu chúng gói gọn vòng lặp sự kiện và đặt một số con trỏ hàm quay lại lớp biểu mẫu của chúng. Sau đó, nói tốt, Microsoft đã làm điều này cho bạn, được gọi là System.Windows.Forms. Chúc vui vẻ.

Nếu họ là nhà phát triển web, hãy yêu cầu họ viết một vài chương trình CGI để họ hiểu POST, GET, v.v ... và sau đó viết kịch bản ra trang. Nó làm cho ASP.NET và PHP có ý nghĩa hơn nhiều.

Nếu họ đang làm việc ở cấp độ thấp hơn trên mạng, hãy yêu cầu họ viết một vài ứng dụng bằng cách sử dụng các socket trước khi giới thiệu chúng với các thư viện đã thực hiện nó.

Tôi đã thấy rằng điều này cải thiện năng suất trong thời gian dài bởi vì nó cung cấp cho họ các công cụ và trực giác chính xác để giải quyết vấn đề của chính họ.

Các trường đại học được cho là đang làm điều này, nhưng chúng không phải vậy.

Điều đó nói rằng, tôi đồng ý rằng việc tìm kiếm các lập trình viên đáng ra khỏi trường đại học ngày càng khó hơn, chủ yếu là vì họ không bị loại bỏ bằng cách buộc phải viết các thuật toán đệ quy và danh sách liên kết. Ngoài ra, họ thường chỉ có các khóa học Java hoặc .NET và do đó không hiểu gì về cách họ làm việc. Tuy nhiên, sự trừu tượng khá hữu ích khi được sử dụng đúng cách.

(..) sớm hay muộn sẽ không có thứ gọi là lập trình bây giờ

Tôi không đồng ý với điểm này.
Không biết ý thức là gì, công việc lập trình viên là an toàn.

Đây là cách "máy móc tư duy" nhìn vào lúc này:

-Stop thay đổi chủ đề!
-Tôi nghĩ tình yêu của chúng tôi là đặc biệt.
-Stop thay đổi chủ đề!
-Tôi không thay đổi chủ đề.
-Bạn là! Tôi đang cố gắng nói về việc bạn không có khả năng hiểu những gì chúng ta đang nói.
-Không nó thậm chí không gần. bài hát Beatles yêu thích của tôi là trên khắp vũ trụ. những gì là của bạn?

Tôi tin rằng chỉ những lập trình viên không đạt được điểm này mới là người cam chịu.

Ví dụ Dehumanizer`s câu trả lời:

Họ không thể trả lời cho điều này - sự khác biệt trong thuật toán Boyer-Moore và Knuth-Morris-Pratt là gì.

Và với "điểm này", ý tôi là - thật sai lầm khi thử vượt qua máy tính ở thứ tốt nhất - thuật toán. Thay vào đó, lập trình viên được cho là hỗ trợ máy tính với bối cảnh, kể về những vấn đề chúng tôi đang cố gắng giải quyết.

Bản thân các công cụ không khắc phục được sự cố, chúng chỉ (đôi khi) làm cho các lập trình viên hiệu quả hơn.

Nó giống như với: "súng không giết, con người làm".

Tuyệt đối không. Theo kinh nghiệm của tôi, sử dụng các công cụ phát triển chính xác cho phép phát triển ứng dụng nhanh chóng mà không làm giảm chất lượng. Trên thực tế, tôi sẽ lập luận rằng, phần lớn, chất lượng đã tăng lên do "quá phụ thuộc vào công cụ" của chúng tôi. Ngoài ra, các công cụ phát triển có thể làm giảm quá trình học tập và giới thiệu nhiều người hơn đến lập trình. Điều này, tất nhiên, có một nhược điểm, vì có nhiều lập trình viên mới hơn, nhưng tất cả, nó hỗ trợ quá trình sáng tạo và thúc đẩy công nghệ tiến lên.

Có quá phụ thuộc vào các công cụ ngụ ý rằng bạn lười biếng?

Nói chung, 'Không'; nhưng có một cảnh báo lớn.

Tôi bắt đầu lập trình trong C ++ tại uni và yêu thích nó. Trong nhiệm kỳ tiếp theo, chúng tôi đã đổi thành VB6 và tôi ghét nó.

Tôi không thể biết chuyện gì đang xảy ra, bạn kéo một nút vào biểu mẫu và ide viết mã cho bạn.

Vâng, thực sự. Kinh nghiệm của bạn tại uni nói lên chính sự cảnh báo mà tôi đã đề cập.

Nếu bạn không biết công cụ của mình đang giải quyết vấn đề gì hoặc bạn không có khả năng khắc phục sự cố khi công cụ của bạn gặp sự cố, thì đó là một lá cờ đỏ khổng lồ. Hoàn cảnh này không nhất thiết ngụ ý sự lười biếng, nhưng nó có thể ngụ ý thiếu kinh nghiệm.

Tôi nghĩ có 2 hương vị lập trình viên. Có những lập trình viên chỉ lập trình để hoàn thành công việc vì có thể là thời hạn hoặc có thể chỉ để làm việc hiệu quả hơn. Tôi sẽ nói rằng họ lười biếng. Tôi chỉ đơn giản tin rằng họ không có hứng thú với "cách" máy tính làm những gì nó làm hoặc "làm thế nào" một chương trình làm những gì nó làm.

Sau đó, có những lập trình viên đam mê, như tôi. Các lập trình viên đam mê, giống như tôi, muốn biết chính xác những gì đang diễn ra trong CPU. Giống như một nhà tâm lý học giỏi cố gắng tìm hiểu những gì đang diễn ra trong đầu con người, nhà tiên tri, giống như tôi, muốn biết những gì đang diễn ra bên trong CPU. Vì vậy, chúng tôi tìm hiểu, phân tích và phân tích một chương trình và sử dụng các công cụ, chẳng hạn như Reflector và disassemblers để cố gắng tìm ra cách một chương trình hoạt động.

Tôi có một hy vọng thầm lặng rằng mọi thứ sẽ thay đổi. CPU không được chia tỷ lệ theo chiều dọc, chỉ theo chiều ngang và ARM, v.v. sẽ bị hạn chế tài nguyên trong tương lai gần.

Hoàn toàn có khả năng nhu cầu lập trình không kéo và thả sẽ giảm và chúng ta sẽ thấy một số công việc thú vị hơn.