Ve věku 89 let zemřel Niklaus Wirth, nositel Turingovy ceny za vývoj programovacích jazyků

Ve věku 89 let zemřel Niklaus Wirth, nositel Turingovy ceny za vývoj programovacích jazyků a autor Wirthova zákona: Software se zpomaluje rychleji, než se zrychluje hardware.

3.1.2024 23:11 | Ladislav Hagara | IT novinky

Komentáře

[okbobcz]

RIP - člověk, který dokázal úžasné věci. Nemusíte mít rádi Pascal, ale Oberon nebo Modula jsou nádherné jazyky. Operační systém Oberon je inženýrský skvost. Věci, které napsal (ať knihy nebo kódy) se daly dobře číst.

[johnyK]

souhlas, zejmena s tim, ze neni nutne mit rad Pascal.

Na jenom foru jsem cetl nasledujici:

Upřímnou soustrast... TurboPascal jsem miloval na odborné škole. To bylo ještě před zavedením JAVY do škol.

Takze si myslim, ze je nyni otevrena diskuze, co je nejlepsi prog. jazyk.

[okbobcz]

Já osobně jsem měl Pascal rád - kompilace byla vůči Cčku nebo Fortranu brutálně rychlá, IDE v Turbo Pascalu bylo super, dělalo se v tom dobře. Turbo Vision vypadalo úžasně a daly se v tom udělat hezký věci. Bakalářku jsem psal v Turbo Pascalu 3.0 provozovaném v CP/M na upraveném Didaktiku Gama - ještě bez diskety s ramdiskem. Diplomku jsem psal v Oberonu - plně 32 bitový systém s nádherným jazykem s GUI, který se i se zdrojáky vešel na disketu, a dělalo se na tom fakt dobře. Všechno to bylo rychlé i na běžných počítačích. Ještě o dekádu později jsem nechápal jak někdo může dělat v IDE napsaných v Javě, která byla neskutečně pomalá. Lidi co vyrostli na Javě nemají tušení, jak počítače mohou být rychlé.

[Peter Golis]

V dobe nasadzovania javy do výučby bežal medzi programátormi vtip:

Ako zistí študent najmenší a najväčší prvok poľa? Použije knižnicu na zotriedenie a vyberie krajné hodnoty.

Inak IDE od Borlandu bolo nadčasové, len mu chýbali hodinky. Ale návod na reziďák bol pribalený, a človek si tie hodinky doprogramoval veľmi rýchlo.

[koroptev]

no a predstav si lidi, co vyrostli na turbo pascalu, kdyz sednou k linuxu a uvidi neco jako vim a gdb

[okbobcz]

jj DOSové aplikace z přelomu 80/90 let jsou z hlediska estetiky i uživatelské přítulnosti vrchol TUI (dodnes nepřekonaný) - ať už je to Turbo (Borland) Pascal, nc nebo třeba FoxPro. Jinak nejnovější port TurboVision (C++) do Linuxu je povedený (aplikace jsou rychlé včetně podpory UTF), takže napsat pěkně vypadající aplikaci i v Linuxu by neměl být problém https://github.com/magiblot/tvision

[koroptev]

pokud je to ironie, tak lol, o debuggingu v ty uzivatelsky privetivosti, ve ktery to mel turbo pascal (nebo cokoli turbo), si linux muze nechat zdat jeste dnes

[okbobcz]

Není to ironie - i pspg, který píšu designově vychází z začátku 90tek https://github.com/okbob/pspg

[koroptev]

ok, sorry :)

souhlasim s tou intuivnosti, zazil jsem to i v praxi z pohledu uzivatelu, IS pouzivany statni spravou puvodne dosovska verze se zminenym TUI, kde stacilo mackat tab a enter nahrazena win verzi, kde bylo nutne trefovat mysi tlacitka, nechutnalo jim to a nechutnalo jim to velmi, meritelne zpomaleni te uplne stejne prace

[Bubak]

To same bylo u nas. Zakaznici nadavali, jak system v TUI (pripadne prevedeny do GUI, ale s v podstate stejnou logikou a ovladanim) je zastaraly - po vymene za jiny od jineho dodavatele plne GUI byli uzivatele zdeseni, jak vsechno najednou trva a kolik toho musi naklikat...

A i pri jakychkoliv upravach a modernizacich systemu se muselo koukat na to, aby nikde nebylo nejake kliknuti navic (nebo spis aby nebylo zadne kliknuti) - kdyz sestricka jede, nechce premyslet, kde je ten spravny cudl (nebo si i pamatovat, ze ma zmacknout o klavesu navic)...

[PetebLazar]

TurboPascal byl asi první mě známou aplikací s "podporou více monitorů", pokud měl člověk v PC MDA i VGA kartu (separátní adresní prostory) mohl trasovat(krokovat) grafický program běžící na VGA a IDE mít na MDA (bez promrkávání způsobené neustálým přepínáním mezi text/graphic mody v případě provozu na jedinem VGA monitoru).

[Radovan]

Na ByteFestu jsem před lety viděl SAPI-1, kde na jedné televizi běžel BASIC, kde sis editoval a spouštěl programy, na druhé televizi ty programy zobrazovaly grafiku, a na plotteru vedle mohly psát i vykreslovat. Všechno současně.

Stačil tomu osmibitový procesor a dvě osmipalcové disketovky

[kdosi]

Díky moc za odkaz, právě jsem se začal zabývat TV a když to půjde bez DosBoxu, tak tím líp :)

[Mikuláš]

Ten tvision je super, něco málo jsem v tom psal a můžu jedině doporučit.

A takové zamyšlení nad zpětnou kompatibilitou a vůbec kontinuitou věcí:

Copyright (c) 1994 by Borland International

Třicet let. Po třiceti letech to pořád žije a běží na dnešních platformách. Klobouk dolů. Na C++ nebo Javu můžeme nadávat a hledat na nich mouchy, ale vývoj softwaru není krasobruslení nebo aranžování květin, které za pár dní zvadnou.

Když to porovnám s "moderními" technologiemi: máme tu několik let starou webovou aplikaci - dneska je problém ji vůbec sestavit a provozovat, lidi se na to bojí sáhnout, i přidání jednoho textového políčka do formuláře je dobrodružství s nepředvídatelným výsledkem. Najatí experti na web (z jiné firmy s velmi dobrými referencemi) se toho štítí a nechtějí na tom pracovat - protože oni přece dělají webové appky tak, jak je to "moderní" dneska, ne jak to bylo "moderní" před těmi pár lety.

[okbobcz]

Pokud se bavíme o https://github.com/magiblot/tvision, tak aby se to dalo přeložit na moderních překladačích, a aby to podporovalo UTF, tak dalo tomu chlapovi dost práce (několik let) a je to extrémně šikovný programátor (viz tvterm. Ten chlap na tom neskutečně zamakal. Portů Turbo Vision bylo víc, ale měly dost omezení - 32 barev a single byte kódování - pro češtinu je to bez podpory UTF nepoužitelné. Shodou okolností se podpora UTF fixnula i v Free Vision - což je C++ Turbo Vision přeportovaný do Pascalu (Turbo Vision pro Pascal Borland neuvolnil).

[koroptev]

skoda, ze nativni aplikace jsou dnes pase

vetsi smysl by mel port turbo vision pro react treba

[xkucf03]

Existují webové emulátory terminálu – aplikace psaná nad knihovnou TVision by běžela na serveru a v prohlížeči by se zobrazovala. Případně by to asi šlo přes Emscripten překompilovat do JavaScriptu a pouštět v prohlížeči celé a na serveru mít jen nějaké API a logiku. Stejně tak se dá v prohlížeči pustit DOSBox, fungují v tom i hry.

[Andrej]

Na gympli / vyske som sa hral s portovanim TurboVision do grafiky. Povodna myslienka bola napisat nieco na zobrazovanie grafov v TurboVision programoch. Vykreslovacie rutiny v assembleri som ale vtedy nezvladol. Medzitym prisli Windows a grafiku do TurboVision uz nebolo treba.

[Tim]

Ja to zazil nebylo to nic hroznyho protoze se nasli pokrokovi programatori co IDE a'la TurboVision prenesli i na unixy. Pamatuji treba XWPE nebo FTE. Pak jeste joe editor mel klavesove zkratky Borlandu a v nouzi slo pouzit i mcedit, oba ale nebyly IDE jen "normalni" editory co znali kurzorove sipky, ne jak puvodni vi a jove Emacs tehdy nepouzival na PC nikdo protoze ten kolos nebyl staveny na 386 s 1MB pameti

[Miloslav Ponkrác]

Borland si své klávesové zkratky nevymyslel. Zejména při editaci navazoval na tehdy rozšířený a po celém světě používaný standard editoru Wordstar. Mnoho programů zejména (ale nejen) v DOSu ho používalo pro ovládání.

Microsoft se rozhodl toto blokovat a překopat to. A unix si to zase dělal po svém.

[Bubak]

Pamatuje nekdo RHIDE? Kolem roku 2000 jsem taky pouzival

[kdosi]

Jo, napříkload já. VIM jsem si zamiloval hned. A když jsem si nedávno ten BP pustil, tak nebylo to IDE špatné, ale vim byl stejně výrazně pohodlnější.

(Pravda je, že taky výrazně větší, dnes už není potřeba každého omezovat na 640kB.)

[koroptev]

a jak ve vimu debugujes - nastavujes breakpointy, krokujes, sledujes obsah registru apod.? bude odpoved ve formatu "takhle takhle takhle, tohle takhle" nebo "ani to nepotrebuju, ale ma to nejaky udelatko, co umoznuje napojeni na gdb, takze problem solved"?

dabel je v detailu, ten pascal to mel extremne intuitivni (a rychly)

[kdosi]

Ve VIMu programuju, debuguju v debugeru, koroptev jedna hloupá :)

Například v TD nebo Emulator6809, nebo jiném, pro daný problém vhodném.

[koroptev]

aha, takze v jedny obrazovce editujes kod a v uplne jiny, ktera zobrazuje ten uplne stejnej kod, nastavujes ty breakpointy?

[kdosi]

Jo, dokonce to jde tak daleko že na jednom počítači edituju kód a na jiným ho spouštím :)

[koroptev]

a kdybys mohl ty breakpointy nastavovat primo v ty "obrazovce" (mozna tim kazdej myslime neco jinyho), kde ten kod zaroven editujes, nebylo by to intuitivnejsi? pro me ano

[kdosi]

U mě se většinou porůznu střídá víc hodně různých fází a každá vyžaduje jiné nástroje.

Například při plánování nevzniká kód, ale často spousta náčrtků.

Při psaní kódu potřebuju dobrý texťák, ale nedebuguju, prostě pořídím třeba stovky nebo tisíce řádků, kdy se v průběhu ani neočekává, že by to snad bylo přeložitelné.

Pak někdy je fáze s překladem, kdy řeším nedeklarované nebo naopak nepoužité proměnné a podobné detaily.

Debugování je fáze, kdy mě v detailu zajímá, co to vlastně dělá doopravdy, ale tam zase změny v kódu jsou malé a většina času se stráví něčím jiným.

Dokumentace je zase zcela jiný případ.

Různé testy zase jiný.

A tak dál a dál.

A podle toho se i řídí, jaké nástroje používám.

"Obrazovky" jsi do toho zatáhnul ty, nevím, zda to pro tebe jsou jednotlivá okna, virtuální obrazovky, nebo monitory, ale je mi to celkem jedno, používám vícero od libovolných z nich.

A pokud jen samotný spustitelný soubor vimu je více než 100x (nebo třeba 1000x) větší, než kompletní RAM na cílovém počítači, tak nedává moc smyslu při krokování toho programu ten vim chtít používat.

Ostatně ani pod DOSem by mi současný vim při debugování moc nepomohl. Zato při psaní programu nevidím důvod se omezovat v použití nástrojů omezeními cílové platformy.

Takže program prostě napíšu ve vimu a pak odladím třeba ve zmíněném TP+TD, nebo BP, nebo čemkoli jiném a těch pár změn, nesrovnatelných s celkovou délkou, udělám v čemkoli, co tam zrovna bude (třeba TP, nebo přímý zápis do paměti, to je fuk). A pokud debugování odhalí potřebu větších změn (třeba jiný přístup), tak jednoduše obětuju pár sekund na přechod do vimu, kde budu řadu minut, hodin či dní pracovat.

Ale to je celkem běžný postup, ať už je cílovou platformou AVR, 6309, DOS, Rapsberry, běžné PC, rozsáhlý síťový systém nebo megapočítač. Nástroje (jak SW, tak HW), které používá vývojář, málokdy odpovídají tomu, co používá koncový uživatel. Ať už jde o gamesky, webovky, účetní systémy, distribuované systémy, nebo cokoli jiného...

[koroptev]

tohle asi neni typicky scenar treba ceckare nedejboze nekoho, kdo pouziva jazyk s nejakymi vyssimi abstrakcemi..

tozn. dostavam odpoved "pokud jsi prislusnikem nejake absolutni minority, tak se ve vimu debuguje super"

[kdosi]

Takže pro tebe není třeba python jazyk s dost vysokými abstrakcemi?

Jeden z mých projektů měl jen v pythonu přez půl miliónu řádků a používal jsem tam přesně tenhle přístup.

Ale používám ho stejně i v céčku, pascalu, ... prakticky kdekoli ... ale uznávám, že lidi, co umí programovat i větší věci, tvoří absolutní minoritu

Samozřejmě že u projektů typu

10 PRINT "HELLO WOLRD"

20 GOTO 10

nebo "splácám dohromady tři cizí knihovny a pět svých řádků a jsem webový guru" to funguje jinak.

[koroptev]

funguje jinak myslis treba Carmacka, kdyz hovori o tom, jak nechape, jak pri urcity slozitosti aplikace, coz jim vyrabeny hry dost pravdepodobne jsou, muze nekdo vubec tusit, jak se jeho aplikace chova a co se v ni odehrava, bez imvrvere pustenyho debuggeru?

dabel je v detailu, je to o tom, jak jednoduchy/rychly/intuitivni je pouziti tech toolu, nikdo me nepresvedci, ze vim a nekde vedle gdb nebo neco podobnyho je lepsi nez zpusob, kterym debugovani probihalo treba v tom turbo pascalu a kterej je ideove stejnej jako totez v dnesnim visual studiu (nikoli code)

[kdosi]

A všimni si, že o debugování ve vimu tu setrvale píšeč ty.

Já píšu o psaní programů ve vimu.

A o debugování v nějakém debuggeru nebo jiném příslušném prostředí, které je pro debugování vhodné (a už možná ne až tak vhodné pro psaní programů).

A odlišuju psaní programů a debugování jako dvě rozdílné činnosti.

[koroptev]

no a kdyz chces zmenit ten program, co prave debugujes, tak jaky presne kroky udelas? bud fakt specifickej, protoze v tom turbopascalu zeditujes kod a to je vse..

[xkucf03]

To mi přijde trochu jako z nouze ctnost a racionalizace ne úplně dobrého řešení. Asi se to dá brát jako „good enough“ řešení, ale neprezentoval bych to jako nějaký ideál nebo vzor.

Ideál je podle mého IDE. (což ale nutné nemusí být IDE typu Netbeans/Eclipse, může to být IDE postavené nad vimem, emacsem nebo jít cestou „UNIX je moje IDE“). Ale důležité je, aby to bylo integrované a fungovalo to perfektně dohromady.

Při psaní kódu potřebuju dobrý texťák, ale nedebuguju

Ladění v debuggeru používám relativně výjimečně, ale i tak nevidím důvod, proč bych měl kvůli tomu odskakovat někam jinam, používat jiný editor, jiné klávesové zkratky atd. Prostě vyvíjím a pak se jen připojím k běžícímu procesu a krokuji ho, ale pořád jsem v tom stejném prostředí, mám otevřené ty samé soubory, maximálně si přepnu režim v IDE nebo otevřu/zavřu pár jeho panelů/oken. Další věc je, že někdy můžu použít živé patchování běžícího programu – upravím část kódu a ono se to překompiluje a vloží do toho programu, aniž bych ho musel ukončovat a znova pouštět. V Javě to funguje jen do nějaké míry, jednodušší úpravy, ale jsou i programovací jazyky, kde toho lze za chodu patchovat mnohem víc.

prostě pořídím třeba stovky nebo tisíce řádků, kdy se v průběhu ani neočekává, že by to snad bylo přeložitelné. Pak někdy je fáze s překladem, kdy řeším nedeklarované nebo naopak nepoužité proměnné a podobné detaily.

Ne, že by to nešlo, byly doby, kdy se programovalo tužkou na papír nebo děrováním štítků, ale proč? K čemu je to dobré? Dneska považuji za samozřejmost, že mi IDE průběžně při psaní kódu kontroluje překlepy, syntaxi, vím, že třídy/metody/proměnné, které používám, existují, případně to dává i nějaká varování (např. „tahle proměnná může být null“ nebo „tahle výjimka zde nemůže vyletět, tak ji nemusíš odchytávat“).

Občas si vytisknu zdroják na papír a přemýšlím nad ním mimo počítač nebo si ho jen schovám do šuplíku. Ale že bych takhle offline (nebo de facto offline v editoru, který nerozumí kódu a nepomáhá) chtěl tvořit nějaké větší množství kódu, to asi ne.

Dokumentace je zase zcela jiný případ.

Pokud píší dokumentaci v TeXu nebo Docbooku, tak ji píši ve stejném IDE jako programuji. Výhoda je např. integrace s verzovacím systémem – IDE mi podbarvuje změněné řádky nebo si tam můžu zobrazit historii, udělat blame atd. funguje to stejně jako při psaní kódu. Spustit generování dokumentace přes Make/Ant se dělá zase stejně jako sestavení programu, prostě je to jen jiný typ projektu.

Různé testy zase jiný.

Jednotkové testy jsou normální zdrojový kód ve stejném jazyce. Takže opět v IDE. Integrační testy můžou být třeba v JMeteru nebo něčem jiném, takže to třeba dělám jinde. Ideální integrace by pak ale měla být, že se při testech zaznamená pokrytí kódu a to mi podbarví/označí řádky v IDE (ne v nějakém jiném nástroji/okně mezi kterým a IDE se budu muset přepínat).

A pokud jen samotný spustitelný soubor vimu je více než 100x (nebo třeba 1000x) větší, než kompletní RAM na cílovém počítači, tak nedává moc smyslu při krokování toho programu ten vim chtít používat. … Ostatně ani pod DOSem by mi současný vim při debugování moc nepomohl. Zato při psaní programu nevidím důvod se omezovat v použití nástrojů omezeními cílové platformy.

Debugger/IDE přece může běžet jinde než aplikace. Vzdálené ladění je normální věc. Program může klidně běžet na nějakém jednočipu a ladí se přes JTAG z velkého počítače.

Nicméně abych byl upřímný, tak já taky používám takový smíšený přístup. Mám sice IDE, ve kterém dělám většinu věcí a nestydím se za to, ale zároveň jdu i tou cestou „UNIX je moje IDE“ (nebo spíš GNU/Linux tedy) a mám různé programy na různých virtuálních plochách a přepínám se mezi nimi – např. s verzovacím systémem pracuji napůl v IDE a napůl z příkazové řádky, protože každý přístup je na něco lepší. A některé soubory taky edituji v konsoli a netahám je nutně do IDE. BTW: přes Vánoce jsem si udělal radost a publikoval tohle: ShaderShark – je to malá věc, spíš jen taková hračka, ale taky ukázka toho přístupu „UNIX je moje IDE“ – ten program samotný je jen zobrazovač, zatímco editor kódu (GLSL) si člověk použije vlastní, parametry (properties objektu) jsou rozšířené atributy (xattr) na souborovém systému a edituješ si je zase nezávislým editorem, textury přepínáš prostě nakopírováním souboru pomocí cat, cp nebo nějakého správce souborů. A dohromady to funguje díky integraci přes inotify a zámky. Časem by mělo přibýt nějaké API a rozhraní pro moduly. Tzn. IDE je pak ta kombinace těch programů dohromady, ne jeden program, ale důležité je, aby to bylo integrované a dobře spolupracovalo.

[prqek]

Moje IDE je obvykle shell (resp. bash) :) Jsou v něm nástroje jako screen, gcc, vim, gdb, grep, sed, man, ls, ... Ano, uznávám, že občas je to poněkud neohrabané, ale nutnost přepnout mezi dvěma oknama a něco mezi nima překopírovat není něco, co by mě zdržovalo. Ale hlavně už jsem si na to nějak zvyk :)

[koroptev]

hm, takze projekt buildujes tak, ze poustis rucne gcc na ruzny podstromy kodu? nedelej blbyho, samozrejme ze ne, tak jako ti nejakej build system tohle odstinuje, tak ti nejaky dobry IDE odstinuje nutnost delat tu znouzectnost, o ktery pise kolega viz vyse..

to je jak vysvetlovat slepymu, co jsou barvy

[prqek]

