Làm thế nào được lập trình 20 năm trước? [đóng cửa]


37

Ngày nay chúng ta có rất nhiều công cụ hỗ trợ lập trình giúp công việc trở nên dễ dàng hơn, bao gồm:

  • IDE

  • Trình gỡ lỗi (từng dòng, điểm dừng, v.v.)

  • Ant script, vv để biên dịch

  • Các trang web như StackOverflow để trợ giúp nếu bạn gặp vấn đề về lập trình

20 năm trước, không có những thứ này ở xung quanh. Những công cụ nào mọi người đã sử dụng để lập trình, và họ đã làm như thế nào nếu không có những công cụ mới hơn này? Tôi quan tâm đến việc tìm hiểu thêm về cách lập trình đã được thực hiện trước đó.


29
Chúng tôi chắc chắn đã có IDE và trình gỡ lỗi 20 năm trước. Năm 1991 thậm chí còn có phiên bản đầu của Visual Studio.
ChrisF

14
Búa và đục
Matthew Whited

15
Bah! Bạn là người bắn tỉa , khi tôi còn trẻ, tất cả những gì tôi phải làm chương trình là đá và cát: xkcd.com/505
Thất

16
Bah, chúng tôi thậm chí không thể có số không, chúng tôi đã phải sử dụng chữ O.
Loïc Wolff

15
20 năm trước bạn thực sự phải biết thứ. Không có Internet biết tất cả mọi thứ.
Joel Etherton

Câu trả lời:


31

20 năm trước, đó là năm 1991. Đó là năm Borland C ++ 2.0 IDE được phát hành. Với trình gỡ lỗi tích hợp (với từng dòng và điểm dừng), xây dựng tự động bằng cách sử dụng make.

Nó trông như thế này http://www.ee.oulu.fi/research/tklab/cifts/521419A/tc201_compile.png

Bạn không có các trang web như Stackoverflow, nhưng với IDE, bạn sẽ nhận được vài nghìn trang tài liệu trong những cuốn sách được in độc đáo.


Tôi đã học cách sử dụng TC và TP IDE ở trường, tôi đã nghe nói ở đó có các công cụ tương tự, các công cụ giá rẻ này đã đưa IDE vào lập trình chính thống ...
umlcat

Gizmos lạ mắt. Bạn sẽ không cần chúng nếu bạn sử dụng butterfiles.
Mateen Ulhaq

Borland cũ tốt ... nếu ứng dụng của bạn quá lớn, bạn phải chọn và chọn DLL mà bạn đã biên dịch bằng mã gỡ lỗi hoặc bạn sẽ làm hỏng toàn bộ máy.
MadMurf

Tôi nhớ những cuốn sách đó với ba tờ giấy nhỏ được đục lỗ với số lượng tương đương với một quyển sổ nhỏ.
JohnFx

3
cùng một cách nó hoạt động trong IDE ngày nay. Bạn đã đặt các điểm dừng, ứng dụng được gỡ lỗi sẽ chạy và trên điểm dừng bạn sẽ thấy chính mình trong IDE. Chỉ khác là bạn tất nhiên không thể lật giữa chúng trong thời gian thực.
jwenting

57

20 năm trước ... 1991 ...

Hãy xem nào. Tôi đã sử dụng SunOS và VAX VMS.

Chúng tôi đã viết mã bằng trình soạn thảo văn bản (vi hoặc chỉnh sửa).

Tôi - cá nhân - không sử dụng trình gỡ lỗi và không bao giờ làm. Một số người đã sử dụng trình gỡ lỗi adb trên SunOS. Tôi thực sự đã sử dụng nó một vài lần để khôi phục một ngăn xếp ngăn xếp từ tệp kết xuất lõi. Tôi không biết những gì đã có trên VAX VMS. Tôi đã sử dụng báo cáo in trong mã.

Chúng tôi sử dụng làm cho biên dịch.

Chúng tôi đọc tài liệu giấy, suy nghĩ và chạy thử nghiệm. Thật vậy, điều đó vẫn hoạt động. Stack Overflow được sử dụng quá mức bởi một số người - vì những lý do không thể giải thích - từ chối chạy thử nghiệm hoặc suy nghĩ.

30 năm trước ... 1981 ...

Hãy xem nào. Tôi đã sử dụng Univac Exec 8 và IBM OS.

Chúng tôi đã viết mã bằng các trình soạn thảo văn bản (Tôi không thể nhớ lại Univac, nhưng IBM là trình soạn thảo của môi trường TSO)

Tôi - cá nhân - không sử dụng trình gỡ lỗi và không bao giờ làm. Những máy đó là "máy tính lớn" và không thể đơn lẻ bước qua bất cứ thứ gì. Không có "trình gỡ lỗi". Bạn phải chèn các câu lệnh in trong mã của bạn.

Chúng tôi đã viết kịch bản để biên dịch.

Chúng tôi đọc tài liệu giấy, suy nghĩ và chạy thử nghiệm.

40 năm trước ... 1971 ...

Hãy xem nào. Tôi đang sử dụng IBM 1620 không có HĐH.

Chúng tôi đã viết mã bằng cách sử dụng thẻ giấy đục lỗ.

Gỡ lỗi có nghĩa là bước đơn bộ xử lý. Nó hiếm khi hữu ích, vì vậy tôi đã học cách chèn các câu lệnh "in" trong mã của mình.

Chúng tôi chạy trình biên dịch bằng tay để tạo ra một cỗ bài giấy đục lỗ mà sau đó chúng tôi chạy. "Bằng tay" có nghĩa là nạp thẻ vào đầu đọc thẻ để cài đặt trình biên dịch hoặc trình biên dịch. Sau đó tải mã nguồn vào đầu đọc thẻ để tạo mã đối tượng. Sau đó tải mã đối tượng kết quả vào đầu đọc thẻ để chạy chương trình.

Chúng tôi đọc tài liệu giấy, suy nghĩ và chạy thử nghiệm.


