Názory k článku
Základní konstrukce v programovacím jazyku Lua

Protože se v tom dobře dělá.

Tak nam prozrad skrze ktery jazyk dojdeme ku spase a na jehoz oltar musime polozit obetinu. Ooo ved nas mocny Trm z temnot do svetla!

Jasne od chvile vzniku Lispu se tvurci dyn. jazyku snazi o jedine - udelat neco stejne mocneho jako Lisp, ovsem s vlastni syntaxi. Mnoha lidem celkem logicky pripada podivne primo zapisovat derivacni stromy, to ma byt zalezitosti prekladace :-)

Je to nesmírně malý, pružný a rychlý dynamický jazyk. Je rychlejší než Per, Python, Ruby nebo PHP (naopak už nestíhá v souboji s některými LISPy, Erlangy či jazykem Scala).

Tohle je spíš ukázka vaší blbosti, než toho, že imperativní/funkcionální přístup je špatný. Špatný není a jestli narážíte na to, že Lua není OOJ, tak vězte, že jím umí být.

http://shootout.alioth.debian.org

Muzu se zeptat, co myslite tim, ze je to "rychly" jazyk?

Nechci se hadat, jestli je to dobry nebo spatny jazyk.
Kazdopadne pokud se rychlosti mysli rychlost vysledneho programu, tak to dost zalezi na interpretru. Pokud tim myslite rychlost vyvoje, tak mi prijde, ze by bylo lepsi pouzit jazyk, na jehoz syntax je clovek zvykly.

Zvyknout si na syntaxi nějakého jazyka je otázka chvilky. Hm... teda pokud to není jazyk příliš složitý, jako například Perl -- there is more ways to do it -- takže pochopit, co myslel programátor, který je narozdíl ode mne zná všechny včetně různých drobných nuancí, je trochu problém... Anebo pokud to není jazyk příliš jednoduchý (jako např. LISP, všechno je funkce a teď to jenom správně poskládat a dopočítat závorky...(jasně, že trochu zjednodušuju a přeháním))

Spíš dá víc práce si zvyknout na standardní knihovny toho jazyka -- a co jsem se díval, Lua jich v základu moc nemá -- je tam práce s vlastními strukturami (stringy, tables, moduly), matematické funcke, základní I/O a operace OS. Takže se dá naučit celkem rychle. Někdo by mohl namítat, že je to nevýhoda a že pak je lepší použít například Python, Perl nebo Javu (a v mnoha případech by to byla správná volba), ale určitě je dobré mít i malý skriptovací jazyk, jako je Lua, který se dá s minimální režií začlenit do projektu v C. (Minimální runtime Pythonu je někde jinde, Javu v této souvislosti raději ani nezmiňovat). Kde je jádro funkcionality napsáno v C a je potřeba nad tím postavit nějakou flexibilní aplikaci je to určitě horký kandidát -- rychlé základní stavební kameny (funkce napsané v C) spolu s rychlým interpretem znamenají celkově rychlou aplikaci -- a asi taky proto je Lua začleněna v několika počítačových hrách...

Takže ta rychlost znamená spíš rychlost běhu než rychlost vývoje.

Ano, filozofií tvůrců jazyka Lua bylo vytvořit minimalistický (ale stále snadno použitelný) jazyk s co nejjednodušším API pro céčkové programátory a pouze základními knihovnami. Je tomu tak z toho důvodu, aby se překladač i interpret dal přeložit na prakticky jakékoli platformě, kde je ANSI C pouze se základními knihovnami.

Jestli je tento minimalistický přístup lepší než "vše v jednom" (například Java EE), asi záleží na subjektivních pocitech. Mě osobně to docela vyhovuje, aspoň mám pocit, že je vše pod kontrolou a skriptovací engine v mé aplikaci postavený na Lua nebude volat třeba funkce jádra, nebude vytvářet další procesy atd.)