Jasně, na to mám obvykle make. S IDE taky samozřejmě občas dělám, ale když si mužů vybrat mezi třeba MSVS a tím, co jsem popsal, tak radši ten vim, shell atd. A že si často vybrat můžu, dost věcí, na kterých dělám jsou multiplatformní.

[tacoberu]

Tak já to teda dělám taky tak. Používám třeba gitg pro zobrazení commitů, nastrkání částí změn do stage, ale rebase, commity, a spoustu dalších věcí dělám v příkazové řádce. Používám "hloupej" editor, ale builduju zase z příkazové řádky. Dokumentaci píšu zase v něčem jiném.

Občas jsem nucen používat VS. Jako je to dobrý, neříkám nic. Ale jediná věc, která mě na něm přijde opravdu zajímavá jsou možnosti refactorování. Vestavěné verzování nepoužívám, páč je blbé, a když by debuger byl extra nástroj, tak mi to bude úplně jedno.

[koroptev]

aha, to si vubec nechci predstavovat, jak ten hloupej editor bez integrovanyho gitu napr. ne/zobrazuje nebo ne/zvyraznuje git diffs, jak neumi rict tohle a tohle chci do stage a musim jen kvuli tomu poustet nejaky dalsi nastroj..

[tacoberu]

Ano. Přesně takto to používám, a takto to mám rád.

Občas mě někdo/něco nutí používat různá IDE. A mě to prostě nevyhovuje. Krom zmíněného refactoringu, nevidím v tom tu přidanou hodnotu.

[prqek]

... nejaky dalsi nastroj..

git diff?

[kdosi]

Jen bych připoměl, že toto začalo jako velmi specifické porovnání IDE z Turbo/Borland Pascalu versus VIM pro psaní programů. Kde TP neměl zejména spolupráci s verzovacími systémy, patchování za chodu (dalo se tam něco připsat a přeložit to znovu a spustit to znovu), kontrolu syntaxe, natož existence proměnných, atd, atd. TD byl celkem vychytaný, ale editor v TP nebyl v porovnání s vimem nic moc (jasně mezi tehdy dostupnými editory byl fakt dobrý, o tom žádná, ale mluvíme o přechodu k vimu).

K MC6809 (natož HD6309) jsem JTAG nenašel a IMHO není.

Ale je fakt, že dnešní IDE jsou výrazně dál, než byl TP, když jsem ho v minulém miléniu opuštěl... :)

[Miloslav Ponkrác]

Editor v Turbo Pascalu nebyl moc dobrý ani s porovnání s editory dostupnými pod DOSem.

Programátoři kolem mě používali různé editory, už si nepamatuji ani jejich jména. Na psaní programů, na psaní. Pamatuji si jen jméno "me editor" a pak ještě jeden mající několik režimů podobně jako vim, ale vim to nebyl.

V těch editorech se psaly delší programy nebo i spisovatelské texty.

Turbo Pascal a Turbo C měly hlavně problém s pamětí. Muselo se do ní vejít všechno, a nebylo jí ani 640 KB. Některé feature byly dostupné jen z řádkového překladače, v IDE nebyly dostupné - například překlad do assembleru. Muselo se šetřit pamětí, to bylo omezení.

[Miloslav Ponkrác]

Hlavní problém IDE je většinou jeho editor. Pokud sedne editor, není důvod nevylézat z IDE.

Problém je, že většinou existují dobré editory (typu vim). A pak je leckdy lepší leccos napsat mimo IDE.

IDE není optimální nástroj na psaní, většinou jsou lepší.

[panpanika]

https://m.youtube.com/watch?v=0moS8UHupGc

[koroptev]

to vypada jako tutorial, jak si v neovimu s pouzitim tri prdeli veci naprogramovat to, o cem mluvim

ja uz jednu praci mam, dekuju, rad bych odpoved slysel od nekoho, kdo tou cestou prosel a denne ji praktikuje a rekne mi neco jako "je to total voser, kdybych ztratil konfigurak, jsem v hajzlu" nebo "na pohodu, pet radek, nastavis cesty k x, y, z.."

kvalita ty odpovedi od nekoho takovyho by se totiz od nahodnyho linku na internet lisila v tech detailech, ve ktrych se skryva dabel, typu "pada mi to 3x denne" nebo "ma to ten a ten problem"

bez techto dovetku to ma kvalitu na urovni "teoreticky je to mozne"

[koroptev]

pascal nerovna se turbo pascal, to nerovnani se je tak velke, ze turbo pascal je plusminus cecko s jinou syntaxi (a ano, par dalsima odlisnostma)

[Miloslav Ponkrác]

Standardní Wirthův Pascal byl míněn jako učební jazyk. (A následovníci Pascalu Modula = přidáno modulární programování, Oberon = přidáno objektové programování ... byli míněni jako praktické jazyky).

Borlandský Pascal byl v zásadě (až na datový typ file, a na short circuit vyhodnocování logických operátorů) standardní Wirthův Pascal + obrovská kupa rozšíření. Zejména OOP, které se IMHO Borlandu nepovedlo, a bylo dost špatně navržené.

Zdrojový kód Wirthova standardního Pascalu nebude problém v Borlandu přeložit.

[ehmmm]

Nic proti, souhlas. Jeste doplnim, ze short circuit vyhodnocovani se tam podle me objevilo az nekde ke konci. Tusim, ze to byl BP7, ve kterem se daly v DOSu programovat i programy pro Windows (ale zajimalo by me, jestli to nekdo tehdy fakt delal, ja byl na to moc mladej). A OOP Borland Pascalu jsem tehdy jako skolak mel problem vstrebat. Na druhou stranu, kdyz to pochopite v Pascalu/Delphi, tak uz ho pochopite snad vsude, lisi se v podstate jen syntaxe.

[koroptev]

OOP v turbo pascalu se od toho (tehdejsiho) C++ lisilo jen v tom, ze se nevolaly konstruktory automaticky na konci scope, tez to nemelo mnohonasobnou dedicnost, coz je takova sporna ficura, ideologicky (v tom vesmiru, kde existuje skutecne objektovej Smalltalk nebo lispovskej CLOS s multidispatchem) to bylo uplne totez (a ano, ted se tu muze nejakej C++ nazi vyloupnout s tim, ze C++ ma auto pointery nebo nejakej podobnej sranec - coz je vpodstate definice C++, kupa hnoje, ze ktery je potreba vybrat takovou podmnozinu, ze ktery se clovek nezWTFuje)

no a OOP pochopeny v pascalu opravdu nenapomuze pochopeni OOP vsude, protoze je to takovej mechanickej pomeranc v porovnani se skutecnym OOP v tom Smalltalku a tez je to uplne jinej vesmir a zpusob uvazovani v porovnani s OOP, ktery ma multidispatch..

[Miloslav Ponkrác]

Ve staticky typovaných jazycích bývá obvykle OOP jako rozšíření datového typu struct (v C terminologii) neboli record (v Pascal terminologii). Přifaří se tam podprogramy a je to.

Mám zato, že objekty na Pascalovskou syntaxi vymysleli mnohem lépe v Simule. Také je tam omezení na jednoduchou dědičnost. Ale v Borland / Lazarus Pascalu to OOP syntakticky i jinak dost podělali. Je to ale jen můj subjektivní názor.

Smalltalk měl jako objekty všechno. Nevolaly se v něm podprogramy, ale posílaly zprávy. Žádný typový systém tam v zásadě není, vše je objekt. Třídy a dědičnost je jen implementační detail pro usnadnění programování, ale každý objekt i stejné třídy se může chovat jinak a mít jinou množinu zpráv, na kterou reaguje.

[koroptev]

cpt obvious to the rescue

[kdosi]

Sáhnul jsem do knihovny a vytáhnul manuál pro TP6.0 a tam už je shortcut vyhodnocování popsáno jako default a dalo se to přepínat nastavením, nebo direktivou {$B+} {$B-}. Ale jestli si pamatuju, tak to měly minimálně i TP5.5 a TP5.0, nejspíš i dřívější.

[vgy]

Jazyk C si vytrel s Pascalom prdel a následne si to isté s C urobila Java, teda keby nebol súdny spor a Oracle nezistilo, že uhrovitý mamlasové sú náhodou aj vo firmách a na súdoch, takže radšej si robili tie svoje orákloviny a na Javu sa vykašlalo...

[vgy]

a že nejaký Linus Torvalds nesúhlasí, aby sa kernel písal v Jave, tak to teda nikoho asi netankuje :)

[vgy]

ale čítal som, že lietadlá so svojimi desiatkami miliónov riadkov kódu vraj v C/C++ písané nie sú :), takže hľadať v tom chybu vraj na presčasy nejako nefunguje...

[vgy]

Ale vraj v Google vymýšľajú ako za letu povedať AI: vymysli a naprogramuj nové drivery na lietadlo a vymeň ich za letu :)

[PetebLazar]

Sonda Voyager 2 má údajně celkem 70KB paměti a její update v současnosti trvá cca den (rychlost spojení má být 16 bps). Ta paměť by dnes asi nevystačila ani na jednu ikonu, na mobilním telefonu.

[Radovan]

... Říká se, že jeden opravdový programátor zorganizoval v lodi Voyager doplnění programu pro rozpoznání, a to do několika stovek nevyužitých bytů v paměti. Doplněk programu nalezl, určil umístění a vyfotografoval nový měsíc Jupitera. ...

[koroptev]

nabidnu jinou optiku:

mnoho idiotu nepochopilo, co cecko vlastne je, (portable assembler) a zacali v tom programovat napr. gui aplikace

jinymi slovy moda a konkretne v pripade cecka a turbo pascalu preference syntaxe, nic jinyho

[~]

Koukas na to nespravne, C-cko prineslo boom her na PC. V jinych jazycych DOS ery to moc neslo a v assembleru to bylo hodne narocnejsi kodit a ladit, pouzival se jen v rutinach kde slo o rychlost.

[vgy]

A preto dnes vládne svetu C# Unity a Linux svet je v kýblu. Ak chcem predávať a nebudú to konzole, prachov až tak neuvidím...

[Miloslav Ponkrác]

Ono je to jednoduché: Autor C je Američan, autor Pascalu je Švýcar.

USA nikdy nepřijmou jazyk, který není z USA.

[okbobcz]

Tohle je blbost. ADA je oficiálním jazykem Pentagonu, a udělali ho Francouzi, a má naprosto jasně evropské kořeny.

[Miloslav Ponkrác]

Ada vznikla na Ministerstvu obrany USA. Zde vytvořili zadání, požadavky, a mnoho inteliktuální práce na budoucí Adě. Následně udělali soutěž, které se účastnilo více dodavatelských týmů, zdaleka nejen Francouzi. Z výsledků si USA vybralo jeden, na kterém začali pracovat.

Když budete dělat na USA projekt jako subdodavatel - tak stále jde o USA projekt.

Howgh.

[..... Izak .....]

PASCAL i jeho obdoba objektoveho DELPHI je naprosto OK - programy byly rychle, prehledne a rychle se psaly, vzpominam si, jak nejaka firma neco psala snad v zacinajicim Dot.NET nebo necem podobnem a za X mesicu to fort nemeli, kolega sedl zas voje stare delphi - a napsal to sam za 2 dny, vse bylo funkcni a odladene.

Vlastne ani nevim, proc se pascal moc nepouziva, kdyz je free i pro linux, par SW v tom napsano bylo, jen se musi doinstalovavat knihovny

[xkucf03]

Ono to není až tak o jazyku samotném, jako spíš o těch věcech kolem. Podobným způsobem můžeš implementovat systém třeba formou DB procedur/funkcí. Vtip je v tom, že máš ten jeden DBMS (nebo ten Pascal nebo C++ nebo čistou Javu) a ne hromady různých knihoven a frameworků od různých autorů, které ti sice mají šetřit práci, ale ve skutečnosti většinu času řešíš, jak co s čím propojit, proč to na sebe nepasuje, v které komponentě nebo vrstvě je chyba…

Přijde mi, že tu v určité době vznikl mýtus, že programování je vlastně ztráta času případně bezpečnostní riziko a že je lepší „jen“ poskládat dohromady hotové komponenty. Ona znovupoužitelnost je dobrá věc, ale v té extrémní formě, kterou lze dnes často vidět, to tu produktivitu naopak podkopává.

[okbobcz]

Souhlas. Vzestup a pád Pascalu jako běžného programovacího jazyka souvisí hlavně se vzestupem a pádem Borlandu. Céčko, C++ nikdy nebylo tolik spojeno s jednou firmou, a Céčko bylo vždy hlavním jazykem Unixu. S tím jak v C komunitě nikdo neměl extra majoritu, tak standardizace nebyla tak akademická a přijde mi, že byla víc respektovaná. Kdežto v Pascalu standardní Pascal a Borland Pascal jsou dost různé jazyky. Borland měl úžasný nástup v první polovině 90 let, ale druhou polovinu pohnojil co šlo. Jednak zaváděl svoje vlastní standardy, které se ale mimo Borland neujaly - BDE nebo VCL, a pak i jeho cenová politika byla neudržitelná. Delphi jsem nepoužíval, ale přišlo mi, že nějaké základní komponenty (pro práci s db) by měly být všude, a ne v Enterprise verzi, která stála balík. Microsoft vydělával na uživatelských licencích a vývojářské nástroje zlevňoval, Borland na licencích pro vývojáře. Dopadlo to, jak to dopadnout muselo. Kromě toho Borland propálil mraky peněz v pokusu konkurovat Microsoftu v Office aplikacích, a pak už odpadl.

[Miloslav Ponkrác]

Vzestup a pád Pascalu je spojen s Borlandem.

Rozšíření C a zejména C++ je zase dost spojeno s Microsoftem. Microsoft udělal pro rozšíření C/C++ možnái mnohem víc než unix.

Borland vznikl v době, kdy se kompilátory jazyků prodávaly za docela vysoké peníze. Což později vlivem Microsoftu a vlivem open source přestávala být pravda.

Pascal padl proto, že Borland nevěděl, co by za ty svoje bloatwary "Pascal + IDE" chtěl. (viz předchozí odstavec) Ty obrovské částky už prostě mnoho lidí platit nechtělo.

Další problém Borlandu byla obrovská chybovost jejich kompilátorů. Jednou už mi přetekl pohár a dal jsem v minulosti Borlandu nadobro papá. Dost se tím zjednodušil život. Namísto toho, abych ladil borlandské kompilátory a neustále kontroloval ve zdrojovém kódu jestli to Borland přeložil správně - jsem toho po odchodu od Borlandu byl ušetřen. Najednou jsem mohl programovat a ne ladil borlandské nedodělky.

Borland měl navíc velmi pomalé kompilátory. Mnoho dalšího času proto bylo ztráceno tím, že některé akce se přepisovaly do inline assembleru, aby to nebylo tak zoufale pomalé. U jiných kompilátorů to člověk dělat nemusel.

Prostě Borland se snažil - cenou i nekvalitou svých kompilátorů - aby člověk vybočil z komfortní zóny, a prostě přešel od Borlandu pryč.

[okbobcz]

Na borlandí překladač Pascalu jsem stížnosti moc neslyšel, ale je fakt, že to byl dost jednoduchý neoptimalizující překladač (v době, když jsem ho používal). O zabugovaném C++ jsem slyšel. Koncem 90 let šel Microsoft s kvalitou hodně nahoru. Když to zjednoduším a pominu prostředí jako PowerBuilder a podobné, tak se koncem 90 let aplikace pro Windows psaly v Delphi nebo ve Visual Basicu. Daly se psát i v Visual C++, ale bylo to výrazně pracnější než třeba v Delphi (a opravdu o dost). Technologicky bylo Delphi lepší než VisualBasic. Nicméně po roce 2000 přišel Microsoft s .NETem a C#, a Delphi technologicky nebyla o tolik lepší, aby si Borland mohl dovolit prémiové ceny.

[deda.jabko]

Na borlandí překladač Pascalu jsem stížnosti moc neslyšel, ale je fakt, že to byl dost jednoduchý neoptimalizující překladač (v době, když jsem ho používal).

Delal jsem v tom mimo jine vcelku velke podnikove IS a s prekladacem problemy nebyly.

Daly se psát i v Visual C++, ale bylo to výrazně pracnější než třeba v Delphi (a opravdu o dost). Technologicky bylo Delphi lepší než VisualBasic.

Nejhorsi na tom je, ze i dnesni vyvoj uzivatelskych aplikaci je pracnejsi nez s Delphi v devadesatkach.

[Peter Golis]

Daly se psát i v Visual C++, ale bylo to výrazně pracnější než třeba v Delphi (a opravdu o dost). Technologicky bylo Delphi lepší než VisualBasic.

Nejhorsi na tom je, ze i dnesni vyvoj uzivatelskych aplikaci je pracnejsi nez s Delphi v devadesatkach.

Delphi a jeho C++ náprotivok (C++Builder) AFAIK žije u spoločnosti Embarcadero Technologies, i keď je to asi len pre Windows. Ale určite sa nájde nejaká OSS klikacia alternatíva umožňujúca naklikať si notepad za 5 minút aj bez znalosti programovania, ako napríklad Lazarus aj s VCL. Ale kto by dnes používal desaťročia overené nástroje, že?

[deda.jabko]

Ale kdo dneska chce desktopove aplikace? A udelat webovou aplikaci dneska chce pomalu dva lidi, jeden je odbornik na FE a druhy na BE. Takze po ctvrtstoleti vyvoje technologii jsme se dostali do stavu, ze na na programovani i relativne jednoduchych veci nepotrebujete jednoho programatora! Ale hned dva! A to se vyplati!

[Miloslav Ponkrác]

Což je spíše symptom klesající kvality programátorů než čehokoli jiného.

[Radovan]

To je ten Wirthův zákon

[koroptev]

zato ta aplikace bezi vsude

tem firmam, co za to platej velmi tucny sumy, se to z nejakyho duvodu vyplati, proc asi..

[Radovan]

Všude kde máš nejnovější verzi Widlí nebo nejnovější verzi Androidu.

A to se vyplatí, Horste!

[koroptev]

co to placas? i kdybych prijal tvoji optiku, tak relevantni je chrome, ale zjednodusene receno - v build systemu si reknes "chci tuhle a tuhle kompatibilitu" a mas venku frontend, co pokryva 9X% uzivatelu, kde X je 5 a vys..

[Radovan]

K tomu 8+ GiB RAM a aspoň čtyřjádrový procesor

[koroptev]

jednak to maji dnes i mobily a nikoho to moc netankuje (a hadej co, do budoucna vykon tech stroju a pocet jader nebude co ... nebude klesat) , druhak to ma nejakou penalty, ale takhle velkou jen pokud bys byl clovek, co by to podobnym zpusobem kurvil ve zcela libovolnym jazyce a frameworku..

[Radovan]

Mají nebo musí mít?

Doom běží i na těhotenském testu

Měl jsem mobil s osmibitovým procesorem, telefonoval jsem z něj a posílal SMS stejně jako dnes. Na stisk klávesy měl menší latenci než ty dnešní šmatlaplacky.

[koroptev]

nemel jsi v nem navigaci, nemohl jsi tu smsku nadiktovat hlasem, nemohl jsi tim telefonem vest videokonferenci s dalsima peti lidma a proste dlouhej seznam veci, co jsi "zapomnel" zminit..

zbejva, abys dodal "nic z tech novot nepotrebuju" a muzem tu debatu ukoncit s "dalsi lhar, kterymu se nelibi dnesek a zitrek, tak vidi jen to spatny"

[Radovan]

Navigaci mám v hlavě a kompas v batohu, SMS namačkám na klávesnici i v hlučném prostředí a s velkými písmeny která ty neumíš, s pěti lidmi se sejdu osobně a bavíme se mnohem lépe, co tam máš dál?

[koroptev]

tozn. "nic z tech novot nepotrebuju"?

[Radovan]

Opravdu to tolik potřebuješ, nebo jenom sám nic neumíš?

Digitální diář jsem na poznámky používal v dobách kdy ty jsi říkal hovnu papů, ale přesto stále dovedu psát tužkou na papír. A dělám to. Také používám vlastní mozek místo počítače, nikoliv naopak

[koroptev]

je videt, ze jsi clovek na spravnem (nekde jinde nez v mem okoli) miste

pokud jako negaci "potrebujes to" vnimas "nic neumis", musi s tebou byt radost nejen pracovat ale i existovat

kazdopadne - neser se do toho, lidi jako ty, co maji pocit, ze by se vse melo zakonzervovat v nejakym stavu, z definice nemaji co noveho prinest, potreba jsou lidi, co vnimaji kontext a rovnovahu, ne fundamentalisti

[koroptev]

stran ty latence smatlapacek - zahod android a kup si iphone

[okbobcz]

Schválně jsem se díval na Borland, a je to firma plná paradoxů. V podstatě z té party, která dělala Turbo Pascal a Delphi, tak v 97 už nikdo nedělal. Interně Borland vyvíjel nový překladač Pascalu, Cčka, Moduly a Ady. Nicméně se v Borlandu rozhodli koupit externí překladač Wizard C, přejmenovaný na TurboC, a dál nepokračovat ve vývoji, tak jeho autor odešel z Borlandu a tento překladač vydal pod značkou TopSpeed. Tento překladač do výrazně lepšího kódu než překladač od Borlandu.

