Newsgroup: it.lavoro.informatica
Titolo: Quale nuovo linguaggio?

Ciao a tutti,

mi inserisco nell'amena discussione sui contratti di lavoro :-) per 

(provare a) iniziarne un'altra sui linguaggi di programmazione.



Allo scopo di svecchiare le mie conoscenze alla mia non pi� veneranda 

et� (passati da poco i 40) e anche per far fare un po' di ginnastica 

alla mia atrofizzata la materia grigia :-), mi � venuto in mente di 

muovere i primi passi in un linguaggio di programmazione pi� moderno. 

Premesse importanti per completare il quadro:



1) Per cultura di studio e di lavoro provengo da linguaggi di 

programmazione tradizionali, all'inizio procedurali (Pascal, C) e 

successivamente OO (C++ e Java). La quasi totalit� del mio recente 

lavoro � in Java (ambiente web, quasi solo backend).



2) Come gusto personale prediligo i linguaggi a tipizzazione abbastanza 

forte, perch� penso che aiuti molto in fase di stesura del codice. Per 

intenderci aborro Javascript, che ritengo l'anti-programmazione per 

eccellenza :-)



3) Multipiattaforma, perci� tenderei a scartare soluzioni proprietarie 

come .NET



4) Non sono in linea di massima interessato al mondo mobile. Troppo 

schizofrenico, ci ho una certa et� ;-)



5) Naturalmente OK a supporto per il mondo web, ma non � un requisito 

vincolante. Per quello conosco gi� Java, che basta e avanza.



6) Sono un convinto sostenitore di concetti come metodologie agili, test 

di unit�, continuous integration, ecc. Ma non sono un talebano: ritengo 

infatti che esse vadano usate adattandosi al contesto (azienda, campo di 

applicazione, ecc.) in cui si opera, e non il contrario.



6) L'occhio ad una eventuale rivendibilit� delle competenze naturalmente 

c'�, ma eventualmente a medio termine. Come idea comunque io sono pi� da 

grande azienda piuttosto che da web startup composta da imberbi nerd :-)



Tenendo conto di tutte queste cose, stavo pensando a qualcosa come 

Python oppure Ruby, che per� � un po' pi� alternativo. Naturalmente sono 

anche aperto ad altre alternative che mi potessero essere sfuggite.



Io ho intavolato la discussione, ors� se vi va dite la vostra :-)



TheStar


 CUT



scala soddisfa tutti i tuoi requisiti. Io ti consiglio quello ;D

Non è un linguaggio semplice (sopratutto da chi ha programmato sempre e solo ad oggetti) ma da tante soddisfazioni.



Ha anche librerie di test molto fighe come Specs2 (compatibile con mockito) e scalacheck.


 eccellenza :-)



ti conviene intanto riconsiderare questi giudizi, sia per quanto riguarda 

la tipizzazione che per quanto riguarda javascript. magari volendo 

approcciare qualcosa di nuovo eliminerei il preconcetto che quello finora 

conosciuto sia il miglior mondo possibile, altrimenti gira e rigira torni 

sempre da dove sei venuto. 


 sempre da dove sei venuto.



Considerazione che rispetto e in parte condivido.



Ma il mio, come lo chiami tu, "preconcetto", deriva dall'esperienza, 

dall'aver provato Javascript e dall'aver constatato N mila volte quanto 

sia inaffidabile, poco manutenibile, a rischio di errori, e chi più ne 

ha più ne metta. E quanto la vita fosse invece più facile (e più 

produttiva) con un linguaggio tipizzato.



Quasi sicuramente sulla mia valutazione pesa il pessimo supporto e la 

compatibilità fra i diversi browser, cosa che non dovrebbe avvenire con 

un linguaggio più di tipo "scripting" ma con una VM fatta e supportata 

in modo più organico.



Voglio dire, la ex Sun/Oracle non sviluppa tutte le JVM, ma la 

compatibilità è molto buona grazie ai requisiti stringenti.



TheStar



Vai sui linguaggi funzionali: Lisp, Ocaml, Haskell, F# sotto Net, pure Scala che ti hanno consigliato.

Certo se vuoi pure una consistente rivendibilità, in Italia poi, la vedo dura :-)



Ma che ci vuoi fare con questo linguaggio?

Ruby è carino, e uno dei pochi che possono aggiungere qualcosa se sei interessato al BDD (penso a RSpec, Cucumber e Watir) ed è discretamente rivendibile.

Ho pero' l'impressione che andresti ad imparare un doppione con caratteristiche appena differenti.

Puoi comunque dargli un occhiata velocemente e spacciarlo per cazzeggio se poi non ti piace: 
http://mislav.uniqpath.com/poignant-guide/




  ngw


 ha più ne metta. 



premesso che non ho intenzione di assumerne la difesa d'ufficio 

(figuriamoci), però questi giudizi non sono oggettivamente corretti. js 

non è intrinsecamente meno manutenibile o più error-prone di altri 

linguaggi, lo diventa nel preciso momento lo si approccia nel modo 

sbagliato. venendo da java e con la convinzione ormai marchiata a fuoco di 

trovare un linguaggio semanticamente simile è normale battere una sonora 

craniata. però se uno assimila i suoi aspetti fondamentali, l'ereditarietà 

prototipale, lo scope dinamico, gli elementi funzionali, gli eventi 

asincroni, magari adatta lo stile di programmazione a queste 

caratteristiche invece di programmare in java usando javascript, il 

risultato può essere molto interessante. e a ben guardare anche 

discretamente elegante.






 Ruby è carino, e uno dei pochi che possono aggiungere qualcosa se sei interessato al BDD (penso a RSpec, Cucumber e Watir) ed è discretamente rivendibile.



Non so nulla circa la rivendibilità, ma condivido l'impressione sul linguaggio. Io uso Python, e alla fine resto li per una questione di esperienza e perché tutto sommato soddisfa le mie esigenze; ma se dovessi partire da zero, sicuramente Ruby.



-- 

Ciao!

Luca


 Non so nulla circa la rivendibilità, ma condivido l'impressione sul linguaggio. Io uso Python, e alla fine resto li per una questione di esperienza e perché tutto sommato soddisfa le mie esigenze; ma se dovessi partire da zero, sicuramente Ruby.



Per cosa usi concretamente Python (cioè, progetti pagati :-), oltre alla tradizionale applicazione web? Stessa domanda per Ruby, dove è usato e richiesto esplicitamente?




Ma usi degli editor per javascript che ti permettono di avere le enne 

comodità ormai irrinunciabili tipo la lista dei riferimenti incrociati, 

il completamento automatico, gli hint sulle chiamate, sintassi 

evidenziata (a colori), salti veloci alla definizioni avanti e indietro, 

ecc...? Comodità che funzionano sempre e non 1 su 10 per motivi non chiari?

JS io l'ho usato poco per carità, però una cosa che mi ha ostacolato 

nell'approfondimento è proprio la scarsa qualità dell'ambiente di 

sviluppo (era VS2010).

Con gli anni divento sempre più pigro e se mi spariscono certi aspetti 

nello sviluppo proprio mi blocco... :-)







Ah dimenticavo, il tutto considerando enne .js e non un malloppo unico, 

insomma tenendo a mente una classica solution con i sorgenti sparsi qui 

e li.




 Per cosa usi concretamente Python (cioè, progetti pagati :-), oltre alla tradizionale applicazione web? 



