20 년 전에 프로그래밍은 어떻게 이루어 졌습니까? [닫은]

요즘에는 다음과 같은 작업을보다 쉽게 ​​해주는 많은 프로그래밍 보조 도구가 있습니다.

• 십오 일

• 디버거 (라인, 브레이크 포인트 등)

• 컴파일을위한 Ant 스크립트 등

• 프로그래밍 문제가 발생했을 때 도움이되는 StackOverflow와 같은 사이트

20 년 전에는 이런 것들이 없었습니다. 사람들은 어떤 도구를 사용하여 프로그래밍했으며,이 새로운 도구없이 어떻게 만들었습니까? 그 당시 프로그래밍이 어떻게 수행되었는지에 대해 더 배우고 싶습니다.

20 년 전 1991 년이되었습니다. 올해는 Borland C ++ 2.0 IDE가 출시 된 해입니다. 통합 디버거 (라인 및 중단 점 포함)와 함께 make를 사용한 자동화 된 건물.

http://www.ee.oulu.fi/research/tklab/courses/521419A/tc201_compile.png 와 같이 보입니다 .

Stackoverflow와 같은 웹 사이트는 없었지만 IDE를 사용하면 잘 인쇄 된 책으로 수천 페이지의 문서를 얻었습니다.

20 년 전 ... 1991 년 ...

보자 SunOS와 VAX VMS를 사용하고있었습니다.

텍스트 편집기 (vi 또는 edit)를 사용하여 코드를 작성했습니다.

나는 개인적으로 디버거를 사용하지 않으며 결코 사용하지 않았습니다. 일부 사람들은 SunOS에서 adb 디버거를 사용했습니다. 실제로 코어 덤프 파일에서 스택 추적을 복구하기 위해 몇 번 사용했습니다. VAX VMS에서 무엇을 사용할 수 있었는지 모르겠습니다. 코드에서 print 문을 사용했습니다.

우리는 컴파일을 위해 make를 사용했습니다.

우리는 종이 문서를 읽고, 생각하고 실험을 진행했습니다. 실제로, 그것은 여전히 ​​작동합니다. 스택 오버플로는 설명 할 수없는 이유로 실험 실행을 거부하거나 생각하는 소수의 사람들이 과도하게 사용합니다.

30 년 전 ... 1981 년 ...

보자 Univac Exec 8과 IBM OS를 사용하고있었습니다.

우리는 텍스트 편집기를 사용하여 코드를 작성했습니다 (Univac을 기억할 수는 없지만 IBM은 TSO 환경의 편집기였습니다)

나는 개인적으로 디버거를 사용하지 않으며 결코 사용하지 않았습니다. 그 기계들은 "메인 프레임"이었고 아무것도 밟을 수 없었습니다. "디버거"는 없었습니다. 코드에 print 문을 삽입해야했습니다.

우리는 컴파일 스크립트를 작성했습니다.

우리는 종이 문서를 읽고, 생각하고 실험을 진행했습니다.

40 년 전 ... 1971 년 ...

보자 OS가없는 IBM 1620을 사용하고있었습니다.

우리는 펀치 종이 카드를 사용하여 코드를 작성했습니다.

디버깅은 프로세서를 한 단계 씩 강화하는 것을 의미했습니다. 그다지 도움이되지 않았으므로 코드에 "print"문을 삽입하는 방법을 배웠습니다.

우리는 손으로 컴파일러를 실행하여 우리가 펀칭 한 종이 카드 더미를 만들어 냈습니다. "수동"이란 말 그대로 카드 리더기에 카드를로드하여 컴파일러 나 어셈블러를 설치하는 것을 의미했습니다. 그런 다음 소스 코드를 카드 리더에로드하여 객체 코드를 생성합니다. 그런 다음 결과 개체 코드를 카드 리더에로드하여 프로그램을 실행하십시오.

우리는 종이 문서를 읽고, 생각하고 실험을 진행했습니다.

"나의 썩은 아이들을 내놔"

