Newsgroup: it.lavoro.informatica
Titolo: Yes, I am a terrible coder, but I am probably still better than you :)

Il Rasmus Lerdorf  pensiero è decisamente da approfondire...   tipo

lui classifica 4 tipi di programmatori :



- Il primo tipo : il pragmatico che semplicemente risolve i suoi

problemi



- Il secondo che intende la programmazione come espressione di se

stesso, tipo un artista



- Il terzo è il programmatore vero, a cui piace programmare a

prescindere perché gli provoca rilascio di oxitocina



- Il quarto è  il programmatore open source che vuol cambiare il mondo





Direi che io nasco del terzo tipo, ma visto che è un po' come giocare

online : anche se sei molto bravo rischi di finire la carriera a

lavorare al Mac.. sono scivolato felicemente nel primo tipo :-)












Che differenza c'è?





Equinozio grafomane.







Ciao!

---

none^none


 lui classifica 4 tipi di programmatori :



Per me ci sono solo due tipi di programmatori:



- quelli con cui potresti passare le ore a parlare di djb, jwz, dmr...



- "gli altri"


 lui classifica 4 tipi di programmatori :





...programmatori, mezzi programmatori, programmatoricchi e 

quaqquaraqqua'...:-)



ciao

fm 






 lavorare al Mac.. sono scivolato felicemente nel primo tipo :-)



bah insomma, io nel rifiutare l'uso delle espressioni regolari per una

mancanza di fiducia preconcetta (nel 2012...) tutto ci vedo tranne che

pragmatismo e senso di risoluzione del problema.



nella prima categoria ci vedo quei personaggi a metà fra il

programmatore e il sistemista, grandi conoscitori di un linguaggio di

scripting cazzuto tipo perl, i quali approcciano il problema con poche

ma risolutive righe di script.









e "gli altri" sono i migliori



-- 

Soprano






Il primo magari identa bene, tiene il codice in ordine, il secondo invece 

cazzuola li le righe?

A me chi cazzuola li le righe, indipendentemente da tutto il resto, mi fa 

girar le balle... :-)




 pragmatismo e senso di risoluzione del problema.



Si, parliamo di te invece. Te invece che tipi di software fai ? Che

tipo di approccio usi ? E i software prodotti quanti bug contengono ?

Vanno bene ?



Sempre senza scendere nel dettaglio certo, pur parler.






 lui classifica 4 tipi di



Platonizzazione irreale e non necessaria.



Capisco che possa derivare da deformazione professionale, ma non per questo ha una qualche base sostanziale.



-- 

ale

http://ale.riolo.co.uk




Nella mentalità italiana, sicuramente.


 Capisco che possa derivare da deformazione professionale, ma non per questo ha una qualche base sostanziale.



E di un Joel Spolsky che da del duct tape programmer a jwz, che ne

pensi invece? Riduzionismo compulsivo o semplicemente gli rode di non

avere un gruppo dedicato su alt.fan? :)


 avere un gruppo dedicato su alt.fan? :)



Si torna sul pragmatico :



Duct tape programmers are pragmatic. Zawinski popularized Richard

Gabriel’s precept of Worse is Better. A 50%-good solution that people

actually have solves more problems and survives longer than a 99%

solution that nobody has because it’s in your lab where you’re

endlessly polishing the damn thing. Shipping is a feature. A really

important feature. Your product must have it.



[cut]



One principle duct tape programmers understand well is that any kind

of coding technique that’s even slightly complicated is going to doom

your project. Duct tape programmers tend to avoid C++, templates,

multiple inheritance, multithreading, COM, CORBA, and a host of other

technologies that are all totally reasonable, when you think long and

hard about them, but are, honestly, just a little bit too hard for the

human brain.



[cut]



Duct tape programmers don’t give a shit what you think about them.

They stick to simple basic and easy to use tools and use the extra

brainpower that these tools leave them to write more useful features

for their customers.





Stai attento: quell'articolo è scritto sul filo del "flame senza dare

troppo nell'occhio" - ogni cosa detta e come è stata detta ha più di

un perchè e se non si conoscono le vicende collegate secondo me si può

facilmente capire una cosa per un'altra...


 facilmente capire una cosa per un'altra...



Mah. Per prima cosa denuncio la mia totale ignoranza sui guru della

programmazione, conoscevo la storia del Worse is Better e mi ha fatto

piacere ritrovarla.



Se ho ben capito Spolsky  scrive il post tentando di percularlo perché

ad esempio non ha adottato  c++ per Netscape o simili.



Ma a conti fatti Zawinski ha scritto uno dei software che hanno fatto

la storia, è uscito prima di tutti con un browser che andava e quindi

merita rispetto. Mentre Spolsky  parla parla e cita più e più volte

COM e visto che considero COM e DCOM il male assoluto,  direi che

anche per me farmi dare del duct tape da Spolsky sarebbe un onore e

quello che lui afferma in modo sarcastico a me suona piacevole.




































 considero COM e DCOM il male assoluto ...



eddai, cosa ti hanno fatto di male ? 






 pensi invece?



Parliamo dello stesso personaggio che basava il principale prodotto

della sua società su un linguaggio di programmazione sviluppato

specificamente per quel prodotto, definito da lui stesso un dialetto

"funzionale" di basic che produceva codice VBScript, che secondo lui

era necessariamente più veloce di qualsiasi codice a tipizzazione

dinamica?



Poi, onestamente, di tanto in tanto qualche articolo interessante lo

scrive pure, e non scrive male, ne ho raccomandati diversi anch'io in

passato, ma bisogna leggerlo con un bel po di sale ...



--

ale

http://ale.riolo.co.uk



 eddai, cosa ti hanno fatto di male ?



Quella è cacca, e più la muovi e più puzza..




 - Il quarto è  il programmatore open source che vuol cambiare il mondo



1+2+3? In ordine direi: 3,1,2 :)



Al3x


E nessuno fa unit testing e test...:-)







non so perché t'incazzi. rifiutare irragionevolmente strumenti

specifici non colloca nella categoria dei pragmatici, questo è

evidente, al limite in quella di chi pratica l'arte (sempre nobile,

per carità) dell'arrangiarsi.


 per carità) dell'arrangiarsi.



Veramente te l'ho chiesto per capire se parli in astratto o in reale.








"cazzuola li le righe" è molto bella.



vallo a capire cosa avrà voluto dire.. ma mi viene il mente che

"l'artista" scrive per se stesso ed interpreta il lavoro come un'arte.

I primi che mi vengono in mente sono gli hacker, ma comunque chi

scrive software per produrre qualcosa che lo rappresenti, che sia un

gioco o un compilatore. Il real programmer invece si diverte a

scrivere codice e basta pure fosse per Telecom :-)


 Veramente te l'ho chiesto per capire se parli in astratto o in reale.



eccerto che parlo in reale. vuoi sapere se faccio i test oltre che a

parlarne? certo che si.




 parlarne? certo che si.



si, chiedevo l'abito. Che software fai ? Forum sul web, combinatori

telefonici, controllo razzi...








 Il Rasmus Lerdorf  pensiero è decisamente da approfondire...



.. ma dai..  cosa vuoi che ci sia da approfondire nel pensiero dell'

"Immane Cretino"?? (cit. professorino moTesto) :)



Per tutti quelli che non soffrono di problemi psichiatrici consiglio