Io a questo punto lo uso un po' per tutto. Peraltro, cosa interessante, ciò che scrivo per Windows, rispettati alcuni canoni, funziona bene per Linux e viceversa. Va però detto che in questo momento non sto scrivendo applicazioni con UI. O meglio, sto portando avanti un progetto a tempo perso (usando PySide come framework grafico), ma si tratta di un'iniziativa personale, per cui per il momento la tengo fuori dal conto.





-- 

Ciao!

Luca





Che non sia *così* male posso anche concordare, ma è letteralmente inondato di warts, e il typing debole di sicuro non aiuta.

Anche se abbastanza comica, mi pare che questa immagine sia molto molto veritiera: 
http://trelford.com/blog/image.axd?picture=JS%20The%20Good%20Parts_thumb.jpg




  ngw



Certo, che domanda è? Lo sottintendono? :D

Io lo uso principalmente come linguaggio di integrazione, scrivo un aggregatore che pesca contenuti da n fonti (Facebook, Twitter, Wordpress, Disqus) e permette a pool di moderatori di gestire i contenuti. Lo usano in tanti (che ne so, Mediaset, Mediobanca, tanti altri). 

Anche i deploy e le automazioni sono molto handy in Ruby, grazie a Capistrano.

Ci ho scritto anche n crawler e piattaforme per usarli (uno dei più divertenti è un crawler che naviga su Google per andare a pescare i vari "x pedofilo mafioso" che passa spesso anche qua sopra, per segnalarli alle authority :D)

Python si usa per circa le stesse cose, sono linguaggi molto molto simili.



  ngw






Casualità pazzesca, proprio ora ho letto una richiesta di un mio contatto su 

LinkedIn (piccola azienda che produce un fighissimo sistema di analisi e 

bilanciamento del traffico di rete) che cerca proprio un programmatore Python 

su Udine, full-time :)



Io non conosco Python, ma se qualcuno fosse interessato gli giro il contatto.



ciao

Gabriele


 su Udine, full-time :)



Per motivi familiari non posso spostarmi. Se potessi ci andrei di corsa: io ho studiato a Udine, e mi è piaciuta tantissimo, è una città ancora molto a misura d'uomo.



-- 

Ciao!

Luca


 Io lo uso principalmente come linguaggio di integrazione, scrivo un aggregatore che pesca contenuti da n fonti (Facebook, Twitter, Wordpress, Disqus) e permette a pool di moderatori di gestire i contenuti. Lo usano in tanti (che ne so, Mediaset, Mediobanca, tanti altri). 



Domanda a te e domanda generale (ergo, anche a te).

1) come ricchezza di librerie, trovi Ruby paragonabile a Python? lo chiedo perché Python ha come contro alcune cose che non mi piacciono (e che Ruby in effetti risolve), però ha dalla sua una quantità di librerie, standard o di terze parti, spaventosa e in grado di coprire quasi qualsiasi esigenza;

2) mi trovo nella sotuazione di dover scrivere della roba non leggibile; Python non va bene, e i vari obfuscators che ho trovato non sono 'sta gran cosa; al di la del fatto che sto pensando di usare PyInstaller, ma alternative sono ben accette.



-- 

Ciao!

Luca


 Ci ho scritto anche n crawler e piattaforme per usarli (uno dei più divertenti è un crawler che naviga su Google per andare a pescare i vari "x pedofilo mafioso" che passa spesso anche qua sopra, per segnalarli alle authority :D)



Dovresti metterti in contatto con l'avvocato oggetto di quelle molestie (se 

vuoi ti mando il suo LinkedIn o email), perché quella storia è diventata 

davvero molto pesante e so che lui si sta organizzando in tal senso.



ciao

Gabriele


 davvero molto pesante e so che lui si sta organizzando in tal senso.



No guarda, ho scritto un crawler per quella roba così, per mio divertimento personale :D

Dietro c'è tutta una storia di uno che ha perso tutto e ora passa le giornate a fare centinaia di post *a mano*, e questi disperati perchè a loro nome su Google si trova quella fuffa e non i loro siti personali :D



  ngw


 1) come ricchezza di librerie, trovi Ruby paragonabile a Python? lo chiedo perché Python ha come contro alcune cose che non mi piacciono (e che Ruby in effetti risolve), però ha dalla sua una quantità di librerie, standard o di terze parti, spaventosa e in grado di coprire quasi qualsiasi esigenza;



Sono molto simili anche in quello. Puoi eventualmente provare a fare qualche ricerca su 
https://rubygems.org/




  ngw



Se è per quello so che il progetto Hermes sta cercando uno sviluppatore Python: 
http://logioshermes.org/




  ngw


 1)

CUT



Sulla base delle premesse su esposte, il miglior linguaggio di

programmazione che fa al caso tuo ï¿œ...



..Java!



Per cui sei giï¿œ a posto ;)








 Io a questo punto lo uso un po' per tutto. Peraltro, cosa interessante, ciò che scrivo per Windows, rispettati alcuni canoni, funziona bene per Linux e viceversa. 



Quanto complicati sono questi canoni, a tuo parere? Tenuto conto che non è così raro trovare linguaggi nelle due versioni Win e Lin, per fortuna. 



Va però detto che in questo momento non sto scrivendo applicazioni con UI. O meglio, sto portando avanti un progetto a tempo perso (usando PySide come framework grafico), ma si tratta di un'iniziativa personale, per cui per il momento la tengo fuori dal conto.



Ok. Mi pare di ricordare che ti occupi anche di applicazioni embedded, o comunque che hanno necessità di interfacciarsi a basso livello con dispositivi hardware particolari. Lo usi anche in questi contesti?


se poi non ti piace: 
http://mislav.uniqpath.com/poignant-guide/




Grazie del link, gli darò un'occhiata!



TheStar


 Python si usa per circa le stesse cose, sono linguaggi molto molto simili.



Nel senso che secondo te Python e Ruby sono simili?



TheStar


 Per cui sei giï¿œ a posto ;)



Non ï¿œ del tutto vero :-)



Io sono anche disposto ad esplorare altri ambiti, rinunciando anche ad 

alcuni dei miei capisaldi.



Il punto ï¿œ un altro. Come detto in un altro post, se ritengo (con tutte 

le ragioni) Javascript un cesso non ï¿œ solo per le sue caratteristiche 

sintattiche, ma anche (anzi, soprattutto) per il supporto estremamente 

eterogeneo negli ambienti dove tipicamente viene eseguito, e cioï¿œ nei 

browser. In parole povere, se io scrivo un pezzo di codice 

sintatticamente corretto, voglio - anzi, PRETENDO - che si comporti allo 

stesso modo indipendentemente da dove lo eseguo. Non deve essere compito 

mio gestire a livello di codice le incoerenze del supporto.



Come dicevo, voglio sperare - ma ne sono abbastanza sicuro - che questo 

non succeda con altri linguaggi meno fortemente tipizzati, come ad 

esempio Python, Ruby, ed altri. Perchï¿œ le rispettive VM mi sembra che 

siano supportate e gestite in modo piï¿œ serio che i vari interpreti 

Javascript.



TheStar


 





giusto a questo proposito,

io conosco solo il mondo java/javascript, perché solo in questo

mondo ho sinora lavorato (ho visto anche un po' di C all'università,

ma mai a livello professionale, e tantomeno ho mai sviluppato

applicazioni in tale linguaggio).



Però, per certi versi quello che dici a proposito del javascript non

è del tutto errato, perché ci sono certe funzioni che vanno bene

con un browser ma non funzionano con un altro; tuttavia ci sono

diversi framework in javascript in cui questi problemi di supporto

sono decisamente minori.

Sto pensando ad esempio a extjs, che negli ultimi mesi sto usando

