Jak se zrodilo programování: Grace Hopper

Ty její fotky s tím UNIVACem jsou z doby, kdy jí bylo cca 45 a i na té pozdější, když jí bylo 80, vypadá na svůj věk výborně. Když v r. 1931 začala ve svých 25 letech vyučovat, tak to tenkrát mohla být docela pěkná mladá kočka?

COBOL je hodne popisný, takový doslovný .. :)
Pro toho kdo je zvyklý na Javu nebo C tak může mít problém číst kód.třeba i++; se v CBL zabíše jako ADD 1 TO inebo i:=j; je MOVE j TO iČili má-li programátor zažité patterny z novějších jazyků, může mít problém intuitivně číst kód, neboť je dost jiný. Nikoli ale komplikovaný.Ostatně, na to COBOL nebyl ani designovaný. Pro člověka, který nikdy kód neviděl, bude určitě COBOL čitelnější než třeba Java nebo C++např. PERFORM WITH TEST BEFORE je prostě laicky velmi pochopitelný než řešit "repeat until" nebo "while" v Pascalu ..

To bude asi ono. Třeba všichni programátoři v PVT říkali, že "COBOL je trošičku ukecanej", ale dokud jsme do něj nemuseli šťourat, tak jsme si neuvědomili, jak je ta syntaxe odlišná od jiných strukturálních jazyků. A to dělení programu na 4 DIVISIONS (nebo jak se to jmenovalo) také v jiných jazycích než v COBOLu nebylo. Přitom jsem neměl problém přepsat spoustu programů z Fortranu 77 na SMEP do Turbo C nebo Borland C++ pro PC, které jsem si sám předtím nastudoval. Nebo jsem během 1 hodiny našel syntaktické chyby v instalačním skriptu pro moduly síťových prvků Fibronics, které se měly nainstalovat do HP OpenView běžícím na SUN Solaris a to jsem nikdy předtím takový script nebo syntaxi (dokonce ani prostředí) neviděl. Kdysi nám ve škole říkali, že k přechodu na jiný programovací jazyk potřebuje programátor asi tak měsíc. Ale přece jen se některé syntaxe a metodiky v programování natolik liší, že to asi není možné všechno rychle pojmout pouze intuitivně.

hehe .. na některých školách říkali, že dobrý programátor je schopen se switchnout přes noc ... S Fortranem jsem nepracoval, ale osobně jsem neměl příliš problém začít pracovat s COBOLem. A pořád tvrdím, že to pro někoho kdo programovat umí, není vůbec problém. Je v podstatě velmi jednoduchý - protože je starý. Rekurze, objekty, dědičnost, a různé jiné formy abstrakce ... ee Ale třeba vůbec nepoužívá běžně přirozené datové typy. Ty jsou zcela v režii překladače. Např. int neexistuje .. jakoukoli numerickou proměnnou jen definuješ jakou počet numerických míst:01 NUMBER PIC 9(12).
(proměnná NUMBER, číslo, délka 12) Co bývá mnohem složitější než COBOL samotný, je se vyznat v komplexních, roky vyvíjených (rozuměj prasených ) obřích legacy systémech, na kterých ještě pořád jedou některé banky, pojišťovny, burzy nebo telefonní operátoři .. To ale někdy těžko vysvětlovat managerům, kteří s COBOLem nepracovali .. Jo, struktura programu je rozdělena do DIVISIONs. Ale přesně už nepamatuji jak to je, neboť na prázdno v podstatě nikdy už dnes nezačínáš. Většinou je nějaká kostra nebo výchozí template, kde jsou základní věci, jako mašiny, přístup k souborům, "knihovny", proměnné, copy-booky už nastaveny, takže to neřešíš .. pokud už teda píšeš nějaký úplně nový program .. jestli mi rozumíš ...

