Ngôn ngữ kịch bản có tác động gì đối với các lập trình viên trẻ? [đóng cửa]


18

Tôi đã có một cuộc thảo luận với một trong những giáo viên của tôi vào ngày khác.

Chúng tôi đã tranh luận về tác động của các ngôn ngữ kịch bản đơn giản hơn (như Python hoặc Ruby) đối với các lập trình viên cơ sở.

Ông lập luận rằng các ngôn ngữ kịch bản tạo ra các kỹ thuật mã hóa cẩu thả bởi vì những người mới bắt đầu không hiểu những gì đang diễn ra "dưới mui xe". Ông cũng trích dẫn các ví dụ khác về cách các ngôn ngữ kịch bản thường khiến lập trình viên bỏ qua các mối quan tâm về hiệu quả, quản lý bộ nhớ, độ phức tạp hoạt động, v.v.

Tôi lập luận rằng các ngôn ngữ cấp thấp hơn có thể là quá nhiều đối với một số người và họ có thể bỏ cuộc trước khi họ phát triển niềm đam mê lập trình. Khi tôi bắt đầu học ngôn ngữ lập trình đầu tiên (C), tôi đã chỉ ra và từ bỏ vì các khái niệm này quá khó (để bảo vệ tôi, tôi chỉ mới 14 tuổi). Nếu nó không dành cho Java, tôi có thể đã không trở thành một lập trình viên! Nếu tôi đã bắt đầu với một ngôn ngữ đơn giản hơn và sau đó đào sâu, tôi cảm thấy mình sẽ không từ bỏ và tôi sẽ học được nhiều như tôi đã bắt đầu với C.

Lớp học kết thúc trước khi hai bên được khám phá đầy đủ.


Đến thời điểm này, tôi đã giảng rằng những người mới bắt đầu nên bắt đầu với các ngôn ngữ kịch bản và sau đó đào sâu; Nhưng sau cuộc thảo luận đó, tôi bắt đầu tự hỏi liệu đây có phải là suy nghĩ sai lầm.

Vì vậy, tác động nào của ngôn ngữ kịch bản có đối với các lập trình viên cơ sở?


8
Tôi không có ý trở thành một ass nhưng grammar.quickanddirtytips.com/affect-versus-effect.aspx
Singletoned

4
Tôi học lái xe ô tô với hộp số tự động. Sau đó, tôi có một với một hộp số tay. Phải mất một thời gian để tìm hiểu, và tôi cảm thấy may mắn vì tôi đã không phải học ly hợp và thay đổi cùng với mọi thứ khác.
David Thornley

2
@Singletenced: Đúng. Bằng cách nào đó tôi đã phải nghĩ đến xkcd.com/326 mặc dù ...


4
Cá nhân tôi nghĩ rằng nó không tự nhiên để học lập trình thấp sau đó cao. Chúng tôi học bò, sau đó đi bộ, chạy, nói chuyện và viết. Không chắc chắn logic là gì cho sự đảo ngược của trật tự tự nhiên trong trường đại học. Tôi thường chỉ nghe mọi người kết luận "bởi vì nếu tôi khó học thì nó cần phải chăm chỉ cho bạn". Ngay cả Joel cũng nói điều này. Tôi đoán chu kỳ sẽ không bao giờ kết thúc.
P.Brian.Mackey

Câu trả lời:


26

Tôi không đồng ý. Đầu tiên, các ngôn ngữ script đang ở mức độ trừu tượng cao hơn, và không có gì sai với điều này. Lúc đầu, người ta chỉ cố gắng học các nguyên tắc. Trên thực tế tôi sẽ nói rằng việc chọn một ngôn ngữ cấp thấp hơn có thể khuyến khích mã hóa xấu, vì người ta phải xử lý một số chi tiết trước khi có thể hiểu chúng. Thay vào đó với một ngôn ngữ đơn giản hơn, người ta có thể bắt đầu viết mã sạch và súc tích ngay từ đầu.

