Jak zrobiono programowanie 20 lat temu? [Zamknięte]

Obecnie mamy wiele pomocy programistycznych, które ułatwiają pracę, w tym:

• IDE

• Debugery (linia po linii, punkty przerwania itp.)

• Skrypty Ant itp. Do kompilacji

• Strony takie jak StackOverflow pomagają w przypadku problemów z programowaniem

20 lat temu żadnej z tych rzeczy nie było w pobliżu. Jakich narzędzi używali ludzie do programowania i jak sobie poradzili bez tych nowszych narzędzi? Chciałbym dowiedzieć się więcej o tym, jak wtedy programowanie zostało zrobione.

20 lat temu, czyli w 1991 roku. To jest rok wydania Borland C ++ 2.0 IDE. Zintegrowany debugger (z linią po linii i punktami przerwania), automatyczne budowanie przy użyciu make.

Wyglądało to tak: http://www.ee.oulu.fi/research/tklab/courses/521419A/tc201_compile.png

Nie miałeś witryn takich jak Stackoverflow, ale dzięki IDE otrzymałeś kilka tysięcy stron dokumentacji w ładnie wydrukowanych książkach.

20 lat temu ... 1991 ...

Zobaczmy. Korzystałem z SunOS i VAX VMS.

Pisaliśmy kod za pomocą edytorów tekstu (vi lub edit).

Ja - osobiście - nie używam debugerów i nigdy tego nie robiłem. Niektórzy używali debugera adb w SunOS. Użyłem go kilka razy, aby odzyskać ślad stosu z pliku zrzutu pamięci. Nie mam pojęcia, co było dostępne w VAX VMS. W kodzie użyłem instrukcji print.

Użyliśmy make do kompilacji.

Czytamy dokumentację papierową, myślimy i przeprowadzamy eksperymenty. Rzeczywiście, to nadal działa. Przepełnienie stosu jest nadużywane przez kilka osób, które - z niewytłumaczalnych powodów - odmawiają przeprowadzania eksperymentów lub myślenia.

30 lat temu ... 1981 ...

Zobaczmy. Korzystałem z Univac Exec 8 i IBM OS.

Pisaliśmy kod za pomocą edytorów tekstowych (nie pamiętam Univaca, ale IBM był edytorem środowiska TSO)

Ja - osobiście - nie używam debugerów i nigdy tego nie robiłem. Te maszyny były „komputerami mainframe” i nie można było przez nie przejść niczego. Nie było „debuggera”. Trzeba było wstawić drukowane wyciągi do kodu.

Napisaliśmy skrypty do kompilacji.

Czytamy dokumentację papierową, myślimy i przeprowadzamy eksperymenty.

40 lat temu ... 1971 ...

Zobaczmy. Korzystałem z IBM 1620, który nie miał systemu operacyjnego.

Kod napisaliśmy przy użyciu perforowanych kart papierowych.

Debugowanie oznaczało jednoetapowy procesor. Rzadko było to pomocne, dlatego nauczyłem się wstawiać instrukcje „print” do mojego kodu.

Uruchamiamy ręcznie kompilator, aby wyprodukować talię perforowanych kart papierowych, które następnie uruchomiliśmy. „ręcznie” oznacza dosłownie ładowanie kart do czytnika kart w celu zainstalowania kompilatora lub asemblera. Następnie ładowanie kodu źródłowego do czytnika kart w celu wygenerowania kodu obiektowego. Następnie załaduj wynikowy kod obiektowy do czytnika kart, aby uruchomić program.

Czytamy dokumentację papierową, myślimy i przeprowadzamy eksperymenty.

„Get Off My Lawn You Rotten Kids”

• IDE. Prawie bezużyteczne. Uzupełnianie kodu może być zabawne, ale nie tak pomocne, jak twierdzą niektórzy ludzie. Kazałem ludziom powiedzieć, że VB jest akceptowalnym językiem ze względu na Visual Studio. Kolorowanie składni jest prawdopodobnie najbardziej przydatną funkcją, jaką kiedykolwiek wymyślono. Reszta powinna być opcjonalnymi dodatkami, abyśmy mogli się z nimi zrezygnować i zwolnić cykle pamięci i procesora.

  O kulach idą gorsze rzeczy, na których można polegać.

