Naleze do systemu BannerPower

---

Jestes osoba na tej stronie od 20.VII.97.

---

REDMOND, WA BUSINESS WIRE (31 marca) - Korporacja Microsoft poinformowala we czwartek o przekazaniu wersji beta Windows TP, nowego telepatycznego systemu operacyjnego, do 1500 miejsc testowych rozsianych na calym swiecie.

Zaprojektowany z wykorzystaniem Microsoft C for Neurons (ukaze sie niebawem) Microsoft TP omija malo wygodny interfejs, wspoldzialajac bezposrednio z mozgiem uzytkownika. Za pomoca Microsoft MindMouse (myszki umyslowej), uzytkownik moze zwizualizowac sobie obrazy w swoim umysle, a aplikacja stowarzyszona z danym obrazem (lub inaczej - "ikona myslowa") zostanie natychmiast uruchomiona. Uzytkownik moze wizualizowac obrazy w celu utworzenia obrazow w formacie Windows Bitmap lub wmyslec tekst bezposrednio do dowolnej aplikacji pracujacej w systemie Windows.

Windows TP jest w pelni zgodny ze wszystkimi poprzednimi wersjami Windows. Dane przechowywane w systemie Windows TP moga byc skopiowane do pamieci krotkoterminowej Uzytkownika (The Windows TP Clipboard), lub przekazane bezposrednio do pamieci dlugoterminowej za pomoca nowego, 32-bitowego systemu DNA (Direct Neuron Access). Uzytkownik moze potem podlaczyc sie do innego systemu Windows TP w celu przeniesienia danych.

Microsoft zapowiedzial takze pierwsza aplikacje, zaprojektowana specjalnie dla systemu Windows TP. CyberMail jest systemem poczty mentalnej, umozliwiajacej przekazywanie informacji za pomoca mysli. Uzytkownik wizualizuje sobie osobe, lub znak firmy, do ktorej zamierza przekazac wiadomosc. Wersja beta tego systemu jest juz od kilku miesiecy testowana w firmie Microsoft.

Zalozona w roku 1975 firma Microsoft jest swiatowym liderem w dziedzinie oprogramowania dla komputerow osobistych. Microsoft oferuje szeroki wachlarz uslug i produktow przeznaczonych zarowno dla biznesu, jak i do uzytku osobistego. Kazdy z produktow jest projektowany z mysla o ulatwieniu i uprzyjemnieniu pracy kazdemu korzystajacemu z dobrodziejstw nowoczesnej techniki obliczeniowej.

KONTAKT: Microsoft Corporation Liz Waghtor, 206/555-8080 (adres CyberMail: niska, pekata pani o ognistoczerwonych wlosach z ogromna gula, rosnaca w prawym rogu wargi. Niebieski tatuaz na prawym ramieniu mowi: "Billy G. -- Mezczyzna dla Mnie").

NOWY JORK, Reuter (1 kwietnia) - wiele jeszcze trzeba dopracowac, zanim ostateczna wersja Windows TP bedzie sie mogla ukazac - mowia beta testerzy produktu. Testerzy zglaszaja m.in. liczne problemy zwiazane z ikonami myslowymi.

"Rybi ogon moze czasami oznaczac pewne pozyteczne rzeczy, ale nie Program Managera! To nie jest intuicyjne." - mowi Clyde Revlon, ekspert MIS Technology. Jej wspolpracownik, McBalmy twierdzi podobnie: "Ktokolwiek potrafi zrozumiec te ikony, wymaga leczenia. Terier faceta z Yorkshire z pewnoscia jest cudowny, ale... nie jako File Manager?! Zlotego Szukacza moge zrozumiec, ale ten sweter, ktory ubiera terrier, jest zbyt ostry. Pozwolcie mi nim sterowac."

Testerzy zglaszaja takze niebezpieczne usterki w systemie Direct Neuron Access. "Kolory, wacham kolory. Dobry piesek, dobry, idz do mamusi, dobrze?" powiedziala Maggie Ferreaux, konsultant. Inni testerzy byli mniej wyrozumiali. "Pracuje nad prezentacja, a tu nagle okazuje sie, ze jedyna rzecza, o jakiej jestem w stanie pomyslec, sa pierwsze strony ksiazki telefonicznej Miami, litery A do C. Stracilem trzy godziny, zanim udalo mi sie wreszcie wyrzucic ja z pamieci. W ten sposob nie da sie pracowac!" - zali sie Max Piernich, pracownik Dzialu Sprzedazy firmy Carp Technology.

Microsoft oficjalnie potwierdzil te informacje, dodajac, ze zadna wersja beta nie jest doskonala. Obiecal takze, ze zapewni opieke tego samego neurologa, ktory pracowal przy rekonwalescencji pracownikow dzialu Kontroli Jakosci firmy Microsoft, testujacych wczesne wersje produktu.

Potwierdzajac, ze blad typograficzny w tekscie zrodlowym Neural C moze dac nieprzewidziane efekty, a kontrola skladni kompilatora nie jest jeszcze dokladna, rzecznik prasowy Microsofta zdementowal pogloski, jakoby niedawny zgon kilku beta testerow mial zwiazek z bledem typograficznym, popelnionym podczas korzystania z procedury EXECUTE_PROGRAM_IMMEDIATE interfejsu Neural C.

Pogloska ta jest jedna z wielu towarzyszacych nie opublikowanemu jeszcze systemowi Windows TP. Mowi sie, ze programisci zamiast nazwy procedury EXECUTE_PROGRAM_IMMEDIATE omylkowo wpisywali EXECUTE_PROGRAMMER_IMMEDIATE, co mialo tragiczne konsekwencje.

Osoby z Microsoft, pragnace zachowac anonimowosc mowia: "to jest w koncu tylko wersja BETA i bledow nalezy oczekiwac.", "Nie mozemy przewidziec kazdego bledu, jaki popelni uztykownik." oraz "ktokolwiek uzywa nie udokumentowanych wywolan, robi to na wlasna odpowiedzialnosc".

Microsoft jest przekonany, ze Windows TP nie bedzie sprawial zadnych klopotow, przynajmniej jesli chodzi o wersje poprzedzajace 2.0. "W koncu nie otrzymalismy od beta-testerow ani jednej informacji o problemach. Nie ma zatem podstaw, aby uwazac, ze Windows TP jest produktem chybionym."

(Originally from Dave Coble)
Na podstawie artykulu w LaughWebie, przeklad EW.

No, Windows is not a virus. Here's what viruses do:

1. They replicate quickly - okay, Windows does that.
2. Viruses use up valuable system resources, slowing down the system as they do so - okay, Windows does that.
3. Viruses will, from time to time, trash your hard disk - okay, Windows does that too.
4. Viruses are usually carried, unknown to the user, along with valuable programs and systems. Sigh... Windows does that, too.
5. Viruses will occasionally make the user suspect their system is too slow (see 2) and the user will buy new hardware. Yup, that's with Windows, too.

Line Lotnicze AMIGA

Terminal lotniskowy jest ladny i kolorowy, z przyjacielskimi i milymi stewardesami, z latwym dostepem do samolotow i bezproblemowym startem. Dla bardziej wymagajacych podroznikow : moga oni podrozowac na wielu samolotach i odwiedzic wiele miejsc w tym samym czasie. Podczas tych wielokrotnych podrozy pasazer moze skozystac z lotow na linaiach MACa, DOSu, UNIXa, czy tez WINDOWSow.

Linie Lotnicze DOS

Sytuacja wyglada tak: Wszyscy pchaja samolot, az ten wzbije sie w powietrze i zacznie szybowac. Nastepnie wskakuja do niego i przez moment szybuja wraz z nim dopoty ten nie uderzy w ziemie. Potem od poczatku pchaja i szybuja itd...

Linie Lotnicze DOS z QEMM

Sytuacja jak wyzej, z tym ze z wieksza iloscia miejsca na nogi.

Linie Lotnicze MAC

Wszyscy na lotnisku, a wiec stewardesy, kapitanowie samolotow, bagazowi i urzednicy wygladaja tak samo, zachowuja sie tak samo i mowia w ten sam sposob. Zawsze, gdy o cos zapytasz, otrzymujesz odpowiedz, ze nie musisz tego wiedziec, nie chcesz tego wiedziec i ze wszystko bedzie zrobione bez twojej wiedzy - wiec zamknij sie.

Linie Lotnicze OS/2

Aby dostac sie na poklad samolotu musisz podstemplowac bilet 10 razy w dziesieciu roznych okienkach. Nastepnie musisz wypelnic ankiete, w ktorej wyjasnisz gdzie chcesz siedziec i czy powinno to wygladac jak na statku pasazerskim, w pociagu osobowym, czy tez w autobusie. Jezeli powiedzie Ci sie, dostaniesz sie na poklad i samolot szczesliwie wystartuje... bedziesz miec wspaniala podroz ... z wyjatkiem sytuacji, w ktorych zamarznie ster i klapy w pozycji, w ktorej bedziesz mial czas tylko na odmowienie modlitw zanim samolot zderzy sie z ziemia.

Linie Lotnicze WINDOWS

Lotniskowy terminal jest ladny i kolorowy, z milymi i pomocnymi stewardesami, z latwym dostepem do samolotu oraz bezproblemowym startem... potem samolot wybucha bez zadnego ostrzezenia...