[Miloslav Ponkrác]

Já vám to zjednoduším.

Lidé do Borlandu přicházeli s kompilátory a odcházeli nespojení. Kompilátor Pascalu přinesl do Borlandu Hejlberg, a zakladatel Borlandu Kahn přišel s myšlenkou integrovaného IDE - složením vznikl Turbo Pascal. Nicméně Hejsberg později v Microsoftu vymýšlel J++ (microsoftí verzi Javy) a později C# jazyk.

Microsoftí HR oddělení často postávalo přímo před firmou Borland a oslovovalo přicházející zaměstnance s nabídkou přejít do Microsoftu. A úspěšně přetahovalo kvalitní lidi.

Někdy v 90. letech už měli asi všichni v Borlandu plné zuby jeho zakladatele Khana, a prostě ho vykopli z firmy. Borland už v té době dost zápasil s konkurencí Microsoftu. Borland koupil databázi dBase, koketovali s kancelářským softwarem, vyvinuli Quattro Pro, a pak Khana vykopli, protože tímto směrem nechtěli jít.

Khana si pamatuji jako týpka, který pořádal tiskové konference Borlandu, mající představit novinky. A půlka času se plýtvala na hudební představení, kde Khan hrál na flétnu, aby se pochlubil, že to umí.

První verzi Delphi stvořil ještě Hejsberg. Pak koupili někde implementaci CORBA pro distribuované objekty.

Následně se přejmenovali na Inprise, což časem vyhodnotili jako chybu. Inprise byla jedna velká obchodní ztráta.

Atd.

[deda.jabko]

Jednak zaváděl svoje vlastní standardy, které se ale mimo Borland neujaly - BDE nebo VCL, a pak i jeho cenová politika byla neudržitelná.

IMHO, VCL byla ve sve dobe uplna spicka.

Microsoft vydělával na uživatelských licencích a vývojářské nástroje zlevňoval, Borland na licencích pro vývojáře.

Kdyz na konci devadesatek kralovalo Delphi, bylo VS neuveritelne neohrabane, moc toho neumelo, a prace s nim byla utrpeni. Co si vzpominam, treba napovidani kodu spis nefungovalo nez fungovalo a bylo zaoufale pomale.

Ale Microsoft mel docela drsnou licencni politiku. Treba nam chodili na ,,upgrade'' stylem: ,,Upgrade z libovolne verze Delphi na Visual Studio za 0 Kc.'' Jsem si tehdy naivne rikal: To se smi?

[Miloslav Ponkrác]

VCL ovšem byla grafická knihovna.

V té době se GUI programy často dělaly ve Visual Basicu (neplést s tím, co je teď v .NET). A tam to šlo bleskovou rychlostí. Vzniklo to asi 5 roků před Delphi. V Basicu se dají GUI aplikace šlehat raketovou rychlostí, a v té době jsem to dělal často.

Mám dojem, že dodnes je součástí standardních Windows poměrně dost programů, které si Microsoft naprogramoval ve Visual Basicu.

Stejně se daly programovat GUI databázové aplikace v Microsoft Accessu, bylo to velmi luxusní a sám jsem jich tehdy dost naprogramoval.

Dovolil bych si tvrdit, že Delphi je koncepčně fakticky opsaný Microsoft Visual Basic.

[okbobcz]

https://cs.wikipedia.org/wiki/VCL

Zrovna ve Visual Basicu jsem dělal několik let, a to s jeho poslední šestkovou verzí. Formulářové aplikace se v tom psaly dobře. Problém byl, jakmile člověk potřeboval trochu low level přístup, případně pokud jste si chtěli napsat vlastní ovládací prvky. Ne, že by se to asi nedalo, ale pak to bylo pomalé. Microsoft razil filozofii, že ovládací prvky se píšou v MSVC, a pak používají ve Visual Basicu. Delphi a později .NET umožňovalo psaní i ovládacích prvků. Ještě jinak - v Delphi i v .NETu bych byl schopný napsat Delphi nebo .NET. Ve Visual Basicu bych Visual Basic nenapsal.

[Miloslav Ponkrác]

Visual Basic byl báječně použitelný v tom, že se dal propojit s jakýmkoli jiným jazykom. Low level věci jsem napsal v C/C++/ASM - a prostě je volal v Basicu.

S Delphi jsem dělal také. Ale u VCL jsem narazil, že není multithreadově bezpečná. Takže vyfikundací, které jsem musel dělat u multithreadových aplikací s Delphi, a zbytečných sunchronizací - to mě hodně otrávilo.

Visual Basic byl skvělý nástroj. GUI člověk napsal v něm. K dispozici byla asi miliarda ovládacích prvků na stažení, další nabízely firmy za peníze. Daly se napsat i v Basicu přímo.

Propojit cokoli s Visual Basicem žádný problém. COM objekty snadno. Databáze snadno. Volání sdílených knihoven snadno. A tak dále.

Pro mě byl nakonec ten Visual Basic daleko šikovnější nástroj než Delphi.

Borlandi si všechno dělali po svém, a pak nějaká interoperabilita byl problém. Často s nutností instalovat vlastní ovladače ála databázové drivery. Prostě to nebylo ono.

[xkucf03]

Často s nutností instalovat vlastní ovladače ála databázové drivery. Prostě to nebylo ono.

Java má JDBC, Perl má DBI, PHP má PDO, Microsoft má asi pět takových API… v podstatě každý jazyk má svoji databázovou abstrakci a někteří na to rezignují a jsou tam jen knihovny pro konkrétní DB, takže nulová přenositelnost… Za společný standard by šlo snad považovat ODBC… ale že bych si při jeho používání chrochtal blahem, to zrovna ne.

[okbobcz]

BDE vznikalo ve stejné době jako ODBC. ODBC je klasická ukázka overengeeneringu - navíc už před dekádou byl problematický, kvůli limitům na velikost stringu, velikost dotazu. Je to 16bit API. Když jsem se bavil s autorem PCFANDu, tak vyprávěl, kolik času spálili na neúspěšném vytvoření ODBC driveru pro PCFAND - z různých důvodů - třeba i mizerné dokumentace. V ideálním světě by ODBC bylo dávno mrtvé, ale je to asi jediný standard, který se dá napsat v Cčku, a portovat třeba do Unixu. Další vrstvy, typu už vyžadují podporu COM, DCOM. V druhé polovině 90 Microsoft zaváděl nové db API co 2 roky. DAO, ADO, ADODB, ADO.NET. Problém je, že napsat driver rozsahu ADO.NETu vyžaduje několik člověkolet, pokud se použije univerzální - ADO.NET vůči JDBC nebo ODBC, tak to má samozřejmě svojí režii nebo narážíte na limity ODBC atd. Ještě do toho jdou věci, které nepochopíte. Vertica měla protokol kompatibilní s Postgresem. Když byla ve vlastnictví HP, tak schválně vytvořili nekompatibilitu, takže už nešlo používat drivery k Postgresu a dodávali pouze ODBC. Instalace ODBC na Unixu - čajíček.

[Miloslav Ponkrác]

Já mám s ODBC vynikající zkušenosti. Dokonce natolik vynikající, že dodnes používám v programech svou sadu tříd PonkracOdbc*, a dokonce dodnes na tom chodí programy pod nejnovějšími Windows zcela bez problémů.

Dokumentace k ODBC je výborná, jak je u Microsoftu vcelku zvykem.

A dokonce jsem už i ODBC driver vytvořil. O autorovi PCFANDu si myslím své.

ODBC považuji za poměrně dobrý standard. Vámi zmíněných limitů jsem si nevšiml. Jako univerzální C API, které je volatelné z libovolně blbého programovacího jazyka, se to vcelku nedá vymyslet moc lépe. Snad jen čtení hodnot sloupců vrácených SQL příkazy je trochu příliš pointerové. Docela seriózně by mě zajímalo, co je na něm špatně. Je to IMHO dobrý sjednocující standard.

A dál už je to jednoduché.

DAO je objektové rozhraní, něco jako ODBC zabalené do objektů a tříd pro Visual Basic.

Další rozhraní umožňují volání přes COM obejtový model.

Jiná rozhraní pro .NET.

Kéž by databázová rozhrnaí byla všude tak slušně unifikovaná a univerzální jako u Microsoftu!

[Miloslav Ponkrác]

Možná by pro objektivitu a konec manipulativních tvrzení bylo dobré sdělit o PC FANDu toto:

1) PC FAND databáze neuměla SQL.

2) Je pak jasné, že udělat driver pro ODBC rozhraní pracující s SQL dotazy - je pak těžké, že ano.

Právě na neschopnosti PC FANDU mít standardní SQL dotazy celý PC FAND skončil a zanikl.

Teď už bude vypadat stěžování si autora PC FANDU úplně jinak, že?

[okbobcz]

Nepotřebujete umět SQL - to řeší JET. V podstatě musíte napsat "IISAM driver files that provide data access between Microsoft Jet and the other DBMS". Hrál jsem si s tím před 22 roky, takže detaily už jsem dávno zapoměl. Ale pamatuju si, že jsem psal SQL dotazy do datových zdrojů, které rozhodně neumí SQL jako seznam procesů v NT nebo registry. Případně napsat jednoduchý parser, který zvládne "SELECT col1, col2 FROM tab WHERE col=" by asi neměl být problém.

Dneska je dokumentace habakuk, a dá se jednoduše vygooglit. Tady se bavíme o druhé polovině 90tek, kdy dokumentace byla, pokud jste měl zaplaceno, pouze na MSDN a nějaké chytré vyhledávání ve stylu google nebylo. Když jsem začal programovat v 97, 98, tak i když jsem měl přístup k MSDN, tak dohledat něco, co nebylo úplně běžné bylo oser.

Těch důvodů proč PC FAND skončil bylo víc - předně autor odešel do důchodu, sekundárně si prošlapali slepou cestu s migrací do Javy nebo podporou Prologu, a finálně člověk, který dělal portaci do Win nečekaně zemřel a do hrobu si sebou vzal i několika roční práci. Důvodů bylo určitě víc - skončil i 602 SQL server, což byla databáze technologicky o dvě dekády mladší.

[Miloslav Ponkrác]

Já se vrátím k PC Fandu. To byla 16bitová aplikace, a jako taková se plácala s jinými problémy - viz vámi zmíněna 16bitová omezení ODBC.

Pc fand skončil proto, že to byla dále už slepá cesta.

Například není těžké někoho naučit dělat s Microsoft Access, ani neprogramátora - a může si udělat co databázového chce včetně formulářů, zadávání hodnot a libovolného GUI. Přičemž základní wizardi mu vygenerují zadávání, zobrazování a x dalších akcí aniž by se musel moc snažit. Dostupné už v 90. letech 20. století.

Možnosti Microsoft Access jsou přitom o mnoho řádů vyšší než Pc fandu. Navíc je to plnohodnotné Windows.

Pc fand nezaručoval nic. Když vám zbuchne počítač, nezaručoval, že data a databáze budou v nějakém konzistentním stavu. Možná ano, možná už z ní nic nepřečtete. Zato každá slušná moderní databáze zaručuje i při zbuchnutí konzistenci dat - a to buď ve stavu před / po SQL příkazu, případně transakcí.

A tak bych mohl psát dál a dál. Pc fand uměl mnoho, ale nic pořádně. V době bastlení to na jednoduché věci stačilo, ale nároky se posunuly dále.

16bitová aplikace pc fand také měla problémy, ale autoři ji do 32bitů už přepsat nedokázali.

Hlavně, že dělali furianty a blbli s tím, že do pc fandu udělali interpret Prologu, ale důležité věci skutečně potřebné jim zlomily vaz, a popasovat se s tím nedokázali.

[deda.jabko]

Například není těžké někoho naučit dělat s Microsoft Access, ani neprogramátora - a může si udělat co databázového chce včetně formulářů, zadávání hodnot a libovolného GUI. Přičemž základní wizardi mu vygenerují zadávání, zobrazování a x dalších akcí aniž by se musel moc snažit. Dostupné už v 90. letech 20. století.

Na zakladni CRUD je Access docela dobry, problemy ma dva. Pokud chce clovek vybocit mimo zakladni operace CRUD zacne to byt peklo a druhy problem je, kdyz se ,,programovani'' chopi clovek, ktery o databazich nic netusi, protoze udelat databazi v Access je prece jednoduche. Nejednou jsem zazil, ze si lidi v Accessu vytvorili a pouzivali moloch bez jakekoliv koncepce, navrhu, normalizace a jednoho krasneho dne jim to zacalo prerustat pres hlavu a nikdo nevedel, co s tim, a jestli bych to dokazal predelat...

Pc fand nezaručoval nic. Když vám zbuchne počítač, nezaručoval, že data a databáze budou v nějakém konzistentním stavu. Možná ano, možná už z ní nic nepřečtete.

Az do prichodu W2K nemohla zadna souborova databaze typu Fand/xBase zarucovat v DOSu/Windows cokoliv, protoze takove garance OS proste neposkytoval. ...a presto na FoxPro zcela bezne bezely firmy o tisicich zamestnancich a pouzivali to na vsechno od planovani vyroby az po mzdy.

[Miloslav Ponkrác]

1) Microsoft Access není profesionální databáze. Je to přesně ten produkt, který má podobný use case jako pc fand. Prostě bastlící databáze.

Nekoncepční strukturu databáze si můžete udělat na jakémkoli databázovém systému. Tomu se meze nekladou.

2) V DOSu jste si mohl udělat co chcete, protože DOS není ipso facto operační systém, ale spíše knihovna podprogramů, které si můžete zavolat. DOS programátor má vše plně v rukách, co si udělá, to má. Takže není pravda, že pod DOSem nelze udělat odolnou databázi.

Celá ta sranda je o tom, že prostě v dobách pc fandu se bastlilo, a nějaké vyšší nároky se moc neřešily. PC fand nemohl vůbec ani pomýšlet na konkurenci produktům, které například něco garantovaly, apod. Proto také skončil.

Ono je strašně hezké mít sentimentální vzpomínky na údajně super kvalitní pc fand či jiný super kvalitní software / operační systém / programovací jazyk, atd. atd. atd.. Ale realita je prostě tak, že pc fand by se dál bez změny koncepce a přístupu nedostal, protože už nemohl plnit na něj kladené nároky. Prostý přepis do Windows / 32 bitů / SQL a vše to, co nezvládl by ho stejně nezachránil. Doba jde dál, a požaduje se seriózní a zaručené chování, což pc fand nabídnout nemohl.

[deda.jabko]

2) V DOSu jste si mohl udělat co chcete, protože DOS není ipso facto operační systém, ale spíše knihovna podprogramů, které si můžete zavolat.

DOS je operacni system v tom smyslu, ze poskytuje abstrakci nad HW, jako kazdy jiny OS.

Takže není pravda, že pod DOSem nelze udělat odolnou databázi.

Ano, to je pravdive a nicnerikajici tvrzeni. Teoreticky to mozne je, prakticky nikoliv. V momente kdy zacne pouzivat tehdejsi souborovy system, muze na garance cehokoliv zapomenout.

[okbobcz]

V momentě, kdy dojde k poškození filesystému, tak přijdete o databázi i na dnešních systémech. Implementace transakcí v databázi je ochranou pouze proti crashi databáze. Jako minimum pro implementaci databáze se bere schopnost si vynutit fsync, a případně možnost sdílených zámků. Mám pocit, že tohle už 6tkový DOS uměl. Některé databáze fsyncovaly, jiné nikoliv - např. MySQL MyISAM. 602SQL měla fsyncování nastavovatelné, ale uživatelé to měli většinou vypnuté, protože to bylo o dost pomalejší.

[deda.jabko]

V momentě, kdy dojde k poškození filesystému, tak přijdete o databázi i na dnešních systémech.

To je jasne, ale poskodit tehdy FS nebylo zase nic moc sloziteho. Tvrdy reset + nasledny chkdsk bylo neco uplne samozrejmeho. Cf. dnesni OS nebo z tehdejsich treba NT4.

Jako minimum pro implementaci databáze se bere schopnost si vynutit fsync, a případně možnost sdílených zámků. Mám pocit, že tohle už 6tkový DOS uměl. Některé databáze fsyncovaly, jiné nikoliv - např. MySQL MyISAM. 602SQL měla fsyncování nastavovatelné, ale uživatelé to měli většinou vypnuté, protože to bylo o dost pomalejší.

Nebudu kecat, uz je to hodne let, ale rozbite databazove soubory byly tehdy dennim chlebem, to same zmizele soubory po chkdsk. Jestli to bylo spatnym (ne)pouzitim fsync nebo jeho nepritomnosti/spatnou implementaci, to uz asi nezjistim.

[okbobcz]

Stavárna (ČVUT) měla studijní systém napsaný ve FoxPro, běželo to v DOSu s Novelláckou sítí (první půle 90 let). Neslyšel jsem, že by s tím byly problémy. Lidi z mé katedry SI se kolem toho motali (nevím jestli to přímo psali). Dr. Demel, dr. Hora. Když jsem dělal v Logosu, tak se tam psaly docházkové systémy a systémy pro kupónovou privatizaci. MS Access nad Windows 3.11 (možná už NT4). Ty docházkové systémy byly rozmrdané skoro permanentně. Byly tam velké rozdíly v kvalitě a všech vrstev. Je možné, že si Access nerozuměl s Novelláckou sítí nebo s nějakou sítí. 2003 jsem dělal v jedné malé firmě analytika a dělali web aplikace v PHP vůči MySQL. Rozpadlou databázi tam měli 1-2x do měsíce.

Někdy kolem roku 2010-2012 byla velká vlna migrací z Accessu do Postgresu. Školil jsem jednu firmu, která psala nějaký sw pro pojišťovny v Accessu, ktery prý aktivně používalo snad několik set lidí. Tomu jsem vůbec nechtěl věřit, a říkal jsem "to musí být furt rozbitý". Ten šéf mi jen přitakal, že jo.

[Miloslav Ponkrác]

Windows 3.x byly rozmrdané z principu. A je jedno, jestli jste tam provozoval kalkulačku, notepad nebo access.

To byly systémy ještě 16bitové, s kooperativním multitaskingem, a nedostatečnou ochranou jádra systému. Ve své podstatě to byla nadstavba MS-DOSu, kterým také boot počítače startoval. Jeden blbý pointer v programu poslal kernel do kolem s porušenými strukturami jádra operačního systému.

Windows 3.1x se liší pouze tím, že čas od času provedly kontrolní součty vnitřních struktur jádra, a případně je opravily. Takže se složity mírně méně často než Windows 3.0.

Když provozujete něco nad exkrementovým systémem, tak do toho netahejte historky o údajné nespolehlivosti accessu. Protože pod Windows 3.x bylo nespolehlivé úplně všechno. Vinou systému.

[okbobcz]

Vy jste vtipálek . A co se tak tady dalo používat? Bavíme se o první polovině 90 let - před příchodem Windows95. 99% jelo s win - NT ještě moc nebylo a OS/2 taky skoro nikdo neměl. A že byste si jako dodavatel aplikace mohl diktovat, co mají mít klienti nainstalované - tak tak to v té první půli 90 let nebylo.

[okbobcz]

Nehledě na to, že NTčka vyžadovala hw, který drtivá většina zákazníků neměla - o ceně za licence nemluvě.

PC a sw od Microsoftu bylo low cost - a stejně to bylo hodně drahé. Pak byly projekty pro velké státní podniky, kde už se běželo na Unixech a už i SQL databázích (Informix, Oracle, DB2). Ale to byly ceny o dva - tři řády větší než co dělal Microsoft, a u čeho jsem byl.

[Miloslav Ponkrác]

Windows 3.11 byly vydány někdy ke konci roku 1993, co si pamatuji. A reálně tedy přišly do českých vod tak někdy 1994.

V té době byly Windows NT 3.1 už na světě. Windows 95 přišly někdy 1995, NT 4.0 1996.

Tu přechodovou dobu si velmi dobře pamatuji, neb se také leccos řešilo.

To nic nemění na tom, že Windows 3.x byly sračky - a padalo pod nimi vše už důvodů žumpovitosti systému. Hodnocení padání aplikací pod Windows 3.x beru za nesoudnost velkého formátu.

[okbobcz]

Byly aplikace, které tolik nepadaly, takže za vše nemohly jen Windows. Nehledě na to, že MS Access se při větší multiuživatelské zátěži pravidelně rozbíjel, a to už dávno uživatelé běželi minimálně na dvoulitrech.

[petr_p]

běželo to v DOSu s Novelláckou sítí (první půle 90 let). Neslyšel jsem, že by s tím byly problémy.