• Debugery. Bezużyteczny. Z wyjątkiem sytuacji, gdy definicja języka jest tak zła, że ​​semantyka jest tak mętna, że ​​nie można zrozumieć, co miało się stać. Na przykład VB. Kiedy potrzebny jest debugger, naprawdę czas na lepszy język.

  W oparciu o moje doświadczenie w nauczaniu programowania debuggery mogą być nieprzydatne. Dla niektórych osób prowadzą one do zamglonego myślenia i dziwnego empirycznego stylu programowania, w którym kod nie ma semantycznego znaczenia - nie ma znaczenia - po prostu czystą hackerską.

• Skrypty Ant itp. Do kompilacji. Kompilacja przyrostowa i łączenie nie jest tak naprawdę świetnym pomysłem. W przypadku bardzo złożonych języków jest to konieczny hack, ale tak naprawdę należy go postrzegać jako hack. To nie jest konieczne ani nawet pożądane.

  Lepszy język z mniejszym poleganiem na kompilacji przyrostowej wydaje się znacznie lepszą rzeczą niż wyrafinowane skrypty Ant.

• Strony takie jak Stackoverflow, aby pomóc, jeśli zbytnio utkniesz w błędzie. Czasami pomocna.

  Podobnie jak w przypadku debuggerów, istnieje możliwość, że niektórzy ludzie odniosą sukces dzięki zwykłemu błędowi szczęścia. To zła rzecz.

Hmm, twoje założenie nie jest do końca prawdziwe. Ostatnie dwa elementy są poprawne, ale 20 lat temu mieliśmy IDE i Debuggery.

W rzeczywistości debuggery zawsze istniały. Ich konstrukcja i zastosowanie ewoluowały, odkąd zespół Brooks zbudował stare komputery mainframe IBM, ponieważ wszyscy mamy własne dedykowane maszyny. Jednak teraz możemy mieć tę samą pracę debuggera dla wielu różnych języków (przykłady można znaleźć w projekcie GCC lub MS Visual Studio).

20 lat temu nie mieliśmy ANT, ale zdecydowanie mieliśmy Make. Było nawet kilka niekompatybilnych wersji tego narzędzia. Właśnie tak ludzie budowali swoje projekty.

I chociaż sieć nie była łatwo dostępna (wciąż był to projekt badawczy na uniwersytetach i wojsku), mieliśmy książki i czasopisma. Czasopisma zawierały najbardziej aktualne informacje, a książki zajmowały się teorią.

Cholerne dzieciaki. 1991? Naprawdę? Jak myślisz, co wtedy się działo? Mam na myśli, że Turbo Pascal nadal był trochę seksowny, Netware nadal był ważnym konkurentem dla systemu Windows, szybkie komputery były nadal mierzone w MHz, ale poza tym nie było zbyt wiele innego. Cofnij się o kolejne 10 lat, a mówisz o zielonych ekranach, ale były też IDE dla tych systemów.

Musisz wrócić do połowy lat 70., aby znaleźć karty ciosów i takie badziewie.

20 lat temu mieliśmy Borland Turbo Pascal i Turbo C ++, dość potężne IDE ze zintegrowanymi debuggerami, profilerami itp.

Było wiele świetnych narzędzi. Jak myślisz, jak zbudowano jądro Unixa? i skompilowane? oraz wszystkie inne ogromne aplikacje, takie jak Lotus 123, Corel Draw, Wordperfect, Xenix, MS Windows, X Windows, GNU, Kings Quest, Flight Simulator itp.

Unix miał wiele narzędzi zwiększających produktywność programistów, takich jak lint do analizy kodu, make do kompilacji i vi lub emacs do edycji. Za pomocą powłoki Korna (i prawdopodobnie innych) możesz zawiesić jednego edytora i przejść do innego edytora w 0,5 sekundy, i zrobić to na wolnym modemie z zielonym ekranem („obserwując, jak trawa rośnie”). Możesz debugować za pomocą dbx lub po prostu odczytać zrzut pamięci.

Jeśli masz pieniądze na terminal graficzny, możesz użyć X Windows i xdbx do naprawdę fantazyjnego debugowania.

Internet był tam, ale nie WWW. Mieliśmy anonimowe FTP, gopher i WAIS. I sieciowe grupy dyskusyjne, takie jak comp.lang.c, do publikowania pytań (teraz jest to głównie spam).