anche di ascoltare almeno la parte iniziale di questa presentazione,

in cui l ' "Immane Cretino" spiega con grande chiarezza e modestia lo

spirito, la filosofia e i motivi pratici che hanno portato alla

creazione di PHP e al suo successo...



http://www.youtube.com/watch?v=V1O4H5pz-c8



 telefonici, controllo razzi...



vari tipi di progetti. a oggi lavoro ad una applicazione web su

internet rivolta ai consumatori e a un sistema di schedulazione task

centralizzato, il primo è un progetto mio (cioè nostro, insieme ad

altri) il secondo è una commessa di un cliente. lavoro nella jvm ma

non in java bensì in scala.








 rimasto a che non ti fidi.



non adotto le regex perché le considero rischiose non inaffidabili.

Ovvero considero troppo pericoloso scrivere una regex complessa in

quanto penso sia più probabile che contenga errori rispetto ad un

codice esteso. Non perché l'engine regex non funzioni, sono sicuro che

lui funziona benissimo. Ma sono anche certo che prima o poi io o

altri  junior sbagliamo la sua scrittura e che tale errore non sarà

facilmente individuabile.



visto che un errore non rilevato in una fase critica come quella

potrebbe portare ad un notevole danno economico, il vantaggio di usare

le regex non vale per me il rischio che giudico introdotto dalle

stesse.












A me rende molto bene l'idea vedendo certi sorgenti... il code troweler :-)






 individuabile.



mentre invece immagino ti fidi ciecamente dello stesso junior che al 

posto di scrivere una riga di codice ne scrive n inventandosi il suo 

string tokenizer. però così l'eventuale errore è facilmente 

individuabile, già ma come se non implementi i test? cerchi i bachi con 

il code review (sieh buonanotte, e quando li scovi)? 


 il code review (sieh buonanotte, e quando li scovi)?



mmhhh, no, no. Lo junionr non scrive nessun "string tokenizer", lo fa

a mano il parsing con tante belle substring o il comando equivalente

del linguaggio equivalente.



 il code review, nello specifico caso è talmente banale che non puoi

non vedere l'errore. Se si rendesse necessario uno "string tokenizer"

per flat file il suo sviluppo sarebbe accettabile solo se anche il suo

engine rimane così semplice da essere banale, altrimenti si utilizzano

altri strumenti, magari anche le regex.


















 non vedere l'errore.



io non credo proprio che fra "tante belle substring" sia così banale

trovare un errore, ad esempio, di un indice sbagliato semplicemente

leggendo il codice. anzi per dirla tutta la ritengo fra l'improbabile

e impossibile.

e poi le "tante belle substring" si traducono in una espressione del

tipo (buttata giù a caso) "^(.{10})(.{12})(.{10})". illeggibile?

immanutenibile? siamo seri per favore...


 li consideri errati.



Però te l'avevo preannunciato che avresti capito una cosa per

un'altra, non inquadrando la faccenda correttamente...



Il C++ è stato standardizzato nel 1998, quello di cui si parla è

accaduto anni prima quando il supporto a templates e compagnia era una

vera e propria giungla fatta di compilatori, hacks e chi più ne ha più

ne metta - la necessità di supportare una certa codebase su 3

piattaforme diverse e in ambiente di sviluppo altamente distribuito

(leggi: l'intero Pianeta Terra) completa il quadro. Non si tratta di

alcuna "scelta molto forte", è stata de facto la scelta di molte

persone all'epoca che sapevano bene cosa facevano (anche in progetti

meno ampi e non distribuiti).



E no, non vedo alcun nesso tra le tue scelte (quali poi? F# per tua

stessa ammissione non lo conosci per nulla poi) e quelle di jwz

dell'epoca.


 passato, ma bisogna leggerlo con un bel po di sale ...



A memoria meritano il Joel Test, The Perils of Java School e la guida

alle interview e altro. Per il resto non si sopporta.


 immanutenibile? siamo seri per favore...



si, quella è la tua opinione, rispettabilissima. Io ne ho un'altra,

rispettabile come le tua. E' per questo che il "siamo seri" è

supponente. Ma tant'è.


 dell'epoca.



non avevo nessun dubbio.



a equino', non è che stiamo a parlà delle partite di iersera. le 

questioni tecniche non sono sempre e comunque opinabili, altrimenti che 

studiamo a fare se alla fine basta avere un opinione che vale come 

un'altra? il "siamo seri" è riferito al fatto che quella domanda è 

retorica, mi dispiace se ci vedi supponenza ma temo non sia un problema 

mio. io trovo più supponente che uno ci provi a farmi bere a garganella 

quello che dice, pedditte.




 un'altra? il "siamo seri" è riferito al fatto che quella domanda è



Sono io che dico "siamo seri".



La tua risposta è la decisione non è opinabile, e la giusta è la tua,

non solo ma io sono anche più ignorante/incapace. Su che basi ? Sullo

studio ? Che studio ? Dove sta scritto ? Chi è che scrive che usare le

regex per parsare un file piatto è l'unica soluzione ? O la migliore ?

O che sia furbo ?   Siamo seri ! Vediamo le fonti, vediamo chi lo dice

e che autorevolezza ha.



I parser più usati forniti con Oracle o con SqlServer le usano

forse ?  No.



E questi usano tutti le regex ?



http://www.google.com/#hl=en&output=search&sclient=psy-ab&q=parser+flat+file&oq=parser+flat+file




No



E quelli scritti in java ?



http://www.google.it/search?rlz=1C1SVEF_enIT454IT454&sourceid=chrome&ie=UTF-8&q=java+parser+flat+file+




No



Tocca chiamarli subito, vedi che non hanno Studiato nemmeno loro.

Siamo seri.



E guarda che volevo veramente evitare di entrare in una discussione

inutile e sterile come questa a chi ha ragione, perché sia chiaro che

anche te hai la tua parte di ragione.



Io sono sicuro di non averla ragione, sicuramente non tutta, mai e di

sbagliare e spesso. Chi pensa il contrario di se stesso è un problema

suo.








 forse ?  No.



Perdona se taglio su tutto il resto, siamo alle solite, parli di cose che conosci molto poco e molto male buttandola sull'opinione, been there done that.



Le espressioni regolari sono presenti in praticamente qualunque libreria standard conosciuta. Sono nella libreria standard di C#, che "molto" apparentemente usi, e nella libreria standard di Java. In Ruby e in Perl hanno una sintassi e un matcher specifico. Sono presenti in Python, in PHP, in Clojure, in Scala, in F#, in Haskell, in Javascript e toh, in Brainfuck. In C e C++ non sono nella libreria standard, essendo linguaggi a basso livello, ma sono notoriamente estremamente usate. Buona parte dei server comunemente usati hanno un parser basato su regexp, tipicamente sul motore pcre, usato principalmente per il parsing del protocollo. Apache, Postfix e Nginx sono i primi che mi vengono in mente, che usano abbondantemente le espressioni regolari nelle loro configurazioni. Buona parte dei comandi Unix che hanno a che fare con il parsing di testo usano le espressioni regolari: find e grep ad esempio. Non uso Windows da molto, ma temo che anche li non ti vada meglio, PowerShell sembra usarle estensivamente. Awk usa le espressioni regolari. I maggiori generatori di parser usano regexp, vengono in mente Lex, Ragel e Quex. 