Linie Lotnicze NT

Sytuacja wyglada tak: wszyscy wychodza na pas startowy, po drodze podaja haslo i kresla zblizony ksztalt samolotu. Nastepnie siadaja i robia halas jakby wlasnie nim lecieli.

Linie Lotnicze Unix

Kazdy przynosi jedna czesc samolotu ze soba na lotnisko. Potem wszyscy wynosza to na pas startowy i skladaja do kupy klocac sie ciagle o rodzaj samolotu, ktory buduja.

Do klienta (nowe linie lotnicze) przychodzi dealer sprzedajacy Amibusy.

Dealer:	...jak juz mowilem nasze samoloty sa najlepsze. Tansze od konkurencyjnych DC286, DC386, DC486 nie mowiac o tych latajacych trumnach DC-5...
Klient:	[slucha]
Dealer:	Nasz samolot moze leciec jednoczesnie w dwie strony...
Klient:	Niesamowite...
Dealer:	Uklad sterowania jest najgenialniejszy na swiecie. Daje pilotowi tyle mozliwosci... Swoja droga Pan wie jakie matoly lataja na DeCetach... Takiemu to wszystko podkladaja pod nos - tylko leci... (tu dealer przelyka sline z gorycza). Nie ma pojecia do jakiej finezji mozna dojsc pilotujac Amibusa.
Klient:	Powiedzmy, ze kupie Amibusa, czy moge nim...
	[tu dealer przerywa]
Dealer:	Jasne ze tak!!!
Klient:	...poleciec do Londynu?
Dealer:	Tak! ... Chociaz.. powiedzial Pan do Londynu? To dalej jak 50 km? W takim razie bedzie trzeba rozszerzyc stateczniki, standartowo montujemy po 1 m , ale jak pan chce leciec dalej to konieczne sa 2 m.
Klient:	[slucha]
Dealer:	Poza tym bedzie pan lecial nad woda? Radze zaopatrzyc sie w staly bak paliwa. Standartowo wyposazamy nasze samoloty w kanistry po O.8 tys. litrow. Rozumie pan... tak jest taniej. Ale trzeba dolewac w czasie lotu... Radze panu niech sobie pan zamontuje bak 80 tys litrow. Chociaz moze miec pan klopoty z kabelkiem paliwowym...
Klient:	Acha...
Dealer:	A w ogole to niech najlepiej pan pozyczy na ten lot DeCeta - one sie do takich nudnych zadan nadaja. Nie to co Amibusy... To sa maszyny... Prawdziwa finezja... zwrotne...
Klient:	Moj znajomy ma Amibusa A-500, czy moglbym od niego pozyczyc troche paliwa do mojego A-1200?
Dealer:	Lepiej nie. To tylko w tych kretynskich DeCetach do kazdego silnika mozna wlac to samo od DC-XT do DC-5. Wobraza pan sobie co to za marnotrawstwo? Po prostu brak ambicji. My stosujemy za kazdym razem rozwiazania unikatowe...
Klient:	Dobrze, na koniec jeszcze jedno pytanie, kto produkuje wasze samoloty?
Dealer:	...obecnie?
Klient:	tak
Dealer:	zwykle znajdujemy je na polach z kapusta.

(Happy Windows Bill) (Happy Windows Microsoft) So this is Windows And what must you do Another big upgrade Hard- and software too And so this is Windows I hope you have fun Spend hours and hours Just to get it to run A phenomenal upgrade The hype and the plugs Let's hope it's a good one Without any bugs And so this is Windows You've waited so long A superior product Bill Gates can't be wrong And so happy Windows Just pray it won't bomb Can't talk to the modem Or the new CD-ROM A phenomenal upgrade The hype and the plugs Let's hope it's a good one Without any bugs And so this is Windows All the old drivers fail Got the Microsoft Network Only can't read the mail And so happy Windows But must take it back Can't get it to work right Try OS/2 or Mac A mind-boggling upgrade The hype and the plugs It isn't a good one Has too many bugs Wait is over, but who wants it Wait is over now Happy Windows

MATEMATYK
jedzie do Afryki, odrzuca wszystko co nie jest sloniem i lapie jedna z pozostalych rzeczy

DOSWIADCZONY MATEMATYK
najpierw przeprowadza dowod isnienia co najmniej jednego slonia a potem postepuje tak jak MATEMATYK

PROFESOR MATEMATYKI
przeprowadza dowod isnienia co najmniej jednego slonia a jego zlapanie pozostawi jako temat pracy magisterskiej dla swoich studentow

PROGRAMISTA
wykona nastepujacy algorytm:

   GOTO Afryka, Przyladek Dobrej Nadziei

   REPEAT

    zlapany:=lap_zwierze;

    if zlapany<>slon then begin

     krok_na_zachod;

     if brzeg then begin

      krok_na_polnoc;

      GOTO zachodni brzeg

     end;

    end

   UNTIL zlapany=slon;

DOSWIADCZONY PROGRAMISTA
przed wykoneniem tego programu umiesci w Kairze jednego slonia, aby algorytm kiedys sie sakonczyl

PROGRAMISTA ASSEMBLEROWY
wykona ten sam algorytm, ale na czworakach

INZYNIER
lapie losowo napotkane zwierze i uznaje je za slonia, jesli wazy tyle, co ktorykolwiek ze znanych sloni (z dokladnoscia do 15%)

EKONOMISTA
nie lapie sloni: uwaza, ze slon zlapie sie sam, o ile tylko dobrze sie mu zaplaci

KONSULTANCI
nigdy w zyciu na nic nie polowali i nie beda polowac, ale za to oferuja swe uslugi jako doradcy dla polujacych

POLITYK
takze nie lapie sloni, ale podzieli sie sloniami, ktore zlapales, z ludzmi, ktorzy na niego glosowali

PRAWNIK
nie lapie sloni, tylko dyskutuje z innymi PRAWNIKAMI, do kogo naleza pozostawione przez slonie kupki

SPECJALISTA od PRAWA do PROGRAMOW
zwykle oglaszaja, ze cale stado nalezy do nich, jako dowod przedstawiajac szczegolny wyglad i zapach jednej z kupek

NACZELNY DYREKTOR
organizuje szeroko zakrojona polityke slonilowstwa bazujac na zalozeniu, ze slon to rodzaj szarej polnej myszy o duzo grubszym glosie

INSPEKTORZY z UBEZPIECZENIOWI
nie interesuja sie sloniami, ale podaza za innymi mysliwymi gromadzac dowody, ze ich samochody byly zaladowane niezgodnie z przepisami

HANDLOWIEC
nie lapie sloni, ale zajmuje sie uzgadnianiem kontraktow na dostawe sloni na dwa dni przet otwarciem sezonu polowan

SPRZEDAWCA OPROGRAMOWANIA
lapie pierwsze napotkane zwierze, wysyla do klienta i wystawia rachunek za slonia

SPRZEDAWCA SPRZETU (komputerowego)
lapie kroliki, maluje na szaro i sprzedaje slonie w wersji desk-top

na podstawie Bajtka

1. Uzywaj mnostwo zmiennych globalnych.
2. Nadawaj im tajemnicze nazwy np.: X27, a_gcl lub Horacy.
3. Pisz wszystko w jednym wielkim pliku .h
4. Implementuj caly program naraz.
5. Uzywaj makrodefinicji, zeby emulowac Pacal'a.
6. Zakladaj, ze kompilator zajmie sie wszystkimi szczegolami, ktore nie calkiem rozumiesz.

1. Jesli to mozliwe, nie rob tego, niech ktos inny to zrobi.
2. Zmieniaj podstawy.
3. Wstawiaj/usuwaj puste linie w losowych miejscach, rekompiluj i wykonaj.
4. Polej klawiature i monitor swiecona woda.
5. Zadzwon pod 997 i krzycz.
6. Jest jasne, ze "printf" jest uzyteczne, ale jest z pewnoscia niezdefiniowane.
7. Podlacz wszystko do CP/M.
8. Jesli ciagle nie dziala, przepisz od nowa w asemblerze. To nie usunie bledu, ale upewni cie, ze nikt inny go nie znajdzie i nie powie, ze jestes durniem.