Te narzędzia były potężne. Czy widziałeś kiedyś przebudowę jądra przez dzień lub dwa? Budowałby makefile po makefile, budując wszystkie te zależności. Był nawet pmake, który mógł wykryć, jakie cele można budować równolegle. Czy mrówka może to zrobić?

Na PC były niesamowite produkty Borland, takie jak Turbo Pascal (v4 była ogromną zmianą, gdy pojawiła się w połowie lat 80-tych).

Były ciekawe czasy. I ciekawe ceny. Zestaw SDK systemu Windows 3 miał uchwyt do przenoszenia, ale aby podnieść dwie ręce, zbyt wiele dysków i stos podręczników o wysokości 1 stopy. Relacyjne bazy danych kosztują tysiące dolarów na użytkownika, wojny z Unixem, wojny z arkuszami kalkulacyjnymi o jeden klucz. Jestem zdumiony narzędziami, które mogę teraz dostać za tak szalone niskie ceny / za darmo.

Najśmieszniejsze jest to, że niektóre polecenia klawiszy Visual Studio (CTRL-K + CTRL-C) to stare polecenia Wordstar. Odrobina nostalgii za każdym razem, gdy jej używam.

20 lat temu programowałem w GFA Basic na Atari ST 1040 :

Więcej klawiatury, mniej myszy.

Dzięki, że facet poczuł się stary :-)

Debugery i makefile były wtedy w pobliżu. Kompilatory były dostarczane z grubymi książkami lub dla Uniksa - dużym zestawem stron podręcznika. Większość programistów Uniksa używała vi lub emacs. W tamtym czasie nie programowałem na pulpicie, ale jestem pewien, że korzystali z edytorów dostarczonych z kompilatorem, które były w istocie IDE z mniejszą liczbą funkcji. Otrzymujesz pomoc od kolegów, książek lub czasopism.

20 lat temu programowałem w języku BASIC. Nie miałem IDE, ponieważ BASICA i GW BASIC nie są IDE. Kiedy później zobaczyłem Quick BASIC, byłem bardzo szczęśliwy. Byłem bardzo podekscytowany, kiedy po raz pierwszy użyłem funkcji Kopiuj i Wklej podczas programowania. Później sprawili, że kompilator QBASIC nie interpreterował tak jak kiedyś i też był świetny, ale potem przeniosłem się do C i użyłem Turbo C IDE Borlanda. Zauważ, że jestem w Egipcie, a wtedy nie było internetu i byliśmy o rok za opóźnieniem w oprogramowaniu. Mam na myśli, że jeśli wersja zostanie wydana dzisiaj, przyjdzie mi do ręki około rok później. Teraz jest o wiele łatwiej, ale radość z programowania była wtedy nieporównywalna :)

Myślę, że zjawisko „roku internetowego” wpłynęło ujemnie na twoje obliczenia daty.

20 lat temu programowałem w Smalltalk - jednym z pierwszych obiektowych języków zorientowanych na GUI na Mac IIe z 20-calowym ekranem, więc myślę, że musisz cofnąć się o kilka lat, aby zdobyć skórki niedźwiedzia i kamień era programowania noży.

40 lat temu programowałem w języku podstawowym za pomocą terminala teletechnicznego, który miał modem typu acustic-coupler (110 Baud baby!) - znasz rodzaj, w którym wybrałeś telefon, a następnie włożyłeś zestaw słuchawkowy do gumowych misek na modemie .

Oto standardowy formularz, który pomoże Ci napisać programy FORTRAN przed zepsuciem kilku kart dziurkacza.

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

Użyj ołówka, aby usunąć błędy i pozostaw kilka pustych linii między wydrukowanymi wyciągami na wypadek, gdybyś zapomniał o niektórych krokach.

(OK, może to trochę przed 1991 rokiem, ale niewiele…)

Cóż, wszystko zaczęło się od kart perforowanych , ale jestem pewien, że przynajmniej słyszałeś o tej lekcji historii. Jednak to sięga ponad 20 lat temu.

Do debugowania? Wiele skrzynek wiadomości, plików dziennika i innych metod wyjściowych, aby pomóc sprawdzić i zobaczyć, co się właśnie wydarzyło.

20 lat temu wszystkie 4GL były na topie.

Zaskakujące, 20 lat temu nie było tak inaczej. Teraz 30 lat temu ...