• 십오 일. 거의 쓸모가 없습니다. 코드 완성은 재미있을 수 있지만 일부 사람들이 주장하는 것만 큼 도움이되지는 않습니다. VB는 Visual Studio 때문에 허용되는 언어라고 사람들에게 말해주었습니다. 구문 색상 지정은 아마도 지금까지 가장 유용한 기능 일 것입니다. 나머지는 선택적인 애드온이어야하므로이를 제거하고 메모리 및 프로세서주기를 확보 할 수 있습니다.

  목발이 갈수록 의존해야 할 상황이 악화됩니다.

• 디버거. 편치 않은. 언어 정의가 너무 나빠서 의미론이 너무 어두워서 일어날 일을 이해할 수없는 경우를 제외하고. 예를 들어 VB입니다. 디버거가 필요할 때는 실제로 더 나은 언어를 구할 때입니다.

  프로그래밍을 가르치는 경험을 바탕으로 디버거는 도움이되지 않을 수 있습니다. 어떤 사람들에게는 코드에 의미 론적 의미가없고 의미도없고 순수한 해커 일뿐 아니라 혼돈 된 사고와 이상한 경험적 프로그래밍 스타일로 이어집니다.

• 컴파일을위한 Ant 스크립트 등 증분 컴파일 및 연결이 실제로 그렇게 좋은 아이디어는 아닙니다. 초 복잡한 언어를 사용하면 필요한 해킹이지만 실제로 해킹으로 간주해야합니다. 필요하지 않거나 바람직하지 않습니다.

  증분 컴파일에 덜 의존하는 더 나은 언어는 정교한 Ant 스크립트보다 훨씬 더 나은 것 같습니다.

• 너무 많은 버그에 갇힌 경우 Stackoverflow와 같은 사이트가 도움이됩니다. 때때로 도움이됩니다.

  디버거와 마찬가지로 일부 사람들은 간단한 실수로 행운을 빕니다. 나쁜 일이야

흠, 당신의 전제는 사실이 아닙니다. 후자의 두 항목은 정확하지만 20 년 전에 IDE와 디버거가있었습니다.

실제로 디버거는 항상 존재했습니다. Brooks 팀이 전용 IBM 머신을 보유하고 있기 때문에 이전 IBM 메인 프레임을 구축 한 이후 그들의 디자인과 사용이 발전했습니다. 그러나 이제 여러 언어에 대해 동일한 디버거 작업을 수행 할 수 있습니다 (예를 들어 GCC 프로젝트 또는 MS Visual Studio 참조).

20 년 전에는 ANT가 없었지만 Make가있었습니다. 이 도구에는 호환되지 않는 버전이 몇 개있었습니다. 사람들이 프로젝트를 구축하는 데 사용한 것입니다.

그리고 웹은 쉽게 구할 수 없었지만 (여전히 대학과 군대에서 연구 프로젝트였습니다), 우리는 책과 잡지를 가지고있었습니다. 잡지는 가장 최신 정보를 제공했으며 책은 이론을 다루었습니다.

빌어 먹을 애들 1991? 정말? 당시에 무슨 일이 있었을까요? 터보 파스칼은 여전히 ​​섹시했지만, 넷웨어는 여전히 윈도우와의 유효한 경쟁자 였고, 빠른 컴퓨터는 여전히 mhz로 측정되었지만 그 외에는 별다른 차이가 없었습니다. 다시 10 년 전으로 돌아 가면 녹색 화면에 대해 이야기하고 있지만 해당 시스템에 대한 IDE도 있습니다.

펀치 카드와 쓰레기를 찾으려면 70 년대 중반으로 돌아 가야합니다.

20 년 전 우리는 Borland Turbo Pascal과 Turbo C ++, 디버거, 프로파일 러 등이 통합 된 매우 강력한 IDE를 가지고있었습니다.

훌륭한 도구가 많이있었습니다. 유닉스 커널은 어떻게 만들어 졌을까요? 그리고 컴파일? 그리고 Lotus 123, Corel Draw, Wordperfect, Xenix, MS Windows, X Windows, gnu, Kings Quest, Flight Simulator 등과 같은 다른 모든 거대한 앱