To bude právě tou netwarovou sítí. NetWare klient se zaháčkoval do jedné z mála abstrakcí, co DOS poskytoval, do souborového systému, a souborové operace se po síti přeposílali na NetWare server, který samozřejmě měl vlastní souborový systém (ne FAT) a vlastní operační systém (ne MS-DOS). Takže poškození souborového systému se nekonalo.

Jiná věc bylo poškození dat na úrovni aplikace-databáze, která naopak u těchto aplikací byla v serverovém nasazení obvyklá. Příčinou ale byla databáze samotná, protože nepředpokládala paralelní přístup více uživatelů. To pak dodavatel aplikace flikoval vytvářením zámkových souborů, nebo se prostě administrativně nařídilo, že aplikaci smí používat nejvýše jeden uživatel :) Ono v menších nasazeních, kde jednu agendu stejně vyřizoval jen jeden zaměstnanec, to zas tak nevadilo.

[Miloslav Ponkrác]

Ano, poté, co jistý maník Gary Killdal dal přednost golfu před jednáním s IBM, na což IBM zareagovalo jednání s jiným Billem Gates a rozšířením MS-DOSu se stalo hodně věcí.

Zoufalý Gary Killdal pod hlavičkou Digital Research začal vyvíjet konkurenční DR-DOS, který měl práva na soubory, task switcher a pár dalších věcí.

Pak to koupil Novell a udělal k tomu síťovou verzi. Pak to nakonec koupila Caldera a nabízela to jako součást Caldera linuxu.

Nicméně DOSovský file redirector, který dělal abstraktní vrstvu nad souborovým systémem byl už dávno předtím zneužíván různými sítěmi pro přesměrování souborů na síť. Novell to jen zavedl do standardního DOSu. Pak samozřejmě soubory sídlily na vzdálených počítačích aniž to program tušil.

DOSovský file redirektor nebylo oficiální rozhraní pro aplikace. Nikdy nesloužilo jako oficiální API. Bylo objeveno hackersky zpětným reinženýrinkem v kódech DOSu.

[okbobcz]

Už i ty souborové databáze podporovaly multiuživatelský přístup (a zamykání) . Vyžadovalo to podporu systému. Něco jiného je, pokud aplikace přistupovala přímo k souborům. Ještě z dob kolem roku 95 si pamatuji diskuze typu - databáze je zbytečná, pomalá, a na co vlastně databázi, když soubory stačí.

[PetebLazar]

Moderní databáze umožňují již dlouho definovat stupeň redundance uložení dat, při vyuzití "raw-device" ani nevyžadují filesystém poskytnutý OS.

[okbobcz]

I ty staré databáze uměli mirroring. Oracle zrcadlí transakční logy, interbase z první poloviny 80 let uměla mirroring dat, analytické databáze umožňují nastavit redundanci nad N nody. V roce 2003 jsem dělal s hezkou malou databází solid, která mirroring uměla také. Ale to už je trochu jiná diskuze. Ta diskuze se vedla ohledně toho jestli jaká je spolehlivost databáze na starém filesystému a operačním systému typu DOS, a novém filesystému a novém operačním systému. Vůbec nepopírám pokrok, jen si nejsem úplně jistý jestli ta odolnost vůči rizikům musí být na nových systémech výrazně větší. Mám zkušenost, že pokrytím (vyřešením) nějakého rizika většinou vznikne riziko jiné (jen s jinými projevem a možná menší četností). Prostě rizika, rizikové faktory nejde eliminovat (jde je jen dočasně zakrýt).

[xkucf03]

jen si nejsem úplně jistý jestli ta odolnost vůči rizikům musí být na nových systémech výrazně větší

Nemusí. Např. taková Kafka běžící na MS Windows se do dvou týdnů rozsype, je tam nějaký problém se zámky souborů. To znamená promazat data a přijít o uložené zprávy. Řešení to buď nemá nebo se to řešit nechce – na téhle platformě to stejně nikdo soudný nepoužívá, maximálně tak nějaký vývojář pro testování, který si data ale promazává častěji, než to stihne vyhnít.

Ale to jsou MS Windows. Na GNU/Linuxu tenhle problém není.

[Radovan]

MS-DOS poskytuje programu:

1. Přístup k souborům na disku.
2. Eeeeé...

[Miloslav Ponkrác]

DOS sice poskytuje abstrakci nad (maličkou částí) hw, ale nijak vám nebrání ji obejít.

Program spuštěný v DOSu de facto funguje jako jádro operačního systému, a řídí celý počítač. To je naprosto odlišná situace proti Windows, unixu, MacOS a dalším, kde program má velmi ustřihnutá křídla a rozhodně ne plnou kontrolu nad počítačem.

[deda.jabko]

Program spuštěný v DOSu de facto funguje jako jádro operačního systému, a řídí celý počítač.

To jako kazdy program si nese sebou vsechny ovladace? To jako kazdy program si sebou nese implementaci souboroveho systemu?

DOS sice poskytuje abstrakci nad (maličkou částí) hw, ale nijak vám nebrání ji obejít.

No, a? OS ma dve funkce, jednak poskytovat abstrakci HW, starat se o spravu systemovych zdroju. Obe tyto funkci DOS plni. To, ze z duvodu omezeni hardwaru tyto funkce neplni zcela, je na jinou diskuzi.

S takovou by za operacni system neslo povazovat ani CP/M, Win9x, macOS (classic) a dalsi, se vsemi dusledky. Ale takovy uz je svet Miroslava Ponkrace.

[Miloslav Ponkrác]

Ad 1) V DOSu si většinu ovladačů nesl program, pokud jste chtěl i tak základní věci jako je grafika nebo zvuk. DOS poskytoval spouštěč programů a souborový systém.

Ad 2) Znovu, pletete hrušky s jablky. DOS je spíše knihovna podprogramů než operační systém.

Ad 3) Představte si, že ta báječná dlouhá diskuse zde byla striktně o věci a tématu. Až deda.jablko začal útok ad hominem. Dost to říká o vaší osobě, kdo jste zač, a co si o vás myslet.

[deda.jabko]

DOS poskytoval spouštěč programů a souborový systém.

Jeste treba textovy vstup/vystup, proste to co IBM PC v roce '80 umelo.

Ad 2) Znovu, pletete hrušky s jablky. DOS je spíše knihovna podprogramů než operační systém.

A co ty podprogramy delaly?

Dokazes mi najit nejaky relevantni zdroj, ktery bude tvrdit, ze MSDOS neni operacni system, ale knihovna funkci?

Je CP/M operacni system nebo knihovna podprogramu?

Je Win9x operacni system nebo knihovna podprogramu, kdyz v nem lze prakticky pristupovat ke vsemu HW stejne jako v MSDOSu?

Plati to i pro MacOS Classic?

Představte si, že ta báječná dlouhá diskuse zde byla striktně o věci a tématu. Až deda.jablko začal útok ad hominem. Dost to říká o vaší osobě, kdo jste zač, a co si o vás myslet.

Uz jsem dostatecne stary na to, abych zazil dost diskuzi, kde jisty pan Ponkrac zacal sve dojmy (v rozporu s realitou) vydavat za fakta. A toto je jedna z nich.

[Radovan]

Ten textový výstup byl tak pomalý, že i Turbo Pascal uměl sám psát přímo do paměti. B800H?

A ve hrách jsi stejně četl scankódy přímo z portu.

Na ZX Spectru je operační systém interpret BASICu.

CP/M je osmibitová hračka, zato CP/M-86 dokázal z diskety nabootovat pod sekundu a chránit na ní data několika uživatelů před neoprávněným přístupem.

O dekádu později, když jsi ve W95 neznal heslo, tak stačilo stisknout Escape :puke:

[xkucf03]

O dekádu později, když jsi ve W95 neznal heslo, tak stačilo stisknout Escape

To bylo ale jen na desktopu nepřipojeném k síti, kde to heslo bylo stejně k ničemu, ne? Na počítačích připojených do sítě to bylo složitější. Pamatuji si, jak jsem na základce objevil, že z toho přihlašovacího dialogu se můžu dostat do nápovědy a ten prohlížeč nápovědy má zase dialog na otevření jiného *.hlp souboru, no a v něm šlo místo *.hlp zadat *.* a najít si nějaký EXáč a ten pak šel odtamtud spustit :-)

[deda.jabko]

CP/M je osmibitová hračka, zato CP/M-86 dokázal z diskety nabootovat pod sekundu a chránit na ní data několika uživatelů před neoprávněným přístupem.

CP/M-86 jsem nepotkal, mohl bys mi proto vysvetlit, jak tam meli vyresene, aby na 8086/88 jednotlive procesy nemohly pristupovat na libovolne misto v pameti a pristupovat primo na porty (jako to delaly DOSove programy)?

[Radovan]

Úplně stejně jako UNIX na PDP-11.

Mohl bys mi ty vysvětlit, jak měl MS-DOS vyřešenou ochranu uživatelských dat a přístupová práva k nim?

[deda.jabko]

Úplně stejně jako UNIX na PDP-11.

Porad tomu nerozumim. Jelikoz PDP-11 doma nemam, pro jistotu jsem vytahl i Lions' Commentary on the Unix Operatings systems, a podle toho i Unix na PDP-11 rozlisoval kernel a user mode a pouzival segmentaci pameti k oddeleni jadra a uzivatelskeho prostoru.

Takze zopakuji otazku: Jak meli CP/M-86 vyresene, aby na 8086/88 jednotlive procesy nemohly pristupovat na libovolne misto v pameti a pristupovat primo na porty (jako to delaly DOSove programy)?

[Radovan]

Jak říkám, úplně stejně jako UNIX na PDP-11. Je to věc procesoru.

Takže jak MS-DOS chránil uživatelská data na disku před neoprávněným přístupem?

V CP/M-86 ses k nim bez hesla nedostal.

[deda.jabko]

Je to věc procesoru.

Jak se na 8086 prepnes z kernel mode do user mode a zpet? Nebud slusny a rekni instrukce!

[Radovan]

Nevíš? Tak schválně, jak to přepínal M$ Xenix, nejrozšířenější Unix své doby?

[deda.jabko]

Tak schválně, jak to přepínal M$ Xenix, nejrozšířenější Unix své doby?

Vsak se te na ptam! Zajimaji me ty instrukce, ne to, ze to delalo dalsich n+1 operanich systemu.

[deda.jabko]

*na to

[Radovan]

Už jsem ti to řekl dvakrát, a mluvím o tom stroji na kterém UNIX v roce 1972 rozjeli, ne o pozdějších verzích z osmdesátých let.

Ale ty tvrdíš že MS-DOS byl operační systém, tak mi řekni jak přiděloval programům paměť? Jak přihlašoval uživatele? Jak chránil jejich data?

Dělal to MULTICS v roce 1965, tak jak to dělal MS-DOS v roce 1981?

[deda.jabko]

Už jsem ti to řekl dvakrát, a mluvím o tom stroji na kterém UNIX v roce 1972 rozjeli, ne o pozdějších verzích z osmdesátých let.

Jak to udelali v roce '72 netusim, protoze k tomu nemam zdrojaky. Ale V6 z roku 75, ktera jela na PDP11/40 (z roku '73) a ke ktere existuji komentovane zdrojaky, pouzival normalne kernel/user mode s nastavenim opravneni k jednotlivym segmentum.

A vis proc? Protoze to processor podporoval!

Dělal to MULTICS v roce 1965, tak jak to dělal MS-DOS v roce 1981?

Multics, stejne jako PDP-11, mel spravu pameti, ktera to umoznovala. 8086/88 nikoliv.

Tak me teda zajima, jak to v CP/M-86 udelali.

Ale ty tvrdíš že MS-DOS byl operační systém, tak mi řekni jak přiděloval programům paměť? Jak přihlašoval uživatele? Jak chránil jejich data?

Ja opravdu nikde netvrdim, ze OS musi prihlasovat uzivatele. Treba v OS pro embedded zarizeni je to zcela zbytecna funkcionalita. K tomu, ze ochrana dat je problematicka, jsem se jiz vyjadril. Ale nejak jsem se stale nedozvedel, jestli W9x nebo MacOS (classic) taky nebyly OS, kdyz nechranili data uzivatelu. A jelikoz mas problem vysvetlit, jak tu ochranu delal CP/M-86 a misto toho mlzis, nejspis to nezvladal ani tento OS.

[Radovan]

Multics, stejne jako PDP-11

Aj, to se pozná odborník. Když nerozezná hardware od softwaru!

Ano, v roce 1973 to procesor už podporoval. A jak to dělal MS-DOS 5 na dvaatřicetibitové 486ce v roce 1991? No pověz!

Jak to dělal CP/M-86 v roce 1981 se můžeš podívat na straně 75.

Takže MS-DOS je jednouživatelský jednoúlohový spouštěč programů, pokud nedokážeš opak.

A mezitím si nastuduj doporučenou literaturu, ať víš co to operační systém vlastně je:

https://aukro.cz/madnick-donovan-operacni-systemy-1983-6969168354

https://aukro.cz/principy-operacnich-systemu-per-brinch-hansen-6977137529

V Maloměku to nevědí dodnes

[deda.jabko]

Multics, stejne jako PDP-11

Beru, upsal jsem se, myslel jsem GE645. Je to dulezite?

Jak to dělal CP/M-86 v roce 1981 se můžeš podívat na straně 75.

Tos mi teda pomohl. Ja jsem se tesil, ze mi ukazes nejaky hack, kterym se na x86 podarilo zablokovat instrukce IN, OUT, nektere zmeny priznakoveho registru (treba IF), zmeny tabulky preruseni, ... a ty mi tady posles odkaz na uzivatelsky manual!

Bez toho, co jsem ti popsal, je ten tvuj CP/M-86 stejne neschopny jako MSDOS a nedokazal ochranit data uzivatelu stejne jako treba W9x (nekteri si treba vzpomenou na CIH).

Takže MS-DOS je jednouživatelský jednoúlohový spouštěč programů, pokud nedokážeš opak.

Proc bych mel dokazovat, ze MSDOS neni jednoduzivatelsky jednoulohovy operacni system, kdyz je to pravda? A jednou z prirozenych funkci operacniho systemu je pochopitelne spousteni procesu. Ty si v Linuxu nespoustis programy?

Mimochodem, uz jsi Ponkracovi vysvetlil, ze MSDOS je tedy spoustec programu a ne knihovna?

[Radovan]

Protože tvrdíš že je to operační systém.

Takže monitor v tom péemíčku je pro tebe také operační systém, protože spouští procesy. Navrch jim dokonce poskytuje knihovnu funkcí pro přístup k perifériím!

A neřekl jsi mi jak chránil data MS-DOS 5 na té 486ce. Jak je chránil CP/M-86 si můžeš vyzkoušet sám, manuál máš:

https://www.pcjs.org/software/pcx86/sys/cpm/1.00/

[deda.jabko]

Od cloveka, ktery tu machruje, jak sazel ovladani mysi ve strojaku, jsem cekal, ze bude sypat jeden hack za druhym, jak se to da udelat. Zatim jsou to stejne prazdne kecy, jako kdyz si vymyslel Churchilluv citat a pak kolem toho mlzil a mlzil.

[Radovan]

S tím machrovat nemusím, ono to není žádné umění. Tady máš stroják:

DATA 55,89,E5,8B,5E,06,8B,17,8B,5E,08,8B,0F,8B,5E,0C,8B,07
DATA 8B,5E,0A,8B,1F,1E,07,CD,33,53,8B,5E,06,89,17,8B,5E,08
DATA 89,0F,8B,5E,0C,89,07,58,8B,5E,0A,89,07,5D,CA,08,00,90

Zjištění pozice myši a stisknutých tlačítek:

DEF SEG = VARSEG(asm)
ax = 3
CALL Absolute(ax, mb, mx, my, VARPTR(asm))

Pro pokročilejšího uživatele MS-DOSu by tohle měla být běžná věc, protože právě k tomuhle tam ten QBasic dávali. Ani se to nemuselo poukovat jako na ZX Spectru

[deda.jabko]

Ja kdybych programoval v QBasicu, tak se tim moc nechlubim.

Ale stale cekam, az mi vysvetlis, jak ten uzasny CP/M-86 dokazal v realnem modu zabranit jednotlivym procesum v pristupu na libovolne misto k pameti (vcetna jadra), k disku, ... aby dokazal ochranit data uzivatelu. Nebo si mam precist pameti TGM, protoze v nich je to vysvetlene?

[Radovan]

Jakože jsem si před pár desítkami let na doma bastlil něco v QB? Třeba editor fontů pro tiskárnu, který jsem měl hotový za odpoledne? Tak tím se klidně chlubit budu, chtěl jsem mít ozdobné písmo v dopisu a také jsem ho měl

Stále čekám až mi vysvětlíš jak MS-DOS 5 na 486ce chránil uživatelská data. Dokaž že uměl aspoň něco, kromě ovládání disku.

Přečti si Benešovy knihy. A vzpomínky Jana Masaryka. Ale pochybuji že ty je pochopíš.

[deda.jabko]

Je videt, ze jsi expert v oboru, proto mi urcite dokazes popsat, jak v realnem modu CP/M-86 chranil data uzivatelu pred neopravnenym pristupem, jak jsi tu tvrdil.

[Radovan]

Ty nejenže nerozlišíš hardware od softwaru, ty nerozeznáš ani hodinky a holinky!

Cpeš mi reálný mód u jednouživatelského jednoprogramového systému, ale já chci slyšet jak ten DOS ochrání data UŽIVATELŮ, ne procesů! Tam totiž žádné další procesy nejsou a není co chránit.

Takže ten CP/M-86, jak ses mohl v mnou odkazovaném manuálu dočíst a vyzkoušet v emulátoru, má příkaz USER, který umožňuje až 16 uživatelům mít svá soukromá data neviditelná ostatním na jednom disku. Jde to i zaheslovat.

A teď mi řekni jak něco takového dělal ten crippleware MS-DOS, nebo W9x. Mimochodem, ty Widle nedokázaly při předstírání multitaskingu pořádně chránit ani ta data procesů mezi sebou, a občas ani před sebou samými, když bezdůvodně hodily modrou smrt.

[deda.jabko]

Cpeš mi reálný mód u jednouživatelského jednoprogramového systému, ale já chci slyšet jak ten DOS ochrání data UŽIVATELŮ, ne procesů!

GOTO #233

Takže ten CP/M-86, jak ses mohl v mnou odkazovaném manuálu dočíst a vyzkoušet v emulátoru, má příkaz USER, který umožňuje až 16 uživatelům mít svá soukromá data neviditelná ostatním na jednom disku. Jde to i zaheslovat.

Coz je skvela funkce do te doby nez si nektery uzivatel napise nastroj, ktery mu pomoci instrukci IN/OUT umozni pristupovat primo k jednotlivym sektorum disku a tedy k celemu souborovemu systemu. V tento moment se ta funkce stava zcela zbytecnou. Jinak je to kod na par radku.

Jesteze tam je to heslo, ktere nikdo nezjisti... ledaze by si treba nekdo povesil vlastni handler na IRQ1, ale... to by prece nikdo neudelal, ze ne? Nebo co kdyby nekdo upravil primo tu funkci pro vstup hesla... a to stejne nikdo nedokaze, tak proc se tim trapit?

[Radovan]

Udělej to. Použij PL/M. A ukaž mi jak data uživatelů chráni MS-DOS. Nebo W9x, kde místo zadání hesla stačilo zmáčknout Escape

[deda.jabko]

A ukaž mi jak data uživatelů chráni MS-DOS. Nebo W9x, kde místo zadání hesla stačilo zmáčknout Escape

Napisu to radeji v BASICu, abys tomu rozumel i ty.

10 NAUC SE CIST!
20 GOTO #233

RUN

[Radovan]

10 PRINT "NAUC SE CIST!"
20 GOTO 230
30 REM ANI TEN BASIC NEUMÍŠ SPRÁVNĚ

[Miloslav Ponkrác]

Deda.jablko: Uz jsem dostatecne stary na to, abych zazil dost diskuzi, kde jisty pan Ponkrac zacal sve dojmy (v rozporu s realitou) vydavat za fakta. A toto je jedna z nich.

Takže jsem měl pravdu, že jste hlupák, který jako jediný v této diskusi nedokáže diskutovat věcně. Prostě vůl, který má tak slabé argumenty v ruce, že bez útoku na lidi a osoby je v pytli.

Tvrdíte pitomosti, a snažíte se je zastřít útokem na osoby. Když nemáte nic jiného v ruce, že?

Jak jsem už napsal - sám jste odhalil, co jste zač.

[deda.jabko]

Kdybys sve tvrzeni podkladal nejakymi argumenty, mohli bychom si o tom urcite hezky povykladat. Proc sem teda nehodis nejaky clanek/knizku, kde nekdo relavantni taky tvrdi, ze MSDOS je knihovna a ne OS?

[Radovan]

Ono se tenkrát operační systém říkalo ledasčemu, defakto byl operační systém i 1KiB monitor na PMI-80.

Ve skutečnosti je MS-DOS pouhý zavaděč programů, poskytující nijak nechráněný přístup k veškerým datům na všech discích. Jednouživatelský, jednoprogramový, nic víc, ani síť neuměl.