in modo molto massiccio nella parte front end del progetto che

sto sviluppando: le pagine web sono scritte tutte con extjs 

(versione 4), e quando faccio i test con browser diversi

(ch, ff e ie) effettivamente constato che problemi di supporto ce ne

sono pochissimi, anzi credo proprio di non averne ancora incontrati,

nell'attuale progetto.





Quindi, voglio dire, è vero che il javascript a volte ti pone

problemi di supporto, ma è vero pure che ci sono diversi

framework con cui riesci a fare molte cose riducendo un bel po'

questi problemi, come appunto extjs.



Tu extjs lo conosci? Lo hai mai usato? A me, per quello che lo

conosco, sembra buono.


 conosco, sembra buono.



Siamo un po' OT, per� � una domanda interessante.



Certo che lo conosco. Non personalmente, ma per "osmosi e vicinanza" nel 

senso che non ci ho scritto niente, ma nel progetto dove lavoro la GUI 

era implementata interamente proprio su di esso.



ExtJS, in effetti, ti maschera buona parte delle incompatibilit� fra 

browser, questo � vero. Ma ha il difetto di avere uno scarso supporto e 

una scarsa retrocompatibilit� tra le diverse versioni. Il porting della 

GUI tra la versione 3 e 4 per i nostri sviluppatori lato client � stato 

un bagno di sangue, perch� hanno cambiato un mucchio di cose 

sottintendendo pi� o meno "dalla versione 4 facciamo cos� invece di cos� 

e il far funzionare le cose ricade tutto su di voi". Morale della 

favola: stiamo buttando nel cesso ExtJS e rifacendo la maggior parte 

della GUI con roba pi� semplice e manutenibile: HTML, CSS e JQuery.



La mia opinione �: ExtJS va bene solo se usato per particolari 

applicazioni, per le quali tecnologie o toolkit pi� tradizionali siano 

inadeguati. Implementare per intero il lato client di una web app solo 

usando ExtJS ha senso se e solo se si tratta di una GUI molto complessa 

e con funzionalit� molto articolate. Altrimenti ci si complica la vita e 

basta.



TheStar





Per me si, tutti e due tipati forti e dinamici, tutti e due OO puri, cambiano sintassi e idiomi, Python ha le list comprehension e i decoratori, Ruby i blocchi ed è vagamente più perlish.

IMHO i framework per il testing, RoR (+ Sinatra, che per me è una meraviglia assoluta) e Capistrano sono punti di forza di Ruby, Python ha un interprete un po' più veloce (e sicuramente più maturo) e alcune librerie che Ruby non ha, ad esempio scipy.



  ngw


 



Tra l'altro, ho letto quel libro, e l'ho trovato abbastanza deludente...



bye!


 neuroni :-)



Io andrei su un paradigma differente, Erlang (o Elixir) o Haskell, la cosa peggiore che ti puo' capitare è che migliori come programmatore.

Sono tutti rivendibili, ma ovviamente non come Ruby o Java: hanno nicchie specifiche che servono egregiamente e sono in espansione, ma certamente danno un mindset molto più ampio a prescindere dal fatto che ci si lavori o meno, visto che sono molto molto diversi da quello che conosci/usi ora.



http://learnyousomeerlang.com/


http://elixir-lang.org/


http://learnyouahaskell.com/




  ngw



Quello di Crawford? Io l'ho trovato ottimo invece...



  ngw


 chiari?



se vuoi ti dico quello che uso (intellij idea e webstorm) però trovo un 

po' ozioso discutere di un linguaggio partendo dalle caratteristiche degli 

editor. 

e in ogni caso non sto facendo il difensore d'ufficio del javascript, ho 

voluto fare delle puntualizzazioni che mi sembravano opportune visti i 

giudizi perentori. 


 e li.



dai un occhiata a grunt, bower, yeoman. aiutano non poco.






Era solo una domanda eh! :-)




 neuroni :-)



sinceramente non riesco a vedere l'imparare un nuovo linguaggio come sfida personale. Magari ha forse piu' senso il passare da Java ad un linguaggio funzionale, che bene o male ti forza a ragionare secondo altri paradigmi. Pero' dubito ti possa veramente lasciare il segno, se non lo usi per rimpiazzare completamente Java o quantomeno non hai obiettivi precisi da portare a termine. Io di recente ho ritrovato la passione nel programmare, non cambiando linguaggio, ma cambiando completamente approccio ai problemi. Ad esempio, salvo necessita' impellenti, cerco di non usare librerie. Detta cosi' sembra una cosa stupida e dispendiosa (in termini di tempo), e probabilmente un po' lo e', pero' la curiosita' di capire appieno l'algoritmo che vai ad usare m'ha ridato il piacere di utilizzare il PC, piu' come strumento di conoscenza, che come per uno sporco "get the job done". E -oltre alla passione- devo dire che anche i risultati non tardano a farsi vedere, implementando un metodo (anche consolidato) un po' lo dissacra, e ne mette a luce i limiti. Don't get me wrong, non ti sto suggerendo di abbandonare l'uso di librerie, ma piuttosto che se non hai una vera necessita' di imparare un linguaggio nuovo, ma lo faresti esclusivamente per "sfida", magari potresti considerare il focalizzarti piu' sull'obiettivo o su un problema difficile, che imparare i fondamenti di un nuovo linguaggio, che di per se' non mi sembra tutto sto "challenge". My 2 cents :-)










webstorm se funziona sempre è una figata!






 Ok. Mi pare di ricordare che ti occupi anche di applicazioni embedded, o comunque che hanno necessità di interfacciarsi a basso livello con dispositivi hardware particolari. Lo usi anche in questi contesti?



No, io mi sono occupato soprattutto di supervisione / collezione dati, e per farlo ho impiegato i bus di campo standard (CAN, ModBus, Step7, ecc). E in quel caso l'ho fatto per un'azienda che - mia personalissima opinione - usava uno strumento totalmente inadeguato, ossia VB6. Però il famoso progetto a tempo perso è Python, PySide E ModBus. Se riesco a arrivare a un punto decente, ti dico come va!



-- 

Ciao!

Luca


 nell'attuale progetto.



Io ho usato ExtJS in modo piuttosto intensivo negli ultimi tre anni. Mi hanno reso nervoso tre cose: 1) è oggettivamente sul pesante; 1) fai un avanzamento di minor release, rifai i test con vari browsers, e qualche problema ti viene fuori, per cui devi rimettere le mani nel codice; 3) per talune funzioni avanzate, non è vero che funzioni con tutti i browser (e l'errore notificato è interno alla libreria).



E' più scomodo, ma sto studiando jQuery....



-- 

Ciao!

Luca


 direi che è imprescindibile, direi che non è assolutamente un dettaglio.



secondo me oltre un certo livello rallentano anziché no, più che altro 

quando instillano la brutta abitudine di non memorizzare e ricercare 

sempre le stesse informazioni.


 E' più scomodo, ma sto studiando jQuery....



jquery fai bene a studiarlo ma non c'entra niente. se vuoi fare una cosa 

fatta bene dai un'occhiata a angularjs + angular ui (la sua integrazione 

con bootstrap). ma è solo l'esempio più "di tendenza", di alternative 

valide per il front-emd ce ne sono tante.

extjs è veramente il peggio fra l'altro anche il suo look&feel mi fa 

abbastanza pena.


 mio gestire a livello di codice le incoerenze del supporto.

CUT



JavaScript ï¿œ uno standard ECMA, quindi la compatibilitï¿œ

cross-browser deve essere garantita. Se cosï¿œ non ï¿œ, ï¿œ