Il parser SQL di PostgreSQL e' implementato con Yacc e Lex (che strano!), le probabilita' che usi le regexp sono molto alte. Per SQLServer e Oracle non lo so, non ho i sorgenti ne particolari dettagli implementativi a disposizione. Puo' darsi che si siano fatti una DSL per il parsing specifica piuttosto che usare una sintassi che conoscono piu' o meno tutti e documentata in tutti i modi possibili e immaginabili e implementata da librerie e motori esterni risaputamente stratestati e molto efficienti. Se hai informazioni a riguardo accomodati, in caso contrario siamo al solito non sequitur.

Non mi risulta comunque che il punto fosse il parsing di un linguaggio completo e la generazione della relativa AST, mi sembra di ricordare che il punto fosse una stringhettina semplice semplice anche se mal specificata che tu eri riuscito a parsare in modo estremamente inefficiente con dello pseudocodice molto scalcinato. Il motivo per cui si e' arrivati a Oracle (tanto per cambiare) non mi e' perfettamente chiaro. La generazione di parser e' un argomento molto complesso, in alcuni casi si usano le regexp, in altri delle DSL specifiche. Nei casi in cui si usano delle DSL specifiche la motivazione e' raramente "le espressioni regolari sono inutili", e non ho mai visto queste DSL implementate con funzioni di libreria che, tra le tante cose, spesso e volentieri accettano una regexp come argomento quando non sono perfettamente specifiche (e quindi non generiche).



Ora, visto che mi pare di aver letto che le espressioni regolari sono utili per fare il parsing di una email e poco piu', forse dovresti produrre tu le fonti di questa ennesima incredibile affermazione, perche' non mi risulta. Fosse cosi', sembrerebbe che il parsing degli indirizzi email sia una delle operazioni piu' comuni e complesse dell'universo, visto che praticamente ogni lexer che conosco usa le espressioni regolari. Tra l'altro, anche il parser java che hai postato (quello C# non riesco a vederlo) usa le espressioni regolari.



Per il futuro, fare il sapientone sul parsing "posizionale" delle stringhe per dimostrare di non conoscere le espressioni regolari nel post successivo magari non e' una idea cosi' buona, specialmente quando si e' cosi' proni a farsi prendere dall'ego e ogni minima obiezione viene presa come un qualche genere di sfida. Ecco, magari non prendere un pezzo dello standard POSIX almeno.



  ngw


 Per il futuro, fare il sapientone sul parsing "posizionale" delle stringhe per dimostrare di non conoscere le espressioni



Posta, posta link di qualcuno che consiglia si usare le regex per il

parsing di un file flat, posta che sono curioso.



Dai.. vediamo. Comincio io vah.



Regular Expressions: Now You Have Two Problems

http://www.codinghorror.com/blog/2008/06/regular-expressions-now-you-have-two-problems.html




Regular expressions are not Parsers. Although you can do some amazing

things with regular expressions, they are weak at balanced tag

matching. Some regex variants have balanced matching, but it is

clearly a hack – and a nasty one. You can often make it kinda-sorta

work, as I have in the sanitize routine. But no matter how clever your

regex, don't delude yourself: it is in no way, shape or form a

substitute for a real live parser.






























 Regular expressions are not Parsers.



che è un po' come dire: il motore a scoppio non è l'automobile.

infatti lui ha ragione da vendere ma purtroppo nonostante il tentativo

di tirarlo per la giacchetta non da ragione a te che dici "per me

nell'automobile è meglio usare un bel paio di pedali che il motore a

scoppio".



e ora l'abbozzo perché mi sarei anche stufato di inseguire i cani

menati per l'aia :P


 
http://code.google.com/p/beanio/source/browse/trunk/src/org/beanio/in.
..



fail che ?



Le usa non per il parsing ma per la validazione dei dati che

eventualmente puoi passare per il campo. E neppure per tutte le

validazioni ! Non lo usa neppure per i tipi per il minimo massimo.

Cioè lo usa per la solita validazione delle email.



Cos'è hai cercato regex nel codice ?




 substitute for a real live parser.



Finalmente, siamo al cut and paste di ulteriori cose che non hai capito. Una vera e propria matrioska dell'incomprensione, quando si arriva alla affermazione di ignoranza finale e definitiva, ce n'e' sempre un'altra sotto ancora piu' ignorante e piu' definitiva.

Innanzitutto il link che posti (di Atwood, mica cazzi) sostiene l'esatto contrario di quello che sostieni tu, che molto evidentemente non sai assolutamente niente di espressioni regolari, non hai alcuna intenzione di conoscerle, e la tua posizione e', tanto per cambiare, puramente religiosa e per partito preso. Atwood sostiene che sono utilissime, andrebbero conosciute, e anzi sono indispensabili.

Quello che dice e' assolutamente normale: non sono parser. Infatti le regexp nei parser, quelli con cui si tirano su dei bei progettoni come PostgreSQL o Mongrel, sono usate per definire la singola token, il parser viene poi generato nel linguaggio di output. 

Il problema di cui parla, che dubito tu abbia capito, riguarda il match bilanciato, e francamente solo un coglione si metterebbe a fare il parsing di un intero linguaggio con una regexp, per questo Dio ci ha dato le singole token.



Comunque non c'e' proprio problema, vuoi sostenere che le regexp non servono a niente e che tirare su un parser a cazzo di cane e' una buona soluzione? Accomodati, nessun problema.



Anzi, fai una cosa, quando fai di queste uscite, tra tabelle in html, mode che casualmente corrispondono a tutto quello che non usi (quello che usi invece e' sempre molto serio e professionale), roba in realtime fatta con cron, e parti dello standard POSIX inutili e inaffidabili, metti un bel tag <opinione equinozio>, che taglio ed evito di perdere del tempo con uno che di fronte al fatto che Ragel e' basato sulle regexp e' ancora in grado di trattarle come cazzatelle e restare serio.

Posso fare lo stesso se vuoi. E' che dovresti imparare le regexp.



  ngw


> Posso fare lo stesso se vuoi. E' che dovresti imparare le regexp.



Quindi secondo te, il miglior modo di fare il parsing di un grosso

flat file posizionale contenente tipi semplici è usare le regexp.



Cioè, è questo che dici giusto ?



E ne sei convinto. Per capire, me lo confermi ?  Poi non rispondo più,

giuro.

















Si.

Puoi procedere con il file di un grosso file "posizionale" senza ne capo ne coda e nessuno schema apparente onde dimostrare che ho torto, che sei piu' imprevedibile dei film porno.



  ngw






Perché, da quando in qua le regexp sono efficienti?

C'è gente che ha scritto che eliminando le regexp dal cms sotto ad un sito 

web ha avuto come effetto un boost delle performance quasi da cambio server.

E' un dettaglio da poco?






 E' un dettaglio da poco?



Hai un riferimento? Detta cosi', e' una cagata talmente grande e su talmente tanti livelli che fa ridere.



  ngw






http://blogs.aspitalia.com/daniele/post2176/Performance-Contano.aspx




Vabbe', non è riferito solo all'eliminazione dell'uso delle regexp, fatto 

sta che pesano, ovviamente.

Tu quanto le hai usate in modo intensivo da poter dire che sono leggere e 

prestanti in ogni scenario?





Se il parsing da fare non e' estremamente banale ogni volta che devo fare parsing di testo. Ci ho anche scritto un parser markdown con Ragel, se e' per quello.

Adesso chiedo a Bochicchio come gli e' uscita quella cazzata.



  ngw



leggo dai commenti che qualcuno gli ha già chiesto lumi a proposito e

la risposta mi pare una supercazzola. che la soluzione di performance

sia una manciata di indexOf mi fa ovviamente sorgere l'altra domanda,

cioè che tipo di espressioni ha sostituito, perché string tokenizing

appena appena intelligenti non  vedo proprio come questa possa essere

una soluzione efficiente. oppure sarà l'implementazione di .net che fa

cacare, boh.






 Nella mentalità italiana, sicuramente.



No, in tutte. Uno che si pone come hai fatto tu sopra (ci siamo "noi" 

innamorati della tecnologia e poi ci sono "gli altri") è il peggior 

compagno di team che ti possa capitare di avere, anche meglio avere un 

neolaureato in letteratura che non ha mai visto un pc.



-- 

Soprano



Riporto:

"il senso del post, fatto nel 2007, è che le regexp non sono veloci se le usi quando le regex non servono. 

mi riferivo in maniera esplicita a scenari del tipo: dammi l'intero dentro un uri, che con un parsing ad hoc fai in maniera più veloce.

se c'è gente che prende info fuori contesto e glie lo da, dammi il link che chiarisco esattamente cosa volessi dire con quel post"



E in effetti, non c'e' proprio scritto che "eliminando le regexp dal cms sotto ad un sito web ha avuto come effetto un boost delle performance quasi da cambio server", che e' delirante.

La realta' e' l'esatto contrario di quanto si sostiene qui dentro, se il parsing e' banale ci puo' stare una soluzione ad hoc, se invece e' complesso le regexp sono una soluzione oggettivamente superiore.

E non e' che ne sono convinto io, e' proprio cosi', fatevi dei benchmark.



  ngw



Nella mentalita' italiana, sicuramente.

Quella dove, per intenderci, e' meglio avere nel team un neolaureato in letteratura con la coda tra le gambe che uno preparato.

Altrove se non si e' preparati si pedala, in Italia la si butta sulla relativita' e sull'opinione, e' assolutamente un classico.



  ngw



Avevo dato cenni in un altro post al riguardo, visto che la

discussione continua specifico meglio qui.

Le regular expressions vengono implementate in molti modi differenti e

alcune semplici regex possono essere sorprendentemente lente (anche

tempo esponenziale) per il troppo backtracking - in pratica non sempre

si tende al tempo lineare di una possibile implementazione come state

machine (implementazioni più semplici sono comunemente usate un pò

ovunque).



Riferimenti: Russ Cox sulle possibili implementazioni

http://swtch.com/~rsc/regexp/regexp1.html
 ,

per la teoria il solito Aho-Ullman sull'Automata.






Ho trovato questo, è roba del 2007, non so se qualcosa sia cambiato (lato 

.net intendo) nel frattempo.

http://channel9.msdn.com/Forums/TechOff/258310-Poor-performance-of-NET-Regex









Fai un esempio per cui provarci?

Intendo un esempio per cui creare codice ad hoc che faccia quel che fa una 

regex e poi verificare i tempi rispetto all'uso di una regex (che fornirai 

sempre tu ovviamente).






 E' un dettaglio da poco?



E' un dettaglio comune a tutto quello che di informatico c'è al mondo

- è interessante ma non così tanto "sensazionale" se lo chiedi a me :)