Teraz, gdy piszę tę odpowiedź, należy pamiętać, że miałem wtedy zaledwie 10 lat, ale nadal dyskietki 5,25 "na moim 1 MB dysku twardym z włączonym komputerem IBM Headstart XT / AT. Dlaczego warto odpowiedzieć na to pytanie?

Ponieważ tam, gdzie pracuję, utrzymujemy 20-letni system i bazę kodu, więc wciąż jesteśmy w stanie wypaczenia czasu podczas pracy ze starszymi systemami, środowiskami programistycznymi i kodem.

20 lat temu programowałem, głównie w C, Pascal. Dla platformy DOS istniało Turbo C, Turbo Pascal, które były w większości kompletnymi edytorami z debuggerami umożliwiającymi przejście. Do prawdziwego programowania czuję, że większość programistów takich jak ja używa kompilatora vi +, uruchamianego z wiersza poleceń.

Programowanie było wtedy trochę trudniejsze, szczególnie w przypadku niektórych języków programowania. Nadal widzę ślady tego w moim własnym programowaniu: prowadzenie testów z printinstrukcjami jest dla mnie łatwiejsze niż przechodzenie przez instrukcje.

Mogę mówić w imieniu Bułgarii.

Wbrew pozorom Bułgaria była jednym z najlepszych krajów pod względem technologii komputerowych. Będąc częścią bloku komunistycznego, ZSRR zainwestował ogromne pieniądze w naszą informatykę, czyniąc go liderem w branży w bloku komunistycznym. Jednak komuniści nie tolerowali prywatnych firm i wszystko w tym obszarze było zarządzane przez rząd. Tak więc niedawny upadek bloku komunistycznego kilka lat temu pozostawił kraj bez stabilnych przedsiębiorstw, które utrzymałyby przemysł w dobrej kondycji. Jednak spuścizna wiedzy pozostała dla następnej generacji specjalistów. Dlatego nigdy nie przestaliśmy mieć dostępu do najnowszych technologii, a rozwój oprogramowania nie różnił się od krajów zachodnich. Wykorzystaliśmy najnowsze narzędzia i koncepcje programowania.

Dlatego nie powtórzę wszystkiego, co mówią inni, ale tak, w tym czasie istniały całkiem dobre IDE i debuggery (odpowiadające naturze tworzonego wówczas oprogramowania).

Pamiętam, że osobiście korzystałem z Turbo Pascal i Turbo C (firmy Borland). Również oprogramowanie Autodesk do grafiki (takie jak 3d Studio i Animator).

Jednak źródło wiedzy było bardziej ograniczone - głównie książki, czasopisma, koledzy i rzadko czasopisma elektroniczne za pośrednictwem BBS. Internet był głównie ciekawostką. Niektórzy mieli dostęp do Usenetu, ale rzadko używają go do pracy.

Zaledwie 20 lat temu. Chyba sobie żartujesz. Korzystałem z debuggerów w 1972 roku, kiedy uczyłem się programowania. Trzeba przyznać, że te, które udało mi się wykorzystać, nie były tak dobre jak dzisiaj. Podejrzewam, że istniały na długo wcześniej.
Narzędzia zmieniły się na przestrzeni lat i stały się lepsze, ale nawet nie myśl, że wtedy nie mieliśmy narzędzi.
Podejrzewam, że musisz wrócić do lat 50., aby dostać się do poziomu, na którym nie było debuggerów.
Pierwszym naprawdę dobrym debuggerem, którego użyłem, był VAX z VMS w latach 80. Stamtąd wszystko poszło w górę.

Do tej pory powinieneś zobaczyć, że proste wersje większości narzędzi, które lubisz, były obecne w 1991 roku, choć nierównomiernie rozmieszczone.

Bardziej interesujące są porównania z 1981 r .: początek szeroko dostępnych procesów społecznych obejmujących sieci USENET oraz UUCP i ARPANET. (Internetowy dzień flagi TCP miał miejsce w 1983 r.)

Jeszcze bardziej interesujące są porównania z 1971 r .: wczesne wersje systemów operacyjnych, które znasz i kochasz, procesy społeczne oparte na publikowaniu (papierowe biuletyny, konferencje z udziałem osobistym, udostępnianie kodu osobistym kontaktom, grupy użytkowników, korzystanie z mediów takich jak taśmy magnetyczne ).

20 lat temu kodowałem na 386 w Borland C ++ używając OWL do programowania Windows.