Thứ hai, có nhiều thứ để học trong các ngôn ngữ này. Theo như học ngôn ngữ, tôi sẽ nói rằng C dễ hơn Python. Người ta phải đối phó với các con trỏ hoặc chăm sóc các chuỗi, nhưng có nhiều khái niệm khác để tìm hiểu trong Python. Hiểu, định hướng đối tượng, phản xạ, phương pháp ma thuật, chức năng hạng nhất, lambdas, iterators và máy phát điện, siêu dữ liệu: tất cả những thứ này là một phần của ngôn ngữ.

Tôi nghĩ rằng bắt đầu với Python cho phép tìm hiểu nhiều hơn về lập trình và với một đường cong học tập nhẹ nhàng hơn. Một ngôn ngữ cấp thấp hơn có thể có ít trừu tượng hơn - do đó, ít khái niệm chung hơn để học - và áp đảo người mới bắt đầu với các chi tiết anh ta có thể muốn làm mà không cần.


1
+1, mặc dù tôi không nghĩ C dễ học hơn Python theo bất kỳ nghĩa nào. Có thể có ít khái niệm hơn để tìm hiểu tổng thể, nhưng bạn sẽ học được nhiều hơn trong cùng một khoảng thời gian với Python. Và tất nhiên, nếu C quá dễ, luôn có C ++, dạy cho bạn sự phức tạp của cả ngôn ngữ cấp cao và cấp thấp. ;)
Martin

+1, đây là suy nghĩ của tôi! Tôi ước tôi đã đọc được điều này trước khi đến lớp :)
joe_coolish

22

Không quan trọng bạn bắt đầu từ đâu. Nó quan trọng nơi bạn đi sau khi bạn bắt đầu.

BASIC có thể không phải là ngôn ngữ thanh lịch nhất trên hành tinh, nhưng nó bao gồm các nguyên tắc cơ bản của lập trình thủ tục, và thế là đủ để bắt đầu.

Tôi bắt đầu với BASIC. Tôi đã không ở lại đó.


+1 cho câu trả lời hoàn hảo - hiển thị chính xác cách đặt sai câu hỏi ban đầu! (Như sự trùng hợp hoàn toàn, tôi cũng bắt đầu với BASIC ;-)
Péter Török

5
Điều làm tôi ngạc nhiên là có bao nhiêu người KHÔNG ở lại đó ..: o /
Gary Willoughby

1
Câu trả lời xuất sắc. Ngắn gọn, chính xác và cho điểm. Tôi cũng bắt đầu với BASIC.
Michael Riley - AKA Gunny

11

Giáo viên của bạn là chính xác, ngoại trừ việc anh ta cho rằng hậu quả của mình là những điều xấu.

Nếu bạn xem việc học ngôn ngữ hoàn toàn là một hoạt động học thuật để tìm hiểu cách thức máy tính hoạt động, thì anh ta đã đúng. Nếu bạn xem chúng như một cách để hoàn thành công việc thì bạn đã đúng.


6
Gotta không đồng ý với bạn. Hậu quả những điều xấu, bởi vì hậu quả là sự thiếu hiểu biết. Điều này có nghĩa là cuối cùng, một cái gì đó sẽ bị phá vỡ và vấn đề sẽ ở mức độ trừu tượng thấp hơn bạn hiểu, và vì vậy bạn sẽ không biết làm thế nào để khắc phục nó. Đó luôn là một điều xấu.
Mason Wheeler

6
Phải đồng ý với bạn. Hậu quả của việc không biết những gì diễn ra dưới mui xe là một sự đơn giản sâu sắc và trực tiếp của biểu hiện mà không phải lo lắng về sắc thái phần cứng. Mức độ trừu tượng thấp hơn dành cho các nhà thiết kế ngôn ngữ không phải nhà phát triển ứng dụng.
S.Lott

1
@Mason: Hoàn toàn đúng. Tôi đã từng kiếm được một số tiền rất lớn để tiết kiệm lừa của một nhóm lập trình viên, những người không có khái niệm về những gì đang thực sự diễn ra, và vì vậy không thể làm cho hệ thống sản xuất của họ hoạt động tốt, hoặc hoạt động đáng tin cậy. (Một lần vì loại công việc đó tệ. Cuộc đời quá ngắn!)
William Pietri