Puoi fare un esempio?





Ma io non parlo degli "innamorati della tecnologia" quanto piuttosto

degli innamorati del *sapere* - in questo senso, in troppi sono

programmatori ma non conoscono i padri fondatori della materia, o il

codice dei grandi del nostro settore. Altrove (_ovunque_, pittura,

artigianato, legge, medicina, filosofia...) è sacro osservare e

apprendere dai grandi che ci precedono, i "migliori" lo fanno anche in

informatica ed è per questo che poi ricordano iniziali, acronimi,

biografie, cosa hanno detto o fatto e quant'altro di chi ha lasciato/

sta lasciando il segno nel campo.



Cosa ci sia di male in questo lo sapete solo voi. Io tra uno che

scende dalla montagna e un altro che conosce Peter Norvig, AIMA e ha

passato del tempo a studiare tutto quello che ha trovato sul suo

website...



p.s. tu non sei *innamorato* di quello che fai e della materia? Io si,

come dello sport che pratico e di un pò d'altre cose. Perchè si tende

sempre a leggere tutto in accezione _negativa_? Me lo chiedo sempre, e

so già che non avrò mai una risposta...


 .net intendo) nel frattempo.
http://channel9.msdn.com/Forums/TechOff/258310-Poor-performance-of-NE.
..



anche quell'articolo è del 2007 quindi in ogni caso fanno capo allo

stesso problema.

però dimostra che è del tutto falso dire che le regexp non sono

performanti. ancora di più l'inadeguatezza di .net per questo tipo di

applicazioni perché un framework che ti costringe ad ottimizzare

queste cose è da non prendere nemmeno in considerazione dove c'è da

sopportare un grosso carico.




 so già che non avrò mai una risposta...



OK, ma se hai un po' di esperienza sai benissimo che sopratutto nel 

settore informatico spesso nei team va tutto a puttane perchè:



A) manca l'umiltà

B) manca la disciplina

C) c'è chi pensa di sapere tutto e di avere verità assolute



E la tua uscita "noi" e "gli altri" si inquadra in questo profilo. Ho 

visto tante volte persone che pur sapendone molto essere controproducenti 

perchè totalmente _INCAPACI_ di relazionarsi con gli altri, di evitare di 

fare sempre e comunque di testa propria, mettere da parte il proprio 

"furore intellettuale e tecnologico". 



Del resto le annose e infinite guerre di religione su sistemi operativi, 

tecnologie e quant'altro sono lì a dimostrarlo.



-- 

Soprano



Non è questione di coda tra le gambe, è questione di umiltà, che è 

fondamentale perchè un team funzioni bene. Umiltà da parte di tutti 

chiaramente.





-- 

Soprano


 non far fare ad una regex perché altrimenti sarebbe più lento?



ma di solito non è così, gli altri framework da rails a django, lift,

play! (per dire quelli che mi vengono in mente al volo) fanno

larghissimo uso delle regexp per il matching degli uri e per estrarre

i parametri. e non si può dire che alcuni di questi abbiano chissà che

problemi sotto carico.


 Puoi fare un esempio?



E' una tecnica nota nelle implementazioni, "bail out early".

http://swtch.com/~rsc/regexp/regexp3.html
  ("Bail out early")

http://code.google.com/p/re2/source/browse/re2/dfa.cc#1397



 Questa domanda non ha senso. Se non specifichi di quale



Alcune cose : le regex di .net non sono molto performanti, neppure

quelle compilate (neppure quelle di java se è per quello )  almeno in

confronto a Perl.



Tra una montagna di indexof e una regex però non so chi vince, credo

che dipenda dal motore che c'è sotto, da cosa bisogna parsare e come.



Discorso diverso nell'esempio del file posizionale dove si conosce la

posizione del campo e quindi si fanno substring che non altro che

copie parziali di array di char o in un csv dove si usa il tokenize o