perchï¿œ stai usando un browser di merda.









Bene, auguri! :-)


 





si, anche jquery in effetti non è male. Io lo usavo tempo fa,

poi non l'ho più utilizzato, ma da quel che ricordo tra extjs

e jquery ci sono un po' di somiglianze.


 sinceramente non riesco a vedere l'imparare un nuovo linguaggio come sfida personale. Magari ha forse piu' senso il passare da Java ad un linguaggio funzionale, che bene o male ti forza a ragionare secondo altri paradigmi. Pero' dubito ti possa veramente lasciare il segno, se non lo usi per rimpiazzare completamente Java o quantomeno non hai obiettivi precisi da portare a termine. Io di recente ho ritrovato la passione nel programmare, non cambiando linguaggio, ma cambiando completamente approccio ai problemi. Ad esempio, salvo necessita' impellenti, cerco di non usare librerie. Detta cosi' sembra una cosa stupida e dispendiosa (in termini di tempo), e probabilmente un po' lo e', pero' la curiosita' di capire appieno l'algoritmo che vai ad usare m'ha ridato il piacere di utilizzare il PC, piu' come strumento di conoscenza, che come per uno sporco "get the job done". E -oltre alla passione- devo dire che anche i risultati non tardano a farsi vedere, implementando un metodo (anche consolidato) un po' lo dissacra, e ne mette a luce i limiti. Don't get me wrong, non ti sto suggerendo di abbandonare l'uso di librerie, ma piuttosto che se non hai una vera necessita' di imparare un linguaggio nuovo, ma lo faresti esclusivamente per "sfida", magari potresti considerare il focalizzarti piu' sull'obiettivo o su un problema difficile, che imparare i fondamenti di un nuovo linguaggio, che di per se' non mi sembra tutto sto "challenge". My 2 cents :-)



Sottoscrivo parola per parola. Se cambi paradigma indubbiamente devi ragionare in modo molto diverso, e questo è bene. Stessa cosa se ti sforzi di imparare qualche algoritmo, rinunciando alla libreria già pronta (qui parliamo di librerie algoritmiche, non mi metterei a riscrivere il driver di un certo dispositivo hardware :-).

La soluzione del problema può arrivare quasi sempre anche usando linguaggi "tradizionali" (pensando al C potrei anche dire: la soluzione arriva sempre).


 





insomma, come ho già detto, io non voglio osannare extjs, assolutamente.



Però sinceramente sul fatto di complicarsi la vita secondo me

vale sempre il discorso dei framework in generale, sia front end che

back end: un framework se lo padronizzi e lo sai usare bene può

essere molto utile per fare le cose, e può farti risparmiare

tempo e fatica, dato che ha le funzioni predefinite per fare determinate

cose, e lo sviluppatore non deve far altro che richiamare le

funzioni esposte.

Però devi conoscerlo bene, altrimenti per fare una cazzata ci perdi

tranquillamente delle giornate (e mi succede), in questo senso il

rischio di complicarsi la vita c'è.

In tal caso forse è meglio non usarlo, o usare un altro framework

che si conosce meglio, su questo sono d'accordo.





Insomma, un framework è uno strumento, bisogna usarlo per ciò per

cui è stato ideato e saperlo usare, sennò ti perdi, c'è niente da fare.




Grazie per l'esempio, mi stavo incomiciando a dimenticare perch� 

personalmente trovo lo sviluppo di webapp una merdata incredibile e voluta.

E' gi� un miracolo che funzionicchino come funzionicchiano (cio� in modo 

tutto tranne che robusto), ma non si pu� buttare tutto e tornare alla 

modalit� tipo terminale? Tanto la connettivit� diventa sempre di pi� 

imprescindibile, tanto vale quindi buttare tutto sto infinito ginepraio 

di tecnologie che lasciano veramente basiti in quanto a fragilit�.



Potevi riassumere con un "si stava meglio quando si stava peggio", il contorno di stupidaggini disinformate e piuttosto comiche non aggiunge molto.

Setterei l'encoding corretto del tuo post inoltre, penso Thunderbird lo permetta. Sai, il fragile Google Groups funzionicchia che se gli dici che il messaggio ha un encoding si fida e poi ti sega tutte le accentate, se lo fai in un messaggio in cui parli di "robustezza" e di miracoli viene un po' da ridere.



  ngw


 dispositivo hardware :-).



si, non stavo pensando ai drivers, che son piu' di competenza del SO che di programmi generici








Messo a UFT-8, te invece perché non ti metti una lunghezza riga non 

infinita?

Ops la web app google groups non lo permette? Sapresti anche come mai 

via google groups un thread non è visibile in modo gerarchico ma 

solamente piatto in stile post in un blog?

Sempre per rimanere in tema di web app che fan cagare ovviamente...




 solamente piatto in stile post in un blog?



Ma sticazzi? Usane un'altra, che vuoi da me? Hai forse la ridicola pretesa di dimostrare a casaccio che una applicazione web e' pessima per dedurre la scemenza che l'altra smiliardata e' simile? Non ci si crede, hanno aperto le gabbie.

Prima che ti confondi e cominci a straparlare, non ho tempo da perdere con te, torna quando hai qualcosa da dire che non sia una scemenza.



  ngw




Ma figurati fermati pure, non vorrei causarti problemi seri facendoti 

sentire obbligato a non cagare cos� comodamente nel ng.

Se ti eclissi non dai nessun fastidio, almeno a me.



Peccato per�, pensavo di imparare qualcosa di utile che faccesse vedere 

come si possono fare webapp robuste e che non schiantano ad ogni 

aggiornamento del mix composto da: versione del browser (gli enne 

classici su pc, pi� gli enne per smartphone e tablet grazie al solido e 

robustissimo supporto a js + css) + versione degli enne framework che 

vivono lato client. In modo da rendere non cos� invasivi in termini di 

tempo tutti i test che invece sono necessari e sono da fare proprio a 

manina sulla UI che esce sugli ennne dispositivi *ogni* volta per *ogni* 

aggiornamento di browser e/o fx.

Un bel mondo davvero quello dello sviluppo delle webapp, pura 

soddisfazione per gli amanti dele pippe ad oltranza sulla sola parte 

tecnologica, ovviamente poi di tempo per la app vera e propria, a 

livello di strumento reale per gli utenti, ne rimane poco o niente...




 spallucce.



lo scenario descritto da kojak è lo scenario di un bug, se una proprietà 

deve essere numerica evidentemente è sbagliato mettere una stringa. sul 

fatto che un browser ignori e gli altri no la soluzione del mistero può 

essere solo nel codice di extjs visto che quel valore dovrà essere 

trasformato in uno stile css e vai a sapere come lo fa. 


 livello di strumento reale per gli utenti, ne rimane poco o niente...



Comincia tu a dimostrare che quello che dici non e' una puttanata colossale, perche' sembri fermo al 2002/2003.

Ultima volta che ad un aggiornamento del browser si e' "schiantato" (che terminologia tecnica, si vede che sei uno che ne sa) Facebook, o Twitter, o che ne so, Google Analytics, o Github? Facce ride'.



  ngw



Personalmente ho trovato interessante fare qualche programma per microcontrollori. Niente a che fare con drivers o cose complicate, comunque è un ambiente particolare, che ti pone limiti stringenti di memoria, tempi di esecuzione, ecc. Insomma ti fa tornare sulla terra, dopo l'abboffata di strati e strati di librerie, framework e macchine virtuali dei loro "fratelli computer"  più potenti :-)




E perché non amazon o ebay?