Další knihovny a moduly lze stáhnout například z http://luaforge.net/ , jde o takový pokus o CPAN :-)

Luaforge mnohem víc vypadá jako Rubyforge než jako CPAN (nejen názvem, i vzhledem ;-)).

Syntaxe (a hlavně sémantika) se dá zvládnout přinejhorším za pár dnů a stejně - v praxi si málokdo vystačí s jedním jazykem (=syntaxí), většinou se i v jedné aplikaci přepíná mezi více či méně rozlišnými syntaxemi (mezi jazyky počítám i shell, SQL apod.) a myslím že to není zas tak velký problém. Na druhou stranu například takové céčko a JavaScript se sice syntakticky přibližují, ale sémantika i základ jazyků je dosti odlišný (slabý typový systém vs dynamické typování, first class funkce atd.).

Scala není dynamický jazyk, na to pozor. Co se týče snadnosti programování, dá se ale s dynamickými jazyky docela srovnávat.

co konkretne sa ti nepaci? alebo budes len p***at na jazyk bez konstruktivnej kritiky?
je prijemne povedat ze tak, ako vyzeras ty, by clovek nikdy nemal vyzerat?

Zvlastni, zacinam mit z toho prispevku dojem, ze vlastne existuje pouze jeden pravy (R) a na vse vhodny (TM) programovaci jazyk, ostatni jen smutne prihlizeji.

pan je tedy mocny hacker, ktery se s nejakymi usmrkanci nebude zahazovat, hmm, pravy clovek pro tymovy vyvoj... (vlastne ano, on zvladne sam to, co cely vyvojovy tym).

V podstate jo.

Jsou dve skupiny vyvojovych tymu. Borci, co si hraji na IT, nechci vas urazit, ale zrejme lidi jako Vy. Pro ne jsou samozrejme nejlepsi Java, C++, hodne UML, teamove prace a bajecne brainstormingy s koblihou a kafem. To je jiste bajo moralni a dusevni zazemi pro to, jak ze zakopat v zaprdene firmicce.

Pak jsou tu takovi ti machri, co zakladaji uspesne startupy a delaji velke veci v malem poctu lidi. Delaji v jazycich, co maji swunk (treba LISP), analyza = experimentalni implementace, a vydelavaj baliky penez, kdyz to pak nekomu streli. ;-)

Máš/máte na mysli asi Paula Grahama - to je pravda, on startupy umí zakládat, nejsou to většinou žádné bubliny, odvedou a prodají dobrou práci. Na druhou stranu mnoho startupů začínalo třeba v Pythonu (a po zakoupení větší firmou se to přepsalo třeba do céčka :-) a dalších jazycích.

Ona Lua na první pohled (= první dvě části seriálu) vypadá vedle Lispu strašně staticky (něco jako Plácal), ale ve skutečnosti to není tak hrozné, viz třeba http://en.wikibooks.org/wiki/Lua_Functional_Programming. Ano, syntaxi jako takovou není možné měnit (=javascript), ani Lisp-like makra zde tím pádem nejdou udělat, ale v dalších fíčurách je to +- srovnatelné - konstruktory dynamických datových struktur, práce s nimi, iterátory atd.

No a když je nejůř, tak může pomoci LuaLisp (http://blog.davber.com/2006/09/07/embedded-lisp-via-lua/), ale i samotné vyhodnocování funkcí uložených v asociativním poli je také snadné.

"Ano, syntaxi jako takovou není možné měnit (=javascript), ani Lisp-like makra zde tím pádem nejdou udělat"

Já nevím, ale MetaLua mi prokazatelně funguje. :]

Sorry ale ty si blb.

Dokonaly priklad toho, proc jazyk nic neresi, je Cadence Virtuoso. Pouzity skriptovaci jazyk je SKILL (derivat/dialekt LISPu). Zatim dobry. Jenze kdyz zjistite, ze obcas dynamic scoping muze zpusobovat vzajemne prepisovani struktur (pripad 'disembodied lists') a funkce pristupujici k ruznym strukturam vraceji ruzne seznamy jen ne ty LISPove, je vam sila LISPu na dve veci.