split che dir si voglia  che non sono che la scansione diretta

dell'array di char in un ciclo ottimizzato. Due operazioni dove l'uso

di regex non credo abbia molte giustificazioni a parte il voler aver

ragione.




 C) c'è chi pensa di sapere tutto e di avere verità assolute



no guarda, non so dove sei te ma in italia sei fuori strada.

spesso va tutto a puttane perché:



a) le decisioni tecniche sbagliate vengono prese fuori dal team che le

subisce anche se non le condivide

b) disciplina e umiltà ce n'è fin troppa

c) chi pensa di sapere qualcosa o avere anche una sola verità viene

gentilmente invitato ad esprimerle da un'altra parte




 informatica ed è per questo che poi ricordano iniziali, acronimi,



Perché proprio quelli li sarebbero i "migliori" ? E non gli altri ?














 ragione.



Occhio che, ripetendolo ancora una volta, la discussione è nata non da

cosa sia giusto o meno usare ma dal fatto che è stata fatta

un'affermazione assurda del tipo "le regex sono *inaffidabili*". Se

torni indietro nel thread vedrai che è li che s'è scatenato tutto, e a

ragione direi io.


 tecnologie e quant'altro sono lì a dimostrarlo.



Ok, da quello che dici quindi presumo tu non abbia mai incontrato

qualcuno che parli estasiato dei posts di Chris Torek su comp.lang.c e

che non sia un coglionazzo come team player. Posso suggerirti di

cambiare/allargare il tuo giro? ;)


 ragione direi io.



Ti riferisci alla frase  :



"Le Regexp sono complesse, inaffidabili ed inutilizzabili se non in

casi semplici o da parte di persone molto esperte."  ?



lo ripeto, senza alcun dubbio. Per usarle con serenità bisogna

conoscerle molto bene, per gli altri sono pericolose ed

inutilizzabili, sopratutto se ci maneggi del denaro.



Nel mio scenario tipico hai a disposizione o lavori con i

programmatori che normalmente girano in Italia e situazioni

paragonabili a ricevere ed inviare ordini direttamente con il flusso

dati della borsa Italiana.



Te in una situazione simile faresti usare e useresti le regex, e

faresti bene anzi benissimo non lo metto in dubbio. Io uso e faccio

usare il codice più semplice e chiaro che sia possibile, in modo che

almeno se mi prendo una causa, non sia per un carattere che mi sono

scordato.



















Perchè sono più consapevoli in ogni passo che fanno.


 inutilizzabili, sopratutto se ci maneggi del denaro.



Ma dai, è palasementa falsa questa cosa. Se fosse esattamente come

dici, ora potresti citarmi una serie di casi di disatri informatici

causati dall'uso di regular expressions. Così non è, anzi si usano con

profitto da decenni in ambiti che scommetto sono di gran lunga più

complessi di quelli in cui le useresti tu eventualmente.

Questa cosa ha dell'assurdo davvero, da parte mia la chiudo qui perchè

mi pare inutile insistere.


"cpascoshi" ha scritto nel messaggio 

news:7dd7983f-4fe0-4b1f...@a5g2000vbc.googlegroups.com...


Ma è una questione di implementazione allora.

Io avevo capito che c'era da stare attenti a come si scrive la stringa che 

rappresenta la regexp da far valutare alla "black box".








Non so, vista l'introduzione nel fx 4 di una libreria (la TPL) per rendere 

più facile la programmazione concorrente e usarla pure con LINQ (PLINQ) 

dubito che gli scenari da poter gestire non siano diciamo anche enterprise.

Magari le regexp con gli anni le avran implementate meglio, boh.






 "cpascoshi" ha scritto nel messaggionews:7dd7983f-4fe0-4b1f...@a5g2000vbc.googlegroups.com...


Ovviamente l'implementazione ha ripercussioni sulle performance, il

backtracking non perdona (!). Leggi qui, per te che t'interessa .Net

direttamente dal blog del BCL team:

http://blogs.msdn.com/b/bclteam/archive/2010/08/03/optimizing-regular-expression-performance-part-ii-taking-charge-of-backtracking.aspx




L'articolo l'ho visto di sfuggita, unica nota interessante che mi

viene al volo dove dice "Backtracking often is necessary because

regular expressions are greedy". Fai attenzione a quanto spiega dopo:

di default la valutazione è greedy ma spesso puoi costruirti un

quantificatore non-greedy (ovvero "lazy") usando "?" in modo che il

match diventa minimo e quindi hai il famoso "bail out" prima che il

backtracking aumenti (andando a ritroso).

Un esempio ancora più banale e chiaro è: "<.*>" è greedy (perchè star

prova sempre ad esaurire la valutazione di tutti i caratteri passati)

mentre se lo riscrivi come "<.*?>" diventa in pratica lazy (vedi poche

righe sopra). Fico, no?


 Perchè sono più consapevoli in ogni passo che fanno.



Non c'è relazione. E' una tua ipotesi. Sia che siano più consapevoli

(potrebbero essere solo i meno originali), sia che essere consapevoli

ti renda migliore (i più bravi nello studio raramente sono i più bravi

nella realizzazione o nella creazione di qualcosa di nuovo).













direi una aberrazione del relativismo bella e buona.


 direi una aberrazione del relativismo bella e buona.



le cose vanno argomentate, non buttate lì. Non si è più consapevoli

studiando il codice dei gurù (è meglio studiare la documentazione, qui

non si fa filosofia).



Ed è tutto da provare che chi studia i post di un guru poi sia

migliore. Per me i migliori sono quelli che realizzano le cose

migliori non chi studia i post di chi ha fatto le cose migliori.




























 mi pare inutile insistere.





Una cosa che adoro di ili che che qui quasi tutti siamo spogliati

dalle nostre carriere e rimangono solo le idee, ma per comprendere

meglio il contesto  : ma  hai mai avuto la responsabilità di un

progetto it ? E se si cosa ti ci giocavi ? Un rimbotto, il posto o la

casa ? Perché le cose cambiano e le vedi diversamente, dipende da cosa

sei passato attraverso.






 le cose vanno argomentate, non buttate lì.



il relativismo è quella corrente di pensiero che nega l'esistenza di

verità assolute. l'aberrazione consiste nell'applicarla a concetti

della vita come cultura e sapere (ma non solo) che non hanno

prerogativa di verità assolute ma che fa semplicemente comodo renderli

concetti relativi. fa comodo perché se uno riesce a sdoganare che (ad

esempio) il giudizio di bravura dipende dal punto di vista è chiaro

che chiunque può essere in qualche modo bravo al pari di qualsiasi

altro. direi che è un classico in un paese che del disconoscimento del

merito ne ha fatto una bandiera e dove guardacaso si è insegnato a non

avere punti di riferimento, cosicché i peggio potessero salire al

potere politico ed economico con tanto di nulla osta del popolino

"cornuto e contento" (cit.).




 b) disciplina e umiltà ce n'è fin troppa 



quindi dici che ILI rappresenta esattamente l'opposto della realtà 

italiana. Ci sta, per carità



-- 

Soprano


 cambiare/allargare il tuo giro? ;)



Ne ho incontrati ma nessuno di loro si sarebbe mai messo a dividere il 

mondo tra "noi" e "gli altri", forse perchè avevano quella qualità 

chiamata umiltà di cui parlavamo sopra.