"Hãy rời khỏi bãi cỏ của tôi Bạn thối trẻ em"

  • IDE. Hầu như vô dụng. Hoàn thành mã có thể thú vị, nhưng không hữu ích như một số người yêu cầu. Tôi đã có người nói với tôi rằng VB là một ngôn ngữ có thể chấp nhận được nhờ Visual Studio. Tô màu cú pháp có lẽ là tính năng hữu ích nhất từng được phát minh. Phần còn lại phải là các tiện ích bổ sung tùy chọn, vì vậy chúng tôi có thể phân phối với chúng và giải phóng bộ nhớ và chu kỳ bộ xử lý.

    Khi đi nạng, có những điều tồi tệ hơn để phụ thuộc vào.

  • Con nợ. Vô ích. Ngoại trừ khi định nghĩa ngôn ngữ quá tệ đến nỗi ngữ nghĩa quá u ám đến nỗi bạn không thể hiểu điều gì sẽ xảy ra. Ví dụ: VB. Khi cần một trình gỡ lỗi, đây là lúc để có một ngôn ngữ tốt hơn.

    Dựa trên kinh nghiệm giảng dạy lập trình của tôi, trình gỡ lỗi có thể không có ích. Đối với một số người, chúng dẫn đến suy nghĩ bị che mờ và một phong cách lập trình theo kinh nghiệm kỳ lạ, nơi không có ý nghĩa ngữ nghĩa đối với mã - không có nghĩa - chỉ là tin tặc thuần túy.

  • Ant script, vv để biên dịch. Biên soạn và liên kết gia tăng không thực sự là một ý tưởng tuyệt vời. Với các ngôn ngữ siêu phức tạp, đó là một hack cần thiết, nhưng thực sự cần phải được coi là một hack. Nó không cần thiết hoặc thậm chí là mong muốn.

    Một ngôn ngữ tốt hơn với sự phụ thuộc ít hơn vào việc biên dịch gia tăng có vẻ như là một điều tốt, xa hơn nhiều so với các tập lệnh Ant tinh vi.

  • Các trang web như Stackoverflow để trợ giúp nếu bạn quá mắc lỗi. Đôi khi hữu ích.

    Cũng như với các trình sửa lỗi, có khả năng một số người sẽ xuất hiện thành công thông qua sự may mắn đơn giản. Đó là một điều xấu.


3
Appox có bao nhiêu dòng mã bạn có thể phù hợp với 1 thẻ đục lỗ?
Nhấp vào Upvote

38
+1 cho "Stack Overflow bị lạm dụng bởi một số người - vì những lý do không thể giải thích được - từ chối chạy thử nghiệm hoặc suy nghĩ"
Binary Worrier 15/03

3
@trufa vào năm 1931, chúng tôi đã có các máy tính tương tự trong đó hình dạng của các bánh xe và bánh răng được mô hình hóa các biến. Vào năm 1831, chúng tôi đã có những khung dệt đọc các thẻ đục lỗ và công cụ khác biệt chạy bảng tính và in kết quả
Martin Beckett

13
Tất cả mọi thứ sau "Get Off My Lawn You Rotten Kids" là một trò đùa phải không?
Alb

7
Tôi không nghĩ rằng đó là một trò đùa. Có vẻ như "buồn nhưng có thật"
Adam Arold 15/03/2016

28

Hmm, tiền đề của bạn không hoàn toàn đúng. Hai mục sau là chính xác, nhưng 20 năm trước chúng ta đã có IDE và Debuggers.

Trong thực tế, trình gỡ lỗi luôn tồn tại. Thiết kế và sử dụng của họ đã phát triển kể từ khi nhóm của Brooks xây dựng các máy tính lớn của IBM vì tất cả chúng ta đều có máy móc chuyên dụng của riêng mình. Tuy nhiên, bây giờ chúng ta có thể có cùng một trình gỡ lỗi hoạt động cho một số ngôn ngữ khác nhau (xem dự án GCC hoặc MS Visual Studio để biết ví dụ).

20 năm trước, chúng tôi không có ANT, nhưng chúng tôi chắc chắn đã thực hiện. Thậm chí có một vài phiên bản không tương thích của công cụ. Đó là những gì mọi người sử dụng để xây dựng dự án của họ.

Và mặc dù web không có sẵn (nó vẫn là một dự án nghiên cứu trong các trường đại học và quân đội), chúng tôi đã có sách và tạp chí. Các tạp chí cung cấp thông tin cập nhật nhất và các cuốn sách xử lý lý thuyết.


17
Chúng tôi cũng đã có USENET, bạn có thể thấy tài liệu lưu trữ của comp.lang.c và những người khác trên Google Groups, có từ đầu thập niên 80 / giữa.
James yêu


3
Gỡ lỗi được phát minh trong EDSAC, trong '48 hoặc hơn. Gill, Wilkes và phi hành đoàn của họ đã tìm ra nó. Wilkes đã có một bài viết trong một tạp chí lịch sử điện toán vào khoảng '82 hoặc lâu hơn để nói về nó. Nếu bất cứ ai quan tâm tôi sẽ có thể khai thác các trích dẫn.
Paul Nathan

1
Cách đây hơn 20 năm, tôi đã sử dụng trình biên dịch GeOS: en.wikipedia.org/wiki/GEOS_%288-bit_operating_system%29 để biên dịch mã nguồn được viết trong trình xử lý văn bản của họ. Thật là mới lạ khi có định dạng WYSIWYG cho các bình luận của bạn, điều mà tôi chưa từng thấy kể từ đó.
Berin Loritsch

4
GDB: Trình gỡ lỗi tệ hại không kém bất kể ngôn ngữ nào được đính kèm. Đó là một kiến ​​trúc cơ bản xấu; trình gỡ lỗi cần được kết hợp chặt chẽ với ngôn ngữ để nó có thể hiểu và hỗ trợ các khái niệm dành riêng cho ngôn ngữ.
Mason Wheeler