Che team hanno dietro quelle webapp? 4 gatti?






Io dico che di questi misteri ce ne sono fin troppi nello sviluppo di 

webapp... IMHO eh, che poi si parte con gli insulti...


 Che team hanno dietro quelle webapp? 4 gatti?



Va bene, scegliti la web app e illuminaci.



  ngw


 fx immagino...).



Unit testing, questo sconosciuto.



  ngw


 perchï¿œ stai usando un browser di merda.



Sapevo dell'ECMA. In un mondo ideale gli standard sono stati creati 

apposta perchï¿œ uno li segua, in modo da "parlare la stessa lingua" e 

capirsi con i vari interlocutori.



Ma purtroppo nel mondo reale non ï¿œ cosï¿œ e non tutti i browser in realtï¿œ 

seguono gli standard alla perfezione. Il primo a non farlo un "tale" 

Internet Explorer, un vero browser di merda. Peccato che perï¿œ sia 

talmente diffuso che non ti puoi permettere di non supportarlo alla 

perfezione.



TheStar


 da quello che conosci/usi ora.



Grazie, gli dar� un'occhiata.



TheStar


 Scusa, rivendibili dove? Di sicuro non in Italia, ovviamente.



Haskell è un po' difficilotto da rivendere, Erlang/Elixir dipende dal tuo potere decisionale dove lavori: se devi tirare in piedi un servizio dove la concorrenza e la safety sono importanti puoi usarlo e avere benefici molto evidenti.



  ngw


 perfezione.



Non mi sembra che siamo messi così male: 
http://kangax.github.io/compat-table/es5/




  ngw


 perfezione.



Perchè IE è il classico standard di fatto, e non so se millanta piena aderenza allo standard Ecma (e non so se tutti gli altri browser in realtà hanno o dichiarano pieno supporto ad esso).

Questa mancanza di standard rispettati non rende certo lo sviluppo web più semplice.


 Non mi sembra che siamo messi così male: 
http://kangax.github.io/compat-table/es5/




Interessante (a parte la nota "some of these tests represent existence, not functionality or full conformance").

Tuttavia basta visualizzare i browser considerati obsoleti per vedere un sacco di rossi. 


 webapp... IMHO eh, che poi si parte con gli insulti...



posso solo dirti ci sono framework ben più consistenti e testabili di 

extjs, che da questo punto di vista è fra i peggio (uno dei tanti motivi 

per cui l'ho bannato). poi ovviamente non ho la pretesa di convincere 

nessuno.








Dissento fortemente nel considerare IE "classico standard di fatto".

C'è da considerare invece che IMHO se parliamo di javascript la compatibilità 

tra browser è maggiore rispetto al rendering dei CSS.

Va anche tenuto presente che dipende da che versioni dei vari browser vogliamo 

usare e questo dipende da una scelta "filosofica" personale (es: me ne frego 

del tutto di chi usa IE <= 8), o dovuta a costrizioni commerciali.



ciao

Gabrieel


 nessuno.



Mi pare di capire che in un certo momento questo Extjs era il framework sulla cresta dell'onda, infatti qui l'hanno usato in molti. Solo dopo ci si è accorti che ha molti difetti, e magari sono arrivati dei sostituti più validi. Instabilità come questa sono molto negative quando il software supera una certa complessità.


 del tutto di chi usa IE <= 8), o dovuta a costrizioni commerciali.



Chiaro, al limite puoi pure fare un'applicazione del tutto non compatibile con IE.




Vengo or ora dal cesso dove i tuoi post mi hanno dato un utile effetto 

lassativo. HTC ONE M7, sito dell'ansa, sezione tecnologia, link timeline 

di Apple su mobile, apro e dopo 30 secondi mi girano le palle perché è 

inusabile e mi fa effetto astringente e quindi devo rinunciare.



Vai e divertiti a gingillarti con le wepapp, forse tra altri 15 anni ci 

sarà qualcosa di decente per il loro sviluppo senza avere team dietro 

che devono buttare il tempo rincorrendo idiozie.








:-D Gli unit testing per sgamare lato app i problemi dei fxs che vengono 

usati.

Ma vai a cagare va.








Quindi se uno nel frattempo ci ha scritto un'app sopra, si attacca, 

diciamo. Oppure se la riscrive in buona parte (tutto quello ruota 

attorno alla UI, che non è poco!) per andare verso altri fx fatti meglio.

Diciamo quindi che con le webapp il fattore fortuna conta enormemente... :-)




 attorno alla UI, che non è poco!) per andare verso altri fx fatti meglio.





Basta che i costi li scarichi sul cliente, inventandoti chissà quali fantasmagorici miglioramenti con il nuovo framework, ed ecco che vai alla grande :-))




Il gioco tra i fx potrebbe essere effettivamente un vantaggio per il 

ciente finale, visto che certe richieste legate alle funzionalità reali 

della app spesso sono relegate in fondo alla lista delle cose da fare.

Per poter fargli andare bene il cambio del fx con tutto il tempo e 

quindi i dindi necessari allo sviluppo (cosa che al cliente finale in se 

può fregar di meno), il fornitore sarebbe per forza di cose costretto ad 

inserire nelle nuove versioni anche un po' di implementazioni funzionali 

richieste e che erano finite diciamo nel dimenticatoio... :-D Ma neanche 

tanto :-D





Più passa il tempo e più è difficile farlo. Fino al 2005 IE aveva un monopolio pressoché assoluto e faceva mercato da solo, da molti anni si sono ristabiliti gli equilibri e il mercato lo fa (finalmente) il W3C.

Ormai basta solo sapere programmare degnamente sul client che le differenze non sono così tante, e principalmente sono coperte dalle librerie.

Fino a poco tempo fa per dire c'era un modo di far girare un frame con il motore di Chrome e quindi usare quello per tutto (
http://blog.chromium.org/2013/06/retiring-chrome-frame.html
), non lo mantengono neppure più perchè tra un browser e l'altro non c'è piu' tutta questa differenza, e anche con l'aiuto di librerie come 
http://modernizr.com/
 si riesce a lavorare bene.



  ngw


 che devono buttare il tempo rincorrendo idiozie.



Tutto apposto, puoi calmarti adesso, va tutto bene.

Ciao neh



  ngw



Se vuoi ci vado, ma si, gli unit test ti aiutano a capire se stai chiamando una funzione con gli argomenti errati. Tipo servirebbero a quello.

Ma tranquillo, tutto bene.



  ngw



p.s. continuano a sfuggirmi che cosa sono gli "fxs"


 





ascolta, al di là di questo megaflame che è saltato fuori,

che io non avevo assolutamente alcuna intenzione di

generare col mio racconto, la questione è molto semplice:

il framework (extjs) in quel caso richiede di impostare

la proprietà con un valore numerico (in realtà la potresti

anche impostare con un valore stringa che rappresenta una

percentuale, ma questo esula dal contesto). Invece, evidentemente

per disattenzione di chi ha scritto il codice di quella parte

dell'applicazione, è stata impostata con una stringa, la quale

voleva essere un numero, ma era invece una stringa, e questo ha

fatto incazzare extjs, colla conseguenza che si sputtanava

la visualizzazione.





Quindi, sulla scarsa affidabilità delle web app si può discutere,

ma in questo caso non questo c'entra un tubo: qui si

tratta di un uso errato del framework, perché una property che

è un numero (come è specificato nella documentazione) è stata messa 

come stringa.



Inoltre quest'opinione che tu qualche messaggio fa hai attribuito

a me, che le webapp è un miracolo se funzionano, l'hai espressa