Più ti leggo e più mi convinci che non ti vorrei mai avere nel mio team. 

Probabilmente tu starai pensando lo stesso di me, la buona notizia è che 

quasi sicuramente non succederà mai :)



-- 

Soprano


merito ne ha fatto una bandiera e dove guardacaso si è insegnato a non



Notizione : considerare "migliore"  chi studia post e conosce

abbreviazioni è il contrario del merito. Che prima di tutto va

ricercato nei risultati raggiunti, e non nella conoscenza o nella

capacità di citare i "grandi".  Sempre che non si intenda migliore

come migliore a parlare in acronimi.



Tutto è relativo tranne quello che è verificato sperimentalmente.



Quindi se parliamo di migliori, noi voi, di più consapevoli o meno

consapevoli, se volete appuntarvi un distintivo per le vostre

conoscenze dovete portare delle prove che tali conoscenze vi rendano

"migliori" altrimenti sono appunto chiacchere e distintivo. Questo si

molto Italico.



Da notare in fine che è molto più facile studiare codice, leggere

post, leggere libri e citare frasi o nomi a memoria che realizzare un

progetto software complesso con successo.




















 Quello che dice e' assolutamente normale: non sono parser. Infatti le regexp >nei parser, quelli con cui si tirano su dei bei progettoni come PostgreSQL o >Mongrel, sono usate per definire la singola token, il parser viene poi >generato nel linguaggio di output. 



Le regexp sono usate, solitamente, per il Lexical Analyzer, che prepara l'input per il parser propriamente detto. Nello specifico per risolvere il problema dello balance tag si usa, solitamente, una context-free grammar che è lo strumento adatto.



Per il resto concordo con te.



Ciao

  Francesco



ili secondo me non rappresenta un bel nulla, quando non è un muro del

pianto è solo una casbah di opinioni che raramente hanno riscontro nel

comportamento reale di chi le esprime.

detto questo: la maggior parte delle volte che un progetto fallisce è

perché parte già fallito per via di scelte fatte dal management

sbagliate in partenza e perché tutti continuano a seguirle senza

contestarle pur essendo consci che sono sbagliate. in italia umiltà è

disciplina si traducono in "chi cazzo ti ha detto di aprire bocca??".




 post, leggere libri...



lasciami indovinare.. tu sei uno che studiare e leggere libri non l'

ha mai trovato molto facile, vero? :)


 nella realizzazione o nella creazione di qualcosa di nuovo).



Seguendo questo "ragionamento" potrebbe anche accadere che dormendo

(invece che studiare il gran codice altrui), si possa avere una

folgorazione per un'idea "originale" (non certo come quei "copioni"

dei signori citati sopra che leggono codice altrui eh) da mettere

subito in pratica - del resto è ben noto come gli inventori "nascano

imparati", pena il fallimento ("se leggi/studi sei finito" o giù di

li, deve essere il tuo motto) personale e professionale.



Tu devi essere uno di quelli che reputano la Storia e la Filosofia

materie inutili, uno di quelli che "io mi sono fatto da me, sul

campo". Ne hai di materiale per cambiare idea.



"Careful study and imitation of good programs leads to better

writing." - Kernighan and Plauger.



Non avere paura di studiare il codice dei due signori qui sopra, non

diventerai di certo meno "originale" se lo fai.


 ha mai trovato molto facile, vero? :)



Al contrario. L'ho sempre trovato facile, perfino troppo facile ed ho

sempre pensato che fosse una specie di lusso poter passare il tempo

sui libri, cosa che tristemente riesco raramente a fare.


cosa che tristemente riesco raramente a fare.



credimi, si nota...




 wrote:


scherzi a parte, e' sempre rischioso tirare a indovinare senza

conoscere qualcuno di persona, ma tu mi dai l' impressione di un

ottimo smanettone che si e' "fatto da se'" e si e' dato anche

parecchio da fare.. ma che nella fretta di imparare tante cose in

pratica ha trascurato la teoria e quindi non ha il senso dell

"insieme"... Lo dico perche' ogni tanto vieni inaspettatamente fuori

con un 'uscita brillante ma poco dopo riesci a dire cose che non

stanno ne' in cielo ne' in terra... Se mi posso permettere un

consiglio .. forse ti farebbe bene prenderti il lusso di leggere e

studiare un po' di piu' per armonizzare e razionalizzare le conoscenze

che hai...


 credimi, si nota...



Don't Worry, sinceramente della cultura informatica non me ne è mai

fregato niente. Per me la programmazione è un mezzo non un fine.

Quando ne so abbastanza da fare programmi che funzionano per me basta,

se mi serve di più studio per risolvere il problema.








 se mi serve di più studio per risolvere il problema.



mmm.. esattamente come avevo intuito.. sei un "reactive programmer"...

beh, se sei soddisfatto cosi', "suite yourself".. mi sono limitato a

ricordarti che con un po' di studio e preparazione si possono a volte

risolvere i problemi meglio e\o piu' velocemente , e scoprire o essere

pronti a cogliere un ' occasione per migliorare il proprio lavoro...


 pronti a cogliere un ' occasione per migliorare il proprio lavoro...



Qui entra in gioco la formula di Gleicher della resistenza al cambiamento.


 pratica ha trascurato la teoria e quindi non ha il senso dell



si si, hai perfettamente ragione. Anche se non mi definirei

esattamente uno smanettone, almeno completamente visto che no lo

considero affatto negativo. Mi sono preso le mie certificazioni, ho

studiato quel che mi serviva, il ciclo di vita, le metodologie ecc...

poi ho sviluppato un mio modo di portare avanti i progetti e detto tra

noi il metodo funziona molto bene da diversi anni.



E come ti dicevo mi piacerebbe avere la cultura IT di cpascoshi e

scrivere software a ben altri livelli. Ma anche sticazzi...me ne fotto

altamente delle regex, il mio tempo non posso impiegarlo per giocare

per vedere come sono realizzate o come sono ottimizzate, lo farò

quando potrò, adesso mi occupo di pagare il mio mutuo o del resto

della vita.



Ci campassi scrivendo codice lo studierei, ma io campo vendendo

soluzioni quindi meglio studiare marketing o le ultime trovate del

fisco.


















 quasi sicuramente non succederà mai :)



Decisamente no, se è di sw devel che stiamo parlando, l'ultima parola

spetta sempre al "talk is cheap, show me the code". Le idee che tu

esprimi e come lo fai mi interessano fino ad un certo punto - se

scopro che sei uno di quelli che fa/può fare la differenza, farò di

tutto per averti nel team (e per andare daccordo con te),

indipendentemente dall'impressione che mi dai o dal come esprimi le

tue opinioni. Preferirei "rischiare" nel costruire con te un'intesa

soddisfacente che non "accontentarmi" di altri sviluppatori

all'apparenza più "simpatici" e malleabili ma dal rendimento

nettamente inferiore.


 Perché le cose cambiano e le vedi diversamente, dipende da cosa sei passato attraverso.



Io sono passato anche attraverso progetti software da milioni di euro

in cui le regex hanno fatto il loro lavoro - no danni, niente disastri

- e così come me tutti i miei conoscenti. Non capisco, che vuoi

sentirti dire? Che gli altri sono degli irresponsabili che le usano in

situazioni di poco conto mentre tu che fai il vero lavoro

