OT Programmazione 2014

[M.A.W. 1968]

Che bello, con le vacanze di natale arriveranno gli universitari disperati per la sessione invernale!
Il forum avrà una botta di vita!

Se confronto il traffico aggregato sui sei o sette principali forum di programmazione italiani con quello delle principali aree nazionali FIDOnet sui linguaggi (Assembly, C, C++,...) durante gli anni Ottanta e Novanta, mi vien da piangere. Doppiamente se si entra nel merito della qualità delle domande, e spesso anche delle risposte. Triplamente, se si considera che oggi il 99,9% delle questioni riguardano solamente due SO e una piattaforma hardware, mentre ai tempi c'erano una decina di brand unix tra loro incompatibili, il DOS, Amiga, GEOS..., e non mancavano mai le domande sui sistemoni (es. VMS) o sui sistemi veramente esotici, con ovvia e conseguente sterminata varietà dell'hardware - all'epoca su ogni piattaforma si andava a scrivere direttamente su registri e locazioni mappate in memoria, col giusto timing, non ci si limitava a richiamare una API buona per tutte le stagioni. Il know how necessario era esponenzialmente più ampio e complesso.

Oh tempora, oh mores...

[MItaly]

Nulla di nuovo sotto il sole...

Sul discorso del lavorare sull'hardware vs le API, diciamo che la difficoltà attuale si è spostata dal costruire sull'hardware al saper rispettare le specifiche e sapere convivere con sistema operativo e altre applicazioni. In un certo senso, prima "valeva tutto" e bisognava essere cacciatori abilissimi, adesso il punto è essere buoni cittadini.

Dall'altro lato, sono comunque tempi esaltanti. La tecnologia non è mai stata così pervasiva, economica e potente, documentazione e paper di qualità si riescono a trovare facilmente, l'open source, tra alti e bassi, facilita la diffusione di codice e idee, e se i progetti sono ben gestiti è facile collaborare...

[M.A.W. 1968]

Sul discorso del lavorare sull'hardware vs le API, diciamo che la difficoltà attuale si è spostata dal costruire sull'hardware al saper rispettare le specifiche e sapere convivere con sistema operativo e altre applicazioni. In un certo senso, prima "valeva tutto" e bisognava essere cacciatori abilissimi, adesso il punto è essere buoni cittadini.

Infatti il 99% dei grandi cacciatori dell'epoca è svanito dal mercato mainstream come neve al sole, e si farebbe più facilmente spellare con delle conchiglie affilate come Ipazia di Alessandria piuttosto che lavorare "nel web" usando PHP o chissà che altro... quelle esperienze irripetibili hanno formato la generazione degli attuali progettisti dei sistemi più critici in circolazione, l'abitudine al bit fiddling e al register tweaking hanno creato le basi per gli skills più richiesti nel mondo dei sistemi dedicati e dell'hardware su misura, la capacità di bypassare DOS e BIOS sui banali PC (e anche su sistemi meno banali, dagli Alpha alle workstations HP-UX e Irix) ha forgiato chi ancor oggi scrive applicazioni systemless o RT-executive per l'avionica o i trasporti, eccetera.

D'altro canto, le fonti informative erano solo i manuali cartacei, i rari testi, qualche rivista USA, e ovviamente i guru su FIDOnet, noi che passavamo le notti a sperimentare e studiare, tra debug e reverse engineering fatto con la pochissima strumentazione disponibile, come e dove inserire una coppia di NOP tra una lettura e una scrittura di un registro per ottenere il giusto timing. Noi che cercavamo tra i rottami schede Hercules monocromatiche per poterle inserire su un 386 con la VGA e pilotare così un secondo monitor su cui inviare l'output di SoftICE, quando non si poteva avere un secondo PC per il debug remoto su seriale a 9600 baud. Altri tempi, altro mondo...

[Scara95]

Ehi, ne abbiamo già discusso, non toccatemi php. Sapete quante cose riesco a farci che non avrei mai immaginato?!

Libera il tuo (suo?) spirito creativo!

[M.A.W. 1968]

In effetti, come già notato, è davvero impredicibile cosa combinerà PHP col codice sorgente che gli viene fornito... un perfetto esempio di macchina non deterministica. Se solo riuscisse ad eseguire davvero in tempo polinomiale TSP o un qualsiasi altro equivalente!

[Scara95]

Eh, suvvia @M.A.W. Vuoi troppo dalla vita! Accontentati delle sorprese che ti riserva di volta in volta! Quanti bei regali ti fa

@MItaly a (s)proposito, quel progetto in cui ti serviva un linguaggio di Scripting come va? Che avete usato alla fine? E come vi trovate?

[MItaly]

Come sempre le cose si sono un po' arenate per via di problemi più urgenti Intanto siamo alla prima fase (portare Qt nell'applicazione e rifare un po' di maschere atroci), per il discorso scripting vedremo poi con più calma. Intanto sto comunque leggendo il libro di Lua, e non mi dispiace, anche se, oltre agli array con base 1, ha un po' di altre cose stranette (la cosa del Nil "magico" nelle tables mi disturba un po' ).
Comunque, quando si tornerà sul problema ti farò sapere gli esiti della vicenda.

[Scara95]

In realtà non c'è niente di magico nel nil, puoi benissimo fargli lanciare un errore o fargli fare qualsiasi altra cosa tu voglia: http://www.lua.org/pil/13.4.1.html

Non so se già sei arrivato a trattare le metatables...

Puoi farlo anche a livello globale in quanto tutte le variabili globali finiscono in una table.

[fermat]

girovagando mi sono imbattuto in AppML: http://www.w3schools.com/appml/default.asp

qualcuno ha avuto a che farci??

[MItaly]

In realtà non c'è niente di magico nel nil, puoi benissimo fargli lanciare un errore o fargli fare qualsiasi altra cosa tu voglia: http://www.lua.org/pil/13.4.1.html

Non so se già sei arrivato a trattare le metatables...

Puoi farlo anche a livello globale in quanto tutte le variabili globali finiscono in una table.

Naturalmente, anche se per il momento stavo cercando di farmi un'idea di come funziona il linguaggio "vanilla" nelle intenzioni dei suoi creatori, l'esperienza mi dice che cercare di portare di peso idiomi di altri linguaggi ad un nuovo linguaggio spesso non è una buona idea.