Podobně jako s BASICem, to byl ve své době nejmodernější vysokoúrovňový programovací jazyk pro víceuživatelské systémy se sdílením strojového času, dneska se bere jako skriptovací jazyk na dětských hračkách.

[tacoberu]

V jednom nejmenované instituci, kde běžel Novell, jsem se přihlásil, spustil jsem si svůj TSR prográmek a odhlásil se. Následně jsem si mohl zalogovat každé přihlášení ostatních uživatelů a získat jejich hesla.

[Radovan]

Přidal jsi ho do té knihovny podprogramů.

[deda.jabko]

Ve skutečnosti je MS-DOS pouhý zavaděč programů, poskytující nijak nechráněný přístup k veškerým datům na všech discích. Jednouživatelský, jednoprogramový, nic víc, ani síť neuměl.

Tak treba prof. Tanenbaum v Modern Operating Systems, pise:

MS-DOS was a 16-bit real-mode, single-user, command-line-oriented operating system consisting of 8 KB of memory resident code. Over the next decade, both the PC and MS-DOS continued to evolve, adding more features and capabilities. By 1986, when IBM built the PC/AT based on the Intel 286, MS-DOS had grown to be 36 KB, but it continued to be a command-line-oriented, one-application-ata-time, operating system.

Takze na jedne strane Ponkrac tvrdi, ze MSDOS je knihovna, Radovan tvrdi, ze je to zavadec programu, a pak tu mame treba cloveka, ktery cely zivot zasvetil vyzkumu v oblasti operacnich systemu, podle jeho knizek se uci na prednich univerzitach a za svuj prinos svetu operacnich systemu dostal, peknou radku oceneni, ktery tvrdi, cituji jeste jednou: ,,MS-DOS was a 16-bit real-mode, single-user, command-line-oriented operating system.

Nazor na to, kdo ma z tech tri vetsi vhled do problematiky, nech si udela kazdy sam.

A rekne mi uz nekdo z tech, co nepovazuji MSDOS za OS, jestli W9x byly taky operacni system, nebo ne?

[koroptev]

Ponkrac jede v astrologii a Radovan ma pocit, ze od tlacitkovych telefonu bez OS se technika nevyvinula zadnym uzitecnym smerem.

Ze bysme to skrtli jako nekonstruktivni a pro realitu nepouzitelne extremy?

[Radovan]

Tak zrovna na něj má Linus svůj názor. MINIX se také pokusil používat

[deda.jabko]

A? V Intelu jsou s nim nadmiru spokojeni.

[Radovan]

Zrovna tím ho teda moc nepotěšili. Hlavně k čemu ho použili

[Miloslav Ponkrác]

Deda.jablko: Jo, vy uvažujete jen skrze odkazy / články / knížky; zatímco vlastní uši, oči, mozek jsou pro vás deprecated. To poměrně dost vysvětluje, proč se neshodneme.

Až vám dám článek, že země je plochá deska, kterou nesou na sobě čtyři želvy, tak to zřejmě budete brát jako tvrdé a nezpochybnitelné faktum.

Jak můžete zde číst, nesouhlasí s vámi více lidí. Protože DOS byla de facto jen knihovna podprogramů, se kterou si spuštěný program mohl dělat cokoli. I když se jmenuje "disc operating system".

Možná byste si ty útoky ad hominem mohl odpustit. Děláte tím ostudu jen sám sobě.

[deda.jabko]

Až vám dám článek, že země je plochá deska, kterou nesou na sobě čtyři želvy, tak to zřejmě budete brát jako tvrdé a nezpochybnitelné faktum.

Vzhledem k tomu, ze jsem stejne jako dalsi miliardy lidi na teto planete nekolik desitek let zil v omylu, ze CP/M, DOS, a nejspis i Win9x, MacOS (classic) jsou operacni system, nediv se, ze se mi nechce verit necemu, co nekdo tvrdi na internetu.

Jo, vy uvažujete jen skrze odkazy / články / knížky; zatímco vlastní uši, oči, mozek jsou pro vás deprecated.

Kdyz jsem polozil dotazy, abych si utvoril nazor na tento neortodoxni pohled, nedostal jsem odpoved. Kdyz jsem se zeptal, jestli existuje jeste nekdo relevantni (krome tebe a ruskeho trolla radovana), kdo zastava podobny nazor, opet jsem nedostal odpoved. Tolik k tomu, kdo tu ma vystredni nazory na operacni systemy a plochou zemi.

[Miloslav Ponkrác]

Dobře, já vás budu ignorovat. Jako každého trola. Jako každého kreténa (záměrně používám sprosté slovo, a už příště nebudu), který útočí na osoby namísto věcné argumentace. Jiný vůl než vy, co útočí ad hominem se tu nenašel.

[koroptev]

jakto

ja napr. tohle delam zcela bezne a udelal jsem to v teto debate nekolikrat

[tacoberu]

Architektura DOSu byla taková, že na začátku nabootoval command.com. Ten (plus nějaké smetí kolem, které se nahrálo do paměti jako obslužné rutiny, které mohla vaše aplikace použít pomocí INT 21h). Pokud jste spustili nějaký exáč, tak command.com ten exáč spustil, a následně se sám ukončil. Už neběžel. Pokud ten exáč něco v paměti přepsal, blbě spadnul, nebo tak něco, tak command.com taky nemusel vůbec naskočit.

Ano, DOS poskytoval různé rutiny, které byly k dispozici. Ale na ovladače čehokoliv kromě diskety a disku zapomeňte. To si každá aplikace tahala sama.

Také si myslím, že DOS nebyl plnohodnotný OS tak jak si to představujeme. Souhlasil bych s kategorizací, že to byl pouhý zaváděč programů.

[deda.jabko]

Architektura DOSu byla taková, že na začátku nabootoval command.com. Ten (plus nějaké smetí kolem, které se nahrálo do paměti jako obslužné rutiny, které mohla vaše aplikace použít pomocí INT 21h).

Tak nejdriv se natahl IO.SYS (ovladace) a MSDOS.SYS (jadro) a pak podle CONFIG.SYS se pripadne spustil (COMMAND.COM nebo neco jineho) a pripadne se pak provedl AUTOEXAC.BAT.

Ten (plus nějaké smetí kolem, které se nahrálo do paměti jako obslužné rutiny, které mohla vaše aplikace použít pomocí INT 21h).

To smeti okolo (IO+MSDOS.SYS) je nezbytne nutne, aby vubec sel ten COMMAND.COM najit na disku a spustit. Bez toho by nemohl spoustet vubec zadne exace.

Už neběžel. Pokud ten exáč něco v paměti přepsal, blbě spadnul, nebo tak něco, tak command.com taky nemusel vůbec naskočit.

To je u takoveho operacniho systemu vcelku prirozena vec, ze nema ochranu pameti, kdyz ji nema HW. A ze kdyz v jednoulohovem OS proces neskonci, nemuze byt spusten jiny proces.

Ale dekuji, ze jsi mi to vysvetlil.

Také si myslím, že DOS nebyl plnohodnotný OS tak jak si to představujeme.

Svet OS je docela pestry a zajimavy, a to co muze dany OS delat je dano hardwarem, na kterem bezi. Porad mi ale nikdo neodpovedel, jestli treba W9x byly operacni systemy nebo ne.

Souhlasil bych s kategorizací, že to byl pouhý zaváděč programů.

Muzes tedy, prosim, vysvetlit Ponkracovi, ze MSDOS neni knihovna?

[Radovan]

Tak nejdriv se natahl IO.SYS (ovladace) a MSDOS.SYS (jadro) a pak podle CONFIG.SYS se pripadne spustil (COMMAND.COM nebo neco jineho) a pripadne se pak provedl AUTOEXAC.BAT.

BIOS, BDOS, CCP.

Akorát Gary Kildall neměl drzost říkat tomu operační systém

A tu knihovnu máš pověšenou na int 21H.

[deda.jabko]

Akorát Gary Kildall neměl drzost říkat tomu operační systém

Tak samozrejme:

• CP/M advertisement in the 11 December 1978 issue of InfoWorld magazine
• CP/M Plus (CP/M 3) System Guide
• CP/M 2.0 Interface Guide (strana 3: Operating System Call Convention)
• ...

[Radovan]

BDOS = Basic Disk Operating System.

CP/M = Control Program for Microcomputers

Čili to co ty nazýváš operační systém je jenom jedna komponenta řídícího programu. Knihovna funkcí umožňujících přístup k souborům na discích.

[tacoberu]

Už neběžel. Pokud ten exáč něco v paměti přepsal, blbě spadnul, nebo tak něco, tak command.com taky nemusel vůbec naskočit.

To je u takoveho operacniho systemu vcelku prirozena vec, ze nema ochranu pameti, kdyz ji nema HW. A ze kdyz v jednoulohovem OS proces neskonci, nemuze byt spusten jiny proces.

Tak bez ochrany paměti toho moc nevymyslíš, to je pravda. Byla to spíše demonstrace toho, že o něčem jako abstrakci se u MSDOS nedalo mluvit. Uměl jen načíst z disku program a umřít. Víc ani ťuk. Na druhou stranu ale třeba DR-DOS uměl i přepínání spuštěných programů. Což už je zajímavá schopnost.

Také si myslím, že DOS nebyl plnohodnotný OS tak jak si to představujeme.

Porad mi ale nikdo neodpovedel, jestli treba W9x byly operacni systemy nebo ne.

Já bych řekl, že jo. Poskytovali abstrakci nad HW, umělo to ovladače, poskytovalo to API, poskytovalo to abstrakci nad službami (síť, tiskárna, procesy).

[Radovan]

Z archivu:

Windows 95 říkáte? Myslíte to 32bitové rozšíření 16bitové nadstavby 8bitového operačního systému určeného původně pro 4bitové počítače vydané 2bitovou společností, která nesnese ani jediný bit konkurence?

[deda.jabko]

Uměl jen načíst z disku program a umřít. Víc ani ťuk. Na druhou stranu ale třeba DR-DOS uměl i přepínání spuštěných programů. Což už je zajímavá schopnost.

Presun se myslenkove do roku '81. Mas pocitac, ktery ma desitky kB (v lepsim pripade stovky) RAM, disketovou mechaniku, pc-speaker, klavesnici a grafiku MDA/CGA. A je to nejlepsi, co si muzes dovolit a i tak je to hodne draha sranda na urovni nekolika vyplat.

Ceho jineho by tam mela byt abstrakce nez disku a konzoloveho vstupu/vystupu?

Druhy problem je, ze teoreticky muzes pridat dalsi abstrakce, podporu dalsich zarizeni. Ale to ti ubira drahocene misto v pameti (ktere chces pro programy a data) nebo na diskete (ktere potrebujes i pro dalsi programy) a pet-a-ctvrtky toho moc nepobraly.

Takze ten operacni system neni zadny zazrak, ale v podstate splnuje to, co se od OS te doby dalo ocekavat. To, ze v ruznych inkarnacich prezil jeste dalsich 20 let je v podstate zazrak.

Já bych řekl, že jo. Poskytovali abstrakci nad HW, umělo to ovladače, poskytovalo to API, poskytovalo to abstrakci nad službami (síť, tiskárna, procesy).

Ok, s tim souhlasim. Ale puvodni teze byla:

Program spuštěný v DOSu de facto funguje jako jádro operačního systému, a řídí celý počítač. To je naprosto odlišná situace proti Windows, unixu, MacOS a dalším, kde program má velmi ustřihnutá křídla a rozhodně ne plnou kontrolu nad počítačem.

Ve Win9x programy mohly pristupovat k cemukoliv ve stejnem rozsahu jako v pripade DOSu, nemelo by se tedy podle nich (Ponkrac a radovan) jednat o operacni system. Tento rozpor mi tu stale nikdo nevysvetlil.

[tacoberu]

Uměl jen načíst z disku program a umřít. Víc ani ťuk. Na druhou stranu ale třeba DR-DOS uměl i přepínání spuštěných programů. Což už je zajímavá schopnost.

Presun se myslenkove do roku '81. Mas pocitac, ktery ma desitky kB (v lepsim pripade stovky) RAM, disketovou mechaniku, pc-speaker, klavesnici a grafiku MDA/CGA. A je to nejlepsi, co si muzes dovolit a i tak je to hodne draha sranda na urovni nekolika vyplat.

Ceho jineho by tam mela byt abstrakce nez disku a konzoloveho vstupu/vystupu?

Amigu znáš?

Nemusíš souhlasit, ale definice, že MSDOS byl jen zavaděč programů a ne plnohodnotný OS mi přijde trefná a budu ji používat.

Ok, s tim souhlasim. Ale puvodni teze byla:

Program spuštěný v DOSu de facto funguje jako jádro operačního systému, a řídí celý počítač. To je naprosto odlišná situace proti Windows, unixu, MacOS a dalším, kde program má velmi ustřihnutá křídla a rozhodně ne plnou kontrolu nad počítačem.

Ve Win9x programy mohly pristupovat k cemukoliv ve stejnem rozsahu jako v pripade DOSu, nemelo by se tedy podle nich (Ponkrac a radovan) jednat o operacni system. Tento rozpor mi tu stale nikdo nevysvetlil.

Pokud se nepletu, tak Win95 běžel v chráněném módu. To je asi tak vše, co k tomu chci říct.

[deda.jabko]

Amigu znáš?

Ten pocitac z roku 1985?