complesso(tm) non puoi proprio  "permettertelo"?. Mah.


quindi meglio studiare marketing o le ultime trovate del fisco.



de gustibus..:)


 nettamente inferiore.



buona parte del "rendimento" sta anche nella capacita' di

comunicazione e collaborazione. Una "primadonna" geniale ( o anche

nemmeno tanto geniale e con ego gonfiato, quelle che poi sono la

maggioranza in circolazione..) puo' fare altrettanti danni di un

simpatico ciuco, se non di piu'...






E anche  chi le progetta.


 della vita.



ho una buona notizia per te.. sembra che la Fornero sia d'accordo con

te.. se il problema e' che in Italia si studia poco, la soluzione e'

l' apprendistato...

http://www.ilfattoquotidiano.it/2012/05/07/fonero-nostri-giovani-sanno-lingue-litaliano-fare-conto/221199/


(per la serie.. se non fosse ancora chiaro che queste marionette fanno

gli interessi di chi vuole un popolo di servi ignoranti..)


 fisco.



Ah ecco, in pratica eravamo tra elettricisti a parlare del perchè un

certo pannello fa contatto... con un idraulico.

http://pontilex-wp-content.s3-eu-west-1.amazonaws.com/2010/10/facepalm-statue1.jpg



 - e così come me tutti i miei conoscenti. Non capisco, che vuoi



no, volevo solo essere certo di parlare con qualcuno che sa di cosa

parla. Così da valutare la tua esperienza meglio, il tuo contributo.






 certo pannello fa contatto... con un idraulico.
http://pontilex-wp-content.s3-eu-west-1.amazonaws.com/2010/10/facepal.
..



Beato te che puoi campare scrivendo codice, si vede che ci sono altri

che pensano al resto.






 E anche  chi le progetta.



si ma voi adesso vi siete fatti l'idea che io abbia l'anello al naso

solo perché schifo alcune soluzioni... ma chi ha lavorato con me negli

ultimi anni si è sempre trovato bene, abbiamo sempre consegnato con i

complimenti della committente e senza restare oltre l'orario di

ufficio.


 solo perché schifo alcune soluzioni..



Se sei un venditore di soluzioni e riesci a campare vendendole non puoi 

avere l'anello al  naso.


 avere l'anello al  naso.



Si, "venditore di soluzioni" che faccio io. Ben inteso, non sono un

commerciale. La distinzione sta nel fatto che nel mio lavoro il codice

non è così importante. Letteralmente se studiassi le regex non

mangerei. Sono più importanti moltissimi altri aspetti.




 mangerei. Sono piů importanti moltissimi altri aspetti.



Invece lo sei nel momento che le vendi oltre che progettarle.

Visto che per te la parte implementativa non e' importante che tipo di 

soluzioni vendi e fai?


 mangerei.



mica devi studiarle per forza a ore pasti.






Letteralmente se studiassi le regex non mangerei. Sono più importanti moltissimi altri aspetti.



tipo?



magna tranquillo (cit.)



;)


 tipo?



L'analisi è 100 volte più importante, se non capisci cosa devi fare e

come è un fallimento certo, poi c'è il database, un corretto disegno

fa la differenza tra il fallimento ed il successo. Poi ci sono aspetti

gestionali come la pianificazione e la garanzia che sei in grado di

offrire sul suo funzionamento in base ai vincoli imposti (per dire, io

accetto tranquillamente il "se poi non va non mi paghi" ), ed

ovviamente il prezzo. Dopo vengono le tecnologie scelte, poi il modo

di lavorare e poi il codice.



Da notare che il modo di lavorare viene prima del codice, se lavori

bene non ha nessuna importanza come scrivi il codice. Se conosci solo

4 istruzioni ma le sai usare bene e il codice è manutenibile che per

me significa non ripetuto, chiaro e semplice per me sei un bravissimo

programmatore. Se poi sai superare l'ostacolo tecnico con una

soluzione che non includa superintruderanali che ci vuole un anno per

capire come funzionano sei un Grande programmatore.



Il motto di oggi è : uno che sa 4 istruzioni le sa usare bene può

sempre imparare la quinta. Ma uno che ne sa 1000 e il progetto non va

non ha speranze.














































 soluzioni vendi e fai?



Faccio gestionali, vedi risposta a Riccardo.


 bene non ha nessuna importanza come scrivi il codice.



Ha importanza se poi quel codice lo devi mantenere.




 Ha importanza se poi quel codice lo devi mantenere.



Per esperienza, un codice semplice, perfino un codice procedurale

purché rispetti le regole della programmazione strutturata è

facilmente manutenibile. Il tempo maggiore si perde a far funzionare

stuperintruderanali complessi che funzionano bene per l'80% dei casi

ma quel 20% di volte in cui non sono sufficienti/non vanno ti fa

perdere l'80% del tempo.












 facilmente manutenibile.



Quindi ha importanza come lo scrivi e sopratutto come lo progetti.







E' contrario alla mia religione parlare senza sapere cosa si sta

dicendo. Non c'è bisogno che ti dia conferma io o chiunque altro qui

sull'ng al riguardo, le regular expressions:



- Sono considerate una manna da tutti, sono una delle invenzioni più

pratiche e fighe del nostro campo

http://www.dwheeler.com/innovation/innovation.html




- Sono usate in modo pervasivo ovunque - in bioinformatica, nel

routing sugli apparati Cisco, data mining, algoritmi genetici, settore

finanziario, nel processare davvero tutti i generi di data. Fai prima

a elencare dove non le trovi che il contrario.



- Non sono complesse come credi:

"Regular expressions are a very simple thing to teach provided you

have a person of sufficient skill. It's much easier to teach a good

programmer regular expressions than it is to teach programming to

someone who understands regular expressions. Hire the programmer."

Come vedi la risposta comune è "s'imparano facilmente", i syadmin ad

esempio le usano con profitto e non sono programmatori esperti. E

comunque quando necessario si fa testing per assicurarsi che

funzionino come ci si aspetti, proprio come per tutto quello che

riguarda il sw devel.



http://stackoverflow.com/questions/1160511/would-you-hire-a-developer-who-doesnt-know-how-to-use-regular-expressions




- Sono utilizzate moltissimo anche dove si "maneggiano soldi", che

pare essere il settore che ti preoccupa. Per dire, dalle note

dell'autore del testo di riferimento moderno "Mastering Regular

Expressions, 3rd Edition":



"Jeffrey Friedl was raised in... before moving in 1997 to Silicon

Valley to apply his regular-expression know-how to financial news and

data for a little-known company called "Yahoo!" "



Puoi provare a fare domande qui 
http://quant.stackexchange.com/


riguardo "regex e soldi", così lasci perdere l'ng e resetti il tuo

giudizio per un attimo.



Insomma, acquisisci altra conoscenza al riguardo, nun te fermà a

quello che _credi_ di sapere già perchè potrebbe non bastare per dire

si/no/forse-un-giorno alle regex. E qui veramente la chiudiamo.

Punto. :)


 Punto. :)



Perché credi che perda così tanto tempo su ili ? Per questo.




 Quindi ha importanza come lo scrivi e sopratutto come lo progetti.



Si, è importante. E torniamo all'inizio della discussione.





Ma pensa te :D