1
@Mason - Tôi đồng ý với những gì bạn nói, điều quan trọng là phải có kiến ​​thức đó nếu bạn sẽ lập trình chuyên nghiệp. Tôi đã tìm thấy kiến ​​thức của mình về con trỏ, cấu trúc rời rạc và phép tính lambda vô cùng quý giá. Tôi đã bị mắc kẹt trong các đội nơi các thành viên trong nhóm của tôi không có những kỹ năng này và cuối cùng họ đã tạo ra mã quá phức tạp hoặc rất lỗi. chỉ bởi vì họ không biết rõ hơn. Có vẻ như đôi khi các trường đại học nuôi sinh viên CS quá nhiều sữa và không đủ thịt, nhưng mặt trái, nếu họ cho những lập trình viên mới bắt đầu ăn thịt, họ sẽ có nguy cơ bỏ học.
joe_coolish

1
@Joe: Theo Joel, làm cho những người không thể xử lý nó rơi ra là toàn bộ vấn đề. Và không chỉ là một lập trình viên máy tính mà còn là một người dùng máy tính , một người thường xuyên phải làm việc với các chương trình khủng khiếp mà tôi chỉ có thể giả định được tạo ra bởi các lập trình viên bất tài, tôi thực sự mong muốn "làm cho họ bỏ học" thành công hơn!
Mason Wheeler

5

Tôi nghĩ rằng "ngôn ngữ kịch bản" là một từ khủng khiếp, cực kỳ lỗi thời hoặc hoàn toàn phù hợp với một lớp ngôn ngữ cụ thể của miền. Giáo viên của bạn chỉ sắp xếp mọi thứ mà anh ta rõ ràng không có đủ hiểu biết về một trục ma quỷ.

Một sự khác biệt hợp lý để thực hiện là giữa các ngôn ngữ cấp cao và ngôn ngữ cấp thấp, hoặc giữa các ngôn ngữ được nhập tĩnh và động, thực sự trực giao.

Trình biên dịch được gõ ở mức thấp (nếu nói về các loại có ý nghĩa gì cả), C ở mức thấp được gõ tĩnh, Ruby ở mức cao được gõ động, Haskell được gõ ở mức cao. Java không phải là cấp cao hay cấp thấp được gõ tĩnh, C ++ là cả cấp cao và cấp thấp được nhập tĩnh. Và như thế.

Các cuộc thảo luận chỉ có thể là, mô hình nào phù hợp hơn cho một lập trình viên cấp nhập cảnh.
Tôi khá tin rằng lập trình cấp thấp có lẽ không phải là một. Có thể là, một thời gian trở lại vào đầu những năm 90, khi bạn thực sự có thể tạo ra kết quả thú vị trong thời gian hợp lý với nó.
Nhưng lập trình được thúc đẩy bởi niềm đam mê. Đam mê được nuôi dưỡng bằng phần thưởng. Do đó, các lập trình viên cấp nhập cảnh nên bắt đầu với các công cụ bổ ích. Các công cụ cấp thấp không còn bổ ích nữa, bởi vì có một biển công cụ cấp cao rộng lớn giúp bạn có được kết quả tương tự trong một phần nhỏ thời gian.

Suy nghĩ của con người là trừu tượng. Khi chúng ta học cách hiểu thế giới, chúng ta làm như vậy bằng những khái niệm trừu tượng rất thô và chúng ta đi vào chi tiết khi cần thiết.
Để một đứa trẻ hiểu môi trường của nó, bạn sẽ không dạy nó về toán học, rồi vật lý, rồi hóa học, rồi sinh học, rồi lịch sử, xã hội học và triết học. Bạn cho nó một mô hình rất đơn giản về thế giới để đối phó và sẽ tự mình vượt qua nó, bắn những câu hỏi vô tận vào bạn khi còn trẻ và phủ nhận hoàn toàn uy quyền của bạn sau này.