• Nigdy nie pozostawiaj dyskietek w stacji dyskow, jako ze dane moga wycieknac z dyskietki powodujac korozje mechanizmow stacji dyskow. Dyskietki nalezy przechowywac zwiniete w pojemnikach na olowki.
• Dyskietki powinny byc czyszczone i woskowane raz na tydzien. Mikroskopijne opilki metalu (ktore mogly nagromadzic sie na powierzchni dyskietki) mozna usunac przesuwajac silny magnes tuz nad powierzchnia dyskietki. Opilki wbite w powierzchnie mozna usunac proszkiem do czyszczenia i mydlem. Przy woskowaniu dyskietek nalezy dbac, aby ich powierzchnia byla gladka. Pozwoli to na szybsze obracanie sie dyskietki (mniejsze opory powietrza) i tym samym szybszy dostep do danych.
• Nie zaginaj dyskietek, chyba, ze nie mieszcza sie do stacji dyskow. "Duze" dyskietki mozna zgiac i uzywac w "malych" stacjach.
• Nigdy nie wkladaj dyskietek ``do gory nogami'' do stacji. Dane moga spasc z powierzchni dyskietki i zablokowac precyzyjne mechanizmy stacji dyskow.
• Nie mozna wykonac back-up'u dyskietki przy pomocy maszyny kserograficznej. Jesli potrzebujesz back-up'u (kopia bezpieczenstwa) swoich danych po prostu wloz dwie dyskietki do stacji. Ilekroc bedziesz nagrywac swoj dokument, zapisze sie on na obu dyskietkach.
• Nie nalezy wkladac badz wyjmowac dyskietek ze stacji kiedy mruga na niej czerwone swiatelko. Moglo by to spowodowac rozmazanie tekstu, w skrajnych przypadkach czyniac go nieczytelnym. Czasami czerwona lampka mruga pomimo, ze stacja nie pracuje. Jest to tak zwany stan "zawieszenia" lub prosciej "zawieszenie". Jesli twoj system sie zawiesi, bedziesz zapewne musial wrzucic kilka monet zanim odzyskasz dostep do niego.
• Jesli twoja dyskietka jest pelna danych, a potrzebujesz wiecej miejsca, to wyjmij ja ze stacji dyskow i energicznie wstrzasaj przez okolo dwie minuty. Ubije to dane (kompresja danych) pozwalajac na zapisanie wiekszej ich ilosci. Nie zapomnij o zaklejeniu tasma klejaca wszystkich otworow w dyskietce, aby dane nie wypadly nimi w trakcie kompresji.
• Predkosc dostepu do danych mozna wydatnie zwiekszyc wycinajac wiecej otworow w koszulce dyskietki. Umozliwi to stacji dostep do dysku w wiekszej liczbie miejsc jednoczesnie.
• Dyskietek mozna uzywac jako podstawek pod szklanki z piwem (lub innymi napojami) o ile zostaly poprawnie nawoskowane. Pamietaj, aby potem wytrzec dyskietke do sucha.
• Nigdy nie uzywaj nozyczek i kleju do recznej edycji tekstu na dyskietkach. Dane na dyskietkach sa zbyt male, aby mozna je bylo zobaczyc golym okiem, i tak postepujac mozesz niechcacy wklejic kawalek calkiem innego dokumentu w sam srodek twojego tekstu. W takich przypadkach mozna uzywac zyletek i tasmy klejacej, o ile jestes wyposazony w mikroskop elektronowy.
• Okresowo nalezy spryskiwac dyskietki srodkiem owadobojczym, aby zapobiec rozmnazaniu sie wirusow.
• Jesli skladasz dyskietki do szafy i nie beda one uzywane przez dluzszy czas - nie zapomnij o przesypaniu ich naftalina.

1. You wake up at seven, save your life and continue sleeping thinking you'll wake up at ten and then continue from the saved state.
2. When you press a wrong button in the lift you try to find the Undo button and when you can't find it you are amazed about the poor user interface.
3. When writing a letter you write \n in the end of each line.
4. You've cut yourself while writing a program and before finding the first aid kit you first start the compilation.
5. You try to reboot yourself in the morning.
6. When reading a book you hit the SPACE key to turn page.
7. When you close a window your fingers automatically go to ALT-F4 position.
8. You write your cheques in hex.
9. When talking about round numbers you mean 0, 1, 2, 4, 8, 16, 32, 64,...
10. When the alarm clock goes off in the morning you do kill -9
11. You try to move a window to the background and you eventually notice it's actually a Post-It sticker.
12. The last thought when falling asleep is "Shutdown completed".
13. When having a mental breakdown you complain that your storage unit is fragmented.
14. In train you watch the landscape scrolling by.

YOU KNOW YOU'VE BEEN ON THE COMPUTER TOO LONG WHEN...

1. When you are counting objects, you go "0,1,2,3,4,5,6,7,8,9,A,B,C,D...".
2. When you dream in 256 palettes of 256 colors.
3. When asked about a bus schedule, you wonder if it is 16 or 32 bits.
4. When your wife says "If you don't turn off that damn machine and come to bed, then I am going to divorce you!", and you chastise her for for omitting the else clause.
5. You try to sleep, and think sleep(8 * 3600); /* sleep for 8 hours */
6. When you are reading a book and look for the scroll bar to get to the next page.
7. When after fooling around all day with routers etc., you pick up the phone and start dialing an IP number...
8. When you get in the elevator and double-click the button for the floor you want.
9. When not only do you check your Email more often than your paper mail, but you remember your {network address} faster than your postal one.
10. When you look for a icon to double-click to open your bedroom window.
11. When you go to balance your checkbook and discover that you're doing the math in octal.
12. When you look for a trash can icon for throwing garbage.

Chemik

Moim zdaniem, to cos z mieszanka, trzeba spuscic paliwo i zatankowac nowe.

Mechanik

Wydale mi sie, ze to cos ze swiecami, nalezaloby wymienic swiece i bedzie OK.

Informatyk

Wiecie co, a moze by tak sprobowac wysiasc i wsiasc jeszcze raz?

Pyt: Jaka jest inna nazwa na nalepke "Intel inside" nalepiana na Pentiumy
Odp: Znak ostrzegawczy.

Pyt: Jak nazwano serie instrukcji FDIV (dzielenie) na Pentium?
Odp: Kolejne przyblizenia.

Pyt: Jakiego algorytmu uzyl Intel do dzielenia w Petium?
Odp: "Zycie to pudelko czekoladek" (informator: Forrest Gump z Intela)

Pyt: Dlaczego Intel nie nazwal Petium (numerkiem) 586?
Odp: Probowali doda 486 i 100 na prototypie i wychodzilo im 585.999983605

Pyt: Wedlug Intela, Petium jest zgodne ze standardami IEEE 754 i 854 w zakresie obliczen zmiennoprzecinkowych. Jesli lecisz samolotem projektowanym przy uzyciu Petium, jak nalezy wymawia "IEEE"?
Odp: Aaaaaaaiiiiiiiiieeeeeeeeeeeee

P: Ilu technikow z Microsoftu potrzeba, aby wymienic zarowke?
O: Trzech. Dwoch trzyma drabine, podczas gdy jeden wbija zarowke w oprawke mlotkiem.

P: Ilu wiceprezydentow Microsoftu potrzeba, aby wymienic zarowke?
O: Osmiu. Jeden zajmuje sie zarowka, a siedmiu pilnuje, aby Microsoft dostal 2$ za kazda zarowke wymieniona na swiecie.

P: Ilu testerow Microsoftu potrzeba, aby wymienic zarowke?
O: My po prostu stwierdzamy stan ciemnosci w pokoju. Aktualnie nie wymieniamy zarowek. Poniewaz wynik poprzedniego testu rowniez byl niepomyslny (dead-bulb result), mamy pewnosc, ze projektanci juz pracuja nad poprawieniem bledu.

P: Ilu praconikow Dzialu Sprzedazy firmy Microsoft potrzeba, aby wymienic zarowke?
O: Mozemy wymienic zarowke w ciagu 7 do 10 dni roboczych. Jezeli zadzwonisz przed druga i zaplacisz dodatkowo 15$, bedziesz mial zarowke wymieniona na dzien nastepny. Nie zapomnij wpisac swojego nazwiska w prawym gornym rogu pudelka z zarowka!

P: Ilu uzytkownikow Windows potrzeba, aby wymienic zarowke?
O: Jednego, ale bedzie przy tym podkreslal, ze bylo to tak latwe, jak by bylo dla uzytkownika Macintosha.

P: Ilu menadzerow Microsoftu potrzeba, aby wymienic zarowke?
O: Powolalismy specjalna grupe robocza do przestudiowania problemu przepalania sie zarowek i okreslenia co my, jako pracownicy nadzoru, mozemy zrobic, aby zarowki pracowaly czysto i bezblednie.

P: Ilu programistow potrzeba, aby wymienic zarowke?
O: Ani jednego. Jest to problem sprzetowy.

P: Ilu programistow Microsoftu potrzeba, aby wymienic zarowke?
O: Zadnego. Bill Gates po prostu ustanowil Darkness(TM) jako nowy standard przemyslowy.

1. Jezeli cos moze sie popsuc, to z pewnoscia sie popsuje.
2. Jezeli cos moze sie popsuc w wielu miejscach, to pierwsze uszkodzenie wystapi tam, gdzie wyrzadzi najwiecej szkody.
3. Jezeli przewidziales cztery mozliwe awarie i zabezpieczyles sie przed nimi, to natychmiast wydarzy sie piata, na ktora nie byles przygotowany.
4. Sprawy pozostawione sobie samym zmieniaja sie ze zlych na gorsze.
5. Jezeli wydaje sie, ze wszystko dziala dobrze, to znaczy, ze cos przeoczyles.

Uogolnienie:

Natura zawsze stoi po stronie Zla.

Tzw. komentarz O'Toole'a do praw Murphy'ego:

Murphy byl optymista.