Zkus mi odpovedet: Ceho jineho by tam mela byt abstrakce nez disku a konzoloveho vstupu/vystupu? (U pocitacu z roku '81)

Pokud se nepletu, tak Win95 běžel v chráněném módu. To je asi tak vše, co k tomu chci říct.

Ale kvuli kompatibilite s DOSem a maximalni rychlosti toho moc nechranil.

Inside Window95:

Notice that a Win32 application has a true 4-GB address space. Calls to system DLLs are direct calls with no ring transition and no context switch. The advantage of this approach is its speed-there's no overhead beyond the overhead of the function call itself. The disadvantage is that an application can obtain a pointer into the system address space and start poking around-possibly to no good effect. Under Windows NT, the system address space is truly protected and no application can obtain a pointer into it. In this particular instance, the Windows 95 designers went for performance over security.

[tacoberu]

Amigu znáš?

Ten pocitac z roku 1985?

Zkus mi odpovedet: Ceho jineho by tam mela byt abstrakce nez disku a konzoloveho vstupu/vystupu? (U pocitacu z roku '81)

Mno, pamatuji si na mé začátky s Atari800XE, kde jsem všem vykládal, že tam píšu operační systém. Problém je v tom, že já to říkal jako vtip. V Amize byl software, který uměl víc. Atari a další 8/16bity samozřejmě měli vestavěný software, který uměl různé věci. Některé měli dokonce okýnka. Ale obvykle jsme tomu operační systém neříkali. Já si nemyslím, že by tam měla být nějaká abstrakce. To jsou tvá slova. Prostě MSDOS toho moc neuměl. Protože to byl jen zavaděč programů ne nepodobný generacím osmibitů před ním. Dokonce toho ze všech těch DOSů uměl nejmíň.

Amigu znáš?

Ten pocitac z roku 1985?

Zkus mi odpovedet: Ceho jineho by tam mela byt abstrakce nez disku a konzoloveho vstupu/vystupu? (U pocitacu z roku '81)

Pokud se nepletu, tak Win95 běžel v chráněném módu. To je asi tak vše, co k tomu chci říct.

Ale kvuli kompatibilite s DOSem a maximalni rychlosti toho moc nechranil.

Může být. A?

[deda.jabko]

Prostě MSDOS toho moc neuměl. Protože to byl jen zavaděč programů ne nepodobný generacím osmibitů před ním. Dokonce toho ze všech těch DOSů uměl nejmíň.

Pro me za me, si tomu rikej treba kolobezka, jestli ti to v necem pomuze. Ale ja se v tomto smeru budu drzet zavedene terminologie. Je zajimave, ze ani hvezdopravec, ani radovan, ani ty jste nedolozili, ze by se to takto nekde bezne oznacovalo.

Pokud se nepletu, tak Win95 běžel v chráněném módu. To je asi tak vše, co k tomu chci říct.

Ale kvuli kompatibilite s DOSem a maximalni rychlosti toho moc nechranil.

Může být. A?

To bylo pro tvou informaci, protoze chraneny mod tam byl sice pouzity, ale pouzival se v hodne podivne podobe.

[tacoberu]

Prostě MSDOS toho moc neuměl. Protože to byl jen zavaděč programů ne nepodobný generacím osmibitů před ním. Dokonce toho ze všech těch DOSů uměl nejmíň.

... Je zajimave, ze ani hvezdopravec, ani radovan, ani ty jste nedolozili, ze by se to takto nekde bezne oznacovalo.

Na něco takového snad ani nikdo neaspiroval. Mě se to označení zalíbilo protože to vystihuje skutečnost..

[Radovan]

Vynechal jsi konektor na připojení magnetofonu a kompozitní výstup na televizi, přes který CGA zvládalo v grafice mnohonásobně víc než jen čtyři barvy. V roce 1981.

Takže na tomhle stroji sis mohl spustit hned tři různé systémy dodávané přímo IBM, a navrch maloměkký XENIX, což byl nejrozšířenější UNIX té doby. A ten toho poskytoval podstatně víc než jen přístup na disk a konzoli.

Ačkoliv na 8088 mohl XENIX těžko ochránit procesy mezi sebou, byl to skutečný operační systém se všemi funkcemi, ne vylevněná imitace která neumí skoro nic. I XENIX si můžeš v tom emulátoru vyzkoušet.

To že MS-DOS přežil dalších dvacet let není zázrak ale důsledek toho, že většina lidí si vždycky koupí radši levný šmejd, než drahou kvalitu. Proto má Windoze většinu na trhu

[xkucf03]

To že MS-DOS přežil dalších dvacet let není zázrak ale důsledek toho, že většina lidí si vždycky koupí radši levný šmejd, než drahou kvalitu. Proto má Windoze většinu na trhu

Ten argument levným šmejdem je platný jen v první fázi. Pak jde spíš o to, že už máš vytvořené/nakoupené aplikace pro daný systém a nad tím nastavené různé procesy a nechce se ti to měnit. Pro DOS vznikla spousta užitečných programů (a her), které se dokázaly vypořádat s mizerností toho "OS" (zavaděče) a byly vlastně samy sobě operačním (včetně ovladačů a různých dalších služeb/funkcionalit). A pak se to lidem samozřejmě nechce měnit. Windows toho poskytovaly trochu víc, ale v principu tam byla situace stejná.

[Radovan]

Ta první fáze je nejdůležitější, pak už jsou naučení používat šmejdy a trvají na nich. Já také nosím kecky od rákosníků

Představte si, že společnost Cray se rozhodne vyrábět osobní počítače. Mají procesor s frekvencí 150 MHz, 200 MB operační paměti, 4 GB kapacity disku, rozlišení obrazovky 1024 x 1024, dá se kompletně ovládat hlasem, vejde se vám do kapsy a stojí 300 dolarů. Co bude první otázka, na kterou se počítačová veřejnost zeptá?

"Je to kompatibilní s PC?"

[xkucf03]

V dobách DOSu jsem tedy ještě neprogramoval, ale pamatuji si, že hry měly ve svém nastavení výběr konkrétních zvukovek. Některé v sobě měly zakompilovanou podporu 3Dfx nebo jiných akcelerovaných grafických karet. Podobně podpora joysticků nebo myší… Nebo takový Impulse Tracker má vlastní ovladače pro různé zvukovky i Covox (LPT DAC).

Tady je přehled API: DOS (a pro zajímavost BIOS). Ten systém sice něco uměl, ale bylo toho hodně málo, a bylo nejen možné, ale i normální a nutné, aby programy pracovaly přímo s hardwarem. To odstínění/abstrakce HW existovalo spíš jen místy a hlavně nebylo vynucované – běžně se obcházelo.

Operačním systémem bych to asi nazval (vzhledem k tehdejší době), ale… pravdu mají i ti, kteří říkají, že je to spíš jen zavaděč aplikací.

[deda.jabko]

Tady je přehled API: DOS (a pro zajímavost BIOS

A tady je poradny prehled. Ono to bylo sice hloupe, protoze Microsoft se drzel kompatibility s 8086, ale zase tak uplne primitivni to nebylo. Treba si nepamatuju, ze bych musel resit cokoliv s mysi. Ovladani slo hezky pres preruseni. Jeste si zive vybavuju, jak jsem si ty rutiny psal v pascalovskem inline assembleru.

To odstínění/abstrakce HW existovalo spíš jen místy a hlavně nebylo vynucované – běžně se obcházelo.

To z toho ale nedala knihovnu, jak tu tvrdi Ponkrac. (I kdyz exo-kernely mi prijdou jako koncepcne hodne zajimave). Stejne je zajimave, ze nejak mlci o tom, jestli W9x byly OS nebo taky knihovna, podobne MacOS Classic. To by to totiz znamenalo, ze tu lidi desitky let pouzivali misto OS knihovnu, a nikdo jiny si toho nevsimnul.

[Radovan]

MS-DOS uměl myš?

Prográmky ovládané myší jsem si dělal i v QBasicu, žádný inline assembler jsem k tomu ani nepotřeboval, stačilo pár desítek bajtů strojáku ve stringu.

Jako ovladač se mi nejvíc osvědčil gmouse, ty maloměkké stály za hovno, buď dělaly problémy nebo něco neuměly. Jako všechno od M$.

[Radovan]

To jako kazdy program si nese sebou vsechny ovladace?

Ano, pokud chce víc než nejzákladnější funkce, jako je výpis znaku na obrazovku.

To jako kazdy program si sebou nese implementaci souboroveho systemu?

Ne, proto je to Disk Operating System.

jednak poskytovat abstrakci HW

Tak tu právě neposkytuje.

[deda.jabko]

Ne, proto je to Disk Operating System.

A proc je to tedy Disk Operating System a nikoliv disk operating library?

jednak poskytovat abstrakci HW

Takze kazdy programator si musel napsat ovladac k FD a HDD, aby mohl ukladat/cist soubory?

[Radovan]

Protože marketing.

programator si musel napsat ovladac k FD a HDD

Které z písmen D I S K jsi nepochopil?

[okbobcz]

MS Access byla výrazně technologicky lepší databáze než PCFAND. O tom žádná. Ale, že by Access byla spolehlivá databáze, to fakt ne. Minimálně ne v první polovině 90 let. Shodou okolností jsem s ní dělal. Pády a poškození dat byly na denním pořádku. Access padal jak šraňky. Zvlášť jakmile se to začalo používat multiuživatelsky. S FoxPro byly výrazně lepší zkušenosti.

[Miloslav Ponkrác]

FoxPro byla už několikátá generace prajednoduchých chroustačů primitivních databázových souborů formátu DBF. Je to odvozenina od starého dbase ze 70. let. Tedy už ustálených.

Microsoft Access byla plnohodnotná SQL databáze - a její vývoj byl tedy o mnoho tříd složitější. Počáteční verze všeho od Microsoftu nejsou moc ok, ale pak to vyladí.

Když používám dnes databázový soubor Accessu typu .MDB jako lokální či sdílené úložiště k aplikacím, tak jsem nezažil / neslyšel jediný případ ztracených dat - a to jich po celém světě běhá velké množství.

Původně jsem chtěl do aplikací dával jako lokální databáze sqlite. Ale při pokusu bylo sqlite tak neuvěřitelně nespolehlivé, že jsem to stopl. Dokonce jsem dostal vynadáno, že je všeobecně známo, které "stable version" od sqlite jsou funkční, a které ne. A kdybych chtěl, že mi to řeknou. No, já si představuji pod označením "stabilní verze" asi něco jiného. Přehodil jsem to proto u windows programů na Access, a no problem. Některé stabilní verze sqlite dokonce ani neuložila data, která se do nich zapsala minutu předtím. Snad už dnes sqlite má jinou představu o "stable verzi", ale v době, kdy jsem se o to zajímal to bylo takto.

Prostě si představte, že v určité chvíli musíte o level výše - a často to znamená mnohem lepší analýzu a složitější požadavky. Jako třeba přechod od .dbf (nebo fandovských souborů, kde databázové tabulky neměly dokonce ani hlavičky, a když program neznal strukturu tabulky, tak smolenka) do SQL, transakcí a nějaké atomické integrity.

Když budete chtít řídit třeba letadlo, tak prostě linux také ani náhodou. Potřebujete mikrojádro a jeho větší odolnost - ale návrh mikrojádra o dva řády složitější než monolit. Návrh mikrojádra jde udělat dobře (a takových dobrých mikrojader běhá po světě dost), a nebo také totálně podělat hůře než monolit. Je to prostě vyšší meta s lepšími vlastnostmi.

Každý projekt - pc fand nevyjímaje - má limit daný svou architekturou a návrhem. Pokud autoři nechtějí ten limit překonat, což je náročné, pak to prostě po darwinovsku zajde.

[Radovan]

Nojo, když ono to "stable" neznamená že je to stabilní, ale že se na to už nebude sahat.

[okbobcz]

O kterém roku se bavíme? - abych byl v obraze - Já jsem Access používal ještě někdy ve verzi 2.0 (1994). Podle wiki ta historie MS Accessu byla dost krkolomná https://en.wikipedia.org/wiki/Microsoft_Access a jednou z jejich plánovaných rolí bylo použití jako interface k MSSQL (matně si vzpomínám, že JET se plánoval pro použití lokální cache nebo v případě offline) a tehdy to byl šrot - klasická souborová databáze. Rozhodně to nebyla plnohodnotná SQL databáze. První release SQLite je květen 2000. Tou dobou už to byla úplně jiná databáze.

[Miloslav Ponkrác]

Microsoft Access byl vždy souborová databáze + kód, která měla uloženo vše v jednom jediném souboru. Proto jsem ji uvedl jako výrazný pokrok pro zhruba stejné použití jako pc fand.

Mimochodem, kdysi jsem mohutně přepisoval pc fandovské aplikace právě do Microsoft Accessu, a bylo to zákazníky vnímáno jako pokrok vpřed. A jednou nebo dvakrát do Visual Basicu, které je pro zákazníky fakticky na pohled stejné, a možnosti jsou obdobné.

Proto jsem uváděl Access jako konkurenta PC fandu, ale na vyšším levelu než PC fand, a s mnohem širším použitím než pc fand.

Microsoft Access nevyžaduje použití vlastní databáze, umí se připojit i kamkoli jinam - na lokální i vzdálené databáze různých výrobců. Vyrobit rychle aplikaci nad jinou databází třeba Oracle, SQL server, mysql a cokoli - na to je Access vynikající.

Později začal Microsoft řekněme vyvíjet tlak na to, aby lidé z Accessu přešli na SQL server. A začal si o to říkat stagnací vývoje Accessu a jeho upozaďováním.

Čistě teoreticky si totéž můžete udělat z libovolného programovacího jazyka, třeba z C++ nebo co chcete. Databázi .mdb můžete vytvořit a používat i skrze API ve Windows. Není nutné mít Microsoft Access. Prostě chvála ODBC a dalším rozhraním, protože toto Microsoft vymyslel velice dobře.

[xkucf03]

Akorát on to Microsoft nevymyslel. Vychází to z Call Level Interface (CLI), za kterým stojí SQL Access Group, X/Open, The Open Group. Dobrou dokumentaci k tomu má např. IBM.

Co mi přijde trochu škoda, je, že se obor nedokázal domluvit na jednotném síťovém protokolu pro přístup k relačním databázím. Něco jako např. LDAP, kterým se taky připojujeme k databázi, akorát nerelační. Tam šla ta standardizace ještě dál až na úroveň datového modelu (a atributy tam mají globálně unikátní identifikátory a definovaný význam; zatímco dva sloupce se stejným názvem v různých databázích nebo dokonce tabulkách můžou znamenat něco úplně jiného).

[Miloslav Ponkrác]

Každopádně tak jako tak, na Windows jsem mohl mnoho let jednotně přistupovat z programů k databázím, a jinde jsem tu možnost neměl. Mohl jsem používat své oblíbené programovací jazyky, ke kterým jsem si jen napsal modul "odbc" - a byl jsem happy. Dokázal jsem vykrýt jakoukoli databázi, kterou používal zákazník, a to jen z minimální námahou.

Někdy mám dojem, že linux / unix je z hlediska API sto let za opicemi. Na low level věci ano, nebo jako dedikovaný server pro nějaké služby. Ale jinak je to strašný nalepovák.

Problém jednotných standardů je několik hráčů, co musejí mít věci po svém. Dlouhou dobu takovou žábu na prameni hrála Java.

[Radovan]

A spouštěli potom to na té samé 286ce jako PC FAND?

Ale jo, pro basu plzní do sámošky se dá dojet i s dvoutunovým truckem s dunícím sedmilitrovým osmiválcem, dvěma výfuky nad kabinou a klimatizací, ale bývaly časy kdy stačil dvoukolák

Pokrok to určitě je, ale pokrok není vždy cesta kupředu.

[Miloslav Ponkrác]

Access se ve starší verzi dal spusti na 286.

Já myslím, že pc fand je šmejd, protože se nedá pustit na 8080 se CP/M operačním systémem. Kdyby bylo všechno rozežrané jako pc fand, kam bychom přišli?

Nebo takový abakus coby dřevěné počítadlo s kuličkami je určitě méně náročné než dnešní vědecká kalkulačka. A šikovný uživatel abakusu si na něm spočítal i arkus sínus nebo přirozený logaritmus za pomoci aproximačních polynomů. Nikdo vás nenutí používat tu vědeckou kalkulačku. Ale asi budete v menšině.

Zpět k pc fandu.

Já myslím, že i relativně nenáročná mysql, sqlite, nebo sql embedded databáze byl pokrok vpřed.

Nebo já už bych dnes nechtěl lepit texty, ani v databázi, pomocí latin 1 nebo kamenických či KOI-8-ČS, ale rád si užívám výhod unicode, které považuje za obrovský pokrok.

Samozřejmě je pokrok a "pokrok". Já jen doufám, že vy dodnes jedete v textovém rozhraní na MD-DOS 3.30. Cokoli jiného je zbytečné.

[Radovan]

Na 8080 sis to napsal v BASICu.

S kuličkovým počítadlem bežně nepočítám, ale logaritmické pravítko na machrování občas používám. A když dnešní omladině ukázuji že ten výpočet je hotový dřív než to do té vědecké kalkulačky namačkají, tak dost čumí. Samozřejmě dnes v batohu nosím vědeckou kalkulačku (od rákosníků za pade) a logáro si doma šetřím pro speciální případy

Na spoustu věcí to textové rozhraní bohatě stačí, akorád dnešní slepice datlující ve Wordu pozvánky musí mít 4K monitor :)

[Radovan]

Jo hele, málem bych zapomněl. FAND samozřejmě na CP/M existoval, na slušovických TNS.

F - floating
A - alfa
N - numeric
D - date

To bylo všechno co původně uměl. Ten šestnáctibitový (IBM-)PC-FAND byl dost velký pokrok

[okbobcz]

Co tak jsem viděl při migracích z Oracle do Postgresu, tak pro 99% aplikací by to stačilo, a ještě by se některý typ nepoužil. Nevím proč, ale dost programátorů se dřív bálo typu date - takže buďto nějak mapovali datum do čísla - viděl jsem hodně obskurní - 15.3.2010 - namapované na číslo 1532010 nebo datum vrazili do varcharu. V LAMPu datumy skoro vždy se ukládaly jako unix timestamp - nevím jak dneska, ale když jsem se kolem toho motal někdy kolem 2003, tak člověk nenarazil na nic jiného.

[Miloslav Ponkrác]

Protože C naučilo mnoho programátorů základní ideologii, že vše je celé číslo. A když ne, tak je to podezřelé, a slušný člověk se tomu vyhne. To se promítlo také do unixu i do php.

Bohužel timestamp neřeší přestupnou sekundu, takže ten koncept není úplně idiotenfest.

[okbobcz]

Cčko za tím rozhodně nebylo. Tady v Céčku skoro nikdo neprogramoval. Ještě začátkem 90 let tu bylo Cčko braný jako dost exotický jazyk. Spolubydlící na koleji o 3 roky starší machroval tím, že diplomku napsal v Céčku. Nejčastější jazyk ke kterému se ajťáci v ČR dostali byl nějaký BASIC z 8bitů, pak určitě Pascal, možná Assembler, možná i ten COBOL. Céčko moc lidí neumělo a nepoužívalo. Mně brali jako experta (20 letý rozumbrada), protože jsem dokázal v Cčku napsat OLE knihovnu. Z mé sociální bubliny (spolužáci na VŠ to byl Pascal, Basic v MS Accessu (později VBA) a FoxPro. Nevybavuji si, že by někdo použil (v první polovině 90 let něco jiného). Druhá polovina 90 let nebyla o tolik jiná. PHP začalo víc používat tak v 97, kdy ještě soutěžilo se strašlivými ASPčkami (ještě s VBScriptem), Java, Javascript začaly až po roce 2002.

[Miloslav Ponkrác]

V Československu byl ostrý přechod pár let po sametové revoluci 1989. Poměrně ostře jak mávnutím proutku končily 8bity, a začala éra PC, případě jiných mašin rozhodně ne 8bitových.

Programovací jazyk C nefunguje efektivně na strojích typu 8bit. Třeba také třiregistrové Atari je vysloveně oříšek pro C kompilátor, a efektivně se na takových strojích C kompilátor udělat nedá. Céčkový program potřebuje dost registrů a velký zásobník, aby to nějak efektivně chodilo.

Já jsem studoval kybernetiku 1984-1989. Céčko byla jasná volba od mého prváku, a dělala se v něm většina programů na celé univerzitě. V polovině studia už to spíše všechno jelo na C++, včetně mě. Asi mám jiné zkušenosti.

Vzpomínám si ještě, že ve 4. ročníku jsem dostal zápočet za to, že jsem napsal v C program pro VAX počítač, který řešil některou komunikaci s hw toho počítače. Učitel to nedokázal napsat, já to napsal. Dostal jsem zápočet i zkoušku rovnou. Předmět se jmenoval "programování ve VAX unixu" nebo tak nějak.

V 1. ročníku se učil Pascal a Fortran, ale moc se nepoužívaly. Fortran se používal na sálových mašinách, kde měl úlohu systémového jazyka - kernel i user části byly ve Fortranu. Pascal se bral jako učení se čistoty programování, a to byl dobrý jazyk na tento účel. (Někteří potom programovali v Turbo / Borland Pascalu, ale byla jich menšina.)

Kromě toho se používaly jazyky pro simulaci a reálný čas. Často se používala Simula, což byl vynikající jazyk s Pascalovskou syntaxí.

Jinak jsem také programoval multithreadové programy ve Smalltalku. Ten Smalltalku to zvládl s grácií. Byla to jediná disketa 3,5" (1,44 MB). A na ní byl celý operační systém včetně Smalltalku. Bylo to samonosné, a zábavné. A neuvěřitelně mocné. (Dá se říci, že to byl pokus Palo Alto o výrazně lepší pc fand, jen starší a lepší.)

V 90. letech už Céčko bylo všude populární. Alespoň co si pamatuji já.

[okbobcz]

Jsme z jiných kmenů - já jsem dělal ČVUT FSV SI 1991-1995 a znal jsem se s lidmi ze strojárny a pár lidí z FELu. V mé sociální bublině nikdo Cčko nepoužíval - zrovna tak se nikdo nedostal k VAXu. Všechno už byly PC - od XT, AT, 386, ... O ročník starší se ještě učili Fortran, my jsme se už učili Pascal. C se za mne ani neučilo. Ale měli jsme XBase nebo TeX. Nicméně je jasné, že výuka IT na stavárně a na kybernetice bude úplně jiná.

[Miloslav Ponkrác]

Já jsem dělal ZČU. Měli jsme výborné učitele. Nestudoval jsem IT. Základem byla matematika, fyzika, teorie systémů. Céčko jelo od první chvíle.

Céčko se u nás neučilo, jen ten Fortran, Pascal, Simula, Matlab. Ale v zásadě se to C naučil každý a programovalo se v něm zdaleka nejvíce.

Ale spíše ta doba byla pěkná tím, že byla skutečně poznávací. O každém řešení se diskutovalo o jeho výhodách i nevýhodách. Dnes už je zparchantělá doba, kdy se o nějaké technologii buď řeší jen výhody nebo jen nevýhody - což je spíše ideologický a emocionální přístup, ale ne pravdivý.

V prvním ročníku jsem ještě PC neměli. Měli jsme sálový počítač EC-1027.

Až ve druhém ročníku se začalo PC objevovat. Nejdříve jako PP-06, což byla československá výroba Tesla, kompatibilní s PC XT.

V těch dobách u nás i u vás všichni věřili, že počítače změní svět k lepšímu, a že se bude věčně programovat. Dnes už je IT spíše stereotyp a práce na pásu, protože ten obor se usadil a ztratil vývoj a tah.

Databáze jsme se učili s SQL. Texty jsme psali v Text602, o pár let později by to asi už tak nebylo.

[Miloslav Ponkrác]

Mimochodem, jedním ze zápočtových úkolů bylo: Napište vlastní multitaskový operační systém. Tehdy se to dávalo běžně jako úkoly studentům. Možná takto nějak v zahraničí začal u Torvaldse linux.

[Radovan]

Legenda praví, že po zkušenostech se Sinclairem QL měl Linus u MS-DOSu záchvaty zvracení, takže za jediný použitelný systém považoval UNIX. Jenže neměl plný kufr dolarů který za něj tehdy chtěli, tak si prostě vzal manuál a naprogramoval si ho sám.

[Radovan]

Tak to je prasárna, kdyby aspoň 20100315, zvlášť že ISO formát byl v ČSSR uzákoněný a povinný od roku 1980!

To byl důvod, proč si lidé stěžovali že MS-DOS to má blbě, když datum psal jinak než byli zvyklí, jenže on to měl dobře

[xkucf03]

kdyby aspoň 20100315

Tohle jsem taky někde potkal. Sám bych to nepoužil, ale má to aspoň výhodu v tom, že hodnoty lze řadit, neztrácí se počáteční nula a oproti timestampu je to čitelné i pro člověka.

Datum/čas nebo jiná data mají být prostě uložená efektivně a správně, ideálně nějakým nativním způsobem podporovaným v DB, a prezentace pro člověka se pak řeší nějakou převodní funkcí (která může dělat i lokalizaci atd.).

[Miloslav Ponkrác]

Což je tvar, který přijímají mnohé databáze v SQL jako datumový literál.

[Radovan]

"Efektivně" to měl ten MS-DOS u času souborů:

7 bitů = rok 0-127 (+1980)
4 bity = měsíc 1-12
5 bitů = den 1-31
5 bitů = hodiny 0-23
6 bitů = minuty 0-59
5 bitů = sekundy 0-29 (*2)

Na liché sekundy nezbyl bit

A existoval nějaký virus, který si nakažené programy označoval nastavením sekund na 31.

[hefo]

MS Access, to bola sranda vec. V tom som v cca. 2005-om na VŠ, už ani neviem, čo to bol presne za predmet, spravil IP paketový analyzátor (niečo ako Wireshark, teda vtedy Ethereal, dostali sme v zadaní nejaký PCAP súbor so záznamom IP komunikácie, myslím že to bolo obmedzené len na IP, aby to nebolo príliš komplexné, a ten bolo treba rozparsovať a nejako zobraziť. Najzložitejšie pre mňa bolo urobiť ten parser vo Visual Basicu, tým sa pakety naťahali do databázy, a následne už urobiť GUI na zobrazovanie a filtrovanie bola v Accesse brnkačka).

Cvičiaceho, zvyknutého na stokrát obšľahnuté programy v C-čku, skoro prekotilo, keď to videl, ale fungovalo to, a bolo jasné, že som to neopísal, nikto predtým a hádam ani nikdy potom to už v Accesse spravené nemal.

[Valgrind]

RIP

Uznani si jiste zaslouzi, i kdyz pascal mi k srdci opravdu neprirostl. Vzdy jsem mel radeji C ci Java. I to php mi prijde lepsi.

[johnyK]

z tech ruznych svetovych ohlasu 2 zajimavosti:

1. call me by name

nekdy v letech 80-90 se diskutovalo o moznosti predavani parametru pomoci jmena (Cobol to napr. umi). Tuto diskuzi komentoval Wirth svym humorem nasledovne:

Zatímco Evropané mé jméno většinou vyslovují správně ("Ni-klows Wirt"), Američané ho vždy zkomolí na "Nick-les Worth". To znamená, že Evropané mi říkají jménem, ale Američané mi říkají hodnotou.

2. kde zacina array

V jednom z komentaru stalo, ze Wirth zemrel v 90, protoze kdyz se narodil , tak mu byl 1 rok. Je tim patrne myslena moznost definovat arrays v Pascalu nasledovne

vector = array [ 1..25] of real;

nebo

vector = array [ 0..24] of real;

Osobne nevidim zadne velke vyhody, ale mozna to nejaky Pascalista vysvetli.

Take pozor: Real Programmers Don't Use Pascal

[okbobcz]

index nemusí začínat pouze 0 nebo 1, ale jakýmkoliv číslem. Jde o to, že pak mohu jako index používat nějakou "reálnou" hodnotu, aniž bych ji musel upravovat offsetem. Myslím si, že mohu vytvořit pole od -100 do 100, například pro četnosti teplot. Tohle je dědictví Algolu v Pascalu. Podobně to má i Ada. Řekl bych, že je to motivováno snahou o názornost čitelnost kódu, a případnou redukci nějakých transformací. Algol, Pascal byly jazyky určené pro vědecké výpočty. Cčko tohle neřešilo, jelikož to byl jen čitelnější macro assambler - pole je jen kus paměti, a index je offset - tudíž první prvek musí být indexovaný nulou. Ono i v reálném životě, když si označujete prvky v řadě, tak začínáte "prvním" prvkem, nikoliv "nultým". Začínat jedničkou je přirozenější (nicméně z pohledu CPU náročnější)

[Miloslav Ponkrác]

V Pascalu nemusí být indexem pole pouze číslo.

Například toto pole umožňuje uložit četnost znaků v nějakém textu:

array [char] of integer;

Počet kladných a záporných odpovědí takto:

array [boolean] of integer;

Po zavedení výčtového typu WeekDay definovaném jako (Monday, Tuesday, ..., Sunday) si můžete ukládat četnost vašeho sexu s partnerkou v jednotlivé dny do pole:

array [WeekDay] of integer;

1) Pascal prostě není C. Má plnohodnotná pole.

2) Pascal prostě není C. Indexem pole není omezen na celočíselné typy.

[koroptev]

jsi si jisty, ze to plati i pro turbo pascal? treba to s tim array[char] of integer?

je to uz strasna doba a nechce se mi to hledat

[kdosi]

Samozřejmě. Tohle měl už od samého začátku :)

[koroptev]

je to holt davno no

[Miloslav Ponkrác]

Ano, toto je standarní Pascal. Od první verze Niclause Wirtha ještě z doby dinosaurů.

C je prostě slepenec typu "všechno emuluj skrze celá čísla a pointery". Pascal má mnohem lepší typový systém, kdy neexistují pouze celá čísla.

Znalost pouze C/C++ člověka trochu pokřiví, protože se naučí všechno chápat jen jako inty a pointery - což je dost nesvobodné.

[Radovan]

Na vyšším levelu je vyšší abstrakce, tu má Pascal. Čili ideální jazyk pro studenty, kterým ohlídá začátečnické chyby a hned je profackuje když nějakou udělají.

C je makroassembler který jede těsně nad hardwarem, kde jsou všechno jenom inty a pointery. Pro větší pohodlí tam máš struktury z Algolu. A samozřejmě žádnou ochranu, kdo z nás nehledal pár hodin proč to segfaultuje?

V Pascalu máš airbagy, v Céčku ocelovou trubku před obličejem.

[johnyK]

to jsou vesela prirovnani, ale porad mi tady chybi ten zasadni pohled, povidani o tom, jak se s nejakou problematikou popasovat.

Kernighan a Ritchie zastavali filozofii, ze C je prostredek, ktery se bude pouzivat pro programovani nastroju a pomucek, kterymi se pak boudou resit konkretni 'problemy' ci'aplikace'. Nikdo z tech opravdovych programatoru, kteri byli u toho zrodu C si nikdy nepredstavoval, ze se ten jazyk vezme a budou se v tom psat aplikace. Tuto skutecnost technicka verejnost nejak prehledla a proto v polovine 80. let rada lidi prekvapene zjistovala, ze se v C nejake 'aplikace' psat poradne nedaji.

Wirth vyse uvedenou filosofii nesdilel a byl zastancem tvorby programovacich jazyku, ktere podpori vsemozne programatora pri psani aplikaci.

To jsou uplne rozdilna paradigmata a ja skutecne nechapu , proc se to porad srovnava.

[Miloslav Ponkrác]

C byl, pěkně prosím, jazyk, který byl vyvinut pro přenos kernelu unixu na jiný procesor. Tedy přenositelný assembler.

Programovací jazyk C je prostě okleštěný, protože jeho autor Ritchie měl panickou hrůzu z programovacího jazyka PL/I. A proto C záměrně držel jako málo rozvinutý.

Kdykoli někdo měl nějakou připomínku, že by se C dalo vylepšít, Ritchie ho poslal do pr...kýnka s tím, že "víš, kde najdeš PL/I". Například takto odmítl lepší práci se stringy v C.

Programovací jazyk C je v zásadě jednak další iterací programovacího jazyka B, a jednak psychologickým výsledkem úzkosti, strachu, paniky a obsese Ritchieho z běžných, pro něho příliš složitých, jazyků. Což je lepší vysvětlení tvaru a filozofie C než cokoli jiného.

Ve své podstatě okleštěnost C nesdílí dnes skoro nikdo. Proto vzniklo C++ a Objective C. Proto vznikla Java nebo Rust nebo Golang. Proto ministerstvo obrany USA vyvinulo Adu. A tak dále. Dnes by nikdo neprošel a neuchytil se s něčím tak syrovým a násilným jako je C. Přičemž většina těch zmíněných jazyků překládá do strojového kódu stejně efektivně jako C.

[Radovan]

Ty nástroje a pomůcky nejsou aplikace? Co je teda aplikace?

https://en.wikipedia.org/wiki/UnxUtils

Díky Céčku je můžeš přenést na libovolný stroj s libovolným operačním systémem a používat jak jsi zvyklý posledních padesát let.

V Pascalu jsi dostal kompletní VW Golf, v Céčku bednu šroubů a sadu nářadí. Jen několik lidí na planetě z toho dokázalo postavit formuli 1.

Ten zbytek by nějakou aplikaci nedokázal napsat pořádně v ničem, ale to jsme zase u Wirthova zákona

[Miloslav Ponkrác]

A díky programům Pascal2C a C2Pascal bylo možné přenést unix utils i do Pascalu a pokračovat v něm. A tyto dva programy jsem měl v DOSu na své základní disketě.

[koroptev]

"V Pascalu jsi dostal kompletní VW Golf, v Céčku bednu šroubů a sadu nářadí. Jen několik lidí na planetě z toho dokázalo postavit formuli 1. Ten zbytek by nějakou aplikaci nedokázal napsat pořádně v ničem, "

idiot

[Radovan]

Takže tu teď budeš psát pod dvěma přezdívkami?

[vgy]

v praxi uvažujeme len o 3-rozmernom priestore a ak zarátame čas, tak 4 ale teória toto neobmedzuje. Vo fyzike však častice sú rôzne, takže n-časticový priestor vlastne hovorí len o predstave z pohľadu častíc array.

[Miloslav Ponkrác]

Zde je jedno nepochopení: Pascal má pole, C pole nemá

C má jen ukazatel na začátek pole. Práce s polem je pak více méně předstírána skrze pointerovou aritmetiku. C je vlastně spíše jen skořápka, kde se všechno lepí pomocí intů a pointerů, protože toho mnoho neumí.

Pascal má plnohodnotná pole, stejně jako řada programovacích jazyků. Je docela dobré chvíli pracovat v programovacím jazyce, který má plnohodnotná pole, dost blbě se to pak odvyká.

Je docela dobré programovat v jazyce s plnohodnotnými poli, pak není moc potřeba ten rozdíl vysvětlovat.

V matematice je zvykem vektory, pole, a tenzory vyšších řádů začínat indexovat od jedničky.

V Pascalu může pole začínat i končit libovolnou hodnotou.

[johnyK]

panove dekuji obema za vysvetleni.

C je vlastně spíše jen skořápka, kde se všechno lepí pomocí intů a pointerů, protože toho mnoho neumí.

K tomu poznamka:

kvuli tomu umrti se nyni vyrojilo mnoho informaci na netu , mezi nimi i 3 videa z ETH Curych, kde v rozhovoru Wirth vlastne reflektuje svuj profesni zivot. A v druhem dile, ktery pojednava hlavne Pascal je kratce take rec o C. Tazajici konfrontuje Wirtha s vypovedi Kernighana, ze Pascal je sice hezky, ale k nicemu. Nato odpovida Wirth, ze s C je mozno delat vsechno, protoze je to vlastne jakysi vylepseny assembler, ale ze jeho filosofie vzdy byla, aby uz sam programovaci jazyk svoji strukturovanosti navadel programatora take k strukturovanemu kodu, se vsemi vyhodami, ktere jsou s tim spojene.

Na tom je videt, jak rozdilny pristup v tvorbe pogramovacich jazyku muze existovat. Souhlasim s predrecnikem, ze ty plnohodnotna pole jsou nejak vstricnejsi. Proc se ale k certu jazyk C tak rozsiril?

[okbobcz]

Myslím si, že kdyby začátkem 70 let byl dostupný jakýkoliv jazyk s vlastnostmi podobnými Cčku, tak se musel rozšířit. Je to jednoduchý jazyk na naučení, jednoduše se dá napsat překladač (v podstatě to opravdu nic neumí), a přitom výsledný kód je hodně rychlý. Totéž platí o Cčkové knihovně, stejně tak o základním POSIX API. Je to jazyk, který má extrémně plochou učící křivku. Ve své době to byl ideální jazyk pro psaní operačních systémů. A pokud shodou okolností jsou v tom jazyce napsány všechny operační systémy, které máme BSD, macOS, Linux a NT, tak se nemůže nerozšířit. Cčko je primitivní až to bolí, tam není jediná frikulínská fíčura, ale to je asi jeho hlavní výhoda.

[okbobcz]

Tím, že říkám, že je Cčko primitivní, nemyslím, že je to hloupý jazyk. Má to všechno, co tam je potřeba (pro systémové programování - v 70 nebo 80 letech). Vůči assembleru je Cčkový kód nádherně čitelný. Samozřejmě, díky nízké abstrakci je tam dost problémů s přenositelností, na některých platformách musíte řešit věci jako zarovnávání pointrů. Jakmile píšete moderní úlohy nebo aplikační úlohu - kód pro síťový stack nebo práci s XML - použití knihovny libxml2 nebo práce s regulárními výrazy, složitější operace s řetězci tak je Céčko peklo. To se ale v 70, 80 letech neřešilo.

[prqek]

Vidím to podobně. Podle mě C je dobrý kompromis mezi níkoúrovňovostí a abstrakcí. Dá se v tom psát stylem assembleru ale taky objektově, což mu dává celkem velkou univerzálnost (i když zdaleka ne na všechno se hodí). To jsem u žádného jiného jazyka nepotkal.

[Miloslav Ponkrác]

C není dobrý kompromis.

C má v základu celočíselné typu s předem neurčenou délkou. Takový int / long int - má jakou délku a obor hodnot?

Typ char, který může být signed i unsigned, podle toho jak se kompilátor vyspal?

Standardní knihovna, která vrací typy nedefinovaných délek? Schválně, přečte fread blok dlouhý 8 GB nebo ne?

[prqek]

Kompromis ze své podstaty obvykle přináší nevýhody na obě strany. Tyhle nevýhody vidím jako názorný příklad. Samozřejmě, že se to dá vymyslet lépe.

[Miloslav Ponkrác]

Strojově zaměřený jazyk, ve kterém neznáte ani velikost základních celočíselných typů - je podle mě spíše hodně velká bota, nedomyšlenost jako kráva.

[prqek]

Vždycky, když v C něco píšu, tak ty velikosti znám. Ale jinak souhlasím, taky mi ten C přístup přijde nešikovný. Ale tak nijak fatálně bych to neviděl. V dobře napsaném kódu to obvykle moc problémů nedělá. A když ano, dá se to řešit.

[Radovan]

To je věc implementace na konkrétní platformě. Proto je tam sizeof().

Co když budeš mít 36bitový počítač s šestibitovými bajty?

[Miloslav Ponkrác]

Těch mám doma asi padesát. A ve světě se takových počítačů válí na každém rohu tucet.

Ada to vyřešila mnohem lépe.

type Ascii_Character_Code is 0..255; type File_Size is 0..2**64-1;

A je úplně jedno, jaká platforma tam je. Klidně můžete mít 13bitový procesor s 3bitovými bajty - a výše uvedená definice typů bude v pohodě na jakkoli obskurní platformě.

Protože programovací jazyk, který nechápe, že datové typy jsou především oborem hodnot, se kterými pracujeme - se hodí do starého železa.

[xkucf03]

Můžeme to brát jako generika – prostě tvoříme Program<TypCharu> a tenhle program by měl fungovat, i když generický parametr TypCharu bude cokoli (nebo v nějakém definovaném rozsahu). A spíš než nějaké lemplovství nebo nedomyšlenost bude důvodem výkonnostní optimalizace – program pracuje s nativními typy dle daného OS a HW a přizpůsobí se jim. Pokud se má dělat serializace do nějakého přenositelného formátu, tak je potřeba to převést na konkrétní typy jako uint32_t, řešit endianitu, ohlídat si, že se tam hodnota vejde…

[Miloslav Ponkrác]

Ada může optimalizovat jak chce. Může používat vnitřně nativní typy procesoru, když ji přeložíte s optimalizací na rychlost. Protože váš typ a strojový typ se může mapovat jakkoli si kompilátor bude přát.

V C++ mám typy dělané jako Ponkrac::Signed<počet_bitů>, Ponkrac::Unsigned<počet_bitů>, Ponkrac::Float<počet_bitů>.

Ponkrac::Signed<11> promenna; // Také funguje.

[xkucf03]

A namapuje se to na nejmenší/optimální typ dané platformy? To je pak dobré.

[Miloslav Ponkrác]

Na nejblíže vyšší existující typ.

Kromě toho je ještě Ponkrac::Fast_Signed<počet_bitů> kdyby šlo o rychlost.

Inspiroval jsem se kdesi v knihovně Boost, ale už nevím přesně kde. Jen jsem tu jejich myšlnku, kterou měli v náznaku dotáhl.

[okbobcz]

ADA je o 20 let mladší programovací jazyk. Mám pocit, že vůbec nevnímáš chronologii. Když jsi psal o Pascalu, že je pro školy, a Modula a Oberon pro praxi, ale ono to tak nebylo. Vznikl Pascal pro slabé počítače, jako redukce Algolu. Na základě zkušeností s Pascalem a dalších požadavků vznikla Modula, a další iterací byl Oberon. Ty jazyky vznikaly chronologicky v určitých různých dobách v rámci určitých projektů. Měly svůj kontext a chronologii. Tady se učil Pascal, protože to bylo furt lepší než Fortran nebo Basic, a nic jiného na školách vlastně nebylo. Ale na ETHZ (Wirthova mateřská instituce), tam už dávno jel Oberon. Kdyby Cčko vzniklo o 20 let později, tak by vypadalo jinak - možná jako Java.

[Miloslav Ponkrác]

Ne. Algol, Pascal, Ada, Modula, Oberon jsou jazyky s algolskou syntaxí. Po syntaktické stránce jsou si dost podobné. Bez ohledu na časovou dobu vzniku.

C je jazyk s jinou syntaxí a jinou filozofií než algolské jazyky. Čert ví, jak přesně tento patvar vznikl. Mladším jazykem ke stejné syntaxi je C++ nebo Java. Pořád je to stejné - slabé datové typy, silné zaměření na "všechno je int nebo pointer" opepřené později "všechno je int, pointer nebo objekt". Ta filozofie je plus mínus stejná, slabé datové typy.

[Radovan]

Jak vznikl? Vyždímali a vyvařili z FORTRANu co se dalo a navrch plácli algolské strukturování, aby se to snadněji používalo.

A protože to vymysleli dva kryptomaniaci, všechno se v něm píše zkratkami místo celých slov.

No a ono se to chytlo a drží dodnes, takže to asi nebude tak úplně špatné, když spousta modernějších jazyků dávno skončila v /dev/null.

[Miloslav Ponkrác]

Pokus o jazyk s celými slovy se jmenoval COBOL. Stalo se to spíše odstrašujícím příkladem.

[Radovan]

Já měl na mysli begin, end, ind, dec...

COBOL - to si Grace prostě chtěla s počítačem jen tak poklábosit, aby nemusela složitě programovat. Na jednu stranu je to fantastická myšlenka, zvlášť v těch padesátých letech, ale na druhou:

Vezmi tohleto, dej to k tomuhle, takhle to ohni a zastrč tamhle.

[Miloslav Ponkrác]

Právě jsem pátral, jak C došlo k té syntaxi.

Jakýsi londýnský matematik si udělal programovací jazyk CPL, což byl polofunkcionální jazyk, kde je množství závorek samozřejmostí. Jen bloky odděloval dolarama.

Pak se do toho navěsil londýnská ajťák, a překopal CPL z matematického do systémového jazyka, který nazval BCPL. Funkcionální paradigma drasticky snížil. Dolary coby oddělovače bloků změnil na složené závorky.

Autoři C následně vytvořili jazyk B jako mixovaný drink BCPL a PL/I.

C pak vzniklo jako následník B. A to tím způsobem, že autor C Ritchie se snažil C zbavit všeho, co připomínalo PL/I. Neboť Ritchie se paranoicky bál PL/I natolik, že při pohledu na něj potřeboval psychiatra a antidepresiva.

Takže syntaxe C jsou zakrnělé artefakty polofunkcionálního jazyka našité na strukturované programování.

[Radovan]

Já bych se mu ani nedivil, on ten PL/1 je docela hnus, protože se snažili vytvořit univerzální jazyk tím že do něj nacpali všechno, jako když pejsek a kočička dělali dort.

BCPL vydržel dost dlouho na Amize.

[Radovan]

Hele, Ada je superjazyk. Ale programuj v ní na PDP-10 vyrobeném v roce 1983

Céčko je hromada starého železa od okamžiku vzniku, a stačí ti vzít pilku abys vyrobil cokoliv.

Ale je fakt že pár věcí mi v něm také chybí, třeba pascalské funkce vnořené do funkcí vnořených do funkcí...

[Miloslav Ponkrác]

V Adě se programují i velmi slabé mašiny a procesory. Nebo si myslíte, že to raket jsou dávány čtyřjádrové Ryzeny?

Naopak, v Adě je možné naprogramovat i platformy, kde C selže.

Vždyť to je účel Ady, proč byla vytvořena! Strojový i high level jazyk na jakékoli myslitelné platformy. Ada to zvládne na širším spektru platforem než C.

Zde jste se moc netrefil.

[Radovan]

Kompletní Ada s multiprocessingem a veškerými dostupnými funkcemi nebo jen podmnožina? Třeba Java běží i na bankovních kartách, ale není to tatáž Java jako na desktopu.

C na dvaatřicetibitovém procesoru má dvaatřicetibitový int. Na šestatřicetibitovém procesoru bude mít šestatřicetibitový int. Pokud na něm budu chtít použít nějaký t_int32 z knihovny, nic mi v tom nebrání. Jenom to udělám jinak než v té Adě.

Ale mezi námi, Ada se mi sice strašně líbí, ale C prostě žeru. Jde asi o ten pocit že v něm držím hardware pod krkem a nemám pod sebou sto nadýchaných polštářů jako princezna na hrášku

[Miloslav Ponkrác]

Kompletní Ada.

Klidně žerte C. Já mám dojem, že držím hardware pod krkem v Adě, Pascalu, Fortranu, Module, a řadě dalších jazyků. V těch všech je přesně jasné a zřejmé co se uděje ve strojáku. A je to přitom mnohem příjemnější než v C.

[Radovan]

Jak na co. Oni ten UNIX původně chtěli psát ve FORTRANu, ale velice rychle zjistili že je to takový voser, že si radši vyvinuli vlastní jazyk. Univerzální

Ale souhlas, je to o tom pocitu.

[deda.jabko]

Kdyz uz jsme u toho, Kralyka a me by zajimalo, jestli existuje nejaka acrhitektura, kde neni v C/C++ definovanym typ uint16_t.

[Miloslav Ponkrác]

C se rozšířil jako černý pasažér unixu.

Unix byl v té době nesmírně populární. A co se k unixu přibalilo, to se prostě rozšířilo - bez ohledu na to, jestli to něco je dobré či exkrement.

Kdyby k unixu přibalili Pascal, tak o Céčku dnes neslyšíte. Kdyby k unixu přibalili (tehdy neexistující) Javu, tak dnes Javu všichni milují.

Prostě cokoli se přibalilo k unixu, se rozšířilo. Jakkoli blbá věc.

Tak to prostě fungovalo.

Dnes má stejnou funkci třeba Google nebo Microsoft. Vytvořte jakoukoli debilitu, ale když jí bude šířit Google nebo Microsoft, tak se prostě rozšíří. Google vytrvale devastuje webové standardy, ale jakkoli blbej standard s podepsaným Google se rozšíří - a nikdo proti tomu moc nenadělá.

[koroptev]

tyhle akademicky debaty o tom, jestli je jazyk objektovej nebo ne apod. ... onanie

[petr_p]

Pokud si dobře vzpomínám, tak Pascal pole sice má, ale o statickém počtu prvků. Což zase vede na ošklivosti typu zakompilovaný limit pro počet položek, které program dokáže zpracovat. Pole definované uvnitř funkce sice mohlo mít velikost závislou na parametru funkce, ale už se nadalo vracet ven. Pak už jen zůstávala možnost použít ukazatele, kteréžto v (Turbo?) Pascalu byly, ale oproti Céčku práce s nimi byla syntakticky značně kostrbatá. (V ten okamžik už bylo lepší přejít k Céčku. Nehledě na to, že člověk dostal mnohem rychlejší binárku nebo 32-bitovou paměť. A jak si člověk zvykl na Céčko, tak už se nechtěl vracet k ukecanému bloku begin-end, číslovanému goto apod. Tohle byla podle mne ta pravá smrt Pascalu.)

[kdosi]

Ta práce nijak moc kostrbatá nebyla, jen se to zapisovalo trochu jinak.

A samozřejmě se dal udělat typ velikého pole, na který se dal přetypovat obecný ukazatel, takže to pole pak sahalo za konec místa rezervovaného v paměti (jako všechna Cčková "pole" - co k ukazateli přičteš, to tam bude, když sáhneš kam už nemáš, tak se můžou dít věci).

32 bitovou paměť TurboPascal uměl taky. Stejně jako například overlaye (napíšeš program větsí než dostupná paměť a on si za běhu natahuje potřebné kusy do paměti sám) :)