18

Những đứa trẻ chết tiệt. Năm 1991? Có thật không? Bạn nghĩ gì đã xảy ra sau đó? Ý tôi là, Turbo Pascal vẫn gợi cảm, Netware vẫn là đối thủ cạnh tranh hợp lệ của Windows, máy tính nhanh vẫn được đo bằng mhz, nhưng khác với điều đó, nó không quá khác biệt. Quay trở lại 10 năm nữa và bạn đang nói về những thứ trên màn hình xanh, nhưng cũng có IDE cho các hệ thống đó.

Bạn phải quay trở lại giữa những năm 70 để tìm thẻ đục lỗ và tào lao như thế.


1
"không quá khác biệt"? Không có web và tôi chắc chắn rằng bạn cũng dành khá nhiều thời gian mỗi ngày để lấy thông tin cần thiết để thực hiện công việc của mình từ mạng.

4
@ Thorbjørn: Chúng tôi đã có một bình cà phê cam! Và sử dụng! Bạn còn cần gì nữa không? Thành thật mà nói, từ hồi ức của tôi, đó không phải là vấn đề. Nhu cầu về tài liệu web đã tăng lên cùng với sự phức tạp của những thứ bạn đang tạo. Nếu bạn đang kết hợp một ứng dụng kế toán với một văn bản gui, bạn sẽ không cần nhiều tài liệu.
Satanicpuppy

1
@satanicpuppy, bạn chỉ có chiếc cốc cà phê vào năm 1991 nếu bạn ở Cambridge. Là bạn?

2
"Netware vẫn là đối thủ cạnh tranh hợp lệ của Windows" ... có vẻ như bạn đang sống trong một vũ trụ thay thế vào năm 1991.
ocodo

2
@ Thorbjørn usenet trước khi đám đông giáng xuống nó là một nguồn tài nguyên tốt hơn StackOverflow ngày nay. Tất nhiên Wikipedia và các trang web nói chung là rất tốt, nhưng chương trình không phải là tất cả khác nhau.
Jim Balter

16

20 năm trước chúng ta đã có Borland Turbo Pascal và Turbo C ++, các IDE khá mạnh với các trình gỡ lỗi tích hợp, trình biên dịch, v.v.


Borland C ++ lúc đó khá ngọt ngào.
Chris Cudmore

12

Có rất nhiều công cụ tuyệt vời. Làm thế nào để nghĩ rằng hạt nhân Unix đã được xây dựng? và biên soạn? và tất cả các ứng dụng khổng lồ khác như Lotus 123, Corel Draw, Wordperinf, Xenix, MS Windows, X Windows, gnu, Kings Quest, Flight Simulator, v.v.

Unix có rất nhiều công cụ năng suất lập trình như lint để phân tích mã, tạo ra để biên dịch và vi hoặc emacs để chỉnh sửa. Với trình bao Korn (và có thể là các trình khác), bạn có thể tạm dừng một trình chỉnh sửa và chuyển sang trình chỉnh sửa khác trong 0,5 giây và thực hiện trên modem quay số chậm với màn hình greeen ("xem cỏ mọc"). Bạn có thể gỡ lỗi với dbx hoặc chỉ đọc kết xuất lõi.

Nếu bạn có tiền cho một thiết bị đầu cuối đồ họa, bạn có thể sử dụng X Windows và xdbx để gỡ lỗi thực sự lạ mắt.

Internet đã ở đó nhưng không phải WWW. Chúng tôi đã có FTP, gopher và WAIS ẩn danh. Và các nhóm tin tức mạng như comp.lang.c để đăng câu hỏi (bây giờ chủ yếu là thư rác).

Những công cụ đó rất mạnh mẽ. Bạn đã bao giờ xem kernel re-build chạy trong một hoặc hai ngày chưa? Nó sẽ xây dựng makefile sau makefile, xây dựng tất cả những phụ thuộc đó. Và thậm chí còn có pmake có thể phát hiện mục tiêu nào có thể được xây dựng song song. Kiến có thể làm điều đó chưa?

Trên PC có các sản phẩm Borland tuyệt vời như Turbo Pascal (v4 là một thay đổi lớn khi xuất hiện vào giữa những năm 80).

Thời gian thú vị họ đã có. Và giá cả thú vị. Hộp SDK Windows 3 có tay cầm nhưng cần hai tay để nâng, quá nhiều đĩa và chồng sách hướng dẫn cao 1 feet. Cơ sở dữ liệu quan hệ có giá hàng ngàn đô la cho mỗi người dùng, các cuộc chiến Unix, các cuộc chiến bảng tính đối với khóa gạch chéo. Tôi ngạc nhiên về các công cụ tôi có thể nhận ngay bây giờ với giá thấp / miễn phí điên rồ như vậy.

Phần thú vị nhất của tất cả những điều này là một số lệnh gõ phím của Visual Studio (CTRL-K + CTRL-C) là các lệnh Wordstar cũ. Một chút hoài niệm mỗi khi tôi sử dụng nó.


Arrrrggghhhhhhh, bạn đã đề cập đến Wordstar!
HLGEM

Unix được viết bằng ed - không có công cụ nào bạn đề cập tồn tại vào thời điểm đó. Chúng tôi đã có vỏ Mashey, được thành công bởi vỏ Bourne - vỏ Korn là một sự xuất hiện muộn.
Jim Balter



7

Cảm ơn đã khiến một chàng trai cảm thấy già :-)

Các trình gỡ lỗi và makefiles đã có khoảng thời gian đó. Trình biên dịch đi kèm với sách dày hoặc cho Unix, một tập hợp lớn các trang man. Hầu hết các nhà phát triển Unix đã sử dụng vi hoặc emacs. Tôi đã không thực hiện bất kỳ chương trình máy tính để bàn nào trước đó, nhưng tôi khá chắc chắn rằng họ đã sử dụng các trình soạn thảo đi kèm với trình biên dịch mà về cơ bản là các IDE có ít tính năng hơn. Bạn đã nhận được sự giúp đỡ từ đồng nghiệp, sách hoặc tạp chí.