Đó là cách chúng tôi nghĩ. Bộ não con người chỉ có thể xử lý một lượng "đơn vị" thông tin hạn chế, nhưng mức độ trừu tượng ít quan trọng trong việc lượng tử hóa thông tin. Ví dụ: đọc biểu thức '34 * 75 'đối với chúng tôi đơn giản hơn so với việc tính toán nó, trong khi đối với máy tính thì ngược lại. Để nhận ra (và do đó trừu tượng) một loạt các pixel đen thành một dòng nguệch ngoạc, sau đó có thể được nhận ra (và do đó một lần nữa được trừu tượng hóa) thành một chữ số riêng lẻ là một công việc rất lớn.
Bà tôi hiểu ý tưởng mở một tập tin. Tuy nhiên, cô không có hiểu biết dưới mức đó. Và thẳng thắn, nếu cô ấy phải học điều này bằng cách đầu tiên nghiên cứu hoạt động bên trong của phần cứng và hệ điều hành và những gì không, cô ấy sẽ không bao giờ có được ở đó.

Có rất nhiều người ngoài kia, những người quá phức tạp, bởi vì họ không bao giờ được dạy phải suy nghĩ theo các giải pháp rõ ràng, ngắn gọn và qua đó, nhưng dành quá nhiều thời gian để bận tâm với các chi tiết cấp thấp có thể trao đổi và giải quyết các vấn đề chống lại chúng. Dạy mọi người suy nghĩ như máy tính là cách tiếp cận tồi tệ nhất để lập trình.
Giá trị của lập trình nằm ở việc tìm ra giải pháp cho một vấn đề. Thể hiện nó như mã thực sự là một nhiệm vụ cơ học buồn tẻ và đơn giản nên được thực hiện với bất kỳ công cụ nào phù hợp.

Ồ, và đừng lo lắng về việc không hiểu con trỏ. Tôi đã có cùng một vấn đề ở cùng độ tuổi. Vấn đề ở đây cũng là sự thiếu trừu tượng. Về mặt kinh điển, bạn học về con trỏ từ một số sách C và trong khi bạn đang vật lộn để hiểu chúng, điều này đi đôi với việc phân bổ bộ nhớ và do đó với bộ nhớ stack và heap, v.v. Khái niệm trừu tượng đằng sau con trỏ là không xác định. Một biến, chứa một chỉ mục vào một mảng cụ thể chỉ là như vậy (thực ra nó thực sự giống nhau trong C, trong đó mảng cụ thể là không gian địa chỉ của bạn) và bạn không cần đến các con trỏ cho việc này.
Điều này chỉ có ý nghĩa để minh họa, rằng việc chọn mức độ trừu tượng cao làm cho mọi thứ dễ nắm bắt hơn rất nhiều.

EDIT: và khi nói đến việc gõ, tôi thích các ngôn ngữ gõ tĩnh hơn. Và tôi nghĩ rằng các lập trình viên cấp nhập cảnh nên hiểu rõ khái niệm về các loại (là một loại trừu tượng).


3

Không có gì đơn giản về Python. Hãy xem Unicode và lập trình meta.


Tôi đồng ý rằng Python có thể rất phức tạp và RẤT mạnh mẽ. Nhưng những điều cơ bản (thao tác chuỗi, thao tác mảng, v.v.) trong Python dễ hơn nhiều so với trong C.
joe_coolish

1
Python rất đơn giản để bắt đầu và nhiều tác vụ hàng ngày là một thứ tự đơn giản hơn so với trong các ngôn ngữ hệ thống. Không, toàn bộ ngôn ngữ, các chi tiết chính của nó và các tính năng nâng cao không đơn giản (điều này đúng với tất cả các ngôn ngữ không phải đồ chơi). Nhưng đó không phải là câu hỏi.

1
Vậy thì tại sao if của tôi là searchopes.lower () trong filecontent.lower (): không hoạt động? bởi vì bom trong tệp sql UTF-16LE trong tfs trên windows với Python2.7. Đã không vui làm cho nó hoạt động mất vài giờ. string.find () cũng không hoạt động ... Argghhh!
Christopher Mahan

1
Unicode đơn giản hơn để xử lý trong C như thế nào?
dan04

3