Moja maszyna miała kilka MB pamięci RAM i 200 MB dysku twardego. Mógłbym zainstalować większość oprogramowania z dyskietek - ale coraz więcej oprogramowania pojawiało się na CD.

Kiedy nacisnąłem F8, aby „uruchomić” mój projekt na Borland, kompilator działałby dość szybko i mogłem od razu grać z wynikami.

W biurze mieliśmy jeden komputer, który co kilka godzin głośno łączyłby się z Demonem (używając Trumpet WinSock) i pobierał e-maile wszystkich.

Kiedy nie mogliśmy wymyślić, jak coś zaprogramować, często szukaliśmy odpowiedzi w książce - książki Win32 API były szczególnie przydatne.

W rzeczywistości byliśmy dość produktywni ... a wtedy IDE działało dość szybko! Ale nie mieli ładnego refaktoryzacji i ładnych zintegrowanych narzędzi testowych.

20 lat temu? Korzystałem z ładnego IDE z fantastycznym narzędziem do budowania interfejsu użytkownika i menedżerem projektów. Był całkiem niezły język OO, zestaw naprawdę dobrych obiektów GUI, mnóstwo świetnych aplikacji i okno terminala, które dało mi solidną powłokę Unix. I debugger, ale zgadzam się, że są one dla słabo myślących (lub radzą sobie z ich ohydnym kodem).

Jeśli brzmi to trochę jak Mac, to dlatego, że mówię o środowisku programistycznym NeXT, które zmieniło się we współczesny Mac OS. Dla whippersnapperów możesz przeczytać historię tutaj:

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

Na marginesie powiem, że niesamowity budynek GUI całkowicie mnie zrujnował. Kiedy zacząłem tworzyć aplikacje Swing w Javie, to było tak, jakby czyjś pies zjadł przestarzały dokument interfejsu API GUI i rzucił go ponownie, a Sun to wysłał. Dzięki Bogu, sieć wreszcie gdzieś się znajduje.

Zacząłem programować w 1981 r., 30 lat temu tej jesieni.

W 1991 roku pracowałem w Apple Computer (obecnie zwany po prostu „Apple”) i ściśle współpracowałem z małą kanadyjską firmą Metrowerks.

Metrowerks budował błyskawiczne IDE dla C, C ++ i Pascala. To środowisko odegrało ważną rolę w pomyślnym przejściu Apple na procesor PowerPC z 68K.

Mimo że byłem pracownikiem Apple, przez kilka lat skutecznie działałem jako kierownik produktu Metrowerks, ściśle współpracując z Gregiem Galanosem i Jeanem Belangerem nad strategią produktu itp. To właśnie ścisłe partnerstwo między Apple a deweloperem zewnętrznym umożliwiło Power Macintosha przejście, pierwsze świetne przejście Apple na Maca (drugie przejście na OS X).

W 1981 roku zaczynałem swój pierwszy rok na UCSC i miałem okazję rozpocząć pracę nad Unix Release 7 (nie wersja 7) działającym na PDP-11/70.

Nie ma tutaj IDE! Cholera, nie mieliśmy kontroli wersji aż kilka lat później!

To było vi (i vim nie był wyborem), cc, ln i make. Pisał C Shell Scripts i hakował źródło do C Shell, aby zwiększyć rozmiar zmiennych środowiskowych od 512 znaków do 1024 znaków, aby dostosować się do coraz bardziej złożonych TERMCAPS naszych „inteligentnych terminali”

Miała okazję przeczytać bootlegową kopię Lions Book na podłodze mieszkania poza kampusem studenta CIS wyższej klasy, Teda Goldsteina. Ted rozpoczął bardzo pełną karierę, w tym wiceprezes ds. Narzędzi w Apple.

Zdobyłem komputer Mac w 1984 roku i wczesną edycję MDS (Macintosh Development System) i nauczyłem się programować tę nową, cudowną bestię.

Było dużo zabawy. O wiele łatwiej było rozpocząć pracę. Ale siła, jaką mamy w językach takich jak Ruby, jest niesamowita. Zamiast pisać tabelę skrótów dla mojej tabeli symboli kompilatorów, używam ich w prawo i lewo jako podstawowy typ danych!

Tak, to była świetna zabawa, ale nie wrócę ...

20 lat temu pisałem kod w AMOS , który miał IDE i całkiem niezły debugger.