Tôi muốn xin lỗi mọi người vì vẫn sử dụng makefiles và emacs.
bev

@bev Bạn không phải là người duy nhất :)
NWS

6

20 năm trước tôi đã lập trình trong BASIC. Tôi không có IDE vì BASICA và GW BASIC không phải là IDE. Khi tôi thấy Quick BASIC sau đó tôi đã rất hạnh phúc. Tôi đã rất phấn khích khi lần đầu tiên sử dụng tính năng Sao chép và Dán trong quá trình phát triển. Sau đó, họ đã tạo trình biên dịch QBASIC không phải là trình thông dịch như trước đây và nó cũng rất tuyệt nhưng sau đó tôi chuyển sang C và sử dụng Turbo C IDE của Borland. Lưu ý rằng tôi đang ở Ai Cập và hồi đó không có internet và chúng tôi chậm hơn một năm về phần mềm. Ý tôi là nếu một phiên bản được phát hành ngày hôm nay, nó sẽ đến tay tôi khoảng một năm sau. Bây giờ thì dễ dàng hơn nhiều nhưng niềm vui lập trình trở lại là không thể so sánh được :)


6

Tôi nghĩ rằng hiện tượng "năm web" đã làm sai lệch tính toán ngày của bạn.

Cách đây 20 năm, tôi đã lập trình trong Smalltalk - một trong những ngôn ngữ hướng đối tượng dựa trên GUI đầu tiên trên Mac IIe với màn hình 20 inch, vì vậy tôi nghĩ rằng bạn phải quay lại vài năm sau đó để lấy da gấu và đá kỷ nguyên lập trình.

Bây giờ 40 năm trước tôi đã lập trình cơ bản bằng cách sử dụng một thiết bị đầu cuối teletype có modem kiểu khớp nối acustic (110 Baud baby!) - bạn biết loại mà bạn đã quay số điện thoại, sau đó nhét tay đặt vào cốc cao su trên modem .


"Em bé 110 Baud" LOL
edelwater

6

Đây là một hình thức tiêu chuẩn để giúp bạn viết các chương trình FORTRAN của bạn trước khi bạn làm hỏng một loạt các thẻ đục lỗ.

nhập mô tả hình ảnh ở đây

(từ: http://www.w3.org/2010/Talks/01-08-steven-ten-euro-computer/ )

Hãy chắc chắn sử dụng bút chì để bạn có thể xóa các lỗi của mình và để lại một vài dòng trống giữa các câu in của bạn trong trường hợp bạn quên một số bước.

(OK, có thể đó là một chút trước năm 1991, nhưng không nhiều ...)


5

Chà tất cả bắt đầu từ thẻ đục lỗ , nhưng tôi chắc chắn ít nhất bạn đã nghe về bài học lịch sử đó. Tuy nhiên, đó là từ hơn 20 năm trước.

Để gỡ lỗi? Rất nhiều hộp thông báo, tệp nhật ký và các phương thức đầu ra khác để giúp kiểm tra và xem những gì vừa xảy ra.

20 năm trước, 4GL là những cơn thịnh nộ.

Đáng ngạc nhiên, 20 năm trước đây mọi thứ không phải tất cả khác nhau. Bây giờ 30 năm trước ...

Bây giờ khi tôi viết câu trả lời này, hãy nhớ rằng tôi chỉ mới 10 tuổi vào thời điểm đó, nhưng vẫn đưa đĩa mềm 5,25 "vào ổ cứng 1 MB của tôi kích hoạt PC Headstart XT / AT của IBM. Tại sao lại trả lời câu hỏi này?

Bởi vì nơi tôi làm việc, chúng tôi duy trì một hệ thống mã và cơ sở mã 20 năm tuổi, vì vậy chúng tôi vẫn đang trong tình trạng khó khăn khi làm việc với các hệ thống cũ, môi trường phát triển và mã.


Tôi nhớ thẻ keypunch vào những năm 1980.
crosenblum

Chết tiệt 4gls. Tôi đã sử dụng một (Speedware) YESTERDAY . Tại sao mọi người từng nghĩ rằng đó là một ý tưởng tốt nằm ngoài tôi, nhưng tất cả những người đi trước của tôi đã bỏ ra hàng giờ để mã hóa mã 4GL không thể hỗ trợ, và cứ thỉnh thoảng, tôi phải điều chỉnh một cái gì đó trong hệ thống. Nói về một kỹ năng vô dụng.
Satanicpuppy

@Satanicpuppy: 4GL là khung web trong ngày. Tôi chỉ có thể tưởng tượng những gì các nhà phát triển 20 năm kể từ bây giờ sẽ nói về mã Ruby trên Rails / jQuery / Zend: "Ai đã từng nghĩ đây là một ý tưởng hay? Có phải tất cả mọi người ở thế kỷ này đều là một kẻ ngốc ?" :)
TMN

@tmn: Heh. Tôi cũng không thích những thứ đó, vì nhiều lý do tương tự ... Tất nhiên, tôi cũng không cần sử dụng chúng, không phải là một anh chàng web. 4GL tệ hơn mặc dù, vì chúng là độc quyền. Hỗ trợ tốn rất nhiều tiền và nếu bạn không có hỗ trợ, bạn không thể nâng cấp. Tôi đã xem xét một giấy phép mới cho chúng tôi vài năm trước, vì vậy tôi có thể di chuyển mọi thứ sang môi trường máy chủ mới và giấy phép đã chạy 150k! Mỗi trang web! COBOL tôi có thể di chuyển miễn phí và cơ sở dữ liệu chỉ yêu cầu giao diện $ 500. Toàn bộ dự án ngừng hoạt động vì môi trường 4GL độc quyền chết tiệt đó.
Satanicpuppy