[koroptev]

jak umel pascal 32bit pamet? nachazim zminku o tom, ze bp (nikoli tp) ve verzi 7 umel pouzit extender a tudiz protected mode, je to toto?

[vgy]

rm -fr DOS pičoviny

[vgy]

nech si to ošetrí niekto iný :) pretože pracák je neďaleko alebo nech program zdochne. A ak za behu, tak žiaľ zmeniť snapshot a jede sa ďalej. a zavolať si programátora na exkurziu po nadávkach

[koroptev]

vpodstate souhlasim, turbo pascal zastydl

produkovalo to kod jen pro realnej mod (byt ted nachazim, ze pry borland pascal 7 umel pouzivat nejakej extender), cili limity adresovani, inline assembler neumel sam od sebe (db 66h lol) pracovat s 32bit registrama a knihovni funkce typu move kopirovaly po bajtech (nebo wordech, uz je to fakt davno)

inherentne ale neni moc duvodu, proc by prekladac pascalu mel byt vyrazne pomalejsi nez prekladac c (coz se nejspis da dolozit porovnanim fpc a gcc)

[okbobcz]

Překladače Céčka jsou víceprůchodové - z důvodu omezení paměti. Překladače Pascalu mohou být také více průchodové, nicméně Pascal byl navržen tak, aby bylo možné napsat jednoprůchodový překladač. Což výrazně zrychlovalo rychlost překladu. Na druhou stranu to omezovalo velikost překladače. Tímhle byl právě pověstný Turbo Pascal, kde se vám do RAMky vešel editor, překladač a kolikrát i samotná aplikace. Vývojový cyklus byl podobně rychlý jako třeba v Basicu, ale byl to překladač, takže kód byl výrazně rychlejší než tehdejší Basic. fpc je z roku 1997 - to už bylo běžně 16-32MB ram, a relativně rychlé hardisky. TurboPascal je 83 roku, ještě na XT nebyly úplně běžné hardisky.