W 1991 roku użyłem IDE / Framework o nazwie UIMX na X Terminal, tworząc aplikacje oparte na Motif, które uzyskiwały dostęp do Informatix RDBMS. Językiem był C.

Było SCCS do wersjonowania, budowania.

Patrząc wstecz, niewiele różni się od tego, jak dziś pracuję.

28 lat temu pisałem ręcznie kod asemblera dla procesora 6809 (w Dragon 32 dla tych z was, którzy go pamiętają) - ostatecznie napisałem dla niego w miarę przyzwoity asembler, co pomogło.

Nie było debuggera - jeśli to nie zadziałałoby, należy dodać kod wydruku, aby zobaczyć stos. Długie noce! Skuteczny kod pomógł, ponieważ było mniej wierszy, które mogły się nie udać

A teraz muszę się uczyć Clearcase, Maven, Ant i VS - cała dobra zabawa (ale tęsknię za dawnymi czasami)

20 lat, co? Działałem tylko na komputerach PC w tym konkretnym czasie po tym, jak opuściłem ziemię Apple na krótko przed tym. Pamiętam, że wtedy bogate dzieci miały w pełni rozbudowane środowiska IDE ze zintegrowanym debugowaniem (Borland i Microsoft). Reszta z nas skrobała wraz z niedrogimi markami, które działały dobrze, ale nie były tak „zintegrowane” (Mix Software, różni dostawcy kompilatorów shareware). Mysz leżała na biurku, ale rzadko była dotykana. 90% czasu spędzonego w trybie tekstowym. Konfiguracje z dwoma monitorami zaczęły zanikać (wcześniej było to powszechnie, że monitor kodowania monochromatycznego i kolorowy monitor „działający” w tym samym systemie, w którym karty MDA i CGA korzystały z różnych lokalizacji we / wy / pamięci i mogły zarówno być uruchomionym w tym samym czasie w DOS). Wczesne wersje systemu Windows nie były zadowolone z wielu monitorów.

Popularne języki to C, Pascal i Modula-2. Ludzie nadal używali Logo i BASIC. „Visual BASIC” wreszcie zaczął zabijać BASIC. COBOL i RPG były nauczane na studiach.

Bogate dzieci korzystały z USEnet w Internecie, biedne dzieci wciąż dzwoniły do ​​lokalnego BBS i korzystały z grup FIDOnet (zwykle przy 1200-2400 bps, modem 9600 bps nadal nie był dostępny dla większości ludzi, kosztując prawie tyle samo, co reszta komputer).

Pierwszym komputerem, który zaprogramowałem w latach siedemdziesiątych, był Univac 1218 . 1218 miał minimalistyczny wykonawczy i 16K 18-bitowej pamięci z rdzeniem ferrytowym zorientowanym na słowa (stąd termin „zrzut pamięci”). Wtórne przechowywanie odbywało się za pomocą taśmy magnetycznej i 80-kolumnowych kart dziurkowanych w Hollerith. Maszyna użyła swojego uzupełnienia do arytmetyki i drugiego do adresowania. Można go programować i debugować za pomocą panelu przedniego, na którym wyświetlana jest zawartość wszystkich rejestrów za pomocą podświetlanych przełączników przyciskowych. Ten procesor może wydawać się prymitywny według współczesnych standardów, ale wtedy był dla mnie bardzo fajny.

Wracając do tematu: Używałem IDE przez większość mojego rozwoju. Nie jestem jednym z tych cholernych starych facetów, którzy uważają, że IDE są dla słabych umysłów. Dobrym IDE jest wzmacniacz produktywności.

20 lat temu byłem studentem programującym RMCOBOL-85.

Korzystałem z zielonego terminala podłączonego do serwera plików.

Interfejs był edytorem tekstu w stylu notatnika. Żadnych wymyślnych kawałków. Mieliśmy również wybór użycia VI. Nigdy tego nie zrobiłem.

Ach, dobre dni. :)