Bây giờ 4GL đã có một điều cần nhớ.
Martin York

5

20 năm trước tôi đã viết mã, chủ yếu bằng C, Pascal. Đối với nền tảng DOS, có Turbo C, Turbo Pascal hầu hết là các trình soạn thảo hoàn chỉnh với trình gỡ lỗi cho phép thực hiện từng bước. Đối với lập trình thực , tôi cảm thấy hầu hết các lập trình viên như tôi đã sử dụng trình biên dịch vi +, chạy từ các dấu nhắc lệnh.

Lập trình sau đó khó hơn một chút, đặc biệt là đối với một số ngôn ngữ lập trình. Tôi vẫn có thể thấy dấu vết của điều này trong lập trình của riêng mình: Tôi thấy việc chạy thử nghiệm của mình với các printcâu lệnh dễ hơn là bước qua các câu lệnh.


Tôi vẫn sử dụng vi (gvim) cùng với Visual Studio (tôi đã sử dụng nó ngày hôm nay). Tôi chỉ sử dụng VS để hoàn thành mã (nó tìm kiếm các phương thức cho tôi) và để bắt đầu IncrediBuild. Nếu không tôi có thể chỉnh sửa nhanh hơn nhiều bằng cách sử dụng vim.
Giorgio

5

Tôi có thể nói cho Bulgaria.

Trái ngược với bạn có thể nghĩ, Bulgaria là một trong những quốc gia hàng đầu về công nghệ máy tính. Là một phần của khối cộng sản, Liên Xô đã đầu tư số tiền lớn vào khoa học máy tính của chúng tôi, làm cho nó trở thành một nhà lãnh đạo trong ngành công nghiệp trong khối cộng sản. Tuy nhiên, những người cộng sản đã không tha thứ cho các công ty tư nhân và mọi thứ trong khu vực này đều do chính phủ quản lý. Do đó, sự sụp đổ gần đây của khối cộng sản vài năm trước đã khiến đất nước không có doanh nghiệp ổn định để giữ cho ngành công nghiệp luôn trong tình trạng tốt. Tuy nhiên, một di sản kiến ​​thức tốt đẹp để lại cho thế hệ chuyên gia tiếp theo. Vì vậy, chúng tôi không bao giờ dừng lại để có quyền truy cập vào các công nghệ mới nhất và phát triển phần mềm không khác với các nước phương Tây. Chúng tôi đã sử dụng các công cụ tiên tiến nhất và các khái niệm lập trình.

Do đó, tôi sẽ không lặp lại tất cả những gì người khác nói, nhưng vâng, có những IDE và trình gỡ lỗi khá tốt vào thời điểm đó (tương ứng với bản chất của phần mềm được phát triển trước đó).

Tôi nhớ cá nhân tôi đã sử dụng Turbo Pascal và Turbo C (bởi Borland). Ngoài ra phần mềm của Autodesk dành cho đồ họa (như 3d Studio và Animator).

Tuy nhiên, nguồn kiến ​​thức hạn chế hơn - chủ yếu là sách, tạp chí, đồng nghiệp và hiếm khi là tạp chí điện tử thông qua BBS. Internet chủ yếu là một curio. Một số người đã truy cập Usenet, nhưng hiếm khi sử dụng nó cho công việc.


Chắc chắn có ít nguồn kiến ​​thức hơn hai mươi năm, nhưng chất lượng của người hành nghề phần mềm trung bình cao hơn. Hai mươi năm trước, chỉ có những người kiên quyết nhất còn sống sót trong ngành này. Bây giờ, sự bất tài có thể ẩn đằng sau những kỹ năng "Googling" và cắt dán tốt.
bit-twiddler

Bạn đã làm loại phần mềm nào ở Bulgaria trong những ngày đó nếu không có công ty tư nhân?
Nhấp vào Upvote

@Click Upvote Khoa học, quân sự, không gian, kỹ thuật, v.v. - tất cả mọi thứ được tài trợ bởi chính nhà nước, rõ ràng - hoặc ít nhất là theo cách đó ở đất nước tôi (Liên Xô) hồi đó.
mlvljr

4

Chỉ 20 năm trước. Bạn phải đùa thôi. Tôi đã sử dụng trình gỡ lỗi vào năm 1972 khi tôi đang học lập trình. Phải thừa nhận rằng những cái tôi có thể sử dụng không tốt như ngày nay. Tôi nghi ngờ rằng chúng tồn tại từ lâu trước đó.
Các công cụ đã thay đổi qua nhiều năm và chúng đã trở nên tốt hơn, nhưng thậm chí đừng nghĩ rằng chúng tôi không có công cụ trước đó.
Tôi nghi ngờ rằng bạn cần quay lại thập niên 50 để đạt đến cấp độ mà không có trình gỡ lỗi.
Trình gỡ lỗi thực sự tốt đầu tiên tôi sử dụng là trên VAX với VMS trong thập niên 80. Mọi thứ đã đi lên từ đó.


4

Đến bây giờ bạn sẽ thấy rằng các phiên bản đơn giản của hầu hết các công cụ bạn yêu thích đã có mặt vào năm 1991, mặc dù phân phối không đều.

Các so sánh thú vị hơn là với năm 1981: sự khởi đầu của các quá trình xã hội phổ biến rộng rãi liên quan đến các mạng USENET và UUCP và ARPANET. (Ngày cờ TCP của Internet là vào năm 1983.)

So sánh thậm chí thú vị hơn với năm 1971: các phiên bản đầu tiên của hệ điều hành mà bạn biết và yêu thích, các quy trình xã hội dựa trên xuất bản (bản tin giấy, hội nghị tham dự, chia sẻ mã với các liên hệ cá nhân, nhóm người dùng, sử dụng phương tiện như băng từ ).