유닉스에는 코드 분석, 컴파일 및 vi 또는 편집을위한 emacs를위한 lint와 같은 많은 프로그래머 생산성 도구가있었습니다. Korn 쉘 (및 아마도 다른 것)을 사용하면 한 편집기를 일시 중지하고 0.5 초 안에 다른 편집기로 이동할 수 있으며 greeen 화면 ( "잔디가 자라는 것을 관찰")이있는 느린 전화 접속 모뎀에서 수행 할 수 있습니다. dbx로 디버깅하거나 코어 덤프를 읽을 수 있습니다.

그래픽 터미널에 돈이 있다면 X Windows와 xdbx를 사용하여 정말 멋진 디버깅을 할 수 있습니다.

인터넷은 있었지만 WWW는 아니 었습니다. 익명의 FTP, gopher 및 WAIS가있었습니다. 그리고 질문을 게시하는 comp.lang.c와 같은 네트워크 뉴스 그룹 (현재는 스팸입니다).

그 도구는 강력했습니다. 하루나 이틀 동안 커널 재 구축을 본 적이 있습니까? makefile 다음에 makefile을 빌드하여 모든 종속성을 빌드합니다. 그리고 어떤 대상을 병렬로 구축 할 수 있는지 감지 할 수있는 pmake도있었습니다. 개미가 아직 그렇게 할 수 있습니까?

PC에는 Turbo Pascal과 같은 놀라운 Borland 제품이있었습니다 (v4는 80 년대 중반에 나왔을 때 큰 변화였습니다).

재미있는 시간이었습니다. 그리고 흥미로운 가격. Windows 3 SDK 상자에는 운반 손잡이가 있었지만 들어 올리려면 양손이 필요합니다. 너무 많은 디스크와 1 피트 높이의 매뉴얼이 있습니다. 관계형 데이터베이스는 사용자 당 수천 달러, 유닉스 전쟁, 슬래시 키를 통한 스프레드 시트 전쟁이 필요합니다. 나는 이런 미친 저렴한 가격 / 무료로 지금 얻을 수있는 도구에 놀랐습니다.

이 중 가장 재미있는 부분은 Visual Studio 키 입력 명령 (CTRL-K + CTRL-C) 중 일부가 이전 Wordstar 명령이라는 것입니다. 내가 그것을 사용할 때마다 약간의 향수.

이십년 전에, 나는에 프로그래밍 된 GFA 기본 온 아타리 ST 1040 :

더 많은 키보드, 더 적은 마우스.

사람이 오래되었다고 느끼게 해 주셔서 감사합니다 :-)

당시에는 디버거와 makefile이있었습니다. 컴파일러에는 두꺼운 책이 있거나 많은 맨 페이지 집합 인 Unix가 있습니다. 대부분의 유닉스 개발자는 vi 또는 emacs를 사용했습니다. 당시에는 데스크톱 프로그래밍을하지 않았지만 더 적은 기능을 가진 IDE 인 컴파일러와 함께 제공된 편집기를 사용했다고 확신합니다. 동료, 서적 또는 잡지로부터 도움을 받았습니다.

20 년 전에 저는 BASIC에서 프로그래밍했습니다. BASICA와 GW BASIC이 IDE가 아니기 때문에 IDE가 없었습니다. 나중에 Quick BASIC을 보았을 때 매우 기뻤습니다. 개발에서 Copy and Paste 기능을 처음 사용할 때 매우 기뻤습니다. 나중에 그들은 QBASIC 컴파일러를 예전처럼 해석하지 못하도록 만들었고 너무 좋았지 만 C로 옮겨 Borland의 Turbo C IDE를 사용했습니다. 나는 이집트에 있었고 그때는 인터넷이 없었고 우리는 소프트웨어에서 약 1 년 뒤였다. 오늘 버전이 출시되면 약 1 년 후에 손에 올 것입니다. 이제는 훨씬 쉬워졌지만 당시 프로그래밍의 기쁨은 비교할 수 없었습니다. :)

"웹 연도"현상이 날짜 계산에 편향되어 있다고 생각합니다.

