Newsgroup: it.lavoro.informatica
Titolo: Ricerca di aspiranti Tafazzi

http://www.infojobs.it/verona/programmatori-php-mysql/of-i373e50d57342f1aaa92954413b5be2






-- 

I fatti mi cosano


 I fatti mi cosano



mm .. questa e' veramente curiosa...io cerco sempre di essere il meno

"dogmatico" possibile.. ma php + no object oriented.. BRRRRRRRRRR


 I fatti mi cosano



Mah, magari si tratta solo di modificare una procedura già esistente

scritta in stile strutturato. Mi sembra ragionevole cercare di

mantenere uno stile uniforme. E tra l'altro penso che non sia facile

oggi trovare qualcuno che sappia programmare in strutturato, o magari

cercano qualcuno che non faccia tante storie. Essere chiari

dall'inizio è un pregio.



Tutto giusto, ma rabbrividisco all'idea dello spaghetti code che ci deve 

essere lì dentro



 essere lì dentro



mah guarda credo che un php-ista debba tenersi sempre pronto a scolare

la pasta... dubito che per un programma php di una certa dimensione

l'essere strutturato anziché a oggetti possa essere il problema più

grosso.




 essere lì dentro



Visto che cose del genere le facevo gia' nel lontano 1999 (anche se non in

PHP), sinceramente, se fossi in zone limitrofe avrei anche potuto

inviargli un CV.



Ciao,

Marco











-- 