Tôi thấy một vấn đề khác, sâu sắc hơn nhiều.

Các ngôn ngữ chưa được chỉnh sửa không buộc người ta phải chú ý đến các loại, phải suy nghĩ theo các loại. Điều này là tốt và tốt miễn là tôi có các tập lệnh nhỏ với một số chuỗi và số được chuyển đổi cho nhau mà không nhận thấy. Nhưng ngày sẽ đến khi điều này sẽ phá vỡ. Đột nhiên, chương trình sẽ bị hỏng, và mọi sửa chữa nhanh chóng sẽ khiến nó bị hỏng lần nữa.

Hoặc, lập trình viên Wannabe mới làm quen rằng anh ta sẽ cần một danh sách thay vì một danh sách các bộ dữ liệu, nhưng sẽ không có ý tưởng nhỏ nhất "làm thế nào để làm điều này", và anh ta sẽ đặt câu hỏi về stackoverflow mà hiển thị là bất lực tuyệt đối.


6
Nhưng Python và Ruby được gõ mạnh. Đây là trực giao để được gõ động. Chuỗi và số không hoàn toàn chuyển đổi lẫn nhau.
dsimcha

3
@dsimcha: Có - Và làm thế nào để bác bỏ những gì @Ingo nói?
Jim G.

1
Bởi vì câu hỏi này chủ yếu là về Ruby và Python. Tôi nghĩ rằng anh ta đang ám chỉ rằng anh ta nghĩ rằng Ruby và Python được đánh máy yếu, đó là một sự hiểu lầm phổ biến.
dsimcha

1
@ davidk01 - đó là quan điểm của tôi: các giá trị có loại cho dù chúng ta có muốn hay không. Nhưng trong các ngôn ngữ được gõ động (nếu thuật ngữ đó làm bạn hài lòng hơn), các biến không có. Thay vào đó, kiểm tra kiểu được thực hiện trong thời gian chạy để phân biệt giữa nhiều biến thể của Unitype.
Ingo

2
@Ingo: Ít nhất tôi đã từng có thể tìm thấy những người dùng Lisp thông thường nghĩ rằng việc thiếu gõ tĩnh là một lợi ích (thực ra, gõ tĩnh tùy chọn, có thể sử dụng để kiểm tra lỗi hoặc cho mục đích hiệu suất), vì nó đã thúc đẩy sự phát triển và rằng các lỗi gõ tĩnh có thể tránh được không trở nên khó tìm và sửa trong thực tế. Tôi chưa thấy gì hơn là ý kiến ​​theo cách này hay cách khác.
David Thornley

2

Tôi vẫn duy trì rằng hướng dẫn chính thức và cố vấn là một yếu tố lớn hơn nhiều so với lựa chọn ngôn ngữ trong chất lượng mã của người mới bắt đầu. Tuy nhiên, nếu tôi phải chọn một ngôn ngữ đầu tiên cho người mới bắt đầu, tôi sẽ chọn python cho các lập trình viên tự học và C ++ cho hướng dẫn đại học.

Lý do là với hướng dẫn chính thức, bạn có thể bắt đầu với các chương trình nhỏ, tầm thường để đặt nền tảng lý thuyết vững chắc trong nhiều năm trước khi bạn cần làm bất cứ điều gì hữu ích. Tôi nghĩ rằng thứ tự đó là lý tưởng nếu bạn có đủ thời gian và C ++ cung cấp cho bạn rất nhiều trợ giúp với các lỗi biên dịch và lỗi phân đoạn giữa các bài giảng để cho bạn biết nếu bạn không nắm bắt được các nguyên tắc cơ bản.

Một số trong những nguyên tắc cơ bản đó thực sự rất khó học nếu bạn tự học, cho đến khi bạn có được một số kinh nghiệm dưới vành đai của mình. Ngoài ra, bạn thường cần phải làm cho một cái gì đó hữu ích càng sớm càng tốt, và có thể đạt được nền tảng lý thuyết khi cần thiết, mặc dù bạn có nguy cơ không bao giờ học được nhiều hơn mức tối thiểu với phương pháp này. Đó là lý do tại sao tôi đề xuất một ngôn ngữ như python trong trường hợp đó.