20 년 전 스몰 토크에서 프로그래밍하고있었습니다. 20 인치 화면이있는 Mac IIe에서 GUI 기반의 객체 지향 언어 중 하나이므로 곰 가죽과 석재를 얻으려면 그보다 몇 년 더 오래 가야한다고 생각합니다 -프로그래밍 시대를 맞이합니다.

40 년 전 저는 어커 스틱 커플러 스타일의 모뎀 (110 Baud baby!)이있는 텔레타이프 터미널을 사용하여 기본 프로그래밍을하고있었습니다. .

다음은 펀치 카드를 정리하기 전에 FORTRAN 프로그램을 작성하는 데 도움이되는 표준 양식입니다.

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

실수를 지울 수 있도록 연필을 사용하고 몇 단계를 잊어 버릴 경우를 대비하여 인쇄 된 설명 사이에 빈 줄을 남겨 두십시오.

(좋아, 아마도 1991 년이되기 전에는 조금 있었지만, 많이는 아니었다 ...)

글쎄, 모두 펀치 카드 에서 시작 했지만, 당신은 적어도 그 역사 수업에 대해 들었을 것입니다. 그러나 그것은 20 년 전으로 거슬러 올라갑니다.

디버깅을 위해? 방금 일어난 일을 확인하고 확인하는 데 도움이되는 많은 메시지 상자, 로그 파일 및 기타 출력 방법.

20 년 전 4GL 은 모든 분노였습니다.

놀랍게도, 일 20 년 전 모든되지 않은 것을 다른. 이제 30 년 전 ...

이 답변을 작성하면서 당시에는 10 살 밖에되지 않았지만 여전히 5.25 인치 플로피 디스크를 1MB 하드 드라이브 지원 IBM Headstart XT / AT PC로 흔든다는 점을 명심하십시오. 왜이 질문에 대답해야합니까?

내가 일하는 곳에서는 20 년 된 시스템과 코드 기반을 유지하므로 레거시 시스템, 개발 환경 및 코드로 작업 할 때 여전히 시간 왜곡이 발생합니다.

20 년 전에 저는 주로 C, Pascal로 코딩했습니다. DOS 플랫폼에는 Turbo C, Turbo Pascal이 있었으며 대부분은 디버거가 포함 된 완벽한 편집기로 단계별로 처리 할 수있었습니다. 내용은 실제 프로그래밍 자신을 명령 프롬프트에서 실행 VI + 컴파일러를 사용하는 것처럼, 나는 대부분의 프로그래머을 느낍니다.

당시 일부 프로그래밍 언어의 경우 프로그래밍이 훨씬 어려웠습니다. 나는 여전히 내 자신의 프로그래밍에서 이것의 흔적을 볼 수 있습니다 : print문장을 단계별로 실행하는 것보다 문장으로 테스트를 실행하는 것이 더 쉽다는 것을 알았습니다 .

불가리아어로 말할 수 있습니다.

당신이 생각하는 것과 달리, 불가리아는 컴퓨터 기술의 최고 국가 중 하나였습니다. 공산주의 블록의 일부인 소련은 컴퓨터 과학에 많은 돈을 투자하여 공산주의 블록 업계의 리더로 만들었습니다. 그러나 공산주의자들은 민간 기업을 용납하지 않았으며이 지역의 모든 것은 정부가 관리했습니다. 따라서 최근 몇 년 전 공산주의 블록이 무너지면서 안정적인 산업을 유지하기 위해 안정적인 산업을 유지하지 못했습니다. 그러나 차세대 전문가에게는 훌륭한 지식 유산이 남았습니다. 따라서 우리는 최신 기술에 대한 접근을 중단하지 않았으며 소프트웨어 개발은 ​​서방 국가와 다르지 않았습니다. 우리는 최신 첨단 도구와 프로그래밍 개념을 사용했습니다.

따라서 다른 사람들이 말하는 모든 것을 반복하지는 않지만 그 당시에는 IDE와 디버거가 훌륭했습니다.

개인적으로 Turbo Pascal과 Turbo C (Borland)를 사용했음을 기억합니다. 또한 그래픽 용 Autodesk 소프트웨어 (예 : 3d Studio 및 Animator).

