OT Programmazione 2014

[Scara95]

Che poi lo sanno tutti che l'editor standard è un altro... http://www.gnu.org/fun/jokes/ed-msg.html

D:

Glie l'ho farò sicuramente notare.

[Scara95]

D:

Glie l'ho farò sicuramente notare.

Oddio rileggendo ho fatto un infarto D:

Quando lo swype gioca contro di te.

[MItaly]

Per chi fosse stufo di sentire parlare sempre e comunque di "cloud" (anche e soprattutto a sproposito):
https://chrome.google.com/webstore/d...kmabhkfapgnoai


(c'è anche per Firefox! https://addons.mozilla.org/en-US/fir...-to-butt-plus/ )

[MItaly]

Da un po' al lavoro si stava pensando si rimpiazzare un linguaggio di scripting custom di un'applicazione "abbastanza legacy" (ma fondamentale, per cui non ce ne libereremo mai) con qualcosa di più normale.

Ho provato oggi a tirare dentro Python (sempre sia lodato), ma, oltre a non essere banalissimo da embeddare (il progettone nostro è basato su CMake e viene compilato con toolchain bizzarre, Python usa gli autotools e tremo al solo pensiero di quando dovrò integrarlo con la build winegcc), pone un po' di problemi per l'uso del whitespace, dato che parte di questi script vengono messi insieme da tecnici (non programmatori).

Stavo quindi dando un'occhiata a Lua, di cui ho spesso sentito parlare bene, e per tanti aspetti (C puro senza dipendenze complicate, build system facilmente integrabile con il nostro, API C semplici, buona diffusione, progetto maturo, sintassi facile e non dipendente dall'indentazione, impostazione interessante, ...) sarebbe perfetto... ma il discorso degli array con base 1 (e dei range chiusi) mi ha messo addosso una grande tristezza So che come "showstopper" è una stupidaggine, ma se si potesse evitare sarebbe meglio

Qualche suggerimento di altro linguaggio da vagliare? O devo prendere il buono di Lua e rassegnarmi agli array sbagliati?

[Scara95]

Lua usa il subset comune di C e C++ e viene compilato tranquillamente da entrambi i compilatori di questi linguaggi, non è C puro...
Comunque se fa al caso tuo usalo!