Per fortuna che non tutti abbiamo la pretesa di fare queste valutazioni: sai la solitudine.



  ngw


 gestione di una catena di farmacie non è complesso o è complesso,



Io ho parlato di gestione dei requisiti non centra nulla con UML mi sa 

che stai facendo un po di confusione.



Per quel che riguarda la complessità  se tu trovi piu' facile leggere un 

documento di X pagine (dove X aumenta in funzione della complessità del 

sistema) rispetto a guardare dei disegni per capire cosa fa un sistema 

anche dopo tempo degustibus fermo restando che UML  e' un linguaggio con 

cui puoi descrivere e formalizzare sistemi e  non un tool  per disegnare 

altrimenti basterebbe usare paint e avresti risolto.



Per quel che riguarda la modellazione di sistemi (che non 

necessariamente sono formati da solo software) uno dei valori che porta 

sta nell'indirizzare i possibili  errori  prima di passare alla fase 

implementativa  per ridurre rischi e costi.





 > dipende molto da quanto ne sai in partenza, da quanto capisci i

 > termini che ti vengono detti, ma sopratutto dalla tua capacità di

 > apprendere e ed analizzare il problema. Se lo  capisci puoi

 > concentrarti sul discutere i processi con il committente, se non lo

 > capisci puoi fare tutti i diagrammi che vuoi, fare tutte le astrazioni

 > ed applicare tutte le best practices teoriche che ti vengono in mente.

 >





Questa e' un'ovvietà se non riesci a padroneggiare il dominio di 

riferimento con nessuna tecnica puoi pensare di mettere in piedi un 

sistema (non solo software) per la gestione delle farmacie ma questo 

cosa centra?






 customizzabili per i processi del cliente  che non vuole modificare.



Io giuro vorrei sapere con che sistemi avete a che fare e se veramente

progettate software (gestionale, perché di quello stiamo parlando) che

macina più transazioni di un cluster Oracle o SqlServer ben

carrozzato.  Cioè buon per voi, spero che vi paghino proprio bene.












 l'esatto opposto.



È chiaro che ragionamo per estremi e che la conoscenza tecnologica è un 

fattore importante e utile, ma ti assicuro che ho visto progetti divenire 

complicati perchè molti dei sedicenti "conoscitori" erano incapaci di 

fare un passo indietro rispetto alle proprie indelebili convinzioni. Così 

come ho visto i "geni" che si inventavano soluzioni efficienti e 

astrusissime senza un briciolo di documentazione che una volta partiti 

per altri lidi lasciavano il precedente team nella cacca totale. Ho visto 

reinventare la ruota infinite volte perchè non si aveva voglia di leggere/

capire cosa avevano fatto altri. Ho visto spendere tempo e risorse per 

progettare soluzioni "innovative" che a conti fatti mettevano a rischio i 

progetti quando una soluzione più semplice e standard, anche se magari un 

po' meno efficiente e rivoluzionaria, avrebbe consentito di consegnare 

con tempo e margini di rischio minori. 



Insomma, le variabili da tenere in considerazioni sono molte, così come 

le qualità del buon informatico.



-- 

Soprano


 ha detto di aprire bocca??".



È vero, le decisioni del management spesso e volentieri complicano la 

situazione anzichè migliorarla. Sopratutto a livello di infrastruttura, 

di application server, di database, di gui e quant'altro: su questi 

aspetti devi fare con quello che hai e c'è poco da fare.



Ma rimane il fatto che quasi sempre il management non va al di la di 

questo: vede una gui, vede dei report di performance, vede dei costi di 

infrastruttura, fine. Tutto ciò che va oltre a questo è di dominio del 

team di sviluppo.



-- 

Soprano



Per l'appunto se continuiamo per estremi non ne si esce più, il senso

della mia "provocazione" era chiaro e con un fondo di verità piuttosto

facilmente accertabile. Non era certo di quelli che descrivi che

parlavo.


 Non era certo di quelli che descrivi che parlavo.



Esattamente quello che avrebbero risposto loro.    ...    :-)




 delle loro belle soluzioni.



tradotto in altre parole stai dicendo che i succitati progetti sono

falliti per incompetenza di chi li ha gestiti sulle soluzioni

proposte. scoperta sensazionale mi verrebbe da dire, peccato che la

teoria che è meglio avere nel team degli incompetenti invece che degli

innamorati della tecnologia (uso testuali parole) sia proprio quella

si sta contestando.




 si sta contestando.



Mi sembra che Soprano abbia spiegato tutto benissimo. Sono d'accordo

con lui al 100%.



Io l'unica cosa che posso aggiungere è che nessuno crede di essere

quell'incompetente preso dal "furore intellettuale e tecnologico" che

fa fallire il progetto.



E posso anche aggiungere che a mio parere l'unico modo che esiste per

"valutarsi" è sottoporsi al giudizio degli altri, dei clienti e dei

colleghi, sopratutto di quelli che coordini. Sono solo loro che danno

la cifra della propria incompetenza o bravura.
















 Esattamente quello che avrebbero risposto loro.    ...    :-)



Figurati, le "risposte" lasciano il tempo che trovano - anche chi

ignora risponde sempre che non è vero e la cosa non è che aiuti molto

poi. Quello che conta per me è continuare a lavorare in posti dove i

criteri di selezione tengono fuori sia gli uni che gli altri.


 la cifra della propria incompetenza o bravura.



bravo. quindi se un tuo collega che coordini viene da te a dirti che

conosce le espressioni regolari e che trova bizzarri i motivi per cui

ne vieti l'utilizzo tu cosa fai?



a) incassi la critica e accetti "la cifra della propria incompetenza o

bravura" che ti è appena stata data

b) bolli lui come "sedicente conoscitore" nonché attentatore

dell'incolumità del progetto da allontanare prima possibile



siccome finora la risposta è sempre stata b si dimostra come siete

bravi a pretendere l'umiltà dei vostri colleghi ma della vostra non se

ne parla proprio.



quanto ai fallimenti dei progetti la mia esperienza è esattamente

opposta alla tua, tutti i progetti che ho visto fallire malamente

facevano tutti capo a scelte estremamente conservative. l'ultimo in

ordine di tempo un progetto di bi su $azienda_distribuzione fatto con

lo strumento oracle la cui scelta si basava sul principio di "abbiamo

già tutto oracle, quindi naturalmente si fa su oracle anche questo".

cioè pensare che l'essere conservativi riduca il trauma da impatto e

di conseguenza il rischio di fallimento *è* il male. chi propone

soluzioni *deve* avere un angolo di visuale come minimo più ampio del

committente e comunque avere due/tre alternative su cui può fare di

volta in volta una valutazione del caso, perché è facile imboccare la

propria strada preferita in discesa specialmente se poi si è pronti a

dare la colpa a tutti tranne che a se stessi se questa non porta dove

si dovrebbe andare.


 già tutto oracle, quindi naturalmente si fa su oracle anche questo".



io non conosco oracle ma ... non credo il progetto sia fallito a 'causa' di 

oracle : forse con SQL server sarebbe stato un successo ? guarda che di 

progetti BI fatti con SQLserver e falliti miseramente ce ne sono eccome :-)



Andrea







ma infatti la colpa è comunque dell'azienda che non ha saputo realizzare 

ciò che ha proposto. era per dire che fare la scelta più conservatrice 

non preserva minimamente dal rischio di fallimento.