tu, io non avevo alcuna intenzione di dire nulla del genere.



Ho solo voluto mostrare un esempio di come un uso errato del

framework può portare a dei problemi che apparentemente

sono di passaggio da browser a browser, ma invece sono dovuti

a un bug nella programmazione, come appunto in questo caso.

Questo è quanto.







Poi sulla scarsa affidabilità delle web app si può certamente

discutere, ma al riguardo io penso che non sempre è colpa

della scarsa affidabilità delle tecnologie, bensì dell'uso

scorretto che si fa di esse, vuoi per poca conoscenza, vuoi

perché c'è poco tempo, vuoi per altre ragioni del genere.

(e il caso da me riportato, appunto, ne è un esempio).

Certamente ci sono tecnologie che non sono il massimo, ma

secondo me molto ci mettono anche gli sviluppatori. 




Peccato pensavo di imparare qualcosa e invece no, da uno che ne sa tanto 

poi non è uscito nulla.

Comunque alla fine cagare ho cagato quindi un po' sei stato comunque utile.

Bye bye.








Ovvio, compresi quelli che producono fxs a nastro per il gusto di farlo.

Ma quanti fxs conosci ormai che vivono lato bw?

Non sono un po' tanti? Diciamo troppi?








fx = framework? Perché la x?



Così ho imparato ai tempi delle abbrevizioni con il .net framework (.net 

fx per l'appunto).

Credo che fw non sia stato usato perché già usato per firewall.




 Comunque alla fine cagare ho cagato quindi un po' sei stato comunque utile.



Anch'io, riso ho riso, dimostrato la cialtronaggine ho dimostrato, tante belle cose.



  ngw


 Fino a poco tempo fa per dire c'era un modo di far girare un frame con il motore di Chrome e quindi usare quello per tutto (
http://blog.chromium.org/2013/06/retiring-chrome-frame.html
), non lo mantengono neppure più perchè tra un browser e l'altro non c'è piu' tutta questa differenza, e anche con l'aiuto di librerie come 
http://modernizr.com/
 si riesce a lavorare bene.



Buono a sapersi.


 virtuali dei loro "fratelli computer"  più potenti :-)



hai colto il punto ;-)

Per di piu', molto spesso usando librerie su librerie si perde il senso del problema in se, conoscendo solo superficialmente come una funzione produce il risultato. Implementando tutto da zero porta a riflessioni interessanti. Per dirne una, anche la semplice lettura/scritture dei files partendo dalle specifiche del formato, porta a ragionare su come poter inserire il pre-processing dei dati mentre blocchi di dati vengono caricati in memoria, tipo l'analisi delle ridondanze, e tutta una serie di analisi specifiche, che su giga e giga di dati hanno un peso. Non utilizzando librerie algoritmiche, poi, lo scenario si amplia esponenzialmente, mettendo a nudo molte delle limitazioni algoritmiche piu' che implemetative, e dando spunti di riflessione ancora piu' interessanti. IMHO, e' molto piu' divertente che imparare l'nesimo linguaggio, che usa le nsime librerie. Poi, son punti di vista, e dipende molto dal contesto e dal tipo di lavoro che uno fa.


 enormemente... :-)



anche questo è probabilmente vero dal tuo punto di vista. 




Che tu abbia dimostrato qualcosa è un'affermazione godbile, però io più 

di una volta al giorno non cago, me la tengo per domani.

Se mi ritappo ti cercherò visto che funzioni.






 enormemente... :-)



anche questo è il tuo punto di vista. mica ho detto che gli strumenti si 

scelgono a caso per parlare di fortuna. e neanche ho detto che i programmi 

scritti in extjs ad un certo punto scadono e vanno buttati. noi abbiamo 

deciso ad un certo punto di usare altri framework ma il pregresso non è 

che lo abbiamo dato in pasto ai maiali, per alcuni programmi abbiamo 

riscritto il front-end e altri invece li continuiamo a manutenere così 

come sono.


 scelgono a caso per parlare di fortuna.

Quanti fxs lato browser esistono ad oggi? Circa.




 passato.



Eh bè, questo dovrebbe essere il minimo sindacale di una libreria o framework, che si vuole qualificare come  professionale, più ancora se a pagamento.


 Quanti fxs lato browser esistono ad oggi? Circa.



framework javascript:



http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks




framework css:



http://en.wikipedia.org/wiki/CSS_frameworks




gli elementi per valutare non mancano. 


 Unit testing, questo sconosciuto.



Battute a parte, s�, possiamo definirlo davvero come "sconosciuto". 

Ovviamente dipende dal contesto, dall'ambito applicativo e da tante 

altre cose, ma il pi� delle volte lo unit testing � snobbato.



In diversi ambienti in cui ho lavorato, per lo pi� realt� di una certa 

dimensione, scrivere codice che "non fa niente se non verificare altro 

codice" � considerata una vera e propria perdita di tempo, soprattutto 

da parte dei. Concetti come testing di unit�, continuous integration, e 

qualche volta persino il controllo di versione, sono difficili da far 

digerire.



Io personalmente attruisco parecchia importanza a queste attivit�, anche 

se non le applico in modo "purista". Cio�: prima disegno le classi e ne 

scrivo il codice, poi i relativi test. Inoltre, nella mia esperienza 

vale la pena di "perdere" (o meglio: "impiegare") tempo a scrivere test 

di unit� (e, non dimentichiamo, mantenerli aggiornati!) non di tutto il 

codice, ma solo delle funzionalit� pi� delicate e complesse. Perci� mi 

accontento di una copertura intorno al 50%.



Nel caso in questione, usando un valore costante con o senza apici nel 

codice, con un linguaggio compilato ti accorgeresti immediatamente 

dell'errore gi� in fase di compilazione invece che perdere ore a capire 

il problema in fase di runtime.



TheStar


Il giorno martedì 23 settembre 2014 11:05:25 UTC+2, TheStar ha scritto:


Sono d'accordo, la scrittura delle unità di test è in sostanza scrittura di codice aggiuntivo, che ha suoi costi in tempo e sforzo (e può perfino avere i suoi bug! :-), e pertanto non si può nè applicare a tappeto, nè può essere l'unico mezzo di verifica della qualità del codice. 

Anzi, dovrebbe essere preferibile ricorrere a tutti i sistemi di verifica statica del codice, a cominciare dalla scelta di linguaggi più attrezzati in tal senso, nella  compilazione e con strumenti specifici. 

Ma spesso neppure questo si fa, nelle "grandi realtà" :-)












Mancherebbe la colonna "developers feedback"...




 Mancherebbe la colonna "developers feedback"...



seriamente: davvero pensi non si trovino feedback su bootstrap o angularjs?






In giro per la rete di certo, mi stavo riferendo al riepilogo di 

wikipedia. Partendo da la e andarsi a cercare i feedback per gli enne fx 

è alla fine questione di fortuna...

Comnuque mi segno la coppia bootstrap e angularjs, se li avete scelti li 

in officina un buon motivo ci sarà. Ma per curiosità li si va di setter 

con validazione interna o è tutto gioco sulle proprietà che possono 

ricevere il mondo e pazienza così?




 ricevere il mondo e pazienza così?



'scolta, fai una cosa, vai su uno dei tanti siti che vendono temi a poche 

decine di euro, comprane uno già fatto e tanti saluti. questa polemica sui 

json senza setter veramente non si può sentire.


 software supera una certa complessità.



conosco il tuo punto di vista e quindi so che stenterai a crederlo, ma ci 

sono informatici a cui la vivacità delle community di sviluppatori non 