Gli indici che partono da 1 sono una scelta dovuta anche al fatto che lua vorrebbe essere facilmente leggibile da persone non abituate alla programmazione che, come è noto, cominciano a contare da 1 e non da 0. Detto questo non mi sembra un grande problema: Un non programmatore andrà meglio, un programmatore deve solo saperlo e stare attento ai casi limite.
Comunque tecnicamente puoi usare array con base 0 è che tutte le librerie standard sono programmate per array in base 1 e dovresti scrivere quindi delle tue funzioni (che oltretutto non godrebbero dell'ottimizzazione della libreria standard, a meno tu non ti prenda la briga di scriverle in C/C++)

Il tipo nativo dei numeri in lua puoi deciderlo con un define in un header, puoi sostituire al double un long double o un long long o quel che vuoi a seconda del problema che stai affrontando. Questo non risolve totalmente il problema ma lo mitiga. Comunque se i dati che tratti entrano nel range dei double senza perdite di precisione sei apposto, sennò considera un alternativa.
Puoi anche pensare di integrare una qualsiasi libreria per il calcolo con range illimitati. non dovrebbe essere complicato e potresti farla risultare (quasi) totalmente nativa.

Dovresti comunque decidere tu la soluzione migliore dato che conosci direttamente il problema.

Mi è noto mruby per sentito dire, ma è alle fasi iniziali.
Mi è noto guile ma non ti saprei dire (da ciò che dice la pagina va su MinGW, quindi dovrebbe andare su winegcc).
Tcl.
Varie implementazioni di javascript (o come lo vuoi chiamare).
E poi svariati trigliardi di linguaggi o sperimentali o poco conosciuti/usati o mal supportati.

Io sono di parte e lua mi sta simpatico perciò non conto, ma ti direi lua.

[MItaly]

Gli indici che partono da 1 sono una scelta dovuta anche al fatto che lua vorrebbe essere facilmente leggibile da persone non abituate alla programmazione che, come è noto, cominciano a contare da 1 e non da 0. Detto questo non mi sembra un grande problema: Un non programmatore andrà meglio, un programmatore deve solo saperlo e stare attento ai casi limite.

Lo so che è più un limite psicologico che altro, però ragazzi, si usano da sempre gli indici che partono da zero perché nel 90% dei casi in cui importa sono più comodi, perché dovevano cascare in sta scemata e rendere inutilmente oscuri tutti i passaggi di array tra lato C e lato lua?

Il tipo nativo dei numeri in lua puoi deciderlo con un define in un header, puoi sostituire al double un long double o un long long o quel che vuoi a seconda del problema che stai affrontando. Questo non risolve totalmente il problema ma lo mitiga. Comunque se i dati che tratti entrano nel range dei double senza perdite di precisione sei apposto, sennò considera un alternativa.
Puoi anche pensare di integrare una qualsiasi libreria per il calcolo con range illimitati. non dovrebbe essere complicato e potresti farla risultare (quasi) totalmente nativa.

Sissì ma guarda, non è che ci siano requisiti particolarmente strani... l'applicazione è una (quasi) normale applicazione Windows, i double vanno più che bene (sono già il default nel linguaggino attualmente impiegato) e non ci sono chissà che problemi di performance.

Mi è noto mruby per sentito dire, ma è alle fasi iniziali.

Guardato, mi sembra anche a me un po' acerbo.

Mi è noto guile ma non ti saprei dire (da ciò che dice la pagina va su MinGW, quindi dovrebbe andare su winegcc).

L'avevamo guardato, uno scheme forse è un po' troppo per il nostro "target" di pubblico.

Tcl.

"In casa" i pochi che abbiamo che lo conoscono lo detestano (e quel poco che ho visto io non mi piace per niente ).

Varie implementazioni di javascript (o come lo vuoi chiamare).

Usato in un altro progettino in cui c'era Qt e integrazione e binding erano sostanzialmente gratis (grazie a QtScript), ovviamente si risente un po' delle bizzarrie di Javascript, ma quantomeno sono ben note e tutto sommato è un linguaggio che si usa tranquillamente. Anche senza Qt (che in questo progetto non c'è) resta un'ipotesi al vaglio, è un po' da vedere la facilità di integrazione.

E poi svariati trigliardi di linguaggi o sperimentali o poco conosciuti/usati o mal supportati.

Che eviterei

Io sono di parte e lua mi sta simpatico perciò non conto, ma ti direi lua.

Eh, mi sto seriamente convincendo... pace per gli indici degli array e per la cosa bizzarra dei nil nelle tables, per il resto mi sembra un linguaggio interessante e molto semplice da iniziare ad usare - effettivamente nasce esattamente per il nostro caso d'uso.

Restando ai linguaggi di scripting embeddable meno esotici, la mia top ten di preferenze include, nell'ordine:
- Ch;

Per carità, un interprete C/C++ è l'ultima cosa di cui abbiamo bisogno le paturnie di C e C++ si sopportano più che volentieri in mano a programmatori esperti in cambio di eseguibili compilati che vanno a tutta birra, tirarsi dentro un interprete che cerca di stare dietro ad una sintassi inutilmente vecchia e complicata per roba da esporre a quasi-non-programmatori mi sembra un atto di masochismo.

[M.A.W. 1968]

...roba da esporre a quasi-non-programmatori...

Ecco, non avevo colto questa sfumatura. In tal caso, rilancio Tcl e Lua, nell'ordine.

[Scara95]

Ecco, non avevo colto questa sfumatura. In tal caso, rilancio Tcl e Lua, nell'ordine.

Non che tcl, C e C++ siano privi di stramberie comunque
C e C++ non sono strambi solo perché sono due dei linguaggi più utilizzati e "la gente ci ha fatto il callo".
Tcl è più strambo di lua

Però devo ammettere che tcl garantisce una flessibilità straordinaria, cosa in cui se la cava molto bene anche lua.

[M.A.W. 1968]

Qualche suggerimento di altro linguaggio da vagliare? O devo prendere il buono di Lua e rassegnarmi agli array sbagliati?

Restando ai linguaggi di scripting embeddable meno esotici, la mia top ten di preferenze include, nell'ordine:
- Ch;
- Tcl/Tk;
- Lua.

Prima di rassegnarti alle stramberie di Lua, dai una bella occhiata a Ch, che comunque è un prodotto commerciale...

[M.A.W. 1968]

Più o meno tutti i linguaggi sono strambi, a maggior ragione per chi viene dagli Assembly degli anni Ottanta... alcuni sono più strambi degli altri, chiosando Orwell. In effetti, negli ultimi trent'anni, mi è capitato più volte di constatare come il C sia in effetti uno dei peggiori linguaggi in circolazione, da parecchi punti di vista.

La medesima impressione nei confronti della generalità dei linguaggi si prova dopo avere usato a lungo e a fondo SmallTalk, Ada o Eiffel: ma in questo caso la probabilità che qualcuno li abbia usati come primo linguaggio o vi sia addirittura "cresciuto dentro" come avveniva con l'Assembly dei PET e PC è infinitesimamente piccola.