그러나 지식의 원천은 주로 ​​책, 잡지, 동료 및 BBS를 통한 전자 잡지와 같이 더 제한적이었습니다. 인터넷은 대부분 curio였습니다. 일부는 유즈넷에 액세스 할 수 있었지만 업무에 거의 사용하지 않았습니다.

불과 20 년 전. 당신은 농담을해야합니다. 프로그래밍을 배우면서 1972 년에 디버거를 사용하고있었습니다. 분명히 내가 사용할 수 있었던 것은 오늘날만큼 좋지 않았다. 나는 그들이 오래 전에 존재했다고 의심합니다.
도구는 수년에 걸쳐 변경되어 더 좋아졌지만 당시에는 도구가 없다고 생각조차하지 않습니다.
디버거가없는 수준으로 돌아가려면 50 년대로 돌아 가야한다고 생각합니다.
내가 사용한 첫 번째로 좋은 디버거는 80 년대 VMS가있는 VAX였습니다. 거기에서 모든 것이 올라갔습니다.

이제 여러분이 좋아하는 대부분의 도구의 간단한 버전이 1991 년에 존재하지만 고르지 않게 배포 된 것을 볼 수 있습니다.

더 흥미로운 비교는 1981 년과 같습니다 : USENET 및 UUCP 및 ARPANET 네트워크를 포함하는 광범위하게 사용 가능한 소셜 프로세스의 시작. (인터넷의 TCP 플래그 데이는 1983 년이었습니다.)

더 흥미로운 비교는 1971 년과 같습니다. 현재 알고 있고 좋아하는 운영 체제의 초기 버전, 게시 (종이 뉴스 레터, 직접 참석 한 회의, 개인 연락처, 사용자 그룹과 코드 공유, 자기 테이프와 같은 매체 사용)를 기반으로하는 소셜 프로세스 ).

20 년 전에 저는 Windows 프로그래밍 용 OWL을 사용하여 Borland C ++에서 386을 코딩하고있었습니다.

내 컴퓨터에는 몇 MB의 RAM과 200MB의 하드 드라이브가 있습니다. 플로피 디스크에서 대부분의 소프트웨어를 설치할 수 있었지만 점점 더 많은 소프트웨어가 CD에 들어 왔습니다.

Borland에서 F8을 눌러 프로젝트를 "실행"하면 컴파일러가 매우 빠르게 작동하여 결과를 즉시 재생할 수 있습니다.

사무실에는 몇 시간마다 한 대의 PC가 소음에 시끄럽게 연결되고 (Trumpet WinSock 사용) 모든 사람의 이메일을 다운로드하는 PC가있었습니다.

우리는 무언가를 프로그래밍하는 방법을 알아낼 수 없었을 때 종종 책에서 답을 찾았습니다. Win32 API 책은 특히 유용했습니다.

실제로, 우리는 매우 생산적이었습니다 ... 그리고 IDE는 그 당시 꽤 빨리 작동했습니다! 그러나 그들은 훌륭한 리팩토링과 훌륭한 통합 테스트 도구가 없었습니다.

20 년 전에? 환상적인 드래그 앤 드롭 UI 빌더 및 프로젝트 관리자와 함께 멋진 IDE를 사용하고있었습니다. 꽤 좋은 OO 언어, 정말 좋은 GUI 객체, 많은 훌륭한 앱 및 터미널 윈도우가있어 Unix 쉘을 제공했습니다. 그리고 디버거,하지만 나는 약한 사람들 (또는 그들의 끔찍한 코드를 다루는)을위한 것이라고 동의합니다.

그것이 맥과 같은 소리라면, 그것은 현대 맥 OS로 변한 NeXT 개발 환경에 대해 이야기하고 있기 때문입니다. whippersnappers의 경우 여기에서 기록을 읽을 수 있습니다.

• http://en.wikipedia.org/wiki/NeXT
• http://en.wikipedia.org/wiki/Interface_Builder
• http://en.wikipedia.org/wiki/Project_Builder