provoca codesto shock anafilattico. addirittura ritengono che evolvere in 

meglio sia pure un fatto positivo, pensa te.




 meglio sia pure un fatto positivo, pensa te.



Il mio punto di vista è che (evoluzione in meglio) <> (rifare le stesse identiche cose ma con diverso framework, libreria, linguaggio, ecc.) :-)

Per cui, se mi dici di usare per diversi progetti lo strumento più adatto, scelto da un certo insieme, sono anche d'accordo con te, magari non ottieni miglioramenti eccezionali ma vedi cose nuove. Tuttavia in tanti casi si tratta proprio di rifare uno stesso sistema con il nuovo tool del momento, con qualche tocco estetico, ed il tutto dopo pochissimo tempo dalla realizzazione precedente. Ebbene sì, questo mi manda in shock anafilattico :-))

Aggiungo che non mi dispiace approfondire il funzionamento dello strumento, e più questo è complesso più tempo ci vuole per usarlo con piena padronanza. Pertanto diffido dei cambiamenti continui, che spesso sono segno di superficialità, del cambiare tanto per cambiare (comunque anche a me capita, eh :-).

E poi la valutazione migliore-peggiore, intesa in senso oggettivo e non soggettivo, è cosa molto complessa. Basta vedere da questa discussione su ExtJs.




Vabbe' a livello di json non si può fare ho capito, devo dedurre che 

anche il recupero da json dei valori delle proprietà e la loro 

applicazione in giro per il dom e le classi css non sia fatto perché 

immagino farebbe diventare il fx più grosso in termini di spazio e 

perché rallenterebbe il rendering.

Contenti voi a fare UI così, per me non è un problema... :-)




 su ExtJs.



ma ti dirò di più, fare queste valutazioni su un qualcosa che non si è mai 

visto e conosciuto rasenta l'impossibile. però converrai che averci 

lavorato qualche anno e conoscere il dominio un pochino aiuta. 


 perché rallenterebbe il rendering.



deduci pure quello che vuoi, su questo ragionamento ormai non ti seguo più.



Senti, io di fx lato bw non ne ho usati, a parte un po' di jquery a 

livello direi basico.

Ma abbi pazienza, non puoi dire che non mi segui, per dire, in jquery ci 

sono enne metodi per valorizzar proprietà a destra e a manca, quei 

metodi internamente faranno anche delle validazioni immagino.

Un approccio simile negli enne fx per fare le UI non c'è?

Non mi par una domanda ne' idiota ne' fatta per il gusto di rompere le 

palle.




 metodi internamente faranno anche delle validazioni immagino.



immagini male. se te alla funzione $.ajax invece dell'url gli passi della 

fuffa, quello che succede è che schianta con tanto di stacktrace nella 

console. e non vedo che altro dovrebbe fare. 



Sta benissimo, il giorno che ci sarà una validazione dentro al metodo 

chi lo usa non dovrà fare nulla e si troverà qualcosa di migliore a 

gratis lato fx. Parlo in generale mica solo per quel metodo specifico.

Comunque ok, ho capito che lato bw i fx sono da prendere con le 

stra-pinze, la facilità di commettere assurdità senza rendersene conto è 

altissima. Magari in futuro miglioreranno.




 affatto parlando di rifare le stesse identiche cose.



Non so di cosa parli tu, io mi riferivo al rifacimento, alle nuove versioni di una stessa applicazione.


 versioni di una stessa applicazione.



appunto, a conferma di quello che dicevo sopra.



comunque: in primo luogo, in questi framework il front-end è separato 

dalla applicazione e l'eventuale rifacimento è tutt'altro che traumatico. 

in secondo luogo, chi ha detto che uno deve mettere le mani nel pregresso? 

extjs non è mica un progetto defunto, i progetti continuano ad essere 

manutenibili e la "foga del rinnovamento" è tutta nel tuo immaginario. da 

noi gran parte dei progetti fatti con extjs rimangono in extjs e saranno 

migrati ad altre tecnologie se e quando ci saranno i presupposti. avanti 

si va prima di tutto con i nuovi sviluppi come è ovvio che sia.


 altissima. Magari in futuro miglioreranno.



anche un trapano messo in mano ad uno incapace la facilità di commettere 

assurdità senza rendersene conto è altissima. e dubito che la cosa 

migliorerà in futuro, a meno che non migliori l'incapace. ti consiglio di 

valutare questa seconda, più praticabile, eventualità.






Si vero, tipo quelli che dovendo far buchi nel cemento armato si 

ostinano ad usare un trapano invece di un tassellatore, probabile che ce 

la si faccia, in tempi enormi e buttando via un po' di punte.




 la si faccia, in tempi enormi e buttando via un po' di punte.



stai per caso dicendo che per scrivere applicazioni web ci sono strumenti 

più adatti del javascript, css e relativi framework? parliamone perché è 

interessante 'sta cosa, se te la giochi bene ci scappa anche un premio 

turing.








Esisteranno framework che faranno validazioni decenti durante il loro 

funzionamento dato che la fase di compilazione vista la tecnologia 

coinvolta non esiste?

O no perché così e più veloce scriverli, occupano meno spazio e girano 

più veloci?

Domandi facili mi pare, qualche risposta a tono magari non guasterebbe.



E per la tua simpatica domanda invece ti risponderei, come avevo già 

fatto enne post fa, in modo più diretto con: un bel terminal server con 

la app che gira nel server e sul dispositivo solo la visualizzazione 

della UI proprio alla pari di un terminale, in modo magari un po' più 

evoluto con la UI che viene generata sul server in base alle 

caratteristiche del dispositivo.




 caratteristiche del dispositivo.



secondo te una soluzione di questo genere sarebbe anche lontanamente 

competitiva con una web application sotto un qualsiasi aspetto 

(performance, costi, scalabilità, sicurezza)? considera solo che io con 

una istanza applicativa posso servire anche 300 utenti, laddove te usi 300 

istanze applicative. non so se mi spiego.
















Certo che ti spieghi. Quanta ram ti occupa l'app pool sul web server per 

300 utenti, facciamo un 3 giga? Sono un 10 mb di media per utente (non 

sono numeri a caso, ho lavorato su una web app con tecnologia ms e i 

numeri erano questi).

Dici che sia impossibile replicare la parte di UI lato app server con 10 

mb per utente? Ovviamente tenendo tutto il resto (accesso ai dati, 

security, caching, e logica applicativa) da un'altra parte. A me vien da 

dire che ce la si possa fare scrivendo codice in modo decente e usando 

componenti per la ui scritti in modo oculato (e quindi replicando gli 

stessi accorgimenti che si usano nelle web app, niente griglie o elenchi 

infiniti con scroll bar che ti fanno muovere su grossi set di dati ma 

paginazione/filtro dinamico in ogni dove).

E sarebbe tutto a vantaggio della comodità, sicurezza e facilità nello 

sviluppo, debugging compreso.




 security, caching, e logica applicativa) da un'altra parte. 



ehi ehi ehi, frena la mula! che vuol dire "ovviamente tenendo tutto il 

resto da un'altra parte"? se io ho il mio application server, dimensionato 

con i suoi (mettiamo) 3 giga di ram, vuol dire che la mia parte server è 

tutta lì. ora io non sono molto ferrato in tecnologie microsoft ma da quel 

poco che so quando dici "un bel terminal server con la app che gira nel 

server" a casa mia vuol dire che ogni singolo utente apre una sua sessione 

windows sul terminal server e lancia la sua istanza della app, con il suo 

fabbisogno di memoria, di cpu e la sua connessione al database. quindi 300 