Dostavate vetsinou "opaque" struktury a i kdyz jsou to seznamy, kazda struktura ma specialni zpusob (nekolik funkci), jak z ni vydolovat nejaky prvek (kazdou blbost treba nejprve manualne prevest na LISPovsky list). Jasne, je to vec implementace, ale ukazje proc LISP nemusi byt vzdy tim nejlepsim kandidatem.

Ad "pan jazyk": lambda kalkul byl pred LISPem, ted mame vsechno delat v lambda kalkulu? Taky proveren radou let...

ad posledni odstavec: z hlediska vycislitelnosti je na tom lambda kalkul v podstate stejne jako Turinguv stroj, takze se da programovat i v nem :-)

Jo a implementace TS ve forme programovaciho jazyka samozrejme existuje, jmenuje se Brainfuck a jeho interpreter se vleze do jednoho sektoru pevneho disku :-) takze zde mame jazyk ekvivalentni k Lispu...

S tim lambda kalkulem to byla spis hyperbola ;-) (z hlediska vycislitelnosti jsou bezne pouzivane jazyky TS-ekvivalenti). Jinak Brainfuck by rozhodne az tak moc neubral na pouzitelnosti kdyby byl pouzil misto SKILLu :-D

Sorry, ale tyhle argumenty neberu. Za prve, dynamic scope se ma pouzivat jen s mirou a Common LISP (coz je jediny spravny LISP) pouziva lexical scope. Dynamicke promenne jsou fajn, ale jen na nektere veci a s mirou. Naopak, pokud je jazyk nema, nektere veci nejdou udelat bez hacku. S tim lambda-kalkulem to je takova plana teorie. Predne, LISP jako takovy s nim nema nic spolecneho, kdyz nepocitam nazev jednoho specialniho operatoru. Pripodobnovat LISP k lambda-kalkulu a jeho ,,prakticnost'' je asi takove, jako pripodobnovat RAM-stroj k Cecku. Sami asi citite, kde tohle prirovnani je.

No predsta jediny spravny jazyk je LabVIEW - graficky a dataflow

Napis v tom maly resic pro 2D/3D nevazke stacitelne proudeni ;)

V com sa taketo veci zvyknu robievat?

IMHO napriklad prave v Lua?

Sa pytas alebo odpovedas?

:-)

v podstate oboje :-)

MarSik u predchoziho dilu psal, ze se podobne simulace v Lua pisou (http://www.root.cz/clanky/programovaci-jazyk-lua/nazory/258335/), ale vzhledem k tomu ze neznam podrobnosti (krome toho, co rekne strejda Google), tak cekam, ze nekdo napise treba o jaky projekt konkretne se jedna, jak jsou ty simulace reseny (asi pres coroutiny) atd.

V drtive vetsine ve fortranu, ale taky v cecku a c++. Jazyk LUA by urcite nasel vyhodne vyuziti... jsem zvedavej na nejakou ukazku te masivni paralelizace:).

Toto je typická ukázka toho, jak by příspěvek v diskusi neměl vypadat. Proč ho proboha někdo napsal? Máš-li co konkrétního - napiš to!

Připomíná mi to dost ofp script
(kdo dělal scripty pro operation flashpoint, bude vedět)

Podle vseho je ofp script prave (plnohodnotna) Lua, takze spravny postreh.

No to těžko :-). Přeci jen o tom vím trochu víc.

Lua je na jedné straně super jazyk - dá se krásně a rychle integrovat do aplikace; jeho jedinou slabinou je prasácky napsaný kód interpretru (jednopísmenné identifikátory, hromady provázaných maker) - debugovat v něm je opravdu jen pro silnější povahy a trochu si jazyk rozšířit (nejen přidáním funkcí a tříd) byl problém.