1. Wie wierz w cuda - POLEGAJ na nich!
2. Wymiary beda zawsze podane w najmniej uzytecznych jednostkach.
3. Kazdy przewod przyciety na dlugosc okaze sie za krotki.
4. Uklad zabezpieczajacy zniszczy uklad zabezpieczany.
5. Tranzystor zabezpieczony przez szybko dzialajacy bezpiecznik, zabezpieczy go - palac sie w pierwszej kolejnosci.
6. Cokolwiek zostanie upuszczone na uklad elektroniczny pod napieciem, spadnie zawsze tam, gdzie wyrzadzi najwiecej szkod.
7. Stopien glupoty Twojego postepowania jest wprost proporcjonalny do liczby przygladajacych Ci sie osob.
8. Prawdopodobienstwo wyczerpania sie baterii jest wprost proporcjonalny do zapotrzebowania na kalkulator.
9. Dowolne urzadzenie, uszkodzone w dowolny sposob ( z wyjatkiem calkowitego zniszczenia ), bedzie doskonale dzialalo w obecnosci wykwalifikowanego personelu naprawczego.
10. Element wybrany losowo z grupy o 99-procentowej wiarygodnosci, bedzie nalezal do pozostalego 1 procenta.
11. Koniecznosc znaczacych zmian w projekcie jest odwrotnie propor- cjonalna do czasu pozostajacego do oddania tego projektu.
12. Ciezar upuszczonej czesci jest wprost proporcjonalny do stopnia zlozonosci i ceny obszaru uderzonego.
13. Jezeli zakres bezpieczenstwa jest ustalony na podstawie doswiadczenia tworcow i obslugi naprawiajacej, to dowolny uzyt- kownik natychmiast znajdzie sposob, aby go przekroczyc.
14. Jezeli projekt zostal calkowicie okreslony i wszystkie sposoby badan zostaly wyczerpane, to niezalezny, niedoinformowany amator-eksperymentator odkryje fakt, ktory badz zlikwiduje zapotrzebowanie na ten projekt, badz rozszerzy jego zakres.

1. Zlorzeczenia to jedyny jezyk rozumiany przez wszystkich programistow (postulat Troutmana).
2. Prawa Makarijewa:
   • Pisanie programu komputerowego jest rozkosza.
   • Uruchamianie programu jest zmora.

3. Tzw. wniosek z praw Pierce'a:

   Jezeli program zostal skompilowany bezblednie za pierwszym razem, to na pewno nie bedzie dawal dobrych wynikow.

4. Drugie prawo Weinberga:

   Gdyby budowlani budowali domy w taki sam sposob, w jaki programisci pisza programy, to jeden dzieciol zniszczylby cala cywilizacje.

5. Prawa Weilera obslugi i konserwacji oprogramowania:
   • Kazdy dzialajacy program jest przestarzaly.
   • Kazdy program po kazdym uruchomieniu drozej kosztuje i zabiera wiecej czasu.
   • Jezeli program jest uzyteczny, to bedzie musial byc zmieniany.
   • Pelna dokumentacje maja tylko programy bezuzyteczne.
   • Kazdy program rozszerzy sie tak, aby zajac cala dostepna pamiec.
   • Wartosc programu jest odwrotnie proporcjonalna do jakosci wynikow jego pracy.
   • Zlozonosc programu rosnie do momentu przekroczenia zdolnosci programisty ten program konserwujacego.
6. Duzy, monolityczny program jest jak talerz makaronu: pociagnij za jedna nitke, a z drugiej strony bedzie sie sypac.
7. Autor programu nigdy nie przetestuje go wiarygodnie.
8. Nie ma programow bezblednie dzialajacych, a sa co najwyzej niedostatecznie przetestowane.
9. Dodanie urzadzenia przyspieszajacego do starego oprogramowania spowolni dzialanie tego oprogramowania.

REGULA REGUL

Kazdy moze ustalic nowa regule.

REGULA OBSERWATORA

Bardzo duzo mozna zauwazyc, gdy sie patrzy

REGULA NIEMOZLIWOSCI

Nie osiagnelibysmy nigdy niczego, gdybysmy zalozyli, ze najpierw trzeba usunac wszystkie przeszkody. Jezeli czegos nie mozna zrobic, to nalezy poprosic o to kogos, kto zwyczajnie nie wie, ze to nie jest mozliwe.

REMEDIUM NA PRAWA MURPHY'EGO

Jesli cos sie wydarza, to znaczy, ze jest to mozliwe. Zatem: W walce miedzy Toba a swiatem stan po stronie swiata.

REGULA DOKLADNOSCI

W poszukiwaniu rozwiazania problemu najbardziej pomocna jest znajomosc odpowiedzi.

REGULA MARTWEGO PRZEDMIOTU

Kazdy przedmiot, niezaleznie od polozenia, konfiguracji, budowy i przeznaczenia, moze w dowolnej chwili zadzialac w zupelnie nieoczekiwany sposob z przyczyn, ktore sa albo calkowicie niejasne, albo zupelnie tajemnicze.

PRAWO CHEOPA ( REGULA PLANOWANIA)

Nic nigdy nie zostalo zbudowane w zaplanowanym czasie lub zgodnie z kosztorysem.

PRAWA SELEKTYWNEJ GRAWITACJI

1. Przedmiot upuszczony spada tam, gdzie moze swym upadkiem wyrzadzic najwiecej szkody.
2. Prawdopodobienstwo upuszczenia i uszkodzenia cennego przedmiotu jest wprost proporcjonalne do jego wartosci.

UOGOLNIONE PRAWO GORY LODOWEJ

7/8 WSZYSTKIEGO pozostaje niewidoczne.

PIATA PRAKTYCZNA ZASADA HORNERA ( REGULA AMORTYZACJI)

Doswiadczenie jest wprost proporcjonalne do stopnia zniszczenia sprzetu.

REGULA ANALIZY I SYNTEZY

Po rozlozeniu i zlozeniu skomplikowanego mechanizmu zawsze pozostanie troche czesci, a mechanizm prawdopodobnie zadziala.

Rozmiary skaleczenia zyletka podczas golenia sa wprost proporcjonalne do donioslosci wydarzenia, ktore jest tego powodem.

Druga kolejka posuwa sie szybciej.

Wyscigi nie zawsze wygrywaja najszybsi, a bitwy najsilniejsi - ale tak nalezy obstawiac.

W wiekszosci przypadkow latwiej jest sie w cos wplatac, niz potem z tego wyplatac.

Nie istnieje taki problem - bez wzgledu na to, jak bylby skomplikowany - ktory po blizszym sie z nim zapoznaniem nie okazal sie jeszcze bardziej skomplikowany.

TWIERDZENIE STOCKMAYERA

Teza 1: Jesli problem wydaje sie latwy, to jest trudny.

Teza 2: Jesli problem wydaje sie trudny, to jego rozwiazanie jest prawie niemozliwe.

PRAWA PUDDERA

1. Wszystko, co zaczyna sie dobrze, konczy sie zle.
2. Wszystko, co zaczyna sie zle, konczy sie jeszcze gorzej.

REGULA WESTHEIMERA

Aby oszacowac czas niezbedny do rozwiazania danego zadania, nalezy okreslic czas potrzebny na rozwiazanie zadania, podwoic go i zmienic jednostke miary czasu na bezposrednio wyzsza - tak wiec na godzinne zadanie nalezy przeznaczyc dwa dni.

PRAWO PARKINSONA

Im wiecej mamy czasu na wykonanie konkretnej pracy, tym wiecej czasu praca ta zabierze.

PRAWO PETERA

W hierarchii kazdy pracownik stara sie wzniesc na swoj szczebel niekompetencji. Stad tez z biegiem czasu kazde stanowisko zostanie objete przez pracownika, ktory nie ma kompetencji do wykonywania swoich obowiazkow; prace zas wykonuja ci, ktorzy swojego szczebla niekompetencji jeszcze nie osiagneli.

PRAWO RUDINA

W sytuacji kryzysowej, kiedy trzeba wybierac miedzy roznymi alternatywami, wiekszosc ludzi wybierze rozwiazanie najgorsze.

PRAWO FINAGLESA

Jesli jakas praca zostala od poczatku zle zrobiona, wszelkie usilowania jej poprawienia jeszcze ja pogorsza.

PRAWO GUMPERTONA

Prawdopodobienstwo osiagniecia pozadanego wyniku jest odwrotnie proporcjonalne do stopnia pozadania tego wyniku.

PRAWO WEBSTERA

Kazda sprawa ma dwie strony - z wyjatkiem sytuacji, gdy rozwazajacy jest osobiscie zaangazowany: w takim przypadku istnieje tylko jedna strona.

PRAWO CORPPSA

Ilosc wykonanej pracy jest odwrotnie proporcjonalna do czasu spedzonego w biurze

PRAWO CAREY'A

Kazda organizacja - jesli temu nie przeciwdzialac - dazy do pograzenia sie w chaosie.

PRAWO ROBINSONA

W biurokracji awansuje sie za dzialalnosc, nie za wyniki.

PRAWO MATTHEWSA

Ci, ktorzy juz maja - dostana najwiecej.

REGULA PRZELOZONEGO

Nie ma zadan niemozliwych do wykonania dla kogos, kto nie musi tych zadan wykonywac.

REGULA MiMar'a

Im blizej jestes ukonczenia dlugiej przygodowki tym wieksze prawdopodobienstwo, ze ktos niepowolany kaze ci wylaczyc komputer.

In the beginning there was the computer.  And God said



%>Let there be light!



#Enter user id.



%>God



#Enter password.



%>Omniscient



#Password incorrect.  Try again.



%>Omnipotent



#Password incorrect.  Try again.



