PHP vs resto del mondo (qualità del codice)

[guest]

Come qualità, non cambia niente, la qualità la fa il programmatore, gli strumenti ti possono dare un aiuto.

Potrei benissimo programmare in Java tramite il blocco note e fare le stesse castronerie che farei con PHP.

Java, di suo, inteso come linguaggio di programmazione, non include un ambiente di sviluppo, va installato a parte, e la stessa cosa la puoi fare con PHP installando Zend, usando Eclipse o ZendStudio ed il suo debugger e così via.

A parità di linguaggio (visto che vuoi parlare di linguaggio e non di environment) PHP e Java fan fare castronerie allo stesso modo, così come ogni altro linguaggio di programmazione. apri il blocco note e prova.

Credo che purtroppo si tenda a voler sopperire alle capacità di un programmatore dando la colpa alla mancanza di un environment, ma per dire io potrei fare una castroneria con Java usando tutti gli strumenti opportuni, compreso i fantastici debugger etc etc che invece con PHP usando il solo blocco note non farei mai.

Il problema non è il linguaggio, ma è chi lo usa, come in ogni cosa.

[Uno]

Facciamo un discorso generale.
Come scegliamo un linguaggio piuttosto che un'altro?
Ovviamente escludendo il fatto di conoscerlo, chi conosce un solo linguaggio cercherà di fare tutto con quello.

1 Ciclo di vita totale dell'applicazione, o meglio di eventuali modifiche indispensabili (l'esempio che facevo sopra degli studi dei commercialisti dove ogni anno cambiano delle cose e spesso vanno aggiornate all'ultimo momento in pochi giorni)

2 Sistemi su cui va installato