Ale jo, určitě by stačilo přečíst nějakou dokumentaci a šlo by to. Třeba v té MTZ v Macroassembleru ten původní programátor nepoužíval proměnné typu float, ale měl všechna čísla v integeru. 2 desetinná místa v cenách, co měly být haléře, tak byly násobkem 100, takže celkový součet cen na skladu byl větší, než long integer. Takže aby to vůbec šlo sečíst, tak si tam vytvořil vlastní pětibytový integer a k němu naprogramoval příslušnou aritmetiku. Samozřejmě tam měl chybu, takže občas nešlo vydávat. Naštěstí jsem našel, jak to má uloženo, přestavil první bit z 0 na 1 a zase byl celkový součet zásob kladný a výdej fungoval. Takové problémy by v COBOLu nebo Fortranu asi nikdo neřešil, ale tenkrát to prý tak dělali "optimálně" v assembleru hlavně kvůli rychlosti zpracování na relativně pomalých počítačích.

Kolegové to už napsali - je ukecaný, dřív se tvrdilo a asi to platí, že je samodokumentovací. Když si člověk rozumně nazve proměnné, dá se zdrojový program číst skoro jako běžný text v angličtině. Přitom jsem v něm kdysi dokázal naprogramovat práci s 8" disketami ve formátu IBM na základní úrovni - žádné sektory, ale souvislé bloky dat. A žádný ovladač v operačním systému, jen program v Cobolu. Takže dalo se s ním ledacos.