%>Technocrat



#And God logged on at 12:01:00 AM, Sunday, March 1.



%>Let there be light!



#Unrecognizable command.  Try again.



%>Create light



#Done



%>Run heaven and earth



#And God created Day and Night. And God saw there were 0 errors.



#And God logged off at 12:02:00 AM, Sunday, March 1.



#And God logged on at 12:01:00 AM, Monday, March 2.



%>Let there be firmament in the midst of water and light



#Unrecognizable command.  Try again.



%>Create firmament



#Done.



%>Run firmament



#And God divided the waters. And God saw there were 0 errors.



#And God logged off at 12:02:00 AM, Monday, March 2.



#And God logged on at 12:01:00 AM, Tuesday, March 3.



%>Let the waters under heaven be gathered together unto one place and let



the dry land appear and



#Too many characters in specification string. Try again.



%>Create dry_land



#Done.



%>Run firmament



#And God divided the waters. And God saw there were 0 errors.



#And God logged off at 12:02:00 AM, Tuesday, March 3.



#And God logged on at 12:01:00 AM, Wednesday, March 4.



%>Create lights in the firmament to divide the day from the night



#Unspecified type. Try again.



%>Create sun_moon_stars



#Done



%>Run sun_moon_stars



#And God divided the waters. And God saw there were 0 errors.



#And God logged off at 12:02:00 AM, Wednesday, March 4.



#And God logged on at 12:01:00 AM, Thursday, March 5.



%>Create fish



#Done



%>Create fowl



#Done



%>Run fish, fowl



#And God created the great sea monsters and every living creature that

 creepeth wherewith the waters swarmed after its kind and every winged =

 fowl after its kind. And God saw there were 0 errors.



#And God logged off at 12:02:00 AM, Thursday, March 5.



#And God logged on at 12:01:00 AM, Friday, March 6.



%>Create cattle



#Done



%>Create creepy_things



#Done



%>Now let us make man in our image



#Unspecified type. Try again.



%>Create man



#Done



%>Be fruitful and multiply and replenish the earth and subdue it and



  have dominion over the fish of the sea and over the fowl of the air and

  over every living thing that creepeth upon the earth



#Too many command operands. Try again.



%>Run multiplication



#Execution terminated. 6 errors.



%>Insert breath



#Done



%>Run multiplication



#Execution terminated. 5 errors.



%>Move man to Garden of Eden



#File Garden of Eden does not exist.



%>Create Garden.edn



#Done



%>Move man to Garden.edn



#Done



%>Run multiplication



#Execution terminated. 4 errors.



%>Copy woman from man



#Done



%>Run multiplication



#Execution terminated. 2 errors.



%>Create desire



#Done



%>Run multiplication



#And God saw man and woman being fruitful and multiplying in Garden.edn



#Warning: No time limit on this run. 1 errors.



%>Create freewill



#Done



%>Run freewill



#And God saw man and woman being fruitful and multiplying in Garden.edn



#Warning: No time limit on this run. 1 errors.



%>Undo desire



#Desire cannot be undone once freewill is created.



%>Destroy freewill



#Freewill is an inaccessible file and cannot be destroyed.



#Enter replacement, cancel, or ask for help.



%>Help



#Desire cannot be undone once freewill is created.



#Freewill is an inaccessible file and cannot be destroyed.



#Enter replacement, cancel, or ask for help.



%>Create tree_of_knowledge



#And God saw man and woman being fruitful and multiplying in Garden.edn



#Warning: No time limit on this run. 1 errors.



%>Create good, evil



#Done



%>Activate evil



#And God saw he had created shame.



#Warning system error in sector E95.  Man and woman not in Garden.edn. 1



errors.



%>Scan Garden.edn for man, woman



#Search failed.



%>Delete shame



#Shame cannot be deleted once evil has been activated.



%>Destroy freewill



#Freewill is an inaccessible file and cannot be destroyed.



#Enter replacement, cancel, or ask for help.



%>Stop



#Unrecognizable command. Try again



%>Break



%>Break



%>Break



#ATTENTION ALL USERS *** ATTENTION ALL USERS: COMPUTER GOING DOWN FOR

REGULAR DAY OF MAINTENANCE AND REST IN FIVE MINUTES. PLEASE LOG OFF.



%>Create new world



#You have exceeded your allocated file space. You must destroy old files

before new ones can be created.



%>Destroy earth



#Destroy earth: Please confirm.



%>Destroy earth confirmed



#COMPUTER DOWN *** COMPUTER DOWN. SERVICES WILL RESUME SUNDAY, MARCH 8 AT



6:00 AM. YOU MUST SIGN OFF NOW.



#And God logged off at 11:59:59 PM, Friday, March 6.

10. Drinks decaf diet soda.
9. Hasn't even considered charging by the hour.
8. Pours melted chocolate over a stack of floppies and yells, "I included an Easter Egg!"
7. When you ask how the project is coming along, he reads lines of code to you.
6. Uses the year of release for version numbering.
5. "Wanna open a file? Press Escape, Transfer, Load."
4. Thinks a voice-control interface is whispering, "Do it again, baby" at the monitor.
3. Uuencodes software and reads the file from right to left for secret messages.
2. Four words: Press F1 to reboot.
1. Wears pizza, eats T-shirts.

But, as usual, times change. We are faced today with a world in which little old ladies can get computers in their microwave ovens, 12 year old kids can blow Real Men out of the water playing Asteroids and Pac-Man, and anyone can buy and even understand their very own Personal Computer. The Real Programmer is in danger of becoming extinct, of being replaced by high-school students with TRASH-80s.

There is a clear need to point out the differences between the typical high-school junior Pac-Man player and a Real Programmer. If this difference is made clear, it will give these kids something to aspire to -- a role model, a Father Figure. It will also help explain to the employers of Real Programmers why it would be a mistake to replace the Real Programmers on their staff with 12 year old Pac-Man players (at a considerable salary savings).

The easiest way to tell a Real Programmer from the crowd is by the programming language he (or she) uses. Real Programmers use FORTRAN. Quiche Eaters use PASCAL. Nicklaus Wirth, the designer of PASCAL, gave a talk once at which he was asked "How do you pronounce your name?". He replied, "You can either call me by name, pronouncing it 'Veert', or call me by value, 'Worth'." One can tell immediately from this comment that Nicklaus Wirth is a Quiche Eater. The only parameter passing mechanism endorsed by Real Programmers is call-by-value-return, as implemented in the IBM/370 FORTRAN G and H compilers. Real programmers don't need all these abstract concepts to get their jobs done -- they are perfectly happy with a keypunch, a FORTRAN IV compiler, and a beer.

• Real Programmers do List Processing in FORTRAN.
• Real Programmers do String Manipulation in FORTRAN.
• Real Programmers do Accounting (if they do it at all) in FORTRAN.
• Real Programmers do Artificial Intelligence programs in FORTRAN.

The academics in computer science have gotten into the "structured programming" rut over the past several years. They claim that programs are more easily understood if the programmer uses some special language constructs and techniques. They don't all agree on exactly which constructs, of course, and the examples they use to show their particular point of view invariably fit on a single page of some obscure journal or another -- clearly not enough of an example to convince anyone. When I got out of school, I thought I was the best programmer in the world. I could write an unbeatable tic-tac-toe program, use five different computer languages, and create 1000 line programs that WORKED. (Really!) Then I got out into the Real World. My first task in the Real World was to read and understand a 200,000 line FORTRAN program, then speed it up by a factor of two. Any Real Programmer will tell you that all the Structured Coding in the world won't help you solve a problem like that -- it takes actual talent. Some quick observations on Real Programmers and Structured Programming:

• Real Programmers aren't afraid to use GOTOs.
• Real Programmers can write five page long DO loops without getting confused.
• Real Programmers like Arithmetic IF statements -- they make the code more interesting.
• Real Programmers write self-modifying code, especially if they can save 20 nanoseconds in the middle of atight loop.
• Real Programmers don't need comments -- the code is obvious.
• Since FORTRAN doesn't have a structured IF, REPEAT ... UNTIL, or CASE statement, Real Programmers don't have to worry about not using them. Besides, they can be simulated when necessary using assigned GOTOs.

What kind of operating system is used by a Real Programmer? CP/M? God forbid -- CP/M, after all, is basically a toy operating system. Even little old ladies and grade school students can understand and use CP/M.

Unix is a lot more complicated of course -- the typical Unix hacker never can remember what the PRINT command is called this week -- but when it gets right down to it, Unix is a glorified video game. People don't do Serious Work on Unix systems: they send jokes around the world on UUCP-net and write adventure games and research papers.

No, your Real Programmer uses OS/370. A good programmer can find and understand the description of the IJK305I error he just got in his JCL manual. A great programmer can write JCL without referring to the manual at all. A truly outstanding programmer can find bugs buried in a 6 megabyte core dump without using a hex calculator. (I have actually seen this done.)

OS is a truly remarkable operating system. It's possible to destroy days of work with a single misplaced space, so alertness in the programming staff is encouraged. The best way to approach the system is through a keypunch. Some people claim there is a Time Sharing system that runs on OS/370, but after careful study I have come to the conclusion that they were mistaken.