ARPANET đã hoạt động vào tháng 10 năm 1969 - Tôi đã ở đó để đăng nhập lần đầu tiên. Chúng tôi đã sớm gửi e-mail, mặc dù '@' không được "phát minh" cho đến một vài năm sau đó. Nhưng ngay cả trước đó chúng tôi đã nhắn tin gián đoạn trên các hệ thống chia sẻ thời gian - khởi đầu thực sự của những thứ như usenet.
Jim Balter

Đúng, vào những năm 1970, "trong đám đông" (tương đối ít) có ARPANET, Xerox Altos, Ethernet, máy in Dover, đã viết các chương trình trong Smalltalk, Lisp, Simula67 hoặc C và có Tenex và Unix cho HĐH. Vào những năm 1980, <i> mọi người </ i> có mạng lưới diện rộng và các đồng nghiệp ở xa chia sẻ các bộ mã lớn hơn và lớn hơn.
Liudvikas Bukys

Những điều này là phổ biến trong các trường đại học.
Jim Balter

1
Jim Balter thân mến, chúng tôi không thực sự không đồng ý. Tôi chỉ nhấn mạnh rằng sự khác biệt lớn giữa thập niên 70 và 80 không phải là sự tồn tại của các công cụ, đó là sự sẵn có thực sự rộng rãi của chúng. Một trường hợp khác: Xem RFC923 (tháng 10 năm 1984). Chỉ có 35 ASN được chỉ định sau đó - chỉ một phần nhỏ các trường đại học.
Liudvikas Bukys

4

Cách đây 20 năm, tôi đã viết mã trên một chiếc 386 trong Borland C ++ bằng cách sử dụng OWL cho lập trình Windows.

Máy của tôi có một vài MB RAM và ổ cứng 200 MB. Tôi có thể cài đặt hầu hết các phần mềm từ đĩa mềm - nhưng ngày càng có nhiều phần mềm xuất hiện trên CD.

Khi tôi nhấn F8 để "Chạy" dự án của mình ở Borland thì trình biên dịch sẽ hoạt động khá nhanh và tôi có thể chơi ngay với kết quả.

Chúng tôi có một PC trong văn phòng, cứ sau vài giờ sẽ kết nối với Demon (sử dụng Trumpet WinSock) và tải xuống email của mọi người.

Khi chúng tôi không thể tìm ra cách lập trình một cái gì đó, thì chúng tôi thường tìm kiếm câu trả lời trong một cuốn sách - sách API Win32 đặc biệt hữu ích.

Trên thực tế, chúng tôi đã làm việc rất hiệu quả ... và lúc đó IDE đã hoạt động khá nhanh! Nhưng họ không có cấu trúc lại tốt và các công cụ kiểm tra tích hợp đẹp.


4

20 năm trước? Tôi đã sử dụng một IDE đẹp với trình quản lý dự án và trình xây dựng UI kéo và thả tuyệt vời. Có một ngôn ngữ OO khá tốt, một tập hợp các đối tượng GUI thực sự tốt, một loạt các ứng dụng tuyệt vời và một cửa sổ đầu cuối mang lại cho tôi một vỏ Unix vững chắc. Và một trình sửa lỗi, nhưng tôi đồng ý những thứ đó là dành cho những kẻ yếu đuối (hoặc xử lý mã ghê tởm của họ).

Nếu điều đó nghe giống như Mac, thì đó là vì tôi đang nói về môi trường phát triển NeXT, đó là thứ đã biến thành Mac OS hiện đại. Đối với các chủ hàng, bạn có thể đọc lịch sử ở đây:

Một ghi chú bên lề, tôi sẽ nói rằng việc xây dựng GUI tuyệt vời ở đó đã hủy hoại tôi hoàn toàn. Khi tôi bắt đầu phát triển các ứng dụng Swing trong Java, nó giống như con chó của ai đó đã ăn một tài liệu API GUI cũ và ném nó lên một lần nữa và Sun đã chuyển nó. Cảm ơn trời, cuối cùng web cũng nhận được ở đâu đó.


4

Tôi bắt đầu lập trình vào năm 1981, đến vào 30 năm trước vào mùa thu này.

Vào năm 1991, tôi đã làm việc tại Apple Computer (hay còn gọi là "Apple" ngày nay) và đang làm việc chặt chẽ với một công ty nhỏ của Canada với tên Metrowerks.

Metrowerks đang xây dựng một IDE kick-ass cho C, C ++ và Pascal. Môi trường này đóng vai trò chính trong quá trình chuyển đổi thành công của Apple sang bộ xử lý PowerPC từ 68K.

Mặc dù tôi là nhân viên của Apple, nhưng trong vài năm tôi đã làm Giám đốc sản phẩm của Metrowerks một cách hiệu quả, hợp tác chặt chẽ với Greg Galanos và Jean Belanger về chiến lược sản phẩm, v.v. Chính sự hợp tác chặt chẽ giữa Apple và nhà phát triển bên thứ 3 đã kích hoạt Power Macintosh quá trình chuyển đổi, chuyển đổi Mac tuyệt vời đầu tiên của Apple (lần thứ hai là quá trình chuyển đổi sang OS X).

Vào năm 1981, tôi đang bước vào năm thứ nhất tại UCSC và có cơ hội bắt đầu làm việc với Phiên bản Unix 7 (không phải Phiên bản 7) chạy trên PDP-11/70.

Không có IDE ở đây! Heck, chúng tôi đã không kiểm soát phiên bản cho đến một vài năm sau đó!

Đó là vi (và vim không phải là một lựa chọn), cc, ln, và thực hiện. Nó đã viết C Shell Script và hack nguồn vào C Shell để tăng kích thước của các biến môi trường từ 512 ký tự lên 1024 ký tự, để chứa các TERMCAPS ngày càng phức tạp hơn của "thiết bị đầu cuối thông minh" của chúng tôi

Nó đã có cơ hội để đọc một bản sao lậu của Sách Lions trên sàn của căn hộ ngoài khuôn viên của một sinh viên CIS thuộc tầng lớp thượng lưu, Ted Goldstein. Ted đã đi vào một sự nghiệp rất đầy đủ bao gồm cả VP của Công cụ tại Apple.