참고로, 거기에 멋진 GUI 빌딩이 완전히 저를 망쳤다 고 말할 것입니다. Java에서 Swing 응용 프로그램을 개발하기 시작했을 때 누군가의 개가 오래된 GUI API 문서를 먹고 다시 던져 버린 것 같았습니다. 웹이 마침내 어딘가에 있음을 감사합니다.

나는 1981 년에 프로그래밍을 시작하여 30 년 전에 올 가을에 시작되었습니다.

1991 년에 저는 Apple Computer (일명 "Apple")에서 일했으며 Metrowerks라는 이름의 작은 캐나다 회사와 긴밀히 협력하고있었습니다.

Metrowerks는 C, C ++ 및 Pascal을위한 완벽한 IDE를 구축하고있었습니다. 이 환경은 Apple이 68K에서 PowerPC 프로세서로 성공적으로 전환하는 데 중요한 역할을했습니다.

필자는 Apple 직원이지만 몇 년 동안 Metrowerks의 제품 관리자로 Greg Galanos 및 Jean Belanger와 함께 제품 전략 등을 면밀히 협력했습니다. Apple과 타사 간의 강력한 파트너십이 Power Macintosh를 가능하게했습니다. 애플의 첫 번째 위대한 Mac 전환 (두 번째는 OS X 로의 전환)입니다.

1981 년에 UCSC에서 신입생 한 해를 맞이하여 PDP-11 / 70에서 실행되는 Unix Release 7 (버전 7 아님) 작업을 시작할 수있었습니다.

여기에 IDE가 없습니다! 몇 년 후까지는 버전 관리 기능이 없었습니다!

그것은 vi (그리고 vim은 선택이 아니 었습니다), cc, ln 및 make였습니다. "스마트 터미널"의 더욱 복잡한 TERMCAPS를 수용하기 위해 C 쉘 스크립트를 작성하고 소스를 C 쉘로 해킹하여 512 문자에서 1024 문자로 환경 변수의 크기를 늘 렸습니다.

상급 CIS 학생 인 Ted Goldstein의 교외 콘도 바닥에있는 라이온스 북 의 부트 레그 사본을 읽을 수있는 기회를 얻었습니다 . Ted는 Apple의 도구 부사장을 포함하여 매우 완전한 경력을 쌓았습니다.

1984 년 Mac과 MDS (Macintosh Development System)의 초판을 손에 넣었고이 새롭고 멋진 짐승을 프로그래밍하는 법을 배웠습니다.

많은 재미이었다. 시작하고 실행하는 것이 훨씬 쉬웠습니다. 그러나 Ruby와 같은 언어로 우리가 가진 힘은 놀랍습니다. 컴파일러 심볼 테이블에 해시 테이블을 작성하는 대신 기본 데이터 유형으로 오른쪽과 왼쪽을 사용하고 있습니다!

예, 재미 있었지만 다시는 가지 않겠습니다 ...

20 년 전에 IDE와 꽤 괜찮은 디버거가있는 AMOS로 코드를 작성했습니다 .

1991 년 에 X 터미널에서 UIMX라는 IDE / Framework를 사용 하여 Informatix RDBMS에 액세스하는 Motif 기반 응용 프로그램을 만들었습니다. 언어는 C였습니다.

버전 관리, 제작을위한 SCCS가있었습니다.

되돌아 보면 오늘날의 작업 방식과 크게 다르지 않습니다.

28 년 전 저는 6809 프로세서 (어떻게 든 기억하는 분들을 위해 Dragon 32에서)를 위해 16 진수로 직접 어셈블리 코드를 작성하고있었습니다. 결국에는 대부분 괜찮은 어셈블러를 작성했습니다.

디버거가 없었습니다. 작동하지 않으면 인쇄 코드를 추가하여 스택을 살펴보십시오. 긴 밤! 잘못된 줄이 적어 효율적인 코드가 도움이되었습니다.

그리고 요즘 Clearcase, Maven, Ant 및 VS를 배워야합니다. 모두 재미 있습니다 (그러나 나는 그리워합니다)