What kind of tools does a Real Programmer use? In theory, a Real Programmer could run his programs by keying them into the front panel of the computer. Back in the days when computers had front panels, this was actually done occasionally. Your typical Real Programmer knew the entire bootstrap loader by memory in hex, and toggled it in whenever it got destroyed by his program. (Back then, memory was memory -- it didn't go away when the power went off. Today, memory either forgets things when you don't want it to, or remembers things long after they're better forgotten.) Legend has it that Seymour Cray, inventor of the Cray I supercomputer and most of Control Data's computers, actually toggled the first operating system for the CDC7600 in on the front panel from memory when it was first powered on. Seymour, needless to say, is a Real Programmer.

One of my favorite Real Programmers was a systems programmer for Texas Instruments. One day, he got a long distance call from a user whose system had crashed in the middle of saving some important work. Jim was able to repair the damage over the phone, getting the user to toggle in disk I/O instructions at the front panel, repairing system tables in hex, reading register contents back over the phone. The moral of this story: while a Real Programmer usually includes a keypunch and lineprinter in his toolkit, he can get along with just a front panel and a telephone in emergencies.

In some companies, text editing no longer consists of ten engineers standing in line to use an 029 keypunch. In fact, the building I work in doesn't contain a single keypunch. The Real Programmer in this situation has to do his work with a "text editor" program. Most systems supply several text editors to select from, and the Real Programmer must be careful to pick one that reflects his personal style. Many people believe that the best text editors in the world were written at Xerox Palo Alto Research Center for use on their Alto and Dorado computers [3]. Unfortunately, no Real Programmer would ever use a computer whose operating system is called SmallTalk, and would certainly not talk to the computer with a mouse.

Some of the concepts in these Xerox editors have been incorporated into editors running on more reasonably named operating systems -- EMACS and VI being two. The problem with these editors is that Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in Women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. TECO, to be precise.

It has been observed that a TECO command sequence more closely resembles transmission line noise than readable text [4]. One of the more entertaining games to play with TECO is to type your name in as a command line and try to guess what it does. Just about any possible typing error while talking with TECO will probably destroy your program, or even worse -- introduce subtle and mysterious bugs in a once working subroutine.

For this reason, Real Programmers are reluctant to actually edit a program that is close to working. They find it much easier to just patch the binary object code directly, using a wonderful program called SUPERZAP (or its equivalent on non-IBM machines). This works so well that many working programs on IBM systems bear no relation to the original FORTRAN code. In many cases, the original source code is no longer available. When it comes time to fix a program like this, no manager would even think of sending anything less than a Real Programmer to do the job -- no Quiche Eating structured programmer would even know where to start. This is called "job security". Some programming tools NOT used by Real Programmers:

• FORTRAN preprocessors like MORTRAN and RATFOR. The Cuisinarts of programming -- great for making Quiche. See comments above on structured programming.
• Source language debuggers. Real Programmers can read core dumps.
• Compilers with array bounds checking. They stifle creativity, destroy most of the interesting uses for EQUIVALENCE, and make it impossible to modify the operating system code with negative subscripts. Worst of all, bounds checking is inefficient.
• Source code maintainance systems. A Real Programmer keeps his code locked up in a card file, because it implies that its owner cannot leave his important programs unguarded [5].

Where does the typical Real Programmer work? What kind of programs are worthy of the efforts of so talented an individual? You can be sure that no real Programmer would be caught dead writing accounts-receivable programs in COBOL, or sorting mailing lists for People magazine. A Real Programmer wants tasks of earth-shaking importance (literally!).

• Real Programmers work for Los Alamos National Laboratory, writing atomic bomb simulations to run on Cray I supercomputers.
• Real Programmers work for the National Security Agency, decoding Russian transmissions.
• It was largely due to the efforts of thousands of Real Programmers working for NASA that our boys got to the moon and back before the Russkies.
• The computers in the Space Shuttle were programmed by Real Programmers.
• Real Programmers are at work for Boeing designing the operating systems for cruise missiles.

The current plan for the Galileo spacecraft is to use a gravity assist trajectory past Mars on the way to Jupiter. This trajectory passes within 80 +/- 3 kilometers of the surface of Mars. Nobody is going to trust a PASCAL program (or PASCAL programmer) for navigation to these tolerances.

As you can tell, many of the world's Real Programmers work for the U.S. Government -- mainly the Defense Department. This is as it should be. Recently, however, a black cloud has formed on the Real Programmer horizon. It seems that some highly placed Quiche Eaters at the Defense Department decided that all Defense programs should be written in some grand unified language called "ADA" ((r), DoD). For a while, it seemed that ADA was destined to become a language that went against all the precepts of Real Programming -- a language with structure, a language with data types, strong typing, and semicolons. In short, a language designed to cripple the creativity of the typical Real Programmer. Fortunately, the language adopted by DoD has enough interesting features to make it approachable -- it's incredibly complex, includes methods for messing with the operating system and rearranging memory, and Edsgar Dijkstra doesn't like it [6]. (Dijkstra, as I'm sure you know, was the author of "GoTos Considered Harmful" -- a landmark work in programming methodology, applauded by Pascal Programmers and Quiche Eaters alike.) Besides, the determined Real Programmer can write FORTRAN programs in any language.

The real programmer might compromise his principles and work on something slightly more trivial than the destruction of life as we know it, providing there's enough money in it. There are several Real Programmers building video games at Atari, for example. (But not playing them -- a Real Programmer knows how to beat the machine every time: no challange in that.) Everyone working at LucasFilm is a Real Programmer. (It would be crazy to turn down the money of fifty million Star Trek fans.) The proportion of Real Programmers in Computer Graphics is somewhat lower than the norm, mostly because nobody has found a use for Computer Graphics yet. On the other hand, all Computer Graphics is done in FORTRAN, so there are a fair number people doing Graphics in order to avoid having to write COBOL programs.

Generally, the Real Programmer plays the same way he works -- with computers. He is constantly amazed that his employer actually pays him to do what he would be doing for fun anyway (although he is careful not to express this opinion out loud). Occasionally, the Real Programmer does step out of the office for a breath of fresh air and a beer or two. Some tips on recognizing real programmers away from the computer room:

• At a party, the Real Programmers are the ones in the corner talking about operating system security and how to get around it.
• At a football game, the Real Programmer is the one comparing the plays against his simulations printed on 11 by 14 fanfold paper.
• At the beach, the Real Programmer is the one drawing flowcharts in the sand.
• A Real Programmer goes to discos to watch the light shows.
• At a funeral, the Real Programmer is the one saying "Poor George. And he almost had the sort routine working before the coronary."
• In a grocery store, the Real Programmer is the one who insists on running the cans past the laser checkout scanner himself, because he never could trust keypunch operators to get it right the first time.

What sort of environment does the Real Programmer function best in? This is an important question for the managers of Real Programmers. Considering the amount of money it costs to keep one on the staff, it's best to put him (or her) in an environment where he can get his work done.

The typical Real Programmer lives in front of a computer terminal. Surrounding this terminal are:

• Listings of all programs the Real Programmer has ever worked on, piled in roughly chronological order on every flat surface in the office.
• Some half-dozen or so partly filled cups of cold coffee. Occasionally, there will be cigarette butts floating in the coffee. In some cases, the cups will contain Orange Crush.
• Unless he is very good, there will be copies of the OS JCL manual and the Principles of Operation open to some particularly interesting pages.
• Taped to the wall is a line-printer Snoopy calender for the year 1969.
• Strewn about the floor are several wrappers for peanut butter filled cheese bars -- the type that are made pre-stale at the bakery so they can't get any worse while waiting in the vending machine.
• Hiding in the top left-hand drawer of the desk is a stash of double-stuff Oreos for special occasions.
• Underneath the Oreos is a flow-charting template, left there by the previous occupant of the office. (Real Programmers write programs, not documentation. Leave that to the maintainence people.)