Ta samodokumentovací vlastnost COBOLu byla určitě výhodou. Třeba v tom Macroassembleru tu aplikaci MTZ psal původní programátor tak, že ke každému řádku kódu měl aspoň jeden řádek s komentářem. Proto se v tom dalo i později orientovat. Třeba ve Fortranu jsem psal komentáře zhruba každý 3. až 5. řádek a když jsem se pak musel do nějakého zdrojáku podívat asi po 3 letech, nějaké úpravy i po takové době byly bez problémů. Později jeden kolega navrhl takový systém komentářů ve zdrojáku, že když se zdroják projel vhodným parserem, tak z toho vypadla kompletní dokumentace. Ale u COBOLu by to asi nebylo zapotřebí.Jinak práce z disky na mainframech (v ČR řada EC 10xx se systémem "DOS", což byl IBM OS/360) byla vždy bloková, pokud si dobře vzpomínám. Na SMEP se logická velikost disků udávala také v blocích (také měla mj. 2 mechaniky na 8" diskety, ale moc se nepoužívaly). Přes tzv. "executive" instrukce bylo možné přistupovat do systému na hodně nízké úrovni a bylo je možné volat buď z Assembleru nebo z Fortranu. Takže když kolega systémový inženýr zjistil, že je třeba vadný zaváděcí blok na systémovém disku, tak mě požádal, abych našel na disku nějaký nepoužitý blok, zapsal do něj zaváděcí (bootovací) instrukce a označil ho jako zaváděcí. Systém pak z toho bez problémů nastartoval. Zkrátka jsme tak měli rozdělenou práci - on věděl co a kde potřebuje v OS RSX11-M opravit, a já jsem věděl, jak a čím to opravit ve Fortranu. V COBOLu by tyhle problémy na SMEPce asi opravovat nešlo.

Co ty víš? Třeba se opřela o jeden z těch PC a kolega od vedle si jí vzal zezadu

Představte si, že jsou tací, jimž k zábavě nestačí jen vyhovět základním fyzickým potřebám.

Naopak si asi užila spousty zábavy s Markem I. a jeho následníky?

google "základy algoritmizace programování"
Hned 7. odkaz: http://www.blabik.cz/vyuka/ict/33_algoritmizac... ...

Samostudiem se programování samozřejmě naučit lze (jako spousta jiných věcí). A oproti nám, kteří jsme na konci 80. let měli jen pár knížek a sem tam článek v časopisu, je dnes na Internetu nepřeberná spousta zdrojů. Ale v prvé řadě by se člověk měl naučit umění algoritmizace, programování není o syntaxi konkrétního jazyka ...

Ono se stačí přihlásit ke studiu na IT, tam se to bere od začátku.

Vstupenka do knihovny stojí pakatel, stejně tak učebnice (je jich jako šafránu, ale jsou). Když se poštěstí, i v antikvariátu lze něco sehnat.Když teda neumíš hledat na Internetu (úplně postačí české vody).

Nesmysl, je jich plný internet. Naopak chybí kvalitní články pro pokročilé - kdy použít interface a kdy předka, jak efektivně používat eventy, asynchronní paraelismus, generika, singletony atd atd. Tyto pořádné tutoriály chybí.

Tyto informace na internetu jsou, dokonce od samotných programátorů. A když člověk něco neví, stačí se zeptat.https://programmers.stackexchange.com/questions/108240/why-are-... ...

jasně, na internetu je všechno, dokonce i přehled pravidelné stolice mého psa. To ale neznamená, že amatérská wiki na stack overflow, kde to navíc ještě budu hledat po kouskách a několik měsíců, je to pravé ořechové

Víceméně souhlasím, že nějaký materiál typu "for total dummies" asi schází, na druhou stranu - komu by se ho chtělo psát? Pak bude umět programovat každý, v oboru bude větší konkurence a nižší platy... Vždyť by si člověk, který by takovou publikaci napsal, jen kálel do vlastního hnízda

No bude teplo a smrádeček aspon v hnízdě

"For total dummies" neschází, byl zveřejněn dokonce zde na živě.
http://www.zive.cz/clanky/poznavame-c-a-micr... ...

No nevím hele. Člověk, který potřebuje vysvětlit i to co je to program se konkurencí jen tak nestane A klidně bych se vsadil, že spousta lidí by se ani díky té knížce programovat nenaučila.

Tak jestli to chcete vzít fakt z gruntu, tak bych začal studiem elektroniky. Bohatě postačí na úrovni střední školy. Pokud pochopíte funkci a použití základních el. součástek, později tranzistorů, z nich postavené základní obvody pro vyjádření logického stavu, integrované obvody, mikropocesory... Věřte, že když pochopíte prazáklad digitální techniky, automaticky Vám dojde to, po čem voláte. Z vašeho příspěvku mám však pocit, že se snažíte nejdéle za rok naučit programovat tak, aby jste si mohl říci o 70K nástup, což . Tak to Vás mohu ujistit, k tomu vede hodně dlouhá cesta.

Hlavne i na programovani, resp. kvalitni programovani je treba talent.
Ten ja sem nikdy nemel. Na skole sme meli Delphi, ale na jazyku nesejde, vsechno sem chapal jak funguje atd. cili kdyz sem od kamose opsal zdrojak a uciteli se pote zdal nejaky povedomy(podminkou moznosti opisovat bylo samozrejme pozdejsi odevzdani prace), vsechno sem bez problemu vysvetlil "co kde proc jak" takze mi jednicku dat musel ale kdyz sem to same mel napsal opravdu ja, bylo to jednou tolik kodu a desna prasecina.Takze programovat muze kazdy, programatorem se stanou jen nekteri...

Velice dobrý způsob, jak spoustu věcí kolem programování počítačů pochopit, je ponořit se do programování počítačů na nejnižší úrovni, tedy pochopit Assembler. V Čechách byla koncem 80. let vydána knížka Byty do bytu, jako reakce na stoupacící zájem o malé 8bitových počítačích. Je to přesně ten způsob literatury, který jde hodně srozumitelnou formou do slušné hloubky. Znalosti uživatelů byly v té době hodně nízké, takže se autor snažil všechno velice názorně vysvětlit.
Knížka je zaměřená na počítač ZX spektrum, který byl v té době velmi populární a především jeho procesor Z80.
Dnešní hodně abstraktní programování, kdy neřešíme jak se co ukládá, může některým začínajícím programátorům dělat velké potíže. U assembleru je to nutné specifikovat přesně.
Nedávno mě zaujal projekt Arduino. Programování je vcelku jednoduché, výhodou je, že se ovládají LEDky, motůrky, různá čidla, takže autor má okamžitou odezvu, jestli mu to funguje správně. Jako vstup do světa programování to také není špatné. Musí ale být nějaké základy z elektroniky.