Nó đã chạm tay vào máy Mac vào năm 1984 và phiên bản đầu tiên của MDS (Hệ thống phát triển Macintosh) và học cách lập trình con thú mới và tuyệt vời này.

Đó là rất nhiều niềm vui. Nó dễ dàng hơn nhiều để đứng dậy và chạy. Nhưng sức mạnh chúng ta có với các ngôn ngữ như Ruby là không thể tin được. Thay vì viết bảng băm cho bảng biểu tượng trình biên dịch của tôi, tôi đang sử dụng chúng bên phải và bên trái làm kiểu dữ liệu cơ bản!

Vâng, nó rất vui, nhưng tôi sẽ không quay lại ...


Ồ Và không có RSI hay carpal hay bất kỳ trở ngại sức khỏe nào khác từ tất cả những năm lập trình? Không, đừng hiểu sai ý tôi, tôi không có ý nói 20+ hay hơn 30 năm mã hóa dẫn đến RSI, nhưng tôi đã thấy các trường hợp sử dụng quá nhiều các trình soạn thảo như vi dẫn đến điều đó.
Mamta D

3

20 năm trước tôi đã viết mã trong AMOS , có IDE và trình gỡ lỗi khá tốt.


Yay, tôi cũng vậy! Một sự kết hợp thú vị của ngôn ngữ khủng khiếp và tuyệt vời để học lập trình, nhưng cuối cùng nó cũng hoạt động khá tốt. Tôi đã sử dụng STOS, tiền thân của Atari ST, trước đó.
Liedman

3

Vào năm 1991, tôi đã sử dụng IDE / Framework có tên UIMX trên X Terminal, tạo các ứng dụng dựa trên Motif truy cập vào RDBMS của Informatix. Ngôn ngữ là C.

Có SCCS để tạo phiên bản, làm cho xây dựng.

Nhìn lại, không khác mấy so với cách tôi làm việc hôm nay.


3

28 năm trước tôi đã viết mã lắp ráp bằng hex, bằng tay, cho bộ xử lý 6809 (trong Dragon 32 cho những ai nhớ nó) - Cuối cùng tôi đã viết một trình biên dịch chủ yếu khá tốt cho nó, điều này giúp ích.

Không có trình gỡ lỗi - nếu nó không hoạt động, bạn thêm mã in để xem ngăn xếp. Những đêm dài! Mã hiệu quả đã giúp, vì có ít dòng sai hơn

Và ngày nay tôi phải học Clearcase, Maven, Ant và VS - tất cả đều vui vẻ (nhưng tôi nhớ những ngày xưa)


3

20 năm hả? Tôi chỉ hoạt động trong PC-Land ngay tại thời điểm đó sau khi rời Apple-Land ngay trước đó. Hồi đó tôi nhớ những đứa trẻ giàu có IDE đầy đủ với việc gỡ lỗi tích hợp (Borland & Microsoft). Phần còn lại của chúng tôi đã tìm kiếm cùng với các thương hiệu giá rẻ hoạt động tốt, nhưng không được "tích hợp" (Mix Software, nhà cung cấp trình biên dịch phần mềm chia sẻ khác nhau). Chuột đã ở trên bàn, nhưng hiếm khi chạm vào. 90% thời gian ở chế độ văn bản. Các thiết lập màn hình kép đã bắt đầu biến mất (trước đó, thông thường có một màn hình mã hóa đơn sắc và một màn hình "chạy" màu trong cùng hệ thống với các thẻ MDA và CGA sử dụng các vị trí I / O / bộ nhớ khác nhau và có thể cả hai được chạy cùng lúc trong DOS). Các phiên bản đầu tiên của Windows không hài lòng với nhiều màn hình.

Các ngôn ngữ phổ biến là C, Pascal và Modula-2. Mọi người vẫn sử dụng Logo và BASIC. "Visual BASIC" cuối cùng đã bắt đầu tiêu diệt BASIC. COBOL và RPG đã được dạy ở trường đại học.

Những đứa trẻ giàu có đang sử dụng USEnet trên Internet, những đứa trẻ nghèo vẫn quay số vào BBS địa phương và sử dụng các nhóm FIDOnet (với tốc độ 1200-2400bps, một modem 9600bps vẫn không thể phù hợp với hầu hết mọi người, có giá gần bằng phần còn lại của máy vi tính).


3

Máy tính đầu tiên mà tôi lập trình trở lại vào những năm bảy mươi là Univac 1218 . 1218 có bộ điều hành tối giản và 16K bộ nhớ lõi ferrite định hướng từ 18 bit (do đó, thuật ngữ "kết xuất lõi"). Lưu trữ thứ cấp được xử lý thông qua băng từ và thẻ đục lỗ 80 cột được mã hóa của Hollerith. Máy sử dụng phần bù của một cho số học và hai phần bù cho địa chỉ. Nó có thể được lập trình và gỡ lỗi bằng cách sử dụng bảng mặt trước trong đó nội dung của tất cả các thanh ghi được hiển thị bằng các công tắc nút nhấn được chiếu sáng. CPU này có vẻ nguyên thủy theo tiêu chuẩn hiện đại, nhưng nó rất tuyệt với tôi vào thời điểm đó.

Quay lại chủ đề: Tôi đã sử dụng IDE hai mươi năm trước cho phần lớn sự phát triển của tôi. Tôi không phải là một trong những người già yếu đuối tin rằng IDE là dành cho những người có đầu óc yếu đuối. Một IDE tốt là một bộ khuếch đại năng suất.


2

20 năm trước, tôi là sinh viên lập trình RMCOBOL-85.

Tôi đã sử dụng một thiết bị đầu cuối màu xanh lá cây kết nối với một máy chủ tập tin.

Giao diện là một trình soạn thảo văn bản kiểu notepad. Không có bit ưa thích. Chúng tôi cũng có lựa chọn sử dụng VI. Không bao giờ làm mặc dù.