Prawie 20 lat temu do dnia używałem komputera IBM i Amigi 1000 do krzyżowania kompilacji kodu C i montażu dla czegoś o nazwie Atari Lynx. W omawianym programie uruchomiono 5 gier kasynowych w 47 KB (to jest kilobajtów) przestrzeni z 1 KB dla niektórych zmiennych systemowych. Ogromne 16K zostało zarezerwowane dla podwójnego bufora wideo. Kiedy pojawił się system „programowania”, pojawiły się przykładowe procedury w języku asemblera, umożliwiające obrócenie ekranu o jeden kolor i kliknięcie głośnika. To było to. Jeśli chciałeś tekstu, musiałeś stworzyć czcionkę i własne procedury tekstowe. Sieć? Śmiało, po prostu napisz własne sterowniki. Nie wiem dlaczego, ale trudność była częścią zabawy. To niesamowite, że wszystko w ogóle działało.

Żartujesz? Kołysałem moim 80286 w Turbo Pascal w połowie / późnych latach 80-tych.

20 lat temu byłem częścią zespołu korzystającego z Konstruktora interfejsów i Objective-C do stworzenia aplikacji do publikowania na komputerze dla systemu operacyjnego NeXTstep. I tak, internet był w pobliżu, był trochę trudniejszy w użyciu - ale mogłem znaleźć i opublikować odpowiedzi na comp.sys.next.

I został debugowanie debuggerów na Słońcu w 1989 roku jako osoba Tech Support dewelopera umowa.

Korzystałem z IDE prawie 30 lat temu - UCSD p-System / Apple Pascal. Napisał Sundog: Frozen Legacy dla Apple II z Apple Pascal i montażem 6502 (1982-84). Napisałem również własny deasembler kodu p / 6502. W tym przypadku użyłem p-System UCSD na mikrokomputerze Northstar Horizon (Z-80) w Lunar & Planetary Institute w 1981 roku.

W 1963 roku pracowałem w letniej pracy na kampusie. Było na komputerze PDP-1 firmy Digital (DEC).

I tak, miał interaktywny debugger o nazwie DDT. Możesz ustawić punkt przerwania, badać i zmieniać zmienne, kod poprawki. Edytor tekstu był dość prymitywny i często zamiast tego używaliśmy maszyny do taśm papierowych offline.

Językiem był asembler. Maszyna miała około 4k 18-bitowych słów. Brak systemu operacyjnego.

W 1971 roku byłem na PDP-10 z 262 144 słowami po 36 bitów każdy. Interaktywny system podziału czasu, który obsługiwał może 10 równoczesnych użytkowników, edytor tekstów o nazwie TECO, debugger wciąż nazywany DDT oraz języki takie jak Lisp, Fortran, Basic i Algol. TECO było naprawdę potężne. Można w nim pisać programy do manipulacji tekstem.

PDP-10 był podstawą podobnej maszyny wykonanej w Palo Alto Research, gdzie narodziło się biuro przyszłości. Ethernet, mysz i GUI, e-mail, drukarka laserowa i programowanie obiektowe. Palo Alto miał to wszystko. Dziesięć lat przed komputerem.

Wiele z tych rzeczy zostało zapomnianych i od tego czasu kilka razy wymyślonych na nowo. I oczywiście jest też mnóstwo nowych rzeczy.

Przechodząc do 1991 roku, pracowałem nad VAX. Moim podstawowym językiem był SQL, chociaż w razie potrzeby pisałem różne rzeczy w PASCAL. Użyłem również DCL i Datatrieve jako języków skryptowych, chociaż nie użyliśmy tego terminu.

VAX nie miał wtedy IDE, przynajmniej nie tam, gdzie pracowałem. Ale edytor tekstu, kompilatory, konsolidator, debugger i język poleceń zostały zbudowane z myślą, że programista użyje ich wszystkich. Pracowali razem dobrze. Zapamiętanie kilku poleceń nie było trudniejsze niż zapamiętanie, gdzie dane narzędzie znajduje się na pasku narzędzi. Ponowne wpisywanie poleceń było łatwiejsze dzięki przywołaniu poleceń.

VAX miał doskonały debugger, ale nigdy go nie nauczyłem. PASCAL sprawił, że bardzo łatwo było zacząć programy od samego początku, a programowanie strukturalne ułatwiło zlokalizowanie błędu bez użycia debuggera. Debugowanie SQL to zupełnie inna gra.

Oprócz pracy nad VAX, użyłem narzędzi pulpitu do lokalnej manipulacji danymi. Były to albo narzędzia MS Office, albo ich prekursory, nie pamiętam. Trudną częścią było połączenie narzędzi pulpitu z danymi przechowywanymi w bazie danych VAX.