questo articolo e` stato inviato via web dal servizio gratuito 

http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it







 essere lì dentro



Non ho capito bene. Tu ritieni che un programma qualsivoglia sia

spaghetti code, solo perchè scritto in stile strutturato? Fammi ridere

di gusto :-))

Io penso che la qualità del codice è assolutamente responsabilità del

programmatore (e spesso della storia del programma, se è roba che va

in giro da decenni, cosa non tanto rara a certi livelli).




 in giro da decenni, cosa non tanto rara a certi livelli).



Anche questo è vero. Ma chiediti (non c'è bisogno che tu risponda qui, è

una domanda retorica) quante volte hai avuto modo di lavorare con codice

sritto da programmatori "responsabili" e quante volte con codice scritto

da "quegli altri"...:-)


 di gusto :-))



Mi accodo alle risate ed aggiungo che l'oo è tanto bello ed io lo

adoro ma lo dovrebbero maneggiare solo chi sa cosa sta facendo.

Altrimenti meglio che scrivano procedure e funzioni, che già le regole

del procedurale non è che siano chiare a tutti, anzi!






 adoro ma lo dovrebbero maneggiare solo chi sa cosa sta facendo.



questo è vero nella misura in cui nessun linguaggio impedisce al

programmatore di scrivere un pessimo programma.


 wrote:


mah alla fine e' una questione soggettiva..  e comunque ogni stile di

programmazione andrebbe maneggiato "da chi sa cosa sta facendo". E l '

idea che la programmazione OO sia piu' complessa e' difficile della

procedurale e' solamente un mito....



sciocchezze da javista provinciale e sciovinista :)

con PHP si puo' scrivere codice molto chiaro ed elegante.

Come al solito si tratta di conoscere bene il linguaggio e lo stile di

programmazione ....

Che poi sia un linguaggio "facile" e su cui si puo' cominciare a

smanettare senza un buon background e' un altro discorso, che tra l'

altro vale anche per Javascript, e anche li' infatti puoi vedere tutto

lo spettro, dall' accrocchio terrificante al massimo dell' eleganza..


 con PHP si puo' scrivere codice molto chiaro ed elegante.



questo non è in discussione. bisogna vedere però quello che trovi

allorché devi mettere le mani su codice esistente e dove non è stato

utilizzato alcun framework (altrimenti l'avrebbero citato). la

fantasia progettuale che può indurre un linguaggio poco coerente come

php non ha limiti.







No, ritengo che codice php scritto in modo non OOP sia basato ancora su 

php4 e sia probabilmente portato avanti con pezze a legacy code un po' 

qui e un po' lì

Inoltre il refactoring a design patterns è possibilissimo, specialmente 

usando il dependency injection.

Il fatto che esplicitamente chiedano NON OOP IMHO vuol dire che c'è un 

gran capo che non sa molto dei paradigmi di programmazione degli  ultimi 

10 anni in php



Francamente la prospettiva di un codice procedurale pulito, ben 

organizzato, facile da mantenere la vedo molto improbabile, non 

impossibile, ma quasi

Posso sbagliarmi, ma non me la sento di rischiare :)



 php non ha limiti.



poco coerente? coerente con cosa? :)

Come e' ben noto ( anche a te se superi per un attimo i tuoi

pregiudizi e luoghi comuni..) la "fantasia progettuale" non ha limiti

in nessun linguaggio...

Di nuovo pregiudizi da javista costipato... ti suggerisco di ampliare

un attimo i tuoi orizzonti e le tue conoscenze.. a fare sempre le

stesse cose tutta la vita si diventa arteriosclerotici molto in

fretta...


 fretta...



Credo intendesse la tipizzazione debole, che è una delle cose che vedo 

spaventa di più i Javisti

M



 spaventa di più i Javisti



spaventa i javisti piu' provinciali vuoi dire.. :)

Credo anche io intendesse qualcosa di connesso alla tipizzazione

dinamica, ma allora sarei curioso di capire come mai me lo ricordo in

piu' di un post che si spippetta su Python :)  (trasgressione permessa

al javista di provincia perche' e' stato benedetto da bruce eckel ..)

Propendo per un caso di semplice "ignoranza & pregiudizio" :)




 un attimo i tuoi orizzonti e le tue conoscenze..



io invece non ti suggerisco proprio un cazzo. visto che ti diverti a

infilarti nelle discussioni come un frullatore riempito a merda

continua pure così che almeno si risparmia il tempo di risponderti

(che tanto poi è tempo perso). fup.


 spaventa di più i Javisti



magari anche quello. comunque quando hai tempo da perdere (ma proprio

da perdere, eh...) spiega a quell'altro la differenza fra tipizzazione

forte/debole e tipizzazione statica/dinamica.


 Per continui a farlo. Di' la verit : ti piaaceee! :)



penso stia sul culo anche a so'mà. ma è in ogni benedetto thread che

cristo manda su questo newsgroup... :P





Difficile che la spieghi io, mi sa che non l'ho capita del tutto.

Io ancora credo che la tipizzazione statica o forte di fatto sia quasi 

solo una rottura di coglioni.

Sarà che scrivo 80% PHP e 20% Java





Vabbé, pure io le facevo, anche se qualche anno più tardi, ma non è che 

per questo mi venga voglia di rimettermici.

Inoltre di solito questi committenti vogliono spendere epsilon/2, dato 

che cmq il codice

- tutto sommato funziona

- che vuoi che ci voglia a sistemarlo

- l'altro sviluppatore l'ha sempre fatto andare



Questi non li conosco, ma se tanto mi dà tanto ....







Più che stare sul culo, ripeto, è stupido.

Spero per lui che non abbia più d'una ventina d'anni.


 Sarà che scrivo 80% PHP e 20% Java



tipizzazione dinamica indica quando il tipo è stabilito a runtime 

anziché a compile-time. tipizzazione forte invece indica la presenza di 

regole semantiche che impongono al tipo di rimanere coerente. python o 

ruby sono esempi di linguaggi dinamici ma strong typed perché una volta 

assegnato il tipo ad una variabile quello rimane per tutto l'arco della 

vita della stessa.








 lo spettro, dall' accrocchio terrificante al massimo dell' eleganza..



Beh pure javascript come quell'altro non è un linguaggio che aiuta a

scrivere buon codice... fortuna che da un po' c'è coffeescript.


 programmatore



quoto. Da sempre si tenta di dare la colpa a qualsiasi cosa (linguaggio, 

tool, ecc ecc) per giustificare tutti i programmatori cialtroni che girano 






 programmazione andrebbe maneggiato "da chi sa cosa sta facendo".



Infatti, e giustamente nell'annuncio precisano che vogliono gente che

sappia cosa fare nello stile strutturato.

Quanto a PHP chiaramente non è il massimo per spingere a seguire un

certo stile in modo chiaro (che non vuol dire che tutti gli stili

siano chiari a tutti, anche agli inesperti), ma questo è quanto.






 del procedurale non è che siano chiare a tutti, anzi!



Preciso che pure io apprezzo l'oo, ciò non toglie che si può lavorare

in modo ordinato e ben comprensibile pure in assembler, ovvero l'anti-

oo per eccellenza, ed in modo disordinato ed incomprensibile in

linguaggi modernissimi, progettati dalla nascita per essere oo.


 impossibile, ma quasi



Non sono d'accordo sull'affermazione in generale, e ristretta allo

stile strutturato.






 solo una rottura di coglioni.



Dovresti provare linguaggi con tipi forti che inferiscono nel 90% dei

casi *automaticamente e correttamente* il tipo. Parlo di linguaggi

parzialmente funzionali come OCaml, F# (già Haskell è più complesso

essendo funzionale puro).







Scusa, mi sono spiegato male: non ne avevo capito pienamente _il senso_



 10 anni in php



Questa è presunzione.



Può esserci benissimo un gran campo che conosce l'oop, la usa o la

insegna ma che davanti ad un software scritto in procedurale non cambi

paradigma solo per seguire una moda o dogmi scritti sull'acqua.



Beh, la mia sarà pure presunzione, ma pure definire l'OOP una moda ....



M



 Beh, la mia sarà pure presunzione, ma pure definire l'OOP una moda ....



Non è sicuramente una moda, ma uno strumento in più. Ma solo uno

strumento.

Personalmente penso che, dato un certo algoritmo/procedura da

implementare, sia meglio usare un linguaggio che mi consente di farlo

in 100 righe che uno che mi obbliga a scriverne 1000.

Indipendentemente da quale paradigma implementi.

Insomma per ogni problema lo strumento più adatto, senza dogmatismi.



PS: va aggiunto che la dotazione di librerie e framework può far

pendere completamente la bilancia da un lato, anche se il linguaggio

di per sè non è il più adatto ad un dato problema.



Guarda, se in quelle 100 righe ci conti anche le righe del framework 

ovviamente sarà sempre più corto un programma procedurale

Se però non le conti allora avrai che con l'oop ne scrivi 10 invece di 

1000, specialmente quando ti lanci con le annotazioni



Se questi non vogliono passare all'OOP vuol dire che non stiamo parlando 

di 100 righe, probabilmente saranno 10k

Vacci a trovare una regressione lì in mezzo ;)







L'OOP è indubbiamente la più bella tecnica di sviluppo inventata, ciò

nonostante modificare un procedurale in un oop solo perché l'oop "è

meglio" è seguire una moda se la scelta non è fatta in base a

razionali.



Tra l'altro è la stessa strada imboccata da molti intorno agli anni

2.000 portando vecchi applicativi bancari o assicurativi scritti in

cobol in java convertendoli in oo in maniera dogmatica ed il botto del

fallimento di alcuni progetti echeggia ancora.




 M



si entra nell'ambito delle opinioni personali, in ogni caso a mio

modesto avviso la non-coerenza dei tipi peggiora (talvolta di

parecchio) la comprensione e quindi la manutenibilità del codice. poi

ovviamente ognuno si trova meglio a scrivere codice con certe regole

semantiche piuttosto che altre, ma bisogna anche pensare che a volte

c'è da mettere mano su codice scritto da altri.

questo naturalmente imho.





Qualsiasi cosa se la si fa senza motivo va a finire "a smerdone come i 

cachi maturi" con ottima probabilità

Non mi puoi dire però che l'OOP non abbia degli enormi punti di 

vantaggio in quanto a manutenibilità rispetto al procedurale

Chiaro che poi bisogna sapere quello che si sta facendo in entrambe le 

circostanze. Di modaioli son piene le fosse e su questo credo che 

concordiamo tutti



Io personalmente ad un cliente così proporrei di iniziare un refactoring 

del codice, incapsulandolo come prima cosa, mettendolo sotto testing 

come seconda.

Se sanno cosa deve fare il codice allora non ci vuole poi un abisso di 

tempo. Se non sanno più bene cosa debba fare il codice o come lo faccia, 

vuol dire che da qualche parte c'è dello spaghetti code pieno di hack. 

Non venitemi a dire che non avete mai visto cose così nella vostra 

carriera perché non ci credo (oppure sarò sfigato io).




Sì, su questo concordo in pieno, ma io personalmente preferisco fare dei 

sanity check ogni tanto piuttosto che perder tempo a esser costretto coi 

tipi delle variabili



Poi magari sarà anche la poca abitudine con Java eh, non dico di no



 razionali.



il ragionamento si applicherebbe pari-pari anche ad una situazione in

cui si sceglie di modificare un procedurale in un altro-linguaggio-

procedurale solo perché "altro-linguaggio-procedurale è meglio".

è normale che sul pregresso si tenda (giustamente) a ragionare in modo

conservativo.




 scrivere buon codice... fortuna che da un po' c' coffeescript.



beh non e' stato pensato per quello, e' stato pensato per permettere

anche a dei dilettanti di "creare qualcosa che funziona" ma e' cosi'

"elastico" che permette di fare cose davvero eleganti a chi invece

dilettante non e'... il prob e' che con la cattiva reputazione che ha

accumulato "un buon programmatore e' disposto a cose inenarrabili pur

di evitare di imparare Javascript" , come dice Crockford... :)


 carriera perché non ci credo (oppure sarò sfigato io).





QUOTO IN TOTO


 Sarà che scrivo 80% PHP e 20% Java



appunto :)




 vantaggio in quanto a manutenibilità rispetto al procedurale



Certo che lo sostengo !



In certi abiti gestionali il procedurale è la scelta giusta, i

software sono più economici, manutenibili e semplici.



Un esempio classico sono le stored procedure Oracle o SqlServer che

siano, la loro semplicità, velocità ed affidabilità sono (per certi

lavori) molto migliori di equivalenti scritti in oop.



Ma se vogliamo scendere nell'inferno anche le vecchie procedure cobol

delle banche sono più semplici, funzionali e menutenibili di

moltissimi accrocchi java o .net che tentano di rimpiazzarle, con i

programmatori che dichiarano oggetti e liste per qualunque cosa salvo

poi veder esplodere le macchine quando si passa dai 4 dati di test ai

4 milioni di produzione.
















 4 milioni di produzione.



si, e poi? vogliamo aggiungerci anche il programmatore java che

rovescia un secchio d'acqua sul server dopo essere inciampato sul cavo

di rete tirando in terra l'armadio con gli switch? :-)

se paragoni il meglio di una parte e il peggio di quell'altra il

risultato è ovviamente scontato, la verità probabilmente sta nel mezzo

perché non è che i vecchi programmi cobol siano sempre dei gran

capolavori di stile. anzi, bisognerebbe tenere anche conto che in

queste migrazioni si chiede di riscrivere in pochi mesi dei programmi

che certo vanno come orologi svizzeri, ma al costo di avere alle

spalle dieci/quindici anni di storia vissuta fatta di sviluppi,

passaggi di mano, correzioni, modifiche, etc... a me piacerebbe

conoscere quello a cui è stato affidato un compito del genere e non ha

tirato un rosario di bestemmie :)


 4 milioni di produzione.





 perché non è che i vecchi programmi cobol siano sempre dei gran



veramente ho appositamente tirato fuori il peggio del procedurale...

ma non è questo il mio  punto che invece è anche più provocatorio :



il procedurale per lavorare in certi (e solo certi!) ambiti è

superiore all'oop.



In particolare quando lavori con dati sono tabellari e programmi che

sono facilmente scomponibili in operazioni semplici (aka immetti un

bonifico o accredita interessi), il procedurale è imho da preferire,

ma non un po'... parecchio.



Il che non vuol dire usarlo anche per l'interfaccia grafica che puoi

fare bella ed elegante magari in html e java e javascript usato in

modalità oo rigorosa.




 di rete tirando in terra l'armadio con gli switch? :-)



e rilassati , chiappette infiammate... si stava solo mettendo in luce

la tipica degenerazione OOP, con Java in testa.."classitis",

"patternitis", framework, interfaces, strati , sottostrati,

sovrastrati che spuntano come funghi...

Poi e' ovvio pure ai muri che ogni linguaggio/tecnologia ha le sue

degenerazioni e i suoi punti deboli...solo perche' si va a toccare l'

ambiente dove lavori tu mica lo devi prendere in maniera personale :)


 la tipica degenerazione OOP,



"si stava" chi? io ho risposto a lui. tu al massimo metti in luce la 

tipica degenerazione delle discussioni in cui ti intrufoli.




 dilettante non e'...



Guarda, sinceramente l'eleganza di javascript è un po' stracciona per i

miei gusti (ok, ci sono cose molto belle tipo le funzioni lambda e la

facilità con cui si creano e manipolano oggetti, ma il linguaggio ha

anche tanti difetti). Sviluppando per il web lo considero un male

necessario con cui bisogna convivere, pace. Coffeescript invece quello

sì è elegante, riesce a mitigare quasi tutti i difetti del linguaggio

nativo, da quando lo uso le mie giornate sono più serene.


 essere lì dentro





Paul Graham ha scritto:

"The object-oriented model makes it easy to build up programs by 

accretion.

What this often means, in practice, is that it provides a structured way 

to write spaghetti code. This is not necessarily bad, but it is not 

entirely good either."





Saluti  Manlio


 1000, specialmente quando ti lanci con le annotazioni



Senza dubbio. Ma i framework 8come le librerie) non fanno parte della

definizione progettuale del linguaggio. Ed inoltre forse ti sfugge che

framework e librerie esistono pure in ambito procedurale... :-))

Pensa solo al C.




 tirato un rosario di bestemmie :)



Completamente d'accordo. Però bisognerebbe anche sapere qual'è la

percentuale di successi di reingegnerizzazione di procedure Cobol in

oo (solitamente Java), anche nel senso di quanto è migliorata la

manutenibilità. Se tale percentuale risultasse bassa, dovremmo dedurne

che l'oo non è la "medicina" definitiva.

Personalmente ho assistito ad uno di questi rifacimenti, proprio

attorno al 2002-2004,... e mi basta :-)

In particolare la manutenibilità non è migliorata, anzi. Sarò

sfortunato...


 sfortunato...



anch'io ho assistito, anzi ho vissuto in prima persona, più di uno di 

questi rifacimenti. se posso sintetizzare l'esperienza:



- per questi programmi dalla prima stesura all'ultima modifica sono 

trascorsi mediamente dai quindici ai venti anni, ma se per il 

rifacimento ti danno tre mesi/uomo puoi brindare e dire che ti è andata 

di gran lusso.



- ovviamente documentazione zero. l'analisi è riassunta in una riga: 

"guarda quello che fa il cobol". se sei fortunato puoi trovare qualcuno 

degli autori che ancora fa il programmatore, anche se la maggior parte 

delle volte leggi fra i commenti i nomi e pensi "ma chi è, proprio quel 

tizio caio che adesso sta ai piani alti e che sta all'informatica come 

cicciolina sta alla clausura?" (fra il 95 e il 2002 penso che anche i 

maiali programmavano, bastava trovargli una tastiera adatta ai loro 

unghielli).



- che in questi programmi ci abbiano messo le mani decine di persone non 

c'è bisogno che te lo dicano, lo vedi da solo appena ti metti a leggere 

il codice. vi si trova un po' di tutto, dal codice morto alle pezze 

provvisorie che stanno lì da lustri...



- ma questo sarebbe anche nulla se non incombesse la leggenda del "cobol 

infallibile". non si sa bene perché, ma ogni programma cobol ha la fama 

di avere tutte e tre le virtù teologali del software: di non essersi mai 

fermato, di andare come le schioppettate e di non essere costato nulla. 

ma guarda il caso in ogni azienda che si rispetti c'è sempre il tizio 

sulla sessantina, con partita iva, baffi e pancetta d'ordinanza, che con 

due o tre procedure ci si è fatto una ricca pensione. e questo mentre 

devi discutere con il "capocentro" il quale per poche migliaia di euro 

vuole il programma chiavi in mano garantito e collaudato. ma si sa, i 

soldi sputtanati in tempi di vacche grasse non hanno memoria... :P



per queste e altre ragioni quando qualcuno mi cita la parola 

"migrazione" ringrazio per il pensiero ma faccio il gesto 

dell'ombrello... :)






 dell'ombrello... :)



e l'altra mano è in tasca che tocca il coso :-))


 più ingestibile, a parer mio.



Quello è uno degli aspetti, ma quello più grave è che mentre il cobol

o Oracle o prodotti simili erano pensati, studiati e progettati per la

gestione dei dati Java lascia una enorme libertà all'architetto :

peccato che poi questi presunti architetti siano programmatori senza

formazione e senza esperienza, gran teorici che spendono giornate o

giornate per far cose che un qualunque procedurale non solo fa in

minor tempo ma anche scrivendo meno righe di codice, con meno errori e

rimanendo più manutenibile (anche perché testarlo è più semplice).



Un po' come è successo per i file piatti e l'xml : bello è l'xml, ma

all'atto pratico i file piatti vincono 10 a 0 se i dati da trasferire

sono molti. ... Adesso c'è Json, nuova moda.. ma già meglio.




Lungi da me il flame, ma questa affermazione me la puoi provare o è 

un'impressione?

L'esperienza mia è il contrario, ossia che il codice procedurale non sia 

intestabile, ma che non è più semplice



 pi� ingestibile, a parer mio.
Ad oggi il fatto che ci hanno messo le mani decine di persone e'
deliberatamente scelto dalle aziende (almeno quelle grandi). Dove ho
lavorato io fino a pochi mesi fa, la politica era (ed e' ancora) quella di
fare gare al ribasso il piu' spesso possibile (al massimo una volta/anno)
con lo scopo dichiarato di fare in modo che il programmatore restasse li'
a lavorare per il minore tempo possibile e che fosse sostituito da un
altro programmatore appunto al piu' presto (NB: lo scopo non e' quello di
far durare il progetto il tempo piu' breve possibile ma proprio quello di
far si' che ci sia il maggior ricambio possibile di personale. Non me lo
sto inventando. E' quanto mi e' stato detto dal PM).
Ciao,
Marco.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Si' ma secondo te questo e' colpa di java, cobol o OOP ?
I linguaggi non possono mai sopperire alla mancanza di visione progettuale.

 sono molti. ... Adesso c'è Json, nuova moda.. ma già meglio.



eh, frena frena... :) prova a lavorare con dei bei dati strutturati,

da una parte con un xml descritto con lo schema e dall'altra

schiacciati su una riga. se il problema deve essere i volumi ci sono

apposta i parser su stream, gli stream compressi, eccetera,

eccetera...


 sono molti. ... Adesso c'è Json, nuova moda.. ma già meglio.





 dovrai usare le parole "imprenditori", "management", "mercato" o simili.
MEGAQUOTE

On Oct 2, 10:15 pm, "Marco Albarelli (fu Motosauro) @fisso "


QUOTE




 sono molti. ... Adesso c'è Json, nuova moda.. ma già meglio.



in parte hai ragione. OOP e' finito in una "corrente di pensiero-

buzzword" che specialmente attraverso Java lo ha portato a degli

eccessi ridicoli. Penso ad esempio ad EJB 2. E l' uso di XML ha

seguito la stessa sorte. E' passato dall' essere una piccola e banale

ma utile idea all' essere gonfiata in un ridicolo carrozzone.. E

spesso anche una buona idea come l 'unit testing degenera in una

specia di culto del test che diventa una disciplina a parte che ti fa

perdere di vista quello che stai facendo.. Insomma come al solito si

tratta di eccessi e difetti piu'  "umani" che legati alle tecnologie.

e spesso e volentieri indotti dal desiderio di "vendere" da una parte

e dall' incapacita' dei manager di giudicare dall' altra...


 grosso.
Smentisco (in parte): diciamo che l'OOP (relativamente a quello che è
possibile fare con PHP, cioè poco) aiuta a limitare i danni e,
fondamentalmente sposta in avanti, anche di molto, quella che è la
soglia di mantenibilità del codice.
Però è vero che oltre una certa soglia OOP e framework vari (Prado,
Zend, ecc.) servono a poco: è il linguaggio ad avere dei limiti, a
partire dal loose typing e dalla mancanza di almeno un precompilatore;
sono purtroppo problemi che fanno parte del design del PHP nato come
progetto casalingo/sfizioso: ai tempi del passaggio PHP 3 -> 4 si
sarebbe dovuto operare un taglio netto, a costo di scontentare una
quota di sviluppatori e rendere un po' di codice incompatibile. Ma
così, su progetti medio-grandi, è un mezzo disastro (e lo dico per
esperienza).
m.

 perdere di vista quello che stai facendo



L'unit testing fine a se stesso non ha senso se  a monte non c'e' una 

fase progettuale molto forte. La test driven programming secondo me e' 

una cosa da evitare.


 una cosa da evitare.



non colgo la consectio delle due frasi.



cosa  non ti e' chiaro?


 cosa  non ti e' chiaro?



principalmente (ma non solo) la logica secondo la quale *siccome* lo

unit testing senza la progettazione non ha senso *allora* la test

driven è da evitare.





Semplicemnte  dare troppa importanza ai test e incentrare lo sviluppo su 
questi ultimi (vedi  TDD) e dare poco spazio invece alla parte 
progettuale e' un modello di sviluppo che non condivido.
E' piu' chiaro?

 E' piu' chiaro?



a casa mia, il fatto che lo sviluppo sia incentrato sui test non

implica che venga tolto spazio alla progettazione.

semmai al contrario scrivere codice insieme alla sua test suite toglie

spazio all'improvvisazione.

poi per carità, le vie del software sono infinite, se uno vuole essere

cialtrone non c'è tecnica che glie lo possa impedire.



Io infatti stavo parlando della TDD e della sua filosofia  non di casa 

tua. Casa tua sinceramente non la conosco quindi non potrei neanche 

volendo esprimermi a riguardo.



Comunque se come affermi  non viene tolto spazio alla progettazione 

allora a casa tua non stai seguendo la TDD.



Concordo sul fatto che se uno vuole essere cialtrone nessuno puo' 

impedirglielo. Al limite le metodologie possono limitare i danni.


 un'impressione?
Se hai letto le premesse che ho fatto io non ho generalizzato su
*tutti i programmi* ma ho fatto un caso specifico su alcuni ben
specifici programmi che gestiscono dati e sono "parcellizzabili" (aka
inserisci un bonifico, calcola interessi cc).
Le procedure che fanno queste operazioni, se sono scritte almeno
decentemente, hanno un ingresso, delle tabelle di configurazione ed un
output. A volte possono essere lunghe, ma finiscono lì, l'ispezione è
semplice ed alla portata di tutti (certo se le sai leggere).
Se le disaggreghi in un software oo ed un application server per
testarle dovrai metter su un ambiente più complesso, con maggiori
interdipendenze tra oggetti diversi, che a loro volta potrebbero
contenere errori.
Se poi l'ambiente ti sei divertito a disaccoppiarlo con webservice o
con altre tecnologie il test diventa un calvario.
Ripeto, mi riferisco a procedure specifiche, che nella mia esperienza
mantenere sul db o sulla macchina predisposta per fare quel lavoro da
garanzie di affidabilità, manutenzione ecc... superiori.
Io non lavoro in AS400 ma lo conosco ed è ancora tanto diffuso anche
per questo : scrivere una procedura che estrae l'inventario di
magazzino con un metodo diverso è molto molto più agevole e sicuro che
farlo con gli oggetti articolo, magazzino ecc.. (spessa cosa si
potrebbe dire con Oracle).





E' probabilmente vero che fai piu' sforzo la prima volta che lo stendi 

ma secondo me ci guadagni in manutenzione e flessibilit� poi. E' chiaro 

che questo dipende da come e' stato incapsulato. Poi nessuno ti vieta di 

usare una stesura procedurale per alcune parti se ritieni che la sia 

piu' efficiente.




 piu' efficiente.



Esatto, questo approccio misto e sopratutto non dogmatico è il mio.








Concordo sul fatto che non si deve essere dogmatici. Ci sono i pro e i 

contro in ogni cosa.


 eccetera...



l'XML è bello per la memorizzazione di informazioni libere ma come

mezzo per l'interscambio dei dati è una cagata pazzesca... Quanto gli

dai ancora di vita ? 5 anni ? 10 ? Già adesso dovessi progettare

degli  web service che li fai in xml ?








 allora a casa tua non stai seguendo la TDD.



e dove starebbe scritto questo?




 sto inventando. E' quanto mi e' stato detto dal PM).



E quale sarebbe il motivo di questo "caos organizzato"?


 magari se parliamo di erlang o haskell il discorso cambia).



E' vero, ma non tanti limiti più di quanti ce ne siano in C, od in

Pascal. Eppure C e Pascal di cose ne fanno, oh se ne fanno. Tieni

conto che versioni relativamente recenti di Cobol ammettono i

puntatori, che sono il cavallo di battaglia di C.





Qui



http://www.agiledata.org/essays/tdd.html




e' il motivo per cui poi e' stato introdotto l'amdd



punto 5.


 E quale sarebbe il motivo di questo "caos organizzato"?



Presumo (ma non ho certezze in tal senso) che sia teso ad evitare alla

fonte ogni possibile problema derivante da eventuali cause di lavoro che

qualcuno potrebbe tentare di avviare.



 mezzo per l'interscambio dei dati è una cagata pazzesca...



scusa ma quando mai? il contenuto xml può essere descritto in uno schema 

e validato, il che lo trovo fondamentale in uno scambio dati al di la di 

tutti i discorsi.




 tutti i discorsi.



no non lo trovo affatto fondamentale, lo trovo utile se il dato che

ricevi è sconosciuto o può variare molto, ma se il tracciato è certo e

condiviso trovo sia una enorme puttanata l'enorme sovra-costrutto

dell'xml che per di più fa perdere la struttura tabellare.



Teoricamente è bellissimo, le validazioni, le trasformazioni,  fai

tutto in automatico.



Ma in pratica si usano i piatti ed i file excel ( cvs o addirittura

nativo) per la comunicazione tra aziende e json per comunicazioni tra

macchine.



Ma perfino google esporta i contatti in cvs... l'xml ha fallito ed è

giusto così.






 proprio di no (spero). immagino tu abbia delle funzioni che riutilizzi.



Probabilmente lui si riferisce al fatto che nella realtà dei fatti

molti programmi "operativi" (Cobol ma non solo) sono scritti

esattamente così, replicando ampie porzioni di codice :-(

In effetti, senza andare al caso estremo che si replica l'intera

logica (es. il calcolo dello stipendio) in Cobol è naturale e diffuso

duplicare parti minori, tipo: routine di formattazione per stampa

elenchi; routine di lettura db tramite cursore o singola select; ecc.

(nota che comunque il Cobol ha meccanismi per evitare duplicazione,

costrutti call e copy). Ciò a prima vista è dannoso (codice duplicato,

bleah) ma ti consente quel disaccoppiamento che evita certe

castronerie che ho visto in ambienti OO superintegrati, dove ad es. la

classe di lettura db è comune a tutti e quindi se viene modificata

senza fare un'analisi superapprofondita scassa mezzo sistema.

Pro e contro, che vanno valutati nel contesto dell'ambiente

organizzativo, non solo sull'astratto tavolo da disegno del

progettista informatico.




 giusto così.



si, giusto i contatti di gmail... hai provato a vedere *tutte* le api

di google cosa ti ritornano? :)










 giusto così.





 marshal/unmarshal?



La forza di XML è lo  schema, da fornire assieme ai dati. Da questo

punto di vista in alcuni casi XML è molto appropriato (per es. nel

colloquio coi web services, dove il client può sapere poco o nulla di

quel che fa il server). In altri casi è estremamente prolisso, ed

anche limitato (sicuramente non puoi specificare da XML tutte le

validazioni che puoi fare da codice con algoritmi specifici del

particolare dominio).

Se priviamo XML dello schema abbiamo un formato come tanti, non vedo i

vantaggi. E tutto sommato non è che sia così fantascientifico

inventarsi un miniformato per descrivere lo schema di un file di testo

o CSV, se proprio si vuole fare finta che i sistemi colloquiano sempre

alla cieca, cosa che non è.


 di google cosa ti ritornano? :)



Qualche anno fa ritornavano tutte solo XML, adesso anche json, ma le

nuove sono REST e  tornano solo Json :



https://developers.google.com/+/api/




l'xml è morto sorry, pace all'animaccia sua.











JSON, certo ritornano anche xml



Volesse il cielo ...
M
-- 
I fatti mi cosano

 capiscono ed il livello di casino che ci possono fare è maggiore.



Questo  e' un problema di skill shortage piu' che della oop .



E' chiaro che se hai solo programmatori cobol a disposizione abituati da 

30 anni a vedere solo cobol difficilemtne potrai affrontare un progetto 

usando il paradigma a oggetti. Ma questo non inficia i vantaggi del 

paradigma.


 paradigma.



Parliamo di paradi-gma o do-gma? :-) Ovvero siamo tutti convinti che

la "vera" programmazione si può fare solo in OO, qualunque sia

l'ambito? Ovvero la verità è che i cobolari possono continuare

tranquillamente altri 30 anni ottenendo risultati più che

soddisfacenti nei loro ambiti specifici, se lavorano in modo ordinato

(lo stesso per chi lavora in C, assembler, Pascal, ecc.)? Propendo per

la 2.





Mai parlato di dogma torno a ripetere per la mia esperienza ho trovato 

molto piu' produttivo   l'uso del paradigma poi e' chiaro che non e' il 

santo graal dell'informatica; non e' una guerra di religione. Ho sempre 

riscontrato una riduzione drastica dei tempi sia nella parte 

implementativa sia nella parte manutentiva  rispetto alla programmazione 

procedurale (Ps io ho programmato anche in modalita' procedurale persino 

in cobol).

Se tu pensi che non ti porti nessun vantaggio continua a implementare il 

software con il paradigma procedurale.

Altra cosa non  sono da  confondere i linguaggi a oggetti con il 

paradigma. Puoi implementare un software a oggetti anche usando un 

linguaggio non nato per lo scopo.Paradossalmente pure in cobol potresti 

farlo.





I cobolari possono continuare a stare tranquilli per un semplice motivo: 

le banche non si sognerebbero mai di rischiare a fare migrazioni che 

mettano in  pericolo il loro core-business portato avanti da procedure 

che si sono stratificate negli anni e di cui si e' persa la memoria 

storica perche' le persone che le hanno implementate non lavorano piu' 

li da tempo.



Il fatto che si ottengano risultati soddisfacenti anche usando 

l'implementazinoe procedurale non significa che i principi della oop non 

possano migliorare quei risultati.










 l'ambito?



ma questo nessuno l'ha mai detto.


 alla cieca, cosa che non è.



nessuno fa finta che i sistemi colloquiano alla cieca, non ho mai

detto questo e neanche che sia fantascientifico inventarsi ogni volta

un formato.


 li da tempo.



No, non ci credo. Le banche avrebbero migrato se i paradigmi e le

piattaforme moderne avessero offerto qualcosa di migliore e più

affidabile.



La verità è che invece si sono portate dietro una complessità molto

maggiore senza offrire alcun vantaggio pratico in certi ambiti.



Ovvio che stiamo parlando di una frazioncina piccina picciò

dell'informatica (la gestione di dati contabili), in altri ambiti

hanno fatto una differenza incredibile.



Ma che la complessità raggiunta per fare qualunque cosa sia eccessiva

lo dimostra anche il fatto della proliferazione di nuovi ambienti di

programmazione (a oggetti ovvio) ma molto molto più semplici.












ma nel mondo reale più che con la skill shortage c'è la skill

absence.



E poi basta paroline 2.0 fighette, l'Italiano è tanto espressivo :  la

maggior parte dei programmatori non ci capisce una cippa e te ci devi

lavorare lo stesso. Mettici pure un toppino ma è così.






Quello che stai rilevando nella frase sopra sembra piu' essere un 

problema di errore implementativo del principio piu' che un errore 

intriseco al principio.





okay ma allora non dire che il paradigma oop non porta benefici e porta 

solo complessità. Dimmi semmai nel mio contesto non puo' portare 

benefici perche' non c'e' il necessario stimolo  per capirlo e 

produrebbe piu' danni che vantaggi.



PS: Direttorio non mi e' mai piaciuto quale traduzione  di directory :)






 solo complessit . Dimmi semmai nel mio contesto non puo' portare



eh no!



che stessi parlando si un contesto particolare sono stato attento ad

aggiungerlo più e più volte nei post, qui caro non sei stato attento

tu.





Si ma tu incolpi la oop di portare complessità io  invece penso  che e' 

il contesto di riferimento ad essere complesso non il contrario :)


 progettista informatico.



ma guarda che io sono pienamente d'accordo, la sovraingegnerizzazione

è male. però anche l'estremo opposto è male. e visto che si parlava

dei test i side effects possono essere neutralizzati proprio con una

buona progettazione di questi.




>  senza fare un'analisi superapprofondita scassa mezzo sistema.





Qui ti puo' venire in aiuto la disciplina del change management.



la sovraingegnerizzazione e' di casa nella maggioranza dei grossi

progetti IT, e visto che lavori in questo ambiente dovresti almeno

avere l' onesta' di ammetterlo...

E non per questioni di linguaggi o paradigmi di programmazione , ma

perche' e' il modo piu' sicuro di estrarre denaro ai clienti quando

non si sanno offrire soluzione originali, belle e innovative..E di

fatto questa degenerazione e' un po' piu' in voga nel mondo Java che

in quello .NET, non tanto perche' le differenze tecniche tra le

piattaforme quanto per la forma mentis del programmatore tipo che

sceglie l' una o l ' altra...


 il contesto di riferimento ad essere complesso non il contrario :)



Facciamo un esempio concreto che trovavo spesso nei manuali : se devi

gestire un aereoporto con gli aerei che arrivano, si spostano,

decollano ed atterrano io decisamente farei l'oggetto aereo, che

deriva dall'oggetto OggettoVolante che ha i metodi decolla, atterra,

aggiorna posizione ecc... senza alcun dubbio. Poi lo uso per

interfacciare i controllori di volo, il display luminoso, la mappa a

terra, espongo il servizio per il computer di bordo ecc..



Se però devo fare il calcolo di redditività dell'aereoporto, con le

tasse pagate dai vettori, il costo del decollo ed atterraggio, il

carburante e lo stipendio delle persone non ci penso neppure ad usare

l'oggetto aereoporto con i metodi dammiSaldoGiornaliero che interroga

la collezione di aereomobili e dipendenti presenti quel giorno ecc...

invece faccio un bel programma procedurale che fa qualche somma e

qualche sottrazione partendo dai dati dei movimenti e puoi star sicuro

che funziona, che lo capisce anche un bambino, che a modificarlo e

testarlo non ci vuole niente e che il dato me lo da in tempo reale.
















 possano migliorare quei risultati.



Su questa affermazione generale discordo. Dipende dagli ambiti. Ed

evidentemente non sono il solo, vista quanta programmazione si fa

ancora con linguaggi non OO, a cominciare dal C.





Attenzione però a spostare il problema dal linguaggio, o dal paradigma

di programmazione, al "contorno". E' un pò facile dire: il linguaggio

o paradigma funziona benissimo, ma *solo se* la progettazione è fatta

secondo una certa metodica. Quindi OOP da solo non dà vantaggi, li hai

con OOP + test driven + altro.

La complessità totale aumenta di molto, basta una virgola fuori posto

nel processo complessivo che si rischia parecchio.




 testarlo non ci vuole niente e che il dato me lo da in tempo reale



Il fatto che lo capisca anche un bambino dipende da come e' stato 

scritto. Un procedurale puo' essere intuitivo oppure incasinatissimo 

come anche un'implementazione  scritta  seguendo i principi dell'oop.










 ancora con linguaggi non OO, a cominciare dal C.
Guarda che la programmazione e' una cosa l'applicazione dei principi oop 
e' un'altra. Anni fa abbiamo fatto insieme ad un mio collega un 
programma scritto in C completamente ma rispettando i principi della oop 
. Quindi il fatto che una cosa sia scritta in C non significa che abbia 
un approccio procedurale. E questo vale per qualsiasi altro linguaggio.

 nel processo complessivo che si rischia parecchio.



Perche' se prima non hai ingegnerizzato correttaemnte il processo il 

procedurale non risente di questo problema?



molto ma molto meno, perchè nel procedurale il "polpettone" del software 

sta tutto li, non devi andare in giro a cercare l'eventuale errore e di 

quale strato è la colpa.



nel paradigma OOP, con annessi e connnessi (application server, test 

driven, ORM, framework, implementazione di FW in house, ecc.) a volte 

fai più fatica a capire dove è l'impiccio e devi attivare più strutture 

per verificare, come sistemisti vari (di OS ,di AS), programmatori vari 

(magari alcuni oggetti appartengono a strutture diverse dalla propria, 

come nel caso di una struttura dove la parte contabile si interfaccia 

con la parte magazzino, o CRM ecc, e quindi gli oggetti a cui il tuo 

software fa riferimento non sono di tua competenza ecc).



Ciao






Perche' secondo te per implementare in un software i principi di oop 

devi per forza mettere su un application server usare orm o altro?





certo che no, ma dall'esperienza che ho, nei sistemi che utilizzano oop 
nella maggior parte dei casi vengono usati con FW, AS, ORM ecc..
anche perchè penso che a nessuno piaccia reinventare la ruota, se si 
utilizza OOP, stai per ogni progetto a riscriverti le varie componenti??
oppure riutilizzi i vari oggetti?? (creandoti un FW in house o 
utilizzando FW sul mercato), ti riscrivi ogni volta gli oggetti per 
l'accesso ai dati a seconda del DMBS che hai sotto o astrai con delle 
classi che implementano un interfaccia su diversi DBMS??? (creandoti un 
ORM) ecc..
come giustamente fai notare gli strumenti accessori al pardigma OOP non 
sono indispensabili, ma necessari, altrimenti è come se ogni volta 
riscrivi n programmi che implementano le stesse cose.
Ciao

 Ciao



Scusa io ho implementato programmi che si rifanno a principi oop senza 

tutti questi accessori che tu definisci necessari su sap usando 

semplicemnte sap e non tutta quell'infrastruttura eppure sono scritti 

rifacendosi all'oop. Tu stai affermando  che  la complessità 

architetturale che viene introdotta nei sistemi  e' colpa dei principi 

di oop. Per quanto mi riguarda e' invece colpa eventualmente di 

un'errata scelta architetturale e di framework utilizzati.

Perche' se vado a complicare il sistema inutilmente e' chiaro che quel 

sistema sara' molto piu' sensibile a problemi.









non conosco sap, ma da quanto identifichi utilizzando sap cosa utilizzi 

di sap ?? (se non ricordo male il linguaggio è abap??? e il db mi sembra 

sia oracle o ms sqlserver???)

da quello che leggo su wikipedia:

Technology



SAP based the architecture of R/3 on a three-tier client/server



     Presentation Server(GUI)

     Application Server

     Database Server



quindi a meno che quello che sto leggendo (non solo wiki) è una 

castroneria, tu utilizzi un AS, un FW (sap stesso che ti obbliga su 

scelte di architettura come la gestione utenti o altro) e un ORM (ABAP 

stesso che si interfaccia con il dbms sottostante)

se ho scritto qualcosa di errato correggimi pure, non c'è mai fine 

nell'imparare



Ciao


 stesso che si interfaccia con il dbms sottostante)



L'unica cosa che e' corretta e' che e' un application server.



Non utilizzi un framework ma il kernel di sap che virtualizza l'ambiente 

sottostante.



No non usi un orm a meno che tu per orm non intenda un'interfaccia che 

astrae l'accesso al db. MA questo non e' un orm e' un layer di

separazione.



In sap tu puoi programmare sia utilizzando il paradigma procedurale (che 

e' il piu' usato fra i programmatori abap) che quello a oggetti.



 un approccio procedurale. E questo vale per qualsiasi altro linguaggio.



Hai perfettamente ragione (anche se credo che senza gestione puntatori

la cosa è quasi impossibile). Ma allora perchè sostituire il Cobol (o

PL/1, RPG, C, ecc.) con Java? :-)  E' evidente che un linguaggio OO

nativo ti dà un aiuto decisivo.



Penso che il processo di progettazione di un procedurale è molto più

leggero di quello ritenuto necessario per avere buoni risultati con

OOP. Ovvero ciò che fatto bene in PP costa globalmente 100, in OOP

costa 100+X.

Ma dipende, nelle interfacce grafiche la OO è eccellente ed

estremamente naturale (infatti, coerentemente, l'interfaccia più usata

in internet è HTML che è tutto meno che OO :-)) Lo dico con

dispiacere.


 nativo ti dà un aiuto decisi



Questo e' chiaro che se il linguaggio e' concepito per dare supporto ad 

un   paradigma risparmi tempo se invece non lo e' e' molto piu' dura e 

il gioco non vale la candela. C'e' pure l'object cobol.


 dispiacere.

Questa non l'ho capita....

In che senso html e' un'interfaccia? al limite dovrebbe essere 

classificato come linguaggio di markup. ma questo cosa centra con il 

paradigma procedurale e funzionale?


 paradigma procedurale e funzionale?



HTML è un linguaggio per disegnare interfacce, giusto? L'ho citato per

deprecare che proprio in uno dei campi dove l'OOP dà il meglio si è

affermato un linguaggio che non è OOP. Specialmente con le pecette

tipo JSP, ASP, Javascript. Era proprio impossibile creare un

linguaggio di generazione interfaccia OO, esattamente come per es. in

Java si descrive una GUI con oggetti pulsante, textbox, ecc.? Domanda

retorica :-)








La puoi descrivere come vuoi anche in un file xml che vai a parsare e 

renderizzare  ma questo cosa centra?

In cobol come descrivi un'intefaccia grafica? domanda retorica al pari 

della tua......

Io non parlo di linguaggi ma di principi da applicare che sono

incapsulamento ed ereditarietà quando implementi del codice.




 tutti questi accessori



Aggiungo che il Linux, il kernel, è scritto secondo un paradigma OOP seppur 

abbastanza lasco.



OOP è solo un modo per organizzare meglio il codice, sono sempre procedure e 

dati solo che in questo caso stanno assieme e hanno lo stesso nome.



-- 

  Daniele "Vihai" Orlandi

  Bieco Illuminista #184213


 in internet è HTML che è tutto meno che OO :-))



HTML non è un linguaggio di programmazione, non vedo come possa essere OO.





Inoltre rappresentazione di HTML in Javascript, il famoso DOM, è tutto OO.







Per quel che mi riguarda sono principi che se applicati al codice poi si 

traducono in quello che dici tu anche se e' un po riduttivo.

Non basta che i dati e il codice viaggino assieme ma devi rispettare ad 

esempio anche il principio di incapsulamento.



Il punto e' se applico i principi dell'oop quindi

ereditarietà e incapsulamento (tralascio il polimorfismo che secondo me 

puo' avere effetti devastanti) al codice riesco ad avere 

un'implementazione piu' mantenibile  ridurre i tempi di sviluppo e avere 

codice piu' affidabile e quindi sostanzialmetne avere  un vantaggio 

competitivo?



La risposta per quel che concerne la mia esperienza e' si.


 della tua......



Se parliamo di interfaccia interattiva, la descrivi con una totale

separazione tra descrizione della pagina (da disegnare ;-) e codice

(per chi conosce Cics e BMS). Tra l'altro comprende un sistema di

gestione degli eventi (rudimentale).






 Inoltre rappresentazione di HTML in Javascript, il famoso DOM, è tutto OO.



Lo so bene. Ma con Javascript non descrivi la pagina.

Comunque vedo che il concetto non è passato, non vedete come me la

confusionarietà di queste varie tecnologie. Ok, pazienza :-)




 programma scritto in C completamente ma rispettando i principi della oop



??????




e quindi ? stai descrivendo un pattern di Model-View-Controller e allora?

L'MVC puoi impleemntarlo  usando principi dell'oop ma cosa centra questo

con i principi di incapsulamento e ereditarieta'?


 con OOP + test driven + altro.



questa e' una discreta vaccata....



Qual'e' il dubbio?


 quale strato è la colpa.



questa e' un' altra sciocchezza. Strati, librerie utili & inutili si

possono serenamente creare sia in PP che in OOP..

La tua percezione e' dovuta al fatto che la maggior parte dei

programmi complessi (spesso anche inutilimente complessi..) sono

scritti in OOP ai giorni nostri...


 retorica :-)



ASP.NET
 fa esattamente questo, idem per JavaServer Faces, e anche

Servlet & JSP , anche se in maniera un po' piu' rudimentale , usano

oggetti per descrivere e manipolare la pagina. Una curiosita: tu in

che ambiente programmi?


 OOP è solo un modo per organizzare meglio il codice



e' anche un modo diverso di "vedere" e "concepire" il codice che

scrivi, ma non posso pretendere che un compilatore capisca queste

cose.. :)


 confusionarietà di queste varie tecnologie. Ok, pazienza :-)



La confusionarieta' la vediamo benissimo ed e' perfettamente

comprensibile visto che le varie tecnologie sono nate e cresciute 'on

the fly' e "by trial and error" .... ma questo ha ben poco a che fare

con PP vs OOP...



ma niente.. solo a cosa sia servito una robetta tipo C++ visto che si

possono scrivere programmi in C che rispettano i principi OOP :)


 possono scrivere programmi in C che rispettano i principi OOP:)



Quella volta eravamo vincolati al compilatore C in quanto era quello lo 

strumento ufficiale di sviluppo presso il cliente; quindi non si 

potevano   usare un compilatore C++.



Non eravamo pazzi e volevamo passare per Tokio partendo da Milano per 

arrivare a Roma. C'era una motivazione di fondo :)



Quel programma fra l'altro e' ancora li che gira e ti parlo di circa 15 

anni fa.

La manutenzione che ha avuto e' stata minima se non per ampliamenti 

dovuti alle modifica di regole dettate dal business.


 Guarda che UML non dipende da una specifica tecnologia o filosofia.....



Non e' totalmente esatto. E' vero che UML non e' legato solo alle

implementazioni ad oggetti e che in parte puo' essere applicato ad

ogni tecnologia , ma e' stato esplicitamente pensato con in mente il

design object oriented (se non altro perche' era quello piu' in

voga..) e prevede diagrammi chiaramente mirati alle strutture OO.


 dati solo che in questo caso stanno assieme e hanno lo stesso nome.



l'oop prima di tutto è un modo diverso di analizzare il problema,

nessuno ha finora ricordato che per programmare ad oggetti è (sempre)

necessario e (spesso) sufficiente analizzare il dominio ad oggetti.

l'organizzazione del codice alla fine anche i linguaggi funzionali

permettono di farla in modo ottimale, o almeno forniscono gli

strumenti per farlo, senza rifarsi alla oop. ma in generale la

leggibilità del codice non è un piano su cui si può fondare il

confronto, ci sono persone che concepiscono il software solo in modo

procedurale le quali non capiscono proprio quando un problema è

analizzato ad ad oggetti e ci sono altre persone che invece trovano

gli oggetti naturali come bere l'acqua. è una questione di forma

mentis, studio ed esperienza.






 utilizza OOP, stai per ogni progetto a riscriverti le varie componenti??



perche', se si utilizza PP invece sei felice di riscriverti da zero

ogni volta tutto?

Bah...


 dati solo che in questo caso stanno assieme e hanno lo stesso nome.





 dovuti alle modifica di regole dettate dal business.
nessuno si sogna di sostenere che non si possano scrivere programmi
che funzionano bene in PP....anzi per alcuni tipi il PP e' sicuramente
piu' indicato.. ma se si tratta di programmi di grandi dimensioni e
che devono essere modificati, estesi ed aggiornati per decenni.. beh
allora OOP e' probabilmente piu' indicato...

 voga..) e prevede diagrammi chiaramente mirati alle strutture OO.x



Semmai prevede diagrammi che ti permettono di modellare un sistema a 

componenti ma non sei costretto ad arrivare a modellare il dettaglio  in 

termini di classi.  Un componente puoi implementarlo anche in PP.




Quoto


 allora OOP e' probabilmente piu' indicato...



Concordo. Infatti io non ho mai detto che OO e' la soluzione finale.

Dipende dal contesto.


 mentis, studio ed esperienza.



una domanda interessante sarebbe:per la maggior parte delle persone ,

esclusi fattori di condizionamente come  studi precedenti e influenze

di colleghi/maestri.. quale delle due tecniche e' piu' facile e

naturale?






Io credo il procedurale. Altrimenti non si spiegherebbe la negatività 

verso l'oop.


 , non vedete come me la confusionarietà di queste varie tecnologie.



Non sono confusionarie, basta aver chiaro il ruolo e il senso di ciascuna 

tecnologia.



 verso l'oop.



mah io sono di parte perche' a me OOP viene completamente naturale, ma

sarei curioso di vedere quanti di quelli che hanno atteggiamento

negativo su OOP hanno cominiciato a programmare in maniera

procedurale.. e magari l' hanno fatto per anni. Il prob e' che i

"vecchietti" hanno tutti cominciato e praticato inizialmente sul

procedurale e i "giovincelli" magari il procedurale non l' hanno

nemmeno mai incontrato...quindi e' estremamente difficile farsi un'

idea.. Quanto all' abbondanza di lamenti sull OOP e' dovuta a due

fatti, il primo e' che nel "mainstream" e' la tecnica dominante, e il

secondo e' che i vecchietti tendono a lamentarsi molto di piu' :P


 tecnologia.



dai, su..un compilatore ha il dovere di essere oggettivo anche sulle

tecnologie che ama :)

Le incompatibilita' e i quirks dei vari browser nella gestione di CSS

e Javascript a te non sono mai sembrate un tantiniello

confusionarie? :)

E il fatto che HTML sia un linguaggio nato come descrizione logica del

documento e finito in orgia di tables e font ?

O il fatto che javascript si chiami cosi' pur non c'entrando una

beneamata mazza con java?

E si potrebbe continuare.. chiaro che non sono ostacoli

insormontabili.. ma se non vedi confusione qui...




 possono scrivere programmi in C che rispettano i principi OOP :)



Oltre ad una sintassi comoda C++ aggiunge anche cose che non sempre sono 

gradibili, questo è il motivo per cui in Linux si continua a usare C, scelta 

che personalmente mi trova d'accordo.



 La risposta per quel che concerne la mia esperienza e' si.



Non posso che concordare ma evidentemente sono una di quelle persone per le 

quai l'OOP viene naturale e quindi ho un punto di vista "biased".



Mi piacerebbe capire se un "procedurista" affronta realmente il problema in 

modo differente o solamente modella il problema allo stesso modo ma mette il 

codice da un'altra parte.



 che personalmente mi trova d'accordo.



questo e' un altro discorso con cui si puo' essere o meno d' accordo.

Sostenere che si possano scrivere in C programmi che rispettano i

principi OOP e' un' altro discorso ed e' semplicemente demenziale.








E perche' dsarebbe demenziale? dove sta il problema  visto che e' stato 

fatto. Non hai i costrutti del C++ che ti aiutano a stenderlo ma puoi 

usare strutture e puntatori  per emularli senza nessun problema. Infatti 

come ti ho scritto in un altro post era quello ceh facevano i primi 

compilatori C++. PRima traducevano in C e poi compilavano il sorgetne 

risultante in codice C con li compilatore C standard.

SE tu nella stesura rispetti incapsulamento e ereditarietą non vedo il 

problema. Fra l'altro puo' non essere vero il contrario ovvero che un 

codice scritto in C++ a classi rispetti i principi della OO.


 rischiare tutti quei nefasti effetti che dicevamo.



francamente non capisco come tu possa fare una valutazione di questo

genere riferendoti solo e soltanto al paradigma.

secondo me tu parli di oop e pp ma nella tua testa pensi a cobol vs.

java e nel preciso ambito delle procedure gestionali. non è così?

perché mi resta difficile immaginare che sia così facile trovare

persone valide e capaci di fare programmazione concorrente in erlang

che è un tipico linguaggio funzionale.


 che è un tipico linguaggio funzionale.

Molto interessante l'erlang... lavori in ambito TLC?


 problema.



Il problema e' che se devi scrivere un programma in C, lo fai

procedurale , non cerchi di stuprare il C per farlo assomigliare

vagamente ad un linguaggio ad oggetti. Oppure ti implementi

sostanzialmente un linguaggio diverso, ma questo e' doppiamente

demenziale perche' stai tentando di reinventare qualcosa che gia'

esiste ed e' ordini di grandezza superiore a quello che potresti

accrocchiare tu, e oltretutto ti imbarchi in questa assurdita' per

sviluppare un singolo progetto...


 codice da un'altra parte.



bah cosi'  a naso credo che in procedurale.. si ragioni.. per

procedure :)

Cioe' si vede il problema come una serie di azioni da compiere, una

serie di attivita' da eseguire, senza che ci sia un' "identita" dietro

a queste azioni...o sei vuoi un' altra visione in procedurale i dati

sono "passivi" mentre in oop sono "attivi"..

(prego evitare facili battute sulla sodomia..:)



Ma questa e' una tua visione SOGGETTIVA. Un linguaggio puoi usarlo per 

implementare il paradigma che piu' preferisci. Se lo avessimo 

impelmentato in maniera procedurale non lo finivamo piu' doveva essere 

fuori in tempi strettissimi e con questa tecnica ci siamo riusciti 

grazie al riuso.

Vedi un po tu quanto demenziale e' la cosa.... Abbiamo rispettato i 

tempi e il prodotto e' riuscito egregiamente con tanti di complimenti 

della direzione perche' altri pensavano fosse impossibile.


 principi OOP e' un' altro discorso ed e' semplicemente demenziale.



Non è demenziale quando ci sono determinati requisiti.



Il kernel è un progetto complesso ma allo stesso tempo ci sono dei requisiti 

molto particolari sul codice prodotto, su come viene allocata la memoria e 

altri side-effect.



Ciao,



 E questo non ti sembra demenziale???



Seguendo il tuo ragionamento si conclude che anche usare C++ è demenziale, 

visto che è privo di una serie di fondamentali costrutti OO.



Tanto per cominciare stringhe, array e costanti non sono oggetti.



Le funzioni non sono oggetti.



eccetera...



 della direzione perche' altri pensavano fosse impossibile.



ma perche' evidentemente invece che "rispettare i principi OOP" quello

che avete fatto e' , come avevo detto prima, un programma procedurale

con una spruzzata di stile OO, cosi' per farvi sentire un po' piu' a

casa e lavorare piu' sereni.. :)


 serie di attivita' da eseguire



Eseguire su cosa? Su dati che per loro natura saranno molto simili ad 

oggetti e avrai un bell'insieme di procedure che opereranno su una ben 

determinata classe di dati.



Ripeto, sarò biased ma questo mi viene naturale.



 che è un tipico linguaggio funzionale.



Sicuramente la mia forma mentis non è funzionle :)



...ma ho trovato un ottimo compromesso per noi "imperativi" con linguaggi 

dinamici moderni con closure e fibers pur usando un modello asincrono con le 

mailbox a mo' di erlang.



Ciao,



 determinata classe di dati.



funzioni che agiscono su "dati strutturati" non bastano per fare OOP.

Se e' per questo allora il C sarebbe ad oggetti, e per rendere OO il

PL/SQL sarebbero bastati i record..



Per come la vedo io  quando si ragiona in maniera procedurale il

fulcro di tutto e' la l' azione che compi, i dati sono oggetti passivi

che possono anche avere una struttura ma non rappresentano il centro

del problema. In PP il centro sono le funzioni, che lavorano sui dati,

in OO non si ragiona piu' in termini di dati e funzioni ma di entita',

cioe' di astrazioni di "cose" che esistono nel mondo reale, o che

servono per descrivere e regolare il mondo reale. E' per quello che io

sospetto che OO sia un po' piu' naturale, perche' e' fondamentalmente

una simulazione della realta' (e se non sbaglio le sue radici vengono

proprio da li'..) mentre il procedurale e' un modo di pensare piu'

dovuto al modo di funzionare delle macchine che a quello umano..

Se devo dirla tutta per me l "OO e' un classico passo lungo la strada

che fa evolvere la programmazione "dal ferro al cervello".. ma come ho

detto.. sono molto di parte :)


 beneamata mazza con java?



Chiamalo ECMAscript se vuoi, sarà mica questo che ti crea confusione?



 casa e lavorare piu' sereni.. :)





A bhe tu parli sicuramente con cognizione di causa senza aver visto 

neanche una riga di codice indubbiamente....






 dovuto al modo di funzionare delle macchine che a quello umano..



Io la vedo esattamente al contrario. Il procedurale è il modello più vicino 

al ragionamento umano che vede gli oggetti (dati) e ci compie sopra delle 

azioni.



Nella realtà gli oggetti fanno realmente delle azioni. Agli oggetti non 

mandi messaggi, non chiedi dati, eccetera...



Ciao,







Riquoto





no no... mi ci sono interessato a titolo personale dopo che ho usato un 

sistema di messaging, rabbitmq, scritto appunto con questo linguaggio. e 

mi ha sorpreso per quanto sia veloce, robusto e affidabile.




 Si può fare OOP in assembly..

credo possa bastare cosi'...


 al ragionamento umano



perche' sei un compilatore :)

Scherzi a parte, ognuno e' fatto a modo suo, ma io continuo a

sospettare che la "naturalita' del procedurale" sia dovuta al training

iniziale che la maggior parte dei programmatori riceve a scuola..,

piu' il fatto che le prime cose che si imparano sono semplici

algoritmi..




 algoritmi..



Il fatto di poter seguire una procedura, ovvero una sequenza di azioni

prestabilita è insito nell'uomo dai tempi dei tempi e le ricette di

cucina o per i preparati medici ne sono un'esempio.



Ma anche i riti magici e le cerimonie religiose seguono un preciso

ordine prestabilito e sono algoritmi procedurali e ne eseguono tutti i

popoli della terra, quindi la capacità di seguirle è impresso nel

nostro firmware.



Seguire un sentiero in montagna, fatto di incroci e scelte ricalca

invece un workflow, anch'esso procedurale ed è anch'esso parte

integrante delle capacità su firmware che abbiamo di base, diciamo che

sono funzionalità di basso livello.



La capacità di immaginare oggetti e le loro relazioni ha più a che

vedere con la facoltà di comprendere ed immaginare una società o un

ecosistema animale. Sconfiniamo nella capacità creativa di immaginare

un racconto, una storia con attori e azioni e conseguenze.



Imho le capacità mentali necessarie sono molto superiori.




 Imho le capacità mentali necessarie sono molto superiori.



mah io piu' che in un ' ottica di "superiore ed inferiore" la vedo

piu' come una questione di "dimensioni" ..

E non nel senso di "avercelo piu' grosso" :)  Ma nel fatto che OO e'

piu' naturale se consideri un programma "nel suo insieme" e PP se

consideri le singole azioni che deve compiere in isolamento. Quindi va

da se' che un programma non e' mai solo OO , perche' ha sempre una

parte procedurale..l OO e' semplicemente un modo per creare l' insieme

e la struttura del programma senza rimanere confinati al modo di

pensare necessario per creare le singole azioni.  E' un estensione, un

modo per "sollevare lo sguardo" e abbracciare un panorama piu'

ampio...e di nuovo penso sia assolutamente naturale se non si rimane

prigionieri del primo modo in cui hai imparato a ragionare...

Trovo interessante quello che dici sulla "storia" perche' per me la

metafora piu' bella e calzante per la programmazione e' proprio

quella, scrivere una storia, un racconto.


 modellazione saltandola a pie' pari.



E' proprio UML che non mi risulta richiesto fuori di certi contesti

specificatamente legati alla OOP.

La modellazione la puoi fare tranquillamente esponendo i risultati con

altri tipi di output, diagrammi o quel che è. Già avevo citato DFD,

ER, tabelle CRUD, i classici flow control diagram. Puoi benissimo fare

modellazione senza usare UML (che poi è quel che dicevi anche tu, se

non erro).




 con PP vs OOP...



Ok, siamo d'accordo sulla confusionarietà (fiuuuu :-), sul perchè ne

abbia parlato rileggi i miei messaggi precedenti.




 programmazione e uno di markup.



Allora  mi dovresti spiegare la "profonda" differenza delle due

notazioni per creare ad es. un pulsante, ed impostarne le proprietà,

tra Java ed HTML. Ti sembra più OO la notazione Java (o Net o simili,

o magari Javascript) o quella HTML?  A questo punto o è Java (Net

ecc.) che fanno fare cose obbrobriose, oppure la differenza su cui

insisti con tanto puntiglio è una di quelle fumisterie che hanno

appestato il mondo IT?








Tutto puoi fare dipende quali rischi vuoi indirizzare e quali vuoi ignorare.

I classici workflow sono presentti in UML ma hanno un limite che possono 

rappresentare solo un aspetto di un  sistema  e non altri.

Ad esempio non possono descrivere come si comportano i componenti di un 

sistema  rispetto al tempo. Per questo hai bisogno di altri tipi di 

rappresentazioni che prendano in considerazioni il sistema da piu' punti 

di vista.

Quindi con un workflow potrai  modellare  solo un'aspetto del sistema e 

non gli altri.










 java e nel preciso ambito delle procedure gestionali. non è così?



No. E comunque quando ho scritto delle migrazioni da PP a OOP andate

male altri (anche tu mi sembra) hanno notato che dipendeva da scarsa

competenza degli addetti OOP coinvolti. Per cui il sospetto che queste

fantomatiche "vere" competenze OOP siano rare diventa forte.


 determinata classe di dati.



Hai ragione, deve venirti naturale capire quali classi definire nelle

situazioni "grigie", che ovviamente nella realtà sono le più

frequenti.

Se non ti riesce naturale, i problemi che porta l'approccio OO

possono essere tremendi.

A mio parere, poi, la "naturalità" funziona quando hai una

approfondita competenza del dominio.


 (Java in primis) penso ci si debba ragionare.





Quando implementi un software non sei obbligato a modellarlo prima.

Se non lo fai o ti sei gia' fatto  un tuo modello mentale chiaro su cosa 

devi fare o rischi di fare refactoring continuo  perche' non lo hai 

progettato prima. Questo vale sia per pp che oop.




 l'esigenza di indirizzare certi rischi.



Direi però che se il mondo è lo stesso (es. le banche) bisogna capire

come mai se il progetto è in Java si richiede spesso UML, ma se è in

Cobol no. I rischi non sono gli stessi?





I rischi della non modellazione di un sistema  (non sto parlando 

necessariamente di software) sono sempre quelli.

Se uno non vuole modellare o non e' conscio dei rischi o li reputa 

accettabili o li sottovaluta. Questo pero' non centra nulla con 

un'implementazione fatta in java.




 un'implementazione fatta in java.



Ma state parlando di usare UML per la modellazione o per l'analisi ?


 competenza degli addetti OOP coinvolti.



no io sono dell'idea che le migrazioni sono dei bagni di sangue a 

prescindere, fondamentalmente perché si tratta di riscrivere un software 

con a disposizione una frazione irrisoria di tempo e risorse impiegate a 

realizzare l'originale. poi la gente si chiede perché "vanno male", già, 

chissà perché. in ambito bancario io ho visto anche la "lanciatrice di 

query" e il "lanciatore di procedure serali", per dirti che situazioni 

kafkiane ci sono a giro, questa gente ha visto un bel mondo altro che...







quoto
































 pagina, definibile ovviamente da HTML, non è una proprietà "grafica".



"definita ovviamente da HTML"  una minchia..

La posizione e il colore di un elemento non sono affatto definiti da

HTML che si occupa della *semantica* di una pagina, della struttura

logica, non della presentazione grafica. *Puoi*  definirli in HTML

volendo , con una bella orgia di tables e font tag...ma di nuovo

questo significa che sei uno che non sa nemmeno da che parte e' girato

in web design...


 pagina, definibile ovviamente da HTML, non è una proprietà "grafica".



tu sei giusto un tantino a digiuno sull'argomento. niente di male, per

carità, ma sarebbe meglio non ti esponessi troppo in considerazioni

che poi si rivelano... come dire... "inesatte" (voglio essere

diplomatico).


 notazioni
Non sono due notazioni. In un caso (linguaggio di programmazione) i bottone 
è il risultato dell'esecuzione di codice, nell'altro è il risultato 
dell'elaborazione di un documento.
La differenza è profonda.


 in web design...



Quindi, a parte le solite fesserie, siamo finalmente giunti ad essere

d'accordo che con HTML "puoi" definire posizione, colore, ecc. (che

infatti agli albori "potevi" definire solo così... :-)

Il "web design" non c'entra niente con ciò che puoi o non puoi fare

con una tecnologia.

Tanto per rimanere in tema sulla confusionarietà di tecnologie dove

"puoi" definire certe cose, ma "non" lo devi fare, perchè sai... il

web design... :-))


 La differenza è profonda.



Però il risultato è lo stesso. Fai una distinzione sottile sul fatto

che nel caso del codice la sequenza di esecuzione è determinata dal

programmatore, nel caso di Html non è determinata dal programmatore.

Con ciò che ne consegue.


 progettato prima. Questo vale sia per pp che oop.



Mi sa che confondi un pò troppo lo strumento, UML, con lo scopo, la

progettazione.


 infatti agli albori "potevi" definire solo così... :-)



No, agli albori potevi definire solo la struttura, il massimo dello stile 

che potevi definire era con <b> e <i>.



La vera piaga  sono stati <font> e compagnia che però noterai sono deprecati 

da tempo.



Lo stille, pefino inline, si definisce a parte e finisce da un'altra parte.



 determinata dal programmatore.



No, non è questa la distinzione "sottile"....




Dove vedresti questa confusione?



UML e' un linguaggio di modellazione ( non uno  strumento )

general purpose che e' applicabile in tutti i contesti..

Ad esempio applicando i giusti  profili UML  puoi modellare anche 

processi di business non solo software.

Forse dovresti capire  prima cosa e' UML invece di ostinarti a legarlo 

unicamente all'implementazione di codice sorgente fatta in java perche' 

hai visto solo quello.




 infatti agli albori "potevi" definire solo cosě... :-)



no. la posizione non si č *mai* potuta definire in html.

ci sono vagonate di articoli sull'argomento, perché non ne leggi uno?


 ci sono vagonate di articoli sull'argomento, perch non ne leggi uno?



si ma son giovincelli..  che io ricordi nell'html 3.2 i css non

c'erano e si usava width e height, sta cosa della separazione è giunta

con l'xhtml, e comunque l'html resta un linguaggio bastardo e lasco

tutt'ora.



(nota di colore al taste of polvere, non mi voglio intromettere nel

vostro 3d)


 tutt'ora.



beh alcune osservazioni:



- width e height non mi pare proprio determinino il posizionamento, per 

il quale prima degli stili si usava le (burp...) table

- css2 c'č da una quindicina di anni, capisco rimanere affezionato ai 

ricordi dei bei (?) tempi passati ma informarsi un attimino su quello 

che č successo da tre lustri a questa parte mi parrebbe opportuno

- html descrive la *struttura* della pagina, non il suo layout e ne 

tantomeno il suo aspetto grafico. una volta che uno ha capito questo gli 

si apre un mondo davanti. certo che se all'html fai fare un mestiere che 

non sa fare hai voglia di definirlo "bastardo e lasco", ti ci prendi a 

schiaffoni tutta la vita senza arrivare a nulla.



html e xhtml tra l'altro sono la stessa identica cosa, cambia soltanto 

il fatto che html e' definito in sgml e xhtml in xml. Non sono neanche 

linguaggi in senso canonico, non avendo alcun genere di costrutto, ma 

appunto linguaggi di markup, che son robe totalmente diverse.

Dubito che qualcuno che si occupa professionalmente di web nel 2011 

tenti di definire l'aspetto della pagina via html. Non solo la maggior 

parte degli attributi degli elementi che definivano la visualizzazione 

sono stati deprecati un decennio fa (se non di piu'), ma e' anche un 

incubo totale, bisognerebbe usare stili inlinea in continuazione.

I CSS ci sono da meta' anni 90.



  ngw




 schiaffoni tutta la vita senza arrivare a nulla.



Si ma qui non si tratta di farlo ma di sapere che si può fare. Di

sapere che l'html accetta sgrammaticature varie, che non è un

linguaggio solo semantico ma appunto bastardo perché contiene ad oggi

elementi di struttura e presentazione e sono cose che non può ignorare

uno che ci lavora.



A proposito ma te lo sai che fine ha fatto il duro e puro XHTML 2

tanto spinto dal W3C che garantiva una reale separazione ed una

definizione formale della struttura ??? Nel cesso. Qualcosa è arrivato

nell'html 5  ma i loro bei documenti xml puro sono falliti.



A a proposito, tornando alla tua affermazione "no. la posizione non si

*mai* potuta definire in html" si sappia che è una cazzata, ma grossa

eh. Anche perché il tag style è html, i css entrano in gioco solo se

ci sono i selettori altrimenti è html o xhtml con tag di stile in

linea, ovvero attributi html.



Unita alla progettazione a tabelle  (sconsigliata ma possibile) , alla

width ed alla height direi che la fregnaccia che hai detto sia bella

grossa.


























 tenti di definire l'aspetto della pagina via html. Non solo la maggior



Vedi proprio l'ottusità che ti pervade : il non capire che "meglio non

farlo" <> "non si può fare".



E' il conformismo il recinto della mente che vi soffoca la ragione, il

non comprendere che anche la strada sbagliata è una possibilità, il

non vedere il quadro completo ma solo lo stretto sentiero che altri

hanno disegnato per voi.








 linea, ovvero attributi html.



Quelli sono stili inlinea, style non e' un tag ma un attributo che si 

applica all'elemento che lo espone. Non esiste nessun tag style in 

html. L'attributo style contiene CSS, il selettore e' implicito visto 

che l'attributo appartiene ad un elemento.

Per me se ti incazzi meno appena uno ti dice mezza cosa e' meglio.

Ed e' vero, il posizionamento si puo' definire in HTML solo con le 

tabelle, cioe' "exploitando" un tag per fare cose che non dovrebbe 

fare, e infatti il posizionamento e' sempre stato definito sulle 

singole celle.

Questa cosa si faceva tanti anni fa quando i browser non implementavano 

il box model correttamente, quindi la gente faceva quello che poteva 

con gli strumenti che aveva.

Oggi chi fa cosi lavora oggettivamente male. Le pagine tendono ad 

essere sensibilmente piu' pesanti, i crawler tendono a capire dentro 

quella sbrodolata di tabelle poco e niente, i browser non cachano 

efficacemente i documenti, e non puoi ad esempio usare un asset server.

Non ti incazzare eh.



  ngw






 Non esiste nessun tag style in html.



Hai ragione che quando usi lo style in linea è un attributo e non un

tag, ma che non esiste il tag <style> in html è una'altra castroneria

mica da poco. E un'altra cosa "html e xhtml tra l'altro sono la stessa

identica cosa": non è vero, hanno due specifiche diverse, storia ed

evoluzione diverse.










 evoluzione diverse.



QUOTO.



Ennesima dimostrazione che 9 programmatori su 10 non capiscono un

cazzo di web design :)


 schiaffoni tutta la vita senza arrivare a nulla.
questo e' un altro discorso e' siamo tutti d' accordo. Bisogna pero'
avere la lucidita' di riconoscere che quasi tutte le tecniche di
"DHTM", HTML, DOM & CSS sono molto piu' "a cazzo" di altre tecnologie
"lato server". E questo e' uno dei fattori che spinge la maggior parte
dei programmatori a sopportare le peggiori torture piuttosto che
cercare di impararle veramente  (un peccato perche' di fatto poi sono
pure interessanti e piacevoli quando ci si mette a studiarle sul
serio..). E il perche' di tutto questo e' ovvio e ben noto.. HTML & co
si sono sviluppati per trial & error , un colpo al cerchio e uno alla
botte e tentativi di accaparrarsi la piu' larga base di utenti
possibile, in mezzo alle guerre tra browser e HTML quando e' nato
c'entrava davvero poco con l' uso che se ne e' fatto per anni ( anche
se ora ci sta per fortuna ritornando..ma per compatibiita' con gli
orrori del passato rimarra' a luuungo "lasco"...)

 grossa.
intanto io non ho detto che non si possa fare un layout di pagina con la 
table, al limite ho detto che fa schifo ma questo � un altro problema. 
ho parlato di posizionamento degli oggetti, e se questa secondo te � la 
fregnaccia allora dimmi: come fai usando tabelle, celle, width e height 
a mettere un testo didascalia sopra un'immagine (giusto per fare un 
esempio banale di posizionamento assoluto)?

 esempio banale di posizionamento assoluto)?
Eccolo qui :  tabella, riga cella con immagine come background, dentro
ci metti un'altra tabella la dividi e metti il testo dove vuoi.
Soluzioni che poi sono state usate fino a ieri ad esempio per fare le
cornici con i bordini arrotondati elastiche.
E comunque per posizionamento assoluto intendo posizionamento in px,
per relativo in % degli oggeti nella pagina, non un sostituto
dell'absolute in x del css, in html non puoi gestire la
sovrapposizione degli oggetti (una volta si usavano i Layer di
Netscape che avevano tutti gli attributi necessari senza css).
per completare la risposta : in html è possible mettere un bottone a
10px dal bordo superiore e 10px dal bordo sinistro, con a fianco una
label che inizia esattamente a 10px di distanza. E successivamente
dividere il resto della riga in 10 rettangoli proporzionali ?  La
risposta è si (se non ti riesce non ci posso fare niente), quindi
direi che si può definire la posizione in html, te che dici ?
Ciò non toglie che tu mi consegnassi uno schifo simile oggi te lo
rimanderei indietro ad un buon libro.

diplomatico).
:)

 evoluzione diverse.
Ah, quindi tu in realta' quando parlavi di tag <style> in linea dove "i 
CSS entrano in gioco solo se ci sono i selettori altrimenti e' HTML" tu 
in realta' stavi descrivendo un metatag che contiene esclusivamente CSS 
e che non mi risulta utilizzabile nel <body> di un documento. Che dire, 
per fortuna che non sei al W3, che capire le tue specifiche sarebbe un 
impresa.
XHTML resta HTML implementato in XML. Il w3c usa esplicitamente il 
termine "reformulation" e rimanda alla specifica di HTML4 per la 
definizione semantica dei singoli elementi. Che siano due specifiche 
differenti e' palese, altrimenti non avrebbero nomi diversi, che 
abbiano storie diverse e' altrettanto palese, visto che sono specifiche 
diverse, che abbiano avuto evoluzioni differenti e' altrettanto palese, 
come ti e' stato detto uno "diventera" HTML5 e l'altro scomparira'. Che 
XHTML fosse il mezzo per separare il layout dal documento e' 
oggettivamente falso, e che sia fallito per i motivi che hai detto lo 
e' altrettanto.
Per chi scrive HTML, HTML e XHTML sono interscambiabili, ed e' una 
feature, non un bug.
  ngw


LOL, per fortuna che c'e' "riccardo" che nell'anno del signore 2011 ci 

insegna come usare le tabelle :D



Equino', fammelo dire, che c;hai frequentazioni che farebbero 

preoccupare Berlusconi :D



  ngw




 di web design :)
LOL, e quindi, genio del design, figure e figcaption per te 
servirebbero per il posizionamento di una immagine? :D Hai avvertito 
quelli del W3C di questo tuo catch? :D
  ngw

 Per chi scrive HTML, HTML e XHTML sono interscambiabili, ed e' una feature, non un bug.
Interscambiabili de chè ? Sono doc type diversi,con sintassi diverse,
interpretati in modo diverso, con regole di validazione diverse e se
questo mestiere non lo fai per hobby lo dovresti sapere. Questa frase
è *oggettivamente* errata.

 di questo tuo catch? :D
no, � che io avevo citato come esempio di posizionamento mettere un 
testo sopra un immagine intendendo ovviamente sovrapposto, siccome lui � 
uno di quelli che capisce al volo quello sarebbe il controesempio.
cosa gli dovrei rispondere?

 hai beccato proprio quello peggiore :)
si, come no. a capirlo, per�.
fup

 è *oggettivamente* errata.



Quello che fa incazzare e' la saccenza che ostenti. Prima accusi chi ti 

corregge di "fare il maestrino", quando ti ho corretto soltanto le 

puttanate che hai scritto. Poi cominci a parlare del "mestiere" che 

ovviamente non fai, insieme all'altro cazzaro++ di riccardo.

"Equinozio", pedala, non sai di cosa parli. Ovviamente la sintassi e' 

diversa, uno deve essere XML valido e l'altro no. Ovviamente i DOCTYPE 

sono diversi, uno e' SGML e l'altro e' XML. Ovviamente la validazione 

e' diversa, uno deve essere XML valido e l'altro no.

C'entra qualcosa con quello che sostieni? Un cazzo. Non c'entra niente 

con il tuo fantomatico "posizionamento via HTML", le differenze sono 

riassunte su Wikipedia, vattele a leggere e *impara* una volta nella 

vita, invece che attribuirti vittorie ogni volta che ti senti attaccato 

(cioe' sempre).

"Ho sbagliato", non e' difficile, lo hai detto anche tu.

I tag di cui parli e che ti permettono di posizionare le tue cagate via 

HTML non scompariranno mai, perche' sei tu che li usi male. Li usavi 

male in HTML4, hai continuato ad usarli male in XHTML (e toh, mai un 

errore di validazione, ne pas?) e continuerai ad usarli male in HTML5, 

dove sono ancora ben presenti. Il problema non e' HTML che e' "bastardo 

e lasco", ma che sei talmente capra da non imparare neppure quelle 3 

regole in croce.



  ngw






 e' diversa, uno deve essere XML valido e l'altro no.



oh ciccio, l'hai detto te che sono la stessa cosa io che ci posso

fare ? Cioè hai proprio detto così, che sono la stessa cosa e che sono

intercambiabili.



Ma cosa vuoi che ti dica che è vero ?



Oppure vuoi che ti dica che in html non si può fare il

posizionamento ?



O che l'html è rigoroso e garantisce la separazione tra struttura e

contenuto ?





Tutto quel che vuoi va, non mi va di flammare tanto più che alla fine

una base di ragione ce l'hai pure te.





Anzi sai che ti dico, chiudo ripetendomi :



> tutt'ora.
Si, son giovincello, e te l'ho fatto a quadretti.
E no, non si e' mai usato width e height per il posizionamento. 
Curiosamente, il loro utilizzo e' legato alla loro traduzione in 
inglese, "larghezza" e "altezza". Il posizionamento avviene grazie al 
box model, che pensa un po', c'era anche ai tempi di HTML 3.2 (anno 
domini 1997), quando del resto i CSS c'erano eccome, risalendo ad un 
anno prima. Ma faccio senza dirtelo, sai benissimo che sono nominati 
nel *secondo paragrafo* della spec di HTML 3.2, no? Pensa quante 
cazzate in una sola frase, dovrei mettermi di impegno.
E' davvero curioso che questo Gange di esperienza non si trasformi mai 
in un rigagnolo di competenza, forse e' ora che lasci spazio ai 
giovincelli, che per me non ce la fai piu'.
  ngw

 giovincelli, che per me non ce la fai piu'.
Grande !
Mi mancavi, giuro.


eeeh te piacerebbe :)  dove e' che avrei detto 'sta roba???
Mi serviva solo un "immagine con didascalia" per pigliare per il culo
il povero stitikit che tra tutti gli esempi di sovrapposizione che
poteva scegliere ne ha scelto uno che si puo' fare "facilmente" con le
tables.. :) e la foto del macaco e' la prima ( e perfettamente e
meravigliosamente adatta visto che appena l'ho vista ho riconosciuto
stitikit!) che ho trovato..

 Mi serviva solo un "immagine con didascalia" per pigliare per il culo
appurato che non è questione di minuti e ne di ore, quanti giorni ti
ci vuole per renderti conto di non aver capito un cazzo?

 singole celle.



"non si dovrebbe fare" e' cosa diversa da "non si e' mai potuto fare",

sorry niente di personale....:)



scusa stitikit, se avessi saputo che ti sarei mancato cosi' tanto
avrei sicuramente cercato di passare tutto il weekend su ILI :)