20 년 이요? 그 직전에 애플 랜드를 떠난 후 특정 시점에 PC 랜드에서만 일하고있었습니다. 당시에는 부유 한 아이들이 통합 디버깅 (Borland & Microsoft)을 포함한 완전한 IDE를 가지고 있었음을 기억합니다. 우리 중 나머지는 잘 작동했지만 "통합되지 않은"(믹스 소프트웨어, 다양한 쉐어웨어 컴파일러 공급 업체) 저가형 브랜드를 긁어 모았습니다. 마우스는 책상 위에 있었지만 거의 손대지 않았습니다. 텍스트 모드에서 보낸 시간의 90 % 듀얼 모니터 설정이 사라지기 시작했습니다 (초기에는 MDA 및 CGA 카드가 다른 I / O / 메모리 위치를 사용하는 것과 동일한 시스템에 단색 코딩 모니터와 컬러 "실행 중"모니터가 있음) DOS에서 동시에 실행). 초기 버전의 Windows는 다중 모니터에 만족하지 않았습니다.

인기있는 언어는 C, Pascal 및 Modula-2입니다. 사람들은 여전히 ​​로고와 기본을 사용했습니다. "Visual BASIC"은 마침내 BASIC을 죽이기 시작했습니다. 코볼과 롤 플레잉은 대학에서 가르치고있었습니다.

부유 한 아이들은 인터넷에서 USEnet을 사용하고 있었고, 가난한 아이들은 여전히 ​​로컬 BBS에 전화를 걸고 FIDOnet 그룹을 사용하고있었습니다. 컴퓨터).

70 년대에 처음 프로그래밍 한 컴퓨터는 Univac 1218 이었습니다. 1218은 미니멀리스트 경영진과 16 비트 워드 지향 페라이트 코어 메모리 (따라서 "코어 덤프"라는 용어)의 16K를 가졌습니다. 이차 저장은 자기 테이프 및 홀레리스 인코딩 된 80- 컬럼 펀치 카드를 통해 처리되었다. 이 기계는 산술에 대한 보완과 주소 지정에 대한 보완을 사용했습니다. 조명 된 푸시 버튼 스위치를 사용하여 표시되는 모든 레지스터의 내용이있는 전면 패널을 사용하여 프로그래밍하고 디버깅 할 수 있습니다. 이 CPU는 현대 표준에 의해 원시적 인 것처럼 보일 수 있지만 당시에는 매우 시원했습니다.

주제로 돌아 가기 : 저는 20 년 전에 대부분의 개발에 IDE를 사용하고있었습니다. 나는 IDE가 약한 사람들을위한 것이라고 믿는 저런 노인들 중 하나가 아닙니다. 좋은 IDE는 생산성 증폭기입니다.

20 년 전 저는 RMCOBOL-85를 프로그래밍하는 학생이었습니다.

파일 서버에 연결된 녹색 터미널을 사용하고있었습니다.

인터페이스는 메모장 스타일의 텍스트 편집기였습니다. 공상 비트가 없습니다. 또한 VI를 사용하도록 선택할 수있었습니다. 그래도하지 않았다.

아 좋은 날. :)

거의 20 년 전까지는 IBM PC와 Amiga 1000을 사용하여 Atari Lynx라는 C 코드 및 어셈블리를 크로스 컴파일했습니다. 문제의 프로그램은 일부 시스템 변수에 대해 1K의 47K (킬로바이트) 공간에서 5 개의 카지노 게임을 실행했습니다. 무려 16K는 이중 버퍼 비디오 용으로 예약되었습니다. "개발"시스템이 도착했을 때 화면을 한 가지 색으로 돌리고 스피커를 클릭하는 어셈블리 언어 예제 루틴이있었습니다. 그거였다. 텍스트를 원한다면 글씨체와 고유 한 텍스트 루틴을 만들어야했습니다. 네트워킹? 직접 드라이버를 작성하십시오. Dunno 왜, 그러나 그것의 어려움은 재미의 일부였습니다. 그것은 전혀 효과가 없었습니다.

농담 해? 80 년대 중반 후반에 Turbo Pascal에서 80286을 흔들 었습니다.