3 Applicazione stand alone singola postazione (che oggi però è quasi roba solo da cellulare anche se c'è un computer solo) o applicazione server-client.

4 Necessità di molte piattaforme o sistemi chiusi e già configurati senza cambiamenti previsti (es lan di tot pc e server centrale, investimento che deve durare qualche anno, con i limiti dell'innovazione teconologica)

5 Mole dei dati trattati e mole di client che debbono interfacciarsi.


Etc etc... adesso ho scritto al volo, ma io personalmente valuto queste cose tra le principali per scegliere un linguaggio.
Php posso dire che le soddisfa praticamente tutte, tranne la 5 anche se con i dovuti distingui a volte cercando il compromesso (vedi i siti web, vedi anche realtà grandi tipo FB) tra praticità e necessità....

Con questo non sto dicendo che PHP sia il meglio e che vada usato ovunque ma spesso è un buon compromesso e l'unica motivazione che me lo fa scartare al 100%, senza se e ma, è quando ho bisogno di interfacciarmi direttamente con l'hardware (esempio sul cellulare, ho il mio pamp per symbian , ma non si può usare per sviluppare applicativi per cellulare, magari per giocare e provare qualcosa se capita di essere in qualche sala di attesa).
Oggi le api fanno miracoli in tal senso, ma è assurdo voler usare per forza php per compiti di tal genere.

Insomma denigrarlo o trattarlo con sufficienza non è una cosa da buon sviluppatore come non lo è osannarlo.

[Antonio]

Come qualità, non cambia niente, la qualità la fa il programmatore, gli strumenti ti possono dare un aiuto.

Potrei benissimo programmare in Java tramite il blocco note e fare le stesse castronerie che farei con PHP.

Java, di suo, inteso come linguaggio di programmazione, non include un ambiente di sviluppo, va installato a parte, e la stessa cosa la puoi fare con PHP installando Zend, usando Eclipse o ZendStudio ed il suo debugger e così via.

A parità di linguaggio (visto che vuoi parlare di linguaggio e non di environment) PHP e Java fan fare castronerie allo stesso modo, così come ogni altro linguaggio di programmazione. apri il blocco note e prova.

Credo che purtroppo si tenda a voler sopperire alle capacità di un programmatore dando la colpa alla mancanza di un environment, ma per dire io potrei fare una castroneria con Java usando tutti gli strumenti opportuni, compreso i fantastici debugger etc etc che invece con PHP usando il solo blocco note non farei mai.

Il problema non è il linguaggio, ma è chi lo usa, come in ogni cosa.

Allora, a prescindere dal fatto che volendo puoi anche metterti a programmare utilizzando le schede forate, passando direttamente il bytecode in binario per java o i codici ascii per il file .php, oggi giorno non si parla più di linguaggio di programmazione prescindendo dall'ambiente di sviluppo.

Quindi quando parlo di PHP parlo del linguaggio, dell'engine+WebserverAPiacere e di ZendStudio/Aptana/Netbeas/QuelCheTiPareConDebugger; quando parlo di JAVASE parlo di JAVA, "librerie SE", eclipse/netbeans/QuelCheVuoi, Tomcat/Jetty/QuelCheTiPare; quando parlo di JAVAEE parlo di JAVA, ""librerie EE"", eclipse/netbeans/QuelCheVuoi, JBoss/Websphere.

Anche i romani dicevano che "errare humanum est", quindi, assodato che nessun programmatore potrà mai scriverti al primo colpo 1k/10k LOC senza un errore con il solo blocco note, l'ambiente di sviluppo è *fondamentale* per poter scrivere codice che abbia poche imperfezioni.

Assodato che l'ambiente di sviluppo è molto importante, andiamo a parlare della qualità del codice prodotto influenzata dal linguaggio. Un linguaggio di programmazione può influenzare la qualità del codice prodotto quando, a livello di progettazione del linguaggio o dell'interprete, sono state prese determinate scelte che possono portare il programmatore a scrivere codice che sia, ad. es., poco riusabile o affetto da malfunzionamenti inaspettati.

Giusto per fare degli esempi su PHP di cose che sono state anche, fortunatamente, corrette negli anni:
- alcuni moduli php, tutt'oggi, non sono threadsafe (se non stai attendo in produzione esci scemo a debuggare e capire il perché di alcuni errori),
- magic_quotes: va eliminato alla radice
- register_globals: c'è ancora chi lo attiva
- goto: invece di eliminare obbrobri li aggiungono
- zero tipizzazione = maggiore possibilità di seminare bug in giro e poca chiarezza nel codice (var che da numeriche diventano stinghe o array e viceversa).
- lunghezza interi a piacere dell'architettura: se si vuole essere sicuri che si sta usando una var intera > 2^32 bisogna usare bcmath per storing/operazioni & Co. (evviva la portabilità)
- comparazioni fatte un pò a membro di segugio = error prone
- nomi delle funzioni builtin scelti senza alcuna logica = error prone (per fortuna che ci sono gli ide e non si usa più il solo blocco note)
- framework per unit/integration testing pressoché inesistenti (giusto symfony con la v.2 sta tirando fuori qualcosina di buono, ma devi usare poi il loro fw per intero)
- namespace (finalmente adesso ci sono)
- potrei andare avanti a lungo...

Ripeto, conosco ed uso PHP dal doppio del tempo rispetto a java, lo usavo dai tempi delle prime versioni di PHP3, quindi direi che non scrivo le cose perché sono un programmatore java e voglio tirare acqua al mio mulino

Semplicemente parlo per esperienza, purtroppo

PS: Python Success Stories - Wingware Python IDE anche rackspace è passata da php a python perché si son resi conto che mantenere i loro applicativi in PHP era oltremodo oneroso.

EDIT: Durante il ciclo di sviluppo sw, la fase di implementazione è quella che richiede meno tempo: a lungo andare è la fase di manutenzione che assorbe la maggior parte delle risorse umane e finanziarie; quindi avere codice di qualità ed un linguaggio (intendo sempre linguaggio+environment) che ti "costringe" (per quel che può) a stare sui binari della buona programmazione si rivela essere fondamentale

EDIT2: Ripeto sempre che il mio discorso parte dal presupposto che non ci siano degli incompetenti a programmare; perché un incompetente può scrivere con il deretano codice sia che programmi in java sia che programmi in PHP o in cobol.

[ceccus]

Salve,
Però, quello che dice Guest, non è tirato fuori dai "marroni" ... nel senso che va bene il linguaggio , ma occorre valutare anche il suo "eventuale" Environment, o tecnicamente parlando, il suo Application Server.
Se si fanno applicazioni che devono servire molti/moltissimi utenti in contemporanea utilizzando la transazionalità è praticamente obbligatorio utilizzare i servizi offerti da un Application Server e non tutti gli Application Server suppotano tutti i linguaggi di programmazione ... sul mondo open , credo, che vada per la maggiore , per le grandi aziende JBOSS e Websphere (quest'ultimo un po' meno "open" visto che è di IBM) ... sul versante Microsoft abbiamo COM+ (con tutti i suoi "fratelli" tipo DTC e IIS , visto che MS non è mai stata capace di "isolare" per benino gli strati di codice ...)
Va da sè, come giustamente detto, che se devo fare l' applicazioncina per gestirmi il mio magazzino che deve supportare un numero limitato di client, probabilmente non utilizzerò un Application Server ... però, se al posto del mio magazzino dovrò gestire, per esempio, i ricambi di una ditta Automobilistica, quasi sicuramente un Application Server lo troverò ... di qualsiasi natura esso sia ... Anche il CICS, con le sue ultime versioni, può essere considerato, oltra ad un Transaction Monitor , anche un Application Server , visto che è possibile far girare dentro di esso , per esempio, degli EJB ...
Quindi, a mio avviso, è importante considerare l' accoppiata , non in tutti i casi, ma in linea generale direi di sì.

Ciao !!

[andrea.paiola]

non essendo un programmatore (...professionalmente sono, come dire, attiguo ai programmatori...) non ho molta esperienza, ma ho giocato con vari linguaggi (e non solo di programmazione) fin da giovane... non che sia poi tanto vecchio eh, intendiamoci

professionalmente ho partecipato alla creazione di siti principalmente php, ma anche asp, .Net e Java... anche per banche

quello che scrivete è vero, ma php rimane molto usato essenzialmente perchè un programmatore php costa meno ed è più facile trovarne... code monkeys certo, ma la qualità super magari è meglio metterla nella progettazione dell'infrastruttura e pagare meno la stesura del codice, magari alzandone un po' la qualità con corsi/manuali/regole interne all'azienda

questo ovviamente non vale per chi ha "soldi da buttare" o "margini più larghi", tipo le banche

[Antonio]

non essendo un programmatore (...professionalmente sono, come dire, attiguo ai programmatori...) non ho molta esperienza, ma ho giocato con vari linguaggi (e non solo di programmazione) fin da giovane... non che sia poi tanto vecchio eh, intendiamoci

professionalmente ho partecipato alla creazione di siti principalmente php, ma anche asp, .Net e Java... anche per banche

quello che scrivete è vero, ma php rimane molto usato essenzialmente perchè un programmatore php costa meno ed è più facile trovarne... code monkeys certo, ma la qualità super magari è meglio metterla nella progettazione dell'infrastruttura e pagare meno la stesura del codice, magari alzandone un po' la qualità con corsi/manuali/regole interne all'azienda

questo ovviamente non vale per chi ha "soldi da buttare" o "margini più larghi", tipo le banche

Ovvio che se l'analisi e la progettazione del sw è fatta da cani, durante l'implementazione puoi usare il linguaggio che vuoi, ma il risultato finale farà sempre c@g@re.

Poi, per me, l'analisi che hai fatto sullo spendere più in hw e meno per il coding porta ad avere TCO più alti a lungo andare, perché se un software è fatto male non scala (o scala da cani) all'aumentare dell'hw.
Senza contare che spendere in infrastruttura significa anche spendere più soldi per il suo mantenimento; poi c'è da dire che all'aumentare della complessità aumenta anche la probabilità che si verifichino problemi.

Ricapitolando, buona analisi ma sviluppo fatto male (per errori di scelta del linguaggio da utilizzare o per non aver prodotto codice di qualità) porta:

• A breve termine: al potenziamento dell'infrastruttura hw ed all'aumento della sua complessità.
• A lungo termine: al refactoring/reenginering dell'applicativo (perché anche aumentando l'hardware non si riscontrano vantaggi).

In poche parole spendi più soldi per hw e manodopera ed altrettanti soldi per cestinare l'applicativo o rattopparlo una continuazione.

EDIT: Il problema ordierno è che i project manager la pensano proprio come te: per rispettare le scadenze (planning errato o p.m. che non sa fare il suo lavoro) o per finire prima il lavoro (per ottenere gratifiche) compiono scelte errate, consci che la gatta da pelare poi passerà al dipertimento IT, che dovrà mettere a budget più soldi per l'hw.

[andrea.paiola]

Poi, per me, l'analisi che hai fatto sullo spendere più in hw e meno per il coding porta ad avere TCO più alti a lungo andare, perché se un software è fatto male non scala (o scala da cani) all'aumentare dell'hw.

lo "scalare" è essenzialmente un problema innanzitutto di progettazione e si può ammortizzare nel tempo... vogliamo fare un esempio pesante? facebook

vuoi dire che non scala? usano php e, incredibilmente, mysql... ti sei chiesto perchè lo fanno?

quanti code monkeys avranno? poi certo ci sono anche le teste d'uovo (Haiping Zhao) che sanno pensare e scrivere un "compilatore di php"... MA non gli sarebbe costato di più avere magari cento programmatori Java/Python/altrolinguaggiofighissimo che cento server in più?

[Antonio]

lo "scalare" è essenzialmente un problema innanzitutto di progettazione... vogliamo fare un esempio pesante? facebook

vuoi dire che non scala? usano php e, incredibilmente, mysql... ti sei chiesto perchè lo fanno?

quanti code monkeys avranno? poi certo ci sono anche le teste d'uovo che sanno pensare e scrivere un "compilatore di php"... MA non gli sarebbe costato di più avere magari cento programmatori Java/Python/altrolinguaggiofighissimo?

Durante la fase di analisi e progettazione non scegli affatto le soluzioni da usare in fase implementativa eh, anche perché a seconda del linguaggio e dell'infrastruttura vanno operate scelte diverse: non confondiamo le varie fasi di ingegnerizzazione di un sw

Per quanto riguarda FB, pensi veramente che siano necessari 100 programmatori per mettere assieme, col linguaggio che ti pare, il portale?

[andrea.paiola]

Durante la fase di analisi e progettazione non scegli affatto le soluzioni da usare in fase implementativa eh, anche perché a seconda del linguaggio e dell'infrastruttura vanno operate scelte diverse: non confondiamo le varie fasi di ingegnerizzazione di un sw

non ho capito
resta il fatto che lo scalare non dipende dal linguaggio, non puoi quindi usarlo pro o contro php

Per quanto riguarda FB, pensi veramente che siano necessari 100 programmatori per mettere assieme, col linguaggio che ti pare, il portale?

era una cifra tonda buttata lì, non ci ho pensato un secondo

[andrea.paiola]

Ovvio che se l'analisi e la progettazione del sw è fatta da cani, durante l'implementazione puoi usare il linguaggio che vuoi, ma il risultato finale farà sempre c@g@re.

Poi, per me, l'analisi che hai fatto sullo spendere più in hw e meno per il coding porta ad avere TCO più alti a lungo andare, perché se un software è fatto male non scala (o scala da cani) all'aumentare dell'hw.
Senza contare che spendere in infrastruttura significa anche spendere più soldi per il suo mantenimento; poi c'è da dire che all'aumentare della complessità aumenta anche la probabilità che si verifichino problemi.

eh eh sono stato frainteso
non ho scritto "infrastruttura hardware", ho volutamente scritto infrastruttura perchè intendevo sia hardware che software... ci devono essere sia i mega-analisti-programmatori che costano un sacco ma ti progettano bene l'infrastruttura (software), ma poi hai bisogno dei code monkeys per le tante piccole cose e lì è il regno indiscusso di php... ecco che php viene a costare meno perchè il programmatore php costa meno: è nella manutenzione ordinaria che php fa vedere il suo vero valore!

mai provato a cambiare un css in, per esempio, Liferay? è un altro mondo! per fare qualsiasi scemenza devi conoscere almeno un po' l'infrastruttura... invece no, con php cambi un file e hai fatto

[Antonio]

eh eh sono stato frainteso
non ho scritto "infrastruttura hardware", ho volutamente scritto infrastruttura perchè intendevo sia hardware che software... ci devono essere sia i mega-analisti-programmatori che costano un sacco ma ti progettano bene l'infrastruttura (software), ma poi hai bisogno dei code monkeys per le tante piccole cose e lì è il regno indiscusso di php... ecco che php viene a costare meno perchè il programmatore php costa meno: è nella manutenzione ordinaria che php fa vedere il suo vero valore!

mai provato a cambiare un css in, per esempio, Liferay? è un altro mondo! per fare qualsiasi scemenza devi conoscere almeno un po' l'infrastruttura... invece no, con php cambi un file e hai fatto

Stiamo analizzando la cosa su due piani diversi, per questo non ci capiamo

Quella dell'usare PHP perché trovi delle scimmiette sottopagate che ti fanno abbassare i costi di manutenzione (a scapito della qualità complessiva del sw, dato che preferisci fornire software eventualmente con bug che poi correggi continuamente in fasa di mantenimento) è una scelta dettata dal vincolo economico

Qui si stava parlando di qualità del codice senza andare a fare queste analisi