2

Chúng tôi đã thấy nó theo cách khác ở trường đại học và tôi nghĩ nó hữu ích. * Chúng tôi bắt đầu trên con đê thấp. Con trỏ, quản lý bộ nhớ, mảng ký tự ... Vì vậy, chúng tôi đã bắt đầu với C. Tương tự với các thuật toán: đầu tiên triển khai danh sách được liên kết, hàm băm, cây ... Và chỉ sau đó sử dụng các thư viện chuẩn.

Sau đó, chúng tôi đã đi đến các ngôn ngữ mạnh hơn như Java, C # hoặc perl. Nhưng với lợi thế là biết những gì đang diễn ra dưới vành đai.

Trong khi điều này hoạt động, tôi tin rằng đi từ ngôn ngữ kịch bản sang ngôn ngữ cấp thấp hơn cũng tốt. Biết cả ngôn ngữ cấp cao và cấp thấp đảm bảo bạn có thể dễ dàng sử dụng ngôn ngữ cấp cao trong khi vẫn hiểu những gì đang diễn ra. Thứ tự mà bạn học chúng ít quan trọng hơn.


1

Ngôn ngữ kịch bản không làm cho lập trình viên cẩu thả. Thiếu sự rõ ràng trong việc hiểu miền vấn đề (ví dụ: doanh nghiệp mà chương trình phục vụ) là nguyên nhân gây ra sự trì trệ.

Như người xưa thường nói: "Bạn có thể viết COBOL bằng bất kỳ ngôn ngữ nào", mặc dù tôi nghi ngờ rằng khi mọi loại dữ liệu trông giống nhau , thì việc xem các khía cạnh thiết yếu của chương trình của bạn là gì, một tính năng chính của COBOL- sự thay đổi


1
Hãy thử nó trước khi nghi ngờ. Sự khác biệt chính là bạn không give a damn về nơi đó là một Foohoặc Barhoặc một cái gì đó hoàn toàn khác nhau miễn là bạn có thể .frobnicate()một trong hai cách. Không có giao diện rõ ràng.

Tôi khá quen thuộc với các ngôn ngữ động, vì công việc hàng ngày của tôi là với Ruby on Rails. Và vâng, đó là một quy ước lớn trong cộng đồng ngôn ngữ năng động. Nói chung, đây được gọi là 'gõ vịt'. Trong tài liệu nghiên cứu, chúng được gọi là các kiểu cấu trúc và có một số quy ước cú pháp có thể cho bạn thấy một loại 'quackable' trông như thế nào. Không chỉ vậy, có những hệ thống loại có thể nhận ra chúng, và xác minh rằng chương trình của bạn đang đối xử tốt với vịt.
Farley Knight