[koroptev]

sorry, myslel jsem "kod produkovany prekladacem" a napsal "prekladac"

[Miloslav Ponkrác]

Ale ono zastydlo i Turbo (později Borland) C/C++. Například neumělo vytvořit program s globálními proměnnými v součtu nad 64 KB. To byl tehdy častý důvod přechodu na Microsoft C/C++, který s tím neměl problém.

Borlandské překladače a IDE byly příjemné, ale prostě ty kompilátory měly často zbytečná omezení. Byly to nedodělky. Pomalý výsledný kód programů, časté chyby v kompilátorech, různá zbytečná omezení.

S hrůzou se dodnes probouzím v noci, když jsem byl nucen kontrolovat ve strojáku, zda Borland přeložil správně to, co je ve zdrojovém kódu. Už nikdy více.

[okbobcz]

Moderní standard Pascalu má dynamické pole.

Pascal má svoje kouzlo v konzistenci syntaxe, což má význam v jednoduchosti psaní parseru (to ve své době mělo extra význam, jelikož se vám vešel parser, překladač i aplikace do RAMky), pro vlastní psaní to není extra komfortní, a víc se mi líbí Modula, nebo pozdější Oberon. Se stylem Moduly se potkávám denně - v PL/pgSQL (což je okopírované PL/SQL, což je přejmenovaná a malinko upravená ADA). Visual Basic má hodně ze syntaxe Moduly. Wirth neskončil Pascalem - naopak ty jeho další jazyky elegantně řeší problémy Pascalu.

[Miloslav Ponkrác]

Pascal byl vytvořen jako jazyk pro výuku programování. Proto měl některé trochu vadící věci v syntaxi - aby studenty naučili čistotě kódu a programu.

Pro praxi byla určená Modula a Oberon. V obou jazycích byly napsány i operační systémy, a to včetně plného GUI. Používají se občas dodnes.

Pascalovská syntaxe se používá v obrovském množství programovacích jazyků. Ostatně vychází z Algolu. A je mnohem čistší a srozumitelnější než C/C++ syntaxe. Například Ada, Simula, Mesa, novější Fortran, Lua, a mnoho dalšího.

A až budete dělat hardware, tak VHDL jazyk na popis obvodů je taky Pascalovskej.

[Miloslav Ponkrác]

Jaký je problém mít v Pascalu ukazatel na pole, a tím pádem nepotřeboval ani v poli proměnné délky žádnou pointerovou artimetiku?

[petr_p]

Nějaký problémy tam (Turbo Pascal) asi byly. Typ pole, na který ukazatel ukazoval stejně potřeboval znát maximální velikost už v době deklarace typu. A ta velikost závisela na množství volné paměti za běhu. Když tam člověk dal příliš velkou konstantu, tak se program odmítl spustit. Když tam dal malou, tak zase program měl umělé omezení. Taky mám dojem, že odmítnutá alokace paměti za běhu namísto chyby vyvolala výjimku. Ta se sice dala zachytit, ale standardní běh programu byl v pytli, takže sice člověk dostal hezkou hlášku, že došla paměť, ale pak vždy následoval konec programu.

[Radovan]

Z jedné pradávné diskuze na Rootu:

Vy asi nepamatujete Teslu 200 se vstupem z dernych pasek z dalnopisu. To clovek deroval na dalnopisu, az do nemoty, pak svinutou pasku hodil do krabice a cekal, kdy si bude moci prijit pro vypis (na te Tesle 200 byl prekladac Pascalu). Kdyz doslo k chybe (preklep nebo chyba pri derovani=syntax error), tak znovu na dalnopis, odkrokovat puvodni pasku az k chybe, opravit chybu a odkrokovat zbytek za chybou. Pri trose stesti i nekolikrat. A kdyz tam jeden dobrak nadeklaroval v programu trirozmerne pole trirozmernych poli trirozmernych poli, Tesla 200 lehla a musel se znovu zavest system. Operator si na toho dobraka tehdy pockal a ptal se ho, co tim sakra myslel.

Takže bych takové chování pokládal za pascalský standard

[okbobcz]

My jsme měli Teslu 200 https://www.historiepocitacu.cz/stredni-tranzistorovy-pocitac-tesla-200.html a na západě PDP 11 :-/

[Radovan]

Tesla 200 pocházela z Francie. Takže ten západ jsme tu vlastně měli také.

Ale v USA ty PDP-11 mají dodnes, běží v emulaci a řídí jaderné elektrárny

[okbobcz]

Co na západě končilo, to jsme tam se slevou kupovali a tady s velkou slávou zaváděli.

Že něco běží v emulaci - komerční banka ještě běží na Cobolu - možná letos se ho zbaví.

[Radovan]

Já bych se toho Cobolu radši ještě držel. Ty bys klidně svěřil jaderku softwaru v Javě?

Problém je, že dnešní mlamoj, který od plenek drží šmatlafoun v pracce, Cobol nikdy pořádně nepochopí. Chybí mu vyjadřovací schopnosti. Teda tomu mlamojovi, Cobolu určitě ne.

Nového psa starým kouskům nenaučíš.

Ale ta Tesla byl sálový počítač, to PDPčko bych srovnával spíš s ADT-4500. Ačkoliv i ten vlastně pocházel ze západu

[okbobcz]

V Cobolu bych nepsal ani já, resp. by mne museli platit zlatem a takovou nabídku jsem nedostal.

Ty mladý by se to naučili, kdyby chtěli a měli a dostali čas. My jsme taky neuměli všechno. Lidský schopnosti jsou úplně stejný. Drtivá většina programátorů, které znám žádný extra esa nejsou (mne nevyjímaje). Jen to, co tehdy parta lidí pytlíkovala v Cobolu 4 roky, tak teď by měl udělat jeden člověk za rok, a kecá mu do toho mnohem víc lidí, kteří nerozumí technologii. A před 40 roky se k počítačům dostali lidi víceméně s VŠ, dneska tam už ten filtr není. Dostat se k počítači před 40-30 roky bylo exkluzivní, exotika, dobrodružství - to člověka motivovalo objevovat a učit se - a to učení nebylo jednoduchý - nebyl Google, nebylo stack-overflow - dokumentaci si člověk musel přečíst načíst. To, co jsme dělali, je dneska banalita, na které nic moc vzrušujícího není. Navíc IT zabili peníze a korporát. Být mladší, znovu teď začínat, tak bych asi nešel rozhodně do databází a možná ne do IT.

[Radovan]

Možná jo, ale kolik dnešních "expertů" by dokázalo udělat tabulku ve VisiCalcu? Jako ne že bych s tím chtěl dělat každý den, ale tuhle jsem si v něm odsimuloval nějaké sekvenční obvody

[okbobcz]

Na procenta populace je to pořád stejné. To se nemění. Je fakt, že ve VisiCalcu asi minimum, stejně tak v Lotusu nebo Multiplanu, jelikož je to znalost sice interesantní ale docela zbytná, stejně jako třeba umět latinu nebo švabach. Třeba moje prababička uměla číst švabach a já to neumím, a nemyslím si, že je na světě méně expertů než tehdy. Ale kdo před 40 roky spustil VisiCalc, tak si dneska pustí Excel nebo Libre office calc. Nějaká základní znalost - na to, aby si někdo ve spreedsheetu udělal nějakou kalkulaci bude mnohem širší - z těch lidí, kteří by si vůbec udělali - protože ten software i hardware je všude. Ne všechny znalosti má smysl udržovat - ještě v 60 letech každý inženýr musel umět dělat s logaritmickým pravítkem, já vím, že existovalo, a můj synovec vůbec netuší, že něco takového bylo. A svět rozhodně kvůli tomu není hloupější.

[Radovan]

Švabach číst umím, latinu ne. Takže jsem kdysi v táborském muzeu lehce vytrolil nějaké studentky historie, když se pokoušely rozluštit nápis na obrazu

Jenže ve dnešních oppicích si ty sekvenční obvody emulovat nemůžu, je tam zpětná vazba!

Je potřeba udržovat znalost čtení a psaní, když máme hlasové asistenty?

[okbobcz]

Google ví všechno - https://www.libreofficehelp.com/error-522-libreoffice-openoffice/ něco podobného bude i pro Excel. Tam byl nějaký resolver (ale dělal jsem s tím před 30 roky, tak už nevím). Já bych to asi udělal ve VBA, asi bych si kvůli tomu VisiCalc nepouštěl. Ale proti gustu - aneb, co se v mládí naučíš.

Ti moudří, které sleduji, tvrdí, že je to důležité, jelikož mozek je potřeba trénovat, a čtení a psaní rozvíjí určité schopnosti mozku a jemnou motoriku. A je to něco, s čím se začíná (a dá začít) u malého dítěte (6let). Vidím tam určitou analogii s jinými svaly. Není nutné odmala nutit děti nebo i dospělé do fyzické námahy (když z většího dnešní práce už není fyzicky namáhavá), není nutné trénovat chůzi, když dneska ve městě nemusíte ujít víc než pár stovek metrů. Ale určitá kondice je potřeba k dobrému spánku, a dobrý spánek je důležitý pro psychiku a duševní zdraví a pohodu, a dokola. Kondice je důležitá pro udržení si pohyblivosti ve stáří. atd atd. Některé znalosti možná nevyužijeme v praxi, ale určitě je budeme trénovat, drilovat protože žijeme ve fyzickém světě, máme fyzické tělo, a mysl, kterou je potřeba trénovat, a udržovat. Dřív lidi chodili, protože museli, dnes chodíme, protože nám to dělá dobře.

[Radovan]

Mozek je sval, musí se hýbat, jinak zakrní.

Čtení a psaní prý využívá starší centra mozku než mluvení, ta která naši praopičáci měli pro posunkovou řeč.

Dneska v officu nemůžu udělat A1=!B1, B1=!A1, protože mi to prostě nedovolí. Zacyklení je error. V tom VC to jde a můžu si to krásně krokovat. Ale samozřejmě si také můžu pustit falstad.com/circuit

[xxx]

TVL. Co s tim Cobolem mate. Je to primitivni jazyk, kterj se naucite za tejden. Dlasi mesic se budete ucit paterny, ktery v nem dana firma pouziva. A pak v nem nadosmrti muzete udrzovat nejaky legacy system, kde veskera prace spociva v tom nerozmrdat nic okolo. Cely to nema zadnou dokumentaci, protoze dokumentace je kod. Takze jestli se vam to tak libi, tak go for it. Placeny je to dobre. Ve vsech dlasich ohledech to stoji za hovno.

[petr_p]

Jazyk, který má přes 300 klíčových slov, se za týden nenaučíte.

[xxx]

Sice to byla to nadsazka, ale zase na druhou stranu, kdyz umis anglicky, tak uz ty slova, a vlastne i vety, znas.

Nicmene pointa byla, ze pokud si nekdo mysli, ze v Cobolu a v tech systemech v nem napsanych, najde svaty gral programatorske elegance a geniality, tak at si to jde zkusit.

[koroptev]

samozrejme, ze nic takovyho se v cobolu najit neda

cobol je takovy nestastny rukojmi par duchodcu, co z tyhle niky tezej velky love a mozna nektery z nich, co uz ztratili uplne soudnost, si na zaklade toho i myslej, ze v tom je nejaka relevance pro dnesek

neni, jen ma ten tezkotonazni vlak dlouhou brzdnou drahu

[Radovan]

Rukojmí pár důchodců s deseti prsty.

Pokud nevíš na co narážím, vyhni se velkým obloukem finanční sféře.

[petr_p]

kdyz umis anglicky, tak uz ty slova, a vlastne i vety, znas

Právě že ne. Můžeš jenom tušit, co to dělá, ale rozhodně neznáš důležité detaily. Například:

MULTIPLY WS-A BY WS-B

Výsledek násobení se uloží kam? Správná odpověď je do WS-B.

MULTIPLY WS-A BY WS-B 
         ON SIZE ERROR DISPLAY "OVERFLOW"
     NOT ON SIZE ERROR DISPLAY "WS-B:  " WS-B.

Při aritmetickém přetečení se zobrazí hláška „OVERFLOW“, ale co výstupní proměnná WS-B? Bude její původní hodnota zachována, nebo v ní bude smetí? Podle manuálu pro zOS zůstane zachována.

Tohle by se dalo čekat. Ale co tohle:

MULTIPLY C BY D E

Podle výukového materiálu se C*D uloží do D a výsledek C*E uloží do F. Doufejme, že je to jen překlep a ve skutečnosti se uloží do E.

Jaký bude obsah D, když k přetečení dojde při ukládaní do E, už manuál mlčí:

MULTIPLY C BY D E
         ON SIZE ERROR DISPLAY "OVERFLOW"

Vědět a myslet si, že vím, jsou dvě různé věci.

[xxx]

Reseni overflow v C taky neni zadny labuzo. Ostatne dulezita je znalost, ze je treba to vubec resit. Ale pravda je, ze jsem nemel psat, ze to je trivialni, ale proste jen, ze se to zas tak nelisi od jinych jazyku.

[petr_p]

O přetečení vůbec nejde. Chtěl jsem ukázat, že znát důvěrně 30 klíčových slov třeba v C, nebo stejně bravurně ovládat 300 v COBOLu je v praxi sakra rozdíl. Obzvlášť, pokud ten kód nepíšeš sám, ale udržuješ kód cizí.

[xxx]

Chapu ze nejde o preteceni, ale kdyz uz to bylo vybrano jako priklad, tak jsem se ho drzel. Z meho pohledu je jedno, jestli se pro reseni nejakeho problemu (nasobeni s overflow) potrebujes naucit 300 slov a o to jednodussi pattern na jeho reseni, nebo 30 slov a slozitejsi pattern na reseni. Pro mne ta komplikovanost roste naopak smerem k Brainfucku, nez pridavanim klicovych slov.

To spis naopak. Pokud udrzujes cizi kod, tak tohle se louska s ref. priruckou pomerne snadno. To uz spis psat sam vyzaduje skutecne tu znalost tech 300 slov.

[Radovan]

Vezmi si referenční příručku COBOLu, stáhni nějaký menší program, tak milion až dva řádků, a udělej v něm pár změn tak abys nic nerozbil.

Až pochopíš že v tomhle jazyce není nic jako v těch ostatních, a pustí tě z blázince, tak nám o tom můžeš povyprávět

[xxx]

Takovyhle reci tady budou za tricet let o Jave/C++. Mas tam neco konkretniho?

[Radovan]

Pokud v tom blázinci chceš takovou dobu strávit, tak se ten COBOL můžeš zrovna zkusit naučit celý

[koroptev]

hele a tohle ma prokazovat kvality COBOLU nebo jeho idiocii?

[Radovan]

Idiocii dnešních kódovacích opic

[Radovan]

A co třeba takový JCL se třemi základními příkazy?

Peklo středověku

[--]

Spíš každodenní realita.

[Radovan]

V tom digitálním středověku určitě, bez řídícího štítku se program nedal ani natáhnout do paměti, ale dneska už je to doufám dávná historie

[--]

Doufat můžeš, ale z/OS se pořád používá, včetně JCL. Pro mě sice JCL není každodení realita, ale čas od času nějaké napíšu a znám lidi, pro které to každodení realita je a emulátor 3270 snad nejpoužívanější nástroj. Jo, máš pravdu, děrný štítky tam koukaj snad z každýho řádku.

[koroptev]

duchodci a mrtvoly bez duse a invence, co se zaprodali za par susnu do "velkochovu" (korporat)

[Radovan]

Tak trochu jsem se obával že něco takového odpovíš.

Středověk neskončil, středověk trvá...

[koroptev]

Cobol je btw jazyk, kterej vznikl v domeni, ze kdyz se zkripli syntaxe jazyka tak, aby pripominala anglicke vety, manazeri pak budou schopni programy vyrabet sami

coz byl samozrejme omyl a v jeho dusledku byli nuceni lide, kterym "normalni" (cti abstraktni) syntaxe necini zadny problem, prochazet utrpenim

tozn. pokud jsi clovek, ktery apriori adoruje Cobol, neco to o tobe rika

[Radovan]

Tak se ho za týden nauč a můžeš těžit velké love

Jestli ti přirozený jazyk připadá málo abstraktní, měl bys rychle změnit svého dodavatele drog.

[koroptev]

proc bych tezil velke love brodenim se srackama, kdyz je muzu tezit delanim neceho, co brodeni srackama nevyzaduje?

[Radovan]

Nauč se COBOL a pochopíš.

[johnyK]

komerční banka ještě běží na Cobolu - možná letos se ho zbaví.

fakt se jim to podarilo?

Na heise.de (to je ten nejrozsirenejsi it portal v nemecke jaz. oblasti) byl pred mesicem prispevek, ze v posledni dobe skokove norostl zajem o Cobol-programatory. Je to pry z toho duvodu, ze to stare software (jako napr. v tech bankach) se vpodstate neda za rozumnou dobu a penize predelat do neceho jineho. Bezne pry je u takove banky treba pocitat s dobou 8 let, behem kterych by se to software melo prepisovat do neceho 'modernejsiho' a to je ten duvod proc to nikdo nezkusi, prtoze neni mozne to software po celou tu dobu zakonzervovat, abe se neco nemenilo. (on ten hlavni duvod samozrejme je, ze se zatim nikdo nenasel, kdo by se pod ten projekt podepsal). A proto pry se rozhodli, ze jedina schudna cesta je, naucit lidi ten Cobol, aby to dal spravovali. ( )

Jestlize to tedy komercni banka da, tak klobouk dolu ... je samozrejme otazka, jaky rozsah to software ma. Ja osobne znam objednavkovy system korporatu (Automotiv) , ktery se tam snazi uz 30 let predelat do Javy (3 pokusy) a zatim to vzdycky zkrachovalo.

[Radovan]

Nebo se možná letos zbavíme Komerční banky

[okbobcz]

Co se ke mně doneslo, tak oni neportují ten starý systém. Nějaký nový systém koupili, nechali si ho upravit, a pravděpodobně do něj přenesou data. Viděl jsem nějakou prezentaci, kde se bili do hrudi, že jsou v tom úspěšní, ale jaká je realita - nevím, netuším. Tipoval bych, že jsou pod dvojím tlakem - konkurence už na Cobolu není (a nějaké menší banky mají moderní sw), a Cobolisti už fakt nejsou (lidi s praxí).

[xxxs]

tusim 90% firiem pri pokuse o zmenu systemu zdochne.