Ah ngày tốt lành. :)


2

Gần 20 năm trước cho đến ngày tôi đang sử dụng PC của IBM và Amiga 1000 để biên dịch mã C và lắp ráp cho một thứ gọi là Atari Lynx. Chương trình được đề cập đã chạy 5 trò chơi sòng bạc trong 47K (tức là kilobyte) không gian với 1K cho một số biến hệ thống. Một con số khổng lồ 16K được dành riêng cho video đệm đôi. Khi hệ thống "phát triển" xuất hiện, có các thói quen ví dụ ngôn ngữ lắp ráp để biến màn hình một màu và nhấp vào loa. Điều đó là vậy đó. Nếu bạn muốn văn bản, bạn phải tạo một phông chữ và thói quen văn bản của riêng bạn. Mạng? Đi trước, chỉ cần viết trình điều khiển của riêng bạn. Dunno tại sao, nhưng khó khăn của nó là một phần của niềm vui. Thật tuyệt vời khi bất kỳ nó hoạt động.


2

Bạn đang giỡn đấy à? Tôi đã khuấy động 80286 của mình trong Turbo Pascal vào giữa / cuối thập niên 80.

nhập mô tả hình ảnh ở đây


2

20 năm trước, tôi là thành viên của một nhóm sử dụng Interface Builder và Objective-C để tạo một ứng dụng xuất bản trên máy tính để bàn cho Hệ điều hành NeXTstep. Và, vâng, internet đã xuất hiện , nó chỉ khó sử dụng hơn một chút - nhưng tôi có thể tìm và đăng câu trả lời tại comp.sys.next.

Tôi đã gỡ lỗi trình gỡ lỗi tại Sun vào năm 1989 với tư cách là người hỗ trợ công nghệ phát triển hợp đồng.

Tôi đã sử dụng IDE gần 30 năm trước - UCSD p-System / Apple Pascal. Đã viết Sundog: Frozen Legacy cho Apple II với Apple Pascal và 6502 lắp ráp (1982-84). Đã viết mã p / mã disassembler của riêng tôi, quá. Đối với vấn đề đó, tôi đã sử dụng Hệ thống p UCSD trên máy vi tính Northstar Horizon (Z-80) tại Viện Mặt trăng & Hành tinh vào năm 1981.


Thật tuyệt khi nghe Bruce này! Tôi nhớ khi bạn rời khỏi thế giới Mac để làm việc trên NeXT ....
Jordan

2

Năm 1963 tôi đang làm việc tại một công việc mùa hè trong khuôn viên trường. Đó là trên máy tính PDP-1, được sản xuất bởi Digital (DEC).

Và vâng, nó đã có một trình gỡ lỗi tương tác, được gọi là DDT. Bạn có thể đặt điểm dừng, kiểm tra và thay đổi các biến, vá mã. Trình chỉnh sửa văn bản khá nguyên thủy và chúng tôi thường sử dụng máy băng giấy ngoại tuyến.

Ngôn ngữ là hợp ngữ. Máy có khoảng 4k từ 18 bit. Không có hệ điều hành.

Đến năm 1971, tôi đã sử dụng PDP-10 với 262.144 từ 36 bit mỗi từ. Một hệ thống chia sẻ thời gian tương tác hỗ trợ có thể 10 người dùng đồng thời, trình soạn thảo văn bản có tên là TECO, trình gỡ lỗi vẫn được gọi là DDT và các ngôn ngữ như Lisp, Fortran, Basic và Algol. TECO đã thực sự mạnh mẽ. Bạn có thể viết các chương trình thao tác văn bản trong đó.

PDP-10 là cơ sở cho một cỗ máy tương tự được sản xuất tại Palo Alto Research, nơi văn phòng của tương lai được sinh ra. Ethernet, chuột và GUI, e-mail, máy in laser và lập trình hướng đối tượng. Palo Alto đã có tất cả. Mười năm trước PC.

Rất nhiều thứ này đã bị lãng quên, và sau đó được phát minh lại nhiều lần trong những năm kể từ đó. Và tất nhiên, có rất nhiều thứ mới.


Tiến tới năm 1991, tôi đã làm việc về VAX. Ngôn ngữ chính của tôi là SQL, mặc dù tôi đã viết nội dung bằng PASCAL khi cần thiết. Tôi cũng đã sử dụng DCL và Datatrieve làm ngôn ngữ kịch bản, mặc dù chúng tôi không sử dụng thuật ngữ đó.

VAX không có IDE tại thời điểm đó, ít nhất là không phải nơi tôi làm việc. Nhưng trình soạn thảo văn bản, trình biên dịch, trình liên kết, trình gỡ lỗi và ngôn ngữ lệnh đều được xây dựng với ý tưởng rằng nhà phát triển sẽ sử dụng tất cả chúng. Họ đã làm việc tốt với nhau. Ghi nhớ một số lệnh không khó hơn ghi nhớ vị trí của một công cụ nhất định trên thanh công cụ. Việc gõ lại các lệnh được thực hiện dễ dàng hơn bằng cách gọi lại lệnh.

VAX có một trình gỡ lỗi tuyệt vời, nhưng tôi chưa bao giờ học nó. PASCAL làm cho việc khởi động chương trình trở nên khá dễ dàng và lập trình có cấu trúc giúp việc bản địa hóa một lỗi khá dễ dàng mà không cần sử dụng trình gỡ lỗi. Gỡ lỗi SQL là một trò chơi bóng hoàn toàn khác nhau.

Ngoài việc làm việc trên VAX, tôi đã sử dụng các công cụ máy tính để bàn để thao tác dữ liệu cục bộ. Đây là những công cụ MS Office hoặc tiền thân của chúng, tôi không nhớ. Phần khó là liên kết các công cụ máy tính để bàn với dữ liệu được lưu trữ trong cơ sở dữ liệu trên VAX.

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.