Kdysi jsem se na tento jazyk díval, a to hlavně proto, že se dá opravdu VELMI těsně spojit s C zdrojákem. V C si napíšu api pro knihovny (kterých je pro C opravdu více, než pro třeba ruby, se kterým si hraju teď) a v LUE napíšu obslužný kód (ve kterém svyvíjí rychleji, než v čistém céčku, navíc se tak dají udělat různé pluginy, skripty, atd.. (využívají různé hry, třeba warcraft 3)). A spoustu syntaxe se od mého oblíbeného ruby až tak neodlišuje. V ruby se vyvíjí skvěle, ale než jsem rozchodil knihovny cairo (s podporou importu SVG) / SDL (rcairo, ruby-sdl), tak jak jsem potřeboval, tak jsem se hezky potrápil - používám jinak v C. Takže mockrát děkuji za článek, o tomhle totiž česky pořádně nic moc nebylo a je to škoda, tak jsem na něco takového doufal. A váš článek je opravdu kvalitní a těším se na pokračování.

Nemělo by v té části 7 být "until a > n"?

Hmm, v původním skriptu to mám dobře, takže chyba musela nastat při převodu do HTML :-( Díky moc za upozornění, opravíme to.

Chápu to správně, že kód napsaný v Lua počítá vždy jenom s jedním číselným typem (buďto plovoucí čárka, NEBO celá čísla)? Pokud ano, nedovedu si v takovém jazyce představit rozumné programování větších aplikací. Chápu, že u některých nasazení to nemusí vadit (J2ME koneckonců Sun taky vydal s podporou pouze celých čísel), ale obecně to vnímám jako zásadní handicap.

Pokud si stáhneš zdrojáky Lua a přeložíš je bez změny hlavičkových souborů, jsou všechna čísla uložena ve formátu double (IEEE, double precision, tj. 64 bitů). Jednoduše se to dá změnit například na 16 či 32 bitové integery, což se dost často využívá v případěch, že Lua (resp. skripty přeložené do bajtkódu) mají běžet na mikrořadičích - což je trošku podobný cíl jako v případě zmíněného J2ME).

Samozřejmě ne vždy dostačuje přesnost či rozsah double, potom lze použít například knihovnu BC (http://www.gammon.com.au/forum/?id=7747) nebo (v případě, že se mají použít dlouhé integery) v luaconf.h změnit datový typ za long long int nebo si stáhnout patch z http://lua-users.org/wiki/LuaPowerPatches.

Další knihovny pro arbitrary precision, numerickou matematiku, komplexní čísla atd.:
http://luaforge.net/projects/ldecnumber/
http://numlua.luaforge.net/
http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/
http://members.chello.nl/~w.couwenberg/ (zde hledat LGMP), zde je další info: http://members.chello.nl/~w.couwenberg/lgmp.htm - problém může být, že se prozatím nepatchovala i syntaxe, takže se používá "objektový" způsob volání
http://lua-users.org/wiki/LuaMatrix (vektory, matice)

Díky za obsáhlou odpověď. Určitě by se mi líbil nějaký příklad v nějakém dalším díle (jak je to s konverzemi, operátory atd.), ale asi na to stejně mrknu sám. Ne tedy, že bych se v nejbližší pětiletce chystal používat tento jazyk (v současné době mě to táhne spíš směrem na Haskell, Erlang, různé varianty ML apod.), ale programovací jazyky mě obecně zajímají.

Mne sa osobne Lua páčí je velmi podobna Pascalu. problem je ze ma mensie nedostatky ktore vyplivaju s jej jedonuchosti. skoda ze lua nie je viac orientovana ako scriptovaci jazyk ako je bash.

Zdravim. Pokud si nechcete Luu sam prelozit, muzu poskytnout jak vlastnorucne prelozene DLLko, tak i hotovy prekladac luac.exe i prekladac+interpretr lua.exe. Ma to cele jen par desitek kilobajtu.