Hmm, M4 jsem používal kdysi, když jsem přecházel (myšlením) z C na Python a vadilo mi, že Python nemá preprocesor. Ale tak nějak jsem to časem přestal potřebovat. Vzhledem k tomu, že to prakticky nikdo nezná, to jde používat asi jen soukromě, ale v žádných projektech.
5. 2. 2020, 09:13 editováno autorem komentáře
Takže vlastně si člověk usnadní práci v jednom jazyku tím, že si jí přidělá řádově více v jiném , abstraktnějším jazyku. A ještě k tomu musí být na úrovni profesora z algebry, programování, gramatiky a stavových strojů. A když toto splní, tak je to věc, kterou nikdo nepodporuje a nikoho nezajímá. Supr věc na použití.
To přeháníte. Ty zdánlivě složité pojmy lze přeložit do neformálního jazyka:
1) najdi-nahraď a nahrazuj tolikrát, kolikrát to lze nahradit bez ohledu na okolní symboly (CFG)
2) při tvorbě kódu občas přehoď výhybku a vytvářej kód jinak (automaty)
3) výsledné kousky kódu ihned nevypisuj, ale někam si je na chvíli schovej (výstupní fronty)
4) zapamatuj si předchozí stav a někam si na chvíli odskoč (zásobníky)
Jsou dva extrémy:
Není dobré se dnes a denně přehrabovat v kódu, který by klidně mohla udržovat i cvičená opice (mrháte svůj potenciál).
Není dobré generovat kód, který se téměř nikdy nemění (mrháte svým úsilím a časem).
Díky za zpětnou vazbu, s těmi formalismy a strašením jsem to asi přehnal.
Zkusím vymyslet co možná nejlidštější popis jazyka pomalejším tempem + kratší příklady.
Ten jazyk je fakt dobrý a dobře se v něm i píše (Vim).
m4root]$ find -name '*.m[c4]' | wc -l
129
Nepočítám tu hromadu kódu, kterou jsem přepsal nebo vyhodil.
Tento clanok je ako taky stroj casu - takto nejako som si predstavil ten manual k ALGOL-u, ktory tu bol na roote popisovany, ze mal stovky husto a urcite matematicky super korektne popisanych stran, ale asi by ho uz dnes nikto citat nechcel. :)
Asi nebude nahoda, ze oba nastroje vznikali v rovnakej dobe.
Tak to patřím do nějaké jiné, ortogonální skupiny. S low level věcmi (C, občas pro formu nějaká drobnost i v asm) problém nemám, s M4 ano, ale z m4 mám husí kůži. Proč?
1.sendmail
2.na věci co si dělám sám je to kanón na vrabce, je spousta snadnějších prostředků na dosažení téhož (občas na generování céčka použiju awk)
3.na věci kam občas hrábne i někdo další docela nevhodné, asi bych byl od kolegů rychle přizabit.
4.z pohledu projektu, kde by se třeba i projevily přednosti M4 proti zbytku světa, část kódu které rozumí jen jeho autor taky není moc velká výhra. A přiznejme si, M4 rozhodně není "kouknu a vidím co to dělá"
5.ale dokážu si v m4 představit semestrálku :-)
1. pohroma jménem Sendmail už naštěstí skončila v pekle jako neopravitelný kus SW
2. od jisté velikosti projektu M4 skript už tolik neroste jako např. XSLT nebo AWK skript
3. zatím bych s tím kolegy moc neprovokoval, hodně záleží na autorovi skriptu jak píše a dokumentuje svůj kód
4. když se udržuje jednotná základní kultura M4 kódu, pak je to i docela přehledné
na mých příkladech je jasně rozeznatelná kostra výsledného kódu, která se posléze obalí masem
5. nějaký zápočtový projekt do Automatů a Gramatik by byl asi v pohodě
udělám několik dílů se zaměřením na automaty na oba způsoby (generující/detekující)
Hutné čtivo :-). Na to, že si myslím, že jsem s m4 trochu obeznámen, tak tohle si budu muset přečíst ještě jednou pomaleji. :-). Upravil jsem si pro sebe kdysi systém na generování konfigurace bindu od Martina Mareše NSC a stále to vesele používáme. Pokusím se tady trochu otočit smýšlení směrem, že to snad ještě nepatří do starého železa. Naopak po překročení nějaké hranice se pro to nadchnete ;-).
Mě osobně celkem mrzí, že plno nových projektů utíká od klasických autotools a používají různé jiné buildovací nástroje. Ono to teda souvisí spíš s přechodem na jiné jazyky než C. Ale což, holt vývoj. Na tenhle seriál se budu těšit. Díky za poctivě zpracovaný materiál.
Dobrý den,
Kdysi jsem s M4 začal dle série článků zde na rootu: https://www.root.cz/clanky/makro-procesor-gnu-m4/ a pak metodou pokus-omyl. Občas to ještě používám právě jako jednoduchý preprocesor. Jsem programátor amatér / hobbysta (strojař) bez formálního programátorského vzdělání.
Ale tento článek jsem nedal. Je tam příliš formální terminoligie - černé magie pro mě.
Jinak souhlasím, že M4, make, automake, autoconf, gettext jsou dobré a mocné nástroje a přijde mi škoda, že dnes se o nich moc neví. Zlatá svatá trojice:
$ ./configure
$ make
$ make install
Jo počáteční bariera je slušná, ale pak se to mnohokrát vyplatí (alespoň pro Cčkaře). Obzvláště make je pak skvělý nástroj skoro pro cokoli (kompilované jazyky samozřejmě) přes TeX, DocBook, octave a vůbec vše co je souborově orientované a je to potřeba postupně rozvíjet a opakovaně kompilovat/spouštět a řešit chyby.
Dobrý den, jako bývalý strojař budu víc používat neformální jazyk, už mi to bylo vytknuto.
Co kdysi bývaly velké počítače, to jsou dnes jednočipy a generovat C kód do jednočipů se vyplatí.
Jazyk M4 byl v té době něco jako K&R DocBook, než ho zahubil Sendmail.
Samotný text tohoto seriálu lze snadno překlopit do libovolného výstupního formátu.
Chystám C, man, XML, ...
Díky za upozornění, je vidět, že nad tím m4sakrem motorovou pilou někdo přemýšlí ;-)
Opravím to ASAP, jakmile mi Petr Krčmář odemkne oba články, těch chyb je tam víc.
~]$ grep -qoP '^(1*01*01*)*1*$' <<< '' && echo 'accept' accept ~]$ grep -qoP '^(1*01*01*)*1*$' <<< '1' && echo 'accept' accept ~]$ grep -qoP '^(1*01*01*)*1*$' <<< '00' && echo 'accept' accept ~]$ grep -qoP '^(1*01*01*)*1*$' <<< '10' && echo 'accept' ~]$ grep -qoP '^(1*01*01*)*1*$' <<< '101' && echo 'accept'
Čas čtení redakční systém sám odhaduje, to tam nikdo nezadává.
On je totiž stavěný na články určené pro weby typu vitalia, lupa, zena, ..., články popisující M4 nerozlišuje.
Jako rychlý bugfix by možná stačilo přihodit jednu nulu.