Tôi biết về các loại cấu trúc và coi chúng là một ý tưởng khá gọn gàng. Nhưng vì không có một ngôn ngữ thuần thục, được sử dụng rộng rãi (cơ sở người dùng ở cấp độ O'Caml sẽ là một khởi đầu tốt) sử dụng chúng, tôi không coi chúng là một thay thế thực tế cho việc gõ động. Buồn, nhưng thực tế.

Các ngôn ngữ được sử dụng rộng rãi thì không, nhưng điều đó không ngăn bạn khởi động hệ thống loại của riêng bạn lên một hệ thống được sử dụng rộng rãi. Tôi chắc rằng bạn đã thấy các bài báo về những thứ như kiểu suy luận cho các ngôn ngữ động.
Hiệp sĩ Farley

Một lần nữa, tôi không coi thứ gì đó được sử dụng bởi tôi và anh chàng bên cạnh là một sự thay thế thiết thực . Một lập trình viên cần những thứ như thư viện, cú pháp ổn định, công cụ, v.v.

1

Tôi sẽ lập luận rằng các ngôn ngữ kịch bản không khuyến khích các kỹ thuật cẩu thả. (Lưu ý rằng điều này không nói các ngôn ngữ là xấu , chỉ là khó duy trì các cơ sở mã lớn trong các ngôn ngữ đã nói) Tuy nhiên, tôi nghĩ rằng vì những lý do khác với các câu trả lời khác ở đây.

Tôi nghĩ rằng để sử dụng bất kỳ ngôn ngữ nào một lập trình viên cần phải có một số hiểu biết cơ bản về lập trình nói chung. Chúng sẽ không hiệu quả ở bất cứ đâu nếu chúng không hiểu các khái niệm như vectơ, cây và bảng băm. Họ không nhất thiết cần phải có khả năng thực hiện những điều này, nhưng họ cần biết đặc điểm của chúng.

Nơi tôi nghĩ rằng sự cẩu thả xuất hiện không phải là kỹ năng lập trình, mà là khi người ta cần tạo ra các thành phần có thể sử dụng lại. Các ngôn ngữ này không yêu cầu bạn xác định giao diện tốt giữa các đơn vị mã hoặc các cơ chế để thư viện thực thi các ràng buộc đối với máy khách của chúng. Đó không phải là không thể làm cho các thành phần reuseable tốt bằng các ngôn ngữ như vậy, nó chỉ là nhiều khó khăn hơn.

Các ngôn ngữ kịch bản có sức hấp dẫn đối với lập trình viên mới vì nó cho phép họ hoàn thành nhiều việc "một lần" hơn trong thời gian ngắn, nhưng khi những lập trình viên đó bắt đầu thực hiện lập trình bảo trì, họ thường nhanh chóng gặp vấn đề với các ngôn ngữ này.

Tôi không nói ngôn ngữ kịch bản là xấu - xa nó. Nhưng chúng gây khó khăn cho việc duy trì các cơ sở mã lớn (vài triệu dòng) (đó là một trong những lý do tại sao bạn không thấy bất kỳ cơ sở mã nào như vậy được thực hiện bằng ngôn ngữ kịch bản). Khi bạn cần các giải pháp tương đối nhỏ hoặc một lần, chúng cho phép bạn hoàn thành nhiều hơn trong thời gian ngắn hơn và ít mã hơn (và ít mã hơn hầu như luôn luôn tốt hơn).

Chỉ cần nhớ rằng không có công cụ nào là tốt nhất cho mọi công việc. Chọn công cụ thích hợp nhất cho tình huống. Điều đó áp dụng cho các ngôn ngữ lập trình giống như đối với bất kỳ công cụ nào.


0

Tôi với giáo viên của bạn, nhưng cũng với @Singletenced khi anh ấy nói rằng giáo viên của bạn đang thừa nhận hậu quả (ví dụ, không có kiến ​​thức về hiệu suất) là xấu.

Tôi nghĩ bắt đầu với C là tốt hơn so với bắt đầu với các ngôn ngữ kịch bản. Là một giáo viên, tôi sẽ tập trung vào toàn bộ kiến ​​trúc von Neumann (ALU, thanh ghi, bộ nhớ, cổng i / o, ...), chuyển thẳng sang con trỏ (tôi xin lỗi, đây thực sự là một khái niệm chính [không phát hành các tham chiếu (nghĩa là các con trỏ) trong các ngôn ngữ VM là một nguồn rò rỉ bộ nhớ chính]), đánh vào một số cấu trúc dữ liệu (cây, danh sách được liên kết, hàm băm 1 ), và sau đó ... đưa nó lên một mức độ trừu tượng vào một thứ khác (OO, lập trình chức năng, một cái gì đó - quy tắc gõ tĩnh mạnh , yo \ m /, vì vậy không có "ngôn ngữ kịch bản"> :().

1 Hmm, có lẽ tôi đồng ý với giáo viên của bạn về những cân nhắc về hiệu suất, sau tất cả.


Lập trình cẩu thả là một nguồn rò rỉ bộ nhớ và không cần phải dạy nhiều người theo dõi các tài nguyên như xử lý tệp. Có vô số chương trình C bị rò rỉ bộ nhớ, vì vậy tôi không chắc bạn sẽ làm gì với việc dạy mọi người về con trỏ càng sớm càng tốt.
davidk01

Điều đó là đúng, nhưng ... (a) không hiểu những điều cơ bản dẫn đến một số mã xấu (thông qua lập trình hack hoặc til-it-right hoặc cẩu thả), và (b) Tôi đã cố gắng thúc đẩy tại sao con trỏ vẫn có liên quan, không phải khẳng định rằng C tốt hơn các ngôn ngữ thu gom rác về rò rỉ bộ nhớ. Mục tiêu của việc tìm kiếm con trỏ càng sớm càng tốt để chúng ta có thể thoát khỏi C.
JohnL4

0

Tôi nghĩ tốt nhất là bắt đầu với một ngôn ngữ mô-đun và sau đó chuyển sang những thứ phức tạp hơn, trong những ngày của tôi, chúng tôi bắt đầu với Pascal và COBOL và cố gắng hiểu các chương trình con, điều khiển biến lưu lượng, v.v. Chỉ sau khi cảm thấy thoải mái với Pascal, tôi mới có mong muốn chuyển sang các ngôn ngữ như C / C ++ và tìm hiểu tất cả các kỹ thuật khác bổ sung thêm cho lập trình viên cơ sở.


0

Bạn đều đúng cả.

Ngôn ngữ kịch bản chắc chắn làm cho các nhà phát triển mới làm quen khó hiểu hơn những gì đang thực sự xảy ra. . -cult lập trình.

Mặt khác, điều số một tôi tìm kiếm trong các cuộc phỏng vấn không phải là sự hiểu biết hoàn hảo, đó là họ thích làm mọi thứ. Quay trở lại khi tôi bắt đầu, một máy tính làm bất cứ điều gì khá ấn tượng, vì vậy những thứ lắp ráp Apple Basic và 6502 nhỏ bé của tôi dường như thực sự tuyệt vời đối với tôi. Nhưng ngày nay máy tính làm được rất nhiều thứ tuyệt vời, vì vậy tôi nghĩ mọi người nên bắt đầu ở mức khá cao nếu đó là những gì cần thiết để họ bị mắc kẹt.

Về cơ bản, tôi nghĩ sẽ ổn khi bắt đầu ở phần cạn của hồ bơi miễn là cuối cùng bạn tấn công vào vùng nước sâu hơn.


0

Đầu tiên, tôi rất muốn bắt đầu với một ngôn ngữ có mức độ trừu tượng cao hơn. Hiện tại tôi muốn giới thiệu Python. Lý do quan trọng nhất để chọn ngôn ngữ kịch bản là ngôn ngữ đầu tiên là bạn có thể dễ dàng kết hợp một thứ gì đó hoạt động. Như Joe đề cập trong câu hỏi của anh ấy, điều số một trong khi trở thành lập trình viên là bạn có động lực để tiếp tục và đào sâu hơn. Động lực này có được khi bạn có thể tạo ra phần mềm hữu ích và hiệu quả.

Bên cạnh những điểm có sự hiểu biết trừu tượng (mức độ cao) và sự hiểu biết về triển khai cơ bản (mức độ thấp), có một điểm thứ ba bị bỏ qua. Để trở thành một lập trình viên giỏi hiện nay, bạn chắc chắn phải thành thạo cả hai điểm trên. Ngoài ra, điều quan trọng đối với năng lực của bạn là bạn liên tục nhìn vào các công nghệ và quan điểm mới. Cho dù bạn bắt đầu từ mức độ trừu tượng nào, bạn phải cải thiện liên tục và đặt câu hỏi cho các phương pháp hiện tại của bạn.

Cần phải làm rõ ngay từ đầu rằng các ngôn ngữ lập trình chỉ là công cụ để hoàn thành công việc. Điều rất quan trọng là chọn công cụ chính xác cho một nhiệm vụ cụ thể. Tôi nghĩ rằng đối với một lập trình viên mới bắt đầu, một ngôn ngữ kịch bản cấp cao sẽ giúp nhấn mạnh điểm này. Một ngôn ngữ cấp cao hơn sẽ cho một viễn cảnh rộng hơn và thúc đẩy lập trình viên đào sâu hơn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.