Newsgroup: it.comp.software.tex
Titolo: A proposito di Tikz

Ho letto di persone che si sono dette impressionate dalla flessibilità e 
potenza di Tikz. Io invece, che programmo da una vita (asm, C, C++ 
(spec. template), lisp, scheme, ruby, OZ, ecc...) non sono per niente 
impressionato. Anzi...
IMHO, TeX andrebbe "soppresso" e ricostruito da zero. Tikz è un 
pacchetto di macro per TeX e di conseguenza è irregolare, poco 
flessibile e lento. Quando uno strumento è inadeguato si cambia lo 
strumento, non ci si adatta. Questa è la mia filosofia. Non a caso molti 
ex programmatori di C++ sono impazziti per Ruby.
Il C++ fu creato in quel modo perché doveva essere compatibile con il 
linguaggio C, quindi per un motivo commerciale, ma pensavo che in ambito 
accademico ci fosse più buon senso.
Kiuhnm

Kiuhnm scrive:

Ti metti tu a rifare TeX da zero? :-)
Se vuoi uno strumento per la grafica che assomigli a C++ c'è
Asymptote: 
http://asymptote.sourceforge.net
Ciao
Enrico

 Ti metti tu a rifare TeX da zero? :-)
tikz/pstricks etc sono talora irritanti ma non possono che essere
cosi', su questo concordo con l'OP, e chiedo a chi ne sa come luatex
si inserisca in questo quadro --- rimarra' tutto sommato ristretto al
filone context? coinvolgera' il piu vasto ambito latexaro? non e'
quello che ci serve?
                                                                g
-- 
Mangiate pure le vostre carote, noi mangeremo le nostre salsicce!
                                                   -- Claud,   in IHC

 Ti metti tu a rifare TeX da zero? :-)
Da solo e gratuitamente? :-)
Per decenni il C è stato usato come back-end perché c'erano già 
compilatori molto ottimizzati e sofisticati.
Lo stesso si potrebbe fare con TeX.
Si potrebbe benissimo creare un linguaggio che si appoggiasse a TeX per 
poi, eventualmente, staccarsene.
L'importante è smettere di aggiungere pacchetti a TeX e di stabilire un 
linguaggio ufficiale da usare per i nuovi pacchetti!
Ma che m'importa. Tanto sono solo di passaggio e ho già le mie crociate 
da combattere :-)
Kiuhnm

da combattere :-)
Non di meno, se sei veramente interessato alla cosa, puoi dare un'occhiata
a Lout e al progetto Nonpareil.
Ciao.

 codice attuale, senza duplicare esattamente TeX.
Mi spieghi che senso avrebbe costruire un compilatore TeX se il 
back-bone del sistema è TeX stesso?
Mi stai praticamente dicendo che non si può fare proprio quello che il 
metodo (del tutto ovvio) che suggerisco permette di evitare di dover fare.
Kiuhnm

metodo (del tutto ovvio) che suggerisco permette di evitare di dover fare.
E che senso ha costruire un front-end per TeX, se il problema è proprio
superare TeX?
Se fai tanto di definire un linguaggio tipografico nuovo, perché dovresti
volerlo impestare con un linguaggio macro come TeX?
Non è particolarmente "ovvio" (la convivenza con un linguaggio macro è
comunque difficile; non è, in generale, qualcosa che si possa incapsulare
in modo invisibile a livello del linguaggio ospite), non ha un grande
interesse per gli utenti di TeX (il cui problema è mantenere il codice
esiste), e non è a mio avviso particolarmente conveniente, rispetto all'uso
di altri motori tipografici, o alla costruzione di un motore tipografico ad
hoc.
Ripeto: sistemi tipografici che funzionano come front-end per TeX ce ne
sono già (OpenJade ha un back-end LaTeX, Lyx si appoggia a LaTeX...), hanno
un loro limitato uso e un certo numero di estimatori, ma non sono quella
panacea che si potrebbe pensare. 
Un "linguaggio che si appoggiasse a TeX per poi, eventualmente,
staccarsene" non è un modo indolore per portare gli utenti di TeX ad un
altro sistema, non è un modo per fare evolvere TeX... è, per come la vedo
io, qualcosa di molto simile ad un vicolo cieco.
Se invece ti interessa un esempio di linguaggio tipografico del tutto
alternativo a TeX, l'approccio di Lout (che pure ha i propri, diversi,
limiti) è sicuramente interessante. Nonpareil, che è, al momento attuale,
poco più di un nome, promette però di essere anche più interessante.
Ciao.

 superare TeX?
E che senso ha costruire un front-end per il linguaggio macchina se il 
problema è proprio superare il linguaggio macchina?
Kiuhnm

 poco più di un nome, promette però di essere anche più interessante.