20 년 전에 저는 Interface Builder와 Objective-C를 사용하여 NeXTstep OS 용 데스크탑 출판 앱을 만드는 팀의 일원이었습니다. 그렇습니다. 인터넷 은 주변에 있었고 사용하기가 조금 어려웠지만 comp.sys.next에서 답을 찾아 게시 할 수있었습니다.

계약 개발자 기술 지원 담당자로서 1989 년 Sun에서 디버거를 디버깅 하고있었습니다 .

저는 거의 30 년 전에 IDE를 사용했습니다 – UCSD p-System / Apple Pascal. Wote Sundog : Apple Pascal 및 6502 어셈블리 (1982-84)를 사용하여 Apple II의 고정 레거시. 나만의 p-code / 6502 디스어셈블러도 작성했습니다. 그 문제에 대해 저는 1981 년 Lunar & Planetary Institute의 Northstar Horizon (Z-80) 마이크로 컴퓨터에서 UCSD p-System을 사용하고있었습니다.

1963 년 저는 캠퍼스에서 여름 일을하고있었습니다. 디지털 (DEC)이 만든 PDP-1 컴퓨터에있었습니다.

그리고 예, DDT라는 대화식 디버거가있었습니다. 중단 점을 설정하고 변수, 패치 코드를 검사 및 변경할 수 있습니다. 텍스트 편집기는 매우 원시적이었고 우리는 종종 오프라인 종이 테이프 기계를 대신 사용했습니다.

언어는 어셈블러였습니다. 기계에는 18 비트 단어의 4k와 같은 것이 있습니다. 운영 체제가 없습니다.

1971 년까지 나는 각각 36 비트의 262,144 워드를 가진 PDP-10에있었습니다. 10 명의 동시 사용자, TECO라는 텍스트 편집기, 여전히 DDT라고하는 디버거 및 Lisp, Fortran, Basic 및 Algol과 같은 언어를 지원하는 대화 형 시간 공유 시스템. TECO는 정말 강력했습니다. 텍스트 조작 프로그램을 작성할 수 있습니다.

PDP-10은 팔로 알토 리서치 (Palo Alto Research)에서 만든 유사한 기계의 기초가되었으며, 미래의 사무실이 탄생했습니다. 이더넷, 마우스 및 GUI, 이메일, 레이저 프린터 및 객체 지향 프로그래밍. 팔로 알토는 그 모든 것을 가지고있었습니다. PC보다 10 년 전.

이 많은 것들이 잊혀지고 그 이후 몇 년 동안 여러 번 재창조되었습니다. 물론 많은 새로운 것들도 있습니다.

1991 년으로 넘어 가서 VAX 작업을하고있었습니다. 필자가 필요할 때 PASCAL로 자료를 썼지 만 제 주요 언어는 SQL이었습니다. 또한 DCL과 Datatrieve를 스크립팅 언어로 사용했지만 해당 용어를 사용하지는 않았습니다.

그 당시 VAX에는 IDE가 없었습니다. 적어도 내가 일한 곳은 아닙니다. 그러나 텍스트 편집기, 컴파일러, 링커, 디버거 및 명령 언어는 모두 개발자가 모든 도구를 사용할 것이라는 아이디어로 작성되었습니다. 그들은 함께 잘 일했습니다. 주어진 도구가 툴바에 어디에 있는지 기억하는 것보다 몇 가지 명령을 기억하는 것이 더 이상 어렵지 않았습니다. 명령 재 호출을 통해 명령을 쉽게 다시 입력 할 수있었습니다.

VAX는 훌륭한 디버거를 가지고 있었지만 나는 그것을 배운 적이 없습니다. PASCAL을 사용하면 프로그램을 바로 시작할 수 있고 구조화 된 프로그래밍을 통해 디버거를 사용하지 않고도 버그를 쉽게 찾을 수 있습니다. SQL 디버깅은 완전히 다른 게임입니다.

VAX 작업 외에도 데스크톱 도구를 사용하여 데이터를 로컬로 조작했습니다. 이것들은 MS Office 도구 또는 그 선구자였습니다. 어려운 부분은 데스크톱 도구를 VAX의 데이터베이스에 저장된 데이터에 연결하는 것이 었습니다.