Vlákno názorů k článku Fortran: Quo vadis? od Mikuláš Patočka - Nebude Fortran s těmi novými featurami už poněkud...
-
Mikuláš Patočka (neregistrovaný)Nebude Fortran s těmi novými featurami už poněkud přepatlaný?
Ve F77 se sice nějaký uživatelský program (např. se strukturami) napsat nedal, ale měl velkou výhodu, že byl jednoduchý, vědci a inženýři se jej nemuseli zdlouhavě učit, nemuseli se zabývat syntaxí, strukturováním programu apod.
Pokud do Fortranu připlácají featury jako z C/C++, tak je otázka, kdo se to bude chtít učit a kdo to pak místo C a C++ bude používat? -
To je samozřejmě věc názoru.
Podle mého názoru (a zkušenosti) je naučit se programovat ve Fortranu podstatně jednodušší než naučit se programovat v C nebo C++, tedy přinejmenším naučit se v něm dělat programy skládající se jen ze soubrového/konzolového I/O a výpočtů. Stát se na něj expertem a znát všechna zákoutí, zejména ta z minulosti, je samozřejmě podstatně těžší. Ale i expertů na Fortran 77 znám mezi staršími kolegy málo.
Fortranská komunita a potažmo standardizační komise nemá žádný záměr konkurovat
C/C++. Jejich záměrem je vytvářet co nejlepší general-purpose jazyk pro numerické výpočty (to není oxymoron :) Nic takového zcela zřejmě (a oficiálně) není záměrem komunity C a C++. Hmm, možná jsem měl tuhle kapitolu více rozvést. -
Mikuláš Patočka (neregistrovaný)Mě by zajímalo, co udělá inženýr (který nikdy žádný uživatelský klikací program nepsal ani nehodlá psát), až dostane zdroják ve Fortranu s objekty a dědičností a bude po něm chtěno, aby ho pochopil a upravil. Fortran byl jednoduchý na naučení právě proto, že tyhle věci neměl.
Přijde mi, že se objekty (a pointery) na tohle použití nehodí. Je nějaký příklad numerického výpočtu, kde by objektovost přinášela výhodu? -
Samozřejmě ano, ale není to příliš časté. Ze své praxe vám mohu říci, že ve výpočetních utilitách malé až střední velikosti (to je subjektivní) vůbec necítím potřebu používat OOP, začínám ji cítit, když už program začíná mít různé komponenty a stává se generickým.
Pointery jsou trochu o něčem jiném, protože bez nich prostě (ve Fortranu 77) nebyla možnost jak
někam "a posteriori" uložit odkaz na nějaké pole. Já si myslím, že omezené pointery jsou ve Fortranu udělané dobře, jen tam prostě měla být i omezená možnost udělat "generický" pointer,
se kterým by šla udělat třeba jen jediná věc, a to předělat ho zpátky na ten správný typ.
Abych to ještě rozvedl, já jsem za svou zatím celkem krátkou praxi došel k názoru, že optimální
model pro výpočetní programy je systém malých až středních utilit, které se ovládají z příkazové řádky a komunikují pomocí souborů a stdin/stdout. Když udělám knihovnu s hezkým rozhraním ve Fortranu 95, je dobrá pro mě a pár vybraných kolegů. Když udělám sexy objektové rozhraní v C++, tak na ni teoreticky dosáhne víc lidí, když udělám klasické C rozhraní (to můžu i ve F2003), tak ještě víc. Naprosto nejvíc lidí ale bude moci můj software používat, když místo systému funkcí a objektů vytvořím systém spustitelných programů ve stylu GNU coreutils, ovládaných volbami z příkazové řádky a komunikujících přes soubory, protože naprostá většina i "počítačově tupých" lidí je relativně schopná a ochotná se naučit a pochopit jak fungují soubory a příkazová řádka, a většina z nich dokonce pochopí i roury a skripty (prostě zapíše příkazy do souboru). Zatímco doufat, že všichni kterým by se můj soft mohl hodit, se naučí programovat v C++ a používat objekty, je marné. Ty knihovny můžou klidně být v pozadí, ale je prostě zbytečné snažit se stvořit co nejintuitivnější a nejflexibilnější
rozhraní i pro idioty, protože můžu s klidem předpokládat, že kdokoli bude knihovny používat,
bude na podobné úrovni jako já.
V tomto světle, kdykoliv to jde (a ono to určitě vždycky nejde, ale překvapivě často) se
snažím rozbít svůj software na nezávislé utility, které si kolegové mohou osvojit postupně a
používat je jednoduše a intuitivně
(spustím to, vypíše to help, přečtu si syntax a volby co potřebuju, připravím soubory, a spustím to znova. Když je to dlouhé a je těch utilit víc, dám to do skriptu a pak spouštím ten.)
no, už to přetahuju, ale chtěl jsem tím říct, že OOP potřebuju tak výjimečně, že se vůbec nedivím, že ve Fortranu 95 není. -
Mikuláš Patočka (neregistrovaný)S tím programováním v shellu --- problémem je rychlost. Pokud uděláte třeba utility na sčítání, násobení a další operace s maticemi a budete programovat pomocí pouštění těchto utilit přes pipy, tak to bude tak tisíckrát pomalejší než kompilovaný kód --- většinu času zabere fork, exec, dynamické linkování těch utilitek při jejich pouštění a parsování vstupů.
Řešením by mohl být nějaký specializovaný matematický program, který by měl takovéto rozhraní a přitom si kód vnitřně kompiloval a pracoval vnitřně v binárním formátu čísel. Ale sám nevím, jak se ty matematické programy ovládají.
--- no, i když ono je pořád jednodušší napsat "a=b+c*d" než
"cat c | multiply d | plus b >a"
Ad. to, jak má vypadat jazyk pro počítačové nevzdělance --- třeba můj otec je dobrý inženýr a fyzik, ale k počítačům má odpor --- a používá na výpočty excel. Proč? Protože se v něm nemusí učit syntax a co napíše, to vidí. Sice je excel na větší programování naprosto nepoužitelný (proměnné nejdou pojmenovávat názvy, ale odkazy typu A3, neumí víc jak 2-rozměrné pole, nejde v něm nijak řídit průběh výpočtu), ale jemu to na to, co dělá, stačí. IMHO kdyby někdo udělal jazyk, který by i takovíhle lidé pochopili (t.j. s naprosto jednoduchou syntaxí), tak by měl reálně šanci na úspěch. Při nabalování featur z C++ do Fortranu si nedokážu dost dobře představit, kdo to pak bude místo C++ používat. -
Ne, to jste mě úplně špatně pochopil. Je sice možné (a občas i užitečné) mít utilitu na například sečtení dvou souborů čísel (tou je např. AWK), ale to samozřejmě neznamená že bych ji pak musel volat z programů ve Fortranu. Můžu, pokud nejde o časově kritickou operaci.
Takových programů je mnoho, např. Octave. Problém je právě v tom, co jsem říkal - používat (kopírovat, mazat, přejmenovávat) soubory a spouštět programy většina lidí umí nebo se to naučí velmi záhy, zatímco učit se Octave chtít nebudou.
Pro low-level operace jako sčítání a násobení jim samozřejmě nezbude nic jiného, než nějaký ten tabulkáč, nebo Octave, AWK apod., nebo si napsat vlastní program. To ale lidi příliš často nepotřebují.
Příklad: J.R. Schewchuk vytvořil excelentní 2D meshátor (generátor sítí) jménem
triangle. Je možné jej použít dvěma způsoby - jako knihovnu s C rozhraním nebo pomocí "driveru", tedy souborů a příkazové řádky. Přestože si s tím dal autor jistě práci, nemůže komfort C rozhraní soupeřit s komfortem driveru, takže software používá stokrát více lidí jako driver než jako knihovnu (např. studenti numeriky na MFF). A dokonce i ve svých programech jej používají tak, že zapíší data do souborů a pak zavolají driver (i já jsem to tak dělal). Ušetří svůj čas za čas procesoru, a jsou to ochotni udělat i v mnoha jiných případech. Kdyby se meshovala tisíckrát nějaká miniaturní síť, asi by nebyli.
Váš otec je typickým příkladem inženýra - (když to přeženu) počítač je pro něj jen jeden z mnoha přístrojů a nechce mu nadržovat. Excel se prostě naučil a vyhovuje mu, tak jej používá kde jen to jde. Pro jiné inženýry je to třeba jiný nástroj - Matlab, Octave, nebo ten starý Fortran 77.
Každý programovací jazyk je kompromisem mezi jednoduchostí a silou a pár dalšími věcmi. Vždycky tu proto bude více jazyků, vyhovujících různým skupinám lidí, a je potřeba to přijmout.
Vaše poslední věta o "nabalování featur z C++" svědčí o tom, že jste příslušnou část článku naprosto nepochopil (to ale může být i moje chyba). Fortran nic "nenabaluje". Změny ve Fortranu jsou reakcí na požadavky jeho uživatelů, a jen velmi vzdáleně, pokud vůbec, mají vzor v C++. Komise Fortranu se snaží vycházet vstříc jednoduchosti právě tím, že je poměrně konzervativní ohledně nových featur - když už se tam něco protlačí, tak to tam (někteří) uživatelé chtějí. Bohužel má Fortran nejdelší historii a tudíž i největší práci se zpětnou kompatibilitou. K odstranění featury obvykle dojde tehdy, když komise usoudí že je nahraditelná nějakou novější a nemá už široké použití v nových kódech. "Nových" je důležité. Kdyby se vycházelo vstříc všem "legacy" kódům, nikdy by se nic nikam nepohnulo. Ostatně nikdo uživatelům nebrání řídit se starším standardem.