Senza entrare nella polemica, mi permettevo solo di segnalare che per alcuni
tipi di utilizzatori, come noi linguisti e filologi, (La)TeX ha al momento
pochi rivali, se non Xpress. Lout non conosce(va) Unicode, mentre Nonpareil
promette di supportarlo.
L'``attrezzatura'' linguistica di LaTeX è ormai di altissimo livello; è
difficile, per me, al momento pensare ad una seria alternativa. In futuro,
chissà. Quanto alla modularità, packages ecc., in fondo deriva dalla
mentalità Unix: carica solo quello che ti serve volta per volta.
Buon lavoro,
guido
-- 
http://docenti.unicatt.it/milanese_guido
 
http://www.arsantiqua.org

problema è proprio superare il linguaggio macchina?
L'analogia è del tutto insensata, come ho tentato di spiegare:
continui ad ignorare la natura di TeX, che è quella di un linguaggio
macro.
Non è possibile instaurare fra un ipotetico linguaggio ospite e TeX il
rapporto che c'è fra un linguaggio di programmazione e l'assembler o
il linguaggio macchina, perché un linguaggio macro introduce una marea
di effetti collaterali (in realtà, gli effetti collaterali SONO il
linguaggio macro), che rende impossibile isolare un frammento di
codice macro e fargli fare sempre la stessa cosa. Se sotto c'è TeX, in
ogni caso verrà fuori qualcosa di altrettanto bizzoso e imprevedibile.
Di più, che cosa useresti di TeX? Plain TeX è già impestato di suo,
LaTeX non ne parliamo... restano giusto le funzioni di basso livello
di TeX, che però non sono di per sé molto interessanti.
Il vero valore aggiunto di TeX sta proprio nell'enorme quantità di
codice prodotto, negli innumerevoli pacchetti LaTeX... cioè proprio in
quello che non potresti più utilizzare. Il resto, il motore
tipografico vero e proprio, sarebbe molto più produttivo duplicarlo in
qualche forma più coerente con il linguaggio ospite.
Ma veramente c'è qualcosa di più convincente delle mie argomentazioni:
l'idea non è affatto nuova, è già stata tentata, e non ha prodotto
risultati rivoluzionari.
Ciao.

 macro.
Il che è totalmente irrilevante e mi fa sospettare che tu non abbia 
proprio capito cosa propongo di fare.
Ti faccio due esempi al volo:
 >>>
#string[] anag(string s)
{
   ...
   return list_of_anagrams;
}
#string intercat(string[] list, string separator)
{
   string s;
   for (l in list)
     s += l + separator;
   s.removelast;
   return s;
}
Gli anagramma della parola \emph{carro} sono:
#intercat(anag("callo"), ", ").
% NOTA: il punto finale non fa parte del gruppo '#'.
--------
Adesso immagina di avere caricato il pacchetto Tikz e di voler disegnare 
la Z-curve o la curva di Hilbert:
#point[] zcurve(int steps, box b)
{
   if (steps > 0)
     return ... zcurve(...)...
   else
     return ...
}
string(point p) = "(" + string(p.x) + "," + string(p.y) + ")";
#steps = ...
% codice tikz
...
\draw #intercat(zcurve(steps, {(0,0),(1,1)}), "--");
% NOTA: il punto e virgola finale non fa parte del gruppo '#'.
--------
Come vedi, il linguaggio di programmazione serve a generare codice 
(La)TeX senza appoggiarsi alle macro (ma nessuno lo vieta).
E' facile reimplementare Tikz stesso in questo modo. Nell'esempio mi 
sono appoggiato a tikz tanto per rendere l'idea.
La potenza di un sistema non si può giudicare dal solo output: bisogna 
conoscere anche l'input. (La)TeX non è insoddisfacente perché l'output è 
inadeguato. E' insoddisfacente perché la produzione di un determinato 
output richiede input alquanto complicato e tedioso da scrivere. E' la 
stessa identica cosa che avviene con l'assembly (NOTA: l'assembler è 
l'assemblatore, non il linguaggio).
Kiuhnm

l'assemblatore, non il linguaggio).
(La)TeX è insoddisfacente perché è più bizzoso di un cammello ubriaco,
perché non si è in grado di prevedere che cosa produrrà un certo input, se
una macro sarà compatibile con un'altra, se una piccola modifica in un
punto non produrrà un effetto generale in altri che dovrebbero essere
teoricamente non correlati... (La)TeX è insoddisfacente perché è un
linguaggio macro.
L'analogia con l'assembler (e chiamalo pure anche "Filippo", se ti piace,
la cosa non cambia) è, ripeto, del tutto insensata.
Ciao.

 Sembra ancora meno interessante di quanto pensavo.
Guarda, smetto di leggere qui. O ci fai o ci sei e francamente me ne 
infischio.
Kiuhnm

Kiuhnm ha scritto:

Capisco che tu, in tutta onestà, creda di avere inventato l'acqua calda, 
e ne sia entusiata, ma il fatto è che è già stata inventata molto tempo 
fa, e non è poi 'sta gran cosa.
Ciao.

 fa, e non è poi 'sta gran cosa.
Complimenti per l'accuratezza con cui leggi i post degli altri. Oltre ad 
aver dimostrato scarsa cultura in informatica teorica, hai completamente 
travisato il senso di quanto ho detto.
Kiuhnm