utenti sono 300 sessioni nel ts, 300 istanze applicative e 300 connessioni 

al database. sbaglio? no perché se sbaglio correggimi pure, ma in caso 

contrario vorrei proprio capire come puoi pensare che i requisiti di 

queste soluzioni siano anche solo paragonabili. 




A me vien da dire che per webapp classiche (gestionali nelle sue 

ennemila forme) ce la si potrebbe fare.

Ovvio che webapp di marketing con ennemila effetti grafici, animazioni, 

transizioni e cazzilli vari buoni per attacchi epilettici sono escluse.




 Quello di Crawford? Io l'ho trovato ottimo invece...



Javascript: the good parts. 

"deludente" perchè mi aspettavo di trovarci qualcosa di più, invece è una raccolta di best practice che magari sono preziose per un novellino ma non c'era niente che già non sapessi di mio... e non sono certo una cima in ambito programmazione, visto che "di lavoro" faccio per lo più altre cose. 

Ben scritto e piacevole lettura, comunque. 



bye!


 moderno.



Dipende dai tuoi interessi e dai paletti che da solo ti poni. Esempi:



Python (OO "tradizionale" migliore di quella di Java) + uno tra

web.py/flask/django
;



Clojure + Ring + Compojure + l'oo di Clojure usata nel modo che più ti

sembra utile - vedi come esempio

http://thinkrelevance.com/blog/2013/11/07/when-should-you-use-clojures-object-oriented-features
 ;



Racket e programmazione web basata sulle continuations;



Smalltalk + Seaside (ancora continuations);



Scala + Lift (o uno dei tanti altri);



Haskell + Happstack, oppure Yesod oppure MFlow oppure Snapp etc.;



OCaml + Ocsigen;



Common Lisp + l'OO di CLOS se e quanto basta + Quicklisp (per i

packages) + quello che più ti piace (es. Hunchentoot, Persistent,

CL-WHO, Elephant, Parenscript, etc.);



Opa 
opalang.org
;



...





Le opzioni sono tante. Per restare su una object-orientation stateful e

una delle varie versioni dell'MVC puoi stare su Python e iniziare da

Flask o web.py visto che sono tra i più basilari, ti distraggono poco

mentre imprari le basi del linguaggio e ti fanno staccare subito dal

mondo Java (vd. "Convention Over Configuration" ad es.)



Personalmente andrei su Happstack (e pure MFlow, Elm, Fay e

Purescript) perché ho buona esperienza commerciale di Haskell oramai e

ne sono molto soddisfatto; altrimenti Racket può insegnare molto in

relativamente poco tempo (vd. le continuations, Typed Racket, e le tante

pubblicazioni di altissimo livello per/basate sui dialetti Scheme).


 Dipende dai tuoi interessi e [...]



chiaro ed esaustivo, as always ;-)



Mi aggancio qui per una pura curiosita', sapresti nominare un linguaggio iterativo, non OO, non-VM, corredato di compilatore, che non sia un ibrido di tecnologie esistenti (per esempio cython), principalmente pensato per operare su array lunghi (diversi giga) su operazioni piu' che altro algebriche/trigonometriche in ambito reale e complesso (FFT/IFFT)? Oltre ai classici C/Fortran/Assembly, che tu sappia c'e' qualcosa di nuovo/promettente sul mercato? Magari orientato a computazioni parallele? Python (NumbaPro)? Altro?


 orientato a computazioni parallele? Python (NumbaPro)? Altro?



julialang.org
 senza dubbio -- parente stretto di Common

Lisp e Dylan, è OO e homoiconic (ha le macros), sistema di compilazione

dinamica simile a quello di Clozure Common Lisp, è unityped con type

tags a runtime (ovvero "dinamico", ma con buona type inference e

ulteriore possibilità di dichiarare i tipi per performance), è

veloce. Speravo in un sistema di moduli più raffinato (sono abituato

allo stato dell'arte dei linguaggi ML) ma va bene così.



http://docs.julialang.org/en/latest/manual/methods/#man-methods


http://docs.julialang.org/en/latest/manual/parallel-computing


http://docs.julialang.org/en/latest/manual/linear-algebra




Non farti impressionare negativamente dall'OO, è basata sulle funzioni

generiche e non sulle classi e supporta i multimethods/multiple dispatch

come CLOS e Dylan. Un modo di fare polimorfismo molto migliore di quello

di diversi linguaggi mainstream, basta capirlo.


 di diversi linguaggi mainstream, basta capirlo.



anche il polimorfismo in esecuzione mi tocca poco, se non per stream raw di dati in I/O magari, per il resto preferisco definire in compilazione: non scrivo librerie e il tipo di dato su cui lavorare lo preferisco decidere in base al problema. Pero' mi sembra interessante come gestisce i numeri complessi, c e c++ fanno un pastrocchio indicibile.




 indicibile.



vedi 
http://arxiv.org/abs/1407.3845
 e l'altra docs. Diciamo che se uno

certa un linguaggio dalle proprietà più prettamente statiche con Julia è

meglio non partire proprio.


 meglio non partire proprio.



ok, tnx.


 vantaggio non da poco del singolo vettore e' col padding ;-)



Che compilatore/arch e con quali opzioni per l'analisi dell'aliasing?

Con un ambito di impiego così ristretto io proverei Fortran 90 con

OpenMP e MPI e tutte le varie versioni/piattaforme per l'high

performance (es. Fortran su CUDA, vettorizzazione di Intel, etc.).


 io proverei Fortran 90



qui intendevo almeno 


 performance (es. Fortran su CUDA, vettorizzazione di Intel, etc.).



Se e' per CUDA tanto vale rimanere al C, o fare lo sborone e andar giu' di Assembly :-)






 giu' di Assembly :-)



asm per i kernel computazionali ok soprattutto se con l'aiuto di qualche

framework adatto.  Ho pensato alla domanda iniziale ovvero se c'è

qualcosa di interessante in giro etc. Penso che da quando è stato

cancellato Fortress non ho intravisto nulla che m'incuriosiva (a parte

Julia). Qui 
http://www.sable.mcgill.ca/array
 c'è da seguire

qualcosa. Non dovendo fare più di quello che Data Parallel Haskell e

Repa già mi fanno risolvere non mi pongo il problema. Usare piattaforme

come CUDA da linguaggi meno obsoleti di C e C++ mi interessa sempre

invece - Accelerate (Haskell) così come altri linguaggi embedded per le

GPGPU ad esempio sono molto interessanti (spesso anche questi con target

gli array multi-dimensionali).




 gli array multi-dimensionali).



Da qui vedo spunti molto interessanti anche per me, principalmente Data Parallel Haskell e Accelerate Haskell. Gli array multi-dimensionali, ripeto, mi interessano sempre di meno, sono inutilmente complessi da gestire, memoria permettendo un array 1D per dati multi-dimensionali IMHO snellisce il codice e rende la vita piu' facile per tante piccole cose, poi se uno non si vuole sbattere a calcolare l'offset e' un problema suo e di chi gli deve costruire linguaggi su misura, io me ne tiro volentieri fuori :-)






 celato :-)



Non si tratta di definizioni formali, sono proprio cose diverse. Nel

Dragon Book ad esempio trovi tutto spiegato (propagation, synthesis e

inference dei/sui tipi) in termini assolutamente informali. 

L'implementazione Steel Bank di Common Lisp è un ottimo esempio dove

vedere sta roba in azione.


 vedere sta roba in azione.



far beyond my interest :-)

Grazie comunque per gli spunti di riflessione degli altri post!