• No Real Programmer works 9 to 5. (Unless it's the ones at night.)
• Real Programmers don't wear neckties.
• Real Programmers don't wear high heeled shoes.
• Real Programmers arrive at work in time for lunch.
• A Real Programmer might or might not know his wife's name. He does, however, know the entire ASCII (or EBCDIC) code table.
• Real Programmers don't know how to cook. Grocery stores aren't open at three in the morning. Real Programmers survive on Twinkies and coffee.

What of the future? It is a matter of some concern to Real Programmers that the latest generation of computer programmers are not being brought up with the same outlook on life as their elders. Many of them have never seen a computer with a front panel. Hardly anyone graduating from school these days can do hex arithmetic without a calculator. College graduates these days are soft -- protected from the realities of programming by source level debuggers, text editors that count parentheses, and "user friendly" operating systems. Worst of all, some of these alleged "computer scientists" manage to get degrees without ever learning FORTRAN! Are we destined to become an industry of Unix hackers and Pascal programmers?

From my experience, I can only report that the future is bright for Real Programmers everywhere. Neither OS/370 nor FORTRAN show any signs of dying out, despite all the efforts of Pascal programmers the world over. Even more subtle tricks, like adding structured coding constructs to FORTRAN have failed. Oh sure, some computer vendors have come out with FORTRAN 77 compilers, but every one of them has a way of converting itself back into a FORTRAN 66 compiler at the drop of an option card -- to compile DO loops like God meant them to be.

Even Unix might not be as bad on Real Programmers as it once was. The latest release of Unix has the potential of an operating system worthy of any Real Programmer -- two different and subtly incompatible user interfaces, an arcane and complicated teletype driver, virtual memory. If you ignore the fact that it's "structured", even 'C' programming can be appreciated by the Real Programmer: after all, there's no type checking, variable names are seven (ten? eight?) characters long, and the added bonus of the Pointer data type is thrown in -- like having the best parts of FORTRAN and assembly language in one place. (Not to mention some of the more creative uses for #define.)

No, the future isn't all that bad. Why, in the past few years, the popular press has even commented on the bright new crop of computer nerds and hackers ([7] and [8]) leaving places like Stanford and M.I.T. for the Real World. From all evidence, the spirit of Real Programming lives on in these young men and women. As long as there are illdefined goals, bizarre bugs, and unrealistic schedules, there will be Real Programmers willing to jump in and Solve The Problem, saving the documentation for later. Long live FORTRAN!

I would like to thank Jan E., Dave S., Rich G., Rich E. for their help in characterizing the Real Programmer, Heather B. for the illustration, Kathy E. for putting up with it, and atd!avsdS:mark for the initial inspriration.

REFERENCES
[1] Feirstein, B., Real Men Don't Eat Quiche, New York, Pocket Books, 1982.
[2] Wirth, N., Algorithms + Datastructures = Programs, Prentice Hall, 1976.
[3] Xerox PARC editors . . .
[4] Finseth, C., Theory and Practice of Text Editors - or - a Cookbook for an EMACS, B.S. Thesis, MIT/LCS/TM-165, Massachusetts Institute of Technology, May 1980.
[5] Weinberg, G., The Psychology of Computer Programming, New York, Van Nostrabd Reinhold, 1971, page 110.
[6] Dijkstra, E., On the GREEN Language Submitted to the DoD, Sigplan notices, Volume 3, Number 10, October 1978.
[7] Rose, Frank, Joy of Hacking, Science 82, Volume 3, Number 9, November 1982, pages 58 - 66.
[8] The Hacker Papers, Psychology Today, August 1980.

• Real Computer Scientists don't write code. They occasionally tinker with programming systems, but those are so high level that they hardly count (and rarely count accurately, precision is for applications).
• Real Computer Scientists don't comment their code. The identifiers are so long they can't afford the disk space.
• Real Computer Scientists don't write the user interface, they merely argue about what they should look like.
• Real Computer Scientists don't eat quiche. They shun Schezuan food since the hackers discovered it. Many Real Computer Scientists consider eating an implementation detail. (Others break down and eat with the hackers, but only if they can have ice cream for dessert).
• If it doesn't have a programming environment complete with interactive debugger, structure editor and extensive cross module type checking, Real Computer Scientists won't be seen tinkering with it. They may have to use it to balance their checkbooks, as their own systems can't.
• Real Computer Scientists don't program in assembler. They don't write in anything less portable than a number two pencil.
• Real Computer Scientists don't debug programs, they dynamically modify them. This is safer, since no one has invented a way to do anything dynamic to FORTRAN, COBOL or BASIC.
• Real Computer Scientists like C's structured constructs, but they are suspicious of it because it's compiled. (Only Batch Freaks and Efficiency Weirdos bother with compilers, they're soooo un- dynamic).
• Real Computer Scientists play Go. They have nothing against the concept of mountain climbing, but the actual climbing is an implementation detail best left to programmers.
• Real Computer Scientists admire ADA for its overwhelming esthetic value, but they find it difficult to actually program in, as it is much too large to implement. Most Computer Scientists don't notice this because they are still arguing over what else to add to ADA.
• Real Computer Scientists work from 5 pm to 9 am because that's the only time they can get the 8 megabytes of main memory they need to edit specs. (Real work starts around 2 am when enough MIPS are free for their dynamic systems). Real Computer Scientists find it hard to share 3081s when they are doing 'REAL' work.
• Real Computer Scientists only write specs for languages that might run on future hardware. Nobody trusts them to write specs for anything Homo Sapiens will ever be able to fit on a single planet.
• Real Computer Scientists like planning their own environments to use bit mapped graphics. Bit mapped graphics is great because no one can afford it, so their systems can be experimental.
• Real Computer Scientists regret the existence of PL/1, PASCAL and LISP. ADA is getting there, but it still allows people to make mistakes.
• Real Computer Scientists love the concept of users. Users are always real impressed by the stuff computer scientists are talking about; it sure sounds better than the stuff they are being forced to use now.
• Real Computer Scientists despise the idea of actual hardware. Hardware has limitations, software doesn't. It's a real shame that Turing machines are so poor at I/O.
• Real Computer Scientists love conventions. No one is expected to lug a 3081 attached to a bit map screen to a convention, so no one will ever know how slow their systems run.

Real Software Engineers Don't Read Dumps

• Real Software Engineers don't read dumps. They never generate them, and on the rare occasions that they come across them, they are vaguely amused.
• Real Software Engineers don't comment their code. The identifiers are so mnemonic they don't have to.
• Real Software Engineers don't write applications programs, they implement algorithms. If someone has an application that the algorithm might help with, that's nice. Don't ask them to write the user interface, though.
• Real Software Engineers eat quiche.
• If it doesn't have recursive function calls, Real Software Engineers don't program in it.
• Real Software Engineers don't program in assembler. They become queasy at the very thought.
• Real Software Engineers don't debug programs, they verify correctness. This process doesn't necessarily involve executing anything on a computer, except perhaps a Correctness Verification Aid package.
• Real Software Engineers like C's structured constructs, but they are suspicious of it because they have heard that it lets you get "close to the machine."
• Real Software Engineers play tennis. In general, they don't like any sport that involves getting hot and sweaty and gross when out of range of a shower. (Thus mountain climbing is Right Out). They will occasionally wear their tennis togs to work, but only on very sunny days.
• Real Software Engineers admire PASCAL for its discipline and Spartan purity, but they find it difficult to actually program in. They don't tell this to their friends, because they are afraid it means they are somehow Unworthy.
• Real Software Engineers work from 9 to 5, because that is the way the job is described in the formal spec. Working late would feel like using an undocumented external procedure.
• Real Software Engineers write in languages that have not actually been implemented for any machine, and for which only the formal spec (in BNF) is available. This keeps them from having to take any machine dependencies into account. Machine dependencies make Real Software Engineers very uneasy.
• Real Software Engineers don't write in ADA, because the standards bodies have not quite decided on a formal spec yet.
• Real Software Engineers like writing their own compilers, preferably in PROLOG (they also like writing them in unimplemented languages, but it turns out to be difficult to actually RUN these).
• Real Software Engineers regret the existence of COBOL, FORTRAN and BASIC; PL/1 is getting there, but it is not nearly disciplined enough; far too much built-in function.
• Real Software Engineers aren't too happy about the existence of users, either. Users always seem to have the wrong idea about what the implementation and verification of algorithms is all about.
• Real Software Engineers don't like the idea of some inexplicable and greasy hardware several aisles away that may stop working at any moment. They have a great distrust of hardware people, and wish that systems could be virtual at ALL levels. They would like personal computers (you know no one's going to trip over something and kill your DFA in mid-transit), execpt that they need 8 megabytes to run their Correctness Verification Aid packages.
• Real Software Engineers think better while playing WFF 'N' PROOF.

Real Programmers Don't Write Specs.

• Real Programmers don't write specs -- users should consider themselves lucky to get any programs at all and take what they get.
• Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.
• Real Programmers don't write application programs, they program down to the bare metal. Application programming is for feebs who can't do systems programming.
• Real Programmers don't eat quiche. They eat Twinkies, and Szechwan food.
• Real Programmers don't write in COBOL. COBOL is for wimpy applications programmers.
• Real Programmers' programs never work right the first time. But if you throw them on the machine they can be patched into working in "only a few" 30-hour debugging sessions.
• Real Programmers don't write in FORTRAN. FORTRAN is for pipe stress freaks and crystallography weenies.
• Real Programmers don't work 9 to 5. If any Real Programmers are around at 9 AM, it's because they were up all night.
• Real Programmers don't write in BASIC. Actually, no programmers write in BASIC, after the age of 12.
• Real Programmers don't write in PL/1. PL/1 is for programmers who can't decide whether to write in COBOL or FORTRAN.
• Real Programmers don't write in APL. Any fool can be obscure in APL.
• Real Programmers don't play tennis, or any other sport that requires you to change clothes. Mountain climbing is OK, and Real Programmers wear their climbing boots to work in case a mountain should suddenly spring up in the middle of the machine room.
• Real Programmers don't write in PASCAL, or BLISS, or ADA, or any of those pinko computer science languages. Strong typing is for people with weak memories.
• Real Programmers know better than the users what they need.
• Real Programmers think structured programming is a communist plot.
• Real Programmers don't use schedules. Schedules are for manager's toadies. Real Programmers like to keep their managers in suspense.
• Real Programmers think better while playing ADVENTURE.
• Real Programmers do it middle-out.
• Real Programmers enjoy machine coding PASCAL compilers for their micros which they improve but never use.
• Real Programmers enjoy getting CP/M to work on 370 machines and MVS on their ZX81s.
• Real Programmers write their own assemblers, preferably in LISP.
• Real Programmers never get annoyed by security systems, they turn off the RACF bits and leave unsigned messages in the security data sets.
• Real Programmers never update the source to reflect the ZAPs, after all, it will have changed again tomorrow.

  10 PRINT "HELLO WORLD"

  20 END

  program Hello(input, output)

    begin

      writeln('Hello World')

    end.

  (defun hello

   (print

      (cons 'Hello (list 'World))))

  #include "stdio.h"

  void main(void)

  {

    char *message[] = {"Hello ", "World"};

    int i;



    for(i = 0; i < 2; ++i)

      printf("%s", message[i]);

    printf("\n");

  }

  #include "iostream.h"

  #include "string.h"



  class string

  {

  private:

    int size;

    char *ptr;



  public:

    string() : size(0), ptr(new char('\0')) {}



    string(const string &s) : size(s.size)

    {

      ptr = new char[size + 1];

      strcpy(ptr, s.ptr);

    }



    ~string()

    {

      delete [] ptr;

    }



    friend ostream &operator <<(ostream &, const string &);

    string &operator=(const char *);

  };



  ostream &operator<<(ostream &stream, const string &s)

  {

    return(stream << s.ptr);

  }



  string &string::operator=(const char *chrs)



    if (this != &chrs)

    {

      delete [] ptr;

     size = strlen(chrs);

      ptr = new char[size + 1];

      strcpy(ptr, chrs);

    }

    return(*this);

  }



  int main()

  {

    string str;



    str = "Hello World";

    cout << str << endl;



    return(0);

  }

  [

  uuid(2573F8F4-CFEE-101A-9A9F-00AA00342820)

  ]

  library LHello

  {

      // bring in the master library

      importlib("actimp.tlb");

      importlib("actexp.tlb");



      // bring in my interfaces

      #include "pshlo.idl"



      [

      uuid(2573F8F5-CFEE-101A-9A9F-00AA00342820)

      ]

      cotype THello

   {

   interface IHello;

   interface IPersistFile;

   };

  };



  [

  exe,

  uuid(2573F890-CFEE-101A-9A9F-00AA00342820)

  ]

  module CHelloLib

  {



      // some code related header files

      importheader();

      importheader();

      importheader();

      importheader("pshlo.h");

      importheader("shlo.hxx");

      importheader("mycls.hxx");



      // needed typelibs

      importlib("actimp.tlb");

      importlib("actexp.tlb");

      importlib("thlo.tlb");



      [

      uuid(2573F891-CFEE-101A-9A9F-00AA00342820),

      aggregatable

      ]

      coclass CHello

   {

   cotype THello;

   };

  };





  #include "ipfix.hxx"



  extern HANDLE hEvent;



  class CHello : public CHelloBase

  {

  public:

      IPFIX(CLSID_CHello);



      CHello(IUnknown *pUnk);

      ~CHello();



      HRESULT  __stdcall PrintSz(LPWSTR pwszString);



  private:

      static int cObjRef;

  };





  #include "windows.h"

  #include "ole2.h"

  #include "stdio.h"

  #include "stdlib.h"

  #include "thlo.h"

  #include "pshlo.h"

  #include "shlo.hxx"

  #include "mycls.hxx"



  int CHello::cObjRef = 0;



  CHello::CHello(IUnknown *pUnk) : CHelloBase(pUnk)

  {

      cObjRef++;

      return;

  }



  HRESULT  __stdcall  CHello::PrintSz(LPWSTR pwszString)

  {

      printf("%ws\n", pwszString);

      return(ResultFromScode(S_OK));

  }





  CHello::~CHello(void)

  {



  // when the object count goes to zero, stop the server

  cObjRef--;

  if( cObjRef == 0 )

      PulseEvent(hEvent);



  return;

  }



  #include "windows.h"

  #include "ole2.h"

  #include "pshlo.h"

  #include "shlo.hxx"

  #include "mycls.hxx"



  HANDLE hEvent;



  int _cdecl main(

  int argc,

  char * argv[]

  ) {

  ULONG ulRef;

  DWORD dwRegistration;

  CHelloCF *pCF = new CHelloCF();



  hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);



  // Initialize the OLE libraries

  CoInitializeEx(NULL, COINIT_MULTITHREADED);



  CoRegisterClassObject(CLSID_CHello, pCF, CLSCTX_LOCAL_SERVER,

      REGCLS_MULTIPLEUSE, &dwRegistration);



  // wait on an event to stop

  WaitForSingleObject(hEvent, INFINITE);



  // revoke and release the class object

  CoRevokeClassObject(dwRegistration);

  ulRef = pCF->Release();



  // Tell OLE we are going away.

  CoUninitialize();



  return(0); }



  extern CLSID CLSID_CHello;

  extern UUID LIBID_CHelloLib;



  CLSID CLSID_CHello = { /* 2573F891-CFEE-101A-9A9F-00AA00342820 */

      0x2573F891,

      0xCFEE,

      0x101A,

      { 0x9A, 0x9F, 0x00, 0xAA, 0x00, 0x34, 0x28, 0x20 }

  };



  UUID LIBID_CHelloLib = { /* 2573F890-CFEE-101A-9A9F-00AA00342820 */

      0x2573F890,

      0xCFEE,

      0x101A,

      { 0x9A, 0x9F, 0x00, 0xAA, 0x00, 0x34, 0x28, 0x20 }

  };



  #include "windows.h"

  #include "ole2.h"

  #include "stdlib.h"

  #include "string.h"

  #include "stdio.h"

  #include "pshlo.h"

  #include "shlo.hxx"

  #include "clsid.h"



  int _cdecl main(

  int argc,

  char * argv[]

  ) {

  HRESULT  hRslt;

  IHello        *pHello;

  ULONG  ulCnt;

  IMoniker * pmk;

  WCHAR  wcsT[_MAX_PATH];

  WCHAR  wcsPath[2 * _MAX_PATH];



 // get object path

 wcsPath[0] = '\0';

  wcsT[0] = '\0';

  if( argc > 1) {

      mbstowcs(wcsPath, argv[1], strlen(argv[1]) + 1);

      wcsupr(wcsPath);

     }

  else {

      fprintf(stderr, "Object path must be specified\n");

      return(1);

      }



  // get print string

  if(argc > 2)

      mbstowcs(wcsT, argv[2], strlen(argv[2]) + 1);

  else

      wcscpy(wcsT, L"Hello World");



  printf("Linking to object %ws\n", wcsPath);

  printf("Text String %ws\n", wcsT);



  // Initialize the OLE libraries

  hRslt = CoInitializeEx(NULL, COINIT_MULTITHREADED);



  if(SUCCEEDED(hRslt)) {





      hRslt = CreateFileMoniker(wcsPath, &pmk);

      if(SUCCEEDED(hRslt))

   hRslt = BindMoniker(pmk, 0, IID_IHello, (void **)&pHello);



      if(SUCCEEDED(hRslt)) {



   // print a string out

   pHello->PrintSz(wcsT);



   Sleep(2000);

   ulCnt = pHello->Release();

   }

      else

   printf("Failure to connect, status: %lx", hRslt);



      // Tell OLE we are going away.

      CoUninitialize();

      }



  return(0);

  }

  #!/usr/local/bin/perl

  $msg="Hello, world.\n";

  if ($#ARGV >= 0) {

    while(defined($arg=shift(@ARGV))) {

      $outfilename = $arg;

      open(FILE, ">" . $outfilename) || die "Can't write $arg: $!\n";

      print (FILE $msg);

      close(FILE) || die "Can't close $arg: $!\n";

    }

  } else {

    print ($msg);

  }

  1;

  #include "stdio.h"

  #define S "Hello, World\n"

  main(){exit(printf(S) == strlen(S) ? 0 : 1);}

  % cc -o a.out ~/src/misc/hw/hw.c

  % a.out

  % cat

  Hello, world.

  ^D

  10 PRINT "HELLO WORLD"

  20 END

  mail -s "Hello, world." bob@b12

  Bob, could you please write me a program that prints "Hello,

  world."?

  I need it by tomorrow.

  ^D

  % zmail jim

  I need a "Hello, world." program by this afternoon.

  % letter

  letter: Command not found.

  % mail

  To: ^X ^F ^C

  % help mail

  help: Command not found.

  % damn!

  !: Event unrecognized

  % logout

 #include "windoze.h"

 #include "system_errors.h"

 #include "stdlib.h"



 char make_prog_look_big[1600000];





 main()

 {



  if (detect_cache())

    disable_cache();



  if (ram<32768())

    printf("Insufficient memory to run this application\n");



  if (fast_cpu())

    set_wait_states(lots);



  set_mouse(speed, very slow);

  set_mouse(action, jumpy);

  set_mouse(reaction, sometimes);

  printf("Welcome to Windoze 96\n");



  if (system_ok())

   crash(to_dos_prompt);

  else

   system_memory = open("a:\swp0001.swp", O_CREATE);

  while(1)

  {

   sleep(5);

   get_user_input();

   sleep(5);

   act_on_user_input();

   sleep(5);

   if (rand() < 0.9)

     crash (complete_system);

  }



  return (unrecoverable_system_error);

}

Zaglosuj na moja humorystyczna strone w notowaniu Listopad '97 "Nieustajacej Listy Przebojow" Wirtualnej Polski.
Wystarczy, ze klikniesz w ten obrazek: