Co nás ph naučil 2: gsl a zproject

20.12.2016 23:09 | Přečteno: 1856× | Jen tak | | poslední úprava: 21.12.2016 08:26

V předchozím zápisku jsem nastínil CLASS. Nicméně zakládání projektů v C je obtížné, protože je potřeba znát a ovládat spoustu "plumbingu" kolem. Typický C projekt tedy začně jendím souborem, nějakým ručně psaným Makefile a postupně iteruje.

O generování kódu

Pieter generování kódu doporučoval a používal.

5. Learn to use code generators.
I've spoken of GSL before. A general-purpose code generator is an essential tool for a serious programmer. There are a few options. Try them, choose one.
Ten Habits of a Good Programmer

Ovšem generování kódu má obvykle mezi programátory špatnou pověst. Ať vygenerovaný, či ne, kód je kód a bude obsahovat chyby. Opravovat chybu v generátoru bývá těžké. Napojit generátor na build systém je složité. V praxi se tak generování používá u magických věcí jako Google Protocol Buffers, nebo msgpack.

Problém: napojit generátor na build systém je těžké.

Update: mluvím tu o případu, kdy je kód generován v rámci all targetu. To sebou nese nutnost dalších závislostí, takže další řádky v configure.ac, nemožnost experimentovat s vygenerovaným kódem, .... Stejně tak není možné projekt přeložit na vašem malém armu bez věcí jako gsl a zproject. Zproject na to má target code. Ten není součástí hlavního buildu, takže takto generované projekty mají jenom smysluplné závislosti pro sestavení.

Řešení: pokud to není nezbytně nutné, nedělejte to. Člověk, který neumí změnit model a přegenerovat kód stejně není dostatečně kvalifikovaný, aby takové úpravy dělal. A kolegové programátoři budou rádi, pokud budou moci vyenerovaný kód prošpikovat print statementy pro účely ladění.

Problém: výstup je nečitelný, nedá se upravit

Řešení: používejte imatix/gsl. Nebo podobný nástroj.

O GSL

GSL je skriptovací a šablonovací jazyk, který se šablony a modelu vytvoří výstupní dokument. Celé to zní složitě. Ale v zásadě se nejedná o nic jiného, než variantu šablonovacího systému jako je Jinja2 pro Python.

.output "deposits.c"
// Generated by C.gsl, do not edit by hand
#include <stdio.h>

int main () {
.for deposit
    printf ("amount=%d, rate=%d, years=%d\\n", $(amount), $(rate), $(years));
.endfor
}

Šablona zdrojového skriptu vypadá jako kód v jazyce C společně s pár předpisy gsl.

<?xml version="1.0"?>
<deposits script = "C.gsl" >
    <deposit amount = "1000000" rate = "5" years = "20" />
    <deposit amount = "500000" rate = "4" years = "10" />
    <deposit amount = "2500000" rate = "6" years = "15" />
</deposits>

Vstupní model, který gsl zpracovává. Zkoušel jsem přiohnout Jinja2 na něco podobného, protože Python je přeci jenom známějším jazykem, ale gsl je ke svému účelu perfektně postaven. Asi největší výhodou celého tohoto systému je, že je rozdělen na tři navzájem nezávislé části. Skriptovací jazyk/engine gsl, model a potom samotný skript. Díky tomu se s celým systémem velmi dobře "hraje" a zkoumá, co to vlastně dělá. No a měnit šablony je obvykle triviální, protože jde o cílový text a pár značek.

Zproject

Problém: zakládat projekty v C je obtížné.

Řešení: zproject

Zproject je asi největším projektem napsaný v gsl. Jedná se (především) o generátor projektů pro jazyk C (a C++). Vytvořit nový projekt je noční můra každého vývojáře v C. Existují tři způsoby

1. Zkopírovat nějakou autotools šílenost odvedle
2. IDE řeší všechno
3. Cmake, scons, whatever

Problém je v tom, že jenom build systémem to nekončí. Člověk musí znát jak se generují sdílené knihovny, jak umět paralelní build, jak instalovat soubory, jak dělat skripty pro Travis CI, jak generovat dokumentaci, jak spouštět testy, ... A když napíše konečně všechno to Makefile.am/confiure.ac a přežije tisíce volání autoreconf

AC_PREREQ(2.61)
AC_INIT([zyre],[m4_esyscmd([./version.sh zyre])],[zeromq-dev@lists.zeromq.org])
AC_CONFIG_AUX_DIR(config)
AC_CONFIG_MACRO_DIR(config)
AC_CONFIG_HEADERS([src/platform.h])
AM_INIT_AUTOMAKE([subdir-objects tar-ustar foreign])
m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
PV_MAJOR=`echo $PACKAGE_VERSION | cut -d . -f 1`
PV_MINOR=`echo $PACKAGE_VERSION | cut -d . -f 2`
PV_PATCH=`echo $PACKAGE_VERSION | cut -d . -f 3`
AC_DEFINE_UNQUOTED([PACKAGE_VERSION_MAJOR],[$PV_MAJOR],
    [ZYRE major version])
AC_DEFINE_UNQUOTED([PACKAGE_VERSION_MINOR],[$PV_MINOR],
    [ZYRE minor version])
AC_DEFINE_UNQUOTED([PACKAGE_VERSION_PATCH],[$PV_PATCH],
    [ZYRE patchlevel])
AC_SUBST(PACKAGE_VERSION)
LTVER="2:0:1"
AC_SUBST(LTVER)
ZYRE_ORIG_CFLAGS="${CFLAGS:-none}"
AC_PROG_CC
AC_PROG_CC_C99
AM_PROG_CC_C_O
AC_LIBTOOL_WIN32_DLL
AC_PROG_LIBTOOL
AC_PROG_SED
AC_PROG_AWK
PKG_PROG_PKG_CONFIG

... nějaká dobrá duše bude chtít překládat pod Windows, takže nebohý programátor bude zkoumat, jak to napsat v CMake. A popravdě neexistuje žádný podstatný rozdíl mezi autotools a CMake, ani jako mezi rcs a csv.

cmake_minimum_required(VERSION 2.8)
project(zyre)
enable_language(C)
enable_testing()
set(SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
foreach(which MAJOR MINOR PATCH)
    file(STRINGS "${SOURCE_DIR}/include/zyre.h" ZYRE_blah blah
    string(REGEX MATCH "#define ZYRE_VERSION_${which} ([0-9_]+) blah
    if (NOT ZYRE_REGEX_MATCH)
        message(FATAL_ERROR "failed to parse ZYRE_VERSION_ blah blah
    endif()
    set(ZYRE_${which}_VERSION ${CMAKE_MATCH_1})
endforeach(which)
set(ZYRE_VERSION ${ZYRE_MAJOR_VERSION}.${ZYRE_MINOR_VERSION}. blah
include(CheckIncludeFile)
CHECK_INCLUDE_FILE("linux/wireless.h" HAVE_LINUX_WIRELESS_H)
CHECK_INCLUDE_FILE("net/if_media.h" HAVE_NET_IF_MEDIA_H)
include(CheckFunctionExists)
CHECK_FUNCTION_EXISTS("getifaddrs" HAVE_GETIFADDRS)
CHECK_FUNCTION_EXISTS("freeifaddrs" HAVE_FREEIFADDRS)
include(CheckIncludeFiles)
check_include_files("sys/socket.h;net/if.h" HAVE_NET_IF_H)
if (NOT HAVE_NET_IF_H)
    CHECK_INCLUDE_FILE("net/if.h" HAVE_NET_IF_H)
endif()
file(WRITE ${BINARY_DIR}/platform.h.in "
#cmakedefine HAVE_LINUX_WIRELESS_H
#cmakedefine HAVE_NET_IF_H
#cmakedefine HAVE_NET_IF_MEDIA_H
#cmakedefine HAVE_GETIFADDRS
#cmakedefine HAVE_FREEIFADDRS
")
configure_file(${BINARY_DIR}/platform.h.in ${BINARY_DIR}/platform.h)

Zprojekt tedy přichází s řešením, modelem.

Todo je model projektu zyre.

<project
    name = "zyre"
    description = "an open-source framework for proximity-based P2P apps"
    script = "zproject.gsl"
    email = "zeromq-dev@lists.zeromq.org"
    url = "http://github.com/zeromq/zyre"
    repository = "http://github.com/zeromq/zyre"
    >
    <include filename = "license.xml" />
    <version major = "1" minor = "1" patch = "0" />
    <use project = "czmq" />

    <class name = "zyre" />
    <class name = "zyre_event" />
    <class name = "zre_msg" />
    <class name = "zyre_peer" private = "1" />
    <class name = "zyre_group" private = "1" />
    <class name = "zyre_node" private = "1" />
    <model name = "zre_msg" />

    <main name = "perf_local" private = "1" />
    <main name = "perf_remote" private = "1" />
    <main name = "zpinger" />
    <main name = "ztester_beacon" private = "1" />
    <main name = "ztester_gossip" private = "1" />

    <target name = "*" />
    <target name = "nodejs">
        <option name = "version" value = "0.0.6" />
        <option name = "repo" value = "https://github.com/hintjens/zyre-nodejs" />
    </target>

    <constant name = "ZRE_DISCOVERY_PORT" value = "5670">IANA-assigned UDP port for ZRE</constant>
    <constant name = "REAP_INTERVAL" value = "1000" private = "1" >Once per second</constant>
</project>

Na základě modelu zprojekt vygeneruje strukturu projektu, čili adresáře doc, include a src. V doc jsou manuálové stránky generované ze speciálních sekcí ve zdrojových souborech skriptem mkman. Adresář include obsahuje veřejné API, s tím, že projekt.h je hlavním souborem projektu. A v src jsou potom zdrojové kódy, hlavičkové soubory soukromých tríd a další soubory jako pkg-config, konfigurační soubory, anebo systemd předpisy.

Všechen kód ze tříd putuje do sdílené knihovny, v tomto případě libzyre.so.1. Tím je libovolný zproject projekt i sdílenou knihovnou, pokud obsahuje alespoň jednu veřejnou třídu. Zprojekt vygeneruje zároveň i testovací funkce, jako zyre_test. Takže make check spustí testy všech tříd, a make memcheck je spustí pod valgrind, takže se rovnou otestují i případně problémy s pamětí.

V základu zprojekt generuje předpisy pro autotools a CMake. Ovšem je k dispozici hromada skriptů, které umí generovat jiné zajímavé věci.

1. Balíkářské informace (zproject_redhat.gsl) a (zproject_debian).
2. Build systém gyp (zproject_gyp.gsl)
3. Docker file (zproject_docker.gsl
4. Testy pro Travis (zproject_travis.gsl

Draft API

Základ draft API byl položen ve SVatém^WPieterově zápisku The End of Software Versions. Hlavní myšlenkou je, že verze software je jako obvykle umělý konstrukt. Důležité je, které protokoly (standardy) daný program podporuje a v jaké verzi. Autoři prohlížečů to pochopili dávno. Takže dneska se nikdo neptá na aktuální verzi Firefox, nebo Chrome. Zajímavá otázka je jenom - podporuje aktuální verze standard foobar 4.0, nebo ne?

Zproject implementuje contract lifecycle tak, že pomocí konceptu draft API (a méně zajímavého deprecated) umožňuje projektům libovolně rozšiřovat a přídávat nová API s tím, že ta označená jako draft, se ve výchozím stavu nepřeloží.

Celé to potom vede k filozofii dávejte všechno do master větve, takže poslední vydání libzmq a czmq ani nepoužívají release forky, jako tomu bylo v minulosti. Viz Git Branches Considered Harmful, nebo A succesful Git branching model considered harmful

API model

Už jen ve stručnosti, zproject obsahuje i generátory bindingů. Díky tomu, jakje CLASS striktní, tak je možné popsat model API v XML. A později vygenerovat dopovídající binfing. Zajímavostí je nástroj mkapi.py, který z C souborů vytvoří XML model.

       

Komentáře

[Ondrej Santiago Zajicek]

Problém: napojit generátor na build systém je těžké.

Asi tak dva radky do makefile?

[Michal Vyskočil]

Díky, ta formulace je hodně nešťastná. Problém není dát volání gsl to Makefile.am. Problém je, když je tohle součástí all, kde už to tak jednoduché není. Upravím zápisek

[Ondrej Santiago Zajicek]

No, ani ten update me moc nepresvedcil.

mluvím tu o případu, kdy je kód generován v rámci all targetu. To sebou nese nutnost dalších závislostí, takže další řádky v configure.ac, nemožnost experimentovat s vygenerovaným kódem, .... Stejně tak není možné projekt přeložit na vašem malém armu bez věcí jako gsl a zproject.

Ze se kod generuje v ramci all targetu nevylucuje:

1) Moznost distribuovat uzivatelum baliky s predgenerovanym kodem (cimz odpadaji zavislosti a nutnost testu v configure.ac).

2) Mit navic target ktery pouze predgeneruje kod (takze je mozne ho pak pouzit pro pripraveni baliku pro uzivatele ci pro preklad na malem ARMu).

3) Nebrani vyvojarum experimentovat s vygenerovanym kodem (dokud neupdatuji puvodni zdroj, tak make nema duvod pregenerovat generovany kod).

[cxx]

Tyto nastroje co pouzivaji deklarativni pristup failujou uz pri prvnim netrivialnim pozadavku. Nesnasim cmake, ale z tech vsech build systemu mi prisel asi nejvic funkcni - Scons a zejmena GYP jsou moje nocni mura.

[kralyk z abclinuxu]

+1

[Michal Vyskočil]

Model a deklarativní zápis bude vždycky omezenější.

Ad cmake, jak v něm vynutit C99?

[cxx]

prvni odkaz 'cmake c99'

Ja jsem si napsal helper, ktery obsahuje nektere funkce co obcas potrebuju, takze treba:

  function(cxx_detect_cflags out)
    set(out_array ${${out}})

    foreach(flag ${ARGN})
      string(REGEX REPLACE "[-=:;/.]" "_" flag_signature "${flag}")
      check_cxx_compiler_flag(${flag} "__CxxFlag_${flag_signature}")
      if(${__CxxFlag_${flag_signature}})
        list(APPEND out_array "${flag}")
      endif()
    endforeach()

    set(${out} "${out_array}" PARENT_SCOPE)
  endfunction()

  function(cxx_detect_standard out)
    set(out_array)
    cxx_detect_cflags(out_array "-std=c++14" "-std=c++11" "-std=c++0x")

    # Keep only the first flag detected, which keeps the highest version supported.
    if(out_array)
      list(GET out_array 0 out_array)
    endif()

    set(out_array ${${out}} ${out_array})
    set(${out} "${out_array}" PARENT_SCOPE)
  endfunction()

Pouziti jednoduche:

  MY_CFLAGS="..."
  cxx_detect_standard(MY_CFLAGS)
  cxx_detect_cglags(MY_CFLAGS "-fno-keep-static-consts")

Nerikam, ze to je super reseni a ze by to neslo deklarativne, ale ... Muj nejvetsi problem s cmake je ten idiotsky jazyk, ktery nema ani 'return'.

[deda.jabko]

Tyto nastroje co pouzivaji deklarativni pristup failujou uz pri prvnim netrivialnim pozadavku.

Scons a zejmena GYP jsou moje nocni mura.

Trochu rozpor, ne? GYP neznam, ale se SCons, kdyz potrebujes neco netrivialniho, prejdes do normalniho proceduralniho programovani a mas po problemu. Ve srovnani s tim mi prisly make+autotools jako generator problemu.

[cxx]

To je jako bych citoval

GYP, SCons, mi prisly jako generator problemu

Scons je mrtvy

[pavlix]

Mě osobně přijde, že se cmake snaží být za každou cenu jiný, takže se mi s jeho pomocí autotools velmi špatně nahrazují, i když o nich nemám žádné iluze.

[dumblob]

Díky za zápisek. Donutil mě znovu se zamyslet nad tím, zdali historický vývoj využívání modelování v IT (čehokoliv) nemá něco do sebe (historicky je většina modelování považována za ztrátu času).

Modelování se v širokém spektru odvětví IT používá velice málo (dle mých subjektivních měřítek přepočtených na procentuální zastoupení modelování ve všech člověkoměsících všech IT pracovníků celosvětově). Zabývám se již mnoho let modelováním na úrovni nikoliv pouze tvorby modelů modelů (tedy technik a vizuální reprezentace budoucích modelů; dále budu používat pouze pojem metamodel), nýbrž zjišťování, pro které případy v IT má modelování smysl a kdy ne.

Ukazuje se, že je tato otázka extrémně složitě zodpověditelná i pro jednoduché projektíky s malým počtem člověkohodin. Dokonce je dle mých pozorování její zodpovězení výrazně složitější než např. výběr vhodného programovacího jazyka či obdobně zásadní technologie (frameworku, nástroje, prostředí, klíčového systému, DB, atd.) pro velké projekty (táhnoucí se např. desítky let).

Řešení, které ohledně metamodelů vnímám je, že metamodel nesmí být omezený pouze na podmnožinu možností, které metamodel nabízí, nýbrž musí nutně poskytovat i "únik" z metamodelu pro případy, které do metamodelu nezapadají, avšak pro daný projekt jsou minimálně tak důležité jako stávající součásti modelu (toto se navíc mění v čase). Jinými slovy, metamodel (včetně jeho implementace v podobě modelovacího jazyka/nástroje/vizuální_reprezentace/...) musí splňovat následující dvě podmínky:

1. Musí být minimálně jednosměrně neodlučitelně spojený s výslednou implementací.
   1. Tzn. buď alespoň generuje finální aplikaci, která se poté již nedebuguje, netestuje funkčními/unit a jinými "systémovými" testy (protože veškeré testování probíhalo nad modelem před generováním; samozřejmě se předpokládá plná korektnost generátoru). Přičemž tuto finální aplikaci není možné převést zpětně na model.
   2. Nebo je model ekvivalentem parametrizované implementace - je tedy obousměrně spojený s implementací a za předpokladu znalosti parametrů dané implementace je tedy možné zpětně automatizovaně sestavit stejný model z dané implementace. Čehož se využívá při úpravách, debugování apod. (všimněme si, že zde debugování a testování může probíhat jak nad modelem, tak nad finální aplikací, což je obrovská výhoda).
   Druhý bod se dle mně dostupných informací vyskytuje pouze u vysoce teoretických (často matematických) a malilinkatých (dle metriky minimální reprezentace algoritmu) projektíků (projekty typu MPS [2] se snaží o další rozšíření pro tyto malinkaté use-cases). Ve většině ostatních nasazení se tedy používá jednosměrné generování, a sice pouze malinkatých částí aplikace (např. injection v Java *beans, různé FSM, tabulky, apod.).
2. Má plně integrovanou (nikoliv "dobastlenou") podporu pro neomezené zacházení s čímkoliv, s čím se v modelu nepočítalo (často cíleně, protože od modelu chceme, aby byl vhodným zjednodušením reality). Jinými slovy, model od samého začátku má zabudovanou a plně integrovanou podporu (tedy neodlučitelnou, avšak např. volitelně zakázatelnou či alespoň detekovatelnou pro účely verifikace) pro turingovsky kompletní výpočty.

V tomto světle GSL dle mého názoru stále selhává, a proto si kladu otázku, proč bych např. měl nahradit Premake (který je maliličkatý, bez závislostí, plně multiplatformní, pseudo-deklarativní, srozumitelný, vizuálně atraktivní - tedy vysoce čitelný s minimálním množstvím textu a podporuje v článku uvedené požadavky na CI apod.) něčím jako GSL (které minimálně v druhém bodě selhává - integrace je neexistující či "dobastlená")?

Mimochodem, velice blízko této oblasti "sestavování, testování a nasazování aplikací", avšak naopak téměř plně bez použití jakéhokoliv modelu lze použít pro sestavování aplikací Ekam, který plně automatizovaně (bez počáteční uživatelské konfigurace a bez uživatelské intervence) a v reálném čase (jak přibývá programátorův/architektův kód/popis_aplikace) generuje, testuje a popř. i nasazuje danou aplikaci.

[Michal Vyskočil]

Pozor, premake je ekvivalent některých skriptů ze zproject. Gsl je obecný nástroj na generování souborů. Například zproto je projekt, který má modely pro binární kodeky a stavový diagram pro klient a server. Takové google protocol buffer pro zeromq.

Neříkám, že se tohle všechno nedá do premake dostat, ale za mě vedou gsl skripty tím, že je obvykle snadné je ručně upravit.

[kralyk z abclinuxu]

Když jsem posledně něco takového potřeboval, použil jsem python + Mako. Mako má svoje záludnosti, ale s obecným pythonem se integruje velmi snadno a zatím nevím o lepším řešení. Nepřijde mi, že GSL by bylo zlepšením, XML data a DSL skriptovací jazyk ve mě úplně nadšení nevyvolávají...

[Michal Vyskočil]

Tak já bych byl všemi za python, nebo alespoň lua, ruby, nebo perl. Ale to bych musel zproject psát bez komunity sám a zase tolik zábavný projekt to není

[kralyk z abclinuxu]

Věřím, že ph byl skvělý programátor, ale nemám úplně rád tenhle přístup, kdy někdo vydá seznam pravidel a pouček a prohlásí je za svaté. Co se týče zproject, připadá mi, že bych tím jen vyměnil problémy s cmake/autotools/whatever za problémy se zproject...

[Mirda]

problémy s cmake/autotools/whatever za problémy se zproject...

jo. Sem ze stare skoly a proto mam radu problemu s temito 'pomuckami'. Napr. predevcirem jsem chtel rozchodit na centos5 nejnovejsi podofo paket. (protoze jsem vubec necekal, ze bude na epelu existovat startsi verze jako rpm-ko). Nejdrive jsemm si musel nainstalovat cmake28 (cmake nestacil) a pak to hlasilo, ze konfigurace se nepovedla protoze ....

Takze jsem jeste zkusil centos6 a zase jine hlasky. Musim rict, ze to jsem fakt necekal, tyhle systemy musi byt preci naprosto blbovzdorne, jestlize podle navodu odsadim ty prikazy a ono to nefunguje a ani nerekne, co mam delat, tak to by bylo lepsi predat seznam tech zdojaku a clovek si to prelozi sam.

Fakt hruza.

[Ondrej Santiago Zajicek]

Co se týče zproject, připadá mi, že bych tím jen vyměnil problémy s cmake/autotools/whatever za problémy se zproject

Ja mam pocit, ze to ma tento vyvoj:

1) Programator chce programovat, ale moc nezna make.

2) Pouzije automake, zkopiruje nekde par sablon, a ve vysledku tam ma make a automake, kterym obema moc nerozumi.

3) V dalsi fazi tam prida zproject, takze ve vysledku tam bude make, automake a zprojekt, pricemz ten programator kloudne nezna ani jedno z toho.

4) Pokud by chtel pridat nejakou neobvyklou vlastnost, tak bude muset vyresit v zproject, aby to generovalo spravne predpisy pro automake, aby ten generoval spravne predpisy pro make, takze to radsi vzda.

5) V konecnem dusledky by asi udelal lip, kdyby si rovnou precetl manual ke GNU make a napsal to primo v tom.

[Michal Vyskočil]

4) Pokud by chtel pridat nejakou neobvyklou vlastnost, tak bude muset vyresit v zproject, aby to generovalo spravne predpisy pro automake, aby ten generoval spravne predpisy pro make, takze to radsi vzda.

Lepší postup je šťouchat do autotools tak dlouho, až dělají to, co potřebuji. A potom výsledek nakopírovat do zproject a nahradit konkrétní jména za $(proměnné). Pak napsat make code pro finální test skriptu a udělat pull request.

5) V konecnem dusledky by asi udelal lip, kdyby si rovnou precetl manual ke GNU make a napsal to primo v tom.

Akorát při použití zproject má člověk rovnou strukturu projektu (include/, src/, doc/), viditelnost symbolů, správně vyřešené závislosti na dalších knihovnách, podporu unit testů, podporu code coverage, callgrind a valgrind, automatické generování dokumentace, verzování ABI i API, ... a to mluvím jenom o ekvivalentu GNU make předpisu.

Jinak je podpora pro docker file, Travis testy, balíkářské informace pro Debian, RedHat, bindingy pro Javu, Python, Lua, Ruby, NodeJS a Qt/QML, build předpis pro Visual Studio a jiné.

[deda.jabko]

Ovšem generování kódu má obvykle mezi programátory špatnou pověst. Ať vygenerovaný, či ne, kód je kód a bude obsahovat chyby. Opravovat chybu v generátoru bývá těžké. Napojit generátor na build systém je složité. V praxi se tak generování používá u magických věcí jako Google Protocol Buffers, nebo msgpack.

Nad timto se musi nejeden lispar pousmat. ;-]

[kralyk z abclinuxu]

To dává smysl - nevšiml jsem si, že by kromě posměšků nad ostatnímy jazyky produkovali lispaři někdy něco jiného.

(Výjimkou jsou autoři Clojure, těm se podařil malý zázrak - vytvořit variantu lispu, která je skutečně používaná v praxi...)

[deda.jabko]

To dává smysl - nevšiml jsem si, že by kromě posměšků nad ostatnímy jazyky produkovali lispaři někdy něco jiného.

Asi jsi malo vsimavy. Kazdopadne tech 50+ let posmesku ma neco do sebe a uz zacina sklizet ovoce.

Staci se podivat, jak vypadaly mainstreamove jazyky na prelomu tisicileti, kdy for-cyklus byl pomalu nejslozitejsi konstrukt, a jak vypadaji jazyky dnes, ... ta mas samou lambdu, map, line vyhodnocovane kolekce, atd. Mozna se casem dobereme toho, ze se rozumne pouzitelna makra (generatory kodu) stanou integralni soucasti jazyka a metod vyvoje a nebude to budit takove pozdvizeni, jako kdyz nekdo z XML generuje kod v cecku.

[kralyk z abclinuxu]

No jistě, když už není lisp úspěšný, tak se aspoň řekne, že úspěchy ostatních jazyků jsou stejně jen díky lispu atd. atd.

Škoda, že nedostávám dolar vždy, když se někdo nechá osvítit moudrostí lispu, což se projevuje zejména lezením po fórech a trousením těchto osvícených mouder do diskusí o v praxi používaných jazycích...

[Odin1918]

trousením těchto osvícených mouder do diskusí

Ty snad delas neco jineho? Nedelas. Delas to same a dukazem toho jsou i prispevky v diskusi pod timto blogpostem.

[kralyk z abclinuxu]

Máš pravdu, taky to dělám. Koneckonců ábíčko je od trousení mouder, že Nicméně v téhle diskusi jsem se snažil poradit Mako. Nevidím se autorovi zápisku, že měl špatnou zkušenost s Jinja, právě proto jsem zmínil to Mako, páč se na tyhle účely snáz ohýbá než Jinja (alespoň taková byla moje zkušenost). Přijde mi to jako celkem konstruktivní, ačkoli jsem to asi mohl líp napsat / zdůvodnit.

A pak přijde lispovej osvícenec a řekne ti, že tvoje snaha generovat kód pro C je úsměvná a že lisp měl makra už v rove 1523 a tyhlety řeči :-/

[Radovan]

Informovaní četli "Revenge of nerds".

Inteligentní ho pochopili

[Michal Vyskočil]

Jak to vidím já, tak generování autotools souborů je podobně populární

[pavlix]

Mimochodem jsem zkoušel jinja2 a chová se to jako strašný bullshit. Jednak to bez nějakého speciálního whitespace modulu nezvládá správě ani opakovat řádky (for cyklus), jednak to i nakonci souboru za různých okolností buď sežere nebo nesežere konec řádku, ačkoliv je na posledním řádku jenom text, žádné šablonové prvky. To jen takový námět k diskuzi. Zkušel jsem Mako a to fungovalo od prvního pokusu bez problémů.